This is a guest contribution by Jeri DeBitto. If you would like to submit a contribution please contact Bill Beatty or submission details. Thank you.

Smart contracts

This next section of the article will deal with the issue of smart contracts and how they are implemented in the different blockchain systems which are popular in the current industry.

Most of the purported benefits from blockchains are ostensibly the promise of smart contracts on blockchains. Smart contracts are the ability for logic to be executed on the blockchain itself (by its main validators or a subset of these) which will enable basic payments upon fulfillment of the conditions which are necessary to make simple settlements automatic. The simplest example of these is the payment upon some external condition being met (which requires the use of trusted information sources, called ‘oracles’. ) such as in simple binary options such the EitherOr option or simple wagers where the payouts are static. But even these are complex when you consider the most basic of smart contracts. One that is so basic and taken for granted that most people wouldn’t even consider it a contract. I am speaking of course of the basic atomic swap.

The atomic swap, where 2 parties can exchange 2 legs of a deal settlement without any risk is normally facilitated by a 3rd party. That 3rd party or escrow, ensures that while the payments or deliveries from the parties may happen at different times in reality, neither party has access to the settlement until both parties payments have been mutually confirmed. This is one case where blockchains can uniquely add value as they logic in transactions can ensure that the 2 payments are made simultaneously, and also the transparency of the blockchains can ensure that neither party has any reason to distrust the smart contract code which will execute the settlement.

We will now examine the smart contract capabilities of several blockchains (both private and public) and gauge their fitness to be used in business applications.

R3 Corda

Corda is the private blockchain offering from R3 which was written explicitly to handle smart contracts between a trusted group of validators. As the blockchain and the contracting language are in Kotlin, a relative of Java, Corda stands to have the most easiest and expressive set of tools to create smart contracts. However, as Corda is not a public blockchain, it’s scope may be limited to companies which have already prearranged to trust each other in the building of a shared ledger system to manage their business use case.

Ethereum

Ethereum is ostensibly where most of the current efforts in smart contract development is taking place. This is mostly in part due to the reason that Ethereum was created with the intent of being able to create smart contracts which could not be done on Bitcoin itself due to the fact that core developers disabled the programming abilities in Bitcoin (BTC). Originally Vitalik Buterin, Vladimir Zamfir, and Gavin Wood proposed an extension system that could be built on top of bitcoin to facilitate smart contracts, but the bitcoin core developers at the time were against this use of the bitcoin blockchain and pushed changes that would block their idea, forcing them to create a new blockchain entirely, ETH.

Currently ETH has the most smart contract developers mostly in part to the fact that the blockchain is publicly shared (and therefore permission-less) and also because there are several languages which are available to write smart contracts in, javascript, python, and go, which all compile to a common virtual machine bytecode for execution (EVM). This is much like the java/JVM model. The most popular smart contract template in the ETH ecosystem is the ERC20, which is a basic fungible token, with additional logic that can be tailored. Many ICOs, and utility tokens are created using ERC20. The only drawback of this popularity is that most of the tokens created have questionable legality or are straight up scams. However, due to the fact that the ledger is public and permission-less, there is nothing that can stop people from creating such tokens.

Bitcoin Cash

Recently, bitcoin native smart contracts have once again been made possible due to the Bitcoin Cash fork, which has re-enabled many of the original smart contract capabilities originally put into Bitcoin by the creator(s). Many of these programming features were disabled in 2011 after the creator Satoshi Nakamoto left the project and handed it over to Gavin Andresen who then allowed many such edits to the original code base by other developers who were afraid that too much functionality in Bitcoin itself would be a threat to the system’s stability. Since the 2017 hard fork which split off BCH from BTC, BCH has had 2 upgrades which brought back many of the old functions of original Bitcoin, and with the upgrade in November (BitcoinSV) promising to enable the final last set of codes which will allow for full smart contract capability to be built on top of Bitcoin again. Since Dr. Craig Wright announced to the world in 2017 that Bitcoin actually was Turing complete others have since come forward and confirmed this fact. It’s just not Turing complete in the sense of an atomic transaction, but rather complex smart contracts can be encoded in a sequence of bitcoin transactions which in turn create other transactions. This revelation has renewed the interest of developers to explore how and what the smart contracting capabilities of Bitcoin can be, and some active projects are working on custom Bitcoin smart contract compilers which can take smart contract code written in a more traditional high level language and produce low level bitcoin script which can then be embedded in a sequence of transactions. This is a relatively new field of research and there is expected to be many new developments in the near future on this front. The promise is rather enticing; the ability to create smart contracts which can be settled directly on the bitcoin blockchain without any overlay system.

Stellar

