Update BytecodeStorage Library to be EOF-compliant

[ryley-o]

Although EOF is not currently scheduled to be in the Shanghai scope of changes, we will eventually need to focus in earnest on an updated BytecodeStorage library that is EOF-compliant being integrated into our core contracts, and potentially new versions of these core contracts being deployed across the board for any V3-contract clients.

We can begin this work from a Solidity development perspective before EIP 3540 is final, but it won't be ship-able until said EIP is final 😄

Also related, and also not scheduled as part of Shanghai, we will have to decide if we want to use (or optionally use) EIP 4844 Shard Blob as contract storage space for scripts. This decision may affect if we choose to continue using BytecodeStorage at all, and it may occur at the same point in time as EOF-compliance becomes required.

other refs:

• https://ethereum-magicians.org/t/eof-proposal-ban-code-introspection-of-eof-accounts/12113
• https://eips.ethereum.org/EIPS/eip-3540
• https://eips.ethereum.org/EIPS/eip-3541
• https://eips.ethereum.org/EIPS/eip-4750

Cc @jakerockland

[jakerockland]

Important to note that this will not only impact our V3 contracts that are deployed that use our BytecodeStorage library, but will also impact our dependency registry which is expected to be shipped before EIP-3540 is active, which will then require an upgrade of said dependency registry to use the new updated EIp-3540-friendly-library.

cc @yoshiwarab

[jakerockland]

Important to note that this will not only impact our V3 contracts that are deployed that use our BytecodeStorage library, but will also impact our dependency registry which is expected to be shipped before EIP-3540 is active, which will then require an upgrade of said dependency registry to use the new updated EIp-3540-friendly-library.

cc @yoshiwarab

To clarify, it is this wording that suggests we should have such a transition plan in place.

Finally, create transaction must be allowed to contain legacy initcode and deploy legacy code because otherwise there is no transition period allowing upgrading transaction signing tools. Deprecating such transactions may be considered in the future.

[jakerockland]

This comment is also notable: https://ethereum-magicians.org/t/evm-object-format-eof/5727/40

[ryley-o]

This comment is also notable: https://ethereum-magicians.org/t/evm-object-format-eof/5727/40

This is a great comment that I think aligns with everyone's incentives and will likely become true in the long run. A great reason for us to be proactive on this 🙏

[jakerockland]

Also very important context on the goals ideation around EOFv2 (iteration after EIP-3540, IIUC) – https://notes.ethereum.org/@ipsilon/eof2-proposal

[jakerockland]

@ryley-o thinking about this more – I think we should split the topic tracking "investigate Shard Blob Storage" into its own ticket. Removing that from the title and filing another issue that cross-references this one.

[jakerockland]

Adding for posterity here in this ticket that I've shared this ticket in the Ethereum Magicians forum here: https://ethereum-magicians.org/t/evm-object-format-eof/5727/47?u=purplehat

And also have shared this information in other smart contracts develop groups that we interact with, including the #onchain-html group in the Mathcastles Discord, and the NFT working group that I am a part of in Telegram.

[androolloyd]

afaik shard storage is short term storage, storing there with the long tail intention of utilizing that space for the creation of the the art doesn't seem effective, or am i wrong on something here?

[jakerockland]

afaik shard storage is short term storage, storing there with the long tail intention of utilizing that space for the creation of the the art doesn't seem effective, or am i wrong on something here?

This is quite probably right – I think the part that is TBD here is that there may be a future in which it is only archival nodes that are required at the protocol level to keep full state history, which makes the choice between contract data storage and shard blob storage a bit more nebulous.

In any case, that topic is definitely separate from this EOF-compliance topic and has now been split into a different issue to track thinking around that topic as it evolves (see #423).

[jakerockland]

Update from today's ACD call, still sounds like the target for EOF is for the hardfork after the proximate one (Shangai), which will be called Cancun.

Additional context: ethereum/execution-specs#688

[jakerockland]

Mega EOF spec document, became aware of on EOF implementers call: https://notes.ethereum.org/ZOEv9yyHQdmxTVaYiJmy9Q

[jakerockland]

Note for ourselves, we should be thinking both about how this impacts our Core Contract roadmap, as well as the on-chain dependency registry / templating engine workstream @yoshiwarab @ryley-o

[jakerockland]

Question asked in the eip-3540 discussion thread to clarify our understanding of the EOF roadmap: https://ethereum-magicians.org/t/evm-object-format-eof/5727/57?u=purplehat, based on our convo today @yoshiwarab @lyaunzbe @ryley-o @shantanubala

[jakerockland]

Our latest thinking on how to handle the EOF v1 migration path from the perspective of our usage of on-chain storage for both a) our core contracts for script storage, and b) our dependency registry for on-chain dependency storage.

(a + b allow us to provide an on-chain rendering/templating engine)

[ryley-o]

@jakerockland a very minor update to the diagram that specifies that V2 reader external library calls V1 reader, and does not use DELEGATECALL (as using DELEGATECALL is expected to be disallowed per our note in the upper left of the diagram)

[jakerockland]

@jakerockland a very minor update to the diagram that specifies that V2 reader external library calls V1 reader, and does not use DELEGATECALL (as using DELEGATECALL is expected to be disallowed per our note in the upper left of the diagram)

Great call out – #704 added to validate this future pattern behavior.

[jakerockland]

Note, per latest ACD update it looks like EOFv1 is not currently planed for the proximate hardfork (Cancun).

See https://ethereum-magicians.org/t/cancun-network-upgrade-meta-thread/12060 for additional context.

[ryley-o]

Some important additional notes:

• the "external library" calls from DependencyRegistry can still be DELEGATECALLs (which is indeed the only option provided natively by solidity) because no post-EIP-3540 contract is DELEGATECALLing a pre-EIP-3540 contract
• the "calls" between post-EIP-3540 and pre-EIP-3540 BytecodeStorageReader external libraries need to NOT be DELEGATECALLs (because as we note, this pattern will not be allowed)
  • This is not a natively-supported operation in solidity at this time, but is certainly possible, and given our simple input args, constructing raw CALLs between the two libraries should be trivial to implement, reference: https://docs.soliditylang.org/en/latest/contracts.html#function-signatures-and-selectors-in-libraries