Paul Dowman




Permissionless public infrastructure

Many people today believe that open source software is positive for our society, but fear the logical next steps: open state, open execution, and open programmability. Using the example of a voting app, I’ll explain what these are and how they’ll eventually be positive for the world in the same way that open source has been.

Today’s primitive version of this is a blockchain, and I’ll show you why we need to evolve these concepts into open public infrastructure beyond financial applications.

Let’s imagine a voting app to be used in a democratic election.


A 1990’s voting app

In the early days of the Internet this app would certainly have been closed-source. No software company with the ability to close a government contract would have been run by those long-haired, anti-corporate Richard Stallman types who would give away their valuable Intellectual Property for nothing! The business of software was simple: it was selling a compiled program for money, one version at a time, and the source code itself was the golden goose from which the valuable egg was produced.

There would probably have been no encryption or cryptographic techniques to validate that the data wasn’t tampered with. Such techniques were not yet widely used because cryptography was still considered a high-tech weapon by the US, and illegal to export. Outside of the military it seemed like only terrorists would go to the trouble of encrypting data.

So we would just have to trust that this app was bug-free, and trust the operator to run it honestly. A risky assumption when there’s a lot at stake.

Fast-forward 25 years…

Open source

By today’s standards such an important piece of public infrastructure as a voting app would need to be open source. Software security experts now believe that the only way to be sure a system is trustworthy and bug-free is to have the code auditable, and preferably as widely as possible. And there are now a variety of business models that work with open source.

But still run by a trusted service provider

Today’s app might be a SaaS product, or at least run on cloud computing infrastructure like AWS, Google Cloud, or Microsoft Azure.

We trust that it’s the same code that we audited, and we trust that the operator runs it honestly without tampering with the data. But we can’t verify these things.

This is still a lot of trust for something as important as an election result. Can we do better?

The next step: open state

To remove the trusted operator assumption we need the state, the operating data inside the system, to be auditable too.

Having the state publicly available allows us to verify that the version we audited is what’s being used, and that the system is operating correctly and hasn’t been tampered with.

There were privacy problems with open state until recently. How could a voting system not reveal the actual votes cast by individuals? We’re now seeing the first applications of a branch of cryptography called “Zero Knowledge” (ZK). With ZK cryptography it’s possible to have a group of verified voters, and to cryptographically prove that each vote came from someone in that group, without knowing which person cast which vote.

So now we know for sure that we have audited the code that’s running, and we know that the data (state) isn’t being tampered with. So we can be sure that all votes are valid.

This is a big improvement, but we still have a problem: the operator can still prevent legitimate voters from voting.

Open execution

In other words we still have the risk of censorship. Open source and open state prevent invalid votes, but they’re not enough. We need to ensure that anyone can interact with the program.

The solution is open execution: allowing anyone to participate in operating the infrastructure that runs the programs. If the programs are open source and open state, and we can cryptographically verify that they run as intended, then there’s no longer a reason to restrict operation to certain trusted nodes.

These nodes run the programs, check the validity of each other’s data, come to consensus on the state of the data, and accept transactions that other nodes might be ignoring (censoring).

We now know for sure that the program is running exactly as intended, with no tampering and no censorship. It sounds like our voting app is finally ready to run a democratic election!

If we stop here do we have something that’s clearly a public good? At least if we agree that our system only runs officially approved programs?


Open programmability

We’re still relying on a large enough group of the node operators to be honest (enough to keep “consensus” on the set of data that hasn’t been tampered with). To ensure this we need to have wide public participation.

If there was a thriving ecosystem of apps paying transaction fees it would support a larger set of node operators, which makes the system more secure because it’s harder for a majority to collude and vote for a fraudulent state.

An open programmable system is the only way to build a thriving ecosystem. Developers want a credibly-neutral platform to build on.

Our data has value, apps we build have value, and just as property rights are necessary for a productive economy in the physical world, the same is true in the digital world.

Entrepreneurs need to know that they’re building on a platform that can’t be taken away at a whim. Digital assets are more valuable when they live on a credibly-neutral public platform. Many writers prefer to publish on a credibly-neutral public platform. The developers and users of important public services such as voting apps will prefer them to be hosted on a credibly-neutral public platform.

If we allow it, eventually these positive applications will compound and build up momentum, slowly moving society’s valuable assets onto a credibly-neutral platform, and we may wonder why we used to place so much trust in a few Silicon Valley CEOs and government agencies.


It’s a blockchain

We have this today, in very primitive form, as a blockchain that can run general-purpose programs (“smart contracts”). For example Ethereum. This is the minimum necessary system to run programs that the public can cryptographically verify:

  • Open source code
  • Open state (maybe with ZK cryptography to preserve privacy while still allowing proof of correct execution)
  • Open execution (anyone can run a node)

And making it an open programmable system ensures that there’s incentive for enough node operators to participate.

Permissionless public infrastructure

I have just described a system with clear applications for the public good, but I argued that it needs to be permissionless, and this is where the objections start. The necessary financial aspect (digital assets have value) combined with a permissionless system means that some of the innovation will obviously go in distasteful or harmful directions.

We’ve seen this before with every valuable new technology including the Internet itself and many other technologies, for example railway mania of 1845.

I’ll leave it to you to decide if the good will eventually outweigh the bad. Personally I’m optimistic that we’ll keep the bad actors in check as we have with every other technology in the past. Fly-by-night scammers come and go quickly, but the real value builds momentum over time.

Comments? Share it  or just comment.
2023 © Paul Dowman