#DappCon22 : Day 3 - Trustless Bridges In The Ethereum Beaconverse, Kirill Fedoseev

Transcript

he's going to talk about what are you going to talk about what's this brooches [Applause] so hi guys my name is the safe I work as a software engineer agnostics chain and with the majority of my work being related with the development and the implementation of bridges at Moses chain and before even agnostic chain appeared today's topic will be about the future of breaches agnostics chain so the agenda for this talk is to see what Bridges do we have agnostic chain today what future plans are we currently developing on and planning to have a technology change in regards of bridges and how all of this is connected with

the trustless bridges and generally the ethereum light clients so when it comes to preacher's diagnosis chain we currently have there are two main categories out there so the first one is the native bridges that were originally developed as part of the development of the chain itself and so the first important Bridge we have at gnosis chain is the ex-day bridge which is responsible for bridging die erc20 tokens from the mainnet which have been converted into the bridge representation of the Native x-state currency which is used for guys payments in technology Network then apart from that we also have the arbitrary message Bridge which is responsible for making possible

cross-chain API encoded contract roles between the ethereum magnet and glasses chain and then on top of this amb protocol we have the Omni Bridge extension built on which is basically responsible for transferring and bridging any compatible erc20 token into its canonical bridged erc20 representation on agnosis chain and backwards and the second category we apart from native Bridges we also have a couple of Integrations with the different third-party bridging providers with the major one being whole protocol connects Network and some others so just in regards of our native Bridges and the way how they currently work uh

just a brief technical breakdown on the way how they currently operate so at first it all starts when the some question message that that should be passed to a different site it's basically locked into the transaction event on the source side in the transaction received then we wait until the independent Bridge oracles run by different third-party independently observe this transaction logs they confirmed the messages found in these logs and finally collect the mfn digital signatures on the destination side being that agnosis chain or ethereum mainnet just on the opposite side of the of The Source One and then once the bridge contracts on the destination side collects enough

signatures and verifies the correctness finally the smart contract of the bridge can execute the message so this approach of Building Bridges is very typical for building bridges for other side chains as well and so we can generalize it and call it like multi-sig-like Bridges and typically these Solutions are considered quite simple suitable and efficient enough for majority of the use cases but the truth is that after some Turning Point either it be in the amount of the liquidity the bridge is currently operating on the amount of transactions the bridge is processing the amount of counterparties it's interacting with typically the case that the risks of

having such Bridge start to gradually outweigh everything else that the bridge can positively provide and by talking about these risks what they actually mean is that the most crucial risks here is that this type of the bridge hardly rely on this small and fixed set of some trusted entities and this fact also opens up a huge space for different web to Vector attack web to attack factors which can be a huge problem for this trusted identities and even from the statistical perspective we have also seen that most catastrophic hacks in the web 3 space we have for the past couple of years we are all to some extent related to a

different Christian bridging protocols so that's just the consideration of the security and bridges should be a top one priority for sure then of course when we're talking about nurses chain it's also pretty obvious that monster chain is an evm sidechain and when it comes to discussion around the security of the side chain it makes sense to consider a sidechain as a combination of two important pieces basically the first piece being the chain consensus and the second piece important piece being the native Bridge which we are using for pricing messages back and forth and passing value back and forth between the networks and when we are discussing security or

reliability properties of our entire side chain is typically been limited by the security and reliability of its weakest Point among both two and while in practice we usually focus a lot about the security of the chain consensus but we always forget about the security of the bridges so that's lagging behind and in practice the biggest point in the most of the side chains typically becomes a bridge so that's and a problem we are trying to solve and even though the agnostic chain has the longest production history probably among all of the bridges available out there and for sure we are doing absolutely our best in in enforcing all known and best security

practices both related to off-chain infrastructure and unchain smart contracts but at some point we also start wondering in searching for some abstract and magical bridging technology that could potentially help us to avoid those risks completely into migrate to some different solution and after some initial thoughts and considerations we start to believe that such magical Bridge Tech might be the become very Stressless Bridge so here it comes the future of preacher's hypnosis chain so in short and on the high level it can be described by something like the following picture so we have this a couple of pick and chains

and the trustless Beach established between them each of the beacon chains either be the ethereum big and chain hypnosis Beacon chain contains the corresponding execution layer and inside of each execution layer we also have the smart contract which implements light client syncing protocol and is capable of keep thinking the history uh of the blockchain located on the other side of the trustless bridge and then we just use this data synced By the Light client in order to prove the necessary events happened in either of both Networks so trustless Bridges when we think about what do we actually need to build one of those so the first point and the central thing we should have here is we should start by having a two Provost take

