Fundamental Insights
Is NEAR the star of tomorrow in public chains?
Recently, NEAR-based DeFi Protocol Flux completed a $10.3 million seed round of funding, with many star institutions participating in the round; NFT star project Mintbase migrated from Ethereum to NEAR, which attracted Flux and Mintbase to land on NEAR, and what is unique about NEAR?
On May 21, Flux Protocol, an open data infrastructure provider, successfully completed a $10.3 million seed round of funding to build the DeFi infrastructure. migration and went live on the NEAR mainnet. In a short period of time, the choice of heavyweight projects has once again drawn the industry’s attention to NEAR.
NEAR Introduction
NEAR is an open network infrastructure and a Layer 1 public chain with PoS consensus, which aims to provide performance and user experience no less than today’s Internet. It enables a dynamic sharding scaling solution through Nightshade protocol, interoperability with other blockchains through Rainbow bridge, and in addition, provides application layer proven tools to provide a convenient and friendly experience for developers and users. NEAR team is composed of several serial entrepreneurs and the world’s top engineers, who have rich industry experience in developing distributed systems and have won 4 ACM-ICPC global championships and multiple medals, Google Code Jam championship and Top Coder championship, etc. The main features of NEAR are: unlimited scalability, cross-chain interoperability.
Nightshade — NEAR’s scaling mechanism
In a decentralized blockchain network system, each node has to handle every transaction of the whole network, which is the reason for the low performance of blockchain and the main adjustment faced by blockchain scaling. In order to solve this challenge, many teams have proposed different solutions to try to solve this problem at the protocol level. These solutions mainly fall into two categories: one is to give all the computation work to a limited number of powerful nodes; the other is to let each node in the network do only a part of all the computation work, the latter is called sharding, and the NEAR protocol is built based on sharding. Current designs for sharding systems almost always use an additional independent blockchain to perform the operations needed to maintain the entire network. The name of this independent chain is called a beacon chain in Ethereum 2.0 and a relay chain on Polkadot.
The model of multiple fractional chains plus a beacon chain is very powerful, but also quite complex. In particular, the fork selection rules need to be executed independently on each chain, and the fork selection rules for the slice and beacon chains must be built differently and tested independently. NEAR’s slice mechanism Nightshade takes a different approach by delicately designing the whole system as a single blockchain. The physical implementation is such that no participant downloads the full state or complete logical blocks. Each participant in the network actually just maintains the corresponding state on the slice for which they validate transactions. The list of all transactions in the block is physically split into segments, with each slice corresponding to a segment.
The two dominant consensuses for blockchains are: longest (or heaviest) chain consensus, which means that the chain built by the most work or equity is considered the orthodox chain; and BFT consensus, which means that for each block a BFT consensus is reached by a group of validating nodes in it. NightShade uses the heaviest chain consensus, based on the heaviest chain consensus, using a deterministic tool that uses proofs to determine blocks. To reduce system complexity, the deterministic tool used does not affect the fork selection rules in any case, but only introduces additional forfeited pledge pass conditions. Thus, as long as a block is identified by the deterministic tool, no fork is possible unless a huge percentage of the total equity is forfeited.
There are two roles in Nightshade: the block issuer and the validation node. The block issuer and the validation node are not necessarily both different entities. Blockers and validation nodes lock a certain amount of built-in currency for a period of time that extends well beyond the time they use to perform the construction and validation of the chain. The state of the master chain is divided into a number of shards. Each blocker and validation node only downloads locally a subset of the state corresponding to a subset of the tiles at any given time, and only processes and validates transactions that affect that portion of the state. To become a blocker, network participants need to lock in a pass (a pledged interest). The network is calculated on an epoch basis, a cycle being a period of several days. At the beginning of each cycle, the first N participants with the most pledged interests (assuming the system has N blockers) are the blockers for that cycle.
For each block B and each slice S on the main chain, there is a block emitter assigned to S who is responsible for producing the portion of the block on B that pertains to that slice. This section is called a sub-segment and contains a list of transactions in B about that slice, as well as the Merkle root of the resulting state. A segment of a particular slice can only be validated by those participants who maintain its state. They can be block generators, validation nodes or simply external witnesses who download the state and validate the slice that holds their assets. After a block is generated, the segment can be verified by no one but the actual person who issued the segment.
The advantage of NightShade is that instead of maintaining multiple fragmentation chains, fragmentation is performed within a block, and each validation node only needs to maintain a single chain, and only one block is needed to confirm cross-fragmentation transactions, solving the transaction latency problem of the fragmentation chain architecture. Blocks are generated relatively quickly, and the probability of forking will be relatively small under normal operation. The NightShade protocol also supports dynamic re-fractionation, where the number of fractions can be dynamically adjusted with the usage of the network. Each slice can support a capacity of more than 1000 transactions per second without optimization. NightShade’s slicing is horizontally scalable and there is no theoretical upper limit to the number of slices.
Rainbow Bridge — A Bridge to Ethereum
Another advantage of NEAR is the implementation of the Rainbow bridge, where all ERC-20 passes can be transferred seamlessly between NEAR and Ethereum. The Rainbow Bridge is a trustless, permissionless, universal protocol that can be used to connect multiple blockchains and is not limited to Ether. Rainbow Bridge makes any information that can be cryptographically proven on NEAR available in an Ether contract (and vice versa), including reading the status of a contract on another chain, and invoking a contract method on another chain and receiving a callback. Rainbow Bridge is fully decentralized and can accommodate any future protocol changes that may occur on both chains.
The technical principle of Rainbow Bridge is to use two lightweight clients that work together to track the state of the chain without a lot of computation: a NEAR contract written in Rust and executed as an Ethereum lightweight client, and an Ethernet contract written in Solidity and executed as a NEAR lightweight client. At the same time, both verify the state of their traces in a trustless manner and, after confirming finality, transfer the data to each other for ecological use through the relay layer. The sketch of the light client is as follows.
The Rainbow Bridge will contain at least the EthOnNEARClient and NEAROnEthClient contracts and three services: Eth2NEARRelay, NEAR2EthRelay and Watchdog. EthOnNEARClient is an implementation of the Ethereum Light Client written in the Rust language and is also a NEAR contract. It accepts Ethereum block headers and maintains the canonical chain. It assumes that a block with a finalized_gc_threshold subconfirmation cannot leave the canonical chain, and it remembers hass_gc_threshold blocks of the canonical chain. This ensures that the state of EthOnNEARClient does not grow indefinitely. NEAROnEthClient, written in Solidity language, is an implementation of NEAR Lightweight Client, which is an ethereum smart contract. Unlike EthOnNEARClient, it does not need to validate every single NEAR block header as long as it validates at least one block header in each cycle.
The value of the Rainbow Bridge is that it allows the native ecology of NEAR to be built on top of Ethereum’s mature financial infrastructure, breaking down ecological barriers. In addition, the Rainbow Bridge protocol itself is universal, and connecting to Ether is only the first step in NEAR’s cross-chain blueprint. Rainbow Bridge can bridge to any blockchain that supports light clients. Rainbow Bridge will make NEAR a hub for many smart contract chains to connect together. Even Substrate-based chains can connect to Ethereum through NEAR to complete asset interactions, which is easier than connecting to Ether directly, just by rewriting the interface.
NEAR’s Ecology
Although NEAR is an emerging public chain, its entire development environment and user experience have been greatly optimized, and it has already attracted a certain number of projects to land and is rapidly forming its own ecology.
According to https://awesomeNEAR.com/, NEAR has more than 50 infrastructure projects, including wallets, authentication, browsers and so on. At the same time, there are nearly 60 well-known Dapp applications and more than 10 development tools.
To sum up.
@FL As the scope and scale of blockchain applications continue to expand, more DeFi protocols and applications like Flux, Mintbase, etc. are likely to accelerate their expansion to new generation blockchains like NEAR in the future. Compared with predecessors like Ethernet blockchain, the new generation blockchain offers more significant performance improvements and wider functionality by absorbing the good design of the previous generation blockchain and proposing targeted solutions for the pass points of current application areas. And because there is no historical baggage, they will be built and advanced at a much higher speed. With the recent saturation of the Ethereum network, resulting in excessively slow transaction times and rising transaction fees, and the uncertainty of when Ethernet 2.0 will land, many applications are already looking for more user-friendly solutions to build core financial functionality.
NEAR’s sharding mechanism, which is theoretically infinitely scalable, solves concerns for future ecological prosperity. near’s rainbow bridge provides a highly promising bridging model that brings true de-trust and license-free blockchain interoperability to the crypto community. Through excellent design and high-quality engineering implementation, Rainbow Bridge better maintains the security of the underlying blockchain, enabling not only seamless and secure transfer of crypto assets between different blockchains, which will inevitably stimulate more user participation. In addition, NEAR will be 100% compatible with Ethereum virtual machines, and the development tools of Ethereum ecology will be available out of the box, which will also attract the majority of developers to invest in the construction of NEAR ecology. NEAR provides an excellent platform for developers from the underlying protocols to the application tools, and I have reasons to believe that the ecology of NEAR will be improved continuously, and there is a high possibility that a star project with great potential will emerge.
