How Sacred Works
Technical Details
Tokenomics
Other Sacred Info
Poseidon Function
Check out Sacred's Github here! Please note the github is from the original build on Conflux, we will release the new contracts when we launch.
How Sacred works:
When a user deposits tokens into a Sacred Box, it was mentioned that the user generates a random Sacred Claim. In actuality, it is more true to say that the user generates two values, that we can call k and r, and the Sacred Claim that is submitted is actually the hash of the two values concatenated. The fact that they are actually two separate values plays a role in the anonymous withdrawal of the funds later.
To keep track of deposits anonymously, a Sacred Box takes advantage of a Merkle tree. Specifically, the Sacred Box keeps track of the latest “former” roots as well as some nodes used to generate the next root for the next added leaf. The leaf nodes are the submitted claims, but are not actually stored in the Sacred Box; nor does a person who withdraws ever reference a specifically submitted leaf (this would break anonymity). Instead, a person withdrawing funds provides cryptographic proof that the leaf simply exists somewhere in the tree, and that you can get to it from one of the roots that the Sacred Box stores.
Poseidon Function
Here is a diagram to illustrate a sample 5-layer tree:
In the diagram above, an arrow represents a hash function (from input to output). Actually, this particular function (Poseidon function) takes in two inputs to produce one output; where it appears that there is only one input, the second input is the appropriate hash of 0,0; let P(x,y) be the Poseidon function with inputs x and y, then a node that is shown to only have one child c at level n is actually the hash of c and the hash of … the hash of (0,0), such that there are n recursive levels of hashing (or n+1 total hash operations). This can be represented as P(P(P(P(...P(0, 0)...), 0), 0), c) or P(P^n(0,0), c) where the “exponent” represents recursion.
All the shapes represent nodes. Red nodes are nodes currently stored by the Sacred Box contract, blue nodes are the stored roots, light-blue nodes are those that had been stored at some point, and grey nodes are those that have never been stored (you will notice that the grey nodes are only ever children to one parent node). Parallelograms are the leaf nodes that contain the Sacred Claims themselves (the hash of the concatenated k and r).
Since the Poseidon function takes in two inputs, each root is actually the root of its own “virtual” binary tree; if there are n levels to the entire structure, then each root could be the root of a tree with 2^n leaves, which is a huge amount! However, this tree is never actually generated in its entirety (only the one branch leading to the current leaf) which serves to obfuscate the leaves. Since hashing only works in one direction, there is no way to compute the leaves from a given root; but it is possible to generate a path from a known leaf to a given root, and this path cannot be faked (only by computationally-infeasible brute force). Verifying a path from the leaf to the root requires that the verifier only have knowledge of the root itself, not necessarily of any of the other nodes.
New leaves and their roots are added on the right, and the formula by which the tree is generated (it may seem chaotic in the diagram) is actually specifically designed such that you can get to any leaf from any later-generated root. The n-level structure is designed to support up to 2^n leaves (that’s a lot of leaves!). In actual implementation, the Sacred Box will store several of the latest roots (constantly cycling the oldest ones out for newer ones) to allow for the case where someone deposits just as someone else is calculating a SNARK.
To withdraw, a person simply picks a root currently stored in the Sacred Box and calculates the opening to get to it from the leaf containing their commitment. The person then generates a nullifier h by hashing k, and uses r, k, and the generated opening (along with some other details including address, fee etc.) to generate a cryptographic proof that the commitment exists in the tree. The proof is sent to the Sacred Box, along with the nullifier h. By the nature of the functions, it is impossible to tamper with h (it can be verified that h is the hash of k, without actually knowing k); the contract will add the value h to a “list” of used nullifiers, and check all subsequently submitted proofs to ensure that the h is not reused. Thus, it is impossible to claim the same deposit twice.
Smart Contract Addresses
Coming soon!
Last modified 2mo ago
Copy link