Ethereum Core Devs Meeting 100 Agenda

[timbeiko]

Ethereum Core Devs Meeting 100 (!!) Agenda

• Meeting Date/Time: Friday 13 November 2020, 14:00 UTC.
  • Daylight savings will have happened in North America, double check the time!
• Meeting Duration 1.5 hours
• YouTube Live Stream: https://youtu.be/5-614J9qNvY

Agenda

1. YOLOv3 & Berlin client updates
   • YOLOv3 spec
     • EIP-2718 clarification & interactions with 2930
   • Final go/no-go for Berlin EIPs
2. Network upgrade process update
3. Other EIPs
   • EIP-2938 (Account Abstraction)
   • EIP-2666
   • BLS12-381
4. Responsible disclosure / Geth bug

Next call: November 27, 2020 14:00 UTC

[prestwich]

Can we talk about responsible disclosure policies for consensus issues? We're downstream from geth, and would much appreciate hearing about consensus issues more quickly after the geth team learns of them. I'm sure other teams that maintain large infrastructure would appreciate it too

[shamatar]

I'd like to add two more points to agenda:

• EIP-2666 was cleaned up, simplified and now merged
• We can continue the discussion on the efficient BLS12 implementation given that empirical measurements don't support a claim that EVM384 is going to be "acceptably efficient" - explainer

[poojaranjan]

I & @MadeofTin will be happy to give a walkthrough or answer any questions on the new
Network upgrade process.

[karalabe]

I'd like to request some clarifications wrt EIP-2718. The spec explicitly wants to omit defining what different transaction types will be in the future and how the numbers are allocated:

There was discussion about defining the TransactionType identifier assignment/selection algorithm in this standard. While it would be nice to have a standardized mechanism for assignment, at the time of writing of this standard there is not a strong need for it so it was deemed out of scope.

This is of course fine as we don't know what the future holds, yet I do think it misses a crucial clarification, namely explicitly stating how legacy transactions behave.

The spec talks about transactions in both a legacy format as well as a wrapped format. The moment you mention the latter, you need to explicitly define it. I think the idea was to have TransactionType == 0 be a legacy wrap, but without a very strong definition of how the legacy transactions should be handled on the wire, RPC and in the consensus structures, this is going to blow up (e.g. in the transaction hash field of a block, do we hash in legacy format or in wrapped format?).

If the EIP does not want to define the wrapped version of legacy transactions, that's is fine, but then my request would be to explicitly mention it that clients implementing this EIP are still expected to fully only use the legacy format, and that and future wrapping will be defined in a future EIP and will explicitly spec the wire, RPC and consensus representation for them.

My personal suggestion on that front is that maintaining both formats in the consensus format is insanity which will surely backfire when some client code does a weird conversion and goes out of consensus; so I'd vote to either use one or the other, but never both.

[holiman]

I think there's a dissonance between 2930 and 2718. In 2930, I get the impression that the hash for a transaction is done by rlp-encoding into the hasher. Basically:

hash([1,[...]])

But the 2718 spec instead sounds like the correct way to hash it would be to hash it as a prefix + opaque blob. Basically:

hash(1, [...])

(where [] means rlp-list)

[timbeiko]

Closed in favor of #224