Ethereum is turning into a labyrinth of unnecessary complexity with EOF - Let's reconsider EOF

[duncancmt]

@shemnon

@duncancmt

TXCREATE’s functionality (or lack thereof) not supporting CREATE3-like patterns.

TXCREATE as specced out in EIP-7873 is designed to allow anyone to deploy a CREATE3-like EOF factory… The current plan is to ship it with the Osaka specced EOF version.

Awesome! As @pdobacz pointed out up-thread and I replied, I had written the originally-linked thread before that was possible and had not checked up on the changes

@shemnon

@duncancmt

The insistance around lack of inspectability of bytecode (and how you can’t completely hide the bytecode if you have anything resembling CREATE2)

Vitalik makes the best arguments for banning code introspection. … Allowing the code to enter or leave system memory locks in one particular representation of the contract as part of consensus.

I’m not denying that there are reasons for having this behavior. My point here is that there are interesting (and arguably valuable) use cases for being able to know things about the code deployed to other addresses. By removing this functionality, it creates new problems for application developers. As a consequence of creating those problems, there is a very explicit disincentive for developers (like myself) to adopt EOF.

@shemnon

@duncancmt

Gas rules (not allowing capped-gas *CALL, the 2300 gas rule, 63/64ths rule)

Relying on a fixed gas schedule has been a problem for a long time and best practices are to not rely on it. EOF formalizes this recommendation in a way that allows future EVM repricings to have minimal impact on user code. There is a working group working on dramatic changes, including things like multi-dimensional pricing and code merkelization, which will have dramatic effects on the gas schedule as a whole.

This is not the only reason to want to pass something less than all-but-one-64th of the available gas to a sub-context when performing a call. Particularly if the called contract is only somewhat trusted by the calling contract. Again, there are valuable design patterns enabled by the ability to pass less gas when performing a call, and the removal of that capability makes my life harder.

Additionally, designing contracts around opcode repricing has been a thing for ages already. A contract that is designed in such a way that it is brittle to opcode gas costs is already a badly-designed contract.

---

Overall, while I appreciate the detailed responses, @shemnon, that you’ve given to the criticism in this thread, but I think that taken in totality they’re clearly missing the point here that EOF is being sold as “a VM improvement that will benefit smart contract developers”, when in fact it is actually being driven by the needs/agenda of the execution layer to the detriment of smart contract developers. It’s this discrepancy that causes me to bristle and which I think will ultimately stand in between EOF and adoption. That’s not to say that I don’t see and appreciate the reasons why EOF may be a net improvement to Ethereum, but when I look shortsightedly at the path of least resistance, that path is “ignore EOF if adopted and oppose it before it is because, it makes my life harder”.

And I also endorse the general thesis of the OP: this is additional complexity that is patently unnecessary from the perspective of the smart contract developer.