Episode 328 - ZK on Bitcoin with Alpen Labs

Transcript

[Music] welcome to zero knowledge I'm your host Anna Rose in this podcast we will be exploring the latest in zero knowledge research and the decentralized web as well as new paradigms that promise to change the way we interact and transact online this week tun and I chat with Sims scam and Liam Egan from alpen Labs we dive into the wild world of Bitcoin l2s and specifically how ZK could be used to incorporate strong connections between Bitcoin and new execution

environments we cover the general Bitcoin L2 landscape the emergence of bit VM the controversial concept of covenants the distinction between Bridge operators and sequencer in this model and how this differs from how these actors work in ethereum l2s we then dive into snark NATO the bridge that they have designed at alpen that would move BTC to and from a rollup we cover what is happening under the hood in snark NATO the ways in which the system offers round-based fraud games mixed with ZK where the da is stored the reasoning behind the security of such models and much more now before we kick off I want to let you know about ZK hack Montreal an event happening August 9th to 11th

2024 in you guessed it Montreal my hometown in case you don't know ZK hack is another project that I'm involved in it's a hub for ZK learning and as part of that we produce IRL ZK focused hackathons our next hackathon is ZK hack Montreal and it promises to be a very special one being our fourth edition of the series but the first that we host in North America applications are open we have some amazing judges and partners lined up keep an eye on ZK montreal. comom for more info about it it promises to be the ZK event of the summer it's happening just after SBC so you are able to do both if you want to so yeah hope

to see you there now Tanya will share a little bit about this week's sponsors galot is the first decentralized proving layer with galot users can generate and verify proofs using any proof system for any use case you can use one of the default provs from projects like Aztec Stark net and polygon or you can deploy your own galot is on a mission to dramatically decrease the cost of proving by aggregating proving workloads from across the industry to better utilize underlying Hardware while not compromising on performance galot is offering Priority Access to ZK podcast listeners so if you would like to start using high performance proving infrastructure for

free go register on gal.com and write ZK podcast in the note field of the registration form so thanks again galot Alo is a new layer one blockchain that achieves the programmability of ethereum the privacy of zcash and the scalability of a rollup driven by a mission for a truly secure internet Alo has interwoven zero knowledge proofs into every facet of their stack resulting in a vertically integrated layer one blockchain that's unparalleled in its approach Alo is ZK by Design dive into their programming language Leo and see what permissionless development looks like offering boundless opportunities for Developers and innovators to build ZK apps this is an invitation to be part of a

transformational ZK Journey dive deeper and discover more about Alo al.org and now here's our [Music] episode today tun and I are here with Sims gam and Liam Egan from Alpin Labs welcome to both of you thanks so much yeah thanks for having us hello tun hey excited to be back and to be talking about the intersection of Bitcoin and ZK which I think has been somewhat underappreciated on the show so hopefully we kind of kind of give it some love yeah I think the first time you mentioned this topic I asked you should we have someone on and you were

like um it's weird right now and I think this was like maybe like two years ago was it two years ago it was Whenever there were the first people who were like we're doing the starkware we're going to do Starks on bitcoin um okay I'm trying to for remember the name of that project I haven't seen anything in their GitHub in a long time so I'm not sure if it's still alive I see I see but now it seems like there are a few projects working on it who are also like coming from like the ZK space so this is going to be really exciting to dig in with you folks but let's kick off with a few intros Sims I'd like to hear a little bit about you and where the idea

for this ZK Bitcoin intersection even comes from maybe the foundation of Alpin yeah share a little bit about what what you've been up to yeah thanks Anna and uh it's great to be on here been listening and a fan of the Pod uh for several years now so nice it's great to talk about Bitcoin here as well because I think it's it is an underexplored topic uh as it relates to ZK and uh we think it's you know quite quite relevant uh particularly on bitcoin um so a little bit about my background uh I I actually don't come directly from like a cryptography background um but I feel like so much of what I've done over the last maybe decade or so has kind of led up to working on Alpin and um I'll share a little bit about that early on I even

got into computer science out of out of my interest in math and in number theory in particular so doing a lot of that even kind of tracking back to high school I found out about Bitcoin actually you know around then as well in 2011 and uh really went down the rabbit hole at that time since then uh what ended up going down MIT did math computer science but really got much more sucked into uh Ai and in particular sort of operating at this intersection between research and actually delivering uh a product and I think you know so much of that background actually translates really well into what we're doing so as an example um after college I started a company called synapse technology you know there we were building uh computer vision systems to

detect banol uh guns knives at x-ray uh checkpoints and uh you know that was actually a lot of that work was taking Cutting Edge neural network architectures uh around object detection adapting it for our use case so we were you know innovating on these multi-perspective deep learning methods But ultimately like actually Building Products that went out and uh you know we were securing checkpoints in several continents uh processing tens of millions of uh packages and so that was a you know amazing experience from 2016 to 2020 uh working on that and kind of doing a zero to one on on that startup and and getting it off the ground but kind of going back now after 2020 we

sold that company to paler spent a few years there and I was you know in in that period of time really following along with everything that was going on um in the blockchain space uh and in Bitcoin in particular as well with the scaling Wars happening in in 2016 and uh even like the defi white papers kind of coming out and turning into protocols so it really felt like um you know in 22 we we ended up me and three other co-founders that you know we'd met at MIT were sort of in this position of like what is the like really interesting you know 10year plus roadmap project here to work on that that like we think is like a fantastic business opportunity but also can create impact particularly in a global uh setting and the

blockchain frenzy was all over the place at that time and there's all sorts of applications we were seeing but there are still some like kernel of um you know how do we get really interesting you know scalable value ad from blockchains particularly around you know monetary aspects like payments uh censorship resisted payments private payments these kinds of uh applications that like really connected to us you know we just kind of weren't sure exactly what the opportunity was until we started exploring a bit more but ultimately we landed on you know Bitcoin as a way to uh really scale privacy expressivity and just you know overall kind of throughput scalability of the

