Pathway to a Smart Contracts tipping point

For this to occur, generally there are 5 main things that are either missing or need to be addressed properly:

1- Connectivity to key resources. A Smart Contracts needs to be able to get data, needs to be able to provide meaningful outputs, whether in the forms of payments or output data, and needs to know what’s happening outside the blockchain in the context of what’s relevant or required for the contract.

2- Security and Privacy for the contract terms and participants, because a lot of the time the parties involved in a digital agreement want the agreement terms to be between themselves only.

3- Scalability of the system in which the Smart Contract will operate. The platform operating the contract needs to be able to perform well enough during contract execution, but also needs to be able to scale to accommodate high volumes of multiple smart contracts executing at the same time.

4- Legal and Regulatory framework. Technology often outpaces regulatory frameworks and the law, and this applies to Smart Contracts as well. Smart Contracts need to be addressed from a legal perspective as well as included in many of the regulations that exist in the various industries in which they will be used.

5- Accessibility of Smart Contracts. Currently only blockchain programmers can write a Smart Contract, and many platforms do not allow them to use widely popular programming languages like Java or C++. Eg the Ethereum platform requires programmers to learn a new programming language (Solidity).

Connectivity

In the current implementation of Smart Contracts on distributed ledger technology, a contract cannot connect to outside resources. It cannot get outside data, and it cannot interact with APIs outside of the blockchain in which they reside, which is a huge limiting factor. This is due to the nature of distributed ledger technology and the fact that the small virtual machine executing the contract on the blockchain is very basic, and can only do a limited number of things. This is as per design, it needs to be small, quick and very lean if you want it to scale well.

So how do you get a Smart Contract to talk to a data feed, how do you get a Smart Contract to send payments, and how do you get a Smart Contract to do off-chain computation about the data it gets? Because without all these input and outputs, the scope of the Smart Contract will be limited to the data that is on the blockchain in which it is executing on, or in the case of cryptocurrency platforms, ownership of the tokens (tokenization). for a Smart Contract to be a form of digital agreement that’s useful for real world events, it needs to know about those real world events. It needs to know about market data, it needs to know about GPS data for trade finance, it needs to know IOT data for insurance, and it needs to reliably receive these inputs to be a digital agreement that meaningfully reacts to real world events. Finally, it needs to be able to pay and settle in format that users want to receive.

The ways to implement this are varied, and there are generally 2 approaches:

Approach 1- Oracle Service:

In this approach a centralized service or application will take data from somewhere (eg an API), and it passes it to the Smart Contract on the blockchain, because the Smart Contract can’t get it on its own. This is a perfectly viable solution, however it does pose some flaws. The value of the Smart Contract is that its tamper proof due to running on a distributed ledger, but its now getting its data from a single node or server. This compromises the ‘tamper proof-ness’ of the Smart Contract, because if that Oracle node is compromised, then the entire Smart Contract can be manipulated, and is therefore not completely secure or tamper proof. If the data going into the Contract is unreliable, then it’s no longer a superior form of digital agreement. Despite this, using a trusted Oracle or Oracles is sufficient for some use cases.

There are already various implementations of this approach, eg Oracalize.

Oracalize Oracle Example

Approach 2- Decentralised Oracle Network

In this approach, a decentralised Oracle network sits between a Smart Contract and the outside world, acting as a ‘Middleware’ layer. The purpose of this is to allow the Smart Contract to potentially get its input (or process output) in a decentralised way, therefore extending the security and ‘tamper proof-ness’ of the Smart Contract out to the point at which it gets and sends data as well. So for example you could have 1 node getting data from 3 different data sources, and then passing the aggregated result to the Smart Contract, or for complete decentralization you could have multiple Oracle nodes getting data from multiple data sources, aggregating the results and then once they have reached a consensus on the result, pass it to the Smart Contract. This example is true decentralization end to end, and is more suitable for large industries with trillions of dollars like securities, trade finance, derivatives and insurance to adopt Smart Contracts, as they’re going to be looking at the process end to end, and will want as much security and immutability as possible.

The first proper implementation of this approach is called Chainlink, and is currently being built by a Startup called smartcontract.com. Once Chainlink is live (most likely Q1/Q2 2019), this connectivity problem will no longer be an issue.

Security and Privacy

On 17 June 2016, a smart contract called DAO on Ethereum’s public blockchain was hacked and a share of investors’ funds, valued at nearly USD $50 million, was moved to a sub-contract controlled by the hacker. While the funds could not be taken by the hacker because of checks built into the contract, the incident has had far-reaching implications. While such an attack is less likely to occur in a permissioned/private blockchain, the incident has served as an lesson learned for smart contract practitioners, and also highlighted the significance of strong governance. For instance:

Roles of participating parties: The parties that come together to operate on one smart contract platform must have clearly defined roles and responsibilities and ensure that all processes related to creation, execution and annulment of smart contracts are well-defined.

Checks and balances: Due to a security feature of the Ethereum smart contract, the hacker was not able to move the hacked funds for 27 days, giving the community time to act, rewrite the rules and rollback the attack (hard fork). Economic impact of failures should be proactively gauged, and features need to be built-in to ensure corrective action can be taken by authorities to avert or limit losses to the transacting parties. These checks will have to be designed while keeping in mind the need for seamless execution.

