How can we make smart contracts enterprise ready?

null

There’s no question about it: smart contracts are set to change the game across the board. In conjunction with IoT, Big Data and AI, trustless agreements that can be upheld and executed by code are poised to disrupt everything from insurance to food supply chains. It’s essential for these to run on blockchain-based systems in order to forego the need for absolute trust between parties. This new paradigm enables trustless interactions between multiple parties, no matter their location or jurisdiction. 

Bitcoin provided the first proof that money and value could operate on a trustless network. Since then, several other projects have sought to extend the blockchain concept to include more than just value transfers. The first project to succeed in this was Ethereum. Ethereum built a Turing-complete virtual machine that powers their own blockchain and allows for completely decentralised applications. 

Today, smart contracts are creating new concepts not previously possible, and approaching new ways to help old industries. However, the hype does not match reality. Despite the thousands of ICOs and their promises to disrupt almost any industry imaginable, the ecosystem is still in its infancy. There are several significant hurdles to overcome before seeing smart contract and blockchain technology really become practical for surpassing these existing industry processes.   

Creating enterprise scalability 

Scalability is the biggest hurdle to be overcome. Most blockchain and smart contract platforms struggle to sustain even 100 transactions per second. Tens of thousands of transactions per second is really the type of scale that needs to be seen for this to be considered an option. Several different approaches are being taken to attempt to solve this problem. Most of the concepts are difficult to use or only theoretical right now, but progress is being made to make this technology easy to access.  

Two of the most well known approaches to tackle the scaling problem are state channels and sharding. State channels allow for a smart contract interactions to take place completely outside of the blockchain, with only certain rare events requiring a blockchain transaction. Sharding on the other hand is an "on-chain" scaling solution. The concept behind sharding is that only a subset of the blockchain network needs to execute smart contracts and validate various parts of the blockchain. This is similar to adding more computers to your datacenter when needing to process a large amount of data. State channels are already being used by some decentralised apps, but it imposes some restrictions on how the application is used that isn't practical for all smart contracts. Sharding is being developed by Ethereum, but the design is still far from being production ready.  

Another answer to the scaling problem that works for some industries is the creation of a private "permissioned" blockchain. Whereas anyone can participate in the Ethereum or Bitcoin network, by closing off the network so that only certain known parties can participate, some significant changes can be made. This includes introducing more trust into the blockchain that can be leveraged to make the entire system operate on a much faster time scale than is possible when coordinating with potentially millions of different parties spread around the world. This approach also solves another major roadblock for industry adoption to smart contracts: privacy and data control. By controlling who can access the network, it is possible to assert different nodes can have different levels of data access.   

Eradicating poor code   

Another crucial, yet often overlooked, aspect to smart contract adoption is the development and engineering side of writing this code that can potentially control hundreds of millions of dollars. Right now, the primary language that must be used for this type of programming is Solidity. Solidity is a programming language that was created by Ethereum and is designed to make it as easy as possible to write smart contracts.  

Despite this lofty design goal, there are many other languages that far surpass it. Some of those include Python and Go. Both have been around for far longer than Solidity, and have had huge mission critical applications written in them. 

Another issue I have with Solidity is that it makes it easy to write smart contract code, whether or not it's secure and well designed. This has led to several disasters in the Ethereum ecosystem that were blamed at least partially on the design of the language. This includes events like the DAO hack, the Parity multisig bug, and many other smaller hacks that have a total easily greater than $1B in lost value. 

I'd much rather see another programming language take over Solidity's lead in smart contract programming. One candidate to me is Rust. Rust is a language designed to build one of the most exposed and often hacked pieces of software: the modern browser. It's creation is being led by Mozilla and some Rust code is already present in the Firefox web browser. It's design makes many classes of programmer mistakes impossible or at least very hard, and despite this it still has a strong focus on ensuring programs have a high performance level. 

Adding stability to blockchain 

It's easy to get caught up in the hype of blockchain, but it's good to keep in mind that none of this technology existed 10 years ago. Technology companies in a new space like this often use the mantra of "move fast and break things." However, when applying this concept to financial constructs of this magnitude, the results are catastrophic as expected. 

I strongly believe we need to look back on the past and try to bring some of that stability and direction to the blockchain ecosystem. If I were writing code that makes sure an airplane stays in the air, "easy" would not be a term I care about in it's design. I also wouldn't care to use the latest and greatest potentially unstable technology. I would want something that has been proven by years, if not decades, of experience and testing. I believe the ecosystem as a whole needs to apply those same concepts to this code that's being written to secure billions of dollars.  

Jordan Earls, Software Engineer and Co-Founder of Qtum 

Image Credit: Pixabay / Pexels