Are Smart Contracts really needed?
This story was first published in The Aleph Report. If you want to read the latest reports, please subscribe to our newsletter and our Twitter.
I’ve been a big fan of Blockchain technology for a while now. Some years ago I wrote a guide to the Blockchain protocol that is still being referenced today.
Despite my admiration for the underlying technology, I can’t but cringe at the current fervor around the space. The industry is riddled with fraud, wannabes, and ignorant. This wouldn’t be a problem except for the fact that we’re playing with sophisticated technology and people’s money.
One of the hottest cryptocurrency areas within the recent fever is Smart Contracts. When, years ago, I dove into Blockchain technology, Smart Contracts were in their infancy. Plenty has changed since then.
It now seems prudent to go on an exploration of what are Smart Contracts and how useful are they. Are they a fad? Do they even make sense? Who should use them? Is it wise to get your company involved?
What is a Smart Contract?
In 1997 Nick Szabo coined the term Smart Contracts to describe the digital automation of certain aspects of traditional contracts.
A contract is a set of promises agreed by two or more parties. It has been the standard way to formalize relationships in society for millennia.
A contract isn’t limited to paper, but to any promise agreed upon, implicitly or explicitly. For example, we can make an agreement between a client and a freelancer. The freelance promises to deliver on what the client wants. The client agrees to pay the freelance a negotiated fee in exchange. If the freelancer doesn’t provide or the delivery doesn’t perform as the client approved, then there is a breach of contract. The client is then entitled, upon their contract, to withhold the freelancer’s fee.
This is an elementary example, but one we’re very familiar with. In this case, the contract is explicit, but it could also be implicit. Every time you go to a Parking, you implicitly agree to a contract with the parking owner. You can park your car, but in exchange, you need to pay for the use of the space. Upon payment and delivery of the proof of payment, the parking barrier will let you out of the structure.
So you see, in a way, contracts are what binds most of our social interactions. Some of these agreements are formal; others are informal. Some are explicit; others aren’t.
The notion of contracts though entails several problems. The first one is the enforceability. Often, contracts end up in dispute because the parts can’t agree on the performance of the delivery. Other times, one of the parties breaches the contract and cheats the other side.
The second problem is transparency. In some cases, there are some information asymmetries between the parts. One side might have inside information, putting the other part at a disadvantage when negotiating the contract.
Last but not least, there is no universal set of rules that apply on a global scale. The way we negotiate the terms of a contract; the dispute resolution laws; or even the consequences of a breach of the agreement, will vary wildly between jurisdictions, cultures, and continents.
This is where Smart Contracts come into play. In 1997, Szabo proposed the use of computers and the newest cryptographic algorithms to fix some of these issues. This secure digital automation is what he called Smart Contracts:
“The basic idea behind smart contracts is that many kinds of contractual clauses (such as collateral, bonding, delineation of property rights, etc.) can be embedded in the hardware and software we deal with, in such a way as to make breach of contract expensive (if desired, sometimes prohibitively so) for the breacher.
[…]
Smart contracts go beyond the vending machine in proposing to embed contracts in all sorts of property that is valuable and controlled by digital means. Smart contracts reference that property in a dynamic, often proactively enforced form, and provide much better observation and verification where proactive measures must fall short.” (Emphasis my own)
Smart Contracts: Formalizing and Securing Relationships on Public Networks
I can’t but admire Szabo’s prescient mind. Not only did he predicted the potential of cryptography to secure binding contracts, but he also took a pass at the future state of the Internet of Things (IoT).
In a nutshell, the idea behind Smart Contracts is to use programs to enforce the clauses of a contract, and cryptography to ensure non-tampering, transparency and fraud protection.
At the time, the technology couldn’t deliver on all this. Bitcoin, Blockchain, and Ethereum changed that.
Early days of Smart Contracts
As technology and broadband started evolving, the future of Smart Contracts became the present.
The increase of Internet penetration and the rise of the cloud computing paradigm started allowing complex deployments with global reach.
Smart Contracts started appearing everywhere. Amazon’s one-click, Amazon Web Services, Salesforce Software as a Service concept, etc. These systems allowed the deployment of automated enforcement of social contracts. The systems supporting them became distributed and automated, fulfilling part of what Szabo envisioned.
There was still some unresolved problems with such architectures. It lacked two key components, transparency, and decentralization. Transparency to know what set of rules govern the contract, what information is the other part storing and what are they doing with it. Lack of transparency puts the security of the deal in jeopardy. While one party promised privacy and security, the others had to trust it was so blindly. The infinite string of hacking incidents, some with disastrous consequences, is a testament to how problematic this has become.
Decentralization was also lacking. It ensures the integrity and enforceability of the contract. If the contract is own by a single entity, it’s easy for them to change the terms of the contract unilaterally and even to avoid the enforceability. Decentralization allows for independent verification and makes it harder to commit fraud.
The rise of Bitcoin and the Blockchain
In 2009, Bitcoin became operational and brought to the market the first decentralized digital currency. The underlying technology, the Blockchain, suddenly makes genuinely decentralized computing a reality. On top of its decentralized nature, the way the Blockchain operates includes mechanisms for trusted consensus and irrevocable operations. Some start seeing the potential of the Blockchain as a vehicle to implement the missing pieces for Smart Contracts adoption.
With a strict focus on the currency aspect, Bitcoin though remains very limited. The Bitcoin team ignores voices asking for an expansion of the protocols. An extension that would enable more advanced uses of the Blockchain.
One of those voices was Vitalik Buterin, co-founder at the time of Bitcoin Magazine. In 2013, frustrated with the lack of action, he starts working on a new system, inspired by the Blockchain, but with a focus on computation.
“What Ethereum intends to provide is a blockchain with a built-in fully fledged Turing-complete programming language that can be used to create “contracts” that can be used to encode arbitrary state transition functions, allowing users to create any of the systems described above, as well as many others that we have not yet imagined, simply by writing up the logic in a few lines of code.”
Ethereum: A Secure Decentralised Generalised Transaction Ledger
In July of 2015, Ethereum comes to life. The system builds on the idea of Blockchain and uses its characteristics to develop the first distributed, decentralized secure Turing Complete computing platform.
Ethereum Smart Contracts
Ethereum, while inspired by Bitcoin, is an entirely different beast. It’s wrong to think of the network as a version of Bitcoin, because, while it employs similar elements, it’s goal and capacity is quite different.
The Ethereum network is like a big distributed computer where you can run code in a distributed and decentralized way. In the same way, you used to pay for time on a supercomputer; you also pay for the time your code runs on the Ethereum network (Note: Ethereum charges per executed instruction, and not time per se).
Ethereum was designed to support the creation of Smart Contracts. Under the system, though, we should understand contracts more as programs and not just contracts. Ethereum’s primary scripting language is called Solidity and enables some basic programming operations.
Solidity programs are executed on each node of the Ethereum network by the Ethereum Virtual Machine (EVM). Each node of the system runs the program simultaneously. This synchronicity ensures the anti-tampering of the execution. But It also imposes severe limits on the computational capacity of the network.
As I said before, executing code on Ethereum isn’t free. There is a cost, both regarding network use, the number of instructions executed and storage used. To pay for all this, you need to purchase Ethereum’s digital currency called Ether.
Ether’s goal is to pay for resources in its network, while Bitcoin was designed to operate as an alternative to fiat currencies. Here lies a big difference between both systems.
There are a series of implications to this that are critical to Smart Contracts. Ethereum enables any developer to code a simple program that runs in a distributed, decentralized network. Once we send the application to the system, the code and it’s associated data (storage database) will get replicated around the network. Our code is now secured, replicated and protected against any tampering.
Once stored, the Ethereum Blockchain assigns a unique id (or address in Ethereum parlor) to reference the uploaded code.
We can then trigger the execution by calling the program at that address.
Ethereum transactions and code execution
While on a regular computer we interact with it via clicks, in Ethereum we interact with transactions. There are three kinds.
The first one is the essential currency exchange between two accounts. The idea is identical to Bitcoin. We might want to transfer, split, share or give Ether to other people.
The second kind of transaction is slightly more complicated. It’s a transaction than uploads our code to the network (Contract creation). The transaction will send both the code and the money to pay for the execution (gas). The system will return the address we can call upon to execute our program.
Once the code is on the network, we can use the third transaction to execute the program. In the same way as before, we transfer money to the program’s address, and this will trigger the execution.
Ethereum Smart Contracts caveats
The fact that Ethereum even exists is already impressive. Nevertheless, it’s important to understand that its capacity and utility is far from perfect.
There are still several problems with Ethereum and its Smart Contracts that are worth highlighting.
User Interface
For starters, the current interfaces to manage its Smart Contracts are crude. It begs to remember what Szabo mentioned in his 1997 article:
“To properly communicate transaction semantics, we need good visual metaphors for the elements of the contract. These would hide the details of the protocol without surrendering control over the knowledge and execution of contract terms.”
Smart Contracts: Formalizing and Securing Relationships on Public Networks
That’s not the case for Ethereum. Even if you best coders craft a fabulous contract, it’s essential to design an abstraction layer to hide the protocol details. This hasn’t been the case and won’t be for a while.
Data limitations
Ethereum Smart Contracts are severely limited. On the one hand, it only allows you to build elementary logic (IF This Then That style). On the other side, it’s not easy to import data streams from outside the network. External information is relevant to bot negotiating clauses and analyzing the performance of the contract. Without external validation, the use of such Smart Contracts is severely limited.
The workaround is to employ what’s known as Oracles. These are programs that connect the Ethereum platform with the outside. They allow Ethereum code to import external data feeds. There are two issues with them though. For starters, it’s hard to secure the information that comes from an Oracle. Due to the secure nature of Smart Contracts, any information used to execute it also needs to be ensured through a chain of custody. This is not easy and requires the use of trusted Oracles. The second concern is that Oracles make Smart Contracts expensive. Using an Oracle incurs on higher processing fees within the network. This might render the advantages of running it on Ethereum mute.
Immutability of code
Once we upload the code to the network, it becomes immutable. This is by design. The problem though is that updating or upgrading the contract becomes a nightmare.
It’s tough, if not impossible, to preempt all potential scenarios of a contract. Not being able to fix an issue with a contract is a blessing and a curse. A blessing because it prevents any part from unilaterally changing the rules of the game. But it’s also a curse because it stops any change that fixes a non-desired consequence for all participants. There are potential workarounds, but they aren’t simple or cheap.
“Although code is theoretically immutable, one can easily get around this and have de-facto mutability by having chunks of the code in separate contracts, and having the address of which contracts to call stored in the modifiable storage.”
A Next-Generation Smart Contract and Decentralized Application Platform
Another effect of the immutability is that whenever we update a contract, we need to upload new code. Code that the Ethereum network will give a different address. The contract owners will require notifying all the parties with the repercussions this has.
Security
Coding Smart Contracts isn’t easy at all. The Ethereum network is a concurrent system. This brings to play all the known problems around parallel programming. And while the EVM executes operations synchronously, Solidity’s code is still vulnerable to other effects, like reentrancy attacks.
Many developers out there have no experience with concurrency. Much less with concurrency-related security bugs like race conditions or reentrancy problems.
“We knew that programming, in general, is difficult, that most of the valley runs on cut&paste from stack overflow, directed by technological decisions made by reading hearsay carefully planted by marketing professionals masquerading as programmers on social media.
[…]
It’s just difficult, what with all the Slack chat and Pokemon Go effort, to get all of those pesky little pre– and post-conditions right to build solid code that actually works.
We also knew that some notable professors had given up on trying to teach concurrency to their students, instead preferring to teach them how to use “event-driven” frameworks.An “event-driven framework” is just some code that someone else wrote where the framework “handles concurrency” (a.k.a. kills it) by grabbing a mutex and making it impossible for the student’s code to take advantage of concurrency, thereby avoiding concurrency bugs.”
The need of expert developers, the use of a sophisticated concurrent system and the severe economic consequences of any bug in the code, make the development of Smart Contracts a nightmare.
On top of this, the most recent studies have determined that while Ethereum is much more decentralized than the Bitcoin network, the control of the network is still in the hands of a few.
“Put another way, there are more Ethereum nodes, and they are better spread out around the world. That indicates that the full node distribution for Ethereum is much more decentralized.
Part of the reason for this is that a much higher percentage of Bitcoin nodes reside in data centers. Specifically, only 28% of Ethereum nodes can be positively identified to be in data centers, while the same number for Bitcoin is 56%.”
Performance
As I mentioned before, the performance of the EVM and node processing is quite limited. There are several projects (Raiden project, Blockchain sharding) that are trying to speed up the network and EVM’s performance.
“Currently, in all blockchain protocols each node stores all states (account balances, contract code, and storage, etc.) and processes all transactions. This provides a large amount of security, but greatly limits scalability: a blockchain cannot process more transactions than a single node can. In large part because of this, Bitcoin is limited to ~3–7 transactions per second, Ethereum to 7–15, etc.”
Until the network doesn’t scale, most Smart Contracts will only be toys. Speed and performance are critical for more complex contracts.
Cost
Maybe the cost of operations is the major problem with Smart Contracts. As we pay per execution, having long, complex contracts are prohibitive. Also, storing data on the Ethereum Blockchain is also extremely expensive.
“Storing vast amounts of data to the blockchain is also not an ordinary task. Depending on the task, a user would likely store a cryptographic reference (a hash) of the data on-chain and keep the rest of the data off-chain.”
As Szabo commented in a talk, he gave in 2016, trying to implement pure Blockchain Smart Contracts won’t be workable. This is because of the many limitations the current platforms have.
Another issue, which is currently in the news is cryptocurrencies volatility. While the amount of Ether we pay to deploy and execute our code is fixed, the price of Ether isn’t.
“While gas is fixed per operation, the amount a user pays per gas — gas price — is dynamic and dictated by market conditions.”
As more people speculate with the cryptocurrency, the price will keep oscillating with virulence. This has massive consequences for any Smart Contract deployment at scale. It’s hard to sell someone on this, and then have them pay exorbitant prices that offset the benefits of having a Smart Contract.
Should you use Smart Contracts?
All in all, we’ve gone a long way from that initial theoretical concept that Szabo exposed in 1997. That said, the current solutions aren’t quite there yet.
We live exciting times, and I believe we need more experimentation in the field. But I also think most organizations need to ask themselves the following question.
Do we need such a trusted and secure environment for our contracts?
Current technology like Amazon Lambda and other serverless computing offerings can achieve much more than the Ethereum computing platform. And cheaper. Orders of magnitude cheaper.
They lack decentralization and transparency, but it begs the question, is it critical for everyone? Security is about tradeoffs. The more secure, the more unusable the system is. Each organization needs to set their balance. Each company has a different customer. The use of Smart Contracts and the underlying platform needs to be aligned with the needs of those customers.
I don’t believe that everyone should be building Smart Contracts on Ethereum. There are some edge use cases where it makes sense though. One of the aftermaths of the network’s decentralization is the capacity to bypass the local law. Sometimes, the fact that the rules are the same all across the globe makes the underlying operations easier. Other times, giving a chance to people to bypass dictatorships and their censorship can have enormous repercussions.
As with all technology, it’s important to understand it and measure the cost-benefit for our organization. Smart Contracts and cryptocurrencies are hard and complicated. They’re sturdy and jaw-dropping, but they’re also dangerous, unstable and volatile.
