Interoperability via the Rainbow Bridge - Chad Ostrowski

Very good. Okay, next up is Near Protocol and Chad will be joining us shortly. So there you have it. Hello. Chad O.

Can you hear me? I'm listening. Can you hear me? I'm listening. It seems that everything is fine.

Yes, I am sharing my screen. Look at that. You can see it now. I don't have a second screen, so I won't be able to see the chat while I'm presenting. So, Near colleagues, I hope you'll have my back .

Thank you. I'm going to start the presentation now. OK. Thank you for letting me know you're there before I change screens. Okay there before I change screens.

Okay , Ethereum and Near sitting in a tree , Ethereum and Near sitting in a tree . BUILDING. App developers, this is for you. We want you to help us put the finishing touches on our Rainbow Bridge client library. It has not been released yet.

I was hoping to have a beta version by now, but if I had submitted it by the end of next week, maybe I would have made it, but we're not there yet. Not in time for today. So, maybe they can help us cross the finish line. That's another option. So, this talk will consist of a demonstration of what the Rainbow Bridge interface looks like.

It still has a few details to polish, but it should work fine today. We'll talk about what you can do with Rainbow Bridge. And we'll talk about some key concepts and the four simple steps needed to add this bridge to your own application. We'll talk about the roadmap for where this is headed. And then, hopefully, we'll have time for some questions and answers.

So, let's begin. This is being implemented in Ropsten. So, if you have MetaMask or Brave with crypto wallets, make sure you're on the Ropsten testnet. They also need some ETH from Ropsten and there are some test tokens they can get, literally TST. All this information is on the last slide of this presentation.

So , again, chat.com/rainbow-bridge-talk will take you to these slides. Let's connect MetaMask B412. I'm going to connect to Near. The way Near connects is by redirecting to the Near wallet.

So, we'll also be connecting to Near's test network. If you create an account on the testnet, you will likely have test tokens in it. When I started using the test network When I started using the test network , it wasn't like that. So I got this elegant one without the test net. So, let's move on and start a new transfer.

So, in Ropsten, we have this TST token. I have 83 of them. Let me send one. I don't know if you have used MetaMask in full screen mode. Things are going to get a little weird when MetaMask shows up .

The MetaMask pop-up window literally takes up the entire screen. So that's what you'll see here. Confirm. We ended up back here. So this is now a multi-step process for an asset to cross the bridge.

First, you lock it on Ethereum. You can see that this transaction has already been approved or the transaction has already been mined. The approval transaction was mined and now we need to block it. So let's go ahead and do it. All of this will be explained a little more soon.

If you are familiar with ERC20 submission, it is generally a two-step process . So that's what you're seeing here. I am sending my TST tokens to this token lock contract . Very good. So, if it were easy to add functionality between strings to your own application, strings to your own application, what kinds of things would you do with it?

The ones that come to mind, that we've talked about and that we're excited to see people building, are using ERC20 tokens on Near, where block times are fast and transaction fees are cheap. There is at least one project that I know of that is already doing this with D. We have the bridge that was working on the main network and will be working on the main network again soon after some updates. And this application is not currently using the main network. Again, he will do it soon.

For now, it's just Ropsten for this interface. By the way, the interface is in near.github.iobridge front end is in near.github.

iobridge front end . Very memorable, I know. And that will also be improved, but anyway, you're seeing it in progress here. But they can now send tokens through the bridge using the CLI and then send them back to Ethereum again. Anyway, other ideas: they could allow users to create NFTs on Near, where transaction fees are cheap and we have a great account naming system that Matt Lock will be talking about tomorrow at the same time.

Where they can make it truly transparent for users who are using blockchain. So, it's easy to set up users to create NFTs, and if they make an amazing piece of art that they want to submit to Ethereum for listing on larger markets , it's totally feasible. You could allow users to balance liquidity and arbitrage between markets on both chains. And what's more, what are your ideas? I wish I could see the chat while I keep this open, but while I keep this open, but could one of my teammates join me on stage and act as a moderator in the chat?

Is that something we can do here? It would be great to have Matt Locker, Peter Depollo, or someone else. Could the facilitator bring one of them here so they can chime in when I ask for audience participation? Very good. Well, we'll see if that happens.

