ed255/pod2
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

docs: add initial docs of Introduction PODs section, with some diagrams (#285)

Browse source
This commit is contained in:
arnaucube 2025-06-13 11:26:12 +02:00 • committed by GitHub
parent 3b4edab1f5
commit f7bb6af219
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
5 changed files with 64 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

63
book/src/introductionpods.md Normal file
View file

@ -0,0 +1,63 @@
# Introduction PODs
Introduction PODs are a kind of POD used to introduce any cryptographic data
structure into the POD system. This allows the POD system to reason about
cryptographic data and cryptographic primitives that are not part of the POD
system itself.
An example of an IntroductionPod are the `Ed25519Pod` and the `EcdsaPod`, both
of them allowing to incorporate their respective kind of signature schemes that
are not supported in the core of the POD system.
This allows to the POD system to incorporate data validated by those
Introduction PODs, and recursively use it in future proofs combining them with
any logical reasoning together with other PODs.
For example, we could have an scenario where we use 3 different Introduction
PODs (Ed25519Pod, RSAPod, EcdsaPod), to prove that a user controls an Ethereum
wallet *AND* a GitHub account. To do so, the user would produce a new `MainPod`
which proves that the user has signed a certain message with the given ECDSA key
(Ethereum wallet) *AND* with either the given Ed25519 key *OR* the RSA key (from
a GitHub account).
<img src="img/introductionpod-mainpod.png" style="max-width:80%;" />
### Interface
The interface of a `IntroductionPod` is just the one of the
[RecursivePod](https://github.com/0xPARC/pod2/tree/3ea0d5be71ce98971305076b220079a1b2b7a8d0/src/middleware/mod.rs#L823)
trait, together with matching the expected `vds_root` of the used `VDSet` in the
`MainPod`, and using the same circuit configuration for the proof verification.
This means that as long as we fit into the `RecursivePod` interface, the
`IntroductionPod` will fit into the recursive verification chain of the
`MainPods`.
### Different configurations
There are some cases, where the operations needed for the `IntroductionPod`
require a different circuit configuration than the standard recursive circuit
configuration that is used for the `MainPods`.
In those cases, we do a previous recursive step, where we verify the logic of
the intended `IntroductionPod`, and then the proof of this circuit is the one
verified in the real `IntroductionPod`.
This is done in order to be able to *converge* the different circuit
configuration shape (and thus different `common_data`) into a new proof that can
be verified with the standard configuration (used for the MainPods).
<img src="img/introductionpod-2-steps.png" style="max-width:80%;" />
Notice that this is not a requirement for implementing a new `IntroductionPod`,
and if the IntroductionPod logic can be directly verified with the standard
recursion configuration, we don't need this previous recursive step.
As examples of the two-recursive steps approach, we have the `EcdsaPod` and the
`Ed25519Pod`. Both of them, require different circuit configurations that would
not match the one used for the standard recursion with `MainPods`. Therefore we
first generate a circuit proof of correct signature verification, and then this
proof is the one actually verified in the `EcdsaPod`/`Ed25519Pod` respectively,
not the original signature itself.
<img src="img/introductionpod-2-steps-ecdsa-example.png" style="max-width:80%;" />
> Examples of `IntroductionPods` can be found at the git repository
> [github.com/0xPARC/introduction-pods](https://github.com/0xPARC/introduction-pods/).