What it Took to Fork

The Peercoin network successfully completed a hard fork to v0.12 Ladybug last night, finally attaining the 90% on-chain consensus required to activate the fork.  This monumental feat took far longer than originally anticipated, and included lots of lessons learned along the way.

To start, we should have some abstract understanding of the Peercoin consensus process.  This is a Proof of Stake blockchain security driven by collective custodianship of a transaction protocol.  Peercoins contribute directly to security when minted, so we can think about the dynamics of the network mostly without including concepts of global macroeconomics.  This allows us to discuss concretely fractions of the supply involved in the process.  For example, only about 20-25% of coins participate at all in the minting process, and only around 10-15% do it regularly and efficiently.

A protocol fork is a matter of security versus flexibility of code.  If a small party could fundamentally change the rules of the blockchain, it could make things very confusing until a large economic majority either reverted the fork or killed the coin entirely.  That said, the same could be true for a chain that refuses to adopt a critical update: the economic majority could punish it.  However, the crypto economy is far from frictionless, and oft times the actions of the price seem to have little to do with on-chain development.  As such, we strive to attain a high level of consensus to ensure our path is well-oriented.

Any coinholder may begin minting and block consensus on the fork.  This became painfully obvious as we proceeded to do calculations on how difficult it would be to override minters who are simply unattentive to the upgrade.  As in, these are not people who voiced any objection to the fork, and likely were not aware of the fork's existence at all.  Possibly still are not, even as their client drops off the now-forked network.  To understand the influence these essentially "abstaining" votes had, let's do a quick calculation (nothing too heavy, i promise).

Say 20 coins are minting on v0.11, and 80 are minting on v0.12.  This is an 80% acceptance rate.  Now imagine we ask how many more coins do we need on v0.12 to get to 90%?  The answer is somewhat unintuitively 100 coins, more than double the number of coins minting on v0.12!  This is because at 90% with 20 coins abstaining, we need 180 coins to pass the fork.  A large weight of minters is needed to overcome a small blocking minority, and it is a wonder that v0.12 was able to attain that level of consensus.

The v0.12 fork was not controversial amongst minters.  It contained some ported bitcoin updates, as well as a bit of code to have PoW blocks update their difficulty on PoS blocks.  These changes were fairly vanilla in their forseen consequences, mostly just adding capability or helping stabilize the chain more.  There were of course discussions, but not to the level of blocked consensus.  That the fork stalled out around 85% acceptance with no direct discussion seemed like it wasn't about real objections to the fork at all, rather just people not paying attention to the update.

At the end of the day, it was not 1 million new coins entering the network for v0.12 that passed the fork.  Rather, it was ~100k coins that stopped voting for v0.11.  There were a series of proposals for how we might help this situation in the future, several of which are or will be implemented.  One example is a banner in the core client that states when a new fork is detected.  This is not a new idea, and has been resisted in the past due to anarchaic concepts of self-reliance.  However, in the present atmosphere of weak subjectivity it could greatly improve coordination amongst actors.

As the fork dragged on, many people started trying to ban nodes minting v0.11.  This, of course, had very little effect.  If even one node propagates blocks from v0.11 to v0.12, then this tactic becomes useless because Peercoin hashing is not as time-sensitive as PoW.  There were more advanced proposals of a similar variety on the table, for example one that has a lower threshold at which v0.12 nodes would start rejecting v0.11 nodes, but would not put out any blocks that kicked v0.11 nodes entirely off the network.  The general response to this proposal was mixed, with some thinking that if we set a lower threshold we may as well just set a lower threshold for everything.  For the next fork, the dev team will likely use a threshold lower than 90% to soften some of these issues.

There was also a point during the forking process where social concepts of disagreement came into play.  These happened mostly in the background, but there were on-chain effects that could be seen.  None of these disagreements lasted anywhere near as long as simply waiting for everyone to be aware and update their client.  The key leverage that the network has in any of these kinds of disagreements is that these forks are simultaneously important for the future of the coin, but not critical in the short term.  Essentially, Peercoin can wait forever for humans to approve of its new capabilities, it's no skin off Peercoin's eternal back.  Human disagreements are important to resolve, but the timescale of human anger is not long enough to permanently stymie Peercoin's progress.

In the Peercoin network everyone is motivated to work together.  Social issues with consensus seem to still be far less of an issue with this coin than the technicality of update.  Forking is a fundamentally existential concept because it is a question of governance, and the consensus threshold is at the heart of what we deem high quality consensus.  We, as a community, should set the bar for what we consider a necessary due-diligence consensus threshold, which is then ratified by developers and ultimately minters in the next fork process.  We should have deep discussions in the wake of this fork about what number is an appropriate threshold.  70%?  75%?  80%  this number should not be arbitrary, and we should discuss the implication of what we choose going forward.

The Peercoin protocol is iterative at heart, allowing for the evolution and education of the people that implement it.  Its governance comes from many organizational aspects and the forking process hopefully embodies a harmony between these governance modes.  It is not just a supermajority of minters, it is the community, the team, the developers, the markets, and the blockchain tools.  A smooth fork has all these pieces moving in tandem, and builds confidence in the capability of the system to adapt and move in unison.  We should be proud of this fork, and learn its lessons in stride.