Anatoly's Thinking

The Consensus Problem

Every blockchain is, at its core, a solution to a coordination problem: how do a group of machines that don't trust each other agree on a single version of truth? Bitcoin solved this with elegant simplicity — the longest chain wins. Proof-of-work makes it computationally expensive to create a fake chain, so the honest majority always controls the canonical history.

The Syrpts Network inherits this model but faces a unique challenge: we're not just tracking one currency. We're tracking thousands of custom tokens, each with their own supply, their own liquidity pool, and their own market dynamics. The consensus mechanism must validate not just "did this transfer happen?" but "is this trade price mathematically consistent with the constant-product formula?"

Why Hybrid Architecture

Pure decentralization is an ideology. Practical decentralization is an engineering trade-off. I chose the hybrid Primary/Replica model because it gives us the best of both worlds:

Why a Primary Node?

• Instant finality — Users expect trades to execute in milliseconds, not minutes. The Railway primary can confirm a trade instantly because there's no need for block propagation consensus.
• Payment gateway integration — PayPal and NowPayments require webhooks, API keys, and secure callback URLs. These fundamentally cannot be distributed across untrusted peer nodes.
• State consistency — With a single primary, there are no state conflicts, no fork resolution delays, and no orphaned blocks during normal operation.

Why Peer Replicas?

• Resilience — If Railway goes down (and cloud providers do go down), the peer network maintains a full copy of the blockchain. When Railway recovers, it re-syncs from peers.
• Censorship resistance — No single entity can prevent the network from operating. Even if the primary is shut down, peers can elect a temporary coordinator.
• Mining distribution — Desktop peers contribute real computational work. This prevents the network from being a "centralized database pretending to be a blockchain."

The Syrpts DAA

Bitcoin adjusts difficulty every 2,016 blocks (roughly two weeks). This works for a mature network with stable hashrate, but it's dangerously slow for a young network where hashrate can fluctuate by 10x in a single day.

The Syrpts Difficulty Adjustment Algorithm adjusts every 10 blocks. The logic is intentionally simple:

The 2× and ½× thresholds prevent oscillation. Without them, the difficulty would ping-pong between values on every adjustment. The thresholds create a "dead zone" where the difficulty stays stable unless there's a significant hashrate change.

I considered more sophisticated algorithms (ASERT, LWMA, weighted moving averages), but simplicity won. A simple algorithm is auditable. An auditable algorithm is trustworthy. A trustworthy algorithm is secure.

Fork Resolution

When a peer node presents a longer valid chain, the primary must decide whether to adopt it. The resolveConflict() function implements the longest-chain rule with strict validation:

1. The incoming chain must be strictly longer than the current chain (not equal)
2. Every block in the incoming chain must pass the validator using the current live difficulty (not the difficulty recorded in the block headers)
3. If validation passes, the current chain is replaced, the database is truncated and rebuilt, and the state is recomputed from scratch

Step 2 is critical. Early implementations validated each block against its own recorded difficulty, which allowed an attacker to submit a long chain of easy blocks. By validating against the current difficulty, we ensure that any reorganization requires the same computational effort as the honest chain.