Guest Post by Barbara Liau, James Prestwich, Conner Swann
Blockchains are isolated. Their state lives in a walled garden, at the top of an ivory tower, protected from easy access by the rest of the world. Within its domain, the chain’s execution environment manages running smart contracts, moving money and tokens between accounts, and updating the state store. The garden’s gates are controlled by public key authentication: signing a string with an account’s private key lets you initiate a transaction from that account. Messages are sent from an account once it’s established that the transaction originates from an authorized signer. Once execution starts, the environment manages passing messages between smart contracts and ensuring that execution eventually halts.
Authentication vs Authorization
Unfortunately, cryptography isn’t very expressive. It can handle authentication, but doesn’t give many tools for granular authorization. In Ethereum, a lot of research and discussion has gone into more complex authorization of access to externally-owned accounts (EOAs). “Account abstraction” aims to allow users to set arbitrary programs that control access to their account, so that tokens in the account can be moved by anyone so long as the movement follows specific rules. Newer designs like EIP-3074 provide many of the benefits of account abstraction at a much lower complexity cost.
Access Control List
Tools for controlling access to blockchain resources are usually standardized at the boundary between the chain’s domain and the rest of the world. At its most complex, available authorization schemes consist of the humble Access Control List (ACL) — access to a resource (ex: the mint function on an ERC-20 Smart Contract) is gated to specific externally-facing accounts. However, messages within a chain’s domain need authentication and strong authorization as well.
Even the simplest Ethereum smart contracts share the same point of tension: access to their capabilities are controlled by lists of addresses. Token contracts grant control over a balance to its owner. Decentralized exchange (DEX) contracts need to ensure they have received value before giving value away. While the Ethereum Virtual Machine (EVM) handles internal authentication (each message contains the address of its sender in the `msg.sender` field), it has no standard pattern for checking authorization. Each smart contract developer needs to make a bespoke access list system to track permissions on specific things. Mis-implemented authentication systems are at the root of a number of complex DeFi bugs, and have caused millions of dollars in damages.
The fatal flaw is shared by any system built with ACLs at its core. To quote the great blog post “What are Capabilities?” by Chip Morningstar:
When you run an application, as far as the OS is concerned, everything the application does is done by you. Another way to put this is, an application you run can do anything you can do.
These problems have been around since Operating Systems were young, and blockchains inherited them because ACLs are a well-documented, established, and relatively intuitive way of understanding access in a system. Newer blockchains, however, are rethinking this design choice in favor of a (relatively) newer permissions model known broadly as “Object Capabilities” (OCAP).
OCAPs, ERTP, and Zoe
“If your program has a reference to an object, it can call methods on that object. If it doesn’t have a reference, it can’t.”
In other words, unless you have access to the actual object, you can’t use it. Simply knowing the name of a variable or public class doesn’t give you a reference to an object. You can only get it if you 1) create it, 2) construct it, or 3) get introduced to it.