Bitcoin and Beyond EP1: Citrea's ZK Technical Design Explained

Transcript

[Music] [Music] [Music] welcome back to bitcoin and Beyond today we have Orin from citria talking about building bitcoin's first ZK rollup looking forward to learning about the practice and the implementation of ZK in

Bitcoin and what you guys are building at citria welcome in Orin and glad to have you hey hi and Robie uh thank you for having me today I'm excited to present what we are we have been cooking so far and how it actually change bitcoin's future I can just directly start uh I'm one of four co- co-creators of craa we are building bitcoin's first CK up we have been working on this project before even all the hype and like the bitm paper came out around a year ago initially designed this as like a different kind of rollup but right now we are building Bitcoins versus EK rollup so let's get it started uh what is a rollup the basic definition it

confused all the people especially on the Bitcoin side of the things people don't get used to this kind of definitions so they often Skip and in it is also something very confusing so roll up by definition is a blockchain that uses another blockchain as the data availability and consensus layer okay where does the settlement fits in or the bridging or the ZK or the optimistic or the execution layer it doesn't matter it is not a part of the definition so the definition is very clear if you you have a blockchain and if you are using another blockchain to have your data available and so sort all this data so you have the consensus then you are a rollup it doesn't matter whether you are ZK or Optimus or evm or solonia so essentially why you should

build a roll up on bitcoin let's get into that and Bitcoin is the most secure and censorship resent block space running over a decade and uh it has a proven record on having a secure and decentralized network but it has limited right it has limitations on block size has limitations on script uh capabilities so what you can do with Bitcoin Beyond Simple payments is extremely limited today and this is a reason and I make I totally respect that reason but uh some people like us want to do more with their BTC want to do more with Bitcoin block space security so the thing is the modularity when you get modular you have this customizability what this means is now

if you have building a rollup then you can customize that rollup as as much as you can you can do p payment roll up you can do gaming roll up you can do evm roll up or Solon AVM roll up because now you have this flexibility to actually customize your stack H you are not dependent on bitcoin but you are building your own stack and as you are building your own stack you can also do some optimizations for example we will talk in a bit but ZK proofs State diffs general purpose comparation these are new things that actually can scale blockchains without actually changing to core block chain itself so that's the one aspect and the most important thing is Bitcoin is secure and all the layers built on top of it must be secure so if you are building a simple side chain you

shouldn't you cannot get this security by default because you are now trusting another layers consensus or proof of work or notes or data availability to actually store your data publish your data or do not transact with invalid blocks and other stuff so the security is the most important thing in Bitcoin and a layer should inherit the security and building a rollup is the like only way to actually getting that security if you are not building like a channels like lightning or mer Mercury which is still limited with bitcoin's functionality and the other thing is the interoperability issue so you can get some kind of Bitcoin security with let's say merge mining right you can build merge mine side chains which exist over

a decade still but you cannot get interoperability you cannot Bridge BTC from main chain to side chain because HH power cannot actually custody anything or cannot transact anything it can only secure the side chain consensus so you still need additional Federation or some other thing to bridge the BTC from one chain to another side chain so we are building roll up to solve all these issues we are getting full Bitcoin security we have this most rust minimize 2way Peg which I will talk in the slides that's the main thing uh that I will talk today so let's get it started in order to build a roll up you have yeah or can I ask you a quick question yeah so you had a very clear definition of a rollup and then and then you mentioned

some some of the differences between a rollup and and a side chain could you just could you just articulate what is the definition of a side chain how is it different from a rollup yeah so roll up has a strict definition but side chain doesn't have a strict definition so in my mind I have several categories like roll up a blockchain that uses another blockchain as the data availity layer a channel that works in peer-to-peer manner so you don't trust each anyone else but that's limited there's no Global State plasma which can build with utxo with offchain data but you still gain some limitations when you try to add programability and the rest of the stack is site chains you can build proof of work site chains with merge mining you can build proof of St

side chains with Bitcoin stake or you can be a totally independent chain but you can anchor some data to bitcoin for finality but it's still a side chain so there's no clear definition but in my definition it is it cannot ever get unilateral exit so if it cannot get ever unilateral exit I will say it's a s so dra UPS today on bitcoin doesn't have unilateral exit because there's no op code but in the long run if there's an OP code you can get unilateral exit if there's a plasma for up code then you can get and with side chains it you cannot because side chain is another chain that has its own security so you have to trust that chain first then you have to trust the P mechanism the bridge mechanism that will be my

definition cool and just uh followup there for for the community who's a little less technical um what is an OP code and then similarly for those who are a bit more technical is there a difference in op codes for Bitcoin versus um ethereum yeah so in ethereum you have these op codes but these op codes is not limited so you can actually writing you are writing solidity and you are writing so some smart contract but your guess is measured by this up Cod and it is to complete so you can actually build everything with that op codes in Bitcoin we have very similar op codes with ethereum but the main thing is the

number of these op codes and what they can do is extremely limited so there is no multiplication op code in Bitcoin scrip so you cannot multiply two numbers or there is no conization of coding script so you cannot actually concap two string and build an orle three for example so that's main definition while building building a Bitcoin script you have the set of op codes and you have this stack which your inputs are ordered and the outputs will be ordered and you are just getting some item from stack applying some op code and putting into stack again so you are doing that to actually create Bitcoin scripts and it is not to incomplete because you cannot do for Loops you cannot do multiplication you cannot do div division you cannot do modulus that's why you cannot do let's

say ZK proof verification the single scripts or something like that so let's let's continue how you can actually use Bitcoin as your data avable to actually become a roll up so it's a bit historical definition so initially in the initial days of Bitcoin we have this op return op code we we still have it so what op return provides is you can append eight bytes of data next to op return and it will be broadcasted across Network so you can actually use this to make a data available but 8 bytes is extremely small just an HH is 32 bytes so you can fit two two heshes let's say and nothing more so that was the issue and later uh there was a softw called

segit and what segit did is basically increased the block size from 1 Megabyte to 4 megabyte but uh Bitcoin doesn't get hard Fork unlike ethereum it gets soft Fork so in order to bitcoin older nodes to be compatible with segit what they did is they uh separated the block with the witness so now you have 1 Megabyte of actual block transaction data and 3 megabytes of witness data and this witness data doesn't have to get broadcasted to the older noes or they can ignore the wi witness data that's why Bitcoin softworks are backwards compartible and with seg we had this 4 megab of blocks but the script size was still limited with 10 kilobytes so you

cannot actually embed data more than 10 kilobytes and after that the next soft fork and the latest softwork was the Tap Root soft for which allowed four megab of scripts equal to the block size so this means that if you can now work with a minor you can actually mine a block which includes a single transaction that uh has the whole block space just like Tap Root Wizards inscrib their visard image so that's actually uh some people think about it and casy Rod armor a former Bitcoin developer come up with a protocol called orinal uh orinal is actually a meta protocol that index some satosi individual satosi and give some numbers but the inscriptions is the name of the

concept uh and what inscription is he find a way to put arbitrary data in Bitcoin script up to 4 megabytes so in the right you are seeing a Bitcoin script and what he did is simply put op fals that op if so that the rest of the branches never get executed in the full modes but they are still available in the script so you can actually publish data into Bitcoin but that data can arbitrary because it doesn't get executed in the blockchain so what he did is he just pushed some arbitrary B data and broadcasted to the network so now you can actually use Bitcoin as a data available to and and in the previous example before we had segwit

tap rot and ordinals you mentioned that the bit the op codes on bitcoin were extremely limited we couldn't do multiplication we couldn't do for Loops so we couldn't do arbitrary data how like how did that change why are we able to do arbitrary data now but we weren't even able to do multiplication in the past we still don't have multiplication or division The Tap Root segment is not about that but they're about increasing the block size and the script size so in op return you put you can put arbitrary data but you can put up to eight bytes which is way smaller than a regular ZK Pro for example the the small C proof you can only put two hashes but with t root we can we still cannot do all the

zp thing and like multiplication another thing but we can put four megabytes of arbitrary data which is like huge amount of data if you just let's say put it hash you can put thousands of hash into single block using that mechanism okay so it's not a it's not a limitation on the size but more so on the complexity of computation that we can do in a Bitcoin script actually the reverse the complexity is the same the opose are the same but the size is increased before that you could only do 80 bytes now you can do 4 megabytes but what you can inscribe is just arbitrary but the operations didn't change you still cannot do multiplication or division or other

stuff and when when people are are thinking about using Bitcoin for as a data availability layer what is the core tradeoff like what is the actual trade-off of cost versus using like one of one of these modular da layers if they're compatible with with Bitcoin rollups like like what is the actual tradeoff here and and um how how re how realistic is it to use Bitcoin at a data availability layer for one roll up or for a thousand rollups so uh if you use Celestia let's say or aail as your as your data availability layer then you are not a

Bitcoin rollup right the definition of the rollup was you should use another blockchain as your data layer so if you use Celestia then you a Celestia but maybe Bitcoin validum you can be or Bitcoin Optimum you can so you have to use Bitcoin data if you want to get full Bitcoin security if you don't care about full Bitcoin security but if you want to let's say only get some bridging you can use Celestia as a data Avail later or a as a data availability later and you can get this bridging but in that case you you cannot get the full Bitcoin security because for example in we are using Bitcoin as a data availability layer and all our full noes look every single Bitcoin transaction and extract the

arbitrary data from it and if it is a EK proof then it verifies it which means and it also takes that data and applies to the state which means that if there is a data on bitcoin and the proof is on bitcoin then that's your canonical chain but if you celest your ail you have to trust that chain to make the data available to actually not reorder the chain not reor the chain so you get all the security depend on that chance but if you are building a Bitcoin rollup you should use Bitcoin you must use Bitcoin as your data layer so from from your perspective is it is it a an ideological alignment posturing to use Bitcoin as a data availability with a

desire for high security versus users and developers wanting to build on something that is is cheaper and more scalable like how are you thinking about this from from your perspective I think it's Case by case you know if if I'm building a like very if I want to build a like highspeed gaming chain I wouldn't use Bitcoin as a DA layer because you don't need that much Bitcoin security and you don't need uh that expensive transactions but if I'm building a like Bitcoin back loan protocol let's say an a fork or compound Fork I want my Bitcoin or USD to be secured as Bitcoin and not with some other chain I think that's the where

trade-offs began if you want to do high let's say high value transactions you should do it on bitcoin chain but if you want to do let's say low value transactions or don't care about the security that much or want high speed or low cost you should use other layers as a DA layer uh to make it actually like make user experience better cool and then just last thing here I don't want to get too caught up but but it's important I think is the security practice of using like Celestia or Avil uh in this case in these examples uh more secure than a side chain with a small number of nodes that is running like a delegated proof of

stake consensus or is it it's kind of dependent on the decentralization of that side chain but how are you thinking about the difference between chains which use like a modular da layer versus side chains which are separate yeah I believe if you are building a validum let's say you are building C but you want to use the layer for like you want to use another layer as your da layer I think it is much secure than side chains because you still have this DK verification on the main chain so it cannot actually steal the money but maybe free freeze the money it is definitely secure than most of the side chains today only one or two side chain can be secured on that construction so okay we figured out how to embed data

and uh so what should be embed and now we have this distinction between the rollup types so we have three different rollup types very broadly uh pessimistic rollups I think there is no rollup like that but uh some sdks are working towards it the pessimistic rollups just embed full block data into the underlying chain and move on and optimistic rollups like most of us know they embed full transaction data and a state rout so after a week if no one challenges that State Route it becomes valid and there can be settlement if the chain prefers but what they uh put as a data the huge amount of data is still full transactional data and on Z care

Ops you have two options one is full transactional data plus the proof or you can use State differences plus the proof so what state difference mean and full transactional data mean is if you have a up then we call it full if you have a block we call it full transaction data if you put all the block into the underlying chain this is full transactional data but in zops I think it was first stet or ZK syn I cannot remember they use this technique called State diffs which actually you input the block into ZK circuit and the output you say instead of giving full transaction data you only need the difference between the initial State and the latest

State because you just want the data you don't care if the proof already asserts that the execution is correct you don't need the full data you only need the difference so if you use State difference and proof it makes the data much more scalable because if you are using the same Unit web pool let's say until the proof is generated if everyone use the same unit pool only balance uh the state will be the only the balance change between the first Unit web transaction and last un web transaction but if you use full transactional data you have to embed all these transactions into the underlying chain which makes the data expensive so we are using State diffs plus proof construction to use Bitcoin very very efficiently because

Bitcoin da is already limited and it can also fit no more than for Megabyte so we have to use it very effectively and we use choose to use the state differences plus proof mechanism because we are waiting proof to be generated and meanwhile people do transactions and I S money to everywhere and only my but difference between the initial balance and the latest Balan is recorded on the Bitcoin which makes the data usage very very efficient so okay uh we we correct it we build our roll up we sent our proof and state to the Bitcoin and now we built a all up but on bitcoin the two thing is I think the most important part the one is the most secure and censorship

resistance block space now we have it because we are using Bitcoin as our data and consensus there the other thing is the BTC asset it is over 1 trillion sitting in the Bitcoin main chain doing nothing than payments but in order to use this BTC on the rollup you have to have some secure bridging or settlement solution to people to deposit BTC from the main chain and mint on the L2 and burn on the L2 and get back on the L1 so so so far landscape was like on the left side there is custodial Bitcoin Bridges we know wbtc on and there are Federate teral Bridges like root stock BTC and liid BTC the OG Bitcoin side chains and now there are third

generation of uh this BTC Bridges cryptoeconomics security Bridges like sbtc and tbtc sbtc on stacks tbtc on eum so how they work is Federated threshold is you just trust a majority of a federation or of a committee let's say there's 10 people and you are trusting that seven of them are Hest in cryptoeconomic security you are still trusting a federation but that people actually saes some other assets it it cannot be Bitcoin in most cases it is some other assets let's say in St case they stake STX and I think in tbtc it is the T token I'm not sure and they stake that asset and if they steal the money

then you can slash that asset but there are some issues with that because you have to have some Oracle to actually like secure the Peg and if the the stake token is too volatile then you can uh Bridge which can be stolen that people can leave with a price so these are like great construction back then but right now we have better constructions so the most important thing is the native settlement that you can get and right now there are two options to actually verify ZK proofs on bitcoin one is not possible today because you have to verify the ZK proof in Bitcoin scripts but like I said in the beginning there is no toing completen on the Bitcoin script and the block size is limited so you cannot actually verify ZK proof

in a single script in Bitcoin so it is not possible if we can get not get any op code let's say op zkp verifier right if we have this op code we can easily verify but there is no op code that can provide this functionality so given this idea a researcher called Robin linas last year started ideating some uh things how we can verify Z care proofs on bitcoin and he actually came up with the idea of BVM the initial of with VM was like a different protocol it now like pivoted more towards a different thing but eventually what it provides is you can optimistically verify ZK proofs so as long as everyone agree with the ZK proof you don't have to do anything but if

someone dis agrees with the ZK proof they can go on chain and put an alert to saying that this ZK proof is incorrect and in couple of transaction you can actually assert that the ZK proof is incorrect or not so instead of verifying in every single single time you just make it optimistic because it saves you from a lot of cost because this fraud proof transactions are too big and the transaction costs are too high so that's the core idea behind BVM and then we introduce Clementine our BVM based uh two-way Peg also known as bridge program so I put 1.5 there because right now there are two variants of BVM one is BVM one and the one is BVM

2 BVM m 1 use a close set of people with a risk five like architecture and bit vm2 has this permissionless idea with a zkp verifier and in Clemen time what we are building is somewhere in between we have this close set of participants but we are not building up on a risk five verifier architecture but a ZK verifier architecture so we have with Clementine now the core idea is you can get optimistic settlement for Z Carol Ops uh this is extremely unique and prob a bit complicated because in ethereum you don't need that you can just verify ZK proof in some other chains you can just verify ZK proof but in Bitcoin we try to correct the best way of building a ZK

roll up and we come up with this optimistically settled ZK up idea and Clementine provides the optimistic settlement part of this product and the core idea is aggregate the proofs from Bitcoin uh because you use Bitcoin as da layer all the proofs are available you just aggregate the Bitcoin proofs from Bitcoin uh to settle less frequently because you cannot settle in every single block it may it will be like expensive so we are just inscribing the data and wait a little bit and then once all the B is inscribed we just aggregate these proofs and eventually we have a single proof representing all the C estate and then there is this operator person who front covers all the

withdrawal that is requested from the rollup and eventually operator says okay I aggregated these proofs these are all the withdrawals I did all the withdrawals and this is the whole ZK proof saying my statement and there is this close set of participant let's say there are 10 participants and they verify the ZK proof and if everyone verify they just sign a transaction and move on but if only one of them thinks that the ZK proof is incorrect they can go on chain and challenge the operator so that the operator if if operator lies it gets slashed and kicked out so your money is still secure and the trust Assumption of this mechanism is we call Trust minimize

because now you have this one of an assumption as long as one person in this n people is honest then your money is secure and remember previously in crypto Economic Security in Federation threshold you have this majority assumption as long as majority of 10 people is honest then your money is secure so you have to trust multiple people you have to trust seven people eight people of 10 but in here if you know only one people of the participant only one person in the participants then you are secure and your money is secure so Oran I I find this uh this one of n uh fraud proof mechanism fascinating like how does how do the block how does the blockchain operators

how do the miners how does everyone know let's say let's say the three of us are verifiers and let's say let's say uh Orin let's say you're telling the truth and Andy and I are are lying and there's two of us but there's only one of you how does the blockchain know that you're telling the truth yeah so the be is with BPM is what they do is they get a snar verifier in Bitcoin script but it is let's say more than 100 megabytes so you cannot put it into single script and they divided this script into multiple chunks So eventually you can do let's say bsection or you can just

reveal all the intermediate steps and someone can directly challenge the intermediate stuff so what happens is if you actually I'm truth I'm the correct one but you say okay your ZK proof is wrong right you go on chain and say to me that execute this Branch execute this chunk of scripts and I actually execute it and eventually if the script returns true which means that I am the truth and you are the liar so your St is slashed that's why that's why it's trust minimized if you don't get onchain evaluation you cannot do trust minimization because it's always on majority uh but with this ZK proof ZK verifier divided into multiple scripts we can actually execute some selected

part of the scripts to determine who is correct or who is not without going through all the verification steps of the huge script and what what if we um what if we kept playing this game like what if we kept kind of like going down deeper and deeper and and um kind of like checking right we would ultimately kind of like refine the the data that we're checking wouldn't that take a very long time yeah yeah so in the bitm one it was 40 transactions so in bitm one we have in the worst case you can challenge me

until 40 transactions and eventually you will be wrong so your all transaction fees and all the Stak is gone but it can actually freeze the bridge for months let's say because it will take 40 transactions but with with vm2 they find a concept that I call this intermediary uh steps instead of doing bisection over chunks they did this intermediate step trick so it is only just one transaction so if you give one transaction a week similar to eum optimistic roll up then you can only challenge me one you say that reveal that step and I reveal and if I'm correct you just kicked out if you point out another script it's already incorrect so you are already kicked out so you can actually

uh freeze the bridge only for one week which is very similar with aium optimistic RS got it and in ethereum rollups the 7day challenge period is still quite arbitrary what is what is the rationale behind the the seven day kind of like standard that that we've landed on you know could we make it shorter if so how do we do that yeah I think it's about the Bas layers how long the Bas layer can actually like uh censor you like any party so in ethereum researchers did some research and agreed on like seven days is the spit spot for baser to like because they did some economic analysis

if you get let's say majority of ethereum stakes and if you censor transaction for seven days your state has to be let's say a billion and all the optimistic rollups let's say back down was total less than a billion so it was not feasible so and they they picked seven days and on bitcoin the rational is very similar and as Bitcoin is like with hash rate it is almost impossible to censor a person uh for seven days you have to have this uh 51% dis majority for seven days which cost a lot in in an economic sense so they choose seven days for single transaction but but on eum in 7 days you can do multiple transactions so there's some different parameters but I think the BPM researchers just select

seven days because it it's kind of standard for optimistic scroll ups and so in in the in the bit VM 1.0 case it was 40 transactions uh bit bit VM 2.0 it's only one transaction um and so that has shortened the time quite a bit in this bit VM 1.5 case that you guys have with Clementine what is is there a middle gra have you it's still just one transaction for seven days yes yes we we got this one transaction trick from bitm 2 and we kept the permission set of verifiers from bitm one so there's no naming like bitm 1.5 but I just call it while telling about this for to

people makes sense um yeah cool yeah I was just going to ask about the top the top bullet is the settle of proofs is it kind of done on like a as needed basis with an arbitrary value of time or proofs or is there like a programmable setting in clementine which provides like if this then that kind of texure in clementine this is three weeks fixed in every three weeks this roll up settles and that is some things because in clementin we have actually like we have this one transaction to challenge but we have two transactions because one is to give the

input on chain and the other is the resolve to input on chain so each takes one week and we give one week period to operator to settle all the withdrawals So eventually we are settling in every three weeks it is fixed it is not weeks by the way it is just some Bitcoin blocks but if you multiply that with 10 minutes average time it is uh three weeks yeah and one of the core pillars in the beginning was around interoperability um by being roll up with something that you guys um value highly when it comes to uh having this 3-week uh proof aggregation window how do you think about interacting with interoperability providers to ensure that there's not any sort of

catastrophic like state reorgs or just general kind of mismatching of States when it comes to interacting with other rollups with different aggregation times or even like side chains yeah so this the settlement happens in every three weeks but the proof generation and inscription on bitcoin happens in every two or three Bitcoin blocks let's say once in every hour so we actually put this proofs in Bitcoin more frequently but we only settle less frequently because the settlement is expensive with bit VM even with bit VM so we are just inscribing this proofs on Bitcoin in let's say every hour so other rollups can read the proof from there and execute based on that or other chains or

side chains can read the proof once in every few hours so they don't have to wait three weeks this three weeks is only for to have this Bitcoin L1 Citra breach so if I'm if I'm a a separate rollup or a separate interoperability provider the maximum time that I'd be looking to wait for like a confirmation of a state transition would be like two or three blocks yeah uh in two or three blocks we prove and put the proof into Bitcoin and if it depends on your configuration if you just want to use that data you can use or if you want to wa some reor blocks you can f three blocks or four blocks or five blocks depending on your

security uh config and just a another followup to that interoperability question and and you sort of touched on this by by describing the settlement of L1 to to the citria bridge like what is the difference between inscribing the proofs into the Bitcoin chain and the and settlement like what you know to to me it's like if I inscribe the proof into the chain that settles the chain onto Bitcoin L1 what's the what's the difference between inscribing the proof and actually settling uh to bitcoin so uh in the beginning I showed this right you remember this this is op false op if then the inscription data then op and if

so in this script what happens is this Branch between op if and op and if is never get executed because it is meaningless it is just bite data and once we inscribe the data here Bitcoin script doesn't understand anything about data it doesn't even go into that Branch it just skips the branch because it is false it's not true so it doesn't have to get in there so this once we inscribe the proof what we gain is other full nodes can look into Bitcoin and so see the proof and verify the proof so locally if you are running a full mod you can make sure the state is correct but Bitcoin still doesn't know that Bitcoin still doesn't know anything about your rollup but your full not know because you just look to bitcoin you so the proof you verified it

and now you're good and with settlement Bitcoin script actually knows that this proof is correct and then it actually allows movement of the utx SCE between the bitm and the withdrawal people okay okay so that that's really cool because like yeah it it means that correct me if I'm wrong but it would mean that like that First Genesis block that Satoshi did where he said National Bank of Britain on the brink of collapse right that was like the first inscription yes exactly he inscribed first arbitrary data into Bitcoin blockchain and now we are inscribing CK proofs into Bitcoin

blockchain and we're also like making memes of it and trading runes and shitcoins and um yeah having a blast yeah H people like shitcoins and they like BRC TNS and r which are like very similar protocol with rollups actually you just inscribe arbitrary data full notes read that data and create a meaning of it Bitcoin doesn't know whether it's a BRC or use it is just some utx so in this sense it is the same it is just some ZK proof but Bitcoin sees that it is just some utx so until it gets settled with okay and the last slide uh craa so if we collect all this pieces together we have a z that use State diffs in

scrap the proofs and state diffs into Bitcoin and optimistically settles to enable the most trust minimiz and secure Bridge we call the craa so citrea uses its native token and guest fee token is BTC the data availability is Bitcoin and in the future it is volution I can touch on this a little bit and this other is sensorship resistance it's with Bitcoin miners as we are roll up we have access to this Bitcoin data trustless and uh we will enable this Force transaction mechanism meaning that if the sequencer sensors you you can just you use your transaction to like inscribe the transaction into Bitcoin and the sequencer has to execute it because if not the proof generation will fail and

the sequencer will get slashed so the idea is you you get Bitcoin level of censorship resistance Bitcoin cannot censor you and won't sensor you so dra up cannot sensor you and the reor existance it is still on bitcoin because the proofs are inscribed on bitcoin and if the chain doesn't reor then your chain is also the same the bridge is Bitcoin settlement by BVM Clementine execution environment we are building our own ZK evm type two fully evm compatible and the block times we are targeting two seconds or three seconds yeah so let's dive into the volition in the future conversation um what are you guys thinking here yeah so the volution is like a hybrid blockchain

mechanism in blockchains you have this Merkle tree we call this state tree and the root of that tree represents a unique hash of that tree so involutions what you do is you divide that three into two you already have the left branch and right Branch but you divide it into another two so the you call this left Branch let's say onchain data and you call this right Branch with offchain data and the both of them roots are still available on ZK proof and the M main route also available on ZK proof but what happens is you only inscribe the state diffs of the left tree but not not right tree so if you let's say want to deploy un web Fork you can deploy on the left three so all

your transaction is available on bitcoin and you have this full Bitcoin security but you have to pay this da fees because you're describing data into Bitcoin if you deploy your fork on the right side of the tree you still get this ZK proven thing so your proof is still valid you still get this BTC brege but your is kept off chain within the sequence run full mode Network so you don't have to pay any da fees only one cent or let's say less than one cent so in this manner they can these two unit we Forks can interact with each other because they're in the same Block Chain they're in the same tree but one data goes onchain one data goes offchain and the one is extremely cheap subs and transaction

other is a bit expensive but it gets full Bitcoin security so depending on your usage if you want to deploy now a gaming application you can use offchain data it is very cheap very fast but still get this BTC and interoperability if you want to use build a Bitcoin back stable coin application you can use onchain data so your stable coin is fully onchain secured fully Bitcoin secured a bit expensive but you still get this interoperability between the gaming application and the stable coin application yeah so um this enables like multiple use cases from Builders kind of give you a more diverse ecosystem basically assessing where your tradeoffs are this might be a silly question but like what if I find myself right in the

middle I want both security and I want cheap fees what do I do uh I think uh there's no such trade of exist right uh if you want to get like security you have to pay for it and Bitcoin is kind of Premium block space it's not not that cheap and it shouldn't be cheap uh because the miners should be incentivized to mine the chains so it should be actually expensive and block revers should be high so if you want to get full Bitcoin security you have to pay a premium but you can still get some kind of Bitcoin security with the ZK proof the proof verification the trust minimization and interoperability but you can use offchain da it's slightly reduced security but it can be extremely cheaper so I think there's the tradeoffs

are always there even on ethereum like the main chain rollups there are some significant Security tradeoffs even though costs are like extremely different it is not the same level of security and in here the other point that I wanted to touch was the data available to part of Bitcoin right I said Bitcoin alignment it's a silly work but uh it's actually real bit because in proof of work in the long run you need fees to actually boost the HH rate right we we had a Hing and we will have another hening and another and another until the fees go to like the zero level the work level goes to the zero level so in each hening we actually have to users have to pay more fees to keep miners incentivized or the Bitcoin price should

