Zycord: Ein Peer-to-Peer-Netzwerk selbstzertifizierender Zustandsübergänge

Zycord: Ein Peer-to-Peer-Netzwerk selbstzertifizierender Zustandsübergänge. Von Simstoshi, v1.0, 2026. Jede Transaktion führt den Zustand mit sich, den sie gelesen, und den, den sie geschrieben hat, sodass ihre Verifikation eine reine Funktion ihrer Bytes ist — keine Festplatte, keine Historie, kein Vertrauen und keine Schranke für Parallelität.

Dieses Dokument zitieren. Der archivierte, versionierte Eintrag von Rang ist doi:10.5281/zenodo.22167490. Ein PDF wird von dieser Website ausgeliefert, mit einer abgetrennten Signatur, erstellt mit dem Projektschlüssel E724 39CE DD85 11F9 D607 550B 87FD 60D5 EB4A 0B29. Der Text unten ist genau dieses Dokument, ungekürzt.

1. Einleitung#

Ein Blockchain-Node erledigt heute drei Aufgaben, die nichts miteinander gemein haben: er verbreitet Daten, er verifiziert Berechnungen, und er mutiert Zustand. Daten skalieren mit Bandbreite. Verifikation skaliert mit Kernen: sie ist peinlich parallel, sofern Transaktionen unabhängig geprüft werden können. Zustandsmutation ist die einzige wirklich sequentielle Ressource: irgendwo muss eine einzige maßgebliche Historie der Schreibvorgänge existieren.

Bestehende Entwürfe verflechten alle drei. Im vorherrschenden Modell kann ein Node eine Transaktion nicht verifizieren, ohne den globalen Zustand zu halten, sodass die Verifikation die Skalierungsgrenzen des Zustands erbt; und weil ein einziger Gas-Markt alle drei Ressourcen gemeinsam bepreist, konkurriert eine Signaturprüfung in derselben Auktion wie ein Storage-Schreibvorgang. Neuere Hochleistungsketten parallelisieren die Ausführung innerhalb des Nodes, aber jeder Node führt weiterhin alles erneut aus, und die bindende Schranke wird der Zustands-I/O. Die Antwort waren immer größere Maschinen, was heißt: immer weniger Nodes.

Dieses Papier schlägt den entgegengesetzten Weg ein. Wir parallelisieren nicht die Ausführung gegen gemeinsamen Zustand; wir entfernen den Zustand vollständig aus dem parallelen Pfad. Eine Transaktion wird zu einem Zertifikat, das seine eigenen Ein- und Ausgaben mit sich führt. Seine Verifikation ist eine reine Funktion seiner Bytes. Die Aufgabe der Kette schrumpft darauf, Zertifikate zu ordnen und einen deterministischen Fold über sie laufen zu lassen — eine Schleife aus Vergleichen und Additionen, die den Zustand genau einmal pro Zertifikat berührt. Konflikte machen Blöcke nicht ungültig; sie führen dazu, dass einzelne Zertifikate übersprungen werden, und jeder Skip wird einem gebondeten Underwriter in Rechnung gestellt. Nebenläufigkeit wird nicht zur Laufzeit entdeckt; sie wird Slot für Slot vom Autor des Contracts deklariert.

Die folgenden Abschnitte definieren das Zertifikat (§2), den Fold (§3), typisierten Zustandszugriff (§4), die Versicherungsökonomie (§5), Application-Sequencer (§6), Zensurresistenz (§7), den dualen Gebührenmarkt (§8), Betrugsbeweise und den Weg zum Sampling (§9), die virtuelle Maschine (§10), maschinenlose native Assets (§11), vertrauliche Zahlungen (§12), Networking (§13), den Start in drei Ären und seine Treasury (§14) sowie Messwerte aus der Referenzimplementierung (§15).

2. Zustandsübergangs-Zertifikate#

Ein Zertifikat ist der einzige Transaktionstyp in Zycord:

Certificate {
    reads:   [(slot, access, operand)]   // declared inputs
    writes:  [(slot, op, value)]         // declared outputs
    program: bytes                       // code or native-op reference
    sigs:    [signature]                 // spending authority
    underwriter: (id, sig, seq)          // who insures it (§5)
    ttl:     height                      // valid if committed by this height
    fee:     (seq_gas_bid, par_gas_bid)  // two markets (§8)
}

Ein Slot ist (address, word). Ein Zertifikat ist gültig, wenn drei Prüfungen bestehen, von denen keine irgendeinen Zustand benötigt:

1. jede sig autorisiert die Zellen, die sie ausgibt;
2. die Underwriter-Signatur ist wohlgeformt über (certificate, ttl);
3. die erneute Ausführung von program gegen die deklarierten reads ergibt genau die deklarierten writes. Signaturen müssen kanonisch sein, und das ist eine Konsensregel und nicht die gute Kinderstube einer Bibliothek. Die id eines Zertifikats ist der Hash seiner autorisierenden Felder — reads, writes, program, underwriter, ttl und die Gebührengebote. Signaturen gehören nicht dazu, und der nächste Absatz sagt, warum. Das Seen Set, das über diese id geschlüsselt ist, ist die gesamte Replay-Abwehr. Die Gebühr ist ein autorisierendes Feld und keine Relay-Präferenz, und der Unterschied ist ein monetärer: ein Gebot ist die Zustimmung des Signierenden zu einer Kostenlast, sodass ein Gebot außerhalb der id ein Gebot wäre, das jeder auf dem Transportweg umschreiben könnte — hochgesetzt, um das Guthaben des Senders über die Basisgebühr zu verbrennen, oder auf null gesetzt, um das Zertifikat aus jedem Block herauszuhalten. Was ein Zertifikat zahlt, ist Teil dessen, was sein Signierender autorisiert hat, und die id sagt das. Was Kanonizität einbringt, ist enger als eine id und ist dennoch eine Konsensregel: ein Verfahren, das zwei Kodierungen einer Signatur zulässt, lässt zwei Exemplare eines Zertifikats zu, und zwei Implementierungen, die uneins darüber sind, welches davon verifiziert, sind über ein Zertifikat geforkt, das keine von beiden ungültig nennen kann. Die Regel, die das schließt, ist ein Satz: eine nicht-kanonische Signaturkodierung ist ungültig, und eine Implementierung, deren Verifier eine solche akzeptiert, ist keine Implementierung dieses Protokolls. Solide Verfahren weisen solche Kodierungen ohnehin zurück; der Grund, es aufzuschreiben, ist, dass die, die es nicht tun, ebenfalls verbreitet sind, und eine unabhängige Implementierung, die zu einer davon griffe, würde auf eine Weise abweichen, die kein eigener Test von ihr aufdecken würde.

Randomisierte Nachweise sind die Ausnahme, und die Ausnahme ist strukturell, keine Frage der Kodierung. Ein Range-Proof (§12) ist randomisiert: für eine Aussage wählt der Prover Nonces, sodass eine Aussage unbeschränkt viele gültige Beweise hat, alle kanonisch, und es gibt keine nicht-kanonische Kodierung zurückzuweisen. Zwei gültige Beweise einer Aussage sind nicht zwei Kodierungen eines Beweises; es sind zwei Beweise, und der Zahlungsempfänger — der die Öffnung hält — kann jederzeit einen frischen erzeugen. Kanonizität reicht daher nicht an sie heran. Eine Signatur ist eine von diesen, und das wird leicht übersehen, weil sie keine der exotischen ist. Ed25519 ist ein Schnorr-Wissensbeweis: der Signierende wählt einen Nonce, und jeder Nonce ergibt eine andere Signatur über dieselbe Nachricht, jede gültig und jede vollkommen kanonisch. Deterministische Nonce-Ableitung ist eine Regel für Signierende, die kein Verifier prüfen und keine Kodierungsregel erzwingen kann, denn jeder Nonce-Punkt ist ein kanonisch kodierbarer Punkt wie jeder andere. Also hat eine Autorisierung unbeschränkt viele Signaturen, und eine id, die sie abdeckte, hätte unbeschränkt viele Werte — jeder erzeugbar von einem beliebigen der erforderlichen Signierenden des Zertifikats, der die Signaturen der übrigen unverändert mitträgt, und jeder abrechenbar in einem eigenen Block. Das Bedrohungsmodell ist enger als das eines Beweises und der Schluss derselbe: ein Beweis kann von einem Zahlungsempfänger re-randomisiert werden, der keinen Schlüssel hält, während eine zweite Signatur einen Schlüssel braucht, den das Zertifikat ohnehin verlangt. Die id schließt die Lücke von Bauart her: sie bindet sich an das, was ein Zertifikat autorisiert, und nie an das, was es bloß nachweist, sodass Signaturen wie Beweise gleichermaßen außerhalb des Urbilds der id reisen. Neusignieren oder Re-Randomisieren ergibt dieselbe id, das Seen Set fängt das Duplikat, und ein Block, der beide führt, ist ungültig. Das teilt die Felder eines Zertifikats in zwei Arten — Autorisierung, die die id abdeckt und Signaturen signieren, und Nachweis, den keines von beiden abdeckt. Diese Teilung ist kein Anliegen von §12, das auf vertrauliche Zahlungen wartet; sie ist ab Block 0 tragend, wo der einzige Nachweis, den ein Zertifikat führt, seine Signaturen sind. Ein Verifier prüft den Nachweis aus den Bytes in der parallelen Stufe und verwirft ihn dann; nur die Autorisierung überlebt in die id, das Seen Set und den Fold.

Die Teilung schafft eine Pflicht, die die id nicht mehr trägt, und sie wird hier benannt statt in der Produktion entdeckt. Nachweis außerhalb des Urbilds der id ist Nachweis, den jeder auf dem Transportweg ersetzen kann: nimm ein Zertifikat, ersetze seinen Beweis durch Müll und propagiere — dieselbe id, jetzt ungültiges Exemplar. Zwei Regeln schließen die zwei Löcher, die das aufreißt. Erstens bindet sich ein Block an den Nachweis, den er führt. Die Zertifikatsliste des Blocks ist eine Liste von Exemplar-Hashes — ein Blatt pro Zertifikat, über seine gesamte Kodierung, Nachweis eingeschlossen —, sodass „dieser Block ist gültig“ eine Aussage über Bytes bleibt, die der Block selbst festnagelt. Die id beantwortet ist diese Autorisierung abgerechnet worden, der Exemplar-Hash beantwortet belegen diese Bytes sie, und die beiden Fragen teilen sich nie einen Schlüssel. Ein Blatt genügt, solange der Nachweis von der Kodierung untrennbar ist, wie er es ist, solange der Nachweis aus Signaturen besteht; wenn die Beweise von §12 ihn zu einem eigenen Feld machen, wird das Blatt zum Paar (id, Nachweis-Hash), und die Bindung ist dieselbe Bindung. Was es nie werden darf, ist eine Liste von ids: das würde sich an gar keinen bestimmten Nachweis binden, und da die Wurzel der Zertifikatsliste ein Header-Feld ist und der Header das Urbild des Proof of Work, würde ein Austausch des Nachweises dann nichts kosten und die Arbeit stehen lassen. Das ist der Präzedenzfall der Witness-gebundenen Transaktionen, und ihm wird aus dem Grund gefolgt, aus dem er erfunden wurde: eine id, die Nachweis abdeckte, war formbar, und eine id, die unabgesicherten Nachweis ignoriert, ist blind. Zweitens behandelt das Relay Exemplare, nicht ids: ein Node, der ein Exemplar empfängt, dessen Nachweis die Verifikation nicht besteht, verwirft dieses Exemplar unbeschadet der id — die id wird nicht markiert, nicht als ungültig zwischengespeichert, und ein späteres Exemplar, das verifiziert, wird normal weitergeleitet. Eine verstümmelte Kopie kostet ihren Verstümmler die Bandbreite des Sendens und kostet das Zertifikat nichts. Die Blindheit des Proposers bleibt unversehrt: er nimmt Exemplare auf, die seine eigene zustandslose Prüfung akzeptiert hat, kann also ebenso wenig dazu verleitet werden, einen verstümmelten Beweis aufzunehmen wie eine schlechte Signatur, und die Behauptung aus §3 behält die Bedeutung, die sie hatte.

Gültigkeit ist eine reine Funktion der Bytes des Zertifikats. Jede Maschine kann sie prüfen, in einem Thread-Pool, auf einem anderen Rechner, auf einer GPU, ohne Datenbank, ohne Historie und ohne Synchronisation. Signaturprüfungen batchen über Zertifikate hinweg; Zertifikate desselben Programms batchen zu Single-Instruction-Multiple-Thread-Workloads (§6); Range-Proofs (§12) batchen mit logarithmischen Grenzkosten. Das ist die Eigenschaft, auf der alles Weitere in diesem Papier aufbaut.

Gültigkeit reicht für die Ausführung nicht aus. Zwei gültige Zertifikate können denselben Eingabewert für denselben Slot deklarieren; höchstens eines kann wirksam werden. Wir teilen daher den klassischen Begriff der Transaktionsgültigkeit in zwei: gültig (zustandslos, parallel, von jedem prüfbar) und anwendbar (zustandsbehaftet, sequentiell, allein durch die Position im Ledger entschieden). Der nächste Abschnitt definiert das zweite Prädikat.

3. Das Ledger als Fold#

Ein Block enthält einen Header, eine geordnete Liste von Zertifikats-Hashes und die Zertifikatskörper selbst. Körper sind Kettendaten: ein Block ist nur gültig, wenn seine Körper verfügbar sind (§13). Der Proposer eines Blocks führt nichts aus und hält keinen Anwendungszustand; er ordnet Bytes, deren Gültigkeit er aus den Bytes selbst prüfen kann. Er ist nicht ganz zustandslos, und die Ausnahme verdient es, benannt statt weggerundet zu werden: er muss die Menge der innerhalb des TTL-Fensters gesehenen Zertifikats-ids führen, denn ein Zertifikat zweimal aufzunehmen macht den Block ungültig, und dazu darf niemand versehentlich verleitet werden können. Diese Menge ist durch die TTL beschränkt und beschneidbar, weshalb die TTL ein Konsensparameter ist und keine Relay-Präferenz. Das Proposen ist bewusst billig und dumm, nicht bewusst blind.

Der Zustand der Kette ist definiert als ein Fold über die geordneten Zertifikate:

apply_block(S, B):
    assert bodies_available(B)
    assert ∀c: height ≤ c.ttl ∧ ¬seen(c.id)     // an expired or replayed certificate
                                                 // makes the BLOCK invalid: a signature
                                                 // is billable at most once, and never at
                                                 // a position its signer could not avoid
    C ← sort(B.certs, key = (underwriter.id, underwriter.seq, c.id))
    for c in C:
        if leased(S, c):     bill(c, LEASED); mark_seen(c.id, c.ttl); continue  // §7; Era 1 only
        ok ← true
        for (slot, access, x) in c.reads:
            EXACT:  ok ← ok ∧ (S[slot] = x)
            GUARD:  ok ← ok ∧ pred_x(S[slot])
        if ¬ok:              bill(c, STALE);  mark_seen(c.id, c.ttl); continue
        w ← stage(S, c.writes)   // a target whose address is spent, or a delta that would
                                 // over- or underflow, fails HERE — nothing has landed yet
        if w = ⊥:            bill(c, STALE);  mark_seen(c.id, c.ttl); continue
        commit(S, w); settle_fees(c); mark_seen(c.id, c.ttl)

