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

Zycord: Ein Peer-to-Peer-Netzwerk selbstzertifizierender Zustandsübergänge.
The Simstoshi
2026 — v2.0
GPG: E724 39CE DD85 11F9 D607 550B 87FD 60D5 EB4A 0B29

Dieses Papier ist vollständig und in sich geschlossen. Es ersetzt v1.0 [0]; §15 legt das Verhältnis dar. Start, Emission, Ären und die vollständige Parametertabelle stehen im Begleitdokument, Zycord: Launch, Eras and Parameters.

Versionen. Der Text unten ist v2.0 des Papiers, ungekürzt, auf dieser Seite gefolgt von seinem Begleitdokument, ebenfalls v2.0. Beide werden als PDFs ausgeliefert, jedes mit einer abgetrennten Signatur, erstellt mit dem Projektschlüssel E724 39CE DD85 11F9 D607 550B 87FD 60D5 EB4A 0B29: das Papier (Signatur) und das Begleitdokument (Signatur). Jede Version ist archiviert unter doi:10.5281/zenodo.22167489, das auf die jeweils neueste auflöst; das ersetzte v1.0 ist doi:10.5281/zenodo.22167490. Das Begleitdokument ist unter einem eigenen doi:10.5281/zenodo.23383987 archiviert.

1. Einleitung#

Ein Blockchain-Node erledigt drei Aufgaben, die nichts miteinander gemein haben: er verbreitet Daten, er verifiziert Berechnungen und er mutiert Zustand. Daten skalieren mit der Bandbreite. Verifikation skaliert mit Kernen und ist trivial parallelisierbar, wenn Transaktionen unabhängig voneinander geprüft werden können. Zustandsmutation ist die einzige wirklich sequenzielle Ressource: irgendwo muss eine einzige maßgebliche Historie von Schreibvorgängen existieren.

Zycord trennt die drei. Eine Transaktion wird zu einem Zertifikat, das seine eigenen Eingaben und Ausgaben mitträgt, sodass seine Verifikation eine reine Funktion seiner Bytes ist und nie das Ledger berührt. 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 keine Blöcke ungültig; sie führen dazu, dass einzelne Zertifikate übersprungen werden, und jeder Skip wird einer Partei belastet, die das Risiko akzeptiert hat. Nebenläufigkeit wird nicht zur Laufzeit entdeckt; sie wird deklariert, Slot für Slot, vom Autor des Contracts. Die Abstammungslinie ist Execute-Order-Validate [3], deterministische Ordnung [4], optimistische parallele Ausführung [5] und die Trennung der Verbreitung von der Ordnung [6].

Die Gültigkeit wird einmal pro Zertifikat geprüft, parallel, bevor überhaupt ein Block existiert. Der Fold läuft einmal pro Block, der Reihe nach, und führt nie etwas aus.

Der Entwurf ruht auf zwei Welten, die sich ein Executable teilen dürfen, aber nie verwechselt werden dürfen:

Konsensregeln verifizieren nur. Ihr Zweck ist, dass kein Nutzer Mittel verliert, ohne es zu autorisieren, niemand einen Kontostand belastet, den er nicht kontrolliert, und kein Angreifer das Netzwerk leeren, blockieren oder verlangsamen kann. Wie ein Sequencer arbeitet, wie Sequencer miteinander kommunizieren und was sie verlangen, liegt außerhalb des Konsenses. Was auf der Kette steht, ist die Abwicklung: die Bezahlung eines Sequencers reist im Intent mit, den der Nutzer signiert hat, und wird nur gezahlt, wenn das Zertifikat angewandt wird.

Die folgenden Abschnitte definieren das Zertifikat (§2), den Fold (§3), typisierten Zustandszugriff (§4), native Assets (§5), die virtuelle Maschine (§6), Sequencer (§7), den Forced Path (§8), die zwei Gebührenmärkte (§9), das Netzwerk (§10), Proof of Stake (§11), den Weg jenseits der vollständigen Verifikation (§12), akzeptierte Risiken (§13), Konformität (§14) und das Verhältnis zu v1.0 (§15).

2. Zustandsübergangs-Zertifikate#

Das Zertifikat ist der einzige Transaktionstyp. Es ist SSZ-kodiert, was eine einzige kanonische Byte-Kodierung ergibt; das Dekodieren erzwingt die kanonische Form, sodass ein dekodiertes Zertifikat von Bauart her strukturell gültig ist und keine spätere Regel die Gestalt erneut prüft.

Zwei Digests beantworten zwei Fragen. Die Zertifikats-id ist der Hash des Zertifikats mit leerer Signaturliste: sie benennt, was das Zertifikat autorisiert. Der Exemplar-Hash deckt die gesamte Kodierung ab, Signaturen eingeschlossen: er benennt einen bestimmten Satz von Bytes. Signaturen bleiben außerhalb der id, weil das Signieren randomisiert ist; jede Nonce ergibt eine weitere gültige Signatur über denselben Körper, und eine id, die sie abdeckte, gäbe einer einzigen Autorisierung unbegrenzt viele abrechenbare Identitäten. Die id ist der Schlüssel für das Seen Set, die Fold-Reihenfolge und jede Deduplizierung. Ein Fill und ein erzwungenes Zertifikat nehmen den Hash ihres Intents als id (§7, §8); das Gebot eines Fills wird durch die Signatur seines Sequencers versiegelt. Der Exemplar-Hash ist das, worauf die Zertifikatswurzel eines Blocks committet, sodass eine Block-id die Bytes bestimmt, die der Block trägt. Das Gebühren-Gebot liegt innerhalb der id und ist signiert: ein Gebot außerhalb der id wäre ein Gebot, das jeder auf dem Übertragungsweg umschreiben könnte. Jede Signatur signiert eine Nachricht, die die Chain-id und die Konsenswurzel des Parametersatzes bindet, sodass ein Zertifikat nicht in einem anderen Netzwerk wieder eingespielt werden kann.

Gültigkeit ist zustandslos. Ein Zertifikat ist gültig, wenn allein aus seinen Bytes gilt:

1. es dekodiert kanonisch, benennt diese Kette, und jede Liste liegt innerhalb ihres Limits;
2. jede Signatur verifiziert unter striktem Ed25519 (kanonische Kodierungen, torsionsfreie Schlüssel), und die Signaturmenge ist minimal und zugleich ausreichend;
3. die erneute Ausführung des Programms gegen die deklarierten Reads ergibt genau die deklarierten Writes;
4. jeder Schreibvorgang, der eine Autorisierung braucht, hat sie, und die Einlagezelle trägt bedingungslos eine Signatur;
5. die Einlage ist eine Zelle mit nativem Guthaben einer Nutzeradresse und deckt den ungünstigsten Fall des Zertifikats;
6. das Zertifikat ist in sich widerspruchsfrei: kein Schreibvorgang widerspricht einem Read desselben Slots, keine belastete One-Shot-Adresse entgeht der Markierung als ausgegeben, und kein Wert wird auf eine ausgegebene Adresse geschrieben;
7. es schreibt keine Protokollzelle;
8. jede Adresse, die es benennt, trägt ein definiertes Versions-Byte;
9. in einem Contract, dessen Sequencer-Schlüssel nicht null ist, trägt der Exact-Read-Pfad die Signatur dieses Schlüssels (§7), außer in einem erzwungenen Zertifikat (§8);
10. ein Metadaten-Schreibvorgang deklariert einen Exact Read jeder Zelle, die er überschreibt, mit dem Wert, den die Zelle hielt, als das Zertifikat gebaut wurde.

Jede Maschine prüft das: ein Thread-Pool, ein anderer Rechner, eine GPU, ohne Datenbank und ohne Synchronisation. Signaturprüfungen sind voneinander unabhängig, sodass sie über Zertifikate hinweg gebatcht werden können. Das ist die Eigenschaft, auf der alles Weitere aufbaut.

Gültigkeit reicht für die Ausführung nicht aus. Zwei gültige Zertifikate dürfen denselben Eingabewert für denselben Slot deklarieren; höchstens eines kann wirksam werden. Der klassische Begriff der Transaktionsgültigkeit wird daher zweigeteilt: gültig (zustandslos, parallel, von jedem geprüft) und anwendbar (zustandsbehaftet, sequenziell, allein durch die Position im Ledger entschieden). Ein ungültiges Zertifikat gelangt nie in einen ehrlichen Mempool, und eines, das in einen Block aufgenommen wird, macht den Block ungültig.

3. Das Ledger als Fold#

Ein Block besteht aus einem Header, einer geordneten Liste von Exemplar-Hashes der Zertifikate und den Körpern der Zertifikate selbst. Körper sind Kettendaten: ein Block ist nur gültig, wenn seine Körper verfügbar sind. Der Producer eines Blocks führt nichts aus. Er ordnet Zertifikate, die er bereits validiert gesehen hat, löst den Proof of Work [13] (oder signiert unter Proof of Stake den Slot, für den er ausgelost wurde, §11) und führt die Menge der innerhalb des TTL-Fensters gesehenen Zertifikats-ids mit, denn ein Zertifikat zweimal aufzunehmen macht den Block ungültig.

Der Zustand der Kette ist ein Fold über die geordneten Zertifikate. Für jedes Zertifikat reserviert der Fold der Reihe nach die Einlage, prüft jeden deklarierten Read gegen den aktuellen Zustand, stellt die Writes mit geprüfter Arithmetik bereit und committet oder überspringt dann:

• APPLIED — jeder deklarierte Read gilt, also landen die Writes, und die Gebühr wird zu den tatsächlichen Kosten abgerechnet.
• SKIPPED — ein Read gilt nicht mehr (STALE), ein Delta würde den Bereich [0, 2²⁵⁶) verlassen (OVERFLOW), oder ein Write landet unter einer ausgegebenen Adresse (SPENT). Nichts wird geschrieben. Eine feste Skip-Gebühr wird aus der Einlage verbrannt, und der Rest wird zurückgegeben.
• FORCED_FAILED — ein erzwungenes Zertifikat (§8), dessen Aufruf revertiert hat oder seine Schranken verletzt hat. Seine Zahler werden belastet und verbrannt, das Wechselgeld geht an den Nutzer zurück, sonst wird nichts geschrieben, und die id wird als gesehen markiert.
• DROPPED — das Zertifikat konnte überhaupt nicht belastet werden (die Einlagezelle ist ungedeckt oder ausgegeben), also wird es mitgeführt, als gesehen markiert und nicht belastet. Es zahlt seinem Producer nichts und kostet ihn Platz unter der Obergrenze. Ein Fill im selben Zustand macht stattdessen den Block ungültig (siehe unten), denn ihn zu droppen würde den Intent des Nutzers verbrauchen, ohne dass jemand bezahlt wird.

Kanonische Reihenfolge. Der Fold ordnet die Zertifikate eines Blocks in drei Klassen und lässt dem Producer keinen Ermessensspielraum. Zuerst die Fills (§7), jeder, sobald jede Pipeline, in der er steht, bereit ist, Gleichstände aufgelöst nach (sequencer key, contract, seq, id). Dann alle anderen Zertifikate nach (deposit address, Seq, id). Zuletzt die erzwungenen Zertifikate (§8), nach id. Jeder Node leitet aus einer identischen Folge von Blöcken einen identischen Zustand ab.

Writes werden geprüft, bevor einer von ihnen landet. Eine Gutschrift an eine Adresse, deren Autorität verbrannt wurde, schlägt lautstark fehl, statt die Zelle wiederzubeleben; ein Delta, das überlaufen würde, lässt das ganze Zertifikat fehlschlagen. Genau dafür existiert die dauerhafte Spent-Registry.

Ein Skip ist Semantik, kein Fehlschlag. Aufnahme und Anwendung sind verschiedene Ereignisse. Ein Block Producer kann nie einen ungültigen Block erzeugen, indem er ein Zertifikat aufnimmt, das sich als veraltet herausstellt; das Zertifikat wird übersprungen, und der Einleger zahlt. Der Einleger hat die Reads gewählt, also steht der Einleger für sie ein.

Eine Signatur, höchstens eine Belastung. Angewandte und übersprungene Zertifikate werden gleichermaßen als gesehen markiert. Ein gesehenes oder abgelaufenes Zertifikat aufzunehmen, oder eines, das in einem der beiden Märkte unter der Basisgebühr des Blocks bietet, macht den Block ungültig, sodass kein Producer die Zertifikate anderer erneut aufnehmen oder absichtlich verzögern kann, um ihre Einlagen abzuschöpfen. TTLs sind durch den Konsens beschränkt, sodass das Seen Set beschneidbar bleibt.

