You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: DeGate Protocol Specification Document.md
+2-3Lines changed: 2 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -39,9 +39,8 @@ For more details, refer to [Circuit Design Document - Entire Merkle Tree](./Circ
39
39
## No Limitation On Deposit/Withdrawal
40
40
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.
41
41
42
-
## Certainty of Smart Contracts & Circuits
43
-
DeGate smart contracts and circuits do not include any code upgrade logic. Once Smart Contracts & Circuits are deployed, no one can update them.
44
-
42
+
## Delayed Upgradable of Smart Contracts
43
+
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.
45
44
46
45
## Asset Independence
47
46
Users can withdraw their assets from Layer 1 through Exodus Mode in the event that DeGate stops operation for any reason or accident.
Copy file name to clipboardExpand all lines: Smart Contract Design.md
+4-3Lines changed: 4 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -70,7 +70,7 @@ The validaty of conditional transactions is enforced by both zk-SNARKs and the s
70
70
71
71
A zk-SNARKs key pair is composed of a proving key and a verifying key. The proving key is used to generate proofs, while the verifying key is used for verifying proofs. Refer to "trusted setup" for more details about how these keys are generated.
72
72
73
-
On the off-chain side, the operators generate the proof through the circuit and proving key; On the on-chain side, the smart contract selects the corresponding verifying key by zkBlock size to verify proof. Different zkBlock sizes correspond to different verifying keys, and the keys are hardcoded into the smart contracts, so once deployed they cannot be changed. One zk-SNARKs key pair is unique to one circuit, meaning that changing keys will result in changing circuits. To make DeGate fully trustless, no verifying keys are allowed to be updated.
73
+
On the off-chain side, the operators generate the proof through the circuit and proving key; On the on-chain side, the smart contract selects the corresponding verifying key by zkBlock size to verify proof. Different zkBlock sizes correspond to different verifying keys, and the keys are hardcoded into the smart contracts. One zk-SNARKs key pair is unique to one circuit, meaning that changing keys will result in changing circuits.
74
74
75
75
76
76
Zk proofs are generated by operators, embedded inside zkBlock, then verified by smart contract using a hardcoded verifying key. To generate zero-knowledge proofs, DeGate takes Groth16 for zk-SNARKs, which is based on the ALT_BN128 curve. There are several precompiled opcodes ( ecAdd/ecMul/ecPairing, added in EIP-196 and EIP-197) for this curve that make verification efficient.
@@ -156,6 +156,8 @@ When using DeGate, users may need to pay different fees depending on the operati
156
156
157
157
For scenarios and fees,please refer to DeGate product documentation for details https://docs.degate.com/v/product_en/concepts/protocol-fees
158
158
159
+
## Delayed Upgradable of Smart Contracts
160
+
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.
159
161
160
162
# Contract Implementation
161
163
## Overview
@@ -742,8 +744,7 @@ About gas cost for verification :
742
744
## About Trustless
743
745
User doesn't have to make any trust assumptions when using the DeGate contract, as "trustless" is guaranteed by the following factors:
744
746
745
-
- Contracts are immutable: DeGate does not use proxy mode, hence no change can be made after deployment.
746
-
- Circuits are immutable: BlockVerifier contract does not allow verifying keys to be changed.
747
+
- Contracts and circuits are upgradable with a delay. DeGate users have at least 45 days to review upcoming transactions and take action in advance.
747
748
- Forced withdrawal can be made by users to force the operator to process the withdrawal request, otherwise, the exchange will shift into Exodus Mode.
748
749
- Users can rebuild the whole Asset Merkle Tree by crawling Calldata in blocks.
749
750
- In Exodus Mode, users can submit merkle proof of Asset Merkle Tree to withdraw funds from Layer 1 directly.
0 commit comments