Ethereum and ICP: two ways to run a program on a chain

On Ethereum, a deployed contract's code is immutable. The EVM has no instruction that rewrites the code stored at an address, so changing a contract's behaviour means deploying a new contract and moving users to it. The pattern the ecosystem settled on is the proxy: a small, permanent contract holds the storage and delegates every call to an implementation address that an administrator can change. The storage layout of the implementation must match the proxy's expectations, which is why upgradeable contracts are written against storage-layout conventions and why a mistake in that layout can corrupt live data. The immutability is real, but the upgrade path exists and it carries an administrative key.

The Internet Computer takes the opposite approach at the platform level. A canister can be upgraded in place: the documentation describes an upgrade as replacing the WebAssembly module while preserving the canister's memory, with an optional pre-upgrade and post-upgrade hook that let the developer migrate state between layouts. The canister keeps its address, its cycles balance and its memory across the upgrade, so users do not have to be moved and no proxy is required. The trade is that the upgrade is a first-class platform operation, which means the platform's own rules about who may upgrade a canister — its controllers — are the security boundary rather than a contract's own access control.

Neither arrangement removes the hard part. Both require the developer to reason about how old state maps onto new code, and both make that reasoning the place where upgrades go wrong. The difference is where the mechanism sits: Ethereum's upgradeability is a pattern built on top of an immutable execution layer, and the Internet Computer's is a feature of the execution layer itself.

Ethereum charges for execution in gas, and the fee for a transaction is the gas used multiplied by a price that the market sets. Since EIP-1559 the price has two parts: a base fee that the protocol adjusts block by block and burns, and a priority fee that goes to the validator. The important property for a developer is that the cost is paid by the transaction's sender, at the moment of the transaction, and is proportional to the work the EVM performs. A contract that is never called costs nothing to keep alive, because there is no such thing as keeping it alive: its storage is simply part of the state that every node already holds.

The Internet Computer charges in cycles, and the model is closer to hosting than to a per-transaction fee. The documentation describes cycles as the unit that pays for computation, memory and network usage, with a fixed conversion from ICP that the network's governance adjusts to keep the cost of computation stable. A canister holds a cycles balance and is charged continuously for the resources it occupies, which means an idle canister still consumes cycles and will eventually be frozen and then removed if its balance runs out. The developer, not the end user, is typically the party topping that balance up.

The two models therefore price different things. Ethereum prices work performed and makes the caller pay for it; the Internet Computer prices resources held and makes the operator fund them. Neither is a rounding error of the other, and a developer moving between the two has to re-learn what "cost" means: a contract that is expensive to call but cheap to keep, against a canister that is cheap to call but must be kept funded.

The table describes mechanisms, not outcomes. It does not say which model is cheaper to operate, because that depends on the workload: a program called once a year and a program called a thousand times a second are priced very differently by a per-work model and a per-resource model, and the crossover point moves with the market price of gas and the governance-set price of cycles. It also does not say which is easier to build on, because that depends on what the developer already knows and on the libraries available.

The comparison is also deliberately narrow. It sets the two execution models against each other and leaves out the questions that the rest of this cluster covers: how each network reaches finality, how each one represents a transaction, and how each one scales. A reader who wants the wider picture should start from the cross-chain research hub, which places this page alongside the execution, scaling, finality and data-model comparisons.

Finally, the page describes the platforms as their documentation describes them at the review date. Both are evolving: Ethereum's roadmap includes changes to how state and execution are organised, and the Internet Computer's subnet and canister model continues to develop. Where a mechanism is proposed rather than deployed, the documentation says so, and this page does not treat a proposal as a capability.