An abbreviated EthPM package description for an ERC-20 token implementation (full version)

Why package management is good

A great fundamental feature of software is that it can be copied essentially for free — when some software is created to solve a problem, that same software can be reused to solve that problem again and again, for many different people. That same software can often be extended to solve all problems of a similar nature. And even further, lots of software can be collected and bundled repeatedly, embedded inside other software, until that software and that solution are so ubiquitous that we can take them for granted and proceed to address more interesting problems.

Example Package: owned

The process of this reuse itself is a software problem: how do developers share code? How do developers borrow others’ code?

For instance, if one developer implements a simple authorization mechanism for their smart contract (perhaps where the “contract owner” has privileged access), then how can that same solution be widely available for other developers to use, without having to write it again or copy and paste the code?

To show some of the complexity of the software reuse problem, consider what happens next, after a piece of software becomes widely shared and reused. Suppose the “contract ownership” solution becomes ubiquitous and used by lots of developers. What if a flaw is found in that solution? Or if that solution can simply be improved in some way? Shouldn’t it be easy to share the outcome of this knowledge, to redistribute these updates with minimal effort, to everyone who is using the solution already?

This is a familiar idea in contemporary software development. Most programming languages and most computing environments have mature tools that make it very easy to do both packaging (the “sharing and reuse” problem) and versioning (the “software tends to change” problem). Most programmers are even used to solving problems by looking for existing solutions first.

Unfortunately, Ethereum and smart contract development (more generally) are new in computing, and so the development ecosystem has suffered from a lack of a well-tailored solution to this problem. Code is often copied and pasted (for example, I have personally seen more copies than I can count of the same Owned.sol file, in various projects, with minor modifications), or other languages’ package management systems are used (NPM, for instance³), and they do not completely handle Ethereum’s unique requirements for code sharing.

Why Ethereum presents a new challenge

Smart contracts are unlike other kinds of shareable code because they allow us to share them in a new way…

In contemporary software development process, the notion of a “package manager” is well-understood to represent a tool or service that lets you package up some code: give it a name, a description, a license, and importantly, an interface by which others can use your code, without their needing to understand your code’s specifics.

Code of this form is a static, lifeless blob of computer-encoded text, a written set of instructions to tell the computer to do a certain thing at a certain time. It might be a stand-alone program, like a web-browser or a tool for running automated tests, or it could be a software library, a building block for larger programs, something that provides the interface for a human to express an abstract idea in a way the computer understands.

This kind of code, the “set of instructions” metaphor, is still extremely useful in Ethereum. Owned.sol is a software library that provides the building block abstraction of “contract ownership.” If you are a smart contract developer who wants to leverage the idea of contract ownership, you need look no further than this.

But code on Ethereum, a smart contract, is more than that…

A smart contract⁴ persists as a unique and active component of the blockchain.

It persists as a continuous entity with its own history and memory — an internal state.

It gets its own wallet and can be programmed to spend its own money.

And anyone, human or machine, can interact with it, through its very own programmed external interface.

A smart contract provides all of the features of shared static code, plus this new feature: this persistent state. Using smart contracts, we can build, for example, a scarce digital asset, a fungible token⁵. This is not just some code for executing transfers and approvals, but is also a historically consistent record of everyone’s balance.

On Ethereum, to package code for reuse, we must be able to package it in its static form, and we also must be able to describe these running smart contracts. We might want to share the abstract notion of a token contract, or we might want to share a specific token contract, with its own address, maintaining a fixed supply of tokens and reliably tracking balance.

Aside: There is a strong analog to smart contracts in traditional computing. Modern computers represent the idea of a process, a running program that is currently active, possibly waiting for user input or crunching numbers. Smart contracts are like running processes, except that the process is designed to be public, interacted with by the world, with the sense that the same process will run forever in continuity. Hence, “the world’s computer.”