Does decentralized consensus really need a chain? What happens if emergence replaces history?

Consensus
1

For about fifteen years, nearly every decentralized consensus protocol—whether PoW, PoS, or DAG variants—has implicitly relied on the same core assumption:

That achieving consensus requires all nodes to share a single, global, ordered history of blocks.

This linear history makes verification simple, but it also introduces structural constraints: global synchronization, replay overhead, finality coupling, and increasing centralization pressure as the network grows.

At some point I started asking a very simple but uncomfortable question:

Is this assumption a mathematical necessity… or just an engineering tradition?
Does decentralized consensus really need a chain?

✦ A hypothetical alternative

Suppose we abandon the requirement for shared historical ordering, and instead allow:

  • Each proposal (block/message) to exist independently
  • No parent references, no global ordering
  • Nodes propagate proposals according to local trust
  • Consensus emerges from network topology, not chain structure

If this were possible, we would need to ask:

  • Would such a system still converge?
  • Could finality be emergent rather than sequential?
  • Would full nodes still need to store history at all?
  • Would high-latency environments (e.g. interplanetary networks) remain viable?
  • If consensus weight derives from behavior rather than capital, would we see less centralization?

✦ A working hypothesis: the L.O.P. Principles

To explore this direction, I defined a minimal set of constraints for a purely local trust model, called the L.O.P. Principles (Locally / Observed / Principles):

1. Trust is strictly local and must never be globally shared
2. Trust must be derived only from directly observed behavior
3. Trust rules must be defined according to the network’s purpose

These rules look trivial at first—but their consequences are not.

They prohibit global trust synchronization
They eliminate the idea of a “single reputation state”
And they force every node to determine trust boundaries independently

In such a world, consensus is no longer a product of shared history.
It becomes a property of network topology + local trust + emergent convergence.

✦ Unresolved questions (and why I am posting here)

To be absolutely clear: I do not yet know whether this direction is viable.

I would specifically love to hear criticism, references, or proof-based counterarguments to questions like:

  • Has this direction been explored—and disproven—before?
  • Is there a theoretical impossibility result that makes “historyless consensus” unattainable?
  • Could local trust models lead to permanent partitioning?
  • Can topology collapse be formalized as finality?
  • Are there applicable results from CRDTs, epidemic consensus, or multi-agent systems?
  • Does this violate any classical impossibility results (FLP, CAP, etc)?
  • Is there any known way to prove (or disprove) convergence in such a model?

I am explicitly hoping someone will tell me why this cannot work, if that is indeed the case.

✦ What this is not

  • Not a token launch
  • Not fundraising
  • Not a product
  • Not a whitepaper announcement
  • Not an “X is better than blockchain” argument

Right now this is simply a conceptual question, one that I think deserves public scrutiny:

If a chain is not strictly necessary, then perhaps we have not yet explored the full space of consensus designs.

✦ Repository (empty for now, for future work)

I have created an empty GitHub repository only as a placeholder for future drafts, experiments, or specifications:

:backhand_index_pointing_right: GitHub - BinGo-Lab-Team/TrustMesh: Consensus without chains — an orderless, history-free, reputation-driven framework with infinite parallelism.

There is currently no documentation, no code, and no implementation.
If anyone finds this direction interesting, feel free to Watch the repository, but please don’t expect anything yet.

✦ Open-ended closing questions

If consensus can emerge without shared history:

  • Do we need to redefine what “consensus” means?
  • Is blockchain just one special case of a larger design space?
  • Could Web3 eventually shift from ordered history → stable trust states?

If the answer is “yes”, then perhaps we haven’t reached the boundary of decentralized consensus at all.

1 Like
2

IOTA has been trying to solve this problem for something like 10 years, and while they always make big claims to having solved it despite al of the “experts” telling them that they haven’t, so far they have yet to turn off their centralized piece that is still required to keep it running.

The core of the problem is that there is no true “local”. Alice can transact in Brazil at the exact same time as transacting in China and if those two transactions are mutually exclusive (e.g., they both spend the same money) then you need some mechanism for deciding which of them comes “first” (and thus gets included) and which comes “second”.

From the point of view of someone in Brazil, the Brazilian transaction arrived first. From the point of view of someone in China, the Chinese transaction arrived first.

3 Likes
3

Strictly speaking, to prevent double spending, it’s not necessary to decide which transaction came first. We could reject both transactions if they appear within a short time frame.

2 Likes
4

That is an interesting idea I hadn’t considered, I will need to think on it more.

You still would need to wait for “finality” though, where you wait to see if there is a conflicting signature in the prescribed time. You also would need to deal with edge cases where the second signature arrives right on the border of what is allowed, so half of the world see it as double-spend, the other half see it as properly spaced sequential spend.

5

Participants in any high-stakes system (e.g. payment network) must agree on the following:

  1. What are the transactions that happened?
  2. Given a set of conflicting transactions, which one (if any) do we accept as valid?

Sounds like you want to relax (1). But isn’t (1) a prerequisite of (2)? It is hard to imagine that a system without some kind of global consensus could solve both.

That said, having a global linear ledger (i.e. a total ordering of all transactions) is not necessarily required; we only need to order conflicting transactions, not independent ones.

1 Like
6

You’re absolutely right that some form of finality is still required. However, the key difference in TrustMesh is that finality doesn’t depend on probabilistic confirmation or multi-round voting. Instead, it emerges naturally from the collapse of the trust topology. In practice, the finality window depends almost entirely on the number of propagation hops—not on the total network size or validator count.

Given modern network conditions, low latency, and nodes proactively maintaining peer connections, the variance introduced by hop-based delay is negligible. This means that what is normally considered a disadvantage (waiting for finality) actually becomes an advantage: the network can operate with a fully fixed block interval without needing synchronized rounds or probabilistic safety.

As for the consensus process itself, the design works like this: in each round, every node may publish a proposal containing a signature tree. Other nodes score proposals based on the signatures they recognize, using their local reputation tables, then append their own signature and continue propagation. After a few iterations, one proposal becomes the dominant attractor in the topology. It consistently ranks first in all healthy nodes, which effectively establishes consensus.

One more thing I want to highlight: using a monetary blockchain as the mental model for this kind of network is actually misleading. Bitcoin and similar systems assume that all state must be linearly chained forever, but many real-world applications don’t require continuous history at all. Once you stop treating continuity as a hard requirement, you’ll find that a very different—and often much more efficient—design space becomes possible.

7

Bitcoin already demonstrates that you don’t need every node to see every transaction in order to resolve conflicts. No node has a complete mempool, yet double-spends are still handled purely through propagation and competition.

Fundamentally, a system only needs to satisfy two conditions:

  1. Each proposal must be internally consistent and not conflict with confirmed history
  2. Eventually, only one proposal will be accepted network-wide

This does not require all nodes to have a global view of all transactions, and it doesn’t require a globally linear history either. As long as the propagation and resolution process leads to a single dominant proposal, consensus can still be achieved—even outside of monetary networks.

1 Like
8

This is the very hard problem that you need to solve. Imagine some actor wants to build reputation over time. They can sybil attack and pretend to be 1000, or 1,000,000 different nodes and they can do whatever is necessary to pump their reputation. Once they have pumped their reputation sufficiently high, they can then “burn” that reputation to double spend.

The traditional way to address the sybil problem and profitable attack problem is via some sort of staking mechanism so if a double spend is detected the attacker can be slashed and we can at least ensure they lose a lot of money. However, once you build such a system you may find that you are back to a linear blockchain as that is much easier to implement slashing on than a tree.

2 Likes
9

Thanks — this is the right question, and I agree it’s the core challenge.

The key difference is that in TrustMesh, reputation is not a global shared variable.
Under the L.O.P. axioms, reputation is:

  • Local
  • Non-exportable
  • Observation-based
  • Decaying

That means an attacker cannot “pump” global reputation — they must independently earn trust from each observer. Even if they control 1,000,000 identities, they do not automatically accumulate 1,000,000× reputation, because every node evaluates them independently.

Sybil behavior simply results in wasted effort, not global influence.

TrustMesh does not require slashing because it does not store “reputation” as a globally agreed-upon value. There is nothing to slash — only local trust to revoke.

In other words: PoS protects a shared ledger. TrustMesh avoids the need for a shared ledger in the first place.

1 Like
10

The third axiom of L.O.P. inherently requires that any attack must be accompanied by sustained positive contributions to the network. Economically, this is far more secure than Proof-of-Stake, because it prevents adversaries from temporarily acquiring influence through mechanisms such as loans. Furthermore, once malicious behavior is detected, any node that observes or receives cryptographic evidence can immediately reduce the offender’s reputation and reject any future requests from that identity.

In addition, we can impose an upper bound on each node’s reputation and allow it to decay over time, completely eliminating the possibility of “whale” nodes.

1 Like
11

Correct me if I’m wrong, but Bitcoin prevents double-spends via reaching consensus on the linear ledger of transactions. Nodes can apply different strategies to exclude double-spending transactions from the mempool, but it’s all a heuristic with no strong guarantees.

1 Like
12

Just to clarify — TrustMesh doesn’t forbid chains. Chains are still necessary for monetary systems because balance history must remain traceable. What TrustMesh does is make chains optional instead of mandatory.

The only consensus guarantee is that each round produces one accepted proposal. Whether those proposals reference a parent (i.e. form a chain) depends on the application.

Using your example: if Alice has 10 tokens and submits two valid spends at once, a proposal that includes both is locally invalid and will be rejected immediately. If the two spends land in separate proposals, both are temporarily valid—just like forks in Bitcoin. Only one proposal will eventually win, and anything building on the losing one becomes invalid.

So it’s the same model as Bitcoin: conflicts are allowed to exist briefly, but only one path becomes canonical. The difference is simply that TrustMesh resolves this via reputation/emergence instead of PoW/PoS.

Chains are still possible when needed—they’re just not the foundation of consensus anymore.