Kontinuum

Appearance

Kontinuum Node — Bootstrap & Tier 0 Operations ​

Genesis network formation, Tier 0 key ceremony, first-launch flows для каждого tier'a. P0 prerequisite — без этого invariants сети не определены.

Audience: kontinuum.org operators (для Tier 0), partner operators (Tier 1), self-hosted users (Tier 2), node developers (bootstrap logic).

Связанные документы:

Обзор ​

Genesis network — chicken-and-egg problem:

  • Tier 1 нода нужен cert от Tier 0.
  • Tier 0 нужно знать, что Tier 1 запросил cert.
  • Client (kontinuum-app) знает Tier 0 через hardcoded pubkeys в коде.
  • Кто signs первый Tier 0? Никто — Tier 0 ключи manually generated в key ceremony, self-signed, и записываются в repo через PR.

Bootstrap rolls forward от Tier 0 ключей → Tier 1 cert'ы → Tier 2 attestations.

Tier 0 anchor — key ceremony ​

Структура anchor cluster ​

v0.1 (launch)v1.0 (production scale)
1 key (org-internal)3-of-5 multi-sig для critical operations (cert issuance, CRL); 2-of-3 для routine config (см. §16)
Single operator5 operators в разных юрисдикциях (US, EU, AP × 2 для resilience)
Offline backup keySame

v0.1 key ceremony (single key) ​

Цель: generate root Ed25519 key для Tier 0, secure storage, publish pubkey в codebase.

Steps:

  1. Hardware preparation.

    • Dedicated machine (laptop, не подключённый к internet, freshly installed OS).
    • Hardware key (YubiKey 5, OnlyKey) для backup signing.
    • Witness: минимум 2 человека от kontinuum.org присутствуют.

  2. Entropy collection.

    • dd if=/dev/urandom of=entropy.bin bs=32 count=1 + dice rolls + camera-captured atmospheric noise (defence-in-depth).
    • Combined entropy → blake3 → seed.

  3. Key generation.

    • cargo run --bin tier0-ceremony generate --entropy entropy.bin --output tier0_root.key.
    • Output: Ed25519 keypair (32-byte private + 32-byte pubkey).

  4. Encrypted backup.

    • Master passphrase (32+ chars, generated by 2 witnesses, half-half).
    • cargo run --bin tier0-ceremony backup --key tier0_root.key --output tier0_root.enc.tar.gz — encrypted с master passphrase через age + Argon2id.
    • Backup записывается на 3 разных hardware tokens (separate physical safes в разных юрисдикциях).
    • Original tier0_root.key стирается с machine (shred -uvz).
    • Passphrase разделена через Shamir Secret Sharing 3-of-5 (для recovery).

  5. Publish pubkey.

    • cargo run --bin tier0-ceremony export-pubkey --key tier0_root.key → hex string.
    • PR в kontinuum-node/server/src/bootstrap/tier0_pubkeys.rs добавляет pubkey в TIER0_PUBKEYS.
    • PR merged → released в client / node version → пользователи могут verify Tier 0 certs.

  6. Witness attestation.

    • Document с timestamp, witnesses, machine fingerprint — signed witnesses (PGP).
    • Archived в docs/node/ceremonies/v0.1-genesis.md (encrypted with PGP).

v1.0 multi-sig ceremony (3-of-5) ​

Цель: 5 Tier 0 keypairs у разных operators, multi-sig для critical operations.

Дополнения к v0.1 flow:

  1. 5 separate ceremonies в разных географических локациях (US-East, US-West, EU-Central, EU-North, AP-East).
  2. Каждый operator проходит шаги 1-5 v0.1 ceremony.
  3. Coordination layer — multi-sig aggregator. Cert issuance:
    • Billing system → kontinuum-node-admin → Tier0Coordinator.
    • Tier0Coordinator шлёт signing request всем 5 operators (через secure channel — PGP-encrypted email + acknowledgment via the chosen operator chat bot platform).
    • Каждый operator проверяет request (legitimate user, payment confirmed) и подписывает на своём offline machine.
    • 3 подписи собраны → cert published в global DHT.

