Thank you to Mark Tyneway, Jon Charbonneau, and Luca Donnoh for their thoughtful reviews of this post.
It's a story as old as time: Jon Charbonneau wrote a mammoth blog post and some people got mad.
Jon's topic du jour is the Rollup and its relationship with the bridging systems that connect it to other blockchains. I'd say that there was probably a 70%/30% agree/disagree split, which is honestly better than I expected. I still think that we can get that number closer to 90%/10%.
Most of the critical reactions to the post boil down to the sentiment that the article paints a picture that departs from the practical reality of Rollup systems today. Reading the post again, I can understand where this sentiment comes from. Jon is poking at a tension between the fundamental nature of a system and the behavior of that system in practice. This is uncomfortable.
Comments on fundamental reality can become touchy subjects and may cause confusion if fundamental reality is actively presented as practical reality. We know that this is true. In theory, Rollup bridges could be created such that they almost entirely inherit Ethereum's security properties with minimal added trust assumptions. In practice, Rollup bridges are (for now) at the mercy of relatively small multisig wallets (Except Fuel V1™). Presenting the theoretical future as the practical reality is misleading at best.
We understand that it's important to communicate practical reality to end-users of these systems because a system's risk profile is defined by its practical reality. However, this does not negate the importance of the fundamental reality. We wouldn't be constructing Rollup bridges if we didn't understand that Rollup bridges could be improved to the level of security that we're looking for. Analyzing the true nature of a system is necessary to see what could be over what is. Anyone working on these systems needs to be comfortable with this duality.
Jon's post is asking us to dig deeper so that we can see what's possible. It is not asking us to ignore the reality of these systems today. I understand that this sort of distinction can be confusing for the "average person" but a fifty page article dissecting the nature of the Rollup is mostly unintelligible to the "average person" anyway. Jon is writing for system designers and engineers with the hopes that we see the fundamental nature of Rollup reality.
At the same time, I do think that this point probably could've been made more clearly. The article begins with the statement that "The prevalent understanding of rollups is a lie." This statement is obviously hyperbolic and provocative but the bridge != Rollup perspective isn't the prevailing view. We sometimes need to say bold things to get a conversation started. It is what it is, and it worked.
I'm going to spend the remainder of this post taking another look at the subject of Jon's article. I think it deserves some backup because the point being made is important and I don't want it to be lost over framing.
Unlike Jon's article, I don't want to make any attempt to redefine terminology. Instead, I want to take a critical lens to the subject in the hopes of highlighting the unspoken tension in our language. I hope that this leads to a better understanding for system designers. I'll also do my best to present the fundamental reality alongside the practical one, contrasting what could be and what is.
I'm going to construct my argument piece by piece. Please stick with me, I promise all the points will eventually come together.
Let's start with some fundamentals. Blockchains are state machines. If you're reading this post, you probably understand that point. State machines are composed of two primary elements, the state and the state transition function. The state of the machine is essentially its memory (oversimplifying) and the state transition function is the program that defines how the machine state can be transformed into some new state [1].
When we "execute" a state machine, we take the current state and some input and generate some new output state. You'll often see this represented mathematically as the following:
stf(current_state, input) → next_state
Assuming that the state transition function is deterministic, the current state of one of these machines is entirely defined by the initial (genesis) state, the state transition function, and the list of inputs that we've fed into the machine. If we want to reproduce the current state, we must have access to all three of these components.
In the real world, "having access to these components" literally means storing the bits of information that represent these components. A genesis state might be a JSON file. You need a copy of this JSON file file sitting on some storage device that you control.
The list of inputs that we've fed into the machine is a different story. State machines (or at least those with some practical utility) tend to be highly dependent on the ordering of these inputs. This should be obvious in the blockchain context. If Alice has a balance of 1 ETH and sends 1 ETH to Bob and Carol in two separate transactions, the ordering of these transactions is critical to the ultimate outcome [2]. Ordering matters.
And, of course, we also need to be able to actually download these inputs from somewhere to execute our state machine. We have no way to reproduce the final state if no one has a copy of the original inputs.
We therefore come to understand that we must be able to maintain two key properties to create a reproducible state machine: the ordering and data availability of the inputs that we feed into our state machine.
Consensus mechanisms exist primarily to establish an ordering of inputs in a distributed environment. Blockchain consensus mechanisms generally aim to achieve this goal by making it prohibitively expensive (in a real financial sense) to reorganize these inputs in any meaningful way [3]. Most blockchains today don't actively incentivize data availability but instead rely on the (very pragmatic) assumption that people will care enough about the data to keep it around [4].
Blockchain consensus is very powerful. Blockchain consensus is also very annoying to bootstrap. Modern consensus mechanisms tend to be complex and carry maintenance and operational overhead [5]. A reliance on economic deterrance also means that anyone spinning up such a system must raise a protective security budget.
We can get around the consensus problem by relying on the consensus (and incentives) of some external blockchain to maintain input ordering (and data availability). We accomplish this by publishing transaction inputs to an external blockchain and making the assumption that the external blockchain will be able to maintain ordering (and data availability). Under this model, we are effectively purchasing consensus as a service from the blockchain that they connect to [6].
This approach is a notable advancement because it significantly reduces the upfront cost of creating a new blockchain. Consensus is no longer a system component that a blockchain must maintain internally and is now a product that can be purchased for a fee [7].
Careful reading of the above description of a reveals an interesting observation: a blockchain does not need to support smart contracts or programmability in order to maintain ordering and data availibility. This is, of course, why Celestia makes any sense at all. Celestia is in the business of selling consensus and data availability as a service [8].
We can therefore construct a new blockchain that utilizes the ordering and data availability capabilities of some external blockchain, even if that external chain does not have smart contract capabilities. We can construct a system like this on top of Celestia just like we can construct a system like this on top of Ethereum. The prevailing narrative refers to a system that uses the external blockchain for ordering and data availability (and nothing else) as a "Sovereign Rollup".
We now need to discuss the topic of blockchain "forks" because of their relationship to the way that we define what a blockchain is (in a more fundamental sense).
We know that blockchains are state machines. We know that we must have access to three components to reproduce the current state of a state machine: the genesis state, the state transition function, and the list of inputs.
A blockchain fork happens when observers are presented with two or more potential versions of the same original blockchain system. We see short-lived forks on major blockchains like Ethereum every day when the consensus mechanism of those blockchains temporarily generate two potential lists of inputs that could both be accepted as canonical. Forks like this are generally expected and designed to be quickly resolved by the blockchain's consensus mechanism.
An interesting type of fork can occur when one or more observers of a system run different versions of the state transition function in their local execution of the state machine [9]. When they do this, the observer will compute a state that likely does not match the state of observers running the unmodified state transition function. Anyone can fork a blockchain at any time by running a node and modifying some software [10].
When a blockchain fork like this occurs, there are really now two distinct blockchains, each defined uniquely by their state transition functions. A process referred to as "social consensus" then kicks in during which "people who care" will "do stuff" to determine which fork is the "real" system. Social consensus is not always decisive and can lead to a fissure in which two or more significant groups choose to follow mutually exclusive versions of the system [11].
I made liberal use of quotation marks in the previous paragraph because the implications of blockchain forks are weird. I'll try to break down each of the things I highlighted one by one. When I say "people who care," I'm referring to the fact that the outcome of the fork is only important to people with an existing vested interest in the original version of the system. A slightly more rigorous statement is that someone only needs to make decision about a fork if the value provided by the new version multiplied by the probability that others will accept the new version is sufficiently positive or negative for the decision maker.
When "people who care" decide that they need to care, they start to "do stuff." Here I'm referring to the concrete actions that people take to determine a course of action and potentially convince others that they should take the same course of action. This is the pseudo-political social consensus process. Social consensus, like any political game, has intricate power dynamics in which some participants may have significantly more sway than others.
Take Circle, the issuer of USDC, into consideration. USDC is one of the largest fiat-backed stablecoins on Ethereum and derives its value entirely from the ability to redeem USDC for USD via Circle. Circle's decision of whether or not to follow any given fork, and therefore redeem USDC on that fork for USD, certainly has a large impact on social consensus.
These last few paragraphs highlight the interesting reality that there are an infinite number of potential forks within any given system that people simply don't need to care about. A state transition function can be modified in any number of ways. All of these potential forks exist in a very real way but are insignificant until a large enough segment of system participants decide that they are sufficiently valuable and likely to be socially accepted that they're worth caring about. The fork of Ethereum where some random bit in the state transition function is flipped could exist (and counterfactually does exist) but is likely not particularly valuable to anyone.
This leads nicely into the concept of the "real" version of the system. Perhaps the easiest way to understand this concept is that there is often a large amount of social and brand capital attached to the capital-N Name of a system. When we refer to the "real" system, we're really mostly referring to the version of the system that gets to take the system Name (along with the social and brand capital that comes with that Name).
I want to hammer home this point because it's critical to my argument. I hold very strongly that it is the system Name that is the most meaningful object in this context. An infinite number of different Ethereums could exist but the vast majority of these aren't worth caring about. When we ask the question of which version is the "real" system, we are actually asking the question of which version gets to carry the system Name.
We care about the version of Ethereum that social consensus decides we should care about. Sometimes the system enters a state of decoherence in which there is more than one version that has a non-trivial chance of carrying on the name. Eventually social consensus makes a decision and one thing becomes Ethereum and the other thing becomes not-Ethereum. Ethereum does exist, and it is the specific version of some system that we socially agree to refer to by the Ethereum Name.
I argue that other definitions the meaning of "real" in this context aren't particularly useful. The modern recipe for Coke in the United States substitutes sugar for high fructose corn syrup. Does this mean that the Coke we can purchase today is not "real" Coke? You could go blue in the face shouting about the fact that "the only real Coke was made in the 1950s and everything else is a lie!" but you'd be met with a sea of blank faces who all think you're being pretentious and confusing [12]. You can argue all you want that Ethereum Classic is the Real Ethereum but you'll be met with a similar fate.
One more topic for discussion before we start tying all of this together: blockchain bridges.
Blockchain bridges are systems that allow two blockchains to communicate with one another under certain security assumptions.
A message sent from a blockchain takes the form of a transaction within the state machine of the sending blockchain. Blockchain bridge communication is therefore fundamentally about the ability to reproduce the state machine of one blockchain inside the state machine of another blockchain.
Luckily, we've already explained exactly how to reproduce a state machine. We simply need to access the genesis state, state transition function, and list of inputs for the sending blockchain from inside the receiving blockchain. We then also need to execute the state transition function over the list of inputs until we generate the desired output state (again, from within the receiving blockchain).
Practical constraints make this a pain in the ass (to say the least). Blockchain environments tend to be highly compute-limited such that executing the entire state transition function is either extremely expensive or flat out impossible. We typically address this problem with an optimistic mechanism (propose the current state, challenge if incorrect) or with a zero knowledge mechanism (prove the result out-right).
Assuming we can fully solve our compute restrictions, we must still be able to securely access the sending blockchain's list of inputs so that we can properly execute the state transition function. Doing so in the most secure manner possible typically requires verifying the sending blockchain's consensus mechanism within the receiving blockchain. The sending chain must expose a mechanism to make this possible.
The highest level of security that a blockchain bridge can achieve is entirely dependent three things:
We can generally reduce the security assumptions for (1) down to a point where they become mostly insignificant. Assumptions for (2) and (3) tend to introduce the largest discrepancies. It is usually the case that these discrepancies are large enough that messages received over the bridge are not considered "trustless" in that their authenticity is dependent on assumptions markedly weaker than the native assumptions already made on the receiving side.
Scalability (in the blockchain context) can be thought of as the ability for a user of a blockchain to expand their access to additional computing power with respect to the security assumptions that must be made to acheive this result. In this sense, scalability is the multiplicative product of computing power and security.
It's worth noting that this description is from the user perspective and not the system perspective. I believe this is the most reasonable way to describe scalability because it highlights the ability for different users to achieve different levels of scalability depending on their risk profiles. An ideal mechanism scales available compute for all users but it's often the case that not all users need this type of scalability. For instance, an account that exists simply to hold a set of assets likely does not care as much about scalability as an account that trades assets on a daily basis.
A mechanism "perfectly" scales if it can add compute without weaking security assumptions at all. In practice, most ways to add compute do introduce new security assumptions but we do our best to reduce these down to a minimum. By viewing scalability from the user perpsective, we can also allow some users to take new security assumptions without imposing those same assumptions onto others.
Blockchain bridges are an important part of blockchain scalability because they allow one users on one blockchain to access the computing resources of another blockchain. Of course, the limitations of blockchain bridges we just described modulate the "quality" of this new compute because it often cannot be fully trusted. We've scaled, but at what cost?
What does any of that have to do with Sovereign Rollups? Well, a Sovereign Rollup has an interesting relationship with the blockchain it connects to — it shares a common consensus mechanism.
This means that both blockchains can access the list of inputs for one another without introducing any new trust assumptions at all. Neither chain needs to verify the consensus of the other (since it's the same consensus) and both chains are already making the same exact security assumptions about the consensus mechanism itself.
Assuming both chains support program execution (not always true, see Celestia), we can therefore construct a bridge between these two blockchains that only makes the security assumptions required to efficiently execute the opposing chain's state transition function. And, as we mentioned earlier, it's possible to reduce these specific security assumptions down to an acceptable minimum. We now have a "trust-minimized" bridge that gives users on each blockchain access to the other's compute resources with excellent security properties [13]. Now that's some high-quality scaling!
Prevailing nomenclature refers to this joint system, the combination of the Sovereign Rollup and the bridge, as a "Rollup." As in, like, a real Rollup.
Here we finally get to the meat of the argument. I posit (and Jon agrees) that this specific way in which the term "Rollup" is used creates a hazy mental model that ultimately does a disservice to the way in which we (as system designers) understand how these systems really work.
Under this model, when a trust-minimized bridge is established between a Sovereign Rollup and its consensus-host chain, a Rollup system is created. We have already established that the Sovereign Rollup, like any blockchain, is a somewhat blurry construct where the "real" version of the thing is dependent on the system that carries a given Name as defined by social consensus. A Rollup, however, would be defined by the bridge smart contract, which itself defines particular version of the state transition function. These are two very different types of objects.
A Sovereign Rollup is a blockchain, and a blockchain can be forked. The existence of a trust-minimized to the host chain does not change the fundamental nature of the Sovereign Rollup. What happens when the Sovereign Rollup forks?
If the state transition function defined in the trust-minimized bridge is immutable, then the Rollup essentially now permanently refers to a previous version of the Sovereign Rollup that may no longer have any meaningful value.
This has profound implications. The Rollup bridge can be used to transfer assets from the host chain to the Sovereign Rollup with a lock-and-mint mechanism. Assets are locked into the Rollup bridge and a message is sent to the Sovereign Rollup with instructions to mint equivalent "bridged" assets on the receiving side. However, in the case of a fork, the Rollup will only verify the legacy state transition function and will therefore only listen to messages from the legacy version of the Sovereign Rollup. Bridged assets on the forked chain can no longer be redeemed for their backing (locked) assets in the Rollup bridge and become essentially worthless.
This means that the existence of an immutable Rollup bridge creates an inherent cost to any fork. Assets transferred through this bridge will always become worthless on the forked chain. If sufficiently many assets have been transferred through the bridge, this cost may make it practically impossible to execute a successful fork of the Sovereign Rollup.
Indeed a Sovereign Rollup can effectively lose its Sovereignty to fork and become Just a Rollup™ if an immutable Rollup bridge backs some sufficently large percentage of assets on the Sovereign Rollup. This isn't a fundamental change to the properties of the Sovereign Rollup, but a practical one.
It is important to note, though, that social consensus can still choose to fork if the benefits of executing the fork outweighs the costs. Assets natively issued on the Sovereign Rollup are still subject to system's social consensus and are not directly tied to backing assets inside of some bridge. If a scenario arose in which a large percentage (say >50%) of the system's economic value were tied to natively issued assets and a fork were required to maintain this value (perhaps to resolve a catastrophic hack/bug), a fork may still be the economically rational decision even if bridged assets become worthless.
This situation highlights the core problem. The "Rollup" in this scenario refers to the bridge and therefore the legacy version of the system. Social consensus may deem that the forked version is the "real" version and therefore allow it to carry the Name of the legacy system. We now have a Sovereign Rollup with the canonical system Name and a Rollup that can probably only be referred to as "Rollup Formerly Known As Rollup Corresponding To Sovereign Rollup <Name>".
Of course, this sort of thing is only a problem if the Rollup bridge is immutable. We can solve that, we have governance! We can choose not to make a Rollup bridge immutable and instead have the state transition function enforced by that bridge be determined by some governing mechanism.
In this version of reality, the Rollup bridge can be updated to follow the forked version of the Sovereign Rollup. Assets transferred through this upgradeable bridge can then still be redeemed on the forked system.
What makes this situation so interesting is that the governance mechanism on the Rollup bridge can exert an enormous amount of influence over the Sovereign Rollup. Just like the threat of worthless bridged assets makes forking painful in the immutable sense, the threat of worthless bridged assets can make not forking to follow the decisions of the bridge equally painful. The upgradeable Rollup bridge may become a force in the social consensus process that's close to impossible to ignore.
When this happens, the contemporary definition of "Rollup" starts to make much more sense. A sufficiently powerful upgradeable Rollup bridge may have close to complete control over the social consensus process. The system Name follows social consensus, the Rollup bridge controls social consensus, so the system Name follows the Rollup bridge. Now the Rollup bridge has, in a sense, become the Sovereign Rollup.
But just like before, this relationship is not absolute. The primary threat of the upgradeable Rollup bridge is the ability to make assets bridged into the Sovereign Rollup entirely worthless. Even so, the Rollup bridge does not have the ability to directly influence the value of assets issued natively on the Sovereign Rollup [14]. The social consensus mechanism of the Sovereign Rollup can still choose to fork, taking the system Name away from the upgradeable Rollup bridge.
Here, then, is the ultimate point. We refer to these things called Rollups by their system Names. We say that OP Mainnet is a Rollup or that Base is a Rollup or that Arbitrum is a Rollup. These system Names can be taken away from the upgradeable Rollup bridge by social consensus. It therefore only makes sense that these things that are given system Names are not Rollups but Sovereign Rollups with very powerful Rollup bridges.
Just like in the case of Coke, referring to the Rollup bridge as the "real" system in the case of such a fork is a losing proposition. Users may be interacting with the forked Sovereign Rollup even if their bridged assets become worthless. Attempting to tell users that "noooo, that's not the real OP Mainnet" makes no sense if the vast majority of people attach the brand value to the forked system. This stance would create confusion for little added benefit.
The goal of this work, and the work that Jon put out, is to highlight that social consensus over these Systems That We Call Rollups But Are Actually Sovereign Rollups is not defined by the Rollup bridge in a fundamental way. It is obviously the case that we cannot ignore the influence that Rollup bridges have over their Sovereign counterparts. We should be clearly communicating this power dynamic to users while understanding the deeper reality as system designers.
But the current presentation of these systems takes this agency away from network participants for the benefit of the Rollup bridge.
It should then be understood that upgradeable Rollup bridges have a massive entrenched interest in making sure that the Rollup bridge maintains control over the social consensus process. This is because the largest upgradeable Rollup bridges are either already governed by or planning to be governed by project-issued tokens. Indeed, the entire value proposition of most of these tokens is that their holders are allowed to govern the bridge.
As long as the Rollup bridge has at least some control over the social consensus process, the governance token makes sense. It can influence the state transition function such that the Sovereign Rollup is required to pay some fee to the governance system at all times. If the Rollup bridge loses control over social consensus, the Sovereign Rollup may choose to stop paying this fee, driving down the value of the governance token.
This relationship between the Sovereign Rollup and the upgradeable Rollup bridge is usually highly beneficial, and not harmful, by default. A governance system can provide highly valuable services for the Sovereign Rollup like ecosystem growth projects and beneficial state transition upgrades. These services may very well be worth far more than the fee that the system is required to pay back to governance (and this is almost always the case, at least for now). But governance is not absolute and harmful governance can be overthrown, at a cost.
Understanding the Rollup through the lens of the Sovereign Rollup and not through the lens of the Rollup bridge is important. It's important for the system designers who want to better understand the potential behavior of their systems. It's important for the users who should be aware of their capabilities and the power dynamics they may be subject to.
We should strive for accuracy and transparency when describing our creations to the world. The prevailing notion of the Rollup, as an object defined by a Rollup bridge, is insufficient.
Perhaps more importantly, the definition is going to fail at some point when a Sovereign Rollup decides to break up with its Rollup bridge. Most of the arguments against this mental model rely on the assumption that this relationship with the Rollup bridge is so absolute in practice that there's simply no point in thinking otherwise. I do not believe this is the case. It may be true for the biggest Rollup bridges today, but there is no reason to believe that it will always be true in the future.
Even in the case of the biggest Rollup bridges of today, there are clear scenarios in which this relationship could be challenged. As these systems become more mature, an increasing number of assets will be natively issued on the chain rather than bridged. A catastrophic hack or bug could create a scenario in which it is significantly more valuable to save the native assets even at the cost of losing bridged ones. This isn't like cryptography where we're assuming some microscopic epsilon probability assumption.
Practically, I'm not entirely sure where we go from here. The existing Rollup definition is deeply ingrained in our collective understanding, particularly in the ways in which these systems have been communicated to end-users. I suspect that the Sovereign Rollup centric perspective will begin to take hold over the coming years, but it'll take time. I see this as a case of social constructionism competing with essentialism. No matter what, we should be doing our best to help users understand that they do have social consensus power over the Rollup bridge.
Additionally, whether you agree with the definitions of specific words or not, system designers should strongly consider the validity of this position. Social consensus exists and the process is not fundamentally defined by a Rollup bridge. I see no pratical reason to ignore this reality. We seek to know what could be rather than what is.
Thank you for reading.
Astute readers of this post might've noticed that I (sneakily) left out a very important point. I previously made the point that scalability is the ability to expand computational resources with respect to the new security assumptions required to access these resources.
Upgradeable Rollup bridges introduce a massive security assumption on the behavior of governance. Depending on the exact details of the governance mechanism at play, this new assumption ranges from "bad" to "attrocious". One could very well make the argument that Sovereign Rollups with a social consensus mechanism driven by an upgradeable Rollup bridge do not actually scale Ethereum very well at all.
If you subscribe to this train of thought, the only "correct" way to scale Ethereum via Sovereign Rollups is through the concept of the Enshrined Rollup bridge. In an Enshrined Rollup bridge, the state transition function is immutably hard-wired into the bridge. Because Ethereum social consensus can modify the "immutable" state, this is essentially an upgradeable Rollup bridge that shares the same security assumption as Ethereum itself.
Enshrined Rollup bridges are like any other Rollup bridges, meaning the Sovereign Rollup on the other side still has its own social consensus mechanism and can choose to break away from Ethereum if it really wants to. A decision to break away would essentially be signalling that the Sovereign Rollup no longer feels that Ethereum is a good steward of the network, highlighting the importance of effective governance.
I'm a strong believer that effective governance is not only worthwhile but critical in the success of a blockchain system. A well-designed governance mechanism can quite possibly be more secure than Ethereum itself (in the sense governance would only ever make net-positive decisions). This is the perspective that would make upgradeable Rollup bridges a viable scaling mechanism and one that I hold very strongly.
[1] Referring to the state as the "memory" of a system is a clear oversimplification but it's surprisingly difficult to communicate the concept of state concisely. I suspect most of the readers of this post will already have an intuitive understanding of this concept so I didn't feel much of a need to elaborate further. If you have a one-paragraph explanation of "state" that I could use in future posts meant for a broader audience, I'd love to hear about it.
[2] Ordering does not always determine final machine state, though this tends to be true for most useful machines. Finding places where ordering does not impact machine state is the key to blockchain parallelization mechanisms.
[3] I say "meaningful" here because most consensus mechanisms are subject to short-term input reorganizations. Consensus mechanisms are typically constructed to avoid long-term reorganizations that would make it impossible for someone to make assumptions about the "finality" of some state.
[4] Most blockchains today generally assume that people care about the inputs enough to keep them around. Without the inputs there's no way to recompute the current state. As blockchains begin to focus on scaling data availability this model becomes less practical and chains are required to come up with explicit incentive structures to guarantee data availability.
[5] Blockchain consensus is a pain in the ass. Consensus mechanisms are difficult to design and maintain. As consensus mechanisms begin to operate at increasing larger scales this overhead becomes more overbearing. Even if relying on someone else's design, you're still required to bootstrap security which typically requires issuing some native asset and getting enough people to recognize that asset as valuable.
[6] Note that we are also purchasing data availability as a service, though ordering and data availability are generally bundled together. I expect that these two components will become increasingly detached as one can always order hashes of data on one system and store the preimages to those hashes on another.
[7] Many other components of the blockchain stack are undergoing a similar "productization". Block producers are the other obvious area for disruption because they're so annoying to run and because they carry regulatory risk. This is essentially the defining feature of the current era of Modular Blockchains™.
[8] Celestia then clearly competes with Ethereum in Ethereum's capacity of acting as a provider of ordering and data availability. I feel this competition has generally been beneficial in highlighting the existence of this capacity and in pushing Ethereum towards EIPs like EIP-4844 which expand this capacity. That said, Celestia is certainly challenging Ethereum's value proposition.
[9] The genesis state can also be modified but this would cause so many problems that it's not really done in practice. You'd end up recomputing the entire chain state which impacts so many things that even a minor change to the genesis state creates two extremely incompatible chains. I'd be surprised if this were ever done in the context of a long-lived blockchain.
[10] Forks like this can also happen by accident when there's a bug in client software. Usually this happens when there are two or more clients with incompatible state transition functions. Client diversity is an important defense against these sorts of issues because diverse clients will actually catch the bug rather than the bug silently becoming reality.
[11] I refer to "significant groups" rather abstractly because the exact nature of what's required for a group to be successful in following a fork is hard to define. Again, social consensus is a power game with complex rules that differ from system to system. You can generally assume that these "significant" means "significantly powerful" within the rules of the game.
[12] Coke is a great example because the Coca-Cola Company famously tried (and failed) to introduce New Coke in the 1980s. Social consensus decided that New Coke was sufficiently Not The Real Coke that it couldn't carry the Coke Name. Clearly the move to high fructose corn syrup was acceptable enough that the Name transferred to the formula that we know today.
[13] Note that there are often also assumptions on the ability for a user to execute the state transition function of the other chain. This is true with both ZK and Optimistic designs. In the Optimistic case, we assume that some honest user is able to execute the state transition function and can therefore act as a guardian if necessary (so executability is required for safety). In the ZK case, this assumption is weakened because of the need for explicit proofs of correctness but executability is still required for liveness properties.
[14] Although the bridge may not be able to directly influence the value of native assets in the same way it can influence the value of bridged assets, there is always some indirect relationship. For instance, the value of a native asset may be derived heavily from its relationship to bridged assets like in the case of a token for a decentralized exchange. A Rollup bridge would then also carry additional weight in the social consensus process in its ability to impact the value of these sort of tokens.