NEAR NEAR Onboarding Bootcamp, 13 Jul 2021

Previous Meeting

⏯

youtube image

►

From YouTube: NEAR Onboarding Bootcamp | Part 4 of 5: Aurora

Description

Aurora is an Ethereum Virtual Machine created by the stellar team at the NEAR Protocol, delivering a turn-key solution for developers to operate their apps on an Ethereum-compatible, high-throughput, scalable and future-safe platform, with low transaction costs for their users.

When you deploy your Ethereum app on Aurora, you’ll benefit from:
- Full Ethereum compatibility: Aurora is fully compatible with Ethereum. No need to re-write your applications.
- High throughput and scalability: Aurora runs on the NEAR Protocol, one of the highest performance third-generation L1 protocols, from one of the most highly regarded teams in the industry.
- Low transaction costs: Your users will not only enjoy fast transactions, but very economical ones as well.
- Features, Features, Features: From its core SputnikVM, to full tool-chain support, to gasless meta transactions, Aurora is the most advanced EVM on the market.
- Trustless Bridging: The Aurora Bridge, as a part of the NEAR Rainbow Bridge, is the only fully trustless asset bridge in the Ethereum industry.
- Base currency is ETH: Transaction fees in Aurora are paid in the base currency, ETH, providing a great UX for user, and opening the door to interesting ecosystem sustainability possibilities.

Aurora is an Ethereum-compatible scaling solution leveraging the next-generation NEAR Protocol.

The Aurora environment consists of the Aurora Engine, a high performance EVM—Ethereum Virtual Machine—and the Aurora Bridge, facilitating trustless transfer of ETH and ERC20 tokens between Ethereum and Aurora, within a great user experience.

Aurora exists and will be operated as an independent, self-funded initiative, but will continue to leverage the shared team DNA and continually evolving technology of the NEAR Protocol.

The governance of Aurora will take a hybrid form of a Decentralized Autonomous Organization—the AuroraDAO—complimented by a traditional entity which will hold one of several seats in the AuroraDAO.

Visit http://aurora.dev for more

Follow the latest from NEAR Protocol on:
Website: https://near.org/
Discord: https://near.chat/
Blog: https://near.org/blog/
Twitter: https://twitter.com/NEARProtocol
GitHub: https://github.com/near https://github.com/nearprotocol
#Blockchain #FutureIsNEAR #NEAR #nearprotocol

A

All right, can you guys see this.

B

A

Awesome all right so um hello, everyone, everyone, my name is michael burch. I've worked at near for a little bit over a year, and I've been on the aurora team for a couple months. um I'm just going to give a quick overview about aurora sort of what it is where, where it's been and talk about some of the tech at a at a pretty high level. um I'll keep it brief. But I have some questions at the end.

A

If people want to ask more uh in-depth questions and and feel free to um interrupt me as well, if something doesn't make any sense, so the whole point of aurora is to connect near and ethereum and benefit both both ecosystems as a result.

A

um So, on the ethereum side, right thinking about like developers coming from ethereum and working on aurora, what are they getting they're getting the benefits of near, so they get a one-second block time, the scalability of of near, which is, of course, still a work in progress, but um something that that they're definitely going to benefit from in the future and and the low transaction fees of near as well like much much much lower than what it would be on ethereum itself and then on.

A

On the other side, when it's near get near gets all of the benefits from ethereum. Being you know, a pretty well established, blockchain right, they've got all this d5 infrastructure with assets and liquidity that we can bridge over and make use of on the near side, and they have an existing developer base.

A

You know that helps grow near helps, push adoption when, when other developers are um using the platform and an existing tooling as well, which is which is a pretty big deal when you think about like people are worried about. You know.

A

Smart contract audits and people are worried about um deploy, processes and, and this sort of thing so being able to use tools that they are already familiar with means that they can sort of get going with with near and by aurora, um with with as little um stumbling blocks as possible as little change as possible, and so that brings me to this this final point here, which is the ethereum compatibility.

A

We want aurora to be fully ethereum compatible, so we want people to be able to just take their code as it is on ethereum not do any changes and be able to to deploy it on uh aurora, so same byte code, same tooling, whether it's truffle or hard hat metamask for for interacting with apps same same interface, all that kind of stuff, so aurora has been uh around not very long technically, uh officially launched, may 12th, but the bridge, which is one of the big technological pieces of aurora, was was launched much earlier back in april and then of course, it's been worked on for a long time.

A

um Originally, the evm piece of aurora was actually part going to be part of near core, but we sort of pivoted and decided to to make it as a smart contract on top.

A

