eth_simulate Implementers' Meeting [Feb 10, 2025]

[poojaranjan]

Meeting Info

• Date & Time: Feb 10 2025 , 12:00 UTC
• Duration: 60 minutes
• Recording: eth_multicall Playlist
• Zoom

📅 Subscribe to the Ethereum Protocol Call calendar for calendar invites

Resources

Ideas for eth_simulateV2
PEEPanEIP#135: Eth Simulate with Oleg and Killari
https://eips.ethereum.org/EIPS/eip-4399
https://docs.login.xyz/general-information/siwe-overview
https://ethresear.ch/t/fork-choice-enforced-inclusion-lists-focil-a-simple-committee-based-inclusion-list-proposal/19870

Agenda

• Notes from last meeting
• Client Implementation update
• Test
• Discuss spec for eth_simulateV2

Add more discussion items or async updates.

The next meeting is scheduled for February 17, 2025 at 12:00 UTC

[poojaranjan]

Recording: https://youtu.be/YgU7S01PUZc

[roninjin10]

How do I provide feedback?

I got a lot of thoughts about this because I built tevm which is a library that supports advanced simulation use cases

[bomanaps]

@roninjin10 There is a Telegram channel. If you could please drop your username, I will add you. I have also requested the channel link, so if I get it before you see this, I will drop it here. But, if I get your username first, I will try adding you.

[bomanaps]

Hey @nixorokish https://t.me/+Th3vqWSnIllhZTlh

[bomanaps]

Eth_Simulate Implementers Call Summary

Feb 10th, 2025

Main Outcome

The primary outcome of the meeting was the agreement to add support for type 4 transactions (EIP-7702) across various blockchain client methods. The team discussed and outlined a rough design for implementing this support, focusing on addressing the challenges related to transaction signature validation and authentication.

Key Decisions and Design Proposals

Type 4 Transaction Support

• The team agreed to add support for type 4 transactions (EIP-7702) in methods like eth_call, eth_simulate, and eth_estimateGas.
• A transaction can have either an authority field, signature fields (r, s, yParity), or both.
• If it contains an authority field, its value must be an address.
• If it contains both an authority field and signature fields, the address recovered from the signature must match the address in the authority field.

Flexible Authentication Mechanism

• A new Authority field will be added to the transaction object to support flexible authentication methods.
• The Authority field can contain:
  • An address (for lightweight authentication).
  • A signature (for cryptographic verification).
  • A mixed list of addresses and signatures (for maximum flexibility).

Validation Rules

• If both Authority and signature are provided, they must match; otherwise, an error will be thrown.
• This ensures users can validate their transactions and catch potential issues early.

Cross-Client Consistency

• The team emphasized the need for a consistent API across all blockchain clients to handle type 4 transactions uniformly.
• All clients will need to implement the proposed Authority field and validation logic.

Testing and Simulation

• Testing type 4 transactions will require simulating transactions with the new Authority field.
• The team discussed using EXTCODE operations (e.g., EXTCODEHASH) to verify authority settings, as direct pulling of authority values from the chain is not possible.

Next Steps

Finalize Design

• Confirm the design with all stakeholders, including Besu and other client implementers.
• Ensure the proposed Authority field and validation rules are acceptable across all clients.

Implementation

• Develop a PR against the execution-apis repo at the Authority field and type 4 transaction support.
• Address any client-specific implementation challenges, particularly in Geth and other clients.

Testing

• Conduct thorough testing to validate the new functionality, especially for eth_simulate and eth_call.
• Use EXTCODE operations to verify authority settings and ensure correctness.

Coordination

• Collaborate with all clients to ensure consistent implementation and approval of the changes.

Conclusion

The meeting concluded with a clear direction to add type 4 transaction support and a rough design for implementing it. The proposed Authority field will provide a flexible and robust way to handle authentication for these transactions. The next steps involve finalizing the design, implementing the changes, and coordinating with all clients to ensure a consistent and reliable solution.

[poojaranjan]

Closing in favor of #1293