cedoor.dev

GRECO in a nutshell

Fri, 05 Dec 2025 00:00:00 GMT

Special thanks to Giacomo Corrias, Enrico Bottazzi, Auryn Macmillan, Younes Talibi Alaoui and Marv for feedback and discussions.

Interest in Fully Homomorphic Encryption (FHE) has been growing rapidly, and with it, more mature applications are emerging that combine it with zero-knowledge proofs (ZKPs) or multi-party computation (MPC). These hybrid systems unlock powerful new use cases, but they also bring fresh challenges that require clever cryptographic engineering.

Imagine that a major city has 6 large-scale hospitals. In order to predict and rapidly respond to emergent epidemics, the hospitals would like to know the aggregate number of patients treated for a variety of common contagions each week. However, for competitive reasons, the hospitals do not wish to divulge their individual numbers with one another.

Using a threshold FHE scheme, each of the hospitals can encrypt their numbers to a key controlled by a committee trusted by the group of hospitals, such that they have strong guarantees that only the aggregate output will be decrypted.

But if the program can’t see the inputs, how can it validate that the inputs are correct?

That’s where GRECO (1), a zero-knowledge proof of correct encryption, comes in. It lets anyone verify that a ciphertext is correctly encrypted under the right FHE key without revealing the plaintext. Together with the application-level checks, GRECO guarantees that the plaintext satisfies the required validity constraints (for example, being within the allowed domain or matching the expected structure) and that it is encrypted with the correct FHE key.

In practice, constructions like GRECO become an essential integrity check whenever multiple parties contribute encrypted inputs to a shared computation (cheating as a single party would only wreck their own results). Systems such as Enclave, which execute confidential multi-party computation across untrusted participants, rely on mechanisms like GRECO to ensure that each encrypted input is both valid and correctly bound to the value being proven.

Let’s unpack how GRECO works.

Under the Hood

In this article, like in the original paper, we will focus on BFV and SNARKs, assuming the reader already has a basic grasp of both. You don’t need to know all the math, just the core ideas. For anyone interested in going deeper, see this great article on FHE by Jeremy Kun and this other article on SNARKs by Vitalik Buterin.

Rather than inventing new primitives, GRECO extends ideas from FHE and ZKPs, relying on the Residue Number System (RNS) and optimized polynomial evaluation to make the math line up properly.

What to Prove

Before diving deeper, we first need to understand what we actually want to prove in zero knowledge: the equation that convinces the verifier that a ciphertext is the result of the correct encryption of a plaintext. To do that, let’s recall how encryption works in BFV.

Given a public key $pk = (p_0, p_1)$ and a plaintext $m$ , the ciphertext $(c_0, c_1)$ is computed as:

\begin{aligned} u &\leftarrow R_2, \quad e_1, e_2 \leftarrow \chi \\ c_0 &= pk_0 \cdot u + e_1 + \Delta \cdot m \\ c_1 &= pk_1 \cdot u + e_2 \end{aligned}

Here $u$ is a random binary polynomial, $e_1$ and $e_2$ are error terms sampled from a noise distribution $\chi$ , and $\Delta = \lfloor q / t \rfloor$ is a scaling factor that maps the plaintext space $t$ into the ciphertext modulus $q$ .

This simple pair of equations hides a lot of cryptographic machinery, but for now all we need to remember is that the ciphertext is a noisy linear combination of the public key and the plaintext, carefully balanced so that only the secret key can recover $m$ . Solving a linear combination is easy, but once you add noise, the problem becomes NP-hard, forming the basis of the Learning With Errors (LWE) assumption that modern lattice cryptography relies on.

In our zero knowledge setting, the ciphertext $(c_0, c_1)$ and the public key $(p_0, p_1)$ will act as public inputs to the proof, while the plaintext and the noise terms $(u, e_1, e_2)$ remain private witnesses.

The ultimate goal of the proof is to convince the verifier that these public values satisfy the encryption equation above, meaning the ciphertext was generated with the right public key.

Challenges

If you’ve seen RLWE before, you already know that these polynomials live in a ring modulo both $q$ and $X^N + 1$ . In simple terms, $q$ keeps the coefficients bounded, meaning every number wraps around once it reaches $q$ , while $X^N + 1$ keeps the degree bounded, making polynomial multiplication wrap neatly back on itself. Together, they form the space $R_q = Z_q[X] / (X^N + 1)$ .

Now, there are two main challenges that make proving this equation inside a ZK circuit tricky:

Depending on the configuration, $q$ can be much larger than $p$ (the modulus defining the SNARK field).
On top of that, solving this equation directly with $R_q$ and all the operations would be far too expensive in a zero knowledge context.

This is exactly where GRECO steps in. It introduces a way to express the ciphertext–plaintext relationship without having to reproduce all the complex arithmetic that happens over the $q$ -modulus ring inside the proof system. In other words, GRECO bridges the world of FHE (which lives in $R_q$ ) with that of SNARKs (which operate in a field modulo $p$ ), keeping the proof lightweight while preserving full correctness.

Splitting the Modulus with RNS

The solution to keep the modulus $q$ from exceeding $p$ comes from a technique already used in many RLWE-based schemes: the Residue Number System (RNS), which is built on the Chinese Remainder Theorem (CRT).

In short, instead of working with one large modulus $q$ , we split it into several smaller moduli $q_i$ . This allows the arithmetic to stay within manageable ranges while preserving the exact same mathematical meaning.

Each polynomial of the equation is represented under this multi-modulus form, meaning every coefficient exists as a set of residues $(c^{(1)}, c^{(2)}, …, c^{(k)})$ corresponding to the smaller moduli. This decomposition makes it possible to handle those polynomials inside a SNARK circuit, since each $q_i$ can fit comfortably within the field defined by $p$ .

To get a feel for it, imagine $q = 105$ and $p = 13$ . Instead of working directly modulo 105, we can split it into smaller coprime moduli: $q_1 = 3$ , $q_2 = 5$ , and $q_3 = 7$ , all of them < $p$ (in GRECO we actually require $q_i \ll p$ , meaning each CRT limb is much smaller than the ZK field modulus $p$ ).

If a coefficient is $x = 23$ , we can represent it as its residues:

\begin{aligned} x_1 = 23 \bmod 3 = 2, \\ \quad x_2 = 23 \bmod 5 = 3, \\ \quad x_3 = 23 \bmod 7 = 2 \ \end{aligned}

So $x$ becomes the triple $(2, 3, 2)$ .

Let’s say we have another polynomial’s coefficient $y = 52$ and its triple $(1, 2, 3)$ . We can add them component-wise in RNS form:

(x + y) \bmod q_i = (x_1 + y_1, ; x_2 + y_2, ; x_3 + y_3) \bmod (3, 5, 7)

which gives:

(2 + 1 \bmod 3, 3 + 2 \bmod 5, 2 + 3 \bmod 7) = (0, 0, 5)

So the RNS result is $(0, 0, 5)$ . And if we reconstruct it back using the Chinese Remainder Theorem, we get:

z = 23 + 52 = 75 \bmod 105 = 75

and indeed, $(0, 0, 5)$ corresponds to $75$ in the original modulus $q = 105$ , since it’s the only number below $105$ that gives those exact residues modulo $(3, 5, 7)$ . In fact:

\begin{aligned} z_1 = 75 \bmod 3 = 0, \\ \quad z_2 = 75 \bmod 5 = 0, \\ \quad z_3 = 75 \bmod 7 = 5 \ \end{aligned}

Now, the same idea applies to the coefficients of our polynomials:

\begin{aligned} c_{0,q_i} &= pk_{0,q_i} \cdot u + e_1 + k_{q_i} \\ c_{1,q_i} &= pk_{1,q_i} \cdot u + e_2 \pmod{q_i} \end{aligned}

where $k = \Delta \cdot m = \lfloor q / t \rfloor \cdot m$ . However, as described in section 3.1 of (2), a more accurate encoding is $k = \Big\lfloor \frac{q \cdot m}{t} \Big\rfloor$ . Given that $q$ and $t$ are coprime, $k$ can be computed directly in the RNS basis as:

k_{q_i} = -t^{-1} [q \cdot m]_t \pmod {q_i}

However, this still isn’t enough. Even after splitting $q$ into smaller moduli, directly solving such equations inside a ZK circuit would be extremely costly. Let’s see how we can fix that.

Scaling Down the Math

Working within $R_q$

After applying the RNS decomposition and splitting the polynomials across the moduli $q_i$ , our equations still live in the ring $Z_{q_i}[X]/(X^N + 1)$ . And this ring structure introduces operations that are non-native to the prime field of the SNARK circuit, meaning they cannot be expressed directly without additional huge cost.

The main trick used to handle this efficiently is to embed the modular reduction inside the polynomial definition itself. Instead of performing explicit reductions inside the circuit, GRECO rewrites each operation so that the reduction is already “baked in.”

For example, a standard modular reduction $y = z \bmod n$ can be expressed as:

y = z - q \cdot n

where $q$ is the quotient obtained during division by $n$ . And since $q$ can be precomputed outside the circuit, the constraint becomes much cheaper.

Now, given that we can consider two modules in our case, specifically $q_i$ and $X^N + 1$ , let’s denote $r_1$ and $r_2$ for $c_0$ , and $p_1$ and $p_2$ for $c_1$ as the reduction factors to be incorporated into our equation as follows:

\begin{aligned} c_{0,q_i} &= pk_{0,q_i} \cdot u + e_1 + k_i + r_{2, i} \cdot (X^N + 1) + r_{1, i} \cdot q_i \pmod{Z_p} \\ c_{1,q_i} &= pk_{1,q_i} \cdot u + e_2 + p_{2, i} \cdot (X^N + 1) + p_{1, i} \cdot q_i \pmod{Z_p} \end{aligned}

where $\pmod {Z_p}$ is the new modulo $p$ in ZK.

Evaluation

Last but not least, we want to avoid multiplications between high-degree polynomials, which would necessarily require $(n + 1)^2$ multiplication constraints and $n^2$ addition constraints (see Appendix B of the paper (1) for more details).

To address this, GRECO relies on a technique known as the Schwartz–Zippel lemma (3,4), which states that two distinct polynomials $f(x)$ and $g(x)$ over a large field are extremely unlikely to be equal when evaluated at a randomly chosen point, meaning that if two polynomials do coincide, it is overwhelmingly likely that they are the same polynomial.

For example, suppose we have:

