What do Protocols want?
Imagine your protocol could speak.
How would it answer the question, "What do you really want?"
The question is important to help distinguish between the properties that a protocol tries to have versus it's actual goal. In an ideal case, all properties contribute to achieve the intended goal, the objective function of the protocol.
In the good old days, a strong hint as to the protocol's desire could be found in its name.
FTP mean the protocol wanted to be a file transfer protocol.
SMTP meant the protocol wanted to be a "simple mail transport" protocol.
However, those describes just defines what the protocol does.
What does it want?
One of those goals would be maximal utility. A protocol wants to be used to the fullest extent for the utility it provides.
What this means is that, for example, if performance is critical for maximum utility, such that a meaningful percentage of people who want this utility will not because of the absence of sufficient performance, the protocol will do something about it.
If sufficient granularity of controls and configuration are essential, the protocol will enable those in a flexible way.
But what else does a protocol want?
The protocol would likely want minimal overhead: to meet the needs of the potential users, it would want to be able to do so with the least amount of support, maintenance, and friction to meet those needs. Depending on the domain, this could mean it wants to be stable and change very little, because the domain has become static; but if the domain is changing, it may want a way to modularize itself so that it can evolve and grow with agility.
As these goals get better defined, as we can see, the properties that support those goals become important. Properties are useful to the degree they serve the protocol's objective function.
For example, a protocol may want itself to be immutable or near-immutable because they serves a function.
Or the protocol may want to be maximally decentralized because that property is essential to meet the objective function.
This is an important distinction and creates the challenge of the design space: is the objective function properly defined and are the properties to get there the "right" ones?
Defining the domain model and the associated properties matters; otherwise, without boundaries on the respective objective functions, the protocol will want all the things.
In the case of a poorly defined objective function, you can have a micro-version of the "paperclip problem" -- it pursues some objective function that either self-destructs or creates a negative outcome.
In the case of poorly defined and scoped properties, it's more likely the objective function is not achieved, or at best, achieved sub-optimally.
Let's use Bitcoin as an example.
If the objective function is to ensure it is the most secure mechanism of peer-to-peer payments, such that there are no double-spending, no vampire attacks via forking, no single entity can change the rules of the protocol, such as fees or minting, then a set of properties emerge.
One of those is decentralization...but decentralization of what?
In this case, decentralization of nodes that form consensus of what the true ledger is matters; because the ledger determined the spending by recording UTXOs.
But...for its goal (and I don't really know what the objective function actually was intended to be) hypothesized above, does decentralization of ownership of Bitcoin matter?
On the one hand, it does: if a single monolithic rock of an entity owned all the Bitcoin, it wouldn't achieve it's primary goal, which is usage as a p2p spending currency.
So the question is whether or not Bitcoin was designed properly since neither technically nor crypto-economically is there a strong limit to this form of decentralization.
Perhaps there could be in the future, and this is where the details of mechanism design come into play: maybe something bad would happen if this huge rock owned all of the Bitcoin and never spent it, this would have negative second order effects on the miners or the nodes, which would hurt the value of Bitcoin.
In this case, the protocol does have some incentive built in to increase velocity of the money being spent as a currency, which would return it back to the original objective function to maximally serve as a p2p currency.
But right now, it doesn't seem that way: if it's a store of value that will go up forever...why would it?
The third thing that protocols want to help achieve it's objective function, such as HTTP/S, would be usage to transport hyper-text. This means it wants to maximize its "marketshare" of potential users who would want to review hyper-text (or perhaps any content) delivered over the Internet.
The reason the Internet and the Web which lives on top of it has been so successful has been the proliferation of products on the protocol.
Protocols which are fertile for the growth of products on top of it likely are the most successful.
Why?
Because users are weird.
Users have all kinds of needs -- the bigger the market, the more diverse their needs.
Not only are the needs diverse amongst users, but even within the life of a single user, their needs are diverse.
Not only are the needs diverse, but so are the capabilities.
The HTTP protocol was less accessible to those who wanted to use it in the beginning. The ability to serve a file via the protocol, the control of the presentation layer, and ability to have read/write -- all of these things needed products to simplify access to the protocol.
The HTTP protocol became wildly successful, in part, because it was served by products which could address the different needs.
Some products became wildly successful because they tapped into near-universal needs.
Google, for example, taps into the need for humans to search and find what they want.
The actual objective of their search is infinitely variable.
But this business took off because the underlying true human need was no secret: people do search for what they want. It can be information, which is what Google offers primarily, and all the downstream behavior that comes once one has the information (prices, addresses, description, recommendation, etc).
As a result, HTTP was happy because of all the products that could be built on top to maximize its utility.
Protocols are happiest when they can maximally deliver its utility. And the properties that help them get there are what determines the winners and losers.