[ZKLLVM] Trustless ZK-proof TVL oracle

Hey everyone, sharing a brief update on the state of =nil; Foundation’s zkOracle for Lido.

Recently, we came to a crossroads for development. After running some preliminary tests on our first Prover version, we realized we would not be able to meet the desired requirement for Lido for this zkOracle. Specifically, those requirements are:

  • Proof generation time: 30min
  • Proof generation cost: $200

Our initial tests came out to approximately 2 hours for ~$1k. You can see our first update here.

After discussing with the Lido core contributors, it’s obvious this is not a viable solution for the production grade zkOracle. The contributors suggested we evaluate the DendrETH approach to zkOracle.

We have reviewed the proposed design by DendrETH, which uses a data caching technique to mitigate the bloat from memory. We’ve run into a similar problem with another project of ours (CasperFFG) and believe this is the optimal design. We’ve reassessed our solution to identify how it might be repurposed to fit this proposed design but unfortunately there doesn’t appear to be much reusable work.

The DendrETH approach can reduce the validator merklization cost by 100x, 200x - depending on the size of the subproblem. Practically, they saw 9-10x speed up (no further details on setup and branching factor). At a glance, if we are to replicate this, we’d need an “recursive proof with explicit circuit”. This would require to make a dedicated circle to compute validator merkle subtrees, change our main circuit to accept pairs (merkle_subtree_root, merkle_subtree_proof), verify proofs, and compute overall merkle tree root from subtree roots. Additionally, we’d need to provide a caching mechanism to store subtree proofs (could be a centralized one, or baked into oracle - the former is faster/more performant, the latter is devops overhead and smaller attack surface). Finally, we’d need to change the oracle to use the “subproblem circuit” first and caching in case validators didn’t change.

Accordingly, we must reset internally and assess how we might allocate resources within our organization to deliver additional work. We’re also speaking with several third-party teams to takeover the completion of this work. We expect this assessment to take approximately 2 months as we restructure our team.

If you have any questions please let us know!

2 Likes