Collective decisions

Goal

• Reach consensus: What is the most frequent color?
• Scalability: Robots can be added to the swarm at any time (to increase accuracy, size of the explored area, speed up process)
• Trustlessness: The swarm members are untrusted (you don't have to know which organization or person a robot belongs to; you don't have to know if a robot sends right or wrong information, you don't have to identify a robot)

Problems

• Noise
• Asynchronicity
• Stochasticity
• Absence of global information/trusted third parties
• AND malicious intruders/failing sensors (Byzantine robots)

Approach

• Define initial swarm (e.g., 10 trusted members)
• Each robot has initial opinion (one of the colors)
• Robots move arbitrarily in the area
• Robots have three functions: (1) sense color, (2) disseminate most frequent color, (3) receive color opinions from peers

FAQ

• Q: Why would the robots keep the blockchain running?
  • While the incentive to keep the blockchain running among human participants is getting new valuable tokens and guaranteeing the security of existing tokens, the incentive in a blockchain based on robotic participants is more indirect:
    • the robots perform a mission that is useful for someone (probably the initiators of the mission)
    • the robots belong to a person or organization that benefits from the token

Therefore, we can assume that at least some of the robots are programmed to do the right thing and follow the blockchain protocol (state update via generation of valid blocks). In the end, no matter which algorithm you are using, no robot will care if it is dead or alive except if it is programmed to do so.

• Q: Why don't you use an authentification system to include trusted members only?
  • A classical authentification system can be easily compromised (e.g., once the password is revealed, the entire system breaks down)
  • The swarm is more flexible without an authentification system: everyone can join at any time