Bedingungen, für die niemand belastet werden kann, machen den Block ungültig. Manche Fehlschläge haben keinen Schuldigen: ein Fill, dessen Sequencer-Zähler außer der Reihe ist, dessen Fence-Zähler (§7) sich bewegt hat, dessen Zahler bereits ausgegeben ist oder dessen Einlage nicht reserviert werden kann; ein erzwungenes Zertifikat, dessen Reads nicht gelten. Ein solches Zertifikat aufzunehmen macht den Block ungültig, und nichts wird belastet. Der Block Producer, der den Block aus Zustand gebaut hat, den er hält, ist die Partei, die es hätte wissen können.

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, keine Arithmetik auf elliptischen Kurven. All das ist parallel während der Gültigkeitsprüfung geschehen. Auch die Zertifikats-id wird dort berechnet und in den Fold hineingetragen.

Wertgleichheit, keine Versionen. Die Anwendbarkeit vergleicht deklarierte Read-Werte, keine Versionszähler. Ein Slot, der sich geändert und wieder zurückgeändert hat, ist weiterhin anwendbar, sodass das System strikt seltener überspringt als versionsbasierte Nebenläufigkeitskontrolle.

Prolog und Epilog des Folds selbst. Vor den Zertifikaten schreibt der Fold an einer Epochengrenze die Beacon-Zellen (§4). Nach ihnen teilt er die Blocksubvention auf und rotiert den Coinbase-Maturity-Ring (Begleitdokument), verbucht das angewandte Gas für den Gebührenregler (§9) und berechnet an einer Epochengrenze den Epochen-State-Root, der dem des Headers gleichen muss. Er gibt nur bei Ungültigkeit des Blocks einen Fehler zurück; ein Problem mit einem Zertifikat ist ein Ausgang, nie ein Fehler.

4. Zellen und typisierter Zustandszugriff#

Eine Zelle ist der Wert an einem Slot (address, word): eine vorzeichenlose 256-Bit-Ganzzahl, Big-Endian in 32 Bytes. Abwesende Zellen werden als null gelesen. Neben den Zellen führt das Protokoll eine Spent-Address-Registry, eine dauerhafte Menge von One-Shot-Adressen, deren Signaturautorität verbrannt wurde.

Eine Adresse ist version ‖ blake3(tag ‖ version ‖ payload)[:31], außer der Protokolladresse, die aus dem Versions-Byte 0x00 gefolgt von Nullen besteht:

One-Shot gegenüber persistent ist eine Wallet-Richtlinie, offengelegt als ein Bit der Adresse, nicht zwei Ledger [7]. Wallets verwenden standardmäßig eine frische One-Shot-Adresse pro eingehender Zahlung, sodass die Zahlung an eine neu abgeleitete Adresse der konfliktfreie schnelle Pfad ist, und eine ausgegebene Zelle ist kompaktierbar, sobald der Block, der sie ausgegeben hat, jenseits des Undo Horizon begraben ist. Wer ein Konto will, verwendet die persistente Version. Mining-Belohnungen gehören an eine persistente Adresse: der Konsens akzeptiert beide Arten als Auszahlungsadresse, aber eine One-Shot-Adresse verbrennt jede Belohnung, die sie hält, in dem Moment, in dem sie ausgegeben wird, und der Node weist eine solche aus diesem Grund ab.

Aus dem typisierten Zugriff kommt die Parallelität. Ein Fold, der nur Exact Reads unterstützte, würde jeden populären Contract serialisieren: tausend Zertifikate, die einen Pool berühren, ergäben eine Anwendung und 999 Skips. Stattdessen deklariert ein Read, wie er eine Zelle einschränkt, und ein Write, was er mit ihr tut:

Nur EXACT wird veraltet. Beliebig viele per Guard geschützte Belastungen und Gutschriften auf einen Slot kommutieren: sie werden in beliebiger Reihenfolge angewandt, und ein Skip tritt nur auf, wenn ein Guard wirklich fehlschlägt (eine echte Überziehung), nicht wenn sich das Guthaben bloß geändert hat. Eine Disziplin pro Slot pro Zertifikat: ein Set und ein Delta bestehen nicht nebeneinander auf demselben Slot. Die Regel, die das Modell korrekt hält, lautet, dass per Guard geschützte Werte nie in die Berechnung fließen: eine Zusicherung gibt nichts zurück und ein Delta liest nichts, sodass die erneute Ausführung eine reine Funktion der deklarierten Exact Reads bleibt. Diese eine Disziplin deckt Überweisungen, angebotsbegrenzte Prägungen, Freigaben, Trinkgelder und Vault-Anteile ab, also die überwältigende Mehrheit der On-Chain-Schreibvorgänge. Die Abstammungslinie sind Escrow-Transaktionen, Transactional Boosting und CRDTs [8][9][10]; Zycord macht die Kommutativität zum Nebenläufigkeitsvertrag zwischen Nodes.

One-Shot-Zellen. Eine Adresse, die nie auf der Kette erschienen ist, befindet sich im Zustand ∅; ein erster Schreibvorgang versetzt sie in gespeichert; das Zertifikat, das sie als ausgegeben markiert, signiert mit ihrem Schlüssel, versetzt sie in ausgegeben, dauerhaft. Der Registry-Eintrag, der die Ausgabe festhält, wird nie kompaktiert: er ist es, was die Wiederauferstehung der Adresse verhindert.

Null ist Abwesenheit. Ein nie beschriebener Slot und ein auf null geschriebener Slot sind derselbe Slot: null zu schreiben löscht die Zelle. Das ist eine Konsensanforderung. Sie erlaubt es einem Guard oder einem Exact Read, 0 zu nennen, ohne zu fragen, ob der Slot existiert, und sie hält den State Root zu einer Funktion des Zustands und nicht der Historie, die ihn hervorgebracht hat.

Der Epoch Beacon. Programme dürfen Umgebungswerte nicht direkt lesen. Das Protokoll schreibt die Höhe des Headers, der die aktuelle Epoche eröffnet hat, und ab der Ära der Maschine dessen Zeit in reservierte Zellen, einmal pro Epoche, und Programme lesen sie wie jeden anderen Slot. Das ergibt Zeitbewusstsein ohne Veralten pro Block; beide Werte sind während der gesamten Epoche konstant, im Mainnet ein Tag: 2.880 Blöcke unter Proof of Work, 17.280 unter Proof of Stake (§11).

5. Assets ohne Maschine#

Die Start-Ära braucht eine Ökonomie, bevor sie einen Computer braucht. Zycord liefert native Assets ab Block 0 als Zertifikatsoperationen aus, ohne Beteiligung einer virtuellen Maschine:

• TRANSFER — bis zu 32 Bewegungen von (asset, from, to, amount) in einem Zertifikat, innerhalb seiner Limits für Reads und Writes, jede ein Guard balance ≥ Δ gepaart mit zwei Deltas. Eine Gutschrift, die auf ein Pure Delta oder auf eine frische One-Shot-Zelle zielt, ist das Trinkgeld, sodass Trinkgelder keinen eigenen Opcode brauchen. Einer Contract-Adresse darf nur die native Münze gutgeschrieben werden, und nie der Adresse eines Precompiles (§6), aus der niemand den Wert wieder herausholen könnte.
• ISSUE — erzeugt eine Asset-id mit einer Obergrenze der Ausgabemenge in einer Write-once-Zelle.
• MINT — per Guard geschützt: minted + Δ ≤ cap.
• RETIRE — verbrennt bis zu 64 One-Shot-Adressen, jede von ihrem Eigentümer autorisiert und innerhalb der Limits des Zertifikats, ohne Wert zu bewegen: keine Reads, ein Pure Write, der jede Zelle als ausgegeben markiert. Das eigentliche Ausgeben geschieht automatisch innerhalb eines Transfers. Die Stilllegung ist das Primitiv für Kompaktierung und Privatsphäre: der Zahlungsempfänger löscht eine One-Shot-Adresse, sobald sie ihren Dienst getan hat.

Ein Streamer, der zehntausend Trinkgelder in einem Block empfängt, kostet den Fold zehntausend kommutative Additionen: null Konflikte, null Skips, kein Sequencer, keine Maschine. Der Emissionsplan der nativen Münze und die Obergrenze jedes ausgegebenen Assets leben hier, durchgesetzt von der geprüften Arithmetik von §3.

Eine Zahlung wird so abgewickelt. Die Wallet des Senders wählt eine One-Shot-Zelle, die sie hält, deklariert einen Guard auf ihr, belastet sie, markiert sie als ausgegeben, schreibt der frischen One-Shot-Adresse des Empfängers gut und schickt das Wechselgeld an eine eigene frische One-Shot-Adresse. Zwei Zertifikate, die über zwei verschiedene Nodes darum rennen, dieselbe One-Shot-Zelle auszugeben, sind beide gültig; genau eines wird angewandt, und das andere wird übersprungen und der Einlage belastet, die es benannt hat.

6. Die Maschine: cEVM#

Zycord betreibt eine virtuelle Maschine, die cEVM, einen an Zertifikate angepassten Dialekt der Ethereum Virtual Machine [2]. Die Wahl ist bewusst: das Neuheitsbudget des Projekts wird für das Zustands-, das Nebenläufigkeits- und das ökonomische Modell ausgegeben, und die Maschine sollte das Vertrauteste im System sein. Solidity, seine Compiler, Auditoren und Werkzeuge lassen sich übernehmen. Die gesamte Abweichung des Dialekts ist eine Liste von Entfernungen, zwei Neubindungen, sechs Ergänzungen und vier Neubepreisungen.

Storage wird deklariert, nicht entdeckt. Ein Zertifikat trägt die Reads, die seine Ausführung verbraucht hat, und die Writes, die sie erzeugt hat, und die Gültigkeitsprüfung vergleicht sie mit einer erneuten Ausführung. Vier Opcode-Familien erreichen eine Zelle: SLOAD und SSTORE in der exakten Disziplin sowie die Assert- und die Delta-Familie in der kommutativen. Ein aufgerufener Frame darf der deklarierten Menge höchstens 16 Einträge hinzufügen, sodass ein Aufgerufener die Limits, die sein Aufrufer braucht, nicht aufbrauchen kann; der Eintrag, der dies überschreiten würde, bricht diesen Frame ab und keinen anderen.

Hinzugefügt, auf Bytes, die kein EVM-Fork je vergeben hat: SASSERTGE 0x21, SASSERTLE 0x22, SASSERTEQ 0x23, SDELTAADD 0x24, SDELTASUB 0x25, SETSEQ 0x26. Das Prädikat und das Vorzeichen stecken im Opcode, nie auf dem Stack. Ein Guard gibt nichts zurück, sodass keine Verzweigung davon abhängen kann, ob er gilt; die Nettosumme eines Deltas wird über den ganzen Zahlen gebildet und nie modulo 2²⁵⁶. SETSEQ(key) setzt die Sequencer-Zelle des Contracts, in dessen Kontext gerade ausgeführt wird, und keines anderen; ein Null- oder fehlerhafter Schlüssel ist ein Ableitungsfehler, der das gesamte Zertifikat ungültig macht.

Neu gebunden: NUMBER und TIMESTAMP antworten aus Exact Reads der Epoch-Beacon-Zellen, sodass beide während der gesamten Epoche konstant sind, und ein portierter Contract, der block.timestamp für eine Frist verwendet, entscheidet gegen eine Zeit, die bis zu 24 Stunden veraltet ist.

Entfernt (13): BLOCKHASH, COINBASE, PREVRANDAO, GASLIMIT, BLOBHASH [14], BLOBBASEFEE, SLOTNUM haben kein Bezugsobjekt; GASPRICE und BASEFEE benennen Zellen pro Block, deren Exact Read von Bauart her veraltet ist; BALANCE und SELFBALANCE würden einen Exact Read eines nativen Guthabens erzwingen; ORIGIN hat keinen Absender, den es benennen könnte; SELFDESTRUCT ließe eine Code-Hash-Zelle auf null zurückfallen.

Neu bepreist: SLOAD und SSTORE kosten pauschal die Warm-Access-Kosten; der Cold-Access-Aufschlag ist überall gestrichen; KECCAK256 steigt auf 720 Gas plus 144 pro Wort, gemessen an der eigenen Implementierung dieser Maschine, die einzige Neubepreisung, die eine Gebühr erhöht. Die Assert- und Delta-Opcodes kosten denselben Warm-Access-Betrag wie SLOAD.

