(Trigger Warning: This article is technical in nature)

Introduction

In Part A, we explored the necessity for a secure and privacy-preserving framework to attract institutional engagement to the Web3 economy. Silent Protocol is crafting the Ghost Layer as a modular Layer 1.5 solution to foster an institutional sandbox that is both compliant and privacy-preserving. This part delves into alternative strategies for mitigating illicit activity within privacy-focused ecosystems and explores the intricate cryptographic mechanisms underpinning the Silent Compliance VM.

Related Work

The Ghost Layer’s compliance stack

Silent Protocol’s Ghost Layer incorporates both the Silent ID and the Silent Compliance VM. This article focuses primarily on the Silent Compliance VM and its role in forming the Silent Compliance Committee, which cooperates with third-party entities as needed to selectively de-anonymize target users without compromising the privacy of others.

The Silent Compliance Committee will be composed of verifiable, reputable agencies bound by a strict code of conduct. The main purpose of the committee is to decrypt certain transactions at the behest of legitimate authorities. Decryption requests submitted to this committee are meticulously verified and backed by substantial evidence to ensure transparency in the process. Decryption approvals must meet a high bar set by the committee to maintain control over sensitive information.

This governance structure deters malicious actors by making it clear that any illicit activity will be traced and nullified. The governing body of the Ghost Layer is allowed to include new members or exclude existing members, thereby maintaining long-term decentralization.

In addition to the Silent Compliance VM, the system will be initiated with a blocklist and an allowlist (Silent ID).

The Silent Compliance VM

The Silent Compliance VM facilitates the non-voluntary de-anonymization of target users in a decentralized manner by leveraging multi-party computation techniques. This decentralized approach avoids reliance on a centralized agency by utilizing a subDAO called the Silent Compliance Committee.

The compliance group is capable of decrypting transactions to reveal details such as sender and recipient identities and transaction amounts. This mechanism enhances the Silent Protocol’s adherence to legal and regulatory mandates, ensuring robust oversight while maintaining the confidentiality and anonymity of the user base.

Members of the Silent Compliance Committee collaboratively generate a public key used for encrypting transaction details. While decrypting, members compute their partial decryption shares, which are aggregated by the subDAO to reveal the details once a sufficient number of shares are collected.

For the compliance public key generation, we made slight modifications to the Joint-Feldman DKG and made it non-interactive by using zero-knowledge proofs and smart contracts. The shares originated from this step are used by the members to compute partial decryption shares.

In the next section, we talk about cryptography and our implementation of the Silent Compliance VM that we utilize within our ghost layer.

Distributed Key Generation

Distributed key generation is an important tool for threshold cryptosystems. It allows a group of participants to collaboratively generate a shared public key and individual private key shares without any participant learning about the others’ private keys. This process occurs without any participant needing to compute, reconstruct, or individually store the secret key, and it does not rely on any trusted intermediary (dealer). While the public key is generated openly, the private key remains confidentially distributed among the participants. The security of the key is intact unless a specified number of participants are compromised. This shared private key is then utilized by the threshold cryptosystem for tasks such as digital signing or decryption, yet never computed again.

At the heart of distributed key generation lies the principle of secret sharing, a method used to divide a secret into multiple parts. Each participant holds only a part of the entire key, and a subset of these parts — typically defined by a threshold — is required to reconstruct the full secret for any cryptographic operation.

Shamir’s (t,m) — threshold scheme Sha79 for sharing a secret s ∈ ℤₚ is defined as follow:

1. Distribution

The dealer pics a random polynomial a(X) ∈ᵣ ℤₚ[X] of degree at most t satisfying a(0) = s. It sends share sᵢ = a(i) to participants Pᵢ, for i= 1,…,m.

2. Reconstruction

Any set Q of t+1 participants may recover secret s from their shares by Lagrange interpolation:

Despite its beauty and elegance, this solution is not enough for our case. A malicious dealer can

• send random values to some/all people
• use different polynomials while evaluating the shares.

Feldman addresses limitations in Shamir’s secret sharing scheme by developing a verifiable secret sharing method as detailed in Fel87. This advancement enables participants to independently verify validity of their received shares and reject any that are incorrect. This verification process is facilitated by the dealer’s broadcast of commitments to the polynomial coefficients during the distribution phase. Specifically the dealer transmits Aᵢ = aᵢG for 0 < i < t. Participants can then confirm the validity of their shares comparing sᵢG against the calculates sum ∑ᵗⱼ=0 iʲAⱼ. If a participant receives an invalid share, they can raise a complaint.

While Feldman’s verifiable secret sharing scheme guarantees that members receive correct shares, it still has a significant drawback: the dealer possesses knowledge of the distributed secret, posing a security risk. To mitigate this, distributed key generation protocols like the Joint-Feldman protocol have been developed.

The Joint-Feldman protocol are multiple parallel executions of Feldman’s scheme. This setup allows each participant to act as a dealer, distributing their secret via Feldman’s VSS. Upon receiving a share, each member verifies its validity. If a share is found to be incorrect or faulty, the recipient raises a complaint. The participant responsible for the erroneous share must then either provide the correct share or face disqualification from the process.

We can enhance this process further by adopting a non-interactive approach using zero-knowledge proofs and smart contracts. In this advanced version, participants generate zero-knowledge proofs for each share, which attest to the correctness of their computations including encryption of the shares. These proofs, along with the shares and commitments, are then sent to a smart contract. The smart contract verifies the validity of these proofs and, upon successful verification, stores the shares and commitments. This setup significantly reduces the administrative burden on participants as it eliminates the need for them to individually verify each share. By leveraging zero-knowledge proofs, the protocol ensures that all computations are correct without revealing any underlying data, thereby maintaining privacy and security.

Description

Setup

The owner deploys the compliance contract. Participants create a Babyjubjub key pair, with the secret key z ∈ Fq and the public key X = xG, where G is the generator of G₁ curve and the q is (order/8, suborder).

Registration

The owner calls the register function in the Compliance contract to register a public key and associate it with an index in Fq.

Secret Sharing

The participant :

1. Gets the index indᵢ associated with their public key from Compliance contract.
2. Checks if the index indᵢ is in Fq.
3. Generates a random polynomial a(X) ∈R ℤₚ[X] of degree at most t satisfying a(0) = x.
4. Computes the commitment values Aᵢ = aᵢG.
5. Computes the secret shares by evaluating the polynomial at the participants’ indexes, sᵢ = a(indᵢ).
6. Generates a random scalar r to be used for encrypting the secret shares for the participants.
7. Encrypts the secret share sᵢ for participant i with public key Xᵢ using hashed ElGamal encryption, C₁ = rG, c₂ᵢ= s_i + Hₚ(rXᵢ) for all participants.
8. Computes the aggregated signs for C₁, Aᵢ’s and Xᵢ’s.
9. Prepares the public input yXᵢ’s, yC₁, c₂’s, Aᵢ’s, signs, indᵢ’s to the secret sharing circuit.
10. Prepares the private input to the secret sharing circuit aᵢ’s, r
11. Creates the zero knowledge proof πᵢ attesting to

12. Calls shareSecretfunction with

and πᵢ.

shareSecret function

1. Checks if all public keys are registered.
2. Checks if the sender has shared their secret already.
3. Calls verification with inputs πᵢ, ssiᵢ, and indexes indˢⱼ₀, where indⱼ is the index binded with Xⱼ.
4. Stores commitment values.
5. Updates the compliance public key CPK by adding the sender’s public key to current CPK.

How a member gets their share

Each successful call to the shareSecret function emits a SecretSharing event including,

So, a member with the public key Xᵢ,

1. Finds the index of Xᵢ in the list of public keys yXˢᵢ₀, say i.
2. Unpacks C₁ using yC1 and signs.
3. Decrypts C₁, c₂ᵢ using xᵢ and gets the share by computing c₂ᵢ — H(xᵢC₁).

How Decryption Works

To deanonymize the transactions, cP is needed, where c is the secret key corresponding to the compliance public key C and P is a point. So, participant Xᵢ

1. Decrypts all secret shares ssᵢⱼⁿⱼ₀ that are originated from the participants Xⱼ₀ⁿ contributed to the Compliance public key C=∑ⱼ₀ⁿ Xⱼ.
2. Computes ssᵢ = ∑ⱼ₀ⁿ ssᵢⱼ.
3. Finally, returns Dᵢ = ssᵢP as their decryption share.

When there are enough shares, DAO

1. Gets the indexes indⱼ₀ᵗ corresponding to Xⱼ’s.
2. Computes Lagrange coefficients

3. Returns cP as

Point Formats

In order to reduce input size and to save gas, the contracts use packed format to represent points. The packed format is uint256 and contains the sign of -coordinate and -coordinate. The circuit side natively supports 253 bits, so coordinate and the sign does not fit into one variable. For each point, we need to also pass a sign bit. But instead of sending a sign per point, we can fit all signs into an aggregated value signs. So we switch from one format to another depending on the part we interact with.

Non-native Arithmetic

For efficient scalar multiplications, we wanted to use a curve that its base field matches the native circuit field, hence BabyJubJub. However, polynomial operations need to be conducted in the scalar field of the curve, which necessitates non-native arithmetic modulo the curve order
𝑝. To achieve this, polynomial coefficients and evaluation points are represented as bigints, structured as fixed-size arrays of signals. Specifically, each bigint is divided into 4 limbs, with each limb being 64 bits. Thus, a polynomial coefficient aᵢ is expressed as

References

Sha79 Adi Shamir, “How to Share a Secret,” Communications of the ACM, vol. 22, no. 11, pp. 612–613, 1979, ACM New York, NY, USA.

Fel87 Paul Feldman, “A Practical Scheme for Non-Interactive Verifiable Secret Sharing,” in 28th Annual Symposium on Foundations of Computer Science (sfcs 1987), pp. 427–438, 1987, IEEE.

‍