Frame format multi-sig cert:

cbor
{
    body: {
        node_id: <bytes>,
        node_pubkey: <bytes>,
        tier: 1,
        tenancy: "single",
        operator: "byo:vps",
        served_identity: <bytes>,
        capabilities: [...],
        capacity: {...},
        issued_at: <unix>,
        valid_until: <unix>,
    },
    signatures: [
        { tier0_pubkey: <pk_us_east>, signature: <sig1> },
        { tier0_pubkey: <pk_eu_central>, signature: <sig2> },
        { tier0_pubkey: <pk_ap_east>, signature: <sig3> },
    ],
}

Validation на client/node side: проверить что ≥3 signatures валидны и от разных TIER0_PUBKEYS.

Hardcoded constants ​

kontinuum-node/server/src/bootstrap/tier0_pubkeys.rs ​

rust
//! Tier 0 anchor pubkeys, hardcoded в binary.
//!
//! Update procedure: ceremony (см. bootstrap.md) → PR adds pubkey → release.
//! Removal: PR removes pubkey + bumps CRL generation. Old nodes will reject
//! certs signed by removed key.

pub const TIER0_PUBKEYS: &[Tier0Anchor] = &[
    Tier0Anchor {
        pubkey: hex!("a3f9...32 bytes..."),
        label: "us-east (kontinuum.org primary)",
        added_in_version: "0.1.0",
        // metadata для display в admin UI
        operator_contact: "ops-useast@kontinuum.org",
    },
    // v1.0:
    // Tier0Anchor { pubkey: hex!("..."), label: "eu-central", ... },
    // ...
];

/// Multi-sig threshold для cert issuance (3-of-N для production, 1-of-1 для v0.1).
pub const TIER0_MULTISIG_CERT_THRESHOLD: usize = 1;  // v0.1; v1.0 → 3

/// Multi-sig threshold для CRL updates.
pub const TIER0_MULTISIG_CRL_THRESHOLD: usize = 1;   // v0.1; v1.0 → 3

/// Multi-sig threshold для routine config updates.
pub const TIER0_MULTISIG_CONFIG_THRESHOLD: usize = 1; // v0.1; v1.0 → 2

kontinuum-node/server/src/bootstrap/tier0_addrs.rs ​

rust
//! Tier 0 anchor bootstrap multiaddrs.
//!
//! Hardcoded canonical bootstrap entrypoints. Test/dev environments override
//! через node.toml `network.extra_bootstrap_peers`.

pub const TIER0_BOOTSTRAP_PEERS: &[Tier0BootstrapPeer] = &[
    Tier0BootstrapPeer {
        peer_id: "12D3KooW...",  // libp2p PeerId base58
        multiaddrs: &[
            "/dns4/anchor1.kontinuum.network/tcp/4001",
            "/dns4/anchor1.kontinuum.network/udp/4001/quic-v1",
        ],
        geo_zone: "us-east",
    },
    // v1.0: 4-5 anchors распределённых по регионам
];

Update strategy: anchor multiaddrs могут меняться (DNS migrations, IP changes). Update — minor release. CRL уведомляет о deprecated anchors.

Node bootstrap flows ​

Tier 1 — org-operated (org × multi-tenant base case) ​

Kontinuum.org руками provisioning нового Tier 1 ноды.

  1. Provision VPS (Hetzner / OVH / DigitalOcean).
  2. Install binary — kontinuum-node-server from release.
  3. Generate node identity:
    bash
    kontinuum-node-server bootstrap \
    --output /var/lib/kontinuum-node/keys/ \
    --geo-zone eu-west \
    --tier 1 \
    --tenancy multi \
    --operator org
    • Generates Ed25519 keypair.
    • Generates BIP39 recovery phrase (12 words) — printed once к operator, NOT persisted.
    • Derives master_key из phrase, encrypts privkey, сохраняет в node.key.
    • Writes node.toml со defaults.
  4. Request cert from Tier 0:
    • kontinuum-node-admin cert issue --node-pubkey <hex> --tier 1 --tenancy multi --operator org --capacity-storage-bytes <N>
    • Admin process отправляет signing request к Tier 0 operator(s).
    • В v0.1: один operator signs immediately. v1.0: 3-of-5 multi-sig collected.
    • Cert returned, saved в /var/lib/kontinuum-node/keys/node.cert.
  5. Start service:
    bash
    systemctl start kontinuum-node-server
    • Service reads node.toml, loads cert, validates against TIER0_PUBKEYS.
    • Connects к bootstrap peers, joins global DHT, publishes node:{node_id} запись.

Tier 1 — partner-operated (revenue-share) ​

Partner = third-party хостер. v0.4+ scoped что partner = byo:* operator (см. architecture.md §3.3 после рефакторинга).

Effectively это byo:vps × multi сценарий — partner запускает ноду на своей инфре, shares ресурсы среди family/team клиентов kontinuum.org. Различие от standard byo: partner подписывает SLA с org, получает revenue share.

Onboarding:

  1. Partner подписывает contract с kontinuum.org.
  2. Kontinuum.org issues partner credentials для admin REST API.
  3. Partner provisions VPS, follows Tier 2 byo flow ниже, но с operator = "partner" и attached SLA.

(Partner detailed onboarding — отдельный документ, post-v1.0.)

Tier 1/2 — Standard buyer (client purchased relay) ​

Client покупает relay-node через kontinuum-app.

  1. Billing flow:
    • User → kontinuum.org website → purchases "Relay-node Small/Medium/Large".
    • Payment confirmed → Kontinuum Billing → webhook → kontinuum-node-admin.
  2. Provisioning automation:
    • kontinuum-node-admin provisions VPS (Hetzner API / Terraform).
    • Installs binary, generates identity, requests cert.
    • Cert binds served_identity = client_identity_id.
  3. App linking:
    • Admin generates deep-link kontinuum://attach-relay?node_id=<hex>&cert_blob=<base64>.
    • User opens в kontinuum-app → app verifies cert → connects to node → joins own Personal Space.
  4. Node fully operational — client может публиковать blob'ы, mailbox start receiving.

Tier 2 — PRO byo:vps (self-purchased VPS) ​

PRO user provisions VPS у внешнего хостера.

  1. PRO subscription активирована (см. app-integration.md §13.1).
  2. VPS provision:
    • User покупает VPS у Hetzner/DO/etc, gets root SSH access.
    • В kontinuum-app → Settings → My Infrastructure → Add VPS → wizard:
      • Enter VPS IP / SSH key.
      • App SSH'ит, installs binary, runs kontinuum-node-server bootstrap.
      • App reads generated node_pubkey, displays для confirmation.
  3. Cert request:
    • App → kontinuum-node-admin REST API: POST /certs/issue с PRO subscription proof.
    • Admin validates PRO subscription активна → requests cert from Tier 0.
    • v0.1: single Tier 0 signs. v1.0: 3-of-5 multi-sig.
    • Cert returned, app uploads на VPS, restarts node.
  4. Node operational as tier=2, operator=byo:vps, tenancy=single, served_identity=<owner>.

Tier 2 — PRO byo:home (home server) ​

Same как byo:vps, но:

  • Initial provisioning через local installer (kontinuum-node-installer package для Debian/Ubuntu/Fedora/Arch).
  • App connects к home server через rendezvous (см. §6.6) или LAN mDNS для initial pairing.
  • geo_zone autodetect через GeoIP, user может override.

Genesis network formation ​

