Concepts

This page bridges the gap between Overview (“what daqq is”) and Architecture (“how the code is laid out”). If you are new to blockchains or to commit-reveal randomness, read this first.

The big picture

daqq is a chain of blocks. Each block is roughly one tick of the system clock. Inside every block, every node in the network runs identical logic, so they all agree on what just happened.

Every 50 blocks the network produces one fresh, unpredictable 256-bit random seed, agreed on by all nodes. That window of 50 blocks is called a round. The seed is what participants use to do the actual work — currently, generating an identical random quantum circuit and recording its theoretical output distribution on-chain.

    flowchart LR
    subgraph Round_N["Round N (50 blocks)"]
        c["Commit phase<br/>participants lock in<br/>secret hashes"]
        r["Reveal phase<br/>participants publish<br/>their secrets"]
        s["Seed finalised<br/>seed = SHA256(XOR of reveals)"]
        c --> r --> s
    end
    s --> use["Nodes use seed<br/>to generate the<br/>random circuit"]
    use --> sub["Participants submit<br/>their results to the<br/>ledger"]

The rest of this page defines each term in that diagram.

Terminology

Block

A batch of state changes that every node agrees on at the same moment. Blocks have an integer height that monotonically increases: block 0 is genesis, block 1 is the next one, and so on. In daqq, blocks are produced roughly every few seconds by validators running Cosmos SDK’s CometBFT consensus.

Node / validator / participant

Node: any computer running quantumchaind.
Validator: a node that has bonded stake and participates in consensus (proposing and signing blocks).
Participant: anyone — validator or not — who submits commits, reveals, and results to daqq. In daqq there is no economic distinction between validators and ordinary participants because there are no rewards; the validator role exists only because Cosmos SDK requires proof-of-stake to make progress.

Transaction (tx)

A signed message sent to the chain — e.g. “I commit this hash for round 42”, “I reveal this secret”, “Here is my result for round 42”. Transactions are collected by validators and included in blocks.

Module

A self-contained piece of chain logic with its own state, messages, and hooks. daqq’s chain has four custom modules: beacon, problems, random_circuit, and quantumchain. See Architecture.

EndBlocker

A hook each module exposes that runs at the end of every block, after all transactions in that block have been processed. The beacon’s EndBlocker is what finalises the seed at the end of a round.

Round / RoundID

A 50-block window. roundID = blockHeight / 50. Round 0 is blocks 0–49, round 1 is blocks 50–99, and so on. At the end of each round, the beacon produces one seed for that round.

Commit (commit-reveal: step 1)

The participant locks in a secret without revealing it yet, by sending the hash of the secret on-chain. Once committed, they cannot change it. This is like sealing a number in an envelope.

Reveal (commit-reveal: step 2)

Later in the same round, the participant publishes the actual secret. The chain checks that hash(secret) matches what they committed earlier. This is like opening the envelope. A participant who refuses to reveal contributes nothing to that round’s seed — but they also can’t bias it, because they were already locked in.

Seed

The 256-bit random value produced once per round. Calculation:

Take every valid reveal in this round.
XOR them all together.
SHA-256 the result.

As long as at least one participant picked their secret unpredictably, the XOR result — and therefore the seed — is unpredictable to everyone else in advance.

Problem

A computational task that consumes the round seed and produces a result worth recording. The first one is random_circuit (generate a quantum circuit from the seed, compute its theoretical output distribution, submit it). Each problem is its own Cosmos SDK module; the problems module is the on-chain registry that tracks which problems exist and whether they are currently accepting submissions. See Problem System.

Lifecycle of one round

A round spans 50 blocks. The block offset within the round (blockHeight % 50) determines which phase the network is in:

Offset within round	Phase	What participants can do
1 – 30	Commit	Send `MsgCommit{roundID, hash}`.
31 – 45	Reveal	Send `MsgReveal{roundID, secret}`. The chain verifies `hash(secret)` matches the earlier commit.
46 – 49	(idle)	No commits or reveals accepted for this round.
50 (EndBlocker)	Finalise	Beacon XORs all reveals, hashes the result, stores `Seeds[roundID]`, emits a `NewRound` event.

Predictable-seed window (offsets 46 – 49). Reveals close at offset 45, but the seed is not officially stored until the EndBlocker at offset 50. During the 4 blocks in between, every valid reveal is already on-chain and the seed is just SHA256(XOR(reveals)) — anyone can compute it locally before the chain announces it. Today this has no impact because the random_circuit module has no submission deadline, so being “early” buys you nothing. But any future problem that introduces a per-round deadline must account for this 4-block predictability window, or shrink the gap by moving RevealEnd closer to RoundDuration.

After offset 50, the seed for that round is publicly readable. Any participant can now:

Read Seeds[roundID].
Generate the random quantum circuit deterministically from that seed.
Compute the theoretical output probability distribution locally.
Submit it via MsgSubmitResult{roundID, distribution} to the random_circuit module.

The next round’s commit phase has already started in parallel, so the network never sits idle.

    gantt
    title One round (50 blocks)
    dateFormat X
    axisFormat %s
    section Beacon
    Commit phase           :a1, 1, 30
    Reveal phase           :a2, 31, 45
    (idle)                 :crit, a3, 46, 49
    Finalise (EndBlocker)  :milestone, a4, 50, 1
    section Problem
    Submit results (next round and on)         :a5, 50, 50

Why commit-reveal?

The naive alternative — “everyone just publishes a random number, XOR them all together” — fails because the last participant to publish can see everyone else’s numbers and pick their own to bias the result. Commit-reveal forces everyone to lock in before anyone reveals, so by the time secrets become public it is too late to bias the outcome.

The remaining attack is withholding: a malicious participant who sees that revealing would produce a seed they dislike can simply not reveal. This skews the seed only across the subset of possible “withhold or not” choices, and only as long as you control multiple participants — and it costs you your own contribution to the seed. daqq accepts this residual bias for simplicity; problem-specific modules can layer extra constraints on top if they need stronger guarantees.

What’s next?

Architecture — how these concepts map to Cosmos SDK modules and their execution order.
Problem System — how multiple problems coexist on one beacon.
beacon module — implementation details of the commit-reveal protocol.

Overview Architecture