NEAR Protocol is another layer-one option in the Web3 development space. It uses a proof-of-stake consensus and a proprietary sharding mechanism to distribute computational load across validators.
The protocol is simplistic by design and is built as a foundational layer for the real goal of NEAR: To become a community-owned dApp platform to compete with cloud-based infrastructure companies such as AWS.
One of the easiest ways to secure a network for your protocol is to use the Proof-of-Stake consensus mechanism. Put simply, Proof-of-Stake swaps computing power for economic power. For validators to create blocks, they must stake a large amount of the native token.
Validators are chosen at random but with a weighted modifier based on the amount staked. The more staked, the better chance that one has of being chosen to be a block leader and receive rewards. Any dishonest attempts to attack the network result in a punishment: a slash in the percentage of tokens staked.
Validators who are not the block leader then vote on the current and true state of the blockchain.
Users who hold the native token but don’t wish to stake them in their own validator may stake them in an existing validator of their choosing. These users then receive a percentage of the reward from the validator.
This is a brief explanation of Proof-of-Stake and every protocol has a different version of it. It is important to note that NEAR still uses the longest chain as the canon chain.
One of the main selling points of NEAR (and any Proof-of-Stake protocol) is the environmentally friendly use of Proof-of-Stake, particularly compared to the spooky Proof-of-Work model.
The NEAR token is the native token of the NEAR protocol. Like any other Proof-of-Stake network, this token is staked to secure the network. Just like any other protocol the token is used as a unit of account and a medium of exchange for fees.
The token has a circulating supply of ~778.92M NEAR (Buy NEAR) and will be capped at 1B NEAR.
NEAR’s inflation schedule is approximately 5% per year. Validators receive 4.5% per epoch with 0.5% going to the protocol treasury. Every transaction sees a burn of 70% of fees. The remainder goes to smart contracts used by the transaction.
There are two parts to a NEAR transaction: Actions and Receipts. Actions are ‘units of operation’ that make up a transaction. Receipts are the objects that are applied to the blockchain.
Every virtual machine blockchain requires gas. This is not only to pay validators but also to counter denial-ofservice attacks. The gas function is generally the same across platforms. On the other hand, the distribution of fees may also differ across platforms. See the breakdown of NEAR’s gas distribution here.
For NEAR to be fast and scalable, it first must solve the problems plaguing the Proof-of-Work Ethereum network. One of those problems is that Ethereum (Buy ETH) has to process transactions on one blockchain.
This means every node must process each transaction and the network must wait for them. Waiting for every node to agree on the current state is a downside of the Proof-of-Work consensus. It’s a slow, steady and safe Nakamotor.
Nightshade is NEAR’s take on sharding. Ethereum 2.0 uses a beacon chain sharding method where shards are separate blockchains to be finalized on the beacon (main) chain. Transaction throughput is only as fast as the beacon chain.
To avoid that bottleneck, NEAR still uses a single master blockchain. Instead of breaking that chain apart, however, Nightshade breaks blocks apart. This means that transactions need only be finalized at the block level and not at the blockchain level. This makes it infinitely scalable, a functionality planned for an eventual rollout.
A minimal sharding of account states called Simple Nightshade was released in November 2021. Accounts states will be split into four shards but will still be confirmed by every validator.
At this stage, the network hasn’t reached capacity yet, but the developers want to begin the transition.
The next phase is to provide a less hardware-intensive role known as the chunk producer. Similar to a validator producing a block, this type of validator produces a chunk for a shard.
This phase represents the completed implementation of a fixed amount of sharded blocks.
Instead of a fixed amount of shards, this fully realized version of NEAR will have a dynamic number of shards as the protocol needs.
The main focus of the NEAR protocol is ease of use. There are usually two reasons for total beginners to quit crypto:
1) They got rekt
2) Nothing is easy or intuitive to use.
Getting rekt is just an unchanging law of nature. That being said, creating an intuitive and smooth user experience can certainly see some change.
Wallet addresses at the user level use human-readable strings. These strings come in the form of ‘.near’ addresses. This is referred to as a Named Account and functions the same as the random strings that wallets are usually labeled with.
The random string isn’t going away. Hashing is important to the security of crypto and ‘AscendEX.near’ is not a very good hash. The foundation of a Named Account is the Implicit Account which is a 64-character string and should be viewed as the public key.
Generally, wallets store both a private key and a public key to send and receive transactions. NEAR’s more modular approach stores many key pairs, all with different levels of permission in an account. Your account is a vault of private/public key pairs.
There are three key types:
Full Access: This is a key that grants a user full access to the account and funds. This type of key can add/remove accounts or sub-accounts. Add/remove access keys and call any contract or transfer NEAR.
Function Call Keys: Different keys give smart contracts limited access to the wallet. Transaction access is kept to only specific functions needed to transact with a smart contract. It even allows the user to set the max amount of gas spent to call a method.
Locked Accounts: An account is locked when all keys are removed from the account. Access is only given to the account’s smart contract.
Each account has a state indicated by metadata stored in the account. This data is the account’s smart contract code and storage. Account states are open for anyone to read but can only be changed by the account itself.
The account must lock and hold NEAR tokens proportional to the amount of storage used. For this reason, storage of data is paid from the account.
Since NEAR is not EVM-compatible, Aurora was developed as a layer-2, adding Solidity functionality to the NEAR protocol. Aurora allows developers to port their Solidity smart contracts to NEAR. This allows users to use Ethereum applications on the NEAR network instead.
NEAR began just like any other Proof-of-Stake blockchain but with a vision to transform it into its own type of scalable blockchain.
With Aurora and Rainbow Bridge, the Nightshade implementation still looks to grab market share from Ethereum developers. Once fully implemented, Nightshade should provide a fast and reliable platform for dApp developers.
And we didn’t even get into the Octopus Network! That’s for another article.