Today I’m happy to start publicly sharing some early but working Ethereum tools that enable general purpose delegation in Ethereum. This is the culmination of years of thinking about what is missing from the computing blockchain ecosystem, and I’m eager to see what the community does with it.
A few things it helps address:
You don’t need to know any of this background to recognize the value and start using it today, so feel free to skip this section if you want to get to the practical bits.
In 2016 I first started becoming very certain that there was some kind of design that could allow highly dynamic and responsive social organizations. I recognized that Moloch DAO was addressing the same general issue but with a very different approach, which introduced latency. I had enough problems in mind that required highly responsive organizations that I wanted to find the best possible solution to social scalability that does not depend on time locks.
This problem was feeling very challenging in part because defining “trust” can seem damn near impossible. For simplicity’s sake, I took a detour and tried reducing the problem to lending: Representing what is risked as “just” money.
I spent a year reading any proposal I could for decentralized credit systems, but mostly found myself tearing them apart. My review of Dfinity’s Phi was pretty entertaining, I think.
I eventually articulated a concept well enough that my twitter community was able to direct me to some prior art, and that led me to two concepts that would end up guiding a lot of my work for the next couple of years: social collateral and object capabilities.
Social collateral in short is the idea that you can trust someone with anything as long as they value your relationship more than that thing. Your social relationship is a form of collateral. People don’t want to get cut out. There’s some great economics literature about how scalable and secure this tool can be, how it actually underpins the banking system already, and how it de-facto underpins most casual lending relationships.
My research on social collateral led me to seek patterns that could allow people to issue transitive allowances to each other (I grant you an allowance, and you can grant it to someone else), and that led to me meeting folks who have been working on systems like that such as Trustlines, Circles UBI, as well as approaches that focus on scalability like XLN (Extended Lightning Network).
I wrote a rough description of a specification in this gist on github, and was quickly directed to the zcap-ld specification at w3c by Mark Miller and Christine Lemmer-Webber, Agoric, and the extensive prior literature on what they call object capability security. What their work showed me was that the secure scalability properties of social collateral were not exclusive to the economic and financial, but could be considered a general framework for managing access around any sensitive resource.
This made a lot of sense, because a recurring challenge of defining a system of trust is trying to define trust, and reducing it to the form of a financial allowance was always obviously reductive. In the object-capability framework, you aren’t always granting a financial allowance delimited in dollars, you can provide access to any function, delimited with whatever computable caveats you can dream of. Here I felt like I had found home, where we were uniting the maximally secure with the maximally expressible.
In 2019 I wrote a public appeal for someone in the Ethereum ecosystem to take up this cause and implement it, but nobody did. I’ve been pretty busy making MetaMask, so I kept feeling pulled away from this, but during a break in early 2022, I finally took the steps to sit down and begin it.
The Delegatable framework does not achieve what I would call pure object capabilities, because it still involves developers needing to manage signature and delegation code, although I’ve started a library that hopefully makes it somewhat ergonomic. The object in object capabilities comes from object oriented programming, and is meant to mean that the syntax of the programming language itself represents the distributed delegation system as mere reference passing. Therefore, I might call this a capability security framework for Ethereum, but have chosen the name Delegatable Eth for the sake of trying to more simply convey the core benefit to the most possible readers.
The design of Delegatable Eth is extremely similar to and obviously inspired by zcap-ld, but with the unique feature of being validated by any Ethereum Virtual Machine, bringing its benefits to any Solidity contract that inherits from it, instead of simply bringing these benefits to a centralized server. By running a private blockchain as a validator, a consumer of Delegatable Eth could use it in a similar way to zcap-ld if they wanted to.
By inheriting from this solidity class, any contract gets a host of features:
Integrating the Delegatable library is as simple as inheriting from a solidity class, and overriding `_msgSender()` (and using that method instead of `msg.sender` directly).
Once inherited, the resulting contract allows any user to sign delegation methods that allow them to share anything they can do on that contract with anyone else. You can see some sample delegation signatures in these tests. These delegation messages are off chain, and include any number of “caveats”, which can include special restrictions like revocability, allowances, call limits, time limits, or eventually with some changes, even multi-sigs and additional forms of cryptography.
Some example caveats that a delegation message include:
You can look at how it works by looking at the implementation of the invoke method here. It can also help to read the type file that is used to generate much of the signature validation code. You can see what it looks like to sign delegations in JS with this library eth-delegatable-utils.
To help guide initial development, I chose to start with the anti-phishing registry use case as MobyMask because it a very simple contract, is a pressing and dire issue, has relatively low stakes if it turns out to be flawed, and it demonstrates a non-financial use case for a blockchain, which I think could be a useful cultural bridge for expanding the discourse of what blockchains are good for. I believe it’s valuable to think about how applications that minimize reliance on a blockchain can still leverage one for key security critical operations, like managing a sensitive access policy.
I think distributing negative reputation in the form of a phishing list is ultimately an incomplete solution, and is only needed on sites where public replies by default and paid ads are the norm, and this issue could be more completely eliminated by changing those norms, but via this tool I hope to demonstrate how these web3 tools can help solve web2 problems.
Long term, there are a wide range of possible uses for making a smart contract Delegatable, but I think it could benefit just about any smart contract. Some ideas:
Part of why I’m a fan of EIP-3074 or EIP-5003: AUTH_USURP is that they would allow any ETH account to benefit from all of the features I’m showing off in the delegatable framework for free, for all contracts they interact with, with no transactions needed until an on-chain action is performed.
If you’d like to try contributing to MobyMask, you can find it on github here.
If you’d like to try out the Delegatable framework, you can find it on github here.
If you want to hear me talk more on this topic and how it relates to my broader work at MetaMask, I discuss it a bit on the Epicenter podcast here.
If you’d like to join me and help build a more dynamic, secure, and cheap decentralized future, we’re hiring.
Thanks for reading ❤️