AdamISZ [ARCHIVE] on Nostr: š Original date posted:2022-11-02 š Original message:Hi John, Sorry for late ...
š
Original date posted:2022-11-02
š Original message:Hi John,
Sorry for late feedback. Very much appreciated the in depth report!
So, I second Greg's main question, which I've really been thinking about a bit myself since starting to research this area more: it feels like the Bitcoin protocol research community (or, uh, some of it) should focus in on this question of: what is the minimal functionality required onchain (via, presumably soft fork) that enables something close to general purpose offchain contracting that is provable, ideally in zero knowledge, but at the very least, succinctly, with onchain crypto operations. An example might be: if we had verification of bilinear pairings onchain, combined with maybe some covenant opcode, does it give us enough to do something like a rollup/sidechain model with full client side computation and very compact state update and verification onchain? (To be clear: just made that up! there is certainly no deep theory behind that particular combination .. although I did see this [1] thread on *optimistic* + covenant).
Is the actual answer to this something like Simplicity? (Above my paygrade to answer, that's for sure!)
Ideally you would want (don't laugh) for this to be the 'soft fork to end all soft forks' so that innovation could all be then in higher layers.
As to rollups themselves: centralization in the sequencer/publisher of state updates seems to be a really big issue that's somewhat brushed under the carpet. Depending on the model, there are cases where it actually is a theft risk (e.g. full control of an onchain smart contract), but there's significant censorship risk at the very least, as well as availability/uptime risk. At the extreme, Optimism has a 'security model' [3] that is frankly laughable (though, no doubt it's possible that will radically change) and for things like Arbitrum you have centralized sequencers, where the claim is that it will migrate to a more decentralized model; maybe, but that's a huge part of the challenge here, so while it's nice to see the sexy 'fast, cheap, scale' aspect straight away, I feel like those models haven't done the hard part yet. I also think these optimistic L2 models have a 'fake finality' issue from my perspective; the delay needed onchain is how long it takes to *really* confirm. (e.g.: rollups look cool compared to sidechains from the pov of 'instant' instead of confirmations on a chain, but that seems a bit sleight-of-hand-y).
It's notable to compare that with a payment-channels style L2 where decentralization and trustlessness are sine-qua-non and so the limitations are much more out in the open (e.g. the capacity tradeoff - while the 'instantness' is much more real perhaps, with the appropriate liveness caveat).
For the validity rollups, some of the above qualms don't apply, but afaik the concrete instantiations today still have this heavy sequencer/publisher centralization. Correct me if I'm wrong.
In any case, I do agree with a lot of people that some variant of this model (validity rollups) intuitively looks like a good choice, for the future, in comparison with other possible L2s that focus on *functionality* - with a mild censorship and centralization tradeoff perhaps.
And I'm maybe a bit heretical but I see no issue with using 1 of N security models for trusted setup here (note how it's probably different from base chain), so PLONK type stuff is just as, if not more, interesting than STARKS which aiui are pretty big and computationally heavy (sure, maybe that changes). So if that's true, it comes back to my first paragraph.
Cheers,
AdamISZ/waxwing
[1] https://nitter.it/salvatoshi/status/1537362661754683396
[3] https://community.optimism.io/docs/security-model/optimism-security-model/
Sent with Proton Mail secure email.
------- Original Message -------
On Wednesday, October 12th, 2022 at 16:40, John Light via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Wed, Oct 12, 2022, at 9:28 AM, Greg Sanders wrote:
>
> > Is there a one page cheat sheet of "asks" for transaction
> > introspection/OP_ZKP(?) and their uses both separately and together for
> > different rollup architectures?
>
>
> We do not have this yet. Trey Del Bonis wrote a more detailed technical post about how those components would be used in a validity rollup, which was cited in my report and can be found here:
> https://tr3y.io/articles/crypto/bitcoin-zk-rollups.html
>
> But it'll take more research and design work to suss out those details you asked for and put them into a nice cheatsheet. I like this idea though!
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
š Original message:Hi John,
Sorry for late feedback. Very much appreciated the in depth report!
So, I second Greg's main question, which I've really been thinking about a bit myself since starting to research this area more: it feels like the Bitcoin protocol research community (or, uh, some of it) should focus in on this question of: what is the minimal functionality required onchain (via, presumably soft fork) that enables something close to general purpose offchain contracting that is provable, ideally in zero knowledge, but at the very least, succinctly, with onchain crypto operations. An example might be: if we had verification of bilinear pairings onchain, combined with maybe some covenant opcode, does it give us enough to do something like a rollup/sidechain model with full client side computation and very compact state update and verification onchain? (To be clear: just made that up! there is certainly no deep theory behind that particular combination .. although I did see this [1] thread on *optimistic* + covenant).
Is the actual answer to this something like Simplicity? (Above my paygrade to answer, that's for sure!)
Ideally you would want (don't laugh) for this to be the 'soft fork to end all soft forks' so that innovation could all be then in higher layers.
As to rollups themselves: centralization in the sequencer/publisher of state updates seems to be a really big issue that's somewhat brushed under the carpet. Depending on the model, there are cases where it actually is a theft risk (e.g. full control of an onchain smart contract), but there's significant censorship risk at the very least, as well as availability/uptime risk. At the extreme, Optimism has a 'security model' [3] that is frankly laughable (though, no doubt it's possible that will radically change) and for things like Arbitrum you have centralized sequencers, where the claim is that it will migrate to a more decentralized model; maybe, but that's a huge part of the challenge here, so while it's nice to see the sexy 'fast, cheap, scale' aspect straight away, I feel like those models haven't done the hard part yet. I also think these optimistic L2 models have a 'fake finality' issue from my perspective; the delay needed onchain is how long it takes to *really* confirm. (e.g.: rollups look cool compared to sidechains from the pov of 'instant' instead of confirmations on a chain, but that seems a bit sleight-of-hand-y).
It's notable to compare that with a payment-channels style L2 where decentralization and trustlessness are sine-qua-non and so the limitations are much more out in the open (e.g. the capacity tradeoff - while the 'instantness' is much more real perhaps, with the appropriate liveness caveat).
For the validity rollups, some of the above qualms don't apply, but afaik the concrete instantiations today still have this heavy sequencer/publisher centralization. Correct me if I'm wrong.
In any case, I do agree with a lot of people that some variant of this model (validity rollups) intuitively looks like a good choice, for the future, in comparison with other possible L2s that focus on *functionality* - with a mild censorship and centralization tradeoff perhaps.
And I'm maybe a bit heretical but I see no issue with using 1 of N security models for trusted setup here (note how it's probably different from base chain), so PLONK type stuff is just as, if not more, interesting than STARKS which aiui are pretty big and computationally heavy (sure, maybe that changes). So if that's true, it comes back to my first paragraph.
Cheers,
AdamISZ/waxwing
[1] https://nitter.it/salvatoshi/status/1537362661754683396
[3] https://community.optimism.io/docs/security-model/optimism-security-model/
Sent with Proton Mail secure email.
------- Original Message -------
On Wednesday, October 12th, 2022 at 16:40, John Light via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Wed, Oct 12, 2022, at 9:28 AM, Greg Sanders wrote:
>
> > Is there a one page cheat sheet of "asks" for transaction
> > introspection/OP_ZKP(?) and their uses both separately and together for
> > different rollup architectures?
>
>
> We do not have this yet. Trey Del Bonis wrote a more detailed technical post about how those components would be used in a validity rollup, which was cited in my report and can be found here:
> https://tr3y.io/articles/crypto/bitcoin-zk-rollups.html
>
> But it'll take more research and design work to suss out those details you asked for and put them into a nice cheatsheet. I like this idea though!
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev