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 ETH1).
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.
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.
In this series, I’d like to evaluate and explore the value of blockchains in the enterprise, and the obstacles that most enterprises face in adopting a blockchain strategy. This will be a comprehensive study of all the issues that surround the adoption of blockchains in the enterprise.
Enterprises have very unique requirements when it comes to blockchains. Of course the appeal of having a shared ledger in which one party does not need to be the sole administrator nor supporter of the network is very appealing. There is much potential to saving costs and also removing a whole class of errors that could occur in a system that is centrally administered.
This article will discuss the considerations of enterprise blockchain use, starting with the general classes of blockchains and distributed ledgers that are under consideration and their ideal use cases, the tradeoffs that the different blockchains make in comparison with traditional databases, and finally, the unique considerations that any enterprise must consider when evaluating whether or not to utilize a blockchain strategy.
The different types of blockchains
Private or public ledger?
The issue of whether or not to use a public or private ledger is the most fundamental question that your enterprise needs to grapple with. They are fundamentally different in terms of the use case that they address. Private blockchains or permissioned blockchains (shared within a group of trusted parties) are more synonymous with a multiparty shared database, with a signed transaction history. Therefore we will mostly be speaking about permission-less blockchains, such as Bitcoin, Ethereum or Ripple. It is worth mentioning that each of these blockchains have different degrees of permission-less participation, which we will speak more on later.
Do you need your data to be publicly verified? Or do validators need to be approved by a central authority? The answer depends on whether or not you want to have central administrative control over the ledger, shared control, or no control? Are you interested in blockchains simply because of their fail-over data resiliency? Should the costs of the infrastructure be shared between participants? Or run for free by the network itself?
Permissioned vs permission-less blockchains
Most of the time when dealing with enterprises with an existing association of partners, a permissioned blockchain is sufficient as the information need not be trusted beyond the closed circle of validators.
In the case where the information needs to incorporate outside information or tokens, then the use of a permission-less blockchain is more appropriate as the possibility of atomic swaps between asset tokens on the public blockchain will greatly simplify settlement in tokens other that the native one.
What are the benefits of permissioned blockchains? For one they have very fast transaction finality. Ledger inconsistencies can be resolved by a quorum of the validators.
By comparison, permission-less blockchains due to their lack of coordinated governance, their consistency is only eventually guaranteed, but not immediately guaranteed. Some permission-less blockchains have come very close to rivaling the finality of permissioned ones, by way of sacrificing some other aspects of the design.
As all of the aforementioned blockchains (or more correctly termed distributed ledgers, as Ripple and Stellar are not blockchains) are ostensibly permission-less to a degree, we should examine the differences between each in terms of their permissioned status.
Bitcoin (Bitcoin Cash):
1. Permission-less validation
2. Permission-less participation
3. Infrastructure is self-supported by validators through built-in economic model
4. Highly available
5. Highly partition resilient
6. Eventually Consistent (~10m)
7. Highly Scalable
Ripple (Stellar)
1. Somewhat Permission-less validation
2. Permission-less participation
3. Infrastructure is funded by participants and validators alike.
4. Highly available
5. Somewhat partition resilient
6. Highly consistent
7. Somewhat Scalable
Ethereum:
1. Permission-less validation
2. Permission-less participation
3. Infrastructure is self-funded by validators through built-in economic model
4. Highly available
5. Highly partition resilient
6. Very good consistent (~30sec)
7. Poor Scalability
In a chart summary:
You can see that depending on the needs of the enterprise, the different blockchain technologies may be appropriate. All of the above technologies are permission-less, but they all make some tradeoffs to achieve this. If your enterprise needs a solution that is highly available, consistent, partition resistant and scalable then the best solution is to run a completely private database system, which is accessible only by permissioned users.
Bitcoin:
Bitcoin is the base line for comparison as it was the first blockchain. It sacrifices some consistency for the fact that only validators need to run full network nodes and the fact that the validators need not coordinate with each other. It sacrifices scalability in exchange for keeping the requirements for running a full network node low, so that participants still have the option to keep the whole ledger, without being validators for the network. Attempts to make up for the scalability sacrifice by pushing transactions to off-chain payment channel networks such as Lightning.
Bitcoin Cash:
Bitcoin Cash is largely the same model as Bitcoin with the exception that it does not sacrifice forward scalability for the option to cheaply run full network nodes by network users. Instead it focuses on the use of SPV (light) clients which only validate their own transactions, for users, and only network miners need to run full nodes (although many businesses such as exchanges may still opt to).
Ripple:
Not a blockchain proper, but a distributed ledger. Partition resistance is sacrificed for high consistency (within a partition). Nodes keep a list of the other nodes that it knows about and trusts and only messages from those nodes which are on the trusted list are validated and further passed along to a node’s peers. Therefore, the most efficient network topology of a Ripple network would be a group of nodes which all trust each other. (This is the same for a Bitcoin network of miners). Scalability suffers somewhat by the fact that there are no light clients, and all clients need to be consistent and in sync with the rest of the network in order to create a transaction. There is no such thing as an offline transaction creation. (Therefore removing some use cases where the offline creation and private sharing of transactions may be useful). Ripple is unlike the other blockchains evaluated because it does not have a native economic model. Its native token is a virtual token created privately and distributed to partners of Ripple Labs directly.
Ethereum:
A cross between Bitcoin and Ripple, it shares the same general validation model as Bitcoin (mining) though developers want to transition it to be a staked system. (With time locked bonded stakes earning the right to validate and earn inflation interest). Ethereum was initially planned to be a smart contract layer on top of Bitcoin, but due to the restrictions that the BTC core developers put onto the system the founders of Ethereum decided to create their own blockchain and fund the development with an ICO of its own token network instead. Ethereum sacrifices forward scalability for flexibility in smart contract expressivity, enforcing that every validator execute every smart contract code independently and redundantly.
Economic model? Or just a ledger infrastructure?
Does it matter if the blockchain has its own economic model? Most permission-less blockchains come with their own economic model, that is because of the decentralized nature of the validators (miners in a PoW system) there must be a way for the validators to be reimbursed for their resources committed to building out the network infrastructure. For a permissioned blockchain this is not necessary, nor even desired. Any economic model (such as controlled distribution of native tokens) is normally controlled out-of-system. This is acceptable because there is an implied level of trust between the validators and their cohorts. Normally the native token in such a system, has little intrinsic value beyond that of a utility token for the use of the network paid by the participants who do not contribute infrastructure themselves.
Transaction immutability or reversibility
Do you need the transactions to be irreversible? (If no, then evaluate whether or not your business case can be served with just a database. If you need immutability then the permissioned blockchain will do if you are okay with the notion that transactions are only as immutable as having the verifiers of the blockchain agree on changes. Permission-less blockchains will have validators or miners which are operating under their own economic model which is separate from your business, and thus would be effectively immutable.
Validators vs miners
Distributed ledgers have validators. The same role is performed by miners in a blockchain. The difference between the 2 is that validators are necessarily participants in the network as primarily users, (albeit likely large ones), while miners operate as their own businesses with their own economic model.
This provides for a measure of isolation for the businesses that want to use the blockchain, because you can be relatively certain that the miners will act independently and in their own best interests, instead of interfering with users. In fact, the economic model of mining on blockchains is such that miners which are seen to be violating the consensus rules or even social ones can be easily identified, and the network will penalize them. This is much harder to detect in distributed ledger systems, as the validators do not publish a proof of their work in a form which is public and transparent for the world to see. It would be much more difficult to determine if a cartel of validators were to deliberately censoring certain transactions from certain users.
This concludes the overview of the blockchains technologies which are popular considerations for enterprises, and gives a sufficient introduction to the general characteristics of each. In part II of this series, I’ll explore some of the common application use cases that enterprises look for and evaluate how each of the technologies fairs in these applications in turn.
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: The different types of blockchains appeared first on Coingeek.