system and we saw sort of this convergence of ZK research it Advanced so much over the last several years where you know things were very real and modular where you can take uh you know very generic ZK VMS uh that had you know very good kind of Prov side performance and uh really kind of leveraged these tools that were going from Theory into very much practice to be able to solve uh what seemed like a really important problem in Bitcoin that was totally under underappreciated at that time and so we sort of went down that rabbit hole until we we realize that like this kind of uh intersection and this kind of timing makes a lot of sense uh to build really interesting uh Technologies on

bitcoin so that's that's a little bit about uh you know the start of Alpin I kind of am curious so you mentioned your startup had been sold to paler were you kind of starting on This research out of paler like do they have a blockchain department they don't not as far as I am aware yeah they don't um yeah I mean it was really it was out of um we were talking a lot about like payments and like Financial technology actually that was like even before blockchain you know I was exploring that quite a bit because um I'm originally from Nepal and like over a quarter of our GDP is remittances and like I I you know actually have experience uh and see how clunky that experience is today you know with

capital controls like there it's also very hard to access you know basic kind of things like Netflix and so you know really saw the the vision for payment technology uh in this way then also realize like there's you know as we saw with all the usage in ethereum in in in the last cycle there like real limits into peer-to-peer consensus systems and you know the way to build this while preserving the the decentralization and security is is through modular execution layers in layer twos and that it felt like bit coin is just like you know the right place to build that and has been sort of designed for that kind of uh you know multi-staged uh modular uh

development Liam I want to hear a little bit about your background I actually know you through a number of collaborations that you've done with other folks in the ecosystem folks who've been on the show for example you worked with Ariel you worked with the folks at geometry tell us a little bit about yourself and what led you to work on alpen uh yeah I've been interested in sort of cryptocurrency I guess for a long time and started working on snarks kind of independently a few years ago wrote this this paper bulletproof Plus+ and uh started working at blockstream which is like a a Bitcoin company for I guess audience members

that may not know um I think you guys sort of mentioned this already but there there's like a strange separation between Bitcoin and the ZK Community although originally there was a connection with zcash yeah like that the first ZK project actually was very Bitcoin oriented but it seems like everything since has been more kind of from the ethereum or other L1 ecosystems the first like uh mention I guess would be like coin witness from Greg Maxwell talking about I guess I don't remember exactly what the details were but the kind kind of ideas that have since been developed and put into production of like compressing blockchains into a single proof of validity and and um privacy and yes yeah zcash for sure Fork

of Bitcoin and I guess that's actually kind of how I got into snarks was was privacy stuff um I was really like inspired by zcash and the ethos of of privacy and and how it like really worked in some sense and so yeah I I I I've done a few papers with Ariel um worked on like lookup arguments and folding schemes and and and lots of cool stuff but I I was always interested in in Bridging the Gap between CK and Bitcoin and now that seems more feasible than it it has in the past so nice I guess that's kind of how I ended up here I actually yeah I guess to your point I feel like there's like the early

2013 or 14 Bitcoin talk posts that you're kind of referring to what has sort of been the in your mind the the kind of like if you could give us stylized timeline of the the intersection of Bitcoin and ZK over you know from over the last decade because I think it's a very like nonlinear story and maybe it would having like the timeline just would give people some grounding as to the stuff we're going to talk about sure I won't claim I may I may not remember everything and my my reflection might not be perfectly accurate but uh yeah there was the coin witness uh stuff from from Greg and uh I think also maybe at the same time or

around then there was also discussion of like using ring signatures for privacy with Bitcoin I think Satoshi may have even participated in some of these discussions I don't remember but so zero coin uh came out in in 2013 and then the zero cash paper which I think basically had the the bones of modern kind of zcash and and other privacy Payment Systems came out in 2014 and just won the uh itle e test of time award in parallel with the sort of work that became zcash there was also Monero or what became what would become Monero using ring signatures and uh these were

I guess two applications of ZK to cryptocurrency really uh early on yeah so I guess the there was the beginning of kind of like a really virtual feedback loop of ZK research and ZK applications that up until all of this hadn't as far as I know really existed it was cool to to see it it really be applied like in the real world I guess in parallel with a lot of that there was also work at blockstream with uh Greg and Andrew and Peter wah who uh I I think the story goes that they approached um Dan Bonet with this problem of improving range proofs and

they they took this this work of bule and uh on inner product arguments and uh came up with bulletproofspeaking.com Bitcoin side chain after this point I feel like a lot of the ZK research and then projects that emerged tended to be more on that ethereum side like sometimes they were just l1s but they were definitely like they'll they'd have something like programmable privacy or this idea of smart contracts interfacing

with them under the hood and what eventually evolved into the ZK rollups they all were very ethereum focused or these like alternative l1s you were coming maybe more from like the Bitcoin side but were you disappoint Ed that like there wasn't more of a Bitcoin overlap during that time and why wasn't there was it from the Bitcoin side or was it from the ZK side that like there was a lack of Interest I think part of it was a perception for a long time that zero knowledge proofs and snarks always had trusted setups which is of course not accurate anymore yeah yeah I don't remember when the Stark paper came out um that that was also in in all of this maybe like

2018 so the the snarks that that people used for for zcash did have trusted setups and there was a strong resistance from the Bitcoin side you know to to using trusted setups certainly against ingraining trusted setups in the L1 yeah I mean to to add to that like I think one of the reasons that you know we didn't see that Innovation like really progress quite as much on bitcoin is because Bitcoin script is limited and there is no you know at at that time especially there's like not even sort of a good route to think about how how does Bitcoin reason about um a zero knowledge proof and I think that's that's some of

