NEAR Multichain

All right, we're live. GM everybody. Welcome to what's going to be another great DevNTell. If you didn't know, DevNTell is a 30-minute podcast for builders to showcase something they're passionate about and been working on in Web3. It's going to be an awesome project they've been working on, demonstrating you best practices, automation goodies, smart contracts, how to structure a project, etc. Basically this is your opportunity to share what you've built with the community. And today I am ecstatic to have Jacob on, who is going to be showing us some cool NEAR multichain stuff. Welcome to the show Jacob, happy to have you.

Thanks so much Narb, it's great to be here.

Excellent. I guess before we get into the meat of the content, did you want to give a brief introduction about yourself for folks who might not be familiar?

Yeah, so my name is Jacob. I've been working with NEAR Protocol for just about three years at this point. I originally got started as just an interested hacker, I joined a coding bootcamp that they were putting on and from there I, you know, fell in love with the protocol and joined NEAR Foundation. I've since switched over from NEAR Foundation to Pagoda. Pagoda is just another entity within the NEAR ecosystem and Pagoda is the entity that does most of the protocol development. Over at Pagoda, I work on a lot of contract, smart contract stuff, so everything from smart contract libraries to working a little bit on the runtime submitting a couple of NEAR enhancement proposals. We'll look at one today, not one that I submitted, but we'll look at a NEAR enhancement proposal today as well. Yeah, so I do a lot of Rust coding and yeah, that's me.

Awesome. So yeah, like right in the thick of it, building all of the cool foundational stuff on NEAR. That's awesome to hear. I guess in the interest of time, let's get right into the meat of the presentation here. So I'll add your screen to the stage here and you're good to go.

Cool. All right, awesome. So there is a problem with how Web3 works today and that is this screen that you might get in MetaMask every now and then where you're, you know, working on a dApp and it asks you to switch networks, right? So oh, I'm on Ethereum and I now need to switch networks over to Polygon or zkSync or Binance Smart Chain or Arbitrum or Optimism or Scroll or something like that and you just have to keep switching networks and switching networks and you know, you still have control over the same keys, but you're submitting transactions across all of these different networks and you have to keep track of your assets across all of these different networks and it can just get a little bit confusing. So the technology that we're going to be talking about today is an attempt by NEAR Protocol to solve that problem. And the first step in the solution to this problem is something called chain signatures using a multi-party computation, also known as MPC, multi-party computation. So the basic idea here is that I want to use my NEAR account to create and sign transactions that then get sent to other chains, right? So you can kind of think of it like an extremely lightweight one-way bridge, but it's significantly less complicated than a bridge, which means that it's going to be way faster. We're talking about resolution times of under a minute generally. Obviously it depends somewhat on the finality time, the block time of the foreign chain that we're kind of trying to communicate with from NEAR, but generally we're looking at much faster resolution times than some bridges might take, you know, sometimes depending on the bridge, you're talking about, you know, a couple of minutes, 15 minutes, even an hour or so to transfer assets over. Again, this is not entirely an analogous solution to a bridge, you're not going to be bridging assets over, you're bridging transactions, but in a lot of ways it's going to try and solve similar problems, you know, managing assets across multiple chains from one single account. Right? Cool. So there is an NEP that I want to introduce you to here, it's NEP 503 here. Narb, do you have the link to this that you can post?

I do.

Or do I need to send you that?

If you send it in the chat, I will share it with the gang.

Awesome. All right, so I'll send you that. This is NEP 503, submitted by my friend David here and this is a very high-level overview of what chain signatures might look like. So all of this is still very like early cutting-edge technology, we have like testing versions of this that we're working on, we're just really excited about this and super happy to get the word out to you even before it's fully released. I think the timeline for release on this is going to be end of March, I believe.

Do love our Alpha on this show.

Yeah, absolutely. I mean it's all open source, so... yeah. All right, so the way that this works is we... so this is going to exist right now, it exists as a smart contract. So we have a smart contract called the Multichain Signer smart contract, we'll call it that for now. And what's happening here is someone is going to call a function called, for example, sign, you pass in a payload and you get back a signature, right? That's pretty much what this function signature is describing right here. And the kind of pertinent question is where in the world does this signature come from? Because you don't really want to put any private keys on-chain because then they're no longer private. Right? So this is where the multi-party computation comes in. We have a bunch of different... you could think of them kind of like signature... or key shareholders that exist, they're like nodes on a network, not unlike say block producers for an L1 blockchain, but instead of being block producers they are signature producers. So they're going to hold a little share of the private key and then when a request comes in for a signature for a payload, they'll contribute a little bit to producing that final signature using their tiny little share of the private key.

There's a lot of interesting tech behind that that we don't need to get into right now but generally on a high level, that's how it's going to work. One interesting feature that's in the version that we're working on that's not visible here in this function signature is the ability to parameterize a signature with additional metadata. So a signature or the private key that will be used is an HD wallet signature or an HD wallet key, which means that you can kind of choose that key path, right? So this contract does give you the ability to modify what that key path looks like slightly. So it's always going to be keyed by whoever calls this function so that, you know, if Alice.near calls sign and then Bob.near calls sign, you know, it's not going to look like they were signed by the same person because they are parameterized by whoever called the sign function. So Alice.near is going to get a different signature for the same payload than Bob.near is going to get. But Bob.near can also add more information here like extra path information that can allow him to essentially have an unlimited number of private keys that he can manage with this contract. This means that I as a NEAR account holder can generate signatures on-chain in a fairly trustless manner. Right now there are still a few trusted components that exist in the version that we are testing that we're trying to eliminate gradually. Right now there are still a little bit of trust in the system yet, but we're working to eliminate that. Again, it's all very early testnet stuff right now, so it's not a perfect technology yet, but we're working on it.

So this gives us the power to develop a second smart contract that uses this as kind of a primitive on the network. And that is the Multichain Gas Station smart contract. This guy right here, I can send you that link as well. Get that over to you. And this is... so this is a second smart contract that's going to interact with that first Multichain Signer smart contract. And what this smart contract does is it's going to manage an account for itself and it's going to manage some accounts for other entities as well.

So the account that this gas station smart contract is managing, we're calling a Paymaster, and that's going to exist on the chain that's kind of our target here. So let's say I want to send... I'm a NEAR user and I want to send a transaction on Ethereum because I want to interact with Uniswap or some other application, right? So I'm a NEAR account holder and I don't necessarily have an account on Ethereum that I know of at least, so I don't have any Ethereum to pay for the gas for that transaction. Now Ethereum has their own solution to this with account abstraction, but again, that's not solving the network switching problem. So we're using kind of a similar solution here except it's split across chains, right? So I'm going to pay for the gas for my Ethereum transaction using NEAR and then there occurs kind of an implicit cross-chain token swap, you could say, of very small value of course because we're talking about gas costs right here. So I pay for gas costs using NEAR on NEAR and then this contract says, okay, thank you very much for the NEAR tokens. I control an account on Ethereum that has some Ethereum tokens and now since you've paid me NEAR on NEAR, I will send you enough Ethereum on Ethereum to pay for the gas for that transaction.

So that means that one transaction that I say, oh, I want to send this transaction on Ethereum turns into two transactions on Ethereum: one Paymaster gas funding transaction and then the real transaction that the user wants to send. But it also means that, you know, someone on NEAR can now just send a transaction on Ethereum without having to maintain their own say Ethereum keys or have a balance of Ethereum just to pay for gas or find someone else to pay for gas for them on Ethereum with the account abstraction. And it also generalizes to a whole bunch of other chains as well. Right now we're looking at obviously Ethereum compatible chains and we have some other chains in mind as well that we are looking at right now. This version of this smart contract right here is for Ethereum compatible signatures though. All right, so that is like a really high-level and very fast overview of this technology. I guess Narb, did you have any questions, anything that stood out to you that you'd like me to maybe go into more depth about?

I guess just for clarification, from the payment side of things, seems like the source chain, so it's NEAR, when you want to send any data or when you want to send the transaction to another chain, you pay in NEAR and is the Master Gas contract, is that funding the destination chain's gas costs or is the NEAR that I paid being converted into whatever the destination token is to account for that gas?

Right, so the way that this particular contract works is it consults an oracle to kind of figure out what the exchange rate looks like, but it doesn't actually perform any sort of token swap because obviously that's a cross-chain endeavor, which if we were actually, you know, concretely bridging tokens and then performing a swap, that's going to take a long time and be really expensive, especially when we're talking about the amount of tokens that, you know, just to pay for gas, it's probably not going to be worth it. It's going to be more expensive to actually do that whole bridging and then DEX swap process, that's going to cost more in gas, you know, because for all we know, this transaction that the user wants to send on the foreign chain is just like a, you know, like claim an NFT or just maybe it's just transfer an NFT, you know, which would be an otherwise very cheap transaction. But if we're adding all of this overhead of, okay, bridge a token, swap a token every time you want to pay just for a little bit of gas, that's going to be really expensive. So there isn't a token swap that occurs at the moment of like relaying that transaction to the foreign chain. Instead what happens is we consult an oracle, say, okay, what is the exchange rate look like right now, charge them the equivalent value of NEAR and then we just have an account that's sitting over on Ethereum that we're continually topping up with more Ethereum, you know, every couple of hours, every couple of days depending on how quickly it's getting depleted, right? And that's kind of where the swapping occurs, right? So the contract here on NEAR is going to collect NEAR and the account that this contract manages on Ethereum is going to be slowly depleted of Ethereum tokens. And that's kind of how that exchange works. Does that kind of answer the question?

