Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Documentation - Centralized Telescope: Proof #145

Open
wants to merge 35 commits into
base: main
Choose a base branch
from

Conversation

curiecrypt
Copy link
Collaborator

@curiecrypt curiecrypt commented Feb 4, 2025

Content

This PR includes extensive documentation for the proof of the centralized telescope scheme, bridging the implementation with theory.

Note that it is based on PR #103.

  • telescope.rs is explained by the files in docs/rustdoc/centralized_telescope/telescope directory.
  • proof.rs is explained the files in docs/rustdoc/centralized_telescope/proof directory:
    • hash functions
      • bin hash
      • round hash
      • proof hash
    • internal functions:
      • prove index
      • dfs
    • prove function
    • verify function

Each documentation link is referenced in the code where necessary.
Additionally, doc files include links to related documents wherever they are mentioned.

Pre-submit checklist

  • Branch
    • Commit sequence broadly makes sense
    • Key commits have useful messages
  • PR
    • No clippy warnings in the CI
    • Self-reviewed the diff
    • Useful pull request description
    • Reviewer requested

Comments

It is strongly recommended to render the documentation for reviewing this PR.

Issue(s)

Blocked by #102 #142
Closes #144

@curiecrypt curiecrypt force-pushed the curiecrypt/doc-centralized-proof branch from 13acba3 to 71947af Compare February 4, 2025 18:53
@curiecrypt curiecrypt force-pushed the curiecrypt/doc-centralized-proof branch from 71947af to e806e0f Compare February 4, 2025 19:34
@curiecrypt curiecrypt marked this pull request as ready for review February 12, 2025 18:27
Copy link
Collaborator

@rrtoledo rrtoledo left a comment

Choose a reason for hiding this comment

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

First pass on documentation
Looks good! Just a few minor points :)

Will do another pass checking the links and rendered pages.

## Prove
The `prove` function generates a valid proof by iterating over multiple retries and ensuring proof construction within a bounded number of steps.
It follows these steps:
- It initializes a step counter to keep track of the total number of DFS calls made throughout the process.
Copy link
Collaborator

Choose a reason for hiding this comment

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

The number of steps is initializedin prove_index

## Creating a Telescope

Constructing an ALBA proof within a **centralized Telescope-bounded DFS setup** requires careful parameter selection to ensure both efficiency and security.
- The **security parameter for adversarial resistance** ($\lambda_{\text{sec}}$) controls how difficult it is for an adversary to forge a valid proof.
Copy link
Collaborator

Choose a reason for hiding this comment

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

Suggested change
- The **security parameter for adversarial resistance** ($\lambda_{\text{sec}}$) controls how difficult it is for an adversary to forge a valid proof.
- The **soundness parameter** ($\lambda_{\text{sec}}$) controls how difficult it is for an adversary to forge a valid proof.

Constructing an ALBA proof within a **centralized Telescope-bounded DFS setup** requires careful parameter selection to ensure both efficiency and security.
- The **security parameter for adversarial resistance** ($\lambda_{\text{sec}}$) controls how difficult it is for an adversary to forge a valid proof.
- A higher $\lambda_{\text{sec}}$ increases the difficulty of false proofs but may require more computational resources.
- The **security parameter for proof reliability** ($\lambda_{\text{rel}}$) determines the probability that an honest prover can generate a valid proof within the given constraints.
Copy link
Collaborator

Choose a reason for hiding this comment

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

Suggested change
- The **security parameter for proof reliability** ($\lambda_{\text{rel}}$) determines the probability that an honest prover can generate a valid proof within the given constraints.
- The **reliability parameter** ($\lambda_{\text{rel}}$) determines the probability that an honest prover can generate a valid proof within the given constraints.

- The **security parameter for adversarial resistance** ($\lambda_{\text{sec}}$) controls how difficult it is for an adversary to forge a valid proof.
- A higher $\lambda_{\text{sec}}$ increases the difficulty of false proofs but may require more computational resources.
- The **security parameter for proof reliability** ($\lambda_{\text{rel}}$) determines the probability that an honest prover can generate a valid proof within the given constraints.
- If $\lambda_{\text{rel}}$ is too low, legitimate proofs may fail, necessitating retries or adjustments in other parameters.
Copy link
Collaborator

Choose a reason for hiding this comment

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

Suggested change
- If $\lambda_{\text{rel}}$ is too low, legitimate proofs may fail, necessitating retries or adjustments in other parameters.
- If $\lambda_{\text{rel}}$ is too low, legitimate proof generation may fail, necessitating retries or adjustments in other parameters.

- The **security parameter for proof reliability** ($\lambda_{\text{rel}}$) determines the probability that an honest prover can generate a valid proof within the given constraints.
- If $\lambda_{\text{rel}}$ is too low, legitimate proofs may fail, necessitating retries or adjustments in other parameters.
- The **DFS bound** is essential for computational feasibility, limiting the number of explored vertices during proof construction.
- A sufficiently high DFS bound ensures a valid proof can be found, while an overly restrictive DFS bound may lead to incomplete proofs.
Copy link
Collaborator

Choose a reason for hiding this comment

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

Suggested change
- A sufficiently high DFS bound ensures a valid proof can be found, while an overly restrictive DFS bound may lead to incomplete proofs.
- A sufficiently high DFS bound ensures a valid proof can be found, while an overly restrictive DFS bound may lead to proof generation failure.

- The [`setup_unsafe`][crate::centralized_telescope::Telescope#method.setup_unsafe] method allows the user to create a `Telescope` manually by directly specifying internal parameters.
- Unlike `create`, this method does **not** verify the consistency or correctness of the provided parameters.
- This gives the user full control but also places the responsibility on them to ensure that the chosen parameters do not compromise security or efficiency.
- The `setup_unsafe` function exists to provide flexibility for advanced users who need custom configurations.
Copy link
Collaborator

Choose a reason for hiding this comment

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

Suggested change
- The `setup_unsafe` function exists to provide flexibility for advanced users who need custom configurations.
- The `setup_unsafe` function exists to provide flexibility for advanced users who need custom configurations or create a `Telescope` object with trusted, already checked, parameters.

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.

Documentation - Centralized Telescope: Proof
2 participants