But anyway, I'm excited to see what their ideas are and what they're going to build. Very good. So, we're ready to mint in Near. Let's find out what that means. TRUE?

I told them that this can be done in four easy steps. So we want to start building, but first we need some key concepts. Let's talk about how the bridge works. First of all, you have clients, thin clients. We have a lightweight ETH client on Near that tracks [].

It's a complete lightweight client implemented as a smart contract on Near, and then an external relay that sends all block headers to the Near blockchain, where it keeps a record of the entire Ethereum blockchain, or enough to do this kind of thing securely. And then the same in reverse. We have a thin client, a Near thin client on ETH running on Ethereum, and an external relay that transfers everything. This is what it looks like. Again, here at Near, we have the ETH client at Near and the Ethereum headers being transferred.

Here on Ethereum, we have the Near client on ETH and the headers being transferred. The current implementation requires this surveillance service. So, when things are sent from Near back to Ethereum, this is because the cryptographic algorithm that Near uses is called ED25519. It is not available as a preset. I forgot 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 get rid of this and make Near to Ethereum transfers much faster.

But that's the basis, that's the core of architecture. You have a customer on each side. Next step, one level further, you have the validators (provers) further, you have the validators (provers) . And to the validators, you send them a test. You say this happened.

This event was broadcast on Ethereum and will say yes, confirmed, and will use the information in the client to prove it. Or no, that didn't happen. So you can't mint coins because the user would have, you know, the ability to spend twice. So, right now the validators we have implemented and maintain are the ETH event validator on Near. You can prove that an event was broadcast on Ethereum.

And on the Ethereum side, you can prove that the result of executing a transaction on Near was what you expected. Perhaps we will write other validators in the future. You can also write other validators, although this talk is aimed at application developers. So maybe the audience I'm talking to right now is n't the one that will go out and write these validators, but someone could go and write their own. Finally, the last step, you have the connectors.

The connectors come in pairs. You have something like token deposit on Ethereum and then you have a minted fungible token on Near. And analyzing this step by step, the fungible token connector. You could have a non-fungible token connector . The fungible token connector could send from ERC20 on Ethereum to our current standard, which is NEP21.

There has been a lot of excellent discussion in the community about a new token standard that will also be released before V1 of this library. And then, obviously, you can also go back. So you can also go back. So , this is what it looks like. I'll let you read this while I drink some water.

I allowed the token deposit to transfer my TST or my DAI. The token deposit then transfers ownership of that TST or DAI to itself. You wait until there are enough confirmations on the ETH client in Near. Those are the 10 blocks. And then you coin it in Near.

And when you mint it, you send proof of the event to the mintable fungible token. Near is an asynchronous blockchain. So, that contract will take a few blocks for this transaction to complete, but you will send proof of that event. And then it will make an inter-contract call to the validator, which will make an inter-contract call to the client, and then it will all come back, finish, and mint a token for you. So, let's give it a try.

Let's keep our fingers crossed. This has had a 25% success rate in my tests so far. We recently got the bridge working again in Ropsten after it had been down for a long time. And it almost seems that this is non- deterministic, that it works sometimes and sometimes it doesn't. So let's see if it works this time for the demonstration.

Usually, an error occurs here. Ah, look at that. On the first try. Very good. So, we went over all those steps.

This can be done in five steps. This has n't been four again because it's a contract call and then the contract makes a call between contracts. Okay, we have clients, validators, and connectors. The connectors come in pairs as a token blocker and a mintable fungible token . Note that we have two chains and four addresses to which assets can be sent.

You can have Ethereum as the origin, where a fungible token in Ethereum is transferred to a fungible token in Near, and then you send that bridged token back where it becomes a natural fungible token in Ethereum again. And the same in reverse, fungible token to bridged fungible token on Ethereum, transferred on Ethereum back to natural token on Near. The terminology for this starts to become a problem pretty quickly, doesn't it? There are many concepts to keep clear. And this is something I would really like to get your feedback on.

Um. Our best bet on how to call these addresses, and this will be used for the rest of the talk, is natural ERC20 to NEP21 and then bridged to NEP21. Back to ERC20. That part, NEP21. Back to ERC20.

That part, right? NEP21 bypassed. It's a bit of a right? NEP21 bypassed. It's a bit of a bridged ERC20, isn't it?

