On December 18, 2021, at the 8th Old Friends Reunion Scaling Summit, we are pleased to have invited Alex Shevchenko, the CEO of Aurora to give us a thought-provoking keynote speech!
Overview:
Aurora is a solution that allows to execute Ethereum smart contracts on top of the more performance environment, which is the shard Near blockchain. For Ethereum, it allows for the scalability of the decentralized applications that are running there and allows to cover additional markets for these DApps. For Near, it allows to quickly bootstrap the Near ecosystem and helps to scale the amount of the applications and the different operations that are available on top of the Near blockchain.
-The base token or the token that is used to nominate the fees for the user transactions is not an Aurora token. They are using ETH as a base token, which is very important for mass adoption.
-Aurora now has a partnership with Consensys and they are working with Infura team on the integration of Aurora in the set of Infura products.
We’ve captured the full learnings and takeaways from Alex’s share below:
Hello, everybody. I’m Alex from Aurora, and today I would like to present you one of the important solutions that we have in Aurora project ETH as a base token. Why it matters and how it is implemented.
To begin with, let me start with something pretty simple. Let’s start with an overview of what Aurora is. So essentially, in a nutshell, Aurora is a solution that allows to execute Ethereum smart contracts on top of the more performance environment, which is the shard Near blockchain. This is a very interesting solution for both the Ethereum and Near ecosystems. For Ethereum, it allows for the scalability of the decentralized applications that are running there and allows to cover additional markets for these DApps. For Near, on the other hand, it allows to quickly bootstrap the Near ecosystem and helps to scale the amount of the applications and the different operations that are available on top of the Near blockchain. Because Ethereum already has seven years of development and there are lots of developers that already know Solidity or wiper. There are lots of audited smart contracts and tools around Ethereum so it will be pretty nice for Near to have access to all of these knowledge bases, people and tools.
In terms of implementation, Aurora is a smart contract that is implemented on top of Near blockchain. This smart contract has inside a SputnikVM, which is the implementation of the Ethereum Virtual Machine. That is run every time when a transaction is submitted to the Aurora.
So we have here this concept of a dream and a dream, right? So we have Near Virtual Machine, which is the native environment where smart contracts are executed in Near and inside of this Near Virtual Machine. What Aurora does, it spins up the Ethereum Virtual Machine and then the user’s transactions, the Ethereum virtual transactions, they are executed inside of the Ethereum virtual machine. This whole machine is actually executed inside of the Near virtual machine. Because of this, we are not pushing Aurora to the level of the Near protocol, which allows for pretty fast iterations, and we are able to deploy new features pretty quickly on Aurora. The good thing about the Aurora is that it’s not only the virtual machine, it’s also an Web3 compatible RPC, through which all of the Ethereum tooling is able to connect to Aurora. This results in everything that you literally know about Ethereum being able to work with Aurora right here right now. MetaMask and other wallets, Truffle, Hardhat or other developer tools, IDEs like Remix and so on and so forth. All of the existing frontend is super easy and clean using, for example, web3.js or ether.js and so on and so forth.
It is just absolutely the same Ethereum, but it is working on a different environment. You can think of it as a different chain where Ethereum is spun up.
Now, the thing that is different for Aurora is that the base token or the token that is used to nominate the fees for the user transactions is not a fancy Aurora token. We are using ETH as a base token. Obviously, it’s not the direct ETH that is existent only on Ethereum, but this is a bridged ETH from Ethereum to Aurora, and this particular feature is very important. And the reason why it is important is that it actually helps us to onboard users and developers quicker and we are able to… These people do not need to understand what is the other token that is working there, whether the transactions are cheap or not. How and where can I get this token? So there is no these problems of the burden. And on the other hand, there are a set of other problems where existing projects would like to integrate with another network. The thing that they need to get, for example, is a robust oracle that displays the token price. For ETH, obviously, there are quite a lot of robust oracles. But for maybe this particular token like Aurora token hypothetical Aurora based token, there is no such an oracle, and that might be a problem in the integration. So using ETH as a base token, it removes this burden of the onboarding of the users and developers and helps people and helps the developers not to change their code and keep things very, very simple during the integration.
Now, the interesting thing is how this stuff is implemented, so I’m going to go and a little bit into the details of the technical implementation. So from the user’s standpoint, he sees that Aurora has this Web3 compatible RPC and the user is working with this RPC. Absolutely the same way how how he works with the theorem. So he signs the Ethereum transaction. He sends this transaction to the RPC and then, well, this is a black box for the user. But in fact, what happens is that this Web3 RPC it wraps users Ethereum transaction into a valid Near transaction, sends it to the Near network, obviously attaches some Near gas and Near to pay for the storage and Near protocol actually unwraps this transaction and starts the calculation of the Near gas onwards. And this is what Near protocol is doing normally. So Near protocol schedules the call of the Aurora smart contract with the parameter as this user signed transaction. Then this transaction goes to the Aurora smart contract and what Aurora smart contract does. It unwraps users Ethereum transaction understands who is the signer of the transaction and executes this. As you know, EVM, what it does. It calculates the ETH gas usage. So in the end of the execution of the transaction Aurora engine or the smart contract with the EVM, it knows the amounts of ETH that user just have spent on the transaction. What it does. It transfers these ETH to the RPC account. So from the user perspective, the payment that is made is that he pays to Aurora or the Aurora protocol a little bit of ETH for the execution of the transaction. However, what is in fact happening is that the user pays this ETH to the RPC account while the RPC is paying Near to the Near protocol and this Near gets burned. So we have this a very interesting separation of the economics that is happening in between the user and RPC and the RPC and the protocol.
I specifically note in this particular feature because from my point of view, this is a tremendous opportunity to introduce something more simpler than the crazy gas user experience that all of the blockchain users are having. Blockchain users need to think about the gas price, whether it goes up and down, whether you need to retry the transaction, speed it up and all of the stuff. So these are a very, very complicated user experience things. And here these things are isolated into the relations in between the RPC and Near protocol, while the monetary relations in between the RPC and the user can be different.
This brings us very nice opportunities, and I’m going to name a few of them, so first of all, the RPC can implement a different model for the access of the blockchain because of what RPC actually does. It supplies to the user the gas price and the meaning of the gas price, in this case, is going to be pretty different from Ethereum ones.
So in Ethereum, the meaning of the gas price is something like the mean gas price of the unconfirmed transactions, while in Aurora case the gas price. While it is absolutely the same number, it is going to mean or it means different things. It means that hey user, if you will put this gas price in your transaction, then I’m going to wrap it into the Near transaction and send it to the Near blockchain. So the gas price that is presented by the RPC is the contract to the user. This is the deal from the RPC to the user. And what is very important, the RPC can introduce different deals to different users. So, for example, there might be users that are buying a subscription to the blockchain, a thing that is unseen at the moment so a user can come in to the RPC login into the RPC somehow, the user can add his credit card to pay 100 dollars for the one month of the access to the blockchain without any limits. Or, for example, what RPC can do is actually allow users to do multiple transactions for free and then charge some money for the transactions.
So this is like a freemium model, so additional business models for access to the blockchain can be implemented.
With this feature, the marketing campaigns can become just insane because instead of paying the advertisers for the paid advertisements or some kind of videos in YouTube showing the features of the project and things like that. What projects can do? They actually can give free access to the Aurora to the users that are using these projects. This is 100% efficient capital deployment. Because 100% of the money that is more like the value that is transferred to the users is turned into the value to the users. And this value is actually the reduction of the fees, right? Or maybe if we are not fully removing the fees, then we can create promo codes that remove that is given, 50% cashback for the fee or something like that. So super nice marketing campaigns.
As I said in the very beginning, the main thing about it is that you can simplify and or almost or fully remove the annoying gas user experience through these new models or either return to the user a flat gas price independently of the actual gas price in the Near blockchain. Since the treatment of the transactions is happening on the user level, this means that the RPC can know about the users or the users of the RPC much more. It can specify the behavior in a very different manner, according to the user.
If you’re an unknown user, you potentially can have very limited access to the RPC and limited time. I mean the quite a lot of rate limits were implemented there. However, if the user is an advanced user, for example, the user verified his identity, he can get higher limits. And through these mechanics, what can be implemented is advanced protection against the denial of service attacks.
As I mentioned, the KYC, is an interesting thing that within this RPC service and additional services can be proposed to the users like getting in this KYC or maybe some additional things like a priority in the transaction execution. The good thing is that, well, this idea is actually extendable to other Web3 compatible networks, right? So it is not something that is fundamentally changed in Aurora. The architecture decisions that were made in Aurora were just for the convenience of the users of the Near protocol and for hiding everything behind hiding everything.
However, all of these ideas can be applied to other blockchains, though there is a problem that obviously the fees on Near are pretty low in comparison to the fees on Ethereum currently. And because of this, the logic of how the algorithms for the RPC are going to decide on the price on the gas price is going to be tremendously different for Aurora and for Ethereum. And most importantly, there is no sacrifice on the decentralization of the access to the blockchain.
One can think that’s OK. This is a single RPC that I need to connect to, and then the RPC fully decides whether to send my transaction to the Near blockchain or no?
Well, this is not correct because anyone is able to spin up the RPC. Actually, Aurora RPC can be spun up in just a single comment from the command line. So we have everything dockerized and packed into very simple docker instances. So you can pretty simply deploy it. The problem is that or anyone is able to do it right. The one single issue with this is that, well, you need to go a little bit into the guts you need to create. You need to acquire a little bit of Near for your RPC to pay for your transactions. And then, for example, you can say that the gas price for all of your transactions in Ether is zero. It’s just RPC that is going to pay for the transactions.
In fact, we are embracing this decentralization, and as you probably heard, we have a partnership with Consensys and we are working with Infura team on the integration of Aurora in the set of Infura products.
So that’s it from me today, I believe that the choice of Aurora of using ETH as a base token is very important for mass adoption. I invite everybody to move towards this mass adoption. Simplifying the gas user experience and onboarding the billion users to the blockchain. Thanks, and stay tuned!
About Co-hosts
IOSG Ventures, founded in 2017, is a community-friendly and research-driven early-stage venture firm. We focus on open finance, Web 3.0 and infrastructure for a decentralized economy. As a developer-friendly fund with long-term values, we launch the Kickstarter Program, which offers innovative and courageous developers capital and resources. Since we consistently cooperate with our partners and connect with communities, we work closely with our portfolio projects throughout their journey of entrepreneurship.
❄️ StarkWare
StarkWare invented, and continually develops, STARK-based Layer-2 Validity Proof scaling solutions over Ethereum. StarkWare’s solutions, which rely on Ethereum’s security, have settled over $250B, and over 60M transactions, serving hundreds of thousands of users. StarkNet, StarkWare’s permissionless general-purpose scaling solution, is live (Alpha) on Ethereum Mainnet. StarkEx, a custom standalone scaling service, has been powering applications since June 2020, including dYdX, Immutable X, Sorare, and DeversiFi.
❄️ imToken
imToken is a decentralized digital wallet used to manage and safeguard a wide range of blockchain- and token-based assets, identities, and data. Since its founding in 2016, it has helped its users transact and exchange billions of dollars in value across more than 150 countries around the world. imToken allows its users to manage assets on 12 mainstream blockchains and all EVM chains, it also supports decentralized token exchange and open DApp browser.
❄️ Arbitrum
Arbitrum is a leading Ethereum Layer-2 scaling solution developed by OffchainLabs. Based on the Optimistic Rollup scheme, Arbitrum enables ultrafast, low-cost transactions without sacrificing the security of the Ethereum ecosystem. Launched on August 31st, 2021, Arbitrum has attracted 100+ ecosystem projects. Arbitrum is currently EVM-compatible to the bytecode level. In the next upgrade, Arbitrum Nitro, Arbitrum will further increase developer experience by incorporating WASM support.