Four ways to record a transaction, and four ways to grow state

Ethereum replaces the output set with a global mapping from addresses to accounts. The documentation describes two kinds of account: externally owned accounts, controlled by a private key, and contract accounts, which carry code and a storage map. A transaction names a sender, a recipient, a value and optional data, and its effect is a state transition applied to the global state. Balances are stored per account rather than derived from a set of coins, so a wallet's balance is a single lookup rather than a scan.

The account model makes some things simpler and others harder. A balance is directly readable, and a contract can hold and move value without the change-output machinery that Bitcoin requires. But because every account's state is part of one global trie, the state a node must maintain grows with the number of accounts and the storage they use, and the documentation's discussion of state growth and state expiry is a response to exactly that pressure. An account that is created and never touched again still occupies space in the trie.

Solana keeps the account model but separates the code from the data. The documentation describes a program as stateless executable code and an account as the container for data and lamports, with the program operating on accounts that the transaction passes to it. Every instruction declares the accounts it will read and write, which is what lets the runtime schedule non-overlapping instructions in parallel. The declaration is also a data-model statement: the transaction carries an explicit list of the state it touches, and the runtime's safety argument depends on that list being complete.

The Internet Computer's data model is neither an output set nor a global account trie. The documentation describes a canister as a WebAssembly module with its own persistent memory, and a transaction as a message delivered to a canister's method. The canister's state is its own memory, replicated across the nodes of the subnet it runs on, and it is not part of a network-wide state space that other canisters read directly. A call from one canister to another is an asynchronous message, and the state each canister holds is private to it.

That arrangement changes what state growth means. Because a canister's memory is local to its subnet, the state a subnet must replicate is the state of the canisters deployed to it, and the platform's answer to growth is to add subnets rather than to make one state space larger. The documentation describes subnets as independent blockchains that can be added to the network, which is a horizontal scaling story rather than a state-pruning one. The cost is that cross-subnet calls are messages with the latency and asynchrony that implies, and a developer who wants two pieces of state to be updated atomically has to keep them on the same subnet.

Storage is charged for directly. The documentation describes cycles as paying for memory as well as computation, so a canister that holds a large state pays for it continuously, and the developer has an explicit incentive to keep state small. That is a different pressure from Bitcoin's, where the unspent set is a shared cost borne by every node, and from Ethereum's, where storage is paid for once at the time it is written. Each model puts the cost of state somewhere different, and the placement decides who has an incentive to economise.

The table describes structures, not sizes. It does not say how large any network's state is, how fast it grows, or what it costs to store a byte on each one, because all three change and none of them is a property of the data model alone. A reader who wants current figures should go to the networks' own dashboards rather than to a comparison page.

The comparison is also silent on the questions this cluster covers elsewhere. It does not describe how each network reaches finality, which the finality comparison takes up, and it does not describe how each one executes a block, which the execution model comparison covers. The four pages are meant to be read together, because a data model only makes sense alongside the execution and settlement rules it serves.

Finally, the models are not fixed. Ethereum's roadmap includes work on state growth and data availability, Solana's account and rent rules have been revised, and the Internet Computer's subnet model continues to develop. This page describes each model as its documentation describes it at the review date, and it does not present a proposed change as a deployed one.