Part 2: Blockchain Scaling | Side Chains, Plasma, and State Channels
Notley Research | Blockchains and Crypto
To become an effective global payment system, a blockchain network must at least compete with current products on the market. Sadly, with Bitcoin and Ethereum currently capped at an average of 7 and 15 transactions per second (TPS) – compared to Visa and Mastercard’s 1,700 and 2,150 – its clear blockchains are still a long way away from achieving this goal. As such, this week, we’ll dive into Part Two of what’s proven to be blockchain’s “kryptonite” to date: Scalability.
Please note, this article is Part Two of my series on blockchain scaling. If you missed Part One but are familiar with Data Availability and the Blockchain Trilemma, you can read on. If not, I highly recommend reading through Part One before tackling this lesson.
In Part One of this series, we discussed why blockchain scaling is important, why it’s proven difficult, and some of the on-chain methods developers use to scale blockchains. This week, we will take that a step further and dive into off-chain scaling mechanisms – often called Layer 2’s.
Off-Chain Scaling
Off-chain scaling attempts to solve the blockchain trilemma by passing transaction processing or data storage to secure, off-chain computing systems. These systems, known as Layer 2’s (L2), are meant to scale transaction throughput and reduce the overall burden of computation on the main chain. Furthermore, they aim to do so in a manner that does not compromise decentralization or security. Let’s look at an example:
Imagine the main chain (Ethereum or somethig similar) as our traditional banking system and an L2 as our credit card payment rails. Within our traditional banking system, it is incredibly inefficient to use a real bank transfer every time we purchase something. Why? The settlement for that transaction is slow and expensive because it aims to be as secure as possible. That security is great, but it simply isn’t that relevant when you’re trying to buy a burrito from Chipotle.
Instead, buying your burrito with a credit card makes much more sense. Your credit card effectively allows the bank to track all your transactions throughout a certain period and then settle all those transactions at once, at the end of the period. This process allows you to purchase things instantly (good for the consumer), and Chipotle can feel comfortable with giving you a burrito because it knows your credit card is backed by the security of our banking system (good for the merchant). In other words, the credit card rails increase our banking system's transaction throughput without a significant compromise to the system's security.
Layer 2’s work in the same manner as our credit cards. They effectively aggregate transactions through a quick, cheap interface and then push those batched transactions to the main chain for transaction finality and settlement. Several different types of Layer 2’s have been proposed, including:
Side Chains and Plasma
State Channels
Rollups
Data Availability Layers
This week, we’ll run through Plasma and State Channels. Next week, we’ll get into Rollups and Data Availability Layers. With that said, let’s dive into side chains and Plasma!
Side Chains
One of the most straightforward blockchain scaling solutions is a side chain. A side chain is exactly what it sounds like – a completely separate blockchain built to be easily compatible with its main chain. Side chains have their own consensus mechanisms, their own node networks, and their own transaction processing power. Furthermore, because side chains are meant solely to help scale the main chain, they can make different tradeoffs in blockchain structure, prioritizing certain aspects over others. For instance, a side chain could be specifically designed to facilitate quick, cheap token swaps (like trading a stock) or to support the activities of an on-chain video game. The key point worth mentioning is that side chains are inherently customizable and can be built to function in a variety of ways. Confused? Maybe an analogy will help.
A good way to understand the relationship between the main chain and side chains is through an analogy to the United States of America and each state. Within the US, each state has its geographic strengths and population. As a result, one state, say Kansas, may have the resources to build a strong agricultural economy while lacking the resources to build a strong energy economy. Another state, say Texas, may have the resources to build a strong energy economy but may be lacking in the financial sector. Finally, a third state, say New York, may have a robust financial sector but no ability to grow food.
Because these states are all part of the greater United States, they can focus on what they do best and rely on other states to supplement their weaknesses. Side chains are very similar. One chain may focus on token trading, one may focus on data storage, and one may focus on NFTs. These specializations allow each chain to be more efficient while still providing the end-user (who can seamlessly use any chain) with any functionalities they may want.
In short, side chains aim to solve the blockchain scaling issue through specialization and “globalization.” Sadly, as with any technology, side chains have their drawbacks. Blockchain networks are, by design, disconnected from the outside world. This design helps minimize the chain’s potential attack vectors, but it also makes it difficult to move information in and out of a chain. As a result, side chain networks have to rely on specialized third parties, known as “bridges,” to communicate with the main chain and with each other. Bridges have different methods of operation, but when given the task of moving an asset from one chain to another, most:
Have smart contracts set up on each chain and some form of communication between each contract. This communication could be fully centralized, rely on oracles, or utilize other methods.
Users “deposit” the asset they wish to transfer into the smart contract on Chain One.
The smart contract locks said asset in “escrow” on Chain One and tells the smart contract on Chain Two to mint an equivalent “voucher” token that represents the original asset 1-to-1.
The voucher can be redeemed to the contract on Chain Two at any point, which then unlocks the original asset on Chain One. This allows it to hold 1-to-1 parity with the original asset due to the ease of arbitrage if it loses its peg.
Bridges are a solution, but as you may have noticed, they also introduce new problems, weaknesses, and security issues. First, they take on the security of the “weakest link” in the network. For example, imagine we have a side-chain network, and we would like to transfer ETH from Chain One (with a security rating of 95/100) to Chain Two (with a security rating of 40/100):
To do so, we would deposit the ETH into a smart contract on Chain One and receive an asset on Chain Two, say bETH, which represents ETH 1-to-1. Now let’s imagine an attacker wanted to steal our ETH. They have two options: They could attempt stealing it from the secure main chain or the far less secure side chain. As you might imagine, there is a high probability they will choose the easier option and target your vouchers on Chain Two. If they successfully break the security of the weaker chain, they can get a hold of your vouchers, redeem them on Chain one, and — Voilà; your ETH is gone.
Please note, blockchain security ratings do NOT exist — I just used them in this example to make the explaination clearer.
This is further accentuated by the fact that security in side-chain networks is somewhat of a zero-sum game. If we assume there are a limited number of potential nodes at any given point, a node securing one chain means one less node is available to secure other chains. In other words, an increase in the overall size of the side-chain network actually decreases the potential security of every chain in the network. Furthermore, bridges also provide a new and often far more accessible attack vector for malicious actors. Which do you think is easier to hack: a smart contract (basically a piece of code) or a fully operational blockchain? Hint, it’s the smart contract. This post from Vitalik details the issues with cross-chain bridges and side-chain networks.
Long story short, relying on basic side-chains as a scaling mechanism is likely not ideal. I highlight likely because even with these flaws, there are still several projects and ETH competitors exploring side chain networks. These projects are focused on ideas such as generalized consensus, built-in blockchain communication protocols (bridges), and more. See Avalanche’s subnets, Polkadot’s parachains, and Cosmos’s IBC-enabled blockchain SDK.1
With that frame in place, let’s get into Plasma.
Plasma Chains
Plasma Chains are simply side chains with one additional feature – they regularly commit transaction history to the main chain through “checkpoints.” These checkpoints occur at consistent intervals and allow the plasma chain to inherit a large portion of the main chain’s security. Importantly, plasma chains communicate checkpoints to the main chain through special smart contracts known as Root Contracts. The technical details of root contracts aren’t that important – just know they are standardized, secure methods of transferring information or assets from the main chain to a plasma chain. Guess what time it is? Example time!
Imagine we have a plasma chain that commits checkpoints to the ETH main chain every ten blocks. This means every ten blocks, the plasma chain sends a message to the main chain saying, “Here is the balance of every Plasma-chain user.” This message lets the main chain keep track of who should own what without burdening it with the transaction processing those users require. Worth noting, users can always withdraw their assets from the plasma chain based on the account balances reflected in the most recent checkpoint.
Now let’s imagine the plasma chain was compromised and assets were stolen. In a standard side chain, those assets are irretrievable. In a Plasma chain, a user could revert to the checkpoints sent to the main chain and request to pull their capital. Regardless of the hack that occurred, the main chain would see the user had capital at the last checkpoint, and it would return the stolen assets to the user.
Said simply, the checkpoints committed by plasma chains give users a “back door” to exit the chain in case something happens. Now, if you’ve been paying attention, you likely realize this structure still isn’t perfect. Why?
First, using the main chain as a source of truth leads to significant delays in transaction finality. This is because no transaction on the plasma chain is truly finalized until it has been committed into the main chain through a checkpoint. Second, the system relies on the assumption that the checkpoints are both valid and tamperproof. As you now know, this isn’t an assumption we can make. So what do we do? Enter fraud proofs.
Fraud Proofs
We discussed fraud proofs briefly last week, but we’ll cover them in more detail this week. Fraud proofs are relevant to many scaling solutions, including sharding, plasma, rollups, and data availability layers. In other words, you may want to pay attention! Fraud-proof secured systems operate under the “innocent until proven guilty” premise and assume all actors are default honest. This assumption allows for increased computational efficiency when it holds true. Sadly, not all actors are honest. Now what?
Luckily, these systems implement incentives for a third party, known as searchers, to monitor things and ensure everyone follows the rules. When a searcher catches a bad actor, the searcher can publish a proof to the network, showing a rule was broken. This is essentially a little “red flag” that alerts the network something malicious may have occurred. When this happens, the network diverts some of its computational power toward identifying the potential issue. If it finds a malicious action, the network can fix the issue,2 and the proof publisher receives a reward for raising the proverbial flag. On the other hand, if something malicious did not occur, the network does nothing, and the proof publisher is punished for wasting the network’s resources.
This system is effective for a couple of reasons. First, searcher incentives are an open market in which anyone can participate. Since you, your mom, or anyone else can profit from participating in the system, it’s improbable every searcher would be malicious. What’s a lot more likely is, at minimum, one profit-motivated searcher exists, ready to flag broken rules. Second, because searchers are punished for false flags, there is a strong incentive against spamming the network by simply flagging every possible issue.
Overall, this system has proven relatively effective over the past several years. Of course, fraud proofs aren’t perfect, but their ease of implementation has led to them being used across a variety of scaling solutions. With that understanding, let’s summarize what we’ve discussed so far.
One potential method of scaling blockchains is creating a network of application-specific chains, all of which communicate with each other through bridges. This approach helps increase transaction throughput, but it’s not without drawbacks. Namely, security in these systems is inversely correlated to the size of the system – This is unacceptable. To solve this, Vitalik and Joseph Poon proposed Plasma, a type of side chain that attempts to inherit the security of its main chain (instead of taking it away). Plasma chains achieve this through regularly “posting” their transaction history to the main chain and then using said checkpoint on the main chain as the source of truth to show who holds what assets. This means if the plasma chain is somehow compromised, users can use the main chain as a “back door” of sorts to retrieve their assets. Finally, incentivized parties known as searchers act as “hall monitors” to ensure everyone in the plasma system is working honestly. Some consequences of this system are summarized below.
Plasma chain networks could theoretically have transaction throughput orders of magnitude greater than what exists today by simply adding in new chains once the network sees congestion.
Attackers are much less likely to target plasma chains in an attack. This is because even if they are successful, it's highly likely users will revert to the main chain and recover their assets.
Plasma chains have significantly worse transaction finality than other scaling solutions or even their main chain. This is a result of the checkpoint system and the time needed for searchers to deem a checkpoint legitimate.
If you’re interested in learning more about some of the actual implementations of Plasma, I recommend you start here.
All in all, plasma chains offer a potential solution to the Blockchain Trilemma, but they simply aren’t as efficient as other scaling solutions. As such, outside of Polygon’s Plasma implementation, the industry is largely moving away from plasma chains. With that out of the way, let’s take a look at the next scaling solution on our plate: State Channels.
State Channels
State channels first came to prominence following Joseph Poon’s 2016 whitepaper, The Bitcoin Lightning Network. Poon recognized early on that if Bitcoin were ever to achieve its goal of powering the global economy, it would need payment channels with transaction throughput several orders of magnitude greater than what existed at the time. As a result, he began playing with some of the basic smart contract functionality within Bitcoin’s codebase and, for once, came across a legitimately feasible solution (at least for Bitcoin). Before we get into it, I’d like to re-define a couple of items:
Wallet: A blockchain user’s “account” on-chain. A user's wallet holds their crypto, allows them to receive and transfer crypto, and allows them to interact with blockchain-based applications.
Smart Contract: A deterministic piece of code that lives on a blockchain. Smart contracts are activated by pre-determined conditions, and once activated, they perform actions based on those conditions.
Multi-signature Wallets (multi-sigs): Customizable smart contract “wallets” controlled by two or more users. You can basically think of these as shared wallets that require approval from one, multiple, or all of the users before a transaction can occur.3
With that out of the way, let’s get to it – What is a state channel? A state channel is simply an agreement between two parties to make transactions off-chain and settle those transactions at some later date. State channels are implemented through two of two multi-sigs that, as the name suggests, require the approval of both parties before a transaction can occur. Notably, state channels can facilitate practically infinite off-chain transactions between the two parties while only requiring a total of two on-chain transactions: the creation of the channel and the settlement (or closure) of the channel. Furthermore, state channels use a specific type of transaction to ensure these interactions occur in a trustless manner – but we’ll get into that in a second. First, let’s look at an example.
Imagine an expensive blockchain network that costs $100 per transaction. This considerable cost is frustrating to Alice and Bob, who enjoy betting on sports games and settling their bets in crypto. Alice and Bob plan to make 1,000 bets over the next two years, but they are obviously unwilling to pay $100,000 to do so. What can Alice and Bob do to get around these exorbinant fees? They can use a state channel!
To do so, Alice and Bob would each send $10,000 to a state channel contract, thus initiating the channel (this is the first on-chain transaction). At that point, the channel holds $20K, Alice and Bob have a claim to their original $10K, and each gambler can initiate transactions to adjust that claim. Let’s imagine in their first bet, Alice wins $1,000. To receive payment, she would initiate a transaction transferring $1,000 of Bob’s claim to her claim. Assuming Bob accepts the transaction, the claim will be adjusted, leaving Alice with $11K and Bob with $9K. Since this happened within the channel, no on-chain transaction is needed. Our gamblers can now repeat this process 999 times, with zero transaction fees. At the end of their gambling escapade, Bob is left with $5K and Alice with $15K. At this point, either Alice or Bob can decide to close the channel, initiating the second on-chain transaction and paying out the final balances to each party. As a result of this process, Alice and Bob made their 1,000 crypto-settled bets while only paying $200 in transaction fees instead of $100,000.
Now that you (hopefully) understand the basic idea behind state channels, let’s look into their implementation. To create a state channel, Alice and Bob will each need to launch a node. Nodes are required for state channel operation because they can perform off-chain computation and allow users to sign transactions with their private key. Once their nodes are up and running, Alice and Bob will use their keys to create a 2-of-2 multi-sig that will host their channel. At this point:
Each party deposits to the newly created contract. The deposit removes capital from their on-chain “account” and adds it to their channel “account.”
Each party cosigns an initial “commitment transaction” and saves it in local memory (instead of posting it to the chain). The “commitment” represents each party’s claim on the assets within the channel. When the “commitment” is eventually posted to the chain, it closes the channel and allows each owner to claim their respective assets.
At the channel’s genesis, the “commitment” represents each party’s original capital deposited. For instance, if Bob deposits $10 and Alice deposits $90, the commitment will reflect those two balances and payout in that ratio when posted to the chain. Importantly, every transaction in the channel creates a new commitment to reflect the updated account balances within the channel. Each new commitment includes the channel’s old state, the channel’s new state, the signed transaction that triggered the state transition, and a unique nonce that helps the system “invalidate” the previous commitment.
Please note, I put invalidate in quotations because it’s a misnomer. What actually occurs is the creation of a new time-locked asymmetric revocable commitment that, in summary, gives the honest party a certain amount of time to react in the event its counterpart attempts to “redeem” an outdated commitment on-chain. Furthermore, if the honest party reacts in time, they can retrieve ALL of the capital in the channel, not just their capital. This provides a strong financial disincentive against posting old commitments. I tried several times to distill this process into non-technical terms without success. I’m not going to spend more time on it. If you’d like to learn more, I’d recommend scrolling down to the “Asymmetric Revocable Commitments” section of this post.
As a result of this system, users transacting in a state channel can transact without requiring trust between either party. Furthermore, state channels effectively boast instantaneous transaction finality 4 because:
It’s only feasible to post the most recent commitment to the chain.
That commitment is created in the process of finalizing a transaction.
Let’s review. State channels are smart contracts that allow two users to make feeless, instantaneous transactions between each other as long as the channel stays open. Users deposit capital into these channels from their on-chain account, meaning the assets within the channel inherit the security of the main chain. The assets within the channel can be redeemed by either user, at any time, by posting the current “commitment” (or state of the channel) to the main chain. Transactions within the channel require the approval of both parties, and each transaction creates a new “commitment.” Finally, creating a new commitment “invalidates” any previous commitments. Thus, it is only feasible to post the most recent commitment to the main chain.
Whew… We got through it. But as usual, we have another layer of complexity. Now we understand how a single state channel operates, we need to dive into state channel networks.
State Channel Networks
State channel networks are exactly what they sound like - a network of hundreds or thousands of intermingled state channels. Why is this necessary?
Well, we already know state channels allow for feeless, instantaneous transactions once created. The issue is, if only Alice and Bob can transact within their state channel, Alice will still be forced to make expensive, on-chain transactions when she wants to send money to Carl, Danny, or Elise. Of course, Alice could set up new state channels with Carl, Danny, and Elise, but that would require 1. Several on-chain transactions 2. Lots of complexity, and 3. Fragmented liquidity (meaning the capital in her channel with Danny couldn’t be used in the one with Elise). Luckily for Alice, Bob is quite the networker, and he already has active state channels with Carl, Danny, AND Elise! What a guy!
Now, if Alice trusts Bob, she could skirt around an expensive, on-chain transaction by sending Bob the money and requesting he forward it to Carl. But what if she didn’t have to trust Bob to ensure Carl got his money? And what if, through her connection with Bob and Bob’s connection with Carl, she could send money to all of Carl’s contacts, their contacts, and so on? This process is called routing, and it is the core idea behind a state channel network. So how does it work? We are going to get very technical here, so prepare yourself. If you’d prefer to skip to the easy analogy, skip to the TL;DR at the bottom of this section.
The first layer of complexity lies in Hashed TimeLock Contracts (HTLCs). HTLCs are the core technology that enables trustless payment routing through state channel networks because they guarantee that a payment either 1. reaches its intended recipient or 2. doesn’t go through at all. HTLCs rely on two key components: hashlocks and timelocks. A brief description of each can be found below.
Hashlocks: A hashlock is a mechanism that restricts the ability to “claim” a specific transaction until a special piece of information, called the pre-image, is publicly revealed. From a technical perspective, hashlocks operate by hashing the pre-image (see Cryptography 101 if you’re unfamiliar with hashing), releasing the hashed result, and hiding the original pre-image. In addition, hashlocks have the unique ability to be copied throughout several transactions, such that the same pre-image unlocks multiple hashlocks. I’ll get to why that’s important in a second.
Timelocks: A timelock is a more intuitive mechanism that limits how long a recipient has to claim a transaction. Furthermore, timelocks make it such that if the transaction is not claimed by the recipient within the set timeframe, the transaction reverts and returns capital to the original sender. From a technical perspective, timelocks are based on block production and can either be relative (the contract expires 100 blocks from now) or absolute (the contract expires at block number 101,023).
To explain how these features are combined to ensure trustless payment routing, we’re going to build a bizarre analogy.
Imagine you have $100, and you store it within a magic box. You want to send your $100 to your cousin, Bertha, but you’ll have to go through 10 other family members to get it to her. You don’t really trust your family, so you decide to put a lock on the box, and you make sure only Bertha has the key. You’re about to send the box through the network of your family, but then you realize it’s possible one family member could just hold the box and try and break it open. To solve this, you come up with two new ideas. The first is a rule that specifies if the box does not reach Bertha within a week of you sending it, the box teleports back to you. How does it do this? Magic! (or, in our case, complex cryptography).
The second rule is that every time the box is passed to a new family member, a copy of the box (with $1 instead of $100) is left with the previous box holder. For instance, when family member 2 passes the box to family member 3, 3 holds the original box and a copy of the box randomly appears in 2’s hand. When 3 passes the original box onto 4, 4 now holds the original box and 2 and 3 have now have copies of the box. Furthermore, because all these new boxes are copies of the original box, once Bertha opens the original box, all the copied boxes also open. As such, if Bertha gets to open the box in time, each family member will get to claim the $1 within their copy box.
As a result of this, the family members understand that 1. If they pass the box on to the next family member, they get a box that holds one dollar 2. If the box makes it to Bertha on time, everyone who participated in this process will get to claim the dollar held in their box and 3. If the box does not make it to Bertha in time, all the copies dissapear AND the original box will be teleported back to me. As a result, every family member has an incentive to ensure this process goes smoothly.
Now imagine instead of a box, a key, family members, and magic, we have an HTLC, a pre-image, a network of state channels, and intensive cryptography.
I apologize; I know that was poorly done. Hopefully, you followed along at least a little…
Effectively, the transaction itself is in a little “box” that gets routed through state channels and can only be opened using the pre-image held by the final recipient. Through the routing process, the HTLC requires each node to keep the HTLC it received (and the value within it) and create a copy of the HTLC in the next channel on the route (by copying the hashlock and fronting their own capital to place within it). The node then sends the new, copied HTLC to the next node, and the process repeats. This occurs until a copy of the HTLC makes it to the final recipient or the timelock expires.
If it makes it to the recipient, the recipient reveals the pre-image, and all nodes can use said pre-image to open their respective HTLCs, rewarding them with their reimbursement, plus a small fee. On the other hand, if a copy never reaches the recipient, every hash lock expires, returning capital to every node that participated, including the original sender. In summary, HTLCs allow us to pass money through a network of participants without worrying about any participants stealing the money before it arrives at its destination.
The second layer of complexity lies in how state channel networks decide to route a payment. This utilizes a mix of a gossip network, which allows nodes to communicate with each other, and complex pathfinding algorithms utilizing graph theory. Long story short, when nodes gossip with each other, they can build a relatively robust “graph” of the network as a whole. Once this graph is built, nodes use pathfinding algorithms to scan these graphs and find the most efficient path through the network, taking into account available liquidity, the number of node touchpoints, and several other factors. For now, I’m going to leave it at that… I don’t want to get you a headache. If you’d like to learn more about HTLCs, gossip networks, or Pathfinding, I recommend starting with the core Lightning Network documentation.
TL;DR
State channel networks are kind of like a financially incentivized game of telephone where I tell my neighbor a secret, she tells it to her neighbor, and so on until it reaches the end of the circle. Everyone gets rewarded if the secret phrase makes it all the way to the end of the circle. Furthermore, in this game of telephone, the original message actually cannot be changed; it can only be “held hostage” by a game member. Finally, if the secret is held hostage for too long, everyone forgets they had a secret in the first place, and I can try passing the secret around again. As such, there is no real reason for anyone to hold the secret “hostage” because they have nothing to gain and their entire reward to lose.
If you were able to follow along with all of that, you might realize that state channels seem to solve the blockchain trilemma. How? Well, they can significantly increase transaction throughput without sacrificing the security or decentralization of the chain. No other scaling solution we’ve looked at offers that kind of guarantee. Sadly, there remains one issue with state channels; they are ideal for transfers of value but significantly less helpful regarding actual program computation. In other words, smart contracts, and all the applications built with them, are very, very difficult to implement in state channel networks. This has to do with the UTXO model they implement, but that is a topic for another day. People are working on generalized state channels to solve this issue, but I think it’s likely rollups will end up winning that race (we’ll get to rollups next week).
Wow, that was a lot…
Usually, I try to keep this stuff high level, but today, it just couldn’t be done. I hope you made it through, and I apologize for being unable to simplify the technical jargon this week. Next week, we’ll finish up blockchain scaling with a piece on Rollups and Data Availability Layers. Until then, feel free to check out the resources below for further learning on the topics discussed. See you then!
Relevant Resources
Side Chains vs Plasma vs Sharding
Plasma Whitepaper: Scalable Autonomous Smart Contracts
Plasma Channels (Ethereum Website)
Side Chain Networks
State Channels
Other
Limits to blockchain scalability
IBC stands for inter-blockchain communication. Cosmos took a different approach than most blockchains by building a software development kit (SDK) that allows developers to easily spin up new, customized blockchains. They did so by creating standardized consensus and security layers, while leaving the application layer open for complete customization. This early standardization makes all Cosmos-based chains inherently compatible, creating a large, interconnected network of chains.
Either by reverting transactions, refusing to accept a block, requesting a new checkpoint, or some other set of solutions.
Imagine you run an investment team with five people, and you’d like to ensure each investment requires the sign-off of at least 3 individuals. You could create a 3 of 5 multi-sig that allows all 5 users to propose investments but requires 3 of the users to sign the transaction before it can occur.
Technically, transactions in a state channel are not final until posted to the main chain. However, If only valid commitments can be posted to the chain, and all old commitments are immediately invalided following a new transaction, we are left with something that is equivalent to instant transaction finality.