The trade-off of fragmentation technology: NEAR Protocol VS Ethereum 2.0

In the field of segmented blockchain, Ethereum 2.0 is undoubtedly the most famous, but it also has competitive competitors, such as the one I want to introduce today, it is the NEAR Protocol from San Francisco.

Although NEAR has not yet launched its main network, it has received a first round of financing of $12.1 million from Coinbase, MultiCoin Capital, Baidu Ventures, and Ruibo Xpring. The level of attention is evident.


(Image courtesy of:

What exactly is the NEAR Protocol, and what are its characteristics? (Note: This article does not introduce the team, only talk about the technology involved)

According to NEAR's official introduction, the NEAR Protocol will be a developer-friendly PoS (Profits) fragmentation blockchain.

In other words, NEAR's goal is to be a highly scalable, low-cost platform on which developers can create decentralized applications (DApps).

Ok, it looks like it will be very similar to Ethereum 2.0…

So what is the color of it?

  1. NEAR's sharding method has many similarities with the Ethereum 2.0 sharding method, but in fact the choice path is different (it will be simple to write below);
  2. In terms of fragmentation technology, NEAR and the Ethereum development team have cooperated research. NEAR's design will be easier to achieve because of the different trade-off points, but its current community foundation is far behind Ethereum 2.0;

Similarities and differences between NEAR protocol fragmentation and Ethereum 2.0 fragmentation

According to the design, NEAR's fragmented blockchain will execute smart contracts on the WASM virtual machine. Well, this sounds like NEAR and Ethereum 2.0. (Ethernet 2.0 uses its own version of WASM virtual machine – eWASM ).

Yes, they are very similar, but according to NEAR's own statement, they can deliver products faster, in contrast, Ethereum 2.0 takes longer.

Excuse me, where is this confidence?

This is to mention NEAR's choice, which uses a different consensus algorithm and fork selection rules than the Ethereum in beacon chain and slice chain design.

About Beacon Chain

For the beacon chain, no fork is naturally the best result. In the Ethereum and NEAR protocols, the beacon chain is responsible for selecting the verifier for the slice chain and capturing the state of the slice chain (the so-called cross-link), both of which rely on the beacon chain. This requires no forks.

NEAR's BFT Consensus Weighing

To achieve a zero-fork target, it is actually very challenging. Most modern BFT consensus algorithms do not scale to more than 1,000 participants, and the goal of unlicensed blockchain networks is for millions or even hundreds of millions of people. Therefore, the system consensus must be completed by participants who are significantly less than the total number of systems, which can be achieved in two somewhat similar but fundamentally different ways (assuming there is a PoS proof mechanism that can resist witch attacks):

  1. Raise the stakes threshold of consensus participants (“verifiers”) so that only 1,000 participants can afford it . In general, this requires setting the threshold above 6 digits. In this way, a fork in the blockchain will result in penalties for millions or tens of millions of dollars. Even if the fork really happens, it will have major consequences. For all practical reasons, we can assume that the probabilities of such a system are close to zero. However, such a setup would lead to a controversy over the system's centralization. This is because people who have the ability to invest such a large sum of money in a particular blockchain ecosystem are often acquainted in real life, which means that the security of the system will be in the hands of a closely connected group. This can lead to a variety of undue erroneous behaviors such as review, suspension, and more.
  2. Reduce the amount of money the certifier needs to collateral, then randomly select 1000 certifiers to create the block . You can select a new set of certifiers for each block, or you can convert them every few blocks. Assuming that the total number of malicious participants in the system is substantially less than 1/3, the probability of more than 1/3 of the corrupted verifiers in the sample is very low. The problem with this approach is that the verifier may change when it is selected (see the analysis in this blog post ). It is extremely difficult, but not impossible, to corrode a sufficient proportion of the pieces. Therefore, systems using this method cannot rely on no forks.

Note: For example, Algorand, which claims to have no forks, uses the latter method. When someone asked questions about bribery verifiers, Professor Silvio Micali replied directly that Algorand assumed that less than 50% of all verifiers were likely to be bribed. This is not only an unreasonable assumption, but in my opinion, it also invalidates other declared attributes about Algorand.

In essence, design decisions can be attributed to some trade-off between centralization and no fork .

Casper's early design would tend to be centralized (the solution at the time was to set the minimum deposit amount for the verifier to 1500 ETH ), and later the Ethereum Casper consensus algorithm was improved to extend the number of verifiers to hundreds of thousands. Therefore, the deposit amount has now dropped to 32 ETH, thus avoiding the centralization problem.

NEAR's design is a threshold equity proof and TxFlow (NEAR custom consensus mechanism) to achieve the goal of avoiding forks.

This Threshold Equity Proof (TPoS) mechanism is very similar to the auction method: participants bid, and the last n bidders win, while receiving a return proportional to their bid size.

In the NEAR system, they want a large number of participants ("verifiers") to be elected at specific time intervals (default is 1 day), and each time interval is divided into a large number of block slots (the default is 1440 for 1 day) The block slot, which is one block per minute, and each block has 1024 block verifiers. In other words, the system eventually needs to fill 1,474,560 verifiers each day.


To participate in network maintenance (becoming a certifier), any account can submit a special transaction indicating how much money you want to take. Once the transaction is accepted, the funds will be locked for at least 3 days.

The NEAR agreement uses inflation block rewards and transaction fees to motivate the certifier to participate in the signing block. During this period, if the verifier signs two competing blocks, the pledge funds will be forfeited and the confiscation will be Taken by the "certifier".

The main advantages of this type of verifier election are:

  1. There is no need to form a pledge pool: there is no reason to pool pledge funds or computing resources because the return is proportional to the amount of the deposit.
  2. There are relatively few forks: bifurcation is only possible when there is a serious network split (more than 1/3 of the malicious party);
  3. Relatively high security: it is difficult to rewrite a single block or perform a long-range attack ;

But it also has some shortcomings:

  1. The verifier is known in advance, so an attacker can try DDoS them. In a NEAR system, this can be difficult to implement because most of the verifiers will use the mobile device and will not accept incoming connections. Attacking a specific relay will only cause the affected mobile device to reconnect to its peer node.
  2. In PoS systems, the total system rewards are allocated in the existing pool of verifiers, which makes these systems detrimental to new verifiers. In response, NEAR has added additional incentives to motivate new certifiers to participate.

Simple comparison: Ethereum's design is mainly for mobile devices, while NEAR's main consideration is mobile devices, so the latter chose a simpler, cheaper BFT consensus mechanism with a smaller certifier committee. Therefore, the beacon chain in the NEAR protocol can theoretically be bifurcated, and the rest of the system is designed without hypothesis that its beacon chain is zero-bifurcation .

About the slice chain:

NEAR uses its own fragmentation consensus mechanism called TxFlow, while Ethereum 2.0 uses the Proposers/Inserters framework.

The advantage of TxFlow is that the generation of blocks is relatively fast, and the probability of bifurcation will be relatively small under normal operating conditions.

The main disadvantage of TxFlow is that if more than 1/3 of the participants are offline, it will "break down". Ethereum maintains system vitality even if any number of verifiers exit (although the production speed of its block will decrease linearly with the reduction of online participants).

On the other hand, the Ethereum segmentation chain relies heavily on participants with synchronized clocks. Blocks are generated on a fixed schedule. In order for the system to progress, the clock needs to be synchronized in seconds, which also makes its implementation much more difficult.

In addition, NEAR is actively researching ways to tune TxFlow so that when the number of active verifiers is less than 2/3, the system remains active (and in this case, leads to a higher probability of bifurcation).

For more technical details on NEAR's blockchain design, readers can check out:

NEAR conceptually competes with Ethereum 2.0, but the disadvantages are also obvious

When designing complex fragmented blockchains, many design decisions boil down to choosing from multiple suboptimal solutions, such as trade-offs between the centralization and non-forkedness of the beacon chain.

The NEAR agreement and Ethereum 2.0 have chosen two similar but different ways. Surprisingly, although NEAR has a competitive relationship with Ethereum 2.0, there are some cooperative research between the two teams. Perhaps both are also aware. The pros and cons of different methods.

From a personal point of view, the NEAR protocol is more like a compromise version of Ethereum 2.0, so it will be easier to implement (there are rumors that it will be online in November), but its goal is better than Ethereum 2.0. Also weaker.

In addition, the current NEAR community is still relatively small compared to the Ethereum community. This gap may not be achieved through “shortcuts”, but its growth may be worth looking forward to. If you have different opinions, please leave a message.

Reference materials:




We will continue to update Blocking; if you have any questions or suggestions, please contact us!


Was this article helpful?

93 out of 132 found this helpful

Discover more