Schreibvorgänge werden geprüft, und zwar bevor einer von ihnen landet. Frühere Entwürfe dieser Skizze wendeten die Write-Menge bedingungslos an, was sich las, als könne eine Gutschrift eine ausgegebene Zelle wiederbeleben und als könne ein Delta überlaufen. Beides trifft nicht zu und beides wäre fatal, deshalb steht der Staging-Schritt jetzt in der Skizze, statt der Spezifikation überlassen zu bleiben. Arithmetik wird überall geprüft, wo sie auftritt: ein Delta, das über 2²⁵⁶ hinaus oder unter null tragen würde, überspringt das Zertifikat, statt es überlaufen zu lassen, weshalb auch die Supply-Obergrenzen von §11 unter unbegrenzt vielen gleichzeitigen Mints halten. Ein Schreibvorgang auf eine Adresse, deren Autorität verbrannt wurde, schlägt lautstark fehl, statt zu verschwinden — genau dafür ist die dauerhafte Spent-Registry da, und sie ist der Ursprung der einen Ausnahme im Zurechnungstheorem von §5.

**leased ist Maschinerie der Ära 1 und bei Genesis nicht vorhanden.** Es wird hier gezeigt, weil dieser Abschnitt den Fold des gesamten Protokolls spezifiziert, aber die Start-Ära hat keine Leases, keine Forced Queue und keine Mitsignierenden, die damit zu schützen wären, sodass der Zweig im Genesis-Binary unerreichbar ist — und unerreichbarer Konsenscode ist unauditierbarer Konsenscode, also wird er nicht ausgeliefert. Eine offene Frage wird markiert statt übertüncht: so wie geschrieben rechnet LEASED ein Zertifikat an einer Position ab, die sein Signierender nicht hätte vorhersehen können, was genau das ist, was die Behauptung vier Zeilen weiter oben verbietet. Entweder darf dieser Ausgang nicht abrechnen, oder er muss den Block ungültig machen. Die Wahl gehört zu der Ära, die Leases einführt, und sie wird hier festgehalten, damit diese Ära den Widerspruch nicht stillschweigend erben kann.

Eigenschaften, die es wert sind, ausdrücklich genannt zu werden:

Ein Skip ist Semantik, kein Fehlschlag. Ein Zertifikat, dessen Reads nicht mehr gelten, wird übersprungen, seine Skip-Gebühr wird seinem Underwriter in Rechnung gestellt (§5), und der Block bleibt gültig. Aufnahme und Anwendung sind verschiedene Ereignisse. Das ist es, was dem Proposer erlaubt, blind zu sein: er kann nie einen ungültigen Block erzeugen, indem er ein veraltetes Zertifikat aufnimmt.

Determinismus. Jeder Node leitet aus einer identischen Blockfolge einen identischen Zustand ab. Der Sortierschlüssel (underwriter, seq, certificate id) ist eine totale Ordnung auf dem Inhalt des Blocks, sodass der Fold unempfindlich dagegen ist, wie ein Proposer Zertifikate verschiedener Underwriter verschachtelt — und er lässt dem Proposer überhaupt keinen Ermessensspielraum, nicht einmal zwischen zwei Zertifikaten, die ein Underwriter beim selben seq signiert hat. Die eigene Pipeline eines Underwriters (seq aufsteigend) committet in der Reihenfolge, in der sie signiert wurde, ganz gleich in welcher Reihenfolge der Proposer sie eingereicht hat.

Genau eine Zustandsberührung pro Zertifikat. Der Fold führt Vergleiche, Additionen und Schreibvorgänge auf einer heißen Key-Value-Arbeitsmenge aus: keine Codeausführung, keine Signaturverifikation, keine erneute Ausführung. All das ist bereits geschehen, parallel, während der Gültigkeitsprüfung.

Und keine Arithmetik auf elliptischen Kurven. Vertrauliche Zahlungen (§12) legen Pedersen-Commitments in Slot-Werte, und ein Commitment ist ein Kurvenpunkt. Das Verfahren ist homomorph und die Summe zweier Commitments ist sinnvoll, was den Fold einlädt, sie zu addieren. Der Fold weigert sich. Eine Punktaddition kostet Hunderte von Nanosekunden gegenüber den ~1 ns einer u256-Addition, und eine EC-Operation in der einzigen sequentiellen Stufe würde das Budget verausgaben, das diese Architektur schützt. Der Fold speichert Commitment-Bytes lediglich in frische Zellen und vergleicht sie auf Gleichheit — beides Speicheroperationen; alle Kurvenarithmetik geschieht in der parallelen Stufe oder in der Wallet des Eigentümers (§12). Dieselbe Disziplin gilt für das Hashen, weiter unten.

Ein Stück Kryptografie wird nicht entfernt, und das Gegenteil zu behaupten wäre zu bequem: die id eines Zertifikats ist ein Hash seiner autorisierenden Felder (§2), und das Seen Set ist über diese id geschlüsselt, also muss sie jemand berechnen. Worauf es ankommt, ist wo, und die Antwort lautet, dass es nicht hier sein muss. Die id hängt von den Bytes des Zertifikats ab und von sonst nichts — kein Zustand, keine Ordnung, keine Position —, sie wird also neben den Signaturprüfungen in der parallelen Stufe berechnet und in den Fold hineingetragen, genau wie das Zertifikat selbst. Eine Implementierung, die sie stattdessen in der sequentiellen Schleife neu berechnet, wird feststellen, dass Hashing eine Stufe dominiert, in der es um Speicher gehen soll, und dieser Fehler verdient es, benannt zu werden, weil er leicht zu machen ist. Wir wollen präzise sein darüber, was hier entfernt wird und was nicht. Der Fold führt weiterhin wahlfreien Zugriff über den vollen Zustand aus, eine Berührung pro deklariertem Slot, und ein committender Node hält diesen Zustand weiterhin. Was den sequentiellen Pfad verlässt, ist alles, was den Zugriff auf einer herkömmlichen Kette umgibt — Interpretation, Signaturprüfungen, Hashing, Authentifizierung eines merkleisierten Speichers pro Operation —, sodass der Zustand in einer flachen Tabelle leben kann und die eine sequentielle Stufe des Systems eine enge Schleife über Speicher ist. Der Referenz-Fold hält 883.000 Slot-Operationen pro Sekunde und Kern auf einem Zehnkern-x86-Desktop durch (§15), und er ist die einzige Stufe, die nicht parallelisiert.

Wertgleichheit, keine Versionen. Anwendbarkeit vergleicht deklarierte gelesene Werte, keine Versionszähler. Weil die Ausführung eine reine Funktion der Read-Menge ist, ist ein Slot, der sich geändert hat und wieder zurückgeändert wurde (der ABA-Fall), weiterhin anwendbar: das Zertifikat jetzt anzuwenden ist semantisch identisch damit, es damals ausgeführt zu haben. Das System überspringt daher strikt seltener als versionsbasierte Nebenläufigkeitskontrolle. Für Commitment-wertige Slots ist der Vergleich Byte-Gleichheit des Commitments: undurchsichtig, exakt und ebenso günstig, sobald die Kanonizitätsbedingungen von §4 durchgesetzt werden.

Replay und einmalige Abrechnung. Die id eines Zertifikats ist der Hash dessen, was es autorisiert, und nie der Signaturen, die die Autorisierung nachweisen (§2), und angewandte und abgerechnet übersprungene Zertifikate werden gleichermaßen als gesehen markiert. Der Unterschied ist es, der die Regel zur Regel macht: ein Signierender, der einen Körper mit frischem Nonce neu signiert, erzeugt dieselbe id, sodass das Seen Set die Kopie fängt, statt sie abzurechnen. Ein gesehenes oder abgelaufenes Zertifikat aufzunehmen macht den Block ungültig — eine Signatur ist also höchstens einmal abrechenbar, und nur an einer Position, die ihr Signierender durch das Signieren akzeptiert hat. Ohne diese Regel könnte ein Block Producer fremde Zertifikate erneut aufnehmen oder absichtlich verzögern, um die Mittel ihrer Underwriter zu verbrennen. TTLs sind konsensbeschränkt, sodass das Seen Set beschneidbar bleibt.

4. Typisierter Zustandszugriff#

Ein Fold, der nur Exact Reads unterstützte, würde jeden populären Contract serialisieren: tausend Zertifikate, die einen AMM-Pool berühren, ergäben eine Anwendung und 999 Skips. Zycords Antwort ist, dass Nebenläufigkeit vom Autor des Contracts deklariert wird, pro Slot, im Zertifikatsformat selbst. Es gibt drei Zugriffsdisziplinen:

Exact. Im Stil von SLOAD: der Read liefert den Wert des Slots in die Berechnung und nagelt das Zertifikat darauf fest. Beliebige Logik; Konflikte auf heißen Slots; die Domäne der Application-Sequencer (§6).

Guarded Delta. Das Zertifikat behauptet ein Prädikat über den Slot — balance ≥ 10 — ohne den Wert in die Berechnung zu lesen, und schreibt ein vorzeichenbehaftetes Delta — balance += −10. Der Fold prüft das Prädikat gegen den aktuellen Zustand und wendet das Delta an. Beliebig viele guarded Belastungen und Gutschriften auf denselben Slot kommutieren: sie werden in beliebiger Reihenfolge angewandt, und ein Skip tritt nur dann ein, wenn ein Guard tatsächlich fehlschlägt (eine echte Überziehung), nicht wenn sich der Kontostand bloß geändert hat. Diese eine Disziplin deckt Überweisungen, supply-begrenzte Mints, Allowances und Vault-Anteile ab, also die überwältigende Mehrheit aller On-Chain-Schreibvorgänge.

Pure Delta. Ein vorzeichenbehaftetes Delta ohne Guard. Es kann nie in Konflikt geraten und nie überspringen. Tips, Zähler, Akkumulatoren, Belohnungszählungen.

Die Regel, die das Modell tragfähig hält: guarded Werte dürfen nicht in die Berechnung fließen. Ein Assert gibt nichts zurück; ein Delta liest nichts. Die erneute Ausführung bleibt daher eine reine Funktion der deklarierten Reads, und die zustandslose Gültigkeit (§2) bleibt erhalten. Die Ahnenreihe dieser Idee ist alt und solide: Escrow-Transaktionen in Datenbanken, Transactional Boosting, CRDTs [9][10][11]. Aber bestehende Ketten nutzen Kommutativität bestenfalls innerhalb des Schedulers eines Nodes aus; Zycord macht sie zum Nebenläufigkeitsvertrag zwischen Nodes, durchgesetzt vom Zertifikatsformat und bepreist von der Versicherungsökonomie.

Eine zweite Regel desselben Ranges, von §12 erzwungen: kein Slot, der einen verborgenen Wert hält, lässt einen Guard Dritter zu. Ein Guard, dessen Ausgang öffentlich beobachtbar ist — angewandt oder übersprungen —, gegen einen Kontostand, der geheim sein soll, ist ein Kontostand-Orakel: reiche balance ≥ x ein, beobachte den Fold, bisektiere, und log₂(balance) Versuche lesen die Zahl, ohne das Commitment je zu öffnen. Die Abhilfe ist strukturell, nicht statistisch. Verborgener Wert lebt allein in One-Shot-Zellen, ausgebbar durch die Signatur ihres Eigentümers; die Guarded-Delta-Disziplin, deren ganzer Sinn darin besteht, dass Fremde einen Slot gefahrlos berühren können, bleibt Slots vorbehalten, deren Werte öffentlich sind. Pull-artige Zahlungen — Allowances, Abonnements, Vault-Abbuchungen — existieren daher nur auf der transparenten Schiene (§12).

Diese Regel durchzusetzen setzt voraus, dass der Fold einen verborgenen Slot von einem öffentlichen unterscheiden kann, und in einer flachen Tabelle kann er das nicht durch bloße Betrachtung: ein komprimiertes Commitment und ein u256-Kontostand sind beide 32 Bytes. Eine Zelle mit verborgenem Wert ist deshalb keine gewöhnliche Zelle, die zufällig ein Commitment hält; sie ist eine eigene Zellenart, die allein von der nativen abgeschirmten Operation (§12) erzeugt wird und in einer reservierten, ableitbaren Region des Adressraums lebt, sodass die Disziplin eines Slots eine Funktion seiner Adresse und wie alles andere aus den Bytes prüfbar ist. Andernfalls würde ein Guarded Delta, das — aus Versehen oder böswillig — auf einen Commitment-Slot gerichtet ist, den Fold dazu bringen, eine u256 zu einer Kurvenpunkt-Kodierung zu addieren: die arithmetischen Prüfungen bestehen, das Ergebnis ist kein Commitment, und die Zelle wird unausgebbar. Wert, der im Stillen vernichtet wird, ohne dass im Fold etwas fehlschlägt, ist genau das, was der Staging-Schritt von §3 verhindern soll, und die Zellenart ist es, die ihn auch diesen Fall verhindern lässt.

Zwei weitere Primitive vervollständigen das Modell:

Write-once-Zellen. Eine Adresse, die nie auf der Kette erschienen ist, befindet sich im Zustand ∅; ein erster Schreibvorgang überführt sie in stored; eine Signatur ihres Schlüssels überführt sie dauerhaft in spent. Auf eine frische Zelle zu schreiben ist per Definition konfliktfrei, sodass die Zahlung an eine neu abgeleitete Adresse der schnelle Pfad ohne Contention ist. Das ist das chimärische Erbe des Netzwerks [8]: kontoartige persistente Zellen für Contracts, UTXO-artige One-Shot-Zellen für Zahlungen, in einem Ledger. Die Werte unter einer ausgegebenen Zelle sind kompaktierbar, sobald der Block, der sie ausgab, tiefer als der Reorg Horizon begraben ist — eine Tiefe in Bestätigungen, kein Finality-Gadget, da die Start-Ära keine Finality hat, auf die zu warten wäre. Der Registry-Eintrag, der die Adresse als ausgegeben festhält, wird nie kompaktiert: er ist es, der verhindert, dass die Adresse wiederbelebt wird, und er ist das ehrliche offene Problem des Protokolls, das es mit jedem Nullifier-Set-Entwurf teilt. Die Stealth-Ausgaben von §12 fahren unverändert auf dieser Schiene mit und lassen die Registry genau in dem Tempo wachsen, in dem transparente Zahlungen es ohnehin tun: ein Eintrag pro Ausgabe, verborgen oder nicht.

