@ -744,11 +744,11 @@ Another factor holding back block size limit increases is block propagation time
Proofs of the validity of the blockchain solve the IBD issue for blocks of arbitrary size by removing the requirement that full nodes download and execute every transaction in every block to sync up to the chain tip. Instead, a validity proof can be produced as of a given block height `n` that can be used to convince full nodes that 1) a copy of the UTXO set is derived from the heaviest valid chain as of block `n` and 2) that newly received blocks `n+1, n+2, etc` correctly build upon the heaviest valid chain. This means that full nodes only have to download a copy of the UTXO set as of block `n`, verify the proof of `n`, and execute transactions in blocks built on top of `n` up until the next proof, rather than execute all transactions in all blocks from genesis. Proofs can continue to be generated for each block or for batches of blocks to maintain fast IBD and sync times for full nodes.
This "proof-sync" technique may solve the IBD problem of large blocks, but it does not solve the mining centralization problems. Work still needs to be done to decrease the bandwidth costs and propogation times of increased Layer 1 transaction volume, for example by implementing or further optimizing protocols such as Compact Block Relay and Erlay that reduce bandwidth requirements even as transaction volume increases.[182, 183] And there's no getting around the requirement for storage of blockchain data, which increases as the size of the blockchain grows. Still, having one less problem to solve (the IBD problem) is a nice improvement. The best part is that no consensus rule changes are required to implement and start using proof-sync clients. As of the time of writing, Lukas George and Robin Linus have begun work on a proof-sync bitcoin client implementation written in Cairo called "Zerosync".[184]
This "proof-sync" technique may solve the IBD problem of large blocks, but it does not solve the mining centralization problems. Work still needs to be done to decrease the bandwidth costs and propogation times of increased Layer 1 transaction volume, for example by implementing or further optimizing protocols such as Compact Block Relay and Erlay that reduce bandwidth requirements even as transaction volume increases.[182, 183] And there's no getting around the requirement for storage of blockchain data, which increases as the size of the blockchain grows. Still, having one less problem to solve (the IBD problem) is a nice improvement. The best part is that no consensus rule changes are required to implement and start using proof-sync clients. As of the time of writing, there are two projects working on building a proof-sync bitcoin client implementation written in Cairo, one is called Khepri and the other is called Zerosync.[184, 185]
## Appendix F. Mitigating harm from compromised cryptographic proof protocols and toxic waste
One concern that is often brought up when discussing the idea of implementing cryptographic proofs for privacy on bitcoin is the possibility of unexpected inflation. If someone discovers this kind of vulnerability in the cryptography used for the privacy protocol, they can exploit the vulnerability to mint an arbitrary amount of BTC. Furthermore, because transactions using the privacy protocol are encrypted in some way, the inflation will be undetectable for some period of time. This concern stems from a fundamental tradeoff in the design of cryptocurrency privacy protocols based on cryptographic proofs: a cryptographic proof can be perfectly hiding, or perfectly binding, but not both.[185] This tradeoff means that the protocol designer must either allow the money supply to be inflated via counterfeit but preserve privacy if the cryptography is broken (perfectly hiding), or they preserve the money supply integrity but allow privacy to be broken (perfectly binding). Production implementations of encrypted transactions, including those covered in Appendix B, are typically designed to be perfectly hiding.
One concern that is often brought up when discussing the idea of implementing cryptographic proofs for privacy on bitcoin is the possibility of unexpected inflation. If someone discovers this kind of vulnerability in the cryptography used for the privacy protocol, they can exploit the vulnerability to mint an arbitrary amount of BTC. Furthermore, because transactions using the privacy protocol are encrypted in some way, the inflation will be undetectable for some period of time. This concern stems from a fundamental tradeoff in the design of cryptocurrency privacy protocols based on cryptographic proofs: a cryptographic proof can be perfectly hiding, or perfectly binding, but not both.[186] This tradeoff means that the protocol designer must either allow the money supply to be inflated via counterfeit but preserve privacy if the cryptography is broken (perfectly hiding), or they preserve the money supply integrity but allow privacy to be broken (perfectly binding). Production implementations of encrypted transactions, including those covered in Appendix B, are typically designed to be perfectly hiding.
The same risk exists when using computational proofs for transaction verification as opposed to transaction privacy, for example to verify unencrypted rollup transactions. If the cryptographic proof is broken, then anyone who exploits the vulnerability will be able to forge proofs withdraw assets from the rollup even if they do not have the private keys to the addresses that control those assets according to the rollup ledger. In this case, the forgery can be detected immediately, but there is still the potential for disastrous harm if L1 full nodes and miners do not react to prevent the forged proofs from being confirmed on L1.
@ -758,7 +758,7 @@ Some people may argue that building an encrypted validity rollup on bitcoin woul
So if you don't want to worry about being left holding worthless encrypted bitcoin because someone exploited an inflation vulnerability and withdrew the maximum available balance from the rollup, you can keep all of your bitcoin in a fully-auditable transparent bitcoin layer. If you are willing to risk keeping some spending bitcoin encrypted so you can transact with strong privacy but want to keep the rest of your bitcoin transparent so you don't put your savings at risk of undetectable inflation then you can do that too. And if you aren't worried about an inflation vulnerability at all, or find the privacy gains worth the risk, you can keep all of your bitcoins encrypted if you want to. The encrypted rollup gives you several options depending on your risk tolerance.
It's important to note here that undetectable inflation in encrypted protocols is _already possible_ because there are already encrypted protocols where the supply of encrypted bitcoin-denominated assets is at risk of an inflation vulnerability. For example, L-BTC on Liquid and renBTC on Aztec could both be unexpectedly and undetectably inflated if there was an inflation vulnerability that got exploited.[186, 78] The only relevant difference between these existing encrypted protocols and validity rollups for the purpose of this discussion is that with L-BTC and renBTC bitcoin users have to trust third parties with the custody of their satoshis while validity rollups are non-custodial by design. The outcome that would be achieved by someone who opposes the implementation of an encrypted validity rollup on bitcoin due to concerns about undetectable inflation would not be to prevent users from putting their bitcoin at risk of an inflation vulnerability, but to prevent users from doing so _in a non-custodial way_ and instead drive bitcoins into the control of trusted custodians — the law of unintended(?) consequences in action.[187]
It's important to note here that undetectable inflation in encrypted protocols is _already possible_ because there are already encrypted protocols where the supply of encrypted bitcoin-denominated assets is at risk of an inflation vulnerability. For example, L-BTC on Liquid and renBTC on Aztec could both be unexpectedly and undetectably inflated if there was an inflation vulnerability that got exploited.[187, 78] The only relevant difference between these existing encrypted protocols and validity rollups for the purpose of this discussion is that with L-BTC and renBTC bitcoin users have to trust third parties with the custody of their satoshis while validity rollups are non-custodial by design. The outcome that would be achieved by someone who opposes the implementation of an encrypted validity rollup on bitcoin due to concerns about undetectable inflation would not be to prevent users from putting their bitcoin at risk of an inflation vulnerability, but to prevent users from doing so _in a non-custodial way_ and instead drive bitcoins into the control of trusted custodians — the law of unintended(?) consequences in action.[188]
## References
@ -1128,13 +1128,15 @@ It's important to note here that undetectable inflation in encrypted protocols i
John Light
2 years ago
GitHub