Breakout-room discussion #7 ( EVM 384 & BLS curves)

[poojaranjan]

Date and Time

• Meeting Date/Time: Monday, Jan 18 at 1600 UTC
• Meeting Duration: 60 mins

Location

Zoom: Will be shared in the breakout-room in EthR&D discord channel

Agenda

• Quick development updates of the proposals

  • EVM-384
  • EIP-2537: Precompile for BLS12-381 curve operations
  • EIP-2539: BLS12-377 curve operations

• Discuss concerns

  • the performance difference,
  • the readiness of proposals for mainnet or
  • any other concern

• Clients' comments on implementation status, integration feasibility & preference on the proposal to be pursued (if any)

• Next meeting - date/frequency?

• Anything else? (Leave a comment).

[gcolvin]

Where can I find the latest documentation so that I can catch up on the state of these proposals?

[poojaranjan]

Where can I find the latest documentation so that I can catch up on the state of these proposals?

These are the resources collected from ACD discord for quick reference:

• EVM384 – Can we do Fast Crypto in EVM?
• EVM384 for Geth
• Current performance of EIP-2537 and EVM384 by Alex Vlasov
• Modifications for EIP-2539 by James Prestwich
• BLS status snapshot

Other links:

• https://github.com/shamatar/eip2537_go_bindings
• https://github.com/shamatar/algebraic_fuzzer

Curated resources for EIPs in the discussion is available here:

• EVM 384
• EIP-2537: Precompile for BLS12-381 curve operations
• EIP-2539: BLS12-377 curve operations

[shamatar]

I think @prestwich can comment about his experience with "gray box" fuzzing of different implementation

[poojaranjan]

Summary

(Recording: https://youtu.be/wJrUQ1QLP9E)

Alex V: It's a long on-going discussion. Two points-

• A particular implementation of BLS 381 is delayed/superseded with EVM 384. What primitive should be implemented for Ethereum?
• If native core precompiles are a better option, they do require more work of testing on later stages, fuzzing, etc. Such requirements should be formalized. EIP-2537 is the highest quality precompile ever included in Ethereum. A formal list of precompile for Consider For Inclusion (CFI) would be helpful to avoid out of thin air comments.

Axic: Clients can make comments on what would be the requirements of precompile & maybe agreeing to formalize the list.

Quick development updates of the proposals

(Axic)

EVM-384

• Working on different things regarding EVM-384,
• Updates provided so far are on a different version of EVM-384, different versions of opcodes. Planning to share another update by tomorrow.
• Mostly looked into Pairing operations which is the most expensive. How cost could be determined? Looked into opcodes Different approaches to dissect the core cost of the interpreter & the processing cost of the codes.
• Run time costs tested on different machines. Results are looking at the safer side of the spectrum
• Room for cost improvements, cost of other instructions. Finding will be published.

EIP-2537: Precompile for BLS12-381 curve operations

• As it is.
• It was made to the point where everyone made it safe & acceptable for inclusion.

EIP-2539: BLS12-377 curve operations

(Prestwich)

• High quality Go implementation integrated with the client and on track to push these out to Celo Testnets (for Celo upgrade) in the next month and the mainnet in March.
• Did a lot of structured building, worked with Alex for fuzzers.
• It ran for a month or so with a billion iteration without running into any issues on Celo's implementation & Alex's implementation & compatibility between them.
• We've full confidence in this EIP however, this will not prevent looking into EVM-384 integration if Ethereum goes that direction.
• Fuzzers are giving valid inputs to the precompile in most cases and also have the ability to generate targeted edge cases and invalid input as well.
• Some writeups will be published.

Discuss concerns

(Tim)

Testing

• Testing is a concern but not a blocker. The main blocker is client developers don't feel confident reviewing the code themselves, which leads to what happens if something goes wrong?
• If there is a bug on the mainnet, what would happen if either there is an arithmetic error that one of the implementations that one of the clients has is just wrong? or is there a concern with consensus failure? The two implementation does not agree with search other
• What if Geth has an implementation that has an error and minority clients used different libraries and are right mathematically. Do such concerns need to be addressed?
• What seems to be appealing about EVM-384 is because they are independent opcode, it is much easier for client developers to have high confidence that those are implemented and the consensus is tested properly across different clients.
• For BLS there is a lot of testing but people are not very confident. We don't have a plan if something goes wrong.

(Alex V)

• There's a lot of independent implementations.
• Clients have the freedom to choose, which one they like.
• The implementations have gone further with paid audits and formal verification performed.
• This is the fastest implementation that is currently available.
• Edge cases are checked. Not the first time used approach, other chains have a similar approach.
• For end-users, it is already a president when a single library is used to implement cryptographic operations by almost all the clients but Geth has an alternative.

Complexity

(Axic)

• It has been one big discussion point in the past but not the only one.
• The other big discussion point was how many different curves? useful curves? different useful curves people want to use are out there?
• Predecessor to this precompile was a more general approach trying to address large space of different curves that people may want to use.
• Different projects use different curves and not just BLS 12.
• BLS 12-321 came into discussion due to limited understanding
  Are we looking for more curves? If yes, where do we stop?
• If we keep on adding precompiles every 6-9 months, complexity will blow up.

Axic: Will only these two curves will be used in the future for next 2-3 year and no other curve will be there?

Prestwich - Can’t say there will be no new curve, but right now, among the families, there are no known curve are getting attention adoption & momentum.

Complexity to EVM -
If we want to arbitrary precision arithmetic then the gas calculation will add another complexity. Arithmetic computation will increase gas cost in EVM 384 and is cheaper in BLS 381. It would require a huge repricing of EVM 384 for calling all other opcode, work required is huge, maybe a year.

Clients' comments on implementation status, integration feasibility & preference on the proposal to be pursued (if any)

Adria: Open Ethereum is not ready with EIP-2537, because we can not review it. It's written, but requires 70K for the review of the code, it's complex and we would pay only if we know that it is going for an upgrade for sure.

EVM 384 has less code and we're more able to review and check it. This is under research, as I understand.

Next steps

• Discord channel for discussion (#cryptography)
• Alex will have a report for EVM-384 coming out tomorrow
• Publish an EIP for EVM-384, once these EVM updates are out

Next meeting - date/frequency?

Paul D.- Meetings should be driven by demand.

Pooja - Will coordinate in the Discord channel.