the interesting innovations that we're seeing recently that that's getting us excited and um a lot of you know folks in this space excited about ZK and Bitcoin happening um and you know one one thing that's also worth pointing out in that kind of intersection between CK and and Bitcoin is that like Bitcoin as a blockchain is sort of you know it's always been designed in in a way that like the the scripting is very very limited so we have very limited kind of smart contracts that that are available on bitcoin because the the core value there in core design thesis is blockchain should be verifying uh computation they shouldn't be executing arbitrary computation um and that you know really comes from how Bitcoin

treats the trilemma or the kind of the security decentralization scaling tradeoffs where you know part of like what makes Bitcoin a really you know interesting digital asset of really interesting money is that like it's just designed for maximizing the you know decentralization and security of of that trade-off and so we have much more limited script but this is where I think you know snarks actually fit really well into that whole thesis because you can do arbitrary computation offchain and um if you have some way for Bitcoin to reason and ver ify these snarks then there you go you can do kind of arbitrary ways to basically take BTC the asset export it into offchain systems in

a really secure way so Bridge it in into uh you know private execution environments or just very expressive environments you could put it into an evm chain uh and you know be able to use it as a collateral for smart contracts Etc right so the the key sort of thing there is like can Bitcoin reason about zero knowledge proof yeah and it wouldn't been able to reason for example about a fraud proof I'm assuming I feel like you needed to get to the ZK being performant enough cuz I what I hear is like there was the Bitcoin ZK intersection but then there's also just like Bitcoin and l2s l2s were not I mean I guess you had side chains you had liquid you had lightning you had like

these sort of like attempts to put side chains or something connected to it but with ethereum you had the fraud proofs and then you had the ZK rollups that like kind of right defined what that could look like and then it's brought back to bitcoin although there's two other things about Bitcoin and and again I'm not like I'm not in the Bitcoin world so I'm kind of looking in from the outside but it seems like just generally Bitcoin and l2s and that narrative started to pick up recently and then at the same time there was like ordinals or like nfts on bitcoin which also picked up and maybe can you talk a little bit about those two things and like maybe where those start as well yeah maybe it

starts with tap rot which is this upgrade you know that came to bitcoin uh a few years ago essentially you know ordinals part of the growth there is like there's they figured out a way essentially to put data on bitcoin block space that was you know much larger than you know what was possible before in a cleaner kind of way leveraging this taper upgrade um which relaxed some of the constraints around uh putting data in and so this of course you know seeing Bitcoin as this kind of more pristine premium block space that not to the you know the same extent after the last kind of nft hype wasn't used um I think this really opened up the design space for you know people to put all sorts of uh things and then also ordinal Theory

which is uh invented by KC Rod armor essentially laid out a way to track these you know utxos on bitcoin these you know nfts that uh get created content data that's get that's created on the pl space to be able to track ownership and essentially index them and you know that that was Innovation that really took off and it brought several hundred million dollars in transaction fees to the minors which is really interesting it also made block space quite expensive given the kind of usage I don't think it was you know quite as sustainable and you know there was definitely like spikes in usage and so on uh but it was it had a lot of interesting kind of secondary effects um into accelerating this conversation

around uh scaling uh Bitcoin and kind of even alternatives to lightning network uh what are other kind of uh Layer Two Solutions and then this is also you know times really well with this other Innovation uh it's worth talking about here uh called bit VM that uh Robin lus uh published a paper for last year uh I think it was like October and uh so this is you know to to your point earlier Anna about fraud proofs and kind of reasoning about that Robin essentially the core idea that uh you know Robin was able to outline in this uh in this white paper was it's a it's a paradigm for uh someone to make a claim on bitcoin and have like a claim about you know sort of arbitrary you know computation it's it's

a claim about some correctness of like a circuit you know someone makes a claim uh another party can challenge that claim and Bitcoin can actually adjudicate who who's correct in this case and so it's it's a it's a fraud proof primitive uh that is sort of available to bitcoin using sort of earlier ideas that Jeremy Rubin had with Lamport signatures and and how to do that on bitcoin this was like a really kind of interesting step forward in terms of like how do we start you know designing uh layer 2 systems uh or bridges that can be more secure than the honest majority assumption um and there's a lot of work you know after that white paper came out that the bit VM Community got together and and um

kind of propelled and I think where it sits today is really interesting as you describe all of this I can't help but Wonder like Bitcoin and it's not a smart contract platform there's no like VM to bitcoin or there is but I guess it's very very simple it's like it can do one thing this has been always kind of my question of like how does Bitcoin verify anything isn't it sort of like there's a multisig that makes a decision based on logic that happens elsewhere maybe but not that it's any like anything's actually happening on bitcoin and the only part that's on bitcoin is like using that memo field this is what I've always understood and it's always kind of seemed like a bit of like a hack around because there is no smart contract to like create the same

impact Bitcoin does have a a scripting language yeah it is very simple it used to actually be more featureful than it is now but it only currently supports you know I guess like Sims was sort of saying it's it's kind of a fourth based stack language with very limited functionality um you can add numbers subtract numbers do like a simple Boolean logic um as signature verification hashes notably it does not support concatenating values or multiplying uh numbers although it used to as a result you can you can Implement

very simple smart contracts and uh with with bit VM and the optimistic kind of protocol you can reduce much more complicated claims to things that Bitcoin script can check M but yes it's it's intentionally limited pretty severely but the stack can't contain more than a thousand elements you can't for example decompose a hash into smaller values or I guess another way of related problem is you can't take two things and put them together and hash them so you can't really do like Merkel proofs so lot of the things you would sort of naturally want to do in a a smart contract are not possible or at

