...
Besu's implementation of EOF is nearly complete, awaiting the finalization of a few final details.
EOAs & Next Steps
pros, cons, next steps
\[EIP-5003 isn't on the EthMagicians list anymore]
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 (or is neutral on?) 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.
...
ePBS (
...
TBD)
...
Pricing Changes
SSZ
pros, cons, next steps
Do we want to move this to the CREEP section? Or are we ready to champion?
Grab bag (TO-DO)
- EIP-2935: Save historical block hashes in state 2
- EIP-3068: Precompile for BN256 HashToCurve Algorithms
- EIP-3074: AUTH and AUTHCALL opcodes 1
- EIP-5806: Delegate transaction
- EIP-5920: PAY opcode 1
- EIP-6404: SSZ Transactions Root 18
- EIP-6465: SSZ Withdrawals Root 9
- EIP-6466: SSZ Receipts Root 7
- EIP-6493: SSZ Transaction Signature Scheme
Aesthetics and consistency with the CL is not necessarily a reason to engage on a large bucket of work on the EL.
Grab bag (TO-DO)
- EIP-6913: SETCODE instruction3068: Precompile for BN256 HashToCurve Algorithms
- EIP-6914: Reuse validator indices 105806: Delegate transaction
- EIP-7212: Precompile for secp256r1 Curve Support5920: PAY opcode 1
- EIP-73776913: Migration TransactionSETCODE instruction
- EIP-7545: Verkle proof verification precompile 16914: Reuse validator indices 10
- EIP-7553: Separated Payer Transaction
- EIP-7557: Block-level Warming
- EIP-7594: PeerDAS - Peer Data Availability SamplingEIP-7609: Decrease TLOAD/TSTORE pricing for common cases 1
- EIP-7623: Increase calldata costEIP-7664: Access-Key opcode
No-Brainers
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 - BLS Precompile
EIP-7212 - Precompile for Secp256R1 - //Danno - The question is at a rollup address or at a mainnet Mainnet address, or both?
No Opinion
- EIP-7545: Verkle proof verification precompile 1
- EIP-7377: Migration Transaction
- EIP-7609: Decrease TLOAD/TSTORE pricing for common cases 1
- EIP-7623: Increase calldata cost
- Happy with costing changes, leaving to the economists
Anti-Goals (or, creep)
Verkle (Karim)
...