Protocol design: Why and How
Notes from a16z Crypto Startup School Talk
The internet is a network of protocols. What’s a protocol? A formal system for interactions that facilitates complex group behaviors.
A centralized protocol means one or few entities have legal or technical control over the system
Protocols can be un-opinionated about where the economic value flows in the system. Early internet protocols like NNTP, IRC, SMTP, and RSS are well specified but they lack specification on the economic component. They failed due to a lack of specific features or they struggled to fund themselves. Web1 protocols were decentralized but lacked specific economic models.
Due to lack of specification around economic models or lack of features, web1 protocols were replaced by web2 apps. Usenet was replaced by reddit, IRC by WhatSapp/iMessage, SMTP by Gmail/Outlook, and RSS by Twitter. Web2 protocols have explicit economic models and they’re centralized.
If you’re running a web1 protocol, you’d feel the pressure to have a more explicit economic model.
The quadrant of decentralized control but still an explicit economic model was unavailable until crypto came around, so web1 jumped from the bottom left to the top right corner.
Let’s consider the case of email. There are centralizing forces like spam, lack of economic model, DNS registration cost, and high switching costs (if you don’t own the domain). And there are decentralizing forces like low-switching costs due to being able to keep your own contacts and being able to own the domain.
Key centralizing forces are network effects and switching costs.
How does web3 change the game? With web3, we can incorporate cryptography and blockchains to minimize trust assumptions, make economic models more explicit, while supporting decentralization. Web3 fits in the quadrant of an explicit economic model with decentralized control. Web1 protocols externalize all value, web2 protocols internalize all value, whereas web3 protocols allow for sustainable value sharing.
How to design a protocol.
Toy example: Stable Horde. It’s an app for image generation where people donate GPU time for others to create images from prompts for free.
Process diagram for Stable Horde:
Kudos are points that accumulate in Stable Horde. Clients can award Kudos to workers who generate the images. Stable Horde is limited by the number of people willing to donate their compute power.
How do we scale this system so it can be much bigger but without damaging its open and interoperable character? And how do we do it in a way that it resists centralization?
Perhaps we can add a blockchain? See the below image. It is easy to attack this system by providing fake results, and that’s bad user experience. So strapping on a blockchain naively doesn’t work.
The design process of a protocol has 3 steps:
1. Goals. A concise description of what you want
2. Constraints. Endogenous (internal) and Exogenous (external).
3. Mechanisms. Subsystems that satisfy the goal according to constraints.
Our toy example’s goal is a decentralized, interoperable image generation marketplace.
What are constraints in our toy example?
Consumers get what they ask for -> Verified Inference.
Workers get paid for their contribution -> Proportionate Reward.
Workers may come and go without cost -> Variable Participation.
Responsive and Quick -> Low Latency.
Let’s look at potential mechanisms that can help us achieve the goal while satisfying constraints.
There are a few verification mechanism candidates:
Game Theoretic
Dispute Resolution
Continuous/Sampled Auditing
Cryptographic
Zero-Knowledge
Traditional (centralization vectors)
Trusted Third Party
User Reviews
We also have to consider mechanisms for Pricing Strategies:
Onchain Orderbook
Onchain verified proxy measure for compute (like Ethereum Gas)
Offchain Orderbook (potential for network effects to accrue offchain instead of to the protocol)
Let’s also consider Storage Mechanisms:
Onchain (expensive)
Separate Crypto Storage System
Peer-to-Peer
Offchain
There are also Job Scheduling Mechanisms. Each of these have potential drawbacks and benefits
Worker Chooses
Protocol Chooses
Client Chooses
A combination of above
There are centralization forces that can form around the following components of the protocol:
Namespaces
Payment Systems
Reputation
Storage
Matching
Pricing Systems
Verification Systems
Key centralizing forces in Protocol Design are Network Effects and Expensive Switching Costs. In the ideal case, network effects accrue to the protocol. And low switching costs are important to encourage entrepreneurs to build on that system.
Decentralized systems are the best possible foundation for building as platform risk is mitigated. Web3 protocols are going to be more successful than web2 protocols as that’s where innovation would take place.
Reference: