Glossar
Zertifikat, Fold, Skip, Einlage, Sequencer, Forced Path. Mehrere davon bedeuten hier etwas Engeres als anderswo, und ein paar benennen Ereignisse, für die die meisten Chains kein Wort haben.
Das Vokabular, das dieses Protokoll verwendet, in dem Sinn, in dem es das tut. Mehrere dieser Wörter bedeuten hier etwas Engeres als anderswo, und zwei davon — Skip und Drop — benennen Ereignisse, für die die meisten Chains kein Wort haben, weil sie keine Entsprechung dazu haben.
Zertifikat#
Der einzige Transaktionstyp in Zycord. Ein Zertifikat trägt den Zustand, den es gelesen, und den Zustand, den es geschrieben hat, dazu das Programm, das beide verbindet, die Signaturen, die es autorisieren, eine Einlage, eine TTL und ein Gebot in jedem der beiden Gebührenmärkte. Weil es seine eigenen Eingaben und Ausgaben mitträgt, verlangt die Prüfung, ob es gültig ist, überhaupt keinen Zustand.
Fold#
Die deterministische Schleife, die das Ledger voranbringt. Sie durchläuft die Zertifikate eines Blocks in einer kanonischen Reihenfolge — zuerst Fills, dann jedes gewöhnliche Zertifikat, dann erzwungene Zertifikate — und prüft für jedes, ob seine deklarierten Reads noch gelten: tun sie es, schreibt sie die Writes fest, tun sie es nicht, überspringt sie es. Der Fold führt Vergleiche, Additionen und Schreibvorgänge auf einem heißen Key-Value-Arbeitssatz aus — keine Codeausführung, keine Signaturprüfung, keine erneute Ausführung und keine Arithmetik auf elliptischen Kurven. Er ist die einzige Stufe des Systems, die nicht parallelisiert.
Skip#
Was mit einem Zertifikat geschieht, dessen deklarierte Reads nicht mehr gelten, dessen Deltas den 256-Bit-Bereich verlassen würden oder das unter eine ausgegebene Adresse schreiben würde. Nichts wird geschrieben, eine feste Skip-Gebühr von 1.000.000 Drops (0,01 ZCD) wird aus seiner Einlage verbrannt und zahlt niemanden, der Rest der Einlage wird zurückgegeben, und der Block bleibt gültig. Wer die Einlage benannt hat, zahlt: der Autor eines gewöhnlichen Zertifikats, der die Reads gewählt hat, oder der Sequencer eines Fills. Ein Nutzer zahlt nie den Skip eines Fills. Ein Skip ist Semantik, kein Fehlschlag: Aufnahme und Anwendung sind verschiedene Ereignisse, sodass ein Block Producer nie einen ungültigen Block erzeugen kann, indem er ein veraltetes Zertifikat aufnimmt.
Drop#
Ein nicht berechnetes Nicht-Ereignis. Ein Zertifikat, dessen Einlage nicht reserviert werden kann — die Einlagezelle ist bereits ausgegeben oder hält weniger als den Betrag, den das Zertifikat reserviert —, wird gedroppt: im Block mitgeführt, nicht berechnet, nicht als gesehen markiert und frei zur erneuten Einreichung gegen eine frische Einlage. Ehrliche Nutzer verlieren daher nichts durch Wettläufe auf ihrer eigenen Einlagezelle.
Einlage#
Die Zelle, die für ein Zertifikat einsteht: eine Zelle mit nativem Guthaben einer Nutzeradresse, der daraus reservierte Betrag und der Wechselgeld-Slot, an den der Rest zurückgeht. Kein Zertifikat existiert ohne eine, und die Einlagezelle trägt immer eine Signatur. Ein Skip darf nicht umsonst sein, sonst ersäuft der Mempool; die Einlage ist das, was jedem Konflikt einen Eigentümer gibt. Ein Fill leistet seine Einlage aus dem persistenten Guthaben seines Sequencers, weshalb der Sequencer und nicht der Nutzer zahlt, wenn ein Fill übersprungen wird, und ein erzwungenes Zertifikat wird stattdessen aus der Zahlung seines Open Intents bezahlt. Die Underwriter und versicherten Zertifikate von Whitepaper v1.0 gibt es nicht mehr; dies hat sie ersetzt.
Zelle#
Der Wert an einem Slot — eine vorzeichenlose 256-Bit-Ganzzahl, in 32 Bytes big-endian gespeichert. Null ist Abwesenheit: ein nie beschriebener Slot und ein auf null geschriebener Slot sind derselbe Slot. Das ist eine Konsensanforderung, keine Bequemlichkeit: es hält den State Root zu einer Funktion des Zustands statt der Historie, die ihn hervorgebracht hat.
One-Shot-Adresse (0x01)#
Eine Adresse, deren Signaturbefugnis durch ihre erste Belastung dauerhaft verbrannt wird. An eine frisch abgeleitete One-Shot-Adresse zu zahlen ist der konfliktfreie schnelle Weg, und je Zahlung eine frische abzuleiten ist es, was eine Zahlung mit der nächsten unverknüpfbar macht. Der Preis dafür ist, dass “gib einen Teil davon aus” etwas ist, was eine One-Shot-Adresse nicht kann — siehe Wallet-Regel 1.
Persistente Adresse (0x02)#
Eine wiederverwendbare Adresse. Sie kann nie in die Spent-Registry gelangen, hat also überhaupt keine Angriffsfläche für Burn-Grief. Händler, Spendenadressen, die Einlagen eines Sequencers und Mining-Auszahlungen verwenden eine; zycordd --payout weist alles andere ab.
Spent-Address-Registry#
Die dauerhafte Konsensmenge der One-Shot-Adressen, deren Befugnis verbrannt wurde. Zellwerte unter einer ausgegebenen Adresse dürfen nach dem Undo Horizon beschnitten werden, der Registry-Eintrag aber nie — er ist es, was die Wiederauferstehung der Adresse verhindert. Etwa 33 Bytes pro Adresse, für immer: das ehrliche offene Problem des Protokolls, strukturell geteilt mit jedem Nullifier-Set-Entwurf.
Gültig vs. anwendbar#
Zwei Prädikate, die eine herkömmliche Chain vermengt. Gültig ist zustandslos, parallel und von jedem allein aus den Bytes des Zertifikats prüfbar. Anwendbar ist zustandsbehaftet, sequenziell und allein durch die Position im Ledger entschieden. Zwei gültige Zertifikate dürfen denselben Eingabewert für denselben Slot deklarieren; höchstens eines kann anwendbar sein.
Guarded Delta#
Eine Zugriffsdisziplin, in der ein Zertifikat ein Prädikat über einen Slot behauptet — balance ≥ 10 —, ohne den Wert in die Berechnung einzulesen, und ein vorzeichenbehaftetes Delta schreibt. Beliebig viele bewachte Belastungen und Gutschriften auf denselben Slot kommutieren, sodass ein Skip nur bei einer echten Überziehung auftritt und nicht bloß, weil sich das Guthaben geändert hat. Diese eine Disziplin deckt Überweisungen, angebotsbegrenzte Prägungen, Freigaben und Vault-Anteile ab, und sie wird nie von einem Sequencer gesperrt: ein sequenzierter Token akzeptiert weiterhin jede Übertragung von jedem.
Pure Delta#
Ein vorzeichenbehaftetes Delta ohne Guard. Es kann nie in Konflikt geraten und nie zu einem Skip führen. Trinkgelder, Zähler, Akkumulatoren, Belohnungssummen.
Exact Read#
Die Disziplin nach Art von SLOAD: der Lesezugriff gibt den Wert des Slots in die Berechnung zurück und bindet das Zertifikat daran. Beliebige Logik, Konflikte auf stark genutzten Slots, und die Domäne der Sequencer.
Sequencer#
Ein Off-Chain-Dienst, den ein Contract wählt, um seinen Exact-Read-Verkehr zu serialisieren. Der Eintrag jedes Contracts hält einen Sequencer-Schlüssel: solange er nicht null ist, brauchen ein Exact Read, ein Gleichheits-Guard oder ein Set auf den Zellen dieses Contracts die Signatur dieses Schlüssels; solange er null ist, ist der Contract offen und nur durch seinen Code geschützt. Der Sequencer führt die Intents der Nutzer aus und veröffentlicht die Ergebnisse als Fills. Ihm wird für die Liveness vertraut, nie für die Sicherheit: er kann nicht ändern, was ein Intent tut, nur wann, und ein auf einer Lüge gebauter Fill wird auf Kosten des Sequencers übersprungen. Hört er auf zu bedienen, bleibt der Forced Path.
Intent#
Was ein Nutzer statt eines Zertifikats signiert, um einen sequenzierten Contract aufzurufen: das Ziel und die Calldata, ein paralleles Budget, eine Nonce, ein Fenster von höchstens 8 Blöcken, die persistente Adresse des Sequencers, Schranken für das Ergebnis, die jedem Sequencer geschuldete Zahlung, die One-Shot-Zahler, die ihn 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 muss eine Zelle nennen, die der Aufruf geschrieben hat. Der Intent ist die gesamte Autorisierung des Nutzers, und seine Zahlungen werden nur abgewickelt, wenn der Fill angewendet wird.
Fill#
Das Zertifikat, das ein Sequencer für einen Intent veröffentlicht. Sein Programm ist der Intent, seine Einlage stammt aus dem eigenen persistenten Guthaben des Sequencers, und seine id ist der Hash des Intents, sodass zwei Fills eines Intents eine id teilen und nur einer belastet werden kann. Fills kommen in der Reihenfolge des Folds zuerst, jeder, sobald jede Pipeline, in der er steht, bereit ist.
Quittung#
Die signierte Antwort eines Sequencers auf einen Intent, in Millisekunden zurückgegeben, lange bevor ein Block existiert: die Intent-id, der Pipeline-seq und das Ergebnis. Sie ist eine Vorabbestätigung — das Versprechen des Sequencers, nicht das der Chain, und erst endgültig, wenn der Fill angewendet wird. Weil Quittungen signiert sind, sind zwei von einem Schlüssel, die einen seq an verschiedene Intents oder einem Intent verschiedene Ergebnisse geben, ein Beweis, den jeder aus den Bytes prüfen kann. Der Konsens bestraft das nicht; die Nutzer gehen.
Pipeline#
Die Chain hält für jedes Paar aus Sequencer-Schlüssel und Contract den zuletzt angewendeten seq vor. Ein Fill kommt nur hinein, wenn dieser Zähler eins unter seinem seq steht, und der Zähler rückt nur vor, wenn der Fill angewendet wird, sodass die Fills eines Sequencers in der Reihenfolge festgeschrieben werden, in der er sie signiert hat, gleich in welcher Reihenfolge ein Producer sie erhalten hat. Ein übersprungener Fill hält die hinter ihm gebauten Fills zurück, bis der Sequencer ab derselben Nummer neu baut.
Fence-Zähler#
Ein Zähler im Eintrag jedes Contracts. Ein Fill deklariert den Fence-Zähler der Contracts, auf denen er gebaut wurde, und kann nicht hinein, wenn sich einer bewegt hat. Er rückt vor, wenn ein erzwungenes Zertifikat, das landet, eine der Zellen des Contracts setzt, und wenn die Sequencer-Zelle des Contracts geschrieben wird — so machen der Forced Path und ein Wechsel des Sequencers jeden Fill ungültig, der über dem von ihnen veränderten Zustand gebaut wurde, ohne dass jemand belastet wird. Ein Read oder ein Delta bewegt ihn nicht, ebenso wenig ein erzwungenes Zertifikat, das gescheitert ist. Der Sequencer baut neu und verliert nur Latenz.
Co-Sequencing#
Ein Aufruf, der Contracts überquert, die an verschiedene Sequencer gebunden sind, landet als ein Fill, der die Signatur jedes Sequencers trägt, dessen exakten Pfad er berührt, bis zu 16, jeder mit einem seq in seiner eigenen Pipeline und jeder mit der Zahlung, die der Intent für ihn nennt. Wie sie sich abstimmen, geschieht off-chain und ist bewusst frei gestaltbar; die Chain sieht ein Zertifikat, atomar durch Konstruktion.
Sequencer-Verzeichnis#
Wo ein Sequencer seinen Dienst ankündigt: ein Verzeichnis-Zertifikat von seiner persistenten Adresse bindet seinen Schlüssel an eine Zeichenkette von 1 bis 256 Bytes druckbarem ASCII, typischerweise eine URL. Der Eintrag verfällt 259.200 Blöcke (etwa 90 Tage) nach der TTL des ankündigenden Zertifikats, sofern er nicht erneuert wird, und ein Widerruf entfernt ihn sofort. Der Konsens speichert die Zeichenkette und interpretiert sie nie — sie dient der Auffindung, nicht der Autorisierung. Ein Node beantwortet sie auf /directory.
Forced Path#
Der langsame Pfad, der keinen Sequencer braucht. Ein Nutzer signiert einen Open Intent und leitet ihn an das Netzwerk weiter; ein Block Producer führt die Open Intents, die er wählt, gegen den Zustand am Blockende aus und hängt die Ergebnisse als erzwungene Zertifikate an, die letzten Zertifikate des Blocks. Aufnahme ist Anwendung: es gibt keine Warteschlange, keinen Lease, kein Kontingent und keine Frist. Ein Block trägt höchstens 16 erzwungene Zertifikate, jedes mit höchstens 4.000 Ableitungseinheiten an parallelem Budget (200.000 Maschinen-Gas), weshalb jeder Ausgang, den ein Contract anbietet, in dieses Budget passen muss. Ein erzwungenes Zertifikat, dessen Aufruf revertiert, landet trotzdem, als FORCED_FAILED: seine Zahler zahlen, Wechselgeld geht an den Nutzer zurück, und sonst wird nichts geschrieben.
Open Intent#
Ein Intent ohne benannten Sequencer und ohne Co-Sequencer, finanziert aus den eigenen One-Shot-Zahlern des Nutzers. Er reist im Mempool als Intent, nicht als Zertifikat, und seine Zahlung deckt die Gebühren des erzwungenen Zertifikats: der Basisgebühr-Anteil wird verbrannt, und der Rest geht an den Producer. zcd wallet open-intent signiert einen, und zcd wallet intent --fallback signiert einen, wenn der Sequencer das Original nicht bedient.
cEVM#
Die eine virtuelle Maschine: ein an Zertifikate angepasster Dialekt der Ethereum Virtual Machine. Storage wird deklariert statt entdeckt, Opcodes für Guards, Deltas und das Setzen des Sequencers eines Contracts kommen hinzu, die Opcodes ohne Bezugsobjekt hier sind entfernt, und NUMBER und TIMESTAMP antworten aus dem Epoch Beacon. Aktiv ab Ära 1, mit einer an bekannten Adressen vorab bereitgestellten Delta-first-Standardbibliothek. Solidity und seine Werkzeuge lassen sich übernehmen.
Epoch Beacon#
Reservierte Zellen, die das Protokoll einmal pro Epoche schreibt: die Epochennummer, die Höhe des Headers, der sie eröffnet hat, ein Entropiewort und ab Ära 1 die Zeit dieses Headers. Programme dürfen Umgebungswerte wie den Zeitstempel oder die Höhe nicht direkt lesen — das würde die Ausführung zu einer Funktion von etwas anderem als den deklarierten Reads machen —, also lesen sie den Beacon wie jeden anderen Slot, idealerweise mit einem Bereichs-Guard. Seine Werte sind eine ganze Epoche lang konstant. Das Entropiewort ist Proof-of-Work-Ausgabe und für hochwertige Lotterien ungeeignet.
Epoche#
2.880 Blöcke — etwa ein Tag bei 30-Sekunden-Blöcken, und ab der Umstellung auf Proof of Stake 17.280 Slots zu 5 Sekunden, weiterhin ein Tag. Die Einheit, in der die Subvention eine Stufe sinkt, sich das sequenzielle Kapazitätsziel bewegt und der Beacon aufgefrischt wird.
TTL#
Die Höhe, bis zu der ein Zertifikat festgeschrieben sein muss, um gültig zu sein. Durch den Konsens auf 240 Blöcke (etwa zwei Stunden) begrenzt, 1.440 Blöcke ab der Umstellung auf Proof of Stake, und genau das hält das Seen Set beschneidbar. Ein gesehenes oder abgelaufenes Zertifikat aufzunehmen macht den Block ungültig — sodass eine Signatur höchstens einmal abrechenbar ist, und nur an einer Position, die ihr Signierender durch das Signieren akzeptiert hat.
Sequential Gas und Parallel Gas#
Gebühren teilen sich in zwei Märkte: einen für sequenzielle Zustandsänderung, die knapp ist, und einen für parallele Verifikation, die es nicht ist. Eine Signaturprüfung konkurriert daher nicht in derselben Auktion wie ein Speicherschreibvorgang, und genau das macht schwere Kryptografie konstruktionsbedingt billig. In beiden wird die Basisgebühr verbrannt, und die Prioritätsgebühr zahlt den Producer, auf Zertifikate, die angewendet werden, und nur auf diese; die Gebühr eines übersprungenen Zertifikats wird vollständig verbrannt.
Ära#
Eine Stufe des Protokolls, freigeschaltet durch eine in öffentliche Releases einkompilierte Höhe und, in Ära 2, durch on-chain innerhalb von Höhengrenzen gemessenen Stake — nie durch ein Kalenderdatum oder eine Abstimmung. Ära 0, live seit Block 0: Mining, native Assets, beide Gebührenmärkte, die Aufteilung der Subvention und die Treasury, anwachsend und versiegelt. Ära 1 bei Höhe 80.640 im Mainnet, etwa am 4. November 2026, und seit Höhe 2.880 im öffentlichen Testnet: die cEVM, Sequencer, Intents und Fills, das Verzeichnis und der Forced Path. Ära 2, Proof of Stake: das Bonding öffnet in Epoche 182, etwa am 7. April 2027; die Rampe beginnt, wenn der aktive Stake 30 Epochen lang 10 % der Supply hält, spätestens in Epoche 273; die Umstellung auf Stake allein folgt, wenn die Rampe abgeschlossen ist. Ära S würde vertrauliche Zahlungen hinzufügen, erst nach unabhängigen Audits, und ist nicht Teil der aktuellen Spezifikation. Die Ären 2 und S werden jeweils als eigenes Release ausgeliefert, per Hard Fork. Das Bonding ist nicht Teil von Ära 1.
Proof of Stake#
Der Konsens von Ära 2, in dem das Recht, den nächsten Block zu produzieren, nach Stake ausgelost statt gegen Hashes verkauft wird und das Blockintervall von 30 auf 5 Sekunden sinkt. Alles andere bleibt bestehen: jeder Node prüft jedes Zertifikat aus seinen Bytes, der Fold und beide Gebührenmärkte sind unverändert, und ein ungültiges Zertifikat in einem Block macht den Block weiterhin ungültig. Die Rechenleistung, die ein Miner für Hashes ausgab, gibt ein Producer für Verifikation aus. Er tritt über eine Rampe und eine Umstellung ein, und bis zur Umstellung werden Blöcke gemint. Spezifiziert in Whitepaper §11.
Stake#
An die Blockproduktion gebundene native Coins. BOND bewegt Guthaben von einer persistenten Adresse in eine an diese Adresse gebundene Stake-Zelle, deren Schlüssel der Schlüssel ist, der Blöcke signiert, und UNBOND gibt es nach einer Austrittsverzögerung zurück, die länger ist als der Undo Horizon. Ein Stake wird eine Epoche nach seiner Bindung aktiv, sodass Stakes nicht in Serie erzeugt und verworfen werden können. Der Mindest-Bond beträgt 1.000 ZCD; ein Schlüssel, ein Stake. Das Bonding öffnet mit Ära 2, in Epoche 182.
Pool und Delegation#
Ein Pool ist ein Stake, der Delegation annimmt. DELEGATE richtet einen Bond auf den Schlüssel eines Pools, ab einem kleineren Minimum als ein produzierender Bond, und das Guthaben verlässt nie den Delegator, der es unter derselben Austrittsverzögerung umleiten oder lösen kann. Das Gewicht eines Pools in der Auslosung ist sein eigener Bond plus das, was an ihn delegiert ist, und der Fold teilt seine Belohnung einmal pro Epoche zwischen dem Pool, zu der Marge, die er erklärt hat, und seinen Delegatoren auf, proportional zum Stake. Ein Delegator wird nie geslasht: begeht ein Pool eine Equivocation, wird nur sein eigener Bond verbrannt. Kein Mining-Pool, der off-chain und außerhalb des Konsenses liegt.
Slot#
Unter Proof of Stake ein 5-Sekunden-Intervall, in dem ein Block produziert werden darf, von dem dafür ausgelosten Producer, mit einer Wahrscheinlichkeit proportional zum Stake, aus einem in der vorherigen Epoche festgelegten Seed. Eine Epoche umfasst 17.280 Slots. Ein Slot ohne Block bleibt leer und zahlt nichts, und unter gültigen Chains gewinnt diejenige, die die meisten Slots belegt. An anderer Stelle ist ein Slot ein Speicherort, (address, word), dessen Wert eine Zelle ist.
Rampe#
Der Eintritt von Ära 2: 90 Epochen, in denen jeder Block weiterhin gemint wird und zusätzlich die Signatur des für seine Höhe ausgelosten Stakes trägt. Der Staker erhält k/180 des Anteils des Producers, wobei k bei 1 beginnt und mit jeder Epoche, die das Gate passiert, um eins steigt: mindestens 90 % der Blöcke der Epoche signiert und ein aktiver Stake von mindestens 10 % der Supply. Ein ohne die Signatur geminter Block ist gültig und zahlt niemanden: der Anteil seines Producers und seine Prioritätsgebühren werden verbrannt. Die Rampe beginnt, wenn der aktive Stake 30 Epochen lang 10 % der Supply hält, und spätestens in Epoche 273. Nicht die 30-tägige Belohnungsrampe der Emission; siehe Emission.
Umstellung#
Der Block, bei dem Proof of Work endet: der erste Block der Epoche nach der 90. Epoche, die das Gate der Rampe passiert, spätestens in Epoche 363, etwa am 5. Oktober 2027, wenn das Gate sie nie anhält. Ab ihm kommen Blöcke in 5-Sekunden-Slots, eine Epoche umfasst 17.280 Slots, und jeder Block zahlt ein Sechstel der Rate der Epoche; die Obergrenzen pro Block werden durch sechs geteilt und jede Blockanzahl, die Zeit misst, mit sechs multipliziert, sodass Kapazität und Dauern pro Tag gleich bleiben. Ein Block ist dann bei einer Tiefe von 120 Blöcken final, 10 Minuten, wo Proof of Work 20 verlangte.
Equivocation#
Zwei Header, die von einem Schlüssel für einen Slot signiert wurden: der einzige Fehler, der unter Proof of Stake im Konsens bestraft wird. Wie ein ungültiges Zertifikat ist er ein Ein-Nachrichten-Beweis, den jeder aus den Bytes prüfen kann. Ein Meldezertifikat trägt die zwei Header, und der Fold verbrennt den eigenen Bond des Signierenden, entfernt seinen Schlüssel aus der aktiven Menge und zahlt dem Melder einen Bruchteil. Nichts, was ein Producer tut, erreicht die Coins eines anderen: die Delegationen eines Pools gehen an ihre Delegatoren zurück.
Emission#
ZCD existiert nur als Blocksubvention, und Block 0 zahlt keine. Die Rate beginnt bei 21 ZCD pro Block und sinkt an jeder Epochengrenze durch exakte Ganzzahlarithmetik — E(n) = max(tail, E(n−1) − floor(E(n−1) / 1054)) — und halbiert sich etwa alle zwei Jahre, bis sie in Epoche 4.376, etwa Jahr 12, den dauerhaften Schwanz von 0,33 ZCD pro Block erreicht. Die ersten 86.400 Blöcke (30 Tage) sind eine Rampe: Block h zahlt h/86.400 der Rate, die Block 86.400 zahlt, und was die Rampe zurückhält, etwa 907.917 ZCD, wird nie nachgezahlt. Ab der Umstellung auf Proof of Stake zahlt jeder Block ein Sechstel der Rate der Epoche, sodass ein Tag dasselbe zahlt. zcd emission --height N gibt die Subvention bei jeder Höhe aus.
Aufteilung der Subvention#
Jede Blocksubvention, und nie die Gebühren, wird ab Block 0 per Konsens im Verhältnis 94 / 3 / 3 aufgeteilt: 94 % an den Producer des Blocks nach einer Maturity von zwei Stunden (240 Blöcke, 1.440 unter Proof of Stake), 3 % an die persistente Adresse des Gründers bis Epoche 1.095 (drei Jahre) und 3 % an die Treasury, die von da an auch die 3 % des Gründers erhält. Während der Proof-of-Stake-Rampe werden die 94 % des Producers ihrerseits zwischen Miner und ausgelostem Staker aufgeteilt. Sie ist eine Regel, die auf jeden geminten Block angewandt wird, keine Zuteilung bei Genesis: es gibt kein Premine.
Treasury#
Das native Guthaben der Protokolladresse. Kein Schlüssel hasht auf sie, kein Zertifikat kann sie belasten, und die Genesis benennt kein Quorum. Ihr werden ab Block 1 3 % jeder Blocksubvention gutgeschrieben und ab Epoche 1.095 6 %. Im Protokoll existiert kein Ausgabeweg: einer kann nur durch ein späteres Upgrade hinzugefügt werden, mit Signierenden, die von der Community gewählt werden und nicht vom Gründer, und das Start-Commitment lautet, dass er nicht früher als bei Höhe 259.200 kommt, etwa am 5. Januar 2027.
Treuhandvorschlag#
Ein Vorschlag zur Prüfung durch die Community, keine Konsensregel. Er schlägt vor, wie die Treasury in ihren ersten drei Jahren ausgegeben werden könnte: fünf Sitze mit öffentlichen Satzungen — leitender Entwickler, prüfender Entwickler, Miner, Community, öffentlicher Vertreter —, mit 3 von 5 zum Ausgeben und 4 von 5 (vor dem Inkrafttreten 20.160 Blöcke lang öffentlich), um einen Inhaber zu ersetzen, Schlüssel zu rotieren, die Reserve auszugeben oder eine Satzung zu ändern. Budgets sind Anteile am Zufluss der Treasury, nie feste Summen. Nichts darin bindet, bis das Treasury-Upgrade einen Schlüsselsatz festschreibt. Der Text steht im Begleitdokument.
RandomX#
Die Proof-of-Work-Funktion, optimiert für Allzweck-CPUs, damit gewöhnliche Hardware konkurrenzfähig bleibt; Mainnet und öffentliches Testnet laufen mit randomx-v2. Sie ist ein Konsensparameter, keine Einstellung: eine Binärdatei, die die pow_engine eines Netzwerks nicht berechnen kann, verweigert den Start, statt zurückzufallen.
State Root#
Das Commitment auf den gesamten Zustand bei einer Höhe. Ein Node berechnet es beim Start neu und verweigert den Betrieb, wenn das gespeicherte abweicht, und es dient zugleich als Differenzabgleich zwischen Nodes im Produktivbetrieb: zwei Implementierungen, die aus einer Blockfolge zu verschiedenen Roots gelangen, haben in einer von beiden einen Fehler gefunden.
Wo jeder Begriff normativ definiert ist#
Diese Seite ist eine Lesehilfe. Die bindenden Definitionen stehen in der Spezifikation und den Golden Vectors; die Begründung steht im Whitepaper, v2.0, und seinem Begleitdokument Launch, Eras and Parameters, das Emission, Ären und jeden Parameterwert regelt. Der Vokabularabschnitt der Implementierung selbst steht in docs/ARCHITECTURE.md.