Bundler Tx Gas settlement process optimization

--- tags: ZK,Bundler-Design --- # Bundler Tx Gas settlement process optimization ## background In the 4337 scenario, after each Tx is executed by the EntryPoint contract agent, the Gas fee used by the Tx must be paid in a timely manner. After analysis, the Gas consumption caused by this operation is relatively large, which is equivalent to an ERC20 The Gas used for transfer needs to be optimized. If this step is removed, 9k+ Gas can be saved ## Optimization ideas - Adopt an optimistic approach to perform batch delay execution on the transfer of Gas fee - In the L1 environment, all the steps of settlement Gas are transferred to the cheaper L2 for execution - Users are required to deposit funds on L1 first to pay for Gas fees - Synchronize the information to the L2 contract, How to avoid the situation that the user's fee asset may be empty due to the delayed settlement of the fee? - The user is required to withhold a part of the pledge fee in advance as a deposit. When the settlement reaches the deposit level, the user's account will be locked. The next time the user will not be able to initiate Tx normally, but the user can normally withdraw the remaining service fee ## There are two options ### plan 1 ![](https://hackmd.io/_uploads/S1zazn72o.png) All Tx fee settlements are executed on the original chain - Advantages: relatively simple to implement - Disadvantage: But it will lead to unstable saving of Gas$[6\%,20\%)$ - Need to rely on a good merge strategy to improve Gas savings ### plan2 Put all the Tx fee settlement of L1 on L2 - Advantages: relatively stable gas saving, close to 20% - Disadvantages: the implementation is more complicated, and the network coupling between L1 and L2 is increased ![](https://hackmd.io/_uploads/r1YCz2mhj.png) ### 2. Optimize the gas fee transfer logic In the scenario of gas fee transfer, fromAddress is the wallet account, and toAddress is always the EP address, which leads to the waste of the abstract ability of ERC20 transfer or ordinary transfer in this scenario ### 3、 Merge fee settlement steps Cache batch and user and fee data locally to the node, which can be represented by the following data structure $$ TypeSet\{batch: keccak256, user_X:address,fee_{n-X}:uint256\} \\ batch_{1}:[\{user_A,fee_{1-A}\},\{user_B,fee_{1-B}\},...{user_F,fee_{1-F}}] \\ batch_{2}:[\{user_B,fee_{2-B}\},\{user_C,fee_{2-C}\},...{user_G,fee_{2-G}}] \\ ...... \\ batch_{n}:[\{user_H,fee_{n-B}\},\{user_K,fee_{n-K}\},...{user_Y,fee_{n-Y}}] \\ $$ We need to design a strategy to combine the handling fees in multiple batches to achieve the effect of reducing data operations. The Gas consumed for one user update is $Gas_{update}$,and there are 128 in each batch.，ssuming that batches are merged , there is a certain user complex rate,like $user_A$ appears in $batch_1$, $batch_3$, $batch_7$, $user_B$ appears in $batch_2$,$batch_5$, $batch_9$，**if the repetition rate of user is higher, the gas cost savings brought by the merge operation will be more ** We get that the range of gas fees that can be saved is $[10\%,30\%)$ Then the proposition of this strategy is transformed into finding a batch of batches in all the batch lists cached by the node, which includes that when the user repetition rate reaches $R$ the combined settlement will be performed #### possible problems - Pay attention to whether it will cause some batches to be unable to settle the transaction fee for a long time - Increased operation and maintenance costs of nodes - The parameters of the merger strategy may need to be dynamically adjusted with the market - Nodes need additional resources to do scanning and computing tasks ### The settlement step is placed on Layer2 If the above operations are performed on Layer 2, a lot of Gas will be saved, but a new proposition will be introduced. The user deposits the Gas fee on L1 to the EP contract of L1, and the settlement process runs on L2. How to make the contract on L2 believe that the user has deposited the corresponding handling fee on L1? It can be more abstract, the user deposits money on ChainA, how to make the contract on ChainB believe that the user has deposited money on ChainA #### Try the Merkle Reserve proof way - The user stores Gas fees on the source chain and updates and maintains the Merkle tree, and updates the root value to the destination settlement contract (updated by cross-chain communication? Speed? Gas, etc., can ZK verification be used? transfer) - The EP contract needs to merge multiple batchIds into a Merkle tree root and pass it to the destination segment contract through cross-chain communication (triggered by the node for execution) ## Preliminary program verification ### Single batch merge verification The Gas used by the user's Deposit Withdraw is not included in the calculation We only look at the Gas fee amortized to each Tx for one RefundGas Fee operation? Test Results: - Execute addTxBatchHash 24091 - Execute refundGasTx 933802 The Gas 10586.23438 originally required for RefundGas is evenly distributed to save Gas 7483 (34330 - (23755 + 7483))/34330 = 10% ### Merge multiple batches (to be verified)