Privacy of data and contracts may be a challenge for enterprise-related smart contracts depending on the type of access put in place for the blockchain. Since transaction records can potentially be visible to all participants, banks will be reluctant to collaborate on a common smart contract platform if security and privacy of data are not taken into account. Cryptographic key management is crucial to hide transaction details from unknown parties, and the question that needs to be addressed is what data should be shared with all participants? Oracles provide off-chain computation capabilities, which can help in ensuring that the blockchain doesn’t need to store or access data that parties wish to keep private, and Hyperledger provides ‘channels’ as a means to ensure data on the ledger is only visible to the participants that are meant to see it.

Unlike regular contracts, there’s no way to stop or modify the contract once its deployed. Because of this, the Smart Contracts need to be 100% bulletproof and bug free. Nobody’s going to be putting millions of dollars into a self executing program unless they are confident it will behave as expected, and that the triggering mechanisms are correct and valid. In the past year the industry has caught on quick, and there is already numerous Smart Contract auditing/testing organizations and software platforms that address this.

Scalability and Performance

For transactions such as loans or mortgages where high transaction processing speeds aren’t an issue, permissionless (anyone can join and contribute to block generation) blockchains would be suitable from a performance perspective. However other transactions such as trade finance and securities would require much better performance than that typically offered by a permissionless blockchain. Regardless of the scenario, many businesses are likely to use permissioned (restricts access to viewing and adding to the ledger) blockchains instead of permissionless ones for several reasons. First, permissioned blockchains make it easier to achieve regulatory compliance. Second, they provide more robust consensus and governance mechanisms. Finally, high throughput is essential for many applications, and private/permissioned blockchains generally perform and scale better. While new techniques will be needed to scale both permissioned and permissionless blockchains up to throughputs required for many applications, permissioned blockchains today already have a considerable performance advantage. Another common requirement is zero downtime, something which a blockchain can handle quite well due to its distributed design and consensus mechanisms.

Oracles can also aid in scalability and performance, because they have off-chain computational capabilities that can ‘take the load off’ from the Smart Contract running on the blockchain. While many current Smart Contract platforms vary in terms of performance and scalability, they are all constantly improving and moving towards a common goal of high performance and scalability.

Legal and Regulatory framework

To make Smart Contracts inter operate with the existing legal system, designers of smart contract systems are actively working on several nuances from a legal perspective:

Immutability- As explained above, Smart Contracts on a distributed ledger are tamper proof. This would cause practical problems in many real-world scenarios , and people are exploring how the terms of the contract could be modified once it is in place. Contract law makes allowances for the modifications or annulment of contracts, which could also be achieved in a Smart Contract if required. One approach is what is often referred to as an ‘escape hatch’, a pre-programmed way of changing the terms of a smart contract. Ensuring that the right permissions are put in place is tricky, though. Also it takes away some of the main features and advantages of Smart Contracts, so implementing something like this needs to be considered carefully.

Contractual Secrecy- Normally, a copy of smart contracts executed on a blockchain or a permissioned ledger is shared with the chain’s members. The anonymity of the parties can be secured, but the secrecy of contract execution is not necessarily secured. This is an area that is receiving attention and where progress is being made. As explained earlier, Oracles can help by ensuring private data and information is kept off-chain. There are also startups trying to solve the problem of privacy, and data sharing within organizations and between organizations, by use of advanced cryptographic structures. Similarly, a concept known as ‘zero knowledge proofs’ is being explored to come up with a way to separate the process of verifying a transaction from seeing the content of that transaction.

Legal enforceability and adjudication- Many industries (eg financial services) are highly regulated, and specific licenses and approvals are issued to firms to operate within the industry. However, the legality of financial smart contracts is yet to be established. Initial steps have been taken in the US and some other countries, to recognize distributed ledgers in the legal system. For contracts to be enforceable, the identity of the parties has to be confirmed to a degree that the legal system and regulators consider appropriate, and electronic signatures need to be considered valid. Also accurate translation of legal terms and conditions into software logic is another key aspect to consider. Startups such as CommonAccord and OpenLaw are working on platforms that address this.

Regulation- Lawyers, legislators, regulators and governments have already begun to realize the potential for distributed ledgers in increasing transparency and ease of compliance and reporting. The push from these authorities will be instrumental in overcoming legal and administrative hurdles.

Accessibility

To write a Smart Contract today, you need to be a programmer that has knowledge on blockchains from a technical perspective. Also depending on the platform, you may need to know custom/bespoke programming languages like Solidity or Golang. If you want to write a Smart ‘legal’ contract, you need the above skills and also have knowledge off the law, and there isn’t many coder/lawyers around!

Going forward, Smart Contracts will need to be able to be written in more widely known languages. Enterprises will prefer platforms that can leverage their existing IT skill sets rather than having to upskill teams in new bespoke languages. Platforms like NEO have already addressed this, offering languages like Java and C# for developers to use, and many other platforms have this coming.

It’s very likely that in the future as Smart Contract usage increases, you will see industry standard or template versions of contracts come into fruition for various use cases, e.g derivatives and trade finance agreements. These standardized templates of smart contract code will continue to improve based on the feedback of the community that want to improve them, which could be for various reasons (i.e to meet some legal requirement). This means not every new Smart Contract will be built from scratch, many will be based on standards and templates and modified to suit. They say that 80% of contract law today is plagiarism, Smart Contracts will eventually follow this precedent.