Null ist Abwesenheit. Ein Slot, der nie beschrieben wurde, und ein auf null geschriebener Slot sind derselbe Slot: null zu schreiben löscht die Zelle, und eine abwesende Zelle zu lesen ergibt null. Das ist keine Implementierungsbequemlichkeit, sondern eine Konsensanforderung, und sie ist gleich doppelt tragend. Sie ist es, die einen Guard oder einen Exact Read 0 nennen lässt, ohne fragen zu müssen, ob der Slot existiert — es gibt keine dritte Antwort zu unterscheiden. Und sie ist es, die den State Root eine Funktion des Zustands bleiben lässt statt der Historie, die ihn hervorgebracht hat: bliebe eine geleerte Zelle als explizite Null zurück, würden zwei Nodes, die auf verschiedenen Wegen zu identischen Kontoständen gelangt sind, sich auf verschiedene Roots festlegen, und das ist eine Kettenspaltung, die durch Buchhaltung eintritt.

Das schränkt §12 ein, mit einer scharfen Kante. Ein Pedersen-Commitment vG + rH ist im Allgemeinen nicht die Nullzeichenkette, sodass ein verborgener Kontostand durch Arithmetik nicht abwesend wird und niemand außer dem Eigentümer erkennen kann, dass er leer ist; persistente verborgene Slots wären für immer unkompaktierbar, was ein weiterer Grund dafür ist, dass die abgeschirmte Schiene ausschließlich aus One-Shot-Zellen besteht, die dadurch sterben, dass sie ausgegeben werden — ein Übergang, den Null-ist-Abwesenheit nie bereitstellen musste. Die Kante ist, dass v = 0, r = 0 das neutrale Element der Gruppe ist, und in einer Ristretto-Kodierung ist das neutrale Element zweiunddreißig Nullbytes — genau die Zeichenkette, die abwesend bedeutet. Ein Commitment darf nie mit Löschung kollidieren, also ist das neutrale Element kein gültiges Commitment: die abgeschirmte Operation weist es beim Eintritt zurück, neben den Prüfungen der kanonischen Kodierung, die ein Kurvenpunkt ohnehin braucht (nicht-kanonische Körperelemente, Torsionsanteile), und das Referenz-H ist ein NUMS-Punkt mit veröffentlichter Ableitung. „Byte-Gleichheit ist exakt“ (§3) ist eine Aussage über Punkte erst, wenn diese Bedingungen gelten.

Der Epoch Beacon. Programme dürfen Umgebungswerte (Zeitstempel, Höhe) nicht direkt lesen; das würde die Ausführung zu einer Funktion von etwas anderem als den deklarierten Reads machen. Stattdessen schreibt das Protokoll einmal pro Epoche einen Epoch Beacon in einen reservierten Slot, und Programme lesen ihn wie jeden anderen Slot, idealerweise mit einem Bereichs-Guard (epoch ∈ [e, e+2]), was Zeitbewusstsein ohne Veraltung pro Block liefert.

5. Versicherte Zertifikate: Jeder Konflikt hat einen Eigentümer#

Skips dürfen nicht kostenlos sein, sonst ertrinkt der Mempool: ein Angreifer könnte tausende gültige Zertifikate gegen dieselbe Eingabe veröffentlichen, Blöcke füllen und für eines zahlen. Aber die übersprungenen Zertifikate haben den Kontostand des Senders nie berührt, sodass es nichts gibt, was dem Sender zu belasten wäre; der Gebühren-Slot ist genau die veraltete Eingabe. Zycords Antwort: kein Zertifikat existiert ohne einen Underwriter, eine Partei, deren gebondete Mittel dafür einstehen.

Es gibt drei Wege, getragen zu werden, ein Mechanismus in drei Erscheinungsformen:

1. Selbstversichert. Der Sender hängt eine kleine Kaution aus einer unbelasteten Zelle an. Nichts wird im Voraus geleast: der Fold reserviert die Kaution an der Position des Zertifikats im Block (die Skizze in §3 lässt diese Klempnerei aus), und ein Zertifikat, das die Anwendung mit bereits verbrauchter Kaution erreicht, wird verworfen — nicht abgerechnet, nicht als gesehen markiert, frei zur erneuten Einreichung gegen eine frische Kaution —, sodass ehrliche Nutzer bei Rennen um ihre eigene Kautionszelle nichts verlieren. Ein Skip mit intakter Kaution verbrennt einen Teil davon. Das Veröffentlichen kostet demgegenüber nichts, sodass der Mempool durch die Relay-Policy statt durch den Konsens beschränkt ist: Nodes begrenzen, was sie pro Underwriter vorhalten, dieselbe Arbeitsteilung wie in jedem Mempool seit Bitcoin. Das ist die erlaubnisfreie Untergrenze: jeder kann immer ohne Gegenpartei transagieren. Es ist auch der einzige Modus in der Start-Ära (§14), was Genesis minimal hält. Die Kautionszelle ist öffentlich und sie gehört dem Sender, was Selbstversicherung zu einem dauerhaften Identifikator macht, der an jedes von ihm signierte Zertifikat geheftet ist. Für transparente Zahlungen enthüllt das nichts, was die Zahlung nicht ohnehin enthüllt; für eine abgeschirmte Zahlung (§12) hebt es die Stealth-Ausgabe auf, die es bezahlt, und §12 greift genau deshalb zum Mitsignieren.
2. Mitsigniert. Ein gebondeter Underwriter prüft das Zertifikat gegen frischen Zustand, signiert (certificate, ttl, seq) mit und übernimmt die Skip-Haftung. Im Gegenzug kann er dem Sender außerhalb der Kette in Rechnung stellen, und seine Mitsignatur ist ein Produkt: eine Vorbestätigung, hinter der das eigene Kapital eines Underwriters steht. Nichts an dieser Rolle erfordert zu sehen, was ein Zertifikat bewegt: Veraltung ist eine Eigenschaft der Zellen — lebendig oder ausgegeben —, nicht der Beträge, sodass ein Underwriter ein abgeschirmtes Zertifikat bepreist wie ein transparentes, ohne dass ihm der Wert anvertraut würde.

Zwei Dinge, die dieses Versprechen nicht verwischen darf, denn das Papier hat sie zuvor verwischt. Die Antwort des Protokolls auf einen Skip ist, die Skip-Gebühr aus der Kaution des Underwriters zu verbrennen — eine Strafe, an niemanden gezahlt, und das ist es, was verhindert, dass jemand vom Verursachen von Skips profitiert. Den Sender zu entschädigen ist eine andere Transaktion: das ist das kommerzielle Versprechen des Underwriters, und dieser Entwurf spezifiziert es noch nicht als Konsensmechanismus. Es dazu zu machen ist keine Frage der Formulierung — es braucht einen in der Mitsignatur deklarierten Policy-Wert, einen benannten Begünstigten, der nicht der Sender ist (sonst ist das Produkt eine Einladung zum Versicherungsbetrug), und eine auf der Kette verfolgte Gesamtexposition, damit ein Bond nicht zweimal verkauft werden kann. Bis es die gibt, ist „mein Bond zahlt“ eine Behauptung, die ein Underwriter aufstellt und ein Markt bepreist, keine Regel, die der Fold durchsetzt, und das Papier sagt das, statt die Mehrdeutigkeit das Produkt verkaufen zu lassen.

1. Erzwungen. Der Pfad der Zensurresistenz (§7), getragen von einer Nutzerkaution und, als Einziger, garantiert zur Anwendung kommend. Die Ökonomie ist zwischen zwei Arten von Fehlverhalten asymmetrisch, und die Asymmetrie ist der Punkt:

Objektive Verfehlungen werden geslasht. Wenn ein Underwriter zwei Zertifikate mitsigniert, deren Exact Reads in Konflikt stehen (derselbe Slot, derselbe deklarierte Wert, überlappende TTLs), sind die beiden Signaturen ein in sich geschlossener On-Chain-Beweis für Äquivokation; jeder kann sie einreichen, und der Bond wird geslasht. Ebenso wird ein Underwriter, der ein Zertifikat mitsigniert, das die zustandslose Gültigkeit nicht besteht (eine schlechte Signatur, eine falsche Ausführung), durch bloße erneute Ausführung geslasht: das Zertifikat ist der Betrugsbeweis (§9).

Subjektive Verfehlungen werden nie geslasht. Zwei verschiedene Underwriter, die um denselben Slot rennen, haben keine beweisbare Verfehlung begangen; der in Fold-Reihenfolge spätere trägt eine kleine Skip-Gebühr, mehr nicht. Langsame, offline befindliche oder unzuverlässige Underwriter verlieren Zulassung und Reputation, keine Mittel. Netzwerke sterben, wenn Latenz zur Enteignung wird; Zycord enteignet nur, was sich aus Bytes beweisen lässt.

Und die Rechnung landet bei einer Partei, die das Zertifikat benennt. Der Titel dieses Abschnitts ist ein Theorem und kein Slogan, und es lohnt, ihn mit seinen Kanten auszusprechen. Ein abgerechneter Skip ist immer genau eines von drei Dingen: der fehlschlagende Read oder Write liegt unter einer Adresse, deren Schlüssel das Zertifikat signiert hat; oder es ist ein Mint, der gegen einen anderen Mint desselben Assets durch den deklarierten Minter rennt, der ebenfalls signiert hat; oder es ist eine Gutschrift an eine One-Shot-Adresse, deren eigener Inhaber sie nach dem Signieren des Zertifikats stillgelegt hat (RETIRE, §11). Keine Partei, die das Zertifikat nicht benennt, kann verursachen, dass es abgerechnet wird. Nur der dritte Fall trennt die Rechnung von der Ursache, und er ist von Bauart her beschränkt: nur One-Shot-Zellen können je stillgelegt werden, sodass ein Zahlungsempfänger, der eine persistente Adresse veröffentlicht, überhaupt keine Angriffsfläche bietet; ein Zertifikat darf höchstens eine feste Anzahl von Adressen stilllegen (§13), was begrenzt, wie viele in Umlauf befindliche Zahlungen ein Stilllegungsschub berühren kann; und die Skip-Gebühr wird verbrannt statt ausgezahlt, sodass niemand davon profitiert, sie auszulösen.

Die Bemessung des Bonds folgt einer Ungleichung: der Bond eines Underwriters muss die maximale Skip-Haftung übersteigen, die er innerhalb eines TTL-Fensters ansammeln kann, und das Unbonding muss länger dauern als das Betrugsbeweis-Fenster, sodass niemand sich fehlverhalten, abheben und verschwinden kann.

6. Application-Sequencer#

Guarded Deltas lösen die Contention bei Zahlungen auf. Was bleibt, ist Exact-Read-Logik auf heißem Zustand — ein Orderbuch, ein AMM-Pool —, wo zwei ehrliche Underwriter im Rennen weiterhin Skips erzeugen. Die Antwort des Protokolls ist, den Contract seinen Serialisierer wählen zu lassen: ein Contract darf auf der Kette den Schlüssel eines gebondeten Sequencers registrieren, wonach nur noch von diesem Sequencer mitsignierte Zertifikate den Exact-Read-Pfad des Contracts nehmen dürfen.

Der Sequencer ist ein gewöhnlicher Server, betrieben vom Anwendungsteam — Websockets, Queues, Autoscaling, beliebige Web-2-Maschinerie —, und ihm wird allein für die Lebendigkeit vertraut, nie für die Sicherheit. Er kann keinen Zustand fälschen: lügt er beim Bau über Eingaben, überspringt das Zertifikat einfach gegen den kanonischen Fold, und die Lüge kostet seinen Bond. Was er bietet:

Serialisierung. Er verleast Slots an in Umlauf befindliche Zertifikate mit kurzen TTLs und verkettet jedes Zertifikat auf den deklarierten Ausgaben des vorherigen (er nummeriert seine Mitsignaturen mit seq; die totale Ordnung des Folds garantiert, dass seine Pipeline der Reihe nach committet, unabhängig davon, wie der Proposer mischt). Contention auf heißen Slots wird zu einem Scheduling-Problem außerhalb der Kette, für die Kette unsichtbar.

Batch-Zertifikate. N Transaktionen über denselben Codepfad falten sich zu einem Zertifikat mit aggregierten Reads/Writes, interne Zwischenschreibvorgänge werden herausgekürzt, und N Unterausführungen verifizieren als eine einzige SIMT-Workload. Hier wird die GPU-These konkret: die Instanz, die serialisiert, ist auch die Instanz, die Arbeit in die Form packt, die parallele Hardware will, und wird dafür über den Parallel-Gas-Markt (§8) bezahlt.

Atomare Komponierbarkeit. Eine Transaktion, die zwei Anwendungen umspannt, wird außerhalb der Kette von beiden Sequencern gemeinsam gebaut (ein Zwei-Phasen-Commit über Slot-Leases) und landet als ein Zertifikat mit beiden Mitsignaturen auf der Kette, atomar von Bauart her. Anwendungsübergreifende Koordination geschieht dort, wo Koordination günstig ist; die Kette sieht nur das Ergebnis.

Die ehrliche Offenlegung: ein Sequencer sieht den Orderfluss seiner Anwendung zuerst und ist damit der natürliche Ort für die MEV dieser Anwendung. Zycord macht den Handel explizit: die Anwendung vereinnahmt ihre eigene MEV, statt sie an Block-Proposer abfließen zu lassen, und §7 begrenzt die Macht, die das mit sich bringt. Derselbe erzwungene Pfad, der den Austritt garantiert, diszipliniert auch die Extraktion: ein Nutzer, dem die Behandlung durch einen Sequencer missfällt, kann ihn vollständig umgehen und zahlt allein mit Latenz.

7. Erzwungene Aufnahme mit garantierter Anwendung#

Ein Contract, dessen einzige Tür sein Sequencer ist, ist ein Gefängnis, wenn der Sequencer zensiert. Jeder Nutzer hat daher einen langsamen Pfad, der niemandes Erlaubnis braucht:

Ein Nutzer (oder ein beliebiger Relayer) rekonstruiert den Zustand aus dem öffentlichen Fold, baut ein Zertifikat, hängt eine Kaution an und reicht es in die Forced Queue ein. Proposer müssen eingereihte Zertifikate innerhalb von F Blöcken aufnehmen (§13). An seiner Aufnahmeposition prüft der Fold seine Reads gegen den aktuellen Zustand; gelten sie, gewährt der Fold eine deterministische Lease auf seine Slots und plant die Anwendung D Blöcke im Voraus ein. Während der Lease ordnen sich mitsignierte Zertifikate, die diese Slots berühren, dahinter ein. Das erzwungene Zertifikat kann daher nicht übersprungen werden: Zulassung bedeutet Anwendung.

Die Gnadenfrist D ist für die in Umlauf befindliche Pipeline des ehrlichen Sequencers gedacht — den Teil davon, der die geleasten Slots nicht berührt. Alles, was sie berührt, ordnet sich hinter dem erzwungenen Zertifikat ein, mitsigniert wie selbstversichert gleichermaßen, und das ist es, was „kann nicht übersprungen werden“ wahr statt bloß erstrebt macht: ein Zertifikat, dessen Reads für die gesamte Gnadenfrist geschützt sind, kann während ihrer nicht veralten. Weil Schreibvorgänge deklariert sind, ist der Zustand nach der Anwendung vorhersagbar, sodass ein Sequencer mit Gewissheit über ein noch nicht angewandtes erzwungenes Zertifikat hinweg verketten kann.

Eine Lease darf nur Slots abdecken, über die das Zertifikat Autorität hat. Das ist eine Bedingung, die der Mechanismus nicht umsonst mitbringt und ohne die der Rest des Entwurfs nicht überlebte. Einen Read zu deklarieren erfordert keine Signatur — nur Schreibvorgänge leiten Autorisierung ab —, sodass ohne diese Regel jeder ein erzwungenes Zertifikat einreihen könnte, das Reads über fremde Slots deklariert, und sie für D Blöcke zum Preis einer Kaution einfrieren könnte. Die Quote pro Contract begrenzt das ebenfalls nicht, da native Zahlungen zu keinem Contract gehören. Eine Lease ist daher nur über Slots zulässig, zu deren Beschreibung das Zertifikat berechtigt ist, was derselbe Autoritätstest ist, den der Fold ohnehin anwendet, nur einen Schritt früher eingesetzt.

Weitere Anti-Grief-Schranken: eine Quote pro Contract und Epoche; eine Kaution, die die auferlegten Kosten deckt; geleaste Slots weisen weitere erzwungene Einträge zurück, bis sie freigegeben sind.

Zwei Konsequenzen erheben dies von einem Merkmal zu einem Überlebensmechanismus. Erstens kehrt sich Zensur um: sie kostet den Zensor (entgangene Gebühren, Nutzer, die ihn umgehen) und kostet das Netzwerk nichts. Zweitens degradiert ein Contract, dessen Sequencer verschwindet — oder eine Kette, deren gesamte Underwriter-Klasse angegriffen wird —, in den Nur-erzwungen-Modus: langsam, teuer und lebendig. Kein Zustand wird je verwaist, und kein Betreiber ist für die Sicherheit tragend. Für ein Netzwerk, das seinen Gründer überleben soll, ist das die Eigenschaft, auf die es ankommt.

8. Zwei Märkte: Sequential und Parallel Gas#

Eine Kette verbraucht drei Ressourcen unterschiedlicher Skalierbarkeitsklassen — Daten, Verifikation, Mutation —, und sie in einem Markt zu bepreisen bedeutet, dass die Verifikation eines Zero-Knowledge-Beweises in der Auktion mit einem Storage-Schreibvorgang konkurriert. Zycord teilt die Gebühr in zwei unabhängige Märkte:

Sequential Gas bepreist Fold-Operationen: Read-Prüfungen, Schreibvorgänge, Leases. Es ist die knappe Ressource, die eine Schleife, die jeder Node der Reihe nach durchläuft, und sie wird entsprechend bepreist.

Parallel Gas bepreist Verifikation: Signaturprüfungen, Einheiten erneuter Ausführung, Bytes und schwere Precompiles (Beweisverifikation, Signaturaggregation, Post-Quanten-Verfahren). Es ist reichlich vorhanden, sein Angebot wächst mit jedem Kern und jeder GPU, die dem Netzwerk hinzugefügt wird, und seine Blockobergrenze ist hoch und günstig angesetzt.

Beide Märkte haben die Gestalt von EIP-1559 [15], jeder in seiner eigenen Einheit: die Basisgebühr wird verbrannt und die Prioritätsgebühr zahlt den Producer des Blocks — auf Zertifikate, die angewandt werden, und nur auf diese. Die Gebühr eines übersprungenen Zertifikats wird vollständig verbrannt und zahlt niemanden, und das ist kein Detail des Gebührenplans, sondern die tragende Regel des gesamten ökonomischen Modells. Würde ein Skip ein Trinkgeld abwerfen, dann würde die Partei, die entscheidet, was ein Block enthält, dafür bezahlt, das Scheitern anderer zu arrangieren, und der billigste Weg zum Verdienst wäre, Skips zu farmen statt Arbeit aufzunehmen. Das Verbrennen kehrt das um: ein Skip verbraucht Platz unter der Obergrenze und wirft nichts ab, sodass ein Producer, der seinen Erlös maximiert, die Anwendung maximiert und nicht bloß gleichgültig gegenüber dem Verursachen von Skips ist, sondern aktiv dagegen. Die sequentielle Basisgebühr zu verbrennen macht Stau in der einen knappen Schleife deflationär (§14.2). Die parallele Basisgebühr zu verbrennen hält den Proposer gleichgültig dagegen, welche schweren Zertifikate die günstige Spur füllen, sodass Priorität in der Verifikationsspur nicht unter der Hand verkauft werden kann. Die Teilung folgt der Richtung mehrdimensionaler Gebührenentwürfe [18], durchgezogen bis zu vollständig getrennten Märkten. Was keiner der beiden Märkte entscheidet, ist, wie viel von der knappen Ressource es überhaupt geben soll; das ist eine Obergrenze, und §8.1 gibt die Regel an, die sie bewegt.

Die Folge ist das Entwurfsziel, formuliert als Invariante: schwere Kryptografie belastet das Netzwerk nicht, aus ökonomischer Konstruktion. Ein Zertifikat, das einen großen Beweis verifiziert, aber zwei Slots schreibt, zahlt fast alles im günstigen Markt. Zycord ist damit als die Settlement-Schicht positioniert, auf der kryptografische Protokolle wirtschaftlich sind, die für Ketten mit einem einzigen Markt zu schwer wären. Derselbe Markt bezahlt Sequencer für das Formen von Arbeit: ein Sequencer aggregiert N Transaktionen zu einem Batch-Zertifikat, zahlt ein paralleles Gebot dafür und stellt seinen Nutzern N in Rechnung — die Marge ist die Gebühr dafür, Arbeit SIMT-förmig zu machen (§6).

8.1 Die elastische sequentielle Obergrenze#

Ein Gebührenmarkt bepreist Knappheit; er entscheidet nicht, wie viel Knappheit es geben soll. Die zwei bisherigen Antworten auf diese Frage sind beide gescheitert, in entgegengesetzte Richtungen. Eine feste Obergrenze macht die Verbreitung zu einer Auktion, die die Nutzer verlieren: als Bitcoins Blöcke voll wurden, überstiegen die Gebühren 50 $ und gewöhnliche Zahlungen wurden schlicht von der Kette wegbepreist, allein zum Vorteil dessen, der den Platz verkaufte. Eine offene Obergrenze ohne Nachfrage scheitert andersherum: ihre Large-Block-Forks kauften Kapazität, die niemand nutzte, und bezahlten sie mit Sicherheit, denn Gebühren kommen aus Volumen, nicht aus Platz. Zycords Obergrenze ist daher weder fest noch abgestimmt — ein Netzwerk, dessen Autor nicht da sein wird, um es zu forken, kann routinemäßiges Wachstum nicht als Governance-Ereignis behandeln, und eine Abstimmung ist ein Griff: Miner profitieren davon, das Angebot zu verknappen, große Betreiber davon, es über das hinaus auszuweiten, was kleine Nodes mitverfolgen können. Die Obergrenze ist eine Konsensfunktion gemessener Nachfrage, ab Block 0 in Genesis, von niemandem bewegt.

Die Regel hat drei Teile, einen pro Zeitskala. Innerhalb eines Blocks hat jeder Markt ein Ziel T und eine harte elastische Schranke 2T; die Basisgebühr schreitet pro Block um einen beschränkten Bruchteil auf das Gleichgewicht zu, in der EIP-1559-Gestalt von §8 — beschränkt, weil von unbeschränkter Anpassung bekannt ist, dass sie oszilliert statt zu konvergieren. Über Epochen hinweg folgt das sequentielle Ziel der Nachfrage: T ← clamp(2·median_applied(e), T − T/Δ, T + T/Γ), nach unten begrenzt auf seinen Genesis-Wert — wobei median_applied Sequential Gas allein auf angewandten Zertifikaten zählt. Übersprungene Zertifikate verbrennen ihre Gebühren und registrieren nichts, sodass der einzige Weg, die Obergrenze anzuheben, darin besteht, Anwendung zu erringen: nachhaltige, konfliktfreie, Basisgebühr verbrennende Nutzung. Wachstum zu erzwingen kostet einen Angreifer genau das, was organische Verbreitung alle anderen kostet, was heißt, dass der Mechanismus sie nicht unterscheiden kann und es auch nicht muss. Wachstum ist zusätzlich an ein Epochen-Gesundheitssignal geknüpft — die beobachtete Rate konkurrierender Header bleibt unter einer Schwelle (Ära 0), Checkpoints finalisieren planmäßig (ab Ära 1) —, sodass Kapazität nie dem davonläuft, was die Propagation nachweislich trägt. Ein Stale Block ist genau das Ereignis, das die Kette nicht aufzeichnet, also wird das Signal auf dem einzigen ehrlichen Weg importiert: Header dürfen jüngste konkurrierende Header zitieren, unvergütet; Zitieren erfordert echten Proof of Work, während das Unterdrücken des Signals erfordert, dass nahezu jeder Proposer Zitate weglässt, die ein einziger ehrlicher wiederherstellt. Die Asymmetrie neigt das Tor zur Vorsicht, und das ist die Richtung, in die ein Tor neigen sollte. Pro Block ein Burst-Ventil: ein Proposer darf 2T bis zu 4T überschreiten und verwirkt dabei quadratisch das, was der Block ihm gutschreibt — seinen Subventionsanteil zuzüglich der Gebühren des Blocks, gegen den Plan von §14.2, als dauerhaften Fehlbetrag, der an niemanden umgeleitet wird —, wobei die Strafe auf dem gesamten Sequential Gas bemessen wird, angewandt und übersprungen gleichermaßen, sodass der Überschuss nicht mit fabriziertem Konflikt zum Rabatt vollgestopft werden kann. Die Bemessungsgrundlage ist der Erlös des Producers und nicht seine Subvention allein, weil die beiden nicht gemeinsam abklingen: die Subvention fällt auf der Kurve von §14.2 auf etwa 1,6 % ihres Genesis-Werts, während der Gebührenerlös, für den ein Burst gekauft wird, überhaupt nicht fällt, sodass ein allein in Subvention bemessener Abschreckungsbetrag genau dort aufhört abzuschrecken, wo die Gelegenheit am größten ist. Eine dauerhafte Eigenschaft muss in etwas bepreist werden, das dem Nutzen folgt, und das ist das Argument, das EIP-1559 für die Kopplung einer Belastung an den Wert macht, den die Manipulation einbringt. Bei Genesis ändert das fast nichts, da die Gebühren nahe null sind. Der Treasury-Anteil von §14.1 wird der ungekürzten Subvention entnommen und wird nie verwirkt, weil das Bursten die Wahl des Producers ist und die Treasury daran nicht beteiligt ist. Echte Nachfragespitzen erkaufen sich sofort Durchlass und informieren den Epochenregler; Spam erkauft sich eine Strafe. Der Präzedenzfall ist Moneros Penalty-Median-Mechanismus [19], dessen dokumentierter Stillstand — Wachstum friert ein, wenn die typische Arbeitseinheit sich dem Median nähert — hier von Bauart her vermieden wird, da Batch-Zertifikate (§6) die typische Einheit klein gegenüber dem Ziel halten, und die Ratenschranken folgen der Linie adaptiver Limits [20]. Die parallele Obergrenze braucht nichts von dieser Sorgfalt: sie ist als festes hohes Vielfaches des sequentiellen Ziels angeheftet und erbt dessen Wachstum, was die Invariante von §8, als Kapazität ausgedrückt, wiederholt.

Man lese das Tauziehen am Mechanismus ab. Die Gebühr des Nutzers strebt zum Boden, denn anhaltender Stau ist per Definition das Signal, das die Obergrenze anhebt und sie wieder senkt — das Bitcoin-Gleichgewicht der dauerhaften Auktion ist unerreichbar. Der Producer wird durch Subvention bezahlt, solange das Netzwerk jung ist, und durch Volumen in der Reife, nie durch Knappheit; das Verbrennen lässt jede Stauepisode der Münze zugutekommen, die der Producer hält, und §8 hat die Anwendung, nicht den Ausschluss, bereits zur erlösmaximierenden Strategie gemacht. Eine Ehrlichkeit, gleich zweifach: Elastizität garantiert allein, dass Kapazität nie der Grund ist, aus dem die Verbreitung stockt — sie erzeugt keine Nachfrage, wie die Large-Block-Forks bewiesen haben —, und eine Obergrenze, die wächst, lässt den Zustand wachsen, weshalb Schreibvorgänge auf frische Slots in Sequential Gas über Deltas bepreist werden: die flache Tabelle, in der der Fold lebt, dehnt sich nicht schneller aus als die Obergrenze, die sie speist. Eine Kalibrierungsregel folgt daraus und wird genannt, weil ihre Verletzung lautlos ist: das Genesis-Verhältnis von sequentiellem Ziel zu Byte-Obergrenze muss unter der Dichte des Verkehrs liegen, für den das Netzwerk gebaut ist, damit ein Block voller gewöhnlicher Zahlungen die Basisgebühr anhebt statt sie zu senken. Ein Markt, der auf seine eigene Auslegungslast verkehrt herum reagiert, bepreist nichts, und das Verhältnis wird vor dem Freeze aus gemessenem Verkehr gesetzt.

