Proposal to include EIP-2327 ("BEGINDATA") in London
Closed this issue · 10 comments
Thanks for proposing, @chriseth ! I've added it to the agenda for this Friday's call, but it's already quite packed, so there is a risk we don't have time to get to it. If you'd rather not attend the entire call with the risk of your EIP not being discussed, let me know. I can add it to the call after and make sure we prioritize it then.
Great, thanks! I guess it would be nice if interested parties (thinking e.g. of @holiman ) could already comment in the magicians thread about the dangers of potential backards-compatibility problems - I remember this has been discussed in context of other EIPs in the past.
Got it. So are you fine optimistically leaving it for this Friday's call 😄 ?
Sure!
@chriseth added to next call's agenda given we couldn't cover it today https://github.com/ethereum/pm/blob/master/README.md#acd-108-march-19-2021
From the ETH R&D discord:
BEGINDATA - proposal looks simple enough, but I would prefer to first look at a more general proposal from @alex (axic) that proposes the introduction of code formats. If the more general approach is found too complex, I would consider including BEGINDATA.
2327 Begindata: imo also too soon/rushed. In it's current form, it's not ideal, IMO, and could be done better.
( same comment being posted to simple subroutines)
I don't think this should target London. The EVM encapsulation format I think is what the first step should be. From there we can impose rules on the EVM bytecode that will make evolution easier.
This proposal will completely moot the BEGINDATA opcode and it feels like a hack to deal with the EVM's tolerance of invalid opcodes and the implications it has on multi-byte operations. I support evm code segmentation but I think right now the evm encapsulation design needs to run it's course before considering this. If it is successful then this will be implicit in that design.
Hey I'm Mark from Optimism, this EIP (or something similar) is really helpful for improving the UX for deploying contracts onto Optimism. There is a Safety Checker that any contract being deployed onto L2 must pass so that we can guarantee deterministic execution on L1 for the fraud proof. Currently, the Safety Checker sometimes fails when it shouldn't due to it interpreting the constructor arguments as opcodes. The current solution is to just try different constructor args until it works which isn't the ideal user experience. Addresses are known to trigger this problem. I'd like to learn more context around this EIP and how we can help to get this functionality into Ethereum.