Precompiles sind eine geschlossene Menge von fünf: sha256, identity, modexp, ed25519_verify und blake3.

Zwei Zähler. Sequential Gas wird aus den deklarierten Anzahlen von Reads, Writes und Registry-Einträgen abgeleitet und nie von der Maschine gemessen. Der parallele Zähler ist das, was der Interpreter zählt, gegen ein Budget, das das Zertifikat in Ableitungseinheiten deklariert; es auf Tiefe 0 zu überschreiten macht das Zertifikat ungültig.

Code reist im Zertifikat. Contract-Code lebt in einer Write-once-Code-Hash-Zelle, sodass es kein Redeploy gibt, und ein Deploy ist ein Aufruf mit einem Null-Ziel. Das Laufzeit-Image wird im Zertifikat mitgeführt und durch einen deklarierten Exact Read der Code-Hash-Zelle aufgelöst, nie allein über die Adresse. Ein Blob umfasst höchstens 24.576 Bytes.

Der Datensatz eines Contracts besteht aus fünf Zellen: dem Code-Hash, dem Deployer, dem Sequencer-Schlüssel, dem Admin und dem Fence-Zähler (§7). Die Admin-Zelle hält eine Adresse; null bedeutet, dass der Deployer der Admin ist, und 32 Bytes 0xff bedeuten, dass auf die Rolle verzichtet wurde, unwiderruflich. Der Admin setzt den Sequencer-Schlüssel über ein Registrierungszertifikat und gibt die Rolle über ein Set-Admin-Zertifikat weiter oder verzichtet auf sie; beide deklarieren Exact Reads der Deployer- und der Admin-Zelle, sodass ein Zertifikat eines ersetzten oder zurückgetretenen Admins übersprungen wird. Contract-Code setzt nie einen Admin; er versetzt seinen eigenen Sequencer mit SETSEQ, und so bekommt auch ein von einer Factory erzeugter Contract einen.

Die Standardbibliothek. Ein Token, eine Trinkgeldkasse und ein Escrow, Delta-first geschrieben, sind in dem Block, der die Maschine aktiviert, an bekannten Adressen vorab deployt, zusammen mit dem Delta-Wrapper, den sie aufrufen. Ein portierter Ethereum-Contract, der die entfernten Opcodes und Precompiles meidet, läuft ab dem ersten Tag korrekt im Vollständig-exakt-Modus, serialisiert von einem Sequencer, wenn er stark genutzt wird; Parallelität ist pro Slot optional, typischerweise ein kleiner Diff, der eine Guthaben-Map von Load/Store auf Assert/Delta umstellt.

7. Sequencer#

Guarded Deltas lösen die Konkurrenz um Zahlungen auf. Was bleibt, ist Exact-Read-Logik auf heißem Zustand, ein Orderbuch, ein automatisierter Market Maker, wo zwei ehrliche Nutzer, die gegen dieselbe Zelle bauen, weiterhin einen Skip erzeugen und wo Contracts, die Zustand lesen, um zu entscheiden, was sie schreiben, nicht in beliebiger Reihenfolge angewandt werden können. Die Antwort des Protokolls ist, den Contract seinen Serialisierer wählen zu lassen.

Bindung. Der Datensatz jedes Contracts (§6) hält einen Sequencer-Schlüssel. Ein Contract, dessen Schlüssel nicht null ist, ist sequenziert: ein Zertifikat darf eine seiner Zellen nur mit der Signatur dieses Schlüssels exakt lesen, per Gleichheit schützen oder setzen. Ein Contract, dessen Schlüssel null ist, ist offen: jeder darf seinen exakten Pfad mit einem eigenen Zertifikat nehmen, und der Contract ist nur durch seinen Code geschützt. Der Schlüssel wird beim Deploy vom Deployer gesetzt, später vom Admin oder vom eigenen Code des Contracts über SETSEQ, und so ersetzt eine Governance einen Sequencer ohne Admin. Die Bindung darf jeden Schlüssel benennen; ein Schlüssel, den niemand bedient, ist kein Konsensfehler, der Contract ist schlicht unbenutzbar, bis jemand ihn bedient oder der Forced Path (§8) ihn ändert. Guarded Deltas kommutieren und werden nie gesperrt, sodass ein sequenzierter Token weiterhin jeden Transfer von jedem annimmt.

Das Verzeichnis. Ein Sequencer kündigt mit einem Verzeichnis-Zertifikat an, wo sein Dienst antwortet: sein Schlüssel und eine Zeichenkette von 1 bis 256 Bytes druckbarem ASCII, typischerweise eine URL, angekündigt von einer persistenten Adresse. Der Eintrag verfällt 90 Tage nach der TTL des ankündigenden Zertifikats, sofern er nicht erneuert wird, und ein Widerrufszertifikat entfernt ihn sofort. Der Konsens speichert die Zeichenkette und interpretiert sie nie. Das Verzeichnis dient der Auffindung, nicht der Autorisierung: Wallets lesen es, um zu erfahren, wen sie fragen sollen.

Intents. Ein Nutzer baut kein Zertifikat gegen einen sequenzierten Contract. Der Nutzer signiert einen Intent: das Ziel und die Calldata, ein paralleles Budget, eine Nonce, ein Fenster von NotBefore bis TTL mit TTL − NotBefore höchstens 8 Blöcke, die persistente Adresse des Sequencers, einen Satz von Schranken für das Ergebnis, die dem Sequencer geschuldete Zahlung, die etwaigen Co-Sequencern geschuldeten Zahlungen, One-Shot-Zahler, die all das finanzieren, und Wechselgeld-Ausgaben. Eine Schranke ist ein Prädikat über eine Zelle, die der Aufruf schreibt, final-at-least, final-at-most, delta-at-least oder delta-at-most, und mindestens eine Schranke muss einen Slot nennen, den der Aufruf geschrieben hat. Der Intent ist die gesamte Autorisierung des Nutzers; der Sequencer kann nicht ändern, was er tut, nur wann.

Fills. Der Sequencer führt den Intent über seiner eigenen Sicht des Zustands aus, der Kettenspitze plus jedem Fill, den er bereits gebaut hat, und veröffentlicht das Ergebnis als Fill: ein Zertifikat, dessen Programm der Intent ist, dessen Einlage aus dem eigenen persistenten Guthaben des Sequencers stammt und dessen id der Hash des Intents ist, sodass zwei Fills eines Intents eine id teilen und nur einer belastet werden kann. Dem Sequencer wird nur hinsichtlich der Lebendigkeit vertraut, nie hinsichtlich der Sicherheit: lügt er über die Eingaben, wird der Fill gegen den kanonischen Fold schlicht übersprungen, und die Lüge kostet die Einlage des Sequencers, nicht die Mittel des Nutzers.

Quittungen. Ein Sequencer beantwortet einen signierten Intent in Millisekunden, lange bevor ein Block existiert: er führt den Intent aus, signiert den Fill und gibt der Wallet den Fill zurück oder eine signierte Quittung, die die Intent-id, den Pipeline-seq und das Ergebnis nennt. Das ist eine Vorabbestätigung. Sie ist das Versprechen des Sequencers und nicht das der Kette; endgültig wird sie, wenn der Fill angewandt wird. Weil jede Quittung signiert ist, ist Fehlverhalten ein Beweismittel: zwei Quittungen eines Schlüssels, die einen seq verschiedenen Intents oder einem Intent verschiedene Ergebnisse geben, sind ein Beweis, den jeder aus den Bytes prüfen kann. Der Konsens bestraft das nicht. Der Markt tut es. Format, Preis, Identität und Reputation der Quittungen liegen Off-Chain und sind von Bauart her frei, sodass Nutzer zwischen einem günstigeren Sequencer, einem öffentlich identifizierten oder einem anonymen wählen und einen verlassen, der beim Signieren widersprüchlicher Quittungen (Equivocation) ertappt wird.

Pipelines. Die Kette hält für jedes Paar (sequencer key, contract) den zuletzt angewandten seq vor. Ein Fill deklariert einen seq für jede Pipeline, in der er steht, und kann nur hinein, wenn der Zähler auf seq − 1 steht; Zähler rücken nur vor, wenn der Fill angewandt wird. Ein übersprungener Fill lässt seinen Zähler daher, wo er war: die hinter ihm gebauten Fills können nicht hinein, und der Sequencer baut ab derselben Nummer neu. Zwei Fills auf einem seq: der erste in Fold-Reihenfolge kommt hinein, der zweite nicht. Die Pipeline eines Sequencers committet in der Reihenfolge, in der er signiert hat, gleich in welcher Reihenfolge ein Producer sie erhalten hat, und ein Producer, der die Pipelines mehrerer Sequencer mischt, hat keine Wahl über das Ergebnis.

Der Fence-Zähler. Jeder Contract führt in seinem Datensatz einen Zähler, fid. Ein Fill deklariert die fid jedes Contracts, den er exakt liest oder setzt; eine Abweichung bedeutet, dass der Fill nicht hinein kann. Der Zähler rückt um eins vor, wenn ein erzwungenes Zertifikat (§8), das angewandt wird, eine Zelle des Contracts setzt, und wenn die Sequencer-Zelle des Contracts geschrieben wird. Ein Read oder ein Delta lässt ihn nicht vorrücken: ein Read ändert nichts, und ein Delta kommutiert mit allem, was ein Fill per Guard schützt oder per Delta ändert. Ein Fill, der eine Zelle exakt liest, die andere per Delta bewegen, steht für diesen Read ein wie jedes Zertifikat, und sein Sequencer zahlt den Skip, wenn sich die Zelle bewegt hat. So machen der Forced Path und ein Sequencer-Wechsel jeden Fill ungültig, der über dem Zustand gebaut wurde, den sie umgangen haben, ohne dass jemand belastet wird: der Sequencer sieht die Fence sich bewegen, baut neu und veröffentlicht erneut und verliert dabei nur Latenz.

Co-Sequencing. Ein Aufruf, der Contracts überquert, die an verschiedene Sequencer gebunden sind, landet auf der Kette als ein Fill, der die Signatur jedes Sequencers trägt, dessen exakten Pfad er berührt, innerhalb des Limits des Zertifikats von 16 Signaturen, jede gegen die Signatur-Obergrenze des Blocks und im Parallel Gas gezählt, jede mit einem seq in ihrer eigenen Pipeline, jeder Sequencer bezahlt mit dem, was der Intent für ihn nennt. Die Koordination, wer führt, wie Reservierungen vorgenommen werden, was jeder berechnet, liegt Off-Chain und ist von Bauart her frei; die Kette sieht ein Zertifikat, atomar von Bauart her. Ein gemeinsamer Fill, der nie veröffentlicht wird, blockiert nur die Pipelines, in denen er steht; sobald sein Fenster verstrichen ist, verwendet jeder Signierende die Nummer wieder, die er signiert hat.

Wer einen Skip zahlt. Wenn ein Fill hineinkommt und ein Read veraltet ist oder ein Write überläuft, wird nichts geschrieben, niemand wird bezahlt, und wer den Fehler gemacht hat, zahlt die Skip-Gebühr: der erste Read oder Write, der in Zertifikatsreihenfolge fehlgeschlagen ist, entscheidet, und die Rechnung geht an den Sequencer, der sich für diesen Contract erklärt hat, wenn der Contract auf dem exakten Pfad des Fills liegt und der Datensatz der Kette übereinstimmt; in jedem anderen Fall geht sie an den Leiter, den Sequencer, dessen Einlage der Fill nennt. Jeder aufgeführte Sequencer hat genau dafür eine Reserve, die an der Position des Fills genommen wird. Der Nutzer zahlt nie einen Skip. Die Zahlung des Nutzers an jeden Sequencer wird erst abgewickelt, wenn der Fill angewandt wird.

Was ein Sequencer ist. Ein gewöhnlicher Server, betrieben vom Anwendungsteam, mit welcher Maschinerie es auch bevorzugt: ein einzelner Prozess, ein Rollup, eine Föderation. Er sieht den Order Flow seiner Anwendung zuerst und ist daher der natürliche Ort für den extrahierbaren Wert dieser Anwendung; der Entwurf macht das explizit und lässt die Anwendung diesen Wert vereinnahmen, statt ihn an Block Producer abfließen zu lassen, während der Forced Path die Macht begrenzt, die damit einhergeht. Schwere Contracts werden tragfähig, Kryptografie, die gesamte Logik eines Spiels, ein ganzes System in einem Contract, weil schwere Ausführung Off-Chain bei der Konstruktion stattfindet und die Kette sie parallel verifiziert. Konstruktion ist ein Wettbewerbsmarkt: ein günstigerer oder zuverlässigerer Sequencer zieht Nutzer an, und jeder Node, der Konstruktion anbietet, fügt Kapazität hinzu.

8. Der Forced Path: Aufnahme ist Anwendung#

Ein Contract, dessen einzige Tür sein Sequencer ist, ist ein Gefängnis, wenn der Sequencer zensiert, überhöhte Preise verlangt oder verschwindet. Jeder Nutzer hat daher einen langsamen Pfad, der niemandes Erlaubnis braucht.

Der Nutzer signiert einen Open Intent: einen Intent genau wie in §7, ohne benannten Sequencer und ohne Co-Sequencer, finanziert aus den eigenen One-Shot-Zahlern des Nutzers, und leitet ihn an das Netzwerk weiter. Er reist im Mempool als Intent, nicht als Zertifikat. Der Block Producer, der den vollständigen Zustand hält und jedes gewöhnliche Zertifikat des Blocks bereits abgewickelt hat, berechnet den Zustand am Blockende und führt die Open Intents, die er wählt, gegen diesen Zustand aus, in Intent-id-Reihenfolge, und hängt die resultierenden erzwungenen Zertifikate als letzte Zertifikate des Blocks an. Die id eines erzwungenen Zertifikats ist der Hash seines Intents, wie bei einem Fill. Aufnahme ist Anwendung: es gibt keine Warteschlange, keinen Lease, kein Kontingent und keine Frist. Ein erzwungenes Zertifikat, dessen deklarierte Reads gegen den Zustand, an dem es platziert wurde, nicht gelten, kann überhaupt nicht in den Block; der Producer hat es gebaut, also ist der Producer die Partei, die es hätte wissen können.

Von Bauart her beschränkt. Ein Block trägt höchstens 16 erzwungene Zertifikate, und jedes deklariert höchstens 4.000 Ableitungseinheiten an parallelem Budget (200.000 Maschinen-Gas). Jeder Ausgang, den ein Contract anbietet, Abhebung, Stornierung, Stilllegung, Transfer, muss in dieses Budget passen; die Regel für Contract-Autoren lautet, dass eine Abhebung in das erzwungene Budget passt. Bei voller Auslastung nimmt der Forced Path ein Drittel der parallelen Obergrenze bei Genesis ein, und der gewöhnliche Verkehr behält den Rest.

Ein fehlschlagender Aufruf landet trotzdem. Ein erzwungenes Zertifikat, dessen Aufruf revertiert, seine Schranken verletzt oder kein Gas mehr hat, kommt in seiner fehlgeschlagenen Form hinein, FORCED_FAILED: seine Zahler werden belastet und verbrannt, das Wechselgeld geht an den Nutzer zurück, die id wird als gesehen markiert, und sonst wird nichts geschrieben. Die Gültigkeitsprüfung akzeptiert die fehlgeschlagene Form nur, wenn die erneute Ausführung des Aufrufs gegen die deklarierten Reads tatsächlich fehlschlägt. Das macht den Pfad missbrauchsresistent: ein Angreifer, der Open Intents weiterleitet, die nicht gelingen können, zahlt für jeden einzelnen, und ein Nutzer, dessen Intent solide ist, kann durch sie nicht ausgehungert werden, weil der Producer für das bezahlt wird, was er aufnimmt, und Überschuss bevorzugt.

Die Fence. Ein erzwungenes Zertifikat, das angewandt wird und eine Zelle eines Contracts setzt, lässt den Fence-Zähler dieses Contracts (§7) vorrücken, sodass kein Fill, der über dem von ihm veränderten Zustand gebaut wurde, hinein kann. Ein erzwungenes Zertifikat, das einen sequenzierten Contract nur liest, exakt oder über Guards, oder darin nur Deltas bewegt, lässt die Fence unberührt, ebenso eines, das in seiner fehlgeschlagenen Form landet; ausstehende Fills kommen weiterhin hinein, und nur einer, der eine Zelle exakt gelesen hat, die das erzwungene Zertifikat bewegt hat, wird übersprungen (§7). Der Sequencer verliert Latenz, nicht mehr, und ein Nutzer, der auf einem heißen Contract eine Transaktion pro Block erzwingt, zahlt jedes Mal den erzwungenen Preis.

Bezahlung. Die Bezahlung des Intents deckt die Gebühren des Zertifikats zu den Basisgebühren des Blocks; der Basisgebührenanteil wird verbrannt, und der Rest kommt zu den Tips des Block Producers. Der Block Producer erhält, was ein Sequencer erhalten würde.

Kein Zustand verwaist. Ein Contract, dessen Sequencer verschwunden ist, bleibt am Leben durch seine Delta-Methoden, die keinen Sequencer brauchen, und durch den Forced Path, über den seine Nutzer abheben und über den sein eigener Code oder der Admin SETSEQ oder eine Registrierung aufrufen und ihn an einen neuen Sequencer binden kann. Zensur kehrt sich um: sie kostet den Zensor, durch entgangene Gebühren und Nutzer, die ihn umgehen, und kostet das Netzwerk nichts. Kein Betreiber ist für die Sicherheit tragend.

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

Eine Kette verbraucht drei Ressourcen unterschiedlicher Skalierbarkeitsklassen, Daten, Verifikation und Mutation, und sie in einem Markt zu bepreisen bedeutet, dass eine Signaturprüfung in der Auktion mit einem Storage-Schreibvorgang konkurriert. Zycord teilt die Gebühr in zwei unabhängige Märkte, jeder mit eigenem Ziel, eigener Obergrenze und eigener Basisgebühr, gehalten im Konsenszustand:

Sequential Gas bepreist Zustandsmutation, die knappe Ressource, die eine Schleife, die jeder Node der Reihe nach durchläuft. Parallel Gas bepreist Verifikation, die mit jedem Kern und jeder GPU wächst, die dem Netzwerk beitreten, und seine Obergrenze ist hoch und günstig angesetzt. Die Folge ist ein Entwurfsziel, formuliert als Invariante: schwere Kryptografie belastet das Netzwerk nicht, von ökonomischer Bauart her. Ein Zertifikat, das einen großen Beweis verifiziert, aber zwei Slots schreibt, zahlt fast alles im günstigen Markt.

Beide Märkte haben die Form von EIP-1559 [12], jeder in seiner eigenen Einheit: die Basisgebühr wird verbrannt und die Prioritätsgebühr bezahlt den Producer, auf Zertifikate, die angewandt werden, und nur auf diese. Die Gebühr eines übersprungenen Zertifikats wird vollständig verbrannt und bezahlt niemanden. Das ist die tragende Regel des ökonomischen Modells. Brächte ein Skip ein Trinkgeld ein, würde die Partei, die den Inhalt eines Blocks wählt, dafür bezahlt, die Fehlschläge anderer zu arrangieren. Das Verbrennen kehrt das um: ein Skip verbraucht Platz unter der Obergrenze und bringt nichts ein, sodass ein Producer, der seinen Ertrag maximiert, die Anwendung maximiert und aktiv dagegen arbeitet, Skips zu verursachen.

Nur angewandtes Gas bewegt die Basisgebühren. Pro Block werden drei Größen gezählt: aufgenommenes Gas (jedes Zertifikat, gleich welchen Ausgangs) begrenzt die Obergrenzen; angewandtes Gas (nur was angewandt wurde) bewegt die Basisgebühren; Block-Bytes begrenzen die Byte-Obergrenze. Ein Skip ist ein gescheiterter Versuch, die Kette zu nutzen, kein Beleg für Nachfrage nach ihr; bewegte das aufgenommene Gas die Gebühr, könnte ein Griefer Blöcke zur festen Skip-Gebühr mit selbstkollidierenden Zertifikaten füllen und alle anderen zu konstanten Kosten aus dem Markt preisen.

Die sequenzielle Obergrenze ist elastisch. Das sequenzielle Ziel T ist ab Block 0 Konsenszustand, keine Konstante, und ein Epochenregler bewegt es:

• Innerhalb eines Blocks liegt die weiche Obergrenze bei 2T und die harte Grenze bei 4T. Ein Producer, der zwischen beiden ausschlägt, verwirkt einen quadratischen Anteil seines eigenen Ertrags, einen Teil der Subvention plus der Gebühren des Blocks, und nie den Anteil eines anderen.
• Über Epochen hinweg folgt T der Nachfrage: das Doppelte des unteren Medians des angewandten Gases in der Epoche, begrenzt zwischen T − T/1024 und T + T/512, nach unten durch den Genesis-Wert und nach oben durch die Genesis-Kapazität beschränkt (Begleitdokument). Wachstum wird zurückgehalten, wenn das Health Gate meldet, dass das Netzwerk nicht gesund ist: zitierte konkurrierende Header über 2 % der Blöcke der Epoche.
• Die Zertifikatsanzahl, die Signaturanzahl und das Byte-Limit skalieren von ihren Genesis-Werten aus mit T, bis zu statischen Kapazitäten (2²⁵ Zertifikate, 8 MB).

Übersprungene Zertifikate verbrennen ihre Gebühren und registrieren nichts, sodass der einzige Weg, die Obergrenze anzuheben, darin besteht, Anwendung zu erreichen: anhaltende, konfliktfreie Nutzung, die Basisgebühren verbrennt. Wachstum zu erzwingen kostet einen Angreifer genau das, was organische Verbreitung alle anderen kostet. Der parallele Markt braucht nichts von dieser Sorgfalt: sein Ziel und seine Obergrenze sind auf ein konstantes Vielfaches, 3×, des sequenziellen Ziels und der sequenziellen Obergrenze festgelegt, also 3T und 6T, und erben deren Wachstum. Die Abstammungslinie ist Moneros Strafmedian [15] und die Arbeit an adaptiven Limits [16].

Die Konstruktionsmarge. Derselbe parallele Markt bezahlt Sequencer für Formungsarbeit: ein Sequencer, der viele Transaktionen zu einem Zertifikat aggregiert, zahlt dafür ein paralleles Gebot und berechnet seinen Nutzern pro Transaktion, innerhalb des Intents.

10. Netzwerk#

Körper sind Kettendaten. Die Zertifikatskörper eines Blocks müssen abrufbar sein, damit der Block gültig ist, sodass der Zustand stets allein aus der Kette rekonstruierbar ist und kein Betreiber, Sequencer eingeschlossen, je Verwahrer von Daten ist. Zertifikate sind größer als klassische Transaktionen, weil sie ihre Reads und Writes mittragen; die Abhilfen sind struktureller Art: Fills schneiden interne Writes heraus, ausgegebene One-Shot-Zellen werden kompaktiert, sobald sie jenseits des Undo Horizon begraben sind, und ein Node darf Körper unterhalb einer Untergrenze beschneiden, die er seinen Peers ankündigt.

Transport. TCP, darüber TLS 1.3 mit Ed25519-Peer-Identitäten in selbstsignierten Zertifikaten: der Kanal ist an einen Schlüssel gebunden, und mehr wird nicht behauptet. Jede Nachricht ist ein 5-Byte-Frame, Länge und Typ, und die Länge wird vor jeder Allokation gegen die eigene Obergrenze des Typs geprüft. Ein Typ, den ein neuerer Build hinzugefügt hat, wird unter einem kleinen Limit gelesen und verworfen, statt die Verbindung zu schließen.

Die Weiterleitung ist hash-first. Zertifikate werden unabhängig per Gossip verbreitet und bei Ankunft auf Gültigkeit geprüft, zustandslos und parallel. Ein weiterleitender Node braucht keinen Zustand, um die Kosten der Spam-Filterung zu begrenzen: die zustandslose Gültigkeit ist aus Bytes prüfbar, und ein Node, der Zustand hält, weist zusätzlich ein Zertifikat ab, dessen Einlage es nicht decken kann. Die Weiterleitung behandelt Exemplare, keine ids: ein Zertifikat, dessen Signaturen fehlschlagen, kostet dieses Exemplar, und gegen die id wird nichts festgehalten, denn ein späteres Exemplar derselben Autorisierung kann gut sein. Blöcke werden als Header plus Hash-Listen gegen den Mempool weitergeleitet [11], sodass die Ausbreitungslatenz nicht mit dem Blockinhalt skaliert, und der Empfänger verifiziert die Arbeit des Headers, bevor er irgendeinen Körper abruft.

Die Synchronisation wählt nach verifizierter Arbeit. Ein aufholender Node bevorzugt den Peer, dessen Header tatsächlich die meiste Arbeit nachgewiesen haben, gegenüber dem Peer, der die größte Höhe behauptet. Header werden als Kette validiert, bevor Körper abgerufen werden; ein konkurrierender Zweig wird nur übernommen, wenn er sich innerhalb des Undo Horizon anschließt und mehr Arbeit trägt als die Kette, die er ersetzt (unter Proof of Stake mehr Slots, §11). Festgelegte Checkpoints, im Release eingebettet und nur akzeptiert, wenn ein Block mindestens eine Epoche alt ist, weisen eine widersprechende Kette zurück, wie schwer sie auch sei, als Verteidigung der Startphase gegen das Umschreiben der Historie; ein Betreiber kann per Flag einen Checkpoint hinzufügen.

Peers werden bewertet, nach Identität: eine ungültige Nachricht kostet 20, eine Protokollverletzung 50, ein nicht ausgelieferter Körper 10, eine übermäßige Anfrage 5; eine nützliche Nachricht bringt 1 ein; ein Peer wird bei −100 gebannt. Teure Prüfungen, Schlüsselepochen und Proof-of-Work-Auswertungen, werden pro Peer budgetiert und erstattet, wenn sich der Block als nützlich erweist, sodass ein Angreifer einen Node nicht dazu bringen kann, Arbeit an Ankündigungen zu verrichten, die ins Leere führen.

Zitate. Ein Header darf bis zu vier jüngere konkurrierende Header auf der Höhe seines Elternblocks zitieren, unbezahlt: das Zitieren erfordert echten Proof of Work, während das Unterdrücken des Signals erfordern würde, dass nahezu jeder Block Producer es auslässt. Die zitierte Fork-Rate ist das Gesundheitssignal, das der Gebührenregler (§9) liest.

Die Node-Schnittstelle. Lesezugriffe werden über HTTP bedient, standardmäßig an localhost gebunden; das Einreichen von Zertifikaten, Open Intents und signierten Service Cards sind die einzigen Schreibzugriffe. Lesezugriffe sind pro Client ratenbegrenzt, mit einem Vertrauens-Token, um die eigenen Werkzeuge des Betreibers auszunehmen. Ein Stratum-Endpunkt in dem Dialekt, den gängige CPU-Miner sprechen, lässt einen Node mit externer Software minen.

11. Proof of Stake#

Dieser Abschnitt spezifiziert den Konsens der Ära, in der die Blockproduktion von Proof of Work an den Stake übergeht. Die Regeln von §2 bis §10 gelten unverändert, außer wo dieser Abschnitt etwas anderes sagt; der Zeitplan und jeder Wert stehen im Begleitdokument. Als offen markierte Konstanten werden durch das Release der Ära festgelegt.

Was sich ändert. Zwei Dinge. Das Recht, den nächsten Block zu produzieren, das Proof of Work gegen Hashes verkauft, wird nach Stake ausgelost; und das Blockintervall sinkt von 30 auf 5 Sekunden. Alles andere bleibt bestehen: jede Gültigkeitsregel von §2 wird von jedem Node für jedes Zertifikat aus den Bytes geprüft; der Fold ist derselbe; die zwei Gas-Märkte sind dieselben; ein ungültiges Zertifikat in einem Block macht den Block ungültig. Die Zitierregel von §10 bleibt bestehen, mit der Slot-Signatur des zitierten Headers anstelle seiner Arbeit. Die Angriffsfläche, die diese Ära öffnet, ist die eines Proof of Stake und keine andere.

Wohin die Rechenleistung geht. Ein Proof-of-Work-Miner gibt Rechenleistung für Hashes aus, die Sicherheit kaufen und sonst nichts. Ein Producer in dieser Ära gibt dieselbe Rechenleistung für Verifikation aus: Signaturen prüfen, Programme erneut ausführen, Zertifikate ableiten, parallel, bevor er sie ordnet. Die Arbeit, für die das Netzwerk bezahlt, wird zu der Arbeit, die das Netzwerk braucht. Ein gewöhnlicher Rechner verifiziert Tausende von Zertifikaten pro Block; ein Producer mit mehr Kernen hält Schritt, während das Volumen wächst. Parallele Verifikation legt die Obergrenze weit über das, was die sequenzielle Schleife verbraucht; was jenseits davon liegt, steht in §12.

Stake. Ein Teilnehmer bindet native Münzen mit einer nativen Operation, BOND, die Guthaben von einer persistenten Adresse in eine an diese Adresse gebundene Stake-Zelle bewegt. Die Stake-Zellen sind Protokollzellen: das Zertifikat autorisiert die Bewegung, und der Fold führt den Schreibvorgang aus, wie er es für die Sequencer-Zähler tut. Der Schlüssel dieser Adresse ist der Schlüssel, der Blöcke signiert. Ein Stake wird eine Epoche nach seiner Bindung aktiv, sodass Stakes nicht in Serie erzeugt und verworfen werden können; UNBOND gibt das Guthaben nach einer Verzögerung zurück, die länger ist als der Undo Horizon. Das Minimum legt das Begleitdokument fest. Ein Schlüssel, ein Stake.

Die Auslosung. Blöcke belegen Slots eines festen Intervalls. Für jeden Slot wird ein Producer aus der Menge der zu Beginn der Epoche aktiven Stakes ausgelost, mit einer Wahrscheinlichkeit proportional zum Stake, aus einem Seed, den die Kette während der vorherigen Epoche festgelegt und in die Beacon-Zellen (§4) geschrieben hat; der Seed darf durch die Producer der Blöcke, die ihn festlegen, nicht beeinflussbar sein. Der Header trägt den Slot und die Signatur des ausgelosten Producers anstelle des Proof of Work; ein Header, der von einem anderen Schlüssel oder außerhalb seines Slots signiert ist, ist ungültig. Ein Slot ohne Block bleibt leer, und der nächste ausgeloste Producer baut auf dem letzten Block auf, den er kennt. Die Auslosung ist eine Funktion des vor Beginn der Epoche festgelegten Zustands, sodass jeder Node sie allein ableitet und über den Block selbst hinaus keine Konsensnachricht ausgetauscht wird. Die Abstammungslinie ist die Slot-Leader-Lotterie von Ouroboros [17] und der Leader-Zeitplan pro Epoche von Solana [21]; den Leader hinter einer verifizierbaren Zufallsfunktion [31] zu verbergen, wie Praos es tut [18], ist die Alternative, falls Denial of Service gegen bekannte Producer zum Problem wird.

Kettenwahl. Wo §10 nach verifizierter Arbeit wählt, wählt diese Ära nach Länge: unter gültigen Ketten diejenige, die die meisten Slots belegt [17]; zwischen zweien gleicher Länge diejenige, deren erster Block nach dem Fork im früheren Slot liegt. Der Undo Horizon und die festgelegten Checkpoints von §10 bleiben bestehen und sind die Verteidigung gegen das Umschreiben mit Schlüsseln, deren Bond inzwischen gelöst ist: ein Node, der dem Netzwerk beitritt, akzeptiert die Historie, die sein Release festlegt, und keine längere Kette widerspricht ihr.

Belohnung. Die Blocksubvention und die Prioritätsgebühren gehen an den ausgelosten Producer, wie sie an den Miner gingen, über denselben Maturity-Ring; der verbrannte Teil bleibt verbrannt. Der erwartete Ertrag eines Teilnehmers ist proportional zu seinem Stake, und die Kosten, ihn einzunehmen, sind die Verifikation der Zertifikate, die er aufnimmt. Ein ungültiger Block wird abgewiesen und zahlt demjenigen, der ihn signiert hat, nichts.

Equivocation. Ein einziger Fehler wird im Konsens bestraft: zwei Header, die von einem Schlüssel für einen Slot signiert wurden. Wie ein ungültiges Zertifikat ist er ein Ein-Nachrichten-Beweis, von jedem aus den Bytes prüfbar. Ein Meldezertifikat trägt die zwei Header; der Fold verbrennt den eigenen Bond des Signierenden, entfernt den Schlüssel aus der aktiven Menge und zahlt dem Melder einen offenen Bruchteil. Eine Meldung wird angenommen, bis der Austritt des Stakes abgeschlossen ist. Kein anderes Verhalten wird im Konsens bestraft, und kein Verhalten eines Producers erreicht die Münzen eines anderen. Der Präzedenzfall ist das Proposer Slashing auf der Beacon Chain von Ethereum [19].

Pools. Ein Pool ist ein Stake, der Delegation annimmt. Jede persistente Adresse darf binden und mit einer nativen Operation, DELEGATE, ihren Bond auf den Schlüssel eines Pools richten; ein Bond, der nur delegiert, hat ein kleineres Minimum als einer, der produziert. Das Guthaben verlässt nie den Delegator, der es unter derselben Austrittsverzögerung umleitet oder löst. Das Gewicht eines Pools in der Auslosung ist sein eigener Bond plus das, was an ihn delegiert ist. Die Belohnung der Blöcke, die ein Pool produziert, wird vom Fold einmal pro Epoche, abseits des Pfads pro Block, aufgeteilt zwischen dem Pool, zu einer Marge, die er bei seiner Registrierung erklärt, und seinen Delegatoren, proportional zum Stake. Bei Equivocation wird der eigene Bond des Pools verbrannt, und seine Delegationen gehen an ihre Delegatoren zurück. Wie die Verifikation innerhalb eines Pools aufgeteilt wird, ist Sache des Pools: jedes Mitglied verifiziert den Anteil, den es erhält, ein Zertifikat kann an mehr als ein Mitglied gehen, und der Betreiber sammelt die Antworten, stellt den Block zusammen und signiert ihn mit dem ausgelosten Schlüssel. All das ist Konstruktion, außerhalb des Konsenses und von Bauart her frei (§1): die Kette sieht eine Tabelle von Delegationen, einen von einem Schlüssel signierten Header und einen Block, dessen Zertifikate jeder Full Node erneut verifiziert. Ein kleiner Node steuert die Kerne bei, die er hat; ein Halter, der nur Münzen hat, steuert Stake bei. Die Abstammungslinie sind die Stake-Pools von Cardano [20], die Delegatoren ebenfalls nie slashen.

Die Rampe. Die Ära tritt in drei Schritten ein, jeder eine Konsensregel.

1. Bonding. BOND, UNBOND und DELEGATE werden angenommen. Proof of Work produziert weiterhin jeden Block und erhält den gesamten Anteil des Producers.
2. Rampe, über 90 Epochen. Jeder Block wird weiterhin gemint und trägt die Signatur des für seine Höhe ausgelosten Stakes, im Header außerhalb des Proof-of-Work-Urbilds; die Block-id deckt sie ab, sodass ein signierter Block und seine unsignierte Kopie zwei Blöcke sind, und bei gleicher Arbeit gewinnt der signierte. Die Kettenwahl erfolgt weiterhin nach Arbeit, und zwei Signaturen auf einer Höhe sind keine Equivocation. Der Anteil des Producers an der Subvention wird zwischen Miner und Staker aufgeteilt: ein Zähler k beginnt bei 1 und steigt mit jeder Epoche, die das Gate passiert, um eins, und der Staker erhält k/180, sodass die Arbeit bis zur Umstellung mindestens die Hälfte behält. Ein ohne die Signatur mitgeführter Block ist gültig und zahlt niemanden: der Anteil seines Producers an der Subvention und seine Prioritätsgebühren werden verbrannt, sodass ein Miner nichts gewinnt, wenn er den Staker auslässt, und ein Staker nichts gewinnt, wenn er abwesend ist. Eine Epoche passiert das Gate, wenn mindestens 90 % ihrer Blöcke die Signatur trugen und der aktive Stake, Delegationen eingeschlossen, mindestens 10 % der Supply hielt. Die Rampe beginnt, wenn der aktive Stake 30 Epochen lang 10 % der Supply erreicht, oder spätestens in der Epoche, die das Begleitdokument festlegt, mit welchem Stake auch immer vorhanden ist. Kein Block wird allein durch Stake produziert, bevor der Stake im Produktivbetrieb 90 Epochen lang neun von zehn Blöcken signiert hat. Der Präzedenzfall ist das Hybridmodell von Decred, in dem geminte Blöcke Stake-Stimmen tragen und die Subvention zwischen beiden aufgeteilt wird [22], und der Merge, bei dem der Stake fast zwei Jahre lang seine eigene Kette betrieb, bevor er die Blockproduktion übernahm [23].
3. Umstellung. Der erste Block der Epoche nach der 90. Epoche, die das Gate passiert, ist Slot 0: Proof of Work endet, das Intervall wird 5 Sekunden, und die Epoche wird 17.280 Slots lang. Was eine Epoche an Subvention zahlt, ändert sich nicht; jeder Block zahlt ein Sechstel, und ein leerer Slot zahlt nichts. Die Obergrenzen pro Block (§9), mit ihren Unter- und Obergrenzen, und die Anzahl für den Forced Path (§8) werden durch sechs geteilt, abgerundet, sodass die Kapazität pro Tag im Moment der Umstellung dieselbe ist, und der Epochenregler setzt von dort aus fort. Jede in Blöcken gezählte Konstante, die Zeit misst (Maturity, maximale TTL, Intent-Fenster, Undo Horizon, Fenster der Medianzeit, Lebensdauer eines Verzeichniseintrags), wird mit sechs multipliziert, und eine vor der Umstellung gesetzte Maturity oder TTL wird beim Umstellungsblock umgerechnet.

