At Agoric, we’re a technology company solving a problem that dates back at least to Thomas Hobbes. In the 1600s, Hobbes pointed out an issue inherent in agreements between two parties engaged in a transactional exchange: The person who performs first has no assurance that the other individual will perform after because “the bonds of words are too weak,” in his famous phrasing, published in Leviathan, his classic contribution to political philosophy.
Hobbes was on my mind recently when I gave a talk at Stanford CodeX, to a group of legal scholars and technologists doing research in computational law. I talked about Zoe, our smart contract framework. This is where Hobbes’ concern about flawed agreements comes into play: Zoe adds a layer of safety to voluntary exchange that hasn’t been seen before. At Agoric we call that layer “offer safety.”
But First, What Is a “Smart Contract”?
We define a “smart contract” as a contract-like arrangement expressed in code where the behavior of the program enforces the terms of the contract. There are two important points in that definition:
• “Smart contract” now often means code that runs on a blockchain; our definition is broader and includes code running on a single machine.
• “Smart contract” might suggest a legal contract, but we consider legal contracts to be distinct.
Let’s start by looking at the ERC20 token standard on Ethereum. ERC20 tokens enable one-way payments, and the token contract has an internal mapping (let’s call it a registry) of accounts and balances. I’ve tried to replicate that registry in the below graphic. This is very simplistic, so bear with me, but let’s say that Alice has a digital asset. Let’s call Alice’s asset X, and she wants to transfer it to Bob. In the registry, or the ledger, as shown above on the right: first Alice has X, and then Bob has X. This is the exchange in a very simple depiction.
Let’s add some complexity. Let’s say that the payment should actually be conditional. Let’s say that Alice only wants to give X to Bob if Bob gives Y to Alice. If Alice does her part first, then we have a problem: At time T1, Bob has X and Y, meaning that he could walk away with both.
Oliver Williamson, centuries later, builds on Hobbes’ point, calling it an example of “opportunism,” or of “self-interest seeking with guile.” And Anthony T. Kronman, circling back to Hobbes, helpfully labeled this situation “transactional insecurity.”
All of which is to say, we’ve known for a long time, at least since Hobbes, that this is a societal problem we need to solve, and it’s traditionally been solved by mechanisms such as the legal system and reputation.
This is where smart contracts come in. Smart contracts solve this problem of transactional insecurity. If we introduce a smart contract, as shown above, instead of Alice giving X to Bob, Alice and Bob can both escrow their assets in the smart contract.
If you look at the registry on the right (above), you can see that at least in code, the smart contract is holding assets in the same way that Alice and Bob are holding assets. Whether this is actually legal ownership is something for legal scholars to weigh in on; I’m not an expert there. But what’s really cool is that if we give the assets to the smart contract, neither Alice nor Bob ever have access to both X and Y at the same time, and so we’ve solved the problem of transactional insecurity. We fulfill the exchange safely.
So that’s great. The problem, though, as you might have noticed, is the smart contract is holding all the assets now. Which leads to the question: What if that smart contract is buggy or malicious?
There’s a great paper called “Greedy, Prodigal, and Suicidal Contracts at Scale,” by Ivica Nikolic, Aashish Kolluri, Ilya Sergey, Prateek Saxena, and Aquinas Hobor, in which they defined three characteristics of Ethereum contracts that are probably problematic. “Greedy” they defined as something that locks up the digital assets indefinitely. “Prodigal” they defined as sending digital assets to an arbitrary user, one that hasn’t seen before, and this is most likely an attacker or some kind of mistake. “Suicidal” they defined to mean that the contract invokes the “suicide instruction” as part of the EVM, meaning that the contract deletes itself.
The paper’s authors analyzed nearly a million contracts automatically using symbolic execution. They found that quite a few of them were vulnerable to one or more of these issues. As a proof of the effectiveness of their technique, they found the Parity bug that had already caused the lock up of $100 million worth of Ether. So to reiterate, we’re talking about hundreds of millions of dollars worth of problems here in the smart-contract space.
Know When to Not Hold Them
Mark S. Miller, our Chief Scientist, and Dean Tribble, our CEO, came up with the following idea: If giving individual smart contracts control over digital assets is problematic, then what if the smart contract wasn’t actually holding the digital assets? What if we could outsource the escrowing of the assets to highly audited, reusable code? This is the idea behind what we call Zoe.
What we’re doing here is partitioning the risk in smart contracts. So there are really two roles:
The first role is escrowing and reallocating digital assets.
The second role is deciding how the digital assets should be reallocated.
I’ll explain what that means: By “escrowing,” I mean taking all the digital assets and holding them for safekeeping and that’s what our framework Zoe does. The second role is where your custom behavior or your complex business logic comes in. This might be, as we saw in the above example, just a simple swap. It may be an auction. It may be a decentralized exchange with an on-chain order book. It may be some complex mechanism design. It may be a negotiated contract that actually kind of looks more like a legal contract. The second role is where the decision of how the digital assets should be reallocated is made.
Defining Things in Terms of Offers
Conditional payments, where Alice wants to give X only if she gets Y in return, as in the example above, we call those offers. In an offer, you say what you want and what you are willing to offer in exchange. Going back to our example: Alice was willing to offer X, and she wanted Y in return. Bob was willing to offer Y, and he wanted X in return. This seems very simple and very obvious, but once you have users define things in terms of offers, then we can enforce this new safety principle that we call offer safety.
Under offer safety, a user is guaranteed to either:
• get what they stated they wanted, or
• get a full refund of what they offered
Okay, so how does this actually work? Above is a very high-level diagram of the concept in action. The parties to the smart contract escrow their digital assets with Zoe. The parties are able to talk to the smart contract, the smart contract is able to talk to Zoe, but importantly the smart contract never actually gets access to the digital assets.
Let’s say that the smart contract is an auction. Let’s first escrow the payment for our bid with Zoe. Then, we’ll tell the smart contract, “Hey, I put this amount of money in escrow. I’d like to make a bid on this auction.” Then the smart contract may send us information back saying, “Yes I’ve accepted your offer.” This information could be anything; it is up to the smart contract.
Then the contract does its own custom behavior. In the case of an auction, it may hold the bids until it gets a certain number of bids, or until a certain deadline has been met. But once the smart contract decides to close the auction, then it will try to reallocate the digital assets.
This is the very important part where offer safety comes in. First, the smart contract calls Zoe and tells it to reallocate with certain information, saying give Y to Alice, give X to Bob. Then Zoe checks that the constraints on all of the offers are met by this particular reallocation. Remember, for offer safety to be fulfilled, everyone must either get what they wanted, or get a full refund of what they offered. If offer safety is not met, Zoe rejects this reallocation, protecting the parties from malicious behavior by the smart contract.
If the reallocation passes offer safety and all of the other invariants, then the smart contract can complete the offers. Offer completion results in a payout to the parties, and that’s where the actual transfer of the digital assets occurs. Note that throughout this whole process, the smart contract never actually had access to any of the digital assets.
This may seem to be a very simple separation of roles, but we expect that the enforcement of offer safety will enable very rapid innovation in smart contracts. People who aren’t necessarily expert programmers, but who are subject-matter experts can build these smart contracts. And at the same time, we’ll be able to protect the users to a large extent from malicious or just poorly written code.
There are some caveats. Zoe doesn’t prevent smart contracts from misbehavior that still complies with offer safety. For instance, a second price auction might still choose the wrong winner. But, for digital assets, we’ve solved Hobbes’ problem of transactional insecurity. And more importantly, we’ve solved it for all of the future contracts that are written on Zoe, so that subject matter experts can experiment with smart contracts without worrying about their users locking up or losing assets.
Zoe is currently pre-alpha, but there is a JavaScript package that can be installed now:
● Install: npm install @agoric/zoe
● Documentation: agoric.com/documentation/zoe/guide/
● Code: github.com/Agoric/agoric-sdk/tree/master/packages/zoe
Thanks for reading! You can join the Agoric community on Twitter, Telegram, LinkedIn, and catch us at these upcoming events.
