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:
- MBIP-4: https://moonbeam.polkassembly.network/referendum/102
- MBIP-5: https://moonbeam.polkassembly.network/referendum/103
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.
To be clear, token holders should vote “Yes” to ONLY 1 of these two proposals based on their preference.
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.
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.