BCP 0.2
Knotenidentität, erlaubter Pfad und Paketaufbau aus überprüfbarem Registerzustand.
Entwicklungsstand
BCP 0.2 ist die Paketschicht und Registry von IPvX. Die Registry-Verträge wurden auf der lebenden Sepolia-Chain geprüft: REG-001 lief im Lesemodus Q, und R1 wurde am 2026-11-06 durch die Light-Client-Lesung REG-001-LC nach dem Ersatzkriterium, dem aktuellen Zustand, geschlossen; die Werte S1–S3 bleiben Beobachtungen im Modus Q. Die von der Registry gesteuerte Paketzustellung hat auf Test-Registry-Zustand bestanden (NET-001-F, PASS am 2026-11-08); auf lebendem Zustand (NET-001-L) ist sie noch nicht gelaufen.
Standaufnahme:
Im Code implementiert
Paketformat, NodeRegistry, TransitPolicy, ConnectionPolicy, EL/CL-Adapter und Kernintegration. Vertragslesezugriffe sind an einen finalisierten blockHash gebunden.
Offline geprüft
93 Runner-Tests und 14 Planprüfungen. Temporäre Schlüssel, EVM im Speicher, synthetische Header und Memory-Ports; keine Messung von Netzwerk oder Chain-Finalität.
Nächstes Netzwerkexperiment
NET-001-F hat am 2026-11-08 auf der separaten Stand-VM bestanden: Der Lauf bcp-net001-run-0003 mit einer vom Eigentümer signierten Genehmigung ergab PASS in allen 14 Prüfvarianten, und der unabhängige Verifier hat das Ergebnis bestätigt. Das ist die Zustellung von Ethernet-Frames zwischen drei Knoten auf einem echten Linux-Kernel mit synthetischem Registry-Zustand: Chain-Finalität, eine physische Leitung und unabhängige Betreiber werden damit nicht geprüft. Das nächste Experiment ist NET-001-L auf lebendem Registry-Zustand. Es liest die Registry über den Helios-Light-Client: Modus LC hat Modus V am 2026-11-05 ersetzt, ein eigener Sepolia-Knoten ist nicht nötig. Helios läuft auf dem Stand noch nicht, und die Aktualisierungsregel für Snapshots in NET-001-L bleibt eine offene Bedingung. Die Freigabe für einen neuen Start ist gesperrt: Jeder Lauf braucht eine eigene vom Eigentümer signierte Genehmigung.
Was BCP ändert
Identität
NodeRegistry bindet eine Knoten-NFT-Kennung an Eigentümer und Schlüssel. Ein selbst erzeugter Schlüssel allein berechtigt nicht zur Teilnahme.
Erlaubter Pfad
TransitPolicy und ConnectionPolicy legen erlaubte Übergänge und Verbindungen fest. Knoten prüfen Pfade gegen fixierten Zustand; Blockchain ersetzt nicht den Frame-Transport.
Paketaufbau
Kennungen, Checkpoint, Pfad, Signaturen und verschlüsselte Daten erhalten ein genaues Binärformat. MAC bezeichnet den nächsten Nachbarn, die Kennung den Zielknoten.
Daten vor Freigabe
Der Datensatz wird separat vorbereitet. Der signierte Permit bindet Daten- und Paket-Hash, Run-ID, Erstellung und Aktualitätsfrist. Nach der Genehmigung erzeugt der Runner keinen Ersatzdatensatz.
Aktualität höchstens 30 Minuten, zusätzlich durch den ältesten frischen Checkpoint begrenzt. Kopieren oder Neustarten verlängert keinen abgelaufenen Datensatz.
Freigabeformat und Grenzen
dataset_sha256 · bundle_sha256 · run_id · created_at · expires_at
Beleggrenzen
Das erste Experiment, NET-001-F, hat in einer Linux-VM bestanden: A–R–B-Namespaces und zwei veth-Verbindungen. Es belegt weder Live-Chain-Betrieb, offenen Zugang, physische Ethernet-Unterlage noch Vorteile gegenüber IP.
Mesh ist ein separates Experiment
Der historische Stand prüft signierte Zustellung und Routenwechsel zwischen vorab zugelassenen Knoten. Er implementiert kein BCP-Blockchain-Register. Journale, Mitschnitte und frühere Schlussfolgerungen bleiben erhalten.
Fragen und Ideen zu BCP
BCP wird im Teilnehmerforum diskutiert; Vorschläge zur Änderung des Dokuments laufen über RFCs und GitHub.
BCP-Kategorie im Forum öffnen