Trustlessness assumes an entirely new meaning in the blockchain space compared to what is traditionally defined in the dictionary as “untrustworthy”. Instead of not inspiring trust, “Trust Less” implies “no need to trust”. It means that participants in a system do not need to trust each other or a third party for the system to function as it should. This new paradigm takes out the trust issue between provider and user.

In a not-trustless financial system, users need to choose who to trust for their money to make sure that

• My money is safe. No one can steal them.

• My account balance is correct. The system cannot mess it up.

• I can withdraw my money whenever I want.

These fundamental needs are ever more important at a time when centralized finance institutions blockchain companies run the risk of collapsing like dominos. But on DeGate, we ensure that these user rights are guaranteed, and users always have the power to control their money.

How does DeGate achieve Trustlessness?

DeGate protocol is built on Ethereum with a Zero Knowledge-Rollup (ZK-Rollup), which consists of on-chain and off-chain components. Smart contracts are deployed on chain, responsible for storing assets, verifying ZK proofs, and providing methods for deposit and withdrawal; Account and assets changes are processed off-chain and rolled up to the on-chain smart contract.

This complex system has multiple components, each imposing challenges in reaching trustlessness. DeGate tackles the challenges through the following features, letting users sleep easy while trading.

1. The protocol has no admin key and is not upgradeable.

