WikiDeck/wikideck
3
0
Fork 1
Code Issues 8 Pull Requests Actions Packages Projects 2 Releases Wiki Activity

deploy

Browse Source
This commit is contained in:
eric
2026-11-01 16:43:28 -05:00
parent b427fa4217
commit b88dfb1e94
11 changed files with 121 additions and 23 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/mainnet-launch.md
+3 -3
View File
@@ -11,7 +11,7 @@ The repository defaults to a **mainnet candidate**, not an audited or launched p
| Selection | `WIKIDECK_NETWORK=mainnet` (or unset) | `WIKIDECK_NETWORK=testnet` |
| Network ID | `wikideck-randomx-mainnet-1` | `wikideck-randomx-testnet-6` |
| Protocol | Version 6 | Existing fixed local testnet version 6 |
| Genesis timestamp | 2027-01-01 00:00 UTC by default; deployment may choose another timestamp before building/freezing | Fixed at 2026-10-19 00:00 UTC |
| Genesis timestamp | Fixed launch default: 2026-11-01 00:00 UTC (`1793491200`); ready to start now | Fixed at 2026-10-19 00:00 UTC |
| Ledger directory | mainnet | testnet |
| Browser wallet | IndexedDB name derived from exact chain ID | Separate chain identity |
| New backup | v2 header authenticates exact chain ID | Same v2 format; legacy v1 is accepted only on the original testnet |
@@ -35,9 +35,9 @@ Starting the candidate node or native miner requires all of:
1. `WIKIDECK_MAINNET_LAUNCH` equals the exact candidate chain ID printed by the manifest command.
2. `WIKIDECK_MAINNET_RISK_ACK=operator-accepts-unaudited-risk` records the operator's explicit acceptance that no external audit is planned and residual risks remain. This is not a safety certification; the manifest honestly reports `audited: false`.
3. The candidate genesis timestamp has arrived. If the operator changes the timestamp or consensus manifest before launch, the chain ID also changes and the old approval is invalidated. Freeze and publish the final manifest before launch.
4. An HTTPS `PUBLIC_ORIGIN`, at least two distinct configured HTTPS peer origins, and no private-peer bypass. Configuration count cannot prove the peers are online, independent, or sufficiently distributed; verify that operationally. Existing peer DNS/origin controls still apply.
4. An HTTPS `PUBLIC_ORIGIN` and at least two distinct configured peer origins. Public deployments require public HTTPS peers by default. An operator-controlled private candidate cluster may explicitly set `WIKIDECK_ALLOW_PRIVATE_PEERS=1` to permit private/HTTP peer RPC; this does not relax browser HTTPS, chain approval, risk acknowledgment, or genesis-time gates. Configuration count cannot prove the peers are online, independent, or sufficiently distributed; verify that operationally. Existing public peer DNS/origin controls still apply when the private opt-in is off, and HTTPS certificate verification is never disabled.
For Kubernetes, the current peer implementation requires HTTPS origins that resolve to public addresses; it rejects private cluster DNS/IPs for mainnet. The node serves HTTP internally and needs a separately configured TLS ingress/reverse proxy. Every node needs a stable, unique public HTTPS origin and at least two distinct peer origins. A default ClusterIP/headless Service alone cannot satisfy these rules, and a load-balanced ingress shared by several pods is not a stable per-node peer identity. Do not set the private-peer bypass to work around this; use public per-node HTTPS endpoints or first review a separate authenticated private-peering design that preserves the public independence gate. No cluster-specific manifests are included because ingress class, TLS/certificate management, storage class/size, resource capacity, and stable peer DNS were not provided.
For Kubernetes public peering, give every node a stable, unique public HTTPS endpoint. For an explicitly private candidate, separate single-replica Deployments, Services and exclusive PVCs may use distinct ClusterIP DNS origins with the private opt-in. Each validator lists the other two internal Services, never itself. The browser-facing node needs a TLS ingress/reverse proxy; internal-only validators may share that HTTPS browser origin without their own ingress. NetworkPolicy must restrict peer RPC to the selected validator pods on target TCP port 3001. Private HTTP RPC is unauthenticated and unencrypted unless protected by an independently configured mesh; do not use it across untrusted networks. Three validators in one cluster/storage failure domain are not independent operators or proof of production readiness.
See the [Kubernetes mainnet preparation checklist](../deploy/kubernetes/README.md) for the deployment contract and the values needed before manifests can be finalized.
Unknown profile names fail closed. A direct import of the HTTP entry point is also guarded. Library-level manifest/consensus/storage inspection remains possible for tests and review; activation gates are accident prevention and operator risk acceptance, not a security boundary against someone who edits the source.