NEAR, a sharded Proof-of-Stake blockchain with a focus on being developer- and user-friendly, is a smart contract platform. "Sharding allows the work of validating transactions to be broken up amongst many ‘shards’, each of which is validated by different nodes." (near.org) Often compared to Ethereum because of a shared vision for the future of smart contract platforms and a utilization of sharding, there are key differences that distinguish NEAR.
Despite the complex technology underlying the network, NEAR intends to be accessible to a wide audience by emphasizing intuitive user experiences and focusing on scalability. As a decentralized community-run cloud computing and storage platform, NEAR is designed to foster the growth of the open web of the future.
NEAR’s “progressive security” provides developers the flexibility to specify exactly what permissions are granted to another user or contract. This means developers can create apps that don’t require users to have advanced knowledge, a model that fosters the creation of experiences similar to those familiar to most people from the web:
A number of usability improvements support developers of the platform:
NEAR is innovating on a number of fronts.
A minimum percentage of Smart Contract usage fees as developer rewards: When a contract is called, a portion of the transaction fees generated by the network are automatically allocated to the contract; the contract’s developer can decide how funds are allocated (to themselves, to the community via the token accruing value, etc.). This “reward'' effectively incentivizes early application development that increases network use.
In NEAR, the percentage of fees allocated to this reward is set to a minimum value as a system-level parameter. Developers may choose any value equal to or above this minimum value. By design, the NEAR protocol protects developers from a “race to the bottom” zero rewards competition.
Balancing inflation vs transaction fees for long-term sustainability: Many blockchains aim to maintain validator participation through transaction fees alone, rather than continuing to incentivize validators with rewards. NEAR’s model strives to achieve this by keeping inflation constant while transaction fees get burnt; if there are enough transaction fees, the network’s real rate of inflation is actually lower and can even be negative! The more transactions on NEAR, the scarcer NEAR tokens become.This is a benefit for everyone holding NEAR tokens, with a different impact on stock-to-flow ratio compared to other similar currencies.
Senders only pay for the gas they use: On NEAR, a sender specifies a max limit of how much gas can be spent to execute that transaction. When the transaction reaches the network and begins processing, it automatically buys enough gas to finish processing at the current gas prices. Once the transaction is processed, the sender’s account is only "charged" for the gas used. Any leftover gas is converted back to NEAR tokens. This process prevents accidentally inputting a significantly higher gas amount than necessary to complete a transaction.
Developers can prepay gas for first-time users: On other networks, users typically need a small amount of tokens in their account set aside to interact with the network. On NEAR, developers can design applications so that first-time users draw funds for purchasing gas directly from an account maintained by the developer. Later, users can transition to pay for their platform usage. This design decision addresses a friction point in the UX that could otherwise hinder the protocol’s ease of use.
Contract-based delegation: On NEAR, staking is done at the protocol level but delegation to validators is done via smart contracts deployed to the platform. This gives validators significantly more flexibility to offer advanced financial products related to staking which specifically target the needs of their audiences. For example, a validator can offer better rewards based on amounts staked, duration of commitment, or even loyalty over time. This also enables automated delegation via smart contracts, which can dynamically provide users with the best available return via lending, staking or any other financial instrument, opening up a wide range of new DeFi use cases.
Human-readable account ID’s: NEAR’s human-readable account names replace a hash of a public key. Account names are similar to domain names. A top level account (TLA) without separators can be created by anyone, for example
near can create
jane.near. And only
jane.near can create
app.jane.near and so on.
near can not create
app.jane.near directly. TLAs will be auctioned off, with a fair process, and all proceeds burned.
Function-call limited permission allows non-monetary transactions from non-owners: Access Keys grant permission to act on behalf of an account. NEAR currently has two types of permissions: full-permission and function-call limited permission. The latter type is a key usability feature of NEAR. This type of permission allows non-monetary function-call transactions to be sent from an owner's account to a receiver with the receiver ID restricted by the access key.
Allowing this interaction enables several critical use-cases:
Token Balance-Based Storage - Storage poses a problem for many blockchains. It is important to store all transaction data forever to ensure individual entities can verify the truth of the whole chain. However, as the chain gets larger, syncing takes longer and it becomes increasingly expensive for new nodes to join the network. Token balance-based storage on NEAR means that the more data you want to store, the more tokens you need to have on your account. The user is not paying for storage per-se, but is essentially putting up a bond to continue having that data on-chain. The intent is to align incentives between users and validators.
Dynamic re-sharding* - Sharding is the partitioning of a large database into smaller components, or shards; shards parallelize computation and distribute storage. Shards aim to increase speed on the blockchain, allowing more transactions per second and the ability to dramatically scale up a network.
NEAR intends to use dynamic re-sharding on-chain, which means the number of shards changes in response to usage demands, scaling up and down. Dynamic re-sharding allows the network to only pay for infrastructure and scale it needs, rather than overpaying for unneeded throughput or underpaying and running into bottlenecks. Developers don’t need to think of shards or deploy their app to a specific shard. In the future, the protocol will continuously reevaluate usage and storage and move smart contracts between shards accordingly. NEAR will automatically load balance smart contracts, maintaining that no shard is more heavily trafficked.
* This feature will not be live at launch.
“We are excited to support the NEAR team as they launch the protocol. I've been following the team at NEAR for some time now and am blown away by their focus on the developer experience. NEAR's incredible technical team understands building a strong developer ecosystem will help drive success.” —Joe Lallouz, CEO of Bison Trails
NEAR is a sharded Proof-of-Stake (PoS) blockchain, but only one shard will exist at launch. That number can increase through hard forks of the protocol. Initially, validators will be rewarded for their participation on the chain in proportion to their stake. As the number of shards increases, validators with large stakes will need to validate multiple shards in parallel, which would require them to have more powerful hardware or split their stake between multiple machines. Long term, the number of shards will be dynamic.
In order to elect validators, the protocol issues an auction for each epoch (approximately every 12 hours). New validators are elected if they bid a higher stake per seat than existing active validators; funds from accounts that don’t provide a sufficient amount of stake will be returned at the end of the next epoch.
Each epoch on NEAR has its own active set requirement. The active set is made up of a number of available seats, currently 100. The seats do not have a one-to-one correlation with the number of validators in the set. Validators with large stakes can occupy more than one seat in the active set.
A seat price is determined to elect validators to the active set. This price is calculated by dividing the total stake by the number of available seats. A validator cannot join the active set if it’s stake is less than the seat price, even if there are “open” seats available (e.g. there are 100 seats, but only 50 validators take all 100). Those validators then become a “fisherman,” an observation node that detects and reports bad behavior.
Validators in the active set are responsible for validating blocks and are assigned to produce blocks on a fixed schedule. The validator responsible for producing a block at height h is called block proposer at h. If the validator fails to produce a block when it is their turn, the protocol stalls briefly until the next block producer’s turn. A single missed block does not result in a penalty.
At launch, all active validators will be on a single shard; eventually they will be randomly assigned to shards. Validators on a particular shard are considered “chunk” producers in addition to block producers. A “chunk” is a group of transactions from a single shard; they are aggregated with chunks from other shards into a block by block producers. Because all active validators are currently on a single shard, they are both chunk and block producers.
In NEAR, Ⓝ represents the right to store data on the chain. As an example, Jane maintains a balance of 1 Ⓝ in her account she can store roughly 10 kilobytes. Therefore, users need to maintain a minimum balance on their account (a fraction of Ⓝ) in order to participate in the network.
This payment system means contracts must lockup Ⓝ in proportion to the amount of data they secure. A contract that maintains balances for millions of users would need to have a balance that covers the necessary storage.
Because most users have very low storage rates, they won’t need to be concerned with tracking their Ⓝ balance. However, dApps and large smart contracts will need to be conscious of their balance.
NEAR apportions 30% of transaction fees to the contracts involved in those transactions.
For example, a transaction sent to smart contract X with a 0.0001 Ⓝ fee, and without calls to any other contracts, will net smart contract X reward of 0.00003 Ⓝ (30% of 0.0001 Ⓝ). If contract X uses contract Y for 50% of its functionality (measured by gas usage), the reward is split between X and Y. This process allows frequently-used libraries to earn rewards from all the client applications that use them.
NEAR Protocol uses human-readable account names. These accounts are a user’s digital identity and can be connected to finances, data ownership, and cryptography.
There are two lengths possible for these names: shorter than 32 characters and longer than 32 characters. As shorter names are expected to have more value for users, a naming auction will take place shortly after MainNet launch. Longer names can be registered on a first-come first-serve basis.
NEAR’s Mainnet is currently running as a Proof-of-Authority network but is planning to transition to a Restricted Mainnet sometime in July or August, 2020. If you are a NEAR token holder, you can begin running a validator at that time. Although there is no inflation during the Restricted stage, the NEAR team will be awarding stipends of 10,000 Ⓝ tokens per month for those who participate.
During the Restricted stage, validators will vote to progress to the next, community-governed stage. Only validators will be able to vote at that time; the validator will vote on behalf of their own stake as well as those who delegate to them. The voting power of the validator continues to be magnified in the community stage by having the additional delegated tokens on the validator.
As NEAR develops and introduces new shards, the network will become more reliant on high-quality validators, as they are distributed among the different shards. Having too few validators in the network will create performance vulnerabilities.
"It’s been great working with the Bison Trails team, learning from their hands on experience with other PoS networks to improve our own staking experience and protocol design. Bison Trails has been on the forefront of what is now considered the professional validator industry, making participation in blockchain networks more accessible and helping to provide more high quality operators to the network." —Illia Polosukhin, NEAR Co-founder
"The formation of the NEAR's Validator Advisory Board reflects the team's commitment to engaging the community to rethink how blockchains should work. NEAR's approach is both ambitious and pragmatic—I admire how the team has driven the protocol development forward while questioning assumptions and pushing the boundaries of user and developer experience. I'm thrilled to be included in the Validator Advisory Board and I look forward to further collaboration.” —Viktor Bunin, Protocol Specialist at Bison Trails
Bison Trails is an Infrastructure-as-a-Service company, based in New York City, specifically focused on blockchain participation. We’ve built a platform for anyone who wants to participate in new chains effortlessly (e.g. by running Cosmos Validators, Tezos Bakers, and Libra Validators, etc.)—without having to invest time and resources into developing any of the engineering, protocol, dev ops, or security competencies in-house. Our goal is for the entire blockchain ecosystem to flourish by providing robust infrastructure for the pioneers of tomorrow.
Meet the Herd: Content Strategist Casson RosenblattSep 17 2020
Bison Trails Newsletter 007 • August 2020Sep 16 2020
Bison Trails Supports the Oasis Network and the Creation of a Responsible Data EconomySep 14 2020
Meet the Herd: People and Development Manager Melissa MeisterSep 4 2020
The NuCypher WorkLock Begins September 1, 2020Aug 28 2020
Coinbase Custody and Bison Trails Enable Secure Staking of Solana (SOL) TokensAug 27 2020
Bison Trails is Minimizing Risks of Blockchain Participation with Double Signing ProtectionAug 21 2020
Meet the Herd: Head of DevOps Rob ChristensenAug 13 2020
Bison Trails Announces Support for Flow and All Node TypesAug 10 2020
Meet the Herd: Engineering Manager Paul Hurlock-DickAug 6 2020
Bison Trails Newsletter 006 • July 2020Aug 5 2020
Optimize Your Participation with Bison Trails InfrastructureAug 4 2020
View More →