Fabian Georgi · ·Überarbeitet: ·Architektur
EPoSe-Rewards: Prüfbare Auszahlungen ohne private Wallet-Schlüssel
EPoSe (Egalitarian Proof of Service): Wie Qwertycoin Service-Rewards berechnet, Empfänger auswählt und Outputs ohne private Wallet-Schlüssel prüft.
Ein Validator soll prüfen, ob ein Block den vorgeschriebenen Service-Reward auszahlt. Dafür braucht er Empfänger, Betrag und passende Outputs — aber keinen Zugriff auf das Wallet des Betreibers. Wie lässt sich diese Zahlung eindeutig validieren, ohne private Wallet-Schlüssel in den erreichbaren Daemon zu verlagern?
Bei meiner technischen Weiterentwicklung des EPoSe-Service-Layers im Auftrag von Qwertycoin war das eine eigene Architekturentscheidung. CryptoNote verwendet abgeleitete Einmalschlüssel für Outputs. Die öffentliche Empfängeradresse steht deshalb nicht einfach als lesbares Etikett neben jeder Zahlung.
Drei Schlüsselrollen, nicht ein gemeinsames Geheimnis
Der Operator-Schlüssel autorisiert die Service-Identität und deren Änderungen. Der operative Service-Schlüssel signiert Dienstantworten. Private Wallet-Schlüssel erfüllen andere Aufgaben: Der Spend-Key berechtigt zur Ausgabe; der View-Key ermöglicht die Erkennung eingehender Zahlungen und ist ebenfalls sensibel.
Der Service-Daemon benötigt die erforderlichen Operator-/Service-Geheimnisse, aber im beschriebenen Reward-Pfad keinen privaten Wallet-View- oder Spend-Key. „Ohne private Wallet-Schlüssel“ bedeutet also nicht „ohne private Schlüssel überhaupt“.
Ein früherer Ansatz bezog den privaten View-Key in den Prüfpfad ein. Die engere Alternative ist ein Scoped Payment Proof: ein auf die konkrete Zahlung begrenzter Nachweis. Seine Bindungen umfassen Netzwerk und Parameter, Höhe und Parent-Hash, Auszahlungsepoche und Qualifikationshash, Service-Empfänger und öffentliche Reward-Adresse, Betrag, Coinbase-Transaktionsschlüssel sowie Indizes, Beträge und Schlüssel aller beanspruchten Service-Outputs.
Die Coinbase ist die blockeigene Vergütungstransaktion. Ihr kanonischer Inhalt wird für diesen Nachweis ohne den Payment-Proof-Record gebunden, damit keine zirkuläre Selbstreferenz entsteht. Der Erzeuger verwendet dabei den Transaktionsschlüssel der Coinbase und die öffentlichen Adressschlüssel, nicht die privaten Wallet-Schlüssel des Empfängers. Validatoren rekonstruieren die Erwartung und prüfen den gebundenen Nachweis samt abgeleiteten Outputs. Ein fehlender Nachweis, falscher Betrag oder falscher Empfänger darf nicht als alternative gültige Auszahlung gelten.
Welches Geld wird aufgeteilt?
B bezeichnet die maßgebliche Blocksubvention, F die Transaktionsgebühren, jeweils in atomaren Einheiten. S ist der Service-Anteil und M der gesamte Miner-Anteil. Im anwendbaren Fall gilt:
M = B − S + F
Die 1.000 Basispunkte entsprechen zehn Prozent der Subvention. Sämtliche Gebühren verbleiben beim Miner. Die Implementierung verwendet geprüfte Ganzzahlarithmetik; eine gerundete Gleitkommaanzeige ist kein Ersatz für diese Regel.
Hypothetisches Beispiel: Bei 300 QWC Subvention und 2 QWC Gebühren erhält der Service-Empfänger 30 QWC, der Miner 272 QWC. Zusammen bleiben es 302 QWC. Diese Zahlen sind ausdrücklich keine Aussage zur gegenwärtigen Blocksubvention oder einer Rendite.
Ist die korrekt geschlossene qualifizierte Quellmenge leer, gilt S = 0 und M = B + F: Im Beispiel erhält der Miner 302 QWC. Ein fehlender, beschädigter oder inkonsistenter Quellzustand ist nicht dieselbe Situation. Ihn als „leer“ zu behandeln würde eine fehlerhafte Auszahlung legitimieren; die Prüfung muss stattdessen scheitern.
Auch kleine atomare Beträge zeigen, warum das Abrunden wichtig ist: B = 10.003 und F = 17 ergeben S = 1.000 und M = 9.020. Die Summe bleibt B + F = 10.020.
Die Quell-Epoche bestimmt den Plan
Für einen Block in Auszahlungsepoche E verwendet der Core ausschließlich die geschlossene Qualifikation aus E−1. Im historischen Beispiel stammt ein Reward in Epoche 31 aus der Qualifikation der Epoche 30. Ein gerade online gegangener oder im aktuellen Status als qualifiziert angezeigter Dienst erhält dadurch keinen Anspruch für denselben Block.
Die Funktion select_service_payee_v2 in reward_v2.cpp bildet für jeden qualifizierten Service-Schlüssel einen kontextgebundenen Hash-Rang. Gebunden sind unter anderem Genesis, Parameter, Qualifikation, Auszahlungsepoche und Auszahlungssaat (payout seed). Die Liste wird nach Hash-Wert sortiert; ein Gleichstand wird über den Schlüssel aufgelöst. Ausgewählt wird der Eintrag am Index:
Damit rotiert pro Block ein vorgesehener Service-Empfänger. Es werden nicht gleichzeitig zehn Prozent an jeden Node ausgeschüttet. Die Zahl der Zahlungsplätze unterscheidet sich innerhalb einer Epoche höchstens um eins; gleiche Coin-Summen folgen daraus bei veränderlicher Subvention nicht.
Der Service-Schlüssel wird auf den eingefrorenen Quell-Epochen-Eintrag und dessen exakten Lifecycle-Deskriptor zurückgeführt. Eine spätere Adressänderung schreibt alte Ansprüche nicht um. Ein Empfänger kann mehrere normale CryptoNote-Outputs erhalten, weil der Betrag nach den üblichen Denominationsregeln zerlegt wird; „ein Empfänger“ heißt nicht „genau ein Output“.
Vier Stufen einer Auszahlung
| Stufe | Was lässt sich daraus ableiten? |
|---|---|
Preview mit get_service_rewards |
Erwarteter Empfänger und Quell-Epoche für eine Höhe; noch kein Nachweis eines geminten Blocks. |
Kanonischer Nachweis mit get_epose_block_reward |
Historischer Reward-Plan und Service-Outputs eines konkreten kanonischen Blockhashs wurden mit dem produktiven Coinbase-Prüfer verifiziert. |
| Wallet-Erkennung | Das Wallet erkennt die zugehörigen Einmal-Outputs; eine UI-Anzeige allein ersetzt die kanonische Prüfung nicht. |
| Unlock | Die normale Coinbase-Reife ist erreicht; erst dann ist das erkannte Guthaben nach diesen Regeln verfügbar. |
get_epose_block_reward liefert mapping_available erst nach Rekonstruktion und Prüfung. Die Position eines Outputs allein ist keine Empfängerzuordnung. Unbekannte, alternative oder inkonsistente Blöcke werden nicht zu einem gültigen Mapping umgedeutet.
Für diesen Artikel liegt kein neu unabhängig validierter Live-Auszahlungsbeleg mit Blockhash, Höhe, Quell-Epoche und Service-Output vor. Daraus leite ich weder „es gab noch keine Auszahlung“ noch eine heutige Erfolgsbehauptung ab. Die Darstellung erklärt den implementierten Prüfpfad.
Die Schlüsseltrennung reduziert den nötigen Wallet-Zugriff im Online-Betrieb, garantiert aber keine Anonymität: Die öffentliche Reward-Zuordnung schafft sichtbare Beziehungen. Die übertragbare Entscheidung ist enger: Für eine begrenzte Prüfung soll ein begrenzter, vollständig gebundener Nachweis genügen. Ob die dafür nötigen Receipts rechtzeitig ankommen, ist die nächste Frage — und Gegenstand von Teil 04.
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.