On "zk-rollups" applied to Bitcoin
ZK rollups make no sense in bitcoin because there is no "cheap calldata". all data is already ~~cheap~~ expensive calldata.
There could be an onchain zk verification that allows succinct signatures maybe, but never a rollup.
What happens is: you can have one UTXO that contains multiple balances on it and in each transaction you can recreate that UTXOs but alter its state using a zk to compress all internal transactions that took place.
The blockchain must be aware of all these new things, so it is in no way "L2".
And you must have an entity responsible for that UTXO and for conjuring the state changes and zk proofs.
But on bitcoin you also must keep the data necessary to rebuild the proofs somewhere else, I'm not sure how can the third party responsible for that UTXO ensure that happens.
I think such a construct is similar to a credit card corporation: one central party upon which everybody depends, zero interoperability with external entities, every vendor must have an account on each credit card company to be able to charge customers, therefore it is not clear that such a thing is more desirable than solutions that are truly open and interoperable like Lightning, which may have its defects but at least fosters a much better environment, bringing together different conflicting parties, custodians, anyone.
Published at
2024-01-14 14:55:28Event JSON
{
"id": "7cec63e064e3124ce8b57c274329a2d5c2b14b6958755f4745518560220fead2",
"pubkey": "3bf0c63fcb93463407af97a5e5ee64fa883d107ef9e558472c4eb9aaaefa459d",
"created_at": 1705240528,
"kind": 30023,
"tags": [
[
"d",
"162a7c34"
],
[
"title",
"On \"zk-rollups\" applied to Bitcoin"
],
[
"published_at",
"1599934860"
],
[
"t",
"bitcoin"
],
[
"t",
"ethereum"
]
],
"content": "\n# On \"zk-rollups\" applied to Bitcoin\n\nZK rollups make no sense in bitcoin because there is no \"cheap calldata\". all data is already ~~cheap~~ expensive calldata.\n\nThere could be an onchain zk verification that allows succinct signatures maybe, but never a rollup.\n\nWhat happens is: you can have one UTXO that contains multiple balances on it and in each transaction you can recreate that UTXOs but alter its state using a zk to compress all internal transactions that took place.\n\nThe blockchain must be aware of all these new things, so it is in no way \"L2\".\n\nAnd you must have an entity responsible for that UTXO and for conjuring the state changes and zk proofs.\n\nBut on bitcoin you also must keep the data necessary to rebuild the proofs somewhere else, I'm not sure how can the third party responsible for that UTXO ensure that happens.\n\nI think such a construct is similar to a credit card corporation: one central party upon which everybody depends, zero interoperability with external entities, every vendor must have an account on each credit card company to be able to charge customers, therefore it is not clear that such a thing is more desirable than solutions that are truly open and interoperable like Lightning, which may have its defects but at least fosters a much better environment, bringing together different conflicting parties, custodians, anyone.\n",
"sig": "1e1010683ecb2cdd901ed9e8207d5bdb50253ac9d07f0c8e6cdd5e21da440566ff352db2ad9a1157654b4ae0e79ecfb84e3bd5c3d6d0590abb4c4e4ed8bdbb63"
}