Solving Software’s Oldest Problem: Good Tech is Not Enough
Why Aragon’s community represents more than just the future of Aragon
To the Aragon community —
I’m Alex Wade, from Authio. My research on smart contract upgradability began in 2017 with two articles, posted by Zeppelin and Aragon. I was intrigued by the ideas set forth in the articles, and was inspired to create auth-os: an experimental upgradability protocol that aimed to build public smart contract infrastructure capable of operating on a global state. Developing alongside ZeppelinOS and aragonOS significantly informed my development as a smart contract auditor.
Following the recent approval by AA vote to include our proposal (AGP-18) on the ballot this January 24th, I felt prompted to contextualize our submission. This article aims to provide prospective voters with an idea of what to expect from Authio, should they select us as their “Aragon Network Security Partner.”
Thank you for your careful consideration.
On October 29, 2018, holders of Oyster Protocol’s PRL token received an unusual update from the Oyster Protocol Twitter account. The tweet read:
“Trading of Oyster PRL on @kucoincom has been suspended for the time being.”
Not 20 minutes later, the reason for this message became clear. Detection of atypical activity in the PRL token contract had prompted an investigation, revealing that an unknown actor had minted some 3 million PRL and sold them on the Kucoin exchange. Half an hour later, Oyster Protocol issued an update to their users:
“No smart contract bugs in Oyster Pearl have been found and the contract passed 3 separate audits.”
Responses on Twitter were understandably mixed. Many expressed doubt, most expressed confusion, and a few even appealed to a higher power.
How does a smart contract pass three separate audits with such a clear issue? Why, according to Oyster Protocol, did this not constitute a “bug”? And how does such a function go unnoticed by the token’s 13,000+ holders?
The answer is found in a fundamental property of software: without parsing every individual line of code, you cannot possibly have a complete picture of the software you use. This property has existed since the inception of modern computing in 1936, but the extent of its ramifications are only being realized in the past decade.
The rise of platforms like Facebook and Twitter has sparked heated debate around the role each should play in consumer safety. The fake news epidemic has shown us that our addiction to social feeds can be used to manipulate public opinion. The placing of public figures in “Twitter jail” has prompted questions about the effectiveness of Twitter’s Terms of Service. Inevitably, though, the same persistent notifications, bells and whistles these media conglomerates thrive on prove an effective opiate to dull our senses towards these red flags.
These phenomena have not gone unnoticed, however. The recent surge of interest in cryptocurrency as the foundation of a new Internet-of-Value, “Web 3.0,” can be attributed to growing sentiment that “our” data should be our data — and not the property of a few controlling parties. We the people believe that the terms of this implicit agreement are unacceptable, and continue to work towards a better one.
In the pursuit of innovation, it’s important to stay focused on your ideals. Building Web 3.0 on a foundation of open-source software is a positive step towards a transparent “Terms of Service” for its users— but it’s far from complete. After all, Oyster Protocol open-sourced their contracts, but the recent Twitter incident made it clear the community did not share the developers’ understanding of the PRL smart contract.
Was the sudden minting of several million PRL a bug? Yes — but not because of a problem with the Solidity in which it was written.
The crucial distinction that makes the PRL event a bug was the developer’s understanding that this behavior was permitted by the code, whereas the community did not. A “bug” in a smart contract has little to do with generic issues in written code. Rather, a bug manifests itself as a disparity between developer communication and consumer expectation.
Auditing Software’s Social Contract
A user’s interaction with software is predicated on their perception of what the software is supposed to do. This perception is influenced by the developer’s translation of what the software actually does. The use of software invokes the terms of an implicit agreement made between user and developer.
The ambiguity of software is the reason security auditors are such a vital part of the Ethereum ecosystem. Without an impartial body of software engineers, the users of Ethereum’s apps will need to blindly trust that they understand the behavior of every smart contract they use. It would be an understatement to say that this trust does not lend itself well to the needs of the consumer, nor does it make it easy for a developer to attract new users.
Auditors bridge the gap between these two groups. In a way, they act as a conduit for communication that helps the user understand what the developer has built, and helps the developer earn trust with users.
Oyster Protocol disclosed that the PRL contract had received three separate audits. Without access to their reports (or any other pertinent information), it’s impossible to know exactly why the auditor relationship failed both parties — but the nature of the bug is telling. The PRL contract’s Achilles heel involved one of the widest-used smart contract development paradigms: the onlyOwner permission pattern.
The Importance of Alignment
The developers of smart contracts must contend with the fact that a smart contract’s implicit agreement is dependent in part on the understanding of the code’s behavior and purpose. Even as one user correctly approximates the code’s intended behavior, another user may arrive at a wholly different expectation from the same sources. As a result, the “correctness” of a smart contract is defined over a diverse, dynamic topology of users.
It is the nature of software (smart contracts included) that things will always change, will always break, and will always need fixing. Putting software on Ethereum doesn’t solve this problem, nor should it. Our code, much like our laws, should always be improving and evolving. The impossible problem Ethereum’s developers often find themselves faced with is how to maintain the trust of their userbase, while remaining flexible enough to adapt to the platform’s inevitable change.
The onlyOwner bug arises directly out of this question: according to Oyster Protocol, the same administrative permissions that allowed the attacker to mint tokens was also necessary in the PRL contract to maintain its adaptability. The PRL contract was intended to be slightly pliable: enough to give the Oyster Protocol team space to amend a few important components of the contract — without handing over complete control. The trade-off made is one every auditor has been asked to review: that some portion of a smart contract remain under control of a few individuals, to help maintain an evolving social contract with consumers.
This trade-off is perfectly legitimate, but can be problematic. In the case of PRL, the administrative permissions likely should have been significantly more restrictive — it’s clear that the attacker was afforded too much flexibility. The other side of this flexibility can be just as dangerous. Insufficient ability to adapt to a rapidly changing development environment and userbase can leave applications irrevocably broken.
Smart contracts that do not strike the balance between relative upgradability and relative centralization of control will inevitably run into problems. If our goal is to decentralize software’s social contract, we cannot advance without widely-used and understood protocols for governance. Without sufficiently powerful governance mechanisms, smart contracts cannot safely implement the flexibility they desperately need to service viable, relevant applications.
Governance mechanisms can align the interests of the developer and the consumer, who can, together, ensure that the code evolves:
- to accommodate changes to Ethereum that alter the fundamental properties of a smart contract’s terms;
- to address previously unrecognized issues that evade initial detection;
- to amend, extend, and otherwise modify the code’s implicit agreement — just like we amend, extend, and modify software all around the world today.
These benefits are critical to the security of Ethereum’s applications. If Ethereum’s ideal is to enable the creation of “unstoppable applications,” it had better ensure its applications can adapt to change.
A Responsibility to Participate
As members of the Aragon community, ANT holders represent the foundation of a community that has the power to re-write the implicit agreement we so often make with software. The ethos on which the community operates aligns strongly with that of The DAO, which is simultaneously one of the greatest successes of, and most catastrophic failures of, Ethereum.
The principles on which The DAO was founded made Ethereum what it is today as much as the lessons learned when it was destroyed. We the community have been hard at work devising and building radically improved smart contract systems. Our understanding of what went wrong has evolved along with our code, and Aragon’s development has been at the forefront of that evolution.
We’ve got the tools to take it to the next step; aragonOS represents a strong candidate for the foundational platform of “The DAO 2.0,” and the constant efforts towards improvement made by the Aragon One team continue to stretch the limits of the EVM. “The DAO 2.0,” and by extension, Ethereum, will never succeed without a vocal community. As members of that community, ANT holders have a responsibility to make their voice heard to evolve the implicit agreement Aragon represents. The best way to do that is to participate; the best time to act is now.
Move fast. Break things. Learn, and improve.
And most importantly — vote.
