Interoperability via the Rainbow Bridge - With NEAR’s Chad Ostrowski February 6, 2021 Link to Full Talk Ethereum and NEAR sitting in a tree b-u-i-d-l-i...app developers, this is for you. We want you to help us put some finishing touches on our rainbow bridge client library. It is not released yet. I was hoping to have a beta version of it by now, but if I had been presenting at the end of next week, maybe I would have been able to manage that, but not quite there, not in time for today. So maybe you can help us get it across the finish line. That's that's. So what this talk is going to be is we're going to demo what the rainbow bridge looks like. Still some rough edges on this as well but it should be good today. Talk about what you can do with a rainbow bridge, talk about some key concepts and then the four easy steps you need to add this bridge to your own app, talk about the roadmap, where this is headed and then hopefully some time for some q and a, so let's get into it. This is running on Ropsten, if you have Metamask or Brave with crypto wallets, make sure you're on the Ropsten test network. You also need some Robsten Eth and there are some test tokens that you can get at Literally tst, all of this info is in the last slide in this presentation, so again, chadoh.com/rainbow-bridge-talk will get you these slides. Let's go ahead and connect Metamask b412. I’m going to connect to NEAR. The way NEAR connects is it redirects to the NEAR wallet, so we're going to be connecting to the NEAR test net as well. If you make a Testnet account, it'll probably have a .testnet on it. Back when I was first using Testnet, that was not the case, so I got this sleek one without the .testnet, so let's go ahead and begin a new transfer. So on Ropsten, we've got this tst token. I have 83 of them, let me just send one across. I don't know if y'all have used Metamask in full screen mode, this is going to be a little bit janky when the Metamask pop up literally takes an entire screen of its own, so that's what you'll see 1 here: confirm. We’ll end up back here. So, this is a multi-step process for an asset to go across the bridge. First you block it in Ethereum. You can see that this transaction was approved already, or the transaction was mined already, the approval transaction was mined and now we need to lock it, so let's go ahead and do that. This will all be explained a little bit more soon, so this is if you're familiar with sending ERC-20s, it's a two-step process in general. So that's what you're seeing here: I'm sending my tst tokens to this token locker contract. Alright, so if it were easy to add cross-chain functionality to your own app, what sort of things would you do with it. The ones I can think of that we've talked about that we're excited to see people build is using ERC-20 tokens in NEAR where block times are fast and transaction fees are cheap. There are already...There's at least one project that I know of that's already doing this with DAI, we do have...the bridge was running on Maiinnet and we'll be running again on Mainnet soon after some upgrades. This app right now does not use Mainnet. Again iit will soon, right now it's Ropsten only for this UI (by the way the UI is at https://NEAR.github.io/rainbow-bridge-frontend/ ) very memorable, I know, and that will also be improved. But anyhow, you're seeing it in progress here. You can already send tokens across the bridge using the CLI and then send them back to Ethereum again. So anyway, other ideas: you could let users make NFTs in NEAR, again where transaction fees are cheap and we have a great account name system that Matlocker is going to be talking about tomorrow at the same time, where you can make it really transparent to users that they're even using blockchain. So it's easy to get users set up making NFTs, and then if they make awesome artwork that they want to send across to Ethereum where they can list it in larger marketplaces, that's totally doable. You could let users balance liquidity and arbitrage across markets in both chains and more! What are your ideas? I wish I could see the chat. While I also leave this open but maybe can one of my teammates join me on stage and kind of like be the moderator in the chat? Is that something we can we can do here? Like that would be great to have like Matt Locker or Peter Depaulo or someone else like. Can the facilitator here pull one of them up here so they can just chime in when I ask for audience participation? Alright, well, we'll see if that happens. But anyway, I’m excited to see what your ideas are and what you're going to build. 2 Alright, so we're ready to mint in NEAR. Let's find out what that means. Right, alright, I told you this can be done in four easy steps, so we want to get started and building, but we need some key concepts first. So let's talk about how the bridge works. First of all, you have clients like clients, we have a eth-on-NEAR light client that keeps track of, that is an actual full lite client, implemented as a smart contract on NEAR. And then external relay that sends transcends all of the block headers over to the NEAR blockchain, where it keeps track of the entire ethereum blockchain (or enough of it to like do this sort of stuff in a secure way). And then the same thing in reverse: we have a light client and NEAR-on-Ethereum light client running over on ethereum and an external relay that pipes everything across. This is what that looks like again. Over here on NEAR, we've got the Eth-on-NEAR client and the Ethereum headers being piped over here. In Ethereum, we've got the NEAR-on-Eth client and the headers being piped over. The current implementation requires this “watchdog service,” so when things are sent from NEAR back to Ethereum this is because...The cryptographic algorithm that NEAR uses is called ED25519, it's not available as a preset print. I forget what they're called on Ethereum but anyway, it's not available on Ethereum yet but we're working on improving the bridge architecture so we can actually get rid of this and make transfers from NEAR to Ethereum much faster. But that's the basic that's the core of the architecture, you've got a client on each side. Next step, one level out from that, you've got provers and the provers: you submit a proof to them. You say this happened, this event was emitted in Ethereum and it will say yes, confirmed, it was, and it'll use the information in the client in order to prove it. Or no, that didn't happen, so you can't mint because the user would have double spend abilities. So right now the provers that we've implemented, that we maintain is the Eth-on-NEAR event prover you can prove that an event was emitted in Ethereum and on the Ethereum side you can prove that a NEAR transaction execution outcome was what you expect. We may write other provers in the future. You are also able to write other provers, though this talk is intended for app developers, so this might not be the audience I am speaking to right now, might not be the ones going out and writing these provers, but someone could go write their own prover. Finally, the last step, you've got connectors. Connectors come in pairs. You've got something like the token locker over on Ethereum, and then you've got a mintable fungible token over on 3 NEAR. And walking through that step by step, right, fungible token connector, you could have a non-fungible token connector. Fungible token connector could send from ERC20 on Ethereum, to, our current standard is NEP21. There's been lots of great community discussion about a new token standard that will also be launched before the V1 of this library, and then obviously you can also go back again. So the way that looks: I'll let you read this while I sip water. I allowed the token locker to transfer my TST or my DAI. The token locker then transfers ownership of that TST or DAI to itself. You wait for sufficient confirmations on the Eth-on-NEAR client, that's the ten blocks, and then you mint it in NEAR. And when you mint it, you submit proof of the event to the mintable fungible token. NEAR is an asynchronous blockchain, so it's that contract. On the next it's going to take a few blocks for this transit transaction to complete, but you're going to submit a proof of that event and then it's going to make a cross-contract call to the prover, which is going to make a cross-contract call to the client, and then it's all going to come back and finish up and mint a token for you. So let's try it, fingers crossed, this has had about a 25% success rate in my testing so far, we just recently got the bridge running on Ropsten after being down for a long time and it almost seems like this is non-deterministic, that this works sometimes and not others. So, let's see if it works this time for the demo. Usually it hits an error about here: AH! Look at that! First try! Alright, so we went through all of those sets, this has it in five steps, this only has four. Again, because this is one contract call, and then the contract itself is making a cross-contract call. Okay, so we've got clients, provers, connectors, (the connectors come in pairs like token locker mintable fungible token). Note here, that we have two chains and four directions that you can send assets in. You can have Ethereum as an origin, where you have a fungible token on Ethereum bridged to a fungible token on NEAR, and then you send that bridged token back, where it becomes a natural fungible token on Ethereum again. And the same thing in reverse: functional token on NEAR, to bridge fungible on Ethereum, bridged on Ethereum back to natural token on NEAR. The naming of this starts to be a problem pretty quickly, right? It's like, lot of concepts to keep straight, and this is something that I would actually like all of y'all's feedback on. Our best guess at what to call these directions, and this will be used throughout the rest of the talk, is natural ERC20 to NEP21 and then bridge to 4 NEP21 back to ERC20, that part right? Bridge to NEP21 it's a little bit: hmm is it a bridge ERC20 though? But it's really important that we specify that it's an NEP21, because it's just a bridged ERC20. Well where does that live? Does it live on Solana or Polka Dot? Does it live on NEAR? But it's an NEP141 not an NEP21? Right, we want to know what kind of token it is, what kind of interface it has. The bridged modifier is about where it started its life, the bridged or natural, right? Is it is it where it was born or has it migrated? That's what we're finding. That's what we're saying with this part. And then this part is: what it is now? That’s my best guess. But do you like this notation? If you go to NEAR.ai/slido slide, I'm not sure how this company wants us to pronounce their name, but go to that link, NEAR.ai/slido, and you can vote. We've got a few options of what we think maybe this should be called. Alright, so go ahead, pop in there, and I think you will start to see, as you answer the question, you'll start to see it pop up on my screen, what all of your answers are. So go ahead, NEAR.ai/slido and vote on what you think makes sense to call these things. Twitch peeps, you can do the same thing, NEAR.ai/slido and you can vote on what you think this should be called. I'm not confident that anyone has successfully visited that link, as i see nothing popping in, someone please answer so i know that it worked. No? Alright, I’m gonna check the chat. What's happening? “Slidooooo!” Thank you Ozymandias. Has anyone actually, has anyone made it there? Yeah? I don't believe so. Actually has anyone made it there? No? You should be able to answer this now. Ah, there are votes rolling in. Great. Why can't I actually see it though? Isn't Slido supposed to show me this stuff? Hide results, show results, hmm...next question, select a poll, ah alright. I think it's because i'm in this goofy mobile view, that's what's happening. Bridge NEP21, my favorite also, has the plurality right now. So if you want something else let us know what it is. What are other ideas? NEAR to ERC20 NERC20. Ooh NERC20 that might mean something else. We're not going to get into that in this talk, but we need that name. We need that name for something else. Uh, cool, well I am gonna call this. 15 of y'all voted, I think maybe more votes keep rolling in, bridged NEP21 pulling far ahead of the pack. Let's just call it there. If you didn't get to vote and wanted to, again, NEAR.ai/slido, but we're short on time so i'm gonna go ahead and wrap that one up. Thanks for voting! 5 Alright, we'll have another vote soon if you didn't get to participate in that one. You can stay in that Slido link and we will have another one soon So, 2 chains, 4 directions, depends on which origin you're talking about. And then back and forth from that origin. This is the next naming thing that I want to talk about. If you're sending DAI to NEAR, once it's on NEAR, is it DAI to the end and then DAI and back to DAI? If you start on NEAR and you go from banana tokens, which you can mine at berryclub.io, and you send them to Ethereum, is it banana to the E? We've got some great choices here. Some of the other ones, other than this, might be your favorite. Go ahead to NEAR.ai/slido and you can check it out. I will hit start on that one and let's see...no one has voted yet. Ah, was that you, Matt? Is that Matt Locker voting? I guess I have no way of knowing. Well, nDAI^21 is the clear winner. Nope, not the clear winner anymore! What's the other? Oh yeah. Was DAI and EVM-DAI, but that doesn't specify which chain it's on. We've got to specify the chain. And if it's EVM or Blossom, we have an EVM y'all. So, whoever said that knows something about our EVM. And I21, but there would be a way to specify EVM in here. Don't worry, this notation is the...all of these notations are flexible enough to allow specifying whether it's in our walls and runtime or EVM runtime. Okay, alright, thank you all for voting. What are we at there? We’re at 14. We got 17 on the last one, so that's three of you who voted before who still haven't here. Maybe you're thinking about it. I’ll give you another 15 seconds. No, not going to make up your minds? Alright, that's it, we've got nDAI^21. Very cool, very cool. Alright, great, can I see the results here? No? I don't know how to see the results, but anyway, cool, thank you, that's super helpful. Alright, so back to those four easy steps. Let's see how to add this to your app. Step one: you're going to need some dependencies. The idea here is that your package JSON is going to look a little something like this, where you have a rainbow bridge client that handles the core logic of how to store all of the transfers in local storage, and how to display all of the transfers between different kinds of connectors. And then you're also going to have a different connector specific library like ERC20 and then NEP21, or maybe it'll be 141 soon or if you're using NFTs you use this one. And if you want to write your own library, for example, our ERC20, our fungible token connector doesn't handle tokens that use the rebase function, so i think that's Ample and Based? Not sure. I got the name of that one right, but anyway, if you wanted to write your own connector for that, or someone in the community wanted to write their own connector client, it 6 could seamlessly interoperate with this one without any permission system, right? You just add this other library to your package, to your app, and you can also use transfers of that kind in your package. So probably what we'll do here is we will add a NPM and Github org for rainbow bridge, and you'll know that we are officially supporting it if it comes from there. But you can also use ones contributed by the community, and they will, like I said, seamlessly interoperate...question coming up though the rainbow bridge github org is not available...maybe it's not a problem. You can say that in the upcoming survey, but maybe we can come up with a better name. One I really liked was ETH plus ERC20 plus NEP21, right? Because it's both. You get to use both,the plus tells you that, super cool. But you can't have a plus in your package name or in your npm org name. So what should we do instead? We've got a third poll here and then we're going to be done with the polls. Go ahead and let us know what you think. There's a few fun options here. Rainbow bridge: no matching github org, no problem! ETH tilda: NEAR that is url safe. You can have that in your NPM or in your package names, so maybe we want tilde NEAR? I haven't seen anyone else do it, but maybe it's fun. Or just to Eth-NEAR because, the tilde is kind of silly. Stop being cute, ETH to NEAR, nice and short, but it kind of implies the bridge is one way, and it's two-way. So maybe ETH and NEAR or ETH with NEAR or it looks like some of y'all or one person, two people have a better idea. Rbow-bridge. No fun for you, ETH-NEAR [Laughter] oh I feel like some of these others have been Mike Pervis trolling me. If I had to guess um maybe Sharif, I don't know. Sure it's late for Sharif, so maybe not. Anyway, it seems like a teammate kind of thing. We've got others rolling in. NEAR-ETH, alright. Ner-o? What’s the “O”? Ner-o is fun but I don't know what the “O” is. Maybe a little too esoteric. ETH tilde Near surprisingly popular, I liked that one, but I wasn't sure if it would poll well. I wasn't sure if other people I feel like maybe some people are really into it and other people are like very against. Yeah that's what I was, that's what I was thinking. It would be for a little while. I put it in the readme of the package that doesn't exist yet, but will be extracted soon, it all has a tilde right now, so if you get to the last slide, the second to last slide and click through, you'll see lots of tildes. Alright, well this is fun. Oh man I don't even know what these are. Habaner-o? Did the same person fill it out twice? I feel like two people did not do that. I don't even believe it. Neath, ThereNEAR. Did you mean to spell it with the y? “They are NEAR?” I guess maybe. They are NEAR. The less than and greater than also not url safe, can't name your NPM org that 7 unfortunately. You also can't use fancy things like the double-headed unicode arrow. Alright, well this this was super cool, I'll give it again another 15 seconds so get in any last minute choices. I feel like this one might be getting more votes than the others now the same as the first. Alright, well 15 seconds is up, thank you very much for voting, we're going to be done with that, but we will incorporate your feedback, thank you very much. Alright, so we've picked dependencies. I think ETH tilde NEAR is the winner, right? Can I show live? Yeah, ETH tilde NEAR is the winner. Well, “other” is the winner, so seems like people are not certain. So I don't know that we came to a firm decision here, but it might be ETH tilde NEAR. For the rest of this talk, I’m going to be using ETH-NEAR, it was just my best guess at what people might want. After originally falling in love with the tilde NEAR myself, so anyway, it'll be yarn add eth-near/client and whichever connector library you want to use. Whichever connector client. Alright, so we've got our two dependencies that we need, cool. We're ready to start sending ERC20 tokens to NEAR. What's that look like? Step two: initiate a transfer. Say you've got a form, you're gonna need four bits of data. Might not make sense to have all of these in your form, right? Like, I'm logged in with two accounts here, so I can use sender and recipient from there. But anyway, gets the idea across. This is how you would initiate a transfer: given that form import natural ERC20 to NEP21 again, based on your feedback we might change the name of that from the connector specific librar, this is actually the only import we're going to use from this library. The rest will be from the core client so, form on submit, make sure it doesn't, you know, reload the page, grab all of the inputs from the form, and then we're gonna say natural ERC20 to NEP21. We call it and we pass it. The address is the value from the input, amount is the value from the input sender and recipient. That's it, we've initiated a transfer, cool. So a little bit more about what these libraries have that it's four main exports. You've got natural ERC20 to NEP21, which we just saw you can go back to Ethereum. Those ones that you just sent across the bridge to NEAR go back to Ethereum and you can guess what the other two are. One for each of those four directions. This library also contains all of the logic about how those different directions work. The two that we've mostly implemented already, this one isn't quite working today, but the two that we've mostly implemented already have different numbers of 8 steps, and very different journeys that these transfers go on. So if you want to make a different kind of connector, and your client needs different, it has different needs. I believe that this architecture still works. I believe it will still be able to interoperate with the client the main client library, that's the goal here. Alright, so step three: list. Say you have this ordered list and you want to put all of your transfers in it. You're going to import, get from the ethernet client...everything else is coming from here. Render transfers, let's get all the in-progress transfers, and then we're going to grab that...transfers go here, ordered list and set the inner html to transfers.map to render transfer. We'll see that next and, by default, Javascript joins a raise with a comma which is a bad decision that someone made in the mid 90s. So, gonna join that with an empty string. This is vanilla Javascript y'all. This is like no framework, but if you wanted to use react or view, this library will work with that as well. And i'll make sure before it reaches V1, react is my wheelhouse, so I'll make sure that it works really well with react for you if that's your preference. Alright, so what's this render transfer look like? Iimport decorate from the client and then, given a transfer, it's going to decorate that transfer first and specify the locale. This is where information about the steps gets added. So the library, the specific connector libraries, are going to be able to provide internationalization, so that you could list these steps in Chinese or Russian or whatever. And it's also going to add info about, “did the transfer fail on this step? Is this step still pendingm” so kind of real time info and stuff that would just blow local storage. Like source token name would be the same for transfers of a specific direction for every transfer of that type and direction, so no reason to bloat local storage with that. So you've got to run it through decorate before some of this useful info will be there. Call to action is interesting, let's look at that next. So again, we're doing vanilla Javascript stuff here, so I’m not able to add something like “on click” right in line, the way that you would with react, if that's what you're familiar with. But what is this act on transfer? Remember those little buttons that were popping up here that were like “Lock,” Mint,” that is the call to action. That stores that little bit of text like meat. But what actually happens there? How does the client library know what to do when you click “Mint?” Well, you have this other import called “Act.” Again, vanilla Javascript shenanigans. When you click anywhere on the body, we check if you clicked on this act on transfer button. If you did, then we're going to find the transfer ID by 9 finding the closest thing with a transfer class. That's this, and we're going to grab the ID and then we're going to say act on this transfer, and the client library will pass it off to the connector specific library, and it'll figure out, “oh this is an ERC20 to NEP21 transfer, and it has already been synced, and now the user said that they want to do something so I’m going to mint it.” Alright great, we've listed all of our transfers, initiated it, but at this point nothing else is going to happen. There's no like, back end here. That's shepherding that transfers through this list of steps. So your app actually needs to check in and see if the approval transaction finished mining. And so for that you, import checkStatusAll from using your client, and you can check it on a loop like every 15 seconds, specified in milliseconds. And then you'll also need this onChange function, EthNEAR client, and just pass it your render function. This might be the thing that needs to change, it needs more consideration for things like react, but anyway, all together, we're going to import one, two, three, four, five, six things. I’m gonna add that form on submit to initiate the transfer, render all the transfers using get decorate and act, and then check in with checkStatusAll and onChange. And that's it! You now have cross-chain functionality in your app. So what's next? What's missing from this library? You might have noticed that there's no authentication or like web 3js initialization. Unfortunately, for all you Ethers fans, this right now, the proof logic, has deep dependencies on web3.js. Might be able to use Ethers in your own app, just understand that we will be importing web3.js as well. Not sure if you care about bloating your Javascript in that way, but anyway, some more consideration needs to be given to how this app is, how this library is going to handle that. If people have good ideas or libraries or they love the way that it handles like integration with metamask or whatever, I would love your links. Alright, so bridged NEP21 to ERC20 doesn't actually work in the UI. It does work in the CLI but we've got a link here for the browsers adding browser support for that. It is a work in progress. With some updates to NEAR wallet, NEP141 that I’ve been talking about is designed NEP21. The one that most of this has been referencing and the one that it's working with right now is just kind of a copy of ERC20. NEP141 is designed to take more advantage of some of NEAR’s unique characteristics like the fact that it's sharded, and the fact that it's asynchronous. The fact that it uses storage sticking, so NAP141, is super cool. We've had great audience, great community participation there. 10 And then our metadata extension as well. So then I need to actually publish libraries. Like I said, right now all of this currently lives inside this UI github repository, so we actually need to publish them. We'll be able to do that fairly soon and just have it be beta for now. Alright, no JS support. I want you to be able to walk through all of the same stuff in node and not have to use the, you know, not have it be browser specific. And then test it, sand it, polish it, that 25% success rate needs to be improved, obviously. So that's kind of where it's headed. ETA for all of this: I think all of this is like a couple weeks, this is all pretty easy, no JS support, and like making sure that we've caught all of the edge cases might take a little bit longer, so I think something like March is much more reasonable for that actually. Honestly, I could get to this one by the end of next week, so if people really want to build with a beta version of this, that's right around the corner. Okay, so where did we go? We saw a demo, we talked about what you can do with this, we talked about some key concepts, and we saw the four easy steps that it would take to add this to your app, and we saw our roadmap. If you want to dig deeper, again get these slides at chadoh.com/rainbow-bridge-talk. You can subscribe to our newsletter, we send it like once a month. So this is not specific for like hey V1 of the library is here, but it will include that. You can unsubscribe after we send that one if you want. There's this great introductory blog post all about the rainbow bridge. Some of my graphics were stolen from that. You can try out the rainbow bridge UI here, again I encourage you go to the last slide, appendix a: using the Robsten to test that bridge Ui. Wth a bunch of info. But we would love for you to try it and let us know. Weird edge cases, weird error states that we didn't expect, that would be super helpful for the testing, sanding, and polishing piece. There's a step-by-step walkthrough if you want to go through all of these manually on the in-your-command line. You can do that if you want to contribute to the library, here's a link to it again, it lives within the front end code right now. If you want to learn more about NP141, there’s a link on this NEAR.org/earn to Figment, which is a great community, created community maintained resource for learning all about NEAR and other blockchains. And there are I think three courses in there all about an EP141. And also, we have a grants program right now with one million dollars in grants available that we're trying to give away in like six months or something like that, so click this link and find out 11 more about that. And finally, we've got, I need to tell you all about our booth. These are my speaker notes. I don't have another screen, so I’ve got to just bring them up and let you read them. As well I’m at 40 minutes over time, oh no. Visit our booth at the sports castle to claim a free custom name and NEAR account , sputnik DAO, that's where this will link you to. And you'll find out more about the bounties there, and then we've, yeah, bounties, grants program, anyway you can read it there. i'll leave it up for a little bit, any questions while all of this is here? Or do we not have time for questions? Yeah i think we're out of time actually you called it yourself, 40 minutes man. It was really good though! Like I mean, you were, I don't think I’ve probably seen a more thorough interoperability-like tutorial, so all right, excellent job. So I mean, that's what this is for their technical workshops, right? So yep, the quintessential technical workshop. So thanks a bunch man! Yeah this was great, i will see you in space, take care. 12
Enter the password to open this PDF file:
-
-
-
-
-
-
-
-
-
-
-
-