Preference Curves Like Permissionlessness in Protocols

We're continuing the exercise in designing, from scratch, a fictitious "blockchain data query and transfer protocol" called BDQTP.

We started off with the objective function to maximize the spend denominated in some stable currency (although an argument could be made to not do that due to exposure to currency risks across countries that need to convert -- but not going to go there because I don't understand this). (see Working Backwards for Protocol Design for that context).

How will we meet that goal, which is further clarified by this snippet from the Protocol's Mission:

"Enable developers anywhere to query and transfer blockchain data in the manner that best meets their needs and their use case and satisfies their core non-functional requirements (e.g. latency, verifiability, availability, and comprehensiveness) without any platform risk."

What do I mean by "in the manner that best meets their needs"?

Arguably, isn't meeting their "use case sufficient"?

We've seen the software industry produce bad, nearly unusable software that met the business' use case, but didn't meet the needs of the user.

In a developer-facing service, the user is the developer, and developers have needs that extend beyond solving the use case for the business.

These aren't defined in the protocol mission statement explicitly because those needs are many and varied.

Yet, if that's the mission, we should ask, how can a protocol do so?

Preference curves -- the needs and preferences of the developer experience -- are difficult to meet, and vary. But...they aren't infinite with regards to how a developer chooses to interact with the service.

We know successful start-ups have been able to grow very big because they deliver on a delightful developer experience across a range of different developers.

But despite those successes, it's hard to maintain over time while broadening scope.

Example: Atlassian for bug tracking and task management.

It met a business case and has been, for the most part, acceptable to enough developers. That market had alot of options, and Atlassian has emerged as a major player.

However, Linear is tackling the same space, and gaining lots of developers from developers who have found Atlassian no longer meet their needs.

That same innovation between companies needs to be within the protocol to capture those changing and varied preference curves.

For a single company to do this is difficult. Preferences among humans vary as much as favorite ice cream flavors.

Even a company like Apple which has the ability to create nearly universally delightful products still has a smaller marketshare than their rivals put together.

What this means is people with different talent, perspective and insights into the various preferences of developers need to be able to serve the protocol's developers without fragmenting the experience.

One side of that equation depends upon Permissionlessness.

In other words, rather than closing the ecosystem from innovators who might be able to better serve a dissatisfied segment of the market, permissionlessness allows and ideally rewards them for taking that leap in an open, positive-sum way to the ecosystem.

This means, in the case of a single unified data service that multiple services need to be able to emerge to respond to the demand of developers quickly. In the same way that AWS was able to respond to the demand for database and data services with a full menu (and did so successfully as a large, single entity), so must the protocol.

The challenge with permissionlessness, however, is that it could invite noisy neighbors: someone comes up with a useful service, and another provider comes up with another service with very minor improvements. In the regular market, they compete in a zero-sum way and often don't differentiate themselves in a meaningful way. They fast follow.

This is similar to the concept of "chimps" -- where lots of chimps exist in a gorilla-dominated ecosystem, but there's still enough profit for them to survive.[^Moore, "Gorillas"]

The Apple App Store is one example of this. The AppStore doesn't care or mind if there are competitors or outright clones of any given app. Even very minor modifications to a service, as long as it can attract more customers, benefits the AppStore.

However, the User Experience begins to degrade. The customer has a harder time to discover the right app they want and will enjoy. Fast followers and clone can look like the right solution but abandon the project, fail to innovate, or even outright scam the customer.

Apple doesn't want to be the sole determiner of what kinds of apps should run in their store. They benefit when innovators and entrepreneurs are able to access it.

However, Apple has an ongoing challenge of ensuring that the quality of apps don't degrade the experience hurting the number of app purchases.

Part of their success comes from not being a close environment where they make all the decisions. They have a layer of permissionlessness.

But it is not total permissionlessness, as Appstore developers know.

There are guidelines to publish to the appstore, some of which can be often obscure or confusing. There is also a review process to check for adherence.

Total free for all in the web2 market doesn't work. Amazon, for example, in their third-party marketplace has seen knock offs, poor quality, and poor customer service tarnish the experience with a looser approach to permissionlessness.

Does web3 change this?

I think it can, but the design space is still emerging.

Imagine the protocol allows any enterprising developer to offer a data service through its network.

Because the innovation needs to be collaborative, the software will be open -- meaning it can be publicly viewable and transparent in an unstoppable repository that allows any developer, including competitive developers, review and fork the code.

But is there a mechanism that can be designed which discourages fast followers or forkers from providing similar if not identical services that don't improve the developer experience, and make it harder by confusing which service best meet their preference?

I'm not going to solve this part in this essay.

The part that the protocol needs to encourage is the supply and innovation side: permissionlessness encourages those who can best meet the demands AND reward them.

How would this work?

The protocol would need to make sure that truly innovative intellectual property from a given developer were rewarded. At the same time if another developer or team of developers like the initial service, and want to join in and constructively contribute to the project, they, too, should benefit from their efforts.

Many protocols rewards the permissionless "work" side of the supply for simpler behavior. The "Proof of Work" concept from Bitcoin is an illustration of this.

Miners who provide computational power to secure the network are rewarded with Bitcoin. There's an adversarial nature in that for a given block reward, only one miner can solve it. However, collaboration of computer power became possible at one point by pooling resources to share in the rewards.

However, in the case of much less discrete competitions like IP or code contribution, the reward mechanisms are different.

In many ways, it's similar to the problem found in companies: founders by virtue of reaching a stage in the market earn an outsized percentage of ownership. In theory, those who come later took on less risk, and so own a much smaller percentage.

However, being early isn't always the indicator of value. Some successful companies have co-founders who can be very early as part of the team, but their contribution to the value of the company may be smaller than that of more talented employees. Yet the "risk" taken early gets a much higher reward premium.

Does the same dynamic exist in more constrained markets like the supply side in a protocol?

I don't know the answer. This is again the challenge of permissionlessness to meet preference curves.

The second, related protocol design question which have a diverisified supply side is how much to abstract the service from the customer.

If we go back to the mission of maximizing demand and meeting the needs of the developers, this drives the protocol to abstract as much of the supply side from the customer as possible.

At the same time, it should promote a closed, user experience that can be tightly controlled to ensure maximum usage.

Here, the comparison between Apple and Microsoft could be appropriate.

Microsoft created an open market for peripheral manufacturers. As long as it could reasonably interface with their "DLLs" which was like the API to the operating system[^Microsoft DLL] they could go to market with mice, keyboards, camera, monitors and so forth.

The strategy largely worked: lots of peripherals came to market, which made Microsoft's platform more compelling to users, initially, due to choice; but over time, the "plug n play" concept failed as users grew frustrated with the incompatability or glitches of different vendors. These could range from it just not working, to being it clunky or confusing.

Apple, in the beginning, abstracted away all the choice and assembly of peripheral components and made everything "just work."

The consumer benefitted greatly from this experience that is tightly controlled on the UX level, and it meant Apple centralized the entire supply chain.

In an environment where you want to encourage and reward innovators, the protocol someone needs to reward and differentiate those that provide differentiated value. It cannot reward the one who designed the service from the beginning equally with service providers who provide the exact same service without contributing. This tragedy of the commons discourages on-going innovation because it lacks the risk-reward dynamic of free enterprise systems.

Nevertheless, the design of a protocol must make choices around how balance their ability to attract innovators while encouraging collaboration in a free market environment.

In fact, this could be called the "supply side" trilema: