Model 1 — Centurion Day-0 Launch Topology (ASCII Diagrams)¶
Visual companion to final_report.md / topology.md, reports/topology_launch_recommendation.json, reports/topology_optimizer_summary.md, reports/topology_failure_matrix.md, reports/topology_cost_model.json, and reports/aws_core_contract_options.md.
Selected family aws_core_plus_edge_plus_public_boot_sentry · profile balanced_day0 · V=18, T=12 · AWS CORE share 2/3 · solver Gurobi 13.0.1 (OPTIMAL) · AWS CORE year-1 $3,381 vs $1,400 budget → budget fit FAIL.
1. Day-0 Topology — Three Tiers¶
Three trust tiers: private AWS CORE (truth + validators), provider-diverse EDGE (validators only), and cheap public boot/sentry (keyless joinability).
CENTURION DAY-0 — V=18 validators, T=12 finality threshold
┌──────────────────────────── TIER 1 · AWS CORE (private, trusted) ───────────────────────────┐
│ 3 nodes · 4 validators each = 12 validators (2/3 of V) · oracle truth sources │
│ │
│ ┌───────────────────┐ ┌───────────────────┐ ┌───────────────────┐ │
│ │ aws-core-a │ │ aws-core-b │ │ aws-core-c │ │
│ │ us-east-1 / 1a │ │ us-east-2 / 2a │ │ us-west-2 / 2a │ │
│ │ m6a.xlarge │ │ m6a.xlarge │ │ m6a.xlarge │ │
│ │ EL go-centurion │ │ EL reth/rustcen │ │ EL nethermind │ │
│ │ CL Prysm │ │ CL Lodestar │ │ CL Lighthouse │ │
│ │ ⛁ x4 · signer │ │ ⛁ x4 · signer │ │ ⛁ x4 · signer │ │
│ │ ORACLE source ● │ │ ORACLE source ● │ │ ORACLE source ● │ │
│ └───────────────────┘ └───────────────────┘ └───────────────────┘ │
│ └──────────── private CORE full mesh (no public raw APIs) ──────────┘ │
└─────────────────────────────────────────────────────────────────────────────────────────────┘
▲ private/allowlisted peering ▲ 2-of-3 oracle reads
┌──────────────┴───────────── TIER 2 · EDGE (validators, not truth) ────────────────┐
│ 2 nodes · 3 validators each = 6 validators (1/3 of V) · NOT oracle sources │
│ │
│ ┌─────────────────────────┐ ┌─────────────────────────┐ │
│ │ edge-hetzner-a │ │ edge-gcp-a │ │
│ │ Hetzner · fsn1 │ │ GCP · europe-west4 │ │
│ │ CX42/CPX41 (8 vCPU) │ │ n2-standard-4 (4 vCPU)│ │
│ │ EL go-centurion │ │ EL reth/rustcen │ │
│ │ CL Prysm │ │ CL Lodestar │ │
│ │ ⛁ x3 · signer · ~$38/mo│ │ ⛁ x3 · signer · ~$145/mo│ │
│ └─────────────────────────┘ └─────────────────────────┘ │
└───────────────────────────────────────────────────────────────────────────────────┘
▲ public P2P / discovery only (no keys, no raw APIs)
┌──────────────┴──────────── TIER 3 · PUBLIC BOOT/SENTRY (keyless) ────────────────┐
│ 2 nodes · 0 validators · public P2P joinability only │
│ │
│ ┌─────────────────────────┐ ┌─────────────────────────┐ │
│ │ boot-sentry-a │ │ boot-sentry-b │ │
│ │ Hetzner · nbg1 │ │ OVH · bhs │ │
│ │ CX22 (~$8/mo) │ │ Starter VPS (~$10/mo) │ │
│ │ ⛁ x0 · NO keys │ │ ⛁ x0 · NO keys │ │
│ │ public: 30303, 9000 │ │ public: 30303, 9000 │ │
│ └─────────────────────────┘ └─────────────────────────┘ │
└──────────────────────────────────────────────────────────────────────────────────┘
Legend: ⛁ = validator ● = trusted oracle source signer = local Dirk cell
V = 3c + 2e = 3·4 + 2·3 = 18 T = ceil(2V/3) = 12 offline budget = 62. Validator-Count & Finality Model¶
The fixed algebra that drives every count in the model.
┌─────────────────────────────────────────────────────────────────┐
│ V = 3c + 2e c = validators per AWS CORE node = 4 │
│ T = ceil(2V / 3) e = validators per EDGE node = 3 │
│ offline_budget = V−T C = 3c (total CORE validators) = 12 │
│ C = 3c E = 2e (total EDGE validators) = 6 │
│ E = 2e │
└─────────────────────────────────────────────────────────────────┘
c=4 ─┐ ┌─ CORE = 3·4 = 12 (2/3 share)
├──► V = 3·4 + 2·3 = 18 ──► ┤
e=3 ─┘ └─ EDGE = 2·3 = 6 (1/3 share)
V = 18 ──► T = ceil(36/3) = 12 ──► offline_budget = 18 − 12 = 6
Finality ladder (validators that may go offline before finality breaks):
18 ┤██████████████████ all online (baseline)
│
15 ┤███████████████ one EDGE down (−3) ✔
14 ┤██████████████ one CORE node/region/AZ (−4) ✔
12 ┤████████████ both EDGE OR CORE-only ═══ ◄ T = 12 finality floor
│ ══════════════════ T threshold — must stay ≥ 12
11 ┤███████████ one EL or CL family down ✗ below T (accepted risk)
│
6 ┤██████ AWS-wide / CORE-overlay ✗✗ finality FAIL (accepted)
└──────────────────────────────────────────────────────────────
Key property: CORE alone (12) == T (12). AWS CORE can hold finality with BOTH
EDGE nodes offline — that is why CORE is sized at exactly two-thirds of V.3. AWS CORE — Regions, Clients & Oracle Quorum¶
Three distinct AWS Regions, three distinct AZs, and deliberately different EL+CL client pairs per node so no single client family lives on all CORE truth sources.
us-east-1 / 1a us-east-2 / 2a us-west-2 / 2a
┌────────────────────┐ ┌────────────────────┐ ┌────────────────────┐
│ aws-core-a │ │ aws-core-b │ │ aws-core-c │
│ EL: go-centurion │ │ EL: reth/rustcen │ │ EL: nethermind │
│ CL: Prysm │ │ CL: Lodestar │ │ CL: Lighthouse │
│ Beacon API (priv) │ │ Beacon API (priv) │ │ Beacon API (priv) │
└─────────┬──────────┘ └─────────┬──────────┘ └─────────┬──────────┘
│ │ │
└────────────┐ │ ┌─────────────┘
▼ ▼ ▼
┌───────────────────────────────────┐
│ RISK ORACLE / SEAT-MANAGER │
│ read quorum = 2-of-3 CORE │
│ writer = active / standby │
│ (active/active REJECTED) │
└───────────────────────────────────┘
▲ ✗
accepts: 2 matching CORE sources rejects: EDGE truth,
(finalized checkpoint + head slot) user-node truth
Stale-source guard: compare finalized checkpoint & head slot across all 3 CORE
sources → reject lagging/divergent → require 2 matching before any seat transition.4. Client-Family Allocation (minimal_family_deviation)¶
Exact one-third-per-family equality is mathematically impossible with one client pair per host at c=4, e=3. The optimizer reports the deviation instead of faking it.
Target per family = V/3 = 6.0 validators Max deviation = 2.0
EXECUTION LAYER (EL) CONSENSUS LAYER (CL)
───────────────────────────────── ─────────────────────────────────
go-centurion ███████ 7 (core-a+hetz) Prysm ███████ 7 (core-a+hetz)
reth/rustcen ███████ 7 (core-b+gcp) Lodestar ███████ 7 (core-b+gcp)
nethermind ████ 4 (core-c) Lighthouse ████ 4 (core-c)
───────────────────────────────── ─────────────────────────────────
▲ target line = 6 ▲ target line = 6
Why not exact: node-level single-client assignment cannot split a host's
validators across families; repo does NOT prove safe multi-client services per
host → exact_el_family_equality = false, exact_cl_family_equality = false.
Consequence: losing the 7-validator family drops 7 offline → 11 online < T=12.5. Failure Matrix (20 scenarios)¶
SCENARIO ONLINE OFFLINE FINALITY ORACLE ACCEPTED
──────────────────────────────────────────────────────────────────────────────────────
one_aws_core_node_outage 14 4 ✔ PASS ✔ no
one_aws_core_region_outage 14 4 ✔ PASS ✔ no
one_aws_core_az_outage 14 4 ✔ PASS ✔ no
one_edge_node_outage 15 3 ✔ PASS ✔ no
hetzner_edge_outage 15 3 ✔ PASS ✔ no
gcp_edge_outage 15 3 ✔ PASS ✔ no
both_edge_nodes_offline 12 6 ✔ PASS ✔ no ◄ on floor
one_public_boot_sentry_node_outage 18 0 ✔ PASS ✔ no
both_public_boot_sentry_nodes_offline 18 0 ✔ PASS ✔ YES
complete_aws_provider_outage 6 12 ✗ FAIL ✗ YES ◄◄ key risk
complete_gcp_provider_outage 15 3 ✔ PASS ✔ no
complete_hetzner_provider_outage 15 3 ✔ PASS ✔ no
one_el_client_family_outage 11 7 ✗ FAIL ✔ YES
one_cl_client_family_outage 11 7 ✗ FAIL ✔ YES
one_signer_domain_outage 14 4 ✔ PASS ✔ no
one_active_oracle_writer_outage 18 0 ✔ PASS ✔ no
standby_oracle_writer_mistakenly_active 18 0 ✔ PASS ✗unsafe no
network_partition_between_core_and_edge 12 6 ✔ PASS ✔ YES
public_p2p_layer_degradation_private_core_ok 18 0 ✔ PASS ✔ YES
private_core_overlay_vpn_failure 6 12 ✗ FAIL ✗ YES ◄◄ key risk
──────────────────────────────────────────────────────────────────────────────────────
Finality FAILs (all explicitly ACCEPTED Day-0 risks, not silent):
┌─ complete_aws_provider_outage ...... 6/18 online — all CORE truth is on AWS
├─ private_core_overlay_vpn_failure .. 6/18 online — CORE control plane halts
├─ one_el_client_family_outage ....... 11/18 — exact family equality infeasible
└─ one_cl_client_family_outage ....... 11/18 — exact family equality infeasible6. Network Exposure & Security Policy¶
ROLE PUBLIC? EXPOSES NEVER PUBLIC
──────────────────────────────────────────────────────────────────────────────
AWS CORE private mesh only (nothing public) raw RPC, Beacon,
Engine, metrics,
Dirk, signer
EDGE P2P may be public 30303, 9000 (if policy) raw RPC/Beacon/
Engine/metrics/signer
BOOT/SENTRY public 30303 tcp/udp, 9000 tcp/udp keys (has NONE)
Sensitive ports — PRIVATE BY DEFAULT on every role:
┌──────────────────────────────────────────────────────────────┐
│ 8551 Engine API 8545 EL RPC 8546 EL WS 5052 Beacon HTTP │
│ 6061 CL metrics 6062 VC metrics 13141 Dirk │
└──────────────────────────────────────────────────────────────┘
Public P2P ports — allowed ONLY on roles needing joinability:
┌──────────────────────────────────────────────────────────────┐
│ 30303/tcp 30303/udp 9000/tcp 9000/udp │
└──────────────────────────────────────────────────────────────┘
Signer topology: one active Dirk cell PER validator-bearing node (5 domains:
core-a/b/c + edge-hetzner + edge-gcp). No centralized cluster, no active/active.
Vouch → Dirk over mTLS. Standby signers fenced/offline/passive until failover.7. AWS Cost Reality vs Budget (year-1, USD)¶
The headline failure: the smallest compliant 3-node AWS CORE costs more than double the configured budget. The optimizer refuses to weaken the topology to hide it.
Per-node m6a.xlarge, standard_reserved_1yr, all_upfront, 200 GB gp3:
aws-core-a ████████████ $1,127 ($93.92/mo)
aws-core-b ████████████ $1,127 ($93.92/mo)
aws-core-c ████████████ $1,127 ($93.92/mo)
───────────────────────────────────────────────
AWS CORE year-1 total .... $3,381 ($281.75/mo amortized)
Budget vs actual:
$1,400 budget ██████████ ◄ configured cap
$3,381 actual ████████████████████████████████ ◄ selected cost
└──────────── violation = $1,981 (FAIL) ───────────┘
Costs reported SEPARATELY (outside the AWS CORE budget):
EDGE estimate ........ $2,196 / yr (Hetzner ~$38/mo + GCP ~$145/mo)
boot/sentry estimate . $216 / yr (Hetzner ~$8/mo + OVH ~$10/mo)
monitoring / archive / signers ... outside CORE budget by config flags
Cheaper REJECTED candidates (and why):
t3.xlarge $2,316 ✗ burstable allowed only in ultra_low_cost_day0
t4g.xlarge $2,643 ✗ ARM64 not confirmed by repo + burstable-only
m7a (apse1)$2,730 ✗ estimate-only row, not eligible vs live pricing
⇒ No compliant option fits $1,400. Mitigation: raise budget, temporary On-Demand,
or the explicitly-labeled ultra_low_cost_day0 burstable profile ($2,862).8. Optimizer Decision Flow (Gurobi 13.0.1)¶
┌───────────────────────────────────────────────┐
│ Build binary MILP: AWS contract × region × │
│ instance × payment × validator c/e pairs │
│ + region-used indicator constraints │
└───────────────────────┬───────────────────────┘
│
┌───────────────▼────────────────┐
│ Solve HARD-budget model first │
│ (AWS CORE year-1 ≤ $1,400) │
└───────────────┬────────────────┘
│ INFEASIBLE (status 3)
┌─────────────▼──────────────┐
│ Write IIS → gurobi_iis.ilp│ (records budget conflict)
└─────────────┬──────────────┘
│
┌───────────────────────▼─────────────────────────┐
│ Solve RELAXED model: minimize budget violation │
│ FIRST, then topology quality, cost, upgrade │
│ flexibility, operational complexity │
└───────────────────────┬─────────────────────────┘
│ OPTIMAL (status 2, gap 0, 0.037 s)
warm-start c=5,e=3 (V=21,T=14) ──┤ selected c=4,e=3 instead (lower cost,
│ still CORE-only liveness, AWS share 2/3)
▼
★ SELECTED: balanced_day0 / aws_core_plus_edge_plus_public_boot_sentry
V=18, T=12, violation $1,981, solution pool = 2 equivalent layouts
Profiles evaluated (all budget-fit = no):
aws_core_only_bootless_baseline V=6 AWS share 1.000
strict_two_thirds_aws_core V=18 AWS share 0.667
core_liveness_strict V=18 AWS share 0.667
one_aws_region_failure_strict V=18 AWS share 0.667
★ balanced_day0 V=18 AWS share 0.667 ◄ SELECTED
low_cost V=9 AWS share 0.333
growth_flexible_contract V=18 AWS share 0.667
ultra_low_cost_day0 V=18 AWS share 0.667 ($2,862)9. Roadmap — Day-0 to Provider-Diverse Production¶
DAY-0 FIRST EXPANSION INTERMEDIATE CORE FUTURE FULL
(this model) scale validators add non-AWS oracle DIVERSITY
───────────── ─────────────── ───────────────── ─────────────
3 AWS CORE grow V only after add non-AWS oracle- 7–9 validator
2 EDGE signer + monitoring capable CORE sources nodes; separate
2 boot/sentry + migration gates → reduces accepted public RPC /
V=18 pass; keep 1 Dirk AWS-wide outage risk Beacon / archive
AWS = cornerstone cell per val node tiers; V=45 lives
HERE, not Day-0
──────────●───────────────────●──────────────────●─────────────────────●──────────►
launch max resilience10. Full Explanation — Everything, From First Principles¶
Plain-language walkthrough of what Model 1 is, what every number means, and why the optimizer landed where it did. No prior context needed.
10.1 What this model is¶
Model 1 is the Day-0 launch plan for Centurion's validator infrastructure — the very first production deployment, deliberately small and conservative. Where Model 2 optimizes a larger 48-validator cloud topology, Model 1 answers a narrower question:
"What is the smallest, safest, AWS-anchored topology we can launch on day one — and what does it honestly cost?"
The output is a fixed three-tier architecture plus an honest accounting of where it fails (notably: it is over the AWS budget, and it cannot survive a total-AWS outage). The defining feature of this model is intellectual honesty — it refuses to weaken the topology to make the budget or the failure matrix look better than reality.
10.2 The vocabulary¶
| Term | Meaning |
|---|---|
| CORE | The trusted private heart: 3 AWS nodes that both run validators and serve as the oracle truth sources (the seat-manager / risk-oracle reads from them). |
| EDGE | Provider-diverse validator nodes (Hetzner + GCP) that carry stake for diversity but are not trusted as oracle truth. |
| boot/sentry | Cheap, public, keyless nodes that only provide P2P/discovery joinability. They carry zero validators and zero keys. |
| V / c / e | V = total validators; c = validators per CORE node; e = validators per EDGE node. |
| T | Finality threshold = ceil(2V/3). At least T validators must be online for finality. |
| offline_budget | V − T — how many validators may go dark before finality breaks. |
| EL / CL | Execution-Layer client / Consensus-Layer (beacon) client. Each validator node runs one EL+CL pair. |
| oracle / seat-manager | Centurion's control plane. It reads chain truth from CORE Beacon APIs to decide validator "seats." |
| Dirk / Vouch | Dirk = remote signer (holds keys); Vouch = the validator client that asks Dirk to sign. |
10.3 The counting model (where 18 and 12 come from)¶
Everything flows from two integer choices, c and e:
V = 3c + 2e (3 CORE nodes + 2 EDGE nodes)
T = ceil(2V/3) offline_budget = V − T C = 3c E = 2eWith the selected c=4, e=3: - V = 3·4 + 2·3 = 12 + 6 = 18 validators. - T = ceil(36/3) = 12 — at least 12 must stay online. - offline_budget = 18 − 12 = 6 — up to 6 validators may go offline safely. - CORE carries C = 12 (exactly two-thirds of V); EDGE carries E = 6 (one-third).
The crucial design property: CORE alone (12) equals T (12). That means AWS CORE can hold finality even if both EDGE nodes are completely offline. EDGE adds provider diversity and reward, but finality never depends on it. This is why CORE is sized at exactly 2/3 — not more (too expensive), not less (would break CORE-only liveness).
10.4 Why c=4, e=3 specifically¶
The optimizer's warm-start guess was c=5, e=3 (which gives V=21, T=14). It chose c=4 instead because: - c=4 is the smallest equalized pair that still keeps AWS CORE at exactly two-thirds of V and keeps CORE-only liveness (C ≥ T). - Smaller c → fewer validators → lower cost, while still satisfying every hard topology constraint. - The warm-start table shows c=5 with various e values either breaks the 2/3 AWS share, breaks CORE-only liveness, or remains budget-infeasible anyway — so c=5 buys nothing.
So c=4 is the cost-minimal point inside the feasible region. (V=45 — the number from an earlier plan — is explicitly a future target, not Day-0.)
10.5 The three tiers and why they exist¶
-
AWS CORE (Tier 1) — three
m6a.xlargenodes in three distinct AWS Regions (us-east-1, us-east-2, us-west-2), each in a distinct AZ. They are the only trusted oracle sources. Distinct Regions mean one Region outage removes exactly one CORE node (4 validators), leaving 14 online — well above T. Each runs a different EL+CL client pair so a single client bug cannot take down all three truth sources. -
EDGE (Tier 2) — one Hetzner node (fsn1) and one GCP node (europe-west4), 3 validators each. They add provider diversity (so the validator set is not 100% on AWS) but are deliberately not oracle truth sources — Centurion does not want its control-plane truth depending on third-party or user-operated nodes.
-
boot/sentry (Tier 3) — two cheap public VPS (Hetzner nbg1 + OVH bhs) that are keyless and non-validating. Their only job is public P2P joinability — letting outside peers discover the network — without exposing any sensitive API or key. They are the only nodes allowed to be public, precisely because they hold nothing valuable.
10.6 The oracle / seat-manager design (2-of-3 quorum)¶
Centurion's control plane must not act on bad or stale chain data. So: - It reads from 3 private AWS CORE Beacon APIs and requires a 2-of-3 quorum — at least two CORE sources must agree (matching finalized checkpoint + head slot) before any seat-manager state transition. - EDGE and user nodes are rejected as truth sources by default — only CORE counts. - The writer is active/standby, never active/active. Two writers acting at once ("standby mistakenly active") is flagged unsafe even though validators stay online, because dual-writer authority risks corrupting control-plane state. Standby can only write after an explicit fencing/lease transfer. - Stale-source detection compares checkpoints/head slots across all three and rejects any source that lags or diverges beyond tolerance.
This is why one CORE node can fail and the oracle still works (2 of 3 remain), but a total AWS outage kills the oracle entirely (0 of 3) — an accepted Day-0 risk.
10.7 The slashing-safety / signer model¶
Each validator key has exactly one active signing authority: there is one active Dirk signer cell per validator-bearing node (5 cells total — three CORE + two EDGE). There is no centralized signer cluster and no active/active authority for the same key, because two processes signing for one key is the classic path to a slashing event (double-signing). Standby signers are fenced/offline/passive until a controlled failover. Vouch talks to Dirk over mTLS. Boot/sentry, archive, and any public RPC/ Beacon roles carry zero keys.
10.8 The client-family relaxation (why it's not exactly 1/3 each)¶
Ideally each EL family and each CL family would carry exactly one-third of validators (6 of 18), so losing any one client family stays within the offline budget. But with one client pair per host and c=4/e=3, you cannot split a host's validators across families — a node is all-Prysm or all-Lodestar, never partially both. The repo does not prove it's safe to run multiple isolated client services on one host, so the optimizer will not assume it.
Result: the closest achievable split is 7 / 7 / 4 per layer (target 6, max deviation 2.0), reported honestly as exact_el_family_equality = false. The consequence is visible in the failure matrix: losing the 7-validator family drops 7 offline → only 11 online, which is below T=12, so a single-client-family outage fails finality. This is listed as an accepted Day-0 risk rather than hidden.
10.9 The failure matrix — what survives, what doesn't¶
Of 20 modeled scenarios, 16 hold finality and 4 fail. The four finality failures are all explicitly accepted and flagged, not silent:
- complete_aws_provider_outage → 6/18 online. Because all CORE truth lives on AWS, losing AWS loses both finality and the oracle quorum. This is the single biggest accepted risk and the main driver of the future roadmap (add non-AWS oracle CORE).
- private_core_overlay_vpn_failure → 6/18. If the private CORE mesh/VPN dies, the CORE control plane and CORE validators halt together. Same shape as AWS-wide.
- one_el_client_family_outage → 11/18. The 7/7/4 client split (see §10.8).
- one_cl_client_family_outage → 11/18. Same cause on the consensus layer.
Everything else — single CORE node/Region/AZ loss, single EDGE loss, both EDGE offline, GCP-wide, Hetzner-wide, signer-domain loss, oracle-writer failover, P2P degradation — stays at or above T=12. Note both_edge_nodes_offline lands exactly on 12 (CORE-only liveness), and losing both boot/sentry nodes keeps all 18 validators online (they hold no stake) but is still flagged "accepted" because public joinability degrades.
10.10 The network & exposure policy¶
The security model is "nothing sensitive is ever public": - CORE: private full mesh, no public raw RPC, Beacon API, Engine API, metrics, Dirk, or signer endpoint. - EDGE: same private-API policy; only P2P may be public if firewall policy permits. - boot/sentry: public P2P/discovery only — and safe to be public precisely because it is keyless.
Sensitive ports — 8551 (Engine), 8545/8546 (EL RPC/WS), 5052 (Beacon HTTP), 6061/6062 (metrics), 13141 (Dirk) — are private by default everywhere. Only the P2P ports 30303 and 9000 (TCP/UDP) may be public, and only on roles that need joinability. "P2P joinability is not RPC/Beacon API access" is a stated principle.
10.11 The cost story (the headline FAIL)¶
The configured AWS CORE year-1 budget is $1,400 — but it covers only the three AWS CORE compute instances, gp3 storage, and required networking. The cheapest compliant choice is three m6a.xlarge on standard_reserved_1yr / all_upfront, at $1,127 each = $3,381/yr ($281.75/mo). That is a $1,981 budget violation → budget fit FAIL.
The optimizer evaluated cheaper instances and rejected them for principled reasons: - t3.xlarge ($2,316) and t4g.xlarge ($2,643) are burstable — allowed only in the explicit ultra_low_cost_day0 profile because of CPU-credit risk on validator nodes. - t4g is also ARM64, which the repo doesn't confirm is supported. - m7a.xlarge in ap-southeast-1 ($2,730) is an estimate-only price row, not eligible while live official pricing exists for other rows.
So no compliant option fits $1,400. Rather than fake it (e.g. dropping to 2 CORE nodes or co-locating two in one Region), the model reports the violation and offers three honest mitigations: raise the budget, accept temporary above-budget On-Demand/RI cost, or consciously pick the labeled ultra_low_cost_day0 burstable profile ($2,862). EDGE (~$2,196/yr) and boot/sentry (~$216/yr) are tracked separately, outside the CORE budget.
10.12 How the optimizer actually ran¶
It is a Gurobi 13.0.1 mixed-integer program. Binary variables choose the AWS contract type, Region, instance, payment option, and the validator c/e pair; indicator constraints track which Regions are used. The solve is two-phase:
- Hard-budget model first (AWS CORE ≤ $1,400). Gurobi proves this INFEASIBLE (status 3) and writes an IIS (
gurobi_iis.ilp) — the minimal set of conflicting constraints — documenting exactly that the budget is the conflict. - Relaxed model: minimize the budget violation first, then optimize topology quality, cost, upgrade flexibility, and operational complexity. This solves to OPTIMAL (status 2, MIP gap 0) in 0.037 s, producing the $1,981-violation layout and a solution pool of 2 equivalent options.
Eight profiles were evaluated (baseline, strict-two-thirds, core-liveness, region- failure, balanced_day0, low_cost, growth_flexible, ultra_low_cost); all are budget- infeasible, and balanced_day0 was selected as the intended Day-0 launch profile.
10.13 The roadmap (why this is only "Day-0")¶
This topology is explicitly a starting point, not the end state. The roadmap: 1. Day-0 — launch this fixed 3-CORE / 2-EDGE / 2-boot topology, AWS as cornerstone. 2. First expansion — grow validator count only after signer, monitoring, and migration gates pass; keep one Dirk cell per validator node. 3. Intermediate CORE — add non-AWS oracle-capable CORE sources, directly reducing the accepted AWS-wide-outage risk. 4. Future full diversity — 7–9 validator nodes, separate public RPC/Beacon/archive tiers, provider-diverse oracle CORE. The V=45 target belongs here, not Day-0.
10.14 One-paragraph takeaway¶
Launch 18 validators in a three-tier shape: 3 AWS CORE nodes (4 validators each, in three distinct Regions/AZs, each with a different EL+CL client pair, all private, all oracle truth sources at 2-of-3 quorum), 2 EDGE nodes on Hetzner + GCP (3 validators each, for provider diversity, not trusted as truth), and 2 keyless public boot/sentry nodes (0 validators, public P2P only). Finality needs T=12 online; CORE alone meets that, so both EDGE nodes can vanish and finality holds. The plan is honest about three things it does not solve at Day-0: it is $1,981 over the $1,400 AWS budget, it cannot survive a total-AWS outage or a CORE-overlay failure (all truth is on AWS), and it cannot hit exact one-third client-family balance (7/7/4, so a single-family outage dips to 11 < 12). Each is a labeled accepted risk with a roadmap mitigation, and the optimizer deliberately refuses to weaken the topology to make any of them look better.
Generated from reports/topology_launch_recommendation.json and the model_1 report artifacts. Values match the committed Day-0 recommendation (Gurobi 13.0.1, OPTIMAL).