waxwing on Nostr: I had a listen last night. Since it's a bit long for most I can summarize where these ...
I had a listen last night. Since it's a bit long for most I can summarize where these guys (Alpen Labs) stand as according to the presentation:
(Caveat though, a lot of this is pretty unclear to me, so this might not all be correct, but, anyway:)
Seems that the heart of what they're doing is (a) using BITVM2 to do a verification (of the "fraud check" type) on chain for cases of challenge and (b) using as many optimisations as they can find to allow a Groth16 verification to be as small as possible in computation, to fit into the prior BITVM2. One interesting datapoint from that: they currently claim that the on-chain footprint of such a challenge is about 450kB, so well within practical limits, albeit still substantially large.
To rewind a bit on some of that for anyone not very familiar: we're talking here about a model of "optimistic rollup": state is committed to the blockchain (here, using OP_RETURN), but all the complexities of off chain transactions, which mutate that state, occur elsewhere. You deposit in via an N of N multisig, do your business off chain in the rollup, and then withdrawals can be triggered. If a withdrawal is attempted which does not satisfy the rules, this BITVM2 based challenge protocol can be executed by anyone (as I understand it from https://bitvm.org/bitvm2.html ) and is no longer multi-round but "one-round" (or 2, whatever).
whilst the N of N is a red flag at first sight (systems that just do stuff offchain but ultimately rely on everyone agreeing in a multisig, can do anything; but they're less interesting because of the trust assumption), note that the challenge to fraud is permissionless, doesn't require cooperation of the "N".
.
Details here: https://www.alpenlabs.io/blog/introducing-the-strata-bridge
The part that's actually more fuzzy to me is the less technically sophisticated part: when someone wants to withdraw from "Strata" into bitcoin they actually do a transaction with some "operator" entity: they provably burn their strata funds, and the operator "fronts" them the money, sending it to them on the BTC chain. *Then* the operator does a claim transaction on BTC to recover the funds, and it's this transaction that can be "challenged" as per the above. I'm really fuzzy though about what level of trust is implied here; how "atomic" is the user's withdrawal in this framework?
I should mention that Groth16 is being used similarly to what halseth was doing with output-zero as per my recent post. The idea is that Groth16 is ideally compact in size (250bytes, fixed) but the actual ZKP calculation is done with a STARK whose verification is recursively bundled into that Groth16 proof.
#cryptography #bitcoin
(Caveat though, a lot of this is pretty unclear to me, so this might not all be correct, but, anyway:)
Seems that the heart of what they're doing is (a) using BITVM2 to do a verification (of the "fraud check" type) on chain for cases of challenge and (b) using as many optimisations as they can find to allow a Groth16 verification to be as small as possible in computation, to fit into the prior BITVM2. One interesting datapoint from that: they currently claim that the on-chain footprint of such a challenge is about 450kB, so well within practical limits, albeit still substantially large.
To rewind a bit on some of that for anyone not very familiar: we're talking here about a model of "optimistic rollup": state is committed to the blockchain (here, using OP_RETURN), but all the complexities of off chain transactions, which mutate that state, occur elsewhere. You deposit in via an N of N multisig, do your business off chain in the rollup, and then withdrawals can be triggered. If a withdrawal is attempted which does not satisfy the rules, this BITVM2 based challenge protocol can be executed by anyone (as I understand it from https://bitvm.org/bitvm2.html ) and is no longer multi-round but "one-round" (or 2, whatever).
whilst the N of N is a red flag at first sight (systems that just do stuff offchain but ultimately rely on everyone agreeing in a multisig, can do anything; but they're less interesting because of the trust assumption), note that the challenge to fraud is permissionless, doesn't require cooperation of the "N".
.
Details here: https://www.alpenlabs.io/blog/introducing-the-strata-bridge
The part that's actually more fuzzy to me is the less technically sophisticated part: when someone wants to withdraw from "Strata" into bitcoin they actually do a transaction with some "operator" entity: they provably burn their strata funds, and the operator "fronts" them the money, sending it to them on the BTC chain. *Then* the operator does a claim transaction on BTC to recover the funds, and it's this transaction that can be "challenged" as per the above. I'm really fuzzy though about what level of trust is implied here; how "atomic" is the user's withdrawal in this framework?
I should mention that Groth16 is being used similarly to what halseth was doing with output-zero as per my recent post. The idea is that Groth16 is ideally compact in size (250bytes, fixed) but the actual ZKP calculation is done with a STARK whose verification is recursively bundled into that Groth16 proof.
#cryptography #bitcoin
quoting nevent1q…fk5fSimanta Gautam joined Brink engineers to discuss SNARKS, ZK Rollups & BitVM2 in a Bitcoin context:
- Verifiable compute w/SNARKS
- 2-way pegs, bridges, BitVM, trust minimization
- Bitcoin's state machine
- Sovereign ZK rollups
- Use cases
https://brink.dev/blog/2025/02/23/eng-call-alpen-zkrollups/