ethereum chains and as you all know the ethereum merge is just around the corner basically in a few hours and the gnosis chain merge is coming probably in the next month so that's just a small time constraint we have over here then the second important piece of tech we need for building trustless which is the ethereum light client implementation made into the evm byte code and finally we'll just use a few Miracle 3 proof verifiers in order to extract actually useful value from the data from the raw data synced By the ethereum Light client smart contract and when we're considering such abstract trustless bridge and start to think about how they are actually better than the bridges we currently have and which

are based on the multisig then the most crucial Improvement here is related with the improved security by which is achieved by inheriting the security of the original proof of stake consensus by inheriting the security of the consensus we also eliminate this necessity and requirement of having some trust in some external third parties and by eliminating those third parties we also eliminate this huge space for direct web to attack vectors which is just a huge Improvement in the overall security of the preaching solution and even on top of that also when we have in some sort of on-chain light client which is capable of syncing the blockchain history

of the opposite of some other blockchain it can be also very useful even without a bridge and direct Bridge Communications by other use cases either that'd be some on-chain voting snapshots historic oracles or something like that so the main thing about trustless bridge is the implementation of the light client of course and just a small recap on how light clients in ethereum after the merge will work so the main concept to understandable like client is this notion of the ethereum sync committee so just a small recap on that ethereum sync commit is a subset of 512 randomly chosen validators which have been regularly rotated and shuffled every 256

epochs in the beacon chain then after the Altair hard work when this sync committees were first enabled each beacon block and its state now contains the information about the current in the next in committee within the periods and then each individual member of sync committee is responsible for producing his individual BLS signature for in each valid block header it processes throughout his assigned period and then once this individual signatures have been submitted and processed onto the peer-to-peer Network they've been aggregated by the block proposal into a single larger aggregated biller signature which has in the end been included into the next proposed beacon block from where it could be fetched by

their Litecoin provers and then this proves generated by the Lite client could be used for actually verifying the state transition so in order to make such a light client based on this notion of the sync committee we basically need to implement this simple transition function which allows us to jump from block X to some later block y so given that our light client knows and trusts into some beacon block hacks which we proved before to it and given it receives some update for some later block Y which was in its turn finalized by Block C and this Block C was then signed by the syn committee and with its aggregated Bella signatures

being included into the Block C plus one essentially our right client should just verify two important pieces here so first it should verify that the Block C was indeed signed by the relevancing committee that could be derived from the Block we are currently standing on and then we should also just simply verify that the block y indeed belongs to the finalized checkpoint of block Z which is just a single Miracle proof verification so once both of this verification are successful we could just tell our light client to update its head pointer to start pointing to block y instead of pointing to block X and then this transition function could be just indefinitely repeated again and again which will allow our light client to stay in synced with the history of the

network so the crucial thing about implementing the trustless bridge is this light client implementation in the evm byte code and the only untrivial and actually higher thin there is this implementation of the on-chain BLS operations and so the story forward way here is to just Implement them directly in solidity and the most preferable way here to do it this is to use the eip2537 BLS program files so these pre-compiles are not so far included into the latest execution layer hard fork and in the most optimistic scenario they will become available into the inside of the Shanghai Fork which is

expected somewhere within the next year so that's just a matter of time how we could actually start using this solution and when and while we are waiting for the enabling of the eip2537 pre-compiles we also started researching together with the cellular spark team the cycling clubs team the possible implementation of this PLS operations not directly on chain but instead by Outsourcing them to the snark shortcut which could basically hide this EAP hide this BLS computations and Outsource them off chain so when we are done with the light client one-chain implementation the only

thing that left for the actual trustless Bridge operation is the way of organizing the trustless message execution and so the way how existing breaches usually approach this problem is they just allow you to make arbitrary calls to the contracts that are located somewhere on the destination Network of your breach and then in order to make such arbit recalls and to actually somewhere and some would technically organize them this arbitrary calls can be encoded into some data blobs that should be just processed by the bridge contract located on the other side of our vision solution and so the question here is how do we pass this ab3 data blobs between the networks securely through the light lines and this can be

actually achieved by either of two ways so we can either verify the correctness of values stored somewhere in the storage try of the world state drive ethereum or we could also verify the value emitted somewhere in the logs of the particular Source transaction so if you follow the first approach we could just keep our messages or their hashes in the storage mapping on our search site Bridge smart contract and then in order to prove their inclusion and correctness of the particular message cache inside of the header route that was synced By the ethereum Light client this could actually be proven by just following a small sequence of Miracle proofs through their head root wall State dry root LLP

