Many people who have been using crypto for a while have experienced some kind of loss on an exchange, including yours truly in the Gox and Bitfinex hacks. Never in history have thieves taken such a large bounty so easily!
Crypto tokens are unique in that they exist only in cyberspace and cannot be easily recovered once stolen (although the upcoming blockchain nervous system on the DFINITY chain may do something about it), making other hacks and insider thefts highly likely.
That is, unless we can create truly decentralized exchanges so that we don’t have to transfer tokens and money to intermediaries.
Such fully decentralized and tamper-proof exchanges should also significantly reduce transaction fees, a critical step in the continued maturation of our industry, but one that has so far been elusive.
However, in this post, I will explain how some recent innovations in cryptography make today’s vision possible.
This article will explain how to create a decentralized token exchange from a smart contract written in Solidity and a Dapp user interface written in HTML/Js, the type you can create with Truffle (for a ready-to-use development environment packaged as a Docker image, including the Cloud9 IDE as well as Truffle and other tools, check out instant-dapp-ide).
While some special accompanying software clients would have to be created to apply the cryptography, we wouldn’t need sidechains, state channels, special consensus hubs, or anything else that either doesn’t exist yet or has its own serious flaws.
Nothing is needed beyond what is already available today!
Therefore, we will describe how to create a crypto-to-crypto exchange on Ethereum (or eventually DFINITY) that will make it possible to trade BTC/ETH and other currency pairs securely and cheaply.
Step 1: Smart Contract Logic
Ethereum smart contracts already provide us with the means to run the logic of two consecutive auction transactions (such as GDAX, Bitfinex, Kraken or Poloniex) on the blockchain computer.
The speed of today’s networks presents real challenges in terms of user experience, as markets may be reorganized within minutes after a new order is submitted and the trade is apparently executed, but solutions are already underway.
Threshold relays will bring finality down to a few seconds (over 50x faster than Ethereum today), and the Casper team is also working on a solution, so we’ll probably be in for some time.
The real challenge is that the tokens we create in smart contracts cannot be trustlessly connected to valuable native tokens on other chains. For example, we cannot create XBT tokens in an Ethereum smart contract that is trustlessly connected to Bitcoin, which we can then exchange for native Ether.
High-level technical description: Here's a code example of a two-auction style swap in Solidity for those who are interested (this was actually one of my first Solidity contracts, written when the language first became available).
There are several design considerations you must take into account, for example, it is necessary to address the problem of HFT "sniping" by arbitrageurs observing price changes on fast centralized exchanges. There are also good reasons to consider using other exchange models, such as single-price batch auctions. These considerations are worth another post if I have time.
Step 2: Threshold Signature Cracking
For simplicity, henceforth we will only discuss custody of Bitcoin on an Ethereum-hosted exchange, although in reality the technique is equally applicable to custody of any native crypto token from within a chain of transactions authorized using ECDSA signatures.
Our requirement is for a large number of independent parties to collectively control a standard Bitcoin address so that users can send Bitcoin there, but Bitcoin can only be transferred after agreement is reached between some threshold proportion of these parties.
For example, let’s say our exchange will have 50 “Guardians” drawn from well-known and independent individuals and companies within the crypto industry.
They must control a Bitcoin address where users can send Bitcoin in exchange for XBT tokens hosted on an Ethereum exchange, and they must be able to distribute Bitcoin from that address to those who redeem XBT tokens.
Traditionally, in cryptography, such functions are created using “threshold signatures”.
High-level technical explanation: The Bitcoin network only relays native “multi-signature” transactions with a maximum of 3 participants, pay-per-script-hash can alleviate some of the burden, but still limits participants to 15.
Now, we can draw the line for the impatient: although Bitcoin and Ethereum transactions are signed using standard ECDSA signatures, and neither natively supports threshold signatures, some innovative researchers recently demonstrated a way to exploit the standard ECDSA signatures Bitcoin and Ethereum use to produce backwards-compatible threshold signatures.
That is, our guardian can create a threshold signature for an address that will be accepted by the Bitcoin network as a standard ECDSA signature that unlocks the UTXO!
You can find a paper describing how to do it here:
• https : //eprint.iacr.org/2016/013.pdf
• https://www.cs.princeton.edu/~stevenag/threshold_sigs.pdf
To be clear, these threshold signature schemes are not the same as the optimized BLS system we use in DFINITY threshold relays, which can combine the outputs of hundreds of signers to create a unique deterministic threshold signature in milliseconds.
In fact, this system is so inefficient that combining our Guardian's signature output does take a long time, and its CPU runs hot, but that's not a problem.
It is perfectly acceptable to charge a modest withdrawal fee to cover computational costs and require withdrawals from our Ethereum-based financial exchange to take a while to process. After all, many people will be happy to have their funds safely on exchange for the sake of convenience!
The application of this technology will allow us to distribute trust among a select number of guardians, allowing them to both accept Bitcoin in return for XBT allocations and allocate Bitcoin when redeeming XBT tokens, thus pegging Bitcoin to XBT tokens in a trustless and secure manner.
Of course, we have to account for the possibility that some guardians may lose their signing keys or get bumped off the metaphorical bus, but threshold signatures allow us to address this problem. We can simply require the output of just 35 of the 50 guardians to create a new signature.
Step 3: Guardian Rewards
We need to create an incentive program for guardians because we want to engage and promote trustworthy individuals and companies that won’t disappear or collude.
The simplest way to do this is to give them a small transaction fee from all withdrawals collected by the exchange.
Step 4: Governance
Decentralized financial exchanges require their own management system since guardians must be elected, software updates to the adopted smart contracts must be made, etc. Therefore, we will design the exchange as a DAO (Decentralized Autonomous Organization).
If these systems become available in time, we may even get a more advanced governance nervous system derived from the DFINITY Blockchain Nervous System technology (the DFINITY team is very hopeful that the BNS will be repurposed in this way).
Within the governance system, token holders with “voting rights” will share in proportion to the small fees collected from transactions. The smart contract will periodically hold a “beauty parade” where potential guardians can apply for positions, which are ultimately assigned by voters.
High-level technical explanation: An attacker could try to buy all voting tokens, then swap out the guardians for their own puppets (typically a DAO 51% attack) and steal deposited funds.
For this reason, after a vote, the contract must exit the guardian only after a certain delay, which can give cryptocurrency holders enough time to safely withdraw their funds (if such an attack occurs). This also applies to the adoption of software updates.
Step 5: Threshold Encryption Settings
Once the set of guardians is set up, they must then set up their threshold signature scheme. This means that some process or protocol must be run to ensure that when we are done each of our 50 guardians has a private “secret key share” that they use to jointly produce a threshold signature that can be used as a single simple ECDSA signature to authorize the ECDSA network to allocate bitcoins from the deposit address.
As mentioned before, the threshold signature schemes cited are actually hacks that create signatures that are backwards compatible with the regular ECDSA signatures currently used by the Bitcoin and Ethereum networks. This means that it is more challenging to set up than the BLS threshold signature scheme used by the DFINITY threshold relay.
The simplest approach would be to perform a trusted setup in a secure ceremony, as the Z-Cash network did recently, and have each guardian signal to the exchange’s smart contract that they are happy with the output before allowing the deposit address to become “active”.
Although the trusted setup process will be much simpler to implement than the one used by Z-Cash, many would like to implement a trustless distributed setup, especially because it is easier to repeat if there is a need to rotate guardians. This will consist of two parts.
The first involves distributing common keys among guardians, and can be done quite simply by applying e.g. IPFS as a log of the messages involved in aggregating and sharing the distributed key generation protocol.
The second part (made necessary by the homomorphic encryption techniques used in the hack) involves the distribution of Paillier key shares. This last part requires careful analysis of execution costs if you want to get your switch up and running quickly!
Step 6: Guardian Client Software
We had to create some special “guardian client software” to monitor the exchange’s smart contracts and regularly cooperate in signing Bitcoin transactions when a user wanted to redeem XBT.
Step 7: Crowdfunding
There should be a crowdsale to collect funds for R&D, and perhaps the first incentive to move funds there (perhaps locking them there exclusively for a period of time) to help bootstrap liquidity.
Note that we may start with just the governance system and then allow it to allocate funds to developers to complete transactions.
Once trading starts happening, we should expect volume to increase rapidly! The underlying costs involved in decentralized exchanges are orders of magnitude lower than centralized exchanges operated by companies, and this will be reflected in transaction fees.
Furthermore, the decentralized system described is also more resistant to hacks and attacks, and you can expect to safely deposit and trade large amounts of cryptocurrencies on such an exchange.
Fingers crossed someone builds this!
Final note: At first glance, decentralized financial transactions appear to make crypto-to-crypto transactions possible. This may be true in the short term. But those interested should check out the PHI system currently being developed by researchers associated with String Labs in Palo Alto.
This mimics the way the commercial banking system works and creates a decentralized “cryptocurrency” that is secured by loan collateral.
Once we get the token on the Ethereum and DFINITY chains (and hopefully within two years), it will be possible to hold the token on a decentralized exchange with the value of the token being similar to that of some fiat currency.
IC content you care about
Technology Progress | Project Information | Global Activities
Collect and follow IC Binance Channel
Get the latest news