Vea bridge: A permissionless, immutable optimistic bridging primitive | Kleros | ETHTaipei 2023

hello hello okay hello everyone let's work our next speaker chateola from clarus clerus is a decentralized arbitration service for district dispute disputes of new economy and he will bring us via Bridge let's welcome [Applause] all right thank you so I'm a developer at Claro's and we've been building a bridge primitive that we call veya um so to to give you a little bit of motivation um claros is a dispute resolution mechanism um why why are we developing a bridge um so you you don't need to understand the full details of what Claris does but I'll just demonstrate motivation for why claros needs a bridging solution and how it can apply to other projects so um one of the problems claro solves are real world problems so imagine you have some client Alice in Taipei who wants to hire a web developer freelancer in Argentina and instead of paying Bob the freelancer directly they're going to pay uh Alice will make the payment to a Smart contract that holds a payment in escrow and claros is an arbitration mechanism where if either party has a dispute claros will resolve it so Claris is an arbitrator but you can imagine any sort of Oracle input being able to resolve this dispute you need some sort of off-chain information and you need to bring that information on chain so in this case Alice wins for example so Claris was built for well it launched three years ago in in an environment where gas was very cheap you know maybe one gig away but clearly in the bull market many applications were priced out of mainnet and so now with the roll up Centric roadmap um how should oracles adapt to a roll-up Centric roadmap what happens when applications like query your Oracle live on different chains different networks different Roll-Ups and so just to demonstrate the point cleros for example is is designed for some high volume low value use cases so the escrow amount might be a hundred die in which case if if you need to query an oracle that lives on a different chain in order to do cross-chain communication if if you use native Bridges then it takes time but it's also costly so the cost of going through mainnet might price out most of your applications so how how can we solve this um one one idea would be hey I'm just going to deploy my protocol on every single chain this has drawbacks because if your Oracle derives at security from Economic Security when you deploy in multiple networks you split your liquidity and you split your security budget so the idea is to choose a home choose a home where you concentrate your Economic Security so in claris's case the Oracle we have is deployed on mainnet and on gnosis chain and our roadmap is for the version 2 to deploy on a single home chain and by the way you know home is where your node Is So currently we're you know comfortable having deployments on gnosis and mainnet those are permissionless systems um because currently all of the Roll-Ups are memes and their systems aren't permissionless and you can't participate in the fraud proof mechanisms whether it's optimistic or zero knowledge all of them are multi-cigs all of them are proof of authority with more steps but we've we've been shopping for a new home and there's a few interesting neighborhoods there's a few popular neighborhoods these neighborhoods happen to be optimistic rollups so you know arbitrary and optimism uh are the most popular neighborhoods but there are some risks involved so so some of the drawbacks of course optimistic roll up if you have an oracle deployed on an optimistic roll up doesn't have to be clearos just imagine any sort of Oracle you have a seven day delay and it you you have a cost of doing some cross-chain communication so how can we solve this well Claris has a solution so uh we've been building this bridge primitive called veya and uh we can Bridge messages in about two days um how does it work so uh Merkle trees are involved so on the sending side so on arbitrum there's a Merkle tree the incremental Merkle tree that maintains uh uh a compact state of all messages sent through the bridge so in this case the tree has no fixed depth the leaves are double hatched we're using ketchak hashes this isn't for any any sort of ZK application we we don't need a fixed depth but in incremental trees the most most efficient in this case so how does it work well we split time into epox so you you could imagine an Epoch is like an hour or so so the idea is that on arbitrim on the sending side anyone can sort of save the state of the bridge save the Merkel route in a storage slot in here for example in the first Epoch in in epox zero and sometime later after a delay on ethereum someone can make a claim after a delay so right now we think a safe delay is 30 hours why 30 hours well um arbitrim just the optimistic rollups don't operate um synchronously with mainnet the sequencer actually has some power to back date transactions 24 hours so because of this you might not know the state of arbitrum for at least 24 hours and then your node needs to needs to sync so we we think 30 hours is a safe time period for a claim DeLay So 30 hours later someone makes a claim and they leave a deposit and a challenge period begins so in the happy case after a challenge period the claim is accepted the deposit is returned to the claimer and we accept the state of the of of the Merkel route and anyone whose messages are included in that tree can relay their messages so in the unhappy case if someone challenges the claim they also leave a deposit and then someone can call the native Bridges to resolve this dispute between the claimer and Challenger half of the deposit will be burned because the claimer and the Challenger could be the same person and the other half is rewarded to whichever party was honest so the system is griefable this system is permissionless and therefore griefable so um someone could make false claims and also challenge themselves in which case uh they incur a cost because half of their deposit will be burned and they slow down the bridge for a single epoch but the thing is the Merkle tree is growing in size and it's storing all messages that have ever been requested to be sent from arbitrum to mainnet so this means in order to delay the bridge you need to spend a deposit or half of a deposit every Epoch so you have this linear griefing Factor so one interesting parameter of the bridge is that honest parties need enough liquidity to uh to challenge potentially malicious claims so is it safe so some of the implementation for veya is related to a ethereum research post that Ed Felton the chief scientist at arbitrim uh posted about and this is how to speed up or shorten challenge periods in roll-ups so the idea is that since the merge since proof of stake um yes since the merge um uh yeah like consensus is sort of working like uh like clockwork so so every slot time there's an opportunity for a block so so the way it's working is that so ethereum consensus has its own notion notion of epochs and in an Epoch you have some randomly selected block uh block proposers and those block proposers uh they they could build a block or if they you know if their Hardware is malfunctioning or if they have some network issues they might miss their opportunity to propose a block in which case you might have a missing block so the the idea is that on chain you can look at the difference between the block number and the timestamp to uh to check how many blocks should there be and how many blocks are missing um so what why is this relevant for uh for uh challenge periods for optimistic systems well so there are some concerns about censorship so if someone makes a malicious claim and uh an honest party actor wants to challenge that claim uh that challenge could be censored so this could be censored by block producers so this is a type of censorship that uh tornado cash was was experiencing where about like at some point fifty percent or eighty percent of block producers refuse to include any transactions to tornado cash but like let's let's say 50 of block producers refuse to include transactions to tornado cash that just means your transaction will take twice as long to be accepted so that's that's one type of censorship that people sort of call like weak censorship but another type of censorship that the Roll-Ups are worried about and optimistic mechanism designers are worried about is strong censorship and strong censorship is censorship of block producers not by block producers so what this means is that a block producer might choose to include a transaction which will challenge an honest claim but there could be some Network level denial of service sort of attacks maybe Eclipse attacks or other more sophisticated attacks at the network level which will Fork out a block that's been proposed so this is very difficult to accomplish there have been some sort of like academic papers or theoretical attacks on slightly modified versions of ethereum consensus but nonetheless if you have an optimistic roll up where you have an escrow contract on mainnet that has you know hundreds of millions of dollars of value locked then you have an attack Vector so this sort of attack is not insignificant so anyways point is uh if you have censorship of block producers if you have blocks that are forked out you can tell on mainnet if blocks are missing and you can build a statistical test of whether or not you think forking censorship is going on based on a risk tolerance so what's what's an example okay here's here's some complicated equation it's it's a statistical equation but the point is we can calculate for let's say you assume that 10 of block producers will not censor your transaction um then you can build a test which says something like in a two hour time period if there's more than 34 blocks missing uh then there's a one in a million chance that forking censorship could be going on so this sort of statistical analysis can give us a test customized for our risk tolerance of whether or not censorship is going on so here's here's like some statistics about ethereum and gnosis they share a similar consensus system uh they they differ that gnosis chain has a slightly different uh slot time so um so what what you see here is that the first week after the merge about one percent of blocks were missing uh on ethereum so this could be you know validators being offline or network issues and uh two months later four months later uh you you have better better uh yeah performance a fewer blocks are missing and then recently after the chappella hard Fork you had about five percent of blocks were missing actually the first day uh yeah in the first 24 hours after the chappella hard Fork there was like 10 percent of of blocks missing so uh block producers missing their slot to propose blocks um so what's what's the point here uh with with the censorship test we can develop a criteria that says something like in a given time period if more than two percent of blocks are missing then we should slow our system down then we should call the native bridge and we should wait for seven days otherwise we can go ahead with our two-day bridging time what this means in practice is that probably after hard Forks the system will slow down and once uh once uh block producers have a better Network performance the system will speed up again and we we can do the same thing for gnosis develop a test that you know in gnosis's case the sensitivity of our test is dependent on already the network performance of block producers so for nurses we can say if more than five percent of blocks are missing in a given time period then we slow the system down so so we we we slightly modify the happy path which is just that after a challenge period we accept a claim only if the censorship test passes so um just just to summarize some some features so features of Vega um I I try to like put things on positive light because oftentimes people use like a negative language to say what a system is not so uh but but I'll I'll provide a translation you know so so it's more more common for crypto natives but yeah so anyone can force the correct execution so in other words translation it's a one of n security or a trust assumption that you yourself can be the honest participant in the system to force the bridge to execute properly the system is inclusive so translation it's permissionless anyone can participate uh it's not closed off to a small set of validators or or operators the system is permanent or in other words immutable and ungoverned no governance parameters no governance token immutable contracts based on based on these safe parameters that are set when you deploy the contract um so you know and in line with that it's a public good so there's no token no rent seeking no fees um but because it's an inclusive system uh delays are possible so the system is griefable attackers can spend deposits to slow down the process but it's but the cost of that delay grief will increase linearly and they can only delay the process a maximum of the time it takes to call the native Bridge which takes about seven days eight days for optimistic systems um so this this sort of system can can be used to uh to send messages between Roll-Ups and different chains um so in particular uh what what I'm showing here is that uh the dollar sign shows you that using Vega rather than the native Bridges is cheaper much cheaper than going through mainnet because you you don't pay mainnet gas in the happy path or if there's a challenge it's very clear who's paying gas fees because the Challenger will reward the well whichever side is dishonest either the claimer or Challenger they're compensating uh the other honest party to pay for the gas fees to call the native Bridges um but in any case in the happy path you don't go through mainnet so it's cheaper so for example uh between arbitrum and optimism uh it's both cheaper than going through mainnet and it's faster so on the happy path two days uh and in the case where you're bridging from an optimistic roll up to ethereum for example the settlement layer it's fast uh not necessarily so much cheaper than going through mainnet it's about the same cost going from optimistic Roll-Ups to noses chain well it's both cheaper and faster because well block space on yeah there's more block space on gnosis less demand it's probably going to stay that way unless there's some crazy nft airdrop on on gnosis in which case demand for Block Space is really high it could could be more expensive on gnosis than ethereum but but yeah basically should should be much cheaper uh when the destination chain is gnosis the idea is in in the happy path you only pay gas on the destination chain you never pay gas on intermediary chains or or uh ethereum L1 um if you're bridging from ethereum uh you don't really have a benefit uh just just use the native Bridges you don't really have a big cost or speed benefit if you're bridging from gnosis to some of these optimistic rollups well you it you you can save some some transaction fees but the system isn't necessarily faster so basically this system is like Vega is a good design for an optimistic bridge between optimistic rollups or sending messages from and to optimistic right um so uh yeah we uh we're working on the test net deployment and uh we we want to prioritize maybe bridging to gnosis first and then uh we'll we'll see about other other chains that uh there's sufficient demand to to operate um and uh we're working on um via scan a way to view your messages and and see claims that are being made um so that's pretty much it I what what I want to to invite like anyone listening to the talk is that like if if you are working on a protocol that uh needs some uh cross chain solution um then consider yeah if if you're interested in this sort of bridging approach where you concentrate your Economic Security on on a single uh chain and just do message passing there's there's no tokens being sent around where we're just sending messages about uh output of the Oracle that you know if if your protocol is interested uh then you can participate as a watcher or validator of the bridge you can be your own security for the bridge um and if you're building uh some applications cross-chain applications uh you you could build liquidity networks on top or cross-chain governance um nonetheless the system works with uh one of an uh trust assumptions so you know even if clairos is the first user of Avea um and claros will operate BB one of the bridge operators uh running a watcher that's that's checking for fraud and and making claims about the state of of the Merkel route um basically if other developers want to use this uh this system in the protocol um you get your messages relayed basically well in a sense for free but uh if if you want to uh yeah participate in the bridging process then you need to run your own Watcher if if you want to be the one event uh honest parties in this optimistic system you have to run your own Watcher but otherwise you know we will be running this bridge and if you are developing a cross-train application you can write your own gateways to to bridge through veya and get your messages passed basically with no extra cost um yeah that's pretty much it uh thanks [Applause] hello Rose talk and does anyone has questions here thank you for the very insightful talk um we'll be curious to learn a bit more about um so the dynamic challenge period would be like reactively adjusted according to on chain like status or on chain um yeah the state of the chain are there any risks to it being a reactive approach versus being a preemptive adjustment before like all the missing blocks before all the potential censorship um like what are the risks involved and are there any good ways to like counter them sure so um right so the question is uh uh what what are the risks involved in using a dynamic challenge period um specifically like in this case dynamic means um you either have this fixed challenge period uh which right now we're using six hours um versus using uh well so so the challenge period is six hours or uh or you have to call the native Bridges if the censorship test doesn't pass so actually the challenge period isn't really Dynamic the challenge period is fixed uh the challenge period is six hours uh but um but if someone doesn't make a challenge uh you can't optimistically verify the claim uh so you have to use the native bridge in order to figure out uh the result of whether or not we should accept the claim um so like yeah at a high level you you could think that the challenge period is sort of dynamic but but in in reality the challenge period is fixed at six hours it's just if there's no challenge after six hours we don't accept the optimistic claim as true and verified we also check if there are missing blocks so it's not not exactly a Dynamic challenge period um yeah any any questions no okay let's thanks to Chateau again and before you leave two things wrong to I would like to share once our afternoon section starts at 1 pm here and the second thing is we have a beer party at 12 30 in the second floor of building M just write a just just Nest by our checking counter 12 30