pull down to refresh
21 sats \ 0 replies \ @BlokchainB 23 Oct 2023
Wow this was fantastic! Thank you for this
reply
21 sats \ 0 replies \ @lightwalker 23 Oct 2023
Clear explanation. Good job
reply
0 sats \ 0 replies \ @dieselbaby 24 Oct 2023
Ah - Tyler...you're a Taproot Wizard, I see. I'm a big fan of Eric and Udi and by extension, the rest of y'all, I assume if you're a Wizard then you're probably someone I'm likely to get along with.
BTW, this is awesome stuff. I actually did understand exactly what was implied within your paper (which I have to say, was written in a very accessible manner for those who might not be sufficiently "tech-savvy" when it comes to some of the intricacies of stuff like solidity/EVM and the differences between this approach and what they are able to do over there on Ethereum. I sent it to a buddy who is way less nerdy than myself and he was able to grasp most of it, with only a few questions for me at the end of his reading it.
The ability for BitVM to verify ZK proofs is to me, the most important aspect of all of this. Obviously, the other stuff is quite cool - verification of other programs, I see this being great for the mentioned bridging features as you said in the paper but for other potential implementations that haven't even been fully thought-out yet, especially once ZKs can get brought into the mix, it'll unlock a litany of fun things that Bitcoin sorely needs, IMHO.
I also fully agree on the idea that Bitcoin will inevitably (sooner rather than later) need a ZK rollup. I hope that it happens, so badly. Lightning has a lot of issues, many of which are pretty fundamental and bringing limitations to it's capacity to scale properly, and they are so fundamental and close to the core of the design that trying to fix them all would provably be a wasted effort. With ZK we don't sacrifice the speed nor scalability, while relying upon the underlying strength of the main chain, it's win-win. It'll be the scaling that we deserve.
Anyway I have so much to say here but I gotta go pick up my food before this place closes, I'll edit this post if I can when I get back. Much love!
reply
0 sats \ 2 replies \ @_b_o_n_e_s_ 24 Oct 2023
nice work. thank you. the papers abstract talks about optimistic rollups, are they different from zk rollups?
reply
10 sats \ 1 reply \ @twhittle OP 24 Oct 2023
Yes, optimistic rollups operate differently from zk rollups.
If we start with the similarities, both optimistic and zk rollups:
- execute transactions "off-chain" (i.e. not on the L1)
- post transaction data back to the main chain
The difference comes in when we consider how they verify that a transaction on the rollup was valid.
Optimistic rollups assume all transactions are valid (hence "optimistic"). They rely on actors searching for invalid transactions in the transaction data that is posted back to the main chain. If an invalid tx is found, whoever found it can post a "fraud proof" that demonstrates it is invalid. If their fraud proof is successful, then the validator that included the invalid tx gets slashed.
Zk rollups operate differently. They rely on zero-knowledge proving systems to ensure that transactions on the rollup are valid. Through some cryptography wizardry, zk proving systems produce a "proof" to go along with each tx that shows it was executed correctly. Given the start state, the end state, and a proof, a verifier can validate that each tx was executed correctly.
So, the big difference is that zk rollups verify every transaction on the rollup whereas optimistic rollups only verify transactions when a fraud proof is submitted.
If you want to dive more into these two topics, I recommend Ethereum's developer docs on each:
- https://ethereum.org/en/developers/docs/scaling/optimistic-rollups
- https://ethereum.org/en/developers/docs/scaling/zk-rollups/
reply
0 sats \ 0 replies \ @om 24 Oct 2023
Just a minor point though:
reply