A few weeks ago, I gave a lightning talk about Commonwealth Crypto’s vision for non-custodial cryptocurrency trading at Underscore VC’s Future of Blockchain Summit in Boston. In this post, I’ll share the key ideas and some slides from my talk.
The perils of custodial trading
Today, centralized cryptocurrency exchanges typically use custodial trading. With custodial trading, when users wish to trade on a centralized exchange, they must first deposit their coins at the exchange; this is done using an on-blockchain transfers of coins from the user’s own wallet to the exchange’s wallet. Trading occurs within the databases of the centralized exchange, and is not recorded on the blockchain. Finally, once trading is complete, users regain custody of their coins by withdrawing their coins from the exchange; that is, the exchange uses an on-blockchain transaction to transfer coins from the exchange’s wallet back to the user’s wallet.
Custodial trading at a centralized exchange exposes the user to serious counterparty risk —if the exchange is compromised, the exchange may refuse (or be unable) to withdraw coins from the exchange’s wallet back to the user’s wallet. This risk has been realized at a large number of centralized exchanges, starting with the famous 2014 hack of Mt. Gox and subsequently affecting several well-known centralized exchanges, including BitFloor, Poloniex, Bitstamp, and, more recently, coincheck and BitGrail.
The promise of non-custodial trading
Non-custodial trading promises to eliminate (or at the very least, limit) counterparty risk. With non-custodial trading, users no longer have to deposit their coins at a centralized exchange. User coins remain housed in user’s own wallets, instead of trusting the exchange’s wallet with custody of their coins.
That way, if the exchange is hacked and coins are stolen from the exchange’s wallet, the user’s coin are not at risk.
We’ve seen a vast number of projects tackling the problem of non-custodial trading (many of which are called “decentralized exchanges”). Each of these projects seeks to realize the promise of non-custodial trading. But the devil is in the details.
In this post I’ll dig into some of these details, and describe where our solution fits into the design space.
Who do we trust?
The promise of non-custodial trading doesn’t come for free. We usually need to make some sort of security assumption to ensure that user’s coins remain secure even if the exchange (that the user is trading on) is hacked. Here are some of the security assumptions that we’ve seen in the ecosystem.
Trusted third party. In cryptography, the classic solution to the problem of trust is to introduce a trusted third party, which is just a centralized party that assures security between other (mutually untrusting) parties. Security holds as long as the trusted third party is not compromised.
We see trusted third parties all over the cryptocurrency ecosystem. Perhaps the most famous of these is BitGo, who is “trusted by market leaders” to secure transfers of cryptocurrencies from one wallet to another.
Trusted gateway. Sometimes, a trusted third party manifests as a trusted gateway. Waves is a “decentralized exchange” platform that comes with its own Waves blockchain. Users deposit bitcoins at a Waves gateway and get “WAVES bitcoins” that can then be traded on the Waves blockchain . These gateways must be trusted, however. If the gateway is compromised, the user may not able to convert her “WAVES bitcoin” back into regular bitcoin when she is finished trading.
Trusted execution engine. One way to eliminate custodial risk is to rely on trusted hardware. The Tesseract project prevents theft of user coins by assuming that any code run inside the Intel SGX enclave is secure and cannot be compromised. That way, any coins the user deposits at the exchange are safe even if a thief “gains complete physical access to the machine in which the funds are stored”. All bets are off, however, if the SGX enclave is compromised.
The blockchain. In all of the security models I mentioned above, security is compromised if the trusted execution engine / third party / gateway is compromised.
What is far more appealing to us at Commonwealth Crypto, is to trust the blockchain itself. After all, we are trading cryptocurrency. That cryptocurrency should have very little value if the blockchain backing it is insecure. As such, we might as well trust that blockchain for security, and completely avoid the requirement that the trusted party is not compromised.
This approach has been used in a variety of other projects as well, including the Lightning Network and the 0x protocol.
What’s the threat model?
Before leaving the topic of security, let’s spend a minute on threat models.
Almost all non-custodial trading systems provide security before and after each trade. ShapeShift (and its many siblings) ensure the coins are never at risk before a trade begins, and after the trade completes. Here’s how a ShapeShift of bitcoins to litecoins works. First, bitcoins are transferred from the user’s bitcoin wallet to ShapeShift’s bitcoin wallet. Next, litecoins are transferred from the ShapeShift’s litecoin wallet to the user’s litecoin wallet.
Notice that the user’s coins are safely held in the user’s wallet before and after each trade. However, the user’s coin are at risk in the middle of a trade. If ShapeShift is hacked, for example, it might receive the user’s bitcoin’s but then refuse to transfer the user’s litecoins.
At Commonwealth Crypto, we are working with a more aggressive threat model. We want to provide security even in the middle of trade.
To achieve this, trades on our platform are atomic swaps. In an atomic swap of 1 bitcoin for 100 litecoin, it is cryptographically guaranteed that: (1) if the user transfers its 1 bitcoin to the exchange, even a malicious exchange cannot prevent the user from claiming her 100 litecoin, and (2) if the exchange transfers its 100 litecoin to the user, even a malicious user cannot prevent the exchange from claiming its 1 bitcoin.
Centralized or peer-to-peer?
One of the biggest differentiators of our approach is that our non-custodial trading system is centralized. That is, each of our trades involves a transfer of funds from user Alice’s wallet to the exchange’s wallet. By contrast, manyplatforms support peer-to-peer trading, where each trade involves a transfer of funds from user Alice’s wallet to user Bob’s wallet.
We think that the key advantage to the centralized approach is that it does not create a closed system. That is, users of our non-custodial trading system can trade with any other user of the centralized exchange, even those users that do not use our non-custodial trading system. By contrast, a user Alice of a peer-to-peer non-custodial trading system, can only trade with a user Bob of that same peer-to-peer non-custodial trading system. Hence the closed system.
We think the centralized approach will lead to better liquidity for traders, since the counterparty to their trade can be anyone at the centralized exchange. In other words, our system is simply used as a non-custodial settlement leg for trading on the centralized exchange. Trading itself can proceed as usual, using the centralized exchange’s existing orderbook.
That said, the centralized approach is likely to be subject to more regulation than the peer-to-peer approach.
Off-blockchain vs on-blockchain trading?
Finally, many “decentralized exchange” protocols, most notably the EtherDelta protocol, require individual trades to execute on the blockchain. In other words, the trade is executed by the blockchain itself.
On-blockchain execution comes with several issues.
First, it can be slow. The speed of the trade is limited by the speed at which the blockchain confirms blocks. For Bitcoin, the expected time to confirm a single block is 10 minutes; many centralized exchanges will only accept a bitcoin deposit only after its corresponding bitcoin transaction has six confirmations(expected time, 1 hour).
Second, scalability is a challenge. If each individual trade needs to be confirmed on the blockchain, and a healthy trading ecosystem leads to many trades, then the blockchain itself will be clogged up with transactions resulting from each individual trade. Note that today’s custodial trading ecosystem avoids this problem, since the only transactions that need to be confirmed on the blockchain correspond to deposit and withdrawal of coins from the exchange. (Clogging does happen; remember the CryptoKitties phenomenon?)
Third, front-running and griefing can become a problem. Simply put, on-blockchain settlement often requires that you tell all the nodes on blockchain about your trade, before that trade is complete and confirmed on the blockchain. This can lead to race conditions. For instance, an adversarial blockchain node can learn the details of your trade, and attempt to profit from it by front-running your trade with its own trade.
These on-blockchain speed, scalability, and front-running issues have motivated us to design protocols where individual trades are executed off-blockchain.
Our protocols do this using an approach that is similar to that of the Lightning Network:
Before trading begins, both the user and the cryptocurrency exchange post on-blockchain escrow transactions. These escrow transactions prove that they hold enough coins to collateralize the trades they plan to engage in.
Then, once the escrows are established, the user can execute multiple off-blockchain trades, as long as trades don’t exceed the value in escrow and the escrow has not expired. Each trade simply involves sending off-blockchain messages between the user and the exchange. This way, we can avoid front-running and griefing.
Finally, each escrow is closed prior to its expiry time by an on-blockchain cashout transaction. Each cashout transaction releases the coins from the escrow and frees them up to be used elsewhere.
In Sum: The Commonwealth Crypto Approach
There are lots of ways to tackle the problem of counterparty risk. Our approach enables fast off-blockchain trading using a centralized exchange’s existing orderbook. We use an aggressive threat model (security must hold even during a trade) and minimal security assumptions (the exchange is untrusted, and users need only trust the blockchain itself).
I’m looking forward to sharing more details about our technology roadmap and vision for cryptocurrency trading in the coming months! But for now, we will continue to build.
