NEAR Governance: Q&A with Protocol Specialist Viktor Bunin

Introduction

We asked Viktor about his role on the NEAR Validator Advisory Board as the proposer of the criteria to move the network forward to a fully decentralized mainnet launch via community governance.

Hi Viktor! What is the NEAR validator advisory board? What are your responsibilities as a member?

The NEAR Validator Advisory Board (NVAB) is a group of professional validators and infrastructure providers that works closely with the NEAR team. We help them with testing, provide feedback, submit feature requests, and offer advice. For example, when the NEAR team asked me which protocol has the best upgrade process (we support ~30 protocols and have seen many variations) I said Algorand and then connected the teams. NEAR's upgrade process is a direct result of that conversation.

Why is a decentralized mainnet launch beneficial for a protocol?

The keystone of a decentralized protocol is that it is decentralized in nature, not just in name. Most protocols start off centralized and desire to decentralize over time. Unfortunately, that transition is very hard to accomplish. Sometimes it's hard because the protocol team doesn’t want to give up control, but a lot of the time it's because the community needs to be built up to take on that huge responsibility! If you start decentralizing too late, the existing community may be so accustomed to centralized leadership that the move to decentralization is an extremely difficult challenge. Launching in a decentralized fashion from the start is hard and messy and uncomfortable, but it sets the tone for the rest of the network’s life. With their protocol and launch design choices, the NEAR team is making it clear they want to get out of the way and empower the community to make decisions, big and small, on behalf of the network.

Why did the community and the protocol benefit by having mainnet launch criteria before transactions were enabled?

Typically the protocol team decides their own criteria to guide when they launch their mainnet. These decisions are then communicated out to the community, which follows the team’s guidance on infrastructure setup, timing, process, etc. In this case, however, each validator determined on their own when they thought the network should launch. This is a huge change and a huge responsibility, and, as we were thinking internally about how to make our own decisions, we realized it would benefit both Bison Trails and the whole NEAR community to open source our decision-making criteria. Community feedback would improve these criteria, so we’d benefit as Bison Trails, and the community would benefit by having this discussion and possibly improving their own decision-making process.

How did you determine the initial set of criteria proposed to the community? What was the process for determining the criteria?

Bison Trails has helped many protocols launch and we’ve seen a whole lot of different processes and their outcomes, from flawless launches to those requiring do-overs. We wanted to bring our experience to bear and show what a best-in-class protocol launch could look like. NEAR always strives to learn from others and to do the best job, and we wanted to keep this tradition going!

Launching a network is, in a way, very similar to planning any major event. There are a few big things you absolutely must get right, but it’s the small details that separate a good event from a great one. Coming up with basic criteria such as having a stable network was straightforward, but we wanted to capture the non-essential bits that are not strictly required but really should be done to ensure the network launch is a success for all participants. There is a proverb that says “if you want to go fast, you should go alone, but if you want to go far, you should go together.” A protocol is less about the technology and more about the community, so it was important this launch was inclusive and accessible.

We also reached out to other protocol teams that we believe had best in class launches, and asked for their advice on what they think they did well and what they feel they could have done better.

The keystone of a decentralized protocol is that it is decentralized in nature, not just in name.

Can you walk us through the final community-determined criteria? Tell us about the benefit and reasoning of the various criteria proposed.

We ranked the criteria in order of importance, not only based on ensuring a best in class launch, but also to capture the components unique to NEAR’s launch (i.e., true decentralization at launch).

Infrastructure

• There is a sufficient number of nodes (30+) running the network

• There is a sufficient amount of stake (115m NEAR, out of the 750 available for staking) online

• No more than 10% of nodes on the mainnet network have been down at the same time over the last two weeks

The Infrastructure category focused on ensuring validation infrastructure was sufficiently stable and decentralized. NEAR planned for the network to be decentralized at launch so our criteria reflected that desire. Most networks may not need or want to have a large number of validators, or a large portion of stake online and participating (while not earning inflationary rewards), but we thought it was important for NEAR to have it to further decentralization.

Network Stability

• The mainnet network has not fallen out of sync, needed to be rebooted, or was unable to finalize blocks in the last two weeks

• All P3 or higher (or equivalent, if P classification not used) bugs are closed

• Any ongoing audit is sufficiently completed, and if critical or major bugs are discovered, they are resolved

• A recovery plan is in-place that describes the process for reverting back to a known good software configuration and network state in case an upgrade fails, either by corrupting state or failing to start. (Courtesy of @adrianbrink)

Network Stability ensures a protocol is fully baked and ready to see the light of day. With these criteria, we wanted to be sure the network as a whole was stable (which is different from validator performance), any final bugs were squashed, and, if there was an issue, the network could recover from it.

Upgrades

• There is a defined and tested process by which network upgrades are performed

• The last 2 upgrades have been performed without issues

• There is a plan in place for the upgrade to enable inflation, including a dry run. Dry run can be performed by NEAR team since inflation is already enabled on testnet - NEAR team should provide an update on the dry run’s success as soon as possible.

