Protocol design: Why and how | Eddy Lazzarin

Transcript

Everybody, this talk is called protocol design, why and how. And uh I'd love to talk about uh despite how early it is and despite how new our tools are, we can design protocols that resist centralization and that can remain economically sustainable in a repeated way uh as long as we follow some specific guidelines. But let me also say, please interrupt with questions. I'm a very conversational reasoner. It's super hard for me to just go for 2 hours like I'm not This is not 2 hours.

This is like 45 minutes, but to to go straight for a long time. I'd love questions. There's so many things I'd love to talk about and they won't come out unless somebody asks something. So, please I encourage you interrupt at any point. So, first uh first I'd like to talk a little bit about why. Uh The internet is a network of protocols. Some are charmingly compact and simple. Uh this is a state diagram of HTTP. And uh some are dizzyingly complex like this infamous interaction diagram for Maker protocol.

That's a that's a great one. There are all kinds of protocols out there. Uh internet protocols, physical protocols, political protocols, and more. On the left we have uh you know, a street uh an intersection inter- section interaction diagram. Which is really cool. Obviously, we're familiar with how those work. Uh And the thing that unites them is they're a formal systems for interaction that facilitate complex group behaviors. That's kind of the key underlying component of a protocol. And what makes an internet protocol so powerful is that you can interact with it not just with people, but with software. And as we know, software is incredibly malleable and performant and

has all kinds of interesting other kinds of mechanisms you can build in. So, internet protocols end up being maybe one of the most important, if not the most important, category of protocols that we have at our disposal. And this is this diagram I think we'll try to I will try to unite all of the subcomponents of my talk with this diagram. On the x-axis, you have decentralization and centralization uh in terms of control. Like how is the protocol controlled?

On the y-axis, we have uh the economic model of of the protocol and specifically how explicit or unspecified it is. Now, this is a little bit of a subtlety, but what I mean is that in some you you can design a protocol that does all kinds of things, but is totally and utterly unopinionated about where value flows, where uh what ownership means, what access rights are, how payments work, but that is those are totally optional components of protocols.

In fact, I think if you look at a lot of the Web 1 protocols that we're going to look at like like these, uh you will find that they are conspicuously unopinionated in terms of how they set up their economic systems. Uh I don't know how familiar you guys are with with each of these. These are some of my favorites growing up. Uh but uh Usenet was a uh was a protocol for exchanging posts and files in categories. Kind of like Reddit, you'll see uh in the early days of the internet. Uh IRC is a totally universal protocol for chat. Uh I'll say a little bit more about SMTP, RSS. These are great protocols that are very well specified,

but totally punt on how they handle their economic components. So, uh I'll say a little bit about Usenet. This is someone using Usenet uh a couple decades ago. I'm I'm kidding. This is This is a Usenet interface. Uh Usenet is organized by categories where there are specific subservers that allow people to post content relating to that specific category. Uh it was the birthplace of terms like FAQ, spam, very early internet culture uh had a strong place in Usenet. And very interestingly, because it existed outside of HTTP, you had to have a specific client and you had to have an ISP that supported it.

Uh typically uh uh yeah. So, so this is a description from Wikipedia about how Usenet worked. Right? It's distributed across a large number of constantly changing news servers that can be operated by anybody and posts will be automatically forwarded to other news servers. That sounds like a pretty decentralized system, right? There's no specific privileged actor. If anybody can run a server, then that's it. How Usenet ended up actually working is that people uh people got gained access through their universities, research institutions, ISPs.

Users rarely paid directly for Usenet access, but later in the 2000s, people might pay for a commercial Usenet server. In other words, you had to broker your own deal to use Usenet. Uh and it was decentralized. So, so it was decentralized, but also lacked an in-protocol economic model. Uh so, if you look at each of these systems, I think that you'll find they're all very similar architecturally. They all kind of come from the same ethos. In fact, I was talking with Sam Ragsdale from my team yesterday and I was saying a a few words about IRC funny for me, he had never heard of it.

But but but despite that, Sam was able to guess exactly how it worked, right? Just based on my saying it was a Web 1 chat protocol. Right? That's how legible it is uh and how uh clean I think the template for what a Web 1 protocol is. So, why did these fail or change over time? And I think if you go through each of these, I will highlight some examples. If you look at how each of these failed, it was all in because of one of two reasons or sometimes both.

They either lost directly to Web 2 competitors because of a lack of specific features or they struggled to fund themselves. That's what all comes down to the specific features that they could embody by being decentralized and the ways that they were able to handle their economics. So, Web 1 protocols go into this bottom left corner, right? Uh decentralized and unspecified. Now, each of these as Web 2 came by, there's this really interesting pattern.

If you look at Usenet, it was replaced very cleanly by Reddit. If you look at or or similar sort of discussion forums. Uh IRC was replaced by WhatsApp, iMessage, any of the sort of data centralized messaging systems. Email, although it hasn't been replaced, and I'll say more about this later, has ended up being de facto centralized. Uh RSS was beaten basically by Twitter. And if you go item by item, there are specific features. So, for Usenet, Usenet's failed features have to do with how difficult it was to set up a new uh a new category in its namespace

uh and how difficult it was to modify the underlying protocol. Uh it also had no spam mitigation. Uh Email also struggled from this spam mitigation issue. It's a common issue in decentralized protocols, and that's because they don't have an inbuilt concept to measure whether a message is legitimate, whether it's from a legitimate person, or whether there's a that the sender has specific permissions, or whether there's a real economic relationship between them. There's all kinds of angles you could think of, uh especially given some of the things we have in Web 3, but in a naive decentralized system, the those lack of features mean that the centralized competitors that come later later have a critical kind of thing that

they can offer uniquely by being centralized that allows uh allows them to surpass their Web 1 predecessor. So, we don't need to go into detail, but obviously Web 2 protocols are in the top right corner. And what defines them, right, is that they're the systems are entirely controlled by their owners, who can make unilateral decisions limited only by business strategy and the law to modify their networks. And they do that. But very interestingly, if you were running a Web 1 protocol or you were interested in facilitating the development of one, you would feel a natural pressure to move up this gradient, right? To make

the economic model more and more explicit. Like you would feel this pressure. And that's because you need to fund it and or you need to align the participants of your ecosystem. And making these things more explicit and more legible gives you the type of control that the protocol needs to enforce new features, pay for itself, all those things. But very interestingly, that corner is not available without decentralized consensus or without verifiable computation and all the other kinds of tools and properties we have in crypto.

So, it's not actually possible to maintain decentralization while making the economic model explicit without what we have in crypto. So, what ends up happening is this slide from the bottom left to the top right where either the protocol adapts and becomes de facto centralized, which is what happened with email, which I'll show in a second, or the protocol simply gets leapfrogged by a web 2 protocol that places itself in the correct area of the design space at the outset.

This is email today. Although it certainly exists, it's become centralized. It you can it's a little hard to make out the details here, but you can see that over 50% of email, depending on domain and depending on the specialization area, is handled by centralized email service providers. And that's not that's there's I think there's very clear reasons for this. There are centralizing forces in email and decentralizing forces. This is where we'll we'll start to get a little bit into the components of protocol design.

Centralizing forces include spam, a lack of economic model, amortizing DNS registration costs, high switching costs, right? No economical no economic model for email means it's only viable at scale as a strategic side project for large tech companies. And spam is only partially able to be mitigated by a combination of economics of economics of economies of scale and data where companies hosting millions of email accounts can identify anomalies easier, right? Because they have more data to do this kind of work.

Or de facto reputation systems between email service providers. So a specific example I invite you to try. If you try to run your own email server, which you can do, right? You can you can you can run your own email server. You can get a machine. You can point the DNS certificate for for mail to the IP address of your machine and you can send your own emails. But you'll find that they'll usually end up in the spam box. And that's because there's a de facto reputation system between the top corporate email service providers.

And they don't do that because they're trying to mess with anybody. They're doing that because it's necessary to solve what is lacking in the email protocol in the SMTP protocol. So SMTP is unspecified underspecified with regard to how to ensure this is a legitimate email. Another key thing to note is switching costs, which I'll say a little bit more about in a minute, but uh a switching cost well, let me let me kind of zoom out a little bit here and say two key centralizing forces that apply to different components of a protocol that will come into play constantly over and over and over again at every turn

when you're designing a protocol are network effects and switching costs, right? Network effects are where power accumulates as the result of a system becoming bigger and more used. And switching costs are just the economic cost or cognitive cost or time cost for users of the system to exit and use a different system, right? If you go back here and look at each of these forces in email, you can apply that those two forces to each of these components.

The DNS registration cost is maybe a better an example of an economy of scale, but high switching costs if you don't own the domain and low switching costs if you do are examples of how users can take advantage of a design in a system to mitigate those switching costs and resist centralizing effects. Uh So when we look at email, it becomes clear there's kind of three components that rise to the top where switching costs and network effects are at play.

There's namespaces, specifically the DNS system and email addresses within a domain like for Google. There's payment systems, which has something to do with how we think about spam and what a legitimate email is and paying for email service, which obviously few are willing to do so. And reputation, which is how we think about the spam problem with regard to email. So before I go to like web 3, are there any questions or thoughts? So the question was say a little bit more about how high switching costs are a are a centralizing force. So let me zoom in a little bit here. Really interestingly, you can see low switching costs and high

switching costs are forces at play in email right? The difference here is in Gmail, if you're using Gmail and you don't own the domain like you don't own a gmail.com, the switching costs are very high. And that's because if you want to use a different email service provider, forget an email client. I mean email service provider like the actual machine that receives and sends the mail. If you don't own the gmail.com domain, you cannot actually switch to a different provider. Whereas if you do own the domain like you buy your own web domain, you can not only move your contacts, but you can continue to receive emails at that domain using any email service provider, whether it's one you run in your garage

or not. And the ability of a company to inflict high switching costs by forcing you to use or encouraging you to use specific components in their protocols design changes those costs. The higher the switching costs, the less likely a user is to leave because they have to do whether or not they're doing it explicitly, they're doing a calculation, right? It can be a subconscious sort of behavioral calculation. It can be an explicit business calculation, but they have to understand exactly the cost that they're bearing to leave. And high switching costs make things sticky, which makes it easier to collect rents, which makes it which consolidates power around that system.

Hope that answers your question. So where would we put Slack, Discord and then systems that generally have powerful moderators? Is that the is that the question? Yeah. So I actually think I'll think about Slack and Discord in a second, but when it comes to allowing moderators like take for example take Reddit where there are subreddits that are unilaterally pardon me, unilaterally controlled by the moderators, right? I think that it's hard to say whether that is a centralizing or decentralizing force specifically. I mean I think allowing any mod anyone to become a moderator feels like a potentially slightly decentralizing force, but if the power is still accumulating to the admin above all admins, right? Which is like the the

Reddit team. Then it's still ultimate they may be taking advantage of an innovative force where people can experiment and try different ways of running a subreddit, but it's still coalescing power to the Reddit domain to the Reddit servers where everything is stored. It's still ultimately concentrating toward Reddit. So I'd say that I think I think uh with Reddit like my first reaction is always that it's kind of crazy that there's no way to remove a moderator, right? Or to continue the development and maturation of a subreddit. And there's also no in protocol way for a moderator to monetize. So it's you end up with a lot of strange pathologies where moderators get paid out of

protocol in ways that violate Reddit's terms of service or are consistent with them. It's a really interesting topic. As far as Slack and Discord, that's that's tough. I think those are still very very very centralizing because with Slack, even though your company has control over the Slack instance or you can you control the Discord server, uh whether or not you can integrate specific tools with the systems, whether or not you have control over the data, whether or not you can you know, receive payments or add features like token gating, things like what whatever all these types of features, those are still at the discretion of the company because they control the client and API interface that you can use.

So those are still totally centralized systems. They're taking advantage of the ecosystem benefits of allowing for an open system, but they're trying to get the benefits of decentralization without the costs, right? Still ends up being centralized. Thanks for that question. Yeah. The question was is high quality user experience or is user experience a centralizing force in general? I'd say no, but it is a force that requires funding. High quality user experience requires funding, which is why it's not a coincidence that the decentralized protocols in web 1 typically have a pretty low quality user experience given what is possible

because of funding. If you can solve funding, I think you can solve user experience. I don't think it's inherently centralizing or not. And in fact, I'd argue maybe this is a little bit of a roundabout path, but if you allow the system to be totally open, so you allow people to compete at the level of the user experience and you allow them to monetize independently like at the periphery of the protocol, then you probably end up with the best user experience there. Like that is probably that type of ecosystem is where you'd end up with the best user experience because not only can each of the individual projects fund themselves, but they can experiment and compete. Whereas if you look at like a Twitter or Facebook or Instagram or TikTok, like there is a specific user interface that you have to use. You have to use

the interface that it comes integrated with the platform. And that means that you are kind of at the whim at their whim in terms of how they upgrade the the interface, right? So that it seems to me like that you won't achieve the global maximum interface, the global best interface if there's only one agent that can climb the hill, right? So how does how does introducing all the components of web 3 change protocols? Well, we can incorporate cryptography and blockchains to minimize trust assumptions. We can make economics explicit all while supporting decentralization.

That is a really interesting corner of the space and in fact, I'd say that that unblocks that top left corner of the space and parks web 3 protocols comfortably in there. So, talking a little bit about value, uh how do how do you answer like I would say this is not necessarily a question a statement for builders. This is kind of a statement for well, it is for builders but it's also for the whole space in general. How do you think about the economic outcomes for all the participants of these systems? Right?

And for the systems themselves. The problem with web 1 protocols in the bottom left corner is that they unwillingly externalize all the value that they create. Right? Because their economic models are unspecified in the protocol, that means all the interesting economics happens outside of the protocol and there's no lever that the protocol can use to collect value. Web 2 protocols, centralized and explicit in terms of their economics, internalize all possible value. Their goal is to internalize all the surpluses of the system and in the cases where they end up being de facto monopolies, the way that they revenue maximize is by absorbing every individual's surplus.

Which means that the people building on top of them cannot be as big as they otherwise would be. If you build a very successful or very powerful business on top of a social network's API, they will limit you. They will change your change the fees, they will cut you off, they may build a competitor and vertically integrate in that direction. The point is that you are building on someone else's territory, which means you cannot fully internalize all the value that you are creating. But what's very interesting about the web 3 corner is that these types of systems, because they're open, interoperable, open source, have known economics in advance, can commit to how they operate,

they can find ways to be sustainable by including their own funding in their protocols while also avoiding capturing all the value. Which means if you're a builder and you're going to build on a system, the best type of system to build on would be one that is decentralized and also has explicit economic models. That is the best corner of the trade-off space because you know it will last and you know your economic relationship with it as opposed to allowing the economic relationship to develop outside of the protocol.

Then in terms of stability, which is an entirely different axis as opposed to value capture, it is always better as a builder to build well, if you want a very it's not always better. If you want to build the biggest possible system that has the greatest chance of surviving the longest, right? The most ambitious project, you should build on a decentralized system. And that's because if you don't, you're subjecting your system to potential risks, single points of failure, platform risks. No one thinks it's crazy to build on the internet anymore, right? Because it's totally decentralized and it's never going to go away.

No one thinks it's crazy to use an open source programming language or rely on web browsers because these systems are decentralized. They're the most solid ground to build the most ambitious projects. And if you build on centralized systems that have strong network effects or switching costs that accumulate to them, you're building on someone else's territory and could be limiting the size and scope of your project. So, this is the pattern of how they're developing and I think that it's possible as a result of the fact that web 3 systems can attract better builders that can build bigger, more ambitious projects.

I think it's possible that we see some of the web 2 networks find legitimate uh serious competitors. So, any any last questions about that before we go to uh an example protocol design. Yeah. That's a good point. Yeah. So, the the observation is that if web 2 networks capture as much value as possible, uh then doesn't that give them the most resources to resist potential competitors? It's totally true but I'd say there's a couple key dynamics with how we see institutions unfold that make this not an existential threat.

The first is that incumbents are very brittle. In fact, there's a slide I removed that would have been like a perfect slide for this but if you think about how a uh this is an analogy I'm borrowing from Seeing Like a State, right? Which is a great book about uh ways that um ways in the 20th century that large states have tried to build optimized and legible systems to solve social problems right? If you look at uh if you analogize a web 2 network with a farm, analogize it with like a modern scientific farm or scientific forest.

They use monocropping, fertilizers, pesticides, they make legible the rows and organization of all their crops. What they're trying to do is they're trying to optimize along a specific dimension. That is always their goal. They have specific metrics that they are hell-bent at optimizing at all costs. And anything that does not play directly into the metrics that they are trying to optimize is either a risk or a distraction and is often a second class priority for them. Right? There's a reason why they have failed so far to develop you know, all these monopolies. Uh well, scratch that. They're not really really monopolies. They just have incredible network effects. There's a reason why they've failed to innovate and create the same types of new products.

Right? And it also makes them more brittle because it means if someone finds the their kryptonite, so to speak, the specific pathogen that works against them, their business model is so optimized to a specific pattern of behavior that it's easier to disrupt if you can find the exact location to undermine it. The way they mitigate this is by acquiring companies and trying to buy them, things like this and they can certainly extend their time their time horizon. But at the limit, I think that uh the innovative types of projects are not going to take place and to be built within these companies.

So, I think it's kind of an innovator's dilemma story. Going back to the farm analogy though, the most productive and interesting type of space that is most ecologically valuable is a space that is fertile soil that is has a fantastic ecological equilibrium where all types of different species and all types of different things can intermingle and rely on each other. Like a think of a rich like multi-species uh rainforest, right? This is like the natural the the natural state of nature.

This is where all the interesting types of things develop. And if you build the right type of substrate, if you build the right underlying protocol, when all the interesting things does develop, they will develop on top of that richer, fertile soil. They will not even be able to take off in the highly sterilized purpose-built specific industrial farm. So, the the longer time passes, the more interesting things will pop up because of interesting entrepreneurs and developers in the fertile soil, the fewer things will accumulate to the single-purpose field.

So, although they have the most economic resources, those aren't the most valuable things. The most economic resources are the willingness to build and willingness to take risks by the potential participants of the system. So I on top of that, uh you know, and this is a whole other path, crypto, because it can create explicit economic models, can do creative things. Like take helium as an example. You can create a token that pays for the development of the network and helps bootstrap up to that large critical mass where the system becomes economically viable by creating a token that represents the future control of the network and distributing it across the widest set of participants that is totally, you know, authentically,

