BlockTrades was contracted late last year to develop a new blockchain called BitShares EOS. One of the primary goals of this blockchain, as hinted at by the name, is to give the BitShares community access to EOS-style smart contracts. To understand why this is useful, it’s important to have a basic understanding of BitShares and its history.
BitShares was the first high-performance decentralized exchange utilizing blockchain technology to maintain its order books. It supports “smartcoins” that were designed to track the price of fiat currencies like the chinese national yuan and the US dollar using data feeds provided by block producers. These smartcoins often serve as popular “base” currencies in the trading pairs available on the decentralized exchange.
BitShares also supports “user-issued assets” which are tokens that anyone can create and back with some form of value. For example, businesses that operate “gateways” on BitShares issue proxy tokens in exchange for deposits of cryptocurrency. These proxy tokens are directly tradeable on the BitShares decentralized exchange and can later be converted back into the coin they are backed by. This allows users to trade coins like bitcoin and ethereum on the exchange using these proxy tokens.
A trading exchange must support fast matching of market orders, so BitShares was written in compiled C++ code for high performance. This does have one disadvantage, however: it means that in order to add new functionality to BitShares, a new version of the code must be compiled, and the block producers must agree to upgrade to the new version of the software. This means that whenever any new feature is added to the code, a certain amount of politics is involved in getting agreement to use the new software and there’s also some delay while waiting for a sufficient number of block producers to upgrade.
The Ethereum blockchain, by contrast, took a different approach to adding new functionality: smart contracts. A smart contract is code that can be added to the blockchain “on-the-fly” without requiring block producers to upgrade to a new version. This is done by writing smart contracts in an “interpreted language” instead of a “compiled language”. Unlike compiled code, interpreted code can be added to a program (e.g. blockchain software) while the program is running.
In fact, block producers don’t even get to decide if the functionality provided by the smart contract code is necessary or even useful. Just like a single block producer doesn’t get to decide if your transactions are processed, a single block producer can’t stop the addition of new functionality provided by a smart contract.
Because block producers can’t easily prevent the addition of new functionality via smart contracts and don’t get an opportunity to review the functionality of the new software before it’s running on their computer, it’s important that the abilities of smart contracts be limited. For example, it wouldn’t make sense to allow someone to publish a smart contract that stole everyone else’s money. Nor should smart contracts be allowed to wipe the hard drives on the computer running the blockchain software.
Blockchain software wasn’t the first time the need for this kind of security was necessary when dealing with interpreted languages: a similar issue happens with web browsers like Chrome, Firefox, and Internet Explorer. Your web browser can run interpreted software from web sites you visit, so the web browser runs such software in a so-called sandbox to prevent the code from stealing data from your computer. In a similar way, a blockchain that supports smart contracts must execute them in a sandbox with strictly limited access to system resources.
Another limitation on smart contracts is that because they are written in an interpreted language they are inherently slower than compiled code. Just how much slower depends a lot on the language chosen and the functions being performed, but it’s not too unlikely that the resulting interpreted code can be 5-10 times slower than compiled code with equivalent functionality. The “sandbox” that provides security against malicious interpreted code can also make smart contracts run much slower since extra code has to execute to determine if the smart contract has “permission” to do certain actions.
Smart contracts execute slower than compile code and have more restricted functionality, but enable blockchain functionality to be upgraded without getting consensus from block producers. As Ethereum as shown, this has turned out to be a powerful advantage for a blockchain, because it removes one of the bigger barriers to upgrading blockchain functionality. Most operators of blockchain nodes do not want to routinely have to upgrade their software manually. Nor do most software developers want to have to “campaign” to get their functionality added to the blockchain software. Smart contracts allow developers to add new functionality without needing to convince node operators to upgrade to the new functionality and eliminates the burden on blockchain node operators to do the upgrade.
There’s three ways smart contract technology can be brought into the BitShares ecosystem: 1) add smart contract processing code to the existing BitShares code base, 2) use an existing smart contract blockchain like Ethereum or EOS and try to write smart contracts that replicate existing BitShares functionality like exchange trading, voting, etc, or 3) add a sidechain which can execute smart contracts that operate on BitShares tokens.
Option 1, adding smart contract processing to the BitShares code base is theoretically an ideal solution, but there are significant risks associated with this approach as smart contract technology is still so new that it introduces many security risks which are arguably unacceptable for a financial platform.
Option 2, upgrading to whole new blockchain has all the risks of Option 1, and is even more problematic as it is likely to result in a degradation in performance for key BitShares operations such as order matching, because smart contracts use more memory and execute considerably slower than compiled code.
Option 3, the sidechain path, is the path we chose to bring smart contracts to BitShares. Financial risks are limited to the amount of tokens that are moved onto the sidechain and the execution of a malicious smart contract can’t impact the performance of trading on the main BitShares blockchain. Yet at the same time, businesses have the flexibility to write customized smart contracts that operate on BitShares tokens.
In an ideal world, BitShares tokens and BEOS tokens should be transferable back and forth in a trustless manner, but initially the two blockchains are being connected via a trusted gateway operated by BlockTrades under a contract with the BEOS trustees. The long-term plan is to replace this gateway with a trustless transfer mechanism via a true sidechain, but the code for this has not yet been written.
Note that the implementation of such a trustless system will require code changes to both BitShares and BEOS, so it will require approval from the block producers of both chains (in theory, the changes could probably be done to BEOS without requiring an upgrade to the core code using smart contract code, but for performance reasons it’s probably better done at the compiled code level).
In it’s initial release, relatively few changes have been made to the EOS code upon which BEOS is based. This means that most smart contracts written for EOS should be easily portable to BEOS. The primary changes in BEOS are related to the way tokens are distributed: instead of being sold via an ICO, BEOS tokens will be handed out over an 89 day period to BitShares and Brownie.pts holders that temporarily deposit their tokens to the BitShare-BEOS gateway. During the distribution period, BEOS tokens won’t be transferable (coins are distributed in “staked” form and can only be unstaked once the distribution period is over).
Similar changes were made to RAM tokens, although these will be distributed over a much longer period of time (80 weeks).
I was asked yesterday to give an interview with Crypto Connie about the work we’ve done on BEOS and it’s scheduled for live streaming tonight at 9pm Eastern Standard Time:
https://www.youtube.com/c/BlueRockTalkwithConnieWillis
