Fabian Georgi · ·Überarbeitet: ·Architektur
EPoSe: Wie aus einem erreichbaren Node ein qualifizierter Dienst wird
EPoSe (Egalitarian Proof of Service): Wie Admission, Snapshot, Prüfer und drei Runden einen Qwertycoin-Node qualifizieren – mit konkreten Epochengrenzen.
Der Daemon läuft und sein Endpunkt antwortet. Trotzdem zeigt die Software noch keine abgeschlossene Qualifikation. Das muss kein Fehler sein: Start, Registrierung, wirksame Mitgliedschaft und qualifizierter Dienst sind verschiedene Zustände. Welche Übergänge fehlen zwischen einem erreichbaren Node und einem Beleg, der für Rewards zählt?
In meinem Entwicklungsauftrag für Qwertycoin war diese Zustandsfolge eine zentrale Aufgabe. Der Dienst canonical-object liefert einen angeforderten kanonischen Block mit signierter Antwort; ein ausgewählter Prüfer kontrolliert sie und signiert den Receipt. Entscheidend ist anschließend nicht nur dessen Signatur, sondern wer in welchem Kontext prüfen durfte und wann der Beleg in der Chain ankam.
Vom Start zur eingefrorenen Mitgliedschaft
Die lokale Konfiguration lädt einen an das Netzwerk gebundenen Keystore. Ein kanonischer Identitätsdeskriptor muss die Service-Identität und ihre Eigenschaften autorisieren. Seine Registrierung heißt noch nicht, dass er in der gerade laufenden Epoche wirksam ist.
Für die Aufnahme in eine Zielepoche folgt die Admission: eine epochegebundene RandomX-Arbeit, die Identität, Deskriptor und kanonischen Kontext bindet. Der Arbeitskontext für Zielepoche E ist der Block am Beginn von E−1. Die Lease muss spätestens zur Enrollment-Frist enthalten sein. Im beschriebenen Profil werden 18 führende Nullbits verlangt. Im idealisierten Modell gleichverteilter Ergebnisse sind im Mittel 2¹⁸ = 262.144 Versuche nötig; das ist keine gemessene Laufzeit und kein fester Geldpreis.
Die maßgebliche Mitgliedschaft wird vor Verarbeitung der Records des Committee-Anchor-Blocks eingefroren. Der Snapshot ist diese kanonisch geordnete, gebundene Menge samt gültigen Deskriptoren. Spätere Ankünfte oder eine neue Reward-Adresse dürfen sie nicht rückwirkend ändern. Die Population ist auf 100 Identitäten begrenzt. Admission-Arbeit und Populationsgrenze sind konkrete Schutzmechanismen, aber kein mathematischer Beweis unabhängiger Betreiber.
Eine bequemere Alternative wäre eine stets aktuelle Liste „aller gerade aktiven Nodes“. Dann könnten sich Auswahlgrundlage und Schlüsselzuordnung aber während der Bewertung verschieben. Der eingefrorene Snapshot gibt allen Prüfern und späteren Validatoren dieselbe Ausgangsbasis.
Wie groß muss das Quorum sein?
N bezeichnet ausschließlich die maßgebliche Snapshot-Population, nicht die Zahl erreichbarer Endpunkte oder gerade verbundener Peers. Bei N ≥ 2 ist k die tatsächliche Zahl der Prüfer eines Subjekts und q die benötigte Zahl unterschiedlicher gültiger Prüferbelege je Runde:
Die kontextgebundene Hash-Auswahl berücksichtigt Netzwerk, Genesis, Parameter, Snapshot, Epoche, Runde, Runden-Anchor, Subjekt und Kandidat. Der eigene Node ist kein eigener Prüfer. Die Kandidaten mit den niedrigsten Auswahlwerten bilden das Committee.
Eine Epoche umfasst drei Runden. Sei rⱼ die Anzahl verschiedener gültiger und rechtzeitig kanonisch berücksichtigter Prüferbelege in Runde j. Vereinfacht gilt:
𝟙 ist die Indikatorfunktion: eins bei erfüllter Bedingung, sonst null. Gültige Identität, erlaubte Kontexte und die übrigen Protokollbedingungen sind vorausgesetzt. Für N ≤ 1 entsteht keine Qualifikation; eine rechnerische Nullschwelle wäre hier das falsche Modell.
| Snapshot | Committee und Quorum | Beispiel gezählter Receipts | Ergebnis |
|---|---|---|---|
| N = 10 | k = 9, q = 6 | 6 / 6 / 0 | Zwei Runden bestanden: qualifiziert. |
| N = 10 | k = 9, q = 6 | 9 / 1 / 0 | Nur eine Runde bestanden: nicht qualifiziert. |
| N = 4 | k = 3, q = 2 | 2 / 1 / 2 | Zwei Runden bestanden: qualifiziert. |
Eine zweite Signaturvariante desselben fachlichen Belegs ist keine zweite Prüferstimme. Ebenso können viele Receipts einer Runde eine fehlende zweite erfolgreiche Runde nicht ersetzen. Das Quorum beschreibt die akzeptierte Evidenz, keine Garantie dauernder Erreichbarkeit.
Historisches Beispiel: Epoche 30
Das Produktionsprofil verwendet 720 Blöcke je Epoche. Bei Aktivierungshöhe null beginnt Epoche E bei 720E. Die Enrollment-Frist liegt 61 Blöcke davor; der Snapshot entsteht 60 Blöcke davor, vor den Records dieses Blocks. Für Epoche 30 bedeutet das Aufnahme bis einschließlich 21.539 und Snapshot bei 21.540.
Die folgende Abfolge ist ausdrücklich historisch, keine Ankündigung einer künftigen Aktivierung:
| Ereignis | Blockhöhe, inklusive |
|---|---|
| Carrier-Fenster Runde 0 | 21.600–21.799 |
| Anchor Runde 1 | 21.800 |
| Carrier-Fenster Runde 1 | 21.801–21.999 |
| Anchor Runde 2 | 22.000 |
| Carrier-Fenster Runde 2 | 22.001–22.259 |
| Abschluss der Qualifikation | nach Verarbeitung von 22.259 |
| Ende Epoche 30 | 22.319 |
| Beginn Folgeepoche 31 | 22.320 |
Ein Carrier ist der Block, dessen Transaktionsdaten den Beleg tragen. Runde 0 verwendet den vorherigen Committee-Anchor. Runde 1 und 2 brauchen dagegen erst ihren jeweiligen Anchor innerhalb der Epoche. Der Anchor-Block selbst kann keinen Beleg seiner neu verankerten Runde tragen: Der früheste Carrier liegt jeweils einen Block später. Die Qualifikation schließt erst nach den Records des inklusiven Deadline-Blocks 22.259.
Blockhöhen geben hier die präzise Reihenfolge vor. Eine aus Zielblockzeiten berechnete Stundenzahl wäre lediglich eine Erwartung. Aufnahmezeitpunkt, tatsächlicher Chain-Fortschritt und spätere Reward-Auswahl verhindern eine pauschale Wartezeitgarantie.
Eine Diagnose in fünf Fragen
Die RPC-Flags in get_epose_info sind absichtlich nicht austauschbar: local_service_node beschreibt den angeforderten Betrieb, key_loaded die lokale Initialisierung, registered den kanonischen Deskriptor und active seine Wirksamkeit. Das Qualifikationsflag ersetzt nicht die Prüfung der richtigen abgeschlossenen Epoche.
Ich gehe deshalb entlang der Zustandsgrenzen vor:
- Ist die stabile Identität mit dem richtigen historischen Deskriptor wirksam?
- Gehört sie zum maßgeblichen Snapshot?
- Stammen die gültigen Belege von den zugeordneten unterschiedlichen Prüfern?
- Gelangten sie in ihrem Carrier-Fenster in die kanonische Chain?
- Ist die betrachtete Qualifikation bereits abgeschlossen — oder noch
pending?
Der Erkenntnisgewinn ist eine gemeinsame Zeit- und Identitätssicht: Nicht ein erfolgreicher Signaturcheck allein entscheidet, sondern die richtige Signatur im richtigen historischen Kontext. Aus der geschlossenen Qualifikation wird anschließend der Reward-Plan der Folgeepoche. Genau diesen Übergang behandelt Teil 03; die Zustellung der Receipts folgt in 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.