organically decentralized. In other words, there are specific ways that you can use the an explicit economic model that the that a crypto system can commit to in order to guarantee that participants will get the reward for their efforts. And in that case, you can you have ways to kind of go up the hill and solve the bootstrapping problem. Um thanks for that question. So, I'd like to say a little bit about how and in in talking about how, I will use a toy example for a really cool little uh little system like a free um so, this is called stable horde.

It is a uh free system for inference image generation. Kind of can't see that super well but this is one of the one of the many free clients you can use to use stable horde. If you know stable diffusion, you know that stable diffusion model weights are very small. They're only 5 gigabytes, which means anybody can run them pretty quickly if they have a GPU. And uh that's about all you need. All the code is open source to run the model and once you have the weights, you can execute them. But not everybody has a great GPU. So, what stable horde is is it's a very simple coordination layer where someone can request an image and specify a prompt, which is kind of at the bottom of this image, uh and uh request that this prompt be generated by a horde of people who are

donating essentially donating their compute time. And this is it's as live, you can go check it out. I think they actually recently renamed it to AI horde. But they've already served 38 million images through stable horde despite the fact that it's totally free. Uh and it's really cool. I recommend you try it yourself. You can just specify an image and it'll generate it. This is a uh process diagram for how stable horde works. So, there is a database in the middle and what happens is a client, which can be anybody, it just has to satisfy the stable horde API, submits a job, that job goes into a work queue for model.

A worker can receive a job and process process the inference, send the send the result back to like a result store where clients can retrieve it and also pay kudos to a worker who receives those kudos. So kudos are a free, you know, little point system that accumulates in the in stable horde. When you come up to stable horde and you make a new API key, you start with zero kudos and you can actually go negative if you spend. But the way that the queue works is that the workers automatically prioritize clients that have a higher number of kudos.

So if you have a lot of kudos, you will be processed first after you pay. And if you have a decreasing amount of kudos, your request will take longer and longer to process that horde. So this is a cool thing, it works today, but it's fundamentally limited in terms of how many people are willing to donate high quality free compute. Like that's that's it. It's just the demand I think is limitless. They you know, they've made many millions of images, but because demand is self-limiting, you know, the more the longer the queue is, the longer it takes to generate an image, you get longer and longer wait times. So I think a really interesting question is how do we scale the system so that it can be much much bigger and

professionalize a little bit, but with but while still preserving its open and interoperable character, right? And also avoiding the risk that it centralizes in a way that undermines the original spirit of the project. I think that's like an interesting task. So does anybody have any immediate thoughts? Like anything that would work or not work? Yeah. So So the suggestion was why just make kudos a ERC-20 token and then maybe like just to add a little more detail, maybe we would move the kudos scores onto a blockchain. Something like that, right? Something like that. That's like an immediate immediate thought, but if we go down this path, well, I'll I'll skip here for a second and then I'll come back.

If we skip right here at the point we send the inference result and wait for a payment, it's pretty clear someone could attack the system by providing fake results, right? They could they could provide fake results and receive payment and that's the most negative possible user experience because you're just not getting what you paid for. So I think it's clear that we can't sort of naively strap a blockchain onto this, right? And make it work. So let's let's kind of let's let's revisit a design process. This is a design process that I've talked a little bit about before and I'll just revisit it very briefly.

You should always start a protocol design with a goal, then constraints and then mechanisms. So a goal is an a goal should be unmistakable. It should be concise and should be it should be very clear whether or not your goal is achieved through means you can measure. We'll go into a specific example, but even if we're not exactly sure how to measure it, it should be something measurable. And also ideally it sounds like the design of a system. Like it sounds like a type of thing that could be a protocol, a coordination of complex behaviors to facilitate like a specific specific end.

Constraints come in many forms. There's endogenous constraints and exogenous constraints. Endogenous constraints are things that are we choose to accept that like come from inside our design, from inside our group. And exogenous constraints come from outside. They're imposed by nature, the state of technology, regulations, the resources we have available, things like that. I'll give some examples, but the purpose of these constraints is to constrain and focus our design so that it's clear what exactly mechanisms are viable and which ones are not. And so you want to limit the design space. You want to constrain the possibilities of design so you can

focus extremely clearly and not be distracted by all the different possible forks in the road. Mechanisms are the actual substance of the protocol. Like these are the subsystems that put together satisfy the goal according to the constraints. So we have our goal, we have our mechanisms and we check that the mechanisms satisfy the goal according to the constraints. All right. Examples of different We'll go through some examples of different mechanisms, but these might be things like liquidation systems, pricing systems, staking systems, incentive systems, payments, verification, all these types of things. Like all the different types of things when you look at

well-known crypto protocols or web two or web one protocols are are used. So going back to our new protocol here, which let's call unstable confusion for for stable diffusion inferences. We already talked about the issue where someone sends fake inferences. So it's pretty clear that we need something to guarantee that consumers get what they asked for. So let's call that verified inference. So we need One of the constraints is that we need inference to be verified.

We need to be able to ensure that this is the intended result. Another issue is that in stable horde, workers ask the database for the next job in the queue, but the job goes to the first worker who requests it. And so this works fine, but in a system with money on the line, incentives could develop to claim lots of jobs that workers don't intend to complete, right? They could come in and compete on latency, start clamoring up jobs and congest the system. Sometimes this family of concerns is related to MEV, right? But depending on the it depends on how the winner is selected. So it's not totally clear out the gate what exact constraint we want,

but the ideal worker experience is probably one where workers don't need to compete in some way that isn't helpful to the network. If workers are going to compete for jobs, it should be productive to the network. So let's just say that workers should be paid according to their contribution and see where that gets us. So we can call this proportionate rewards right? So while we're at it, it's pretty clear that it would be useful if workers could drop in or out with minimal costs. Like this is a common behavior in other types of distributed systems and makes it easier for us to get to solicit more participation.

So let's let's add that and let's call that variable participation. And then finally from a user experience point of view, it's clear the app should be responsive and quick in order to remain fun. So let's add that and let's call that low latency. So if we go back to our template, we have a goal, which is to make a decentralized interoperable image generation marketplace. We have a couple key constraints, which is probably not complete and we'll you know, we we can we can definitely add more or modify them or become more specific later.