least not possible efficiently so you mentioned though bit VM kind of opened the door to like more of an optimistic rollup model but what opens the door to ZK like you still have to verify proofs if you're writing them to this so that's the part that I've found really challenging to get my head around how do you actually do verification on bitcoin I think um it' be great to talk a bit more about snark NATO which is this protocol that we released recently but essentially it's you know like we think about it as you know you have arbitrary computation that's offchain evm roll up for example uh take you a bunch of ethereum transactions uh you have now all these kind of modular tools

available which is awesome use W uh use Z kvms and you know wrap that Stark with with maybe a snark and then ultimately get to uh you know a proof a really succinct proof about this estate transition on on a rollup for Bitcoin it's you know how do we maybe BCT over that uh you know verification of that proof um so the the approach that BVM in in the kind of latest uh like Risk five uh abstraction kind of takes is you know well you can kind of run that computation uh for verifying the proof the snark proof over a risk five Trace and then you can kind of do a bisection game over that Trace uh on bitcoin going to a specific place a specific

place in the in the trace where you know you can adjudicate kind of fraud similar you know in style to you know optimistic kind of things um where we sort of innovated with snark NATO as even more optimized kind of version of that is to remove the risk five abstraction altogether for us it was how do we BCT over a snark directly and if we can do that maybe we can get it down to much fewer rounds uh played out on bitcoin to be able to uh actually adjudicate the the claim um and maybe Liam if if you want to go into the details around kind of the bisection I think that could be interesting sure sure just to reiterate because I think many people are confused by this what what we're proposing doing

and many people are doing with bit VM is you are optimistically verifying a snark mhm so you have a snark that is a proof of a rollup transition and then you use bit VM to optimistically run the snark verifier on bitcoin so it's actually both things it's like a ZK rollup and a optimistic rollup because that last bit of the ZK can't be automatically proven on chain exactly yeah whereas in in ethereum you could you could you could just uh write a snark verifier and and check it directly yeah yeah so for snark NATO right um because we're only really interested in using um bit VM to verify

a snark we uh decided I guess that um removing the risk 5 abstraction and working more uh directly with I guess what you might think of as like a circuit for verifying the snark uh is more efficient and um I guess maybe this is also confusing but the model that we have for using bit VM to verify a snark is itself also based on snarks so we kind of encode the wait your implementation or the implementation is based on snarks uh the the strategy we use for using bit VM to verify a snark is based on polinomial iops kind of uh you know how snarks represent problems

that they're verifying maybe can you define what bit VM really is because you sort of mentioned that it exists and you said that it has risk 5 something but is it a library like is it a piece I don't even know what it actually is so it it's many things to many people no um it people use the term in inter subjective virtual Machin people use the term bit VM in different ways so there's the bit VM paper which U Robin wrote and it includes a lot of what I I would describe as like the bit VM Primitives so bit VM uses Lamport signatures to measure equivocation and uh that talks about you

know B section but it also talks about like nand gates for example which is is I think more of like an existence argument rather than like a concrete thing that was ever meant to exist then there was also bit VM the project from zeros sync at which other people have also sort of forked off of and that that is the risk five bit VM I see this is an open source project yeah yeah everything zero sync does is open source they're they're a nonprofit um and uh I don't believe they're working on the risk 5 bit VM anymore uh there there's then another protocol that they release called bit vm2 which uses some of the bit VM Primitives but not bsection and um for

people who are interested it's a little a little bit like bit VM If instead of bisecting you just had a single Round And the reason why this is interesting is because bit VM like one has a permissioned set of Challengers and bit vm2 by having only a single round is able to uh weaken that to allow anyone to challenge MH why is there this trade-off between number of rounds and uh number of participants like it seems like you're kind of saying something akin to like given the stack size you know like there's a fixed amount of storage that you can use so because of that you can't do multiple rounds is it

is it a Pure Storage constraint or is this like a more theoretical Reas uh there's like a dis a discret thing that happens when you go to one round essentially bit bit VM requires us to do some complicated hacks to emulate what are called covenants and uh maybe it's worth defining what a covenant is it's it's a way to encumber a utxo with some kind of like future restriction on how people can use the money going forward Bitcoin currently does not support covenants and they're they're very controversial in the Bitcoin Community but bit VM

requires them right like you kind of need a covenant in order to implement what you would sort of think of as a smart contract smart contract is kind of like a or one one model of it in Bitcoin would be a utxo that can only be spent to a new valid like smart contract state for example anyway all that to say bit bit VM requires uh a trusted setup to emulate a covenant oh and we're back to the trusted setup yeah it's it's funny it's it's an interesting uh full circle how did bitcoiners all of a sudden allow that if they were so anti in the first place well I mean part of what makes bit VM interesting is that it's not like

allowed per se it just sort of is possible right now okay yeah it works it works today without requiring self works it feels like in your description somehow the threat model change is like the model of the adversary between the multi cuz like when I think about the proof of bisection games and optimistic rollups the more number of rounds you have the more secure your proof is usually right so it's like I can do more challenges um I can do more like fine grained challenges like so it's kind of weird to me you can actually comp press to one round without changing the adversarial model like either weakening the adversary or or something like that so like why why why is this possible I'm

just kind of curious like formally like when you try to like prove consistency properties of this I think it it has to do like again I don't want to say anything wrong but it it sort of has to do with the way the Covenant emulation works so if you if you never need the like classically in in bit fm1 it's two parties right there's like Challenger and the prover and they sort of go back and forth if they never have to go back and forth then the Challenger doesn't need to be known in advance that's kind of the innovation of bit VM too oh I see I see it's around kind of the interactivity and pre-signing related to bit VM setup so so so so I should think of the one round

thing as sort of like a Fiat Shamir like type of thing even though it's for this other purpose cuz it it does feel like then the interactivity comes from some other assumption right like in the case of fat Shamir it's like effectively assuming random Oracle like I'm not sure if I guess that's what I meant by weakened adversary is that I I guess I I mean to summarize like The Innovation with BVM and the direction there is essentially to bring forward A Primitive that enables sort of these optimistic ZK Bridges if you will uh on on bitcoin there's definitely you know other complexity associated with that bridge construction as well which is uh you know how do you work within the other constraints uh of Bitcoin uh some of the you know mentions Liam brought up were

around Covenant so like how do you actually emulate some kind of Covenant using you know pre- signs uh and how do you kind of manage all of that complexity is one there's certainly an economic consideration here as well and that's been discussed uh quite a bit with these Bridges which is how do you you know actually manage to handle uh large amounts of withdrawals at the same time like what's the capacity of those bridges the bridge construction itself is slightly different even though it's you know sort of optimistic ZK Bridge uh the contracts on bitcoin and how the you know mechanism for this conical Bridge works is different because uh than than ethereum contracts say for arbitrum because of you know how we're able to sort of adapt to uh the limitations of

Bitcoin and so like one key difference is uh this kind of idea where you know there's a set of uh in in the at least you know kind of the the snark NATO or bit vm1 design there's a set of uh Bridge operators uh we'll call them and you know let's say they're n n of these Bridge operators and uh the deposits essentially go into this n of n the underlying kind of assumption in this in the trust model here is trusting one of the N to be honest and to be able to withdraw the uh you know BTC that you have on the rollup back into Bitcoin um this is where sort of the mechanism is is a bit different where one of the operators is essentially assigned to front that withdrawal to the user so

with user would make a withdrawal request one of the operators uh fronts that withdrawal and the operator then gets a reimbursement from this nfn that's holding all the deposits by presenting a snark proof that's aggregated you know the claim that they're making is like hey I've fronted you know this withdrawal to the user and I was assigned and you know I have you know and this maps to the latest state of of the rollup and so this proof if it's not challenged and you know it's correct then that operator is actually able to withdraw uh back you know out from the the deposits um so this fronting reimbursement scheme is a bit different yeah this sounds so much like the early conversations we were having

around bridging off optimistic rollups like to avoid the 7day you'd have schemes that sound somewhat similar to that so that youd basically be kind of like lending on one side and then like somebody's taking the risk and then like a proof comes in later and yeah this is interesting but there's a few strings I want to pull here because you talked about the bit VM I think we got through like it was a paper it's an implementation there's two versions but then you have like you've stripped out risk five from what I understand and almost just like taken the parts of this that are like really really needed for the ZK rollup model and just focused on that with snark NATO is that correct uh

yeah I think so um so we we use the bit VM Primitives um of uh Lamport signatures and bisection um our our goal in designing it was to do a bit VM type protocol in as few rounds as possible while also keeping the amount of data on chain as small as possible so bit VM 2 I think it's worth probably mentioning if you think about the way these kind of optimistic things work as is forcing the pr to provide enough evidence to prove that they're lying bit vm2 Works in one round right by forcing the prover to put like the whole trace on chain in one

shot and then anyone can look at this and extract an error from the committed Trace that has a kind of unfortunate scaling properties unlike bsection so in bsection you you would imagine say having the one big linear trace and the Challenger asks the prover to sort of pick out a very small piece of the trace by bisecting over it so you split it in half and the errors in the first half then you split it in half again and so on so there's sort of this open research question of how big of the of a trace do you do you need to put on chain to make bit VM to work for um snark verification however introducing even a

relatively small number of rounds reduces the amount of data on chain exponentially so if you have two rounds you it's like having a binary tree with two levels right so the amount of data you have to put on chain is now square root the trace size or three rounds is cubed root so being able to um freely get the number of rounds really really small allows us to be a little bit less sensitive to the exact size of the trace it's it very well might be the case that it's possible through lots of tricks and hard work to make the the trace small enough for bit VM 2 to be practical and in that case it's it's interesting that snark NATO if you do it with one round ends up sort of converging towards bit

vm2 and you could then relax the permission to challenge or set but there there are lots of like really tricky technical issues so for example with with all of these things with bit vm2 especially you have to split your computation that you're you know checking into Bitcoin scripts and like we said earlier Bitcoin script is is extremely limited and difficult to work with and even if as uh zeros sync and collaborators have they they write like a a giant Bitcoin script to check something transferring that into like chunks is itself a complicated and non-trivial task you know because the

stack can't be more than a thousand elements and you have to like share the stack between the chunks so you have to Lamport sign the state going from one chunk to the next chunk and you have to put all of the signature data on chain and I mean I'm not trying to make it sound like it's it's impossible just to give people a sense of the the technical like engineering challenges that go into making it work wow yeah which is I mean this is one of the motivations for snark NATO as a sort of you know doesn't go to a single round kind of following the bit vm2 approach which you know that that would be awesome and like we know we'd love to you know contribute research ideas and we are uh to that project but snark NATO is something that's practical and you know we're building today and

it's you know targeted for this public test net version that we're launching this year right and so one one quick point I think it's worth clarifying is we talked about number of rounds a bunch and like why that's even important is um you know I described that withdraw flow back um so essentially if a operator is challenged about their withdrawal proof then then we go into the bisection game played out on bitcoin where uh each round is uh approximately you know in in most designs including ours today uh one we period where you know the Challenger the the kind of the verifier has approver has time to respond um and so with bit vm1 you know we're looking at something like over 30 32 kind of rounds

played out on bitcoin translating to you know well over six months basically to adjudicate some kind of fraud um and so that being the worst case was uh concerning for us in trying to design this kind of practical bridge and so bringing that down to up to four rounds it's even worse than that actually yeah because cuz if you have multiple Bridge operators and and we want to be robust if most of them are dishonest they could you know if you have 100 and 90 of them are dishonest you'd have to wait for like 96 month periods potentially if they if they were just trying to do like a liveness attack so Bringing Down the number of rounds is very critical in

terms of like thinking about what's practical in the worst case of course like this isn't the case that there's like a challenge and then you know that that whole thing gets played out on bitcoin yeah I guess like the reason I'm asking this is generally when I think about safety and liveness proofs formally they sort of assume that you can kind of show like hey some process for converging on either finality or some imate property happens relatively quickly in in sort of a in some system parameter whether it's like key size or number of you know latency like upper bound on latency dot dot dot right but usually whenever you lower that you're kind of changing your threat model right like if I lower my partial synchron

constant like the minimum the maximum latency for a vote to be considered true or for you know for people to to give a valid input then i' I've sort of changed my threat model so I guess my question is like what is changing in the different in the threat models for say bit VM versus snark NATO because it does feel like there has to be like sort of a no free lunch type of thing right like there's there's something there is something that has to give and maybe clarify which bit VM is it bit VM one or bitm apologies I for for bit vm1 right like the design is basically to to BCT over some fix size risk five Trace and because of the trace length that's how

we arrive at the number of rounds essentially that we have to go through to to be able to pick out a a particular row right and for snark NATO it's like it's fundamentally different like we're not actually you know we we don't support arbitrary rust code like executed uh and and compiled into this risk five Trace we we specifically support pairing based snark uh and we're going with gr 16 and like like that's the abstraction that we're working with hence like the fewer rounds so I guess that's that's kind of where the tradeoff lies I don't know Liam if you have more thoughts on that I don't think the threat model fundamentally changes I mean it's it's sort of just like playing with the aity of tree right with bis

section you split it in half you can you can split it in thirds and I I think everything from like a I don't know formal perspective is basically the same but the depth matters more than the width right for for things like that where like the the depth is sort of the real measure of complexity than the like just from like a computational hardness standpoint right like if I give you a random Boolean function you know the depth controls the complexity more than the width right like that's why you Define complexity so I guess my my my main question is just more like what are the threat models for these things like have have people actually done kind of like the research of like writing out exactly sort of the adversarial model

and where is the state of research maybe that might like a more highle question than kind of getting in the week I know I I think I think it's definitely early like systems like this you know snark NATO based you know optimistic Bridge like these are just kind of they're just coming out now yeah right and so uh I think that you know the state of This research is quite early what's interesting though is like we do have a lot of even on designing the rollups we have like several years to look at for ethereum uh and and that lag is actually kind of interesting because we're you know taking some of the most interesting ideas there or more most interesting kind of threat models there and applying it uh into kind of similar systems but I'd say quite early turn yeah I I just I

think that there's there's actually a lot of it feels like there's a lot of interesting research problems here that probably haven't been formalized at least like that at least just from hearing your description that is kind of interesting yeah definitely I don't I don't think that they there there's been any at least to the best of my knowledge formal research um specifically on bit VM slight slight tangent if you in mind we were talking about sort of some of the data limitations uh within Bitcoin rollups and you know when you think about ethereum Roll-Ups there's a huge focus on like where the call data is stored and and you know data availability type of issues uh how do you deal with that in in Bitcoin rollups how do you think

about that like from what I heard it sounds like the bridge operators effectively need to be providing da but I'm not 100% sure if that's true or whether there's a third party that could be used you know like how does that whole sequencing work sure I essentially I mean yeah we da on bitcoin is more limited um definitely than than on ethereum we don't have you know Proto Dan charting Etc but you know there is space on bitcoin directly like inscription style to be you know putting State diffs of of the rollup and uh you know we will be using you know Bitcoin as the da layer for for our kind of public test net going out um over time um I think it does make sense to explore like a volition type model where uh you

know we we can have some accounts essentially or most accounts uh use da external to bitcoin like some use some kind of Da layer uh and there's there's some like collaborations we're doing there as well to to figure out you know how do we get inclusion proofs and data availability proofs basically verified as part of the bridge program to be able to like essentially like the what is the blob stream X version of that for for Bitcoin you know in regards to Celestia but over time essentially like you know we'd have alternative da layer uh as an option uh for really high throughput low you know low cost kind of uh transactions on the rollup and uh accounts also available directly on bitcoin for the like different tradeoff of like higher cost and uh more security

so you just mentioned inscriptions which I know kind of are the foundation of the ordinal project ordinal but like are inscriptions also the basis of bit VM or are they not related they're definitely related I mean inscriptions are are really just putting data in into Bitcoin it's a more efficient way to just put data on on bitcoin um bit VM uses inscriptions as well yeah definitely you're saying it's through the inscriptions that you get the da yeah so we would use inscriptions both like as part of bit VM but for the the rollup itself you you would inscribe like a state diff or something got it and then you can you know introspect the Bitcoin chain from the layer two and you know

it's it's complicated but yeah basically I I guess my question is just more like you know when I think about rollups right I think about like the sequencer provides you a particular set of services the base layer provides you another set of services mainly the exit hatch the da but it feels like the the bridge operators here actually provide more like there's sort of some kind of different security model so you know you mentioned they one out of n honest but is that for both directions and sort of yeah like what how should I think about you know the security model of a centralized sequencer versus the security model of your operators if that makes sense yeah um I the sequencer part uh I think it's quite similar to what we

already see on ethereum which is essentially you know batching transactions generating a proof and posting that so we inscribed that proof along with like the compressed version of the trans actions on bitcoin you know for that part um the settlement actually is done client side in our architecture so you know noes of the L2 will be running Bitcoin and see you know the the proof of State transition posted and verified that directly so they're like clients and you know they can get to the latest State this way uh and these proofs are also recursive so like you know you can verify the latest proof you can verify kind of the latest State you know since Genesis of our rollup um for the bridge operator like I think there are differences there because now we

