Bundling

Bundling Explained

Bundling is the process of collecting and organizing individual UserOperations into a coherent batch to be included in a block. Given the process described, here's a detailed explanation of the bundling procedure:

1. Filtering UserOperations:

   • Exclude any UserOperations that might interfere with others in the same batch. This is to ensure that transactions do not conflict with each other or cause unintended consequences.

     • Exclude those that access a sender address used by another UserOp in the same batch.

     • Exclude those that tap into an address created by another UserOp's validation in the same batch.

2. Paymaster Balance Tracking:

   • For each paymaster (entities that subsidize transaction fees for users), monitor its balance while adding UserOperations. This ensures that the paymaster has enough deposits to cover the associated transaction fees for all UserOperations it supports.

3. Sort and Aggregate:

   • Organize UserOperations based on their respective aggregators.

   • For each aggregator, execute their specific code to aggregate signatures and then update the respective UserOperations.

4. Pre-block Inclusion Checks:

   • Before finalizing the bundle for inclusion into a block:

     • Use debug_traceCall with maximum gas allocation. This step is crucial to validate the entire batch of UserOperations and ensure no rules or constraints are violated.

     • If the call fails (i.e., reverts), inspect the FailedOp event. This event helps in diagnosing what went wrong, especially since such failures should've been caught earlier during the individual UserOperation simulations.

     • Should any rule be violated, the client must treat the offending UserOperation as if it failed and should subsequently:

       • Remove it from both the current bundle and the mempool.

       • Depending on the nature of the error, and which entity caused it (factory or paymaster), appropriate punitive actions are taken:

         • If the error's origin is a non-staked entity, the corresponding factory or paymaster gets banned (see the section on "Reputation, throttling and banning").

         • If a staked entity is at fault, instead of banning the associated factory/paymaster, the staked entity itself gets banned.

     • The process is repeated until the debug_traceCall is successful.

This bundling process ensures the integrity of the transactions that get included in a block. It's designed to catch and handle errors, avoid potential conflicts, and ensure that all transactions are valid and conform to the set rules and protocols. The introduction of checks, balances, and corrective measures safeguards the system against malicious or erroneous transactions. Safeguards in Bundling Process

This section outlines the crucial safety measures during the bundling process. Let's break it down:

1. Transient Storage & Banning Rules:

   • Staked entries (those who have locked up some collateral or stake) have the privilege to use a form of temporary storage to convey data between various UserOperations within the same bundle. This is significant because it provides a way for different UserOperations to communicate or share data.

   • However, this also comes with the risk of potential misuse. To mitigate this risk, the exact rules that are imposed on individual UserOperations (like opcode and precompile banning and storage access) must also be applied when validating the entire bundle (handleOps).

   • If these rules weren't strictly enforced, malicious actors could exploit banned opcodes to detect when they're operating on-chain and deliberately cause a FailedOp revert, disrupting the bundling process.

2. Banning Mechanism:

   • When an entity violates the protocol or exhibits malicious behavior, it needs to be banned to protect the system. Banning is achieved by increasing the opsSeen value of the entity by 1,000,000. This massive increment acts as a punitive measure, ensuring that the entity is penalized.

   • In addition to this, all UserOperations linked to the offending entity that are currently in the mempool are removed. This is to clean the pool of any associated risks. Over time, the negative reputation this action brings will gradually decrease, which is consistent with other banning reasons.

3. Validation & Acceptance of UserOperations:

   • If the validation conditions are violated during the simulation calls, the client should outright reject the UserOperation.

   • If the simulation calls go through without any violations (or if there's no paymaster specified and the first call is successful), then the client can accept the UserOperation. It's essential for bundler nodes to record the storage keys accessed during these simulations. This recorded list becomes the accessList of the UserOperation, providing transparency about which storage keys a given UserOperation accesses.

4. Preventing Conflicts during Block Inclusion:

   • Bundlers have a responsibility to ensure that when a bundle is added to a block, preceding transactions in the same block do not cause any UserOperation within the bundle to fail.

   • To manage this, bundlers can use access lists to track and avoid conflicts. If managing these potential conflicts becomes too cumbersome, the bundler can opt to simply place the bundle as the very first transaction in the block, ensuring no preceding transactions can interfere with it.

In summary, these measures emphasize the importance of enforcing strict rules, both for individual UserOperations and for the entire bundle. They aim to maintain the integrity of the bundling process, protect against potential threats, and ensure smooth operations when including bundles in blocks.