Excuse me, on top of near instead and there's, there's still a few artifacts hanging around in the near code base as a result of this pivot, um but there there are to-do items to eventually get rid of them, but I think this is worth pointing out. You know for people onboarding uh onto the near team, because they they might be confused like oh, why? Why do we have all this evm stuff that doesn't appear to be um used at all?

A

Yes sandy, I see your hand is up and.

B

Actually yeah, I I'm not a boot camper, but I have a question so.

A

Like what does it mean.

B

That of like, initially, we wanted to have it as part of near core, but then we decided to have it as a smart contract and like how does it work and what is the difference? That's what I never understood so a good time for me to ask the question: yeah.

A

Yeah great question, so when it's part of near core, basically, what that means is it's actually baked into the run time itself right? So, if you think about what a smart contract looks like on on near it's um a set of wasn't by code that gets executed by some wasm interpreter virtual machine and there are host functions because wasn't right. Has this external function interface that it calls out to the node itself and the node runtime fills in these these host functions.

A

So as far as I understand it- and I I wasn't working on this at the time- so this might not be exactly what the plan was, um but as far as I understand it, basically, the evm commands were going to be essentially host functions right, so you could take evm byte code and pass it into the runtime and say here run this for me and give me back the result.

A

Whereas what we're doing now is we've actually got all of the evm logic as wasm byte code, so it's executing within the wasm piece of the near runtime, whatever the wasm vm is right. So, in some sense, this is now like a near native contract.

A

There's nothing special about the evm relative to any other smart contract, whereas if it was baked into near core, then at some level the near protocol itself understands what the evm is and what it does, which introduces a lot of complexity in the protocol, and that's one of the main reasons why we didn't want to do it that way, anymore.

B

So is the whole evm compiled into a.

A

Wasn't bytecode.

B

And deployed like that yep, oh amazing, I didn't know that that.

A

Yeah, it is amazing, it's pretty it's pretty impressive um right, any any other questions about about that cool. Okay, so we'll move on here. um So the first technical piece that I want to talk about is is the rainbow bridge. This is like. I was saying in some ways the the big technological uh piece of of aurora. um I actually chose to wear my rainbow bridge shirt today. This was you know some near swag that uh was put out around the same time as the bridge launch um so very high level.

A

The idea here is, we have two smart contracts. You know we have a smart contract on here and a smart contract on ethereum and they understand how to use the data from each other's blockchain right. So, on the near side, we've got a wasm smart contract written in rust, and it understands what to do with ethereum block headers and on the ethereum side. We've got a smart contract written in solidity and it understands what to do with near block headers.

A

So the idea is that you effectively have a ethereum node living on the near blockchain in the form of a smart contract and a near node living on the ethereum blockchain in the form of a smart contract, and so what this lets you do is when you're interacting with either blockchain eventually and we'll talk about the eventually in a moment the other blockchain learns about this because of these clients.

A

So as an example and we'll talk about this again later on as well, if I deposit some tokens, I lock them up on the ethereum side say die or whatever there's going to be a block that contains that transaction and that block is eventually going to get relayed over to the ethereum node living on the near blockchain.

A

And then someone later can submit a proof to nir and say hey look. This is a this. Is a merkel proof showing that this transaction was in this block.

A

Please mint me some some dye on this side to correspond to the amount that got locked up and so we're effectively transferring the tokens in this way and the client is then able to verify that proof and say: oh yes, you know, I understand that this miracle proof corresponds to this block header, which I have um and, and this is all a legit transaction.

A

It does the proof of work, verification as well to make sure that it's on the longest chain. um But again the high level is basically you've got ethereum node on the near blockchain and near node on the ethereum blockchain and then some infrastructure to relay the information back and forth, and some logic that takes care of the proof of work stuff and the signature, verification for proof of stake, and that kind of thing.

A

um There's a couple caveats to to this, which make it a little bit more complicated than this picture. One is the rate at which you actually send data back and forth right. It becomes expensive. Imagine if you were to try to send literally every block from near to ethereum. Every second you'd have to be sending a block, and that would be totally infeasible, so you, you actually only have to send one block per epoch because of details around how the the near um protocol works um and then on.

A

On the other side, um I think it's also done in batches there's some number of headers that get batched up into a single transaction for for efficiency reasons and so effectively. What that amounts to from a user perspective is there's some latency when you try to go across blockchain, because you have to wait for a certain number of blocks to appear before the transaction is finalized and there's some details there around that as well, because ethereum doesn't actually have a real notion of finalization.

A

So there's questions of like how many blocks are good enough and so on, but I'll I'll leave it there for now I'll share these slides afterwards. So you can, you know, go through any of these links. If you want for for more for more details or if you have a particular question, we can talk about it at the end.