And now we're in a place to evaluate the viability of different mechanisms. So this is where I'm going to go through a couple and talk about them, but I'd love your thoughts as as we consider them. So let's let's let's look at first we need we agree we need some verification mechanism, right? Because we need to make sure that the inferences are correct. A classic place to go in crypto world is game theoretic mechanisms, right? Where we maybe we use a dispute resolution systems. This would be where users receive a a result, they're unhappy with it, they escalate and some sort of in-protocol party evaluates the result and litigates it, right? And says, "Yeah, yeah, this is

correct or this is wrong, right? This inference was given the model, given the parameters, this model hash disagrees with what I got. So this is wrong." Another could be another in the game theoretic category would be continuous or sampled auditing. This is where there's an in-protocol agent who has something at stake, who goes around and plucks from the underlying worker set and make sure that different jobs are being handed out to different workers and updates some sort of representation of which workers are passing audits.

Right? That can provide information to the protocol that certain workers are high quality. Another interesting path is to use cryptography, to use a zero-knowledge proof. Maybe if we could generate an efficient proof that an inference was correct, then we could use that within the system and allow workers to generate a proof that their inference was correct and exactly as specified in a way that's very succinct and low cost. And this of course without going too long into this, you might think zero-knowledge protocols have a lot of overhead, but actually there's a interesting and appealing way to do this that one of the researchers from our

team, Justin Thaler, has spent a lot of time advocating for that it that involves making very very quick and easy low overhead proofs for matrix multiplications, which are the key components in inference. Some traditional methods that are used in similar sort of marketplaces for verification are trusted third parties, so having someone who vouches, you know, vouches for this worker or vouches for this type of job, something like that.

Or you can use user reviews, right? Where users say, "Yeah, this looks right. This is what I wanted. Here's a thumbs up. Here's a five star. And allows that information to accumulate. Reason I have it in red is because these are uh pretty obviously potential centralization vectors. Right, because network effects could accumulate to third Well, there's both network effects and switching costs involved in both of these. User reviews create network effects because when we when users use user reviews, they are more willing to use workers that have high-quality user reviews.

And those workers will then get more work from users, which means they're more likely to receive more user reviews. So, depending on where those user reviews are stored, that could accumulate network effects either to whoever controls the review system or directly to the workers themselves. For trusted third parties, uh there's that's a little bit weaker uh where that network effect comes from, but a trusted third party can accumulate the trust and reputation to themselves, which means that when you're asking for the the next inference, you can request that the trusted third party just generates it for you, right?

If you already trust them, you're already building trust into the system, they could potentially undercut because they don't have to double-check anyone's work or do something like that, offer an out-of-protocol special deal. Any other interesting verification mechanism candidates anybody can think of? The suggestion was maybe there's a system where multiple workers complete a job, and the user basically has their choice among the completed results. And of course, if there's obvious disagreement, that would be obvious to the user. So, that's a that's a that's a good one, uh but it does have a high fixed costs because the network then has to produce every inference x number of extra times. But, if it's sufficiently cheap, it may be worth it,

right? It may be worth it. So, we have we have a couple more potential avenues to consider uh or uh potential mechanisms to consider for a design. There's pricing strategies, right? You could have an on-chain order book. You could have an on-chain verified proxy measure for compute like gas. So, this is where instead of just simply a free market where you post, you know, how much you're willing to pay for the inference, and workers can accept it or, you know, they can bid for work. Instead, you create a proxy representation like gas where specific inferences cost some amount of compute, and that, you know, quantity of compute is what's

priced directly. That can simplify the mechanism. Uh we could also use an off-chain order book, right? And that would be really cheap to run and uh you know, potentially really, really performant. The issue is, of course, is whoever owns that order book could attention could potentially call us network effects to themselves, too. So, that's uh some pricing strategies. There's also ways to manage storage. Uh storage although we didn't go I I didn't touch this part in the diagram here. Storage is really important because uh you need to ensure that the result was delivered to the to the client.

And it's very difficult to prove that work was delivered properly in a way that mitigates trust. You could imagine, for example, a uh you could imagine a pathological case where uh whether or not the item was delivered was the uh happened becomes a source of dispute, right? Like a user can basically complaining, I didn't receive the ended good. Or um you know, or you could imagine a system where uh auditors, in order to verify the compute, need to be able to check the output specifically to ensure that it's uh it's it was done correctly. So, outputs need to be visible to the protocol. So, they need to be stored somewhere that's protocol accessible.

You could put it on chain, but that's very expensive. You could use a separate storage-specific crypto network. It's also possible. Peer-to-peer is probably a little bit more difficult, but maybe there's some ways around that. You could also store it off-chain, but obviously if it's stored off-chain, and whoever's controlling that system has the ability to influence many other components of the system like the you know, the the verification, the final transmission of payment, things like that. And maybe the last component is uh how we schedule the work.

Just a This is kind of a complicated category, and I'm not going to spend much time on it, but you could imagine cases where the worker chooses the task once it's been submitted to the system, where the protocol allocates tasks once they're submitted to the system, or allowing the client, the end user, to choose which worker does the work. And each of these have potential vulnerabilities uh and potential strengths. Maybe there's some combinations between a few like you could imagine a system where the protocol decides which workers are able to request which jobs or things like that. But uh you'll notice there's all kinds of interesting subtleties here.

For example, uh if in a protocol chooses system, you need to have an a notion of whether a worker is online available to to the system so that it can know whether to schedule to it. And you also need to have a sense of the capacity of each worker as an example. So, you start to see how all kinds of extra facts need to be visible to the protocol. And our naive implementation might not have had them in there in the first place. So, now that we've done like kind of a rapid-fire tour of some potential paths, interesting paths in the idea maze about Web3-izing this Web2 protocol, we can see a couple other key design components that end up being potential vectors for centralization.

The first three came from email, but these last four like storage, matching, pricing systems, verification systems, these are all potential centralization vectors. And uh of course uh this just a reminder that the key uh ways that these objects can be influenced is with uh or it can become centralizing is as a result of network effects or high switching costs. So, certain types of systems you can mitigate the accumulation network effects, or you can drive the network effects to accumulate to the protocol.

And in the ideal case, network effects accumulate to the protocol. And additionally, there is a decentralized control layer for the protocol. This is personally where I think tokens make the most sense like volatile tokens that allow control over decentralized systems because the system often needs a steward who is responsible for the long-term health of the system. And a token, if sufficiently decentralized and sufficiently distributed, uh is a great thing to point a control requirement toward. Right? How else do you distribute control over many, many people? I think there's actually some really interesting governance designs that don't involve volatile tokens. You

