Possible Solutions for Unsustainable Storage Growth

Development
,
21

Introduction

The Moonbeam and Moonriver community had previously discussed possible solutions for unsustainable storage growth in this forum post. This discussion then led to a Snapshot vote.

While the community appeared to give preference to MBIP-4: Storage Base Fee and MBIP-5: Gas-Based Storage Limit; overall turnout for the vote was rather low - in all 729 wallets voted, with a combined 1,616,014.49 GLMR. Furthermore, while MBIP-4 ended up winning the snapshot vote, this result was mostly determined by 1 single wallet voting with 1.1M GLMR. As a result, 180 wallets voted for MBIP-4, with a median vote of 2.48GLMR; whereas 348 wallets voted for MBIP-5, with a median vote of 5.6GLMR.

Because of the low turnout overall for the snapshot vote, the criticality of this decision and 1 single wallet potentially swaying the vote, an on-chain run-off vote will be conducted between MBIP-4 and MBIP-5. The general implementation details of these two solutions are explained in the original forum post, but this post will expand on some of the trade-offs between the two solutions; as well as provide a recommendation from the Moonbeam Foundation. However, the community can of course choose to ignore this recommendation.

MBIP-4: Add a StorageBaseFee - Pros and Cons

Pros:

  • Transaction fees stay the same for transactions with low storage increase (most of transactions). A user would see a higher up front transaction fee that would be refunded once the transaction is executed
  • The price for storage does not impact the price for CPU usage. This means that if your transaction has no impact on storage, you’ll have 100% of the StorageBaseFee refunded.
  • A block can be filled with both storage and CPU. In other words, transactions that only modify storage are not penalized via gas used, only through gas pricing. As a result, to fill the block with transactions that only modify storage will result in very high transaction fees
  • The maximum growth is roughly ~6.5GB/y. The exact number will vary based on the soft-limit per block (see below).

Cons:

  • This solution is complex to implement and also complex to explain to someone not intimately familiar with the code; because the actual fee would vary on a per transaction basis.
  • Querying the baseFee through an RPC call might show a higher value than what will actually be used. However, users that don’t use the maximum storage allowed will get a refund.
  • Fees paid don’t match the expected (baseFee + MaxPriorityFee) * gasUsed formula (or gasPrice * gasUsed for legacy transactions). Nevertheless, the effectiveGasPrice of the transaction receipt will return the resultant gasPrice used for a specific transaction. Consequently, fees paid can be calculated using effectiveGasPrice * gasUsed from the transaction receipt.
  • Storage heavy contracts will require manually providing higher fees than the baseFee. As a result, this might break a typical deployment script or scripts that build transactions that are very storage heavy
  • This has a higher impact on Ethereum RPC compatibility and scripts that work on Ethereum might not work out-of-the-box on Moonbeam, as some manual gas price adjustments might be needed
  • Each block would have a soft-limit of 40K bytes storage per block. If this limit is exceeded, it would require more fees to get the transaction to pass. However, this limit can be changed.

MBIP-5: Add a Storage limit per gas - Pros and Cons

Pros:

  • This solution is simpler to explain and to implement
  • There is no change to the base fee (when compared to MBIP-4). The transaction fee calculation follows the EIP-1559 standard, as this MBIP is focused on gas limit
  • There is a lower impact on Ethereum RPC compatibility. However, there is still a risk that deployments and transactions that might have worked in the past might not work after implementing this MBIP. For example, a transaction that uses a lot of gas already, without accounting for its impact on storage, might run over the transaction gas limit when this MBIP is implemented
  • The maximum growth is roughly ~6.5GB/y. The exact number will vary based on the hard-limit per block (see below).

Cons:

  • Each Block has a hard limit of 40k bytes storage, which cannot be exceeded.This limit is still open for discussion and could later be changed with a runtime upgrade.
  • Block storage and CPU are combined, 1 limiting the other. In other words, there can be blocks that are not doing any CPU operations (which is what typical smart contract execution is for) as their available gas is used with storage based operations
  • Gas price will increase with storage being used. This is a direct consequence of using gas to quantify storage usage. If storage usage is high, the gas used per block is high. Consequently, the dynamic gas price mechanism (similar to EIP-1559) will increase the baseFee of the block, increasing the transaction fees for the entire network

Foundation Recommendation

It is the Moonbeam Foundations recommendation that the community adopt MBIP-5. Not only is it simpler to explain to a non-technical user, it is generally more inline with Ethereum standards (both EIP-1559 and RPC compatibility) and so will lead to fewer integration problems for Solidity developers.

That being said, the foundation will of course abide by the community’s decision if it decides to go with MBIP-4 instead.

Voting

Given the importance of this decision and the relatively low turnout of the snapshot vote, an on-chain vote will be held. Two competing proposals have been submitted on-chain; these are:

Both proposals are system.remarks and are merely used to capture the will of the community. The vote for both has been fast-tracked to 7 days, and the foundation will implement whichever MBIP has more votes at the end of the voting period.

3 Likes