Aurora CEO: Why do we need to enable ETH as the base token? How will it be implemented?

Author: IOSG Ventures

Preface:

With the explosive growth of traffic in the blockchain world, the network transaction fees of the largest L1 platform, Ethereum, have continuously broken historical highs. Aurora is dedicated to solving the high transaction costs and low transaction speeds of blockchain, maintaining an average transaction cost at a few cents while achieving finality within two seconds.

In addition, Aurora places great emphasis on improving the user experience details for both developers and ordinary users. It allows developers to deploy existing Solidity and Vyper contracts without changes, while users can seamlessly access these applications using MetaMask and other Ethereum wallets.

At the same time, ERC-20 tokens and contract data can be transferred from Ethereum to Aurora through the trustless Aurora bridge (based on Rainbow Bridge). With low costs, top-notch transaction finality, and scalability, Aurora redefines the possibilities of the Ethereum ecosystem while expanding the NEAR ecosystem to include every EVM-based application.

On December 28, 2021, at the 8th Old Friends Reunion Scaling Summit, we were honored to invite Aurora's CEO Alex Shevchenko to deliver an exciting keynote speech titled "ETH as a Base Currency: Why It Matters and How It Works." Let’s listen to how Aurora creates an interoperable future by adopting ETH as a base currency, bridging the gap between blockchain, developers, and users.

Through its smooth and seamless user experience, allowing assets to flow uninterrupted between the Ethereum and NEAR blockchains, this technology merges economies and fosters the growth of the creator community, making it mainstream.

Full text reading:

Hello everyone, I am Alex from Aurora, and today I would like to showcase one of the key solutions of the Aurora project, the importance of ETH as a base token and how it operates. First, let me give an overview of what Aurora is.

In short, Aurora is a solution that allows Ethereum smart contracts to be executed on a higher-performance environment (i.e., the sharded NEAR blockchain). This is a very interesting solution for both the Ethereum and NEAR ecosystems.

For Ethereum, it allows for the scalability of DApps running on Ethereum and enables these DApps to explore other markets. On the other hand, for NEAR, it allows for the rapid expansion of the NEAR ecosystem and helps to increase the number of applications and different operations available on the NEAR blockchain.

Since Ethereum has been developing for seven years, many developers already know Solidity or Vyper. There are many audited smart contracts and tools around Ethereum, so NEAR can access all these knowledge bases, personnel, and tools, which is particularly great. In terms of implementation, Aurora is a smart contract implemented on the NEAR blockchain.

Inside this smart contract is a SputnikVM, an implementation similar to the Ethereum Virtual Machine. Every time a transaction is submitted to Aurora, it runs.

This can be described as a double delight. We have the NEAR virtual machine, which is the native environment for executing smart contracts within NEAR. In the NEAR virtual machine, Aurora's role is to launch the Ethereum virtual machine, and then the user's transaction is an Ethereum virtual transaction, which is executed within the Ethereum virtual machine.

The entire machine is actually executed within the NEAR virtual machine. Therefore, we do not push Aurora to the level of the NEAR protocol, which iterates quickly, and we can deploy new features on Aurora very rapidly. The benefit of Aurora is that it is not only a virtual machine but also a Web3 compatible RPC, allowing all Ethereum tools to connect to Aurora.

This means that everything you know about Ethereum can now be used with Aurora. MetaMask and other wallets, Truffle, Hardhat, or other developer tools, IDEs like Remix, and so on. All existing front-ends are very simple and clean, such as using web3.js or ether.js, etc. It works in different environments and can be seen as a different chain launched by Ethereum.

Now, what sets Aurora apart is that the base token used to specify user transaction fees is not some fancy Aurora token. We use ETH as the base token.

It is not the native ETH that exists on Ethereum, but bridged ETH from Ethereum to Aurora. This special feature is very important because it actually helps us attract users and developers more quickly.

These people do not need to worry about what base token to use on Aurora, whether transactions are cheap, or how and where to obtain this token. So there are no such concerns. On the other hand, existing projects wanting to integrate with another network face a series of other issues, such as needing to obtain a robust oracle to display token prices.

There are obviously many powerful oracles for ETH. However, for tokens like the Aurora token or tokens based on Aurora, there may not necessarily be price oracles, which could lead to integration issues. Therefore, using ETH as the base token eliminates the concerns for users and developers to get started, and project teams and developers do not need to change their code, making the integration process very simple.

It is interesting how these things are implemented, and I will delve into the technical implementation details next. From the user's perspective, Aurora has this Web3 compatible RPC, and users are using this RPC, which operates exactly the same way as it does on Ethereum, so they sign Ethereum transactions, send this transaction to the RPC, and for the user, this is a black box.

But what actually happens is that this Web3 RPC wraps the user's Ethereum transaction into a valid NEAR transaction, sends it to the NEAR network, and of course also sends some NEAR gas and NEAR to pay for storage fees, while the NEAR protocol actually unpacks this transaction and starts calculating NEAR gas. This is what the NEAR protocol typically does.

