Ethereum Core Devs Meeting 94 Agenda

[Souptacular]

Ethereum Core Devs Meeting 94 Agenda

• Meeting Date/Time: Friday 21 August 2020, 14:00 UTC
• Meeting Duration 1.5 hours
• YouTube Live Stream

Agenda

1. Progress on EIP-1057
2. Ewasm Team: Findings on "evm384"
3. EIP Discussion
   a. Vitalik's Idea
4. YOLO / YOLOv2 & Berlin state tests update
5. Raw benchmarks for EIP 2666
6. EIPIP Meeting: New EIP Statuses
7. Ethereum Cat Herders Survey Results
8. Migration from ACD Gitter to Eth R&D Discord
9. Review previous decisions made and action items (if notes available)

Next call: September 4th, 2020 14:00 UTC

[edsonayllon]

Can we add a section talking about the new EIP statuses from EIPIP?

[gcolvin]

I'll need to leave to see a doctor by 14:30, so will want to make a quick status update on EIP-1057 before I go. I intend to put it on the agenda for ACD Meeting 95, will say more later tonight.
@Souptacular

[gcolvin]

Progress on EIP-1057 has been slow - two of the co-authors have been very ill, and one is still in and out of hospital.

The reference code hasn't changed since @AndreaLanfranchi's May 1, 2020 PR to fix the Kik exploit and mitigate the "Light Evaluation" attack as suggested by Least _Authority.

The EIP itself mostly needs minor edits and final review of the spec. The current EIP PR is here.

Note: We Do Not recommend that this Proposal be deployed at this time. Rather it is being offered in the spirit of Ben DiFrancesco's compromise, which @vbuterin and others have taken to be the consensus of Meeting 82.

[shamatar]

Necessary benchmarks for EIP 2666 were provided by the clients and raw form is assembled in here

Besu benchmarks

Short summary:

• BNADD

		Gas
Geth		350
OE		225
Besu		165
Nethermind		120

BNADD cost will need to be adjusted when EIP 2046 is accepted

• BNMUL

		Gas
Geth		3000
OE		6250
Besu		19109
Nethermind		5250

Besu result is surprising (I was told that some Rust lib is used, and addition looks fast, but multiplication is very slow). Only little repricing will be necessary when EIP 2046 is accepted

• SHA256 precompile

Currently it's 60 gas + 12 gas per 32 byte word. Proposed formula is A * ((len(input) + 8) / 64 + 1) + B, with coefficients below

		A	B
Geth		5	3
OE		9	4
Besu		5	10
Nethermind		10	5

EIP 2666 proposes A = 9, B = 5. Besu implementation is Java built-in, so I doubt it can be improved, so it would be better to set A = 9, B = 10 that largely fits everyone. There are no large one-off costs in this precompile, so it's EIP 2046 - safe.

• RIPEMD precompile

Currently it's 600 gas + 120 gas per 32 byte word. Proposed formula is A * ((len(input) + 8) / 64 + 1) + B, with coefficients below

		A	B
Geth		12	6
OE		8	2
Besu		29	16
Nethermind		10	6

EIP 2666 proposes A = 12, B = 6. There are no large one-off costs in this precompile, so it's EIP 2046 - safe. Besu expects to have performance improvements by the end of the year

• Keccak256 performance

Currently it's 30 gas + 6 gas per 32 byte word. Proposed formula is A * (len(input) / 136 + 1) + B, with coefficients below

		A	B
Geth		13	13
OE		15	2
Besu		19	28
Nethermind		16	3

EIP 2666 proposes A = 15, B = 13. There are no large one-off costs in this precompile, so it's EIP 2046 - safe. Besu expects to have performance improvements by the end of the year

[Souptacular]

@gcolvin

@vbuterin and others have taken to be the consensus of Meeting 82.

Can you cite this? I haven't personally seen anyone say there was consensus that the compromise was accepted by the core devs or community.

[axic]

If there is time, the Ewasm team would be interest to present our findings regarding "evm384": https://notes.ethereum.org/@axic/evm384

There is also an EthMagicians topic for discussion.

[Souptacular]

@axic Added to the agenda!

[shamatar]

Nice one, @axic. I've briefly looked at the code and speed-wise arithmetic operations should have the same performance in 1962 and your implementation. Then what is a source of 3x performance difference? Memory checks and copies/dereferences?

[axic]

looked at the code

Do you mean the implementation in evmone?

There is definitely overhead in the EVM for memory operations, and crafting an optimal stack layout is not trivial in many languages for the EVM. We have used Yul which definitely struggles with optimal stack allocation. It seems that Huff would be a good candidate for creating higher performance bytecode, but partly due to lack of time and our unfamiliarity with Huff we have not used it yet.

[shamatar]

looked at the code

Do you mean the implementation in evmone?

Yes, I’ve briefly looked at add/sub/mont_mul code. Assembly could have given 30-40% boost there, but 1962 does not use it, so it’s quite apples to apples for arithmetic performance.

[poojaranjan]

If we get time, I can share a quick summary of the survey results - "The state of client diversity in Ethereum". 

[Souptacular]

vbuterin: One topic I want to bring up is short-term gas cost increases for storage-accessing operations. I can talk about why I think this is necessary; the short form is (i) the regenesis plan advocated by Alexey and co includes witness size bounding for partially stateless clients, but there's reasons why we need witness size bounding for fully stateless clients as well, and (ii) it's a quick short-term path to mitigating the "30 second DoS block" issue that is simultaneously very well aligned with 1.x and 2.0 objectives regarding witnesses

[timbeiko]

Closed in favor or #203