\begin{aligned} f(x) &= c_0(x) \\ g(x) &= pk_0(x) \cdot u(x) + e_1(x) + k(x) \end{aligned}

If we check that $f(\gamma) = g(\gamma)$ for a random point $\gamma$ , the Schwartz–Zippel lemma tells us that, with overwhelming probability, this implies $f = g$ , meaning the ciphertext relation holds without needing to calculate complex polynomial operations.

What we need to do, then, is simply evaluate all polynomials at the point $\gamma$ .

A straightforward way to do this is by using Horner’s method (5), a simple and efficient algorithm for polynomial evaluation. Instead of computing every power of $\gamma$ separately, Horner’s method rewrites the polynomial so it can be evaluated with just a few multiplications:

For example,

f(x) = a_3x^3 + a_2x^2 + a_1x + a_0

can be rewritten as:

f(x) = ((a_3x + a_2)x + a_1)x + a_0

This lets us compute $f(\gamma)$ step by step with multiplications and additions without ever calculating $\gamma^2$ , $\gamma^3$ , and so on, which is perfectly suited for circuits where every multiplication counts.

Now, how do we find a random value $\gamma$ ? We use the Fiat–Shamir heuristic (6), which replaces the verifier’s random challenge with a deterministic one derived from a hash. In practice, $\gamma$ is computed by hashing all relevant data in our equation above, ensuring that $\gamma$ is both unpredictable and uniquely tied to the specific proof instance.

In summary, the evaluation step compresses the polynomial relation into a single equality check at a random point $\gamma$ . Schwartz–Zippel lemma guarantees soundness, Horner’s method keeps multiplications cheap, and Fiat–Shamir ties $\gamma$ securely to the proof instance.

Putting It All Together

Back to the example: each hospital encrypts its weekly case count under the shared FHE key and proves in zero-knowledge that the number is valid and in range. GRECO ties the two together by ensuring that the ciphertext really contains the same value that appears in the proof.

GRECO doesn’t define what “valid” means, that’s the job of the application (range checks, format checks, consistency rules, and so on). What GRECO ensures is that whatever you prove about the plaintext is actually tied to the FHE ciphertext that enters the joint computation.

It achieves this by combining a few elegant ideas:

RNS decomposition to split large ciphertext moduli into smaller, circuit-friendly parts.
Embedded reductions that keep operations compatible with the SNARK field.
Evaluation at a random point using the Schwartz–Zippel lemma and Fiat–Shamir heuristic to replace full polynomial checks with a single equality test.

The result is a lightweight, reusable component that connects ciphertexts and ZK proofs cleanly, and that can be plugged into many different FHE-based systems.

This post is part of the new Enclave Cryptography series.

References

Bottazzi E. Greco: Fast Zero-Knowledge Proofs for Valid FHE RLWE Ciphertexts Formation [Internet]. 2024. Available from: https://eprint.iacr.org/2024/594

Kim A, Polyakov Y, Zucca V. Revisiting Homomorphic Encryption Schemes for Finite Fields. In: Advances in Cryptology – ASIACRYPT 2021 [Internet]. 2021. Available from: https://doi.org/10.1007/978-3-030-92078-4_21

Schwartz JT. Fast Probabilistic Algorithms for Verification of Polynomial Identities. Journal of the ACM [Internet]. 1980;27(4):701–17. Available from: https://doi.org/10.1145/322217.322225

Zippel R. Probabilistic Algorithms for Sparse Polynomials. In: Symbolic and Algebraic Computation (EUROSAM 1979) [Internet]. 1979. p. 216–26. (Lecture Notes in Computer Science; vol. 72). Available from: https://doi.org/10.1007/3-540-09519-5_73

Smoryński C. Horner’s Method. In: History of Mathematics: A Supplement [Internet]. Springer; 2008. p. 175–224. Available from: https://doi.org/10.1007/978-0-387-75481-9_7

Fiat A, Shamir A. How to Prove Yourself: Practical Solutions to Identification and Signature Problems. In: Advances in Cryptology – CRYPTO 1986 [Internet]. 1986. p. 186–94. (Lecture Notes in Computer Science; vol. 263). Available from: https://doi.org/10.1007/3-540-47721-7_12

The Wonderful Story of Amerigo Dumini

Sat, 19 Apr 2025 00:00:00 GMT

The following story is not something I invented. It is just the (very funny) story of a man who actually existed during the fascist era, someone who might be the perfect representation of a (substantial?) part of my country. I first heard about him in a lecture by Barbero, in which the professor masterfully tells the events surrounding the murder of Matteotti

Amerigo Dumini, the man who heroically took full responsibility for the murder of Giacomo Matteotti in 1924. The Fascist Party applauded his “noble sacrifice” with praise and he became the perfect scapegoat to wash Mussolini’s hands clean.

Convicted of involuntary manslaughter (yes, somehow involuntary), he walked out of prison in 1925 almost before the ink was dry on the sentence. Reward? A mountain of cash and a cozy monthly pension of 5,000 lire. Not bad for a murder.

But Amerigo wasn’t satisfied. He started shopping around his memoirs to an American publisher and whispering that while he got 5 years (never served), Mussolini deserved 30! Oops, arrested again. This time for illegal possession of a firearm. One year and two months. But no worries, the King (yes, the King too) pardoned him.

