Introducing Simple Contracts

Business Logic Without Smart Contract Security Risks

Smart Contracts are fully fledged computer programs that authenticate and implement the conditions of predetermined contracts. They can be partially or fully self-executed and can trigger additional Smart Contracts when a certain threshold is reached or in its execution by containing an internal state, meaning it can go from A to B to C and D and trigger other contracts or actions in every state in the process. Smart Contracts can be a powerful tool when several variables are at play and the added complexity is viewed as a benefit. But what if you could extract all the functionality with none of the overhead? This is what we call Simple Contracts.

Simple Contracts have no internal state. They rely solely on the specific data that the contract can see, the entire system overall doesn’t matter. Simple Contracts can only execute transfers, they cannot trigger additional contracts and this is the biggest difference between the two, there is no chaining of contracts. To test a Smart Contract, you have to go over each internal state, triggering a new contract to go into each state, which can trigger another Smart Contract, and so on. It can quickly snowball into something you can’t control. It’s very difficult to predict the outcome and validate every state in the contract. With the finite execution time of Simple Contracts, it’s easy to predict how much computation time it will need upfront and it’s also very easy to change each input and combination.

Smart Contracts operate on a potentially infinite if-this-then-that-or-that-and-or-this type of principle, Simple Contracts only go as far as the if-this-then-that.

If no PR is bad PR then Smart Contracts have been having an incredible year. The DAO, possibly the most (in)famous example to date, has been making headlines across the board from its initial record-breaking funding to its equally record-breaking hack. A Smart Contract is a piece of code that allows machines to transact with no human intervention. They have to maintain an internal state which is problematic because once one contract is executing, it has to keep track of all those internal elements during execution. Like any other piece of code, vulnerabilities can be exploited by attackers and in the case of the DAO hack, a recursive loop was used to pay the hacker again and again—to the tune of $50 million, to be exact. If there is only one takeaway from the DAO hack, it is that writing a strong and secure Smart Contract is extremely difficult.

Who Can Use Them?

Simple Contracts could be applied in a myriad of use cases and benefit all those who are looking for a blockchain with permissions — meaning one group of people can transfer to another group of people and no one else, ie Group A can only send to Group B — from banks, trades and exchanges to supply chains and anything triggered by sensory inputs (IoT).

Let’s look at some examples.

1. A trader who wants to sell at x position would set up a “if my security is valued at x amount, I want to sell” contract. A simple if-this-then-that. The only information necessary is the answer to “is it time to sell?” which is achieved by comparing two values.
2. When you order something online today, your payment is processed, the company is notified who then ships the product and is ultimately delivered by a third party like FedEx, for example. With a Simple Contract, when a purchase is made online, the funds are held in a contractual agreement that essentially says “I, the customer, will pay you, the supplier, if the item is delivered based on the agreed terms.” If-this-and-that-then-this. If those conditions are not met, the funds aren’t released.

Remember how pizza places used to abide by the if it’s not there in 30 minutes, it’s free rule? It’s a perfect example of a supply chain use case that could leverage and benefit from a Simple Contract. As a pizza place, you definitely don’t want to worry about $50 million hacks, you want to keep it simple because there is money inside that contract and if there is money, you don’t want loopholes.

If there is only one takeaway from the DAO hack, it is that writing a strong and secure Smart Contract is extremely difficult.

Let’s use this scenario to explain how a Simple Contract could be implemented and triggered.

Business is good for Blockchain Pizza, they have loyal customers to whom they are committed to delivering quality pizza that is fresh and on time so they turn to Simple Contracts to help facilitate this.

When you order a pizza today, customers either pay upfront online or at the time of delivery, both of which carry a certain level of risk. As the customer, if you pay in advance you have no guarantee it will arrive on time or at all. If payment is set to happen once it arrives, the pizza delivery person can’t be sure that it’s a valid address or that the customer will have enough money to pay. They are counter-parties in this situation, they don’t want to trust each other and they don’t need to.

Predefined contracts can be set up with conditions that say if the location and time are correct, the customer pays 100%. If the location is correct but it arrives late, customers pays 50%. If none of the conditions are met, the customer pays nothing and keeps the pizza.

When someone places an order with Blockchain Pizza, the customer reads and agrees to the terms of the contract before the money is placed in a shared account which is unlocked only once all the conditions of the contract are met. These conditions are met by reading data that is automatically emitting to BigchainDB, requiring no work from either the customer or Blockchain Pizza. The pizza arrives, both parties agree the conditions have been met and the transaction is completed, releasing both the pizza and the funds at the same time.

The money and the contract live in a sort of programmable vault and to open this vault, you have to know the code. Locks for these programmable vault must be cryptographically sealed and have a connection to the data, meaning the lock must be able to communicate with that data input and verify cryptographic signatures.

BigchainDB facilitates this in two ways:

• Cryptoconditions which allow for a standardized format that acts as building blocks to express checks and conditions, specify signatures or other data points.
• A big data infrastructure which allows data to be queried efficiently.

When putting all the functionality inside one program which holds all the money and all the data, it’s often a race for hackers to find the weak spot that may have been overlooked, leaving the whole organization vulnerable.

The Implementation

For this to be implemented, Blockchain Pizza would have to set up a federation with BigchainDB. The GPS system of the delivery person would be linked and constantly emitting data of their location to the system. The delivery address would also be input to the GPS as the unit to match and then every second that the GPS is emitting that data, BigchainDB is recording the location and comparing the two. Because everything has been registered on BigchainDB, the data is easily fetched and the data stream is easily captured.

If a specific time has been included as a variable, this is recorded in the same way as the location. The current time, or the last emitted, substitutes the variable by the actual location and if that matches the delivery address, that condition is checked off.

A digital signature may also be required. A crypto-library would handle this by saying this signature is equal to this person. If the customer has an account, they could use the same key every time they place an order or there could a temporary ID generated for guests or one time users that would automatically expire after the delivery.

In this scenario, the customer has placed their order online, submitted money which creates an ID which resides on the value layer of the stack. Funds have been placed in an account that is registered in the same database where the order is, where the GPS data is and where time is being recorded. From the user end point it’s easy, they don’t see where the data is emitting to or even know of BigchainDB at all, no account needs to set up and no further information from them is collected. For Blockchain Pizza it’s easy because it’s working with sensory data and accounts. Once an order is placed, a virtual voucher for pizza money is created. This could also be referred to as “tokenized money.”

When putting all the functionality inside one program which holds all the money and all the data, it’s often a race for hackers to find the weak spot that may have been overlooked, leaving the whole organization vulnerable. When the program only uses data that is registered on the chain and not inside of the contract, human error is greatly limited.

BigchainDB is a big data solution that can store huge amounts of data because sensors, signals or events can just start pushing data onto the system. By using big data databases, BigchainDB can query that data and pull it into the contract when needed. Additionally, any legacy system or language doesn’t need to be thrown out or rewritten. BigchainDB becomes a part of your legacy stack that introduces you to blockchain features and adds a reporting, provenance and transparency layer across your entire ecosystem, while also allowing you to store value.

While Smart Contracts take an Apple approach in that you have to buy the complete package for it work smoothly or at all, BigchainDB’s API is open enough to have a communication channel between our system and others to make sure they communicate bidirectionally and interoperate.

BigchainDB’s Simple Contracts can be summed up in one sentence: you place funds on hold and if certain conditions are met, the vault opens and money is released. It doesn’t get much simpler than that.

Thank you to Dimitri De Jonghe for formulating and building these concepts as well as taking the time to explain Simple Contracts, the benefits and implementation.