have like this fixed you know like set of these Bridge operators that are responsible essentially I mean the difference is more on the withdrawal back I think deposits are standard like you know you have way to deposit in and of course the rollup can introspect on bitcoin so they'll see deposits and be able to Mint there uh but in withdrawing BTC from the roll up back to bitcoin like this is where you have to trust that one out of the End Bridge oper operators that are there is functional meaning they're honest and live withdrawal requests will go to the uh sequencer and essentially there's you know a bunch of withdrawal requests can kind of be aggregated and then um the

protocol can select one of the bridge operators to uh handle a reimbursement within you know some period of uh time on bitcoin uh and that's when you know the operator goes and actually you know does that if they don't then like that assignment you know can go to another operator and that withdrawal is like a little bit delayed but you know you trust that one of the operators will actually process that withdrawal by you know fronting that liquidity that withdrawal request to the user and then you know immediately after um there are different kind of tiers to this if all the operators are live then immediately after the reimbursement can be processed right away like you know in that block next block or you know essentially over a challenge period when the operator

submits a proof to get a reimbursement if that's not challenge then kind of the reimbursement is processed back to the the operator and we can have multiple operators be processing at the same time which is like a kind of key difference in our Bridge model the bridge models around kind of bit VM and and these like fraud proof mechanisms are still very nent and I think that's evolving quite a bit um we're about to release our uh specs quite you know pretty soon but you know in our sort of approach you can have multiple operators handle uh multiple deposits and uh there's you know operator assignment and um there is some collateral requirement here because there's like this fronting reimbursement something you keep talking about are like the bridge and the rollup and they sound like two different models and that

there's the bridge operators and then there's the rollups and the sequencers but like like can we just very clearly Define what those two things are and if they are not the same thing like why do you know what I mean like I this is something where I think we've sort of been flipping back and forth we've said like the sequencer oh no but the bridge operator so like in the models that you're working on are you creating two unique ones and are they do they have different actors in them yes yeah so this is you know quite different uh thanks Anna for pointing it out between you know what exists on ethereum and and and what uh exists on uh Bitcoin um or what we're building on bitcoin um so the sequencer is a separate entity here from the bridge operators and uh you know the the

sequencer uh is responsible for that state transition I mean similar kind of responsibilities as as we're typically used to and essentially posting a proof of that state transition uh along with you know the the transactions uh on Bitcoin in a kind of world where you know you just want to inherit the security of uh Bitcoin on your rollup like you can build something like a sovereign rollup even if Bitcoin can't reason about zero knowledge proofs or you know can't do fraud proofs at all uh it just means you have a limited Bridge you can still build a Sovereign rollup uh where you know you can uh inherit the double spend security of Bitcoin by posting proofs having nodes uh run

Bitcoin and and arrive at uh the latest state that way so the key difference is you know we also want to be able to take BTC the asset and be able to bring it to our rollup in a way that is really really secure uh relative to you know options available today like that gets better than an honest majority uh assumption and so that's that's where the separate Bridge system comes in but you're using snark NATO for both of these things is that what you're saying we're using snark NATO specifically for the bridging okay not for building a rollup okay yeah the requirement for Bitcoin to be able to reason about these proofs comes from you know wanting to create a two-way Peg a bridge to bring

BTC to and back uh from a rollup right and so we're using the snark NATO primitive uh for the you know Bridge uh design that we have uh and that's where the bridge operators also come in which is separate entity from the sequencer cool one question that I've kind of been always wondering about is like you know this is obviously a debate in ethereum right of whether the sequencer should be posting collateral and be able to be slashed you know let's say they don't process something in time or you know when the valid fraud proof is executed they need to have some kind of like skin in the game outside of like trust me I guess the question to me is uh you know you

mentioned that there's some collateral that has to be placed you know to some extent um like Anna said earlier this is like sort of a loan you know you put up collateral on one side you kind of which you're you're sort of fronting capital on the other side and then eventually they settle how do you think about these kind of like slashing conditions and then also kind of the like lightning style problem of like the free option of like hey I can request something but then kind of cancel or not fulfill one side but I got the value of it for like that small duration type of thing if if there is such a thing I you know I don't totally know the entire design to know how how complex it is to actually execute such a type of thing but yeah

how how do you think about that design that part of the design sack the the question was like slashing sequencers if they misbehave or they don't behave approp l in time and then also like the free option problem with lightning sorry the the free option problem here is just more like I I go AC I want to go to across the bridge right I I like say hey Bridge operator take me across and there's a sense in which the bridge operators now have they can basically if assuming there's no honest Bridge operator they effectively can delay my transaction or maybe delay it multiple blocks so like let's say it's I'm sending a capital to do a trade on

the rollup the bridge operators delay my trade by the time I get there I sort of get a worse price and the difference between the price I would have got if they acted promptly versus the real prices this kind of free option thing which people people enlightening always talk about is people kind of blocking you from doing a certain route so you have to take a longer route and then you pend up paying more in fees so like how do you think about these types of like griefing kind of attacks it seems like the bridge operators could do a lot of those types of things even if one of them is honest how do you kind of Reason through that the bridge at least in and I think all of the bit VM constructions is really like heavy and slow and and difficult to use and so uh I mean one

maybe version of an answer is that normal people will probably either use swaps to move between the layer one and the rollup or you know some kind of credit based thing I don't know if that like solves the problem but at least the way I think about bit VM stuff working is like normal people don't really use the bridge there's like big liquidity providers that move very large amounts of money across the bridge to settle very infrequently so I I don't know if that's like a satisfactory answer but that's kind of how I think about it definitely agree there most most us users um you know we're expecting actually probably

