If the vote is passed, the first milestone proposal will be submitted for the council's consideration. If it is not passed, the proposal will be adjusted.

Proposal application document: https://hackmd.io/@phala/Hy60fQ0sI

Date of proposal: 2020.06

Abstract

We want to build a decentralized dark pool on KUSAMA with all infomation encrypted and stored in a decentralized network. Everything in the dark pool is invisible -- accounts, order book, order history -- except your own orders.

The dark pool is built on Phala Network confidential smart contract. While the inputs, outputs, and the states are encrypted, the execution can still be verified by anyone. The dark pool allows users to trade with confidence, but without exposing any sensitive information.

In general, the protocol is based on TEE-Blockchain hybrid archetecture to help process the encrypted contract data. To further reduce the attack surface, while the order matching happens inside hardware enclaves ephemerally, the persistent assets balance can be protected by ZKP-based private token technology. This combination can achieve a good balance between utility and security.

Protocol

The protocol has two major subsystem: Private Assets, and Confidential Trading Engine.

The Privite Assets subsystem manages the conversion of external assets and the assets used in the dark pool in a privacy-perserving way. It interacts with the Confidential Trading Engine by allowing transferring assets between the two subsystems.

Why Kusama?

1. Kusama is a great place to hack with cross-chain composiability.

   Being a part of Kusama ecosystem, it gets access to all the assets on Kusama. Not like Ethereum who can only trade ERC20 tokens, on Kusama we can access coins (BTC), native token (KSM), external tokens (ERC20 from ETH bridge), and parachain native tokens (ACA, PLM).

   Our design requires a subsystem to manage all the assets (Private Assets). It's supposed to be a pallet, and then deployed as a parachain. Having a single place to manage all the assets can benefit not only this specific use case, but even more developers who want to integrate their DeFi projects with Kusama. A simple scenario: suppose a multi-chain custodial wallet wants to accept assets in Kusama, instead of integrating with all the parachains, it can just connect to this single "assets hub". The pallet can even be deployed to Kusama relay chain in theory.

   Comprate with Polkadot, Kusama is a better place to experiment innovation ideas. The parachains are not so expensive, and new community-driven pallets can also be added to the relay chain potentially.

2. We want to explore a novel collaborative pattern

   We described a roadmap to build a dark pool, and truly believe that it can only be done in Kusama ecosystem. However, it doesn't mean we can or should build it end-to-end. Phala team is good at devleoping TEE-based infrastructure and applications, but that's just a part. To make the final product a success, there are a few other necessary conditions:

   • Kusama parachains to offer rich native or bridged assets
   • ZKP-based private asset protocol to offer higher security
   • Teams with DEX experience to offer domain knowledge, community and operation

   So here we call for the community developers to join the effort to make the first-ever dark pool a real product.

3. Support from the Kusama community

   Of course, we would like to apply for Kusama tresury. In return, the Private Assets pallet will be built as a parachain (or a relay chain pallet), and it will be the unique assets gateway of the dark pool.

   Note that the dark pool is built on Phala Network, which could be a standalone Substrate blockchain, a Kusama parachain, or a Polkadot parachain. Phala Network provides the basic security of TEE environment, but it's irrelevant to the dark pool business logic. The dark pool will always commit to Kusama as the assets are on Kusama.

Development roadmap

The following milestones are listed in a rough order. Some of them can be done in parallel, and some depend on other tasks. Depending on the progress of ZKP-based Private Assets module, the path might be different.

• M1-1: Private Assets

  • Basic functionalities
    • Lock the native token, relay chain token (KSM), and parachain tokens
    • User issued token for assets gateway
    • Assets withdraw
    • Transfer between the pallet and the trading engine
  • Will first implement the naive TEE-based version

• M1-2: Private Assets (ZKP)

  • Same functionalities as naive Private Assets, but whenever possible, switch to ZKP-based version
  • Integrate with ZKP wallet SDK
  • Receiving / sending ZKP token in TEE

• M2: Basic dark pool exchange in confidential contract

  • Implement the dark pool Confidential Trading Engine as confidential contract
  • Interoperable deposit / withdraw with naive Private Assets module
    • Migrate when a ZKP Private Assets module is ready
  • Overall tests of the trading engine

• M3-1: Cross-chain assets integration

  • Deploy Private Assets pallet as a parachain
  • Integrate with XCMP for relay-parachain and parachain-parachain assets transfer

• M3-2: Assets custody gateway integration

  • Integrate with centralized gateways and asset custody module to enable external token deposit and withdrawal.
  • Basic front-end for assets management and deposit / withdraw.

• M4: Productionalize

  • Secure TEE setup: finalize the design of and implement contract replica deployment in Phala Network
  • Liquidity sharing: open source service to provide liquidity between Cybex Dex and Bitcloak dark pool.
  • Documentation and deployable code.