An Alternative Paradigm for Developing and Pricing Storage on Smart Contract Platforms

Smart contract platforms facilitate the development of important and diverse distributed applications in a simple manner. This simplicity stems from the inherent utility of employing the state of smart contracts to store, query and verify the validity of application data. In Ethereum, data storage incurs an underpriced, non-recurring, predefined fee. Furthermore, as there is no incentive for freeing or minimizing the state of smart contracts, Ethereum is faced with a tragedy of the commons problem with regards to its monotonically increasing state. This issue, if left unchecked, may lead to centralization and directly impact Ethereum’s security and longevity. In this work, we introduce an alternative paradigm for developing smart contracts in which their state is of constant size and facilitates the verification of application data that are stored to and queried from an external, potentially unreliable, storage network. This approach is relevant for a wide range of applications, such as any key-value store. We evaluate our approach by adapting the most widely deployed standard for fungible tokens, i.e., the ERC20 token standard. We show that Ethereum’s current cost model penalizes our approach, even though it minimizes the overhead to Ethereum’s state and aligns well with Ethereum’s future. We address Ethereum’s monotonically increasing state in a two-fold manner. First, we introduce recurring fees that are proportional to the state of smart contracts and adjustable by the miners that maintain the network. Second, we propose a scheme where the cost of storage-related operations reflects the effort that miners have to expend to execute them. Lastly, we show that under such a pricing scheme that encourages economy in the state consumed by smart contracts, our ERC20 token adaptation reduces the incurred transaction fees by up to an order of magnitude.

💡 Research Summary

The paper addresses a critical scalability and security issue in Ethereum: the uncontrolled growth of the global state due to underpriced, one‑time storage fees and the lack of incentives to free or minimize stored data. Because every smart contract’s storage persists forever without recurring cost, the total state size continuously expands, increasing the hardware burden on full nodes, encouraging centralization, and threatening the network’s longevity.

To solve this, the authors propose a two‑pronged paradigm shift. First, they decouple data storage from on‑chain verification. Application data are kept in an external, possibly unreliable storage network (e.g., Swarm, IPFS, Storj), while the smart contract maintains only a constant‑size representation of that data using a hash‑tree based universal accumulator (Camacho et al.’s construction). An accumulator compresses a set of elements into a single hash value and allows the generation of succinct membership or non‑membership witnesses whose size grows only logarithmically with the set size. Clients retrieve the necessary hash paths from the external storage, construct witnesses locally, and submit them to the contract for verification, thus proving that a particular piece of data is (or is not) part of the stored set without downloading the whole dataset.

Second, the authors argue that Ethereum’s gas model must be revised to reflect the true cost of storage. They suggest three complementary changes: (1) price storage‑related operations proportionally to the computational effort miners expend, (2) impose recurring fees proportional to the amount of state a contract occupies and to the overall network capacity, and (3) introduce mechanisms to reclaim space occupied by stale or unused contracts. Under such a model, contracts would be economically motivated to keep their on‑chain footprint minimal.

The paper demonstrates the feasibility of the approach by re‑implementing the most widely used token standard, ERC20, with accumulators. In a conventional ERC20 contract, two mappings—balances and allowance—store (address → uint) and (owner → spender → uint) data directly on‑chain. In the accumulator‑based version, three accumulators replace these mappings:

• balancesAcc accumulates (owner, balance) tuples.
• allowedAddressesAcc accumulates (owner, spender) pairs, indicating which spenders have been approved.
• allowedBalancesAcc accumulates (spender, allowedAmount) tuples, representing the amount each approved spender may transfer.

When a user wishes to transfer tokens, the client must provide:

1. Membership witnesses for the sender’s current balance and the receiver’s current balance.
2. Update witnesses for deleting the old balance tuples and inserting the new ones (sender balance minus amount, receiver balance plus amount).
3. For an approve operation, witnesses proving whether the (owner, spender) pair already exists, followed by appropriate update witnesses.

All these proofs are of logarithmic size, and the contract itself stores only the three accumulator roots and a few counters—hence the on‑chain state remains constant regardless of the number of token holders or approvals.

Empirical evaluation shows that, even with up to 400 k accounts and 400 k approvals, the accumulator‑based ERC20 consumes 5–10× less gas than the traditional implementation for the core functions (transfer, approve, transferFrom). The authors attribute this to the fact that the gas cost of their design is dominated by hash‑tree operations, which scale logarithmically, whereas the classic design’s cost grows linearly with the number of stored entries. However, under Ethereum’s current pricing, the one‑time storage fee for the accumulator’s root is still relatively high, making the new approach appear more expensive in absolute terms. The paper demonstrates that if the proposed recurring‑fee and effort‑based pricing model were adopted, the accumulator‑based design would become economically superior, offering both lower long‑term costs and a healthier network state.

Beyond ERC20, the authors claim the methodology is applicable to any dApp that requires verifiable data (e.g., naming services, voting systems, ERC721 NFTs). By keeping only a constant‑size cryptographic commitment on‑chain and off‑loading bulk data to a decentralized storage layer, developers can build scalable, secure applications while mitigating the “tragedy of the commons” that currently threatens Ethereum’s state growth.

In summary, the paper makes three key contributions:

1. A novel architecture that separates storage from verification using universal accumulators, guaranteeing constant on‑chain state size.
2. A concrete ERC20 implementation that validates the architecture and shows up to an order‑of‑magnitude gas savings under realistic workloads.
3. A revised economic model for storage that aligns miner incentives with state minimization, proposing recurring fees and effort‑based pricing to prevent unchecked state bloat.

If adopted, these ideas could reshape how smart contracts are designed, fostering a more sustainable and decentralized Ethereum ecosystem.