I like how the system keeps the posting in line with the Github issue @nicocsgy
Call Notes
Testing
Planning a release soon for Pectra “final”
would like eof-devnet-1 release
concerned about in-progress breaking changes from eof-devnet-0
missing coverage is OK
should only be TXCREATE/EOF Bootstrapping and removing EIP-7698
Fuzzing
start fuzzing next week
Client/Compiler Updates
Nethermind
Passing devnet-0 tests (tests v 2.2)
merged to master
devnet-1 being worked on
evmone
Passing devnet-1 (because it’s filling the tests)
Reth
1 bug on devnet-0 fixed
running sate tests
running some devnet-1 tests
currently in TXCREATE
Geth
no update
EthereumJS
no update
EELS
passing 2.3 devnet-0 tests
PRs for TXCREATE pending resolution of bootstrapping discussion
devnet-1 otherwise fine
Besu
eof-devnet-1 fixing extdelegatecall bug and txcreate gas bugs
PAY opcode - targeting devnet 2
question on legacy support of compatible EOF opcodes
Erigon
No Update
racytech fork passed EOF-devnet-0 fuzzing
Vyper
No updates
Solidity
radak has PRs i queue
working on pectra
working on eofcreate in assembly
assembly is complicated, crosses the line between custom container and assembly code
q: how are creation salts handled?
right now user provided salt, used as-is
No plans for a default solution
q: support new Foo{salt: salt}(input) - has legacy/eof semantic differences
Won’t have a drop-in replacement
frangio: not a good idea, we need to preserve semantics, need to hash with foo’s bytecode, as well as the input data hash. Perhaps rawsalt is the unchanged salt, and salt has the initcode and input brought into the salt calculation. Just new Foo(input) not compiling is insufficient, the salt should include data hashed from input and initcode to match legacy security guarantees.
piotr: the rawsalt hashing will be cheaper, there are cost implicaions with EOF.
cameel: Daniel prefers rawsalt == salt, please come on our calls to discuss with daniel. We need a non-solidiy opinion on this.
Spec Changes / Updates
Legacy opcode support
Is PAY legacy support
Danno’s proposal: wait for a request to be made in the appropriate EIP’s eth-magician threads
PAY, however, uses EOF’s return code semantics and we would introduce that into legacy if we bring it over, or we would need to change the opcode for legacy
In general, we need to keep the possible differences in behavior in legacy.
Frangio thinks differing impls based on context is a bad idea, and that users will just need to keep in mind what is happening.
What is the impact? Clients is mostly small, EEST tests are larger
Frangio - waiting for requests could be a while, bad for “outsiders” who don’t keep up.
How do we know which ones?
Not including is not an irrevokable decision, just costs time (on the order of a year)
Possibly RETURNDATALOAD, and EXTCALL opcodes into legacy
Time boxed discussion, no decisions.
EOF Bootstrapping
Danno summarized the document
Q: Why does option 4 and 6 limit it to one initcode?
felt cleaner
not mandatory
could be changed
Q: Address of 4?
same as types 0, 1, 2 - nonce based
Note options 5 and 6 provide cross-chain address niceness.
no dependency on nick’s method, with no nonces.
also 5 and 6 do not include the address of the sender
5 and 6 can be front run, does not include address.
including the sender means you cannot un-include this
option 7 propsoed: execute initcode as legacy and allow it to TXCREATE
Tension is address of sender vs. front-running capability.
If your contract doesn’t use sender or tx.origin, or the value, then frontrunning is a wierd suprise. Contract creation that depends on externalities will be vulnerable
Main question: Stick with 3 for devnet-1? Will it hurt adoption? Can we add a variant of 4,5,6 in the future?
