Bitcoin Blockspace: Dynamics of System Resource Use
Competition for blockspace is and always will be one of the core tensions that exist between different users of the Bitcoin protocol. At the end of the day there are only two restrictions on how it will be used, the technical and consensus layer of what is actually possible or allowed by the protocol, and the economic layer of what people are willing to pay to make use of blockspace to different ends.
This is a fundamental and inescapable reality of how the network works. It is a purely market driven distributed mechanism for deciding how Bitcoin is used. Concerning anything that is possible to do, the market is the ultimate decider as to whether or not it will be done. The market is also the ultimate decider when it comes to enabling new things that are not already possible.
It’s an important thing for market participants to actually have an informed understanding of the dynamics involved in different use cases of blockspace to really assess how different uses might interact with each other.
Blockspace As A Common Resource
Blockspace is essentially a commons, no one owns it, both on the production and the consumption side, but it is finite. It is not quite a tragedy of the commons as such, especially given the inescapable cost of using it, but the dynamics of its use does have some similarities. Every use case consuming blockspace has an externality it imposes on every other use case that has a need for that blockspace. On some level, blockspace consumption is very much a zero sum game. One entity or use consuming space pushes out another entity or use that would also consume that space.
In any type of normal social context, people would consciously work out such conflicts. If one use arrives that is consuming large amounts of space, people would work to make that more efficient, or make uses that are pushed out more efficient, in order to maintain some type of balance. In the worst case, destructive uses that are detrimental to a large set of others would be limited or restricted. But Bitcoin is an anarchic system, there is no point of control or authority to engage in that type of system management.
All we have is the market.
The relationship between blockspace utilization and the market dynamics governing it is usually conceptualized in a very oversimplified manner. People buy blockspace, and they can do whatever they want within the consensus rules with it. While this is the foundational aspect of this dynamic, it is not the only one. What is consensus? How is consensus arrived at? This is also an integral component of the dynamic.
Consensus rules are an organic ground up thing enforced by economic actors, and consensus rules govern what can or cannot be done with blockspace. This is a critical layer of the market dynamics governing its use beyond the simple economic facet of what people choose to purchase blockspace for.
This is a critical aspect of the system, and how it works, and how users of blockspace must reason about the system if they wish to preserve the viability of their specific use of blockspace. Every participant in the system needs to understand that they can participate in market actions through what rules they choose to enforce, not just what they choose to pay for blockspace they consume themselves.
How Blockspace Is Used
Many different dynamics are important to consider when looking at different use cases of blockspace, and how they will impact the overall availability of space for other uses. How much is used, frequency of use, how much inelastic demand there is in the face of price volatility, etc. Everyone designing a system built on top of Bitcoin needs to consider not only how their system functions in regards to its use of blockspace in these ways, but also how other systems do.
Each system needs consider its own internal interactions with the blockchain, but also the equilibrium it will exist in with all the other systems. One system might function very well in a vacuum, but be stressed or ultimately run into a failure mode if it must operate in an environment with other systems of a different nature.
These are the core categories of properties to consider in these dynamics.
Amount of Space
The most basic factor is how much space does a specific use take up in a block in terms of bytes? This is the first form of scarcity introduced to the common resource of blockspace. An ideal system built on top of Bitcoin will seek to minimize the amount of space required for it to function to the largest extent possible without sacrificing utility or security.
Think of it as a simple ratio, you want to consume the least amount of blockspace possible while maximizing the utility and security provided to the user of a system. In some cases this can be done in an exact deterministic manner, i.e. the amount of space used is a constant and predictable thing dependent on the system design and the state the system is in when it requires use of blockspace. In other cases the blockspace requirements of a system cannot be so exactly predetermined. In the case of indeterminable space requirements, a range between lower and upper bounds can be established depending on the state of the system and system design.
So there are systems that have a constant size requirement that doesn’t change during different states of the system, or one that is relatively constant proportional to its level of use. Other systems could have space needs that are variable and not directly proportional to their level of use. Whether or not a protocol’s space needs are variable or constant is a critical consideration when designing a system.
Frequency of Use
The next important factor is how often you have to make use of blockspace. How much space an individual transaction in a system takes up is only a part of the total cost of that system, how frequently does it necessitate transacting?
Some systems are going to require constant utilization of blockspace everytime the system changes state or performs some action. Other systems will only require infrequent use of blockspace. Some might even require essentially none at all except to enter or exit the system.
Just like minimizing the overall space requirement for a single use of blockspace is an ideal design goal, so is minimizing the frequency with which a system must consume blockspace. Ideally a properly constructed system will not need to make use of blockspace except in a worst case failure mode, or when entering or exiting a system.
There are two ways to design a system in terms of frequency of blockspace use, constant or variable frequency. Obviously, in a constant frequency system any time the system performs an action and progresses in some way, blockspace must be used to progress the system forward. In a variable frequency system state can progress, or an action can be taken, without needing to consume blockspace in order to process that.
Both of these types of systems interact with the blockspace market, and each other, in different ways.
Constant frequency systems are predictable and easily analyzable in terms of blockspace use depending on the volume or use of the system itself. The engineering focus of such a system is on minimizing the on-chain footprint, as the frequency with which it will need to use blockspace is predictable and deterministic based on the level of use, i.e. not fundamentally changeable.
Variable frequency systems are not predictable, and are much harder to analyze in terms of blockspace use. The focus of the system isn’t only on minimizing its on-chain footprint, it is also balancing the incentives of the system. Variable frequency systems are generally variable because the need for blockspace arises from users of the system being non-cooperative with each other. This is the source of unpredictability, and why engineering focuses on incentive balancing to ensure cooperation.
Time Sensitivity
How time sensitive is a system’s requirement to utilize blockspace? When a system update or action needs to be performed, does it need to be performed immediately, or can it wait? Is it a response to some other action, or just an update that has to eventually happen but has no solid deadline?
Constant frequency systems should generally have no real time sensitivity other than the need to shift a system state change from unconfirmed to confirmed. Some specific instances of state progression might have some time sensitivity component, but overall the system will either progress state or not.
Variable frequency systems generally have a need for blockspace because a cache of off-chain state progressions is being disputed on-chain. This involves a time sensitivity because the use of blockspace is not a matter of retaining the current state or progressing it, it is a challenge during which it is possible for an entirely incorrect state to resolve on-chain.
These are two very different dynamics in terms of time sensitivity, and because of that price sensitivity, when systems require blockspace. Systems that are less time sensitive can be more price insensitive because they can simply wait longer to confirm some operation on-chain. Conversely, more time sensitive systems are more price sensitive, because they must pay whatever the current market rate is to confirm quickly in order to ensure proper state progression.
Interacting Systems
Both constant and variable systems need to interact with each other, or rather the externalities each creates for everyone, when they interact with the blockchain. Each of them is a very different kind of beast. Constant frequency systems are giant lumbering creatures, not very adaptable or dynamic. They must always use blockspace when the system progresses. Variable frequency systems are much more nimble and flexible, and capable of dynamism in operation. They can find inventive ways in terms of design or incentives to avoid having to consume blockspace.
Whether these systems are constant or variable systems in terms of space requirements is also a huge factor regarding the adaptability of a system sharing the common resource of blockspace with others. Every system’s cost of operation is a factor of the overall saturation of blockspace use globally and where that pushes the price of blockspace. So how often do they have to consume blockspace, and how much do they have to consume?
To top it off, the general level of saturation and therefore fees is determined by the aggregate of systems operating on Bitcoin. So it is a feedback loop, the nature of the systems operating are going to decide how saturated blockspace demand is, and how high fees are. This then has consequences for the viability and operating cost of systems with different architectures.
Lots of constant frequency systems will create consistent and predictable demand, and after a certain saturation point will start driving fees up constantly. Constant systems cannot adapt to this except by finding ways to lower their on-chain footprint, paying more, or simply waiting longer to process system updates.
Lots of variable frequency systems will have less consistent and predictable demand for blockspace. Rather than being a result of consistent system state progression, blockspace demand driven by these protocols will be caused by entry and exit to the system, or severe disruptive events causing incentive breakdowns or disruptions to user cooperation.
When it comes to adapting to high fee environments that cause the cost of systems built on Bitcoin to increase, constant and variable systems have two fundamentally different strategies that can be employed to adapt to that environment.
Constant Systems can compress the data they need to include in the on-chain transactions that they use to progress the system state. Other than this, their options are to wait longer or pay more.
Variable Systems can try to scale the coordination of larger groups of individuals in an incentive compatible way. They can also adjust the architecture to remove or mitigate incentive misalignments or attack vectors that could disrupt systems and force them to consume blockspace to settle a contested state.
Lightning is a perfect example of a variable system, both in terms of frequency of blockspace use and data size. Rollups are shaping up to be a perfect example of a constant frequency and data size system. Both of these things interacting with each other are going to be an important part of watching fee markets mature on Bitcoin, and understanding the different aspects in how they consume blockspace is important.
What Is Gained?
The most important question to ask when comparing different system architectures is what is gained from them? What type of security model does a user gain in choosing one particular system over the other? What is the cost of that security model in one architecture over another? Is the cost borne by a single user alone, or shared across a large number of users?
The cost of constant and variable systems needs to be weighed against the benefits. The stronger the security model, and the fewer parties or assumptions that must be trusted, the greater the value realized by users.
There will overtime be a large number of trade offs in this regard. Many different architectures will come with different costs, different blockspace consumption frequencies, and different benefits. Each one of these systems will have implications for the costs and benefits of all of the other systems operating.
Another factor to consider is centralizing pressures. Variable systems create breathing room to allow many different participants to exist in a system, and leave flexibility for users to adapt to each other’s presence in the context of periodically needing to consume blockspace to guarantee the system’s functioning. Constant systems will likely not, and lead to more centralizing dynamics due to the rather rigid consumption of space and the upper limit of room for other systems to operate that creates.
Choices of the Market
Ultimately what types of systems will exist on Bitcoin, and the effects they will have on each other, comes down to what the market of users chooses to use. It is important for users to both understand the costs and benefits of different systems for themselves, but also the externalities that different systems they use will have on the wider network and ecosystem.
People continuously bring up absurd concerns when new features for Bitcoin come up, like government blacklists, or arbitrary data, or other nonsensical rationalizations to police what people should be able to or not able to do with blockspace they purchase. These are red herrings in my opinion.
The real concern when discussing adding new functionality to Bitcoin is the interaction between constant and variable systems built on top of it, and which one of these types of system architectures a new feature adds utility or efficiency to. This needs to be deeply considered when analyzing new functionality for Bitcoin.
How these different classes of systems are catered to in the base protocol will have profound implications in terms of how Bitcoin’s fee market, and viability (or lack thereof) of different types of systems, evolve in the long term.
Constant systems have a hard ceiling of how far they can push scalability, given their consistent need for blockspace, and those dynamics also make it very likely that they will be a huge driver of consistent and heavy fee pressure if too many of them operate concurrently.
Variable systems might drive fee pressure during mass on-boarding or off-boarding events, or disruptions to system functioning, but otherwise likely won’t drive consistent and predictable fee pressure until reaching a much deeper saturation point than constant systems. If close to ideal designs are made possible, they could potentially never hit a true consistent saturation point.
The market will ultimately decide, but that market should be an informed one.
Credit: Source link