Yes, yes, that's clear now. And I guess you touched on it a bit, but what kinds of interesting use cases are you guys envisioning for this tech to enable? Is there like a particular niche or something?

Right. So there are I think two that I think are really interesting. So a tech that we released... oh goodness, I don't even know when we released it, it's the delegate transactions or meta transactions, which allows someone else to pay for your gas on NEAR, right? So kind of maybe sensing a theme here, right? So I can submit a transaction without paying for gas and kind of leverage a sponsor to pay for my gas. So let's say I have an account on NEAR but I don't own any NEAR. And that's possible with zero-balance accounts, implicit accounts, whatever. So I have an account on NEAR but I don't have NEAR. Maybe I have some other tokens like USDC or some other token on NEAR that has value, but I don't have any NEAR native token to pay for my own gas. So I create a transaction that says, okay, hey sponsor, I have this transaction, I'll pay you a little bit of USDC if you pay for my gas on this transaction, right? And then sponsor says, great, I like USDC, so they pay for your gas, right?

Now what if another thing you could do, I guess, is say, all right, hey sponsor, I'll give you some USDC if you pay for my gas on NEAR and, you know, pay for NEAR to pay for a transaction on Ethereum using this setup here. And a sponsor could just as easily say, hey, yeah, I'll pay for your gas here natively on NEAR, I'll pay for your gas on the other chain using NEAR using this contract setup, and all you have to do is pay me a little bit of USDC. And guess what? You never had to go to an exchange and purchase some esoteric native token for all of these different chains that you want to work with, you just used a fungible token. So now using this sponsor meta transaction setup and these chain signatures, you can also, you know, submit transactions where you don't have to worry about paying for gas in the corresponding token to whatever chain you perform the interaction on, you just pay for it using, well, whatever a sponsor accepts. So it kind of generalizes that as well. The other use case that's really interesting is at least with the contract how it's designed right now, it would allow not only say, you know, a wallet, because a wallet might be interested in being a sponsor, and that's a pretty easy step for a wallet creator to take is to say, oh, look my users have a lot of USDC and maybe not a lot of native NEAR, so I'm interested in becoming a sponsor. Right? So that's an easy step for wallets to take. But another interesting use case for this contract is actually now other smart contracts can call this smart contract and conduct transactions on other chains, which is pretty interesting.

Yeah, yeah, that is quite neat, I'll say. And basically is making interacting with chains way more approachable for the average user who doesn't, maybe doesn't know how to, like you mentioned, go and buy these different tokens or know which ones to buy, right? It's like USDC is very familiar for a lot of people and yes, yeah, definitely can see the transformative nature of this.

Yeah, that's really one of the goals we have with NEAR. If you have experience working with NEAR's ecosystem tools, you'll notice that NEAR is a very friendly wallet... or it's a very friendly ecosystem, I guess, the wallet being probably the first point of contact that many people will have with the general ecosystem. But you'll notice that the NEAR ecosystem feels a lot like Web2, right? Because we have a lot of web wallets and every time you want to use a dApp or something, you log into the dApp and you get presented with a kind of a permissions acknowledgment screen, not dissimilar to what you'll get when you say like, oh log in with Google and then the log in with Google screen comes up and it says do you want to allow this application to access your calendar, access your emails, access your contacts, access your whatever, right? So is a very, very similar process to that. You know you say, hey, I want to use this app, I want to use Ref Finance or whatever. And then you say, okay, yes, I want to use Ref Finance, I'm going to log in with my NEAR account, then you see this permission screen that says do you want to allow the application Ref Finance to, you know, do whatever action Ref Finance wants to perform and then you click yes and it feels very similar to this like Web2 process that we're all familiar with with traditional federated login. So that's really something that NEAR Protocol is striving towards is making Web3 feel intuitive, feel natural to people who are used to Web2.

And we need a lot more of that in this industry. So it's great to hear that's top of mind for NEAR.

Yeah, lowering the barrier to entry, that's the whole goal here. It comes with a lot of fun other possibilities as well. All right, do we have other any other questions or maybe people from comments or something?

Nothing in the comments at this moment but gang, if you do have any questions please post them in the comment section and I will ask on your behalf. Sorry I might have derailed your presentation but we have about five or six-ish minutes left if you want to power through something else.