could imagine sort of reputational systems being used for governance or a rotating cast of elected people through some civil resistant mechanism. There's some really cool design patterns. But uh either way, you need to accumulate the network effect to a decentralized entity that is incentive-aligned with the protocol. If that's the case, and the protocol is potent enough and has a strong enough network effect, and is creating enough value, it's very, very likely to me, and this kind of depends on the protocol, that you'll be able to find a path for the protocol to extract value in a way that is not rent-collecting, is not excessive, uh and does not capture all of the surpluses built on top of it.

So, that In my mind, that is the kind of tightest way to explain how protocols can end up capturing value in a positive way. And the same thing is true for switching costs, right? Uh I think interoperability and allowing for low switching costs is really important for allowing for encouraging entrepreneurs to build on a system, right? I think we've all learned over the last couple decades on the internet that if you build on a system that you can't leave with anything, you're taking a lot of risk. So, I think that's probably table stakes is to minimize switching costs wherever possible.

But uh either way, we can inadvertently introduce high switching costs into naive systems like in Stable Horde by, for example, having a uh off-chain order book or having a verification system that relies on third party that we really come to rely on. Yeah, so the observation is just that in Web2, the largest systems tend to the largest protocols, largest players tend to either in-house or verticalize or acquire or limit the people building on top of them. And, you know, that obvious pattern is something that is maybe maybe we can ameliorate with uh some of the tech in Web3.

Uh so, if you kind of sum everything up, I think each of the uh you know, if we want the system that we're building to be a building block for the future of the internet that others can use, and that will stand the test of time, we need to endeavor to steal people's resolve with all these cool Web3 tools that unlock this very valuable corner of the design space. Protocols are going to end up bigger, last longer, and have more vibrant system ecosystems than Web2 protocols because that's where all the safe and interesting innovation will continue to be possible beyond the tolerances of the largest companies.

So, uh anyway, so I'm going to open it up to questions. YEAH, IT'S THE SO, THE QUESTION WAS, IS THERE an optimal strategy for this like decentralized compute marketplace? Uh we've been thinking about it a lot. I think that a few of these areas are much more promising than others, but ultimately which mechanisms uh you adopt uh is a complicated research task where, you know, you have to plumb all the depths. I don't know that there's an exact one. I think for verification it's almost certainly going to be the case that the that the cryptographic solution is the best. That seems clear to me.

Uh for the pricing, I think having a proxy for compute is the best because it's the most generalizable. Because once you have a decent enough proxy for compute, then you can have all kinds of different inferences or machine learning tasks that are represented by the like this one measurable thing, like gas, right? Uh for in terms of pricing, or sorry, in terms of uh scheduling, my gut is that a mixture of protocol and worker chosen is the best where the protocol has some continuously updating concept of what the capacity of different workers is and whether they're on or off and hands tasks to them in an equitable way where the workers can choose to accept them or not. I think that there's

I think that there's something interesting there. And then uh the last dimension was uh storage is an interesting but tough one. You know, 4844 like proto-danksharding actually plays into this a little bit, this similar design path because you actually only need the image there for as long as you need to dispute it and guarantee that it was received. Right? So, you don't actually need to permanently store the image. So, if you can get away with that short time window, you can probably use some type of temporary storage that is guaranteed to be held by consensus but is ephemeral. So, if I had to kind of like pick and choose, that's how I'd pick and choose, but I haven't designed this whole thing and I'm sure that there's many of many entrepreneurs who are you know, going to going deeper down that. Thanks for that question.

Yeah. Hey, it's uh Nikita from Chain Patrol. Um I want to ask um when developing, you know, any software, like I think centralized sometimes feels almost like easier to develop or maybe faster. And so, like what are your thoughts on uh starting off centralized and progressively decentralizing? And also, um if that's a good approach or if you should start it off that way, and then if you do start off centralized, what is the stage when you decide, okay, now we're going to start um like progressively decentralizing? Yeah, it's a it's a great question and could be a very long conversation, for sure.

I personally think it's a really good strategy and I think it's important for a couple key reasons. It is easier to iterate and to move on a centralized system, right? Not because of some like uh grand political fact, but because a centralized system is under your control and something you can control you can manipulate faster. Like that's just incredibly straightforward. As far as the right time, I think that the it depends on what you're building, but you there needs to be a credible path to decentralization. You shouldn't just start building something totally centralized and just kind of wave your hands and hope that it's going to be decentralized uh be decentralizable. Decentralization is incredibly incredibly difficult.

We've already seen kind of how about every path has its risks. So, I think you need to start the process of decentralizing, thinking about decentralizing immediately. Like it needs to be like at the extreme beginning. But if you had to pick an exact right time to choose to actually take the steps of decentralizing, I think it'll be right around the time that you get product market fit, right? Right around the time that the need for iteration and the need for experimentation starts to taper off. But, you know, there's other forces that can drive you to need to decentralize, you know, what if you're not attracting enough builders because it's just not credible enough yet, right? At this at that point you're still asking people to trust you, right?

Uh so I I think it I think it depends a lot on the thing, but I'd say start decentralization planning immediately like from the beginning and have a credible path there and tactically choose which components you will tolerate centralization for uh at the outset. So, thanks for that question. Thank you. Yeah. Hi, I'm J from Ether ID. Thank you for the uh brilliant talk. There's uh a lot to think about. Uh this is more of a philosophical question, but would you say the uh the fact that branding exists for humans means that there's a uh a natural human tendency towards centralization?

You know, I I would I think it's a good observation. I would modify it a little bit is that there is a natural need by human beings when dealing with a complicated system to reduce things into a single synoptic lens, right? A single Human beings want to minimize the cognitive burdens of considering choices and and things like that. And being able to say like, this is a good brand, I trust this brand, is a great groove to grease, so to so to speak, in your behavior. So, there is an incredibly important role for brands for that reason.