An Admin key allows the developers to arbitrarily change the rules of their smart contracts. The admin key is susceptible to attack for decentralized finance(DeFi) projects because it can enable unilateral change of very crucial parameters, including user balances! The vast majority of DeFi projects have the ‘God mode’ admin key, a recipe for disaster. (See for example this Cointelegraph article https://cointelegraph.com/news/how-many-defi-projects-still-have-god-mode-admin-keys-more-than-you-think).

DeGate does not have an admin key. Once the protocol is deployed, its code execution logic is immutable. The smart contract and the circuit program are bound to generate verification keys in the first initialization phase. The contract’s deployment and the circuit program’s binary are always in one-to-one correspondence. Since the on-chain smart contract is immutable, if any part changes in the circuit program, the generated ZK proof cannot be verified by the smart contract. This mechanism ensures the immutability of DeGate protocol. No one can change or upgrade it.

2. Non-custodial protocol means assets cannot be manipulated

DeGate protocol hosts users’ assets in smart contracts and has no central custody of assets. No one can manipulate a user’s assets which are proved by cryptography and secured by the immutable protocol.

3. ZK-Rollup to confirm off-chain state change’s correctness

On DeGate, account changes are processed off-chain and rolled up to the on-chain smart contract. Its ZK-Rollup uses validity proofs to confirm the correctness of off-chain state transitions without having to re-execute transactions on Ethereum.

The ZK-Rollup is secured by two key factors: proof generation and proof verification. The proof generation is undertaken by the relayer through an off-chain circuit program. The relayer collects a large number of transactions to generate a SNARK proof. The SNARK proof is a hash-like piece of content representing the changeset to the state of the protocol. To achieve and prove trustlessness in the blockchain system, DeGate uses immutable open-source smart contracts to verify the proof and update the state atomically. The exchange data is recorded in Merkel trees through the smart contract, and the Ethereum mainnet guarantees security.

This means that users always get the correct balance in their accounts after trading and operations.

4. Users control their assets in DeGate protocol

• When depositing assets on DeGate, users can perform a self-retrieval of assets if the deposit transaction has not been confirmed after a specific duration. DeGate allows users to deposit funds to the smart contract. If the deposit is not processed after a period of time, users can call a smart contract function to retrieve their asset.

• Users always need to sign and authorize operations involving a change in the assets of the user’s account. The transactions can occur and be completed only with the user’s signature. Here is a list of required signatures for the types of operation

• Users can execute on-chain cancellation when cancelling an open order

On DeGate, before an order is fully filled, the order’s signature is effectively valid and can be used for trade. And every order is enforced to require an expiration duration. With each trade, the circuit verifies the signature and expiration date of the orders. If any orders have expired, the verification will fail. The purpose is to reduce the risks if an attacker gets hold of the order’s signature and manipulates the order.

Limit and Grid Trading orders have a default expiration duration. Users can amend the value of the “Expire in” field for their desired expiration duration and cancel their order at any time. The cancellation is instant and free. DeGate node verifies the order cancellation request and cancels the order in the trading system, and the order signature is discarded. But what if you don’t want to trust the node, afraid it still holds your signature and fulfils the order against your will?

DeGate gives users an option to use on-chain cancellation to make it 100% trustless. Users can select a cancelled order and perform an on-chain cancellation request. This transaction requires a gas fee. As soon as the DeGate node has rolled up this cancellation request transaction onto the blockchain, the order will be tagged as closed and can never be matched again. Users can check the calldata to determine if the DeGate node has processed the on-chain cancellation request.

• Exodus mode

DeGate protocol has provided a contingency mode called Exodus Mode to ensure the trustless handling of assets. Exodus Mode allows users to autonomously withdraw their assets if DeGate’s node fails to operate as intended. The operator in the DeGate off-chain node is responsible for generating the zkBlocks and submitting the proofs to L1. If the operator can no longer perform its functions, all off-chain transactions that have not been submitted to L1 will become invalid. Though it is improbable, there is still an availability risk in that the operators all go offline and are unable or unwilling to provide services.

Suppose any forced withdrawal has not been processed for more than 15 days, anyone can trigger a transaction to enable **Exodus mode. **Once DeGate enters exodus mode, users can directly call the DeGate smart contract to retrieve their assets. The smart contract will reject new rollups, implying all off-chain transactions will not be processed where all DeGate account and asset states will remain the same from the last rollup state before the exodus mode was activated. The smart contract will handle all assets based on the final states. To retrieve assets, users will first need to parse all the CallData of the DeGate smart contract to build the Merkle tree, which will provide the latest account and asset states. Using this data from the Merkle tree, they can retrieve their assets from the smart contract. Third-party services can be used to perform parsing of the latest account and asset states.

DeGate’s Exodus mode has been successfully tested. In November 2022, DeGate shut down its Layer 2 node on the Rinkeby network. On this occasion, the community and the team tested the Exodus Mode and withdrew their assets. More about it here https://medium.com/degate/testing-degate-trustlessness-in-exodus-mode-2a510f1d5b8

Collectively, these features respond to the three fundamental needs users have when ensuring asset security:

My money is safe. No one can steal it.

On DeGate, users’ assets are non-custodial and are stored in the immutable on-chain smart contract. The immutable protocol ensures that no one can manipulate it to steal users’ assets.

My account balance is correct. The system cannot mess with it.

Any account’s asset change requires the user’s signature and authorization. The ZK-Rollup data availability ensures that users’ accounts reflect the correct state change and balance.

I can withdraw my money whenever I want.

Users can withdraw their assets autonomously, even in the most unlikely scenario where the operator goes down, enabled by Exodus Mode.

L2beat has a thorough risk analysis (https://l2beat.com/scaling/risk) on major Layer 2 projects, evaluating their security and trustless from State Validation, Data Availability, Upgradeability, and Sequencer & Validator failure. Analysing DeGate through these criteria, the results would be:

• STATE VALIDATION: ZK proofs(SN) — ZK-SNARKS are zero-knowledge proofs that ensure state correctness, but require trusted setup.

• DATA AVAILABILITY: On-chain — All of the data needed for proof construction is published on-chain.

• UPGRADEABILITY: No — The code that secures the system can never change.

• SEQUENCER FAILURE: Force exit to L1 — The user is only able to submit an L1 withdrawal request and force the sequencer to include it on L2. After that, the user exits the system with their funds.

• VALIDATOR FAILURE: Escape hatch(MP) — Users are able to trustlessly exit by submitting a Merkle proof of funds.

These attributes combined make DeGate one of the most trustless Layer 2s.

What to expect

DeGate aims to provide an orderbook experience similar to traditional exchanges, at a similar cost, but with much higher security and decentralization. With these trustless measures in place, DeGate lets users Trade easy, Sleep easy.

DeGate is currently on testnet. Expect the mainnet beta launch by Q1 2023.

LINKS

Website | Twitter | Discord | Telegram | Forum | YouTube | Contact | Join