Ten web3 system requirements from Moxie Marlinspike’s post

Last month, Moxie Marlinspike published an in-depth, evidence-based analysis of the current state of web3 architectures. Moxie is the creator of the Signal protocol and a respected leader in the world of modern cryptography. His article has been re-shared many times since.

The post has inspired some thoughtful responses from industry members like Emily Gorcenski and Cardano founder Charles Hoskinson. It has also received its fair share of counter-arguments from people like Ethereum founder Vitalik Buterin and André Staltz. I personally agree with Staltz’s point that in any given network there will always be some participants that do want to run their own servers, in particular if the function of the network is to provide user independence. Staltz provides evidence that even if these “nerds” only represent 1% of total users, that is all that is needed to keep the network viable.

Regardless of your views on this point or others that Moxie makes in his article, he echoes many concerns that are top of mind for web3 developers that want to stay true to the principles of decentralization and its promise of user sovereignty.

This is certainly true for my Orcfax oracle project. Namely, how do we bring authentic real-world data on-chain without having to rely on any centralized points of trust? How can we ensure that permanent access to the source data and its provenance metadata remains independent of any mediating third-party?

This assumes of course that your definition of web3 includes the concept of decentralized trust or distributed consensus through cryptographic proofs. Other criteria may include self-sovereign identity, privacy, and end-user ownership of data.

Moxie’s analysis provides a sober reality check for any web3 project with high aspirations. For one, he is blunt about the fact that many projects in our space dress themselves up in the guise of web3 purely for marketing purposes. In short, they want their piece of the cryptocurrency and NFT gold rush.

Regardless of motivation or values, Moxie warns that we need to be thinking urgently about how to avoid making web3 just like Web2.0 but then with even less privacy. This is currently happening because of technological and psychological forces that naturally drive us to centralization. If we are going to have a decentralization revolution then we need to make these trends explicit like Moxie has so eloquently done.

We also need to change how we think about our technology architectures and our own personal comfort-levels around decentralized trust. Are you ready for true decentralization? Do you really care about this more than the net worth of your crypto bag and NFTs? As Sarah Lewis from Open Privacy has stated so succintly “no one ever got rich decentralizing power.” Echoing Moxie’s thesis, she reminds us that “moving power from one entity to another entity is not decentralization.”

The Orcfax project is very much concerned with implementing standards and good practices that enshrine true web3 principles into our system architecture. To start, we are implementing an “oracle pool” design that decentralizes all data collection, aggregation, validation, publication, archiving, and indexing to independent nodes that are coordinated through a distributed consensus protocol backed by cryptographic proofs.

Moxie’s article provided us with a great set of core system requirements to validate the Orcfax design against. Our project implements standards-based software engineering practices which includes evidence-based requirements analysis. We have been doing this against record-keeping standards and archival science principles.

We applied this same process to Moxie’s article and decided to share our results here at the bottom of this post. The quote blocks are verbatim from Moxie’s article. I’ve re-ordered and grouped them into a more logical progression.

Ten requirements for a true web3 system

Client APIs are not using anything to verify blockchain state or the authenticity of responses.

1. The web3 system must have independent, trustless methods for verifying the authenticity of blockchain state and transaction data.

The results aren’t even signed.

2. The web3 system must use verifiable, cryptographic signatures for all requests and responses between peers, users, and external systems.

We should accept the premise that people will not run their own servers by designing systems that can distribute trust without having to distribute infrastructure.

3. The web3 system must base its trust assumptions on cryptographic proofs rather than the reputation of infrastructure providers.

These companies also have visibility into almost all read requests from almost all users in almost all dApps.

4. The web3 system must provide the option to anonymize all read requests for the data that it manages.

MetaMask needs to interact with the blockchain, but the blockchain has been built such that clients like MetaMask can’t interact with it.

5. The web3 system must accommodate wallets that can interact directly and independently with blockchain state and transaction data.

Royalties aren’t specified in ERC-721, and it’s too late to change it, so OpenSea has its own way of configuring royalties that exists in web2 space.

6. The web3 system must explicitly declare the revenue sharing rules for its participants and specify how it implements a trustless payout mechanism.

People don’t want to run their own servers, and never will.

7. The web3 system must not require management of servers by end users.

Blockchains are designed to be a network of peers, but not designed such that it’s really possible for your mobile device or your browser to be one of those peers.

8. The web3 system should include fully functional peer-to-peer nodes that have acceptable performance on consumer-grade computing devices.

We should try to reduce the burden of building software.

9. The web3 system must make it easy and cost-effective to maintain and enhance its software components.

A protocol moves much more slowly than a platform. If something is truly decentralized, it becomes very difficult to change, and often remains stuck in time.

10. The web3 system must accommodate frequent updates to its protocols and architecture through a decentralized governance mechanism.