###### tags: `SILENT`
# Silent Protocol Yellowpaper(WIP)
This document provides an overview of the core protocol specifications for Silent.
<!-- here, we may include date and deployment address as well . -->
## Introduction
Silent is the scalable multi-asset shielded pool on Ethereum which enables anonymous DEFI interaction and private and anonymous transactions within Silent users.
that utilizes smart contracts, relayers and interacts with DeFi's, with four core functions; *deposit*, *transfer*, *interact* and *withdraw*. In order to maintain these features, Silent embraces [re-randomizable ElGamal public key encryption](https://hackmd.io/qEZiXB1IRxi5z1pvrKYjDQ?view#Re-randomizable-Public-key-Encryption) based account model to keep the assets private within the shielded pool by leveraging [Groth16-based zkSNARK with Circom 2.0](https://hackmd.io/loRD3OHDQ6aZAG1xaDDzRg) library to hide sender's & receiver's address and transferred amount (whenever possible), arguments of a transaction.
The protocol supports shielded transactions of ETH and ERC tokens so that the users can interact with the DeFi protocols privately, and consists of
- [*Crypto Primitives*](https://hackmd.io/qEZiXB1IRxi5z1pvrKYjDQ) - Elliptic curve based addtive ElGamal public key encryption, hash functions, threshold decryption scheme,
- [*Zero-Knowledge Proofs*](https://hackmd.io/loRD3OHDQ6aZAG1xaDDzRg) - Groth16-based zkSNARK with Circom 2.0,
- *[Templates](https://hackmd.io/loRD3OHDQ6aZAG1xaDDzRg#Templates)* that are utilized within the main circuits,
- *[Circuits](https://hackmd.io/loRD3OHDQ6aZAG1xaDDzRg#Main-Circuits)* - for building privacy preserving account-based shielded transfer protocol
- *[Deposit](https://hackmd.io/loRD3OHDQ6aZAG1xaDDzRg#Deposit)* - Logic for depositing assets into an Silent user account,
- *[Transfer](https://hackmd.io/loRD3OHDQ6aZAG1xaDDzRg#Transfer)* - Logic for transfering assets between two Silent user accounts,
- *[Withdraw](https://hackmd.io/loRD3OHDQ6aZAG1xaDDzRg#Withdraw)* - Logic for withdrawing assets from an Silent user account,
- *[Deposit from DeFi](https://hackmd.io/loRD3OHDQ6aZAG1xaDDzRg#DepositFromDefi)* - Logic for depositing assets from previously interacted DeFi,
- [*Multi-asset shielded pool (MASP)*](https://hackmd.io/SJA1bNp2TSa9HogQA_m7vg) - one pool for all the deposited assets that contains the logic to verify zkSNARK proofs. Silent user accounts' state are kept as ciphertexts within the shielded pool,
- *[Relayers](https://hackmd.io/DBGD_W_rSBKbvyk5Ohj1Dg)* - responsible for forwarding users' meta-transactions
- *[Stealth Addresses](https://hackmd.io/qEZiXB1IRxi5z1pvrKYjDQ#Stealth-Address)* - generated from user's Ethereum addresses with the Silent Protocol front-end and used for interacting the DeFi,
- *[ODeFi]()* - provides Silent users to interact with supported DeFi protocols via their stealth addresses,
- *[Governance](https://hackmd.io/ruBfQMGlQAiIkrkSpG7xKA)* - for Silent DAO management.
## Silent Protocol
<!-- here, we may include assumptions and reuqirements as well . -->
### Protocol in a nutshell
Silent utilizes the account-based model instead of the unspent transaction output (UTXO)-based model. This design choice eliminates the need for spent asset tracking, that the UTXO-based privacy-aware solutions would require. More concretely, Silent's account-based model offers better user experience, no scan delay, no Merkle tree root updates, reduced gas cost for proof verifications, at the cost of a limited anonymity set size as in Monero.
Asset owners seek to use Silent to be able to privately store or transfer their digital assets on Ethereum blockchain without needing a lift to a Layer 2 mechanism, while keeping the following three hidden:
- All details of the digital asset that are being transferred
- The identity of the sender
- The identity of the recipient
Overview and core components of the Silent protocol can be illustrated as follows.
### Notations
- Fixed parameters
| Symbol | Description |
|:---------------|:----------------------------------------------|
| $q$ | big prime |
| $\mathbb{Z}_q$ | integers modulo $q$ |
| $\mathbb{G}$ | [*BabyJubjub*](https://hackmd.io/qEZiXB1IRxi5z1pvrKYjDQ#Baby-Jubjub) Ellictic curve group of order $q$ |
| $G$ | fixed group generator |
|$\ell$ | fixed size for the anonymity sets |
|$a_{\sf max}$ | fixed constant for maximum transferable amount|
### Multi-asset Shielded Pool
*Multi-asset shielded pool (${\sf sp}$)* is the shielded pool, stored and governed by the Silent smart contract, for all the deposited assets that contains the logic to verify zkSNARK proofs. Silent users' account state are kept within this shielded pool based on the asset identifier $\sf t$. In other words, the shielded pool ${\sf sp}$ is the registry for the supported asset types
\begin{align*}
{\sf sp} \gets \{{\sf t}_1, {\sf t}_2, \ldots {\sf t}_n \}
\end{align*}
where each registry keeps track of the user accounts' balance state for that specific asset
\begin{align*}
{\sf t}_i \gets \{{\sf acc}_{1}^{i}, {\sf acc}_{2}^{i}, \ldots, {\sf acc}_{\ell_{i}}^{i} \}
\end{align*}
for some $n$ (the number of supported assets types) and $\ell_{i}$ (the number of accounts registered under the asset ${\sf t}_{i}$).
| Variable |Type |Size | Description |
|:---------|:-------|:--------|:----------------------------------|
|`tokenid` | uint160 | 160bits | asset identifier for ${\sf t}_i$ |
|`acc` |(Point, (Point,Point)) | 3x 256bits | user account identifier ${\sf acc}_{(\cdot)}^{i} \gets ({\sf pk}_{(\cdot)}^{i}, (C_1,C_2)_{(\cdot)}^{i})$ for asset ${\sf t}_i$|
Note that the asset identifier format is set to be 160 bits long, since this lets Silent smart contract to use ERC tokens' smart contract deployment address as asset identifier.
Please note that, even if we denote the ${\sf sp}$ as given above, follow the same notation in the sequel, $\sf sp$ is actually implemented in a differently to assure better efficiency. Please refer to [Silent Multi-Asset Shielded Pool](https://hackmd.io/SJA1bNp2TSa9HogQA_m7vg) for further details.
### User Accounts and Stealth Addresses
#### Key Generation and Management
Silent account and stealth address private keys are generated and managed according to BIP39 and BIP42 from the users' Ethereum account keys maintained by their Metamask wallets. When a user $A$ with Ethereum key pair $({\sf sk_{eth}}, {\sf pk_{eth}}, {\sf addr_{eth}})$ wants to generate a Silent account,
1. the user creates a signature $\sigma$ on a given message $m$ with her private key ${\sf sk_{eth}}$ using his Metamask sign data feature.
2. Then this signature is used as a seed to derive a mnemonic phrase ${\sf mnm}$.
3. Using ${\sf mnm}$, master seed ${\sf ms}$ is generated.
4. Then a private key ${\sf sk}$ is generated using ${\sf ms}$.
Similarly, when a user with Ethereum key pair $({\sf sk_{eth}}, {\sf pk_{eth}}, {\sf addr_{eth}})$ wants to generate a stealth address ${\sf addr}_{{\sf defi}_s}$ for specific DeFi with unique identifier ${\sf defi}_s$,
1. the user creates a signature $\sigma$ on a given message $(m,{\sf defi}_s)$ with her private key ${\sf sk_{eth}}$ using his Metamask sign data feature.
2. Then this signature is used as a seed to derive a mnemonic phrase ${\sf mnm_{{\sf defi}_s}}$.
3. Using ${\sf mnm_{{\sf defi}_s}}$, master seed ${\sf ms_{{\sf defi}_s}}$ is generated.
4. Then a private key ${\sf sk_{{\sf defi}_s}}$ is generated using ${\sf ms_{{\sf defi}_s}}$, and the corresponding public key ${\sf pk_{{\sf defi}_s}}$ from this private key ${\sf sk_{{\sf defi}_s}}$.
#### User Accounts
Silent keeps its user's account as a tuple ${\sf acc} \gets ({\sf pk}, (C_1,C_2))$ where
- ${\sf pk}$ is the user's ElGamal public key corresponding to the private key ${\sf sk}$, and
- $(C_1,C_2)$ is the ElGamal ciphertext of the account balance $b$;
$C_1 \gets rG$ and $C_2 \gets bG + rX$, i.e. $r \in \mathbb{Z}_q$ is random scalar and $X \gets xG$ is the user's public key ${\sf pk}$.
Typescript implementation and Circom 2.0 account template for user account is included in [here](https://github.com/projecteuanthe/elara-crypto/blob/main/src/account.ts) and [here](https://github.com/projecteuanthe/elara-crypto/blob/9c2383b805f096b7392e37aac1713e31c6db18be/circuits/templates/account.circom), respectively.
| Variable |Type |Size | Description |
|:---------|:-------|:--------|:----------------------------------|
|`EGPrivKey` |Scalar |254bits | the private key, ${\sf sk} \gets x$, i.e. $x \in \mathbb{Z}_q$|
|`EGPubKey` |Point |256bits| public key: BabyJubjub curve point, ${\sf pk} \gets xG$|
|`balance` |Scalar |254bits | Account balance, $b \in \mathbb{Z}_q$|
|`EGCtext`|(Point, Point)|2x 256bits| Account state as ElGamal ciphertext $(C_1,C_2)$ |
#### User Stealth Addresses
Using the advantage of the Silent protocol being a Layer 1 solution, it is possible to create new stealth Ethereum addresses for users in order to make their interaction with DeFi as cheap as possible and to provide better user experience. This also eliminates the relatively costly adapter or bridge based solutions.
For each user, the stealth address ${\sf addr}_{{\sf defi}_s}$, that is generated from her stealth public key, is binded to user's underlying Ethereum account and unique DeFi identifier, therefore the user will have different stealth address for each DeFi that she would like to interact.
#### Anonymity Set Formation
Silent protocol utilizes anonymity set based model as it is in many out of many proofs given in [Diamond21](https://eprint.iacr.org/2020/293.pdf).
In order to hide sender and/or recipient information, an anonymity set
$${\sf \phi} \gets \{{\sf pk}_{1}^{{\sf t}_i}, {\sf pk}_{2}^{{\sf t}_i}, \ldots, {\sf pk}_{\ell}^{{\sf t}_i}\}$$
where apart from the involved accounts, the decoy Silent account addresses ${\sf pk}_{i}^{{\sf t}_i}$ are chosen randomly from the registry ${\sf t}_{i}$.
Currently, $\ell =8$ and actual anonymity set formation differs based on the transaction type:
##### Deposit:
For each Deposit transaction, new anonymity set is formed in $4+4$ manner, i.e.
- $4$ existing accounts are randomly chosen from the respective asset type registry ${\sf t}_{i}$,
- remaining will created by
- if this is an initial deposit and new Silent account will be created, then remaining $3$ will be chosen from existing Silent accounts that are not included within the asset type registry ${\sf t}_{i}$,
- otherwise $4$ will be chosen from existing Silent accounts that are not included within the asset type registry ${\sf t}_{i}$.
##### Transfer:
For each Transfer transaction, a new anonymity set is formed uniformly at random within the asset type registry ${\sf t}_{i}$, where it includes
- sender's account,
- recipient's account, and
- 6 existing accounts are randomly chosen from the respective asset type registry ${\sf t}_{i}$.
##### Withdraw:
For each Withdraw transaction, a new anonymity set is formed uniformly at random within the asset type registry ${\sf t}_{i}$, where it includes
- sender's account, and
- 7 existing accounts are randomly chosen from the respective asset type registry ${\sf t}_{i}$.
##### toDeFi Interaction:
For toDefi interaction, assets are withdrawn from a Silent account to a stealth Ethereum address, that is created during initial interaction.
For initial toDeFi randomly anonset will be created and it is fixed further toDeFi and fromDeFi interactions as long as the same sender Silent account and stealth Ethereum address are involved. This anonymity set is formed by
- sender's account, and
- 7 existing accounts are randomly chosen from the respective asset type registry ${\sf t}_{i}$.
For later toDeFi interactions with different asset type registry ${\sf t}_{j}$, utilizing same anonymity set may not be fullfilled with negligible proability. If this would be the case, then toDeFi will be initiated by retrieving the states of the existing accounts from the contract, and pursued by adding the missing decoys accounts with zero balances into the asset registry ${\sf t}_j$.
##### fromDeFi Interaction:
fromDeFi interaction can only be utilized after toDeFi interaction. Therefore, anonymity set formation is pursued as it explained in toDeFi section.
Assume that a user wants to move some amount of an asset type ${\sf t}_i$ to a DeFi ${\sf defi}_s$, utilizes Silent's 0DeFi feature with her Ethereum account ${\sf addr}_{{\sf defi}_s}$.
At some point, she may own new asset type ${\sf t_j}$ within this account. If she would like to transfer this new asset back into the Silent's shielded pool ${\sf sp}$ with *fromDeFi*, the following cases may occur.
- *asset type ${\sf t_j}$ is not included in ${\sf sp}$*:
- ${\sf t_j}$ should go under whitelisting process and be registered into ${\sf sp}$ and all of the anonymity set accounts should be added into ${\sf t_j}$ registry.
- *asset type ${\sf t_j}$ is included in ${\sf sp}$ but some accounts, are not included in the registry*:
- missing anonymity set accounts should be added into ${\sf t_j}$ registry with the correct encrypted balances,
- *asset type ${\sf t_j}$ is included in ${\sf sp}$ and all accounts are included in the registry*:
- account states are correctly updated in the registry.
### Core Functionalities
#### Deposit
Asset owner $A$ initiates a deposit order that deposits an amount $a$ of asset ${\sf t}$ from an Ethereum address to an Silent user account ${\sf acc}_{A}^{\sf t} \gets ({\sf pk}_{A}^{\sf t}, (C_1,C_2)_{A}^{\sf t})$ included in the asset ${\sf t}$ registry.
In order to deposit an amount $a$ of asset type $\sf t$ to Silent smart contract, asset owner needs to have an Silent account credential for $\sf t$, which is in fact an ElGamal private-public key on the BabyJubjub curve.
1. If it does not exist already, asset owner $A$ runs ElGamal $\sf KeyGen_{eg}$ to generate account keys for the asset $\sf t$:
$\sf KeyGen_{eg}$: $({\sf sk}_{A}^{\sf t},{\sf pk}_{A}^{\sf t}) \gets ({\sf pp_{eg}})$ -
- generate a random scalar $x \in \mathbb{Z}_q$ as it outlined in [Key Generation and Management](#key-generation-and-management) and set it as the private key ${\sf sk}_{A}^{\sf t} \gets x$,
- compute $X \gets xG$ and set it as the corresponding public key ${\sf pk}_{A}^{\sf t} \gets X$,
- output $({\sf sk}_{A}^{\sf t},{\sf pk}_{A}^{\sf t})$.
1. Then, A initiates deposit transaction with the following parameters.
*Public Inputs*:
| Variable |Type |Size | Description |
|:---------|:-------|:--------|:----------------------------------|
|`fromEthAddr`|uint160 |160bits | A's Ethereum address |
|`toSilentSCAddr`|uint160 |160bits | Silent smart contract's address |
|`tokenid` | uint160 | 160bits | asset identifier for ${\sf t}$ |
|`amount` |Scalar |254bits | Amount $a \in \mathbb{Z}_q$, $0 < a \leq a_{\sf max}$, to be transfered|
|`inAccSet`|Array | $3\ell$ x 256bits | selected anonymity set of Silent accounts $\{{\sf acc}_{1}^{\sf t}, {\sf acc}_{2}^{\sf t}, \ldots, {\sf acc}_{\ell}^{\sf t} \}$ |
|`outAccSet`|Array|$3\ell$ x 256bits| anonymity set with updated/randomized states|
| `ECPointSigns` | | | Signs array for compressed EC points |
*Proof Paramaters*:
| Variable |Type |Size | Description |
|:---------|:-------|:--------|:----------------------------------|
|`proof` | Proof | xx | Output of deposit circuit |
|`publicSignals` | uint[] | xx | Public inputs of deposit circuit |
> publicSignals = (yInC1, yInC2, yOutC1, yOutC2, yPublicKeys, yAmlPublicKeys, signs, valueIn, yIndexCiphertext, recipientHash)
> proof = (A, B, C), where $B \in \mathbb{G}_2$ and $A,C \in \mathbb{G}_1$
>proof/public signals parameters will be updated after the deposit SC is finalized!
- $A$ first needs to randomly pick $\ell-1$ Silent accounts to form an anonymity set `inAccSet` including the receiver account, i.e.
\begin{align*}
\{{\sf acc}_{1}^{\sf t}, {\sf acc}_{2}^{\sf t}, \ldots, {\sf acc}_{\ell}^{\sf t}\}
\end{align*}
in which ${\sf acc}_{A}^{\sf t} \gets ({\sf pk}_{A}^{\sf t}, (C_1',C_2')_{A}^{\sf t})$ being $A$'s account,
- $A$ computes her new account balance by using additive homomorphism of ElGamal scheme
\begin{align*}
(C_1, C_2)_{A}^{{\sf t}} \gets(C_1',aG + C_2')
\end{align*}
Note that if this deposit order is the first one, then $(C_1',C_2')_{A}^{{\sf t}}$ is set as the tuple consisting of only the identity element of $\mathbb{G}$, BabyJubjub elliptic curve group.
- $A$ re-randomizes the states of all the accounts to form anonymity set `outAccSet`,
\begin{align*}
(E_1, E_2)_{i}^{\sf t} \gets (E_1' + rG, E_2' + rX_{i}),
\end{align*}
where for each $i \in [1,\ldots,\ell]$, $(E_1', E_2')_{i}^{\sf t}$ being the previous state and $X_{i}$ being the ElGamal public key of the account ${\sf acc}_{i}^{\sf t}$,
- For KYC/AML compliance assurance, $A$ also encrypts transaction details as described in [Compliance](#Threshold-Decryption) section,
- Next, $A$ generates the proof $\pi \gets(\text{proof, publicSignals})$ for new balance ciphertext component $(C_{2})_{A}^{\sf t}$ is correctly computed by utilizing the [Deposit](https://hackmd.io/loRD3OHDQ6aZAG1xaDDzRg#Deposit) circuit, sends the transaction to Ethereum network with the following data
```
fromEthAddr, tokenid, amount, input data
```
where the `input data` being
```
proof, publicSignals <- deposit(amount, bjjyPublicKeys, bjjyAmlPublicKeys, bjjyOldCiphertexts, bjjyNewCiphertexts, signs, complianceVars, index, random, r)
```
along with the necessary Ethereum transaction fields.
1. Upon receiving the message call, Silent smart contract would follow the steps given below.
- require verification of the proof $\pi \gets(\text{proof, publicSignals})$, by retrieving the states of all the involved accounts' state from the ${\sf sp}$,
- update/initiate account state for each account included in
\begin{align*}
\{{\sf acc}_{1}^{\sf t}, {\sf acc}_{2}^{\sf t}, \ldots, {\sf acc}_{\ell}^{\sf t}\}.
\end{align*}
<!--- - if ${\sf pk}_{A}^{\sf t}$ is already exists in asset registry $\sf t$:
- require verification of the proof $\pi \gets(\text{proof, publicSignals})$ with the registered account state ${\sf acc}_{A}^{\sf t} \gets ({\sf pk}_{A}^{\sf t}, (C_1',C_2')_{A}^{\sf t}$ stored in the ${\sf sp}$,
- update account state as ${\sf acc}_{A}^{\sf t} \gets ({\sf pk}_{A}^{\sf t}, (C_1,C_2)_{A}^{\sf t}$.
- else (this is the initial deposit for a new Silent account):
- require verification of the proof $\pi \gets(\text{proof, publicSignals})$ with the initial account state ${\sf acc}_{A}^{\sf t} \gets ({\sf pk}_{A}^{\sf t}, (C_1',C_2')_{A}^{\sf t}$ where $(C_1',C_2')_{A}^{\sf t}$ is set as the identity element of $\mathbb{G}$, BabyJubjub elliptic curve group,
- register account state as ${\sf acc}_{A}^{\sf t} \gets ({\sf pk}_{A}^{\sf t}, (C_1,C_2)_{A}^{\sf t}$ into the asset $\sf t$ registry.
--->
#### Transfer
Asset owner $A$ initiates a transfer order that transfers an amount $a$ of asset ${\sf t}$ from an Silent user account ${\sf acc}_{A}^{\sf t} \gets ({\sf pk}_{A}^{\sf t}, (C_1',C_2')_{A}^{\sf t})$ with balance $b_A'$, included in the asset ${\sf t}$ registry, to another Silent user $B$ account ${\sf acc}_{B}^{\sf t} \gets ({\sf pk}_{B}^{\sf t}, (D_1',D_2')_{B}^{\sf t})$ with an unknown balance $b_B'$.
During asset transfer within ${\sf sp}$, asset owner needs to utilize a relayer of her choice, relayer details can be found [here](https://hackmd.io/DBGD_W_rSBKbvyk5Ohj1Dg).
1. Then, A initiates transfer transaction with the following parameters.
*Public Inputs*:
| Variable |Type |Size | Description |
|:---------|:-------|:--------|:----------------------------------|
|`tokenid` | uint160 | 160bits | asset identifier for ${\sf t}$ |
|`inAccSet`|Array | $3\ell$ x 256bits | selected anonymity set of Silent accounts $\{{\sf acc}_{1}^{\sf t}, {\sf acc}_{2}^{\sf t}, \ldots, {\sf acc}_{\ell}^{\sf t} \}$ |
|`outAccSet`|Array|$3\ell$ x 256bits| anonymity set with updated/randomized states|
| `ECPointSigns` | | | Signs array for compressed EC points |
| `ComplianceVars` | | | Variables for compliance |
*Private Inputs*:
| Variable |Type |Size | Description |
|:---------|:-------|:--------|:----------------------------------|
|`accEGPrivKey` |Scalar | 254bits | $A$'s ElGamal private key, ${\sf sk}_{A}^{\sf t} \gets x$|
| `senderIndex` | | | Sender $A$'s index in anonymity set |
| `recipientIndex`| | | Recipient $B$'s index in anonymity set |
|`amount` |Scalar |254bits | Amount $a \in \mathbb{Z}_q$, $0 < a \leq a_{\sf max}$, to be transfered|
|`newAccBalance` |Scalar |254bits |new account balance, scalar $b \in \mathbb{Z}_q$|
|`EGRandom` |Scalar |254bits | Random scalar $r \in \mathbb{Z}_q$ ElGamal randomization|
|`ephemeralR` | | | Asynchronous key share for KYC/AML compliance |
*Proof Paramaters*:
| Variable |Type |Size | Description |
|:---------|:-------|:--------|:----------------------------------|
|`proof` | Proof | xx | Output of deposit circuit |
|`publicSignals` | uint[] | xx | Public inputs of deposit circuit |
>proof parameters will be updated after the transfer template is finalized!
- $A$ first needs to randomly pick $\ell-2$ Silent accounts to form an anonymity set `inAccSet` including the sender and receiver account, i.e.
\begin{align*}
\{{\sf acc}_{1}^{\sf t}, {\sf acc}_{2}^{\sf t}, \ldots, {\sf acc}_{\ell}^{\sf t}\}
\end{align*}
in which ${\sf acc}_{A}^{\sf t} \gets ({\sf pk}_{A}^{\sf t}, (C_1',C_2')_{A}^{\sf t})$ being $A$'s and ${\sf acc}_{B}^{\sf t} \gets ({\sf pk}_{B}^{\sf t}, (D_1',D_2')_{B}^{\sf t})$ being $B$'s account,
- $A$ computes new balances for her and recipient $B$'s accounts by using additive homomorphism of ElGamal scheme
\begin{align*}
(C_1, C_2)_{A}^{{\sf t}} & \gets(C_1',C_2' - aG) \\
(D_1, D_2)_{B}^{{\sf t}} & \gets(D_1',D_2' + aG) \\
\end{align*}
- $A$ re-randomizes the states of all the accounts to form anonymity set `outAccSet`,
\begin{align*}
(E_1, E_2)_{i}^{\sf t} \gets (E_1' + rG, E_2' + rX_{i}),
\end{align*}
where for each $i \in [1,\ldots,\ell]$, $(E_1', E_2')_{i}^{\sf t}$ being the old state and $X_{i}$ being the ElGamal public key of the account ${\sf acc}_{i}^{\sf t}$,
- For KYC/AML compliance assurance, $A$ also encrypts transaction details as described in [Compliance](#Threshold-Decryption) section,
- Next, by utilizing the [Transfer](https://hackmd.io/loRD3OHDQ6aZAG1xaDDzRg#Transfer) circuit, $A$ generates the proof $\pi$ for
- knowledge of sender's private key, sender and recipient index in anonymity set, random $r$, compliance random `ephemeralR`,
- $0 < a \leq a_{\sf max}$,
- new account balances are correctly computed and re-randomized
- KYC/AML compliance encryption is pursued correctly,
- sends the transaction over a chosen relayer with the following data
```
tokenid, amount, input data
```
where the `input data` being
```
transfer(inAccSet, outAccSet, signs, proof, publicSignals)
```
along with the necessary Ethereum transaction fields.
2. Upon receiving the message call, Silent smart contract would follow the steps given below.
- require verification of the proof $\pi \gets(\text{proof, publicSignals})$, by retrieving the states of all the involved accounts' state from the ${\sf sp}$,
- update account state for each account included in
\begin{align*}
\{{\sf acc}_{1}^{\sf t}, {\sf acc}_{2}^{\sf t}, \ldots, {\sf acc}_{\ell}^{\sf t}\}.
\end{align*}
#### Withdraw
Asset owner $A$ initiates a withdraw order that withdraws an amount $a$ of asset ${\sf t}$ from an Silent user account ${\sf acc}_{A}^{\sf t} \gets ({\sf pk}_{A}^{\sf t}, (C_1',C_2')_{A}^{\sf t})$ with balance $b'$, included in the asset ${\sf t}$ registry, to an Ethereum address.
During asset withdrawal, asset owner needs to utilize a relayer of her choice, relayer details can be found [here](https://hackmd.io/DBGD_W_rSBKbvyk5Ohj1Dg).
1. In order to withdraw of an amount $a$ of asset type $\sf t$ from the Silent shielded pool, asset owner should create a new Ethereum address as the recipient address. Even if this is not compulsory, this would be a better strategy for assuring unlinkability. Since this is a standard Ethereum address creation process, the details for Ethereum address creation are omitted.
2. Then, A initiates withdraw transaction with the following parameters.
*Public Inputs*:
| Variable |Type |Size | Description |
|:---------|:-------|:--------|:----------------------------------|
|`toEthAddr`|uint160 |160bits | recipient's Ethereum address |
|`tokenid` | uint160 | 160bits | asset identifier for ${\sf t}$ |
|`amount` |Scalar |254bits | Amount $a \in \mathbb{Z}_q$, $0 < a \leq a_{\sf max}$, to be transfered|
|`inAccSet`|Array | $3\ell$ x 256bits | selected anonymity set of Silent accounts $\{{\sf acc}_{1}^{\sf t}, {\sf acc}_{2}^{\sf t}, \ldots, {\sf acc}_{\ell}^{\sf t} \}$ |
|`outAccSet`|Array|$3\ell$ x 256bits| anonymity set with updated states|
| `ECPointSigns` | | | Signs array for compressed EC points |
| `ComplianceVars` | | | Variables for compliance |
*Private Inputs*:
| Variable |Type |Size | Description |
|:---------|:-------|:--------|:----------------------------------|
|`accEGPrivKey` |Scalar | 254bits | $A$'s ElGamal private key, ${\sf sk}_{A}^{\sf t} \gets x$|
| `senderIndex` | | | Sender $A$'s index in anonymity set |
|`amount` |Scalar |254bits | Amount $a \in \mathbb{Z}_q$, $0 < a \leq a_{\sf max}$, to be transfered|
|`newAccBalance` |Scalar |254bits |new account balance, scalar $b \in \mathbb{Z}_q$|
|`EGRandom` |Scalar |254bits | Random scalar $r \in \mathbb{Z}_q$ ElGamal randomization|
|`ephemeralR` | | | Asynchronous key share for KYC/AML compliance |
*Proof Paramaters*:
| Variable |Type |Size | Description |
|:---------|:-------|:--------|:----------------------------------|
|`proof` | Proof | xx | Output of deposit circuit |
|`publicSignals` | uint[] | xx | Public inputs of deposit circuit |
>proof parameters will be updated after the transfer template is finalized!
- $A$ first needs to randomly pick $\ell-1$ Silent accounts to form an anonymity set `inAccSet` including the sender and receiver account, i.e.
\begin{align*}
\{{\sf acc}_{1}^{\sf t}, {\sf acc}_{2}^{\sf t}, \ldots, {\sf acc}_{\ell}^{\sf t}\}
\end{align*}
in which ${\sf acc}_{A}^{\sf t} \gets ({\sf pk}_{A}^{\sf t}, (C_1',C_2')_{A}^{\sf t})$ being $A$'s account,
- $A$ computes new balance for her account by using additive homomorphism of ElGamal scheme
\begin{align*}
(C_1, C_2)_{A}^{{\sf t}} & \gets(C_1',C_2' - aG)
\end{align*}
- $A$ re-randomizes the states of all the accounts to form anonymity set `outAccSet`,
\begin{align*}
(E_1, E_2)_{i}^{\sf t} \gets (E_1' + rG, E_2' + rX_{i}),
\end{align*}
where for each $i \in [1,\ldots,\ell]$, $(E_1', E_2')_{i}^{\sf t}$ being the previous state and $X_{i}$ being the ElGamal public key of the account ${\sf acc}_{i}^{\sf t}$,
- For KYC/AML compliance assurance, $A$ also encrypts transaction details as described in [Compliance](#Threshold-Decryption) section,
- Next, by utilizing the [Withdraw](https://hackmd.io/loRD3OHDQ6aZAG1xaDDzRg#Withdraw) circuit, $A$ generates the proof $\pi$ for
- knowledge of sender's private key, sender index in anonymity set, random $r$, compliance random `ephemeralR`,
- new account balances are correctly computed and re-randomized
- KYC/AML compliance encryption is pursued correctly,
- sends the transaction over a chosen relayer with the following data
```
toEthAddr, tokenid, amount, input data
```
where the `input data` being
```
withdraw(inAccSet, outAccSet, signs, proof, publicSignals)
```
along with the necessary Ethereum transaction fields.
3. Upon receiving the message call, Silent smart contract would follow the steps given below.
- require verification of the proof $\pi \gets(\text{proof, publicSignals})$, by retrieving the states of all the involved accounts' state from the ${\sf sp}$,
- update account state for each account included in
\begin{align*}
\{{\sf acc}_{1}^{\sf t}, {\sf acc}_{2}^{\sf t}, \ldots, {\sf acc}_{\ell}^{\sf t}\}.
\end{align*}
- transfers the requested amount of asset to the given `toEthAddr`.
#### Interact
Asset owner $A$ may initiate an interact order to move an amount $a$ of asset ${\sf t}$
- **toDeFi**: from an Silent user account ${\sf acc}_{A}^{\sf t} \gets ({\sf pk}_{A}^{\sf t}, (C_1',C_2')_{A}^{\sf t})$ with balance $b'$, included in the asset ${\sf t}$ registry, to a DeFi protocol specific stealth address, or
- **fromDeFi**: from a Defi protocol specific stealth address into her Silent account ${\sf acc}_{A}^{\sf t} \gets ({\sf pk}_{A}^{\sf t}, (C_1',C_2')_{A}^{\sf t})$
In order to reduce the gas fee costs and provide friendly user experience, instead of utilizing adapter/bridge smart contracts, Silent protocol promises a better approach and lets its' users to utilize stealth Ethereum addresses for their DeFi interactions.
Naturally, during an interact transaction, asset owner needs to utilize a relayer of her choice, details can be found [here](https://hackmd.io/DBGD_W_rSBKbvyk5Ohj1Dg).
##### toDeFi
This is almost identical to the asset withdrawal from Silent's shielded pool to an Ethereum address. Main difference is that here users transfer their assets to a stealth Ethereum address and interact with DeFi protocols through this stealth address.
1. $A$ creates a stealth Ethereum address `toStealthEthAddr` based on the chosen DeFi protocol by following the steps given in [Key Generation and Management](#Key-Generation-and-Management) section. This procedure runs once per DeFi and Metamask managed Ethereum address and can be utilized in both toDeFi and fromDeFi transactions.
2. $A$ initiates interact transaction with the following parameters.
*Public Inputs*:
| Variable |Type |Size | Description |
|:---------|:-------|:--------|:----------------------------------|
|`toStealthEthAddr`|uint160 |160bits | $A$'s stealth Ethereum address |
|`tokenid` | uint160 | 160bits | asset identifier for ${\sf t}$ |
|`amount` |Scalar |254bits | Amount $a \in \mathbb{Z}_q$, $0 < a \leq a_{\sf max}$, to be transfered|
|`inAccSet`|Array | $3\ell$ x 256bits | selected anonymity set of Silent accounts $\{{\sf acc}_{1}^{\sf t}, {\sf acc}_{2}^{\sf t}, \ldots, {\sf acc}_{\ell}^{\sf t} \}$ |
|`outAccSet`|Array|$3\ell$ x 256bits| anonymity set with updated states|
| `ECPointSigns` | | | Signs array for compressed EC points |
| `ComplianceVars` | | | Variables for compliance |
*Private Inputs*:
| Variable |Type |Size | Description |
|:---------|:-------|:--------|:----------------------------------|
|`accEGPrivKey` |Scalar | 254bits | $A$'s ElGamal private key, ${\sf sk}_{A}^{\sf t} \gets x$|
| `senderIndex` | | | Sender $A$'s index in anonymity set |
|`newAccBalance` |Scalar |254bits |new account balance, scalar $b \in \mathbb{Z}_q$|
|`EGRandom` |Scalar |254bits | Random scalar $r \in \mathbb{Z}_q$ ElGamal randomization|
|`ephemeralR` | | | Asynchronous key share for KYC/AML compliance |
*Proof Paramaters*:
| Variable |Type |Size | Description |
|:---------|:-------|:--------|:----------------------------------|
|`proof` | Proof | xx | Output of deposit circuit |
|`publicSignals` | uint[] | xx | Public inputs of deposit circuit |
>proof parameters will be updated after the transfer template is finalized!
- if this is not $A$'s the first interaction with stealth address, first she acquires the anonymity set that was formed within the first interaction. If this is her initial interaction, then she needs to randomly pick $\ell-1$ Silent accounts to form an anonymity set `inAccSet` including the sender and receiver account, i.e.
\begin{align*}
\{{\sf acc}_{1}^{\sf t}, {\sf acc}_{2}^{\sf t}, \ldots, {\sf acc}_{\ell}^{\sf t}\}
\end{align*}
in which ${\sf acc}_{A}^{\sf t} \gets ({\sf pk}_{A}^{\sf t}, (C_1',C_2')_{A}^{\sf t})$ being $A$'s account,
- $A$ computes new balance for her account by using additive homomorphism of ElGamal scheme
\begin{align*}
(C_1, C_2)_{A}^{{\sf t}} & \gets(C_1',C_2' - aG)
\end{align*}
- $A$ re-randomizes the states of all the accounts to form anonymity set `outAccSet`,
\begin{align*}
(E_1, E_2)_{i}^{\sf t} \gets (E_1' + rG, E_2' + rX_{i}),
\end{align*}
where for each $i \in [1,\ldots,\ell]$, $(E_1', E_2')_{i}^{\sf t}$ being the previous state and $X_{i}$ being the ElGamal public key of the account ${\sf acc}_{i}^{\sf t}$,
- For KYC/AML compliance assurance, $A$ also encrypts transaction details as described in [Compliance](#Threshold-Decryption) section,
- Next, by utilizing the [Withdraw](https://hackmd.io/loRD3OHDQ6aZAG1xaDDzRg#Withdraw) circuit, $A$ generates the proof $\pi$ for
- knowledge of sender's private key, sender index in anonymity set, random $r$, compliance random `ephemeralR`,
- new account balances are correctly computed and re-randomized
- KYC/AML compliance encryption is pursued correctly,
- sends the transaction over a chosen relayer with the following data
```
toStealthEthAddr, tokenid, amount, input data
```
where the `input data` being
```
withdraw(inAccSet, outAccSet, signs, proof, publicSignals)
```
along with the necessary Ethereum transaction fields.
3. Upon receiving the message call, Silent smart contract would follow the steps given below.
- require verification of the proof $\pi \gets(\text{proof, publicSignals})$, by retrieving the states of all the involved accounts' state from the ${\sf sp}$,
- update account state for each account included in
\begin{align*}
\{{\sf acc}_{1}^{\sf t}, {\sf acc}_{2}^{\sf t}, \ldots, {\sf acc}_{\ell}^{\sf t}\}.
\end{align*}
- transfers the requested amount of asset to the given `toStealthEthAddr`.
##### fromDeFi
This transaction can be mounted if a user had already created a DeFi-specific stealth address through Silent protocol's user interface. So she had transfered some amount of her asset into this stealth address, while doing this, an anonymity set that includes and is binded to her Silent account ${\sf acc}_{A}^{\sf t} \gets ({\sf pk}_{A}^{\sf t}, (C_1',C_2')_{A}^{\sf t})$ is already formed, i.e.
\begin{align*}
\{{\sf acc}_{1}^{\sf t}, {\sf acc}_{2}^{\sf t}, \ldots, {\sf acc}_{\ell}^{\sf t}\}.
\end{align*}
In order not to create a linkability issue and cause privacy leakage, Silent protocol fixes this anonymity set for each user's Silent account-DeFi-specific stealth address pair.
1. Then, A initiates deposit transaction with the following parameters.
*Public Inputs*:
| Variable |Type |Size | Description |
|:---------|:-------|:--------|:----------------------------------|
|`fromStealthEthAddr`|uint160 |160bits | A's stealth Ethereum address |
|`toSilentSCAddr`|uint160 |160bits | Silent smart contract's address |
|`tokenid` | uint160 | 160bits | asset identifier for ${\sf t}$ |
|`amount` |Scalar |254bits | Amount $a \in \mathbb{Z}_q$, $0 < a \leq a_{\sf max}$, to be transfered|
|`inAccSet`|Array | $3\ell$ x 256bits | selected anonymity set of Silent accounts $\{{\sf acc}_{1}^{\sf t}, {\sf acc}_{2}^{\sf t}, \ldots, {\sf acc}_{\ell}^{\sf t} \}$ |
|`outAccSet`|Array|$3\ell$ x 256bits| anonymity set with updated states|
| `ECPointSigns` | | | Signs array for compressed EC points |
| `ComplianceVars` | | | Variables for compliance |
*Private Inputs*:
| Variable |Type |Size | Description |
|:---------|:-------|:--------|:----------------------------------|
|`accEGPrivKey` |Scalar | 254bits | $A$'s ElGamal private key, ${\sf sk}_{A}^{\sf t} \gets x$|
| `senderIndex` | | | Sender $A$'s index in anonymity set |
|`newAccBalance` |Scalar |254bits |new account balance, scalar $b \in \mathbb{Z}_q$|
|`EGRandom` |Scalar |254bits | Random scalar $r \in \mathbb{Z}_q$ ElGamal randomization|
|`ephemeralR` | | | Asynchronous key share for KYC/AML compliance |
*Proof Paramaters*:
| Variable |Type |Size | Description |
|:---------|:-------|:--------|:----------------------------------|
|`proof` | Proof | xx | Output of deposit circuit |
|`publicSignals` | uint[] | xx | Public inputs of deposit circuit |
>proof parameters will be updated after the transfer template is finalized!
- $A$ first retrieves her fixed anonymity set that includes and is binded to her Silent account ${\sf acc}_{A}^{\sf t} \gets ({\sf pk}_{A}^{\sf t}, (C_1',C_2')_{A}^{\sf t})$ is already formed, i.e.
\begin{align*}
\{{\sf acc}_{1}^{\sf t}, {\sf acc}_{2}^{\sf t}, \ldots, {\sf acc}_{\ell}^{\sf t}\},
\end{align*}
- $A$ computes new balance for her account by using additive homomorphism of ElGamal scheme
\begin{align*}
(C_1, C_2)_{A}^{{\sf t}} & \gets(C_1',C_2' - aG)
\end{align*}
- $A$ re-randomizes the states of all the accounts to form anonymity set `outAccSet`,
\begin{align*}
(E_1, E_2)_{i}^{\sf t} \gets (E_1' + rG, E_2' + rX_{i}),
\end{align*}
where for each $i \in [1,\ldots,\ell]$, $(E_1', E_2')_{i}^{\sf t}$ being the previous state and $X_{i}$ being the ElGamal public key of the account ${\sf acc}_{i}^{\sf t}$,
- For KYC/AML compliance assurance, $A$ also encrypts transaction details as described in [Compliance](#Threshold-Decryption) section,
- Next, by utilizing the [Deposit from DeFi](https://hackmd.io/loRD3OHDQ6aZAG1xaDDzRg#DepositFromDefi) circuit, $A$ generates the proof $\pi$ for
- knowledge of sender's private key, sender index in anonymity set, random $r$, compliance random `ephemeralR`,
- new account balances are correctly computed and re-randomized
- KYC/AML compliance encryption is pursued correctly,
- sends the transaction over a chosen relayer, with the following data
```
fromStealthEthAddr, toSilentSCAddr, tokenid, amount, input data
```
where the `input data` being
```
withdrawfromdefi(inAccSet, outAccSet, signs, proof, publicSignals)
```
along with the necessary Ethereum transaction fields.
2. Upon receiving the message call, Silent smart contract would follow the steps given below.
- require verification of the proof $\pi \gets(\text{proof, publicSignals})$, by retrieving the states of all the involved accounts' state from the ${\sf sp}$,
- update account state for each account included in
\begin{align*}
\{{\sf acc}_{1}^{\sf t}, {\sf acc}_{2}^{\sf t}, \ldots, {\sf acc}_{\ell}^{\sf t}\}.
\end{align*}
- transfers the requested amount of asset from the given `fromStealthEthAddr`.
#### ODefi
With the Interact features, Silent users' own,manage and more importantly transfer assets into the freshly created DeFi-specific stealth addresses that are binded to users' Metamask managed ETH addresses uniquely.
As soon as, a Silent user move some her assets into her stealth address, she can utilize Silent protocol's user interface and pursue her financial interaction directly to decentralized finance protocols.
This innovative solution primarily eliminates the need for users to deal with bridge/adaptor smart contracts. Apart from its user friendly way of doing things, this also saves users from paying extra fees that may arise for those adapter based DeFi interactions.
## Compliance
### Threshold Decryption
During the transfer, withdraw and interact, transaction details are encrypted for compliance. Suppose that sender's key pair is $s_s,P_s$ and DAO's key pair is $s_{DAO}, P_{DAO}$. Encryption for the compliance is as follows.
1. Get a number $r$ in order to derive a different shared key for each transaction and compute ephemeral public key $R = r P_s$.
2. Compute sharedSecret = poseidon$((rs_s)P_{DAO})$.
3. Let txDetails = $[P_s[0], P_s[1], P_{DAO}[0], P_{DAO}[1], amount]$.
4. $iv$ = mimc7.hash(rand(), 91).
5. EncryptedTxDetails = []
6. for $0 \leq i < 5$:
$\quad$ EncryptedTxDetails[$i$] = txDetails[$i$] + mimc7.hash($iv+i+$sharedSecret, 91)
7. return (R, iv, EncryptedTxDetails).
When DAO wants to reveal transactions belonging to a particular address, they need to find the transactions that the address takes part as sender or receiver. Since transfer and withdraw uses anonymity sets, it is not possible to identify this transactions exactly. Instead, DAO can find the transactions that the anonymity set contains the address. Then, for each transaction, they do the following steps.
1. compute sharedSecret = poseidon$(s_{DAO}R)$.
2. for $0 \leq i < 5$:
$\quad$ TxDetails[$i$] = EncryptedTxDetails[$i$] - mimc7.hash($iv+i+$sharedSecret, 91)
3. sender = [TxDetails[0], TxDetails[1]]
receiver = [TxDetails[2], TxDetails[3]]
amount = TxDetails[5]
This process reveals not only the transactions that belong to the particular user but details of all of the transactions that the particular address is involved in the anonymity set.
<!--Please note that, in order to compute the sharedSecret that is used to encrypt/decrypt transaction details, DAO needs to use their secret key. This can be done in two ways.
1. Secret sharing: Each member has a share of the secret key ($s_{DAO}$ in this case), and the secret key can be revealed if $t$ out of $m$ members participate, then this secret is used to compute $sharedSecret$. Downside of this is that the secret key is out after the process.
2. Threshold encryption: Each DAO member has a share of the secret and DAO has a single public key. Users of the Silent protocol can encrypt a message using DAO's public key. In order to decrypt, $t$ out of $m$ members need to participate and compute their partial decryption shares. sharedSecret is revealed after combining the shares. -->
NOTE: There is not a mechanism in place that prevents DAO from decrypting all of the transactions.
#### DAO Public Key Generation
Suppose that DAO has $n$ members. Now we describe a mechanism such that $k$ of them are able to decrypt messeges. It is assumed that $n \geq 2k-1$.
Let $C(m,r)$ denote a commitment to a message $m$ using a random $r$. Then, DAO public key is generated as follows:
1. Each party $P_i$ chooses random $x_i$ and computes $Q_i = x_iP$. Then $P_i$ chooses a random $r_i$ and broadcasts $C_i$.
2. When all parties broadcast their commetments, each $P_i$ opens its commitment $C_i$ and everybody knows $Q_i$.
3. The public key $P_{DAO} = \sum_{i=1}^n Q_i$.
At this point, all members know the public key however they can not find/use the secret key, $x = \sum_{i=1}^n x_i$, unlesss all of them participate in the process. Since we want $k$ of them to be able to use the secret key, each party $P_i$ is going to share their secrets in a way that $k$ parties are able to use $x_i$.
<!---
> [name=togobramble] we need to decide how this $n$ members would be selected. If we let any $k$ DAO member would form decryption set then with the Sybil attack, an attacker can pose as $k$ different entity and then decrypts messages. If this would be case, we need to let DAO as golden member for forming decryption set.
--->
#### DAO Secret Key Share Generation
1. $P_i$ chooses a polynomial $f_i(x)$ of degree $k-1$ such that $f_i(0)=x_i$. Let $$f_i(x) = f_{i0} + f_{i1} x + \ldots + f_{i(k-1)} x^{k-1},$$ where $f_{i0} = x_i$.
2. $P_i$ computes $F_{ij}=f_{ij}P$ for $0 \leq j \leq k-1$ and broadcasts $\{F_{ij}\}_{1\leq j \leq k-1}$. Notice that $F_{i0} = Q_i$ is known before this process.
3. When all parties broadcast $F_{ij}$'s, $P_i$ does the following for each $1 \leq j \leq n$
3.1. evalutes $f_i$ at $j$, $s_{ij} = f_i(j)$, and sends $s_{ij}$ and a signature $\sigma_{ij}$ on $s_{ij}$ to $P_j$, secretly.
After this phase is completed, each party verifies that the other parties followed the protocol correctly.
1. $P_i$ verifies that the share $s_{ji}$ received from $P_j$ is consistent with the values broadcast by $P_j$ by checking $$s_{ji}P = \sum_{l=0}^{k-1} i^l F_{jl}.$$
2. If the above verification fails, $P_i$ broadcasts that an error is found, publishes $s_{ij}$ and $\sigma_{ij}$, and stops.
3. $P_i$ computes its share of $x$ as the sum of the shares $s_{ji}$ that $P_i$ received, $$s_i = \sum_{j=1}^n s_{ji}.$$
4. Finally, $P_i$ signs $P_{DAO}$.
#### DAO Decryption
For each transaction with ephemeral key $R$, each/some DAO member $P_i$ computes $w_i = s_iR$ and sends to Authority. After getting shares from $k$ members, denote the set as $S$, Authority
1. computes the lagrange coefficients $\lambda_i = \prod_{j\in S\i} \frac{i}{j-i}$.
2. computes $s_{DAO}R$ as $\sum_{i\in S} \lambda_i w_i$.
3. computes sharedSecret = poseidon$(s_{DAO}R)$.
4. for $0 \leq i < 5$:
$\quad$ TxDetails[$i$] = EncryptedTxDetails[$i$] - mimc7.hash($iv+i+$sharedSecret, 91)
5. sender = [TxDetails[0], TxDetails[1]]
receiver = [TxDetails[2], TxDetails[3]]
amount = TxDetails[5]
## Security & Privacy
### Security
Silent's offers overflow and overdraft protection since the discrete logarithm problem on the Babyjubjub elliptic curve group $\mathbb{G}$ is hard. Please refer to [FMMO18](https://eprint.iacr.org/2018/990.pdf) and [Diamond21](https://eprint.iacr.org/2020/293.pdf) for formal definitions and proofs.
### Privacy
Transparent nature of Ethereum chain allows tracking of all the transactions. Therefore, whenever an asset owner initially deposits some amount of asset into the Silent, an adversary can link the Silent account to her, since a new account will be added into the multi-asset shielded pool ${\sf sp}$. Based on this fact, currently, the [Deposit](#Deposit) functionality do not attempts to break this linkability issue.
Full privacy feature joins the game while executing the [Transfer](#Transfer) orders which takes place between two Silent accounts. Asset owner forms an anonymity account set of order $\ell$ that includes both sender's and receivers accounts. Then she performs the actual transfer between sender's and receiver's accounts and re-randomizes the remaining accounts' states, so that even if the adversary can observe the anonymity account set, he would not be able distinguish the sender's and receiver's accounts within the anonymity account set.
While moving assets to a DeFi with [Interact](#Moving-funds-to-a-DeFi), asset owner can keep her Silent account hidden within the chosen anonymity account set, destination address and the amount will be seen by an observer. Accordingly, while moving assets from a DeFi to an Silent account, asset owner should create a new Silent account to assure unlinkability.
In order to minimize the linkability probability, during the [Withdraw](#Withdraw) order, the asset owner should use a fresh Ethereum address. Even so, due to the Ethereum's transparent structure, the whitdrawal amount and recipient address will always be visible to the observers.
Fixed size anonymity set utilization,
- lets Silent users have a form of *plausible deniability*; since the users specify anonymity sets themselves, no one can tell if a user meant to be involved in a given transaction, or if their address was simply used in an anonymity set without their consent, and
- holds *privacy against insiders*; since different random scalars are used for re-randomization of decoy accounts, even a decoy account owner who is included in an anonymity set, would not be able deduce extra knowledge from the transaction.
## References
1. [GM15](https://eprint.iacr.org/2014/764.pdf) - Groth, J. and Kohlweiss, M., *One-out-of-many proofs: Or how to leak a secret and spend a coin*
2. [Groth16](https://eprint.iacr.org/2016/260) - Groth, J., *On the size of pairing-based non-interactive arguments*
3. [FMMO18](https://eprint.iacr.org/2018/990.pdf) - Fauzi, P., Meiklejohn, S., Mercer, R. and Orlandi, C., *Quisquis: A new design for anonymous cryptocurrencies*
4. [BAZB19](https://eprint.iacr.org/2019/191) - Bünz, B., Agrawal, S., Zamani, M. and Boneh, D., *Zether: Towards privacy in a smart contract world*
5. [Diamond21](https://eprint.iacr.org/2020/293.pdf) - Diamond, B.E., *Many-out-of-Many Proofs and Applications to Anonymous Zether*
6.
...
Sign in with Wallet
Connect another wallet