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. 

One of the best parts about running Breez is the diverse range of people I get to meet and work with. We have partners from Jamaica, the USA, Switzerland, Germany, Canada, Estonia, and who knows where else. We have users in Finland, Wales, Namibia, India, and almost everywhere else. The people behind Breez are split across three continents and come from a broad range of national and ethnic backgrounds.

Agreeing on a communication platform (Telegram? Slack? Zoom? Discord?) sometimes takes a bit of coordination. What never needs coordination, though, is the language we use to communicate. It’s always automatically English. For many of us, English is our second (or third, or fourth) language, and parts of it are baffling, but it doesn’t matter. Every initial contact is in English, all channels are automatically in English, and all public communication (like this blog) is in English. There’s not even a contender for second place.

And there’s basically no way to change this convention. Nobody could simply decree that we’re all going to start speaking Mandarin or Esperanto or Inuktitut. Whether because of convenience, actual utility, historical imposition, or sheer numbers, English is locked in. But it works, so why mess with it?

This example demonstrates a few points. First, the interface between individual nodes in a network – whether people, nations, or communities – has the form of a language. Second, there needs to be a common language. In fact, the limits of the language are the limits of the network. In other words, the distribution of the language defines the network. Finally, common languages are very sticky. Once everyone has adapted to a common language, it’s basically locked in.

Now for a fact about the present that will irrevocably shape the future: Lightning is emerging as the common language of the bitcoin economy.

 A Common Language among Subnetworks

We’ve talked before about various last-mile technologies. They’re like the local secondary roads that connect users to the higher-throughput Lightning Network and, ultimately, the Bitcoin mainnet. They all basically work by bundling users and their transactions into subnetworks.

For example, Ark and Liquid convert incoming bitcoin into their own mechanisms (VTXOs and L-BTC, respectively) that users can then send to each other according to their respective protocols without needing further on-chain transactions. Alternatively, Fedimint members effectively pool their bitcoin and trade IOUs among themselves, with transactions and the financial state of affairs overseen by a federation of trusted guardians. With Cashu, people exchange e-cash tokens and trust the issuing body.

Each kind of subnetwork can use its own language. How the nodes communicate among themselves in these subnetworks is their business. What’s interesting is that these subnetworks communicate with each other over Lightning, even if we’re just talking about, say, two different Cashu mints or when a Fedi interacts with an Ark. Lightning is the common language of all the emergent and thriving subnetworks based on bitcoin.

Returning to the analogy of English, it doesn’t matter to me what language you speak at home or at the supermarket. You can speak whatever obscure dialect you want with others who understand it. But if you want to talk to me or virtually anyone else on Telegram or Slack, English is really the only option. Nobody could change that even if they wanted to, and nobody seems to want to. Just like Lightning.

Lightning is the common language of the emerging subnetworks. It’s the language of bitcoin.

Why Lightning Is the Optimal Language for Bitcoin

A common language is not necessarily an optimal language. It just has to work and be broadly accepted. Just like the Bitcoin mainchain has certain advantages (e.g. immutability, openness, borderlessness, etc.) that recommends it for certain uses, Lightning is the best choice for a common language between subnetworks for at least three reasons.

Lightning Is Bitcoin, and Bitcoin Is the Trustless Bearer Asset

The first and probably most important reason why Lightning is the best common language is that it uses bitcoin. Simply, the subnetworks might not trust each other, and they have no reason to. But since Bitcoin and, by extension, Lightning eschew trust, the subnetworks can interact without trust. Bitcoin is the only viable bearer asset, and Lightning is the language of Bitcoin, so Lightning is the best common language for the subnetworks to interact with each other.

Further, Lightning, like Bitcoin, also eschews leverage. The whole business model of fractional-reserve banks is based on a hole in their balance sheets. By contrast, every sat on Lightning is accounted for at every moment. A balance sheet displaying all the positions on the network would be perpetually balanced. No gap, no overlap. Lightning resists imbalances due to hubris, incompetence, and villainy, which is a necessary feature in a trustless environment.

Lightning Is Inherently Transactional and Interoperable

Second, Lightning is a transactional protocol designed to facilitate flow. For normal payments, there’s no mempool and no delay until the next block is mined. Payments take seconds, if that. And transactions – money in motion – are what make Lightning valuable. Literally. Static sats on the network don’t earn any return. In order for liquidity on Lightning to grow, it has to flow. A common language won’t be used much if it rewards silence. It must promote communication, which is exactly what Lightning does.

Further, the Lightning technology detailed in the catalog of bolt specs is inherently interoperable. It was designed to enable multiple implementations of Lightning nodes with different designs, trade-offs, and programming languages. All these nodes can, however, interact over a common network because they all support the same bolts. Being interoperable by design makes it easy for other technologies to add Lightning as another interface.

Lightning Has Critical Mass

Finally, a common language needs a sizeable community of speakers. Try saying “skibidi rizz” in a nursing home or, even better, a nursing home in Cambodia. Perhaps the biggest advantage of English is simply its popularity: more people speak English than any other language on the planet. And while only a quarter of the inhabitants of many countries speak English, you can still find an English speaker at the next table at virtually every bar and restaurant on the planet. Try that with Catalan.

Lightning has already achieved a critical mass. It’s already obvious how a Cashu subnetwork and Fedimint subnetworks will communicate with each other: Lightning. That’s how they were designed, so switching the common language between networks would require rebuilding most of their parts. Like English, whatever language subnetworks use internally, Lightning is the language they use to speak to each other, and it’s already locked in.

The Permanence of Lightning

Actual lightning – the kind from storm clouds – is a notoriously brief phenomenon. Flashing momentarily and vanishing is its whole thing. But the Lightning Network – the interface between any number of nodes, subnetworks, and the Bitcoin mainchain – is not going anywhere. Common languages tend to hold that status for centuries.

Bitcoin is the world’s best currency. Lightning is the common language of the bitcoin world, and it’s here to stay. For those of us already established in Lightning, this is very good news. That Lightning is locked in means our first-mover advantage is going to be very valuable indeed.

But it’s also good news for those just entering Lightning now or considering it. It eliminates uncertainty about which technology to support and invest in. Lightning is going nowhere but up, so it’s never the wrong time to get started. Better yesterday than today, better today than tomorrow, but tomorrow is good too.

The best time to get into Lightning is now. Always has been.

This is a guest post by Roy Sheinfeld. Opinions expressed are entirely their own and do not necessarily reflect those of BTC Inc or Bitcoin Magazine.