NEAR is a decentralized development platform that uses a Proof-of-Stake (PoS) consensus mechanism and will eventually feature a sharded architecture to scale transaction throughput. Its block generation scheme is called Doomslug and its proposed sharding design is dubbed Nightshade. These technologies will work together to scale the network and minimize congestion. NEAR has also been designed to be developer and user-friendly as it features a few key innovations to accelerate the application development and user-onboarding processes. The NEAR blockchain was created and developed by the NEAR Foundation. Its mainnet went live in April 2020, and network validators voted to unlock token transfers in October 2020. NEAR’s bridge to Ethereum (called the Rainbow Bridge) launched in March 2021.

History

NEAR was a machine learning project before it became a blockchain development platform. Illia Polosukhin and Alexander Skidanov started NEAR.ai in early 2017 to explore program synthesis: the field of automating programs from a human specification. Named for the science fiction novel The Singularity Is Near, the NEAR project drew from Illia’s work as a lead contributor for TensorFlow at Google and Alexander’s as the lead engineer at MemSQL. Researching program synthesis led the team to explore programmable smart contract platforms and crypto payments in late 2017 and early 2018. As they explored the solution space and tried out a variety of blockchain protocols, they realized the current state of the tech didn’t meet their needs and began to design a blockchain that could. Illia and Alex gathered a team of engineers and formally started building NEAR Protocol in August 2018. The founding vision for the NEAR platform was to offer developers an easy path to building decentralized applications that can scale to mass usage. To achieve these goals, NEAR adopted a Proof-of-Stake (PoS) mechanism to support transaction verification and block production. NEAR combines a horizontal scaling approach with a new consensus mechanism that splits the network into parallel shards and dynamically distributes the computation to increase the network’s processing capacity. The network launched in April 2020, became community-operated in September 2020, and passed a vote to enable token transfers in October 2020.

Technology

NEAR’s blockchain uses a new consensus algorithm and a sharding architecture to achieve a relatively high level of performance. The key elements of NEAR’s technology are: Dynamic Re-Sharding Nightshade Doomslug Fees as Developer Rewards Token Balance-Based Storage Dynamic Re-Sharding There are two ways to approach scalability – Horizontal and Vertical. NEAR has chosen to use sharding, which is a type of horizontal scaling technique. Sharding is an approach to scaling databases, and it involves spreading computing and storage capacity across multiple servers. In the world of blockchains, sharding involves partitioning a blockchain across subgroups of nodes and distributes computation across multiple parallelized sub-chains (“shards”). Sharding is not live on NEAR at the moment. Once sharding goes live on NEAR, the network intends to regularly adjust the number of shards supported by the network based on user demand. The project calls this demand-based approach to scaling “Dynamic re-sharding.” This scheme allows the network to only pay for the infrastructure and scale it needs at any given time. Dynamic re-sharding might be a more cost-efficient approach to scaling and securing a sharded network since node storage requirements can adjust with demand. Nightshade NEAR uses a new sharding approach called Nightshade to reach consensus and settle cross-shard transactions. Most sharded networks use a smaller validator committee that rotates its lead block proposer when validating transactions across shards. This approach introduces some difficulties to the validation process. For instance, these validator groups must either download the entire state of each shard or receive only the portion that changed. The validation process for either technique can be inefficient as the first one requires a bigger time frame and the second one requires a larger state size. Nightshade offers a different model by modifying the typical sharding abstraction. It assumes that each shard works together to produce “chunks” of data that collectively create a single block. Blocks are produced with a regular cadence regardless of whether each individual shard has produced its “chunk” for that specific block height. Nightshade is a leader-based system, meaning it assigns a single validator to produce each block. This validator must assemble the data chunks generated by each shard during their leadership period into a block. Leadership assignments will rotate through the existing validator set. Validators don’t accept transactions, only chunks. Doomslug Doomslug is NEAR Protocol’s new block production technique. According to the team, it enables the network to achieve some sense of practical finality after one round of communication, with a finality gadget providing BFT finality after a secondround. Practical finality in Doomslug (or Doomslug finality) is when a block is irreversible unless at least one participant is slashed. Doomslug also allows the network to continue producing and finalizing blocks as long as over half of the validator set are online and honest, although the finality gadget will stall if less than two-thirds of participants are online. Fees as Developer Rewards NEAR distributes 30% of any transaction fee to the contract (or contracts) that transaction calls. The contract’s owner (often a developer group or a DAO) can decide how to allocate these funds. These fee “rewards” effectively incentivize early application development on NEAR. The percentage of fees allocated to this reward is a system-level parameter (can be adjusted by governance), but developers may choose to receive any amount equal to or above this minimum value. Token-Based Storage NEAR token holders have the right to store data on the chain. For example, if someone holds a balance of 1 NEAR, it means that the person can store nearly 10 KB of data on the account. This model is similar to how checking accounts in banks require a minimum balance to have an account. It allows contracts that are maintaining important state to pay validators proportionally to the amount of data they are securing.

Governance

Network governance is open to contributions from the community. Anyone can submit or comment on an improvement proposal. These governance discussions take place within the NEAR forum. Proposals typically go through a draft stage where they are open to community feedback and scrutiny. If proposals receive enough support, NEAR development teams will build a spec and aim to merge the change. The timing of the proposal’s implementation will depend on the change’s urgency (e.g., a hotfix for a critical bug would be administered almost immediately). Validators ultimately choose whether to adopt a new version of the protocol by running the latest client release.

Token Usage Details

NEAR is the native currency of the NEAR protocol. It represents the core medium of exchange and unit of account for native transactions. It primarily serves the following purposes: Security: Stakers receive awards in NEAR by staking their tokens and contributing to network security. NEAR’s user of Proof-of-Stake (PoS) provides Sybil resistance from DDoS (distributed denial of service) attacks. Network Fees: The utility of the network is provided by storing application data and providing a way to change it by issuing transactions. The network charges transaction fees for processing the changes to this stored data. The NEAR network collects and automatically burns these fees, such that higher usage will lead to more NEAR tokens being burned. A minimum percentage of smart contract usage fees is allocated for developer rewards. This reward effectively incentivizes early application development that increase network use. When a contract is called, some portion of the transaction fees is generated by the network is automatically allocated to the contract. A minimum value has ben set as a system-level parameter and the developers can choose any value to or above this minimum value.

Asset profile is provided by messari. Original version can be found at Messari