Bridging non PoW/PoS sidechains with Ethereum

Transcript

is it okay to start so hi good morning everyone thank you for coming I'm Claudia today I'm here with Donna and we're gonna talk about

bridging nonpolar side chains with ethereal so as first slide just some motivation introduction as many of you will know many crypto project have been built aside seems to be theorem this is due to the classic issues of scalability interoperability or update ability but we would like to focus on the single purpose sightings as we consider them that they bring lightness and agility to etherium and they add capabilities and functionalities without a brand into theorem however any sighting when you're

working with a site and you muster guarantee some security awareness you need to guarantee a secure interaction of course at first any sidechain is vulnerable to civil attacks and we're not sharing the consensus algorithm you even sometimes it's hard to guarantee the update ability so the TOC structure is going to be we're going to talk about breach interaction like very basic and transaction verification block headers reporting which includes a voting committee selection and finality gadgets then we'll talk a bit about be less on

how they improve efficiency and to finish the winner beat workflow to sum up so now thank you okay okay listen and we're talking for for just for you to have some context we're talking about single purpose side chains in this case we will showcase the this sort of protocols through example which is wit net which is what we are building in the sombre lab which is a decentralized oracle network so thin that this actually works for many

different protocols but for the sake of having a specific case you can simply imagine how some terms that are specific to win it would translate to your own protocol of choice so we need in this case is a single purpose oracle sidechain oops okay in in theorem and it's incentivized by talking rewards and there's an algorithmic reputation system so basically there's a system that tracks the performance and their reliability of the notes in the network and we will explain later how it works and and why that's important in why protocols that

use this scheme of cited entry theorem through this system should have something in that line in this case we are talking also about fully permissionless protocols okay and but particularly also about sightings that may or may not have their own token okay it's not that an assumption that it needs necessarily to be the kind of sighting that uses the same token as they as I maintain so what's what's this with what's bridge interaction we we call bridging to the fact that in some way you need to pick one chain to another or connect one

chain to another you need to some way to communicate both change them the side chain and then and the main chain and this communication in our case is achieved through a contract that needs to exist in there in the theorem maintained which we call the wbi there wouldn't bridge interface by for short it's a bulletin board where you want to it's just for posting in this case data request so the tasks that you want to offload into the side chain and into the sighting that will access an Oracle but you can think of things of very different things like I don't know like Gollum or five coin or things like

that where you have a like a sort of second layer protocol that is single purpose for doing some sort of computation and and and yes you just keep did you just care that you want to get the result back at some point with some guarantees so who's in charge of that communication that's the bridge notes the bridge in in a classical sighting scheme or something like a drive chain you would have miners been mining into in both chains but in this case if one wants to not to rely on proof of work or even on proof of stake

their alternative schemes which is what we are exploring here in this case these dis nodes relate in transactions from one chain to another will need simply to monitor the state the status of the of the contract of the bridge interface contract and relay their requests from one network to another and one their requests have been resolved they will be in charge of relaying their their results back it's important that they are economically in the device to do so in this case the the way we we would love it to work and the way it works is by having these nodes earn eath which is

paid as fees and when when when someone requests data from a theory on contract and spend with in our case but in any other case they token thus that is native to the sighting which could be if also so that that's that's indeed the most robust way to do it and then there needs to be some way to selecting which notes will be in charge of doing that because we want the bridging scheme to have the same degree of permissionless nests as there as the sytem itself or as the theorem itself and for that to happen we need to have some mechanism for for choosing those

notes and in our case we decide to go to to go with the with a verifiable random function which is a noble creature graphic tool that we have today that is being used also by five coin and alga run and it's becoming more and more common and and and the idea is that we can basically do this certain select from a pool of rich notes like a few of them and that will by turn be in charge of relating the transactions then there if we want to relate transactions from

one 22 from one thing to another we need to have some way to verify those so we we use something that everyone will be familiar with SPV simple payment verification it's a protocol that has been used for more than 10 years it's free notifications pretty common in not settle in Bitcoin for example and idea is that I can prove the fact that some transaction was included in in a block by simply providing the America path which is the minimum set of data that you need to prove to prove that some the cryptographic commitment from one

transaction to to one block that's exactly how light clients are created and how they're how that's the point of using a miracle tree when creating blocks at the end of the day so the idea is that you can present a compact a very calm efficiently verifiable proof of inclusion that proves that that transaction actually comes from with net and that that's the result for the data request if you think of any other protocol proving that that's the actual result from from one request sent to that obviously if you if you want to verify against blocks transactions