encoded account and then finally through the storage try towards the correct correct value of the message hash and also as a bonus in this solution we could also cache the value we obtained after the second step so the storage unit of the particular account can be reused and cached for also execution of messages happened in other transactions before the one we are currently executing and in the second approach it looks very simple so we've just seen sent our messages by emitting events containing the message hash the message itself and then just prove their inclusion and correctness again of this message hash inside of the header root sync By the

Light client by proven slightly different sequence of Miracle proofs and then finally just searching manually through the all the events happened inside of the transaction and just look for the necessary topics to find the one we're actually interested for when Once of all of the buff is implemented let's see how the overall process of bridging data will look like just on a simple example so it all starts when Alice submits your transaction to the female magnet which in the simple case for example could just log 100 die erc20 token on the balance of the XJ Bridge smart contract then she patiently Waits until the associated beacon block has been finalized then she waits until someone generates signs and submits analysis

relied client update to diagnosis chain in a permissionless way then the Alice or the user interface on behalf of your computes and submits the necessary Monger proofs for your message execution to diagnosis chain side and once the transaction is executed happy Alice observe message execution results and in our example that will be just the mint the fresh mint of 100 x Day Native coins so and the great thing about this process of reaching data is that it's entirely permissionless from the very start to the very end and no trusted body is ever required throughout this process at all so where we are now with our research

and implementations so far we have completed our proof of concept solution for making the Stressless player of currently adopted omnibridge plus tresless arbitrary message Bridge protocol which works on top of and over eap2537 PLS program files so that one cannot be tested in the public test Nets but so far we have tested in the devnets so it looks very promising and workable then we also have from our friends from Xerox Park team a proof of concept solution for this snark light client circuits implementation and the bridge prototype which you could actually try and which works on top of this uh snark like client circuits and also utilizes

the similar approach of verifying light client updates and apart from that we are also interested in doing some additional resources on making the possible optimistic light client verification in order to save something on on the POS on the gas expenses possibly and we're also doing some research on the potential ways of improving participation rate in the single meters by doing some of chain tricks basically and collecting some of the signatures of chain so that's I think was it so please show your support for eip2537 and its inclusion into the upcoming I hope

Shanghai hard work so that's very important for us you're welcome check to check out our demo the demo of the Xerox Park team and as always just stay excited about if you emerge if you're in big Converse and the trustless bridges that could be built on top of that so thank you you thank you curiel so we have a few minutes we have about five minutes to uh for a few questions so if you have one well there you go all right so do I get correctly from the presentation that it's I have a few questions by the way do I understand correctly that 27 up to 27 hours it takes for the whole process to complete

so the 27 hours is the duration of the single syn committee period so that's theoretically the maximum amount of time your Litecoin prover could wait between those light client updates but the minimum limit is basically just the time of verification of the single Epoch which is just five to six minutes in the terms of the main net so that's not a big of a problem to verify each Epoch when it comes to bridging data from ethereum diagnosis chain because the gas and losses chain is very cheap but probably for no 16 to Infinity site it will be slightly slower but still it's just a matter of how much guys we are willing to spend on this purification

process so you already answered my second question so we can go to the third one so it seems you can build a economic bridge on top of that when you just have a party that gives you money right away and they just take a fee for that and wait for for the whole transition is that something that you plan or someone else to build or basically this 30 third party Bridges I talked about in the beginning as hope protocol connects they are already working on top of existing bridges on roll ups and gnosis chain so when they utilize this LP based pools in order to speed up particular transfers and just once this bridge will

go to production it will be just a matter of time when these protocols will just switch towards the Stressless Omnia bridge and will provide this LP based speed UPS towards the transfers and the last question would be about the cost of verification as you said it's more expensive it's more problematic to verify knowledge chain on ethereum do I need to verify every single blog do I need to verify the changes in the committee and all that stuff so the main like the great part of the cost comes to this verification of the light client update hopefully it could be done just by a single time per day for example in the worst case it could be done once in a few hours so that cost

could be splitted between all of the users of the bridge and so that's uh if we have a large enough number of users in our protocol net it could be not a big problem and then the cost we are actually carrying with each message execution itself is just the cost of verifying a few Miracle proofs and this is typically comparable to what cost we currently have diagnosis chain Bridges and others so that's just the comparable numbers but I think did I see correctly you're missing one more piece in the presentation which is when the committee changes you need to make sure that the transition was correct right yeah it's all included into this so just the way

how committed change is verified is basically described in the the Litecoin protocol specification so the smart current radical or is it shortcut could just follow this protocol and so yeah the sync committee changes is included into this implementation of course wonderful thank you very much seems like you did a great job a round of applause thank you so much