While not many people will think of Stellar (a clone of Ripple) as a smart contract platform, some significant advances have been made on the side of Stellar to make their platform capable of simulating the effects of smart contracts. As Stellar was originally a clone of Ripple, they inherited the base layer which had token creation/transfers. Ripple was originally designed for the ease of creating IOUs which were intended to be currencies. Although they have limited ability to write logic around the transfer and issuance of these IOU tokens, the creation of them by any party was always a native feature of Ripple. Stellar took this and added some additional basic rules which could be applied to the tokens, and with smart use of transaction sequencing, multi-signature escrow-ed accounts, and time locked transactions are able to do some basic smart contracts such as atomic swaps and joint-entity crowdfunding. It is however unable to execute smart contracts independently without the use of trusted escrows to manage the execution of the contracts, as their contracts need the actions of trusted third parties to ensure that the transactions are executed faithfully. It is arguable whether or not these are truly “smart” contracts. Perhaps it would be more accurate to call them on-chain digital contracts.

Scalability

The big concern for institutions evaluating smart contract platforms is whether or not they are suitable for their needs. Institutions generally value scalability in the base design because the costs of migration from a legacy system and the disruptions to the business can be restrictively costly and is a constant concern. Therefore we shall evaluate the scalability of the blockchain platforms and their abilities to scale to high volumes as well as their ability to handle different levels of smart contract complexity.

R3 Corda

Corda, being a private blockchain run by a group of validators (which they call Notaries) can easily scale to levels which a traditional shared multi-user database can achieve. The scaling issues that face public blockchains don’t normally affect private blockchains such as Corda. But since the applications of a private blockchain are necessarily of a different scope from that of a public blockchain, businesses that are willing to sacrifice application scope and direct B2C applications (where retail customers access the blockchain directly) a private blockchains scalability is enticing. Measurements vary, but private blockchains range anywhere from 15-1400 tps in terms of transaction processing speeds. The complication with this metric is that as blockchains have different ways to measure when a transaction initiates and completes depending on the definition of finality that they employ, it is hard to objectively use this metric to compare blockchains. It is relatively safe to consider other private blockchain platform competitors such as Hyperledger to be in the same performance and feature domain. The main benefit of a platform like Corda, however, is that they have full expressivity in terms of creating smart contracts, and in the case of Corda specifically, focuses on binding the legal representations of smart contracts as an intrinsic characteristic of the smart contract itself, so that it can have the best and smoothest integration with existing legal systems. For enterprises which are considering just porting over an existing system to a blockchain model, Corda seems to be a good consideration.

Ethereum

The biggest scaling hurdle facing Ethereum is that the platform takes the absolute maximal approach of having all validators execute every smart contract transaction from everyone on the network. While this method ensures maximal decentralization of the validation process ensuring that there is the minimal chance that a transaction can be blocked or double spent, it does put an undue scaling bottleneck on the network. One archetypal case was when some internet developers created and launched the now infamous Cryptokitties, a tradable token which had no value except for collectible value and novelty. The sudden popularity of this token slowed the entire Ethereum network to a crawl such that normal transactions took hours to be confirmed. This case highlighted the flaws of a system which implements it’s security model by forcing every validator in the system to validate everyone else’s transactions and contracts.

Fundamental volume scaling issues aside, Ethereum is the most developed of the smart contract platforms, and due to the fact that the language for smart contracts are high level languages that developers are accustomed to, thus it lends the ability for developers to create smart contracts quickly. This benefit is sometimes a flaw, however, when some contracts which were created and launched ended up having bugs which resulted in lost or locked up funds for all those involved (Such as the multisig wallet bug and the now infamous DAO). The trade off in making smart contracts very easy to create, coupled with the fact that the blockchain is public and permission-less inevitably means certain types of smart contract applications are easier to create on ETH than on other blockchains. One such application space that of crowdfunding. Because crowdfunding can be done by creating a smart contract that has transparent rules, it is easy (some would argue too easy) to launch such a contract and start raising money. Recently there has been increased regulatory concern over the use of ICO platforms and smart contracts being used to launder funds systematically, which will continue to put some pressure and scrutiny into ETH smart contracts. Additionally, with current ETH token standards, all ownership of tokens is clearly visible on the public blockchain. Therefore, it is rather trivial to DE-anonymize token holders simply by following their token balances which are kept in the blockchain in a central registry. This may be a problem for institutions who wish to keep their token holdings private. It is likely for this reason that most institutions using ETH style smart contracts opt to run a private version of the ETH blockchain which they solely control themselves (such as Quorum, used by JPMorgan)

Bitcoin Cash

Bitcoin Cash has a unique view on smart contract scaling. While the base protocol and all base token transfers (BCH) are validated by all miners, many of the now emerging smart contract platforms on Bitcoin Cash use a “permissionless subset of interested parties” model for the validation of the smart contracts. These are sometimes called 2nd layer validation models, and they encompass all systems that make use of meta data being validated only by validators that understand the meta data, and ignored by the rest of the miners. Sometimes these systems are together referred to as “OP_RETURN” models due to their use of that op-code to embed the smart contract meta data, even though not all of them use that op-code (some use multi-signature script embedding). However, recently, due to the old disabled op-codes that were originally part of the bitcoin protocol being re-enabled in BCH by the nChain version of the protocol, ‘native’ smart contracts can now be written directly in bitcoin script, which is the native language which the Bitcoin miners execute as part of their validation process when they receive transactions.

