BLSWallet: Fully Embrace 4337 (In Detail)

Previous Doc

Outlined options for our 4337 strategy. The current doc expands on the first option - to fully embrace 4337.

Vanilla Ethereum Transactions

(To assist with upcoming comparisons)

4337 Ideal Flow

(Note that we are only considering 4337's aggregate ops in this doc.)

Under 4337, users own a contract wallet instead of an EOA account. 4337 defines a very special contract called EntryPoint which coordinates signature verification and gas payments, and passes on the actual on-chain actions to the contract wallets.

Users have control over how their actions are authenticated by freely specifying how they respond to getAggregator(). EntryPoint asks this contract whether the UserOp is valid before passing it to the user's contract wallet.

Non-blocking: Check with 4337 authors about the point below:

• Note that the Tx Mempool doesn't appear in this diagram. The idea here is that the client gathers a bundle of UserOps from the UserOp Mempool for direct inclusion into the block. Other transactions may be included from the Tx Mempool into that block but the UserOps aren't interacting with it.

Non-blocking: Why is unused gas refunded as credit (increasing the deposit/stake) instead of sending it back to the contract wallet? Does it cost more gas to send it back? Is it worth it?

There are two downsides of this ideal flow:

1. It depends on integration into Ethereum clients
2. It doesn't include use of an Expander contract for reducing the amount of calldata that needs to be sent to L1

4337 Flow without Ethereum Client Integration

This flow introduces a Bundler - a specialized network participant which draws from the UserOp Mempool to produce bundles which can be submitted to the Tx Mempool for inclusion on-chain.

Going via the mempool allows bundlers to compete to produce the most efficient bundles. This creates the incentive to use an Expander contract for reducing calldata.

(Using an Expander in the 4337 ideal flow seems like it might be possible, but it's less clear and perhaps out of scope for those focused on implementing account abstraction.)

In the short term, we can demonstrate this approach by having the wallet redirect eth_sendUserOperation calls to our bundler and just have a local UserOp Mempool. It's also possible to proxy a regular client but redirect just these calls. This is the same type of role as the current BLSWallet aggregator.

Using tx.origin Payments

As a special case, dApps that are extracting value in other ways have the opportunity to offer gas-free transactions to their users (by paying for it themselves).

dApps do this by integrating tx.origin payments into their contracts (or use a wrapper contract).

For example:

function valuableInteraction() external {
    tx.origin.call{
        value: block.basefee * VALUABLE_INTERACTION_GAS
    }("");

    // ...
}

(Presumably, things like valuableInteraction cannot be openly accessible, otherwise mev bots would arbitrage this until all funds are drained from the contract. It's expected to be arbitrage since VALUABLE_INTERACTION_GAS will need some headroom to account for the uncertainty in the gas used by the contract wallet.)

VALUABLE_INTERACTION_GAS should include the gas associated with the calldata. This has a few sources of complication:

• Compression of the original calldata that passed through an expander contract to generate the handleAggregatedOps call
• Compression utilized by the L2 before posting the calldata to L1
• Generation of inputs for other reasons
• Variation between L1 and L2 gas prices

When relying on tx.origin payments, we can avoid paying for the calldata for gas-related fields in the UserOperation by using a specialized expander contract. Expansion is expected to have more layers that enable additional compression, but here's an example that just achieves the basic savings for this use-case:

//SPDX-License-Identifier: Unlicense
pragma solidity >=0.8.4 <0.9.0;

import "@account-abstraction/contracts/interfaces/IAggregator.sol";
import "@account-abstraction/contracts/interfaces/IEntryPoint.sol";
import "@account-abstraction/contracts/interfaces/UserOperation.sol";
// (See https://github.com/eth-infinitism/account-abstraction/tree/develop/contracts/interfaces)

contract Expander {
    uint constant ARBITRARY_GAS_LIMIT = 1000000000;

    // (Needs real deployed address)
    IEntryPoint constant ENTRY_POINT = IEntryPoint(
        0x0001020304050607080910111213141516171819
    );

    // (Needs real deployed address)
    IAggregator constant AGGREGATE_SIG_VALIDATOR = IAggregator(
        0x0001020304050607080910111213141516171819
    );

    struct SmallUserOperation {
        address sender;
        uint256 nonce;
        bytes callData;
    }

    function handleAggregatedOps(
        SmallUserOperation[] calldata smallUserOps,
        bytes calldata signature
    ) public {
        IEntryPoint.UserOpsPerAggregator[] memory opsPerAggregator =
            new IEntryPoint.UserOpsPerAggregator[](1);

        uint len = smallUserOps.length;

        UserOperation[] memory userOps = new UserOperation[](len);

        for (uint i = 0; i < len; i++) {
            userOps[i].sender = smallUserOps[i].sender;
            userOps[i].nonce = smallUserOps[i].nonce;
            // Leaving .initCode as empty
            userOps[i].callData = smallUserOps[i].callData;
            userOps[i].callGasLimit = ARBITRARY_GAS_LIMIT;
            userOps[i].verificationGasLimit = ARBITRARY_GAS_LIMIT;
            // Leaving .preVerificationGas as zero
            // Leaving .maxFeePerGas as zero
            // Leaving .maxPriorityFeePerGas as zero
            // Leaving .paymasterAndData as empty
            // Leaving .signature as empty
        }

        opsPerAggregator[0] = IEntryPoint.UserOpsPerAggregator(
            userOps,
            AGGREGATE_SIG_VALIDATOR,
            signature
        );

        ENTRY_POINT.handleAggregatedOps(
            opsPerAggregator,
            payable(msg.sender)
        );
    }
}

The following fields are excluded because they're about paying gas:

• op.preVerificationGas
• op.maxFeePerGas
• op.maxPriorityFeePerGas
• op.paymasterAndData
• beneficiary

Some other fields are also excluded above for other reasons not specific to this section:

• op.initCode
  • Used for creating the contract wallet if it doesn't exist, so this will sometimes be needed, and will need to rely on expansion variations. Excluding it isn't specific to the tx.origin payment system of this section.
• op.signature
  • 4337 also allows non-aggregated user operations. This is why there is a .signature field in UserOperation, but it's not needed for this use case, which a single aggregate signature is attached to the bundle. Our wallet enforces aggregation during validateUserOp(), so it's safe to accept an empty signature field.

Prototype

To see the detail of how a UserOperation can be constructed, signed, and executed for BLSWallet, take a look at these tests.

This repo contains a variation of the BLSWallet contracts.

The prototype has a couple of known gaps/issues:

• Contract wallets are being created explicitly and independently of 4337, instead of using initCode (see Instantiating Contract Wallets)
• The requestId used for signing is unnecessarily complicated (based on this but should be based on this)

Paying for Calldata

It's important to keep in mind the distinction between execution gas and calldata gas.

Execution gas is measured by the 4337 EntryPoint by comparing calls to gasleft(), but these calls also have a cost associated with their calldata.

Calldata cost is not measured by EntryPoint because it is static. Instead, it is the responsibility of the Bundler/client to ensure they are going to be compensated using offchain calculations.

Compensation for calldata is contained in preVerificationGas. It's a fixed amount of gas unconditionally added to the measured execution gas, and is also used to account for the gas spent inside EntryPoint for its coordination.

To account for compression, when available, users should be able to sign for less calldata than the raw number of bytes in their operation. Note that compression is performed across many operations, so there isn't simply a 'compressed size' that can be used here.

More information:

• Calldata is currently 16 gas/byte (4 gas/zero-byte)
  • eip-4488: change to 3 gas/byte (for all bytes)
  • in future sharding is hoped to reduce this dramatically (100x?)
• L1 vs L2 gas

Instantiating Contract Wallets

When using a wallet for the first time, the initCode field of the UserOperation is used to specify creation of the contract wallet (e.g. BLSWallet.sol). This is used concurrently with the first actual operation of the wallet (in the same UserOperation).

4337 doesn't create the contract wallet directly. Instead, the first 20 bytes of initCode is the address of a factory of our choice, and the remaining bytes are an encoded call to that address which must return the new contract wallet. Here's the code for it.

This means we can continue creating wallets as we currently do (TransparentUpgradableProxy and initialize function). We just need to make getOrCreateWallet externally callable (not private).