NEAR vs Ethereum Developer Comparison

11 min readNov 2, 2020

This article will acquaint you with the main differences between NEAR Protocol and Ethereum, which are necessary for developers and for initial understanding .

According to the developers, the platform is more productive and less expensive than Ethereum, while allowing to solve a wider range of issues. In fact, Vitalik Buterin, the Ethereum founder, has been known to make statements to the effect that NEAR may represent a significant challenge to Ethereum at some point.

First, let’s figure out what are the NEAR Protocol and Ethereum.

NEAR Protocol

NEAR Protocol is a sharded, developer-friendly, proof-of-stake blockchain and developers can build decentralized apps on top of it.

The NEAR Protocol uses its own variation of the “Proof-of-Stake” consensus mechanism called Nightshade. The system uses sharding technology to implement parallel computing, which is not supported on Ethereum. Consequently, the project’s hashrate will grow with decentralization.

Ethereum

Ethereum is a cryptocurrency and platform for building decentralized blockchain-based online services (dApps) powered by smart contracts.

Ethereum currently uses a transaction confirmation system called “Proof-of-Work”. It allows the Ethereum network to reconcile the state of all information registered on the Ethereum blockchain and also prevents some types of hacker attacks.

NEAR Protocol vs. Ethereum

How does it work?

NEAR is similar in principle to the “cloud-based” infrastructure that developers currently build applications on top of except the cloud is no longer controlled by a single company running a giant data center — that data center is actually made up of all the people around the world who are operating nodes of that decentralized network. Instead of a “company-operated cloud” it is a “community-operated cloud”.

NEAR uses a technique called “Nightshade” from the database world, which splits the network so that much of the computation is actually being done in parallel. This allows the network’s capacity to scale up as the number of nodes in the network increases so there isn’t a theoretical limit on the network’s capacity. Figure 2 shows you NEAR Protocol architecture.

Account model

NEAR uses readable account IDs instead of a hash of a public key.

Because we use Account ID instead of a hash, we can have multiple public keys per account. We call them Access Keys. An Access Key grants permissions to act on behalf of an account. There are currently 2 types of permissions with room for more: full-permission and function-call limited permission.

Function-call permission of access keys is the most powerful usability feature of NEAR. It enables sending non-monetary function-call transactions from the owner’s account to the receiver. The receiver ID is restricted by the access key. This enables multiple use-cases including:

1. Authorize front-end web applications without trusting the contract code or the web app itself. This is done by creating a new access key on your account and pointing it towards the contract of the web-app. This can be done through the web wallet. This use case is demonstrated by the first example (NEAR Wallet integration) available now in examples.

2. Allow a new user without an account to use your dApp and your contract on-chain. The back-end creates a new access key for the user on the contract’s account and points it towards the contract itself. Now the user can immediately use the web app without going through any wallet.

3. Limited access for the account. An account has a contract and only function-call access keys (no full-permission keys). Only the contract can initiate transactions from this account. It can be a multi-sig, a lockup contract, a delayed withdrawals or @argentHQ guardians.

4. Proxy based blockchain access. It’s like @ATT for blockchain. A user may be paying a monthly service fee instead of paying per transaction. Multiple options are possible.

5. All data for a single account is collocated on one shard. The account data consists of the following:

Balance
Locked balance (for staking)
Code of the contract
Key-value storage of the contract
Access Keys
Postponed ActionReceipts
Received DataReceipts

Storage staking

Let’s walk through a NEAR example:

1. You launch a guest book app, deploying your app’s smart contract to the account example.near

2. Visitors to your app can add messages to the guest book. This means your users will, by default, pay a small gas fee to send their message to your contract.

3. When such a call comes in, NEAR will check that example.near has a large enough balance that it can stake an amount to cover the new storage needs. If it does not, the transaction will fail.

If you’re familiar with Ethereum’s pricing model, you may know that, like NEAR, the protocol charges a fee (called “gas”) for each transaction. Unlike NEAR, Ethereum’s gas fee accounts for the amount of data stored via that transaction. This essentially means that anyone can pay once to store permanent data on-chain. This is a poor economic design for at least two reasons:

