The Hitchhiker’s Guide to NEAR
The topics covered range from an introduction to the NearProtocol, its smart contract development ecosystem, the basics of its sharded-blockchain design, Doomslug consensus, cryptoeconomics, and governance– explained with the stress on the economic and security implications for Near Protocol’s diverse stakeholders.
About the Hitchhiker’s Series
The hitchhiker’s series by Cryptium Labs aims to provide the reader with the most essential things one should know about a Proof-of-Stake network in a succinct article. It is written without any previous knowledge requirements about the latter, so readers, such as stakeholders, validators, developers, researchers, or anyone who are currently or planning to interact with the network do so in an informed manner and with better understanding.
What is the NEAR protocol?
NEAR is an open-source blockchain protocol, purpose of which is to foster decentralized applications (dApps). The design of NEAR’s smart contract platform is characterized for its focus on usability for both developers, as well as end-users, scalability via novel components in their blockchain architecture, such as Nightshade, simplicity in their implementation, and focus on sustainable decentralization at the technological and community level.
NEAR Smart Contract Development Ecosystem
NEAR’s virtual machine is able to execute programs written in any language, as long as it supports compilation to WebAssembly (Wasm). While just a few years ago, only a few languages were experimentally able to compile to Wasm (namely C, C++, or Rust), WebAssembly’s support has become pervasive among the most broadly adopted languages such as Go, Java, Python, or TypeScript.
At the time of writing, Rust (with near-sdk-rs) is the most directly supported one for smart contract development on NEAR, based on the extensive list of available documentation for developers with or without dApp experience.See for example the following links: building applications, get started, simple Rust smart contract, writing Rust contract. To make it even more accessible for developers, here’s a list of already implemented dApps, which can be used as reference, including real-world dApps such as Non-Fungible Tokens (NFTs), Token Contracts (à la ERC20), or other Fungible Tokens (FTs).
At the time of writing, projects such as Mintbase, ZEST, Flux, among others are built in the NEAR platform (more on NearProtocol’s community updates). Going beyond NEAR’s accessible smart contract development ecosystem, NEAR is part of the startup accelerator Open Web Collective and provides programs for contributors to the protocol, as well as builders on the platform.
NEAR’s Nightshade Sharding Design
One of the most interesting components of NEAR’s architecture is its Nightshade sharding design. For years, sharding has been a prominent topic among blockchain researchers and developers. Although being a very broad concept, it is commonly associated to its potential to achieve scalability. The elemental concept behind sharding is rather simple: consensus nodes only need to validate parts of the history, in contrast to the traditional architecture where all consensus nodes (both in proof-of-work and proof-of-stake based systems) have to validate the entirety of every single block from genesis–thereby limiting both computation and storage overhead on each consensus node, regardless of the growth of the ledger.
NEAR’s architecture is a pioneering instance of a sharded blockchain (to this date, all live public blockchains are non-sharded). Simply put, all transactions on NEAR are aggregated into one list and later on split into chunks (shards). In other words, a consensus node (block producer) on NEAR doesn’t validate an entire block, but rather specified chunks or shards of every block. In practice, the main chain’s state is divided into shards and participants only have stored locally the subset of the state and only validate transactions that are pertinent to the later.
NEAR’s Doomslug Consensus & Node Roles
NEAR relies on its own variant of BFT consensus, known as Doomslug, which is used in combination with a finality gadget. In Cosmos Network’s Tendermint or Hotstuff validators undergo 2 voting rounds per block (pre-votes and pre-commits) and a block is considered finalized as soon as 2/3 of the validating set have provided their pre-commit for a specific block (BFT finality)*.
However, NEAR’s Doomslug distinguishes between two types of finality: Doomslug finality, which is achieved as soon as the block has received its pre-votes and cannot be reversed unless the malicious validator is slashed, in addition to BFT finality, which is achieved after 2/3’s of the block producers have pre-voted and pre-committed (just like in Tendermint or HotStuff). The main benefits behind Doomslug finality are twofold:
- It facilitates the continuous process of block production, as a block is considered finalized as soon as it has received the first communication round– advantageous during network conditions, where a larger subset of the nodes are irresponsive.
- Eases the recovery of the network– in contrast with Tendermint, where the network stalls if 2/3 of the validating set are offline and requires off-band coordination to restart the network.
*For a deeper comparison of BFT consensus algorithms, see Doomslug Comparison, written by Alex Skidanov.
The most relevant to role to node operators is block production, which is the processes that contributes to building the main chain. NEAR relies on its variant of proof-of-stake as a sybil resistance mechanism, thus anyone can become a block producer and/or validator on NEAR as long as they have NEAR tokens to lock as collateral.
NEAR’s Proof-of-Stake & Cryptoeconomics
NEAR’s epochs, inflation, and validator selection
At the beginning of every epoch (1/2 day) the set of largest stake-weighted participants on the network are selected. The likelihood of one entity being selected is proportional to their stake weight. Participants are rewarded with ~4.5% of the overall network yearly inflation plus transaction fees. An additional 0.5% of the yearly inflation is allocated to the NEAR protocol’s treasury, dedicated to foster the ecosystem. To sum it up, inflation on NEAR is a maximum of 5% a year minus transaction fees and other events which burn NEAR tokens.
NEAR validator seats, availability and consistency slashing
For the time being*, the number of validator seats on NEAR is limited to 100, thus, in order to be selected as a validator, one must stake enough tokens to be selected in the top 100.
NEAR does not have explicit slashing for availability (liveness). However, if a validator is not responsive enough at every epoch (fulfilling with minimum threshold of chunks), they will drop out of the consensus set and lose the rewards from the epoch. Once that happens, the validator must re-stake the tokens and wait at least an extra epoch, besides the finalisation of the current epoch (1 epoch = 12 hours, then at least 24 hours and their corresponding rewards).
At launch, NEAR will not have slashing for consistency (safety). However, in the future, NEAR will have slashing conditions for validators that deviate from the protocol (details TBA).
The sources to keep in mind if you’re planning to validate on NEAR are the following:
NEAR’s staking via smart contracts
NEAR token holders who do not wish to operate validators themselves can delegate their tokens. Furthermore, as NEAR is a smart contract platform and community members and stakeholders (including us!) are able to innovate around applications that offer novel forms of staking. At the time of writing, the standard staking contract developed by the NEAR team can be found under this NEP pull request.
NEAR‘s Governance
NEAR distinguishes between technical governance and resource governance. Technical governance refers to the process and rules to amend the NEAR protocol’s technical components, from smaller (bug fixes, parameter changes) to larger scale amendments. Resource governance refers to the decision making process and rules through which the funds in the treasury (which accumulates ~0.5% NEAR token annual inflation) are allocated via community grants. At the time of writing, both technical and resource governance processes are led by the NEAR Foundation.
NEAR x Cryptium Labs
Cryptium Labs has participated in all major testnets including StakeWars and is currently on the active validator set of NEAR’s mainnet (see @cryptium.poolv1.near). Additionally, we are a founding member of the NEAR Validator Advisory Board (NVAB). Just like with the existing networks, Cryptium Labs service fees on NEAR will be competitive with the market. Soon you will be able to find all the information relevant to NEAR stakeholders on Cryptium Labs NEAR portal.
