RequantTESTNET
Requant research

How the lab models a network

Requant Lab plays a proof-of-work network as a sequence of events in virtual time. This page says what is in the model, how a run is made repeatable, and where the model stops.

Events and time

  • Virtual time in microseconds. Every find, message, delivery, request and change of the plan is an event in one queue; the engine takes the earliest. Nothing reads the wall clock, files, the network or the operating system's randomness.
  • One seed, separate streams. Mining, links, transactions and random impacts draw from their own streams derived from the scenario's seed, so adding noise to links does not change when blocks are found.
  • Repeatable by hashes. The same build, platform, scenario and seed give the same history. A run's manifest records the build, the normalized scenario and SHA-256 hashes of every file; compare reports EQUAL or the first difference. Portability of floating-point logarithms between platforms is not proven, so the platform is part of the conditions.

Who is in the network

  • Nodes, pools and miners are different participants. In a proof-of-work network nodes do not mine: miner groups connect to pools that run on nodes. Work and finds travel with delays, and miners move to a working pool when theirs goes down. A node can also mine solo.
  • Power is in hashes per second. A find is a draw from an exponential waiting time given the group's power and the target of the branch it mines on.
  • Miners come and go. A group can have a live number of miners around its mean, following the day and sometimes jumping; with a coin price and an electricity bill, miners decide every few blocks whether the work pays, and leave or return.

The network between them

  • Links with latency, random delay (0-5000 ms) and loss, bandwidth with a FIFO queue per direction and drops on overflow, and compact block relay that sends a header and the missing transactions instead of the whole block.
  • Partitions and outages. The network can be cut into groups and healed; nodes can be switched off and come back, keeping their chain and catching up from neighbours with ordinary messages.
  • Block validation takes time. A node can check blocks one by one at a base cost plus a cost per transaction, and can mine on a header before the body is checked, which produces empty blocks.

Chain rules

  • Fork choice by most work, optionally with uncles (up to two per block, up to six deep, Ethereum's reward formula).
  • Difficulty rules of real networks: a fixed target, a window every N blocks (Bitcoin), DigiShield (Zcash, Dogecoin), Dark Gravity Wave (Dash), LWMA (CryptoNote forks), ASERT (Bitcoin Cash, and Requant's parameters), Monero's window with outliers dropped, Kimoto Gravity Well, and Bitcoin Cash's emergency adjustment of 2017.
  • Block timestamps set by the miner, with the median-of-past rule, so timestamp attacks can be played.
  • Several chains with their own genesis, difficulty and coin, merged mining between two of them, and a hard fork at a chosen moment that splits the network by the rules each node accepts.

Coins and transactions

  • Rewards and schedules: a constant reward, halvings every N blocks, smooth decline and a tail. Only main-chain blocks pay.
  • Pool payouts: PPLNS, PPS or PROP with a pool fee; solo miners keep whole blocks. The result shows what each pool and each miner group earned.
  • Transactions: a flow with sizes and fee rates (log-normal, with a daily rhythm), a mempool limit that evicts the cheapest and raises the minimum rate, replace-by-fee, child-pays-for-parent packages, block weight. On a reorganisation transactions return to the queue.

Attacks

  • Selfish mining: a pool hides the blocks it finds and releases them when the network catches up, cancelling honest blocks.
  • Double spend with a result: a merchant waits k confirmations; each attempt is counted with its probability, its cost and what the attacker gains.
  • Attacks on pools: sabotage by withholding found blocks, and eclipse of a node.
  • Power surges and outages of chosen pools at chosen times.
  • Any impact can be random: on each tick of its interval it fires with a set chance, repeatably by seed.

Many runs, not one

  • A series plays a scenario on many seeds (30 by default) and reports the distribution of each figure with 95% intervals; two scenarios are played in pairs on shared seeds, so the difference between them is measured on the same luck.
  • On the server a fast series runs up to a million runs, with a GPU worker taking the nodes outside the event loop.

Where the model stops

  • Block search is probabilistic. In the model a find is a random draw, not a hash; the protocol mode is the exception and searches real TNet claims for regtest.
  • Messages are a model of peer-to-peer relay, with the propagation rules listed above, not a node's networking code.
  • Real-network profiles are scaled for a demonstration: emission 100 times faster, transaction flow and block size 20 times smaller, 60 nodes.
  • Limits are stated where they apply. A browser run is bounded in nodes, events and journal size, and a server run in events and compute time; a run that reaches a limit keeps its partial result with the reason.