1. The people running the network (miners, in the case of Ethereum) are not appropriately incentivized to store large amounts of data, since a gas fee far charged in the distant past can increase storage costs forever

2. The users of a smart contract are charged for the data they send to store in it, rather than charging the owner of the smart contract.

Gas

When you make calls to the NEAR blockchain to update or change data, the people running the infrastructure of the blockchain incur some cost. At the end of the day, some computers somewhere process your request, and the validators running these computers spend significant capital to keep these computers running.

Like NEAR, Ethereum uses gas units to model computational complexity of an operation. Unlike NEAR, rather than using a predictable gas price, Ethereum uses a dynamic, auction-based marketplace. This makes a comparison to Ethereum’s gas prices a little tricky, but we’ll do our best.

Etherscan gives a historic Ethereum gas price chart. These prices are given in “Gwei”, or Gigawei, where a wei is the smallest possible amount of ETH, 10⁻¹⁸. From November 2017 through July 2020, average gas price was 21Gwei. Let’s call this the “average” gas price. In July 2020, average gas price went up to 57Gwei. Let’s use this as a “high” Ethereum gas fee.

Multiplying Ethereum’s gas units by gas price usually results in an amount that easy to show in milliETH (mE), the same way we’ve been converting NEAR’s TGas to milliNEAR. Let’s look at some common operations side-by-side, comparing ETH’s gas units to NEAR’s, as well as converting to both the above “average” & “high” gas prices.

While some of these operations on their surface appear to only be about a 10x improvement over Ethereum, something else to note is that the total supply of NEAR is more than 1 billion, while total supply of Ethereum is more like 100 million. So as fraction of total supply, NEAR’s gas fees are approximately another 10x lower than Ethereum’s. Additionally, if the price of NEAR goes up significantly, then the minimum gas fee set by the network can be lowered.

You can expect the network to sit at the minimum gas price most of the time, learn more in the Economics whitepaper.

And anyway check the gas price before relying on the numbers above.

Transaction processing

A Transaction is a collection of Actions that describes what should be done at the destination (the receiver account).

Each Transaction is augmented with critical information about its:

An Action is a composable unit of operation that together with zero or more other Actions defines a sensible Transaction.

Following action are primary for Ethereum:

Debugging

NEAR uses build system called CLion for debugging.

CLion is a cross-platform C and C++ IDE for Linux, macOS, and Windows integrated with the CMake build system. The initial version supports GNU Compiler Collection (GCC) and Clang compilers and GDB debugger, LLDB and Google Test. You can see the process of installing and getting started with CLion here.

You can explore and debug all data to see every contract, transaction, receipt and more with NEAR Explorer.

So it’s quite simple compared to Ethereum.

But debugging transactions in Ethereum is still a major pain point. While there’s been a lot of progress, it remains an unpleasant activity. The more tools you have at your disposal, the better. There are many tools for debugging:

The Remix IDE has a great integrated block-by-block simulator and debugger.
Ganache allows fast contract testing without the hassle of running a node.
Once the contract is live, the etherscan.io block explorer can be used to view internal state and EVM execution logs.

Developing side comparison

The first thing is to know that NEAR Protocol and Ethereum operate in different environments. NEAR Protocol runs on WebAssembly (WASM), while Ethereum runs on the Ethereum Virtual Machine (EVM).

Smart contract

NEAR Protocol supports Rust and AssemblyScript (JavaScript with types) for a smart contract development. For those unfamiliar, Rust is a flexible programming language like C++ with the ability to protect against memory safety issues and other common bugs. Goal of using Rust is to make it easy for developers to write complex applications. For example, Rust allows developers to write general-purpose code with custom data structures. Developers can also make use of third-party Rust libraries developed and maintained by the Rust community such as machine learning, data serialization, and other utilities.

