6 posts tagged with "Core Tech"

A core piece of Aurora’s technology is the Aurora Engine smart contract, which is an Ethereum Virtual Machine (EVM) implementation deployed as a smart contract on Near. Therefore, Aurora sits at the intersection of both EVM and Near runtimes. It naturally draws us to think about comparisons between EVM and Near.

For example, the concept of “gas” exists in both the EVM and Near’s runtime. The reason is because of the famous halting problem, which says we cannot know in advance if an arbitrary computer program will finish in a finite time. In the context of a smart contract platform, this means we must measure (and limit) the computation the contract does at runtime. In both the EVM and Near, “gas” is the unit that is used to measure the computational work done by a smart contract.

Even though EVM gas and Near gas both measure the same thing, they are not identical. One analogy is miles and kilometers; both measure distance, but the numerical value of the same physical distance will be different depending on which unit is used. Computation is a more abstract concept than distance, but this analogy leads us to expect some kind of approximately linear relationship between EVM gas and Near gas, similar to how 1 mile equals 1.61 kilometers.

In this blog post, we explore this question and discuss the implications for developers building on Aurora.

The classical Rainbow Bridge makes it possible to transfer tokens from the NEAR blockchain (or the Aurora Blockchain) to Ethereum. However, it is important to note that these transactions may have longer processing times, typically ranging from 4 to 8 hours, and the final transaction cost remains unpredictable at the time of initiation. These attributes significantly impact the overall user experience, and in certain scenarios, transaction speed becomes a critical factor.

In this article, we introduce the innovative Fast Rainbow Bridge. This groundbreaking solution enables the transfer of tokens from NEAR to Ethereum with just a few minutes of delay. As an added advantage, this bridge also provides the ability to determine the transfer cost during its initialization stage.

Since its inception, the Aurora Protocol has continued to break boundaries in the blockchain world. Its latest innovation is a service known as Borealis Business, aimed at solving one of the most significant challenges for users of Web3 products – the concept of transaction fees.

The main goal of this article is to understand the Aurora Chain code.  In a future post, we will discuss how it embellishes the Aurora Engine and how the advantages of an Aurora Chain correspond to different parts of code and Aurora architecture.

Aurora’s infrastructure is built upon an innovative combination—our Ethereum Virtual Machine (EVM) operates as a smart contract running atop the powerful NEAR protocol. Harnessing NEAR's innate ability for smart contracts to communicate with one another, we seamlessly route EVM-compatible transactions to any smart contract deployed within NEAR. By doing so, developers are granted unparalleled access to the best of both ecosystems - from a rich collection of sound and robust Solidity libraries to the groundbreaking NEAR accounts model and an ever-growing, expansive user base.

In the blockchain world, relayers are off-chain facilitators of data exchange and transactions between blockchain networks and/or layers. They are used primarily in decentralized finance applications, cross-chain communication, and Layer 2 solutions, like sidechains or state channels. In general, relayers listen for events and transactions from one point and then submit the corresponding data or transactions to another. For that, they can charge fees for their services, incentivizing them to operate and maintain their infrastructure.

Initially developed in-house at NEAR, the Aurora EVM is the official EVM for the NEAR ecosystem. Powered by the SputnikVM, it accomplishes a 1:1 experience with the Ethereum protocol. This compatibility between Aurora and Ethereum is achieved by the **Aurora Relayer, a **JSON-RPC compatible server with Ethereum's Web3 API for the Aurora Engine. It has its own internal database to serve multiple read methods and an indexer that is constantly following the head and indexing blocks, transactions and logs to that internal database

Relayer 2.0​

As mentioned above, the Aurora Relayer has two main components. First, an implementation of Ethereum’s JSON-RPC specification—a standard collection of methods that all clients must implement and the canonical interface between users and the Ethereum network—on Aurora’s Ethereum Virtual Machine (EVM), a.k.a. the Aurora Engine. Second, an indexer that continuously reads the NEAR network for blocks and other relevant information relevant to Aurora. 