But it's very important to specify that it 's an NEP21, because if it were just a bridged ERC20, well, where does that live? Does it live in Solana or Polkadot? Does it that live? Does it live in Solana or Polkadot? Does it live in Near but it's an NEP 141 and not an NEP21?

Right? We want to know what type of token it is, what type of interface it has. The bridged modifier refers to where his life began. The bypassed or the natural, right? Is it where it was born or has it migrated?

That's what we define. That's what we're saying with this part, and then this part is what it is now. That's my best bet. But do you like this notation? If you're going to near.

ai solid slide, I'm not sure how this company wants us to pronounce its name. But go to that link near.ai solid and you can vote that link near.ai solid and you can vote . We have a few options for what we think this could be called.

Okay, so go ahead, go in there and I think you'll start to see, as you answer the question, you'll see all your answers appear on my screen. So go ahead , near.ai AI/Slido, and vote for what you think makes sense to call these things. Twitch people, you can do the same. Near.

ai solid and you can vote on what you think this should be called. I'm not sure if anyone has successfully visited that link , as I don't see anything appear , as I don't see anything appear . Please, someone reply so we know it worked. Huh? Huh?

No. Okay, I'll check the chat. What's going on? Slideo. Thank you, Aussie Mandas.

Has anyone actually gotten there? Yes, I don't think so. Actually, has anyone ever managed to get there? No. They should be able to answer this now.

Ah, there they are, the votes are coming in. Brilliant. But why can't I actually see it? Isn't Slido supposed to show me these things? Hide results.

Show results. H. Next question. Select a survey. Ah, okay.

I think it's because I'm on this weird mobile view. That's what's happening. Ah, NEP21 bypassed. My favorite. It also has plurality right now.

So, if you want anything else, let us know what it is. What are some other ideas? Near an ERC20. Nerk 20. Nerk 20.

That could 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. Yeah, great. Okay, um, I'm going to call this the 15 of you who voted.

I think more votes might still be coming in. NEP21, when bridged, is far removed from the rest. Let's leave it at that. If you couldn't vote and wanted to If you couldn't vote and wanted to , again, near.ai/Slido, but we're short on time, so I'll end with that.

Thank you for voting. Okay, we'll have another vote soon. If you couldn't participate in that one, you can stay on that Slido link and we'll have another one soon. So Slido link and we'll have another one soon. So , two chains, four directions, depending on which origin you're talking about, and then back and forth from that origin.

Um, this is the next topic of names that I want to talk about. of names that I want to talk about. What do we call it if you send Dai to Near What do we call it if you send Dai to Near ? Once in Near, is it Dai to N and then Dai N back to Dai? If you start on Near and go from banana tokens that you can mine on berryclub.

io and send them to Ethereum, is it banana to the power of E? We have some excellent options here. I think some of the other options besides this one might be your favorites. Head over to near.ai slido and you can take a look.

I'm going to press start on that one look. I'm going to press start on that one . Let's see. Nobody has voted yet. Oh, was that you, Matt?

Is that Matt Lock who's voting? I guess I have no way of knowing. Um, well, Endie at 21 is the clear winner. Oh, no. He is no longer the clear winner.

What 's the other one? Ooh, yes. Dai WASM and Dai EVM. But that doesn't specify which network it's on. We need to specify the string and whether it is EVM or WASM.

That's it... the string and whether it is EVM or WASM. That's it... We have an EVM, folks. So whoever said that knows something about our EVM.

Uh, End 21, but there would be a way to specify EVM here. Don't worry, this notation here. Don't worry, this notation ...all these notations are flexible enough to allow you to specify whether it's in our WASM runtime or EVM runtime. Okay, thanks everyone for voting.

How are we doing there? We're at 14. We had 17 in the previous one. So there are three of you who voted before who have n't voted here yet. Perhaps they are thinking about it.

I'll give you another 15 seconds. No, they're not going to decide. Mhm. Okay , that's all. We have Endi at 9 PM.

Very cool. Very cool. Very good 9 PM. Very cool. Very cool.

Very good . Oh, great. Can I see the results here? No, I don't know how to see the results, but anyway. Brilliant.

Thank you. That's a great help. Um, very good. So, let's go back to those four simple steps. Let's see how to add this to your application.

