Skip to content

Recursive verifier#440

Open
gabriel-barrett wants to merge 28 commits into
mainfrom
recursive-verifier
Open

Recursive verifier#440
gabriel-barrett wants to merge 28 commits into
mainfrom
recursive-verifier

Conversation

@gabriel-barrett

Copy link
Copy Markdown
Member

Implements the recursive verifier, that is, multi-stark in Aiur, including Plonky3's PCS verifier.
Currently it assumes values of a few parameters:

  1. capHeight = 0, meaning commitments are a single digest. Cap height decides how deep into the merkle tree the commitment is. A greater cap height means the commitment themselves are larger, but it saves on the openings.
  2. maxLogArity = 1, meaning FRI uses arity 2 fold.
  3. queryProofOfWork = 0, meaning there's no proof of work before the sampling of query indices

Eventually we could generalize it to accept other values for capHeight and queryProofOfWork. This is mostly for proof size. Regarding maxLogArity, it might not be worth it generalizing it, since arity 2 is pretty standard

Comment thread RecursiveVerifier.lean
@@ -0,0 +1,201 @@
import Ix.Aiur.Meta

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This file seems to be a smoke test for the recursive verifier.
I think testing should be properly integrated in the test suite.

Comment thread Cargo.toml
lean-ffi = { git = "https://github.com/argumentcomputer/lean-ffi", rev = "cc98ebf67bf453ac3827cb767f78b13ea674dd6a" }
mimalloc = { version = "0.1", default-features = false }
multi-stark = { git = "https://github.com/argumentcomputer/multi-stark.git", rev = "9ecab51d553445c0cc7b571af00a76b8a83a6f8c" }
multi-stark = { path = "multi-stark" }

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This change needs to be undone.

Comment on lines +56 to +58
enum Commitments {
Mk(MerkleCap, MerkleCap, MerkleCap)
}

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seeing these single-constructor enums gave me the idea: they don't need tags in the bytecode and should be treated as simple tuples

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants