Michael Bucher - Bridging EVM and Non-EVM Assets: A Practical Approach

Transcript

thanks for the nice introduction so welcome to my talk here um this is going to be a practical approach so it might get quite technical so if you have any questions on pretty details just talk to me afterwards so we're aabs Team of five people three located here in Switzerland we've been uh developing tools for web 3 for a long time for about six years now and even also before we've worked with web 3 so we have quite uh some experience uh today so we've worked with various VCS

uh corporates um binance and okx for example use our tools um to transact Neo for example um and we're also uh a core community of the Neo blockchain chain and we're in close ties as well with the hashgraph association so here's a quick overview of what we're going to talk and going to look into here so let's Dive Right into so the Neo ecosystem is quite a dinosaur and crypto it's been here since 2014 some of you might not recognize it because

previously uh pre8 it was called an shares and it did a rebranding in 2017 um it aims to build a smart economy and its main part of the Neo ecosystem is its blockchain uh Neo N3 it has the neov VM which is quite future feature Rich and dynamic flexible um but it's not evm compatible we'll get into that later it has a dbft consensus which means it has a one block finality so whenever you issue a transaction and you see it in a

block you don't need to wait for further confirmations it's done it provides native oracles and a file storage as well so you can easily store your files on a side chain uh that's connected to Neo it supports multiple languages so you can for example example develop your smart contracts in C or in Java or in Python whatever you like best it also has a special dual token model so we have two tokens here one is native gas token which is used for uh utility things like transaction fees um and Neo is uh the governing

token so when you vote with Neo and hold Neo you earn gas so you just need to hold gas and you get uh you just need to hold Neo and you get your gas that you need to pay for your transactions or pay for file storage Etc so as you might know the current situation is quite challenging for non evm chains it is uh not the main standard like evm has a large community already um so it has first mover advantages so if you're a non evm chain um it's just

difficult um if you would have evm compatibility it's just easier for integrating with Central exchanges or issue a stable coin or also just gener generally uh to to connect to to institutions because most uh companies that start with web 3 they will start with emium compatible Solutions on the other side Neo non evm chains have also some R&D um possibilities that evm doesn't have evm is a bit slower where nonm chains can just have a f faster Pace right so the

Neo ecosystem uh wants to have both both in its world so evm compatibility to connect to everyone that's out there that's already in the game and still keep this feature neov VM that it already has so introducing neox which will be the new evm compatible side chain on in the Neo ecosystem it will adapt uh the N3 dbft consensus so you will also have a one block finality there and more importantly it will add a very great

feature which is anti-me so on neox you or I'm not sure if it will become the standard but it might that all transactions will be enveloped so they'll be encrypted and only after the ordering of the transactions is finalized they will be decrypted um besides all that gas will be the native token on that chain so usually some projects they they come up with a new chain right and they will issue a new token but Neo doesn't want

to do that they want to keep the current dual token ecosystem and they want to use gas because why why come up with something new if you have something that's already working so the gas token on on Neo X should not be new gas so no new gas should be minted on that chain everything that's on new X must have come from N3 that's the goal and also the the gas product ultimately just stays on N3 also important is that gas will be burned on neox to keep the the ecosystem

flourishing um yeah further utilities for gas will on neox will be governance as well which they don't have so it will just extend the utility base of the gas token in general so we we need a bridge we need to bring these gas tokens from Neo N3 somehow to Neo X right so why do we need it it's really simple it's not rocket science we just need to move it and connect Neo X to Neo N3 in this whole new ecosystem so when we were uh asked to

help with that development we had some requirements so first one is it should be a lowrisk solution of course because you all know uh bridges are pretty drawn uh to hackers in the recent past so um there shouldn't be a single point of failure right so there should be no single keyh holder and also we want to decentralize the TR another thing is we don't have that much time to develop this so we can't you know do much R&D we we need to

do it but not too much so we need to do more engineering so here are some solutions that that we uh considered um we considered X as an as a layer two solution and the solutions for the bridge would be an optimistic rollup and a c or a CK rollup um however with the requirements that I just mentioned um it will take a long development time for some of them uh for optimistic rollup for example we would need to emulate the evm because re remember uh neov VM is not evm compatible um which will take take quite some time and CK

rollup it's just a high complexity and we don't have the skill set uh so we would need on board new people that already know this or otherwise we would need to learn it but this takes a long time as well so we went to the direction of a side chain so um we need to bridge something without having this challenge uh option right so let's let's just take a the most trivial approach that we could have uh we could have just a central entity that just listens to one chain right sees an event a bridge

event and then creates a transaction on the destination chain and does that but that requires a lot of trust right so before we will talk about what exactly we will Bridge we'll talk about how we will do that so the goal here is to reduce trust and also what's not on the slide is uh increase security um as you can see here at the bottom are multiple validators so our solution includes uh multiple nodes that are disconnected they will list listen to

the chains if there is a bridge event and then they will sign individually what happened forward this to the relayer and once the relayer has enough signatures of those validators he will relay this to the destination chain so the validates here act kind of like like a multi Uh current in current stage it's uh uh State it's a five out of seven uh multi sick so with that said let's go into what we want to bridge right because

