Ethereum Core Devs Meeting 84 Agenda

[Souptacular]

Ethereum Core Devs Meeting 84 Agenda

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

Agenda

1. Eligibility for Inclusion (EFI) EIP Review
   • EIP-1962 and its BLS-Signature working group updates (EIP-2537) - Ethereum Core Devs Meeting 81 Agenda #152 (comment)
   • EIP-2515 - Difficulty Bomb
   • EIP-2315 Simple Subroutines for the EVM 

   • EIP-2456 Time Based Upgrades

2. Berlin Timing
3. EIP-2583 Penalty for account trie misses
4. Testing updates
5. EIPIP Survey
6. Review previous decisions made and action items (if notes available)

Next call: April 17, 2020 14:00 UTC

[holiman]

Some status updates:

• https://blog.bitmain.com/en/bitmains-antminer-e3-firmware-update/ -- bitmain releases a firmware update for E3, so the E3s out there won't all drop off in April, the patch can make them last until October 2020.
• I have made a change-proposal to EIP-2315 (evm subroutines). The changes have been discussed with @gcolvin, but he hasn't signed off on the PR yet: eip-2315: updated spec and examples EIPs#2576

[gcolvin]

I have signed off now. It looks great! Thanks, Martin @holiman

[shamatar]

Returning back to ethereum/EIPs#2046:

• SHA256 function was found to NOT depend on current CALL cost pricing and simultaneously hugely overpriced. Recommended to change to 10 + 6 gas per word (32 bytes) from the current 60 + 12 per word
• Ripemd160 function was found to NOT depend on current CALL cost pricing and simultaneously hugely overpriced. Recommended to change to 12 + 4 gas per word (32 bytes) from the current 600 + 120 per word
• Blake2f function was found to NOT depend on current CALL cost pricing and simultaneously strangely priced. Recommended to change to 5 + 1 gas per three(!) rounds(!) from the current 1 gas per round. Typically it's 10-12 rounds for the Blake2s/Blake2b, so the main benefit here is removal of the huge CALL cost
• BN_ADD function was found to NOT depend on current CALL, but was underpriced. It's recommended to change it to 300 gas from the current 150 gas if CALL cost is reduced
• BN_MUL function was found to NOT depend on current CALL and was well-priced. It's recommended to change it to 6300 gas from the current 6000 gas to account for a worst-case input parameters (largest hamming weight of the scalar)
• BN_PAIRING function was found to be well priced, no adjustments are necessary. Although I would recommend parity to switch from bn package to pairing_ce or EIP1962 implementation cause those are significantly faster
• MODEXP - there was a EIP merged that did NOT perform artificial corrections for CALL cost, so we can conclude that function can be treated to NOT depend on current CALL cost

Bonus:

• keccak256 function was found to consume 10 gas + 4 gas per word (32 bytes) compared to the current 30 + 6 per word (OpenEthereum implementation is just a wrapper on top of tiny-keccak package). Fancy part is that 0, 32, 64 and 128 bytes take the same amount of time, so may be pricing should be changed to elaborate this. Most common use case of Merkle trees would benefit from this, and pricing itself would be more precise. Note that this may be implementation dependent for Rust, but most likely not due to the nature of the sponge construction with 1600 bits of internal state.

[edsonayllon]

Could you add an agenda item for the EIPIP survey?

[MadeofTin]

I won’t be attending this week for EIPs in consideration for Berlin just Read through the list for awareness of what is being worked on.

EIP-1962 and its BLS-Signature working group updates
#152 (comment)
EIP-2515 - Difficulty Bomb
https://ethereum-magicians.org/t/eip-2515-replace-the-difficulty-bomb-with-a-difficulty-freeze/3995
EIP-2315 Simple Subroutines for the EVM 

https://ethereum-magicians.org/t/eip-2315-simple-subroutines-for-the-evm/3941
EIP-2456 Time Based Upgrades