Step one add this to your application. Step one , you're going to need some dependencies. The idea here is that your JSON package will look something like this, where you have a Rainbow Bridge client that handles the core logic of how to store all transfers in local storage and how to display all transfers between different types of connectors. And then you'll also have a specific library for the connector, like ERC20 and NEP21, or maybe it will be 141 soon ERC20 and NEP21, or maybe it will be 141 soon , or if you're using NFTs you use this one. And if you want to write your own library if you want to write your own library , for example, our ERC20 fungible token connector does not handle tokens that use the rebase function.

So I think it's Ample and Based. I'm not sure I spelled the name right, but anyway, if you wanted to write your own connector for that, or if someone in the community wanted to write their own connector client, it could interoperate seamlessly with this one without any permissions system, right ? You just add this other library to your package, to your application, and you can also use transfers of that type in your package. So what we'll probably do here is...add an npm and a GitHub repository for Rainbow Bridge, and you'll know we officially support it if it comes from there, but you can also use community-contributed ones, and like I said community-contributed ones, and like I said , they'll interoperate seamlessly.

Well, another question arises. The Rainbow Bridge GitHub repository is unavailable. Perhaps it's not a problem. You can say that in the next poll, but maybe we can find a better name. One that I really liked was ETH plus MIR/ really liked was ETH plus MIR/ ERC20 plus NEP21, right?

Because it is both. You can use both. The plus sign tells you so. Super cool. But you can't have a plus sign in your package name, your GitHub name, or your npm name.

So what should we do instead? We have a third poll here and then we'll be done with the polls. But go ahead, let us know what you think ahead, let us know what you think . There are some fun options here . There are some fun options here .

Rainbow bridge, without a matching GitHub repository, no problem. ETH tilde near, that's safe for URLs ETH tilde near, that's safe for URLs . You can have that in your npm and in your package names. So maybe we want ETH tilde near. I haven't seen anyone else do it, but maybe it'll be fun.

Or simply ETH hyphen near, because the accent mark is kind of silly. Stop being corny. E to near. Nice and short, but it implies that the bridge is unidirectional and it is bidirectional. So maybe ETH and near or ETH with near, or it seems that some of you, or one or two people, have a better idea.

Arbo bridge. Nothing fun for you. Eth dasher. Oh, I feel like some of these others have been Mike Pervvis trolling me, if I had to guess. Maybe Sheree.

Don't know. Share. It's too late for Share, so maybe not. Anyway, it seems like some kind of team thing. We have more arriving.

Near-E. Very good. Near as the main one. Near O. What is the O?

Near O is fun, but I don't know what the O is. Maybe it's a bit too esoteric. E tilde. Surprisingly popular. I liked that one, but I wasn't sure if it would be successful.

I didn't know if the others... I feel that maybe some love it and others are very much against it. Um. Yes, that's what I've been thinking for a while. I put it in the readme file of the package that doesn't exist yet, but will soon be extracted exist yet, but will soon be extracted .

Everything has an accent mark right now. So if you get to the last slide, or the second to last one, and click, you'll see a lot of checkmarks. Um, very good. Well, this is fun. Wow, I don't even know what these are.

Nero. Hava. Nero. Did the same person fill it out twice? I feel like two people didn't do that.

I don't even believe it. Neath. They are near. Did you mean to spell it with a Y? They are near.

I guess maybe they're Near. The less than and greater than signs are also not safe for URLs. Unfortunately, you can't call your npm organization that. You also can't use fancy things like the double-headed Unicode arrow. Very good double-headed Unicode arrow.

Very good . Well, this was great. I'll give you another 15 seconds. So make your last-minute choices. I feel like this one might be getting more votes than the others.

No, just like the first one. Very good. Well, the 15 seconds are over. Thank you so much for voting. We'll finish that up, but we'll incorporate your feedback.

Thank you so much. Very good. We've already chosen the facilities. I think E tilde is the winner, right? Can I show it live?

Yes, E tilde is the winner. Well, "another" is the winner. It seems that people are not safe. So I do n't know if we've reached a firm decision here, but it could be ETH tilde firm decision here, but it could be ETH tilde . For the remainder of this talk, I will use the ETH script Near.