Очерёдность для самого первого launch'a сети:

  1. Day 0 — Tier 0 ceremony (см. выше). 1 anchor key created, pubkey baked в codebase.
  2. Day +1 — Tier 0 anchor нода stood up:
    • Self-signed cert (tier=0).
    • Hardcoded multiaddrs.
    • DHT initialized but empty (no peers).
    • Anchor публикует свой node:{node_id} запись.
  3. Day +2 — Org provisions 3-5 Tier 1 нод (org-operated), все получают cert от anchor.
    • Каждая Tier 1 нода подключается к anchor, joins DHT.
    • DHT начинает заполняться.
  4. Day +3 — Soft launch: limited beta users invited.
    • Beta users → buy relay-node → cert issued.
    • Standard purchase flow тестируется.
  5. Day +30 — Public launch.

Critical invariants:

  • DHT не может функционировать с одной нодой (k=20 Kademlia требует minimum пары peers). Минимум 3 нод для initial DHT.
  • Tier 0 anchor должен быть first peer для всех. После того как Tier 1 ноды online, anchor становится one of many bootstrap entrypoints.

Tier 0 operational procedures ​

Cert issuance (routine) ​

Triggered Kontinuum Billing webhook:

  1. Billing event subscription.created приходит на kontinuum-node-admin.
  2. Admin process verifies signature, parses payload (subscription_id, identity_id, plan).
  3. Admin assembles cert request CertRequest { body: CertBody, ... }.
  4. v0.1: Admin process signs cert с (cached) Tier 0 private key, returns.
  5. v1.0: Admin process отправляет request 5 Tier 0 operators через secure channel; ждёт 3 подписей; aggregates в multi-sig cert.
  6. Cert published в global DHT (node:{node_id} запись) + return к provisioning flow.

CRL update (revocation) ​

Triggered:

  • Billing event subscription.lapsed (after 28-day timeline).
  • Manual admin action (kontinuum-node-admin cert revoke).
  • Anti-fraud / abuse detection.

Flow analogous to cert issuance: assembled CertRevocation, signed (multi-sig в v1.0), published в crl:{tier0_pubkey} global DHT record.

Tier 0 key rotation (planned) ​

Periodic rotation Tier 0 keys (e.g., every 2 years) — preserved security against key compromise.

  1. Generate new Tier 0 keypair (ceremony as above).
  2. Old Tier 0 key signs transition cert для new Tier 0 pubkey.
  3. New Tier 0 pubkey published в codebase + released.
  4. Overlapping window (~3-6 месяцев) когда оба ключа активны.
  5. После window: old key retired, removed from TIER0_PUBKEYS.

Tier 0 key compromise (emergency) ​

Detection:

  • Anomalous cert issuance (cert для node_id не в billing records).
  • Anomalous CRL entries.
  • Out-of-band notification от operator.

Response (v0.1, single key):

  1. Immediately: offline backup key recovered (3-of-5 Shamir shares).
  2. New Tier 0 keypair generated (emergency ceremony).
  3. Emergency release: clients/nodes get update с new pubkey + revoked old pubkey.
  4. Network repairs: all certs signed by compromised key re-issued.

Response (v1.0, multi-sig):

  1. Compromised key revoked from multi-sig group (remaining 4 sign revocation).
  2. 5th key restored from Shamir shares (new ceremony).
  3. Continuing operations с reduced threshold (3-of-4 temporary).
  4. Eventually 5-key cluster restored.

Multi-sig drastically уменьшает blast radius single key compromise.

Bootstrap subcommand specification ​

kontinuum-node-server bootstrap ​

Generates node identity + initial config.

kontinuum-node-server bootstrap [OPTIONS]

OPTIONS:
    --output <DIR>            Output directory for keys & config (default: /var/lib/kontinuum-node)
    --geo-zone <ZONE>         Geo zone (eu-west, us-east, ...)
    --tier <N>                Tier (1 | 2)
    --tenancy <MODE>          single | multi
    --operator <OP>           org | byo:vps | byo:home
    --served-identity <HEX>   identity_id for single-tenant nodes
    --capacity-gb <N>         Total storage capacity in GB
    --interactive             Interactive mode (default for ops)
    --print-recovery-phrase   Print BIP39 phrase к stdout (default: yes)

OUTPUT:
    <output>/keys/node.key    Encrypted Ed25519 signing key (chmod 600)
    <output>/keys/node.cert   EMPTY initially — needs cert request flow next
    <output>/config/node.toml Default config with paths populated
    stdout                    BIP39 recovery phrase — WRITE DOWN SECURELY

Critical: BIP39 phrase printed once. Operator MUST capture it; нет way recover potом.

kontinuum-node-server cert request (manual flow, для testing) ​

kontinuum-node-server cert request [OPTIONS]

OPTIONS:
    --admin-endpoint <URL>    Admin REST API URL (например http://admin.kontinuum.local:8080)
    --token <TOKEN>           Auth token issued by admin (e.g., from billing webhook)

EFFECT:
    - Sends signed cert request to admin.
    - Admin validates token, requests cert from Tier 0.
    - Receives cert, writes к node.cert path в config.
    - Restarts node service (если running).

В production обычно flow автоматический (admin process инициирует), manual subcommand для testing / disaster recovery.

Implementation checklist ​

  • [ ] Создать server/src/bootstrap/ модуль:
    • tier0_pubkeys.rs — hardcoded TIER0_PUBKEYS + thresholds.
    • tier0_addrs.rs — hardcoded TIER0_BOOTSTRAP_PEERS.
    • subcommand.rs — bootstrap CLI subcommand handler.
    • cert_request.rs — cert request subcommand.
  • [ ] Создать admin/src/tier0/ модуль:
    • cert_issuer.rs — assembles + signs (or multi-sig collects) cert requests.
    • crl_publisher.rs — assembles + publishes revocations.
    • coordinator.rs (v1.0) — multi-sig coordination через secure channel.
  • [ ] CLI bootstrap subcommand — interactive prompts для critical inputs (recovery phrase display, confirmation).
  • [ ] Tests:
    • Bootstrap generates valid Ed25519 + BIP39.
    • Cert verification против hardcoded TIER0_PUBKEYS.
    • Multi-sig validation (v1.0).
    • CRL propagation через DHT.
  • [ ] Operator handbook (separate doc, post-v1.0): step-by-step ceremony procedures.

Security considerations ​

Tier 0 ceremony threats ​

ThreatMitigation
Side-channel attack на ceremony machineAir-gapped, dedicated hardware, no peripherals except keyboard
Compromised entropy sourceMulti-source entropy (urandom + dice + camera) blake3'd
Witness collusion2+ witnesses от kontinuum.org, witness attestation PGP-signed
Backup theft3-of-5 Shamir shares в разных юрисдикциях, master passphrase split
Single-key compromise (v0.1)Offline backup key restore + emergency release; acceptable risk при малой user base
Multi-sig collusion (v1.0)3-of-5 threshold; 3 operators must collude — geographically distributed makes coordination hard

Recovery phrase для node identity ​

  • Generated при bootstrap subcommand.
  • Printed once, NOT persisted on disk.
  • Operator responsibility: capture, secure storage.
  • Loss = node identity loss = need new node + cert (data on node — at risk пока re-issue не сделан).

Open implementation questions ​

  1. Tier 0 secure channel для multi-sig. PGP email? Signal? Dedicated wire protocol? v0.1 — manual, v1.0 — нужен production-ready.
  2. Shamir Secret Sharing implementation. vsss-rs или sharks? Library choice.
  3. Ceremony tooling. Standalone tier0-ceremony binary в отдельной crate? Включить в kontinuum-node-admin?
  4. Tier 0 anchor hosting. Where do they physically run? Org's own DC, AWS, ... Decision до v1.0 launch.
  5. Genesis recovery scenarios. What if Tier 0 anchor выключается на 24h? Network resilience under prolonged outage — нужны load tests.