Off he went to Somalia, where he was arrested again and sent into exile. From there, he wrote to General De Bono, hinting that his memoir contained “certain compromising details.” Magically, he was freed and sent to Libya, where state contracts and money poured in. A true entrepreneur of silence.

Then WWII broke out. The British invaded. Dumini, staying behind, was mistaken for a spy and sentenced to death. He survived 17 gunshots (seventeen!). Like a fascist Rasputin, he escaped, returned to Italy, and was welcomed back as a hero.

In 1947, post-fascism, the republic gave the Matteotti case another look. Life sentence for his murders? No problem. Thanks to Togliatti’s amnesty, it became 30 years. And thanks to Pella’s amnesty in 1953, he was free after only 6 years! Then jailed again when the pardon was revoked. And then freed again in 1956 (wtf??).

Amerigo Dumini finally died in 1967 at age 73, not from bullets, trials, or exile, but from tripping in his house while playing with his dog.

For anyone interested… Unlike Germany, Italy never had its own Nuremberg Trials. In Italy, the fascists simply claimed they were no longer fascists and went on to hold new government positions (not all of them but too many).

Dal paese del Barocco al paese dei balocchi è un attimo (it doesn’t work very well in English).

From silos to synergy

Mon, 20 Jan 2025 00:00:00 GMT

Special thanks to Giacomo Corrias, Andy Guzman, Zoey, Ki Chong Tran, Vivian Plasencia and others for help and discussions.

Takeaways

Challenges: The main obstacles for privacy protocols are interoperability, lack of standards, and developer accessibility.
Emerging solutions: POD2 and SelfAttestHub offer different approaches to address these issues, with POD2 focusing on general-purpose cryptography and SelfAttestHub on identity and verifiable credentials.
Goals: Both solutions aim to make protocols more modular, composable, and interoperable.
Potential synergies: While distinct, POD2 and SelfAttestHub could complement each other in privacy-driven ecosystems.

Over the past few months, I’ve explored digital identity, learning from experts, understanding key challenges, and evaluating privacy technologies in current systems. The lack of interoperability, standards, documentation, and developer tools appears to be the main obstacle hindering the adoption of privacy-focused technologies. This is especially true for protocols that fall under what 0xPARC calls “Programmable Cryptography” (1), namely those protocols that mark a shift from specialized cryptographic systems, like public-key encryption and digital signatures, to more general-purpose ones. These include zkSNARKs, MPC, FHE, Witness Encryption, and Obfuscation.

That said, it was reassuring to see that many people and organizations are actually already actively working to overcome these challenges. Efforts range from promoting the adoption of specifications to creating comprehensive documentation, improving the developer experience, and establishing format standards. Most importantly, there is a gradual but essential process of abstraction underway, which aims to make these protocols accessible to a broader audience without any background in cryptography, while also enabling a paradigm shift in how we approach them. Instead of treating them as isolated tools, abstraction allows us to think of them as interoperable components that can be combined to create more powerful, multi-faceted privacy solutions.

This article aims to clarify the topic by exploring two recently emerged solutions that have notable similarities but also important differences. While they might seem like alternatives, they could actually complement each other: POD2 by 0xPARC and SelfAttestHub by PSE.

But before moving forward, let’s go back to the origins and examine the challenges that inspired these solutions.

From concept to reality

If we were to identify a common thread running through all the issues, it would likely be the challenge of making a real-world impact. At its core, this means bridging the gap between “Programmable Cryptography” protocols and the mainstream digital ecosystem, that is the everyday apps people actually use. But this isn’t a sudden realization that emerged in recent months, but rather a growing awareness that has developed over the years, driven by the gradual maturation of development tools made possible through the combined efforts of individual contributors and teams.

The origins of these protocols go back around 40 years, to when Micali, Yao and co published the first research on zero-knowledge proofs (2) and multi-party computation (3). For a long time, these ideas stayed in the world of theory, understood only by a small circle of researchers. Things started to change when a few bold developers decided to turn theory into practice, creating domain-specific languages (DSLs) like Circom and other tools, which in turn paved the way for a range of protocols built on top of them.

Over the past five years, various teams, working more or less independently, have then focused on implementing new protocols. Their efforts have gradually improved the developer experience, enhanced documentation, and expanded both the range of use cases and the community of developers involved (4).

However, it’s still not enough to reach critical mass and make these technologies mainstream. We’re still just getting started. So, what are the challenges we face today?

Understanding the core challenges

We need to move forward on three fronts in parallel: developer experience, interoperability and adoption.

Developer experience

Developers, developers, developers! A lot has been achieved, but we still need more cryptography developers to make existing tools even simpler for the broader developer community, especially in mobile and web environments. We need greater abstraction, hiding unnecessary complexity, and making cryptography accessible to everyone, not just a small niche of enthusiasts and experts.

I’ve personally spent the past few years working on this through Semaphore, and I still believe it’s absolutely essential.

Interoperability

Although we’re starting to see some progress, most projects continue to operate in silos, within an environment that remains too fragmented, lacking both coordination and a clear overarching vision.

What we need is composability, along with meta-protocols and infrastructures built around modular components, drawing inspiration from a well-known success story: Ethereum, with its smart contracts and EIPs.

We also need a streamlined system of specifications and standards. The work done by ZK-ID by PSE (5), from which SelfAttestHub was born, has made it clear that the lack of standards and coordination is the main reason why not only ZK protocols but the entire digital identity space remains highly fragmented today.