It was just my best guess as to what people might want. After having originally fallen in love with ETH, I tilde myself. Anyway, it will be yarn add-lant. and any connection library they want to use, any connection client. Very good.

We already have our two necessary facilities. Brilliant. We are ready to start sending ERC20 tokens to Near. What does that look like ? Step two, initiate a transfer.

Let's say you have a form. You'll need four pieces of information. It probably doesn't make sense to have all of these on your form, right? For example, I'm logged in with two accounts here, so I can use the sender and recipient from there. But hey, it 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 could change the name of that from the specific connector library. Actually, this is the only import we will use from this library. The rest will come from the main client.

So will come from the main client. So , uh, onsubmit form. Make sure you do n't, you know, reload the page. Get all the form entries. And then we'll say natural ERC20 to NEP21.

We called him and gave him the address, which is the value of the ticket. The amount is the value of the ticket. Sender and recipient. That 's all. We have initiated a transfer.

Brilliant. So, a little more about what these libraries have: they have four main exports. You have natural ERC20 to NEP21, which we just saw. You can go back to Ethereum. Those you just sent through the bridge to Near return to Ethereum, and you can guess what the other two are.

One for each of those four directions. This library also contains all the logic about how those different addresses work. The two that we have already implemented mostly, this one does n't work completely today, but the two that we have already implemented have different numbers of steps and very different paths that these transfers follow. So if you want to do a different type of trans, if you want to make a different connector and your client has different needs your client has different needs , I think this architecture still works. So I think it will still be able to interoperate with the client, the main client library.

That 's the goal here. Very good. Then, step three, list. Let's say you have this sorted list and you want to put all your transfers on it. You will import get from the ETHR client.

Everything else stems from here. Render transfers. Let's get all the transfers in progress. And then we'll take that ordered list "transfers go here" and set the inner HTML to transfers.map to render the transfer.

We'll see that next. And, by default, JavaScript joins arrays with a comma, which is a bad decision someone made in the mid-90s. So we'll join it with an empty string. This is native JavaScript, folks. This is like using no framework at all, but if you wanted to use React or Vue, this library will also work with that.

And I'll make sure of that before it even reaches version 1. React is my specialty. So I'll make sure it works great with React for you works great with React for you , if that's your preference. Very good. So, what does this "render transfer" look like?

We import "decorate" from the client and then, given a transfer, it will first decorate that transfer and specify the language transfer and specify the language . This is where information about the steps is added. So the library, the specific connection libraries , will be able to provide internationalization so you can list these steps in Chinese, Russian, or whatever. Um, and it will also add information about whether the transfer failed at this step. Is this step still pending?

So, it's real-time information and things that would just fill up local storage just fill up local storage , like the source token name, which would be the same for transfers from, you know, a specific address for each transfer of that type and address. Therefore, there is no reason to fill up local storage with that. So you have to run it through "decorate" before some of this useful information becomes available. Um useful information becomes available. Um , the call to action is interesting.

Let's look at that next interesting. Let's look at that next . So, again, we're doing things with basic JavaScript here. So I can't add something like "on click" directly to the line like you would with React, if that's what you're used to. Um, but what is this "act on transfer"?

Do you remember those little buttons that used to appear here that said "block mint"? That's the call to action that stores that small fragment of text as "mint" small fragment of text as "mint" . Um, but what's really happening there . Um, but what's really happening there ? How does the client library know what to do when you click on "mint"?

Well, you have this other import called "act". Again, basic JavaScript tricks. When you click on any part of the body, we check if you clicked this "act on transfer" button. If you did, we will search for the transfer ID by finding the closest match with a transfer class. That's it.

And we're going to get the ID. And then we're going to say "act on this transfer". And the client library will pass it to the connector-specific library, and it will discover: "Oh, this is an ERC20 to NEP21 transfer and it has already been synchronized, and now the user said they want to do something." So I'm going to do the "mint". Very good.

We've listed all our transfers, we've initiated them, but at this point nothing else is going to happen. There is no backend here monitoring the transfers through this list of steps. So your application really needs to check and see if the approval transaction finished mining. And for that you import check status all from ETH near client and you can check it in a loop, for example every 15 seconds specified in milliseconds. And then you'll also need this onchange function from ETH near client and simply pass it your rendering function.

