· ·Überarbeitet: ·Architektur

EPoSe: Vom Service-Konzept zum überprüfbaren System

EPoSe steht für Egalitarian Proof of Service. Die Qwertycoin-Fallstudie erklärt Service-Nachweise, Architektur und die Grenzen der Vergütung.

epose qwertycoin blockchain architektur

Ein Full Node hält die Blockchain vor, prüft neue Daten und stellt anderen Teilnehmern Informationen bereit. Dafür laufen Rechner, SSDs und Netzwerkverbindungen; hinzu kommen Wartung und die Verantwortung, bei Störungen zu reagieren. Mining kann auf derselben Maschine stattfinden. Die Frage „Wer produziert den nächsten Block?“ ist aber nicht identisch mit der Frage „Wer stellt einen definierten Dienst zuverlässig bereit?“. Aus einer Mining-Vergütung folgt keine gesonderte Bezahlung jeder anderen Infrastrukturleistung.

Neu im Thema? Der vorausgehende Beitrag Kryptowährungen, Monero und meine Freude an Open Source erklärt die Grundlagen und die Motivation hinter dieser Fallstudie.

Die ursprüngliche EPoSe-Idee stammt von Xecute, einem ehemaligen Mitglied des Qwertycoin-Projekts. Aufbauend auf dieser historischen Konzeption habe ich im Auftrag der Qwertycoin-Organisation den Service-Layer technisch weiterentwickelt und implementiert. Diese Fallstudie zeigt die Entscheidungen und Fehleranalysen dieses Entwicklungsauftrags.

Aus Betriebskosten wird eine prüfbare Aufgabe

EPoSe steht für Egalitarian Proof of Service. Der Ansatz ist, eine klar definierte Leistung an eine öffentliche Service-Identität zu binden und anhand gemeinsamer Regeln zu vergüten. Der heute implementierte Dienst ist konkret: Ein Node liefert einen angeforderten kanonischen Block im gebundenen Prüfkontext; ausgewählte andere Teilnehmer prüfen die Antwort und signieren Belege.

Der Betreiber muss dafür keinen monetären Stake hinterlegen. Teilnahme ist deshalb weder kostenlos noch ein sicherer Gewinn: Hardware, Bandbreite, Admission-Arbeit und laufender Betrieb kosten Ressourcen. Eine Registrierung allein erzeugt keinen Zahlungsanspruch. Der Dienst muss die Qualifikationsregeln erfüllen, und die nötigen Belege müssen rechtzeitig Bestandteil der maßgeblichen, kanonischen Chain werden.

Die naheliegende Alternative wäre, einfach einen erreichbaren Server zu belohnen. Doch „antwortet jetzt“ ist eine lokale Beobachtung, keine reproduzierbare Grundlage für eine historische Auszahlung. Mein Schwerpunkt lag darin, diese Lücke mit Identitäten, gebundenen Nachweisen, eindeutigen Fristen und einer im C++-Core prüfbaren Reward-Zuordnung zu schließen.

Projekt auf einen Blick

Frage Technische Antwort
Ausgangsproblem Infrastrukturleistung braucht einen präziseren Maßstab als einen Online-Status.
Entwicklungsumfang Service-Protokoll, Integration in den Core, Qualifikation, Rewards sowie Transport- und Zustandsfehler.
Zentrale Entscheidungen Feste Mitgliedschaft je Epoche, ausgewählte Prüfer, kanonisch enthaltene Belege und getrennte Schlüsselrollen.
Nutzen Betreiberanforderungen und Auszahlungen werden nachvollziehbar; Wallet-Geheimnisse müssen nicht im Service-Daemon liegen.
Reifegrad Ein veröffentlichter Core-Stand und neuere offene Optimierungen mit jeweils eigenen Test- und Betriebsbelegen.
Sechs Karten führen von Infrastrukturkosten über Architektur, Qualifikation und Vergütung zu Übermittlung und Betrieb.
Die fünf Fachfragen bauen aufeinander auf. Eine Vergütungsregel braucht einen präzisen Dienst und einen nachvollziehbaren Betriebsweg. Diagramm vergrößern (SVG).

Fünf Fragen statt einer Erfolgserzählung

Die Fachartikel folgen dem Weg von der Regel zur betreibbaren Implementierung:

  1. Architektur: Wie wird aus einer Service-Idee ein Protokoll, das verschiedene Nodes gleich auswerten?
  2. Qualifikation: Was muss zwischen dem Daemon-Start und einer kanonisch belegten Qualifikation geschehen?
  3. Vergütung: Wie prüft der Core eine Auszahlung, ohne private Wallet-Schlüssel zu benötigen?
  4. Übermittlung: Warum können kryptografisch gültige Receipts trotzdem in Warteschlangen scheitern?
  5. Betrieb: Wie lassen sich Zustände ressourcenschonender zurücknehmen, ohne Historie und Auszahlungen zu verändern?

Die Navigation dieser Seite führt in genau dieser Reihenfolge durch die Reihe. Jeder Beitrag ist auch als direkter Einstieg lesbar.

Was der aktuelle Stand trägt

Am Quellenstichtag 17. Oktober 2026 ist Core v2.0.4 veröffentlicht. Die neuere Hauptbranch-Dokumentation beschreibt unter anderem lokale Endpoint-Telemetrie und Checkpoints bis Höhe 23.039. Ein Release beweist nicht, dass jeder Node diesen Stand verwendet.

Die Speicheroptimierung in PR #228 ist implementiert und getestet, aber weiterhin offen. Zusätzlich ist ein einzelner Daemon als 2.0.5-Canary erprobt worden. Das ist weder ein stabiles 2.0.5-Release noch ein flächendeckender Rollout. Teil 05 erklärt, welche Beobachtung welche Aussage stützt.

Bessere Verfügbarkeit und mehr unabhängige Infrastruktur sind Zielsetzungen des Anreizmodells. Ohne entsprechende Messreihen behandle ich sie nicht als nachgewiesene Wirkung. Ebenso wenig wird aus EPoSe ein zweites Verfahren zur Chain-Auswahl: RandomX Proof of Work bleibt dafür zuständig, während Service- und Reward-Regeln konsenskritisch geprüft werden.

Für meine Arbeit ist gerade diese Verbindung interessant: Protokollimplementierung, verteilte Nachrichtenverarbeitung und Verifikation müssen zusammenpassen. Die Reihe beginnt deshalb bei der Architekturentscheidung — und endet nicht bei einem grünen Test, sondern bei der Frage, wie weit ein belastbarer Nachweis tatsächlich reicht.

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.