Kapazität über die Ären hinweg. Die Obergrenzen für Zertifikatsanzahl und Bytes skalieren mit dem sequentiellen Ziel, statt fest daneben zu stehen: bei Genesis binden alle drei innerhalb eines Faktors zwei zueinander, sodass eine feste nach einer einzigen Verdopplung zur eigentlichen Schranke wird und die elastische dekorativ zurücklässt. Hinter ihnen stehen statische Kapazitäten: die Breite der Zertifikatsliste, die die Merkle-Tiefe eines Blocks festlegt, und die Byte-Kapazität, die ein Block erreichen darf, gepaart mit den Transportkonstanten darunter — ein Block reist in Stücken, sodass keine einzelne Netzwerknachricht einen Block begrenzt. Die Listenbreite wird bei Genesis für die gesamte Kurve bemessen (2²⁵ Zertifikate; sie später neu anzuheften würde zwei Merkle-Breiten in eine Kette bringen, und die virtuelle Auffüllung macht den Spielraum kostenlos). Die Byte-Kapazität wird für das Startnetzwerk bemessen und an Ärengrenzen neu angeheftet — dort ohnehin Hard Forks (§14) —, gegen die Propagation, die das Gesundheitstor gemessen hat; nie innerhalb einer Ära, nie per Abstimmung. Die Kurve, der diese Leiter dient, folgt aus Γ: das Ziel wächst um höchstens 2× pro Jahr voller gesunder Blöcke, sodass die Genesis-Obergrenze von ~90 angewandten Zertifikaten pro Sekunde (ein Block nach §15 je 30-Sekunden-Intervall) ~11.000 pro Sekunde in sieben Jahren anhaltender Nachfrage erreicht, ~90.000 in zehn, und in weniger als vierzehn die ~1,1 Millionen pro Sekunde, die die Listenbreite von 2²⁵ festlegt — die eine Wand, die keine Ära verschiebt, und daher das Ende der Leiter statt einer Sprosse auf ihr. Die Einheit sind Zertifikate, nicht Zahlungen: ein Zertifikat trägt eine Zahlung, oder die N, die ein Sequencer hineingebatcht hat (§6), sodass jede Zahl eine Untergrenze für Transaktionen ist und keine Behauptung über sie. Die Bedingungen sind genau drei, jede bereits ein Mechanismus von oben: die Nachfrage muss volle Blöcke tragen, denn angewandtes Gas ist die einzige Eingabe, die T anhebt; die Propagation muss das Gesundheitstor offen halten, denn Wachstum wird in der Epoche zurückgehalten, in der es schließt; und die Neuanheftungen müssen an den Ären landen, denn dazwischen ist die Byte-Kapazität die Wand. Rechenleistung ist keine Bedingung — der Fold schafft das ferne Ende der Kurve auf einem einzigen gemessenen Kern (§15), und Verifikation skaliert mit Hardware, die dem Netzwerk nicht gehört (§2). Bandbreite schon: Körper sind Kettendaten (§13), und Sampling (§9) teilt die Verifikation, nie die Daten, sodass jeder Node jedes Byte trägt und ein Producer am oberen Ende der Kurve allein von der Bandbreite her Rechenzentrumsklasse ist — ein akzeptierter Endzustand für Producer, und für sonst niemanden, da die Kosten pro Node bei der Verifikation sich in die andere Richtung bewegen (§9). Bevor die Bandbreite bindet, tut es der Zustand: die Spent-Registry (§4) wächst um einen Eintrag pro One-Shot-Ausgabe, in der Größenordnung von 10² Terabyte pro Jahr bei 10⁵ Zertifikaten pro Sekunde, was das in §4 erklärte offene Problem von einem stehenden Punkt in Arbeit verwandelt, die die Kurve terminiert.

Konstanten (Genesis, illustrativ, wie §13): Wachstumsdivisor Γ = 512 pro Epoche (die Obergrenze kann sich pro Jahr voller Blöcke höchstens verdoppeln); Abklingdivisor Δ = 1024 (ungenutzte Kapazität halbiert sich in ~2 Jahren, nie unter Genesis); Burst-Schranke 4T, Verwirkung des Subventionsanteils des Producers und der Gebühren des Blocks an der Schranke (der Treasury-Anteil von §14.1 wird der ungekürzten Subvention entnommen und wird nie verwirkt, weil das Bursten die Wahl des Producers ist und die Treasury daran nicht beteiligt ist); Gesundheitstor: zitierte konkurrierende Header ≤ 2 % der Blöcke pro Epoche; Kapazität der Zertifikatsliste 2²⁵ (strukturell, siehe oben); Byte-Obergrenze 2,5 MB bei Genesis, mit dem Ziel skalierend bis zu einer strukturellen Byte-Kapazität von 8 MB (an den Ären neu angeheftet); Signaturobergrenze pro Block 6.000 bei Genesis, mit dem Ziel skalierend, geprüft bevor irgendeine Signatur verifiziert wird — eine Schranke für die Arbeit, getrennt gehalten vom Preis des Parallel Gas, weil ein Parameter nicht zugleich die Arbeit begrenzen und den Markt bepreisen kann.

9. Sofortige Betrugsbeweise und der Weg zum Sampling#

Weil Gültigkeit eine reine Funktion der Bytes eines Zertifikats ist, ist ein ungültiges Zertifikat sein eigener Betrugsbeweis. Wer es erneut ausführt, kann es in einer Nachricht widerlegen, sofort, ohne Zustand und ohne interaktives Bisektionsspiel. In der Startkonfiguration ist der Punkt auf die beste Weise gegenstandslos: jeder Node verifiziert jedes Zertifikat, bevor er einen Block akzeptiert, sodass ein ungültiges Zertifikat nie lange genug überlebt, um eine Anfechtung zu brauchen. Das Fenster wird bedeutsam, sobald die Verifikation gesampelt wird, und dort ist es ein Propagationsparameter statt eines Streitprotokolls: eine Handvoll Blöcke, damit eine Nachricht das Netzwerk durchquert, angelastet dem Underwriter, der das Zertifikat attestiert hat (§5). Man vergleiche die Alternativen: Optimistic Rollups brauchen wochenlange interaktive Streitverfahren, weil das Anfechten Zustand am angefochtenen Schritt erfordert; beweisbasierte Systeme vermeiden Streitverfahren, zahlen aber für Prover, die Größenordnungen mehr kosten als die Ausführung. Zycords Betrugsbeweise kosten, was Verifikation kostet: ~1× erneute Ausführung.

Das eröffnet den Skalierungsweg, den Ketten mit erneuter Ausführung nicht gehen können. Das Netzwerk braucht im Prinzip nicht auf ewig jeden Node dazu, jedes Zertifikat zu verifizieren. Mit Underwriter-Bonds an Ort und Stelle kann die Verifikation gesampelt werden: ein per VRF gewähltes Komitee pro Zertifikat, so bemessen, dass die Wahrscheinlichkeit eines unverifizierten ungültigen Zertifikats vernachlässigbar ist, wobei es jedem Full Node freisteht, alles zu prüfen, und eine Nachricht zum Slashen genügt. Bei Genesis verifiziert jeder alles; das ist günstig und parallel. Sampling ist Roadmap, nicht Start. Aber es ist die Roadmap, die die Kurve der Branche umkehrt: die Kosten pro Node fallen, während das Netzwerk wächst, wo im Paradigma der erneuten Ausführung die Kosten pro Node mit dem Durchsatz wachsen, bis nur noch Rechenzentren bleiben.

10. Die Maschine: cEVM#

Zycord betreibt eine virtuelle Maschine: die cEVM, einen Dialekt der EVM von Ethereum [2], angepasst an Zertifikate. Die Wahl ist bewusst. Das Neuheitsbudget des Projekts wird für das Zustands-, Nebenläufigkeits- und Ökonomiemodell ausgegeben; die Maschine sollte das Vertrauteste im System sein. Solidity, seine Compiler, Auditoren und Werkzeuge werden übernommen.

Unterschiede zur Standard-EVM:

• SLOAD kompiliert zu einem Exact Read (im Zertifikat deklariert); SSTORE zu einem SET-Write.
• Neue Opcodes SASSERT(slot, pred) und SDELTA(slot, ±v) machen Guarded und Pure Deltas zugänglich. Ein SASSERT legt nichts auf den Stack — Guards geben keine Werte zurück (§4).
• TIMESTAMP und NUMBER lesen den Epoch-Beacon-Slot; es gibt keine andere Umgebungseingabe.
• Die Gas-Messung ist dual (§8): Storage-Opcodes messen Sequential Gas; Berechnung, Calldata und Precompiles messen Parallel Gas.
• Das Transaktionsformat ist das Zertifikat. Ethereum-Contracts portieren auf Quellcode-Ebene; rohe Wallet-Kompatibilität wird nicht behauptet, und wir tun auch nicht so. Ein portierter Contract läuft im All-Exact-Modus: vom ersten Tag an korrekt, über einen Sequencer serialisiert, wenn er heiß ist. Die Parallelität ist pro Slot zuschaltbar, typischerweise ein kleiner Diff (die Balance-Map eines Tokens wandert in ~30 Zeilen von SLOAD/SSTORE zu SASSERT/SDELTA). Damit das Vorzeigemerkmal ab dem ersten Block der VM-Ära sichtbar ist, statt auf Portierungen zu warten, wird die Maschine zusammen mit einer nativen Standardbibliothek aktiviert — Token, Trinkgeldkasse, Escrow, Vesting und eine hybride Orderbuch-/AMM-Referenz —, Delta-first geschrieben und an bekannten Adressen vorab deployt.

11. Assets ohne Maschine#

Die Start-Ära braucht eine Ökonomie, bevor sie einen Computer braucht. Zycord liefert daher native Assets als Zertifikatsoperationen ab Block 0 aus, ohne jede VM: ISSUE (eine Asset-id mit einer Supply-Obergrenze in einer Write-once-Zelle erzeugen), MINT (guarded: minted + Δ ≤ cap), TRANSFER (Guard balance ≥ Δ, gepaarte Deltas; eine Gutschrift, die auf ein Pure Delta oder eine frische One-Shot-Zelle zielt, ist das Trinkgeld, sodass Trinkgeld geben keinen eigenen Opcode verbraucht) und RETIRE (eine Adresse verbrennen, ohne sie auszugeben: keine Reads, kein bewegter Wert, ein reiner Schreibvorgang, der die Zelle als ausgegeben markiert — das eigentliche Ausgeben geschieht automatisch innerhalb von TRANSFER). RETIRE verdient sich seinen Platz gleich doppelt. Es ist das Kompaktierungs- und Privatsphäre-Primitiv, das einen Zahlungsempfänger eine One-Shot-Adresse löschen lässt, sobald sie gedient hat; und es ist die Operation hinter der einzigen Ausnahme im Zurechnungstheorem von §5 — der dritte Fall existiert, weil es Stilllegung gibt, weshalb das Zertifikatsformat stillgelegte Adressen pro Zertifikat begrenzt (§13) und weshalb das Theorem mit dieser Kante statt um sie herum formuliert ist. Die Menge ist abgeschlossen: diese vier sind der gesamte Genesis-Befehlssatz, jede andere Operation — Bonding eingeschlossen — kommt mit dem Regelwerk einer späteren Ära (§14), und das Zurechnungstheorem von §5 ist genau gegen diese Oberfläche bewiesen.

Ein Streamer, der zehntausend Trinkgelder in einem Block empfängt, kostet den Fold zehntausend kommutative Additionen: null Konflikte, null Skips, kein Sequencer, keine Maschine. Trinkgeldkulturen auf früheren Ketten lebten nach dem Belieben von Plattform-APIs und starben mit ihnen; hier ist das Trinkgeld ein Protokoll-Primitiv. Es ist zudem, nicht nebenbei, ein fortwährender Stresstest für die zentrale Behauptung des Systems. Die Supply-Obergrenzen der nativen Münze leben hier, auf der transparenten Schiene, durchgesetzt von der geprüften Arithmetik von §3, und §12 lässt sie unangetastet.

12. Vertrauliche Zahlungen#

Die vorangehenden Abschnitte behandeln den Betrag einer Zahlung als öffentlich. Dieser Abschnitt fügt die Möglichkeit hinzu, ihn zu verbergen und den Empfänger hinter einer einmaligen Adresse zu verbergen, unter Erhalt der Eigenschaften der vorangehenden Abschnitte. Der Entwurf ist enger als die Systeme, von denen er abgeleitet ist: jede der folgenden Einschränkungen schließt einen Angriff, den ein allgemeinerer Entwurf mit schwererer Maschinerie beantworten würde.

Was verborgen wird und was nicht. Eine abgeschirmte Zahlung verbirgt ihren Betrag und schiebt die Verknüpfung zu ihrem Empfänger auf. Man sei genau bei „aufschieben“: eine frische Stealth-Ausgabe ist im Moment ihres Empfangs unverknüpfbar, aber da es keinen Ring gibt, benennt ihr späteres Ausgeben die ausgegebene Ausgabe, und diese Benennung enthüllt, welche frühere Zahlung sie finanziert hat. Unverknüpfbarkeit hält bis zur ersten Ausgabe und endet dort; es ist eine Verzögerung, keine Löschung. Ebenso wenig verbirgt der Entwurf die Graphenposition des Senders: Zertifikate werden öffentlich signiert, getragen und geordnet, sodass ein Beobachter sieht, dass eine Zahlung stattfand und wer sie getragen hat — nicht den Betrag und nicht, bis eine Ausgabe es offenlegt, welche Ausgabe eines Empfängers wohin ging. Die ehrliche Beschreibung lautet Confidential Transactions mit einmaligen Empfängeradressen über einem öffentlichen Graphen, und der Graph deanonymisiert rückwirkend, während Ausgaben ausgegeben werden. Senderseitige Mehrdeutigkeit — Ringsignaturen, Mitgliedschaftsbeweise über historische Ausgaben — liegt außerhalb des Umfangs: ein Ring verweist auf die Ausgaben anderer, was die Gültigkeit zu einer Funktion der Historie macht, und die Zustandslosigkeit von §2 ist die Eigenschaft, die das Protokoll nicht aufgibt. Moneros Bedrohungsmodell verlangt ein anderes Protokoll.

Die abgeschirmte Ausgabe. Eine abgeschirmte Zahlung schreibt eine frische Write-once-Zelle (§4), deren Adresse eine Stealth-Adresse ist: der Sender leitet aus dem veröffentlichten View Key des Empfängers und einem eigenen ephemeren Schlüssel eine einmalige Adresse ab, die nur der Empfänger erkennen und für die nur der Spend Key des Empfängers signieren kann. Der Wert der Zelle ist ein Pedersen-Commitment C = vG + rH; daneben reisen ein Range-Proof, dass v ∈ [0, 2⁶⁴), und das an den View Key des Empfängers verschlüsselte Paar (v, r), dazu ein Ein-Byte-View-Tag, das eine scannende Wallet die meisten fremden Ausgaben früh verwerfen lässt. Die Primitive sind Confidential Transactions mit Stealth-Adressierung: die betragsverbergende Hälfte von RingCT ohne den Ring, jede mit etabliertem Produktiveinsatz.

Gültigkeit bleibt eine Funktion der Bytes. Die Bilanzprüfung eines abgeschirmten Zertifikats ist die Commitment-Gleichung: deklarierte Eingabe-Commitments minus deklarierte Ausgabe-Commitments ergibt fee·G, mit öffentlicher Gebühr (siehe den Pool unten). Die Gleichung, die Range-Proofs und die Signaturen werden alle allein aus den Bytes des Zertifikats geprüft, in der parallelen Stufe, gebatcht: die Bulletproof-Verifikation amortisiert logarithmisch über einen Batch, und nichts davon berührt Zustand. Ein gefälschtes inflationäres Zertifikat — eines, dessen Commitments unter einer gebrochenen Annahme oder einem gebrochenen Verifier nicht aufgehen — ist immer noch rein durch seine Bytes gültig oder ungültig, und der Fold prüft es nie erneut; das ist die Teilung in gültig/anwendbar aus §2, die wie entworfen arbeitet, und keine Ausnahme von ihr, und die Pool-Regel unten ist es, die einen Bruch der Sicherheit davon abhält, unbeschränkt zu sein. Hier hört auch der duale Gebührenmarkt (§8) auf, ein Effizienzargument zu sein, und wird zu einem ermöglichenden: auf einer Kette mit einem einzigen Gas-Markt sind vertrauliche Transaktionen teuer, weil eine Millisekunde Beweisverifikation in derselben Auktion konkurriert wie ein Storage-Schreibvorgang, während hier die Verifikation vollständig im par_gas landet — von Bauart her günstig — und der sequentielle Markt sie nie zu Gesicht bekommt.

