Combining Bitcoin and Ethereum via Hybrid L2s - Dominik Harz

Transcript

[Music] Go. All right, cool. So, hello. Uh, thanks everyone for, uh, joining the first talk of the day. Really appreciate you all coming in. Um, my name is Dom. Um, and as mentioned, I'm one of the co-founders at Bob. We are building what we call the hybrid L2. That might be very confusing. Uh, so I'm going to talk today about what that actually means. Uh, why that matters and how we're doing this. Um, so why bother with Bitcoin in the first place, right? We're at an Ethereum conference. Um, why do I talk about Bitcoin? So, Bitcoin, um, is the largest asset class. Even if you take,

you know, all of Ethereum and all of Salana and you combine it, then Bitcoin is still so much larger. And we think basically there's a huge gap in the way that Bitcoin is used right now. So you have like 30% of of Ethereum's TVL that's like onchain but in Bitcoin the the onchain TVL is just 0.3% of all the Bitcoin that actually exists and if we can you know grow that to the 30% of onchain TVL that Ethereum has well we we have a huge additional market opportunity there and really if we think about why we're all in you know cryptocurrencies web 3 um if all we ever do is use Bitcoin on Revolute and Robin

Hood and Coinbase and and Binance, then why even barter with cryptocurrencies in the first place? So, really, we want to get this onchain and we think it's a huge opportunity uh for everyone to do that. Um, one of the reasons we haven't really seen much of onchain movement on Bitcoin in our opinion is Bitcoin is really good at like uh focusing on mass adoption. So getting more users, running big conferences, uh doing um getting ETFs approved. Um but a lot of the talent and and users and the capital for innovation actually moved over to Ethereum mostly and to Salana as well and the L2's arbitum optimism base. Uh

because on the technical side like most of the innovation in the past years all happened on here on this side you know social happened here. um amm happen on Ethereum. Um so there's a there's a big gap between what we what Bitcoin can do right now and and what we have over here. So um why is that? Um we think there's three main challenges to actually build a Bitcoin L2 and to bring this innovation uh back to Bitcoin and or combine Bitcoin and Ethereum. Um you have a Bitcoin security and bridge problem. So that's a very hard technical problem like how do you actually get Bitcoin security and how do you build a secure bridge? Um pretty much all the

bridges we have right now uh for Bitcoin are centralized RPTC CBTC uh is a few trusted entities. Um and Bitcoin security yeah you can do some anchoring techniques and stuff like that but it's still is a tricky problem. Um the other two problems are equally important in our opinion. Uh you need to build up an ecosystem. uh you need to have users uh you need to have apps you need to have interesting applications and I think this is where a lot of the current L2s also fall short uh it's more or less copycat applications of existing Ethereum L2s right now probably if you look at innovation um on Solana it happens a lot of people deploy on base and on arbitum but there's very little

novel applications being deployed actually on Bitcoin L2s and last but not least you need liquidity especially if you want to do DeFi your users ers want to have low slippage. Uh they want to have efficient trading routes and for that you need liquidity. So kind of you need to solve all of these three problems and um how we are approaching this is uh and and now I'm talking mostly about the first problem actually. Um so today mostly here I'm not going to spend much time on existing liquidity. Um how we're solving this um is we taking the OP stack uh so we get standard EVM we get a Ethereum native bridge we adding uh roll-up security via ZK verification uh using risk zero uh so

risk zero is working on the Kyua project uh we are one of the first rollups to actually implement that into production it's on test net right now um and then on the bitcoin side uh we need finality anchored into bitcoin This is where we're working together with Babylon uh to integrate Bitcoin staking. Um and then the big thing that I'm going to talk about today is uh native Bitcoin bridge via BitVM 2. Bitvm2 is like a new technology that allows us to do fraud proofs on Bitcoin. And with that we can build Bitcoin bridges that are not that don't have a majority assumption but have a you just need one single honest party to make sure that the bridge is actually correct. And very last thing is

this Bitcoin access fireb gateway. That's our Bitcoin intense bridge. Not going to talk much about that today. Uh but there is uh there's some interesting work that we're doing with that as well. So if you're familiar with like across or or similar intentbased bridges, we basically do that with Bitcoin. Um all right. So going to talk about hybrid architecture first like how does it look high level. Uh then going to talk about BitVM and then how kind of this whole Bitcoin staking actually fits into that. So, we're going to go from our optack rollup. So, those of you familiar with optack, um you have a sequencer. It produces blocks every two seconds and uh

that's pretty standard. Um you have a native L1 L2 bridge um where you have Ethereum security basically via fraud proofs. Um and currently on Bob uh you have uh all the rap Bitcoin assets that you already have on Ethereum like Rap BTC, TBTC uh and the different Babylon LSTs uh like X of BTC or LBTC. Um the cool interesting thing is you can get them with a single Bitcoin transaction on BOP uh via this gateway construction. Um yeah, just as a side note, um now what we're doing with the opt so we we're leaving the core component like produce blocks every two

seconds that stays the same. Uh now what we're adding is Bitcoin finality. So as you know like op stacks they finalize on Ethereum um and it's basically you have a state proposal and if nobody challenges it within a timeout period usually 7 days uh then it's considered final. Uh that's pretty slow to finalize. If you ever had to withdraw from base or arbitrum, um waiting for seven days for your assets is not no fun. Um so with Babylon, we can do uh Bitcoin staking which allows us to finalize the state of the rollup much faster. Uh but it doesn't impact safety because for safety um we are still using a validity proof over block that we

verify on Ethereum. So you get fast finality but you still get the safety guarantees on on Ethereum. And then how we get the native bridge to Bitcoin is via this BitVM construction which I'm going to talk about in in more detail. Um and then lastly if we ever get to that stage uh we can also get uh Bitcoin security as like a proper as a proper rollup uh on Bitcoin uh one of the this this is early research uh oh yeah the previous one that's on testn net and first one is actually live right now. Um the last one um that would be constructing a full rollup. Uh biggest problem or one of the biggest problems here right now is um if you want to do a proper rollup you want to have the data

availability on Bitcoin as well. Uh you know Bitcoin has very little storage capacity. So it's very expensive to do that. Uh so right now that's not really possible unless you want your users to pay a lot of money for your chain. Uh so this is in very much R&D stage. Okay cool. Let's uh let's dive into BitVM. Uh I think BitVM is is an interesting topic. Uh who has heard about BitVM before? Most people. Oh, that's a lot more than uh than usual. Cool. Um awesome. So um yeah, most of Bitcoin merges is centralized right now.

This is from uh bitcoin layers.org. Uh they're like a L2 beat for Bitcoinish. Um and yeah, as you can see like RapTC, Binance, like those are the big bitcoins right now. uh pretty much none of these are are uh decentralized. Um and we think like one of the big issues to well why would you go onchain and not use you know Coinbase Binance or one of these other providers if if you go take your Bitcoin and chain it's anyway centralized so might as well just stick with a centralized application right so um somehow somehow we need to change this and um you have the standard bridges so you basically trust the majority um of the

signers that is correct so for rapidc you trust BitGo and Tron. Uh for CBBTC, you're trusting Coinbase. Um TBTC is a bit better in that sense. Uh you still trust the majority, but there's like a more open signer set and there's way more signers in this. Um but the cool thing with Bitv BitVM is basically it's very much like an optimistic rollup. You have fraud proofs. So you just need one honest challenger. And the bonus with BitVM is you can actually go and verify it yourself. So if you're very technically capable, you know how to run infrastructure or you trust somebody who can do that, they can actually verify that it's correct and it's all done via um via zk proof. So not a signer set you can actually dis disprove somebody or