against blocks transactions against block headers you need to have some knowledge of the block headers in the maintained inside the the in our case that bridge interface so you will probably need to bundle some block relay scheme in there so basically what you are doing is replicating in our case if we have on one side etherium and in the other side the witness chain we need to build a light with the client inside a solidity contract and eevn contract on etherium okay

so the way it has to to access those block headers is having those block headers to start on in there on this IBM contract and for that we can leverage the same reporters the sense a set of notes that will be relaying their requests and the results from one side to another and we need to provide some incentives for them to do that also and for sure we will have to handle chain Forks finality and so on which Claudia will explain later and it's it's really also how it works so for for a really really easy example of how this kind of relaying works with Wynette is a little bit more complex but

we at the end of the day it boils down to a scheme which is very similar to the BTC relay which is something that has been operating for four years to means anything and basically something that allows you to verify Bitcoin transactions from etherium contracts and the the the mechanism is quite simple basically there are related submitting between blocks to the to the to this contract that exists in a mysterion and as Bitcoin is using proof of work proof of work is super easy to verify super efficient to verify you just need to do some hash of some nuts and some data and you just verify that and you can follow

the same logic for the fourth choice rule inside the theorem contract so you can simply have a probabilistic finality of tea after a while and and and so on you're really familiar with that the thing is that from that moment on any bit contraction can be sent to the contract for verification it's actually on it's it's a call so it's it's it's it's free it would be free all the other thing is that these are done through transactions because you do you want incentivized there relates to send the blocks so the idea is that when someone sends a block to the block relay they are promised

that they will get a share of the of the fee or they will get the fees for any turn sections that are verified against that block for any transaction that belongs to that block every time someone verifies a transaction that belongs to that block they will get this a small fee so the problem comes when you're not using proof of work when you're using proof of stake or if you are using things that are not necessarily proof of mistake but more in the lines of BFT protocols so in that case verifying is not that easy and you have difficulties with finality and you will probably need

to have a lot more context and information on what's going on on there on the side chain what's the state the world state and and and Claudia will we'll explain later so the problem here obviously with with non proof of work chains is that you can trivially forge block headers that may include or exclude transactions of your choice if you're an attacker and you could basically construct a proof of inclusion for for those transactions and for the for the made-up header and and that would be very easily readable and to the

wbi and it would accept it and it would store it and you have basically forged this contract from the actual site end so we don't want that so how do we solve that so there there are two important things for preventing that one is as really finding a really smart and sensible way to to have these voting comedies so basically make the nodes of the sidechain vote or a test what's the status of the system and what where the chain is what what's the best blocking the chain and so on and then having some finality gadget which is

some mechanism for having reasonable finality in an eventual finality so Claudia what will explain how how it actually works right so a sedan is just said one of the most important parts of the integrity of the blog headers to be reported is selecting the right vote in committee at first when we had this discussion in wit net the first thing that came to our mind was thinking why not reach notes since they were already connected and in

touch with them with the wbi but as witnesses fully permissionless this was a set of notes that were easy they could be attacked by a similar tax and then why not then just the known identities in in with it well this is a highly scalable because of course you don't know how many notes you have and you can't limit the nodes of the of someone just spinning up notes so we decided to have the active reputation set as it was the set of active notes that have proved that they had unknown its behavior in

the last epochs for us than we use in witness a reputation system was um I got said but of course depending on the side chain that you're using on the consensus you have this could change but the thing is they're only honest notes that you trust and because of BFT assumptions you know that at most one third of them of the notes will have about behavior then we had a collateral on coinage in order to prevent them other attacks and we know the RSS the errors is limited with respect the

velocity velocity velocity of the of the network that didn't happen with their known identities so the area's important thing is is that is the set of the nodes are going to be in charge of proposing block headers to the block relay so the next thing to study was them finality got it that we wanted to had implemented so the problem here is we have a blog or a prop header that has been finalized voted for enough members of the voting committee that would be this one and then more blog headers are being proposed supposing chains a a and

B so therefore it happens on how do we manage this situation so today work where I'm going to do is just explain in a very simplified way the solutions that have been implemented in the cosmos Kasparov of TN and Grandpa so for cosmos is a very simple way to do and manage this situation we have an reporters and unless two-thirds at least two-thirds of the voting committee agree on on our blog you don't get finality so the block is stop until you get that was two-thirds so suppose we have a hundred reporter in these situations we have 50 of them voted for a chain a on 49 14 B

then the block is just as I said I mean the Chinese stop until you get the the 2/3 so they need to keep voting until they get it third in this case for example they get a t14 a on 2014 B so the China is set as the good one the valid one and this new block yeah it's a tosser final so of course this is a very nice simple way to do it because every block is gets the two-thirds but it suffers from like this so another approach was the Kasparov of T this is