And it is to some degree centralizing, right? Brand and reputation is a centralizing thing. Now, I don't think it's but I think that if I had to sort of quantify how centralizing it is compared to network effects, compared to incredibly high switching costs, I'd say it's much much much smaller. So, I think it's not like a huge concern, but it is a very fascinating effect. So, thanks for mentioning it. Yeah. Hey, my name is Murad from Prime app. We're building a block builder communication network. Cool. Um you gave a great framework on kind of how to go about mechanism design essentially or for for protocol, the three steps.

And when we think about protocols that kind of stack on top of each other, for example, in Ethereum, there's a compute protocol, there's a consensus protocol that has some slashing mechanism in it. How do you kind of bring together, you know, that framework with kind of these stacking uh protocols in a sense? Yeah, it's interesting. So, when you're when you're building one protocol on top of another, right? So, you're taking advantage of composability, which like your project certainly is like totally totally preoccupied with, right? So, yeah. Yeah. It's an important piece. You should think of the uh you should think of the thing that you're building on as introducing additional constraints. Mhm. Right? In certain in certain cases it also supplies mechanisms that you can take advantage of, but these are constraints that you're you're limited by. So, I

just dump them in, right? And say like, look like this is like this is the this is the gas environment we're in. This is the this is the way that like we communicate blocks to relays, right? Like this is and so on and so forth. So, I would introduce that into the constraint side. Um and that does that would Yeah, I think that that would simplify the view. Is there another way that you mean? I mean, it certainly makes the process more complex. that answers it, for sure. That that helps kind of think through how to apply it on multiple levels, so thank you. Okay sure.

Can you share your thoughts about all of this at the application layer or how the decentralization of the protocols and the economic like model being explicit. Yeah, what do you think about the application layer? Does Say Say a little more about what you mean by application layer. Like an example, maybe. So, you have clients building on top of protocols, like you have user interfaces. Like assume Twitter is a protocol and anyone can now build like a client, right? Uh Does that trend tend towards centralization? Is centralization of the like clients and the applications a bad thing? How do they capture value? Yeah, just general thoughts.

Yeah, yeah, that's that's an interesting question. I think what's what's interesting is that we have not really seen the full array of potential business models by clients, right? We've actually not seen that full space explored because typically it's too powerful a move for a client to try to vertically integrate downward into the data the data side, right? They all want to control their own graph. They don't want to control their own network. And the reason they want to do that is because there's a nearby viable business model there. If you control the client and you control the underlying uh the back end, then you can do ads and things like that, right? Uh so, there's a very nearby

sort of local maxima that's like high quality. I think if we had uh a space where um if we had a space where the underlying protocol is has explicit economic conditions unlike Usenet and a Usenet client trying to monetize on top of Usenet, right? Where the underlying protocol actually has economic components, I think that gives a lot more options and a lot more uh a lot more maneuverability to a client on top, right? The reason for that is that if the protocol is well specified enough, the client can try to take credit for behaviors and contributions to the underlying protocol.

And if the underlying protocol is monetized and is such that it wants to encourage the widest possible set of clients, then there's a positive relationship between them, not a competing relationship. So, there's a really interesting design space there. In general, whether it's centralizing for there to be clients at all, like you know, is the relationship between users and clients centralizing? I think it kind of is for brand-like reasons, but depending on switching costs and depending where the network effects are accumulating, uh that can it can be relatively minor such that a client won't be able to exert economic power over the underlying protocol. But it again, it depends on the specifics. I'd like to spend more time talking about it cuz there's a lot

of nuance. I'm trying to stay have my have a general answer but not uh meander too much. Yeah, that's interesting. I think Sure. Thanks. Hey, um at the application level, I just want to think about like what if we flipped the script a little bit? Like, what are the So, in Web 1, if you're building on top of a protocol and you're building application, we sort of knew what the risks were. In Web 2, we saw that the risks were like, "Hey, you can get you know, they they could capture the value, they could limit your growth." Um how do you think about like application risk when you're choosing to build on top of our protocol um for Web 3? Like, what's different compared to Web 2 and Web 1 that we should look out for? Like, for example, I know some friends who built companies that were on

protocols that Well, those are no longer companies, right? So, like, what are kind of how do you think about Mhm. what what the risk profile and and like exposure is for applications building on top of protocols? Yeah, that's a really interesting question. Yeah, what's the risk profile for an application building on top? Cuz at at the limit, like I said in the talk, my genuine belief is that the risk profile should be the least of all potential risk profiles. Like, building on top of a Take for example, like building on Ethereum, right?

There's no sense in which building on Ethereum, you should feel like you are competing against Ethereum. Like, that doesn't That doesn't make sense. Uh you may be competing with other types of agents in the ecosystem, but not with the base layer that you're building on. And on top of that, Ethereum's economic model is totally legible. Like, you know exactly what it's trying to do and how it operates, uh even though it's not run by or controlled by any specific group. Like, you kind of have a reason for how you you can reason about how this protocol itself operates. So, I'd say that at the limit, it should be the least risky thing you can do because it's all totally legible and it's not going to shift underneath your feet, right? The decentralization and the economic explicitness.

That being said, the the riskiest component is probably that because uh because the protocol itself is interoperable, you can assume that uh the switching costs between your application and other applications are very low. Like, that's kind of one of the promises of relying on a system that just uses permissionlessly generatable public private keys. So, I think that that's that's more of the risk, but I think that that just means more competition in terms of like features and quality and things like that and finding different directions to expand, like uh you know, vertical expansion into the protocol probably a little bit more difficult. It's kind of a big strategic

lift. Um yeah, it's hard to It's hard to say, but thanks for Thanks for the question. Cool. Thanks. Yeah. Hey, Brandon. I thought that was a uh really fascinating talk, so thank you. Um I thought your analogy with the farm and the rainforest was was uh particularly inspiring. Do you have concerns that long-term the optimal corporate strategy would be to wait for the rainforest to be sufficiently developed and then to come in and extract all the value by building a vertically integrated application that just competes on UX through funding?

It's a It's a good question. I'd say that I think the the this sort of really complex ecosystem is really resilient. If there's a genuinely a lot of players and a lot of different systems are interlocking, inter composing, it's going to be really difficult to come in and then just straight vertically integrate from the bottom to the top. If it's as robust and complex as it should be, then there's an incredible number of participants that you need to displace. Right? So, I think it's actually really challenging. Yeah, I mean, I I hope so, too. I just wonder because you did mention like um funding can solve UX, right? And so, if UX becomes the fundamental factor in switching cost, then at some at some juncture, you just have like UX that's so incredible from