Thus, the NEAR protocol will schedule the parameters of the Aurora smart contract call for the transaction signed by that user, and then this transaction is sent to the Aurora smart contract.

The role of the Aurora smart contract is to deconstruct the user's Ethereum transaction, understand who the signer of the transaction is, and execute it. It is well known that the EVM's role is to compute the ETH gas usage.

Therefore, at the end of the transaction on the Aurora engine or with the execution of the smart contract with the EVM, it knows the amount of ETH the user just spent on the transaction. It then transfers this ETH to the RPC account. So from the user's perspective, the payment process occurs when they pay ETH to the Aurora protocol to execute the transaction.

However, what is actually happening is that the user pays this ETH to the RPC account, while the RPC pays NEAR tokens to the NEAR protocol, and this NEAR token is burned. Thus, we have created a very interesting separation of the economic relationship that occurs between the user, the RPC, and the protocol.

I specifically point out this special feature because from my perspective, it is a huge opportunity. This can help simplify the user experience rather than facing the crazy gas issues that blockchain users encounter.

Blockchain users need to consider gas prices, whether they are high or low, whether they need to retry transactions, whether they need to speed up transactions, and so on. So these are all very, very complex user experiences.

In our design, these issues are isolated in the relationship between the RPC and the NEAR protocol, while the monetary relationship between the RPC and the user can differ. This gives us a very good opportunity, and I will list a few of them.

First, the RPC can implement different models for accessing the blockchain because what the RPC actually does is provide the user with gas prices, in which case the meaning of gas prices will be completely different from Ethereum.

Thus, in Ethereum, the meaning of gas prices is similar to the average gas price of unconfirmed transactions, while in Aurora, it is the gas price. Although it is the exact same number, it will mean or has meant different things. That is to say, if the user puts this gas price into the transaction, then the gas will wrap it into a NEAR transaction and send it to the NEAR blockchain.

So the gas price presented by the RPC is the contract for the user. This is a transaction from the RPC to the user. It is very important that the RPC can introduce different transactions for different users.

For example, there may be users purchasing blockchain subscriptions, which are currently invisible. Users can somehow access the RPC, log into the RPC, and add their credit card to pay $100 for unlimited access to the blockchain for a month.

Or, for instance, what the RPC can actually do is allow users to make multiple transactions for free and then charge a fee for the transactions. This is like a freemium model, so we can implement additional business models for blockchain access.

This feature could make marketing campaigns very exciting because projects do not need to pay advertisers for paid ads or some paid videos showing project features on YouTube. Projects can actually allow users using these projects to access Aurora for free. This is 100% effective capital deployment.

Because 100% of the money or value intended to be transferred to users becomes value for the users. And this value is reflected in the reduction of fees. Alternatively, if we do not completely eliminate fees, we can create promotional codes for a 50% cash back on fees or something similar. This would be a very good marketing campaign.

As I mentioned at the beginning, you can simplify or completely eliminate the annoying gas user experience through these new models, or return a fixed gas price to users on the NEAR blockchain that is unrelated to the actual gas price. Since transaction processing occurs at the user level, this means that the RPC can know more about the users or the users of the RPC.

Depending on the user, it can set behaviors in completely different ways. Unknown users may have very limited access to the RPC and time due to quite a few rate limits. If it is a verified high-level user, they can receive higher limits. What can be achieved through this mechanism is advanced protection against denial-of-service attacks.

KYC is an interesting thing. In this RPC service, additional services can be offered to users, such as priority in transaction execution during KYC.

The good news is that this idea can actually be extended to other Web3 compatible networks; it does not fundamentally change what happens in Aurora. The architectural decisions made in Aurora are simply to facilitate users of the NEAR protocol and hide all the complexities in the backend.

All these ideas can be applied to other blockchains, although there is one issue: the fees on NEAR are obviously quite low compared to the current fees on Ethereum.

Therefore, for Aurora and Ethereum, the logic of how the RPC algorithm determines gas prices will be very different. Most importantly, there is no sacrifice in the decentralization of blockchain access. Some people might think, well, this is the single RPC I need to connect to, and then the RPC completely decides whether to send my transaction to the NEAR blockchain, right? This is incorrect because anyone can start an RPC.

In fact, the Aurora RPC can be started with a single command line comment. Therefore, we have dockerized everything and packaged it into a very simple docker instance.

Anyone can deploy it simply and directly, just needing to configure a little NEAR token for your RPC to pay for the corresponding transactions, for example, all transactions in Ether have a gas price of zero; the RPC will pay the transaction fees. We are embracing this decentralization, we have partnered with Consensys, and we are working with the Infura team to integrate Aurora into the Infura product suite.

I believe that choosing Aurora to use ETH as the base token is crucial for mainstream large-scale applications. I invite everyone to move towards this vision, simplify the gas user experience, and bring a billion users onto the blockchain.