On Our Inability to Read Minds
Here’s an opener I’ve used in many of my lectures:
“Can we predict, with a high level of confidence, the exact response of an individual, given an external stimulus?”
The question often confuses a few of the participants.
Essentially, I am asking if we can guess (with accuracy!) someone’s reaction to a certain action.
Take the following simple example: can I know what you’ll do after I give you $1,000? Well, I can most likely correctly assume that you will be happy, but I cannot be sure of what exactly you will do after my charitable donation.
I don’t know if you will decide to give me a hug in the heat of the moment, call your mom to tell her the good news, go grab a beer to celebrate, or do something I couldn’t even think of.
Thus, this rather straightforward action produces an unpredictable reaction. Even if I am able to narrow down the possible outcomes to a somewhat accurate set of feasible possibilities, it is unlikely that I will correctly guess someone’s reaction consistently.
Additionally, if I do manage to pick up on a pattern and choose to rely on it, I might just be setting myself up for disastrous consequences when that pattern is broken.
The reason we cannot predict reactions accurately is that we cannot read minds (yet), and this becomes problematic when our society requires us to take part in complex interactions that would be simplified if we could be sure of everyone’s behaviour.
To mitigate this problem we create incentives, which are often expressed via contracts — traditional contracts (we’re not talking about the digital world just yet).
Contracts are based on a robust system of incentives (i.e. the legal system) which have the aim of adding predictability to our interactions.
Think about it like this: because of the incentives in place, a contract gives its parties some sort of guarantee that they will reach desired output Y (or another equally desirable output) given the input X. As such, the parties feel more comfortable putting up input X.
It all boils down to Functions
Confused? Let’s go back to the original example. Let’s assume that for the thousand dollars I proposed to give you in the beginning of the article, I wanted something in return. Maybe I want you to paint my house.
In this case, from my perspective, the $1,000 constitute input X, while my house beautifully painted represents the desirable output Y (mathematically f: X → Y).
Without a contract, you would not want to begin painting before getting paid, and I would not want to pay you before you started painting. It would be impossible, or at least difficult, to engage in this interaction. The contract solves it all, however.
With a contract, if you do not comply with the established terms, I can sue you. That’s where we find the incentives: if you do not provide me output Y, you may have to refund me, or even pay me extra to cover any damages. In extreme cases, breaching a contract can even get you in jail. Given those incentives, I feel more secure that I will get to output Y, which is what I wanted in the first place.
Furthermore, if I don’t get my house painted, I should be able to get an equally desirable output Z: a refund plus some extra cash, for example. Maybe I don’t get Y, but I should get close.
Hence, independent of their formal definition, this is what contracts represent to me: a way for getting from X to Y in complex interactions. They work well, but require a lot of ground work to be effective.
A multitude of institutions must be in place to ensure appropriate incentives, and the process can be extremely resource-intensive (to enforce the terms of a contract we need paper, lawyers, judges, courts, etc).
Code comes with an amazing quality: determinism. Ceteris paribus, code will always generate output Y for input X. Thus, if I can examine or try out what a chunk of code can do, I can be sure of what I’ll be getting out of it.
Awesome — we can cut resources, automate processes and there’s no need to rely on complex human-based institutions anymore, right? Well, not really. If humans are the source of uncertainty we wish to eliminate, we are not really improving much.
And that’s because humans write code.
The Missing Piece
So then we have a problem: code is deterministic only to the extent that it is immutable.
If I rely on a specific program to perform certain operations and its code changes, it will suddenly not do what I want it to do anymore. It’s as if clicking on a button while browsing a website did something different today than it did yesterday.
It is for this reason that smart contracts were idealized all the way back in 1994 but only left the paper to became a reality with the launch of the Ethereum mainnet in 2015.
As defined by the “father” of the field, Nick Szabo, smart contracts are just “computerized transaction protocols that execute the terms of a contract”, so they could certainly have been implemented in the 1990s with the languages and tools available then. The problem was that there was no immutability.
The database administrator could play around with the data the contract relied on, and the maintainer of the code could change it, making it non-deterministic.
With Ethereum this finally changed. Ethereum allowed for the creation of immutable code, by leveraging two essential characteristics: public verifiability and open participation.
If it takes one person to change a given piece of code, you can say that piece of code is far from immutable. If it takes two people, it gets a little closer to immutability. But with thousands of nodes, we get near-immutability.
We cannot reach true immutability, but we can reach probabilistic immutability, and that’s huge. By allowing anyone to join the network and verify its operations, Ethereum (and the protocols that followed) made it possible for programs to be created that could not feasibly be changed.
With these deterministic programs we are then able to have a system which takes an input X and returns output Y, theoretically, forever & always.
And that’s why, in their essence, smart contracts are indeed contracts, despite what is usually preached by blockchain educators (past me included).
Sure, the differences between our traditional concept of a contract and a smart contract are endless, but at their essence, they fulfil the same purpose, only in different ways — they both turn X into Y.
What Should We Fight For?
Smart contracts have a few advantages, though. Given that nothing changes, they are sure to always return the same output. Furthermore, one can evaluate and test the code before using it, which guarantees a predictable output.
Traditional contracts, despite mostly serving their purpose well, are inherently ambiguous. Hence the need for lawyers. The same contract can lead to vastly different interpretations, and consequently, distinct outcomes.
That is inefficient at best and unfair at worst. Another benefit of smart contracts is that costly robust institutions (e.g. a legal system, a government, etc.) are not necessary for the maintenance of the system.
Complex digital protocols are needed, but those are vastly less resource-intensive than entire legal frameworks. Smart contracts are also not bound geographically, allow for the automation of processes, and, most importantly, can directly trigger necessary actions.
With traditional contracts, the document merely works as a set of guidelines which can incite the triggering of an action, if the parties involved choose to abide by it.
The paper cannot execute a transfer of money by itself, nor can it update the land registry. A smart contract, on the other hand, can trigger operations at the same time as it provides guidelines for action. The two purposes are no longer separated but rather integrated into one.
A smart contract could, for example, trigger an update to a land registry as payment is received for the sale of a house, notify the tax authority (or automatically deduct the tax), and transfer the token of ownership of the house to the buyer. Systems become integrated, automated, and more efficient.
This new technology is not perfect, however, and still has a long way to go to reach the level of the example presented above. Smart contracts are not ready yet (and to be frank, who knows if they ever will be) to fully substitute traditional contracts.
But the point is: they have disruptive potential.
Part of this potential can be exploited in closed environments, such as private blockchains, but in order to achieve all that they can possibly bring to the table, they rely on those two characteristics mentioned earlier: public verifiability and open participation.
Now, think about the so-called blockchain trilemma. It states that blockchain protocols can only achieve two of the following three traits: decentralization, security, and scalability.
Out of those three, where do you think public verifiability and open participation fit? So yes, we can sacrifice decentralization and achieve greater scalability, but decentralization was what got us here in the first place. It’s why smart contracts can do what they do.
We can always innovate and improve at the margins. But if we want a shot at disruption, it’s a whole different ball game. Going forward, it’s important to keep in mind what we are trying to achieve as we hope to upgrade our protocols to the next level.
So, should more transactions per second come at the expense of open participation? I’ll leave it up to you to decide.