https://ethereum-magicians.org/t/eip-2456-time-based-upgrade-transitions/3902/11

[axic]

MODEXP - there was a EIP merged that did NOT perform artificial corrections for CALL cost, so we can conclude that function can be treated to NOT depend on current CALL cost

@shamatar to be fair I don't think merging a draft constitutes as confirmation that modexp is not relying on call costs

Also on last ACD I mentioned I was working on a document trying to establish cost relationships, so we could reason for the reduction. I haven't gotten to any conclusion yet, but here is my working document: https://hackmd.io/@axic/rJPHqPywI

[holiman]

I've made a new EIP PR: ethereum/EIPs#2583. File is here: https://github.com/ethereum/EIPs/blob/db1e389aae4e05654703d24862b0db91040bf745/EIPS/eip-draft-trie-penalty.md

It implements a penalty-scheme, which is think is much needed at this point in time. If we have time, I would like to present it to the meeting, to get some initial feedback. Some of you have seen early copies of this eip, but it's been expanded since the initial conception, both in the EIP itself and the investigation into if/how it could disturb existing contracts.

[holiman]

@shamatar all of what you conclude is only relevant for Parity, and might also be tied to some characteristics of your hardware.

I will try to repro the benchmarks on geth, but I don't know what vectors ot use, so it would be good if you can publish them somewhere. Even if you generated them on the fly, perhaps you can spit out a relevant cross-section? As I see it, we're not even close to being able to draw any conclusions yet, but initial results look good.

[axic]

In such a scenario, the malicious would spend ~750 gas each call to relay, and would need to provide the relay with at least 700 gas to do a trie access.

@holiman maybe it is worth considering the idea which was brought up as part of "Stateless Summit". Have a separate counter, this time for the entire transaction frame, for the penalty counting. This same counter could be used for witness size counting.

Wouldn't it eliminate this attack vector?

[shamatar]

@holiman

Vectors are randomly generated from seeded RNG. For hash functions it's just a random input into the string. For Blake2f I place random data everywhere and manually control number of rounds (first 4 bytes as BE encoding of uint32). For point_add and point_mul I take a generator and multiply it by random 248 bit scalar (to not overflow the group order value using RNG). For point_mul worst case scalar is [255] * 32 cause there is no check that the value is in range (smaller than modulus). For pairing I do the same, make N pairs by producing random points in a same manner (now you also need to multiply G2 generator by random scalar).

I believe that hardware dependent part is only a constant of 35_000_000 gas/second using ecrecover reference on my machine. We could expect hardware dependency on 32-bit machines or ARM processors, but for modern 64 bit Intel/AMD only one constant should matter.

[holiman]

@holiman maybe it is worth considering the idea which was brought up as part of "Stateless Summit". Have a separate counter, this time for the entire transaction frame, for the penalty counting. This same counter could be used for witness size counting.

Wouldn't it eliminate this attack vector?

Definitely maybe. But that idea can be done in several different ways, and depending on what path you go down, the effects on layer-2 can vary wildly.

I'm open to exploring other ideas, but thought that my EIP suggestion above was about as good as I could make it, and wanted to publish it before moving on to exploring some other solution.

[winsvega]

Testing updates:

• Blockchain generation code reworked. blockchain tests could be generated with retesteth now.
• VMTests generated as blockchain tests
• Launched test run stats http://retesteth.ethdevops.io/

Testing questions:

• Should make a discussion call @holiman and see where to direct the testing efforts

[axic]

@shamatar @holiman I would suggest that:

1. EIP-2046 should be concerned only about the STATICCALL change, with one exception: the price fixing of bnadd and bnmul.
2. keccak256 could be its own EIP, because it is an EVM opcode.
3. The other repricings may be conflated into a single EIP.

However it may be a lot of changes and it could make sense to restrict the number of repricings for this hard fork and roll out others later?

[poojaranjan]

6. Review previous decisions made and action items (if notes available)

Ethereum Core Devs Meeting 83 Notes