Giters

ethereum / pm

Project Management: Meeting notes and agenda items

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Execution Layer Meeting 183

timbeiko opened this issue · comments

commented

Meeting Info

Agenda

commented

I'd like to discuss the latest with EIP-2537, now that it has been scheduled for Pectra.

We will be doing gas costs updates and make a pass on testing/test vectors in the coming months.

After talking with various users of this precompile and sourcing use cases, including zero-knowledge cryptography and zk-rollups, we have the following open questions. I'd like to raise them for awareness and discuss with core devs to get a temperature check on what to include to finalize EIP-2537.

EIP-2537 open questions

  • Precompiles for point decompression: can be better for computation in data-constrained environments (e.g. L2s)

  • Precompiles for operations in G_t: BLS12_GT{ADD, MUL, MULTIEXP}

  • Update BLS12_PAIRING to BLS12_PAIRING_VERIFY (which works as currently specified) and add another precompile BLS12_PAIRING which returns the result of the pairing operation.

And note, I'm working on sourcing a "hash to field" implementation in Solidity, which should be cheap enough to not need a precompile. There are also some cryptographers reviewing the text for editorial changes and relevant security call outs (e.g. cofactor clearing). I'll also be having a similar conversation with rollups on the next RollCall I can attend.

commented

Could we discuss EIP-7645 (alias ORIGIN to SENDER)? Or, if that change is too steep for Pectra, the precursor step of banning all new use of ORIGIN (contract deployment txs containing ORIGIN are invalid)?

commented

Think agenda might be busy given priorities, but we published our research on state growth recently which may be relevant to people working on EIP-4444 and Verkle, so would be keen to have @sslivkoff present either on the next ACDE.

https://www.paradigm.xyz/2024/03/how-to-raise-the-gas-limit-1

commented

Could we discuss EIP-7645 (alias ORIGIN to SENDER)? Or, if that change is too steep for Pectra, the precursor step of banning all new use of ORIGIN (contract deployment txs containing ORIGIN are invalid)?

Banning opcodes from new deployments doesn't work for legacy EVM. What if ORIGIN shows up in solidity's signature data?

commented

Could we discuss EIP-7645 (alias ORIGIN to SENDER)? Or, if that change is too steep for Pectra, the precursor step of banning all new use of ORIGIN (contract deployment txs containing ORIGIN are invalid)?

Banning opcodes from new deployments doesn't work for legacy EVM. What if ORIGIN shows up in solidity's signature data?

Not sure if this is the right venue to have this discussion, but in the ban-only-for-now scenario, ORIGIN code would still exist within old contracts, would still be an accessible variable within transactions and still be treated the same way it's always been treated. The only change is it won't be able to appear in new smart contract code. The idea is to start aligning ORIGIN and SENDER, tease out misuse cases and give us more information about the implications of aliasing of ORIGIN to SENDER.

I might be missing something in your question, though. Maybe we table this until tomorrow or until there's an EIP for the ban-only proposal?

commented

We can discuss tomorrow, but I don't see how we can ban an opcode without code/data separation. For that we need a container format, which is EOF. Code validation has no context with our stream-of-bytes model, apart from jumpdest analysis, which is only a runtime impact not a tx validation/CREATE time impact.

commented

@ralexstokes thanks for flagging, have added it to the Pectra discussion! @gakonst agreed this is valuable to bring up. I've put it after all the "in progress" EIPs, and think we should have time for at least a brief overview. @cyrusadkisson I'll put yours at the end, but if other topics take too long we may have to push this to another call.

commented

hey! for the pectra discussion i think it would be great to discuss the EIP-7547 (inclusion lists) spec PoC we are prototyping: https://notes.ethereum.org/@mikeneuder/il-poc-spec. lots of people have been involved. also would like to discuss the friday breakout room

commented

Hi all, I'd like to join and am happy to comment on the benefits of EIP-3074 for our existing wallet users.

commented

If there's time, I'd like to quickly share some updates on EIP-7623.

I did some impact analysis and published the results in the following:

  • Table showing the individual methods and if they'd be impacted
  • Quick post with many more details on the EIP
commented

if there's time, i'd like to get more feedback on including EIP-5920 and EIP-7069 in prague/electra

commented

@danfinlay thanks for coming on! adding you to the top of the Pectra section. @nerolation @charles-cooper I've added your proposals to the agenda too... let's see how far we get!

commented

would like to discuss a small cleanup to 4844 EIP references:

commented

Closed in favor of #982