Adoption

We need to experiment and build real-world applications, gather feedback from developers and people with diverse backgrounds, and showcase how these protocols can be applied through practical examples, education, and outreach. Projects like Cursive and Zupass are great examples of how to move forward.

Last but not least, we must closely monitor the progress of governments and institutions in the field of digital identity. It’s essential to advocate for the use of privacy-focused technologies and ensure that the protocols we develop are compatible with the standards that will ultimately be adopted. We cannot predict whether the future will revolve around W3C standards, X.509 certificates, or an entirely new paradigm. What we do know is that we must be prepared to support it, no matter what form it takes.

PODs

To describe POD2, it’s essential to first define the concept of a POD as envisioned by 0xPARC and understand its first implementation, POD1.

A POD is defined as a standard for cryptographic data and enables secure data storage and sharing with integrity guarantees, supporting a more interoperable and privacy-preserving internet. Users can share verifiable, unaltered data, with cryptographic operations allowing redaction, transformation, and aggregation while preserving end-to-end verifiability.

To a user, a POD is a piece of cryptographic data attested by some issuing authority. A POD can serve as proof of event attendance, a secure message, a collectible badge, or even an item in a role-playing game. For a developer, a POD object is a key-value store that can hold any signed data.

POD1

POD1 is the first implementation of this concept, and it can in this case be described in detail since it was successfully used at the last Devcon in Bangkok in November 2024. If you attended Devcon, you likely scanned a QR code for your ticket using the Zupass app and may have collected crypto frogs. All of these were PODs.

When a POD1 is issued, its entries (key-value pairs) are hashed as part of a Merkle tree, precisely a LeanIMT. The root of that tree is signed by the issuer, and the so-called GPC (General Purpose Circuits) allows developers to generate zero-knowledge proofs from a simple proof configuration (i.e. a human-readable JSON format). GPCs can then prove properties of one POD or several PODs together. Additionally, PODs can be proven to be owned by the prover using a Semaphore identity.

POD2

POD2 is the natural evolution of POD1, addressing three key limitations of the original version:

Need for issuer alignment: POD1 requires data attesters to change the way they issue data. Specifically, credential issuers must adopt the POD1 infrastructure and its technologies (e.g. EdDSA with BabyJubjub). This dependency limits adoption, interoperability, and scalability.
Single-round computation: POD1 is constrained to a single round of computation. Once a proof is generated using GPC, the output cannot be used as input for further computations. In other words, it is not possible to chain PODs together, as each operates in isolation.
Limited multi-party computation: POD1 does not support use cases where multiple parties want to collaborate in generating proofs while keeping their respective inputs private. This limitation prevents more advanced privacy-preserving multi-party workflows.

The solution proposed in POD2 shifts the approach from handling data issuance and signing within its system to enabling the import of any externally issued cryptographic data. This data is then converted into a format compatible with the POD ecosystem through a specialized component known as the “Introduction Gadget.”

For example, imagine a crypto frog generated at Devcon — essentially, a zero-knowledge Groth16 proof created using GPC and POD1. Through the Introduction Gadget, this proof is transformed into a POD2-compatible proof, meaning it now adheres to a proving system that can be fully integrated within the POD2 ecosystem.

In addition, POD2 introduces new cryptographic primitives, like recursive proofs and MPC (Multi-Party Computation), or potentially FHE (Fully Homomorphic Encryption). This evolution allows for composable proofs, where the output of one POD can serve as the input for another. And each POD can receive multiple inputs from different parties, enabling the creation of verifiable and interoperable computational graphs.

This composability clearly unlocks a world of possibilities for more complex workflows and seamless cross-party interactions within the POD2 ecosystem.

]

Building on the foundation established with GPC in POD1, which aims to abstract the complexity of writing zero-knowledge circuits, POD2 also introduces a new paradigm called the “zk Logic Virtual Machine” (zk-LVM). This approach shifts the underlying concept of zkVMs from “circuits proving the state transition of a CPU architecture” (CPU model) to “circuits proving the correctness of logical operations on statements” (Logic model).

The core idea is to let developers write circuits using a predefined set of logical statements like ValueOf, Equal, NotEqual, and GreaterThan within a specialized logic programming language (like LISP), eliminating the need to deal with the low-level complexity of circuit design.

The concepts behind POD2 are still being explored, but the vision is clear. It aims to create a composable system that leverages new cryptographic primitives and technologies to import the vast array of real-world data into an ecosystem where advanced computations on encrypted data can be performed. At the same time, it seeks to provide developers with intuitive, easy-to-use development tools, significantly lowering the barrier to entry for building privacy-preserving applications.

If you want to dive deeper into PODs, I highly recommend checking out these resources from the 0xPARC website and Devcon in Bangkok:

Programmable Cryptography (Part 1): https://0xparc.org/blog/programmable-cryptography-1
POD1 workshop: https://www.youtube.com/watch?v=gWoVrIO1tIE
POD2 workshop: https://www.youtube.com/watch?v=5C8SovQZnqY
POD2 talk: https://www.youtube.com/watch?v=Qob-AsX0mxY&t=795s

SelfAttestHub

