Update: MainNet launched as planned on April 22. Learn more about how this works and what it means for each stakeholder in Announcing MainNet Genesis
Introduction to NEAR Protocol’s MainNet
Building a blockchain is hard enough. Building a complex blockchain that can scale to billions of users and provides great developer experience is extremely hard.
The core difference between building a regular product and blockchain is that you can’t launch something and iterate with your users quickly fixing issues in near-real time. This is not how protocols are designed and built. Once a protocol is live, changing it requires an enormous amount of coordination. In the case of a blockchain protocol, especially one built with Proof of Stake, the protocol will begin securing hundreds of millions or billions of dollars on day one. You can’t launch a half-completed project and quickly iterate in this case.
Our team comes from a background of building products and quickly iterating on them. From the start, we took a product approach, trying to learn as much as possible from the market. Instead of following the whitepaper we initially wrote or relying on our preconceptions of what developers need, we built an MVP with developer tooling, a test wallet, and a not-a-blockchain smart contract backend. We called it DevNet and got initial developers at hackathons and workshops to try building applications on it.
This gave us a lot of feedback about how smart contracts work in multi-sharded setups and the tools needed to make blockchain accessible to a wider group of developers. It also gave us time to realize that our original approach to sharding wouldn’t cut it. This led to rethinking the approach and, ultimately, the Nightshade sharding design paper.
As we continued to iterate on the design of the blockchain, we ran a publicly accessible TestNet that any developer could build and deploy contracts to. The currently running TestNet is actually a continuation of one we started in April 2019. Through many hard forks, the network has kept the state for over a year.
From the beginning, all of our development has been public on GitHub. It went from a single repo for NEAR’s reference client (nearcore) to almost 100 public repos across three organizations (nearprotocol, near, near-examples) spanning a set of tools and products to support needs of developers and initial users of NEAR Protocol.
Requirements for a fully operational network
There are a lot of pieces that must work together to make a fully decentralized network like NEAR operational:
- The NEAR code must be bulletproof and successfully running on a large number of validators’ computers around the globe, which together are providing their compute resources and securing the network.
- Developers should be building and launching products on NEAR.
- NEAR should be integrated with various partners who provide additional value to the ecosystem.
- Tokens should be in the hands of the involved parties, who are going to use them for staking, development and using the applications. These token holders are our initial community who will be early adopters of the applications and also the loudest voices of our support.
- Active ambassadors around the world should be spreading our mission and message and educating people both about blockchain and what can be done on NEAR.
- The general market should have both the knowledge and the desire to learn more about the project and get involved.
MainNet Roadmap and Timeline
We are going to be releasing NEAR’s MainNet in stages. Each stage is identified by the restrictions that it has and each stage has different goals. It’s important as we open up the network more and more to test at every stage and provide flexibility to address issues early in the process.
The following sections detail each of these stages.
MainNet POA
Expected time to launch: April 22 – 27, 2020
ZenHub link to track this release
This is NEAR Protocol running in Proof of Authority mode, with the NEAR Foundation operating the initial set of nodes. Most importantly, the state of the network will be maintained going forward.
The goal for this stage is to distribute initial tokens to contributors and get the initial set of validators onboard. At this point, only the NEAR Foundation is able to transfer tokens and will be using lock-up account contracts when allocating tokens to first users. In other words, most token transfers are restricted.
Developers who are ready to deploy their applications to MainNet can apply to the NEAR Foundation and get an account to deploy their application.
In parallel, we are still running our TestNet with various validators to test out all the corner cases of validation. As soon as both NEAR Collective and validators are satisfied with the stability of running on TestNet, we will transition into the next phase.
MainNet (Restricted)
Expected time to launch: June – August, 2020
ZenHub link to track this release
Given that transfers are disabled for most accounts and the lockup contracts doesn’t allow to stake directly (only via delegation), the initial validator set is determined by a whitelist of validators to delegate to. As soon as the initial set of validators is determined from TestNet and shows their MainNet infra running, NEAR Foundation will stop staking and pass the staking to these validators.
There are a few goals for this phase:
- Test that MainNet is operating correctly with a decentralized set of validators and continue code and security reviews
- Initial applications which can work without transfer restrictions can start launching
- NEAR Foundation will be continuously distributing tokens to the value-add community.
This stage is completed when the community decides that the network is secure and decentralized enough. A contract to vote on lifting transfers will be used by the community to identify such time. Validators will be casting votes, as they have locked capital in the network and can not “double vote”. Delegators can cast their votes via staking contract as proxy, overruling validators vote proportionally to their stake.
When ⅔ of total stake and at least 35% of total supply vote for a specific block number, it’s considered decided by the community and transfers will unlock in two weeks from that block number.
MainNet (Community Governed)
Expected time: decided by the community
At this point, the network is fully operational and doesn’t have any restrictions. Validators and delegators are now responsible for continued operation of the network and deciding to upgrade.
In parallel with the general community gaining confidence and voting to unlock transfers, NEAR Collective will continue to work on ensuring the quality and security of the network, and has released a target to finalize a number of post-flight tasks. ZenHub link to track progress is here.
Comparison between stages
Here are more specific dimensions to compare different release stages of the MainNet:
Post MainNet
One of the critical parts for any project is to continue moving forward and evolve over time. To make sure NEAR does this, we follow a development process that establishes a fixed launch timeline. We have setup three networks to provide us with a testbed:
- devnet – nightly released network from the master branch that provides a place to stress test and do initial testing of code added that day, additionally run nightly test suit.
- betanet – released weekly, accepts external validators and application developers who want to live on the bleeding edge.
- testnet – released every 4 weeks and is a stable version, this is the same TestNet we have been running since April 2019, and is the best place to do acceptance testing for one’s applications.
Validators on MainNet will be voting as a community on accepting new stable releases. We expect that the timing on this would usually depend on the magnitude of changes that came in that release.
We are not going to launch MainNet with all the features we have in mind. Many things end up being outside of our “MainNet v1” scope to make sure we can deliver quality products. Some of these include:
- Upgradability without hard forking (link to discussion and epic tracking issues related)
- Unbiasable randomness (design, implementation)
- Safes: safe locks for operations with assets across contracts and shards (design)
- Enable challenges to switch to selfish majority assumption (epic)
- Parallelize Runtime (epic)
- Rework Storage (epic)
- Dynamic resharding (epic)
- And more features and improvements coming from community and developers
After the “Community Governed” phase is done, we are going to set up the next release of MainNet v2 with a set of tasks to complete in subsequent 4 weeks.
FAQ
How do existing token holders claim NEAR tokens on MainNet?
If you are an existing token holder, you will receive an email with detailed instructions which information must be provided to NEAR Foundation for your account to be created on MainNet with your funds.
It’s highly recommended that token holders claim their tokens before the MainNet Restricted stage to be able to participate in validation and subsequent voting to unlock transfers.
How many shards will NEAR Protocol have? How should validators handle it?
At launch, we are going to configure the network to 1 shard since it is unnecessary to have more. As network usage grows, a hard fork into 2 or more shards can happen based on a community vote. At that point, the number of shards are just a parameter in the genesis configuration.
We have a design for Dynamic resharding that will be implemented in upcoming releases, allowing the system to change the number of shards dynamically based on load.
The important note for validators is that, as the number of shards increases, validators who have multiple seats due to large stake will start validating multiple shards in parallel (refer to the economics paper for more details regarding how validator selection works). This means they will need to run more powerful hardware or split their stake between multiple computers.
In parallel with MainNet “Restricted” launch, we are going to be running the first BetaNet and then TestNet with at least 8 shards to test performance and tooling. Validators should join these networks to establish that their setup scales properly before MainNet scales to that.
What kind of slashing does NEAR Protocol have at launch?
Slashing is disabled at launch. At launch, the network will operate with an honest supermajority assumption. Going forward, slashing conditions for violating BFT finality and producing invalid state transitions will be added via normal governance procedures.
Why should I delegate during the MainNet “Restricted” Phase if there is no inflation?
The requirement for unlocking transfers is to gain momentum around community governance. We expect a large percentage of distributed supply to participate in the voting to showcase this. If you are not delegating, you might be delaying when the community can make this decision. Validators will cast votes for their delegates (unless delegates want to override it), thus making it easy on delegates who might have limited ability to control their holdings in the short term (due to limited custody support for example).
Since there is no slashing initially, delegation is risk-free and ensures that as soon as inflation starts, people will begin receiving their rewards. If you are planning to delegate, you still should be careful to choose which validators to delegate to. Validators who don’t maintain an online presence will be kicked out and won’t receive their rewards.
How do I become an initial validator at MainNet “Restricted” Phase? How do I accept delegations?
The main way to become a validator at MainNet “Restricted” phase is to participate in the upcoming revision of Stake Wars and be an active validator of TestNet. There will be tutorials published on Github and already now you can run your nodes on Betanet. Specifically, Stake Wars 2.0 will be around delegations, so as a participant in Stake Wars you will be able to learn how to set up delegation smart contracts and invite people to delegate to you.
From our side, we will also connect all active participants of Stake Wars with existing token holders who are interested in delegating, making sure that participants have enough stake to take a seat in MainNet “Restricted” phase.
Alternatively, if you are an existing NEAR token holder you will be able to stake your own funds freely.
As a developer, how do I create accounts for my users?
During POA and Restricted stages, only the NEAR Foundation is able to freely create accounts after doing KYC. NEAR Foundation, as part of its distribution activities, will provide a way for people to receive some initial amount of NEAR which they can use to provision their account and deploy applications.
If an application needs users to have an on-chain account, it can route them to the NEAR Foundation’s work drop landing page (which will be created).
Alternatively, applications can use Access Keys to their own application as a proxy identity and provide a way to “export” the user’s identity later to a full account. We are going to write a separate blog post to describe how this can be done.