prove that somebody behaved correctly or incorrectly uh which we couldn't do before. So how does bitvm work? Um so in a very very simple initial construction you have a thing called operators and operators are the ones that you know operate the bridge uh they have a wallet on bitcoin and they set up this bitvm program. We're going to treat the BitVM program as a black box for now. Uh BitVM program under the hood. It's a bunch of of Bitcoin transactions. But yeah, so the the operators set up these uh an instance of this program and they facilitate this this bridging process.

Uh technically anyone can be an operator. Um the BitVM program implements like the bridge. Uh you can you can implement any kind of program in BitVM. Uh in our case because we talk about bridges here um we we are implementing basically a light client for for the bch chain. Um and yeah under the hood it's a bunch of bitcoin transactions. Uh and then we have another role uh the committee uh they sign and verify bitv programs. Uh the committee is mostly a workaround for a limitation in bitcoin script. You're going to hear me say that quite often.

Bitcoin script is very limited of what we can do. Um, if we had covenants on Bitcoin, we wouldn't really need the committee, but we don't have that, so we need a committee. Uh, and they're really just there to verify that the program is correctly, and then they are handling the connections between the transactions. So, uh, what a user now does, they basically they lock bitcoin with a bitm program. Um, and then that's more or less a normal Bitcoin transaction. And then uh the operator would do an SPV proof on the bop side.

So Bitcoin light client on the bite uh into the bridge contract and then you would mitvm BTC ear c20 on the bite and then you have a fully fungeible um wrap bitcoin on the b side that you can use on any chain. Uh since Bob is a eth rollup you can then use it on anywhere on ethereum really. Uh Bob is also part of the uh optimism super chain. So, you know, you could move that anywhere you really want to. Uh, and then that's basically it. Like for the users, just these two steps. Um, and then if you want to go back, this is where it gets interesting. Um, so the user would lock their ERC20 on the on the Bobite uh and and burn it. Um, the operator, this is

the important part, they send Bitcoin to the user. they see that that the bitcoin has been uh the 20 was locked and burned and then the operator preps to the user. So uh the the initial bitcoin is still locked in this bitvm program u and now the operator sends the bitcoin back to the user and now they need to claim it back and this claiming back logic is precisely where the fraud proofs come in. So operator sends a proof uh to the BitVM program saying okay I sent Bitcoin to the user and the bridge bitcoin has been burnt. Um and then the challengers they verify that that was actually done correctly. So you have like a challenger role like in a fraud proof that says

wait a minute did you actually send it send the bitcoin to the user was at the correct address was it actually correctly burned and because that's a zk proof uh we can we can prove that [Music] um so that is very high level how the bridge works and now let's let's dive a tad bit deeper um so that bitvm program for Bob uh implements basically more or less five um conditions. So we need to burn uh the bitm BTC on Bob. Uh we need to make sure that the Bob blocks are actually correctly produced. Uh we need to make sure that those are assigned aka finalized that it's checkpointed onto Bitcoin. So we know that the

finalization is actually uh more or less irrevocable because if it's deep enough in Bitcoin like it's really expensive to actually change it. And then uh making sure that the packout transaction is on the like the you know when the operator sent the bitcoin to the user that it's on the same bitcoin chain as the bop checkpoint on bitcoin. So we make sure that we stay on the same chain. Uh and now this is the this is the most complicated slide. Um uh but it's also the most fun for the ones that are technical. Um right so uh this bitvm program right so our five the five things that we very simply wanted to do we encode this into a a program um a prover and then we have a snark

verifier the the cool part in bitv this snark verifier we actually implement this in bitcoin script yes it's possible to do this in bitcoin script it's very large Um, right now I think it's actually down to about 1 gigabyte. Um, so it's not two gigabytes anymore, but it's it's a very very large program. Now you people that know what's going on in Bitcoin. They're like, "Wait a minute. Bitcoin blocks are at most 4 megabytes bit. How are you going to fit like a huge program like that onto the Bitcoin chain?" Well, you don't. So, you need to do a little trick. And the trick is uh we're splitting up this verifier in Bitcoin script into a lot smaller chunks that

