Imagine a futuristic scenario in our not-so-distant future in which we can live in a fully automated world where technology dictates what we can or what we can’t do and where code is essentially law. To decide whether this Vonnegut meets Judge Dredd sci-fi setup sounds utopian or apocalyptic I leave it up to you but in theory smart contracts can take us closer to such an imaginary world with their automated and deterministic design.
How do they work?
To create a bit of confusion, let us start with the fact that the name “smart contract” is a bit misleading as smart contracts are not particularly smart nor really a type of contract (in the traditional sense of the word) in reality. Smart contracts are a piece of code that can be executed on the blockchain automatically giving them the advantage of being trustless and secure. They are especially good at removing the human factor from the decision-making process which is arguably one of the most error-prone and unreliable elements in that chain.
The original concept of the smart contracts was created by Nick Szabó in 1997 and his description might still be the best to this day. He describes them as:
- A set of promises
- Specified in a digital form
- Including protocols
- Within which the parties perform on those promises
For the conspiracy theorists among you, there is an unconfirmed belief that Nick Szabó might be the person under the alias of Satoshi Nakamoto (or part of the group of Nakamoto) who created Bitcoin in 2008.
The protocols mentioned above usually follow a simple if-then semantics, essentially describing the mechanics of what happens when a certain event occurs or when a certain condition is met. There is no AI or ML involved in this execution and this is why some people actually refer to them as “dumb” contracts as they are just algorithms performing a function.
The Vending Machine
Arguably, one of the most frequently used examples of how a smart contract can be easily imagined is a vending machine as it has a similarly straightforward and deterministic working. If I have 5 bucks and the machine has the drink I like, I inserted the money and I entered the product number then I get my well-deserved refreshment. The huge benefit is that we could lower the transaction cost by automating the process as we eliminated a buffet and its employee standing there 0-24 handing out cokes.
Similarly, for example if there is a crowdfunding goal set and a given Ethereum wallet receives enough ETH to surpass the balance required, a smart contract can automatically execute the necessary actions to set the wheels in motion and make the project happen. The important thing here is that there is no intermediary (like Kickstarted or Indiegogo) necessary that would be needed to be trusted, the whole operation can rely on code and that opens up countless new opportunities. This is why we often refer to these solutions as “trustless” but in fact, the trust is simply shifted from big central companies like banks or internet giants and it is put into technology and ‘cryptographic truth’ (but more on that in a separate article).
If you are really curious about the topic and want to deep dive, I highly recommend starting with MIT’s open course wave series to build a solid foundation. In particular, this lecture with Prof. Gary Gensler and Prof. Lawrence Lessig as Mr. Lessing perfectly explains one of the biggest “challenges” of smart contracts today, namely how they fit into our legal system. We can write smart contracts about many things but that doesn’t mean they are going to be legal and even if they are, they are not uniformly controlled or accepted by the law globally.
To go back to our vending machine example, when we buy our drink we automatically expect that the product we get meets certain standards and won’t upset our stomach for example but this is not in our “virtual” smart contract, this is provided by the state behind it making sure that certain food quality requirements are always met.
Hybrids and Oracles
A smart contract becomes hybrid when it needs data from outside of the blockchain. Blockchains can be imagined as isolated networks, like a computer with no Internet connection. So on-chain code and off-chain infrastructure need to be combined to support advanced decentralized applications (dApps) that are able to react to real-world events and interoperate with external systems.
To continue our growing list of examples, lets say we want to set up an insurance company that automatically pays when our flight is delayed by more than X minutes. It is really easy to write such a code but flight data comes from outside, it is provided by external systems which makes the mechanism as a whole less secure. Blockchains are highly secure and reliable because of their key design principles. They only need to form consensus on very basic binary questions using data already stored on their own ledger. At the same time, blockchains are much less suited to answer questions that are more subjective or require external data that is not easily accessible to every node in the network. Questions like ‘What is the weather in New York?’ or ‘What is the current market price of Ether?’ can elicit many different answers that may vary depending on which data source we look at and when we check the data given by the source. This introduces a new challenge, as we need to determine what the correct answer is and how it can be verified as true.
Blockchain oracles are secure pieces of middleware that facilitate communication between blockchains and any off-chain system we need, like data providers, web APIs, enterprise backends, cloud providers, IoT devices, e-signatures, payment systems… etc. so these blockchain oracles provide the information that is not dicertly available on the chain.
Reputation based on on-chain performance history
Whether we talk about Input, Output, Cross-chain or Compute-enabled oracles, the minute we start to use them we open the previously mentioned Pandoras-box to a whole host of security, reliability, governance and even scalability concerns, risking the main advantage blockchains aim to provide and it is for this very reason that oracles are not directly integrated into the base layer of blockchains.
On the other hand, they are a necessary evil as 90% of the real-world use cases need these added layers in order to provide true value. The main concern is how to ensure external data inputted into the blockchain is (sufficiently) high quality? The broad range of blockchain oracle services means reputation is key in choosing the best oracle service provider and performance history based reputation can give users and developers the ability to monitor and filter blockchain oracles based on certain parameters they define. This reputation is provided by the fact that blockchain oracles sign and deliver data to the immutable blockchain ledger so their performance history can be tracked, analyzed and presented to users through interactive dashboards such as market.link and reputation.link.
If you want to discuss the “blockchain oracle problem” or just need a smart contract for your soda machine, don’t hesitate to contact us as we truly love this topic.
