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.