we use some kind of like Atomic swap based uh Bridge system which um essentially I mean you don't have to go through the functional requirements of that canonical Bridge uh which is you know a delayed withdrawal period due to you know settlement period Etc um you can do instant withdrawals instant deposits um through this Atomic Bridge um but it requires on on the other end having some kind of service that is you know swapping with you right so like if you have BTC there you you want the BTC on the roll up also to be available and so we expect like actually several different you know swapping Services uh to be you know placed there and then there being you know different trustless permissionless ways to uh bridge in and out uh between the two btcs uh on on

base layer and rollup is that what it's going to be also like will the rollups be BTC emulations often in this case or they they're not like trying to add more function I mean I think in the bit VM it does because it has the risk five but what you're creating it's actually Bitcoin to bitcoin no so like I think we didn't talk about this as much but where the BTC is going uh and what we're building is a evm uh oh it is okay roll up right yeah so you know once you once your BTC is there uh you know you can do whatever you want and then you know we expect to bring in Native stable coins there we expect to bring in um all sorts of kind of other things there you know where

we're excited is that it's it's not like just around scaling Bitcoin but really expanding the functionality uh in terms of like what can be done uh around privacy uh with BTC what can be done with programmability uh you can do lending protocols Bor you know lend borrow uh you can have all sorts of like kind of interesting uses of BTC as a collateral which a lot of teams in the defi space um across various ecosystems have have actually reached out around how do we access BTC in a more native way um and use it as a collateral uh for for our applications can I ask a really dumb question which is is it ever possible that a rollup be a roll up both

on bitcoin and ethereum at the same time I realize that's like really dumb because often they're like branching off of one of these to exist but could you have like two sequencers pointing in different directions mhm it's funny you mention that actually because I think starkware had an announcement yesterday um really around Stark net yeah essentially being um a roll up both on on bitcoin and ethereum like they're plan planed to do that okay there are fundamental problems um with it because if the two l1s like if if one of them rolls back or Forks or something it's you you don't have a single canonical source of Truth for the rollup um I I can't say for sure that this is like

insurmountable but I don't know I I think you we can't really avoid this I think what's interesting is uh having for an ethereum roll up having also like a bridge uh that is like a ZK Bridge optimistic CK Bridge uh from Bitcoin as well because like BTC as an asset is incredibly valuable yeah um and uh you know the state of that today bridged into the ethereum ecosystem is is still you know very centralized it's uh it's something that we can definitely do better so like what it is today it's often like what is it a multisig or a single address on bitcoin locking Bitcoin and then minting wrapped Bitcoin on ethereum right essentially yeah right and you know the best designs would be

like trusting a majority of that you know multisig uh to be honest and in life but in what you're what you've created with snark NATO would be like you're basically you're creating a much more authentic synthetic like there's no single account or multisig that needs to lock it right like it's written more onto the chain or is there still that entity in in your build yeah so there is still uh like a federation um where the deposits are locked into um except you know the trust model around the BTC and and and how the Federation can kind of spend you know all the deposits is a lot better uh with with this approach given it's it's trusting one of that n members

to actually be functional um what's really interesting and maybe it's worth pointing out here is like if we can directly verify a z proof you know on bitcoin uh in a single transaction then uh you know we have architectures and models for how to build a fully TR trustless like no Federation way to be able to withdraw BTC back from the rollup so like do the the bridge um without requiring um any kind of federation whatsoever uh of course like this is you know not possible today as far as we know but uh cat is really interesting proposal that's been really popular and getting a lot of momentum in the Bitcoin space it's literally to concatenate two you know elements in the stack for Bitcoin but the implications

um would be you know to be able to verify Merkel proofs which might be enough to be able to verify Starks uh and so there's been some really interesting research that a bunch of groups are doing including ourselves uh we've been collaborating with Benedict uh on Benedict buns on uh understanding you know how can we get towards direct verification of code-based snarks if opcat was actually available so if that ends up being soft forked in and you know the Bitcoin Community is uh accepting of that change uh we we may see you know that threat model kind of even improve you know the bridging model improve even further who although that sounds like a big if yeah like if the Bitcoin Community accepts this thing

that they're kind of legendarily not into accepting new things so there's definitely some momentum around it okay yeah it the attitudes have warmed quite a bit I mean it's definitely not by any means even maybe even likely to happen but there's been definitely a Vibe shift and there's even talk of of activating more of the old old op codes that used to be active on bitcoin but were disabled when you say cat the cat proposal what is that is it like is it just cat yeah there there's an OP operation in Bitcoin script um called opcat that takes two elements from the stack and puts them together and makes and puts what's the concatenation El

what it stands for okay yeah exactly and you know the basic way you'd use this to do something interesting is if we wanted um to check say that a hash is a hash of some particular values you put your things on the stack you concatenate them you hash it check the hashes are equal and now you can like do stuff with the hash pre-image it without cat you can't do that um and you can't like decompose things interestingly or or like Sims was saying right you can also do Merkle proofs right you have to the two paths and you can catenate them in hash say sounds good I think what like is interesting and of like it being very

difficult to make changes into Bitcoin uh consensus protocol why that I I think that's really interesting uh as a you know a roll up Layer Two company is this gives us great guarantees that the base Slayer will be secure uh it provides us like really good consensus guarantees uh and you know we also using BTC as an asset like I think this is actually you know don't mess with the consensus protocol attitude is is the right sort of approach we think uh you know for a base layer a lot of that Innovation is going to happen in the modular world in in the L2 a lot of that execution like things happening should be offchain in this layer too and and the base layer should literally interact with knowledge

proofs and be able to just you know verify these kinds of proofs and like that kind of abstraction keeps also the base layer uh kind of more secure while still being really valuable longterm nice all right well thank you to both of you for coming on the show and uh yeah for sharing with us everything about Alpin Labs what you've been working on helping us to explore the ZK Bitcoin World which is something we haven't really covered on the show yeah thanks so much thank you thanks Anna thanks tun I want to say thank you to the podcast team Rachel Henrik and Tanya and to our listeners thanks for listening