Der Fold speichert Bytes. Bei der Anwendung ist eine abgeschirmte Zahlung das günstigste Zertifikat, das der Fold zu sehen bekommt: ihre Ausgabezelle ist frisch, sie kann also nicht in Konflikt geraten (der schnelle Pfad ohne Contention aus §4); ihre Eingabezellen sind lebendig oder ausgegeben, ein Registry-Nachschlag; und der Schreibvorgang legt 32 Bytes Commitment ab. Keine Kurvenarithmetik betritt die sequentielle Stufe (§3). Die Alternative, die die Regel ausschließt, ist ein persistenter „Akkumulationsslot“, dem Fremde homomorph gutschreiben, und die scheitert an drei Fronten: sie bringt EC-Addition in die sequentielle Schleife (§3); sie erzeugt einen wiederverwendeten öffentlichen Identifikator, genau die Heuristik gemeinsamen Eigentums, die die Stealth-Adresse vermeiden soll; und ein verborgener persistenter Kontostand lädt zu den Guards Dritter ein, die §4 verbietet. Die Akkumulation geschieht in der Wallet: ein Empfänger hält viele One-Shot-Ausgaben, alle über einen View Key erkennbar, und konsolidiert sie, indem er mehrere seiner eigenen Zellen in eine frische Zelle ausgibt, ein gewöhnliches abgeschirmtes Zertifikat, in dem Takt, der ihm beliebt, mit dem Epoch Beacon (§4) als Uhr. Die Summe, die ein persistenter Slot auf der Kette führen würde, führt der Eigentümer außerhalb der Kette — und die Konsolidierung ist nicht spurenfrei: mehrere Eingaben in einem Zertifikat zu deklarieren ist ein öffentliches Ereignis gemeinsamen Eigentums, schwächer als ein wiederverwendeter Identifikator, aber real, sodass die Wallet-Policy darin besteht, es zu minimieren und nie unverwandte Herkünfte in einer Konsolidierung zu mischen.

Nur der Eigentümer gibt aus, und was das verbietet. Ein verborgener Wert ist allein durch die Signatur seines Eigentümers über seine eigene Zelle ausgebbar. Es gibt keine Guards Dritter gegen verborgene Kontostände (§4) und daher keine Pull-Zahlungen auf der abgeschirmten Schiene: keine Allowances, keine Abonnements, kein Vault, der die abgeschirmten Mittel eines Nutzers abräumt. Diese Muster bleiben auf der transparenten Schiene, und die Grenze zwischen den Schienen ist ein Zertifikat breit. Die Einschränkung beseitigt das Kontostand-Orakel: wenn kein Fremder eine Vermutung gegen einen Kontostand einreichen und den Skip auslesen kann, hat das Orakel keinen Betreiber.

Der abgeschirmte Pool ist eine öffentliche ganze Zahl, die der Fold durchsetzt. Gebühren sind öffentlich. Coinbase ist öffentlich. Zahlungen an Contract-Slots sind öffentlich. Jede Überquerung zwischen der transparenten und der abgeschirmten Schiene bewegt ein öffentlich sichtbares v — ein abschirmendes Zertifikat öffnet v auf dem Weg hinein, ein entschirmendes Zertifikat öffnet v auf dem Weg hinaus. Die Poolsumme lebt daher in einem reservierten Slot, im Klartext, allein durch Guarded Delta bewegt (§4): das Abschirmen schreibt ihm gut, pool += v; das Entschirmen guarded pool ≥ v und belastet ihn, pool += −v; die Gebühr eines abgeschirmten Zertifikats belastet ihn ebenso. Der Slot ist genau Σ ein − Σ aus, und die Guarded-Delta-Disziplin lässt unbeschränkt viele Überquerungen ohne Contention kommutieren.

Das macht den Pool zu einem Zaun, nicht zu einem Alarm. Beträge zu verbergen tauscht die geprüfte u256-Arithmetik von §3 gegen die berechnungsmäßige Sicherheit einer Diskreter-Logarithmus-Annahme ein, und ein Bruch — der Annahme oder, weit wahrscheinlicher, eines Verifiers — fälscht Commitments innerhalb des Pools. Aber ein gefälschtes Commitment trägt keinen Klartext, und Wert verlässt den Pool nur durch Entschirmen, was den öffentlichen Slot unter seinem Guard belastet. Der Slot stieg allein durch echtes Abschirmen, sodass ein Entschirmen, das ihn unter null treiben würde, übersprungen wird: gefälschter Wert kann den Guard nicht passieren. Inflation leert den Pool nicht; sie schafft es nicht hinaus. Der Wirkungsradius eines kryptografischen Versagens ist beschränkt, durch eine Fold-Regel statt durch die Wachsamkeit eines Auditors, auf den realen Inhalt des Pools, und der Fehlermodus ist kein stiller Abfluss, sondern ein sichtbares Echtzeitrennen, in dem die letzten ehrlichen Halter nicht mehr entschirmen können — schlimm, beschränkt und beobachtbar, und das ist die Eindämmung, die ein System ohne Notfallteam von Bauart her haben muss. Der Präzedenzfall ist konkret: der Zcash-Sprout-Fälschungsbug war überlebbar, weil sein abgeschirmter Pool eine beschränkte, auditierbare Größe war; hier ist diese Größe nicht bloß auditierbar, sondern im Fold tragend. Die nativen Supply-Obergrenzen von §11 leben auf der transparenten Schiene und bleiben von geprüfter Arithmetik durchgesetzt, unangetastet.

Der Pool hat einen Preis für die Privatsphäre, und der gehört ins Protokoll: Grenzüberquerungen legen exakte öffentliche Beträge offen, und markante Beträge korrelieren. Ein Beobachter, der v den Pool verlassen sieht, kurz nachdem v + fee ihn betrat, hat etwas erfahren, was kein Commitment verborgen hat. Standardstückelungen an der Grenze stumpfen das ab, und Wallets verwenden sie standardmäßig; das Protokoll schreibt sie nicht vor, denn eine Konsensregel kann einen markanten Betrag nicht von einem legitimen unterscheiden. Verknüpfbarkeit unter Verkehrsanalyse wird ausgesprochen, samt ihrer Abmilderung, statt bestritten.

Der Underwriter ist Metadatum, und Privatsphäre und Zensurresistenz koexistieren nicht in einem Zertifikat. Ein selbstversichertes abgeschirmtes Zertifikat benennt die öffentliche Kautionszelle des Senders, was wieder verknüpft, was die Stealth-Adresse entknüpft hat (§5); abgeschirmter Verkehr fährt daher auf mitsigniertem Underwriting, wo die id eines Underwriters viele Sender bündelt und die Menge die Deckung ist. Der Underwriter bepreist die Lebendigkeit von Zellen, nicht Werte (§5), sodass er den Betrag nicht erfährt — aber er erfährt alles andere, was das Zertifikat ist: den Sender, dem er außerhalb der Kette in Rechnung stellen und den er daher identifizieren muss, die ausgegebenen Zellen, die erzeugten Stealth-Ausgaben und das Timing. Genau das will eine gerichtliche Anordnung, und mit der rückwirkenden Deanonymisierung von oben setzt es sich durch den öffentlichen Graphen vorwärts fort. Es ist zudem ein struktureller KYC-Punkt, denn der eine private Modus hat einen erkennbaren Betreiber. Das legt eine Beschränkung offen, die das Papier klar ausspricht statt zu übertünchen: die beiden Underwriting-Modi sind mitsigniert (privat, aber erlaubnispflichtig — ein Underwriter darf dich ablehnen) und selbstversichert oder erzwungen (erlaubnisfrei, aber selbstidentifizierend). Der erzwungene Pfad von §7 garantiert, dass ein zensierter Nutzer immer transagieren kann; er garantiert nicht, dass er privat transagieren kann. Ein Nutzer, den jeder Underwriter ablehnt, behält das Recht auszugeben und verliert in derselben Bewegung die Privatsphäre — und das ist genau der Nutzer, für den Privatsphäre wichtig war. Die abgeschirmte Schiene erbt die Zensurresistenz von §7 nur um den Preis ihrer eigenen Privatsphäre; die beiden Eigenschaften halten nicht in einem einzigen Zertifikat.

Eine Ära, nicht Genesis. Zwei unabhängige Argumente legen den Zeitplan fest. In der Praxis verwenden abgeschirmte Zertifikate mitsignierte Underwriter, die es ab Ära 1 gibt. Nach dem Grundsatz von §3 ist unerreichbarer Konsenscode unauditierbarer Konsenscode und wird nicht ausgeliefert: das Genesis-Binary enthält keine Commitments, keinen Range-Proof-Verifier, keinen Pool-Slot — nichts, dessen einziger Aufrufer eine künftige Ära ist. Die abgeschirmte Ära ist nicht rein additiv, und das Papier sagt es: die Typisierung verborgener Zellen und das Verbot von Guards Dritter aus §4 berühren den Guard-Pfad des Folds, der genesiskritische Oberfläche ist, sodass die Ära ebenso verändert wie hinzufügt, und ihre Aktivierung ist ein Hard Fork, der als die konsenskritische Änderung auditiert wird, die er ist. Eine Ära, die ihre Komplexität nicht wert ist, wird schlicht nie ausgelöst, und die Genesis-Kette hat nichts verloren, indem sie sie nicht enthielt.

Kosten, klar benannt. Ein abgeschirmtes Zertifikat ist 3–5× so groß wie ein transparentes — ein bis zwei Kilobyte, dominiert vom Range-Proof selbst nach Batch-Aggregation —, was der dynamische Block (§8) ökonomisch aufnimmt und die Verbreitung aus §13 in Bandbreite bezahlt. Empfänger entdecken Zahlungen durch Scannen: jede neue abgeschirmte Ausgabe wird gegen den View Key der Wallet probeweise getestet, ein Aufwand von O(n) im Netzwerkvolumen, den View Tags durch eine frühe Zurückweisung anhand eines Bytes verringern, ein konstanter Faktor, begrenzt durch die ihr vorausgehende Ableitung des gemeinsamen Geheimnisses. Das Scannen ist die wichtigste UX-Last der abgeschirmten Schiene; ausgelagertes Scannen, das den View Key nicht preisgibt, ist ein offenes Problem, das dieser Entwurf erbt statt löst. Auch die Relay-Policy muss sich auf dieser Schiene ändern, und zwar nicht optional: ein Zertifikat zu veröffentlichen ist kostenlos (§5, §13), einen Bulletproof zu verifizieren nicht, sodass ein Relay, das den Verifier laufen lässt, bevor dem Veröffentlichenden Kosten auferlegt sind, ein Denial-of-Service-Verstärker ist — die abgeschirmte Schiene erfordert ein Relay nach dem Prinzip günstig-vor-teuer prüfen (Signatur und deklarierte Lebendigkeit zuerst, Beweis zuletzt, Quote pro Underwriter), was das „durch die Relay-Policy beschränkt“ des Mempools von einer Voreinstellung zu einer Anforderung macht.

Offene Fragen, die dieser Abschnitt einem späteren Entwurf überlässt, markiert statt vergraben. Ob die abgeschirmte Schiene allein die native Münze trägt oder auch die Assets von §11: ein einzelner Generator H lässt vG + rH sich auf einen Skalar festlegen, nicht auf ein Paar (Asset, Wert), sodass eine abgeschirmte Multi-Asset-Schiene Generatoren pro Asset braucht (Confidential Assets), was die Beweisgröße und die „3–5ד-Zahl von oben ändert; bis das entschieden ist, ist die Schiene per Regel auf die native Münze beschränkt, nicht durch Auslassung. Ob RETIRE (§11) auf abgeschirmte Zellen wirkt: wenn ja, kann Wert den Pool ohne öffentliches Entschirmen verlassen, sodass der Pool-Slot zu einer oberen Schranke wird (Σ ein − Σ aus ≥ Inhalt) und die Richtung der Inflationserkennung als Ungleichung neu formuliert werden muss; wenn nein, verliert die abgeschirmte Schiene ihren Garbage Collector und unöffenbare Ausgaben (unten) sammeln sich an. Ob das verschlüsselte (v, r) im Zertifikatskörper lebt (jetzt günstig, unwiederbringlich, wenn Körper beschnitten werden, was die reine Seed-Wiederherstellung von Wallets vereitelt) oder im Zellenwert (kostet Zustand pro Ausgabe, verschwindet, wenn die Zelle ausgegeben wird, und passt zu „die Akkumulation geschieht in der Wallet“). Und ob ein Underwriter einen Dritten bonden kann, während er innerhalb des Zertifikats in öffentlichem Wert abrechnet, was die obige Identitätsanforderung aufheben würde und der aussichtsreichste Weg über die Privatsphäre-/Zensur-Beschränkung hinaus ist — das sind Entwurfsfragen, keine Formulierungsfragen, und sie werden hier benannt, damit der nächste Entwurf sie nicht stillschweigend erben kann.

13. Netzwerk#

Körper sind Kettendaten. Die Zertifikatskörper eines Blocks müssen abrufbar sein, damit der Block gültig ist; der Zustand ist daher stets allein aus der Kette rekonstruierbar, und kein Betreiber — Sequencer eingeschlossen — ist je Datentreuhänder. Zertifikate sind größer als klassische Transaktionen (sie führen Reads und Writes mit sich), und die Abmilderungen sind struktureller Art: Batch-Zertifikate kürzen interne Schreibvorgänge heraus (§6), und ausgegebene One-Shot-Zellen werden kompaktiert, sobald sie jenseits des Reorg Horizon begraben sind (§4).

Eine dritte Abmilderung ist in Aussicht und wird als solche benannt statt vorausgesetzt: ein Read könnte auf den Schreibvorgang eines früheren Zertifikats über (cert_id, index) verweisen, statt den Wert zu wiederholen — der UTXO-Trick. Er ist nicht Teil des hier beschriebenen Protokolls, und er wird es erst, wenn eine Frage beantwortet ist, denn die Frage ist eine Konsensfrage und keine der Kodierung: worauf ein Verweis auflöst, wenn das von ihm benannte Zertifikat übersprungen wurde oder nie aufgenommen worden ist. Ein Verweis, der stillschweigend auf den aktuellen Wert auflöst, ist kein deklarierter Read mehr, und die zustandslose Gültigkeit stirbt mit ihm; einer, der fehlschlägt, reißt Zertifikate mit, deren eigene Autorisierung nie in Zweifel stand. Kompression, die die Eigenschaft kostet, auf der der ganze Entwurf ruht, ist keine Kompression, die es wert wäre, also fehlt das Feld, bis die Semantik geklärt ist.

Das Relay ist Hash-first. Zertifikate werden unabhängig gegossipt und bei Ankunft (zustandslos, parallel) auf Gültigkeit geprüft; Blöcke werden als Header plus Hash-Listen gegen den Mempool weitergeleitet, im Stil von Compact Blocks [13], sodass die Propagationslatenz nicht mit dem Blockinhalt skaliert. Ein Relay-Node braucht überhaupt keinen Zustand, um Spam vollständig herauszufiltern — zustandslose Gültigkeit plus Underwriter-Signatur ist aus Bytes prüfbar, was den Betrieb von Relay-Infrastruktur auf der transparenten Schiene nahezu kostenlos macht. Die abgeschirmte Schiene (§12) ist die bepreiste Ausnahme: ihre zustandslose Prüfung schließt eine Range-Proof-Verifikation ein, die drei Größenordnungen mehr kostet als eine Signatur, sodass dort die kostenlose Veröffentlichung als Voreinstellung zum Verstärker wird und das Relay an die Disziplin günstig-vor-teuer prüfen und die Quoten pro Underwriter gebunden ist, die §12 zur Anforderung statt zur Präferenz macht. Das Relay der einen Schiene ist nahezu kostenlos; das der anderen ist nur deshalb günstig, weil seine Policy verbindlich ist.

Parameter (Genesis, illustrativ). 30-Sekunden-Blöcke; Zertifikats-TTL standardmäßig 240 Blöcke (~2 h); stillgelegte Adressen pro Zertifikat ≤ 64; Epoche 2.880 Blöcke (~1 Tag); erzwungene Anwendungsverzögerung D = 4 Blöcke; erzwungene Aufnahmeschranke F = 16 Blöcke; Ären-Auslöser-Stake-Fenster K = 14 Epochen (~2 Wochen); Treasury-Anteil 300 Basispunkte (3 %) der Blocksubvention ab Block 0, Zelle versiegelt bis Ära 2, dann 3-von-5 über einen per Hard Fork angehefteten Schlüsselsatz, Schlüsselrotationsverzögerung R = 20.160 Blöcke (~7 Tage) (§14.1); Emissionskonstanten in §14.2.

14. Start: Drei Ären, keine Premine#

Zycord startet ohne Premine, ohne Gründerzuteilung, ohne Investorenrunde und ohne Admin-Schlüssel. Genesis ist aus veröffentlichten Quellen reproduzierbar. Zuerst läuft ein Testnet; erst wenn es stabil ist, wird ein Mainnet-Termin angekündigt, öffentlich und im Voraus, damit Block 0 für jeden erreichbar ist, der ihn will. Was dem Autor auferlegt wird, ist die Abwesenheit von Privilegien, und die ist in Genesis Zeile für Zeile überprüfbar. Upgrades geschehen durch sozialen Konsens und Hard Fork.

Dieses Papier ist die Argumentation. Die Regeln sind die Architekturspezifikation, die Golden Vectors sind das Protokoll, und wo zwei von ihnen sich widersprechen, gewinnt das Präzisere und der Widerspruch ist ein Bug. Zusammen mit ihnen wird das Protokoll darüber veröffentlicht, wie dieser Entwurf angegriffen wurde — aufeinanderfolgende gegnerische Lesungen, die Befunde, die sie hervorbrachten, jene, die die Regeln änderten, und jene, die entkräftet wurden, und warum. Dieses Protokoll wird vollständig und unbearbeitet freigegeben, einschließlich der Reviews, die echte Mängel fanden, und der Instrumente, die Erfolg meldeten, während sie nichts maßen. Für ein Projekt, dessen Autor nicht persönlich für es einstehen wird, liest sich ein Entwurf ohne sichtbare Geschichte des Angegriffenwerdens als ein Entwurf, den niemand angegriffen hat, und es gibt keinen Weg, das zurückzuverdienen, was sein Verbergen kosten würde.

„Unbearbeitet“ ist ein Versprechen über die Befunde, und es lohnt, genau zu sagen, was es umfasst, denn das Protokoll wird als Dateien statt als lebendes Archiv neu veröffentlicht. Jeder Befund, jede Messung, jedes Argument und jede verworfene Alternative überlebt so, wie sie geschrieben wurde, einschließlich derer, die falsch waren, und der Instrumente, die Erfolg meldeten, während sie nichts maßen; nichts wird ausgedünnt, abgemildert, zusammengelegt oder weggelassen. Zwei Klassen von Änderungen werden vorgenommen und nur zwei. Die erste ist Identitätsschwärzung — Namen, Handles, Adressen, Maschinennamen und lokale Pfade, die nichts über den Entwurf aussagen. Die zweite ist Eigenständigkeit: ein Verweis in einen Tracker oder eine Commit-Historie, die der veröffentlichte Baum nicht mitführt, wird durch die Begründung ersetzt, für die er stand, inline ausformuliert. Ein Leser, der allein diese Dateien hat, kann daher jeder Behauptung folgen, und dafür war das Versprechen da; ein Verweis, der ins Leere auflöst, würde den Buchstaben von „unbearbeitet“ wahren und dessen ganzen Zweck verlieren.

Proof of Stake kann nicht fair starten — der anfängliche Stake muss irgendwoher kommen, und jeder klassische Weg (Verkauf, Premine, Zuteilung) konzentriert entweder das Netzwerk oder identifiziert seinen Autor. Proof of Work wird daher als Verteilungsmechanismus mit Verfallsdatum eingesetzt, nicht als dauerhafter Konsens:

Entwurfsnotizen zum Übergang. Ära 0 ist bewusst winzig. Ohne Admin-Schlüssel gibt es keinen Pausenknopf, sodass jede Genesis-Zeile eine Zeile ist, die das Netzwerk ohne Abhilfe töten kann; der Fold (§3) plus die nativen Operationen (§11) sind die gesamte sicherheitskritische Oberfläche (klein genug, dass dieses Papier ihre vollständige Spezifikation enthält), und sie werden auditiert und gegnerisch simuliert ausgeliefert. CPU-Mining (RandomX) passt zur Zielgruppe: mine auf dem Laptop, den du ohnehin hast. Es lädt auch Botnetze ein; jede CPU-minebare Münze hat sie bekämpft, und wir erwarten nicht, die Ausnahme zu sein. Wir gehen diesen Handel mit offenen Augen ein: eine durch Botnetze verzerrte Verteilung ist immer noch breiter als eine in einem Verkauf entschiedene, und ehrliche Standardhardware wettbewerbsfähig zu halten ist der gesamte Entwurfsauftrag von RandomX [14]. Das Mitsignieren ist live, sobald Underwriter sich registrieren können; die Checkpoint-Finality ist es nicht, bis der Stake anhält, und wir benennen die Lücke, statt sie zu verbergen: der Bond bepreist Skips, nie Reorgs, sodass keine Protokollregel einen Underwriter davon abhält, Vorbestätigungen in diese Lücke hinein zu verkaufen — was keine Regel leisten kann, ist, den Verkauf ehrlich zu machen. „Wird in Sekunden angewandt, oder mein Bond zahlt“ ist erst dann unterschreibbar, wenn tiefe Reorgs vom Tisch sind, sodass das Produkt der versicherten Vorbestätigung der Finality als Marktehrlichkeit folgt und nicht als Protokollrecht. Attester werden aus der Emission bezahlt, sobald das Overlay aktiviert ist — beide früheren Hybridübergänge taten dies (Decred zahlt PoS-Wählern einen Anteil jeder Blockbelohnung [17]; Ethereums Beacon-Validatoren verdienten zwei Jahre lang Emission, bevor sie Mainnet-Blöcke vorschlugen) —, und die producer-lastige Aufteilung 77/20/3 bleibt auf die Verteilungsphase beschränkt, denn derselbe Präzedenzfall zeigt, dass eine miner-lastige Aufteilung der falsche Dauerzustand ist: die Rampe schafft sie ab. Ära 1 teilt ihren Auslöser, und die Teilung ist tragend: der Befehlssatz aktiviert sich nach Höhe — BOND zuerst, die Registrierung von Underwritern und Sequencern und die cEVM danach, zwei Höhen, die die Genesis-Parameter getrennt und geordnet halten —, während das Finality-Overlay sich erst aktiviert, wenn gebondeter Stake ≥ 1 % der Supply K Epochen lang angehalten hat, denn Stake kann nicht gemessen werden, bevor die Operation existiert, die ihn erzeugt. Ära 2 behält einen doppelten Auslöser (Höhe und anhaltender Stake), sodass das Netzwerk weder bei trivialem Stake übergeht noch amtierende Miner es ewig blockieren lässt; Höhen sind Schwellen, keine Termine, und kein Kalender wird versprochen. Einen Vorbehalt sprechen wir aus, statt ihn zu vergraben: bei der Aktivierungsschwelle von 1 % braucht es ein Drittel davon (0,33 % der Supply), um die Finality zum Stillstand zu bringen, sodass die Finality, auf der die ersten versicherten Vorbestätigungen ruhen, selbst jung ist. Die Anforderung, K Epochen anzuhalten, hebt die Latte mit der Zeit, der Inactivity Leak macht einen Stillstand teuer im Halten, und von Underwritern wird erwartet, dass sie junge Finality in junge Policen einpreisen; tiefere Sicherheit kommt mit tieferem Stake, nicht per Erklärung. Ära 1 ist die Schattenkette: der Validatorensatz finalisiert die gesamte Ära lang im Produktivbetrieb — echte Bonds, echtes Slashing —, bevor er einen einzigen Block vorschlägt, jene Eigenschaft, die den einen erfolgreichen PoW→PoS-Übergang im großen Maßstab sicher gemacht hat. Sie ist zudem ein Ruhezustand, kein Korridor: hält der Stake die Schwelle von Ära 2 nie, bleibt das Netzwerk auf unbestimmte Zeit ein funktionierender Hybrid. Die Rampe statt einer Klippe verwehrt einer Miner-Fork-Rallye ihren Moment, und die Rampe ist abbrechbar: finalisieren Checkpoints zwei Epochen in Folge nicht, pausiert sie auf ihrem aktuellen Niveau, bis die Finality zurückkehrt. Miner können die Pause nicht kaufen: die Finality zum Stillstand zu bringen braucht ein Drittel des gebondeten Stakes, den der Inactivity Leak ausblutet, bis die Finality zurückkehrt, sodass der Angriff mehr kostet, als die pausierte Belohnung einbringt. Miner der Ära 0, die ihre Coinbase bonden, erhalten Vorrang — keine zusätzlichen Münzen — in den ersten Sequencer-Rotationen, was die Mining-Gemeinschaft in die Betreibergemeinschaft überführt, statt sie zu verwerfen.

Der Auslöser der abgeschirmten Ära ist bewusst anders geformt als die übrigen. Höhen und Stake-Schwellen sind Tatsachen, die ein Node misst; die Reife eines kryptografischen Verifiers ist es nicht, also ist der Auslöser stattdessen eine Checkliste, die ein Hard Fork zitieren können muss: veröffentlichte Audits, geleistete Testnet-Epochen, Vektoren im Artefakt. Die Form zählt mehr als die Punkte. Dieses Netzwerk hat kein Notfallteam — der Zcash-Fälschungsbug war teils deshalb überlebbar, weil eine besetzte Organisation binnen Tagen einen Fix auslieferte, und nichts hier kann das versprechen —, also ist die Aktivierung der Ära darauf angelegt, ihre Wartenden zu erzeugen, statt sie vorauszusetzen: eine Gemeinschaft, die keine zwei unabhängigen Audits hervorbringen und kein gegnerisches Testnet besetzen kann, ist eine Gemeinschaft, die keinen Konsens-Verifier warten kann, und die Checkliste macht die zweite Unfähigkeit als Versagen der ersten sichtbar, vor der Aktivierung statt nach einem Bruch. Die Fold-Regel von §12 begrenzt, was ein überlebender Bug kosten kann; die Checkliste begrenzt, wie unbeleuchtet ein Verifier in dem Moment sein darf, in dem er anfängt, etwas zu kosten. Keines ersetzt das andere, und die Ära wird mit beidem ausgeliefert oder gar nicht.

Die Rampe ist eine Neuaufteilung und keine Kürzung: welchen Anteil auch immer der Proof of Work abgibt, die Proof-of-Stake-Proposer nehmen ihn auf, sodass der Subventionsplan von §14.2 davon unberührt bleibt, wo im Übergang das Netzwerk steht. Das ist es, was den Plan eine reine Funktion der Höhe bleiben lässt, von jedem Node aus vier Konstanten berechenbar, ohne das Ledger zu befragen.

Der Übergang ist aus einem architektonischen Grund handhabbar, der es wert ist, genannt zu werden: der Fold ist gleichgültig dagegen, wer ordnet. Ein PoW-Miner ist bereits der blinde Proposer, den der Entwurf verlangt; Ära 2 ändert, wessen Signatur auf dem Header steht, und keine einzige Regel der Zustandssemantik. Es gibt keine Ausführungsengine, die über die Grenze zu tragen wäre.

Eine Ärengrenze ist auch der Ort, an dem sich Kapazität bewegt: die Byte-Kapazität von §8.1 und die Transportkonstanten darunter werden dort neu angeheftet, gegen die im laufenden Netzwerk gemessene Propagation, sodass routinemäßiges Wachstum auf den Upgrades mitfährt, die dieser Zeitplan ohnehin enthält, statt selbst zu einem Governance-Ereignis zu werden.

14.1 Die Treasury#

Drei Prozent jeder Blocksubvention werden der Treasury-Zelle gutgeschrieben; siebenundneunzig Prozent bezahlen den Konsens — den Producer des Blocks und, ab Ära 1, die Checkpoint-Attester (§14). Der Anteil ist in Genesis festgelegt, gilt ab Block 0 und gilt für jeden Block gleichermaßen. Gebühren werden nie angetastet (die Treasury hat keinen Anspruch auf die Märkte von §8), sodass die Kosten auf die Emission fallen, verteilt über jeden Halter im Verhältnis zu seinem Bestand.

Die Zelle ist bis Ära 2 versiegelt. Sie läuft ab Block 0 auf, und kein Schlüssel öffnet sie vorher: kein Quorum in Genesis, keine Adresse, kein Autorenschlüssel, kein Notfallpfad. Bei Block 0 gibt es keine gereifte Gemeinschaft, die die Schlüssel halten könnte. Kommt keine, öffnet sich die Zelle nie und die Münzen werden nie ausgegeben. Die Auflaufregel sitzt vom ersten Block an in Genesis, damit sie nie eine Änderung ist; bei Ära 2 geschieht nichts Neues außer dass eine vereinbarte Regel wirksam wird.

Nichts davon ist eine Premine, und der Unterschied ist überprüfbar statt rhetorisch. Eine Premine ist eine Zuteilung: Münzen, eine Adresse und ein Schlüssel, die bei Genesis existieren und jemandem gehören. Genesis enthält hier nichts von den dreien. Keine Treasury-Münze ist ausgebbar, keine Adresse ist bestimmt, kein Schlüssel existiert, und keine Partei ist benannt; was Genesis enthält, ist eine Regel, angewandt auf jeden je geminten Block gleichermaßen, plus eine zweite Regel dafür, wie eines Tages ein Quorum über das aufgelaufene Ergebnis angeheftet werden darf. Ob dieser Tag kommt, ist nicht die Entscheidung des Autors. Weil der Schlüsselsatz per Hard Fork angeheftet wird, ist der Auswahlmechanismus derjenige, den jede Konsensänderung verwendet: jemand schlägt fünf öffentlich identifizierte Halter vor, Node-Betreiber übernehmen den Fork, der sie anheftet, oder lehnen es ab, ihn zu betreiben, und ein Kandidatenquorum, das das Netzwerk nicht dazu bewegen kann, seinen Fork zu betreiben, hält die Schlüssel zu nichts. Es gibt keine Abstimmung zu kapern, kein Register von Mitwirkenden auszunutzen und keinen Moment, in dem die Stimme des Autors mehr wiegt als die irgendeines anderen Node-Betreibers.

Ab Ära 2 wird die Zelle allein durch ein Zertifikat belastet, das drei von fünf Signaturen über einen per Hard Fork angehefteten Schlüsselsatz führt. Ausgaben sind gewöhnliche Zertifikate: öffentlich, endgültig und allein aus der Kette zählbar. Das Quorum wird aus zum Zeitpunkt der Öffnung aktiven Mitwirkenden gebildet und öffentlich identifiziert, bevor der Satz in Kraft tritt; jeder Schlüssel liegt bei einer eigenen Partei, keiner unter gemeinsamer Kontrolle. Eine gültige 3-von-5-Ausgabe darf stattdessen fünf Ersatzschlüssel benennen, wirksam nach R Blöcken, während derer die Rotation öffentlich ist und der alte Satz noch gilt: die Rotation trägt die Schwelle einer Ausgabe und die Sichtbarkeit einer Ausgabe.

Die Ären 0 und 1 sind spendenfinanziert: Vorschläge öffentlich vor der Zahlung, Meilensteine und Budget im Voraus, Auszahlung gegen geleistete Arbeit, nicht verbrauchte Beträge zurück an den Fonds. Das Quorum erbt diese Disziplin, wenn die Zelle sich öffnet. Es ist eine Norm und keine Konsensregel; was sie durchsetzt, ist, dass jede Abweichung im Ledger sichtbar ist.

Der Anteil verfällt nicht. Er ist ein Bruchteil der Emission und keine Menge Münzen, sodass er mit der Subvention von §14.2 abklingt und im Schwanz als fester nominaler Strom fortbesteht; als Anteil an der Supply strebt er gegen null. Ihn zu entfernen kostet, was jede Konsensänderung kostet: einen Hard Fork. Ab Ära 2 ist das 3-von-5 das einzige vertrauenswürdige Quorum des Protokolls.

14.2 Emission#

Die Subvention klingt gleichmäßig zu einem dauerhaften Schwanz ab. Die Rate ist innerhalb einer Epoche konstant und tritt an jeder Epochengrenze einmal herunter, durch exakte ganzzahlige Arithmetik über vier Konstanten:

E(0) = E₀
E(n) = max(tail, E(n−1) − E(n−1)/Q)

wobei L die Epoche in Blöcken ist, Q der Abklingdivisor, E₀ die Genesis-Subvention und E(n) die Subvention pro Block über die gesamte Epoche n. Diese vier — L, Q, E₀, tail — sind die Konstanten; C, die Vor-Schwanz-Supply, zu der der Plan sich aufsummiert, wird aus ihnen durch Ausführen der Rekurrenz abgeleitet und ist keine Eingabe für sie. Frühere Fassungen schrieben die erste Zeile als E(0) = C / (L · Q), was sich liest, als sei C eine Konstante, aus der die Subvention herausdividiert wird; es ist die geschlossene Form des unendlichen geometrischen Abklingens, und der endliche Plan unten summiert sich nicht dazu auf. Es gibt keine Gleitkommazahlen und keine Tabelle, die man falsch machen könnte, und keine Halving-Klippen: der Schritt ist klein genug, dass kein einzelner Block eine sieht, dieselbe Überlegung, die die Belohnung in Ära 2 zu einer Rampe macht. Sobald die Formel unter den Schwanz fällt, ist die Subvention für immer ein fester Betrag pro Block.

Der Plan ist eine reine Funktion der Höhe. Er zieht nicht heran, wie viel tatsächlich ausgezahlt wurde, was bedeutet, dass ein Block, der weniger zahlt als der Plan — etwa eine Coinbase, die einer Adresse zusteht, deren Halter sie verbrannt hat —, ein dauerhafter Fehlbetrag gegenüber C ist und keine Schuld, die die Kurve später zurückzahlt. C ist daher die Zahl, zu der der Plan sich aufsummiert, keine Obergrenze, die er zu erreichen garantiert.

Der Schwanz existiert, weil Sicherheit eine dauerhafte Ausgabe ist: er bezahlt, wer immer die aktuelle Ära absichert — Miner, dann Miner und Attester, dann Validatoren —, ohne die Gebührenmärkte von §8 einzuziehen. Er ist so bemessen, dass die jährliche Schwanzemission unter 1 % der ausstehenden Supply beginnt; weil der Zähler fest ist und die Supply wächst, fällt dieser Prozentsatz nur. Gegen ihn läuft die sequentielle Basisgebührenverbrennung von §8, sodass die Nettoemission Schwanz minus Verbrennung ist und unter Last negativ werden kann. Die 97/3-Aufteilung von §14.1 gilt für jede Subvention, den Schwanz eingeschlossen.

Konstanten (Genesis, illustrativ, wie §13): Epoche L = 2.880 Blöcke; Abklingdivisor Q = 1054; Genesis-Subvention E₀ = 21/Block; Schwanz 0,33/Block. Mit 30-Sekunden-Blöcken ergibt das einen Jahresfaktor von 0,70702, was heißt, dass sich die Emissionsrate alle zwei Jahre halbiert — und zwar exakt, nicht näherungsweise: E(730) = 10.50230028 gegenüber E₀ = 21. Die Formel fällt in Epoche 4.376 unter den Schwanz, Höhe 12.602.880, ≈ Jahr 12, sodass der abklingende Arm über die Epochen 0 bis 4.375 läuft und C, die Supply, zu der er sich aufsummiert, 62.744.838,47 beträgt. Davon werden 62.744.817,47 tatsächlich emittiert: der Unterschied sind die 21 des Genesis-Blocks, der überhaupt keine Coinbase auszahlt, weil es keinen Miner zu bezahlen gibt und ein reproduzierbares Genesis keiner Adresse etwas gutschreiben darf. Die jährliche Schwanzemission beträgt dann ≈347K, also 0,55 % der emittierten Supply, von dort fallend. **Die geschlossene Form L · E₀ · Q = 63.745.920 ist eine obere Schranke für C, nicht sein Wert**, und die Lücke ist kein Rundungsfehler: dieses Produkt ist die Summe des unendlichen geometrischen Abklingens, während der Plan endlich ist, bei jedem Schritt abrundet und beim Schwanz aufhört. Es überschießt C um 1.001.081,53, also 1,60 %. Man zitiere die Summe und nie die geschlossene Form. Konformität heißt, die Rekurrenz zu reproduzieren — kein Node berechnet je C oder irgendeine andere Zahl aus diesem Absatz, in keiner Höhe.

15. Messungen#

Ein Entwurf, dessen zentrale Behauptung eine Durchsatzasymmetrie ist, schuldet dem Leser Zahlen. Die folgenden Werte stammen aus der Referenzimplementierung und lassen sich aus ihrem veröffentlichten Quellcode nachvollziehen. Hardware: eine Zehnkern-x86-Desktop-CPU. Die Werte sind Mediane über 5 Läufe.

• Fold-Durchsatz: 883.000 Slot-Operationen pro Sekunde und Kern über eine Arbeitsmenge von 100.000 Slots, das heißt 294.000 angewandte Zertifikate pro Sekunde bei 3 Slots pro Zertifikat.
• Zustandslose Verifikation: 1.470 Zertifikate pro Sekunde und CPU-Kern und 5.220 pro Sekunde über 10 Kerne — das Verhältnis ist die Parallelitätsbehauptung, gemessen statt behauptet.
• Signaturverifikation: 1.500 pro Sekunde, einzeln, einschließlich der Prüfungen auf kleine Ordnung und Torsion.
• Ende zu Ende: ein Block aus 2.900 Zertifikaten validiert in 1.963 ms und foldet in 9,9 ms. Die beiden werden getrennt berichtet, weil sie die zwei Hälften des Arguments sind: die erste skaliert mit Kernen, die dem Netzwerk nicht gehören, die zweite ist die eine Schleife, die ihm gehört.

Die Messung des Folds ist eine Subtraktion, und das zu sagen gehört zu ihrem Bericht: einen Block zu committen führt die zustandslosen Prüfungen und den sequentiellen Fold zusammen aus, sodass der Wert des Folds das Ganze minus der für sich gemessenen Prüfungen ist. Beide Hälften liegen im Artefakt.

Wir berichten allein, was die Referenzimplementierung ausführt, was zwei Grenzen setzt, die es wert sind, benannt zu werden, statt sie einem Leser zur Entdeckung zu überlassen. Die Signaturverifikation wird eine Signatur nach der anderen gemessen: die Batch-Verifikation ist eine reale Technik und offensichtlich passend, aber sie ist sicherheitskritische Kryptografie, die dieses Projekt nicht geschrieben hat, und eine Zahl für Code, der nicht existiert, ist keine Messung. Die GPU- und SIMT-Werte, die §2 und §6 in Aussicht stellen, gehören zu den Batch-Zertifikaten des Sequencers, die mit Ära 1 kommen. Beides sind Entwurfserwartungen. Keines von beiden ist für die obigen Zahlen tragend: die Parallelitätsbehauptung ruht darauf, dass Zertifikate unabhängig prüfbar sind, was das Batching schneller machen würde und nicht wahr machen kann.

16. Verwandte Arbeiten#

Zycords Pipeline — erst ausführen, blind ordnen, beim Commit validieren — hat einen Vorfahren im erlaubnispflichtigen Umfeld: Hyperledger Fabrics execute-order-validate [3], dessen dokumentierte Schwächen seine Abbruchrate unter Contention und seine Abhängigkeit von institutionellen Endorsement-Policies sind. Zycords Beiträge gegenüber dieser Linie sind (i) Anwendbarkeit über Wertgleichheit mit dem Skip als erstklassiger, ABA-toleranter Semantik; (ii) ökonomische Zurechnung von Konflikten — gebondetes Underwriting, das Äquivokation objektiv slashbar und Veraltung zu einer bepreisten, versicherbaren Dienstleistung macht, was execute-order-validate fehlte, um erlaubnisfrei zu werden; und (iii) erzwungene Aufnahme mit garantierter Anwendung, wo die Notausstiege von Rollups allein die Aufnahme garantieren. Deterministisch vorab deklarierte Read-/Write-Mengen stammen von Calvin [4] ab und erscheinen in Solanas Access Lists [16]; kommutative Escrow-Verfahren gehen auf O'Neil [9] zurück und leben heute in Single-Node-Schedulern wie Aptos-Aggregatoren über Block-STM [5] — Zycord verschiebt den Kommutativitätsvertrag zwischen die Nodes und bepreist ihn. Parallel-EVM-Systeme [5] und Ketten mit aufgeschobener Ausführung führen weiterhin überall erneut aus und laufen gegen die Zustands-I/O-Wand; Narwhal [6] trennt die Datenverbreitung vom Ordnen, wie es unsere frühen Entwürfe taten; Suis Owned Objects entsprechen unseren Write-once-Zellen; die Pending/Base-Teilung von Zether [7] hat die Guarded-Delta-Disziplin angeregt (und kehrt, mit den Privatsphäre-Wurzeln des chimärischen Ledgers [8], in den vertraulichen Zahlungen von §12 wieder — dem ersten Mieter der Schwerkrypto-Spur, verborgene Beträge und einmalige Adressen, in Parallel Gas eingepreist statt in die Basisschicht eingebaut). Verkettete Finality-Overlays folgen Casper FFG [12].

17. Fazit#

Wir haben ein Netzwerk vorgeschlagen, das Zertifikate ordnet, statt Transaktionen auszuführen: Gültigkeit von jedem, überall, parallel, allein aus Bytes prüfbar; Zustand fortgeschrieben von einem Fold, der einfach genug ist, um auf einer Seite spezifiziert zu werden; Konflikte übersprungen, bepreist und mit Eigentümer; Nebenläufigkeit deklariert statt entdeckt; Zensur von Bauart her überlebbar; und ein Start, der die Münze verteilt, bevor er irgendwen bittet, einem Validatorensatz zu vertrauen. Die Verifikation skaliert mit Hardware, die dem Netzwerk nicht gehört. Das Committen bleibt sequentiell — und nahezu kostenlos.

Zycord jagt der Arbeit nicht hinterher. Es hält still, und das Netzwerk verrichtet die Arbeit.

Literatur#

[1] S. Nakamoto. Bitcoin: A Peer-to-Peer Electronic Cash System. 2008. [2] V. Buterin. Ethereum: A Next-Generation Smart Contract Platform. 2013. [3] E. Androulaki et al. Hyperledger Fabric: A Distributed Operating System for Permissioned Blockchains. EuroSys 2018. [4] A. Thomson et al. Calvin: Fast Distributed Transactions for Partitioned Database Systems. SIGMOD 2012. [5] R. Gelashvili et al. Block-STM: Scaling Blockchain Execution by Turning Ordering Curse to a Performance Blessing. 2022. [6] G. Danezis et al. Narwhal and Tusk: A DAG-based Mempool and Efficient BFT Consensus. EuroSys 2022. [7] B. Bünz, S. Agrawal, M. Zamani, D. Boneh. Zether: Towards Privacy in a Smart Contract World. Financial Cryptography 2020. [8] J. Zahnentferner. Chimeric Ledgers: Translating and Unifying UTXO-based and Account-based Cryptocurrencies. IACR ePrint 2018/262. [9] P. E. O'Neil. The Escrow Transactional Method. ACM TODS, 1986. [10] M. Herlihy, E. Koskinen. Transactional Boosting: A Methodology for Highly-Concurrent Transactional Objects. PPoPP 2008. [11] M. Shapiro et al. Conflict-free Replicated Data Types. SSS 2011. [12] V. Buterin, V. Griffith. Casper the Friendly Finality Gadget. 2017. [13] M. Corallo. BIP 152: Compact Block Relay. 2016. [14] tevador et al. RandomX: Proof-of-Work Algorithm Optimized for General-Purpose CPUs. 2019. [15] EIP-1559: Fee Market Change for the ETH 1.0 Chain. Ethereum Improvement Proposals, 2019. [16] A. Yakovenko. Solana: A New Architecture for a High Performance Blockchain. 2017. [17] Decred Documentation: Issuance. docs.decred.org — Aufteilung der Blockbelohnung zwischen PoW-Minern, PoS-Wählern und Treasury. [18] EIP-4844: Shard Blob Transactions. Ethereum Improvement Proposals, 2022. [19] Monero: Dynamic Block Weight and Penalty. Dokumentation des Monero Research Lab; siehe auch JollyMort, Monero Dynamic Block Size and Dynamic Minimum Fee, 2017. [20] bitcoincashautist. CHIP-2023-04: Adaptive Blocksize Limit Algorithm for Bitcoin Cash. 2023.