Upgrade Driven Development

About

This is a simplified overview of ideas regarding a design philosophy for developers building applications on the Ethereum blockchain. It builds upon many conversations I have had with developers both inside and outside the Ethereum ecosystem. It builds upon a talk I gave in March at the Ethereum Community Conference in Paris. It is an attempt to create an inclusive, positive alternative to prevailing blockchain design thought in a way that fosters and encourages developers to create exciting on-chain applications.

As a note, I am Developer Advocate at Zeppelin, which means I am a bit predisposed to thinking of things in terms of the software we create, in particular, ZeppelinOS. That said, the ability to upgrade smart-contracts in the Ethereum space is not exclusively a Zeppelin project and there are a number of proposals such as ERC1538 and EIP-1822 which are working to try and standardize the use of proxies to build upgradable smart contract applications.

What is Upgrade Driven Development?

• A design thinking for iteratively creating dynamic and secure smart-contract based applications on immutable blockchains.
• Understanding that the governance processes behind the decision of how what and when to upgrade on-chain deployed software is critical to the trust expectations of users.
• The governance processes for upgrading should be considered early in the software development process and communicated clearly.
• Embraces a philosophy of isolation of risk, via practices such as code composability which creates smaller units of more easily testable, and understandable code.
• A belief that complex and creative applications can be safely and securely built on immutable blockchains with thoughtful design.
• Developers can abstract applications into composable units of trust, risk, responsibility, finance, and code.

If you are interested in more background on some of these ideas, I cover a number of them with some examples in my talk below:

Recorded live stream from ETHCC 2019 in Paris

Why is this relevant?

Legacy smart contract developers are informed by the Ethereum communities traumatic experience with high profile code failures such as the DAO hack and Parity wallet hack (among many others). These experiences, (combined with other limitations such as gas) have led developers to attempt to migrate functionality off-chain, (partially with the expectation that their exposure to immutable on-chain errors will be minimized) and to reduce the size of their code base (and auditing costs) by eliminating functionality.

The result is a reduced variety and diversity of on-chain applications, as developers fear to create ‘dangerously’ complex and difficult to test on-chain smart contracts.

Developers reflexively err on the side of caution when the surface area of attack is unclear and recovery/repair options for mistakes is limited. This effect is magnified by the communities legacy dogma surrounding governance which causes developers to doubt the wisdom of upgrading.

This doubt and inflexibility has had a negative effect on not only existing developers but also on larger traditional enterprise customers considering the blockchain space. The narrative of inflexible, potentially compromised code, that can result in irreconcilable losses, is unacceptable for many potential ecosystem participants.

How does Upgrade Driven Development offer an alternative?

Upgrade Driven Development offers a design narrative that is positive in nature and more in line with the workflow of traditional software developers. Software bugs are treated as design flaws which can be planned for, rather than existential threats.

Developers should assume their code will have unforeseen errors, and design in such a way that danger can be detected, compartmentalized and isolated to minimize the impact of catastrophic events.

Upgrading is the tool that allows developers to swap compromised or out-dated application blocks with newer versions of code. This involves educating developers that planning for the upgrading of code needs to be considered during the planning phase of a project.

By encouraging developers to build an upgrade path for individual components into projects at the planning phase, they have the freedom to decide at a later point how much or how little code mutability they actually need. This decision is much harder, or impossible, to do in reverse depending on the stage of product development.

Upgrade driven development brings Ethereum smart contract development in line with traditional software development. It builds upon the known processes of test-driven development and offers developers a tangible philosophical approach to confidently create secure, dynamic, and creative code.

Have a boat. Because people hate too much text in blog posts. Photo by Matthias Jordan on Unsplash

How can this support the Ethereum development ecosystem?

The adoption of an upgrade driven development narrative creates a solid market need for developer tooling and services. Taking the reintroduction of Test Driven Development in the early 2000s as an example, an entire industry has been created to service the needs of developers who adhere to its principles.

Test libraries such as Mocha, Chai, Istanbul (in javascript) have become industry standards. Continuous integration tools such as Travis-ci (which would not be possible without standardized testing tools for software) are now the norm and widespread. The Ethereum ecosystem has a number of nascent testing frameworks and as development increases I expect these tools to mature and proliferate.

A philosophy of development where code can be upgraded opens a door to the creation of an entirely new suite of developer tools- tools that in many cases, already exist in other programming languages. The creators of these tools have a substantial opportunity to capture the mindshare of developers in the smart-contract software ecosystem.

A recent uptick in the number of different projects that are proposing standards for upgradable code and proxy tools is evidence that upgrading on-chain code as a concept is gaining mindshare among developers and teams.

Questions:

Is this a temporary problem?

It is possible that upgrading is a “temporary solution to a temporary problem” due to the ecosystems nascent experience building immutable code on a public network. Future versions of the Ethereum network may support native code-upgrades if it becomes clear that having such a feature is valuable at the protocol level.

However, upgrade driven development is not a product itself, rather it is a design philosophy which supports a new narrative. It is unlikely that the practices of code-composability, isolation of risk, governance decisions, etc… will become outdated anytime soon.

The core ideas of upgrade driven development are also not new or unique and are in many ways just plain healthy programming coming sense.

Is it “snake oil”?

No. While upgrade driven development is certainly more of a nebulous philosophical idea, it does offer a positive counter-narrative to the prevailing narrative of blockchain development. The risks of smart-contract development are known, and with proper planning can be mitigated.

This narrative, like most ideas, is ‘open-source’: open to interpretation and definition by the community. As the blockchain space matures: practices, philosophies, and tools will naturally become more mature, robust and well defined. The ‘wild-west’ nature of smart-contract development today will eventually give way to standard practices that more resemble traditional software development. Upgrade driven development is a contribution in that direction.

Does it scale?

Yes. As Ethereum scales, so will the necessity for more complex, more dynamic applications with larger code bases and expanded functionality. Layer two solutions such as Skale, Loom, POA, xDai are still immutable blockchains, but with gas fee structures that allow for vastly different amounts of on-chain computation when compared to the Ethereum main net.

As the complexity of applications increases, so will the necessity to iteratively add features and fix bugs. This is where the philosophy of designing for upgradable code bases will become even more important.

Smart contract developers will not be able to design this kind of software for these networks with the current philosophy of single, monolithic applications, with no upgrades and perfect code-bases.

Does Everything need to be upgradable?

No. Developers are free to consider which elements of an application require an upgrade path. Not all applications, nor all components of all applications will require an upgrade path. Some applications will leverage immutable code-bases as a feature, while others will mix and match based upon the project needs.

How does governance fit into this?

Who decides what to upgrade and when will always be an important design consideration. The complexity of governance should not scare developers away from its’ potential. Some elements of an application could be upgraded via a multi-sig of core developers, while others can be controlled by a DAO (Distributed Autonomous Organization) or other programmatic means. Governance can be designed to match the task at hand and reflect the nature of the component being upgraded as well as the stakeholders involved.

Follow me on Twitter

Special thanks to:

The team at Zeppelin, Ramon Recuero, Santiago Palladino, Demian Brenner, Martin Triay and the many developers I’ve spoken with inside and outside the Ethereum community.

Upgrade Driven Development was originally published in Hacker Noon on Medium, where people are continuing the conversation by highlighting and responding to this story.