Voting Challenge Proposal
This proposal is intended to be a community lead effort to move the IC in the direction of decentralization on the Replica Version Management NNS proposal topic. It proposes crowdfunding for bounties to pay people and organizations to formally review Bless Replica Version proposal types. It is intended to attract and recognize people in the community who perform quality work on these code reviews. The program would be administered by the proposal lead, Wenzel Bartlett, and is intended to scale if proven successful. Please consider making donations to fund this program (see Crowd Fund section at the end). Formal progress reports and as well as proof of each code review will be submitted via NNS Governance Motion proposals each week. This program does not require any changes by DFINITY to the current process for issuing and voting on these proposal topics, nor does it require any changes to tokenomics to incentivize participation. The program can be a successful example of decentralization if adequate donations are received each week to attract reviewers.
There has been recent activity in the community from individuals (see Resources section) who have considered performing technical reviews of Replica Version Management proposal topics (for example, proposal 100821 submitted today). These reviews are arguably the most important opportunity at this time that can advance the decentralization of the internet computer. However, performing these reviews properly is real work which likely will not happen consistently unless there are incentives. Genesis occurred 20 months ago and there are many well-known organizations and many ICP whales, but none have formed named neurons that people can follow and none are publicly contributing to the development or review of the IC protocol. Hence, people and organizations with natural incentives (e.g. large stakes and/or major projects) to make meaningful contributions to the decentralization of the IC don’t seem to be contributing at the protocol level. We all depend on DFINITY, which most people will readily admit is not very decentralized. However, everyone, including DFINITY, likely agrees that we need to be on a path toward decentralization that will take many years. Community code contributions need to start somewhere. Therefore, I want to start an initiative to help catalyze change that enables developers of all skill levels to receive public recognition for demonstrating their technical skills in a way the benefits decentralization of the IC. Specifically, I want to administer and scale a program designed to crowdfund bounties that will be paid to people who provide quality technical reviews of the Bless Replica Version proposal type, which falls under the new proposal topics called Replica Version Management. It won’t be a perfect system initially, but perhaps it is a good start that can evolve into something better. The goal is decentralization and developer recognition.
In my opinion, success is the identification of people or organizations who are willing to routinely perform technical reviews for proposals that are submitted weekly in the Replica Version Management proposal topic. This topic was created 4 months ago (proposed by @Manu and implemented by DFINITY) in order to separate the Bless Replica Version and the Retire Replica Version proposal types from more frequent proposals. This provides an opportunity to engage the community in replica reviews without an overwhelming workload. The path to decentralization requires that people and organizations that perform these reviews are committed to doing it often enough and reliably enough that they can be selected as Followees by NNS participants for this proposal topic. In other words, if we want decentralization, then we need Followee options that don’t exist today. At this time, this proposal topic falls into the All Topics catch all category, which means most existing neurons were configured to follow DFINITY when the neuron was created and there has never been a reason for people to change that selection. Natural incentives have not been enough so far, so perhaps supplemental incentives can result in people and organizations that make a commitment to becoming a reliable reviewer.
The minimum definition of success is public recognition of developers who can perform this task (perhaps it will lead to job opportunities). The desired outcome is for more than 3% of total voting power in the NNS to choose to follow neurons other than DFINITY on the Replica Version Management proposal topic. A stretch goal is for 5-25% of total voting power in the NNS to follow neurons other than DFINITY on the Replica Version Management proposal topic. The exact number is somewhat arbitrary. However, it can be considered a simple measurement of the extent of decentralization on this topic. These Followee changes are 100% voluntary, low risk to the ecosystem, and will be a slow, yet high value, transition toward decentralization.
Please note that 100% of total voting power in the NNS currently follows DFINITY on this proposal topic due to default following. DFINITY directly owns 23% of this total voting power. Hence, there is no risk of the community getting it wrong by participating in these reviews and making these changes to their Followee selection. DFINITY is still able to cast their vote just like they have in the past and it will still initiate Absolute Majority even if a major fraction of NNS participants change their Followees. It would require 50% of total voting power in the NNS to change their Followee in order to introduce a risk of getting it wrong and they would all have to vote opposite DFINITY. We don’t have that much total participation on the Governance proposal topic, which is the most decentralized proposal topic so far, so getting it wrong is truly a non-issue.
Also note that DFINITY can still vote any time they want (e.g. critical updates) and people can still get their voting rewards even if they are not following DFINITY. Proposals are executed by Absolute Majority immediately after more than 50% of total voting power is cast as either Yes or No, but that does not end the voting period. The voting period stays open for at least 4 days on every proposal. Hence, if DFINITY casts their vote 2 hours after submitting a proposal and a notable fraction of the NNS voting body is following someone else, everyone will still vote when their Followee votes. The votes won’t change the result, but the vote does count toward voting rewards. The key is for NNS participants to select Followees who are known to be reliable at always voting, which means we need to provide public opportunities and incentives for people to prove their reliability on this topic.
Every week, the Administrator will submit a NNS Governance Motion proposal titled Voting Challenge Status Update and Crowd Fund Request. This proposal will be submitted on Friday or Saturday and will outline 1) the bounty and percent allocation that is available, 2) the specific proposal ID that is offered for bounty review, 3) an updated explanation of the Voting Challenge for the week, 4) the bounty distribution details for the past week, and 5) a summary of the successful and unsuccessful reviewers for the past week.
Every week, people and organizations who want to perform replica reviews and get paid for this work will submit individual NNS Governance Motion proposals that demonstrate the results of their review. These motion proposals must be submitted to the NNS before the end of the Voting Period for the proposal that they are reviewing. In order to qualify, each proposal must include all details outlined in the Review Requirements section below. Since this review will be submitted as a motion proposal, the NNS governing body will decide if the review that is submitted passes quality inspection based on the Accept / Reject status. Each individual / organization may submit one review. All proposals that are accepted by the NNS will be paid from the available bounty. There is a good probability that the NNS governing body will be somewhat lenient in the beginning but may develop high expectations as the Voting Challenge continues and examples of quality work are produced by reviewers. It would be ideal if the bounty were significant enough to attract talent and to give reviewers an opportunity to hone and show off their skills in a formal way.
Requirements for Review (submitted as NNS motion proposal)
- Reviewer name (an anonymous identity is acceptable)
- Reviewer NNS voting neuron ID (this can be different than the neuron ID that is used to submit the proposal and will be used to verify the vote was cast)
- Reviewer account ID (the account that will get paid from the bounty if the proposal is Approved)
- Reviewer social media username (so unknown anonymous identities can be validated)
- Link to social media post showing proposal id and review conclusions (part of validation)
- Proposal ID (corresponding to the proposal that is being reviewed)
- Replica Version ID (corresponding to the proposal that is being reviewed)
- Release Package sha256 hex result
- Computer screen capture showing sha256 function command, the hex result, a unique computer ID, and the computer date/time (proof of performing work)
- Review Summary (outline of findings from the review)
- Review Methodology (describe how the review was performed)
- Anything else that you want to submit that you believe helps give you credibility to the NNS governing body as a reviewer.
The requirements as written can possibly be gamed, so additional suggestions to help minimize that potential are welcome. The requirements can be modified to include anything reasonable that uses existing, common infrastructure for both the user and the NNS. In other words, it is not in scope to immediately develop new tools to prove this review work was performed by unique individuals/organizations. This will start as an experiment. We will learn and improve as we go including potentially developing new tools.
The NNS will be used because it offers a formalization of the process that brings heightened awareness to NNS participants. Governance motion proposals do not change code. However, all proposals that are proposed in this Voting Challenge are about IC code and the formalization of a review process intended to engage the community and improve decentralization.
Below is an example of how the bounty that is raised through crowd funding could be distributed. This example assumes 1000 ICP is raised for bounties and the fiat price is $4/ICP. It is not known how much funding will be raised, so these numbers are only examples and will be adjusted on a weekly basis to match actual donations.
- Proposal Reject Fee for Status Updates: Fixed Cost = 10 ICP = $40
- Voting Challenge Administration: 15% = 148.5 ICP = $594
- Voting Challenge Bounty: 85% = 841.5 ICP = $3366
The Voting Challenge Administration allocation would be used to 1) pay the administrator for services, 2) potentially form a legal entity such as a non-profit 501(c)(3) to enable tax deductions for donations, and 3) build capital to potentially pay for developer services that may be needed to build software tools that support the Voting Challenge program. I am proposing myself (Wenzel Bartlett) to be the Administrator.
The Voting Challenge Bounty will be divided among all reviewers who receive Approval of their review by the NNS. Goals, deliverables, work process, and fund distribution may be adjusted as the program progresses. This will start as one specific bounty for one specific proposal each week but will scale if crowd funding levels and review participation is successful. If there are no reviews for a given week, then the Voting Challenge Bounty portion will carry over to the following week and will be added to any new bounty that is crowd funded. If the weekly Status Update proposal submitted by the Administrator is rejected, or a Voting Challenge Bounty cannot be raised, then that will be taken as a sign that the NNS governing body is not interested in continuing this Voting Challenge program.
Here are many examples of manual code reviews: Voting Challenge portal on DSCVR by @bjoern
Here is an example of code review automation: Taggr discussion by @christian
Here is a potential example of team review: Forum Discussion by @lastmjs
@bjoernek @diegop @Jan @dominicwilliams @lomesh @paulyoung
sayitkind on Twitter and Reddit; BartlettWenzel on Telegram; wpb on the forum, Taggr, DSCVR, and Distrikt
IC ecosystem credentials: Manager for Synapse.vote neuron; Founder for CrowdGov.org website
Neuron ID: 12008772471346176261 (same neuron I have used many times to submit proposals)
Account ID: 10517e297382fd13abf9a1d05ab35b67a6875e26462d881d87418206094e4b84
Donations are non-refundable and will be used to support this Voting Challenge. Weekly crowd funding is proposed in order to start small and only scale if the program proves to be successful.