Versions Compared

Old Version 13

changes.mady.by.user Danno Ferrin

Saved on

compared with

New Version Current

changes.mady.by.user Danno Ferrin

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

To streamline Prague planning from the Besu client team, our maintainers propose the following scope...

...

Prague Meta-Thread

In-Favor

EOF

Besu encourages advocates for adding EOF to the Prague hard fork. 

...

Besu's implementation of EOF is nearly complete, awaiting the finalization of a few final details.

EOAs, AA, & Next Steps

pros, cons, next steps

...

The following two EIPs as currently written are unsuitable for fork scheduling.

* EIP-5003 - AUTHUSURP

This EIP provides the same category of functionality seen in EIP-7377, except in the form of an opcode driven by external data.  From a UX perspective this introduces unique risks not present in 7377. A transaction may or may not result in an account migration depending on smart contract logic.  The process of upgrading in 7377 is unambiguous and direct: the account will be migrated if the transaction reaches consensus.  Furthermore wallets can appropriately detect such actions and warn users as needed, whereas a smart contract activated migration can be constructed to make such warnings unreliable. Shipping EIP-7377 would be better, as would waiting for better EOA evolution alternatives. 

* EIP-3074 - AUTH and AUTHCALL

Besu supports adoption of EIP-3074

This EIP was considered and rejected for the London hard fork, almost three years ago, citing security issues. There was a call for a security audit at the time, which has not been done. The EIP would benefit from such an assessment. A major recent update to the nonce handling rules allows for a user to revoke authorizations with a single action. This recent specification change has removed the major safety concerns team members have had.

Inclusion Lists (Justin) 

pros, cons, next steps

Do we want to move this to the CREEP section? Or are we ready to champion? 

...

The Besu team views the need for 3074 as an opportunity cost. If we do not ship something in Prague, we run the risk of not supporting AA for the next 2-3 years. While this necessarily creates complexity in censorship resistance workstreams, the learnings from implementing AA sooner will allow us to have a better, more informed design where AA transaction validation logic is baked-in. This is a feature, not a bug. Keeping UX on Ethereum stunted for 2-3 years in order to solve some niche MEV challenges via ePBS seems like a poor trade-off. 


Supported Grab-Bag EIPs 

  • EIP-2935: Save historical block hashes in state 2
    • Implemented, not complex, brings value after Verkle. Shipping this in Prague will allow us to simplify Osaka for Verkle. 
  • EIP-2537 - 3068: Precompile for BN256 HashToCurve AlgorithmsBLS Precompile
  • EIP-3074: AUTH and AUTHCALL opcodes 1-7212 - Precompile for Secp256R1 
    • Besu team to run Benchmarks and help with understanding libraries, gas costing, and existing tooling
  • EIP-5806: Delegate transaction7623: Increase calldata cost
    • Happy with costing changes, smaller blocks, lower latency/state, chain ops 
    • Small implementation in the EL

Neutral/No Opinion


Opposed

SSZ

  • EIP-7664: Access-Key opcode

No-Brainers

EIP-2537 - BLS Precompile

EIP-7212 - Precompile for Secp256R1 - //Danno - The question is at a rollup address or at a mainnet address, or both?

Anti-Goals (or, creep)

Verkle (Karim)

...

Aesthetics and consistency with the CL is not necessarily a reason to engage on a large bucket of work on the EL. 

Opposed Grab Bag EIPs 

  • EIP-6913: SETCODE instruction
    • Code immutability is questionable. 
  • EIP-5806 Delegate Transaction
  • Weakly Opposed - EIP-5920: PAY opcode 1
    • Might break some assumptions of existing smart contracts 
    • Ether can get stuck in a smart contract that cannot send it 
    • Users may create issues with stuck Ether and