While SelfAttestHub (6) is built on principles similar to POD, it emerges from ZK-ID’s research in digital identity and the alignment of some PSE projects. By identifying key challenges in the Self-Sovereign Identity (SSI) space, the team proposed a solution that enables PSE’s data provenance projects (e.g. AnonAadhaar, OpenPassport, TLSNotary, ZKEmail) to coexist within an on-chain infrastructure while maintaining full compatibility with the VCs/DIDs standards ecosystem. The core objective is to provide a shared interface, ensuring that PSE proofs can be seamlessly consumed and utilized by identity providers in real-world applications.

A key aspect of this infrastructure is the use of blockchain as a Verifiable Data Registry (VDR), which is crucial for SSI. It provides a decentralized, tamper-proof trust layer that enables users to control their identities through Decentralized Identifiers (DIDs), anchor cryptographic proofs, and manage revocation registries in a secure, transparent, and privacy-preserving manner.

Iden3-inspired approach

Building on this foundation, SelfAttestHub’s approach, inspired by Iden3, shifts proof verification to smart contracts. Users generate identity proofs client-side and submit them to smart contracts, which act as decentralized issuers. These contracts verify the proof and add users to on-chain groups, allowing verifiers to check membership status without re-verifying the original proofs. The verification process is managed through a unique verifier contract, streamlining proof validation and ensuring a unified, consistent approach to verification across different groups and use cases.

To enable selective disclosure, SelfAttestHub uses a two-level Merkle tree structure:

Identity tree: Represents a user’s identity attributes. The attributes (like birthdate, gender, and address) are stored off-chain as a Verifiable Credential (VC) in plain text. These attributes are hashed into a Merkle tree, with the Merkle root serving as part of the identity commitment added to the on-chain claim tree.
Claim tree: An on-chain tree whose leaves are identity tree roots. Users can add their identity tree roots using provenance proofs (like AnonAadhaar) and later generate proofs of membership on behalf of them. This on-chain Merkle tree allows verifiers to check a user’s membership status within a specific claim tree.

When a verifier requests specific attributes, the user generates an identity proof with the corresponding Merkle proof for the requested attribute. This is shared as a Verifiable Presentation, allowing the verifier to check if the user’s identity root matches the one previously committed on-chain, ensuring privacy and data integrity.

Building the ultimate PSE modular infrastructure

Alongside the progress made by the ZK-ID team, several teams within PSE also started exploring ways to integrate multiple PSE projects beyond the context of SSI and W3C standards. An example of this is Sinu’s proposal (7) to bootstrap private Identity Sets (i.e., Semaphore groups) using TLSNotary.

This vision of connecting multiple protocols within a modular, shared infrastructure, rather than maintaining isolated and non-interoperable projects, clearly aligns with the approach of SelfAttestHub. In fact, SelfAttestHub itself could potentially be built entirely using PSE protocols. For example, one promising approach is to use Semaphore groups (LeanIMT) instead of Iden3’s Sparse Merkle Trees for the claim tree, and leverage POD1 for the identity tree.

The main challenge would undoubtedly be to preserve essential SSI properties such as selective disclosure, recovery, and revocation. However, let’s assume these issues can be addressed with a PSE-driven solution. With this in mind, let’s engage in a experiment to conceptually design this solution:

Excubiae can serve as the entry point for accessing Semaphore groups. In this architecture, gatekeepers act as components that import external cryptographic data. This approach establishes a controlled entry mechanism, ensuring that only users with valid external data can gain access to the relevant Semaphore groups.
Semaphore can function as a Verifiable Data Registry (VDR) for credentials. Once users are admitted into groups through the gatekeepers, they can anonymously prove their membership in a group. This, in effect, allows them to demonstrate possession of the credentials that the group represents. By doing so, Semaphore enables efficient provability of external cryptographic data within an interoperable on-chain ecosystem, all under a single verifier.
TLSNotary, ZKEmail, AnonAadhaar, and other data provenance protocols can be utilized either individually or in combination to construct gatekeepers. These gatekeepers can bootstrap various Semaphore groups, offering multiple pathways for users to prove their credentials. This modular approach enhances flexibility, allowing for different data sources to contribute to the creation of anonymity sets while maintaining privacy-preserving principles.
As mentioned above, POD1 could be used to enable selective disclosure by following a flow similar to the one described above with the identity tree.

An interesting feature is that once gatekeepers are established to grant access to Semaphore groups, those same groups can then be used in combination to create new gatekeepers.

Imagine a user utilizes AnonAadhaar to join a Semaphore group representing Indian citizens over the age of 18. Later, the user also joins a second Semaphore group that represents individuals who have a valid driver’s license. By combining the proof of membership from both of these groups, the user can gain access to a new group that represents “Indian citizens over 18 with a valid driver’s license.” Instead of having to prove both credentials separately, the user only needs to provide proof of membership in this new combined group, effectively demonstrating possession of both credentials in a single step.

In a way, it’s similar to recursive proofs. The proof generated from one Semaphore group can serve as an input (or condition) to join another Semaphore group, and this process can be repeated iteratively, enabling the creation of increasingly complex credential compositions.

]

At this point, some clear similarities with POD2 begin to emerge, which will be described below.

For a deeper understanding of the ideas behind this solution, I recommend reading the following articles:

