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

add preliminary apk-proofs spec #625

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from
Draft

Conversation

drskalman
Copy link
Contributor

This is a mainly a draft but I needed some proper way of compling the latex stuff to make sure they are correct, so I added it to the spec so I can compile the math.

@drskalman drskalman self-assigned this Feb 22, 2023
@drskalman drskalman marked this pull request as draft February 22, 2023 17:10

[#sect-grandpa-apk-proof]
=== Ultralight Finality Proof
A plokadot APK prover node is responsible to generate succinct proof for aggregated validator public keys who has signed a particular BEEFY message in form of a SNARK.

Choose a reason for hiding this comment

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

APK = aggregate public key

Copy link
Contributor

@0xCaso 0xCaso left a comment

Choose a reason for hiding this comment

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

Misspells


[#sect-grandpa-apk-proof]
=== Ultralight Finality Proof
A plokadot APK prover node is responsible to generate succinct proof for aggregated validator public keys who has signed a particular BEEFY message in form of a SNARK.
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
A plokadot APK prover node is responsible to generate succinct proof for aggregated validator public keys who has signed a particular BEEFY message in form of a SNARK.
A Polkadot APK prover node is responsible to generate succinct proof for aggregated validator public keys who has signed a particular BEEFY message in form of a SNARK.


In light client protocols, such commitment is used to commit to the
upcoming validator set, signed by the current validator set. Honest
validator should check the proofs of possession of each public key
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
validator should check the proofs of possession of each public key
validators should check the proofs of possession of each public key

===== Prover

Prover is responsible to generate APK proofs. The `Prover` struct
encapsultes this task. It contains the following fields:
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
encapsultes this task. It contains the following fields:
encapsulates this task. It contains the following fields:

encapsultes this task. It contains the following fields:

* `Domains`: ???
* `Keyset`: set of all committe public keys (?)
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
* `Keyset`: set of all committe public keys (?)
* `Keyset`: set of all committee public keys (?)

APK proofs are SNARK based proof protocols to enable verification of
aggregated BLS signatures without the knowledge of individual public
keys of all the signers. APK proofs uses its own custom SNARK. The
protocol is implemented in two flavours: link:#BW6[BW6] and
Copy link
Contributor

@0xCaso 0xCaso Mar 2, 2023

Choose a reason for hiding this comment

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

just for the checks, technically both terms are correct ;)

Suggested change
protocol is implemented in two flavours: link:#BW6[BW6] and
protocol is implemented in two flavors: link:#BW6[BW6] and

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.

3 participants