Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

EOF Implementers Call #61 #1184

Closed
poojaranjan opened this issue Oct 16, 2024 · 5 comments
Closed

EOF Implementers Call #61 #1184

poojaranjan opened this issue Oct 16, 2024 · 5 comments

Comments

@poojaranjan
Copy link
Contributor

poojaranjan commented Oct 16, 2024

Meeting Info

Oct 30, 2024 , 15:00 UTC

Duration: 60 minutes

Zoom: https://us02web.zoom.us/j/88940506383?pwd=aTdsbHVyMTNDSUFHYmhTWlI2ZEVldz09

📅 Subscribe to the Ethereum Protocol Call calendar for calendar invites

Resources

Agenda

Please add other agenda items or links to discuss.

Next call on Nov 13, 2024 ??

@shemnon
Copy link
Contributor

shemnon commented Oct 30, 2024

@frangio
Copy link

frangio commented Oct 30, 2024

Perhaps we should at least briefly touch on EXTDATACOPY.

@shemnon
Copy link
Contributor

shemnon commented Oct 30, 2024

  • Testing

  • Clients

    • Nethermind -
      • merged osaka fixes,
      • based off of prague / main
    • reth
      • has osaka wired in,
      • Fixed one bug with precompiles and EXTDELEGAGECALL
    • evmone transition to osaka is larger than expected
      • Migrated all ethereum/tests state tests over to EEST
      • EOF validation tests are not moved over yet
      • Some evmone tests are not ported yet - EVMONE v13 tests
    • Besu
      • osaka ready in main
      • prague-3/4 - based on where main besu gets to
  • Spec Changes

    • EXT*CALL
      • discuss after devcon
    • EOFCREATE hashing
      • multiple initcode contexts are creaed
      • Using container address only works for first level, not nested creates
      • create transaction - sender has no code so container address won't work
      • Not always possible to point to a "physical address" of the container holding the initcode
      • Maybe omit address, and still hash subcontainer when it cannot be proved, but computation time is different in two scenarios
      • Goal is to reduce extra hashing
      • Useful property is to prove code came from a specific code (not just address)
      • Is it possible to defeat polymorphic code?
      • Should auxdata be included?
    • Change max stack height - to be stack needed in addition to inputs
      • makes the two fields (inputs / max stack) unrelated, rather than max >= inputs
      • rename the field from max_stack_height to... max_stack_increase
      • EEST has some auto-calculations we could leverage, client unit tests would incur ~4h work
      • Quality of Life fix, can miss if we are shipping Q1, but if we had 6 more months would be worth looking into for devnet-1
    • Re-order EOFCREATE to match EVMCALL
      • same QoL level of effort. Can miss, but if we have time worth adding.
      • Feels "small"
      • Valuable for tooling and developers manually debugging code, to not have to swap elements
    • Rename RETURNCONTRACT to RETURNCODE
    • Zero client impact, opcode stays the same
    • Documentation changes only
    • QoL for devnet-1
    • Please comment on EXTCODE* after devcon (//TODO add link)
    • EXTDATACOPY and EXTDATASIZE (//TODO add bug link)
      • Target memory? SSTORE2 will use return buffer
      • When SSTORE2 is used in this context really we are talking about just the read side, not write
      • Question now is smart contract read methods equivelantly good.
      • How does it handle legacy and delegate contracts? Read like EXTCODECOPY? Zeros? fault?
      • Would EXTDATALOAD be needed too? (no EXTCODELOAD...)
    • DELEGATECALL to legacy
      • If we fail we need to be able to detect legacy contracts safely and easily
      • Could we further tweak SELFDESTRUCT to behave differently when a delegate of EOF?

@shemnon
Copy link
Contributor

shemnon commented Oct 30, 2024

Cancel the call on the 13th, next call 27 Nov at 1500 GMT

@poojaranjan
Copy link
Contributor Author

Closing in favor of #1192

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants