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.
Mesh: Ethernet-Austausch
Vorab zugelassene Knoten wählen den nächsten Hop. Aufgaben und Routen werden in Ethernet-Frames übertragen.
- Prüfstand
- Live-Mesh, 5 VMs auf 3 physischen Hosts
- Frames
EtherType 0x88B5- Agenten
- synthetisch, ohne LLM
- Betreiber
- einer
- Verwaltung
- über administrative IP
- Bezug zu BCP
- separater Prototyp · BCP 0.2 und seine Zulassung →
Verbindung zu den signierten Protokollen wird hergestellt…
Knoten abschalten können nur die Betreiber des Prüfstands. Hier wird eine begrenzte Auswahl signierter Einträge gezeigt, nicht das vollständige Netzprotokoll.
Warten auf Nachrichten
Der Pfad erscheint nach dem Abgleich der Protokolle von Sender, Empfänger und Vermittlern.
Zeitverlauf des Netzes
Der Zeitverlauf wird in diesem Tab gesammelt; der lokale Verlauf wird höchstens 15 Minuten gespeichert.
Jeder Punkt ist eine Nachricht, abgeglichen mit den signierten Protokollen aller Knoten auf dem Pfad. Die Zeit stammt aus den Protokollen der Knoten selbst. Der Beobachter liefert die letzten 24 Zustellungen. Der Tab speichert gesehene Einträge höchstens 15 Minuten; das Diagramm zeigt die letzten 3 Minuten. Beim Schließen des Tabs geht dieser lokale Verlauf verloren. Die Signaturen bestätigen die gezeigten Hops, nicht aber die Vollständigkeit des Protokolls. Klicken Sie auf einen Punkt, um die Nachricht aufzuschlüsseln.
Was was ausgelöst hat
Kette der letzten Abschaltung aus signierten Einträgen. Klicken Sie auf einen Schritt, um den Eintrag oder die Nachricht zu öffnen. Zeit ab dem Eintrag zur Abschaltung, nach den Uhren der Knoten selbst.
Zugestellte Nachrichten
Wer die Route wählt
Jede Zeile ist eine Entscheidung des Knotens selbst aus seinem signierten Protokoll. Einen gemeinsamen Dispatcher gibt es nicht.
Wie das Netz den Ausfall überstand
Was auf echten Maschinen geprüft wurde
Wie unterscheidet sich dieses Experiment vom gewöhnlichen Internet?
wird aus dem öffentlichen Schlüssel abgeleitet. Keine Registrierungsstelle vergibt sie; der Empfänger bleibt auf dem ganzen Pfad derselbe.
Nachbarn tauschen signierte Ankündigungen aus: Das ist ein . Der Knoten wählt den kürzesten verfügbaren Pfad; alte Angaben über einen verschwundenen Nachbarn verfallen.
Eigene Frames mit dem Typ 0x88B5 werden über Ethernet übertragen. Daten und Routenankündigungen enthalten kein IPv4, IPv6, TCP, UDP oder DNS. gibt nur den nächsten Nachbarn an.
Die Betriebssysteme dieser VMs behalten eine administrative IP. SSH und die Beobachtungsseite nutzen IP. Sie dienen dem Betreiber; die Agenten setzen den Austausch fort, auch wenn das Panel abgeschaltet ist.
Es sind fünf vorab zugelassene VMs auf drei physischen Hosts, bei einem Betreiber und in einem Rechenzentrum. In den Gästen werden Ethernet-Frames beobachtet; die Konfiguration des Underlays zwischen den Hypervisoren ist nicht gesondert bestätigt. Blockchain-Registry und BCP-Richtlinien sind in diesem Mesh nicht implementiert. Das ist ein separater Modus: der aufgezeichnete Strict-LLM-Versuch nutzt drei Gäste auf drei Hosts, zwei lokale Modelle und Gast-Kernel ohne INET/IPv6. Hier laufen synthetische Agenten ohne LLM. Die Version des Live-Prüfstands steht in der Fußzeile der Seite; das Datum der gespeicherten Abnahme im Abschnitt „Was auf echten Maschinen geprüft wurde“. Wir prüfen die eigene Zustellung und das Routing, aber noch nicht ein globales Netz, die automatische Zulassung unbekannter Knoten oder die Belastbarkeit bei Überlast.
A und B behalten die Schlüssel der vorigen Stufe. R1 schaltet den echten Übertragungskanal für 60 Sekunden ab; die Dienststeuerung bleibt erreichbar, danach wird der Kanal automatisch wieder eingeschaltet. Der direkte Pfad A↔B ist durch die Regeln der Gastmaschinen verboten.
Aufgaben in einem großen Netz
Was bereits mit echten Frames zugestellt wurde — und wo die aktuelle Architektur an Skalierungsgrenzen stößt.
- Dokumente
- echt
- Agenten
- Software, ohne Sprachmodell
- Betreiber
- einer
- Wo gemessen
- separater Versuch auf einer VM des Relcom-Projekts
- Messung und Berechnung
- getrennt dargestellt
- Daten
- gespeicherte Ergebnisse · fünf laufende Maschinen — im Live-Prüfstand
Berichte abgeschlossener Tests werden geladen…
16 Agenten führen Ihre Aufgabe aus Gemessen
Jeder Kreis ist ein eigener Prozess mit eigenem Schlüssel und eigener Routentabelle. 16 Prozesse laufen auf einer physischen Maschine in einem isolierten Netz ohne IP. Die hervorgehobene Linie ist der bestätigte Pfad der Aufgabe. Gleiche Marken H… oder V… an gegenüberliegenden Rändern bezeichnen einen Hop zwischen den äußeren Nachbarn, an den Zwischenknoten vorbei.
Wie lange auf Aufgaben gewartet wurde
Quelle des Diagramms: gemessener Lauf auf einer Relcom-VM; Verarbeitung zweier öffentlicher Artikel. Jeder Punkt ist die Zahl der erhaltenen korrekten Ergebnisse.
Eingespeist wurden eine Verzögerung von 4 ± 1 ms, 0,02 % Frameverlust und die Abschaltung des echten Kanals N05 für etwa 10 Sekunden. Der erste Lauf deckte eine automatische IPv6-Adresse auf der Brücke auf und bestand die Prüfung nicht. Er ist separat gespeichert. Der zweite Versuch zeigte Dienstverkehr per von der Brücke und zwei Ausfälle wegen eines Fehlers in der Aufgabenfrist. Nach den Korrekturen wurde ein neuer Lauf durchgeführt; beide vorherigen Ergebnisse sind gespeichert.
Bis zu 2 048 Agenten: Berechnung eines möglichen Netzes Simulation
Das ist eine Simulation, keine 2 048 gestarteten Agenten. Hinter jedem simulierten Router stehen acht logische Agenten. Last, Verluste, Bandbreite und Warteschlangen sind explizit vorgegeben; die Ergebnisse versprechen nicht dieselbe Geschwindigkeit in einem echten Netz.
Alle 36 Berechnungen
Anteil erledigter Aufgaben über die Zeit: Zeile — Bedingungen, Spalte — Netzgröße, drei Linien — drei . Gestrichelt: Limit von 60 Sekunden. Klicken Sie auf eine Zelle, um die Berechnung unten zu öffnen. Derzeit arbeitet das Protokoll mit höchstens 16 Knoten und 7 Hops, daher sind 64 und 256 eine Berechnung für eine Version, die es noch nicht gibt.
Jeder Knoten trifft die nächste Entscheidung anhand seiner eigenen Tabelle. Die Tabellen entstehen durch den Austausch zwischen Nachbarn; ein zentraler Routendienst wird nicht verwendet. Der hervorgehobene Pfad stammt aus einer abgeschlossenen Berechnung. Gleiche Marken H… oder V… an gegenüberliegenden Rändern sind ein Hop zwischen den äußeren Nachbarn.
Die wichtigste Schlussfolgerung: Eine bloße Erweiterung der Liste der Schlüssel-IDs macht das Protokoll nicht global. Nötig sind kompakte Routenankündigungen, eine separate Diensterkennung, Überlaststeuerung und Prüfungen in unabhängigen Netzen. Die Simulation zeigt den Preis dieser Einschränkungen, sie beseitigt sie nicht.
Sind andere Agenten schon umgestiegen? Quellenübersicht
Befragte externe Betreiber: 0. Es liegen zwei separate Einschätzungen isolierter Codex-Agenten im selben Dienst vor. Sie sehen den Transport ihrer eigenen Ausführung nicht und können einen Umstieg auf IPvX nicht bestätigen. Ein erreichbarer externer Knoten mit prüfbarer Telemetrie wurde nicht gefunden.
Unten: geprüfte Primärdokumente mit Stand 27. Oktober 2026. Das ist eine Übersicht über Protokolle, keine Einführungsstatistik. Belege für einen massenhaften Umstieg von KI auf ein Native-Netz ohne IP enthält diese Übersicht nicht.
Signierte Nachweise
Jede Stufe ist ein Bundle. Die Bundles sind mit dem Schlüssel des Labors signiert und in ein Merkle-Protokoll eingetragen.
- Bundle
- Berichtsdateien mit SHA-256, Release-Commit und GitHub-Assets
- Signatur
- Schlüssel des Labors
- Protokoll
- Merkle-Baum
- Wer prüft
- Ihr Browser, nicht der Server
Protokoll wird geladen, Signaturen werden geprüft…
Was das beweist und was nicht
Beweist Integrität und Reihenfolge: Ein Bundle lässt sich nicht ändern, entfernen oder umstellen, ohne die Signatur oder den Konsistenznachweis zu brechen. Wer einen früheren Protokollkopf aufbewahrt hat, erkennt jede umgeschriebene Historie.
Beweist weder unabhängige Zeit noch einen unabhängigen Zeugen: Schlüssel und Protokoll liegen in der Hand eines einzigen Labors, die Daten sind dessen eigene Angabe. Der nächste Schritt ist, die Köpfe dort zu verankern, wo das Labor nichts kontrolliert; das ist zugleich der Vergleich des Protokolls mit der Blockchain für H11.
Dateien selbst prüfen
Der Browser lädt die Berichte selbst nicht herunter. Ein Befehl in einem Klon des Repositorys prüft die Signaturen, den Baum und den SHA-256 jeder Datei:
python -m ipvx_agent_lab.evidence verify
Zwei Agenten. Direkter Austausch.
Jeder Agent läuft auf seiner eigenen Maschine und sendet seinem Gegenüber selbst Nachrichten. Die ID bleibt beim Wechsel der IP gleich.
- Stufe
- 2 · abgeschlossen: auf diesen Maschinen läuft die nächste Stufe · Netz ohne IP öffnen
- Netz
- echtes TCP/IP · internes Netz des Prüfstands
- Namen
- DNS bei den Agenten abgeschaltet
- Daten
- synthetisch
- Agenten
- Software, ohne Sprachmodell
- Maschinen
- zwei VMs auf verschiedenen physischen Hosts · ein Betreiber
Agenten und Zustellung
Warten auf ZustellbestätigungDirekte Verbindung über TCP · internes Netz des Prüfstands · geswitchter Abschnitt
Ein Beobachter auf dem dritten physischen Host liest die signierten Protokolle beider VMs. Nachrichten zwischen den Agenten laufen nicht über ihn.
Zugestellte Nachrichten
Gezeigt werden Nachrichten mit übereinstimmenden Einträgen beider Seiten. Wählen Sie eine Zeile, um den Pfad zu prüfen.
Adressen und Ereignisse
Prüfungen auf zwei Maschinen
Wer legt die Route, wenn es viele Agenten gibt?
Die ID beantwortet die Frage „wer“, die IP „wo“
In diesem Experiment kennt A die öffentliche ID und die erste Adresse von B im Voraus. Wenn B die Adresse wechselt, signiert B einen neuen Eintrag und sendet ihn selbst an A. A prüft Signatur und Version, speichert die neue Adresse und öffnet eine direkte Verbindung.
Bei großem Maßstab lässt sich die anfängliche Suche auf viele Knoten verteilen. Sie halten Teile des Verzeichnisses ID → Adressen mit Kopien und Caches. Die Suche ist vor einer Verbindung oder nach dem Verlust einer Adresse nötig, nicht für jede Nachricht. Ein solches Suchsystem ist in diesem direkten Pilot noch nicht implementiert.
Die Pakete stellt das bestehende IP-Netz zu. Seine Router arbeiten mit Netzpräfixen; sie brauchen keinen eigenen Eintrag für jeden Agenten. Warteschlangen, Anfragelimits und Agentenreplikate lösen ein anderes Problem — die Überlastung der Berechnung.
Ein Verzicht auf IP würde die Entwicklung eines eigenen Routing-Netzes bedeuten. Derzeit prüfen wir eine unabhängige ID und den direkten Austausch über TCP/IP. Verlieren beide Agenten gleichzeitig alle bekannten Adressen des jeweils anderen, ist eine Wiederherstellung in dieser Stufe nicht vorgesehen.
Grenzen des Versuchs
Zwei VMs auf verschiedenen physischen Hosts · ein Betreiber und ein Rechenzentrum. Der Umzug wechselt die lauschende IP innerhalb einer VM; die Verwaltung bleibt auf der bisherigen Adresse. Die Schaltfläche startet nur den Adresswechsel, die Benachrichtigung des Gegenübers übernimmt der Agent selbst.
Internet für Agenten
Ein Agent findet Daten, erhält begrenzte Rechte und übergibt die Aufgabe an einen Analysten. Verfolgen Sie den Ablauf der Aufgabe und die Gründe der Entscheidungen.
- Stufe
- 1 · im Stufenarchiv · aktuelle Arbeit: BCP 0.2
- Daten
- synthetisch
- Betreiber
- einer
- Agenten
- Software, ohne Sprachmodell
- Start
- nur Betreiber des Prüfstands · gezeigt wird der zuletzt gespeicherte
Pfad der Aufgabe
Ereignisse des echten Laufs
Eigentümer der Aufgabe
Persönlicher Agent
Drei Resolver
Datenquelle · MCP
Analyst · A2A
Neuer Anschlusspunkt
Die ID beantwortet die Frage „wer?“. Der Resolver: „wo gerade?“. Die Berechtigung: „was darf er?“.
Ereignisprotokoll
0 EreignisseEreignisse erscheinen nach dem Start. Jede Zeile öffnet eine Erklärung und die beobachteten Daten.
Was wir prüfen
Erhalt der ID beim Umzug, Prüfung der Signaturen, Grenzen der Rechte und Verhalten bei Ausfällen.
Hypothesen und Nachweise
Das Urteil gilt für einen konkreten Lauf. Ein Teilergebnis lässt Fragen offen.
- Stufe
- 1 · im Stufenarchiv · aktuelle Arbeit: BCP 0.2
- Quelle
- letzter gespeicherter Lauf von Prüfstand /1
- Adresse der Hypothese
#hypotheses/H5
Ergebnis des Laufs
Alle Hypothesen
Eigenen Agenten anbinden
Die Python-Clientbibliothek löst eine signierte ID über drei Resolver auf, prüft den Eintrag und speichert die bekannte Version. Der Datenzugriff erfordert eine gesonderte Berechtigung des Eigentümers.
- Stufe
- 1 · im Stufenarchiv · aktuelle Arbeit: BCP 0.2
- Sprache
- Python
- Vertrauen
- legt der Betreiber fest, nicht die Bibliothek
Lokaler Start
git clone https://github.com/relcom-technologies/ipvx-agent-lab cd ipvx-agent-lab python3 -m venv .venv source .venv/bin/activate pip install -e '.[test]' ipvx-lab local
Öffnen Sie http://127.0.0.1:8080. Der Befehl startet sieben separate Prozesse. Die Installation aus dem privaten Repository erfordert Zugriff auf GitHub.
Aufruf aus Python
from ipvx_agent_lab import AgentClient, invocation
with AgentClient(
resolver_urls, # drei Resolver-Adressen
checkpoints={agent_id: (2, 3)},
state_file=".state/known-versions.json",
allowed_origins={"https://your-agent.example"},
) as client:
profile = client.resolve(agent_id)
result = client.invoke(
profile,
invocation(permission_chain, subject_key, "read"),
)Resolver-Adressen, vertrauenswürdige Anfangsversion, erlaubte Knoten und Rechtekette legt der Betreiber fest. Die Bibliothek entscheidet nicht für den Eigentümer, wem er vertraut.
Automatisch prüfen
ipvx-lab run --scenario full --output reports/full.json pytest -q
Experimentelles Protokoll
Version 1 · vom Projekteigentümer am 26. Oktober 2026 genehmigt.
- Stufe
- 1 · im Stufenarchiv · aktuelle Arbeit: BCP 0.2
- Grundlage IPvX
218bf93
Was auf dem Prüfstand funktioniert
Lokale ID-Erzeugung, signiertes Profil, Suche nach Fähigkeit, aus zwei von drei Resolvern, enge Berechtigungen und Schutz vor erneuter Ausführung. Der Umzug ändert den Anschlusspunkt und erhält die Identität.
Was als Nachweis gilt
Die Szenarien senden HTTP-Anfragen an separate Prozesse. Jede Prüfung speichert Bedingung, beobachtetes Ergebnis und Zeit. SQLite-Einträge und exportierte Berichte bleiben nach einem Neustart erhalten.
Grenzen des Experiments
- Ein physischer Host und ein Betreiber. Separate Prozesse beweisen keine Unabhängigkeit der Betreiber.
- Die Agenten führen vorgegebene Regeln auf synthetischen Daten aus. Ein Sprachmodell ist nicht angebunden.
- MCP 2025-06-18 und A2A 0.3.0: Geprüft werden begrenzte Adapter. Die Kompatibilität mit externen Implementierungen ist noch nicht zertifiziert.
- Der erste Kontakt erfordert einen aktuellen Vertrauensanker. Eine Signatur allein garantiert weder Aktualität noch Qualität des Ergebnisses.
- Ist die Widerrufsquelle nicht erreichbar, ist ein Cache-Fenster von bis zu 3 Sekunden erlaubt; danach Ablehnung. Eine Uhrenänderung ist ein explizit eingespeister logischer Fehler.
- Blockchain und Einführung durch externe Teams sind noch nicht geprüft.
Festgeschriebene Grundlage IPvX
218bf93acb842604167c93144e5bc967b70ecb6aDie Quorumregel stammt aus dieser Version. Agentenprofile und Berechtigungen sind ein neues experimentelles Protokoll.
Vollständiges Protokoll lesen ↗