[PROPOSAL] Audit for Circom-Ed25519 for standardization of NEAR ZK Light Client

[garvitgoel]

Background

This proposal is part of the discussion from the ZK Working Group. Electron Labs has created a ZK library that generates SNARK proofs of a batch of Ed25519 signatures. This allows succinct verification of the NEAR block headers on the Ethereum blockchain.

Goal

Through this proposal, we aim to conduct security audits for this implementation. If successful, this will bring us one step closer to standardization of the ZK implementation of the NEAR Light Client.

Project Links

Implementation - https://github.com/Electron-Labs/ed25519-circom Docs - https://docs.electronlabs.org/ Underlying Mathematics - Medium

List of Firms with ZK Audit Experience

Links to the relevant ZK-audit work has been provided.

ABDK Consulting https://www.abdk.consulting/

• Tornado Cash - link
• Railgun - link
• ZK Swap - link
• zkSync - link
• Elusiv, a Circom based privacy protocol- reports not public yet

Trail of Bits https://www.trailofbits.com/

• Hermez, an zk-rollup build on circom - link
• ZCash Security audits - link, link, link
• Aleo zkVM audits - not public

Least Authority https://leastauthority.com/

• Circom circuits for ZKopru - link
• ZK Circuits for Loopring - link
• Aleo Trusted Setup Ceremony - link
• ZK Cash Security Reports - link

Hashcloak https://hashcloak.com/

• MACI - link
• Light Protocol, a ZK based privacy protocol - link
• Lelantus Spark Audit link

Igor Gulamov

• Audit of ZKopru Circom circuits - link

[frol]

@garvitgoel Thanks for opening up the conversation! Could you, please, elaborate more on the action items here and what immediate next steps you believe should be taken?

[garvitgoel]

cc: @nearmax

[maxzaver]

@frol this is a proposal to whitelist certain ZK-competent auditors so that we can proceed with auditing projects like speeding up Aurora bridge with ZK compression. This is a good topic to discuss during our next ZK Community Group meeting.

[austinabell]

@frol this is a proposal to whitelist certain ZK-competent auditors so that we can proceed with auditing projects like speeding up Aurora bridge with ZK compression.

Whitelist for who exactly? For Electron labs specifically or some other defined group(s)?

[garvitgoel]

@frol this is a proposal to whitelist certain ZK-competent auditors so that we can proceed with auditing projects like speeding up Aurora bridge with ZK compression.

Whitelist for who exactly? For Electron labs specifically or some other defined group(s)?

Hi @austinabell sorry for the late reply. I am not the authority to speak on this, but Circom-Ed25519 is a public good free to use across NEAR ecosystem. The audits will help in making this work production ready. Making a ZK Light Client for NEAR is one of the items we are discussing in the ZK Community Group.

As we built a ZK-ecosystem on NEAR, it will be easier for newer projects to have a panel of auditors to work with.

Full Disclosure: We plan to use this work in our upcoming zk-bridge - https://positron.electronlabs.org/ (live on testnet)

[Mikerah]

Hi all, I'm Mikerah from HashCloak, one of the audit forms listed here. Garvit reached out to us late last year and we provide a quote alongside a timeline and the prospective auditors that we would assign to this project. I'm not sure if I should share all that info here. I should also note that our availability has changed quite a bit since then and we are looking at booking into May 2023.

[rahulghangas]

@nearmax @frol @austinabell I would strongly recommend that the aforementioned circuits not be audited, or used in production. They are incomplete and severely under-constrained, and it is possible to create valid proofs for invalid signatures. I am the primary author of these circuit (although my commits have been overwritten on the main repository, you can find my commit history here). If used in production, these circuits will not serve as proper validation of validator signatures, and the prover could potentially spoof erroneous proofs. So any bridge using these will not be a functioning light client bridge, but rather a centralized bridge where user assets will be at risk

I have raised these concerns with the team before, but they have failed to pay heed to them