-
Notifications
You must be signed in to change notification settings - Fork 28
A (Hopefully) Simple Overview
In this piece I'll try to explain Codius and "smart contracts" using two examples: purchasing goods from an online marketplace (e.g. eBay, Craigslist, Alibaba) and buying a house or renting an apartment. Smart contracts are a powerful and open-ended technology so they can be difficult to understand in the abstract. Here I hope to explain a bit of the what, how, and why you should care.
Let's say I want to buy something decently expensive from someone on eBay, Craigslist (in another location), or Alibaba. For this example let's say it's a cell phone. The seller will ship the phone to me using FedEx, UPS, DHL, etc.
The biggest problem from my perspective is that I may pay for the phone and then the seller might never ship it. The biggest problem from the seller's perspective is that they may ship the phone and I might never pay for it.
Right now, what is our recourse if one of us cheats the other? There might be a reputation system that would help others avoid being cheated in the future, but that doesn't help us now. Maybe we could take the other to small claims court (if we're in the same place) or hire some kind of collection agency. Either way though this sounds like an awful lot of time and money that'll quickly outweigh the original cost of the phone.
How could a smart contract help here? (Don't worry, I'll define what that actually means very soon)
Well what we'd ideally want to solve this problem is the following. I transfer the money to a holding account that is not under my control. The seller can verify that the full payment is in the holding account so they feel confident sending me the cell phone. Then, once I've received the phone the payment is automatically transferred to the seller. If the phone is never shipped the payment will be returned to me automatically.
A smart contract is an agreement that has been translated into a computer program that can automatically check the conditions of the agreement and execute the penalties or outcomes.
In this cell phone example the conditions and outcomes are fairly simple so we can "translate" our agreement into some computer code that will automatically check the shipping status and pay the seller or return the money to me. This is our "smart contract", or self-enforcing agreement.
(Note that we can include more complex conditions as well, such as the possibility of bringing in a third-party arbiter or even a "crowdsourced" service if I received the phone but in poor condition, or if something else goes wrong.)
Recently the development and proliferation of "cryptocurrencies" like Bitcoin and Ripple has caused a surge of interest in smart contracts. The reason is that in most financial systems today programs like smart contracts cannot hold bank accounts. They may be able to act on behalf of people but the program itself cannot have exclusive control. Since cryptocurrency networks are purely digital anyway, programs like smart contracts can actually be given exclusive control over funds transferred to it. This is extremely useful for smart contracts because it means that the agreement we have programmed can hold onto and move the money we've put in escrow such that neither of the parties involved in our agreement can withdraw them improperly.
The problem we have now is who will run this program.
I don't trust the seller to run the program because they'll run it on their computer and then tell me that when the code ran it said all the money should go to them, even if they did not ship the phone. The seller doesn't trust me to run the program because I'll run it on my computer and say that all the money should come back to me, even if the seller did in fact send me the phone.
What if we could give this program, our smart contract, to someone else to run, someone neutral that we both trust? A big company like Amazon or Google might be sufficiently trustworthy because it's not worth it for them to collude with me or the seller just to cheat the other party in our relatively miniscule agreement.
What if we don't want to trust any single party though, for fear they might get hacked or might actually try to cheat one or both of us?
What if we could give the same program to three big entities and as long as two of the three agree on the outcome it will work properly? What if we could give it to 10, 100, or 1000 different companies or people to run? The likelihood that 7/10, 70/100, or 700/1000 unrelated entities will collude just to cheat either the buyer or seller of a single cell phone is practically zero. Since the money will only move based on a threshold that we set when we create the agreement -- it could be 51%, 70%, 95%, whatever we choose -- I, the buyer, and the seller can only be cheated if this threshold works together to manipulate the program's reported results. Imagine we picked a set of institutions across different continents to run the code -- international diplomacy would have to happen before those parties would collaborate. And for what? To mess with the outcome of a simple cell phone sale. Not likely.
So who are these entities that we can trust to run our program? They are what we call "smart oracles".
The idea of smart contracts is not new and many previous proposals for how to implement them included additional entities called "oracles" that would provide information about the non-digital world to smart contract programs.
In our white paper we propose making these "oracles" smart as well and using them not only as sources of information but also as the entities that will run the code of our agreements.
Smart Oracles are entities that faithfully run smart contract code.
As was mentioned in the previous section, we can choose to trust a single smart oracle or we can entrust the execution of our agreement to a group of smart oracles that we merely trust not to collude.
(If you are interested in more of the details of Smart Oracles, our implementation Codius, and why we think this provides the most powerful and flexible way to implement smart contracts, take a look at the white paper.)
Alright, I kind of understand all this talk about turning agreements into code and getting some neutral parties to execute the code. So what? What else does that get me and why is there so much hype about this topic?
Another type of contract that people commonly enter into involves either purchasing a house or renting an apartment.
Purchasing a house is relatively similar to the example of buying a cell phone, albeit a bit more expensive. If there were, say, a digital title to the house we could set up a straightforward automatic escrow contract. The smart contract program could be given exclusive control over both the title and the money and automatically exchange them or return it if one of the parties did not uphold their part of the agreement.
Renting an apartment is a slightly trickier case to translate into a smart contract, but it's not inconceivable.
The terms of a rental agreement generally follow this outline: "the renter gets to live in the apartment provided that they pay X per month to the landlord and there will be a security deposit of Y put down at the start to cover unpaid rent or property damage but that will be refunded if there are no problems".
What if instead of handing my security deposit directly to the landlord I placed it in an automatic escrow account, similar to the one from the previous example? This time the smart contract controlling the funds would check that I am paying my rent each month and could automatically deduct money from the security deposit if not.
One possibility that is a bit more out there involves the idea of "smart property". What if the key to my apartment were not a metal key but a digital device that would look for authorization from the smart contract controlling my rental agreement? The key (and door) of my apartment would then help enforce the part of they agreement that says I'll pay my rent on time. Admittedly that's a bit of a scary prospect from the point of view of the renter but I would know exactly what the terms are up front and could trust that the rules would be executed precisely as we had specified from the beginning.
For this example, let's say I'm good about my rent payments so I get to the end of my stay without any breaches of the agreement.
What do we do about the security deposit? In the best case, both the landlord and I agree on exactly how much each of us should get from the escrowed funds. In the worst case, I say I should get it all back and the landlord says they are entitled to the full amount, because of some damage I caused.
Currently the renters have little or no recourse because the landlord is already in control of the security deposit, so the renter's only option might be going to small claims court. From personal experience I know that this is a hassle for everyone involved.
Using a smart contract we could specify at the beginning of the agreement that in the case of an unresolvable dispute we would go to a particular third-party arbiter. When a dispute arises we could go directly to this individual and whatever they agree upon with either of the parties is followed by the smart contract controlling the security deposit. Here's where we can get even more creative though.
What if instead of picking one person we picked a group of people? As long as the landlord and I trust these people not to collude with either of us we can trust that their judgment will be reasonable and the contract will execute the results immediately.
Both of the examples above use an automatic escrow account to handle some of the potential problems that may arise when an agreement is carried out. The problem with escrow is that it is an expensive way to handle dispute resolution. The money would add up quickly if I needed to put funds in escrow for every contract I enter into.
One alternative to escrow is insurance. If both of the parties of a contract have insurance policies with reputable providers each of us can trust that even if the other contract party cheats us, we will be compensated by the insurance provider.
Another alternative is a reputation system. Imagine if the automatic penalty a smart contract could impose for a breach of the agreement were publicly posting to a kind of digital bulletin board. If that reputation were used widely enough this would be a significant threat and could be used to avoid breaches of smart contracts.
Identity -- and in particular decentralized approaches to digital identity -- is an interesting and complicated topic so more on that later.
As previously mentioned, "smart property" could check who owns it or has the right to use it. An oft-cited example is of a car that only unlocks for the owner, someone authorized by the owner, or the car dealership if the owner hasn't been good about their lease payments. Other digital titles could automatically enforce the conditions of their transfer.
The system I've described enables two or more people to turn contracts and other types of agreements into programs that can automatically enforce penalties and transfer digital assets.
This could make doing normal business a whole lot easier for a lot of people whose only recourse right now is to go straight to the legal system. Since there will undoubtedly be cases that are not easily foreseen or translated into code, we don't see smart contracts replacing the current legal system. However, we do think they could make the legal system a lot faster and cheaper for many cases and smart contracts could provide a useful layer between people and the traditional legal system.
On top of all of this, there are many applications that have got technologists salivating over the possibilities (distributed computing, open source services, automatic bridges between cryptocurrencies), but I'll leave those for another post.
I hope I've answered the questions about what smart contracts and smart oracles are, explained just enough about how they work to make some sense, and given a bit of a taste of why they're interesting. If not, please post your questions on the live chat: 
By Evan Schwartz