Feature Ideas & Requests: Modules to support Dapp on L2

[Ratimon]

Since the EIP4844 (aka Proto-Danksharding ) is coming soon in March, the gas fee on layer 2 will become much cheaper. Then, the set of smart contracts is expected to will be mostly deployed and be used on layer2.

I think it is worthwhile to consider having some discussions about adding features regarding dApp development on L2. This does not only include front-end components but also smart contract ones.

Context : calldata optimization

It is barely known that writing smart contract and gas optimization technique on the layer 2 chains require a different paradigm and design from layer 1. When developing applications on an L2, the majority of gas costs come from calldata. Therefore, gas optimization for L2 emphasizes minimizing that cost, while gas optimization for L1 focus on minimizing the execution cost. In general, most of the gas spent on L2s currently comes from data/security part NOT execution.

Besides, the gas fee structures on the l2 chains are differently calculated compared to layer1. the same set of smart contracts on different L2s could produce different gas results. This is because different L2 chains (like Arbitrum/ Optimism and etc) use different rules and formulas to compute how much they will charge the user for the calldata on top of the L1 cost. So, if one gas optimization method produces the optimal on one L2 chain, it does not mean it will also produce the same optimal result on the other L2 chains.

Moreover, these rules will have been evolving, as the client & Ethereum ecosystem matures overtime. By way of illustration, EIP4844 will make gas L2 data/security component even cheaper and the L2 execution part more significant, resulting in possible changes in how L2 execution fee will be calculated in order to reflect appropriate incentive & economic model.

Aforementioned, it is hard to standardized the fee markets (including execution, calldata ,and the blob fees).

I note that I, for reference, have provided some resources pointing about this topic as follows:

Rareskill's post about calldata optimization
sequence 's post about calldata compression
scopelift 's article
op-kompressor's implementation

My thought

I highlight that this will not only effect how smart contract developers will design and write smart contract but it could also effect how dApp will write front-end in case layer 2 becoming mainstream.

For instance, I, as an experiment, created two GitHub repositories. One is the implementation of call-data-gas-optimized of Uniswap and the other one is front-end, tailored designed for calldata optimization paradigm. Check them out at ( https://github.com/Ratimon/solid-grinder and https://github.com/Ratimon/uniswap-calldata-optimization-monorepo respectively )

However, most of current libraries, standard, and practice regarding dApp development still focus on layer 1 not layer 2. I feel that this topic is under-rated and needs to be raised and discussed more, so that the the right architecture could be standardized by the community.

Would love to hear everyone's thoughts, opinions, and ideas on this. I understand that this is not directly relevant to Scaffold-ETH 2, but it is worth to explore this interesting design space and some features could be drafted and integrated into Scaffold-ETH 2 so that the vision of Scaffold-ETH will align with Ethereum rollup centric roadmap 's vision.

[lenasula4]

nice