User Tools

Site Tools


Decentralized Security

How to maintain order in a decentralized network?

Imagine a decentralized communications system or video game where there is no central server, but each participant is an equal.

  • Advantage: The system could survive a component of it going down. If the company that built the network went out of business and downed its main server, the product would survive.
  • Disadvantage: The system would be extremely vulnerable to hacking. A modified node could send false communications to other nodes, disrupting the purpose of the network.

Decentralized Network examples

Examples of decentralized networks:


We have Usenet; spammers destroyed it and pranksters were often forging messages in others' names and orders to delete popular communications forums.


We have BGP; administrator errors regularly down networks and the system's reliability depends on the average Internet user not having the authority to make changes to it.


The Hacking Problem

The nodes can send messages that have an effect on other nodes. The nodes are supposed to follow agreeable rules to determine what messages are sent under what conditions, but the rules on any one node may be changed by its operator.

In order to guarantee the proper operation of the network, there needs to be a means for nodes to recognize and ignore illegal messages.

Insecurable Ruleset

The ruleset is not secureable.

Any attempt to secure the ruleset is doomed to failure. Obfuscated code can be deciphered, and an emulator could be produced. Resolutions must be based on the contents of the messages alone.

Spoofable Identities

Identity may be spoofed. An emulator can claim to be anybody. Without a central authentication database, how is the identity of a message sender to be confirmed by other nodes?

Falsified State

State may be falsified. A gamer may give himself extra hit points and ammunition and refuse to die when his HP go below zero.

Potential Resolutions

Full Disclosure

A node may announce its state to other nodes so that they may confirm that a future change in its state is according to the rules.

This will wreck any games that depend upon the player not knowing this information, since a hacked client can give a player an unfair advantage.

Majority Rule

This resolution requires that all messages be broadcast to a number of local nodes, and that it not be possible for messages to be directed to a single node.

This resolution will fail if there are only two nodes in a communication.

This resolution will fail if there is a malicious group.

Trust Lists

The user of a node may mark other nodes as trustworthy or blocked. Only messages from trusted nodes will be respected in a whitelist system; or, messages from blocked nodes will be ignored in a blacklist system.

The whitelist system will fail if messages can be spoofed, in which case there are bigger problems. The blacklist system will fail if the hostile origin can change its identity to get around the block.

decentralized_security.txt ยท Last modified: 2013/11/30 16:18 by deltatango