are maximum four megabytes big. And these chunks uh we basically so we we take a program uh we have we have one input here and now what we do we chunk it up and we take the initial input as the initial input here and then uh we take the output of this 4 megabyte program as an input to the next one and the next one and the next one and the next one. Um and that way uh we can now include part of the zk verifier onto bitcoin. Now what what happens uh so our operator now uh our operator in this uh in this step the operator submitted to this program um the zk proof uh saying

that they did all of these things and these are true. If if this isn't true, what the challenger actually does is the challenger is going to look at the ZK proof going to do the same kind of construction and splitting up and then the the verifier is going to say, "Wait a minute, your proof is actually wrong and it's wrong in this part or it's wrong in this part of the verifier construction." And then the challenger is actually going to tell the operator, look, you actually need to prove to me on chain that this is correct. Now submit this part on chain to Bitcoin and we're actually going to verify we're going to execute this part of the snark verifier in Bitcoin script on

Bitcoin and with that we get full Bitcoin security of the verification of the program. So uh we're doing a like a bisection over over a ZK verifier and then executed in Bitcoin script on Bitcoin and that way we get we get to do fraud proofs on Bitcoin. Uh I know this is very all very technical and I'm skipping over a lot of more nuance details. How do you get the data? Uh there's some winets winter and and lampboard signature commitments but um yeah happy to answer that uh in a few follow-up questions. Um yeah and you basically once you're done with the challenging so um you can you can verify it actually on chain in Bitcoin because

it's in script uh and that way uh you can know that the bridging is correct or not. uh and if the claim by the operator was incorrect, you just slash the operator uh and you don't release the bitcoin from the bitfam instance uh another operator can come in and uh and do a correct proof uh and then claim the bitcoin back. So as long as you have online honest operators, at least one uh you actually get a functioning bitcoin bridge that has much better trust assumptions than anything we have right now in production. Um, and this is my uh Oh, I promised the previous one was the most technical one.

Uh, this is how it actually works. Uh, or well, this is a tad bit higher level of the actual Bitcoin transactions that you're creating. Uh, so there's a lot of Bitcoin transactions. They're all connected with funny connector outputs and spending conditions. And um there's the BitVM paper. Uh, so my co-founder Alexi, he's one of the authors of this BitVM paper. Um the BitVM paper, BitVM 2 paper is very well written I think. Uh so you can go through it how like BitVM works and how you construct a bridge with it. Um and yeah, this is kind of the transaction graph under the hood.

You know when we treated this whole thing as like a BitVM program like this is actually how it looks if you implement it on on Bitcoin. Um cool. So uh very last part um that I want to talk about Bitcoin finality. Um this is a very quick one. Um so one big problem in in BitVM right we said we want to make sure that Bob is actually finalized. Why do we need Babylon? Why not why isn't Ethereum consensus good enough? Ethereum has so much like while it's smaller than Bitcoin is still it's very very secure. Well, Bitcoin is not very light client friendly. Um so in BitVM we need light client proof and uh if you try to build a light client for Ethereum it's really

hard. um you need to usually work around with a sync committee, but then you don't really get full Ethereum security. Um so we we need something that's deterministic for BitVM and well we're a Bitcoin project so might as well align with Babylon and use a use a solution that that works well for us. So in Babylon you have Bitcoin stakers. So they stake Bitcoin uh on Bitcoin uh and then they can delegate the stake to these finality providers and the finality providers they have now a bunch of Bitcoin like behind them and they can finalize the blockchain and then you get like a very pretty much standard tenderment style consensus protocol deterministic uh very easy to verify in a bitm

program. uh much much easier than Ethereum consensus. And uh I think Babylon has like six billion dollars worth of Bitcoin right now. Um that's um sorry. Um yeah, and yeah, that's that's pretty much good enough for us right now. Um cool. So um if we bring it all together, right? Uh so you have Bob Hybrid 2. Um you finalize the Bob locks. Um you get finality through through Bitcoin staking. You get safety through ZK proof. So when you settle the bridges to Ethereum, uh you need to use a ZK proof that the Blocks were produced correctly. You don't trust the finality providers to do that job. You need the ZK proof. You need to verify on Ethereum that Blocks are produced correctly. And

