Fabian Georgi · ·Überarbeitet: ·Architektur
EPoSe: Aus einer Service-Idee werden überprüfbare Regeln
EPoSe (Egalitarian Proof of Service) bei Qwertycoin: Wie aus einer Service-Idee prüfbare Regeln, kanonische Belege und getrennte Schlüsselrollen werden.
Ein Server antwortet auf eine Anfrage. Das klingt nach einer geeigneten Grundlage für eine Service-Vergütung — bis ein zweiter Node dieselbe Entscheidung später nachvollziehen soll. Er beobachtet ein anderes Netzwerk, vielleicht eine andere DNS-Antwort und einen längst umgezogenen Endpunkt. Wie wird aus dieser flüchtigen Beobachtung eine Regel, die alle Validatoren gleich auswerten?
Die ursprüngliche EPoSe-Idee stammt von Xecute, einem ehemaligen Mitglied des Qwertycoin-Projekts. Aufbauend auf dieser Konzeption habe ich im Auftrag der Qwertycoin-Organisation den Service-Layer technisch weiterentwickelt und implementiert. Sein historischer Medium-Beitrag ist der sichtbare Ausgangspunkt, nicht eine Leistungsbeschreibung der heutigen Implementierung.
Historische Zielsetzung und konkreter Dienst
Das frühere Konzept verband Service-Bewertung und Rewards mit weitergehenden Zielen wie kürzeren Blockzeiten und höherem Transaktionsdurchsatz. Diese Ziele sind historische Aussagen. Sie werden nicht dadurch zu gemessenen Eigenschaften der heutigen Software, dass beide EPoSe heißen. Umgekehrt wäre „vor diesem Auftrag gab es keinerlei Implementierung“ eine unbelegte Verkürzung der Vorgeschichte.
Für die aktuelle technische Beschreibung ist der tatsächlich implementierte Dienst entscheidend: canonical-object. Ein ausgewählter Prüfer fordert einen kanonischen Block an — also ein Blockobjekt aus der maßgeblichen Chain. Der Service liefert die Bytes und signiert seine Antwort. Der Prüfer kontrolliert die Daten anhand seiner eigenen kanonischen Sicht und erstellt einen ebenfalls signierten Beleg, den Receipt.
Der Austausch ist an Epoche, Runde, Snapshot, Anchor, beide Service-Schlüssel, Endpoint-Bindung, Nonce und angeforderten Objekthash gebunden. Eine Epoche ist dabei ein festes Intervall von Blockhöhen; Snapshot und Anchor legen Mitgliedschaft und Chain-Kontext fest. Die Unterschrift des Prüfers bindet auch die Antwortsignatur des Dienstes. Ein beliebiger signierter Ping wäre zu schwach: Er belegt weder die richtigen Blockdaten noch die vorgeschriebene Prüfung.
VPN oder allgemeiner Speicherverkauf sind damit keine heute nachgewiesenen EPoSe-Dienste. Solche Anwendungen wären gesondert zu entwerfen und zu implementieren.
Drei Verantwortungen, ein gemeinsamer Block
| Bereich | Verantwortung |
|---|---|
| PoW und Blockvalidierung | RandomX-Blockproduktion, Chain-Auswahl und Prüfung aller konsenskritischen Regeln. |
| Service-Protokoll | Identitäten, Deskriptoren, eingefrorene Mitgliedschaft, Prüfer, Receipts, Qualifikation und Reward-Regeln. |
| Lokaler Betrieb und Transport | Erreichbarkeit, HTTP-Austausch, Relay, Wiederholungen, Diagnostik und Darstellung. |
Diese Trennung ist keine Auslagerung aller Service-Regeln in unverbindliches Monitoring. Ein Block mit einem falschen vorgeschriebenen Service-Reward ist ungültig. Ebenso müssen die enthaltenen Service-Records korrekt geprüft werden. „Service-Layer“ beschreibt Verantwortungen innerhalb der Architektur, nicht einen austauschbaren Off-chain-Zähler.
Die entscheidende Grenze liegt zwischen Evidenz erzeugen und kanonische Evidenz auswerten. Der lokale HTTP-Austausch darf von Netzwerkbedingungen abhängen. Die Konsensprüfung darf das nicht: Sie prüft den enthaltenen authentisierten Transcript und seinen historischen Kontext, ohne Live-HTTP, DNS, Remote-RPC oder lokale Wanduhr. Damit können zwei Nodes denselben alten Block erneut prüfen, ohne den damaligen Dienst nochmals kontaktieren zu müssen.
Identität darf kein Hostname sein
Ein Endpunkt kann wechseln; ein operativer Schlüssel kann rotieren. Die fachliche Identität muss solche Änderungen überleben. Sie wird deshalb aus dem öffentlichen Operator-Autorisierungsschlüssel und dem gebundenen Netzwerkkontext abgeleitet — nicht aus IP-Adresse, DNS-Name oder Reward-Adresse.
Ein kanonischer Identitätsdeskriptor ordnet dieser stabilen Identität ihre zeitlich gültigen Eigenschaften zu: Service-Schlüssel, Operator-Schlüssel, öffentliche Reward-Adresse, Endpoint-Commitment, Sequenz sowie Wirksamkeits- und Ablaufepoche. Autorisierte Änderungen werden künftig wirksam und referenzieren den vorherigen Deskriptor. Bei historischen Prüfungen darf nicht einfach der neueste Eintrag verwendet werden.
Damit sind auch die Schlüsselrollen getrennt. Der Operator-Schlüssel autorisiert Identitätsänderungen, der online nutzbare Service-Schlüssel operative Antworten. Die privaten Wallet-Schlüssel gehören zu einer anderen Aufgabe: Zahlungen erkennen und Guthaben ausgeben. Der automatische Service-Keystore enthält Service-/Operator-Geheimnisse, keine privaten Wallet-View- oder Spend-Keys. Schlüsseltrennung verlangt weiterhin einen geschützten Betrieb; sie bedeutet nicht, dass der Daemon ganz ohne Geheimnisse auskommt.
Warum „online bedeutet qualifiziert“ verworfen werden muss
Ein Online-Flag ist eine nützliche Diagnose. Als Vergütungsregel wäre es aber abhängig davon, wer es wann setzt. Ein signierter Ping verbessert nur die Authentisierung dieser Aussage. Er macht aus ihr noch keinen Nachweis des vorgeschriebenen Dienstes.
Die technische Entscheidung lautet daher: Nicht einen Status belohnen, sondern gültige, kontextgebundene und rechtzeitig kanonisch enthaltene Belege auswerten. Erst ihre gemeinsame Auswertung kann eine Qualifikation schließen. Die Grenzen bleiben sichtbar: Einzelne erfolgreiche Prüfungen beweisen keine ununterbrochene Uptime; verschiedene Schlüssel beweisen keine unabhängigen Betreiber.
Für mich liegt der Erkenntnisgewinn in dieser Präzisierung. Ein Protokoll entsteht nicht durch möglichst viele Zustandsflags, sondern durch eindeutige Übergänge und überprüfbare Zuständigkeiten. Der nächste Artikel verfolgt diese Übergänge vom gestarteten Daemon bis zur abgeschlossenen Qualifikation.
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.