Sort the top gas spenders of the past 24 hours and what do you see? Centralized Exchanges as far as the eye can see. (Also, it is very common for exchanges to have multiple accounts splitting responsibilities like forwarding funds from deposit addresses etc.)
Even if you sort by the largest gas guzzler contracts, what do you see (besides Uniswap)? ERC-20 stable coins. Who uses ERC-20 stable coins the most (by direct call, not internal call)? Centralized Exchanges.
What can we do that is easy and will decrease the footprint of CEX on Ethereum?
Answer
Add a memo field in the transaction. This can be added during the London hard fork.
It can be inserted after the data field, and each byte added to memo will cost the same as calldata bytes (iirc. 16 gas for non-zero byte, 4 gas for zero byte)
This memo should not be accessible from EVM.
Why not just use the data field?
While txes to EOA accounts would be fine, ERC20 transactions would need to append the memo to the end of the transfer calldata. This might be fine now, but Solidity dev has said that in the future Solidity might check upper bounds on calldata. Also there is no guarantee that contracts don’t revert on extra data.
Why make memo invisible to EVM?
This is to prevent contracts from preventing memos.
Why allow useless data?
Set a max size for memo if that worries you. But tbh as long as there is a gas cost for bytes it shouldn’t be a problem.
How does this lower gas usage?
Currently, most exchanges do the following:
- Deposit account is EOA hot wallet. User sends to deposit EOA (21000 gas (40~60k for ERC20)) X deposit count
- Deposit sends to central single wallet (hot or cold). (21000 gas (40~60k for ERC20)) X deposit count
This essentially doubles the gas usage that is actually needed.
If there was a memo field, there could be an address format that specifies the memo field to be an identifier for each user. Or (like XRP and XLM) we could just tell them to manually copy paste the memo data.
Then each deposit would all be sent to the same account, no need to double the gas usage by creating a new tx.
Related threads I have created in the past.
EIP2876 is “how do we do this without a hard fork? (assuming memo feature fails)”
I think we can use the address format from EIP2876 as a format that exchanges can use with each other.
I will write up an EIP about this hard fork proposal, and modify EIP2876 to focus on the address format, and switch between the Deposit interface or the memo field depending on whether the hard fork change passes.
I like the discussions on other scaling methods, but there are some low hanging fruit here that can really help with congestion.