Upgrades are incredibly important for a protocol and cannot be done haphazardly. Having an established and tested process that consistently works without issue is crucial for network stability and community trust in the protocol. I’m also a big believer in testing everything, so when we were discussing the inflation upgrade, I asked the NEAR team to conduct a dry run and to release the results before we attempted the upgrade on mainnet. Inflation had been active since genesis on testnet, which is where this testing would normally occur, so extra testing before upgrading and enabling it on mainnet was important.

Security

• Security program is in place to report bugs and vulnerabilities

It is common to find bugs, vulnerabilities, and edge cases in any new tech, but especially in recently launched decentralized protocols. Having a defined policy for how these issues can be safely reported so they can be patched without being exploited protects the protocol and its users.

Token Holders

• Token holders received information on their staking and participation options (DIY, infrastructure providers, custody, etc.)

Wallets and Stake Management

• There are 2 or more options by which token holders can manage their tokens

• A custody provider (e.g. Coinbase Custody) is ready

These categories tackle the ability for token holders to safely and comfortably participate in the protocol by performing the most basic functions of a PoS protocol - claiming, holding, and staking. NEAR has many thousands of token holders from their private and community sales. All these folks have different needs, familiarity with blockchains, and levels of technical expertise. While a protocol can launch with only basic CLI support, we think it’s important that the infrastructure exists to support all types of users from non-technical enthusiasts to large venture funds.

Foundation

• The NEAR Foundation is fully established and has all necessary positions appointed

• Communications

• Comms plan is in place to alert the NEAR ecosystem of upcoming votes and upgrades

The final two requirements were for the NEAR team. It’s easy to discount the operational overhead required to build and lead a decentralized protocol, but ensuring that the foundation is ready and the team is able to effectively communicate with the community is key.

How did you engage the community to socialize the criteria and get feedback? What kind of feedback did the community provide?

The first thing we did was solicit feedback from the NEAR team on the criteria. They were not the final arbiters or decision makers on the criteria, but their input was invaluable in identifying the right criteria and setting the bar (e.g., why require 30 nodes as opposed to 20?).

After that initial feedback, our goal was to conduct as much of the discussion in public as possible. First, I shared the criteria as a NEAR Enhancement Proposal in the NEAR Github and asked the community via email, Telegram, and Discord to provide their feedback. I then spoke at the first NEAR community town hall on September 28th to tell community members about the Phase 2 launch process and the criteria we put forward for community feedback. Afterwards, I hosted two community calls that were attended by about 20 community members each, on September 30th and October 2nd. These calls were held on different days and at different times to accommodate the global nature of the NEAR community.

Throughout this time, the most important thing to me was to engage folks. A few things went particularly well. First of all, other validators led the charge in providing invaluable feedback on the criteria and posting their own, such as Adrian from Cryptium Labs, Ernesto from Astro-Stakers, Henry of OpenShards, Chorus One, and Gaia. They improved the community criteria and engaged with the community and other stakeholders on how to best make this decision. Second, engagement was very high. There was a lot of community buy-in -- not just on voting yes, but voting yes for the right reasons and being intentional about it.

What happened with the community vote that was initiated before the criteria was finalized?

The NEAR team really did leave everything up to the community, for better or worse. The vote to enable transfers was initiated not only before any criteria were discussed, but even before any tokens were distributed! This early introduction was unfortunate in some ways because several validators voted to unlock transfers right away, long before the network or community was ready for it. On the other hand, it really lit a fire under the community to figure out the criteria and launch the network.

Any challenges or surprises that you didn’t expect during the process?

One of the hardest parts was knowing when to lead and when to get out of the way. I was doing this work in service of the NEAR protocol and community, to help ensure a successful mainnet launch. There is a natural desire to drive the conversation, engage folks, get buy-in, and otherwise build consensus. But I know that is the exact moment when it’s important to step back and leave room for other people to own the process, express their opinions, engage on their own terms, and come to their own conclusions. My goal was not “get the community to accept and use my criteria” but “share the criteria, empower folks, and get out of the way.”

How universally applicable is this criteria? Would it be useful for other protocol communities considering launching their mainnet?

Absolutely. Most people only ever launch a single protocol and it's hard to know how to do it - there’s no guides or books written on the process! These categories and criteria can be customized per protocol and should be used to help each team have a best in class launch. This criteria builds on the collective wisdom of many protocol teams, validators, and community members; it is an ideal starting point for future protocol launches.

Anything else you’d like to share about this process?

I encourage anyone who’s striving to build a decentralized system or protocol to practice decentralization early and often. It’s not enough to decentralize in name only. Giving up power and control over the most important decisions is true decentralization. This launch was not perfect - it was messy, disorganized, and, at times, contentious. But, it was exactly as it should have been, because perfection is the price you pay for empowering the community rather than operating as a centralized decision making body.

—Interview by Mark Forscher