On an alternative blockchain consensus architecture

The main idea: enforce network security through social consensus whilst retaining a decentralised architecture.  

0. Posts on this blog are ranked in decreasing order of likeability to myself. This entry was originally posted on 18.12.2025, and the current version may have been updated several times from its original form.

1.1 Let’s strip back as much as we can from the Nakamoto consensus, and re-build from there. 

1.2 We have transacting nodes who store blockchains, and miners who work on existing chains by adding successive blocks, who then must compete for adoption by the nodes. 

1.3 We have, so far, no proof of work, no adoption or consensus rule, no block time, and no block limit. 

1.4 Indeed, suppose for now, that each node is entirely free to pick whichever chain they seem fit. We will narrow this freedom quite a bit in 1.24, but for now assume this is the case.

1.5 The first step to re-establish some order in this chaotic primordial soup is Rule one, every node must publish the hash of the chain it is storing at any time. 

1.6 And then Rule two, two nodes can only transact if they share the exact same such hash at the time of transaction.

1.7 These first two rules already do the heavy lifting in terms of network coordination, and given the massive network effects that dominate money, all honest nodes will have an incentive to stick to the same main chain.

1.8 If we assume for a moment that all honest nodes magically know which is the main chain that all god boys are supposed to flock to, they will. 

1.9 Note then, how even without a algorithmically deterministic rule that forces the adoption of the same chain, we can enforce the same through social consensus. But.

1.10 But in removing a load-bearing requirement such as “adopt the longest chain”, we have left the network wide open to accidental fragmentation, and we must take every precaution to ensure that all honest nodes know which is the main chain they are supposed to hitch onto.

1.11 So, Rule three, we code in a notional genesis time as well as a hard but notional block time of, say two minutes exactly. 

1.12 Every node can derive the exact length of the chain given these two data points using their machine clock, and no honest nodes will ever disagree on the canonical chain length for more than a second or so every two minutes. 

1.13 Time stamps are trivial to forge, but it might be still worth having nodes check that each block in a chain is timestamped according to the two-minute interval, just to make life a tiny bit harder for lazy attackers. 

1.14 Note how there’s nothing backing the block time we chose except algorithmic convention. But note how this forces the entire network to march ahead at the same cadence. 

1.15 So far, we have introduced incentives for all honest blocks to be on the same main chain, and let all honest blocks know how long the chain should be. 

1.16 Assuming that they all start on the same main chain, this means that they somehow all need to jump on the exact same bloc every two minutes. Further, they need to do this based on self-interest. So,

1.17 Rule four, miners can propose any block reward they like to for the blocks they mine, but must burn at least a nominal amount of token to publish a block, though they are free to burn more than this. What you burn is lost regardless of whether your block is adopted, whereas what you propose to gain as rewards only accrue if the network picks your block.

1.18 Now we have made it obvious which among the various blocks competing to be added to the mainchain every two minutes is to be adopted. Though you can adopt whichever block (or indeed chain) you like, you’d be a fool to adopt any except the one that dilutes you the least or, to generalise for what will become useful soon, the block where your UTXO set relative to the total supply on-chain is the greatest.

1.19 Our token’s supply is now market-driven to a degree that should respond to economic incentives and should provide some long-term price stability. Though this is not as good as a fully dynamic supply algorithm (like this, or this), it still should serve fine for a base layer on top of which something more dynamic can be pyramided, be it even on a fractional reserve basis. 

1.20 So, we have a network that incentivises all honest nodes to stick to the same main chain, move the chain forward at the same cadence, agree in a decentralised manner where to jump to, and ignore any attempt to force deep reorganisations. And we have no power-hungry Proof-of-Work, and a market-respondent supply function. So far, so good.  

1.21 Now, we promised in 1.4 that the extreme freedom we were temporarily granted nodes in choosing whichever chain they fancies would be curtailed somewhat. So let’s do some curtailing. 

1.22 For our purposes today, let’s say that blockchain A dominates blockchain B if and only if it contains every transaction found in B, plus at least one more.

1.23 It follows that adopting a chain that dominates ours can never lead to loss of information, and is always a Pareto improvement from the point of view of the switching node. 

1.24 So, Rule five, a node will search for chains during the two-minute interval immediately following the notional adoption of the preceding block (as dictated by their local clock), and only consider chains that dominate theirs and are themselves not dominated by any other chain they are aware of. Of these, they will pick the chain with the highest UTXO/total supply ratio. If chains tie for this spot, the node adopts the one with the lowest leading digit in its hash.