one player that they just you know, take advantage of the innovation. I think one example would be like Apple and Unix. Right? Like, Unix is a very innovative kernel, um and Apple comes in and has all the money and that becomes the de facto way to interoperate with uh with Unix. Yeah, that's true. Although, Apple's strategic position comes because they fundamentally control the hardware and it's incredibly difficult to make extremely high-quality hardware. As like, Apple's lead is like it's the There's There's a bit of a brand, but they actually have like different network effects and different economies of scale all like down the stack that took an incredibly long time to generate. I think if anybody wanted to compete even with one of those layers, it'd be extremely difficult.

And uh so, it's hard to locate, you know, exactly the the thing that a if there was a sufficiently developed rainforest, right? What is exactly the thing that uh competitor would pry into? You know, you know, if they you could say like uh you know, transaction fees or something. Like, some totally centralized system is cheaper. Yeah, but then it doesn't interoperate necessarily with all the other participants in the system that have built all the software that connects with each other and composes all the different types of tokens and protocols. So, they would have to replicate an increasingly large thing.

And the larger and more complex their vertically integrated system would need to replicate, the more difficult and also the less credible for people building on it, you know, why build on this thing when you can build on this Why build on this someone else's yard? Yeah. Yeah. Cool. Thanks so much for the talk. Oh, thanks. Um thanks so much for the talk. Uh I had a I really liked what you mentioned around uh like network effects and and switching costs. And I guess in a system like in crypto everything's open source and there are um sort of reducing or like uh tending toward zero switching costs, how might um what are like other options for creating strong network effects? And like, in particular, we've seen like vampire attacks or like different types of uh attempts to sort

of subvert existing networks. Yeah, that's a That's a great question. A little point I'd make about the vampire attacks is that none of them have worked. All right? Like, at the limit, they fail. I think they fail partly for um partly for legitimacy reasons cuz they just seem less legitimate cuz they're kind of obviously fast following and they don't necessarily have the credibility of the original who, you know, like if you if you had to if you had to choose which team you're going to work with, like, you know you want to deal with the people on the original, right?

Um and another reason is that I think once the once the control plane goes out, once the incentive plane goes out, like, once all the tokens go out, that can catalyze a community. A community can be a very strong source of defense because you have a bunch of people who are inherently aligned even though they're not part of the same like legal entity or or may not even know each other, they're all aligned around defending a specific thing and expanding it and pushing it together. We're the very earliest days of that, but I think that that is a kind of defensibility that's not even possible really in Web 2 world, right? Because you'd have to like give everyone some ownership of your company, which is at odds inherently with it being centrally controlled,

right? So, I think that's a potentially interesting one. I also think people may undervalue the network effects that are possible with composability. Composability has to be limited by centralized companies, right? They have to limit it because they want to focus the ways people use their system in ways that serve their end goal. But if it's if it's an open ecosystem where anyone can remix and recombine the constituent parts, then you can emerge with new types of composability and interoperability that are inherently very sticky that contribute to network effects. Think about the incredibly powerful, like, crazily powerful network effects of uh programming languages, for example, or like uh low-level pieces of software that people check out, like, open source

software. Massive network effects around those things. If you try to build a system with like a new programming language, you have a major uphill battle, right? Like, some new esoteric language. Yet, the languages have almost no means of uh collecting on that network effect, right? They cannot internalize the value that they're creating. Which is why like it's that like I don't know if you've seen like the Python Software Foundation like struggles for funding all the time even though it's like what ubiquitous, one of the most powerful pop- popular programming languages in the world. So, my point is to say is that if the components of the systems you're building are truly composable in such a way that they can achieve network effects like, you know, open source software or

programming languages, that is a kind of network effect that even a centralized system cannot obtain. So, I genuinely think there's a much higher global maximum. And I think once you have a potent network effect and a way to incentivize all the contributors and participants in that system, then it's very likely, although it depends on the system, that you'll be able to discover some way to capture value. Awesome. Thanks so much. Sure. Hey, Eddie. Thank you very much for the talk. Um I have a question. So, what's your definition for application? So, I'm So, so I'm thinking like Ethereum, it's a protocol, right? And the Uniswap on top of it is also a protocol. Yeah, it's all protocols. It's all protocols. Maybe

like the front end of uh Uniswap, it's a prod- product. Yeah, I mean, it's uh it's an admitted weakness and overgenerality of the definition. I think the right way to think about applications is like it's the it's the thing that has some sort of meaning to its end user. Like, it's a specific a specific meaning. You know, you can have you know, if you're using some corporate API, like, in some sense, that's an application that you're using, right? Like, you can, you know, that's that's an application. Uh Uniswap is an application for some people, but it's also infrastructure for others.

So, I I admit it's a little bit blurry, but I think that maybe the key defining line is whether you whether the application has a direct relationship with the end user. Whether the software has an end direct relationship with the end user. Oh, okay. Okay. But But, not a strict definition. I'm Wait. Wait. Weakly held, yeah. Yeah. Yeah. Yeah. And by which like which most protocol they have they run the team runs their own front end, but like it's not like the protocol itself has a relationship. Yeah. So, in that framing like when we're talking about like for example like our regulatory teams idea which like I totally agree with like regulate apps and our protocols. Like what they mean by that is exactly that.

It's like the application in that case is the interface. The front end. The front ends, right? Which many people could run. And then the protocol is the sort of credibly neutral system that's running directly on the blockchain that, you know, has some other governance system or it's immutable or something like that, right? So, in that case I'd say yeah, the application is the interface. The protocol is the back end, so to speak. Like a public good type of Could be, yeah. I mean it's a little bit of a play on public good cuz when people talk about public good they typically think of something because of how few options we've had in the past. When they say public good they typically mean something like something that is free or does not capture value. Right? But, I would I would argue there's like a this third space like

you don't have to be ca- trying to capture every externality you create. Right. You also don't need to be totally free. In fact, I think that the best space to be in for the longest lasting infrastructure can feed itself, can grow itself, can defend itself, can pay for itself, can internalize value, but it doesn't have to do so in a way that is rent-seeking. Mhm. You know, that's net deleterious to the ecosystem that uses it. Yep. Yep. Yep. Thank you. Sure. Cool. Okay. Well, that's all the questions. So, thank you again.