DeGate is a decentralized order book exchange based on a Zero Knowledge (ZK) Rollup. It and allows assets to be listed permissionlessly and transactions to occur in a trustless way. Further, DeGate provides various features, including Limit Order, Market Order, Grid Trading, making it a complete and user friendly experience.
| Terms | Description |
|---|---|
| Layer 1 (L1) | Layer 1 refers to a base blockchain network/protocol that validates and finalizes transactions. |
| Layer 2 (L2) | Layer 2 refers to scaling solutions for the blockchain layer 1 network that handles transactions off the layer 1 network and at the same time, benefits from layer 1 security, data availability, and decentralization. |
| Asset Merkle Tree | The asset Merkle tree is a Merkle tree that stores all important data of DeGate's accounts and assets. |
| Entire Merkle Tree | The entire Merkle tree is a Merkle tree that stores all data of DeGate's accounts, assets, and orders. |
| Zero Knowledge Proof | A zero-knowledge proof is a way of proving the validity of a statement without revealing the statement itself. |
| zkSNARK | zk-SNARK refers to a proof architecture where one can demonstrate ownership of specific knowledge, such as a secret key, without disclosing that knowledge and without interacting with either the prover or the verifier. |
| ZK-Rollup | Zero-knowledge rollup is a layer 2 scaling solution that bundles transactions into batches that are executed off-chain where the summary of the change representing all the batched transactions is submitted into the blockchain. This increase throughput on the blockchain network by moving computation and state-storage off-chain. |
| DeGate Account | DeGate account is used to track portfolio assets, place orders, facilitate deposits, withdrawals, and transfers in DeGate protocol. |
| Exodus Mode | Exodus mode allows users to retrieve assets in their DeGate account without the involvement of any third party. When the exodus mode is activated, DeGate smart contract rejects receiving new zkBlock data (all off-chain activities will cease). DeGate protocol will only support the withdrawal of user assets back to their wallet address. |
| Force Withdrawal | Force withdrawal is a smart contract function that allows users to initiate a withdrawal request that forces DeGate node(s) to execute the request within a stipulated timeframe. |
| Shutdown Mode | Shutdown mode can be activated by the DeGate protocol which returns all assets to users. |
| ZKP-Worker | ZKP-Worker generates zero-knowledge proofs through the circuit based on the data passed by the operator. |
DeGate is a Layer 2 network based on ZK-Rollup. Before using the Layer 2 network, the user needs to deposit funds on Layer 1 first.
Most user interactions occur on Layer 2, with a small proportion of interactions such as deposits completed on Layer 1. All state changes are stored in two Merkle trees(Entire Merkle Tree & Asset Merkle Tree) on Layer 2. To guarantee data availability, the root hash generated by DeGate from the two merkle trees is periodically posted to Layer 1 by ZK-Rollup via Calldata , together with the changes of the Asset Merkle Tree.
The Asset Merkle Tree is the Merkle tree dedicated to Exodus Mode, it only stores the user account and asset info, the change of which will be brought to Layer 1 via Calldata by ZK-Rollup so that any user can rebuild Asset Merkle Tree through historical blocks. You may refer to Circuit Design Document - Asset Merkle Tree for more details.
The Entire Merkle Tree not only maintains the user account and asset info but also user trading history. The Asset Merkle Tree can be regarded as a subset of the Entire Merkle Tree.
Based on Entire Merkle Tree and Zero Knowledge proof, DeGate makes the Layer 2 highly available and as safe as Ethereum Layer 1.
For more details, refer to Circuit Design Document - Entire Merkle Tree
All funds deposited by users are stored in the smart contract of Layer 1, which can neither be transferred by any account in DeGate nor locked by the smart contract itself. Users can request to withdraw their funds at any time and complete their withdrawal within a set period of time.
In order to enhance product functionality and safety, products can evolve and improve sustainably, DeGate smart contracts deployment adopts a delayed upgradable scheme. In the scheme, the admin rights to upgrade the contract are jointly managed by the Timelock contract and HomeDAO multi-signature account. When an upgrade occurs, DeGate users have at least 45 days to review the upcoming transaction and take action to decide whether to continue using DeGate, thus ensuring the highest level of trustless.
Users can withdraw their assets from Layer 1 through Exodus Mode in the event that DeGate stops operation for any reason or accident.
DeGate supports permissionless listing on tokens and trading pairs, in a process similar to Uniswap.
DeGate supports access using Ethereum wallets, so there is no entry barrier for Ethereum users to use DeGate, no need to prepare a dedicated wallet, and no need to transfer assets across chains.
As a fully open protocol that is permissionless in its use, listing, or trading, DeGate requires both functional and economic security considerations. DeGate is the only decentralized exchange order book protocol that has implemented permissionless listing at this time.
To ensure asset security, DeGate features the following:
- Subsidy of Processing Fee for Deposit.
- Token Parameter Configuration.
- Specified gas fee token for trading pairs.
- Risky price.
- Minimum order value.
- Risky orders.
- Blacklist.
- Blacklist removal.
For more details refer to Economic Security
Note: Though the costs of the gas fee is still higher on DeGate than CEX, DeGate stands in contrast to CEX in a number of ways, including entry barriers, transaction openness, and capital security. What's more, it provides a similar trading experience as the CEX exchange.
Contract on Layer 2 only accepts ZK-Rollup transactions posted by nodes in the whitelist.
Usually, transactions on Layer 2 can only be regarded as complete when they are confirmed on Layer 1. But in DeGate, transactions except withdrawals confirmed on Layer 2 are regarded as finished, which implies that users don't have to wait for the block posted to Layer 1. This is a huge improvement.
For withdrawal transactions, users have to wait for Layer 1 to confirm for security consideration.
Transactions will be packaged into one block before being posted to Layer 1 through ZK-Rollup, with a maximum of 355.
As high-frequency trading, Spot Trading has been optimized by aggregating up to 9 transactions from up to 6 users into one, which is called a 'Trade aggregation'. Therefore, a block from Layer 2 can contain up to 355 * 9 = 3195 spot transactions matched.
All state changes by transactions occur on Layer 2, while Layer 1 only records the roots of the two trees, significantly reducing gas cost.
Posting transactions to Layer 1 one by one is high cost, so DeGate optimizes by packaging a bunch of transactions into one block. In this way, all transactions in the block will share the baseFee required on Layer 1, which reduces the cost of each transaction.
Asset Merkle Tree is dedicated to Exodus Mode in DeGate. It differs from the implementation of Exodus Mode of Entire Merkle Tree, that it doesn't carry historical trading info when posted to Layer 1. Instead, it carries only the users' account and asset change info, which saves gas for the user.
Transaction data are stored on Layer 2, for Layer 1 only records the root hashes of the two merkle trees ( Asset Merkle Tree and Entire Merkle Tree ), which greatly reduces data storage costs. And as we mentioned in Asset Merkle Tree, additional data will be brought to Layer 1 via Calldata.
After much research and discussion, DeGate finally chose Groth16 for its zero knowledge proof. Groth16 is widely used and applied by many leading projects, and it has a rich library, making it friendly for developers. It also allows DeGate to achieve fast proof generation, lower ZK-Rollup cost within acceptable security limits.
DeGate has invited multiple trusted institutions or any users to participate in the process of Zero Knowledge Proof Trusted-Setup, which generates proving key and verifying key that are both public and open to challenge. The proving key is used for a proof generation while verifying key is used for verification. For more details about Trusted-Setup please refer to the document.
DeGate hardcodes the verifying key into the contract on deployment, so no one has the privilege to delete or replace it after deployment.
- DeGate passes the Layer 2 block to the ZKP-Worker.
- ZKP-Worker parses the block, and performs a check on data accuracy according to circuit logic.
- ZKP-Worker hashes all transactions and block info, and the hash result is used as the public input of the circuit.
- Using base library EthSnark a proof is generated with the proving key generated by Trusted-Setup.
- DeGate posts the proof and block data to Layer 1.
- Layer 1 performs hash calculation on the received Calldata.
- Layer 1 verifies the Zero Knowledge Proof with the hash and the verifying Key.
The trading system matches and orders the trades
Due to the high efficiency of the trading engine, DeGate has a real-time trading experience. e.g. in the matching of user's orders, The user's transaction is considered complete when it is sequenced in the trading system without waiting for the posting of ZK-Rollup to Layer 1.
The block producer of Layer 2.
The operator is the node that submits blocks to Layer 1. It receives transactions from the trading System, packages them, and generates proof by invoking ZKP Worker, then posting them to Layer 1.
The operator holds a DeGate account and will use this account's asset private key to sign a block when posting a block.
All trading fees and gas fee are charged directly by the Operator account.
ZKP Worker is a proof generation service with cluster deployment. It can perform proof generation efficiently.
Smart contract deployed on Layer 1 is responsible for a series of functions, including data verification, proof verification, deposit, withdrawal, and so on.
The funds deposited by the user exists on Layer 1. Under normal circumstances, DeGate will serve the withdrawal requests after the request is submitted to Layer 1 with valid proof.
The trading system and operator have higher privileges like the ability refuse to serve a specific user. Therefore, DeGate provides forced withdrawal to avoid this.
Forced withdrawal allows users to initiate a withdrawal request directly from Layer 1. Regardless of whether the withdrawal request is legal or not, the withdrawal must be processed within a specific time, otherwise, anyone can invoke a smart contract to shift DeGate into Exodus Mode.
Once DeGate steps into Exodus Mode, the process cannot be reversed. In this case, users can only withdraw funds, and no one can generate a block in DeGate anymore.
Users need to crawl blocks (crawl Calldata) by themselves to get all users' account and asset info for recovering the asset tree. Then they provide the asset tree info to Layer 1 smart contracts and withdraw the assets belonging to them.
For smart contract implementation details, please refer to [Exodus Mode] article (./Smart%20Contract%20Design.md#exodus-mode-1)
DeGate has three modes of operation: normal mode, exodus mode and shutdown mode.
DeGate is in normal service status and can produce blocks normally.
Refer here.
Shutdown mode is activated by DeGate itself and is irreversible. It is activated when DeGate will not continue operating.
In shutdown mode, DeGate can continue generating blocks, and DeGate can withdraw funds for the user. The funds can only be transferred to the user's wallet.
DeGate uses an EdDSA signature in the circuit, which is friendly to zero knowledge proof and can be executed efficiently in the circuit.
Here is the EdDSA signature data format:
Signature {
Rx (254bit)
Ry (254bit)
s (254bit)
}
When EdDSA public key is included in Calldata, it will be compressed from 64bytes to 32bytes.
EdDSA Technical Reference Document
DeGates supports multiple on-chain signature verification modes:
- EIP712
- ETH_SIGN
- ERC1271 pass-through for smart contracts
DeGate also supports the trader system where each DeGate account has two private keys, one for asset management and one for trading. The asset private key has greater privilege than the trading private key. Both private keys can be used to create EdDSA signatures for transactions, but the asset private key can also be used to update the trading private key. The asset private key can be used to set the authority of trading private key for spot trading, transfer, and withdrawal respectively.
For institutions, the institution administrator can transfer a trading private key to a trader while keeping the asset private key.