The Ethereum smart contracts are written in Solidity. It’s a programming language developed by the team behind the Ethereum network with a syntax really similar to JavaScript. If you’re a JavaScript developer you’ll understand it pretty fast. Unfortunately, we can’t say anything good about it. The language is being currently developed and for that reason, a lot of important features are missing (like the decimal point). This complicates the development process from the core.

The protocol

NEAR Protocol is designed to make it easier to:

Build decentralized applications, especially as a developer familiar only with “traditional” web or app concepts. For developers that means they don’t need a deep blockchain features for starting.
Onboard users with a smooth experience, even if they aren’t familiar with crypto, tokens, keys, wallets or other artifacts of this ecosystem.
Scale your application since the underlying platform automatically expands capacity via sharding without additional costs or effort on your part. You don’t need to care about blockchain load anymore.

Ethereum was the first blockchain which introduced the smart contracts. An essential step for the blockchain adoption since Bitcoin. And this protocol doesn’t have some modern features offered by other blockchains

Development tools

A developer without development tools is not developer. We’re all trying to work in an environment where we can develop faster and easier and it should have user-friendly interface.

NEAR Protocol has various development and testing tools. For example, to write dApp in AssemblyScript, you need a GitPod and you use AS-pect and Jest for testing.

Jest allows us to perform integration tests on NEAR’s testnet network.
AS-pect allows us to test our smart contract on a locally mocked network.

We can use Rustup for both writing and testing if we’re using Rust language.

And there are many great tools for Ethereum development which can help you a lot — from starting a local blockchain node to unit testing smart contracts with JavaScript. The most famous is truffle — a development framework for Ethereum smart contracts. If you haven’t heard about them you should go and check it.

Environment comparison (it isn’t the full list of tools being used)

Some basic practice moments comparison

Sending request to blockchain

The near-api-js library is responsible for sending requests to NEAR Protocol blockchain and web3 used to send requests to Ethereum blockchain corresponding.

Web3

NEAR Protocol is a sharded, proof-of-stake blockchain. Keeping that in mind, some Ethereum concepts are naturally not shared with NEAR; for example, there is no concept of uncle blocks, pending blocks, or block difficulty.

As a sharded blockchain, the structure of NEAR blocks is also different. In Ethereum, blocks have transactions. In NEAR, blocks have chunks, and chunks have transactions.

near-web3-provider has been adapted to follow the Ethereum JSON RPC API and its web3 equivalents as closely as possible. Where there are no equivalents, empty values have been passed through. Other return values have been adapted to account for the difference in block structure (for example, the root of the transaction tree comes from a chunk rather than a block).

Mining, hashrates, ssh, and db methods are not supported.

Limitations and differences using web3 provider in NEAR Protocol:

Methods that have an extra default block parameter will function as latest, regardless of the actual argument. This is a NEAR RPC limitation.
eth_call does not support from or value arguments. This is a NEAR RPC limitation.
eth_estimateGas will always return 0x0. NEAR RPC does not seem to support gas estimation for calls.
Some fields in Ethereum data structures do not have a direct correspondence to NEAR data structures, therefore these fields are unimplemented or unreliable. Always consult implementation in near_to_eth_objects.js. Examples include:

The Tx receipts status field is always 0x1, regardless of the success of the transaction.
transactionIndex is constant, and not reliable.

Some calls, like eth_getTransactionByBlockHashAndIndex have no sensible correspondence to NEAR block structure.
NEAR doesn’t keep track of nonces for contracts which is a required feature for the EVM. Therefore both an EVM nonce and NEAR nonce exist for each account. eth_getTransactionCount will return a reference to the EVM nonce. All other nonce fields in the web3-near-provider reference the NEAR nonce.

EVM nonce: nonce used for address calculation in the next EVM contract deployment from this EVM account
NEAR nonce: number of all NEAR transactions (including EVM transactions) executed by account

Follow link to learn more about all limitations and differences.

Conclusion

In conclusion, we can say that NEAR Protocol has many significant advantages over Ethereum, and the project team will work to improve this blockchain platform in the future. You can see links below to learn more about NEAR Protocol and start building.