the same for the BitVM bridge. You need the ZK proof for safety and you need the the Babylon validators for finality. That means Babylon can only um cause liveness failures. Um and the rest is all done via ZK proofs. Um okay and wrapping up. Uh so the idea what what we're trying to do is basically okay we have our little roll up here in the middle the L2 uh you have all this complicated bitcoin stuff but then really uh if you're building an app uh or whatever chain you have uh we give you access to bitcoin. So if you if you're an app on base, uh we are very happy to provide Bitcoin access to you.

If you want to build a new app that's very that wants to have Bitcoin security and direct access to that stuff, go go deploy it on Bob. Um you're in good company. We have uh Uniswap, we have Oiler and a few others on our chain. Uh but also if you're somewhere on on another chain already deployed, we can probably help you. Um we're on mainet since one year. Um we have like 280 mil of onchain TVL right now. Um yeah and some of the the rankings like uh we have a bunch of projects uh you can you can just Google us. Uh so yeah uh very happy to talk if you are interested in either BitVM or finality stuff or want to deploy your your next Bitcoin app. And uh oh yeah uh last last thing I wanted

to mention is we have this BitVM accelerate organization. So if you're very interested in BitVM and uh you didn't get scared by my presentation on it, uh we have a bunch of people that we work with on BitVM. It's a it's a big lift to actually make this a reality. There's a lot of organizations involved. So if you want to be part of that also please reach out. Uh we are always happy to to chat to more people. Uh yeah and that's it. Thank you very much. So uh we have like time for one or two questions and please try to be uh precise. Thank you.

Thanks for the talk. Um when you say uh FPS can finalize Bob what does it mean with regards to um the fact that the OP chain has a 7-day where it can revert and same for the the fraud proof. I don't know what the window is for a native BTC paging payout. Uh yeah, this is a modification we're doing to opt. So basically uh yeah, opt has standard 7 days. Um that's just to get in the um the fraud proof in time. Uh but the fraud proof and standard opt uh takes a bunch of transactions. Uh that's why they need a long kind of timeout. Um our fraud proof um our froth proof is going to be zk proof. Uh so

it's just one transaction basically which instantly finalizes it. So, um, our current timeout or once we have it on mainet is probably going to be around 18 hours. That's determined by the Babylon. We're bing checkpointed via Babylon on Bitcoin. Uh, and we're waiting for 100 Bitcoin confirmations and that's about 18 hours. So, finality delay is going to be a lot lower. Yeah, thank you. So, one last question. Yeah, thank you for the talk. Um, I have two questions. One of them is uh splitting into four megabytes of blocks.

Um ZK Snark is you know sorry Bitcoin scripts cannot verify altogether as you said um at that moment that this means we need to rely service right uh to be able to verify um it's not going to be verified in a decentralized matter that's going to be one question. The second is about the disputes. So if there are three uh let's say uh frouds or four fras at the same time so it's going to be like 40 minutes because of every block is going to be confirmed for blocks in zk rollup or optimistic roll up it's going to be just you know much quicker than this one uh is this the drawback of

bitcoin or your service that's it thank you uh yeah for the first question um the cool thing with bitv we can actually do this uh with this trick of splitting up the verifier we can verify buy the ZKIP proof right now on Bitcoin without any forks. It's just expensive, but it it's possible. But it's going to be verified externally. No, it's verified on Bitcoin. Is verified direct the the the splitter of this proof you actually verify it on Bitcoin itself. Yeah. The proof verification is done on Bitcoin itself. Yeah. Uh and then uh if you have multiple faults basically and

and and violations uh yeah you just basically in this operator construction you just need to provide like one fault proof that shows that the operator was cheating and then you consider everything else invalid by this operator. Cool. Awesome. Thank you. Um I'll be around uh today so if you have more questions feel free to come. [Music]