Uniswap Labs Blog

The Unix Philosophy at Uniswap Labs
April 05, 2023

By Zach Pomerantz

The Unix philosophy, popularized in the 1980s, emphasizes breaking down complex software systems into smaller, interchangeable pieces of code that developers can easily reuse. While it may seem like conventional practice today, it was revolutionary when developers were far more focused on monolithic systems. This approach became popular among developers, allowing them to ship better code faster and get new technology into the hands of users without delay.

Web3 applications, which generally exist in a public and open-source ecosystem, have embraced this philosophy to develop software. By sharing useful code across developers and building on emerging standards, Web3 developers create increasingly sophisticated software at a rapid pace. I see this directly with how quickly we can ship code at Uniswap Labs.

In drawing from the Unix philosophy, Web3 developers have been able to work in real time with developing technology to solve challenging problems. This approach has revolutionized how software is built and is a testament to the power of collaboration and shared standards.

Unix Philosophy and Web Development

The Unix philosophy emerged with the development of the Unix operating system. Later summarized by Peter H. Salus, the Unix philosophy was distilled to:

  1. Write programs that do one thing and do it well.
  2. Write programs to work together.
  3. Write programs to handle text streams, because that is a universal interface. 1

These three brief principles result in simpler code that can be easily combined to perform more complex operations. For example, copying and pasting text from one file into another:

cat file1.txt | pbcopy
pbpaste > file2.txt

Each CLI command is a tool whose combined inputs and outputs can be piped together for more useful actions. String together enough commands, you can build scripts or create new and reusable tools to perform more sophisticated tasks, elevating the playing field for all developers. From Unix came the POSIX specification, a standard library to maintain compatibility between operating systems. It was a big step that allowed us to focus on our applications without worrying about tasks delegated to these foundational tools, like file system access and permissions.

Fast forward a few decades, and we see the Unix philosophy break new limits. Node.js and its package manager, npm, gives JavaScript developers better tools for more sophisticated software. Instead of coding smaller tasks, npm provides foundational libraries like left-pad. These allow programs to delegate smaller tasks and keep their application code focused.

When something gets too big, it becomes harder to think through. Design doc reviews often boil down to paring a project to its constituent parts, scoping them, and then building it back up. By treating each constituent as a black box, teams only need to reason about how to “do one thing and do it well”, and not the myriad of requirements necessary for the final product. In this way, every developer is standing on the shoulders of giants.

Unix Philosophy and Web3

As I learned more about web development and Web3 applications, I realized that this type of development eventually consolidates around open standards. Blockchain code is publicly callable, and developers use this to their advantage by rallying around standards that let them focus on the applications they want to build.

The Request for Comments-style Ethereum Improvement Proposal (EIP) process encourages discussion around new standards and facilitates broader adoption with new foundational libraries. In 2018, Web3 applications did not have a standardized way to connect to user wallets. Each wallet API implementation was slightly different. Writing your own Web3 application meant accounting for how a user's wallet might connect. EIP-1193 solved that. The proposed Ethereum Provider JavaScript API introduced basic functionality like connection and request logic between apps and wallets. With a standard API to follow, app developers could spend more time on core functionality and less time accommodating conflicting connection methods.

As with Node.js and npm, each new standard library gives developers a new tool to work more precisely by using them to abstract important logic unrelated to their core application and create more sophisticated software. String together enough of these libraries and developers can unlock powerful new tools.

We built one of these new tools with Permit2. When users interact with a Web3 application, they must give the application permission to send tokens from their wallet. Permit2 allows these approvals to be shared across multiple applications instead of each application requiring its own approval.

But Permit2 was only possible because we built on already-existing standards like ERC-20, ERC-1155, and ERC-712. ERC-20 defined the token standard. ERC-1155 extended the token standard to "approve" spending by another contract. ERC-712 extends EIP-1193 with a way for wallets to sign data to verify user permission.

Permit2 extends the ecosystem further by taking a token's approval and a wallet's signatures to prove that a user has permitted it to spend a token across other applications resulting in a more unified, cost-efficient, and safer user experience. In turn, we wanted developers to use Permit2 to manage token access control list functions, so we made it easy for developers to integrate with it.


Developers can steadily enhance their capabilities by leveraging existing EIPs and foundational libraries, codifying and abstracting these patterns into even better libraries. Whenever this pattern repeats itself, it elevates the baseline of what is possible, making Web3 an exciting space to work in.

Web3 intrinsically operates in public. We don't just build applications; we create the building blocks with tools and libraries that make them easy to use. I'm excited to participate in this ecosystem by building at Uniswap Labs. If you think you'd like, consider joining us!

Footnotes

  1. I propose modernizing this to “Write programs to handle domain-specific languages.”

Related posts