1. 25 Any honest node in this network will now always discover the exact same chain to adopt, and no one will ever have coordination issues…if we assume double spends, propagation delays and network partitions away.

1.26 The issue caused by double spends is that two chains which each contain at least one transaction the other doesn’t cannot dominate one-another. 

1.27 It then follows that, in an environment when double spends circulate and propagation delays exist, domination might lead to path-dependency, and two nodes that see and adopt blocks containing mutually exclusive transactions (spending the same inputs) won’t be able to dominate one-another. Once these nodes diverge, they won’t be able to automatically remerge.

1.28 These issues can only be solved by manual intervention, with one of the nodes choosing to jump into the competing non-dominant chain in the name of ability to trade.

1.29 So, Rule six, nodes can at any time adopt any chain that neither dominates their incumbent chain, nor is dominated by it. No manual adoption of a dominating or dominated chain is allowed.

1.30 This is the iffiest bit of the design, as we do rely on intervention to resolve these relatively common mini-forks.

1.31 In practice, one of the forks will encode the highest UTXO/total supply, by virtue of different miner proposing different rewards, so it stands to reason that nodes might default to adopting any non-dominating chain with a higher UTXO/total supply that only diverges from theirs by one or two blocks. In short, a “I would have adopted this block in the previous window if I had seen it” kind of deal.

1.32 Nodes might be far more guarded against adopting non-dominating chains that diverge from theirs by more than a few blocks though.

1.33 As a direct result of the above, transactions would not be immediately final, but would still require confirmation by a couple of blocks. This window would hopefully be shorter than under Bitcoin, as well as more predictable given our strict block time design.

1.34 The above wouldn’t be a hard rule, but a likely direction in which coordination would evolve, such as to allow nodes to continue on autopilot for all but the most extreme partition events (ex. longer-term network outage that separates two partitions for hours). Any node might set their own such default rules. 

1.35 But back to that extreme partition example: how would such partitions be handled? The Nakamoto consensus just burns whichever half happens to have found the weakest chain upon contact, but we need not resort to such extreme measures.

1.36 It would be entirely possible for enterprising miners to vampire transaction from the parallel chain into their main chain, as long as no input conflicts are seen, healing the partition in very short order once communications are reopened with little to no loss of transactions, expect for any double spends, which duh.

1.37 That’s it: six rules to banish deep reorganisations, eliminate energy-intensive proof of work whilst retaining an asynchronous and decentralised network, speed up finality, and gain a market-responsive supply function.

1.38 Now, I can foresee people being quite unhappy with the only defence against deep reorganisations being some airy-fairy coordination impossibility. 

1.39 Nodes can, of course, willingly force a deep reorganisation if they all agree to jump to a pre-set chain, and there is indeed nothing stopping them from doing so. But nothing stops the network under any blockchain from forking either.

1.40 The risk scenario would be of the network being somehow cajoled or strong-armed into adopting a non-dominating chain that rewrites more than just one or two recent blocks, as there would be o algorithmic defence against this.

1.41 A node would only agree to jump to a deeply divergent chain (which they are given the freedom to) if they think the rest of the network is on it already, and otherwise never do so (which would require a manual user override) regardless of how high their relative UTXO set would appear (money is worth nothing if you cant spend it).

1.42 Remember, there is no penalty for a node to switch chains, so nothing forces a node to jump at once if they perceive the network to have pre-empted them. Nodes have the luxury of only jumping when they need to transact, which =means that they would only jump if part of the network already has.

1.43 Whilst it might in principle be possible for an enterprising attacker to somehow present a juicily-deflated chain and sybyl their way into forcing a local cascade of adaptations that might fool the network into switching, I doubt that this would be practicable at all, and surely would be much harder than mounting a 51% attack under a Nakamoto consensus, especially in a new network of limited hashing power.

1.44 The user base of your typical blockchain might dislike relying on such social consensus trick for their security instead on algorithmic rules, but in time the strengths of the system might make themselves clear.

1.45 Another issue might be checking for domination. Most chains would derive from a recent common ancestor, and a quick A-B check of the hashes would isolate the blocks where they diverge, allowing for nodes to only check a few blocks.

1.46 Miners would be wise to add new transaction as late as they can for this reason, as well as to publish early in the window to give time to nodes to check.