Wegwerf-Showcase (dev) · Test-Ausweise, keine echten Daten · Widerruf wird hier nicht live geprüft · Prüfung mit QR-Code läuft über einen Tunnel des Browser-Herstellers (bei Chrome: Google)
Hinter den zwei Türen
Fünf Stufen, sechs Bilder und ein Satz, der in allen steckt: Es findet ein Aufruf nicht statt, und das ist die interessanteste Kante hier. Die letzte Stufe ist die wichtigste — sie sagt, was diese Vorführung nicht beweist.
Ab dem 24.12.2026 muss jeder Mitgliedsstaat eine EUDI-Brieftasche bereitstellen, ab dem 24.12.2027 müssen regulierte Stellen sie akzeptieren. Das ist der Teil, der in jeder Präsentation steht.
Die interessantere Frage ist eine andere: ob jemand sie anbindet. Eine Brieftasche, die niemand abfragt, ist eine App mit einem Dokument darin. Dieser Showcase ist die kleinstmögliche ehrliche Antwort auf „was heißt anbinden eigentlich?“ — klein genug, dass man ihn ganz lesen kann, und ehrlich genug, dass er seine eigenen Lücken benennt.
Das Ökosystem hat drei Rollen. Der Aussteller signiert einen Nachweis und übergibt ihn. Die Inhaberin trägt ihn auf ihrem Telefon und entscheidet, was sie zeigt. Der Verifier prüft eine einzelne Aussage daraus. Dieser Dienst ist der Verifier, und nur der.
Vier Wörter fallen in jedem Gespräch dazu, oft füreinander. Drei Unterscheidungen tragen wirklich, eine ist bloß Gewohnheit — und es hilft zu wissen, welche welche ist.
| Begriff | Was gemeint ist |
|---|---|
| Dokument | Die Sache aus der Welt: Personalausweis, Führerschein. Der Standard kennt sie als Typ — diese Vorführung fragt einen elektronischen Personalausweis, keinen Führerschein, und ein Verifier legt vorher fest, welchen Typ er akzeptiert. |
| Nachweis (Credential) | Das signierte Datenpaket in der Brieftasche — die digitale Form desselben Dokuments. Hier ist die Unterscheidung meist bloß Gewohnheit: wer „Dokument“ sagt, meint in der Regel das. Eng wird es erst dort, wo ein Dokument mehrere Nachweise hat, etwa weil die Brieftasche mehrere Kopien für Einmalverwendung vorrätig hält. |
| Attribut (Claim) | Eine einzelne Aussage darin: family_name,
age_over_18. Das ist die Ebene, auf der Datensparsamkeit
überhaupt stattfindet — gezeigt wird nicht ein Dokument, sondern eine
Auswahl von Attributen. Der Alterscheck fragt zwei von fünf. |
| Attestation | Die signierte Zusage des Ausstellers, die Attribute an einen Schlüssel im Telefon bindet — der Grund, warum eine Kopie des Datenpakets niemandem nützt. Das Wort hat eine zweite Bedeutung, und daher kommt die meiste Verwirrung: es bezeichnet auch die Zusage, dass eine Brieftasche zertifiziert ist. Erstes prüft dieser Dienst, zweites nicht. |
Zwei Wörter noch, weil sie unten vorkommen: Präsentation ist die eine Antwort, die die Brieftasche auf eine Anfrage hin erzeugt — nicht der Nachweis selbst, sondern ein daraus gebauter, einmaliger Auszug. Und die Vertrauenswurzel ist das Ausstellerzertifikat, gegen das die Signatur geprüft wird; hier eine Test-Wurzel im Programm, produktiv eine staatliche aus einer nationalen Liste.
Ein Container von uns, eine Adresse, eine verwaltete Datenbank daneben. Alles Statische — Vorlagen, Bilder, Diagramme, die Vertrauenswurzel — steckt im Programm selbst. Der Tunnel-Server des Browser-Herstellers ist als das gezeichnet, was er ist: ein fremdes System, das wir weder betreiben noch abschalten können.
Die Reihenfolge ist die aus der Spezifikation, und jeder Schritt setzt voraus, dass der vorige gehalten hat. Auf der Ergebnisseite steht dieselbe Liste noch einmal — dort mit dem Stand, den der konkrete Durchlauf erreicht hat.
Kommt ein zweites Gerät dazu, taucht eine Partei auf, die wir nicht gewählt haben. Der QR-Code kommt nicht von diesem Dienst, sondern vom Browser, und die Verbindung zum Telefon läuft über einen Tunnel-Server des Browser-Herstellers — bei Chrome also über Google. Deshalb hat er im Bild eine eigene Spur und keine Linie: er ist eine Partei, kein Kabel.
Wer diesen Weg wählt, ist eine Eigenschaft des Geräts, nicht dieser Seite. Ein Browser auf einem Rechner beantwortet jede solche Anfrage mit einem QR-Code, gleich welche Adresse man geöffnet hat. Wir können das weder auslösen noch verhindern noch beobachten — deshalb steht der Hinweis darauf auf jeder Seite und nicht auf einer bestimmten.
Vor der Zustimmung zeigt die Brieftasche in Rot sinngemäß: „diese Website ist unbekannt, stellen Sie sicher, dass Sie ihr vertrauen.“ Das ist keine Panne und kein Konfigurationsmangel — die Anzeige ist korrekt. Wir senden ein unsigniertes Anfrage-Objekt, also kann die Brieftasche nicht feststellen, wer da fragt. Produktiv verschwindet der Hinweis erst mit Registrierung als Relying Party und signiertem Anfrage-Objekt.
Interessanter als die Erklärung ist, was dort eigentlich geschieht. Über Altersprüfung wird fast immer in eine Richtung gesprochen: der Händler prüft den Kunden. Hier prüft das Ökosystem den Händler — und weil wir uns nicht registriert haben, sagt es das dem Kunden auf seinem eigenen Bildschirm, bevor irgendetwas übertragen wird. Für ein Publikum, das Kontrolle über seine Kassenprozesse gewohnt ist, ist das die unbequeme Hälfte der Verordnung. Sie steht hier zufällig in Rot auf einem Telefon, und besser lässt sie sich nicht zeigen.
Eine Beobachtung, die mehr wert ist als alles, was wir über uns selbst sagen können, weil sie von einem Dritten kommt. Vor der zweiten Tür schiebt Chrome einen eigenen Zustimmungsschritt ein — „Möchtest du dieser Website deine Daten anvertrauen?“ — vor dem QR-Code. Vor der ersten Tür, dem Alterscheck, erscheint er nicht: derselbe Browser, dieselbe Sitzung, Minuten auseinander.
Belegt ist der Unterschied. Was ihn verursacht, ist es nicht — und diese Naht muss sichtbar bleiben. Ein Nachlauf am 26.07.2026 hat dieselbe Anfrage wie der Alterscheck gestellt und nur die Art des Merkmals getauscht, ein Identitätsattribut statt einer Ja/Nein-Aussage. Der Dialog erschien. Damit sind zwei von drei Erklärungen ausgeschlossen: es liegt weder am Dokumenttyp noch an der Zahl der Felder.
| Durchlauf | Dokumenttyp | Felder | Art des Merkmals | Zusatzdialog |
|---|---|---|---|---|
| Alterscheck | mDL | 1 | Aussage age_over_18 | nein |
| Sonde, 26.07.2026 | mDL | 1 | Attribut given_name | ja |
| Zweite Tür | PID | 2 | Attribute | ja |
Was das erlaubt zu sagen: bei sonst gleicher Anfrage geht die Altersaussage ohne Zwischenschritt durch, ein Identitätsattribut nicht. Was es nicht erlaubt: irgendeinen Satz darüber, dass Chrome PID von mDL unterscheide — diese Lesart ist damit widerlegt, nicht bloß unbelegt. Getestet wurde genau ein Nicht-Alters-Merkmal; ob der Browser gezielt Altersaussagen bevorzugt oder breiter einteilt, bleibt ungeprüft.
Dieselbe Antwort ein zweites Mal einzureichen ist der billigste Angriff, den es gibt. Er scheitert — aber es lohnt sich, hinzusehen, woran.
Eine Reihenfolge, die den Beweis fast verhindert hätte. Vor der Prüfsequenz stand zunächst ein Wächter, der eine bereits abgeschlossene Transaktion sofort abwies. Der Replay hätte die Prüfung dann nie erreicht, und auf dem Bildschirm stünde „Transaktion bereits abgeschlossen“ — wahr, aus einem anderen Code-Pfad als dem echten, und stumm über das, was hier gezeigt werden soll. Der Wächter sitzt jetzt auf dem Schreiben, nicht auf dem Prüfen.
Den dritten Angriff, eine falsche Adresse, gibt es hier absichtlich nicht als Knopf. Die Adresse wird nicht verglichen, sondern mitsigniert — es gibt kein Feld, das ein Knopf verstellen könnte. Ein Pfad, auf dem der Server für eine Anfrage eine andere Adresse erwartete, wäre genau der Sonderpfad, der jede dieser Vorführungen wertlos macht. Vorgeführt wird er stattdessen als Aufbau: dieselbe Station über eine zweite Adresse geöffnet, so dass der Browser echt eine fremde Adresse bindet.
Eine Prüfung hinterlässt eine Zeile. Die Hälfte dessen, was diese Zeile ausmacht, sind die Felder, die nicht darin stehen — und die stehen nicht darin, weil es keine Spalte für sie gibt, nicht weil jemand sie freilässt.
age_over_18, nie ein Alter. Jede Zeile trägt den Hashwert ihrer
Vorgängerin, weshalb sich eine Zeile nicht entfernen lässt, ohne dass es
auffällt — und weshalb auch wir selbst keine entfernen können.
Die Abfragesprache darf jede Schwelle erfragen — 13, 16, 18, 21, 65, was immer ein Gesetz morgen einführt. Aber sie wählt nur aus, sie rechnet nicht. Was im Ausweis liegt, entscheidet allein der Aussteller. Beim Alter ist der Händler nicht der Souverän, sondern Bittsteller beim Aussteller.
Das lässt sich an einem Ausweis vorführen, mit zwei Fragen nebeneinander:
| Frage an denselben Ausweis | Was passiert | Was sie zeigt |
|---|---|---|
| eine Schwelle, die er trägt | die Brieftasche antwortet: nein | ein beantwortetes Nein — ein Ergebnis, keine Ablehnung |
| eine Schwelle, die er nicht trägt | die Brieftasche meldet selbst: es seien keine teilbaren Informationen vorhanden | nicht können ≠ verneinen — und der Unterschied ist auf dem Telefon sichtbar, nicht in unserer Erzählung |
Der Kontrast zwischen diesen beiden Bildschirmen ist der Inhalt der Kachel. Der stärkste Satz dabei wird von der Brieftasche gesprochen, nicht von uns — und zwar bevor irgendetwas übertragen wird.
Welche Schwellen ein Ausweis trägt, ist eine Eigenschaft dieser Ausstellung, nicht des Protokolls, und das ist selbst ein Befund: das im Juni erzeugte Test-Dokument trug zwei Schwellen, das am 26.07.2026 erzeugte trägt acht. Zwei Dokumente, eine App, ein Aussteller, Wochen auseinander. Aus einem Satz über Aussteller im Allgemeinen ist damit ein beobachteter Unterschied zwischen zwei Ausweisen auf demselben Telefon geworden.
Es gibt genau drei Wege, und jeder kostet etwas.
| Weg | Was er kostet |
|---|---|
| Den Aussteller bitten, die Schwelle mit auszustellen | Zeit und Verhandlungsmacht. Für jede neue gesetzliche Grenze von vorn — und wer sie nicht hat, wartet. |
| Das Geburtsdatum nehmen und selbst rechnen | Der Händler erfährt das exakte Geburtsdatum. Aus „kann nicht“ wird „entscheidet sich, es nicht zu behalten“ — eine Zusage statt einer Architektur. |
| Bereichsbeweise (Zero-Knowledge) | Beliebige Schwellen ohne Preisgabe — kann unsere Test-Brieftasche nicht. Diese Vorführung zeigt das Problem, nicht seine Lösung. |
Darauf läuft es hinaus, und der Unterschied ist der ganze Punkt: Bei „über 18“ kann der Händler das Alter nicht erfahren. Beim Geburtsdatum entscheidet er sich, es nicht zu behalten. Das eine ist Architektur, das andere eine Zusage — und Zusagen überleben Reorganisationen schlechter als fehlende Spalten.
Diese Stufe ist der Grund, warum es die Seite gibt. Ein Showcase ohne seine Grenzen erzeugt Erwartungen, die später jemand anders einlösen muss. Die Tabelle steht deshalb ungekürzt hier und nicht in einem Anhang.
| Beweist — belegbar mit dieser Vorführung | Beweist nicht / offen |
|---|---|
| Lokale Verifikation: die Signatur wird bei uns gegen die Test-Vertrauenswurzel geprüft, ohne Aufruf beim Aussteller oder bei Google | Echte Aussteller-Vertrauenskette (staatliche Wurzel) — diese Vorführung nutzt eine Test-IACA |
| Beweise ohne Personenbezug: gespeichert wird „DASS geprüft wurde und mit welchem Ergebnis“, nicht „WER“ | Zusammenspiel mehrerer Brieftaschen — geprüft wurde ausschließlich Multipaz, weder Apple- noch Google-Wallet |
| Souveränität des Betriebs: läuft auf STACKIT, nicht auf einer US-Cloud | „Kein Google im Transport“ gilt nur bei Prüfung auf einem Gerät. Kommt ein zweites dazu, läuft die Verbindung über den Tunnel des Browsers — bei Chrome über Google. Diese Vorführung zeigt das absichtlich und benennt es. Sie widerlegt die Souveränitäts-These nicht, sie zeigt, wo über Souveränität entschieden wird: nicht im Standard, sondern im Browser |
| Gleichheit der Prüfung: dieselbe Prüfsequenz, dieselbe Anfrage, dieselbe Signaturbindung — ob ein Gerät beteiligt ist oder zwei, unterscheidet nur den Transport, nicht die Verifikation | Ein browser-freier Weg über zwei Geräte (eigener QR-Code, kein Browser-Tunnel) ist nicht Teil dieser Vorführung — er bräuchte eine zweite, bisher nicht gemessene Handover-Form |
| — | Phishing über weitergereichte QR-Codes: QR-basierte Abläufe sind strukturell dafür anfällig, dass ein Angreifer den Code an ein entferntes Opfer weiterreicht und dessen Zustimmung erntet. Diese Vorführung mildert das nur über kurze Gültigkeit, sie löst es nicht — produktiv braucht es ein Gerät oder eine zusätzliche Kanalbindung |
| Einmaligkeit pro Präsentation (die Challenge) | Replay-Freiheit im Produktivbetrieb — nur die Logik dieser Vorführung, nicht gehärtet |
| Datensparsamkeit ist eine Wahl, keine Eigenschaft: dasselbe Protokoll, zwei Türen, zwei Datenschatten — der Alterscheck lernt ein Bit, die zweite Tür einen Namen. Sichtbar auf drei Ebenen: beim Fragen (der Zustimmungs-Dialog listet zwei von fünf Attributen), beim Speichern und im Vergleich (beide Bestände auf einem Bildschirm) | Dass die sparsame Variante ausreicht: ob ein Händler mit „ja/nein“ auskommt, hängt am Prozess dahinter — Reklamation, Nachweispflichten im Jugendschutz, Anfragen der Strafverfolgung. Die Vorführung zeigt, dass es technisch geht, nicht dass es betrieblich trägt |
| — | Den Kanal für den empfohlenen Pilot: geübt wird der Online-Kanal zwischen Browser und Brieftasche, nicht der Nahbereichs-Ablauf (Lesegerät, NFC am Kassenterminal), den der Pilot bräuchte → das Risiko des Terminal-Pfads wird dadurch nicht gemindert |
| — | Das Alters-Kennzeichen an der Kasse: die Vorführung endet bei „ja/nein“ in der Prüf-Station — sie zeigt nicht, wie der geprüfte Status an die Kasse gelangt und dort die Personal-Intervention unterdrückt. Genau das ist der Engpass des Piloten: die Kassenanpassung hat ein halbes Jahr Vorlauf, und der Umweg „Intervention nachträglich abfangen“ ist ungetestet. Auch die Übergabe aus Scan&Go und „Alter plus Zahlung in einer NFC-Transaktion“ sind nicht Teil davon |
| — | Der Aufruf aus einer nativen App: geübt wird die Browser-Oberfläche, nicht der Aufruf aus einer iOS- oder Android-App über die Plattform-APIs — die offene Integrationsfrage für eine Kunden-App |
| — | Die niedrigen Altersschwellen — und das ist die unbequemste Lücke. Der Weg über die Brieftasche funktioniert für Menschen, die einen Nachweis besitzen. Je niedriger die Schwelle, desto unwahrscheinlicher ist das: Feuerzeuge sind rechtlich ab 12 abgabefähig, praktisch handhaben Läden es ab 14 oder 18 — und Zwölfjährige haben in aller Regel kein Ausweisdokument, also erst recht keine zertifizierte Brieftasche. (Rechtslage nach Auskunft aus dem Handel, ungeprüft — vor externer Verwendung nachschlagen.) Daraus folgt eine Umkehrung, die man aussprechen muss: die Brieftasche hilft dort am besten, wo das Problem am kleinsten ist — und am wenigsten dort, wo die tägliche Reibung an der Kasse sitzt. Am anderen Ende gilt dasselbe: Seniorenrabatte treffen die Gruppe mit der geringsten Verbreitung. Die Abdeckung ist glockenförmig — in der Mitte dicht, an beiden Rändern dünn. Verschärfend: aus dem Fehlen eines Nachweises folgt nichts. „Keine Brieftasche“ heißt nicht „minderjährig“, also bleibt für alle, die nicht präsentieren können, die Personal-Intervention bestehen |
| Wer über Altersschwellen bestimmt: die Vorführung zeigt live, dass eine legitime Abfrage unbeantwortbar bleibt, weil der Aussteller die Schwelle nie ausgestellt hat — und was der Ausweg kostet | Beliebige Schwellen ohne Preisgabe: dafür bräuchte es Bereichsbeweise, die unsere Test-Brieftasche nicht kann. Die Vorführung zeigt das Problem, nicht seine Lösung. Wer beliebige Grenzen prüfen will, hat heute nur die Wahl zwischen „den Aussteller fragen“ und „das Geburtsdatum nehmen“ |
| — | Abdeckung mit Nachweisen in Deutschland · Sicherheit und Skalierung im Produktivbetrieb (Schlüsselverwaltung in Hardware, Last) · Bindung an ein Konto statt an eine Person · Widerruf (hier nicht geprüft) · Mehrere Länder (eine Test-Wurzel, kein Zusammenspiel nationaler Vertrauenslisten) |
Alle drei sind Zeilen der Tabelle oben, ausgeschrieben. Sie stehen hier, weil sie gestellt werden — und weil eine improvisierte Antwort auf jede davon wie eine Ausrede klingt.
In der ausführlichen Fassung: Wie erfährt die Brieftasche, dass jemand jetzt über 18 ist, oder dass der Führerschein noch gültig ist — braucht es dafür nicht doch eine Abfrage beim Aussteller?
Geprüft wird ein Gültigkeitsfenster, und das steht in der Signatur. Der Aussteller signiert nicht nur die Angabe, sondern auch, bis wann sie gelten soll. Der Gültigkeitsschritt der Prüfsequenz oben vergleicht diesen Zeitpunkt mit jetzt und lehnt ab, wenn er vorbei ist; fehlt die Angabe ganz, gilt der Nachweis als abgelaufen, denn eine nicht angegebene Gültigkeit ist keine unbegrenzte. Das Ablaufdatum landet auch in der Beweiszeile — nachlesbar, ohne dass jemand nachfragen müsste.
Ein Gültigkeitsfenster ist aber keine Aktualität, und der Unterschied ist die eigentliche Antwort. „Über 18“ ist eine Entscheidung, die der Aussteller beim Ausstellen getroffen und in die Signatur eingefroren hat. Wer danach volljährig wird, trägt bis zur Neuausstellung ein „nein“ mit sich herum. Die Brieftasche erfährt also nichts — sie holt sich einen neuen Nachweis. Aktualität ist eine Eigenschaft des Ausstellungsrhythmus, nicht der Prüfung, und sie wird über kurze Laufzeiten eingestellt: je kürzer der Nachweis gilt, desto häufiger muss die Brieftasche beim Aussteller nachladen und desto frischer ist, was sie zeigt.
Zwei Arten des Veraltens, die man auseinanderhalten muss. Die eine ist die eben beschriebene: das Merkmal ändert sich planmäßig — ein Geburtstag, eine hinzugekommene Führerscheinklasse. Dagegen hilft die Laufzeit. Die andere ist der Entzug: der Führerschein wird aberkannt, der Ausweis als gestohlen gemeldet. Davon weiß das Gültigkeitsfenster nichts, denn es wurde vorher signiert. Dafür gibt es Statuslisten, die ein Verifier periodisch lädt statt bei jeder Prüfung. Diese Vorführung prüft keinen Widerruf — die Zeile steht in der Tabelle oben und ist genau deshalb dort.
Und warum nicht doch einfach live nachfragen? Weil das genau das zurückholt, was dieser Aufbau entfernt. Ein Verifier, der bei jeder Prüfung beim Aussteller anriefe, meldete ihm jede Vorlage — mit Zeitpunkt und mit der Gegenstelle. Der Aussteller ist im Regelfall der Staat. Das ist keine Nebenwirkung einer sonst guten Lösung, sondern der ganze Unterschied zwischen einem Ausweis und einer Ausweis-API; es ist die gestrichelte Kante im ersten Bild dieser Seite.
Der ehrliche Rest: Zwischen einem Entzug und dem Moment, in dem ein Prüfer davon weiß, liegt ein Fenster. Wie groß es ist, ist eine Richtlinienentscheidung — Laufzeit des Nachweises plus Ladeintervall der Statusliste. Kein Verfahren ohne Rückfrage bringt es auf null; die Live-Abfrage bringt es auf null und bezahlt mit einem Meldekanal. Die belastbare Antwort ist deshalb nicht, dass es dieses Fenster nicht gäbe, sondern dass man seine Größe kennt und einstellen kann. Beim Papier existiert dasselbe Fenster übrigens auch: ein entzogener Führerschein sieht im Portemonnaie unverändert gültig aus, und niemand hat je gemessen, wie lange.
Die Prüfung: ja, unverändert. Was Sie hier sehen, hängt am Browser nur im Transport. Entschlüsseln, beide Signaturen, die einmalige Challenge, Gültigkeit, das Auslesen des Merkmals — nichts davon weiß, wie die Antwort angekommen ist. Eine native App tauscht die Übergabe aus, nicht die Prüfung.
Die Übergabe: nicht in diesem Showcase gebaut, und das hat einen Preis, den wir beziffern können. Hier ruft eine Webseite die Digital-Credentials-API des Browsers auf. Ein browser-freier Weg ist möglich — eigener QR-Code, die Brieftasche holt ein signiertes Anfrage-Objekt bei uns und schickt ihre Antwort direkt zurück. Dann ist kein Browser-Hersteller mehr im Transport, und das Souveränitäts-Argument hielte auch geräteübergreifend.
Er ist aus einem konkreten Grund nicht gebaut: dieser Weg bindet die Signatur an eine andere Struktur — nicht mehr an die Web-Adresse, sondern an ein signiertes Anfrage-Objekt. Diese Struktur haben wir nicht gemessen, und ungemessene Strukturen sind in diesem Bau schon sechsmal teuer geworden. Geschätzter Aufwand: zwei bis drei Tage mit mittlerem bis hohem Risiko — plausibel, nicht belegt. Das ist der interessanteste Nachfolger dieses Showcases und der ehrlichste Weg, das Souveränitäts-Argument technisch einzulösen, statt es zu behaupten.
Diese Demo läuft im Browser, an einem Bildschirm, mit einem Menschen, der ein Telefon dabei hat und eine Brieftasche darauf installiert hat. Eine Kasse ist keine dieser Bedingungen selbstverständlich.
Die unbequeme Form der Antwort: Die Abdeckung ist glockenförmig. In der Mitte — Erwachsene mit Ausweis, Schwelle 18 — ist sie am dichtesten. An beiden Rändern ist sie dünn: Zwölf- und Vierzehnjährige haben in aller Regel noch kein Ausweisdokument, also erst recht keine zertifizierte Brieftasche; und altersgebundene Vorteile für Ältere treffen die Gruppe mit der geringsten Verbreitung. Die Wallet hilft also dort am besten, wo das Problem am kleinsten ist — und am wenigsten dort, wo die tägliche Reibung an der Kasse sitzt.
Und der Satz, den man aussprechen muss: Aus dem Fehlen eines Nachweises folgt nichts. „Keine Brieftasche“ heißt nicht „minderjährig“. Für alle, die nicht präsentieren können, bleibt der bisherige Weg bestehen — der Händler braucht den Nicht-Wallet-Pfad also dauerhaft und nicht übergangsweise. Damit ist der Entlastungs-Nutzen ausgerechnet in den transaktionsstärksten Kategorien am dünnsten.
Diese Demo zeigt davon nichts und kann es auch nicht. Sie zeigt, was funktioniert, wenn alle Bedingungen erfüllt sind — und wie wenig dabei preisgegeben wird. Wie oft sie erfüllt sind, ist die andere Frage, und sie wird nicht hier beantwortet, sondern im Handel.
Die Quelltexte aller sechs Diagramme liegen im Repository neben den Bildern, damit nachlesbar bleibt, was gezeichnet wurde, ohne es ausführen zu müssen.
Beide Türen sprechen dasselbe Protokoll. Der Unterschied ist, wonach sie fragen — und das ist der ganze Gegenstand dieser Seite.