ERC20 transfer process data compression path analysis
This is ZeroKPunk from Orbiter.
Vitalik posted a tweet in August. This diagram shows the data space that can be saved when a user initiates an ERC20 transfer in ERC-4337 compared with the ordinary transfer. Reading this analysis if you are curious how the intermediate steps are accomplished.
The process of Step 1 to Step 2:
EVM will encode and store all data in the slot with 32 bytes, which will result in some wasted storage gaps in between. For more details, please refer to the official documentation of Solidity. This diagram can help you understand the principle:
This section can be implemented by combining the assembly code of solidity. There is a good tutorial for reference (It is also a trick used by Optimistic rollups when compressing transaction data): https://ethereum.org/zh/developers/tutorials/short-abi/
The process of Step 2 to Step 3:
ERC-4337 is introduced in the third step, and the data flow of Tx has been changed significantly, where we can see that the signature data is greatly shortened. The signatures are compressed because of the use of the BLS aggregated signature technology, which can combine the signatures of multiple transactions into a single signature, thus reducing the average number of signatures per transaction evenly spread down.
BLS can be interpreted as a scheme for bulk transaction signature compression. For example, each transaction contains separate signatures and public keys in traditional 10 transactions. In order to verify that the 10 transactions are correct, the signature and public key of each transaction must be verified separately, which takes up more storage and computational resources.
How is BLS signatures actually used in projects?
The process of aggregating signatures:
Reference: https://github.com/eth-infinitism/account-abstraction/blob/develop/test/y.bls.test.ts#L51
It is possible to generate signatures for 2 transactions at 2 addresses at the same time, and this step can be done off-chain or calculated out in contracts.
Verifying Bulk Signatures:
https://github.com/eth-infinitism/account-abstraction/blob/develop/test/y.bls.test.ts#L88
A node.js tool repository of BLS named hubble-bls could be useful: https://github.com/thehubbleproject/hubble-bls
The process of Step 3 to Step 4:
The initcode field is removed and the type tag is added. It is not clear what this field means, but it is also different from the definition of 4337. The Nonce is greatly compressed, it should be changed to a smaller data format. ERC20 prefix is also removed. Token Amount is also compressed, we saw an algorithm to compress the Uint256 field into Uint32.
The gas fee and fee params are compressed to fix the gas and gas price parameters to the 2² to 2¹⁶ power. The user can simply pass the corresponding exponent. Whether this affects the relevant economic model will have to be analyzed in depth.
The process of Step 4 to Step 5:
Compression of the Sender field: The guess is that the Sender and Recipient are changed from a string of 20 bytes to retrieving numbers. Like zkSync’s model, each address should be registered first, generating an account id. Eventually, the chain of interaction data is stored with this id, the specific mechanism can be used merkel tree to achieve. Nonce is directly removed, which is a field that can be directly discarded on layer2 because it is possible to get the nonce in the previous state.
