Architectural (de)centralization — how many physical computers is a system made up of? How many of those computers can it tolerate breaking down at any single time?

Political (de)centralization — how many individuals or organizations ultimately control the computers that the system is made up of?

Logical (de)centralization— does the interface and data structures that the system presents and maintains look more like a single monolithic object, or an amorphous swarm? One simple heuristic is: if you cut the system in half, including both providers and users, will both halves continue to fully operate as independent units?

Architectural centralization often leads to political centralization, though not necessarily — in a formal democracy, politicians meet and hold votes in some physical governance chamber, but the maintainers of this chamber do not end up deriving any substantial amount of power over decision-making as a result.

Fault tolerance — decentralized systems are less likely to fail accidentally because they rely on many separate components that are not likely to fail

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

It is crucially important to have multiple competing implementations.

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).

If any one actor gets more than 1/3 of the mining power in a proof of work system, they can gain outsized profits by selfish-mining.