Finalität. Ein Block ist durch Tiefe final, wie unter Proof of Work. Finanzdienstleister sollten 10 Minuten warten: 120 Blöcke, wo Proof of Work 20 verlangte. Blöcke, die älter als eine Epoche sind, dürfen als Checkpoints festgelegt werden.

12. Jenseits der vollständigen Verifikation#

In den Ären von Proof of Work und Proof of Stake verifiziert jeder Node jedes Zertifikat. Die Rechenleistung ist nicht die Grenze: die Verifikation ist parallel, und die Obergrenzen von §9 werden an Ärengrenzen neu festgelegt, bis hin zur strukturellen Breite der Zertifikatsliste, 2²⁵ pro Block. Was vor dieser Wand begrenzt, sind die Daten: die Bandbreite, um jeden Körper zu empfangen, und der Speicher, um jeden Körper und jeden Eintrag der Spent-Registry vorzuhalten. Dieser Abschnitt sagt, was über den Weg jenseits davon bekannt ist, und überlässt ihn einer späteren Ära, die bei Bedarf aktiviert wird, wenn sich das tägliche Volumen dem nähert, was ein gewöhnlicher Node verifiziert. Er ist eine Richtung, keine Spezifikation: die Probleme haben mehrere Lösungen mit unterschiedlichen Zielkonflikten, das Netzwerk bedient lange Zeit jede Nachfrage, die ihm begegnen wird, ohne eine von ihnen, und sich im Detail auf eine ferne Zukunft vorzubereiten ist nicht mehr wert, als den Weg für diejenigen markiert zu lassen, die ihn gehen. Nichts von dem, was vorher kommt, ändert sich. Gültigkeit als Funktion der Bytes, der Fold, typisierter Zugriff, die zwei Märkte, Sequencer und der Forced Path bleiben, wie sie sind. Was sich ändert, ist nur, wer jedes Zertifikat verifiziert.

Was das Zertifikat erlaubt. In Ketten mit erneuter Ausführung, Ethereum, Solana und denen, die von ihnen abstammen, führt jeder Validator jede Transaktion gegen den globalen Zustand aus, das Verifizieren erbt die Grenzen des Zustands, und die historische Antwort waren größere Maschinen, also weniger Nodes. Parallele Ausführung innerhalb des Nodes, mit deklarierten Zugriffslisten wie bei Solana [21], macht jede Maschine schneller und ändert nicht, wer eine braucht. Cardano kam näher heran: im erweiterten UTXO-Modell ist die Validierung deterministisch und lokal [24], aber Skripte laufen auf jedem Node, und geteilter Zustand konkurriert, was das Modell löst, indem es die Serialisierung an Batcher außerhalb der Kette verlagert, die von der Kette nicht anerkannt werden. Rollups, optimistische wie Validity-Rollups [25][26], haben die Ausführung von der Basiskette genommen und sie verifizieren lassen: das ist die richtige Aufteilung, bezahlt mit einer zweiten Schicht, einer Bridge, einem einzelnen Sequencer, dessen Forced Path hinter einer Verzögerung wartet, und, je nach Art, einer Woche interaktiver Streitbeilegung oder einem Prover, der um Größenordnungen mehr kostet als die Ausführung. Ein Zycord-Zertifikat ist ein Rollup-Batch, den die Basiskette aus seinen eigenen Bytes prüft und nie gegen ihren Zustand ausführt, und der aus diesem Grund keine zweite Schicht braucht: es gibt keine Bridge, weil es einen Zustand gibt; keinen Streit, weil ein ungültiges Zertifikat sein eigener Betrugsbeweis ist, in einer Nachricht; keinen Prover, weil das Verifizieren kostet, was das Ausführen kostet; der Sequencer ist pro Contract, der Forced Path landet im nächsten Block, und zwei Contracts unter verschiedenen Sequencern lassen sich in einem atomaren Zertifikat zusammensetzen (§7), wo zwei Rollups eine Bridge brauchen. Und wo die Antwort auf Wachstum Sharding ist, Ethereums ursprünglicher Kurs, Near [27], die Parachains [28], das den Zustand partitioniert und die Atomarität über Partitionen hinweg verliert, partitioniert Zycords Partition, wenn sie kommt, die Verifikation und nicht den Zustand: der Zustand bleibt einer, der Fold bleibt einer und jedes Zertifikat bleibt atomar, weil die Frage, wer ein Zertifikat verifiziert, frei wählbar ist, wenn die Gültigkeit eine Funktion der Bytes ist.

Stichprobenartige Verifikation. Mit gebundenem Stake kann die Verantwortung für die Verifikation eines Zertifikats einer ausgelosten Teilmenge von Stakes zugewiesen werden, statt auf alle zu fallen. Ein Zertifikat gelangt mit den Attestierungen seines Komitees in einen Block; jedem Node steht es weiterhin frei, alles zu verifizieren; ein ungültiges Zertifikat bleibt sein eigener Betrugsbeweis, eine Nachricht, ohne Zustand und ohne interaktives Spiel [29]; und was die Ära hinzufügt, ist das Slashing derer, die attestiert haben. Die Größe des Komitees, die Form der Attestierung, das Anfechtungsfenster und was mit dem geschieht, was über einem für nichtig erklärten Zertifikat angewandt wurde, sind die Spezifikation jener Ära und bleiben offen. Die Wirkung ist, die Kurve umzukehren: die Kapazität wächst mit jedem Node, der beitritt, weil jeder einen kleineren Anteil verifiziert, und das Komitee wächst mit der Menge.

Der Verifikationskegel. Wer ein Zertifikat erhält, braucht nicht die ganze Kette, um ihm zu vertrauen. Reads sind deklariert, sodass die Menge der Zertifikate, von denen es abhängt, aus der Kette aufzählbar ist: für jede gelesene Zelle die Zertifikate, die sie seit dem letzten Epochen-State-Root geschrieben haben, und deren eigene, rekursiv. Dieser Kegel, aus den Bytes erneut verifiziert und an einer Epochenwurzel verankert, auf die der Header committet (§3), ist eine vollständige Verifikation dessen, was für den Empfänger zählt, erledigt in Sekunden, in Netzwerkzeit, ohne Schaltkreis und ohne speziellen Beweis. Eine Börse, die eine Einzahlung erhält, verifiziert den Kegel der Einzahlung, nicht das Netzwerk; unter stichprobenartiger Verifikation bleibt dann, Reorgs und das Anfechtungsfenster abzuwarten, was sie heute schon tut. Ein Beweis, dass eine Zelle an der Epochenwurzel einen gegebenen Wert hielt, ist das eine neue Objekt, das dies erfordert, und seine Form ist offen; die Abstammungslinie ist die vereinfachte Zahlungsverifikation [1].

Speicher. Was das Netzwerk bereits tut: ausgegebene One-Shot-Zellen werden jenseits des Undo Horizon kompaktiert (§4), und ein Node beschneidet Körper unterhalb einer Untergrenze, die er ankündigt (§10). Was als Studienfall bleibt: eine Spent-Registry pro Epoche, in der One-Shot-Adressen verfallen und die Registry geschlossen wird; ein Akkumulator anstelle der Registry [30]; und die Aufbewahrung alter Körper durch einen Bruchteil der Nodes, mit der Epochenwurzel als Garantie dafür, dass das Aufbewahrte das Ausgegebene ist.

Bandbreite. Zwei Wege. Der erste ist die Topologie, die der Entwurf bereits hat: Wallet, Sequencer, Producer. Ein Fill muss das Netzwerk nicht fluten; er geht vom Sequencer zu den Producern, und alle anderen erhalten den Hash, wie es die Weiterleitung bei Blöcken bereits tut (§10). Der zweite besteht darin, den Kopf eines Zertifikats von seinem Körper zu trennen. Der Kopf ist das, was der Fold berührt: id, Reads, Writes, Einlage und Gebot. Der Körper ist das, was die Verifikation verbraucht: Programm, Calldata, Signaturen. Unter stichprobenartiger Verifikation braucht ein Producer den Körper nur von den Zertifikaten, für deren Verifikation er ausgelost wird, und von allen anderen den Kopf, und seine Bandbreite sinkt um Größenordnungen. Der Block committet weiterhin auf den Hash des gesamten Exemplars, und Körper bleiben Kettendaten, bereitgestellt von denen, die sie verifiziert haben, und von denen, die sie archivieren; wie ihre Verfügbarkeit garantiert wird, wenn nicht jeder Node sie hält, ist die Frage, die die Ära beantworten muss, bevor es sie gibt [29].

13. Akzeptierte Risiken#

Folgen der Regeln, die so akzeptiert werden, wie sie sind. Jede ist beschränkt oder trifft eine Partei, die sie gewählt hat; keine erlaubt es irgendwem, den nativen Wert eines Dritten an sich zu nehmen.