ZK-ID - Retrospective: https://pse-team.notion.site/ZK-ID-Retrospective-10ed57e8dd7e80258146ce4bcef0ee16#10ed57e8dd7e80b884e3df91727b37d4
SelfAttestHub: A Port From ProgCrypto to Verifiable Credentials: https://hackmd.io/@wFJY6cGcRfmvPHiQ5VYP6w/BJjh3X2JJl
Bootstrapping Private Identity Sets: https://hackmd.io/@sinuio/Byo7xxhZC

Commonalities and Differences

As highlighted in the previous sections, SelfAttestHub and POD2 are two distinct solutions with notable similarities and differences, yet they have the potential to be complementary. Both aim to tackle key challenges related to interoperability and composability, but while they share a common goal of enabling seamless workflows, they diverge significantly in their design choices and probably target use cases.

Key similarities

Data Importation: Both solutions aim to create a system for importing external data into a composable ecosystem.
Bridging Components: Each solution has a component that serves as a bridge between external cryptographic data and the internal ecosystem — Excubiae Gatekeepers in SelfAttestHub and Introduction Gadgets in POD2.
Universal Proof Verification: Once the data is imported, all proofs within the ecosystem can be verified through a single, universal verifier.

Major differences

Blockchain Dependency: POD2 is not inherently tied to the blockchain and can function as a standalone system. In contrast, SelfAttestHub relies on the blockchain to provide a decentralized and tamper-proof infrastructure.
Use of Decentralized Identity (DID) and Verifiable Credentials (VCs): Both solutions can be extended with an additional layer to support standards like DIDs and VCs. However, within Self-Sovereign Identity (SSI), a Verifiable Data Registry (VDR) is essential, and SelfAttestHub is natively built on a ledger, whereas POD2 operates independently of one.
Composability Mechanisms: POD2 achieves composability through recursive proofs, while SelfAttestHub achieves it through Semaphore groups.
Privacy and Anonymity: SelfAttestHub introduces anonymity sets, which provide or make it easier to provide useful privacy properties such as unlinkability, revocation, recovery, identity management. These properties are not guaranteed by POD2 by default.

Conclusions

The convergence of programmable cryptography and self-sovereign identity (SSI) highlights shared challenges like interoperability, standardization, and developer accessibility. POD2 and SelfAttestHub might present two distinct yet complementary approaches. POD2 focuses on a composable, general-purpose cryptographic system, while SelfAttestHub offers an on-chain infrastructure for privacy-preserving identity systems. Both solutions aim to abstract complexity, foster interoperability, and increase accessibility for developers and users.

By aligning these efforts, the privacy-tech ecosystem can accelerate adoption, unlock composability, and enable a new generation of modular, privacy-preserving applications.

References

Gubsheep. Programmable Cryptography (Part 1) [Internet]. 2024. Available from: https://0xparc.org/blog/programmable-cryptography-1

Micali S, Goldwasser S, Rackoff C. The Knowledge Complexity of Interactive Proof-System [Internet]. 1989. Available from: https://doi.org/10.1145/22145.22178

Yao AC. Protocols for secure computations [Internet]. 1982. Available from: https://doi.org/10.1109/SFCS.1982.38

developerreport.com. Crypto Developer Report [Internet]. 2024. Available from: https://www.developerreport.com/developer-report?s=2054-monthly-active-developers-support-zero-knowledge-zk-ecosystems

Cedoor. ZK-ID Retrospective [Internet]. 2024. Available from: https://pse-team.notion.site/ZK-ID-Retrospective-10ed57e8dd7e80258146ce4bcef0ee16

Meziane Y. SelfAttestHub: A Port From ProgCrypto to Verifiable Credentials [Internet]. 2024. Available from: https://hackmd.io/@meyanis/BJjh3X2JJl

Sinu. Bootstrapping Private Identity Sets [Internet]. 2024. Available from: https://hackmd.io/@sinuio/Byo7xxhZC

Financial awareness

Sat, 06 Jan 2024 00:00:00 GMT

Another year has begun, bringing with it a wave of good intentions. Honestly, I am a little skeptical about the effectiveness of this kind of motivational boost people feel at the beginning of the year, which tends to be fueled more by false hopes than realistic goals. However, I do believe that the start of a year is a great time for reflection. It’s a moment to look back at what has happened and think about what the future might hold.

One goal I want to set for myself this year, which I didn’t get around to last year, is creating a long-term investment plan. A plan where I will surely need to understand where I see myself in the future, what I hope to achieve, and my personal philosophy on money. But more importantly, I want this journey to be guided by a fundamental conviction I have: what really matters is the freedom to forge my own path in life, without depending too much on other people (or things). In other words: financial independence.

Let me be clear: it’s not that I feel particularly chained to an unwanted life, quite the contrary. But having a solid financial foundation in the future will undoubtedly continue to secure my freedom and open up more opportunities.

Well, well… That’s not so different from what most people desire, my friend. Are you implying that you want to be rich?

I don’t believe that being rich is necessarily the solution, and I don’t think that only rich people can have financial independence. However, whether we like it or not, money is very important, and the way we relate to it and manage it can significantly impact our lives (1).

While my relationship with money has evolved, my general attitude toward it has remained largely consistent. I believe that money is important, but it should primarily serve as a tool to enhance our lives. As the Stoics have taught us, wealth is neither inherently good nor bad, it’s how we use it that truly makes the difference.

So, what’s the plan then? Depriving yourself of fun and pleasures today in order to enjoy a hypothetical and uncertain tomorrow without thinking about money? Is carpe-diem no longer in vogue?