This could be what needs to change. It requires more consideration for things like React. But anyway, in total we're going to import one, two, three, four, five, six things. We're going to add that form on submit to start the transfer. Render all transfers using get, decorate, and act.

and then verify with check status all and on change. And that's all. You now have string-to-string functionality in your application. So what's next? What's missing from this bookstore?

You may have noticed that there is no authentication or initialization of 3JS web. Unfortunately for ethers fans, at the moment the test logic has deep dependencies on web 3.js. You could use ethers in your own app. Just keep in mind that we will also be importing web 3.

js. I'm not sure if you mind overloading your JavaScript like that . But either way, more consideration should be given to how this library will handle that. If people have good ideas or libraries or love the way it handles integration with MetaMask or whatever, I'd love to receive your links. Very good.

So, the NEP21 to ERC20 bridge doesn't actually work in the user interface. It works in the CLI, but we have a link here to add browser support for that. It's a work in progress with some updates for Near Wallet. NEP 141, which I've been talking about, is designed; NEP21, which most of this has been referencing and which it now works with, is just a copy of ERC20. NEP 141 is designed to take better advantage of some of Near's unique features, such as the fact that it is sharded, asynchronous, and uses linked storage.

So, NP141 is super cool. We had a great audience and great community participation there. And also our metadata extension. So I need to publish the libraries. As I said, right now all of this lives within this UI GitHub repository .

So we really need to publish them. We'll be able to do that fairly soon and leave it in beta for now. Node.js compatibility. I want them to be able to do everything the same in Node and not have to use, you know, not depend on the browser.

Uh, and then test it, sand it, polish it. That 25% success rate obviously needs to improve. So that's where it's headed. The estimated time for all of this, I think, is a couple of weeks. All of this is quite easy.

Uh, Node.js compatibility and making sure you've covered all edge cases might take a little longer. So I think something like March is much more reasonable for that. In fact, honestly, I could get to this by the end of next week. So, if people really want to build with a beta version of this build with a beta version of this , uh, that's just around the corner .

Good. So, what did we see? We saw a demonstration. We talked about what you can do with this. We talked about some key concepts.

And we saw the four simple steps it would take to add this to your app. And we saw our roadmap. If you want to delve deeper, again, get these slides at shadow.com/rabbridge talk. You can subscribe to our newsletter.

We send it about once a month. So this isn't just to say, hey, the V1 of the library is here, but it will include it and you can unsubscribe after we send that one if you want after we send that one if you want . There is an excellent introductory blog post about the rainbow bridge. Some of my graphics were taken from there. You can try the rainbow bridge user interface here.

Again, I encourage you to go to the last slide, appendix A, using the option to test the user interface of the test bridge with a lot of information. Hey, but we'd love for you to try it out and let us know about rare edge cases , uh, weird error states that we didn't expect. That would be super helpful for the testing, sanding, and polishing part. There is a step-by-step process. If you want to do all of this manually on your command line, you can.

If you would like to contribute to the library, here is a link to it. Again here is a link to it. Again , it lives inside the front end code at this time. Um, if you want to learn more about NEP-141, there's a link on near.org/learn to Figment, which is a fantastic resource created and maintained by the community for learning about Near and other blockchains learning about Near and other blockchains .

And there are, I believe, three courses there on NEP-141. And we also have a grant program right now with one million dollars available that we'll try to distribute over about six months or so. So click on this link to find out more about it . And finally, we have, uh, I need to tell you all about our booth. These are my speaker notes.

I do n't have another screen, so I have to put them here and let you read them too. I'm 40 minutes late. Oh, no. Visit our stand at the Sports Castle to claim a free personalized Near account. Sputnik Dao, that's where this link will take you and you'll find more about the rewards, and then we have, yes, the grant and rewards program.

Anyway, you can read it there. I'll leave it for a moment. Any questions while all this is going on, or do we no longer have time for questions? Yes, I think we've run out of time, actually. We have it, you said it yourself.

40 minutes, man. But it was really good. I mean, I think I probably haven't seen a more comprehensive interoperability tutorial. So yes , excellent work. That's what this is for .

They're technical workshops, right? So you were the ultimate technical workshop. So thank you very much, my friend. Yes, this was great. I'll see you in space.

Take care.