Smart Contracts in Enterprise Blockchains — A Detailed Explanation in Pictures
Depending on the Blockchain platform you choose, Smart Contracts drastically differ in their method of implementation. Public Blockchain such as Ethereum, EOS, Cardano and Tron allow them to be implemented over an open, permissionless network operated by their underlying tokens to pay for different types of fees. On the other end of the spectrum are permissioned Blockchains who execute Smart Contract code on a network whose validators are known and trusted.
In this article, we aim to breakdown the method of implementation of Smart Contracts on four major private Blockchain platforms — Hyperledger Fabric, R3 Corda, Multichain and Ethereum (more specifically its private implementations of Quorum and Burrow). If you are new to the entire concept of Smart Contracts, I highly recommend reading my previous article linked below, before venturing on to this topic.
Smart Contracts on private Blockchains help implement a shared database system on a peer-to-peer network. Any changes made to this database are propagated in the network as transactions. If the participants of the network reach a consensus about their validity, these transactions get executed on the local database of each participant. They get included in blocks that subsequently append to a common ‘Blockchain’ that is maintained by every participant in the network. At large what we have here is —
- An append-only ledger of transactions that are maintained at the system of each participant, using a Blockchain data structure, kept in consensus by all participants in the network
- A local database owned by each Blockchain participant whose rows are updated by the contents of these transactions.
The primary difference between how the implementation above differs from traditional shared databases is ownership.
Unlike a traditional setting, there is no central administrator. Transactions that transform the local database are processed independently by each participant and each transaction can be irrefutably linked to its initiator because they signed the transaction with their private key. However, there are numerous challenges that arise due to such an implementation
- If anyone in the network can initiate a transaction which changes everyone’s local database, then what is stopping them from doing so in a manner that benefits them?
There needs to be a set of transaction rules that govern what changes to everyone’s local database are acceptable and what are not. For example, in a shared financial ledger, we cannot allow a participant to increase their own account balance while taking others' money away. There need to be rules set that disallows this. - If the transaction rules above are implemented as code, how can we ensure that all participants interpret the code in the same way?
There needs to be a method to ensure a deterministic output or an output that the entire network can generate equally and agreeably. - If there is no central ownership, then how do we deal with transactions that follow transaction rules, but conflict with one another?
There needs to be a means to prevent conflicts that occur both incidentally and maliciously on the network
The four platforms discussed in this article differ in how they implement the above three concepts — transaction rules, determinism and conflict prevention. Before delving any further, special shout out to Gideon Greenspan from Multichain who allowed me to borrow the overall structure of his original article linked here. If you are looking for a more technical take on this subject, do check out Gideon’s article. On to the first platform —
Multichain
Multichain is a platform that allows businesses to quickly build and deploy their own private Blockchain. The platform borrowed and enhanced Bitcoin’s code to enable the creation and configuration of private validator networks between known participants.
Transaction rules are implemented in Multichain using a model that we can call The Input-Output Model.
In this model, transactions feature a set of inputs and outputs. Inputs are database entries that are deleted or replaced, and outputs are the new entries that get inserted. Every transaction must consume an input, and create an output that represents that change the transaction has made. An entry in the database on a Multichain ledger can represent any type of asset (e.g. any financial asset as shown above) or even JSON (as shown below), text or binary data.
Hence the state of a Multichain local database is represented by the set of all transaction outputs that are yet to be part of a new transaction. These transaction outputs are also called UTXOs. Multichain also allows a transaction to store any type of metadata that may contain additional information regarding the transaction, that does not become a part of the local database.
Transaction rules are implemented on the above set of inputs, outputs, and metadata by pieces of arbitrary code which restricts certain transformations in a transaction. These codes are built into the Mutltichain protocol in the form of abstractions and these include those that ensure:
- An asset-based transaction must have an equal quantity of assets in its input and its output. This prevents users from creating or deleting money arbitrarily.
- Every transaction has to be signed by the owner of each of its inputs. This stops users from spending each other’s money without permission.
Multichain features additional abstractions (or pre-defined rules) such as those for permissioning of nodes (Blockchain participants), creating and transfer of digital assets, data storage, etc. that allow developers to implement these rules without having to code it themselves. Developers can additionally use Smart Filters, to further add custom rules on top of these existing abstractions. For example, in the instance of having to implement a multi-signature escrow transaction, a developer can write a smart filter, that releases funds to the receiver only when a certain document is approved or uploaded by a third-party (such as a delivery agent).
To be continued in a future post…
Leave a comment or book a session with me at www.adilharis.com to know if enterprise Smart Contracts make sense for your business.
