Why ERC-4337 Isn't That Simple in Layer 2 | Alfred Lu, imToken | ETHTaipei 2025

[Music] Hello everyone, I'm Alfred and today I will give a talk about the issues of Povery 7 on layer 2 and I currently work at Untoken Labs as a blockchain developer and you can find more information about me in my personal website chihallu. and my Twitter handler is Malu. And here's the today agenda. Uh we have four target issues about the implementation of 437 on event compatible layer 2. And the first issues is authorization issues.

Uh I will introduce how to manage account in multi- chain. And next is the address issue. uh I will explain why the address is matters and why we shouldn't assume the address send in 437 and next is the fee issues uh I will introduce how to get uh rational pre-ification guess on layer 2 and uh the final topic is contra accessibility and before the target issues uh I have a quick introduction for you to understand today's topic So what causes the difference? Uh we often subconsciously assume that implementation of 437 uh should be the same uh between the Ethereum and layer 2. But uh we may meet some problems like protocol difference and synchronization challenges.

It will cause our implementation of 437 different. So for example uh you may meet variations in EIP IP halfworks of course G charges and fee mechanisms and you may meet some synchronization problem like uh you cannot simply send one transaction and affect accounts across all chains simultaneously. But uh why we rarely discussed these issues before? Uh it is because in the past from the perspective of EOA we share the same address and same private key uh between the event compatible layer choose and uh even so the asset is not synchronized but the uh same address and set private key uh can make sure you use the identical authorization mechanism of your account. And uh now uh you have contra and a accounts uh not only the uh asset recommendation but your account address may differ and authorization methods will differ and off ownership states may differ too.

Okay. The first uh topic is authorization issues. So uh if we want to change an account ownership on chain X uh how to we uh ensure le Y updates as well. Uh it means uh we usually want to call uh transfer ownership function to modify our variable which is uh which perform as uh ownership uh storage in your country account. So uh what happens if it succeed on one chain but not another and this problem uh will be uh occur will occur in two scenario too like the changing signature verification uh for example you may want to change from pass key to multisk and another scenario is if a user's control key is lost and you have a recovery mechanism in your country account how to achieve the recovery across all trends.

So our target question is uh is there any protocol that can automate multi-chain authoriz authorization updates or make management easier? Uh the first solution is multi- chain signing. uh in multi chain signing the user can sign a single useration once and broadcast it across multiple chains instead of uh signing uh multiple user pressions to perform your authorization in multiple chains. So how to do the uh chain signing? Uh there are two approaches uh currently the one is coin basis approach is ignore the chain ID field from your user pressure hash so in your country account in the signature verification phase uh the signature doesn't include chain ID means uh it won't verify your ch ID in from signature and another approach is zero devs merit it combines multip multiple user version hash values from different chains into a single mer root.

It means uh the user only uh need to sign a single mer root to perform their uh authorization for the multiple user operation in different chains. So your signature will your use operation hash will in the mo true m tree leaves and then uh the both me all share common trait they bypass the ch ID restriction during signature verification. The coin basis approach uh ignores chain ID field in the useration hash and zero devs approach includes all possible chain ids within the mer tree. And another solution is wallet provider support. If are using a web as wallet, you need a database to check the user's current authentication mech because the webin need to record the uh domain and device.

And if you have a boss vtor in ch A and ECDSA vitor in ch B, you may need this database to record your V edger. And another example is if you only have ECDSA editor bus, but you have different ownership uh aka my public key in different chains and you also need a database to record it. So the database can ensures a seamless and secure user experience. And wallets can also provide an alert or oneclick sync function to unify the authorization methods across all chains. And it can help your user it can notice user what they should do.

And next issues is address issues. So why uh address issues? It is because uh from an EO perspective uh users expect their account address to be a send. So if le uh uh if le doesn't have this in layer mindset uh they will unknowingly send funds to a recipient they don't have control and it will lead to asset risk and some bridges assume the same address between the two nodes. So if your user doesn't double check the recipient address you will al uh you will also cause the uh asset risk and when your user register the uh ENS name they should double check the registering address too.

