ECIP-1109: "Spiral" network upgrade

[diega]

Let's talk about #510, Spiral network upgrade.

[IstoraMandiri]

Interoperability: Establishing and maintaining interoperable behavior between Ethereum clients is essential for developers and end-user adoption, yielding benefits for all participating chains (e.g., ETH and ETC, Sepholia and Mordor).

Immutability: None of the introduced new opcodes in the EVM has the potential to change the behavior of existing contracts. Adding opcodes to the EVM increases its functionality and should be considered a feature upgrade rather than a modification.

While this means no currently executable contract is affected, it states deployment of new data contracts starting with the 0xEF byte.

Looks good to me

[meowsbits]

EIP4399 is categorized as "Compatible inclusion". I'm not sure I understand what's intended here. To me, it seems that the EIP is not relevant or applicable to ETC, since for ETC the difficulty values are never supplanted, and the EVM is still expected to return a Difficulty value from 0x44.

My concern primarily comes from where EIP4399 is (anonymously) implemented in core-geth's code: https://github.com/etclabscore/core-geth/blob/master/core/vm/jump_table.go#L196-L203. ETC does not, AFAIU, want to adopt the opRandom behavior, which leads me to think we should just categorize this EIP as Omit.

[diega]

I wanted to define a category for an EIP that's not exactly included, in the sense that we're not changing consensus nor semantics, but that for practical matters (i.e. compilers) the behavior is compatible. We may mark it as omit, but I think it would be good if we make it clear that when a developer uses block.prevrandao in Solidity, that will be compiled to 0x44 and will behave exactly like the, now deprecated, block.difficulty

[meowsbits]

So the Solidity type constraints are the same (as a number of same potential magnitude), but the meaning of the operation will vary; for ETC 0x44 will (still) return the context's block difficulty, and for ETH will return a random value.

[meowsbits]

I like Omit with a note early in the abstract that despite omission, EVM compatibility remains invariant though the operational logic will differ.

[bobsummerwill]

Another option would be to write a very short ECIP which we include instead, detailing the difference.

Maybe we should also have done that (and could do so retroactive) to note the non-inclusion of BASEFEE?

[diega]

I created #513 moving 4399 to omit

[bobsummerwill]

I think that description in the Meta ECIP is good enough, yes.

Maybe we review the Meta ECIP for the hard fork where BASEFEE was not introduced and add some similar language there if the current ECIP is not sufficiently clear that our EVM varies in behaviour from the ETH EVM on that point?