# BLSWallet: Fully Embrace 4337 (In Detail)

## [Previous Doc](https://hackmd.io/ljSvjpi7Q7eRt9mrEg5xmQ)

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 `UserOp`s from the `UserOp Mempool` for direct inclusion into the block. Other transactions may be included from the `Tx Mempool` into that block but the `UserOp`s 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](https://github.com/web3well/bls-wallet/tree/main/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](https://github.com/voltrevo/account-abstraction/blob/21b72dd/test/blsWallet.test.ts)

To see the detail of how a `UserOperation` can be constructed, signed, and executed for `BLSWallet`, take a look at [these tests](https://github.com/voltrevo/account-abstraction/blob/21b72dd/test/blsWallet.test.ts).

This repo contains a [variation of the `BLSWallet` contracts](https://github.com/voltrevo/account-abstraction/tree/21b72dd/contracts/samples/BLSWallet).

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**](https://hackmd.io/6_rTYV--SimB3lTlLVFOmg?both#Instantiating-Contract-Wallets))
- The `requestId` used for signing is unnecessarily complicated (based on [this](https://github.com/eth-infinitism/account-abstraction/blob/699ecca/contracts/bls/BLSSignatureAggregator.sol#L84) but should be based on [this](https://github.com/eth-infinitism/account-abstraction/blob/699ecca/contracts/core/EntryPoint.sol#L204))

## 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)](https://eips.ethereum.org/EIPS/eip-2028)
- [eip-4488: change to 3 gas/byte (for all bytes)](https://eips.ethereum.org/EIPS/eip-4488)
- in future sharding is hoped to reduce this dramatically (100x?)
- [L1 vs L2 gas](https://medium.com/offchainlabs/understanding-arbitrum-2-dimensional-fees-fd1d582596c9)

## 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](https://github.com/eth-infinitism/account-abstraction/blob/699ecca/contracts/interfaces/UserOperation.sol#L23-L24)).

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](https://github.com/eth-infinitism/account-abstraction/blob/699ecca/contracts/core/SenderCreator.sol).

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).