just bridging every single deposit that happened to the other chain um it could lead to validators not signing something they could just leave something out so what you would want want to do is to keep track of what happened in the past as well so you can trust that the validators actually signed everything that happened in the past so there are two approaches here that we considered where one is a state proof um which takes minimal computational effort because on the Destin On the Origin chain when you deposit something you can you could just uh do the transaction and in a smart

contract it would just stored that data and that data would ultimately uh be included as a leaf you know in the whole Merle Patricia Tree in in the State uh proof however in on N3 the state route is not in the header um so it doesn't really have final consensus um on the other hand as well to prove that on the destination chain is quite expensive so remember neox is a new chain so if a user wants to bridge something he doesn't have any gas yet on ux so he can't claim so what we really want is an

automatic Bridge so we want to include the whole transfer the Distribution on the destination chain to be in the hands of the relayer we can do that on a smart contract level so we can force whenever we update the route on a destination chain or on either chain you need to provide data you need to provide the bridge data in order that you can do that right so uh that will be automatically um and we also considered uh Merkel tree using Merkel trees um directly on a smart contract level so we did actually a proof of concept for this um but it it's just expensive and

another uh interesting uh problem we we discovered was that there were variable transaction fees which is a problem on a UI level so if a user Bridges something provides some funds to pay for the transaction and someone uh some other uh person comes with his Bridge action before him then maybe the transaction will just cost more and your funds will not be sufficient and fail so then we asked ourself um what do do Merkle trees provide that that we can actually afford to lose and keep in mind

what I just said before is we want to have something automatic so we want to have the relayer prove what happened directly when updating the route so we don't need the feature of Merkel trees that someone can come after 20,000 deposit and prove a this Leaf this deposit was included we don't need that right because we do it on the go so we don't actually need a tree so what could we do we can just chain it together so it's it's no rocket science here um chaining it together will just keep track of the

whole history um with having uh lower complexity we don't need to claim and uh a downside though is it there's not really a proven record for that um but let's go for it so here's the ordered binary hash chain that we use so on the bottom right maybe I can point here you see this is a deposit so that represents deposit data so let's say I want to bridge something I send my funds to the bridge contract this will be the data then it will be hashed and then it will be

connected to the previous route that is stored on chain and then hashed again and will be the new route so it goes just up like this instead of a tree form so let's go into challenges that we discovered when when implementing this so on a high level of course we have different smart contract languages for example the contract in in for neox was written in solidity but we can't write the Neo N3 contract in solidity so we need to write that one in Java for example but it has essentially

the same needs the same functionality on a business perspective right then standards as of now with gas we don't really have that problem yet but because gas will be the native token right you can you can consider gas on neox like ether on ethereum right um but Neo N3 doesn't have rc20 Neo N3 has another standard for funable tokens so you would need to if if you were to include uh if you were to includ uh support f tokens for example you will need to map that and there are

other uh differences for example ketak 256 is not supported on N3 so you can't use that hash function so for example here we used sha 256 then on a lower level you have big Indian versus little Indian from evm side you probably don't even know about that if you're not working on a low level um because everything is Big Indian uh on the evm however on neov VM everything is Lan so it's reversed the bites are reversed and then evm has a fixed size data structure on BM level while Neo has

Dynamic structure so on evm for example you have un 8 un 16 un 64 and so on on Neo you have just int and the the data the btes will be as long as they need be so you don't have the limit of U and 256 or whatever so let's go into a quick detail about this so what happens if I deposit to on N3 let's we have a non here then I want to bridge this amount of course with the decimals and this is the recipient address so what happens on chain now in the contract is this is uh in HEX it's 01 that's the hex for this amount and

then the address Remains the Same then we concatenate this data and then we hash it and we get this hash 8B E4 Etc right now when the relayer reproduces this on the destination chain on neox he will provide this data here then and then the hash will be recreated to check whether that data is correct however on neox the data in bytes looks like this right lots of zeros so the message will be different so the hash will be different so if you run easy recover on

that it will return another address and not the one that actually signed it right so we need to fix that so what we can do since Neo m is flexible we can adapt to that and we pad the bytes to the same length that evm requires so in order to get to the same message and get ultimately to the same hash then we can recover the same uh signer again one thing that's not on the slide is what I said before big andian little andian these bites here actually there's another step in between they're in little end in uh on

on the neov VM so this is actually in reverse on neov VM so on Neo VM you need to reverse and then pad concatenate you have the same message so you need to consider a lot of things on a really low level so yeah that's it um we are live currently on tesna T2 we're developing uh as I'm speak T3 will release that soon and you can scan here to get to know more about newx um some future things we want to include is that the relayer could be open currently it's just restricted to one Central

entity but as you know we don't want Central a single point of failure um and we can also bring more validators to even the centralized more so just quick takeaways here non evm ecosystems we can't just copy so we can just Fork an existing solution and deploy it and if you want to do this you need if you want to create a bridge from non evm to evm you need a really good understanding of both VMS to achieve that thanks for listening and if there's any question we we have time for one

short question if there's one question you can also ask me later if you want I'll be here ah there's one oh I'm sorry um so is this a uh nonprofit or a for-profit project so far um well from our perspective we're we're getting paid from from the Neo Foundation so it's not pro uh for profit okay okay thank you that was it already thank you so much Michael um I guess if if anyone else has questions you will still be around later on a little bit right um please stick around

our next speaker will be getting ready uh in approximately 2 three minutes so thank you very much I