Uh so the address difference is primarily caused by the protocol difference uh like whether a layer 2 follows layer one half in a tiny manner and whether a layer 2 supports all lay one pre-ompile contract and EIP and not only the layer two cost difference but uh the layer one may uh doesn't support some layer 2 exclus exclusive features like uh the casing uses different encoding method for country creation of codes and iserial maintenance doesn't support certain IP but uh why wasn't this any issues before it is because in the past like the merge uh it uh it only affect a little subset of your current smart contract but the newer up codes like push zero which is introduced by uh sanghai half fork will almost affect fates every every country in the east area and the uh ERC 437 also amplify the importance of consistent address and next I will introduce some past and future halfwork impact uh the first one is Shanghai hard fork which introduced uh push zero and certain trends and tools initially uh didn't support this up code so if you want to prevent producing the push zero. You should specify the event version and so compiler version to maintain the identical address uh even your so high level code is identical and Kenquin also introduced new up codes uh but it it's not affect as significant as uh push zero because in current currently the solid compiler doesn't allow transient storage as your data storage uh with the high level solic you should use the t store and t load up codes with inline assembly and in the future uh once ef goes live uh we will likely encounter encounter similar issues and so how to make sure the uh edges identical or how to sol uh how to solve the edges issue uh the simple Simplest way is fix both the event version and solidity version when you compile your core. Uh for push zero uh you can specify the 0.8.19 8.

19 as your EVM uh compiler version and specify the Paris as your EVM version and this can uh prevent the push zero producing and you may need some tool like EV div to help you know the difference between layer 2 and manet but uh the number of decision making criteria will only grow over time because we will only have more and more hardworks and more and more uh new up codes. So the long-term solution is uh do not assume less an account will be will have the same address across all chains. Uh this this should be a fundamental mind mindset shift and you may have uh you you may notice your user or you can help them to use the uh ENS and it can enhance a lots of user experience. And next issues is fee issues uh for the wallet provider like uh I'm token uh calculating purification gas in 437 is a hard issue because in in layer 2 uh the purification gas includes layer one cost and layer two cost and before I introduce how to get the rational PVG uh from the perspective of layer 2. Uh let's recap the uh PVG first.

So uh in 437 the bundler sends us use operation to entry point by calling the handle ops function on entry point contract and it is a regular transation and we call them we call it uh bundle transaction and it is a supererset of the verification phase and execution phase. So there are some guest cost uh doesn't in uh isn't included by the verification guest limit and code guest limit but this gu should be uh paid by the bundler and bundler charge user your your account contract with the PVG field. So you can see the uh 10day guest profile for the handle ops function. You can see the val prepayment is verification phase and execute use up means your execution phase and there are some guess cost doesn't uh include is isn't included by uh the verification phase and execution phase. So you need to specify the pg field to uh pay this cost to the uh bundler.

So the P pg means the guest cost cannot be checked via changes in gas left onchain and pg includes the following two parts. The first part is the cost of processing and user operation in the entry point contract like 21,000 Steven and memory usage and copy and the me memory usage cost means if you have more code data in your uh bundle transaction uh you need to pay more gas cost for the uh memory expansion and intrinsic gas and another part of PBG is additional expense. uh you may uh pay the subsidy for prioritizing the bundling of the user operation from the main pool which means uh you pay more to let the bundler uh pick your user version from the main port quickly and a fee for bunders to prioritize their bundle transition with the uh block builder and on layer two you must uh account for layer one security fee and this is what we talk about today. So how to get rational PVG on layer 2? Uh the total cost of for bundle transient is equal to layer one cost plus layer two cost.

Layer one cost means uh this bundle transaction security cost uh from the perspective of layer one and layer two cost means the processing cost of this bundle transition on layer two. And then we can do some math. Uh we express the total cost for bundle transaction equals to gas price multiple total gas used. And this gas price reverse to the gas price on layer two. And then we divide by gas price.

