GCR

This is inspired by the writing of Vitalik with some of his excerpts. I urge you all to read the original article to understand his logic. It will help you form a mental framework around how to think about decentralization.

Definition of Decentralization

Vitalik categorizes the definition of protocol decentralization into 3 components. He is a very articulate writer so I have here his points listed verbatim:

• Fault tolerance: decentralized systems are less likely to fail accidentally because they rely on many separate components that are not likely.
• Attack resistance: decentralized systems are more expensive to attack and destroy or manipulate because they lack sensitive central points that can be attacked at much lower cost than the economic size of the surrounding system.
• Collusion resistance: it is much harder for participants in decentralized systems to collude to act in ways that benefit them at the expense of other participants, whereas the leaderships of corporations and governments collude in ways that benefit themselves but harm less well-coordinated citizens, customers, employees and the general public all the time.

Fault Tolerance Assessment

On the fault tolerance front, the most problematic issue arises from common mode failure. Common mode failure means that all the failures come from one single shared source. So here are areas to focus on and potential risks when common mode failure arises:

• Assess the team: issue arises when all nodes in a blockchain run the same client software, and the development team of this software turns out to be socially corrupted.
• Assess the blockchain’s underlying technology and the blockchain stability: an issue arises when all nodes in a blockchain run the same client software, and this client software turns out to have a bug.
• Assess how the members are incentivized and scrutinize upgrades and their consensus method: issue arises when the research team that is proposing protocol upgrades turns out to be socially corrupted.
• Assess country and governments’ involvement and their outlook and attitude on the industry: issue arises when in a proof of work blockchain, 70% of miners are in the same country, and the government of this country decides to seize all mining farms for national security purposes.
• Assess the hardware platform in which the technology is built on: issue arises when the majority of mining hardware is built by the same company, and this company gets bribed or coerced into implementing a backdoor that allows this hardware to be shut down at will.
• Assess a possible concentrated exchange risk. The best thing for the protocol team to do is to work with exchange in advance of ICO. In a proof of stake blockchain, 70% of the coins at stake are held at one exchange.

A holistic view of fault tolerance decentralization would look at all of these aspects, and see how they can be minimized. Per Vitalik’s words below, some natural conclusions that arise are fairly obvious:

• It is crucially important to have multiple competing implementations.
• The knowledge of the technical considerations behind protocol upgradesmust be democratized, so that more people can feel comfortable participating in research discussions and criticizing protocol changes that are clearly bad.
• Core developers and researchers should be employed by multiplecompanies or organizations (or, alternatively, many of them can be volunteers).
• Mining algorithms should be designed in a way that minimizes the risk of centralization
• Ideally, we use proof of stake to move away from hardware centralization risk entirely (though we should also be cautious of new risks that pop up due to proof of stake).

Attack resistance

• Assess how consensus occurs in the protocol: Vitalik pushes strongly in favor of proof of stake over proof of work, as computer hardware is easy to detect, regulate, or attack, whereas coins can be much more easily hidden (proof of stake also has strong attack resistance for other reasons).
• Assess on where the teams are geographically located and distributed. In case an attack happens in one region of the world, would be another group of people who are able to take over easily?
• Assess how the economic incentives make the fault tolerance structure model more robust

Collusion resistance

I love when Vitalik describes that “Collusion is difficult to define; perhaps the only truly valid way to put it is to simply say that collusion is “coordination that we don’t like”.” Ways to assess whether protocol is collusion resistant:

• Assess how the mass protocol users are incentivized to prevent collusion. Out of all the groups of participants in the protocol, the most decentralized group would be the users, and protocols should be empowering that first and foremost
• Assess how the protocol incentivizes members to coordinate in a positive way
• Assess how the protocol prevents undesired coordination. Ways members can react and shut down undesired events: Don’t bother mitigating undesired coordination; instead, try to build protocols that can resist it.
• Assess how to construct protocols to encourage beneficial coordination and discourage harmful coordination. Try to make a distinction between beneficial coordination and harmful coordination, and make the former easier and the latter harder.

Per Vitalik, the third is a social challenge more than anything else; his proposed solutions in this regard include:

• Social interventions that try to increase participants’ loyalty to the community around the blockchain as a whole and substitute or discourage the possibility of the players on one side of a market becoming directly loyal to each other.
• Promoting communication between different “sides of the market” in the same context, so as to reduce the possibility that either validators or developers or miners begin to see themselves as a “class” that must coordinate to defend their interests against other classes.
• Designing the protocol in such a way as to reduce the incentive for validators/miners to engage in one-to-one “special relationships”, centralized relay networks and other similar super-protocol mechanisms.
• Clear norms about what the fundamental properties that the protocol is supposed to have, and what kinds of things should not be done, or at least should be done only under very extreme circumstances.

These are the list of criteria for myself to assess whitepapers. Vitalik’s work is definitely a good start. Will be adding more to this as I read more great writing on medium!