Discussion topic for EIP-7761
None as of 2024-09-02.
None as of 2024-09-02.
The EIP should name the specific EIP that disables EXTCODESIZE rather than the meta EIP for EOF.
That would be EIP-3540, and it is already listed.
The Changes to Execution Sematics section of EIP-3540 is where EXTCODE* is banned in EOF.
It seems much easier to just add back EXTCODESIZE. I haven’t yet found the rationale for removing the extcode opcodes.
I distilled some takeaways from a Eth R&D discord conversation here: Update EIP-7761: Fill Endgame AA's Rationale section by pdobacz · Pull Request #8904 · ethereum/EIPs · GitHub (Endgame AA concerns), hopefully this is accurate. If there are more arguments to be made, let’s continue the discussion here.
Overall the arguments are not very convincing to me either.
@vbuterin’s initial proposal was to ban code introspection of EOF accounts only, the rationale was very clear, and there was at least an idea of how to migrate legacy accounts. Current EOF seems to have gone way beyond this initial proposal to ban code introspecion by EOF accounts of all accounts, with unclear rationale, and to my knowledge no idea of how to eventually migrate.
I have a few questions about the return values for this opcode.
When I (informally) discussed this opcode, I proposed the following:
0x00xEF00XX) return the version of the contract, as defined in EIP-3540 (0x01-0xFF)0xEF0100) return 0x100 (this is in continuation of the eof version)0xFFFFFFFFThis is included in the spec:
If
loaded_codeindicates a delegation designator (for example,0xef0100as defined in EIP-7702),
- replace
loaded_codewith the delegated code.- deduct gas in accordance with the delegation designation rules
i.e. return value that of the targetted delegation.
Some practical intention of this is EOA return value match legacy’s EXTCODESIZE, allowing for a quick ISZERO check, as the main purpose of EXTCODETYPE remains to do the legacy’s EXTCODESIZE > 0 check.
Leaking the EOF version to the EVM and allowing coupling smart contract codes to it doesn’t sound right to me.
Would
0x00xEF00XX) return the version of the contract, as defined in EIP-3540 (0x01-0xFF)0xFFFFFFFFFWork better ?
On of the many usecase of this opcode, and the reason it makes a distinction between EOF and legacy contract is that there is a risk (for EOF contract) to delegate to a legacy contract, and that EOF contract should be able to inspect if something is a contract that they can delegate to, or not.
I’m somehow worried that maybe in version 3 of EOF we introduce something that introduce a similar case where its safe to do something with other EOF contract of version 3, but not version 1 or 2. In that case, we may want EOF contract to detect the version of other EOF contract, which this EIP doesn’t support.
It but does address the ISZERO problem. It would still be nice to have the versions ordered for simple comparison, but that can be solved with: return 0x01 for legacy and the entire 3byte 0xEF00<version> for EOF.
That is subjective, but I maybe am less worried. I also think that the worrying about the “proxy-accidentally-upgrading-to-legacy-and-bricking” is overstated, as it would indicate that the upgrade is done without proper testing in place. And there are I guess many ways to brick an upgrade, but I’m open to discussing how the particular EOF-to-legacy upgrade case is special, I might be missing sth.
If I put myself in the shoes of a smart contract developer, I have no way today to know if I should be doing my EOF-check like EXTCODETYPE == 0xEF0001 or EXTCODETYPE > 0xEF0000, as I don’t know if EOFv2 will break my assumptions or not. Which boils down to the leaking point I made.
I find it somewhat safer to have EXTCODETYPE not be impacted by EOF version at all, even if it absolutely must discriminate btw legacy and EOF. In the unlikely event that discrimination between EOF versions is absolutely necessary for EOFv2, this could be handled by an extra opcode like EXTEOFVERSION.
(Actually, I now see that the EIP nails down the specific version of EOF, so it already implies a design like yours, where version will be distinguished! I forgot about that detail, I will propose to explicitly decouple the result from EOF versioning as a counter proposal, or at least we should make it clear what the returned value is intended to discriminate)
That also sounds great to me
I want to say that right now there is no plan for any future incompatible “EOFv2” on the horizon. All of the features getting serious discussion are all backwards compatible and won’t require a major version bump.
Personally I would be resistive to any new major EOF version in the next 5 years (assuming we ship with our current planned slate include TXCREATE) and a better goal is 10 years. The best goal is no future EOFv2 and I am optimistic that remains an option.
This feels like something we will want to address in 5-10 years time when we are aware of what the breaking features are and how other contracts may want to interact with them. So making space today for a feature we know nothing about seems a little presumptive. Changing the EXTCODETYPE return is an option, as is a new version opcode, but we don’t have any idea what the impacts would be, so I think it is best to plan for what is best for today.