One of PegNet’s selling points is decentralization — officially there is nobody in charge of PegNet. It works as long as the people using it agrees to play by the same rules, which at the moment is done by everyone using the same software: pegnetd. As a core developer for pegnetd, one of the first questions I ask myself before considering a new feature is: how will the community react to this?
That immediately raises another question: Who exactly is the “PegNet” community and can we determine who the majority is? The obvious answer is that it’s a combination of all the people using it: members on discord, core developers, exchanges, miners, etc., however, it’s not feasible to quantify a majority from that and reaching any kind of consensus among a multitude of communication channels is practically impossible. There is one way that lets us quantify a majority: Proof of Work (PoW).
Whoever controls 51% or more of hashpower effectively controls PegNet’s economy, which is the very nature of PoW chains. If the PegNet community accepts these values, everything is fine. If more than 51% of hashpower is controlled by a community-minority that acts against the interests of the community-majority, the community-majority can fork. If that happens, both forks are once again controlled by the majority of its community. We can, therefore, assume that in the long run, the entities that control more than 51% of hashpower are representative of the community.
Consensus Algorithm
We can easily tap into the OPR format to store additional information, letting miners signal their intent. For the rest of the article, I will be referring to this as a vote.
A technical difficulty of PegNet is that not all submissions are shared, only those above threshold determined automatically by miners. If all miners submit every OPR they calculate, it would be as easy as taking a count and seeing if a majority of them have agreed on the same vote. However, miners only share OPRs that they think have a shot of winning, so every block there are likely to be some miners that do not submit any shares. This means we can’t rely on a single sample to judge the results but have to look at the average over N sequential blocks.
This chart was made using a small simulator that acts like a PegNet grader. Each block, 100,000 “yay” votes and 100,000 “nay” votes were assigned a random proof of work score. The top 50 entries were then selected of the pool, the count of yes votes is shown as the blue bars. There is a lot of variance from block to block, with some having 70 yay votes, some only 35. This is reflected in the Simple Moving Average of 1 block (SMA-1), which is the same as the block count. Since we know the actual distribution of yay-to-nay votes (50%), these results are clearly not accurate. SMA-6 (a one hour window) is closer but still jumps away from the target by +/- 5%. The one day window (SMA-144) is fairly close to the real average, though it is not perfect. It is consistently within roughly half a percent of the real value.
Just how representative is the vote? Using the probability math from my previous blog, we know that the expected entries of a single miner are 50 * Hashrate / Total Hashrate per block. If our target is at least one entry every 144 blocks (0.00694...), we end up with a minimum representation of 1/7,200th the total hashrate.
At the time of writing, the PegNet Network has an estimated 1.4 gigahash. One 7,200th of that is roughly 200,000 h/s. Anyone who is in control of a miner force exceeding that can expect that at least one of their votes will impact the average, though very little.
Note: The source code of the app used to generate the dataset used for the chart above can be found here: https://github.com/WhoSoup/pegnet-consensus-math if you want to verify the methodology yourself.
Voting Process Example
With the math out of the way, we can take a look at how the voting process plays out. It starts with someone proposing a vote, whether that happens on-chain or off-chain is not important. For the sake of an example, let’s use the question: “Do you like PegNet?” Every miner that likes PegNet should include the string “vote-pegnet-001-yes” in their OPR. As a target, I’m going to declare that the vote is successful if at least 50% of the miners have the answer for a period of 6 blocks.
The next step would be informing the community, which would be manual since the vote is created off chain. This involves reaching out to discord and the mining pools, asking them to include their vote. After that, I start to monitor the PegNet chain using the census tool. How long this runs for is up the miners but using SMA-144, it’s unlikely for a vote to conclude in less than a full day. If the vote is successful, I now have on-chain proof that can be audited.
To summarize, a vote will need: A specific keyword or pre-determined format to include in the OPR A target percentage of miners * A range of how many blocks the percentage has to be met in order for it to count
Potential Implementations
As I mentioned before, this is just the foundation for processes to build on top of. One such process I will detail in a future blog is the automatic addition of new assets or removal of existing assets. The voting process can be used to programmatically decide when a new asset is required instead of requiring a hard fork where all miners and pegnetd operators have to update their codebase.
Anything that affects the behavior of the miners and pegnetd nodes would require them to be implemented in code first but these votes could be significant for a lot of informal decisions. Significant choices like the PEG conversion limit or one way FCT conversions could be voted on by the community. Community interest in pursuing a specific goal can be gauged on-chain. This would have the added effect of giving mining value beyond providing oracle data, incentivizing community members to start mining so that their input is taken into account.
Originally published at https://factomize.com on January 15, 2020.