be double in every half week or both so as long as you pay more fees on bitcoin you you increase the hash rate you increase the security of the network and you contribute to like this this you fix the long-term security budget issue that people call so if you are using Bitcoin as a daily which means we are paying thousands of dollars in BTC to Miners and keeping them incentivized and to mind the chain and actually get get back more HS yeah that I was going to ask about that um kind of how you guys are like how you see citria contributing to bitcoin it's like bigger than just citria chainway it's like the broader ecosystem scaling Bitcoin as a whole it

further contributes to its security Now on that point and I know Rob's got something then we're going to wrap up do you see yourself ever having like a citria stack where Builders can come and build new rollups using citria Tech either like a layer three or like a like hosting an ecosystem of citria rollups outside of just the main chain itself mhm so craa is stack is extremely unique so it is like an early Fork of sovereign SDK you had Jam last week I think in here uh it's early Fork of s SDK we now like collaborating with more efforts to like merge this CH get this efforts

together but eventually it is extremely difficult to adopt to other chains because it is specifically designed for Bitcoin with with VM and no other chain has this trade off all the evm chains or celesa ZK accounts and a they don't have this tradeoff we built it specific for Bitcoin but the funny thing is it is fully VM compatible layer too so if you want to build gaming application you don't have to wait for Vol you can copy an obac roll up Deploy on craa settle on Citra but use aail or celest as your da layer and you can build your gaming application so all the infrastructure built for etherium can be run on craa easily you can get share sequencers you can get ltres you can get OPC chains you can get blow stream you can get Vector X

all the bridges just Deploy on Citra and work on your customized chain so our goal is not introduce our own stack because Bitcoin is extremely unique and the data is quite limited so you cannot actually build let's say thousands of rollups on bitcoin right it will compete with each other but you can get come back with Al trees and other infrastructure built on ethereum but run them on craa so that people can customize their stack people can customize their application environments and use any other D they want awesome Orin well that's all that I've got um thank you for your time Rob do you have anything else yeah I guess uh I I've just got a couple like unre like somewhat unrelated questions which is that like you you briefly alluded to

this but how uh how much less would could we expect transaction fees to be on citria than the main chain yeah as it is State diffs it really depends on the usage but uh we did some research on like the average Bitcoin the medium Bitcoin fee and the fees of regular Unis transaction is somewhere between aium and eum l2s eum rollups uh so it is not as cheap as like eum l2s because eum introduce blops eum has this already has the settlements so it is it has rollup Centric road map Bitcoin doesn't do anything for rollups uh so it is kind of in between them it is not as expensive as ethereum depending on the usage but it is definitely expensive than eing

rollups got it and um and and is there any data at the moment as far as like you know uh transaction fees per block that that we see at the moment before like rollups on bitcoin and then how how do you expect that to change do you expect there to be like 10 times more transaction fees 100 times more transaction fees per block yeah uh so we had this research abouta can if you do 10 times more TPS than Bitcoin we only take quarter of block which means we can go up to 40 times more TPS than Bitcoin uh but if you have multiple rollups they will clash with each other because they will compete for

The Limited block space and it will increase the fees uh but in the short term I don't think there are like other rups as near production as us uh hopefully we will have a public DEET very very soon maybe once this is released we will'll be already live on bitcoin testet and in that time we will have more concrete data to conduct these analysis and share with the users and researchers nice yeah I was going to say like at what point does the Band of Brothers trying to secure Bitcoin for the long term diminish when you have so many rollups that are now causing the transaction fees to be so high like where does this kind of

balance it's going to be interesting yeah I think it really depends on the usage if you have more good applications or and more liquidity why people won't use other rollup for the same transaction fee so they will come to you and eventually the roll up has the most users and the most liquidity will win the block Space Race and the other won't be survive I expect there will be only like two or three Bitcoin rollups that is actually uh the actual real rollups that use Bitcoin as a DL but eventually you can build trees on Citra that settles on other that uses da layer of Citra sorry of celestian ail so they can be extremely cheap or and they will be compete with Bitcoin block

space love it man very very cool vision and um absolutely amazing conversation and presentation thank you for coming on and um chatting with us today man thank you for watching me guys