Exploring Security Checkpoints in Shard Blob Transactions Based on EIP-4844 by Fairyproof
Led by Ethereum’s co-founder Vitalik Buterin, recently an EIP to create a new transaction format for “blob-carrying transactions” was…
Led by Ethereum’s co-founder Vitalik Buterin, recently an EIP to create a new transaction format for “blob-carrying transactions” was proposed. And it is EIP-4844[1].
According to this EIP’s specification, although it is a stop-gap solution, the format it introduced for blob transactions will be the same as the format that will exist in Ethereum’s final sharding specification [2]. And eventually, all rollup solutions [3] will have to use sharded data (i.e., blobs) instead of calldata which they use now if they expect to submit rollup data to Ethereum.
Therefore, this EIP will very likely be adopted and implemented in Ethereum’s clients and existing rollup solutions will eventually have to make changes to be compliant with this EIP.
Whenever changes are introduced, issues or risks might be introduced as well.
As a blockchain security company, Fairyproof’s research team is extremely interested in the issues or risks that might be introduced by these changes. We studied this EIP, explored possible security checkpoints, and would like to share some ideas on these checkpoints.
There are significant changes introduced by this EIP in both the implementation of Ethereum clients and rollup solutions.
On the Ethereum client-side, a new blob transaction is proposed, therefore new data structures such as SignedBlobTransaction and BlobTransactionNetworkWrapper are introduced, and new algorithms such as validate_blob_transaction_wrapper are introduced.
On the rollup solution side, both Optimistic-Rollup solutions [4] and ZK-Rollup solutions [5] need to put rollup data in a blob transaction.
The changes in both Ethereum’s client-side and rollup solutions may not introduce noticeable vulnerabilities however the newly introduced blob transaction may render two kinds of mempool issues.
The first one is that a blob transaction has a variable intrinsic gas cost. And this would expose a mempool to attacks since a transaction may be qualified to be included in one block but may not be qualified to be included in the next block. To prevent such an attack, this EIP recommends only broadcasting transactions “whose gas is at least twice the current minimum” to greatly increase a legitimate transaction’s chance of being included in a block.
The second one is that a blob transaction has a large data size at the mempool layer, which would expose a mempool to DoS attacks. This EIP recommends increasing “the minimum increment for mempool replacement from 1.1x to 2x” to increase an attacker’s cost thus decreasing his/her attempt to attack.
It is worth noting that the EIP says these two are just recommendations. This means a developer may not need to follow them in his/her implementation. But as far as security is concerned the developer needs, by all means, to handle these issues in his/her code.
This is what a blockchain security company needs to pay close attention to when auditing an Ethereum client implementing this EIP.
In addition, these two recommendations were proposed to counteract attacks on mempools. If they are implemented it implies that if a non-malicious user wants his/her transaction to be promptly handled, he/she needs to pay a gas fee that meets these recommendations.
This is something a user should be aware of.
References:
[1] EIP-4844: Shard Blob Transactions, https://eips.ethereum.org/EIPS/eip-4844, Feb 25, 2022
[2] Shard Chains, https://ethereum.org/en/upgrades/shard-chains/
[3] An Incomplete Guide to Rollups, https://vitalik.ca/general/2021/01/05/rollup.html, Jan 5, 2021
[4] Optimistic Rollups,
https://docs.ethhub.io/ethereum-roadmap/layer-2-scaling/optimistic_rollups/,
[5] ZK-Rollups, https://docs.ethhub.io/ethereum-roadmap/layer-2-scaling/zk-rollups/
Join Coinmonks Telegram Channel and Youtube Channel learn about crypto trading and investing