I strongly believe in the wisdom of enjoying the present, of acting now rather than postponing, and not relying too much on an uncertain future or the perfect moment. But I also believe that a life worth living needs planning and clear goals, and for these goals to be achieved it is necessary to understand what is really important and follow a minimalist approach.

So… I will begin by rigorously monitoring my expenses, eliminating anything that isn’t essential or doesn’t contribute to my personal growth, maximizing savings, making wise investments, and carefully balancing them with the level of risk I’m comfortable taking over time. But before all this, I need a solid ISP.

My ISP

Ok, after days of reading articles and watching videos, I know something more about stocks, bonds, ETFs, funds, and financial independence. Not even close enough to be able to explain these concepts to someone else, but enough to allow me to start creating my first ISP.

What the fuck is an ISP? Are you thinking of providing web access to …

No, it is not an Internet Service Provider… ISP also stands for Investor Policy Statement: a detailed plan to manage your investments and not derail in times of desperation and emotional instability (2).

Interesting.. But why are you going to create a so called ISP? And above all, why are you making it public?

As I mentioned before, planning is very important to me, and a rough ISP is the first step to start investing and managing my money pragmatically and consciously.

I also strongly believe in the power of public commitment. Sharing your goals with others makes you feel more responsible about them. It also helps keep you motivated. Why? Because even if no one is really watching (or reading), in your mind, it feels like they are. This feeling makes you want to stay true to the image you have of yourself and stick to your goals.

So, let’s begin!

My ISP is directly inspired by Mr RIP’s, which is a bit dated and has changed a lot over the years but can be a good starting point (3). Mine will be adjusted according to my risk profile and my goals.

It will therefore initially be organized into three parts (I’ll think about asset allocation later on):

Goals
Strategy
Philosophy

But first, let me make a list of terms I’ll use with their descriptions:

FI (Financial independence): A state where an individual has sufficient personal wealth to live without having to work actively for basic necessities.
NW (Net Worth): Measure of an individual’s financial health.
WR (Withdraw Rate): Percentage of savings or investment portfolio that can be withdrawn annually after FI.
SR (Saving Rate): Percentage of income that is saved or invested.
FU (F*** You): The specific net worth that enables FI.

Goals

Reach FI (NW >= FU) before age 42, i.e. before the year 2036.
- FU = 30x yearly expenses (desired WR = 3.33%).
- Once FI is reached, yearly expenses (thus FU) will be updated each year based on forecasts and actual spending.
Reach 120% FU before age 45.
Stay above 80% FU forever (after having reached FI).

Strategy

Hard Accumulation phase (NW < 100% FU):
1. Keep SR >= 60% but be careful not to push too far.
2. Stay in this phase until you reach FI.
Self Sustainability phase (80% FU < NW < 120% FU):
1. Probably worth decreasing SR according to income and lifestyle.
2. Right time for any substantial changes in investments.
3. If you fall below 80% go back to phase 1.
Actual FI phase (NW >= 120% FU):
1. Stop caring about having to earn money.
2. It’s ok to withdraw from the principal if necessary.
3. Make all work and income decisions as if the wage were 0.

Philosophy

Remember to invest in yourself even before the markets.
Invest in a diverse portfolio (primarily funds).
Invest mainly in stocks (>60%), secondary in bonds.
Tolerate high risks the younger you are.
Avoid investing in specific sectors.
Prefer Distributing over Accumulating ETFs given the same costs and tax conditions.
During the accumulation phase, keep investing each month.
Once every 6 months do a major rebalance between asset classes and within each class.
- Use this “major rebalance time” to review your ISP and eventually improve/change it.
Keep 2-6 months of living expenses in cash while working (emergency fund).
In case of an urgent need for cash in a bear market, sell bonds first.

Great, very simple for now. But this is just the first step! :)

Curious to know how much time you need to reach FI with your income and SR? Try https://networthify.com/calculator/earlyretirement.

References

Mellers B, Killingsworth M. Does Money Buy Happiness? Here’s What the Research Says [Internet]. 2017. Available from: https://knowledge.wharton.upenn.edu/article/does-money-buy-happiness-heres-what-the-research-says

PhysicianOnFIRE. You Need an Investor Policy Statement [Internet]. 2016. Available from: https://www.physicianonfire.com/you-need-an-investor-policy-statement

MrRIP. My Investor Policy Statement [Internet]. 2017. Available from: https://retireinprogress.com/ips

Hello World

Tue, 02 Jan 2024 00:00:00 GMT

Hi!

I’m Cedoor and this is my first post on my new blog!

cedoor.dev

GRECO in a nutshell

Under the Hood

What to Prove

Challenges

Splitting the Modulus with RNS

Scaling Down the Math

Working within RqR_qRq​

Evaluation

Putting It All Together

References

The Wonderful Story of Amerigo Dumini

From silos to synergy

Takeaways

From concept to reality

Understanding the core challenges

Developer experience

Interoperability

Adoption

PODs

POD1

POD2

SelfAttestHub

Iden3-inspired approach

Building the ultimate PSE modular infrastructure

Commonalities and Differences

Key similarities

Major differences

Conclusions

References

Financial awareness

My ISP

Goals

Strategy

Philosophy

References

Hello World

Working within $R_q$