All right, cool. We can mention that we might have a bit more technical audience here, which is great. So we can dive a bit into some of the interesting problems that we have to solve here. So one of the things you'll notice about this contract if you take the time to read it is that a transaction, sending a transaction you don't just say, hey I want to send this transaction over to Ethereum. It actually requires a couple of different function calls in sequence. And at first glance it's like it doesn't really require multiple function calls, right? Because what happens is you call this create_transaction function call and the create_transaction function call returns to you kind of a transaction signature request ID and then you have to call another function called sign_next and pass in that ID and you have to call this function like twice. And it's like, okay, why is there this sequence of function calls here? This is not exactly necessary, but it is really nice because currently one of the more interesting things that the signature contract is doing is, so I submit a transaction where I'm saying, hey can you sign this payload. And then all of the private key shareholders, they have to get together off-chain, work together to form the signature and then it's submitted back on-chain and then this sign function call can return that signature. Which sounds a little bit strange maybe to people who are familiar with the Ethereum ecosystem, it's like how can you kind of delay this function call resolution, right? Doesn't it all have to return the value right away, right? And in NEAR that's not exactly the case because we have asynchronous receipts, so a transaction can span multiple blocks. But then the question is, okay, how do we get this sign function to kind of wait multiple blocks for the signature to come back from the private key holders. And the answer we would like to give is using some sort of like continuation function where, you know, you submit a receipt that just says, okay, I'm waiting for this data that's going to come from another source, but that does not exist in NEAR Protocol right now. So right now this sign function just kind of sits there and spins, right? So it just calls itself once every block and it just keeps calling itself until someone else has called the contract and delivered the signature that it's looking for. Cool. That means however that this sign function uses a lot of gas because every block it's calling another function and it just keeps calling the function and it's in an effort to actually just wait, right? Just sit around and wait for that signature to be delivered back. So that means that this sign function uses a lot of gas. Luckily on NEAR gas is pretty cheap, but there is a gas limit for a transaction. So this way of breaking up the transaction signing process into three function calls, which can all be called like right very quickly one after another. So ideally this doesn't really create any sort of delay because they can all be called... well you call this one. This one doesn't take very long to resolve. Does it just pretty much validates the payload and then gives you a transaction ID. Then you call sign_next and you just give it the maximum amount of gas so that the sign function call for the multi... for the MPC signer contract can have as much gas as possible to work with for one signature. Then you call sign_next again with again as much gas as you can possibly attach, again so that the second signature can also have as much gas as it needs to wait for resolution and then you'll get your signatures back. But once this is finished then hopefully we'll have a sort of like continuation functionality, maybe even in protocol. Again it's something that we're discussing working through right now and then this kind of three-step signing process won't be necessary. So even simpler, yay. But just some fun technical issues that we are working through to give you a glimpse of what it takes to design this sort of thing.

Definitely, definitely. Yeah, it looks like it isn't trivial to say the least, but a very important problem it seems like that's being solved here. Unfortunately, that does bring us to time. If you had something else we can stay on for another like 5-10 minutes. Happy to do so.

Those are all the materials that I have to present right now. Again like we can talk through the code all day, this is what I do all day is I write code like this, so I can talk about this a lot if you're interested in reading more code, but otherwise those are all the materials that I had to present today and that pretty much covers everything I wanted to say.

Excellent. I guess since this is open source, and if viewers are interested in helping to build this out, are they open to do so? Can they pick up any open issues that are on the repo?

Yeah, so there are issues that you can pick up as well, although this gas station smart contract is still pretty early in development, there is a testnet version but it's again still very, very early, so this one is probably not going to be quite as interesting to maybe submit issues to. However, let's see here... give me one second to pull up this link for you... the signer smart contract probably a lot more interesting at this point in time. So I'm just going to pull up that link... if I can remember what it is... And for all our viewers we'll have all these links for you in the YouTube description after the show. Yeah. So if people are interested in looking at that multi-party signature technology, that's that link that I just posted there. And that repo actually contains all of the code for the key holder... the key shareholders as well as the on-chain smart contract, so you can look and see how this whole system works.

Excellent. And yes, unfortunately that does bring us to time then, but it was awesome seeing this all in action, Jacob, and thank you so much for taking the time to come on. I'm really looking forward to seeing how this continues to evolve over time here. Yeah, my pleasure. Thanks so much for the opportunity to speak to all of you, it was my pleasure. Excellent. And before everybody leaves, I just want to share the QR code here for you to scan to be able to claim your NFT for being an attendee here on DevNTell. So what you'll want to do is scan this QR code with your regular QR code scanner and fill out the form and you will be airdropped a NFT on the Base network within the next handful of days. Again, you'll want to scan this code, fill out the form and you will have a attendee NFT dropped into your wallet on Base within the next handful of days. And this will be open for the next, let's say hour and a half. And with that, I just want to wish everybody a very happy Friday, happy Saturday wherever you may be around the world and we'll catch you back here next week on DevNTell.

Thanks so much everybody. Take care.

Bye-bye.