noir-lang
Singularity - Darkpool proposal with ZK (Noir-lang) and FHE #6320
Replies: 2 comments 4 replies
-
|
Hi @miaoabcd, thank you for submitting the proposal! Could you elaborate on:
|
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
Here's how it's utilized: Additionally, Noir.js is employed on the front end (FE) to manage keys and generate the necessary zero-knowledge proofs on behalf of traders. This integration allows users to interact with the protocol securely and privately. Order matching is performed within an FHE environment by the "BOOK" nodes (bookies) and not within Noir. The process is as follows: Order Matching Process: Traders encrypt their orders and submit them to the bookies. The bookies engage in an FHE protocol to compute order matches without decrypting the orders, thus preserving privacy. |
Beta Was this translation helpful? Give feedback.
-
|
Ah I see. In that case, is it right to understand the trust assumptions of this project as the combination of:
(If yes, could you elaborate on what consensus protocol will the "BOOK" use?) |
Beta Was this translation helpful? Give feedback.
-
|
Yes, thats correct, |
Beta Was this translation helpful? Give feedback.
-
|
Deadline to update proposals is now extended to October 28th, 2024 if it helps buy a bit of extra time to supplement details. Good luck! |
Beta Was this translation helpful? Give feedback.
-
Summary
In the world of financial trading, dark pools have emerged as a critical tool for traders seeking to execute large orders without revealing their intentions to the wider market. Traditional dark pools -- privately organised exchanges or forums -- allow institutions to transact away from public eyes, preventing undue market movement that might arise from the broadcast of a significant trade. However, these centralised dark pools, though hidden from the public, still entrust a central authority with the confidential details of their trades, presenting concerns around security, trustworthiness, and potential misuse of private data. There are numerous examples of fines levied against central authorities that have broken this trust.
The use of decentralised networks, and recent advances in zero-knowledge proofs and cryptographic computing offer an opportunity to disintermediate dark pools; enhancing security, ensuring privacy, increasing transparency and fairness, all while reducing (or even removing) the need for trust. But to date, despite this gap in the market, no one has successfully developed a decentralised dark pool. Portal Gate seeks to bridge this gap. By introducing a decentralised dark pool protocol, Singularity promises to revolutionise the large institutional trading of cryptocurrencies and other blockchain-based assets by offering a protocol where traders can execute their strategies with complete privacy, without compromising on the core benefits of decentralisation.
The decentralised web3 dark pool protocol ensures complete privacy in trades, shielding both trader identities and order details.
The system employs three core layers:
And two support layers
The combination of zero-knowledge proofs, fully-homomorphic encryption (or MPC), and reputation games offers better computational efficiency and reduced protocol complexity compared to alternatives.
Please note that this darkpool will be the latest product developed by the Singularity team which has been building privacy infrastructure using Noir language since early 2023. www.thesingularity.network.
Methodology
The FE
FE is the user interface on the browser side. Traders interact with it in order to deposit, withdraw, trade, and generally interact with the protocol. It is backed by noir.js to take care of managing keys and producing zero-knowledge proofs on behalf of traders.
The SINGULARITY
The singularity is an on-chain smart contract that pools together all assets of all types of all traders. It is so named because to all observers all protocol transactions appear to come from this one smart contract. In this way, it provides anonymity to its users, where more users means more anonymity.
The singularity uses a multi-asset UTXO model. This means that assets of different types share anonymity with each other, helping to increase overall privacy for low-liquidity assets.
Notes
To participate in the protocol, traders must first deposit assets into the singularity. During this process, the trader creates a zero-knowledge note that contains all the information about their deposit: the asset type, the amount, and the owner. These are known only to the trader.
Similar to normal UTXO based models, traders can use multiple notes as inputs to transactions, or even merge multiple notes into one.
The total balance of the trader in the protocol is represented by the sum of all of their unspent notes (see below for details on spending). Since only the traders know the details of their notes, their balances are fully private. In this way, the singularity can be used for mixing.
Note that because deposits necessarily come from a standard on-chain address, they should not be considered anonymous or hidden.
A similar argument exists for withdrawals. While deposits and withdrawals should not be considered private, all interim transactions can be considered to be private.
Notes are defined as follows:
Note = H(asset, amount, secret, pub_key)and nullifiers are defined as follows:
Nullifier = H(H(secret), pub_key)for some hash function
Hand some randomly generated field valuesecret. Thepub_keyis a Schnorr public key where the corresponding private key is used to authorise transactions.When creating notes, the note is appended to an append-only Merkle tree and the root of the new Merkle tree is stored permanently.
When spending a note, the user must reveal the corresponding nullifier, and prove in zero-knowledge that (a) the nullifier is related to the note and (b) the note is in the Merkle tree. The smart contract will check that the nullifier is unique and that the proof is valid.
Any of these stored Merkle roots can be used (allowing for writes to happen concurrently with reads) but users should prefer the latest Merkle root for their own privacy.
Swaps
Two traders can use the singularity to swap notes in order to settle trades that have been discovered. The discovery of trade and the communication of its details have nothing to do with swaps or settlement and are assumed to happen in other parts of the protocol (e.g. the Book) or a completely different protocol (e.g. it could even happen manually over Telegram).
Swaps are just the settlement layer—a way for traders to swap an exact amount of one asset for an exact amount of another. In principle, users can use the swap feature of the protocol without engaging at all with other features of the protocol (such as the book). In practice, we expect most users to find counter-parties to swap with (and the details of those swaps) via the Book (see below).
After finding a counterparty and negotiating the details of their swap, traders will mutually sign the details of the swap. Then, either trader can use these signatures to construct a zero-knowledge proof that changes ownership of the notes. Both traders do not need to be online for this step. Swaps are atomic, meaning that the swap either both sides of the swap happen, or neither side happens; both traders are always left whole.
Although swaps are atomic, it is worth noting that swaps are independent of orders in the Book and the “full swap” does not have to correlate with the “full order”.
For example, consider 2 traders, Alice and Bob. Alice wants to purchase 1 BTC for 20 ETH. Similarly, Bob wants to sell 2 BTC for 35 ETH. These can be thought of as their “full orders”. Alice and Bob both submit their orders to the Book and through this process discover that they are a partial match. Alice and Bob then create the details of a swap where Alice buys 1 BTC from Bob in exchange for 17.5 ETH. This is the “full swap”. While it is entirely compatible with their orders, it is not exactly the same. It is the full swap that must happen atomically, not the order. It is also entirely possible for Alice and Bob to have found each other without using the Book (perhaps through a mutual third-party that knows both of them).
Interactions between a trader and their FE are generally anonymous and hidden to the rest of the protocol.
The Noir language would be used to build these circuits
The BOOK
The book is a fully private off-chain order book operated by a decentralised group of book nodes (also known as bookies, which are roughly equivalent to miners in other protocols). It is generally expected that the book will be used for traders to find each other and communicate about their intents to swap in a way that is fully private.
Bookies are special fully homomorphically encrypted (FHE) nodes that are collectively responsible for operating the order book in a trust-less and decentralised way. The order matching algorithm for the book is run inside a FHE environment (without the need for trusted hardware) which allows matching to be done without revealing any information about the orders being matched.
FE encrypt orders and submit orders to the bookies. API nodes know the orders, but no one else does.
Bookies engage in a FHE protocol to compute which orders are matched and which are not.
Bookies reveal the results of the order matching algorithm but do not reveal the original orders. This allows traders to know who they’ve matched against without revealing their order.
Traders that have been matched then communicate with each other directly for settlement using the swapping capabilities of the singularity.
Bookies are running under a sort of consensus mechanisms to compete each other to do the matching jobs
The AUTOMATON (optional)
The automaton is an anonymous (but not hidden) automated market maker. Because automated market makers by necessity have a publicly knowable price point, it is impossible to make them fully private. However, the automaton is anonymous.
Traders can submit a transaction from the singularity to deposit into the automaton. Because the singularity is anonymous, so too is this deposit. Both assets must be deposits such that the
xy = kconstraint is maintained.Traders can submit a transaction withdrawing their funds back into the singularity at any time. All of the usual functions and trade-offs of an AMM still apply (e.g. impermanent loss).
Orders that fail to match against anything in the book are matched against the automaton to help boost liquidity.
Or alternatively, the public liquidity pool such as Uniswap could be integrated here to replace the Automaton, through Singularity to add/remove liquidity and swap, wallets that interact with would be obfuscated.
Or alternatively, if built on Aztec , the Aztec ZK Box through to the uniswap portal could be leveraged to fulfil the same needs
RELAYERS
Relayers are responsible for submitting meta-transactions on behalf of users. That is, relayers pay the gas costs for user transactions. This is necessary because gas costs must be paid to the base layer blockchain, which is usually public, and so the anonymity of users would be compromised if they paid their own gas.
Assumptions
Compatibilities
EVM, all emv-compatible chains would be supported, leveraging Noir language to build circuits and corresponding on chain ZK verify contracts.
Aztec, if built on Aztec, all UTXO and private transaction related stuff would be handled by Aztec naturally
Multi-signatures
Authorization of transactions is done using Schnorr signatures which are trivially able to be generated using a standard threshold signature scheme. This allows trading groups to distribute authorization capabilities.
The FHE algorithms
In order to match orders under FHE environment, all orders need to be encrypted by the same key(s), thus multi-encryption by different public keys in different orders need to be compatible with FHE to maximus the matching efficiencies.
Where the design uses a combination of zero-knowledge proofs, fully-homomorphic encryption, and multi-party computation, other protocols often rely primarily (or even solely) on multi-party computation. The 2 major disadvantages of the latter approach are computational efficiency and protocol complexity.
MPC-based protocols that do not leverage FHE are required to prove and verify zero-knowledge proofs within an MPC environment. Zero-knowledge proofs are already computationally intensive to produce, and multi-party computations typically introduce a slowdown of multiple orders-of-magnitude and rely on stable network connections between parties (an often-overlooked assumption that rarely holds in a globally decentralised network). Compounding these 2 slowdowns makes a fully MPC-based protocol impractical for large-scale applications such as order matching engines. In contrast, FME-based computations, while slower than unencrypted computations, are faster than MPC and do not require network communication. Ultimately this makes them more suitable for globally decentralised networks.
The complexity and relative immaturity of the MPC field also makes developing MPC-based protocols significantly harder and more error prone. While this is something that can be overcome, it slows down development times, makes the addition of new features take longer, and is more likely to result in unexpected loss-of-privacy and/or loss-of-funds, requiring a more careful and controlled rollout than would otherwise be necessary.
Timeline & Deliverables
Start Date
1st of Nov
Research & Detail design
1st of Nov - 29th of Nov
Singularity development
2nd of Dec - 27th of Dec
Deliverables: Finalise smart contracts
Book development
2nd of Dec - 17 th of Jan
FE(web application) and Relayer development
19th of Dec - 31st of Jan
Wrap up and testing
3rd of Feb - 28th of Feb
Key deliverables
End of November: Product design documents and specifications
End of December: FInalise smart contracts
End of January: Darkpool deployed on testnet
Teams
Singularity development team with members including Jay X (CTO/Engineering lead), Loong W (ZK lead), Maksym S (lead backend developer) and Peter P (lead front end developer). This darkpool will be the latest product developed by the Singularity team which has been building privacy infrastructure using Noir language since early 2023. www.thesingularity.network . Singularity launched in July 2024 with live features including deposit and withdrawal, private OTC swaps, private vesting and obfuscated AMM trading
Jay X: 20 years of experience in leading large technical and engineering teams in both US and China, including in tech unicorns. Successfully exited 2 tech startup as a founder. Full time in blockchain since 2019. Currently responsible for overall design and development across the entire Singularity protocol.
Loong W: Ex-cofounder of Ren Protocol which successfully secured more than $1bn TVL at its peak. ZK expert who has been designing and developing with ZK circuits for 8+ years. Loong focuses on the ZK circuit design and development of the darkpool.
Maksym S: 5 years of experience in smart contract development experience and leading the development of Singularity’s backend infrastructure and smart contracts.
Peter P: 15 years of front end experience and leading front end teams in both large tech companies and startups.
Jay will be the main point of contact for this. Email: [email protected].
Questions
The consensus mechanisms of the Book nodes need to be further explored, potential options are:
Leverage protocols like Eigenlayer
Build a POW/POS type consensus mechanism
Any suggestions or alternatives from Aztec team would be appreciated.
The Automaton, if built on Aztec, we would like to know the status of Aztec ZK Box. Is it ready to be integrated with and/or what does the Aztec ZK Box timeline look like?
Beta Was this translation helpful? Give feedback.
All reactions