The important difference between Ethereum smart contract model and the Bitcoin Cash model is that while Ethereum focuses on full transparency of the smart contract code for all, Bitcoin cash methods tend to focus on a model in which only the counter parties to a deal and interested parties are aware of the smart contract. While the execution part of the contract is performed faithfully by the miners (validators) or in the case of OP_RETURN models, the specific validator nodes, the actual visibility of the smart contract terms prior to execution can be sufficiently obscured from public scrutiny.

This is achieved by allowing only the counter-parties involved to keep a copy of the smart contract code on the client side, and only in the instance when they need to settle the contract will one side or the other use the code to produce a closing transaction which is then published to the blockchain. This allows contract terms to be obscured until after execution is complete, which adds security to the model as there will be less incentive for miners in the network to collude to defraud the participants compared to the situation if they were aware of the contract details. (as is the case with ETH¹).

This model of contract separation between the legal terms and the execution of the contract terms is similar to the model taken by Corda, Stellar and other platforms focusing on smart contracts.

Bitcoin Cash smart contracts are the only ones that scale in direct relation to the scalability of the base blockchain itself, due to the fact that native smart contracts written in bitcoin script is code that miners execute themselves as part of transaction validation. This is a positive design decision as the more complex smart contracts which take more transactions and larger script to execute will naturally cost more in execution fees due to the sats/byte fee pricing model in Bitcoin Cash (which at writing holds steady at ~1sat/byte.)

This means that as long as Bitcoin Cash can scale itself, then smart contracts will scale with Bitcoin Cash base layer. This is in stark contrast to Ethereum, whereas the transactions costs (‘gas’ in Ethereum terms) require developer input in helping with coming up with reasonable default rates due to the complexity of using a Turing complete language at the mining/validator level. This is due to the fact that it is not trivial to come up with a computation cost metric scale for different high level language constructs, especially when looping and recursion is introduced. With a lack of a simple guiding metric based on size such as sat/byte, it is hard for a liquid market on fee rates to emerge.

Stellar

The scaling considerations surrounding stellar is similar to the ones that face Ripple. Ripple and Stellar use a balance account based method of ledger accounting, all transactions just effect a delta on accounts. This means in order to run in a completely trust-less way (such that any node starting from zero could verify independently the balances of all accounts) all transactions need to be kept. Additionally one of the features of Ripple/Stellar is the fact that the order system and book is built into the protocol itself. This means that in addition to actual payments and trades, the order states themselves is a transaction that must be stored on the ledger. Because of this extra information (compared to the simple UTXO model used in Bitcoin) the ledger is very large (in the case of Ripple, 7TB in size and growing at a rate of 1GB a day). The scaling issues with Stellar therefore, is less with the consensus layer and more at the storage layer, and how to manage the ever growing blockchain data store.

The second issue with Stellar is the open question on how to scale their public permission-less blockchain in a way which is decentralized. Of course if all new nodes were to just adopt a closed set of validators which are trusted then the system will be free of ledger forks, and enjoy maximal consistency of data (as discussed in Section I). But to do so means that the set of trusted validators must be known beforehand and coordinated. Also if a critical number of trusted validators were to have a byzantine fault, then the ledger would partition and it would be very difficult to detect. Furthermore, it would be quite a challenge to resolve the matter of legitimacy of a split ledger, and whether or not a re-merge of the ledger is even possible after such a fault. (Compare this to bitcoin-style blockchains which can recover and automatically re-merge after a ledger split)

Another issue with Stellar is that they lack a native smart contract language and interpreter as part of the base validation engine. The Stellar application of smart contracts is more akin to using high level transaction pre-signing and time lock manipulations in order to effect the desired business use case. Therefore more complex smart contracts are not possible as of this time. In fact, due to the fact that Stellar lacks a built in “executor” process for smart contracts, it is fair to say that their contracts aren’t ‘smart’ at all. However, with timelocks and multisignature transactions one can compose a good number of basic use cases which normally fall under the realm of ‘smart contracts’ such as crowdfunding and atomic swaps.

Summary of Smart contract native capabilities of blockchains (red: private, green: public)

* Not readily possible given the private nature of the blockchain

** Possible only through the use of a third party escrow signer.

1This does not preclude the possibility that ETH will create smart contract templates that mirror this design philosophy in the future. It just is an observation from the existing smart contract market of the current state of affairs of ERC20, ERC223, ERC721, ERC777, ERC820 tokens.

Editor’s Note: This is the second in a series where Jeri Debitto explores and evaluates blockchains in the corporate environment. In case you missed the first article, you can read it here.

Note: Tokens on the Bitcoin Core (segwit) Chain are Referred to as BTC coins. Bitcoin Cash (BCH) is today the only Bitcoin implementation that follows Satoshi Nakamoto’s original whitepaper for Peer to Peer Electronic Cash. Bitcoin BCH is the only major public blockchain that maintains the original vision for Bitcoin as fast, frictionless, electronic cash.

The post Blockchains in the enterprise: Smart contracts in different chains appeared first on Coingeek.