@ -20,7 +20,7 @@ Contact the author: https://lightco.in/contact
- Section 4. Scaling improvements
- Section 5. Building validity rollups on bitcoin
- Section 6. The costs and risks of validity rollups
- Conclusion**(TODO)**
- Conclusion
- Appendix A. Comparing validity rollups to other protocols
- Appendix B. Comparing alternative cryptocurrency privacy techniques
- Appendix C. Increasing throughput with offchain data availability
@ -381,7 +381,7 @@ If someone were to implement support for validity rollups in bitcoin, they may a
Bitcoin was launched under the premise that miners are economically rational, self-interested profit maximizers, and that their profit-maximizing behavior will lead to the emergence of a well-operating peer-to-peer electronic cash system. This design has worked pretty well so far. Rumors of a double-spend attack (which turned out to be a non-event) resulted in swift financial retribution, cautioning miners not to ever deviate from the norm against intentionally re-organizing the blockchain for selfish gain.[96] Even the mere possibility of being able to pull off a so-called "51% attack" has led miners to redistribute their hashpower away from dominant mining pools.[97]
With that said, it is normal and expected that miners operate within the norms of bitcoin to maximimize their profit. Putting only transactions that pay the highest fees into their blocks, to the exclusion of lower-fee-paying transactions, for example, is tolerated and even celebrated.[98, 98] However in the past few years we have seen new miner behavior emerge, particularly in blockchains that support financial contracts such as borrowing and trading. This behavior has come to be known as "non-fee-based miner extractable value" or "MEV" for short.[100] MEV encompasses a growing number of different types of value that miners can extract by ordering transactions in a block to their exclusive benefit (and generally at a cost to other blockchain users).
With that said, it is normal and expected that miners operate within the norms of bitcoin to maximimize their profit. Putting only transactions that pay the highest fees into their blocks, to the exclusion of lower-fee-paying transactions, for example, is tolerated and even celebrated.[98, 99] However in the past few years we have seen new miner behavior emerge, particularly in blockchains that support financial contracts such as borrowing and trading. This behavior has come to be known as "non-fee-based miner extractable value" or "MEV" for short.[100] MEV encompasses a growing number of different types of value that miners can extract by ordering transactions in a block to their exclusive benefit (and generally at a cost to other blockchain users).
One example is the "sandwich attack", a form of frontrunning that can be performed against users of onchain automated-market-maker-based algorithmic exchanges. It works like this: A miner observing the mempool sees Alice place a "market buy" order for Asset ABC on the AMMSwap exchange. The miner will place their own equal-sized market buy order for Asset ABC on AMMSwap, yielding the miner an average cost basis of X. The miner structures their block so that their market buy order is immediately before Alice's market buy order in the block. As a result, when Alice's market buy order executes she receives Asset ABC at a cost basis of X+1. In the same block, the miner then places an equal-sized AMMSwap market sell order for Asset ABC right after Alice's market buy order in the block, capturing the "+1" liquidity that Alice's buy order gave to Asset ABC. The end result: Alice paid more for Asset ABC than she otherwise would have, and the miner earned +1 profit risk-free.
@ -395,7 +395,9 @@ The bitcoin community could also decide to enable more expressive validity rollu
Several developers and researchers were asked about this while doing interviews for this report and the consensus is that MEV on bitcoin validity rollups may lead to an increase in L1 transaction fees due to the increased transactional volume created by MEV bots, but otherwise L1 users would not be affected by MEV. Those familiar with the matter pointed to the lack of negative effects of L2 rollups on L1 Ethereum users as evidence for why bitcoin L1 users would likely not be negatively effected by L2 rollups built on bitcoin either. Given that L2 rollups are a relatively recent phenomenon on Ethereum, however, more time and research is needed to better understand the interplay between MEV on L2 and consensus security and incentives on L1.
Researchers have been able to develop many solutions that prevent or minimize the negative effects of MEV. Some of these solutions are structural changes to consensus that impede the ability of block producers to order transactions in their favor.[101] Other techniques hide transaction information so that block producers and "searchers" are unable to see transactions that would be vulnerable to MEV.[102] Users who don't want to have their lunch eaten by MEV bots can and should demand that developers implement these MEV countermeasures in their rollups and rollup-based financial applications. If these countermeasures become widely implemented then MEV as a general concern could become a thing of the past.
Even if new forms of MEV are not enabled on L2, depending on how validity rollups are implemented on bitcoin, new forms of MEV could still be enabled on L1. If validity rollups are enabled on bitcoin using recursive covenants, then recursive covenants could be used to build new types of MEV-vulnerable protocols on L1. For example, the decentralized exchange protocol BitMatrix is a constant product market maker protocol built using recursive covenants.[101] BitMatrix was originally designed for the Liquid blockchain, which has support for recursive covenants but also supports confidential assets thus making BitMatrix trades resistant to MEV. Bitcoin does not support confidential assets on L1, which creates the possibility of MEV on a version of BitMatrix deployed to a recursive-covenant-enabled bitcoin L1. Users would be smart to move this activity to L2 protocols where protections against MEV can be implemented, but still, the fact that they will be able to generate new MEV opportunities on L1 should be taken into consideration.
Researchers have been able to develop many solutions that reduce and even prevent the negative effects of MEV. Some of these solutions are structural changes to consensus that impede the ability of block producers to order transactions in their favor.[101] Other techniques hide transaction information so that block producers and "searchers" are unable to see transactions that would be vulnerable to MEV.[102] Users who don't want to have their lunch eaten by MEV bots can and should demand that developers implement these MEV countermeasures in their rollups and rollup-based financial applications. If these countermeasures become widely implemented then MEV as a general concern could become a thing of the past.
@ -408,23 +410,29 @@ One example of an AIM smart contract is a "TxWithhold" contract. In a BitMEX Res
If a validity rollup on bitcoin supported expressive smart contracts, they could be used to instigate "re-org wars", where smart contracts battle each other to incentivize and dis-incentivize miners reorganizing the blockchain.[104, 105] This type of AIM attack was shown to be possible using a "HistoryRevision contract" on Ethereum L1.[106] It's unclear if such contracts deployed to L2 could have the same effect on L1, or whether it _would_ be possible but only under _certain conditions_ (e.g. heavy overlap of block producers on both layers). Even if such reorg contracts on L2 could have the same effect on L1, if they can both incentivize and dis-incentivize reorgs then perhaps they cancel each other out and there's no harm done. Again, this is an area where further research is needed.
**Majority-vulnerable contracts**
One category of smart contract whose positive uses have been discussed at length by researchers but whose potential for harm has arguably been under-explored is the "SPV bridge" (also referred to as a "hashrate escrow") and the similar category of "optimistic" smart contracts.[107, 108] SPV bridge and optimistic contracts are collectively referred to here as "majority-vulnerable contracts" because users of these contracts trust the majority of block producers (as measured by whatever Sybil-protection resource is used e.g. hashpower, stake, identities, etc) to not steal funds held in the contract. The obvious risk here is that majority-vulnerable contracts enable an AIM attack that could lead to users getting robbed by block producers. Perhaps of more concern is a more subtle risk: _the existence and use of majority-vulnerable contracts creates an incentive for block producers to collude to effectuate the theft, making majority-vulnerable contracts potentially harmful to the security of the blockchain itself_. By creating an incentive to collude to form a "dishonest" majority where no such incentive would otherwise exist, majority-vulnerable contracts could be considered to be directly undermining the otherwise honest, correct, incentive-compatible operation of Nakamoto consensus.
One category of smart contract whose positive uses have been discussed at length by researchers but whose potential for harm has arguably been under-explored is the "SPV bridge" (also referred to as a "hashrate escrow") and the similar category of "optimistic" smart contracts.[107, 108] SPV bridge and optimistic contracts are collectively referred to here as "majority-vulnerable contracts" because users of these contracts trust the majority of block producers (as measured by whatever Sybil-protection resource is used to guard entry to the block producer set e.g. hashpower, stake, identities, etc) to not steal funds held in the contract.
The obvious risk is that majority-vulnerable contracts enable an AIM attack that could lead to users getting robbed by block producers. Perhaps of more concern is a more subtle risk: _the existence and use of majority-vulnerable contracts creates an incentive for block producers to collude to effectuate the theft, making majority-vulnerable contracts potentially harmful to the security of the blockchain itself_. By creating an incentive to collude to form a "dishonest" majority where no such incentive would otherwise exist, majority-vulnerable contracts could be considered to be directly undermining the otherwise honest, correct, incentive-compatible operation of Nakamoto consensus.
Empirical observation has shown that block producers have not yet colluded to steal despite the existence of majority-vulnerable contracts, suggesting there is some other incentive or dis-incentive preventing them from stealing.[109] It's also possible that there's simply a tipping point that has yet to be reached and it's only a matter of time before the collusion and theft these contracts incentivize finally occurs. With sufficiently expressive smart contract capabilities, it would be possible to create an AIM contract that automatically allocates the proceeds of theft from a majority-vulnerable contract to block producers who participate in the attack, reducing risk and coordination costs and thereby potentially increasing the likelihood that the attack is attempted and succeeds. Since majority-vulnerable contracts have already been deployed to production, only time will tell whether or not they really are a threat to their host networks.
The existence of majority-vulnerable contracts on bitcoin L2 may not be such a problem for L1 bitcoin users if the majority-vulnerable contracts use a different set of block producers than L1 e.g. a hashrate escrow contract implemented in a validity rollup that uses a different set of miners to secure the hashrate escrow. However if the implementation path used to add support for validity rollups on bitcoin enables new types of majority-vulnerable contracts on L1, then the bitcoin community may want to consider whether the potential risk introduced by majority-vulnerable contracts is worth the benefit of this particular implementation path. For example, bitcoin developer has pointed out that recursive covenants could be use to build hashrate escrow contracts on bitcoin.[109] So if support for validity rollups is implemented on bitcoin using recursive covenants, then the bitcoin community will need to consider whether they also want to enable L1 hashrate escrow contracts as well.
Empirical observation has shown that block producers have not yet colluded to steal despite the existence of majority-vulnerable contracts, suggesting there is some other incentive or dis-incentive preventing them from stealing.[110] It's also possible that there's simply a tipping point that has yet to be reached and it's only a matter of time before the collusion and theft these contracts incentivize finally occurs. With sufficiently expressive smart contract capabilities, it would be possible to create an AIM contract that automatically allocates the proceeds of theft from a majority-vulnerable contract to block producers who participate in the attack, reducing risk and coordination costs and thereby potentially increasing the likelihood that the attack is attempted and succeeds. Since majority-vulnerable contracts have already been deployed to production, only time will tell whether or not they really are a threat to their host networks.
**Fully-automated totalitarianism**
Here we again reference the rollup designs from Section 5 that require the use of recursive covenants. The defining quality of a recursive covenant is that it not only defines the conditions under which a UTXO locked in the covenant script can be spent, but it also defines the type of script that the UTXO can be encumbered by after it is spent (hence the name "recursive" covenant). In theory, a recursive covenant can require a UTXO to be locked into the same type of restrictive script forever, no matter how many times the UTXO is spent.
Some commentators have cited the recursive restrictions enabled by recursive covenants as justification for pushing back on the implementation of covenants in bitcoin.[110, 111] They point out that this capability could be used by totalitarian governments to force bitcoin users in their jurisdictions to lock their satoshis into recursive covenants where the government has programmed in their control of the satoshis in perpetuity. While that would indeed be technically possible to implement with recursive covenants, that is only one way that such controls could be implemented.
Some commentators have cited the recursive restrictions enabled by recursive covenants as justification for pushing back on the implementation of covenants in bitcoin.[111, 112] They point out that this capability could be used by totalitarian governments to force bitcoin users in their jurisdictions to lock their satoshis into recursive covenants where the government has programmed in their control of the satoshis in perpetuity. While that would indeed be technically possible to implement with recursive covenants, that is only one way that such controls could be implemented.
It is currently possible for governments to implement restrictions on how the satoshis owned by their citizens can be transferred, and in a much more flexible way than recursive covenants allow, using a type of smart contract that has been standard in bitcoin for over a decade: multisig.[113] The basic idea is that the government would require satoshis owned by their citizens to be encumbered by a multisig script that requires a signature from both a government-controlled private keys and the actual owner's private key in order to transfer the satoshis to another address. Before the government co-signs the transaction, the computer that has control of the government's private key will check to make sure that the transaction is following a transfer policy that is defined offchain in a normal text file that is stored on the government's computer. If the transaction complies with this transfer policy, then the government computer will co-sign the transaction. If the transaction does not comply with the transfer policy (for example, by trying to transfer satoshis to an address that the government has not approved) then the government copmuter will not co-sign the transaction and the transaction will effectively be blocked. If the government ever wants to update their transfer policy to add or remove restrictions, then it's as simple as updating the offchain text file that defines the policy.
It is currently possible for governments to implement restrictions on how the satoshis owned by their citizens can be transferred, and in a much more flexible way than recursive covenants allow, using a type of smart contract that has been standard in bitcoin for over a decade: multisig.[112] The basic idea is that the government would require satoshis owned by their citizens to be encumbered by a multisig script that requires a signature from both a government-controlled private keys and the actual owner's private key in order to transfer the satoshis to another address. Before the government co-signs the transaction, the computer that has control of the government's private key will check to make sure that the transaction is following a transfer policy that is defined offchain in a normal text file that is stored on the government's computer. If the transaction complies with this transfer policy, then the government computer will co-sign the transaction. If the transaction does not comply with the transfer policy (for example, by trying to transfer satoshis to an address that the government has not approved) then the government copmuter will not co-sign the transaction and the transaction will effectively be blocked. If the government ever wants to update their transfer policy to add or remove restrictions, then it's as simple as updating the offchain text file that defines the policy.
A working example showing how transfer restrictions can be implemented using multisig is found in Blockstream AMP, a platform developed by the company Blockstream to support the managed issuance and transfer of assets on the Liquid blockchain.[114] Despite the Liquid blockchain already having support for recursive covenants, Blockstream still decided to implement transfer restrictions using multisig. Blockstream explains in their documentation that transfer restrictions implemented at the smart contract level are "very difficult to adapt to fast-moving regulations worldwide".[115] In contrast, "Blockstream AMP implements transfer restrictions through a simple multisig authorizer setup, providing [the user] with flexibility to adapt to shifting regulations."[ibid]
A working example showing how transfer restrictions can be implemented using multisig is found in Blockstream AMP, a platform developed by the company Blockstream to support the managed issuance and transfer of assets on the Liquid blockchain.[113] Despite the Liquid blockchain already having support for recursive covenants, Blockstream still decided to implement transfer restrictions using multisig. Blockstream explains in their documentation that transfer restrictions implemented at the smart contract level are "very difficult to adapt to fast-moving regulations worldwide".[114] In contrast, "Blockstream AMP implements transfer restrictions through a simple multisig authorizer setup, providing [the user] with flexibility to adapt to shifting regulations."[ibid]
Implementing spending restrictions offchain using multisig would enable the government to change the restrictions whenever they want and make the restrictions as complex as they want. If the government implemented the restrictions directly in a smart contract using a recursive covenant, then their restrictions would be constrained by the size limits and capabilities of bitcoin Script. Allowing for the possibility of changing the transfer restrictions, to mirror the inevitable changes in offchain government policy, would require additional script complexity. If support for recursive covenants was added to bitcoin, and a government wanted to implement totalitarian controls over how its citizens could transfer their satoshis, they would be more likely to implement such controls using multisig, not recursive covenants, due to the flexibility offered by offchain transfer policies.
Implementing spending restrictions offchain using multisig would enable the government to change the restrictions whenever they want and make the restrictions as complex as they want. If the government implemented the restrictions directly in a smart contract using a recursive covenant, then their restrictions would be constrained by the size limits and capabilities of bitcoin Script. Allowing for the possibility of changing the transfer restrictions, to mirror the inevitable changes in offchain government policy, would require additional script complexity.
Some people may argue that yes, while multisig may be more flexible, recursive covenants are scary because they could be used to lock BTC into the script forever. At least with today's multisig implementations, BTC could theoretically leave the multisig script. The possibility of locking BTC into a script forever is still not a new risk. Anthony Towns pointed out that proof-of-burn could be used to burn BTC and mint some amount of govt-BTC in an embedded consensus protocol (similar to how XCP was created on bitcoin) or in a dedicated Spacechain. Once burnt, the govt-BTC would never be able to be converted back into regular BTC, and would forever be locked into the government's transfer restrictions, however they are implemented.
If support for recursive covenants was added to bitcoin, and a government wanted to implement totalitarian controls over how its citizens could transfer their satoshis, they would be more likely to implement such controls using multisig, not recursive covenants, due to the flexibility offered by offchain transfer policies. In any case, the takeaway here is that, contrary to popular belief, from a practical standpoint recursive covenants do not introduce any new risks when it comes to government-enforced transfer restrictions.
The main takeaway here is that, contrary to popular belief, from a practical standpoint recursive covenants do not introduce any new risks when it comes to government-enforced transfer restrictions. Multisig is already being used to enable such transfer restrictions, and XCP-style proof-of-burn could be used to irreversibly lock BTC into such transfer restrictions. There may be legitimate, good reasons to oppose enabling recursive covenants on bitcoin; their ability to be used to implement transfer restrictions is not one of them.
### 6.5 Provoking authoritarians
While the very existence of bitcoin itself is a provocation toward authoritarians who seek to control how other people earn, save, and spend money, validity rollups could add whole new provocative dimensions to bitcoin.
@ -432,6 +440,12 @@ While the very existence of bitcoin itself is a provocation toward authoritarian
**Private payments**
Shielded transactions would enable peer-to-peer transactions that are nearly as private and untraceable as physical cash. In some cases, shielded transactions are potentially even more private and untraceable than physical cash, due to the possibility for remote, anonymous interactions online. This would give people under an authoritarian regime (in their government or in their home) the ability to earn and spend money privately, using a hidden wallet on a small computing device that either would not raise suspicion or could be concealed more easily than physical cash.
Governments have already begun cracking down on the usage of protocols that provide privacy protections to cryptoasset users. The governments of Japan and South Korea have effectively banned the trading of several specific cryptoassets that have implemented privacy protocols, such as DASH, XMR, and ZEC.[116, 117] Most recently, South Korean regulators have pressured exchanges to delist LTC after the Litecoin community implemented support for an opt-in Mimblewimble extension block protocol.[118] Curiously, although both bitcoin and Ethereum support opt-in privacy protocols with similar characteristics as DASH (in the case of bitcoin's coinjoin implementations) and ZEC (in the case of shielded protocols such as Aztec on Ethereum), both BTC and ETH remain available for trading in South Korea. Although BTC and ETH have escaped a ban in these jurisdictions despite supporting nearly identical privacy protocols as several of the banned cryptoassets, this luck may not last forever. If bitcoin were to implement support for validity rollups with strong privacy, for example, this may increase government scrutiny in these and other jurisdictions hostile to financial privacy.
An alternative to outright banning of the usage and trading of privacy-protecting cryptoassets is to continue to allow their usage but to apply regulatory pressure on exchanges, block producers, and other identifiably chokepoints to disallow interactions with opt-in privacy protocols. For example, when the United States Treasury Department added the Tornado Cash smart contract addresses to the Specially Designated Nationals list that identifies sanctioned individuals and organizations, it created a chilling effect prompting proactive over-compliance.[119] The exchange FTX reportedly began blocking deposits from addresses that had previously interacted with Tornado Cash, even going so far as to flag deposits associated with the (non-sanctioned) privacy protocol Aztec.[120, 121] Ethereum mining pool Ethermine even began to exclude Tornado Cash transactions from its blocks.[122]
The legal advocacy group Coin Center has published an anlysis questioning the legality of adding the Tornado Cash smart contract addresses to the SDN list.[123] Investment group Paradigm has published a separate analysis suggesting that there is no legal basis for Ethermine and other block producers to exclude Tornado Cash transactions in their blocks despite the sanctions.[124] Even if these analyses are correct, it would not mean other, stronger legal attacks could not be mounted against blockchain privacy protocols in the future, particularly in jurisdictions that have fewer free speech or rule of law protections than the United States. While attacks on users of privacy protocols may remain focused at the application layer, it's possible that some governments take their fight to the block producer and consensus layer. Bitcoin is designed to be resilient to these kinds of attacks, but nonetheless, Bitcoin developers and community members will have to decide if the risk of prompting such attacks is worth the advantages of adding strong privacy via validity rollups built on bitcoin.
**Financing a freer future**
Censorship-resistant smart contracts provide permissionless access to finance outside of authoritarian control, enabling entrepreneurs to raise capital for their businesses, activists to fund their movements, and oppressed minorities to circumvent the financial controls forced on them by the authoritarians in their lives. Control of finance is control of a huge part of the economy and people's livelihoods. Providing a neutral, programmable, globally accessible infrastructure for financial activity can give people under the thumb of authoritarians a way to build wealth and fund a freer future for themselves and their communities.
@ -467,9 +481,13 @@ STARK-based proof protocols, being "transparent" in nature, inherently do not re
See Appendix F for a look at how the risk of compromised cryptographic proofs and toxic waste could be mitigated to prevent harm to L1 bitcoin users.
---
## Conclusion
In this report, we described the history of validity rollups, how they work, and how they could be built on bitcoin. We described how, even in their simplest form, validity rollups can enable over 100 times more transaction throughput on bitcoin with no loss of ownership security for validity rollup users compared to the ownership security of transacting on bitcoin L1. Given that validity rollups are "trustless" by design, and could be implemented without introducing new risks or sacrificing any of bitcoin's core values or features, we believe the simplest possible implementations of validity rollups are a great fit for bitcoin.
### Appendix A. Comparing validity rollups to other protocols
Optionally, the implementation of validity rollups on bitcoin could also support the verification of more powerful validity proofs. This would enable new capabilities for bitcoin users, such as support for more expressive smart contracts and stronger privacy protocols. Depending on how support for these more powerful validity proofs is implemented, these new capabilities could be enabled at little to no increase in the cost of running an L1 full node. However, these new capabilities could also come with new risks, such as enabling new classes of AIM and MEV attacks, along with the possibility of provoking a crackdown on bitcoin by authoritarian governments who may be opposed to the strong privacy and censorship-resistant applications these protocols enable. Each of these new capabilities, and the risks that come with them, should be scrutinized on an individual basis, each with their own cost-benefit, risk-reward analysis, to determine whether or not they would be worth enabling on bitcoin, even in a validity rollup on L2. Some analysis of these issues was presented or referenced in this report, but should not be considered the last word on the subject.
## Appendix A. Comparing validity rollups to other protocols
Validity rollups are part of a decade-long history of protocols designed to improve the scalability and capabilities of blockchain-based digital asset and smart contracts.
John Light
2 years ago
GitHub