1. Ein Contract, dessen Sequencer, Admin und sequencer-ändernder Code allesamt verschwunden sind, kann nur über den Forced Path verlassen werden: langsam und teurer, aber lebendig.
2. Bei leeren Blöcken kommen beide Basisgebühren bei 7 zur Ruhe, oberhalb ihrer Untergrenze von 1: unter 8 rundet der Abwärtsschritt auf null. Diesen Ruhepunkt zu verschieben erfordert eine Parameteränderung an einer Ärengrenze.
3. Etwa ein Block bezahlten Gebühren-Griefings auf einem heißen Contract: die eigenen erzwungenen Zertifikate des Block Producers, rund um das eines Nutzers platziert, beschränkt durch die Schranken des Nutzers, und ein erzwungenes Zertifikat pro Block, das den Sequencer zwingt, seine Pipeline neu zu bauen.
4. Ein offener Contract, mit einem Sequencer-Schlüssel von null, ist nur durch seinen Code geschützt, und der Autor eines Zertifikats gegen ihn zahlt seine eigenen Skips: der Autor hat die Reads gewählt.
5. Ein nicht-natives Asset, das einer One-Shot-Adresse von irgendjemand anderem als dem Zertifikat, das sie verbrennt, gutgeschrieben wurde, wird durch das Verbrennen eingefroren, das nur das native Guthaben und die Zellen bewegt, die dieses Zertifikat schreibt. Die Asset-Guthaben einer Adresse vor dem Verbrennen zu prüfen ist eine Wallet-Regel, keine Protokollregel.
6. Ein Zertifikat, das nur Deltas bewegt, lässt die Fence nicht vorrücken (§7); ein vor ihm gebauter Fill, der eine Zelle exakt liest, die es bewegt hat, wird in einem späteren Block übersprungen und dem Sequencer belastet. Ein Sequencer vermeidet das, indem er keine Zelle exakt liest, die sein Contract jeden per Delta bewegen lässt.
7. Restliches Griefing gegen den Ausführenden des Forced Path: ein Angreifer mit vielen Zahlern kann Open Intents weiterleiten, die kein Zertifikat tragen kann, etwa einen, dessen Zahler die Bezahlung nicht deckt. Ein Aufruf, der bloß revertiert oder seine Schranken verletzt, gehört nicht dazu: er landet in seiner fehlgeschlagenen Form und zahlt (§8). Jeder nicht tragbare Intent kostet den Ausführenden einen Bau; die Kopie wird dann verdrängt und unter Quarantäne gestellt, und ein Ersatz auf demselben Zahler muss strikt mehr zahlen.
8. Ein Mitsignierender sperrt keine Zelle. Ein gemeinsamer Fill, den er signiert hat, hält einen Platz in seiner Pipeline, bis der Fill mitgeführt wird oder sein Fenster verstreicht (§7). Ein gemeinsamer Fill, der nicht rechtzeitig mitgeführt wird, kann auf andere Fills auf diesen Zellen treffen; welcher auch immer als zweiter in den Fold gelangt, wird übersprungen und seinem eigenen Einleger belastet.
9. Auf einem offenen Contract gewinnt das Zertifikat, dessen Einlageadresse als erste einsortiert wird, ein Rennen um Exact Reads, und Adressen lassen sich billig grinden; ein Contract mit umkämpftem exaktem Zustand wählt einen Sequencer, dessen Pipeline die Reihenfolge festlegt.
10. Ein einfacher Aufruf auf dem exakten Pfad eines offenen Contracts deklariert die Sequencer-Zelle des Contracts als exakt null. Erhält der Contract einen Schlüssel, bevor das Zertifikat landet, ist der Read veraltet und der Aufruf wird übersprungen und dem Aufrufer belastet; die Wallet warnt, bevor sie einen solchen Aufruf baut.
11. Die Skip-Gebühr ist fest, sodass ein Skip bei hohen Basisgebühren weniger kostet als eine Anwendung; mehrere Varianten eines Zertifikats auszuprobieren ist billig, und jeder Node verifiziert jede davon.
12. Bandbreite und Speicher bei hohem Durchsatz sind ein erklärtes offenes Problem, kein gelöstes: Körper sind Kettendaten, jeder Node trägt jedes Byte, ein Maschinenaufruf trägt den Code, den er ausführt, und die Spent-Registry wächst um einen Eintrag pro One-Shot-Ausgabe. Der Weg steht in §12.
13. Unter Proof of Stake (§11) ist die Sicherheit der Kette die eines herkömmlichen Proof of Stake: sie kostet, was es kostet, eine Mehrheit des Auslosungsgewichts zusammenzubringen, Delegationen eingeschlossen. Die Rampe beginnt an ihrer Frist mit welchem Stake auch immer vorhanden ist, und das Gate ist es, was verhindert, dass die Umstellung abgeschlossen wird, ohne dass lebendiger Stake ein Zehntel der Supply hält; ein abwesendes Zehntel des Stakes hält sie an. Die Equivocation eines Pools kostet nur seinen eigenen Bond, gleich was an ihn delegiert ist; Delegatoren wählen ihren Pool im Wissen darum. Langstrecken-Umschreiben mit Schlüsseln, deren Bond inzwischen gelöst ist, wird nur durch die festgelegten Checkpoints (§10) verhindert, die ein beitretender Node aus seinem Release übernimmt und nicht aus der Kette ableitet.

14. Konformität#

Die Regeln sind die Architekturspezifikation, die Golden Vectors sind das Protokoll, und wo zwei davon sich widersprechen, gewinnt das Präzisere und der Widerspruch ist ein Bug. Das Protokoll lebt in einem veröffentlichten Verzeichnis spec/: die Parameterdateien, das Chain-id-Register, die festgelegten Checkpoints, die Images der vorab deployten Bibliothek und drei Vektorkorpora:

• Fold-Vektoren: (pre-state, block) → (post-state | invalid, outcomes, fees); ein Ungültigkeitsvektor hält die einzelne Regel fest, die er verletzt;
• Ableitungsvektoren: (program, declared reads and writes, deposit) → (reads, writes, artifact, parallel gas), oder die Regel, die das Zertifikat abweist, bevor die Maschine erreicht wird;
• Difficulty-Vektoren: (parameters, headers) → next target, mit einem Urteil über einen Kandidaten-Header; unter Proof of Stake (stake set, seed, slot) → drawn key.

Vektoren werden generiert, nie von Hand bearbeitet. Die Regenerierung treibt den Referenz-Fold an, spielt das Ergebnis durch ihn erneut ab und spielt dann das committete JSON durch einen zweiten, bewusst naiven Fold ab, der keinen Code mit dem ersten teilt; eine Regenerierung, der der zweite Fold widerspricht, schlägt fehl. Eine Regenerierung, die einen bestehenden Vektor ändert, ist eine Konsensänderung und wird als solche geprüft. Eine Implementierung ist konform, wenn sie die Genesis-id reproduziert und die Vektoren besteht; sie ist dann ein Peer, kein Fork.

15. Verhältnis zu v1.0#

Dieses Papier ersetzt v1.0 [0] vollständig. Wo die beiden sich unterscheiden, ist dieses Papier das Protokoll, und v1.0 ist nicht daneben zu lesen. Die These ist unverändert: selbstzertifizierende Zertifikate, ein Fold, der nie ausführt, typisierter Zustandszugriff und zwei Gebührenmärkte. Die Änderungen unten wurden bei der Implementierung des Entwurfs gefunden; jede hat Konsensoberfläche und ganze Fehlerklassen entfernt.

16. Schluss#

Zycord ordnet Zertifikate, statt Transaktionen auszuführen: Gültigkeit, geprüft von jedem, überall, parallel, allein aus Bytes; Zustand, vorangebracht von einem Fold, der nur vergleicht und addiert; Konflikte, übersprungen, bepreist und der Partei belastet, die sie gewählt hat; Nebenläufigkeit, deklariert statt entdeckt; Anwendungen, in Millisekunden bestätigt von Sequencern, denen hinsichtlich der Lebendigkeit vertraut wird und nie hinsichtlich der Sicherheit; ein Forced Path, der jeden Contract erreichbar hält; und ein Konsens, der, sobald die Münze verteilt ist, seine Rechenleistung für Verifikation statt für Hashes ausgibt. Die Verifikation skaliert horizontal mit Hardware, die dem Netzwerk nicht gehört. Das Commitment bleibt sequenziell und nahezu kostenlos.

Literatur#

[0] The Simstoshi. Zycord: A Peer-to-Peer Network of Self-Certifying State Transitions, v1.0. 2026. Durch dieses Papier ersetzt.
[1] S. Nakamoto. Bitcoin: A Peer-to-Peer Electronic Cash System. 2008.
[2] V. Buterin. Ethereum: A Next-Generation Smart Contract and Decentralized Application 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] J. Zahnentferner. Chimeric Ledgers: Translating and Unifying UTXO-based and Account-based Cryptocurrencies. IACR ePrint 2018/262.
[8] P. E. O'Neil. The Escrow Transactional Method. ACM TODS, 1986.
[9] M. Herlihy, E. Koskinen. Transactional Boosting: A Methodology for Highly-Concurrent Transactional Objects. PPoPP 2008.
[10] M. Shapiro et al. Conflict-free Replicated Data Types. SSS 2011.
[11] M. Corallo. BIP 152: Compact Block Relay. 2016.
[12] EIP-1559: Fee Market Change for the ETH 1.0 Chain. Ethereum Improvement Proposals, 2019.
[13] tevador et al. RandomX: Proof-of-Work Algorithm Optimized for General-Purpose CPUs. 2019.
[14] EIP-4844: Shard Blob Transactions. Ethereum Improvement Proposals, 2022.
[15] Monero: Dynamic Block Weight and Penalty. Monero Research Lab documentation.
[16] bitcoincashautist. CHIP-2023-04: Adaptive Blocksize Limit Algorithm for Bitcoin Cash. 2023.
[17] A. Kiayias, A. Russell, B. David, R. Oliynykov. Ouroboros: A Provably Secure Proof-of-Stake Blockchain Protocol. CRYPTO 2017.
[18] B. David, P. Gaži, A. Kiayias, A. Russell. Ouroboros Praos: An Adaptively-Secure, Semi-Synchronous Proof-of-Stake Blockchain. EUROCRYPT 2018.
[19] Ethereum Foundation. Ethereum Consensus Specifications: The Beacon Chain (proposer slashings). 2020.
[20] L. Brünjes, A. Kiayias, E. Koutsoupias, A.-P. Stouka. Reward Sharing Schemes for Stake Pools. IEEE EuroS&P 2020.
[21] A. Yakovenko. Solana: A New Architecture for a High Performance Blockchain. 2017.
[22] Decred Documentation: Proof-of-Stake. docs.decred.org.
[23] Ethereum Foundation. The Merge. ethereum.org, 2022.
[24] M. M. T. Chakravarty, J. Chapman, K. MacKenzie, O. Melkonian, M. Peyton Jones, P. Wadler. The Extended UTXO Model. Financial Cryptography Workshops 2020.
[25] H. Kalodner, S. Goldfeder, X. Chen, S. M. Weinberg, E. W. Felten. Arbitrum: Scalable, Private Smart Contracts. USENIX Security 2018.
[26] V. Buterin. An Incomplete Guide to Rollups. 2021.
[27] A. Skidanov, I. Polosukhin. Nightshade: Near Protocol Sharding Design. 2019.
[28] G. Wood. Polkadot: Vision for a Heterogeneous Multi-Chain Framework. 2016.
[29] M. Al-Bassam, A. Sonnino, V. Buterin. Fraud and Data Availability Proofs: Maximising Light Client Security and Scaling Blockchains with Dishonest Majorities. 2018.
[30] D. Boneh, B. Bünz, B. Fisch. Batching Techniques for Accumulators with Applications to IOPs and Stateless Blockchains. CRYPTO 2019.
[31] S. Micali, M. Rabin, S. Vadhan. Verifiable Random Functions. FOCS 1999.

Zycord: Start, Ären und Parameter#

The Simstoshi
2026 — v2.0
GPG: E724 39CE DD85 11F9 D607 550B 87FD 60D5 EB4A 0B29

Dieses Dokument ist das Begleitdokument zu Zycord: A Peer-to-Peer Network of Self-Certifying State Transitions, v2.0 („das Papier“). Das Papier definiert die Mechanismen. Dieses Dokument legt dar, wie das Mainnet gestartet wurde, wie die Münze emittiert wird, welche Ära was aktiviert und welchen Wert jeder Parameter hat. Es ersetzt §13 und §14 des Papiers v1.0 vollständig; wo sie sich unterscheiden, ist dieses Dokument maßgeblich.

1. Start#

Mainnet-Genesis: 2026-10-07 00:00 UTC (1791331200), Chain-id 1.

• Blöcke alle 30 Sekunden unter Proof of Work; alle 5 Sekunden ab der Umstellung auf Proof of Stake (§6). Proof of Work: RandomX v2, per CPU minebar. Difficulty: LWMA über ein Fenster von 90 Blöcken.
• Block 0 enthält kein Zertifikat, keine Adresse und keinen Schlüssel. Vor Block 0 existiert keine Münze. Genesis ist aus veröffentlichten Quellen reproduzierbar.
• Keine Investorenrunde und keine Admin-Schlüssel. Kein Codepfad lässt irgendeinen Schlüssel pausieren, upgraden, minten, zensieren oder reorganisieren.

Das Start-Commitment. Der Parametersatz trägt ein Commitment auf eine geheime Startnachricht. Block 1 muss dieses Commitment in seinem Header öffnen, sodass nur der Inhaber der Nachricht Block 1 produzieren kann und niemand sonst Arbeit auf einer Kette ansammeln kann, die vor der angekündigten Genesis beginnt; die Emissionsrampe macht jeden Vorsprung wenig wert. Ab Block 2 kann jeder Miner bauen.

Chain-ids werden in einem Register festgehalten. Das Register, mit der Genesis-id, die jedes aktive Netzwerk trägt, ist in jedes Binary eingebettet und wird beim Start geprüft: der Node weist eine stillgelegte id zurück sowie einen Parametersatz, der einer festgehaltenen id eine andere Genesis gäbe. Ein Node verweigert den Start mit einer anderen Work-Engine als der, die das Netzwerk deklariert.

2. Emission#

Die Subvention klingt sanft zu einem dauerhaften Schwanz ab. Die Rate ist innerhalb einer Epoche von einem Tag konstant und sinkt an jeder Epochengrenze um eine Stufe, durch exakte Ganzzahlarithmetik über vier Konstanten:

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

