Account Abstraction is easy, except for Censorship resistance - Censorship.wtf

The smart account access problem (0:20)

Externally owned accounts (EOAs) can operate on-chain directly without intermediaries, while smart contract wallets require the help of an EOA to operate on-chain. This creates poor user experience as users need to manage two accounts and sign transactions twice.

The common approach until ERC-4337 was to use centralized relays that send meta transactions on behalf of users. This has downsides like :

• Poor UX needing two accounts
• Centralized points of failure
• Front-running
• Censorship
• Privacy issues.

ERC-4337 solves these issues by enabling smart contract wallets to pay their own gas fees on-chain directly without intermediaries.

The naive solution (3:50)

A naive solution is to have many relays operated by the same entity, but this is not decentralized as they can still collude to censor users

Gas Station Network (GSN) provides a decentralized network of relays, but has an issue : relays can lose money if smart contract wallets behave inconsistently and don't reimburse gas.

There were attempts to mitigate this risk like whitelists or reputation systems, but those systems reintroduce censorship risk and hurt censorship resistance.

Attackers can exploit non-determinism to force relays to simulate transactions that will never pay out, wasting CPU cycles. Flashbots relay protection can help but attackers can still overwhelm it.

To sum it up, the key problems are :

1. Lack of true decentralization
2. Smart contract non-determinism
3. Censorship risks of attempted solutions
4. CPU draining attacks

Therefore, a censorship resistant approach is needed that handles non-deterministic smart contract wallets and prevents malicious draining of relay funds.

The ERC-4337 way (7:20)

ERC-4337 aims to enable full smart contract account abstraction without compromising censorship resistance. It has no centralized components or permissioning.

Validation involves executing EVM bytecode, which opens up attack vectors to address.

1. The protocol needs to be permissionless for bundlers, anyone should be able to provide bundling services.
2. It needs to be permissionless for users, no one should be able to censor transactions.
3. Bundlers must be compensated for valid work
4. Bundlers must not do griefing attacks draining their funds.
5. The network as a whole needs protection against denial of service (DOS) attacks

The to-do list (9:00)

Transactions are split into validation and execution phases with separate gas limits, this reduces simulation cost.

Validation must be deterministic, environment access like block number is disallowed to prevent on-chain reverts.

Mass invalidation attacks are mitigated by storage rules, accounts can only access their own storage in validation. To invalidate many transactions, an attacker would need to make on-chain state changes which is expensive.

This enables reduced simulation cost, determinism, and prevention of denial of service attacks.

Transactions in a bundle must remain valid together, otherwise attackers could invalidate other txs.

Validations are done before executions, so executions cannot invalidate validations after gas is paid, so this prevents cross-invalidation

Global entities like paymasters can still invalidate bundles by detecting multiple calls. So misbehaving paymasters have to get throttled, and must stake more funds to keep attacking.

Various attack vectors had to be addressed with minimal validation restrictions to retain permissionless nature.

Overall, the goal was to find the right balance between open participation, attack deterrence, and economic incentives.

Why must all bundlers implement restrictions ? (15:15)

All bundlers need to enforce the same validation rules to prevent denial of service attacks. Attackers could spam nodes with invalid transactions using up maximum validation gas. Nodes can detect this by checking the validation block hash

If bundlers have different validation rules, a transaction could be valid for some but invalid for others. This would allow attackers to spam some bundlers by sending transactions tailored to their specific rules.

With standard uniform rules, invalid transactions mark nodes as spammers to block them network-wide.

Having a single standardized set of validation rules prevents fragmentation into small isolated mempools.

Why mempool fragmentation is bad ? (17:00)

• Small fragmented mempools are more susceptible to censorship attacks and centralization.
• Fragmentation also loses the robustness of having multiple client implementations, as bugs could take down an entire isolated mempool.
• Economically, small mempools can't construct optimal bundles reducing incentives to participate.

The solution is to have multiple bundler implementations but with a single compatible set of validation rules. Ethereum faced similar issues and solved it through :

1. Clear specifications
2. Reference implementation
3. Compatibility testing
4. Fuzz testing for consensus bugs

Conclusion (18:55)

Designing a truly censorship resistant account abstraction protocol is very challenging as it requires considering many edge cases and attacks.

That's why it took significant time and efforts to develop ERC-4337 while retaining decentralization.

Wallet/smart contract developers often don't care about censorship resistance, only user features.

They can get censorship resistance "for free" by using an ERC-4337 compatible SDK. However, this relies on bundlers implementing compatible validation rules.

Bundlers should use an implementation that passes ERC-4337 compatibility tests. Once the p2p network launches, compatible bundlers will get full censorship resistance benefits.