BLSWallet & 4337

1. Fully embrace 4337

  • Drop support for directly calling VerificationGateway for ordinary transactions and pivot to only using the 4337 EntryPoint contract
  • Use the 4337 fee/gas mechanism
  • Stop developing the model where the wallet adds an explicit tx.origin payment
  • Continue to explore/promote an ecosystem where dApps can pay tx.origin, allowing us to set the 4337 fee fields to zero when this is available (relying on mev/etc to identify these opportunities)

This seems by far the best option. We can still promote an ecosystem where dApps pay tx.origin and enable us to set the 4337 fee fields to zero. This will always be a (perhaps rather small) subset of dApps, so we need to primarily support a payment mechanism that is universal, so dApps paying tx.origin is secondary.

I also believe we should not pursue a model where the user simply includes an extra tx.origin payment. It diverges from the 4337 ecosystem without benefit. At the very least, these tx.origin payments should be tied to BASEFEE for stability, but… that's just 4337. Let's just do that.

I think we might be overestimating the inertia of the current system. Most of the work we have done is really about bringing all these pieces together and assembling a team that deeply understands the idea. Pivoting to 4337 from this point is totally achievable, and trying to support a hybrid seems to be mostly a headache with little benefit.

2. Support 4337 in parallel

Like (1), but:

  • Retain direct calls to VerificationGateway
  • Always set 4337 fee fields to zero (or have different kinds of payment for each system?)
  • Rely on wallets adding explicit tx.origin payments for all dApps that haven't integrated these kinds of payments

This option might cause less disruption to our current plans. It avoids new development to support the 4337 fee mechanism but depends on a separate tx.origin payment ecosystem emerging and relies on incomplete work to support wallets adding tx.origin payments.

It's also possible we could use the 4337 fee fields when using 4337, and separately use tx.origin payments when not using 4337.

Unless there is already a lot of momentum with third parties wishing to integrate the current system, I see it as an unnecessary fragmentation and source of confusion for BLSWallet.

2a. Support 4337 in parallel using extra contracts to avoid existing contract changes

In (2), the idea is to add the necessary 4337 mechanisms to VerificationGateway and BLSWallet. There is a prototype for this.

There's been some discussion about using additional contracts to avoid any changes to the existing contracts, which may reduce our auditing costs.

However, this is currently incompatible with signature aggregation. The 4337 EntryPoint contract makes separate calls for signature verification and contract wallet calls. The only way to make our contract wallet do anything is to go via VerificationGateway#processBundle, which requires a valid signature. Because the 4337 EntryPoint makes a separate call for each operation, each operation would then need to have an individual signature for VerificationGateway#processBundle to accept it.

Conceivably the 4337 EntryPoint could be changed, but 4337 wants to measure the gas used by each operation to enable fee payment tied to those measurements according to the actual on-chain execution. It's not possible to do this without carving out another new 4337 flow specifically for our model which sets 4337 fees to zero (relying on paying tx.origin in other ways).

Instead, we should simply change BLSWallet.sol to trust calls from the 4337 EntryPoint or another proxy contract. This still allows us to avoid changing VerificationGateway, and instead have BLSWallet.sol or its proxy contract point to another place for aggregate signature verification.

"Proxy contract"s above would allow us to avoid adding validateUserOp() and getAggregator() to BLSWallet.sol. However, since these are simple, and we're modifying this contract anyway, I believe it makes a lot more sense to simply add these to BLSWallet.sol in addition to trusting another caller. Proxy contracts would also mean the sender field in the 4337 UserOperation would need to be these proxy contracts instead of the actual contract wallets (BLSWallet.sol), resulting in additional confusion for wallet implementers, users, block explorers, etc.

To summarize:

  • Can avoid changing VerificationGateway
  • Can't realistically avoid changing BLSWallet.sol
  • May reduce auditing overhead because VerificationGateway is unchanged, but introduces a new contract to audit (the 'Aggregator' indicated by getAggregator(), which verifies aggregate signatures for 4337 calls)

Contract wallet creation / 1st tx

For (2) and (2a) there's ambiguity about how the contract wallet (BLSWallet.sol) is created.

4337 supports contract wallet creation using the initCode field, which could be used, but creates confusion for the blskey <=> address relationship (now different depending on whether you use the 4337 EntryPoint or VerificationGateway). It also requires an extra contract interaction to configure the VerificationGateway, and might mean additional changes to VerificationGateway (relevant for (2a)).

Alternatively, we can rely on VerificationGateway for contract wallet creation, but it means users targeting 4337 will need to explicitly create their wallet.

3. Abandon all 4337 interop plans

Maybe it's possible that it's too important to keep things the way they are and 4337 isn't getting any traction anytime soon anyway. If these things are true it's conceivable we could just forget about 4337 and continue without it.

A related and more realistic point is that we could finalize V1 without any relationship to 4337 and focus on V2 as a 4337 wallet.

Select a repo