From 894a776f3dddefe5e2fcd710277977460de677b5 Mon Sep 17 00:00:00 2001 From: igneum-labs <337424239+igneum-labs@users.noreply.github.com> Date: Thu, 8 Oct 2026 15:41:25 +0000 Subject: [PATCH] Igneum 2.0 D5: the partition row (the chain's behaviour across partitions under rule v4, measured in scenario N), on the coordinator's plan files; spec: Devnet 3 clock line dropped Co-Authored-By: Claude Fable 5.1 --- docs/plans/igneum-2.0-reference.txt | 132 ++++++++++++++++++++++++ docs/plans/igneum-2.0.md | 150 ++++++++++++++++++++++++++++ docs/spec/finality-guarantees.md | 2 +- 3 files changed, 283 insertions(+), 1 deletion(-) create mode 100644 docs/plans/igneum-2.0-reference.txt create mode 100644 docs/plans/igneum-2.0.md diff --git a/docs/plans/igneum-2.0-reference.txt b/docs/plans/igneum-2.0-reference.txt new file mode 100644 index 000000000..d23b64a25 --- /dev/null +++ b/docs/plans/igneum-2.0-reference.txt @@ -0,0 +1,132 @@ +INGEUM 2.0 


Yes—if the programme delivers the independently verified results we defined, my judgement is that Igneum would belong in the top tier of GPU-first mining projects, with a credible case for technical leadership. +That is different from automatically becoming the largest, most profitable or most trusted GPU network. You can engineer a leading system; adoption and sustained demand still have to follow. +The distinction is between shipping the proposed changes and demonstrating that they achieve the objective. The latter is what would earn that position. +Where successful execution would put you +Area +My assessment of the proposed end-state +Keeping ordinary GPUs competitive +A potential leadership position, provided independent hardware analysis confirms the result against programmable, multi-epoch competitors. +Quality of the resistance evidence +A major strength if you publish reproducible measurements, realistic adversarial designs and economics that do not assume chips automatically expire. +Miner experience +Potentially top-tier: straightforward installation, effective tuning, transparent earnings, reliable payouts and retained control. +Usefulness of the hardware +A compelling proposition if the same accessible hardware can earn from genuinely purchased proving work as well as securing the chain. +Security and decentralisation +A credible contender after independent review and failure testing—not something a feature list establishes. +Miner profitability and market leadership +Still dependent on demand, competition, liquidity and operating costs. These cannot be guaranteed by protocol design. +The strongest potential advantage is the complete package—not one supposedly unbeatable hash. +You would be competing with serious projects +The space is not empty, and I would not claim Igneum had surpassed these projects merely because its design is newer. +Ravencoin already expresses a closely related objective. Its KAWPOW approach is intended to keep consumer GPUs competitive, explicitly allows for future ASIC development, and does not envisage further algorithm forks as the normal defence. Igneum would need to demonstrate a stronger result or a more valuable overall offering—not just restate that goal. +Ergo already has a GPU-oriented, memory-hard mining design, with implemented changes to pooling, emissions and difficulty adjustment. That gives you an operating system to benchmark against, rather than merely a competing whitepaper. +Firo is actively improving commodity mining accessibility. Its September 2026 reference-miner release supports NVIDIA and AMD, charges no developer fee, and reports performance within roughly 1% of popular closed-source alternatives. That performance figure is Firo’s own report, but it illustrates the practical standard Ember would need to meet. +Those are useful reference points, not an exhaustive league table. They also show why “GPU-friendly” is the entry requirement, not sufficient differentiation. +What could make Igneum stand out +Your proposed combination is more interesting: +Competitive commodity mining + application execution + verifiable proving + an accessible operator application + meaningful miner control. +The litepaper already frames mining, proving and Ethereum-compatible execution as separate but connected parts of the system. The opportunity is to make that combination work reliably and economically—not simply to have more features than another chain. +For a miner, the strongest proposition would be: +“My hardware remains useful and competitive, I can earn from more than the mining subsidy, and I do not have to surrender control to participate.” +For a customer buying proofs: +“I receive a correct result at a competitive price and reliable delivery time, without needing to care which independent operator produced it.” +Deliver both, and Igneum would have a strong reason to exist beyond attracting miners from another coin. +However, the proving-income distinction matters enormously. The current economics page describes internal proving payouts on a valueless devnet and says the external proving market is not yet built. Internal reward distribution demonstrates the mechanism; repeat purchases by outside customers would demonstrate demand. +What separates “top-tier technology” from “the leading network”? +I would look for three outcomes. +Miners stay through difficult conditions. Not because the launch is temporarily lucrative, but because hardware compatibility, operating costs, payouts and control remain attractive. +Customers repeatedly pay for the output. Not subsidised pilots or partnership announcements: useful work purchased at prices that support reliable service and operator margins. +The network works without the founding team holding it together. Independent operators build the software, enforce the rules, survive failures and continue operating without emergency intervention. +Those would be my tests for leadership. A small specialist-hardware advantage alone would not establish any of them. +My direct answer +The ceiling is category leadership. Successful, independently validated execution would put Igneum in serious contention for the top of the GPU-mining space on engineering and operator proposition. +But I would not give it an unsupported “number one” ranking before comparative results and real-world adoption exist. +The progression I would expect is: +Demonstrated technical advantage → credible top-tier project → repeat customer demand and miner retention → potential category leader. +You have a plausible route to the top. The decisive move is now to prove that ordinary operators can succeed on the system—not to make the design sound more ambitious. +


Yes—EVM-compatible applications with ZK-proven execution are the right default for Igneum. But I would position and build it as a GPU-secured L1 with a flexible proving layer, not simply “another zkEVM chain.” +The architecture I would choose is: +EVM for developers. A general-purpose zkVM for proving. Igneum’s own consensus for security. External customers for additional proving demand. +Those choices fit together, but they are not the same decision. +1. Separate the three architectural choices +Decision +My recommendation for Igneum +Why +What developers build against +EVM-compatible execution +Let builders use familiar contracts, languages and tools rather than requiring them to learn a new application platform. +How execution is proved +An established general-purpose zkVM, initially your SP1-based implementation +Prove the EVM implementation without developing an entirely new proof system yourselves. Preserve a carefully versioned replacement path. +Where the network obtains consensus and finality +Your sovereign GPU-mined L1, subject to the security gates we discussed +This preserves your actual objective: an independent network secured by accessible hardware, rather than a proving service attached to someone else’s settlement system. +Your litepaper already points broadly in this direction: it identifies revm for EVM execution and SP1 behind a versioned proving interface. I would refine that architecture rather than restart it. +A zkVM and a zkEVM are not competing choices here. SP1 proves programs compiled for RISC-V; one such program can implement EVM execution. Succinct’s RSP project demonstrates this composition using Reth and SP1, although that repository explicitly warns that it is not audited or production-ready. +2. Why EVM is a sensible application layer +I would not make attracting developers harder while you are already solving difficult mining, consensus and proving problems. +EVM compatibility lets developers reuse familiar languages and infrastructure. Ethereum’s documentation identifies precisely that benefit: applications can use established tooling while gaining proof-based verification. +For Igneum, my preferred developer experience would be: +“Deploy familiar contracts, understand a small, clearly documented set of differences, and obtain verifiable execution.” +That is a stronger starting point than asking developers to adopt a new language, wallet model, execution environment and security model simultaneously. +However, compatibility needs to be demonstrated, not described as “everything runs unchanged.” Your ledger already acknowledges differences in block context, randomness and two-dimensional fees. Those can matter to application behaviour even where the bytecode executes successfully. +I would therefore make compatibility testing a product deliverable: representative contracts, wallet fee estimation, indexing, failed transactions, receipts and application-specific assumptions. +3. ZK-proven execution is also aligned with where the technology is going +This is not a case of choosing an architecture whose only purpose is Ethereum rollups. +The Ethereum Foundation’s current zkEVM programme is working towards proof-based verification of Ethereum’s own L1 execution, beginning with optional execution proofs and aiming later for mandatory proofs. Its approach explicitly involves general-purpose zkVMs. +That supports your architectural direction: +Keep a familiar application environment, while changing how execution is verified. +It does not establish that Igneum’s implementation is secure or that customers will choose it. It does mean you can build on a substantial shared engineering direction rather than invent every component. +My recommendation is to benefit from that work while concentrating your own effort on what is distinctive: accessible operators, distributed proving, reliable payments and the GPU-mined base layer. +4. I would not turn Igneum into an Ethereum L2 by default +Using EVM execution and ZK proofs does not require moving Igneum “onto Ethereum.” +A conventional Ethereum ZK-rollup uses Ethereum to enforce state updates and make the necessary state-reconstruction data available. That is a different security and settlement arrangement from operating a sovereign L1. +An L2 could be the better choice for a project whose primary objective was Ethereum settlement and an Ethereum-facing application. But it would not automatically be a better implementation of your objective: an independent, durable home for GPU operators. +There is a real cost to choosing sovereignty: you must establish your own consensus security, data availability and credible cross-chain verification. Adding execution proofs does not make those responsibilities disappear. +My preferred commercial relationship is: +Serve Ethereum and other networks without requiring Igneum to become subordinate to one of them. +Customers should be able to purchase supported proofs for their existing systems. Requiring every customer to migrate its application to Igneum would unnecessarily narrow the business. +5. The proving business should be broader than your own zkEVM +This is the most important strategic refinement. +Make EVM the main application interface, but do not make EVM execution the only useful work your proving infrastructure can eventually support. +A general-purpose zkVM gives you a potential route to additional verifiable workloads. It does not make every proof format interchangeable: each supported service still needs its own validated program, inputs, verification rules, performance measurements and delivery requirements. SP1’s general-purpose execution model supports that broader direction. +I would start narrowly: +First: reliably prove Igneum’s own execution. +Next: support one external customer’s exact workload, with repeat paid jobs. +Then: add further workloads where the existing operator fleet has a demonstrated advantage. +Your economics page still describes the external proving market as unbuilt. That is an opportunity to shape correctly—not established demand that should already be included in revenue assumptions. +Igneum should not need to win a contest for the largest application ecosystem before its operators can sell useful computation. +6. The conditions that make this the right choice +I would keep this architecture only while enforcing four requirements. +Proofs must become a protocol guarantee +Your ledger currently states that proof verification occurs outside the consensus path in proving v0; a modified producer can include a matching statement without the valid proof and cause an undeserved payout. +Closing that gap is essential. Otherwise, the network is demonstrating proving activity rather than enforcing a permissionless proving economy. +The hardware requirements must match the miner promise +The litepaper currently distinguishes NVIDIA proving from AMD and Apple mining support. That is an important limitation to preserve in the product language. +I would judge the proving stack on the complete pipeline: inputs, proving, aggregation, verification, payment, memory footprint and mining income forgone. +A fast shard result is not sufficient when aggregation or memory pressure makes ordinary operators uncompetitive. +Proof-system flexibility must not become arbitrary acceptance +Keep the implementation replaceable, but pin the permitted program identities, verifier versions and security parameters in the protocol. +My recommendation is one well-tested backend first, a clean replacement interface, and independent implementations where justified later—not several immature backends accepted interchangeably. +The Ethereum Foundation’s security work emphasises that proving speed is insufficient without soundness analysis and appropriate security margins. That is directly relevant to deciding which optimisations and versions Igneum can safely adopt. +Proving must not become the authority to control the chain +I would preserve your separation between winning the mining lottery and producing proofs. +But also test whether a concentrated proving provider could stall useful operation by withholding service. The design needs replacement operators, usable inputs, reassignment and explicit behaviour during proof delays. +Separate responsibilities on paper are not enough; they must remain separable during a failure. +7. What “zkEVM” should—and should not—mean in your positioning +I would not lead with: +“We are another zkEVM.” +I would lead with: +“A GPU-secured network for Ethereum-compatible applications and verifiable computation.” +Then explain the proof architecture underneath it. +Also keep three boundaries explicit: +Proven execution is not automatically finality. +EVM compatibility is not Ethereum security. +ZK technology does not automatically make transactions private. Ethereum’s rollup documentation explicitly notes that published state-reconstruction data is public; privacy requires additional application or protocol design. +And none of these choices, by itself, solves specialised-hardware competition. Your mining-resistance programme remains a separate obligation. +My judgement +Yes: stay with EVM-compatible, ZK-provable execution. I would not switch to a new application VM, develop a bespoke proof system, or convert Igneum into an Ethereum rollup just to follow a category label. +The strongest architecture for your stated purpose is: +A sovereign GPU-mined L1, familiar EVM applications, an established and versioned zkVM proving engine, and a proving service capable of serving customers beyond Igneum. +EVM is the right front door. Verifiable computation is the broader opportunity. Keeping ordinary operators competitive is the differentiator you still have to prove. \ No newline at end of file diff --git a/docs/plans/igneum-2.0.md b/docs/plans/igneum-2.0.md new file mode 100644 index 000000000..043699516 --- /dev/null +++ b/docs/plans/igneum-2.0.md @@ -0,0 +1,150 @@ +# Igneum 2.0 + +Decided 8 October 2026, 17:45 BST. The testnet is held (go cut acaf08b0 never ran; the three seeds idle for D5). Devnet 3 is the network. The miner line restarts at v2.0.0. Everything below is a pin: a box, an owner, a pass condition. A pin closes only with a landed document and the pass condition met, never with a plan. + +## The objective + +Durable GPU competitiveness, not chip destruction. Four properties, all holding without assuming a future emergency algorithm change: + +1. A specialised miner cannot remove much cost without losing substantial performance. +2. Ordinary operators can obtain competitive hardware, software and access to rewards. +3. Mining and proving stay economically sustainable as the network grows and issuance falls. +4. The above hold with no rescue upgrade assumed. + +A manufacturer with a profitable product is not the failure. An exclusive, durable advantage large enough to displace the accessible GPU fleet is. The target is contestable mining. + +Positioning line (served text, every page): "A GPU-secured network for Ethereum-compatible applications and verifiable computation." Never "another zkEVM". Three boundaries stated wherever the proof architecture is explained: proven execution is not finality; EVM compatibility is not Ethereum security; ZK is not privacy. + +## Standing rules carried in (do not re-decide) + +- [ ] More layers is not more resistance. A smaller generator whose every accepted program is strong beats a larger one with occasional weak programs. +- [ ] Rejected knobs (long programs, select trees, W=8/W=32, SM count, memory clock) stay out and stay as regression controls. Never resurrected under new names. +- [ ] The adversary is re-optimised after every change. Synthesis k is never a lower bound; placed rows score. +- [ ] GPU-cost budget is set before results (10 percent at the lock). No ratio is bought with honest GPU energy. +- [ ] "Every chip dies within a family epoch" is out of the baseline economic model. Chip-arrival percentages are not published. +- [ ] No ASIC detection in consensus. No hardware whitelists, attestation, per-address quotas or self-reported GPU bonuses. +- [ ] Rotation is optional to the security argument. Seed delay is evaluated only as seed-selection protection. +- [ ] Energy advantage, economic advantage and response capability are reported separately. Cohort = the discrete-GPU population, used cards included. +- [ ] Mining resistance, proving competitiveness and system stability are three questions with three answers. + +## D1. A frozen, reproducible baseline + +Owner: coordinator (Counter ASIC 3.0) with the hash lane and the node lane. + +- [ ] One exact generator, verifier, dataset policy, compiler configuration and measurement harness, pinned by digest and served. +- [ ] Pending measurements closed: placed 64-register rows, PC 1 lock row, 5.5 GiB coexistence rows, mixed FP32 (optional branch, must not delay). +- [ ] Mining and proving measured together on the final configuration, not combined on paper. +- [ ] Wall power alongside device telemetry; accepted work, rejected work, compile time, memory use, sustained thermals. +- [ ] Reference GPU population published: several vendors, memory sizes, generations, used cards (5090, 5080, 4090, 3090, 9070 XT, RX 7600 8 GB, Arc, Apple). +- [ ] Two tests per class: existing owner (power, wear, fees, alternative use) and new entrant (purchase, operating, resale). +- [ ] Central measure served: cost per accepted unit of work = (annualised hardware + power + hosting, failures, fees) / annual accepted work. +- Pass: an independent operator reproduces the baseline within declared tolerances from the served kit alone. + +## D2. Two architectural experiments, not twenty knobs + +Owner: class v6 invention lane (a) and the multi-family adversary lane (b). + +- [x] (a) Reorganise existing work for unavoidable live state and resource coupling, counts held constant. RESULT 8 Oct 17:25: KILL as a class. Only the window width reaches the chip (+1.2 pJ per lane-op at N5); rearranging the dependency graph of the same ops moves neither side. Document: docs/analysis/class-v6/connected-state.md. The generator variant and liveness tool stay behind a flag. +- [ ] (b) Attack memory sharing, recomputation and data-local execution against v6 (ProgPoW review threat: dataset split across processors, compute moved to the data). Price the cheapest combination of moving state, moving data, recomputing and local resources, not the expected architecture. +- [ ] Cumulative memory complexity and bandwidth hardness mapped onto the actual evaluation across many hashes (shared datasets, partial caches, recomputation, multiple engines amortising setup). Which trade-offs are bounded, which rest on physical-design experiments. +- [ ] Selective participation: distribution of the specialist's advantage across programs and epochs, not the mean; downtime, difficulty adjustment, re-entry included. +- [ ] Cryptographic review of the template, nonce, expensive work and result binding: no expensive intermediate reused across cheap winning attempts. +- Pass: the candidate improves against re-optimised adversaries across the declared population within the preset cost and verification limits. Otherwise v6 stands and the experiment is published as a failure. + +## D3. A programmable adversary allowed to survive + +Owner: multi-family adversary lane with the k lane (shadow k from RTL). + +- [ ] Whole-system cost minimised across every published family, free to change lane count, register implementation, instruction storage, memory technology, scheduling and support hardware. +- [ ] Physical implementation (placed), not logic synthesis. Uncertainty published with every row. +- [ ] Three-year stress life for the programmable chip; survival across the family bank assumed. +- [ ] Next-generation opponents in the matrix: programmable compute without graphics (Vortex class), chiplets and 3D packaging (UCIe), denser external memory (24 Gb GDDR7 boards), data-local hybrids, proof accelerators (PipeZK class), an operator combining mining and proving devices. +- [ ] Dataset schedule (5.5 / 8.5 / 11.5 GiB) scored per step: adversary burden against commodity burden (cards excluded, mine-and-prove lost, replacement cost). A step that hurts ordinary operators more than an adaptable adversary is rejected. Default: epoch-defined bounded dataset with a conservative published support horizon. +- [ ] State coupling of the dataset justified or dropped after sync, recovery, storage and adversarial state-growth costs. +- Pass: the best supported cost and energy advantage sits inside the chosen competitiveness envelope, with uncertainty published. 1.5x energy is a research goal, not the pass criterion. + +## D4. A five-year coexistence model + +Owner: research lane (economics), with the k lane's rows as input. + +- [ ] Replaces the capex wall. Mandatory stress case: development already paid for; the opponent covers manufacturing, deployment and operation only. +- [ ] Growing and shrinking networks, reduced issuance, cheap and dear electricity, GPU replacement and resale on both sides, changing proving demand, private mining and hardware sales, several productive lifetimes, cheaper derivative chips. +- [ ] Miners react: no fixed market shares. +- [ ] Outputs: cost advantage, replacement economics, accessible supply, break-even electricity price per class, supplier and operator dependence. +- [ ] Tariff advantage shown separately from hardware advantage (the 6.25x illustration). +- [ ] Economics page: the tip-share discrepancy resolved; explicit user-funded proving payment with congestion pricing, burn treated separately; hard cap and no development tax kept. +- [ ] Profit-maximising operator simulation: mine, internal prove, external prove, off; under a proving demand spike, a token price fall, a major prover leaving, a specialised entrant in either market. Pass if pricing and capacity rules restore service without an administrator. +- Pass: the model names credible conditions for sustained commodity participation and names where it fails. A result needing a small network, token appreciation or scheduled ASIC death has not passed. + +## D5. A no-rescue network exercise + +Owner: node lane with the build-server lane (the three ex-testnet seeds are the start). + +- [ ] Prerequisite: proof verification enforced in consensus (verifier_in_consensus, proof_rule_active_from) live on the exercise network. +- [ ] No founder-operated mining, proving, aggregation or mandatory distribution infrastructure. +- [ ] Cross epoch boundaries, interrupt signing, partition the network, remove major operators, hostile proof submissions, independently written clients. +- [ ] A withholding concentrated prover: replacement operators, usable inputs, reassignment, explicit behaviour during proof delays. +- Pass: specified behaviour with no emergency algorithm change and no privileged intervention. + +### The partition row (finality boundary lane, 8 October 2026; the full statement is `docs/spec/finality-guarantees.md`, the tables `sim/results_v2.md` "Rule v4") + +The chain's behaviour across a partition, with no emergency change and no privileged intervention, as rule v4 specifies it and the simulator measures it (the simulator is the checkpoint-level model of `sim/finality_v2.py`: no DAG, 1,000 Pareto keys, each side retargeting and counting only the blocks it has seen; seeds 7 and 11; run on igneum-build-3 under the lease tool at nice 19, 16:02 to 16:09 BST). Known-failed first: rule v3 (the devnet's rule today, `finality_v3_activation_daa`) expires its frozen weight table one window after the last certified checkpoint, which is a timeout, and the external review of 8 October 2026 (accepted 16:1x BST) found that a timeout alone cannot tell a node whether missing miners are gone or on the other side of a partition. Measured: under v3 both sides of a 31-day honest partition lock alone at day 30.00 (50/50: 2,679 to 2,701 conflicting locks; 60/40: 2,822 to 2,870; 55/45: 2,795 to 2,820), with no attacker. + +The behaviour (rule v4, the anchored table): a checkpoint locks when two thirds of all 30-day weight at the checkpoint AND two thirds of the weight table anchored at the last certified checkpoint have signed it; the anchored table never expires by time; it is replaced only by a certificate that passes it, reduced only by a strip (3.6) or moved by a succession (W5), both functions of the chain. When too much weight is missing, finality pauses and the chain runs on proof of work: blocks, ordering, execution and every program rotation continue (every seed is drawn from a chain block below the lead on the header's own chain, certified or not; the hourly program, the weekly table and the family epoch all change through a pause of any length, on both sides of a partition; only the emergency flip vote waits). No certified checkpoint is ever reversed. The pause ends when the missing weight returns, hands over, or is stripped, or, after a full window with no certificate, under the majority-continuity recovery: a certificate on the chain through the last certified checkpoint whose signers hold two thirds of the sliding table and strictly more than half of the anchored table, verifiable by any node from the chain alone. Two such certificates share a signer, so at most one side of a partition can recover without equivocation; an even split stays paused until the heal. + +- [x] Partition the network, 31 days, 50/50, 60/40, 55/45: v4 pause (no recovery): no side locks, 0 conflicting locks, every pre-heal lock kept, first lock 0 minutes after the heal, 0 stalls in the three hours after; v4 recovery: the same at 50/50; at 60/40 and 55/45 the larger side recovery-locks once at day 30.00 and then locks normally, the smaller side never, 0 conflicts, kept, heal 0 minutes (N1). +- [x] The 40/40/20 split, 150 minutes and 31 days, honest: no side locks under either v4, 0 conflicts, the heal locks at once (N2). With a 20 percent equivocator reaching both 40 sides and mining on one: one side recovers at day 30.00, the other never (after a window the equivocator is under dust on the other side and not in its voter list), 0 conflicts (N2). +- [ ] The recovery's bound, the equivocator mining on both sides (N1b at 10, 20, 34 percent across 50/50; N2b at 60/60): two recovery locks need a month-long partition plus equivocating keys above dust on both sides whose share exceeds the split's imbalance; the pair is a 3.11.4 conflict after the last certified checkpoint, never a reversal. Rerun queued on build-3 at 16:40 BST (the first run was stopped by the drain at 16:39); the rows land in the 20:00 report at the latest. +- [x] Interrupt signing while mining continues, 34, 40, 45 percent for 24 hours and 34 percent for 31 days: every checkpoint stalled for the whole silence, first lock 0 minutes after the resume, 0 conflicts; the recovery adds nothing here, since a silent third keeps its share of the sliding table and the signers fail the two-thirds floor itself (N3). +- [x] Remove major operators at once, 35 and 50 percent of weight, 31 days: v3 and v4 recovery lock at day 30.00 at 35 percent; v4 pause never; at exactly half the recovery is a knife edge (one seed day 30.23, one never); 0 conflicts (N6). Old keys bought or stolen and withholding (worth 40 percent, the holder at 30 percent of hashrate): v2 day 20.9, v3 day 30.00, v4 pause never (one purchase is a permanent veto, the cost of the pause-only variant), v4 recovery day 30.00; compromised keys stripped by their owners' self-equivocation on day 1: the first lock the same day (N4). +- [x] Cross epoch boundaries while finality is paused: every seed is a chain block below the lead on the header's own chain, certified or not, so 744 hourly programs change through a 31-day pause and nothing waits (`docs/spec/finality-guarantees.md` section 8, consistent with `04-seeds-and-vdf.md` 4.3 and 4.4 and the era VDF record; O-4.3 closed). Derived; the harness reading of the program id on both sides of a paused boundary is owed (below). +- [ ] The harness row on real nodes (three igneumd on the 60x file, `tools/finality-attacks/v3.mjs split50` with the split past the window): the known-failed v3 line (both sides lock alone, conflicting certificates at the heal) queued on build-3 at 16:40 BST on the 0.3.25 node pair; the v4 line needs the node change (one function, `frozen_table` without its drop, plus `continuity_met`, behind `finality_v4_activation_daa`; the node lane). +- [ ] The founder's choice, one switch: the recovery as written (recommended: its failure needs an attacker, a month-long partition and equivocation the chain then strips, and it never touches certified history) or the pause only (strictly stronger safety; a sudden honest loss of a third pauses finality until succession, a strip or an operator's trusted certificate on the chain through the last lock). +- Not guaranteed, stated: at or above one third of equivocating weight two certificates can coexist (reported, never resolved); a recovery lock's bound is the imbalance rule above, not one third; a loss of half or more of the last certified table has no in-protocol exit; an even split pauses until the heal; the first month; body availability and execution correctness (proven execution is not finality: the four interface words, included, executed, proven, finalised, are defined once in section 9 of the statement with where each interface shows them today). + +## Pools, software and participation (launch requirements) + +Owner: pool lane. + +- [ ] Vote keys stay with the miner at protocol level: the member's retained voting key committed into its work, payment aggregation separate, verifiable, pool identity substitution resisted. +- [ ] Non-custodial payouts, practical minimum payouts, local work verification, low-bandwidth participation (P2Pool as precedent, not code). +- [ ] Accepted-work penalty measured for home internet against datacentre connections. +- [ ] Optimisation work, compiler settings and safe tuning logic published; Ember reaches good operating points without third-party software. + +## Architecture and product (review 2) + +Owner: node lane (protocol), reference-apps lane (compatibility), second-prover lane (backend policy), site lane (positioning). + +- [ ] EVM-compatible execution for developers (revm); SP1 as the one well-tested proving backend behind the versioned interface; sovereign GPU-mined consensus. Not an Ethereum L2. +- [ ] Program identities, verifier versions and security parameters pinned in the protocol. One backend first; a second only where justified, never interchangeable immature backends. +- [ ] Compatibility as a product deliverable: representative contracts, wallet fee estimation, indexing, failed transactions, receipts, application assumptions; the documented set of differences (block context, randomness, two-dimensional fees). +- [ ] Hardware language kept honest: NVIDIA proving against AMD and Apple mining; the full pipeline judged (inputs, proving, aggregation, verification, payment, memory, mining income forgone). +- [ ] Proving business ladder: own execution; one external customer's exact workload with repeat paid jobs; further workloads only where the fleet has a demonstrated edge. The external market stays out of revenue assumptions until built. +- [ ] Every served page carries the positioning line and the three boundaries; "zkEVM" appears only under the architecture explanation. + +## Versioning + +- [ ] Miner v2.0.0 cut from the 0.3.26 line with the audit's window rebuild, the 2.0 served text and the baseline kit digest. Three-part versions, canary gate, one-box rollout, commit-string read-back, as before. +- [ ] Node 2.0.0 follows once D5's prerequisite (enforced proving) is on Devnet 3. + +## Leadership tests (review 3) + +Owner: main. These are the tests the site may claim progress against, never completion without the evidence. + +- [ ] Benchmarks published against operating systems, not whitepapers: Ravencoin KAWPOW (same stated objective), Ergo (GPU memory-hard, live pooling and emission changes), Firo's reference miner (NVIDIA and AMD, no developer fee, within about 1 percent of closed miners: the bar Ember meets or beats). +- [ ] Miners stay through hard conditions (compatibility, operating cost, payouts, control), measured, not launched. +- [ ] Customers repeatedly pay for proofs at prices that carry reliable service and operator margin. Pilots and announcements do not count. +- [ ] The network runs without the founding team: independent clients, rule enforcement, failures survived, no emergency intervention (D5). +- [ ] Served ranking language: "serious contention for the top of the GPU-mining space on engineering and operator proposition" is the ceiling; no "number one" claim before comparative results and adoption exist. + +## Site reset + +Owner: site lane. + +- [ ] The served site starts at Igneum 2.0: no 0.x release history, no changelog before 2.0, no Counter ASIC 2.0 / 3.0 / 4.0 names, no testnet pages or links, no old-version evidence rows, no status-log history. +- [ ] The pre-reset site is tagged site-pre-2.0 on the box mirror; the repo keeps everything, the site serves none of it. +- [ ] Devnet 3, the explorer, the faucet and the reference apps stay: they are the network, not history. +- [ ] Every page carries the positioning line; the miner page serves v2.0.0 when it is cut and nothing older. +- [ ] The facts page is wiped: it restarts with only 2.0 facts, each traceable to a landed document. +- [ ] The FUD ledger is written fresh against this brief: every entry names the pin it answers; the old ledger and its decisions stay in the repo as history and are not served or linked. +- [ ] Copy sweep beyond the site: the litepaper and the apps (miner, wallet, Windows host, HiveOS card) are edited to the 2.0 reference where the text differs from it (positioning line, three boundaries, EVM + SP1 + sovereign consensus stated as three decisions, NVIDIA proving against AMD and Apple mining stated plainly, no rotation-as-defence claims, no chip percentages, no 0.x history, no testnet). Dataset state-coupling in the litepaper is marked "under evaluation (D3)" until justified or dropped. diff --git a/docs/spec/finality-guarantees.md b/docs/spec/finality-guarantees.md index 6abe1d76f..e9d33c6cc 100644 --- a/docs/spec/finality-guarantees.md +++ b/docs/spec/finality-guarantees.md @@ -16,7 +16,7 @@ This document states, in one place and in the form an external reviewer can chec - Weight is blocks: a key's weight at checkpoint `C` is the number of blue blocks in the trailing 30-day window of `C`'s past that name the key (W2; the simulator counts DAA time, the node counts DAA score along the selected chain's mergesets, the rule of 3 October 2026 denominates in past-median time). Nothing but blocks changes it: no stake, no bond, no coins. - The **sliding table** `T(i)` at index `i` is the weight of every key above dust (100 blue blocks in the window, W3) and not stripped, computed at `C_i` from its own past. The **anchored table** `T_f` is the sliding table at `C_f`, the highest certified checkpoint whose block lies on the selected chain of `C_i` (Q5's "frozen table", renamed here because under this document it does not expire). Both are functions of the chain, so every node with `C_i`'s past computes the same tables, and a certificate carries enough (index, block, bitmap over the canonical voter list) for anyone to verify it against them. -- **How the eligible set changes, and over what window.** A key enters when its window count reaches 100 blue blocks (about 9 to 10 days for the smallest honest key, 20 days for every key of a 1,000-key Pareto network from zero history, measured in `sim/results_v2.md` A). A key leaves the sliding table by ageing out (every block leaves the window 30 days after it was mined, whoever holds the key), by dust, by the equivocation strip (3.6: zero weight from the first block in `C`'s past that carries the evidence, for one window), by succession (W5: its weight moves once to a successor that both keys signed for, a function of the chain, carried in any block) and by the leave item where that rule is active (`finality_leave_activation_daa`; Devnet 3 from DAA 93,600, about 20:01 UK on 8 October 2026). The anchored table changes in exactly two ways: it is **replaced** when a certificate passes it (then `T_f` becomes the table at the new certificate), and it is **reduced** by a strip or moved by a succession, both functions of the chain (the node applies "the bans known now" to `T_f`, section 3's Q5 row). It is never changed by time. The window over which the set can turn over completely is therefore one weight window, 30 days, **and only while certificates keep forming**; while no certificate forms, the anchored table holds the set as it was at the last certified checkpoint. +- **How the eligible set changes, and over what window.** A key enters when its window count reaches 100 blue blocks (about 9 to 10 days for the smallest honest key, 20 days for every key of a 1,000-key Pareto network from zero history, measured in `sim/results_v2.md` A). A key leaves the sliding table by ageing out (every block leaves the window 30 days after it was mined, whoever holds the key), by dust, by the equivocation strip (3.6: zero weight from the first block in `C`'s past that carries the evidence, for one window), by succession (W5: its weight moves once to a successor that both keys signed for, a function of the chain, carried in any block) and by the leave item where that rule is active (`finality_leave_activation_daa`; set at DAA 93,600 on Devnet 3's object). The anchored table changes in exactly two ways: it is **replaced** when a certificate passes it (then `T_f` becomes the table at the new certificate), and it is **reduced** by a strip or moved by a succession, both functions of the chain (the node applies "the bans known now" to `T_f`, section 3's Q5 row). It is never changed by time. The window over which the set can turn over completely is therefore one weight window, 30 days, **and only while certificates keep forming**; while no certificate forms, the anchored table holds the set as it was at the last certified checkpoint. - Keys are free (W6): every rule draws by weight, never per key. ### 2.2 The adversary