for side chains that may have high velocity the velocity of the network and in which you would need to get finality of a lot of blocks so what they do is that they select them checkpoints that be set of epochs so every any box the reporters or the voting committee needs to to vote to get finality again you have the two thirds so when a block gets the two thirds of the votes and they agree on on a block the blocks between the checkpoints are finalized as well so this is nice but the thing here

is that there exist blocks that they per se didn't get there two thirds so grandpa is another approach similar to to the one in cosmos again we need we get the two thirds of the votes in each block that has been finalized but what we you do here is you can continue voting so for example here suppose we have an reporters the some epic 20 of them voting 14 a 30 of them voting for Team B then they click on T they can continue voting and you take out the the

the rest of the voting committee that didn't vote at the first epoch so you take for example at chain a another five in the next epoch 25 foot in chain be another 5 in next step of 14 a and another 15 thing so in the end you can't and when you get the 2/3 of the other voting committee if we had one a 100 people this would happen in chamber you can see there is finalized the first block of the chain that you set as valid and meanwhile the other the other chain this case a is just cancelled and then you start again with the same procedure

for the next epoch so just a quick quick recap of what we have seen so far we have a WPRI this contract in in aetherium that is in charge of the transactions between the hesitance a between a we need a side chain and ethelia Mazar maintained that needs to have some knowledge of the block headers in with it and for that we have the block Steiners over voting committee in our case a us the active repetition set the vote for a new block Heather and when they get the to Thirsty's are the dozen you look Heather so now I'll talk about

BLS but very quickly the thing the classical thing that we have here is if we want to report and take into account in the block Heather's have been reported for the voting committee we usually what we have is that every node in the in that set is proposing is proposing a blog header and then you have to verify every signature then you get once they are verify you count the blockages that have been reports this and as if they agree or not so the thing here is the cost is very high if you have a big number of nodes in the committee and the voting committee said

um so this would be yeah that's caused a 40k a pair it the number of notes that you have to verify so what we like to have is in some way have just one verification to verify each of the members of the of the set and this can be done using BLS which the gas cost is a 500k so is a great solution one having a lot of signatures to be verified but the Brazilian is very similar we just say have one reification and then count again they the block headers and up icon

sources so when speaking of BLS you always have to find the parent functions these are basically functions that send points from two elliptic curves do they in natural numbers and the thing is they have two properties the first one is natural it's that they they are bilinear when you multiply as color for one of the arguments here is is equal of multiplying that color in the other argument and when you do they the sum of two arguments is equal to the product of the two parent functions and the second

property is that when you multiply each argument for a forest color you get the parent function power to a times B being a and B they're various colors so the thing is just that they haven't nice functions that they have two properties so what we can do with the this parent functions is verify our signature just need to satisfy the Equality that the bearing function of the public key and the heart needs to be equal to the parent function of the generator of the curve and the signature itself so the

arguments are you use it are just the same as in the typical a signature verification so the nice things oh yes sure and this is a guarantee by the by the first property of the parent functions yeah and the nice thing here is doing just the same we can verify a finite number of signatures so suppose we have we can consider P as a sum of we have if we want to verify and signatures so P would be the sum of these n public keys then as the sum of the n signatures and hm them

we just need to verify a that the the parent function satisfy the the Equality of abuses the same this can be proved for the same properties but uh does explain that I don't have time to explain them anyway the idea is that you can verify many I find a number of signatures win with one a equality so just to finish just summing up the workflow of the preaching in with it and to have a recap of the main ideas that we had in this talk so first we have the WPI contract that is in charge of

receiving the transactions from one to another and in charge of monetary sizing this interaction are they breached notice other than explained before then for these transactions to be verified you need to the WPI needs to be a aware or a miss you have some knowledge of the of the block relay I'm sorry the block headers in width and these are stored in a block will a contract and using this easy you can verify them very easy using the merkel path on the SPV protocol so

then for the block head of reporting you have to select appropriate a voting committee in our case was the active invitation set the signatures of those members in the set a our verify using BLS then the you check consensus count the numbers of block reporters and a and when you get the two thirds and finality is applied you can either well you can they they block header is added today to the block relay contract I think yeah I hope everything was the more less clear and although this talk

had a lot of contact but we try to explain as nice and easy as possible so thank you very much and hope we can see you tomorrow in our last talk my colleagues are presenting is five to four about the raid on the domain-specific language for a course in wit not for specifying their data requesting with so thank you and please if you have any questions no it's brave enough

okay we will be happy to answer any questions that you may have we will be around for that full day and tomorrow thanks for coming thanks also to the whole winter team which are the actual magicians that made this possible Oh