Fabian Georgi · ·Überarbeitet: ·Architektur
EPoSe: Warum gültige Receipts trotzdem in Warteschlangen scheitern können
EPoSe (Egalitarian Proof of Service): Warum gültige Receipts in Queues scheitern und wie fachliche Slots und idempotente Retries den Relay-Weg härten.
Eine Nachricht ist korrekt signiert. Der lokale Node nimmt sie an. Trotzdem fehlt am Ende der Runde der kanonische Beleg. Warum garantiert kryptografische Gültigkeit weder zuverlässige Übermittlung noch rechtzeitige Berücksichtigung?
In der EPoSe-Entwicklung für Qwertycoin wurde diese Frage an einem konkreten Queue-Fall sichtbar. Ein Receipt bestätigt eine gebundene Dienstprüfung; ein Envelope ist seine übertragene Nachrichtenhülle. Die Unterscheidung zwischen Inhalt, Hülle und Transportzustand entscheidet darüber, ob Wiederholungen helfen oder knappe Ressourcen verdrängen.
Der belegte Fall aus Epoche 17
Die historische Analyse in ADR-0010 beschreibt die abgeschlossene Mainnet-Epoche 17 mit 18 aktiven Service-Identitäten und null qualifizierten Identitäten. Probes und Signaturen gelangen weitgehend, doch nur ein kleiner Teil der lokal eingereichten Receipts wurde kanonisch aufgenommen. Lange laufende Daemons hielten Queues, die von wiederholt randomisierten Signaturen bereits eingereichter Slots dominiert wurden; Varianten aus Runde 0 verdrängten spätere Runden.
Das ist der dokumentierte Befund. Das ADR veröffentlicht keine vollständige Zeitreihe der Queue-Belegung und keine exakten lokalen oder kanonischen Receipt-Summen für diesen Vorfall. Ich behandle die dort beschriebene Beobachtung deshalb nicht wie einen neu durchgeführten Live-Test und ergänze keine vermeintlich präzisen Rohwerte.
Die entscheidende Hypothese war überprüfbar: Die Queue identifizierte vollständige signierte Nachrichten über deren Hash, während die Qualifikation fachliche Prüfplätze zählte. Würden neue Signaturbytes denselben Platz mehrfach belegen, könnte eine kryptografisch gültige Wiederholung neue Arbeit verdrängen.
Ein Hash erkennt Bytes, keinen zusätzlichen Prüfer
Eine erneute Signatur derselben Aussage kann andere Bytes erzeugen. Der Hash des vollständigen Envelopes ändert sich dann ebenfalls. Zwei unterschiedliche Nachrichtenhashes bedeuten deshalb nicht zwei unterschiedliche Dienstprüfungen.
Die Funktion receipt_slot in relay_pool_v2.cpp baut den tatsächlich verwendeten Schlüssel in dieser Reihenfolge auf:
Domain: QWC_EPOSE_RECEIPT_SLOT_V2
service_kind
Epoche: 64 Bit, Little Endian
Runde: 64 Bit, Little Endian
öffentlicher Service-Schlüssel des Subjekts
öffentlicher Service-Schlüssel des Prüfers
Das ist eine Beschreibung der konkreten Serialisierung, kein frei erfundener C++-Tupeltyp. Die separate Funktion receipt_context bindet mit eigener Domain den Snapshot-Hash und Anchor-Hash. Der fachliche Slot bezeichnet also die Prüfbeziehung in einer Runde; der Kontext ordnet sie ihrer maßgeblichen kanonischen Vorgeschichte zu.
Für 18 Mitglieder, drei Runden und bis zu neun Prüfer pro Subjekt entstehen rechnerisch höchstens 18 × 3 × 9 = 486 Prüfplätze je vollständiger Epoche. Das ist keine gemessene Queue-Belegung, keine garantierte Receipt-Zahl und keine Zusage gleichzeitiger Auslastung. Beliebig viele neue Signaturvarianten vergrößern diese fachliche Aufgabe nicht.
Die Änderung betrifft den ganzen Lebenszyklus
Die gewählte Härtung macht nicht nur die Queue größer. Sie ändert, was als neue Arbeit gilt und wann alte Arbeit ihren Platz verliert:
- Je fachlichem Slot im maßgeblichen Snapshot-/Anchor-Kontext wartet höchstens ein brauchbarer Receipt.
- Abgelaufene Runden und nach einer Reorganisation veraltete Kontexte werden vor Vergabe des Template-Budgets entfernt.
- Wird ein Receipt kanonisch beobachtet, verschwinden seine wartenden Slot-Varianten.
- Nach einem Wechsel des kanonischen Anchors darf ein gültiger Ersatz für den neuen Kontext aufgenommen werden.
- Transportwiederholungen verwenden dasselbe authentisierte Envelope, begrenzt nach stabiler Peer-Identität und Zeitfenster.
- Ein Vermittler darf dieses Envelope erneut weiterleiten, ohne einen zusätzlichen Queue-Eintrag zu erzeugen.
Authentische späte Varianten bereits kanonischer Slots sind erwartbare Rennen. Sie sind kein Grund, einen Peer wie einen Fälscher zu behandeln. Eine ungültige Signatur muss weiterhin abgelehnt werden. Die gutartige Einordnung setzt die nötige Authentisierung voraus.
Nicht erneut speichern heißt nicht nie erneut senden
Ein idempotenter Vorgang verändert das fachliche Ergebnis bei Wiederholung nicht erneut. Für die Queue bedeutet das: Das bereits wartende Envelope braucht keinen zweiten Speicherplatz. Für den Transport bedeutet es gerade nicht, dass nach einem einzigen Sendeversuch für immer Schluss ist.
Bei Paketverlust könnte die einmalige Sendeentscheidung den einzigen gültigen Receipt verhungern lassen. Daher trennt die Implementierung idempotent_duplicate — dieselbe authentisierte Hülle darf begrenzt erneut weitergeleitet werden — von receipt_slot_variant: Eine anders signierte Variante belegt denselben Slot und wird nicht als neue weiterzuleitende Arbeit behandelt.
Die Alternative „jedes Duplikat vollständig unterdrücken“ spart kurzfristig Verkehr, verliert aber den Wiederholungsmechanismus. Die Alternative „jede gültige Signatur neu speichern“ erhält Wiederholungen auf Kosten der Queue-Fairness. Die brauchbare Grenze ist: einmal fachlich halten, bei Bedarf begrenzt identisch übertragen, fristgerecht kanonisch auswerten.
Historische Grenze 21.600, keine neue Hard Fork
Die Härtung wurde für Release 2.0.3 mit lokaler Produktions-, Relay- und Template-Policy ab Höhe 21.600 festgelegt, dem Beginn von Epoche 30. Diese Höhe liegt im Quellenstand bereits in der Vergangenheit. Sie ist keine neue Ankündigung und verändert weder Blockgültigkeit noch Blockversion oder Reward-Regeln.
Ein vollständiger Block wird unabhängig von der lokalen Relay-Queue geprüft. Deshalb können alte und aktualisierte Nodes dieselben gültigen Blöcke akzeptieren, obwohl ihr Weiterleitungsverhalten unterschiedlich gut ist. Genau darum gehören Miner- und Pool-Template-Daemons zum Wirkungsweg. Ein Update nur der Service-Nodes beweist nicht, dass die Belege auch die Template-Erzeuger erreichen.
Die Änderung liefert zudem keine rückwirkende Qualifikation: Ein authentischer Receipt außerhalb seines kanonischen Carrier-Fensters bleibt zu spät. Die historische Policy-Grenze und die Fristen des Protokolls sind verschiedene Dinge.
Welches Ergebnis ist überprüfbar?
Das ADR formuliert den historischen Befund und die Entscheidung; spätere Release-Unterlagen und die Regressionen prüfen die Mechanismen. Die Tests decken unter anderem Slot-Varianten, Bereinigung, Wiederholung, Anchor-Wechsel und die Höhen um 21.600 ab. Diese Testfälle belegen das geprüfte Verhalten, nicht nachträglich eine vollständige Rekonstruktion aller damaligen Queue-Ereignisse. Die dokumentierte Binärprüfung von 2.0.2 und dem 2.0.3-Kandidaten auf derselben Chain stellte gleichen Tip und EPoSe-Zustand sowie erfolgreiche Rücknahme und Replay fest; sie fand noch vor der Aktivierungsgrenze statt und ist kein Live-Zustellnachweis danach.
Für die laufende Diagnose liefert das geschützte get_epose_diagnostics die Übergänge getrennt:
| Station | Passender Nachweis |
|---|---|
| Lokale Erzeugung | Versuch, Antwortprüfung und Terminalgrund; success heißt lokale Annahme. |
| Queue und erneutes Relay | Items/Bytes sowie Zähler für Duplikate, Signaturvarianten, Verfall, Kontext- und Kapazitätsfehler. |
| Template-Auswahl | Auswahlzähler; ein ausgewähltes Template ist noch kein geminter kanonischer Block. |
| Kanonische Aufnahme | Beobachtungen und chain-abgeleitete canonical_unique_receipts, gebunden an Höhe/Hash und Epoche. |
| Qualifikation | Unterschiedliche Prüfer je Runde, Quorum und abgeschlossene Qualifikationsmenge. |
Lokale Betriebszähler werden beim Neustart zurückgesetzt. relay_canonical_receipts zählt entfernte Queue-Records nach kanonischer Beobachtung, nicht qualifizierte Nodes. Die Chain-Evidenz wird dagegen rekonstruiert. Ein pauschaler Vergleich solcher Summen ohne ihren Geltungsbereich führt erneut in die Irre.
Der Fall aus Epoche 17 erklärt frühere erfolglose Epochen 9–11 nicht automatisch. Dafür wären jeweils eigene Ursachenbelege nötig. Meine übertragbare Erkenntnis ist enger und nützlicher: Authentizität, fachliche Neuheit, Frist und Transportzustand sind unterschiedliche Prüfungen. Im letzten Teil geht es darum, wie die zugehörige Historie korrekt und mit tragbaren Ressourcen gehalten wird.
Quellen und Stand
Inhaltlich geprüft am 17.10.2026. Hauptbranch: e2f7b6788dee6e065acc874daee3d4a085dbd9c8; veröffentlichtes v2.0.4: 1e479cc9feda48e07dd07ba6abcb89ca3934b5e2. Der frühere Quellenstand dieser Fallstudie war bc31e684dc365be5ed851b038b47d6f692d49a1e. Die neuere Hauptbranch-Dokumentation ist nicht automatisch der Stand jedes laufenden Nodes.