Into the Wormhole: Bridging Ethereum and Solana - Anatoly Yakovenko & Bartosz Lipinski

all right next up we have uh solana and uh we've got anatoly from the project here to present uh into the wormhole so anatoly are you here with me now i am assuming we're gonna see you in just one second so uh what i want to demo to you guys is the wormhole bridge that we built between ethereum and solana and not us actually uh the steam shardest one that is one of our validators fill this out so we'll see if it works um here's an instance of it this is actually deployed on are we as a web application it um detects your running metamask and it connects to a solana wallet so here i'm going to try to transfer a 0x token into solano so we're going to try to transfer one token and the first kind of weird interesting thing about solana is that um the account for that token needs to exist beforehand and what that means is that um this is part of kind of a nuance of the salon runtime so in ethereum when you do a store uh evm just goes find your location where to store data um that's unfortunately kind of slow because you are modifying the index and you have to have those indices pre-allocated so what we're doing solana is you actually pre-allocate all these indices ahead of time so i don't know if you guys can see this approved creation so that that's basically it um oh yeah so here's the token we're going to transfer 1 0x so metamask confirm dvd so while this is running i'm hoping i'm hoping this works but this does require waiting for uh ethereum to confirm it so in the meantime you're going to talk about what's happening in the background um so user has uh some your c20 that they want to transfer to solano uh the first thing that we needed to do was create a destination where this is going to land on the salon chain and that's done via deterministic caching so that index is created beforehand and that's you can think of it as a memory location where information is going to be passed through and we can derive that deterministically from the erc token type so it doesn't matter which user uh kind of creates that thing first it'll always land in the same spot so user basically does a transfer all right here we go does it transfer from their wallet into the bridge the validator on this side does a mint instruction in a transaction to transfer that those tokens to the user's wallet so in this particular case what are these validators or who are these people um and how does how does that work where's my so if you look at salamat beach. this is a validator website that was built by one of one of our folks the validators that run this bridge are actually a subset of the validators of one consensus and the reason for this is because of how salon is designed and the number of validators to get to super majority um is pretty large so to get to 67 for consensus we need 133 validators um and each one of these validators generates a different ft5519 signature every 400 milliseconds so for a full block confirmation what you're dealing with is a is you know 133 messages at least and in the worst case it could be 32 times that um which is unfortunately uh just kind of too much data for the evm so to make this feasible and to make this work on ethereum we pick effectively a subcommittee of these validators and they observe the ethereum chain and when they observe that chain they don't internally have iran any consensus but they simply sign those messages and when a subset of them signs that that's the super majority of that committee um that contract executes on both sides so where's my presentation so we're looking at this this contract over here as soon as the user does this action those validators independently observe it and they sign a message that message is gossiped and any one of them can collect the super majority of that acknowledgement and submit it to either side so you don't really need to run consensus in the middle here it's kind of done implicitly because each contract in each chain can take those requests which is uh pretty cool so to make this more decentralized in the future um we have another project that is working on um actually verifying right client proofs inside ethereum um and we don't want to do these proofs in every transaction because this is going to make this whole system you know a thousand times more expensive but what those proofs can do is they can every two days they can make sure that this validator stops up actually matches validators from solana given some prerequisite in terms of state and the second thing they can do is that that like client proof can actually ensure that these validators haven't committed fraud because the log on ethereum has to match the log on salon so you can technically do full reconciliation of a history you know every two days and make sure that it matches and you know one way to think of it as as a kind of embedded domain-specific language that defines the bridge operations between these two networks and this this works exactly the same way no matter if the initial transaction is issued on the solana side or on the ethereum side so let's see where we got with our wormhole validators uh okay all right perfect i i almost timed that completely so were you guys able to see that um so that transfers completed in my wallet on solana i should have some tokens uh so where's my wallet tada look at that so that's the token address that we created before this is a deposit address and i have one crx bridge crx um so something to do is obviously here is this interface pretty ugly but it works we need to add some token symbols here and kind of start figuring out how do we display this correlation in the explorer how do we actually demonstrate that this particular address represents 0x on ethereum and you can kind of dig through through this behavior uh so if you if you if you look through our explorer at least given this transaction signature you can see who actually ran it and this you can track down to the wormhole program and this is the program that is run by our by that by that bridge and that program executed these state transitions so that's basically working i'm actually surprised that it um it works so easily um cool okay so we have uh what else should we cover i think uh where this can go and like people on the conference are probably interested how they could help uh build that out um so maybe how we can bridge to amm on solana some assets from ethereum uh like imagine maybe interest bearing tokens from abba into liquidity pools that we have that are controlled by the like market makers on the other side and have like cheaper fees yeah this is like one of the one of the cool projects that uh i would i'm really kind of looking forward to is basically folks doing something really really simple which is taking ave tokens that are interest-bearing and bringing them through to solana's side and then plugging them into a serum dust does and the cool thing about it is that you have a much slower kind of like exchange if you if you want to call it that which is the avi liquidation market plus the unislop running an ethereum and you have a much faster cheaper one running on solana so you you could actually start hedging between both of those you could issue a transaction into the memphis and ethereum and cover that position or potentially losing that like transaction rates on solana depending on gas prices so there's like opportunities for both thoughts and for humans to actually take advantage of this so for people that are not necessarily familiar with solana ecosystems serum decks that anatoly is referencing is fully on chain exchange uh that's running on solana without any external interaction with limit orders which is something that we are super proud of so yeah i'm actually kind of surprised that that transaction was successful because that was going to be the most of my presentation so the second part like what we can cover um is folks that want to actually dive into development uh on solana and there's this awesome guide that goes through the solana memory model um so i don't want to share this like with everyone in the comments um so the the kind of thing that we saw like in that simple presentation was that this program over here um um it's how the solana model works is that everything in in our memory model is an account so these accounts have to be addressed and pre-allocated ahead of time this is really this is kind of like the thing that is harder for people to get is that like when you do a store you don't get a free index allocation and why this is important is because when you're dealing with a single shard giant state machine those indices grow really really large and if you don't pre-allocate pre-allocate those spots you actually end up with a very expensive virtual machine so programs like everything else are accounts so warm wormhole is a address and this is a public key that the wormhole validators had to grind to get a private key with this public key that starts with wrm um so this is the closest thing that we have to uh vanity addresses right now you actually have to do some homework to get one um it's kind of funny and what's weird about the account system is that every account has an owner field um so what is the owner this isn't actually a human owner it's not a person it's another program so for when you load your own smart contract or a program that account is owned by the loader and what that means is that the loader is the only thing that they do state transitions in that account so warm itself is a separate program but it lives in an account and that account is owned by the loader and only the loader effectively can load like load programs and set them as executables but as soon as that new program is loaded this thing itself can start owning other accounts and therefore do state transitions on them and this is kind of the core of the security model here that now wait it's all programmed yeah it's always has been that everything in in the salon account system is a program and every account is owned by another program and the only two things that have interesting powers are the loader itself which is the thing that can make things executable or system program which is the only thing that can allocate memory and once you kind of get the hang of it you can almost think of it as forking in unix so the working model in unix right is i create my master process i fork into a sub process and then reduce privileges and then take you know hand ownership over to somebody else um it's similar in that sense that everything in itself starts from a from a different program so if you're building in solana um the second thing you'll notice is that transactions are kind of fat and that's because transaction itself has to specify all the accounts it's going to read and write ahead of time and this is again like another kind of a pain point for a lot of dogs is that you have to design your program to effectively like we're forcing the developer to do this to do this really hard um process of making every state transition in your program effectively statements there's no global memory um if you have global memory it has to be passed in as an argument to your entry point so things like token initialize account have to take the target account the mint which is the descriptor of that token the human owner which is like a parameter and it also has to kind of keep track of rent and like know exactly how much um land force it needs to store um to prevent that account from being cleaned up by the state garbage collector so this is kind of a pain in the butt for devs um but the reason for this is again is if we see a big pile of transactions and we know exactly which accounts each transaction needs to read and write um we don't need to allocate any dynamic indices like all the english only in just all all the indices can be pre-allocated ahead of time the second part is we can process all the transactions in parallel so every other transaction that doesn't touch that has doesn't touch any of these accounts um they can execute in isolation this is kind of the second cool thing and this is why we get this kind of massive speed up um so if you go to like new salona surf and you look at the let's say transaction rate we're kind of handling a big pile of dps um at any given moment um and if you want to examine what those blocks are we can actually kind of this is a cool new interface one of our validators built so you can go look at which programs have been executed in the last 10 000 blocks inside of those are a bunch of different calls to different accounts and because all of these are isolated they can all execute in parallel so because of this parallel execution model we can actually run consensus as a smart contract um now this isn't exactly a gimmick what's important about this is that our whole kind of like goal to decentralization is that every two years the amount of parallelism we can do for the same price basically doubles right like because all of these programs can execute in parallel they can all run on separate cores they touch separate memory therefore they can run effectively in separate solid state drives use separate queues for you know reading and writing to ssds they can use a separate core um those things basically drop in price by 50 that kind of parallel computation is called really easy to scale it's it's kind of like a 3d horizontal scaling and because consensus is one of those things that takes up resources that actually fits natural to run it as a smart contract in the system because every time we double capacity right double bandwidth double cpus double ssds we can double this number of validators for free like we it literally like means if we have twice as much capacity we can use twice as much of it in consensus we can use twice as much of it on market programs and things like that so that is basically it um so if folks want to like actually dive into the development process um we have uh i want you should check out this guide and if you look at our github see if my links work that's not it all right there's uh an open zeppelin style solano program library um so i hope folks can go check this out because this thing contains reference implementations for amms which is second swap lending and as well some other cool weird things like uh the brave themis uh design and like a really cool straight memory model between applications and need to uh store return values between each other um so that basically covers what i wanted to cover during this talk um cool i don't know i don't know if we have a way to get questions from um from folks on twitch or in the comments section yeah i'm not sure anatoly let me take a quick look well i guess while he's looking uh thanks a lot guys for your contribution and your support of the event hopefully you guys enjoyed as much as we have i mean uh that was really good information so thank you for sharing all of that um everybody again thank you to solana for being a presenting sponsor you guys have been fabulous to work with and we really appreciate everything that you've done yeah likewise and um yeah if if you guys want to start moving tokens through wormhole please check out the bridge in the docks it's as cheap and easy and it works what's in first drive once you uh load the right gun excellent cool we'll check it out for sure as soon as i get done doing this all day all right all right take care cool take care thanks guys