The Relayer had its first version deployed in October 2021. Developed in Typescript and JavaScript. It has been deprecated and replaced by version 2.0, with a JSON-RPC server written in go-lang and the indexer developed in go-lang and rust.

Relayer 2.0 was motivated by the necessity of migrating from Javascript to a more reliable language like golang that is designed for concurrency and is particularly good at managing multiple connections and resource-intensive tasks, making it very well-suited for the type of high-performance RPC systems required in blockchains. Additionally, it required migrating to a more efficient database system, so it was migrated from PostgreSQL to badger-db an embedded key-value database. As a result, there is now a relayer with faster execution speed,  lower machine resource usage, and lower data latency that is easier to code, debug, optimize, and deploy. Now, let’s have a general overview of some of the internals of the Relayer.

The JSON-RPC​

Written in go-lang, it exposes endpoints that implement the methods of Ethereum’s JSON-RPC protocol, commonly known as the Web3 API. This middleware leverages a messaging system that forwards JSON-PRC calls to the NEAR network and vice versa. Its source code is open and available to developers, contributors, and anyone who would like to build, run and experiment with it natively. A list of all the implemented methods and the server's source code can be found in the GitHub repo. Also, there is a standalone version available here.

The Database​

Embedded databases are a better choice for applications that don't require complex querying planning, as it provides a lightweight solution with fewer dependencies. They are also well-suited for applications that benefit from local data storage with low latency and need single-process concurrency for concurrent read and write operations without external coordination.

BadgerDB—our database of choice—is an embeddable, persistent, fast key-value (KV) database written in pure Go. It is ideal for JSON-RPC servers as most methods grab data by key while benefitting from better data compression and lower latency. In addition, other teams inside Aurora are also using it, therefore, the required competencies and know-how were already there.

The Indexer​

The new embedded indexer continuously reads JSON files generated by the Aurora Refiner that populate a local database. The refiner allows users to download all NEAR Blocks and get all information relevant to Aurora. NEAR Blocks data can be consumed from two different sources: the NEAR data lake— a repository of blocks and events from the NEAR network as JSON files on AWS — and an archival instance, the NEARCore. In general, Aurora Relayer infrastructure implements an indexer of NEAR blocks, an indexer of blocks from tar backups and an indexer of pre-history blocks (height < 34 mln). An open-source repository for the Aurora Refiner can be found here.

And more…​

In addition, and due to the nature of Aurora’s relayer infrastructure and its interactions with the NEAR network, it was possible to upgrade our internal infrastructure to use our relayer with additions that allow the implementation–among other things–of complex multi-tenant, rule-based accounting systems that support virtually any possible way to account for transactions, to enforce gas prices, pre- or post-run transactions, etc. So it is possible to have users with prepaid fees, prepaid gas, no gas, and many other configurations for distributing gas and fees between relayers, users, and owners of smart contracts. This means that anyone willing to spin a relayer will have access to more sophisticated economic mechanisms for its users or on behalf of others, thus acting the same way ERC-4337 bundlers do, i.e., as validators who earn incentives for completing transactions. 

The Future of User Experience​

By improving efficiency and reliability and by adding innovative functionality into the relayer, Aurora builders and developers can offer faster, more robust applications and significant improvements to the user’s experience where — among other things — per-transaction fees could be eliminated and accounts could be detached from keys. Therefore, the Aurora Relayer stands as a groundbreaking innovation in the world of decentralised blockchain technologies. Furthermore, as we continue to see rapid advancements and increasing adoption, the Aurora Relayer sets the stage for a more interconnected and efficient future with the potential to unlock unprecedented levels of usability, scalability, security, and cost-effectiveness, ultimately contributing to a more accessible landscape for all types of users.

If you are interested in getting to know Aurora Relayers in more depth, in our next post, we will teach you how to modify and launch a stand-alone version of the relayer that can be called by a smart contract that can execute functions without charging gas to its callers, stay tuned!