We can guess the formula total gas used uh equals to layer 1 cost divide by layer two gas price plus layer two costly divide by layer two gas price. So it means what we want uh what we need to pay uh from the perspective of layer two and then we can define the layer one cost as layer one coda uh layer one coda cost divide by layer two gas price and from a layer two perspective we can get the how much layer one security fee need to pay with the layer two gas price we can get the formula lay one gas price multiple laya size divide by layer two price. Okay, math lecture and the total PVG on layer 2 is composed of two parts. The PVG for layer one and PVG for layer two. So uh we have already uh get the PVG for layer 1 because PVG layer for layer 1 equals to layer 1 security fee equals to layer 1 ca price multiple laya size divide by layer 2 gas price.

And this formula calculation can help us uh get the rational PVG from a perspective of layer 2. And it is a a complex calculation. So in long term you can try the IP7560 to simplify the calculation. It defines the cross raw native air as standard and replace the PVG field with builder fee and the builder fee means the layer one data fee and the intrinsic portion of PVG is set as the constant airbased gas cost. So this IP can help you simplify the uh PVG calculation of uh uneven compatible layer tools.

But in shorten or you want to make your product more stable and you want uh the optimal earning, you may set up your own bungal or establish a business partnership with banglers because uh the PG calculation is complex. you may charge and uh unreasonable gas fees. So set up your bound uh set up your own bundler is a better choice. And the final topic is contra accessibility. Oh, the first one is info accessibility.

Uh we assume the event compatible layer 2 should support all of Ethereum pre-o compiles but some like score may not fully support due to circuit limitations and you you may if you are using a account you may want to use the uh secp 256R1 uh signature verification in your contra account. So you may try the Daimos implementation or IP7212 to uh verify your P256 signature. And if you are using the R1 signature verification, you should check your verifier contract is accessible in your target contract in your target uh chance. And next is the service uh accessibility. Uh choosing Mongol and Pamester is a hard question for 47 developers.

It's uh the one u there is a um very embarrass embarrassive uh problem is many many service uh depends on nodes such as your bangler paytor and relayers and before they actually send the transaction or return some results to you they will do the sim they will do the simulation and uh let's take the 7212 as an example here. Uh if the uh service you you are using doesn't use uh the latest node, it will cause problems in simulation phase. For example, uh the optimism supports the RP7212 in 2024 Q3 and alchemy bundler is expected to support the P 256 pre-ompile by 2025 Q2. So if you are using R1 as your signature verification mechanism and you send your user operation to the alchem bundler uh within this period your user operation will fail due to the simulation fail and it may not affect your control logic. it it won't let your uh uh account stolen but it will affect your product table because users uh have a valid uh signature but their user perition cannot be sent.

And next is tool accessibility. Uh we usually use some development frameworks and tools like fun create to factory uh fun create to factory contract multi call free contract slicer and we need to check uh if they support the new half fork or not and it is because there is always a period of transition before and after a half fork. So if you do the import important operations like deploying contracts, launching products or upgrading contracts in this period uh it is very risky and inconvenient. Okay. The conclusion uh today we cover some issues uh like account synchronization authorization mechanisms address consistency and PVG calculations on layer 2.

And here are some key takeaways for you. Uh if you want to manage the crosschain accounts, you can try the multi- chain signing to help your user sign only once to send it broadcast to multiple chains. And you may rely on w provider support to help you enhance the user experience and achieve the security and address at the tent is in available but manageable. You should not assume the edges same and you may try the you can try the ENS and PG calculation on layer 2 is more complex than expected and in longterm you can use the 7 uh 7560 to simplify your PVG calculation but uh to make your product more stable you should set up your own bangle or establish a a business partnership with len and in the future uh The 47 on layer 2 will depend on how infrastructure providers wer developers and rural teams collaborate to make it a true standard. Thanks.

[Applause] Thank you, Alfred. Do we have any questions from the audience? Um, okay. I have one. Um I'm curious about um is 4337 your interest or why do you study 4337 so hard?

Okay. uh because uh we are developing our web a new cutting edge wallet uh which use the 437 and today's uh we I I share the uh issues about we how we meet uh on layer two and if you want to uh know more about I'm tokens a wallet you can you can hey go to building a to listen Nick's talk in 213 30. Yeah. Our next talk. Okay.

Um yeah. Um then thank you Alfred um uh for giving such a good talk on ERC 4337. Um the next panel [Music]