Inspiration
Long before Silicon Valley, microchips, or AI, the ancient Greeks had already invented the fundamental concept of an algorithm.
They didn’t call it code. They called it The Loom of Destiny.
In Greek myth, the universe wasn’t run by a sky god’s whim. It was run by a system. Three sisters known as the Moirai (The Fates) sat at a cosmic weaving loom, weaving a flawless loop that controlled every human life:
- Clotho (The Spinner): Spins the never-ending raw flax.
- Lachesis (The Allotter): Measures the thread with her rod while deciding the destiny.
- Atropos (The Unturnable): Cuts the thread the very instant it reaches its destined end.
But here’s the secret: they never carved into stone: They were running a loop.
Today, we aren’t building a god. We’re building the loom.
I’m going to show you an algorithm that weaves threads exactly like the Fates did - spinning out possibilities, measuring their weight, and cutting the ones that lead nowhere. No divine intervention required.
Stick around to the end, and I’ll show you how to bend time. But first… let’s set the spindle spinning.
The Ghost in the Machine: Why “Slow Clap” Fell Apart
Our previous algorithm, “Slow Clap”, worked. It got the job done: not a single bridge transaction has failed since the latest update!
But let’s be honest: running it felt like babysitting a volatile nuclear reactor.
It had some massive architectural bottlenecks that made our lives miserable. Here is why it broke down in production:
- The Infinite Blame Game (Aggressive Slashing): The system was wildly over-sensitive. Validators were getting slashed left, right, and center (including me, the guy who wrote the post). If a validator sneezed, it lost its stake.
- The RPC Dependency Trap: It had a hard, unyielding dependency on RPC endpoints. If the RPC nodes lagged or choked on data, our entire pipeline stalled out completely, thus marking honest validators as malicious.
- The “One-Shot” Moving Window: Because we were hunting for events, we had to store a jumbled, rolling window of blocks in memory. We couldn’t look back at history; we could only march aggressively forward into the future.
To compensate for this terrifying “future-only” blind spot, we had to crank the security parameters up to maximum. We forced aggressive slashing to punish any node that didn’t keep up perfectly with our hyper-linear timeline.
We weren’t weaving a beautiful tapestry. We needed a system that understood time, history, and flexibility. Enter our new architecture…
Re-Weaving the Loom: What We Must Get Right This Time
To build a system that actually works across decentralized networks, we can’t just write happy-path code. We have to architect around the brutal realities of blockchain infrastructure. If we want to build a truly resilient loom, our new design must account for three non-negotiable engineering constraints:
The Reality of Block Finality (The Shifting Foundation)
Chains aren’t static; they are living, breathing state machines prone to forks and reorgs before a block is truly settled (if you want a deep dive on how messy this gets, check out this Engineer’s Guide to Blockchain Finality).
Because of this finalization lag, our system must provide a rock-solid functionality that allows anyone to query and fetch data based on a specific, finalized block height. No guessing, no front-running data, and no acting on phantom blocks that get dropped by a reorg.
The Bridge Guarantee: Clotho’s Promise
When a user triggers a bridging transaction, they shouldn’t have to cross their fingers and pray to the RPC gods. The architecture must offer a 100% mathematical guarantee that the transaction will execute in the future. Just like Clotho spins the raw thread into existence with absolute certainty, the moment a user initiates a bridge transaction, that thread is permanently bound to the loom. It will be woven; it cannot be dropped.
Decentralized Chaos: Lachesis’s Filter
We have to assume the worst about infrastructure. In production, our validators will be scattered across different global geo-locations, relying on entirely different, sometimes flaky RPC endpoints. Worse yet?
Some of those validators might be actively malicious, trying to feed the system bad data.
Our logic must act like Lachesis measuring the threads - we need parsing engine that takes this chaotic, multi-source input, filters out the noise and malicious actors, and measures out a single, unassailable truth.
Deterministic Execution: Atropos’s Shears
Finally, we need a bulletproof wrapper around the entire lifecycle. The process must guarantee we travel from Point A (the source chain state) to Point B (the GHOST Chain) with absolute finality. Atropos holds the shears to cleanly cut the thread when the program is done.
If a critical edge case occurs (for example if block numbers went back or jump too much into the future), it triggers a deterministic rollback or fallback state. No hanging states, no frozen funds, and no infinite loops in mid-air.
Historical Checkpoints: Back to the Future Part O(log n)
To escape the nightmare of chasing volatile EVM events in real-time, we need a permanent, time-stamped paper trail. We need to store data indexed directly by the block number when it occurred.
It turns out we don’t need to reinvent the wheel here. OpenZeppelin already built the perfect library for this: Checkpoints.
The core concept is brilliantly simple. A checkpoint history is just an ordered array of key-value structures, where the key is the block number and the value is whatever state data we want to preserve.
Index: [0] [1] [2]
+-----------+ +-----------+ +-----------+
Block: | Block 100 | | Block 150 | | Block 210 | <-- Sorted Keys
+-----------+ +-----------+ +-----------+
Value: | State A | | State B | | State C | <-- Historical State
+-----------+ +-----------+ +-----------+
^
|
Target: Block 180 --------+
(Binary Search finds the lower bound!)
Because these checkpoints are pushed sequentially, the array is guaranteed to be sorted by block number. This unlocks a massive performance optimization.
When a validator needs to know the network state at a specific historical moment, we don’t scan the whole array from day one. Instead, we use a Binary Search to find the lower bound.
Specifically, the algorithm hunts for the latest checkpoint with a block number less or equal than our target key. This gives us semi-instant, O(log n) access to any point in history. No more jumbled rolling windows. No more missing events.
If you want to see exactly how OpenZeppelin writes this gas-optimized math in production, check out their official source code for Checkpoints.sol on GitHub.
Hash Chains: How I Met Modulo Distribution
Split the load!
We use a modulo distribution strategy to slice the transactions evenly across multiple independent arrays (think of it like weaving a giant tapestry by assigning different color threads to multiple independent looms running in parallel).
And to verify the integrity of the data inside these chunks? We implement an old-school, rock-solid cryptographic mechanic: Hash Chains.
A hash chain is essentially the digital version of ancient wisdom: a reliable, unforgeable mechanism older than most Web3 developers’ careers, yet still sharp enough to protect billions in assets.
When a transaction arrives, we don’t just dump it anywhere. We look at its Global Index, apply a simple modulo operation against the total number of available arrays, and route it to its exact destination array.
Each array is simply a vector of sequential transactions. But instead of storing full block events, the state prover compresses the array’s history into a one hash.
Tx_N = {array_index_N, amount_N, receiver_N}
Example:
txs = [Tx_1, Tx_2, Tx_3, Tx_4]
hash = Hash(Hash(Hash(Hash(0, Tx_1), Tx_2), Tx_3), T_x_4)
Merkle Trees: The Ultimate Cosmic Tapestry
If Checkpoints are the memory and Hash Chains are the thread, then Merkle Trees are the absolute GOAT of algorithmic design. This is genuinely one of the most brilliant architectural blueprints humanity has ever conceived. A top-notch idea that makes modern decentralized computing possible.
The architecture relies on building a perfectly balanced binary tree. Here is how the construction works from the ground up:
- The Bottom Layer (The Leaves): This base row is filled entirely with your raw transaction values (or their individual cryptographic hashes).
- The Layer-by-Layer Weave: The algorithm pairs up adjacent leaves, concatenates them, and hashes them together to form a parent node.
- The Summit (The Merkle Root): This process repeats recursively, narrowing the tree upward until only one single hash remains at the very top.
This solitary Merkle Root serves as the cryptographic summary of the entire dataset. It represents the absolute, unassailable state of every single transaction included below it.
The reason this data structure is considered a masterpiece is how efficiently it handles verification.
If a user needs to prove that Transaction B is genuinely included in the block, they don’t need to pass all transactions to the validator. Instead, the prover only needs to provide a tiny path of companion hashes up the tree (called a Merkle Proof) - in this case, just HashA and HashCD.
This drops our verification complexity down to an incredibly lightweight O(log n). Whether your tree holds 4 transactions or 4 billion, proving a single transaction takes just a handful of steps.
Connecting the Threads: The Cosmic Loom in Action
Now, let’s tie our secret weapons together into a single, cohesive masterpiece. We are combining Checkpoints, Hash Chains, and Merkle Trees into a uniform network architecture.
To visualize this, stop thinking like a software engineer for a second. Start thinking like a master weaver operating a giant mechanical loom.
[ MERKLE ROOT ]
/ \
[ Hash AB ] [ Hash CD ] <-- Heddles (The Pulley Logic)
/ \ / \
[HashA] [HashB] [HashC] [HashD]
| | | |
[H_A] [H_B] [H_C] [H_D] <-- Warp Threads (Hash Chains)
================================
[Tx_9] ...... ...... ...... /\
[Tx_5] [Tx_6] [Tx_7] [Tx_8] || <-- Weft Injections
[Tx_1] [Tx_2] [Tx_3] [Tx_4] || (The Checkpoints)
The transactions (Tx_N) are being pushed upward over time. The vertical columns represent our modular Hash Chains - these act as the structural warp threads pulled tight on the loom. Every single block mutation triggers a new insertion checkpoint. These chronological inserts act exactly like weft threads, shot horizontally across the warp by a flying shuttle, locking the historical states tightly into place.
Down the Rabbit Hole: The Raw Bytecode of Destiny
If you look at the absolute majority of Merkle Root implementations, they do something incredibly wasteful: they recompute the Merkle Root on-chain during every single write operation. Every single transaction insertion forces the EVM to loop through hashes, burning user gas fees like a runaway furnace.
We decided to do things differently. We shifted the heavy lifting entirely!
Instead of burning gas on-chain to recompute the root during every write call, we do zero state root calculation during insertions. We simply push the new transaction data to its modular checkpoint vector.
When a user or a bridge validator needs the Merkle Root to prove a transaction, they invoke a customized read call (a view function). Because view calls are executed entirely off-chain by the local node provider, computing the Merkle Root becomes absolutely FREE!
Atropos Comes into Play: Snapping the 2048th Thread
This is where the third sister, Atropos, steps out of the shadows.
If we choose a fixed tree depth of 8, and apply a strict design of depth matched to value storage capacity, the math dictates our precise boundaries. Running the formula (2^depth) * depth means each chunk holds exactly 2,048 transactions total.
Yes, that’s right - 2,048 is the answer! Just like the legendary internet puzzle game, once your grid hits its maximum threshold and there are no moves left, the board freezes.
So, what happens next? What do we do when all 2,048 transaction slots are completely filled to the brim?
Atropos raises her shears and cuts the thread.
She cleanly terminates the current session, seals the finished tapestry, and pushes it into cold archive storage forever - indexed safely by its final block numbers.
And just like that, the cycle resets, the cosmic coin drops, and it’s time to push Insert Coin to start a brand new game.
The loom clears out, the initial state reinitializes to zero, and the play starts all over again from the very beginning. We get a fresh, lightning-fast, unbloated tree structure ready to weave the next 2,048 transactions into history, while the past remains completely immutable, searchable, and safe from reorgs.
But wait! What’s on the other side?
The Fates didn’t work alone. Neither do we.
We’ve covered how we store transactions (the Spindle’s Memory) and how we prove them (Hash Chains). But who weaves the final tapestry? Who decides what’s real and what’s not?
The Validators of GHOST Chain. Collectively. As Clotho.
They don’t just validate - they weave the final root hash and store it for all time. And they do it in a beautifully simple 2-round protocol:
Round 1: The Block Number Consensus
- Each validator (independently) queries their RPC endpoints for the current block number.
- The Protocol checks:
- Is there at least BFT (Byzantine Fault Tolerant minimum number of validators participating?
- Among those, what’s the maximum allowable deviation between the lowest and highest reported block numbers?
- The protocol takes the exact middle of the filtered range.
Round 2: The Root Hash Consensus
- Each validator requests the root hash from the smart contract based by block number from previous round.
- At minimum BFT of participating validators must match on the root hash.
- The protocol accepts the root as the canonical truth.
This is how the destiny is decided. The collective block number might drift to any side at any point in time, but the latest root hash will be included, whatever it takes.
For the block number consensus, we borrowed a page from the Silicon Valley series. If you haven’t watched it, stop reading and go watch it. Seriously… It’s the best show about IT industry ever made, and I will die on that hill.
Back to the algorythm, the idea is simple: we take the reported block numbers, sort them, and do middle-out search. Just like Pied Piper’s middle-out compression, but with fewer existential crises and more actual math.
The simple visualization of the algorithm is:
max_block_distance = 20
threshold = 6 * 2 / 3 + 1 = 5
block_numbers = [1, 10, 12, 15, 18, 100]
===================== round 0 ======================
[ 1 ] [ 1 ] [ 10 ] [ 12 ] [ 15 ] [ 18 ] [ 100 ]
||
[LEFT/RIGHT]
====================== round 1 ======================
[ 1 ] [ 1 ] [ 10 ] [ 12 ] [ 15 ] [ 18 ] [ 100 ]
|| ||
[LEFT] [RIGHT]
====================== round 2 ======================
[ 1 ] [ 1 ] [ 10 ] [ 12 ] [ 15 ] [ 18 ] [ 100 ]
|| ||
[LEFT] [RIGHT]
====================== round 3 ======================
[ 1 ] [ 1 ] [ 10 ] [ 12 ] [ 15 ] [ 18 ] [ 100 ]
|| ||
[LEFT] [RIGHT]
====================== round 4 ======================
[ 1 ] [ 1 ] [ 10 ] [ 12 ] [ 15 ] [ 18 ] [ 100 ]
|| ||
[LEFT] [RIGHT]
====================== round 4 ======================
[ 1 ] [ 1 ] [ 10 ] [ 12 ] [ 15 ] [ 18 ] [ 100 ]
|| ||
[LEFT] [RIGHT]
collective_block = (10 + 12) / 2 = 11
Final Thoughts
We’re putting the final touches on the actual weaver pallet, and we’re planning to ship it in the upcoming update. Stay tuned - we’ll keep you posted on the release.
The EVM-side code is out there, ripe for the reviewing. Feel free to dig in yourself, or just ask your favorite AI to explain it to you.
And if you’re feeling adventurous: ask an AI to generate test cases for it. Then run them. Then report back. We’d love to see what breaks and what holds.
Until next time, keep weaving.