mit E0 = 21 ZCD pro Block, Q = 1054 und tail = 0,33 ZCD pro Block, beim Proof-of-Work-Intervall von 30 Sekunden. Die Rate halbiert sich etwa alle zwei Jahre. Es gibt keine Gleitkommazahlen und keine Tabelle. Der Genesis-Block zahlt keine Coinbase. Der Schwanz beginnt in Epoche 4.376, etwa Jahr 12, mit 61.836.900,03 ZCD planmäßig ausgegeben: die 62.744.838,47, auf die sich der Zeitplan summiert, abzüglich der Startrampe und des Genesis-Blocks. Diese Zahlen sind das, was die Rekursion ergibt; kein Node berechnet je eine geschlossene Form. Ein ZCD sind 100.000.000 Drops.

Ein langsamer Start. Die ersten 86.400 Blöcke (30 Tage) sind eine Rampe: Block h zahlt E(30) · h / 86,400, die Rate der Epoche, in der die Rampe endet, abgerundet, sodass die Belohnung geradlinig von nahezu null auf den Zeitplan steigt. Was die Rampe zurückhält, etwa 907.917 ZCD, wird nie nachgezahlt.

Der Wechsel des Intervalls. Ab der Umstellung auf Proof of Stake (§6) ist die Epoche 17.280 Slots lang, und die Subvention pro Block ist E(n)/6, abgerundet in Drops; die Rekursion ändert sich nicht. Was ein Tag voller Slots zahlt, ist unter beiden Intervallen dasselbe: 21 ZCD pro Block auf der Genesis-Kurve entsprechen 3,5 pro 5-Sekunden-Block, und der Schwanz von 0,33 entspricht 0,055. Der Schwanz beginnt in derselben Epoche, 4.376. Die Rundung hält weniger als ein Tausendstel eines ZCD pro Epoche zurück und wird nie nachgezahlt.

Der Schwanz bezahlt diejenigen, die die jeweilige Ära sichern, ohne die Gebührenmärkte einzuspannen. Ihm gegenüber stehen das Verbrennen der Basisgebühren beider Märkte und das Verbrennen jedes übersprungenen Zertifikats (Papier §9), sodass die Nettoemission Schwanz minus Verbrennung ist und unter Last negativ sein kann. Als Anteil an der Supply strebt der Schwanz gegen null.

3. Aufteilung der Subvention#

Jede Blocksubvention wird ab Block 0 per Konsens im Verhältnis 94 / 3 / 3 aufgeteilt. Die Aufteilung gilt nur für die Subvention, nie für Gebühren, und für jeden Block gleich. Während der Proof-of-Stake-Rampe (§6) werden die 94 % des Producers ihrerseits zwischen Miner und ausgelostem Staker aufgeteilt, nach dem Bruchteil, den die Rampe erreicht hat.

Es gibt keine Premine: die Aufteilung ist eine Regel, die auf jeden geminten Block angewandt wird, keine Zuteilung bei Genesis. Über seine drei Jahre summiert sich der Anteil des Gründers auf weniger als 2 % der Supply vor dem Schwanz. Ein Block Producer, der die weiche Obergrenze überschreitet (Papier §9), verwirkt nur aus seinem eigenen Anteil; die Anteile von Treasury und Gründer werden aus der ungekürzten Subvention genommen.

4. Treasury#

Die Treasury-Zelle ist das native Guthaben der Protokolladresse. Kein Schlüssel hasht auf sie, kein Zertifikat kann sie belasten, und die Genesis benennt kein Quorum. Sie sammelt ab Block 1 an, und dieses Release trägt überhaupt keinen Ausgabeweg. Ein Ausgabeweg wird durch ein Upgrade definiert, nicht vor Höhe 259.200 (etwa 5. Januar 2027), mit Signierenden, die von der Community gewählt werden und nicht vom Gründer. Bis dahin ist die Zelle eine öffentliche Ganzzahl, die jeder prüfen und niemand anrühren kann.

5. Verwaltung: Die ersten drei Jahre (Vorschlag)#

Status. Dieser Abschnitt ist eine Richtung zur Prüfung durch die Community. Nichts darin ist eine Konsensregel, bis das Treasury-Upgrade von §4 einen Schlüsselsatz festlegt, und die Einzelheiten werden erst spezifiziert, nachdem die Richtung angenommen ist.

Was die Treasury erhält. Etwa 533.000 ZCD in Jahr 1, 396.000 in Jahr 2 und 280.000 in Jahr 3: insgesamt etwa 1,21 Millionen. Ab Jahr 4 erhält sie zusätzlich die 3 % des Gründers (§3), für insgesamt etwa 396.000 in jenem Jahr. Was das kauft, hängt von einem Preis ab, den niemand kennt, und ein dünner Markt kann keine großen Verkäufe aufnehmen, also muss der Plan am unteren Ende funktionieren:

Jeder Betrag unten ist daher ein Anteil am Zufluss der Treasury, nie eine Zahl in Dollar oder in ZCD.

Fünf Sitze. Der Sitz wird vor seinem Inhaber definiert. Jeder Sitz hat eine öffentliche Satzung: seine Pflichten, seine Ergebnisse, wie er berichtet und was er bezahlt bekommt. Jeder darf sich bewerben. Wer den Sitz innehat, dient der Satzung, wie unter einem Vertrag.

Entscheidungen.

• Eine Ausgabe braucht 3 von 5.
• Einen Inhaber zu ersetzen, Schlüssel zu rotieren, die Reserve auszugeben oder eine Satzung zu ändern, braucht 4 von 5 und ist vor dem Inkrafttreten 7 Tage lang öffentlich.
• Amtszeiten dauern ein Jahr und sind verlängerbar. Kandidaturen sind 30 Tage lang öffentlich. Die ersten fünf Inhaber sind der Schlüsselsatz, der von dem Upgrade festgelegt wird, das die Node-Betreiber übernehmen; ein späterer Hard Fork kann ihn neu festlegen.

Bezahlung ist Beteiligung, kein Gehalt. Der Anteil eines Sitzes sammelt sich gesperrt an und wird alle sechs Monate freigegeben, gegen einen veröffentlichten Bericht und die Stimmen von 3 der 4 anderen Inhaber. Kein Inhaber stimmt über die Freigabe seiner eigenen Bezahlung ab. Was nicht freigegeben wird, fließt in die Reserve zurück. Die Bezahlung der Sitze ist durch die Satzungen festgelegt und wird nicht durch eine Ausgabenabstimmung bestimmt. Eine Obergrenze pro Sitz, gemessen zum Marktpreis am Tag der Freigabe, schickt jeden Überschuss in die Reserve.

Budget, als Anteile am Zufluss.

Die Infrastruktur hat Vorrang: Nodes, Seeds, Explorer und Build-Server kosten heute etwa 500 US$ pro Monat. Erstattungen werden zum Marktpreis am Tag der Zahlung umgerechnet. Der Anteil deckt diese Kosten bei etwa 0,06 US$ pro ZCD in Jahr 1, 0,08 US$ in Jahr 2 und 0,11 US$ in Jahr 3; darunter wird der Fehlbetrag zinslos vorgetragen und gezahlt, wenn der Anteil es zulässt.

Der Gründer. Die 3 % der Subvention für den Gründer (§3) entlohnen die bis zum und beim Start geleistete Arbeit. Sie sind getrennt vom Sitz des leitenden Entwicklers, der wie jeder andere Sitz für laufende Arbeit bezahlt wird. Der Gründer hält einen Schlüssel von fünf und stimmt nicht über die Freigabe der Bezahlung dieses Sitzes ab.

Was der Konsens durchsetzt. Sobald das Upgrade landet: die 3-von-5-Ausgabe und die 4-von-5-Rotation mit ihrer Verzögerung. Alles andere in diesem Abschnitt ist eine Norm. Was eine Norm durchsetzt, ist, dass jede Ausgabe ein gewöhnliches Zertifikat ist, öffentlich und allein aus der Kette nachzählbar.

Offen. Die Obergrenze pro Sitz. Die Rechtsform, unter der der öffentliche Vertreter unterzeichnet. Ob die sechsmonatige Sperre durch einen Escrow-Contract der Standardbibliothek durchgesetzt wird, sobald die Maschine aktiv ist.

6. Ären#

Ären sind Höhenkonstanten, die in öffentliche Releases einkompiliert sind. Ein Block unterhalb einer Schranke, der ein Programm trägt, das die Schranke freischaltet, ist ungültig, und diese Höhenprüfung ist das Einzige, was Ären trennt, außer der Rampe und der Umstellung von Ära 2, die innerhalb von Höhengrenzen durch Zustand ausgelöst werden. Eine neue Ära darf Regeln und Datensatztypen hinzufügen; sie ändert nie, was ein bestehender Block unterhalb ihrer Aktivierungshöhe bedeutet.

Ära 2 und Ära S werden jeweils als eigenes Release per Hard Fork ausgeliefert, mit einer Spezifikation, einem Devnet unter Angriffsbedingungen und einer Prüfung. Ära 2 öffnet das Bonding nach Höhe, startet ihre Rampe nach Stake mit einer Frist und stellt um, wenn die Rampe abgeschlossen ist: frühestens kann die Umstellung in Epoche 303 (Monat 10) erfolgen, und die Frist für den Start garantiert, dass die Rampe bis Ende von Monat 9 läuft. Für die 10-%-Schwelle ist der Stake der aktive Stake mit seinen Delegationen und die Supply die ausgegebene Münzmenge, beide zu Beginn der Epoche. Das Gate kann die Umstellung über Epoche 363 hinaus anhalten; was es nicht kann, ist zu verhindern, dass sie beginnt.

Stake. Der Mindest-Bond beträgt 1.000 ZCD, und ein Stake nimmt eine Epoche nach seiner Bindung teil. Ein Bond, der nur delegiert, hat ein kleineres Minimum, festgelegt durch das Release der Ära, und verlässt nie die Verwahrung des Delegators. Das Minimum ist in ZCD und nicht in Dollar angegeben, weil keine Regel einen Preis lesen kann; es wird an Ärengrenzen überarbeitet, während die Block-Obergrenze wächst.

Ära 0 ist bewusst winzig, und Ära 1 ist auf das reduziert, was der Entwurf braucht: ohne Admin-Schlüssel gibt es keinen Pausenknopf, also ist jede Konsenszeile eine Zeile, die das Netzwerk ohne Abhilfe töten kann. Unerreichbarer Konsenscode ist unauditierbarer Konsenscode und wird nicht ausgeliefert. Eine Ära, die ihre Komplexität nicht als lohnend erweist, wird nie ausgelöst.

Der Übergang ist handhabbar, weil der Fold agnostisch dagegen ist, wer ordnet: Ära 2 ändert, wessen Signatur auf dem Header steht.

Schranke von Ära 1. Der Schrankenblock schreibt die einkompilierten Konstanten der Ära in Protokollzellen, sodass der State Root von da an auf sie committet. In den ersten 240 Blöcken nach der Schranke muss ein Zertifikat, das SETSEQ ausführt, eine TTL tragen, die mindestens 240 Blöcke hinter der Schranke liegt, und warten, bis es in Reichweite kommt.

Ära 2 und Höhen, die Zeit messen. Nach der Umstellung schreitet die Höhe sechsmal schneller voran. Jede Genesis-Konstante, die eigentlich eine Dauer ist (das Ende des Gründeranteils, die Coinbase-Maturity, die maximale TTL, das Intent-Fenster, die Undo-Tiefe, das Fenster der Medianzeit, die Lebensdauer eines Verzeichniseintrags), wird von Ära 2 in der Einheit gelesen, die sie misst: Höhe 3.153.600 sind 1.095 Epochen zu 2.880, und die Ära beendet den Gründeranteil in Epoche 1.095. Die Genesis-Parametertabelle ändert sich nicht, weil die Konsenswurzel jeden Parameter durchläuft und das Verschieben eines einzigen die Genesis-id jedes laufenden Netzwerks verschieben würde; die Konstanten der Ära sind einkompiliert, wie die von Ära 1.

7. Parameter#

Der Parametersatz ist bei Genesis eingefroren, zur Kompilierzeit in jedes Binary eingebettet und nur per Hard Fork veränderbar. Seine Konsenswurzel geht in jede Signatur ein. zcd params gibt die kompilierten Werte eines Builds aus; zcd genesis gibt Netzwerk, Chain-id, Parameter-Hash, Genesis-id und State Root aus.

Die Konstanten von Ära 1 sind einkompiliert, keine Parameter, weil die Konsenswurzel jeden Parameter durchläuft und das Hinzufügen eines einzigen die Genesis-id jedes laufenden Netzwerks verschieben würde.

Die Konstanten von Ära 2 sind aus demselben Grund einkompiliert.