Wisdom of the Crowd as a Consensus Mechanism

A new approach to scaling a more energy-friendly blockchain?


Bitcoin, scaling and CAP Theorem

CAP Theorem (Image taken from hazelcast.com)
CAP Theorem (Image taken from hazelcast.com)

“So, wait, are you saying Bitcoin is inconsistent?

The problem with consensus through Proof-of-Work

To compensate for increasing hardware speed and varying interest in running nodes over time,  the proof-of-work difficulty is determined by a moving average targeting an average number of blocks per hour. If they’re generated too fast, the difficulty increases.
From the original Bitcoin whitepaper. This ‘average number of blocks’ is ~6 per hour; roughly one every ten minutes.

Possible alternatives

Basic ingredients of an alternative consensus mechanism

Look, I even made a logo. Because, why not?

The hypothesis

Wisdom of the Nodes

Transaction consensus

Providing incentive

Overview of the degrees and block rewards

Dealing with collusion

Node selection

Dealing with transaction malleability

Overview of a WoC-based blockchain — with the process of initiating the next block addition on the right

So how does this provide protection?

Dealing with Sybil Attacks

Verifying Trust — With apologies for the extraneous emoji’s

Dealing with failure & corruption

Consensus fails, due to node failure (red = corrupted, brown = timed out/offline)

The key: randomization

Possible questions

“So, why bother with all these ‘degrees’? Why not just select 40 random nodes?”

“How will the network cope with this potentially high block-creation speed?”

Notes/thoughts/loose ends

Nodeseed = seed_generator();
eligible_nodes = derivation_protocol(prevBlock.Nodebase + Nodeseed, 80);
selected_nodes = [];
x = 0;
while(selected_nodes.length < 40 && x < 80) {
node = eligible_nodes[x];

while(!node.accepted) {
if (node.accepted) {
x += 1;
} else if (timer > 5000) {
x += 1;


Summary illustration


a.k.a c_kick/hnldesign. Full-stack developer, full-cack designer