A

So now we'll talk about the the engine, so this is a very rough sketch of what the the architecture looks like. So I mentioned the evm logic is all baked into the was, and by code of our contract itself. That's courtesy of this sputnik vm library, that's a library that was originally developed by parity and we've made some contributions to it as well, but it's basically an evm written purely in rust, and so we can compile it to wasm no problem um and in fact it's just an ordinary.

A

You know: cargo dependency inside our rust smart contract, which is compiling to wasm. So the the engine contains this uh core evm library and then we've written some extra logic around it. That includes things like account: state management and the uh connectors which we'll talk about on the next slide. So all that is wrapped up in our contract and it gets deployed on on near so then how does this actually get uh interacted with by ethereum infrastructure?

A

Right because remember, we want full compatibility, so we want things like metamasks to be able to talk to it. So we have an intermediate layer here which um we're still thinking of a good name for, but for the purposes of this presentation, we'll call it proxies in the code base. We call them relayers, but then relayers becomes kind of an overused term. So for the sake of differentiating it from the three other usages of relay or we'll call it a proxy for now.

A

But the idea is that the engine exposes some interface right. We, hopefully you guys, have already seen a presentation about interacting with smart contracts on near so there's some interface that the engine exposes and the proxy knows how to talk to it. But the proxy also understands the web 3 rpc like the the geth or um I think it is actually exactly the guest standard that we're using uh for ethereum. So any of the ethereum tooling can talk to the proxy and you know, make requests like.

A

Oh tell me the nonce of this account or get me the the code state of this account or process this transaction and the proxy understands how to take that request and translate it into the corresponding engine request which it can submit to the near blockchain, get the result back and you know reformat it back to what the ethereum tool is expecting.

A

So at a very high level, that's what's happening. Obviously there are some details here and again, maybe I'll mostly hand wave them away.

A

But one thing you might wonder about is what about payment right, because ethereum tooling expects payment to happen in eth, whereas the near transaction that actually happens expects the transaction to be denominated and near, um and so the the technical solution there is.

A

The proxy actually has an account on near and the uh proxy will try to convert the eth into near and sort of charge it in in that way, um and we'll talk about that a little bit more in the next slide as well, um but as of right now, anyways we're not bothering with that complexity because we're still trying to build adoption. So, for now it's it's just all the transactions are actually free and that's that's fine.

A

We're willing to you know, fund the um transactions that are happening right now, because there aren't that many and again this is sort of the benefit of near right is that transactions are cheap anyways.

A

So this is sort of short term uh fine and then, in the long term we have a technical solution and and again there there are some links here if people want to after the presentation, go, look at and get more details, so the last thing I want to talk about is the aurora bridge, which is a distinction from the rainbow bridge based on the target of this right.

A

So in both cases the bridge on the other side is ethereum, but on the near side the rainbow bridge is actually targeting the near base run time, whereas the aurora bridge is meant to target the the engine right, we're targeting the sort of pseudo evm runtime that exists inside this engine.

A

So for this we have some some special codes. So we have things called connectors. Connectors are basically just the logic that that talks about locking and unlocking eth um or erc20 or whatever um we still reuse a lot of the rainbow bridge infrastructure. So I was talking about these clients being like nodes on the other blockchains like near on ethereum and ethereum, on near and and provers to show that the the transactions are finalized correct.

A

So we reuse all that infrastructure. We have some extra logic for the locking and unlocking, and we also have some dedicated again we're using the word three layer here, but here I think it's maybe the best usage of it, because we're literally taking events from the ethereum solidity smart contract and we're converting them into um near transactions so that the minting process becomes automatic. You know you send your eth to the eth connector on the east side and automatically 10 minutes later.

A

Your um uh near beef, your east, on the near side, has appeared because the relayers automatically picked up the event, the deposit event from the smart contract and submitted a a new transaction on your behalf.

A

So this this a couple bullets summarizes that here. So we send some ethereum to the eve connector contract, there's a deposit event from that contract and the relayer captures it constructs a proof showing the event actually happened sends that over to near the near contract, verifies that proof and mints the eth on the user's account, and then I mentioned that the the idea here is, you know we want to be able to mint directly into the sort of pseudo run time of the aurora engine, as well as being able to mint directly onto mirror accounts.

A

B

Wrapping up here.

A

I wasn't keeping super close taps on my time, so I apologize sandy if I went over um again I'll show these slides afterwards, but um a couple resources here again. If people are looking for more details or want to chat about this, some more we've got some telegram links and- and that is all so happily taking.

A