Smart Contracts: The Good, the Bad, and the Ugly

Smart Contracts are one of the biggest drivers behind the enthusiasm for blockchain. The idea is that contracts can be translated into code, which is then distributed to multiple nodes in a blockchain.  As it executes, the outcome is also recorded in the blockchain: the exchange of assets, the access to property, the receipt of items, among others.

The power of Smart Contracts is that they remove counter-party risk, and with that they make escrows and middleman services redundant. This is better seen with an example:

Say you decide to buy a plot of land in Georgia (the country). They happen to be piloting land titling based on blockchain. You enter into a contract to buy some land by putting a small deposit upfront and committing to pay the full amount by a certain date, while you look for financing. A Smart contract could verify if your payment took place on time, release the funds and change the title on the property, or cancel the contract altogether and liquidate the deposit if you were unable to find financing. There would be no need for an escrow service to keep your deposit, for a title company to verify payments, or for a titling clerk to update the records.

For this to work well, several conditions have to be met – and they speak to the main limitations of the concept:

  • First, these contracts would need legal recognition to be enforceable.
  • Second, the inputs and outcomes of the smart contract (land title, payments, dates) have to be in blockchain. This does not necessarily mean you have to pay for the land using bitcoins (although that would work), but you need a way to record your payments in blockchain.

These limitations will determine the range of applications for the Smart Contracts. Can we get every clause in a contract modeled in the blockchain? What happens when a judge rules something not considered in the initial design?

In the last year, we built a blockchain solution on Ethereum, one of the first platforms to fully support Smart Contracts. So on top of the big picture issues, we learned a lot about the implementation of and the technology issues that Smart Contracts have:

  • They may be buggy, just like any other code. Debugging and testing them is quite involved due to the lack of tools. If Smart Contracts take off in popularity, expect new services and technology focused on doing all types of security checks before they are deployed.
  • Contract complexity is limited. In Ethereum, this is expressed as a “Gas Limit”: the fee that you pay to execute your transaction is capped by the network. This prevents issues with buggy or malicious code clogging the system. But your transaction cost depends on lines of code executed – literally- and you may not have full control on that. For instance, loops running a variable number of times can run out of gas in the middle of the execution. As the amount of gas you can spend is capped, you may not be able to process a transaction.
  • In the past few months, Gas Limits have been more of an issue because Ethereum lowered them several times to fight the DDoS attacks they experienced. Changing network conditions or specifications on short notice will create havoc: for us, it was contracts that were too big to execute and transactions that could not be processed.

Vitalik Buterin, the co-founder of Ethereum, said in March of this year: “This is still an experiment.” It was a good reminder for anybody working with this powerful technology.

Pepe Catala

Pepe Catala

Senior Product Manager

Pepe Catala is a Senior Product Manager at 3Pillar Global. He helps clients shape new ideas into working products, as well as use technology to differentiate and create great experiences. His work focuses on the financial and media verticals. Prior to joining 3Pillar, Pepe worked in several start-ups in the digital advertising space, and worked at PricewaterhouseCoopers implementing enterprise software for Fortune 500 companies.

Leave a Reply

Related Posts

Take 3, Scene 17: The Value of Data Analytics Dan Greene and Adi Chikara join us for this episode of Take 3 to discuss the value of Data Analytics for making sense of the massive amounts of data t...
Take 3, Scene 13: Redux Your React On this episode of Take 3, we take a look at the React development library and how it pairs with the Flux pattern Redux. Vlad Zelinschi and Cassian Lu...
Take 3, Scene 14: The Present and Future of Angular 2, Part ... On this two-part episode of Take 3, Cassian Lup and Andrei Tamas join us all the way from Romania to discuss the newest iteration of the AngularJS fra...
Take 3, Scene 14: The Present and Future of Angular 2, Part ... On the second part of this two-part episode of Take 3, we continue our conversation with Cassian Lup and Andrei Tamas on the newest iteration of the A...
Spell Check and Autocorrect with Conditional Probability A client of mine wanted to reduce the time it took for his vendors to upload an inventory list to his system. The system currently matches the product...

Free product development tips delivered right to your inbox