Zycord : un réseau pair-à-pair de transitions d'état auto-certifiantes

Zycord : un réseau pair-à-pair de transitions d'état auto-certifiantes.
The Simstoshi
2026 — v2.0
GPG : E724 39CE DD85 11F9 D607 550B 87FD 60D5 EB4A 0B29

Cet article est complet et autonome. Il remplace la v1.0 [0] ; le §15 en expose la relation. Le lancement, l'émission, les ères et le tableau complet des paramètres se trouvent dans le document compagnon, Zycord : lancement, ères et paramètres.

Versions. Le texte ci-dessous est la v2.0 de l'article, non abrégée, suivie sur cette page de son document compagnon, également en v2.0. Tous deux sont servis en PDF, chacun accompagné d'une signature détachée réalisée avec la clé du projet E724 39CE DD85 11F9 D607 550B 87FD 60D5 EB4A 0B29 : l'article (signature) et le compagnon (signature). Chaque version est archivée sous doi:10.5281/zenodo.22167489, qui pointe vers la plus récente ; la v1.0, remplacée, est doi:10.5281/zenodo.22167490. Le compagnon est archivé sous son propre doi:10.5281/zenodo.23383987.

1. Introduction#

Un nœud de blockchain accomplit trois tâches qui n'ont rien en commun : il dissémine des données, il vérifie des calculs et il fait muter un état. Les données passent à l'échelle avec la bande passante. La vérification passe à l'échelle avec les cœurs, et elle est massivement parallèle si les transactions peuvent être contrôlées indépendamment. La mutation d'état est la seule ressource véritablement séquentielle : quelque part, un historique unique et faisant autorité des écritures doit exister.

Zycord sépare les trois. Une transaction devient un certificat qui porte ses propres entrées et sorties, si bien que la vérifier est une fonction pure de ses octets et ne touche jamais le registre. La tâche de la chaîne se réduit à ordonner les certificats et à exécuter sur eux un fold déterministe : une boucle de comparaisons et d'additions qui touche l'état exactement une fois par certificat. Les conflits n'invalident pas les blocs ; ils provoquent l'omission de certificats individuels, et chaque omission est imputée à une partie qui a accepté le risque. La concurrence n'est pas découverte à l'exécution ; elle est déclarée, slot par slot, par l'auteur du contrat. La filiation est exécuter-ordonner-valider [3], l'ordonnancement déterministe [4], l'exécution parallèle optimiste [5] et la séparation de la dissémination et de l'ordonnancement [6].

La validité est évaluée une fois par certificat, en parallèle, avant qu'aucun bloc n'existe. Le fold s'exécute une fois par bloc, dans l'ordre, et n'exécute jamais rien.

La conception repose sur deux univers qui peuvent partager un exécutable mais ne doivent jamais être confondus :

Les règles de consensus ne font que vérifier. Leur objet est qu'aucun utilisateur ne perde de fonds sans l'avoir autorisé, que personne ne débite un solde qu'il ne contrôle pas, et qu'aucun attaquant ne puisse vider, bloquer ou ralentir le réseau. La manière dont un séquenceur fonctionne, dont les séquenceurs communiquent entre eux et ce qu'ils facturent sont hors du consensus. Ce qui figure sur la chaîne, c'est le règlement : le paiement d'un séquenceur voyage à l'intérieur de l'intent que l'utilisateur a signé, et n'est payé que si le certificat s'applique.

Les sections suivantes définissent le certificat (§2), le fold (§3), l'accès typé à l'état (§4), les actifs natifs (§5), la machine virtuelle (§6), les séquenceurs (§7), le chemin forcé (§8), les deux marchés de frais (§9), le réseau (§10), la preuve d'enjeu (§11), la route au-delà de la vérification complète (§12), les risques acceptés (§13), la conformité (§14) et la relation avec la v1.0 (§15).

2. Certificats de transition d'état#

Le certificat est le seul type de transaction. Il est encodé en SSZ, ce qui donne un encodage canonique unique en octets ; le décodage impose la forme canonique, si bien qu'un certificat décodé est structurellement valide par construction et qu'aucune règle ultérieure ne recontrôle sa forme.

Deux condensés répondent à deux questions. L'id du certificat est le hash du certificat avec une liste de signatures vide : il nomme ce que le certificat autorise. Le hash d'exemplaire couvre l'encodage entier, signatures comprises : il nomme un ensemble d'octets. Les signatures restent hors de l'id parce que la signature est randomisée ; chaque nonce produit une autre signature valide sur le même corps, et un id qui les couvrirait donnerait à une même autorisation un nombre illimité d'identités facturables. L'id sert de clé à l'ensemble des vus, à l'ordre du fold et à toute déduplication. Un fill et un certificat forcé prennent le hash de leur intent comme id (§7, §8) ; l'offre d'un fill est scellée par la signature de son séquenceur. Le hash d'exemplaire est ce sur quoi s'engage la racine des certificats d'un bloc, si bien qu'un id de bloc détermine les octets que porte le bloc. L'offre de frais se trouve dans l'id et est signée : une offre hors de l'id est une offre que n'importe qui pourrait réécrire en transit. Chaque signature signe un message qui lie l'id de chaîne et la racine de consensus du jeu de paramètres, si bien qu'un certificat ne peut pas être rejoué sur un autre réseau.

La validité est sans état. Un certificat est valide lorsque, à partir de ses seuls octets :

1. il se décode de façon canonique, nomme cette chaîne, et chaque liste respecte sa limite ;
2. chaque signature se vérifie selon Ed25519 strict (encodages canoniques, clés sans torsion), et l'ensemble des signatures est minimal autant que suffisant ;
3. la réexécution du programme sur les lectures déclarées produit exactement les écritures déclarées ;
4. chaque écriture qui exige une autorisation la possède, et la cellule de dépôt porte une signature inconditionnellement ;
5. le dépôt est une cellule de solde natif d'une adresse utilisateur et couvre le pire cas du certificat ;
6. le certificat est cohérent avec lui-même : aucune écriture ne contredit une lecture du même slot, aucune adresse à usage unique débitée n'échappe au marquage comme dépensée, et aucune valeur n'est écrite vers une adresse dépensée ;
7. il n'écrit aucune cellule de protocole ;
8. chaque adresse qu'il nomme porte un octet de version défini ;
9. dans un contrat dont la clé de séquenceur est non nulle, le chemin à lecture exacte porte la signature de cette clé (§7), sauf dans un certificat forcé (§8) ;
10. une écriture de métadonnées déclare une lecture exacte de chaque cellule qu'elle écrase, à la valeur que la cellule détenait lorsque le certificat a été construit.

N'importe quelle machine contrôle cela : un pool de threads, un autre ordinateur, un GPU, sans base de données et sans synchronisation. Les vérifications de signature sont indépendantes les unes des autres ; elles peuvent donc être groupées d'un certificat à l'autre. C'est la propriété sur laquelle tout le reste est construit.

La validité ne suffit pas à l'exécution. Deux certificats valides peuvent déclarer la même valeur d'entrée pour le même slot ; un seul au plus peut prendre effet. La notion classique de validité d'une transaction est donc scindée en deux : valide (sans état, parallèle, contrôlé par quiconque) et applicable (avec état, séquentiel, décidé seulement par la position dans le registre). Un certificat invalide n'entre jamais dans un mempool honnête, et un certificat invalide inclus dans un bloc rend le bloc invalide.

3. Le registre comme fold#

Un bloc est un en-tête, une liste ordonnée de hashs d'exemplaires de certificats, et les corps des certificats eux-mêmes. Les corps sont des données de la chaîne : un bloc n'est valide que si ses corps sont disponibles. Le producteur d'un bloc n'exécute rien. Il ordonne des certificats qu'il a déjà vus validés, résout la preuve de travail [13] (ou, sous preuve d'enjeu, signe le slot pour lequel il a été tiré au sort, §11), et porte l'ensemble des ids de certificats vus dans la fenêtre du TTL, parce qu'en inclure un deux fois rend le bloc invalide.

L'état de la chaîne est un fold sur les certificats ordonnés. Pour chaque certificat, dans l'ordre, le fold réserve le dépôt, contrôle chaque lecture déclarée contre l'état courant, prépare les écritures avec une arithmétique contrôlée, puis valide ou omet :

• APPLIED — chaque lecture déclarée tient ; les écritures sont donc appliquées et les frais se règlent au coût réel.
• SKIPPED — une lecture ne tient plus (STALE), un delta sortirait de la plage [0, 2²⁵⁶) (OVERFLOW), ou une écriture tombe sous une adresse dépensée (SPENT). Rien n'est écrit. Des frais d'omission fixes sont brûlés sur le dépôt et le reste est restitué.
• FORCED_FAILED — un certificat forcé (§8) dont l'appel a échoué (revert) ou a enfreint ses bornes. Ses payeurs sont débités et brûlés, la monnaie revient à l'utilisateur, rien d'autre n'est écrit, et l'id est marqué comme vu.
• DROPPED — le certificat n'a pas pu être facturé du tout (la cellule de dépôt n'est pas approvisionnée ou est dépensée) ; il est donc porté, marqué comme vu et non facturé. Il ne rapporte rien à son producteur et lui coûte de la place sous le plafond. Un fill dans la même situation invalide au contraire le bloc (voir ci-dessous), parce que son rejet consommerait l'intent de l'utilisateur sans que personne soit payé.

Ordre canonique. Le fold ordonne les certificats d'un bloc en trois classes et ne laisse au producteur aucune latitude. D'abord les fills (§7), chacun pris dès que chaque pipeline dont il fait partie est prêt, les égalités étant départagées par (sequencer key, contract, seq, id). Puis tous les autres certificats, par (deposit address, Seq, id). Enfin les certificats forcés (§8), par id. Chaque nœud dérive un état identique d'une suite identique de blocs.

Les écritures sont contrôlées avant qu'aucune d'elles ne soit appliquée. Un crédit vers une adresse dont l'autorité a été brûlée échoue bruyamment au lieu de ressusciter la cellule ; un delta qui provoquerait un dépassement fait échouer le certificat entier. Le registre permanent des adresses dépensées existe précisément pour cela.

L'omission est une sémantique, non un échec. L'inclusion et l'application sont des événements distincts. Un producteur ne peut jamais produire un bloc invalide en incluant un certificat qui s'est révélé périmé ; le certificat est omis et le déposant paie. Le déposant a choisi les lectures ; c'est donc le déposant qui en répond.

Une signature, une facturation au plus. Les certificats appliqués comme omis sont marqués comme vus. Inclure un certificat déjà vu ou expiré, ou un certificat dont l'offre est inférieure aux frais de base du bloc dans l'un ou l'autre marché, rend le bloc invalide, si bien qu'aucun producteur ne peut réinclure ou retarder délibérément les certificats d'autrui pour en récolter les dépôts. Les TTL sont bornés par le consensus, si bien que l'ensemble des vus reste élagable.

Les conditions sans personne à facturer invalident le bloc. Certains échecs n'ont pas de coupable : un fill dont le compteur de séquenceur est hors d'ordre, dont le compteur fence (§7) a bougé, dont le payeur est déjà dépensé ou dont le dépôt ne peut être réservé ; un certificat forcé dont les lectures ne tiennent pas. Inclure un tel certificat rend le bloc invalide, et rien n'est facturé. Le producteur, qui a construit le bloc à partir d'un état qu'il détient, est la partie qui aurait pu le savoir.

Exactement un accès à l'état par certificat. Le fold effectue des comparaisons, des additions et des écritures sur un ensemble de travail clé-valeur chaud : aucune exécution de code, aucune vérification de signature, aucune réexécution, aucune arithmétique sur courbe elliptique. Tout cela a eu lieu en parallèle lors du contrôle de validité. L'id du certificat y est également calculé, puis transmis au fold.

L'égalité des valeurs, non des versions. L'applicabilité compare les valeurs de lecture déclarées, non des compteurs de version. Un slot qui a changé puis est revenu à sa valeur reste applicable, si bien que le système procède à une omission strictement moins souvent qu'un contrôle de concurrence fondé sur les versions.

Le prologue et l'épilogue propres au fold. Avant les certificats, à une frontière d'époque, le fold écrit les cellules de la balise (§4). Après eux, il répartit la subvention de bloc et fait tourner l'anneau de maturité du coinbase (document compagnon), enregistre le gas appliqué pour le régulateur de frais (§9) et, à une frontière d'époque, calcule la racine d'état de l'époque, qui doit être égale à celle de l'en-tête. Il ne renvoie une erreur qu'en cas d'invalidité du bloc ; un problème avec un certificat est un résultat, jamais une erreur.

4. Cellules et accès typé à l'état#

Une cellule est la valeur à un slot (address, word) : un entier non signé de 256 bits, gros-boutiste sur 32 octets. Les cellules absentes se lisent comme zéro. À côté des cellules, le protocole tient un registre des adresses dépensées, un ensemble permanent d'adresses à usage unique dont l'autorité de signature a été brûlée.

Une adresse est version ‖ blake3(tag ‖ version ‖ payload)[:31], sauf l'adresse du protocole, qui est l'octet de version 0x00 suivi de zéros :

Usage unique ou persistance est une politique de portefeuille exposée comme un bit de l'adresse, non deux registres [7]. Les portefeuilles utilisent par défaut une adresse à usage unique fraîche par paiement entrant, si bien que payer une adresse nouvellement dérivée est le chemin rapide sans contention, et qu'une cellule dépensée est compactable dès que le bloc qui l'a dépensée est enfoui au-delà de l'horizon d'annulation. Qui veut un compte utilise la version persistante. Les récompenses de minage ont leur place à une adresse persistante : le consensus accepte l'une ou l'autre sorte comme adresse de paiement, mais une adresse à usage unique brûle chaque récompense qu'elle détient au moment où elle est dépensée, et le nœud en refuse une pour cette raison.

C'est de l'accès typé que vient le parallélisme. Un fold qui ne prendrait en charge que des lectures exactes sérialiserait tout contrat populaire : mille certificats touchant une même réserve donneraient une application et 999 omissions. Au lieu de cela, une lecture déclare comment elle contraint une cellule, et une écriture déclare ce qu'elle lui fait :

Seul EXACT devient périmé. Un nombre quelconque de débits et de crédits gardés sur un même slot commutent : ils s'appliquent dans n'importe quel ordre, et une omission ne survient que lorsqu'une garde échoue réellement (un vrai découvert), non lorsque le solde a simplement changé. Une discipline par slot et par certificat : un set et un delta ne coexistent pas sur le même slot. La règle qui garde le modèle cohérent est que les valeurs gardées ne s'écoulent jamais dans le calcul : une assertion ne renvoie rien et un delta ne lit rien, si bien que la réexécution reste une fonction pure des lectures exactes déclarées. Cette seule discipline couvre les transferts, les frappes à offre plafonnée, les autorisations, les pourboires et les parts de coffre, soit l'écrasante majorité des écritures sur la chaîne. La filiation est celle des transactions de séquestre, du transactional boosting et des CRDT [8][9][10] ; Zycord fait de la commutativité le contrat de concurrence entre les nœuds.

Cellules à usage unique. Une adresse qui n'est jamais apparue sur la chaîne est dans l'état ∅ ; une première écriture la fait passer à stockée ; le certificat qui la marque comme dépensée, signé par sa clé, la fait passer à dépensée, définitivement. L'entrée du registre qui consigne la dépense n'est jamais compactée : c'est elle qui empêche l'adresse d'être ressuscitée.

Zéro est absence. Un slot jamais écrit et un slot écrit à zéro sont le même slot : écrire zéro supprime la cellule. C'est une exigence de consensus. Elle permet à une garde ou à une lecture exacte de nommer 0 sans se demander si le slot existe, et elle garde la racine d'état fonction de l'état et non de l'historique qui l'a produit.

La balise d'époque. Les programmes ne doivent pas lire directement des valeurs ambiantes. Le protocole écrit la hauteur de l'en-tête qui a ouvert l'époque courante et, à partir de l'ère de la machine, son heure, dans des cellules réservées, une fois par époque, et les programmes les lisent comme n'importe quel autre slot. Cela donne la conscience du temps sans péremption à chaque bloc ; les deux valeurs sont constantes pendant toute l'époque, soit un jour sur le mainnet : 2 880 blocs sous preuve de travail, 17 280 sous preuve d'enjeu (§11).

5. Des actifs sans machine#

L'ère de lancement a besoin d'une économie avant d'avoir besoin d'un ordinateur. Zycord fournit des actifs natifs sous forme d'opérations de certificat dès le bloc 0, sans aucune machine virtuelle :

• TRANSFER — jusqu'à 32 mouvements (asset, from, to, amount) dans un même certificat, dans ses limites de lectures et d'écritures, chacun étant une garde balance ≥ Δ associée à deux deltas. Un crédit visant un delta pur ou une cellule à usage unique fraîche est le pourboire, si bien que le pourboire n'a besoin d'aucun opcode propre. Une adresse de contrat ne peut être créditée qu'en pièce native, et jamais l'adresse d'un précompilé (§6), dont rien ne pourrait faire ressortir la valeur.
• ISSUE — crée un id d'actif avec un plafond d'offre dans une cellule à écriture unique.
• MINT — gardé : minted + Δ ≤ cap.
• RETIRE — brûle jusqu'à 64 adresses à usage unique, chacune autorisée par son propriétaire et dans les limites du certificat, sans déplacer de valeur : aucune lecture, une écriture pure qui marque chaque cellule comme dépensée. La dépense proprement dite est automatique à l'intérieur d'un transfert. La mise au rebut est la primitive de compaction et de confidentialité : le bénéficiaire efface une adresse à usage unique une fois qu'elle a servi.

Un streameur recevant dix mille pourboires dans un même bloc coûte au fold dix mille additions commutatives : zéro conflit, zéro omission, pas de séquenceur, pas de machine. Le calendrier d'offre de la pièce native et le plafond de chaque actif émis vivent ici, imposés par l'arithmétique contrôlée du §3.

Un paiement se règle ainsi. Le portefeuille de l'expéditeur choisit une cellule à usage unique qu'il détient, déclare une garde sur elle, la débite, la marque comme dépensée, crédite l'adresse à usage unique fraîche du destinataire et envoie la monnaie rendue vers une adresse à usage unique fraîche qui lui appartient. Deux certificats en concurrence pour dépenser la même cellule à usage unique via deux nœuds différents sont tous deux valides ; exactement un s'applique, et l'autre est omis et facturé au dépôt qu'il a désigné.

6. La machine : cEVM#

Zycord exécute une seule machine virtuelle, la cEVM, un dialecte de la machine virtuelle d'Ethereum [2] adapté aux certificats. Le choix est délibéré : le budget de nouveauté du projet est dépensé sur le modèle d'état, de concurrence et économique, et la machine devrait être la chose la plus familière du système. Solidity, ses compilateurs, ses auditeurs et son outillage se transposent. Toute la divergence du dialecte tient en une liste de suppressions, deux reliaisons, six ajouts et quatre retarifications.

Le stockage est déclaré, non découvert. Un certificat porte les lectures que son exécution a consommées et les écritures qu'elle a produites, et la validité les compare à une réexécution. Quatre familles d'opcodes atteignent une cellule : SLOAD et SSTORE dans la discipline exacte, et les familles d'assertion et de delta dans la discipline commutative. Une frame appelée peut ajouter au plus 16 entrées à l'ensemble déclaré, si bien qu'un appelé ne peut pas épuiser les limites dont son appelant a besoin ; l'entrée qui dépasserait ce nombre fait avorter cette frame et aucune autre.

Ajoutés, sur des octets qu'aucun fork de l'EVM n'a jamais attribués : SASSERTGE 0x21, SASSERTLE 0x22, SASSERTEQ 0x23, SDELTAADD 0x24, SDELTASUB 0x25, SETSEQ 0x26. Le prédicat et le signe sont dans l'opcode, jamais sur la pile. Une garde ne renvoie rien, si bien qu'aucune branche ne peut dépendre du fait qu'elle tienne ; le net d'un delta est pris sur les entiers et jamais modulo 2²⁵⁶. SETSEQ(key) fixe la cellule de séquenceur du contrat dont le contexte s'exécute et d'aucun autre ; une clé nulle ou malformée est un échec de dérivation qui invalide le certificat entier.

Reliés : NUMBER et TIMESTAMP répondent à partir de lectures exactes des cellules de la balise d'époque, si bien que tous deux sont constants pendant toute l'époque, et qu'un contrat porté qui utilise block.timestamp pour une échéance décide par rapport à une heure qui peut dater de 24 heures.

Supprimés (13) : BLOCKHASH, COINBASE, PREVRANDAO, GASLIMIT, BLOBHASH [14], BLOBBASEFEE, SLOTNUM n'ont pas de référent ; GASPRICE et BASEFEE nomment des cellules par bloc dont la lecture exacte est périmée par construction ; BALANCE et SELFBALANCE forceraient une lecture exacte d'un solde natif ; ORIGIN n'a aucun expéditeur à nommer ; SELFDESTRUCT permettrait à une cellule de hash de code de revenir à zéro.

Retarifés : SLOAD et SSTORE sont forfaitaires au coût d'accès chaud ; la surcharge d'accès froid est supprimée partout ; KECCAK256 passe à 720 gas plus 144 par mot, mesuré par rapport à l'implémentation propre de cette machine, la seule retarification qui augmente un coût. Les opcodes d'assertion et de delta coûtent le même montant d'accès chaud que SLOAD.

Les précompilés forment un ensemble fermé de cinq : sha256, identity, modexp, ed25519_verify et blake3.

Deux compteurs. Le gas séquentiel est dérivé des nombres déclarés de lectures, d'écritures et d'entrées de registre, et n'est jamais mesuré par la machine. Le compteur parallèle est ce que l'interpréteur compte, contre un budget que le certificat déclare en unités de dérivation ; le dépasser à la profondeur 0 invalide le certificat.

Le code voyage dans le certificat. Le code d'un contrat vit dans une cellule de hash de code à écriture unique ; il n'y a donc pas de redéploiement, et un déploiement est un appel dont la cible est nulle. L'image d'exécution est transportée dans le certificat et résolue par une lecture exacte déclarée de la cellule de hash de code, jamais par la seule adresse. Un blob fait au plus 24 576 octets.

L'enregistrement d'un contrat se compose de cinq cellules : le hash de code, le déployeur, la clé de séquenceur, l'administrateur et le compteur fence (§7). La cellule d'administrateur contient une adresse ; zéro signifie que le déployeur est l'administrateur, et 32 octets de 0xff signifient que le rôle a été abandonné, de manière irréversible. L'administrateur fixe la clé de séquenceur au moyen d'un certificat d'enregistrement et transmet ou abandonne le rôle au moyen d'un certificat set-admin ; tous deux déclarent des lectures exactes des cellules de déployeur et d'administrateur, si bien qu'un certificat émanant d'un administrateur remplacé ou ayant renoncé est omis. Le code d'un contrat ne fixe jamais d'administrateur ; il déplace son propre séquenceur avec SETSEQ, et c'est aussi ainsi qu'un contrat créé par une fabrique en obtient un.

La bibliothèque standard. Un jeton, un pot à pourboires et un séquestre, écrits en priorité delta, sont pré-déployés à des adresses connues dans le bloc qui active la machine, avec l'enveloppe delta qu'ils appellent. Un contrat Ethereum porté qui évite les opcodes et précompilés supprimés fonctionne correctement dès le premier jour en mode tout-exact, sérialisé par un séquenceur s'il est chaud ; le parallélisme est optionnel par slot, typiquement un petit diff qui fait passer une table de soldes de load/store à assert/delta.

7. Séquenceurs#

Les deltas gardés dissolvent la contention des paiements. Ce qui reste est la logique à lecture exacte sur un état chaud, un carnet d'ordres, un teneur de marché automatisé, où deux utilisateurs honnêtes construisant contre la même cellule produiront encore une omission, et où des contrats qui lisent l'état pour décider quoi écrire ne peuvent pas être appliqués dans un ordre arbitraire. La réponse du protocole est de laisser le contrat choisir son sérialiseur.

Liaison. L'enregistrement de chaque contrat (§6) contient une clé de séquenceur. Un contrat dont la clé est non nulle est séquencé : un certificat ne peut lire de façon exacte, garder par égalité ou fixer l'une de ses cellules qu'avec la signature de cette clé. Un contrat dont la clé est nulle est ouvert : n'importe qui peut emprunter son chemin exact avec un certificat qui lui est propre, et le contrat n'est protégé que par son code. La clé est fixée au déploiement par le déployeur, plus tard par l'administrateur, ou par le propre code du contrat au moyen de SETSEQ, ce qui permet à une gouvernance de remplacer un séquenceur sans administrateur. La liaison peut nommer n'importe quelle clé ; une clé que personne ne sert n'est pas une erreur de consensus, le contrat est simplement inutilisable jusqu'à ce que quelqu'un la serve ou que le chemin forcé (§8) la change. Les deltas gardés commutent et ne sont jamais soumis à une porte, si bien qu'un jeton séquencé accepte toujours chaque transfert de quiconque.

L'annuaire. Un séquenceur annonce où son service répond au moyen d'un certificat d'annuaire : sa clé et une chaîne de 1 à 256 octets d'ASCII imprimable, typiquement une URL, annoncée depuis une adresse persistante. L'entrée expire 90 jours après le TTL du certificat d'annonce sauf renouvellement, et un certificat de retrait la supprime immédiatement. Le consensus stocke la chaîne et ne l'interprète jamais. L'annuaire est de la découverte, non de l'autorisation : les portefeuilles le lisent pour savoir à qui s'adresser.

Intents. Un utilisateur ne construit pas de certificat contre un contrat séquencé. L'utilisateur signe un intent : la cible et les calldata, un budget parallèle, un nonce, une fenêtre allant de NotBefore au TTL avec TTL − NotBefore d'au plus 8 blocs, l'adresse persistante du séquenceur, un ensemble de bornes sur le résultat, le paiement dû au séquenceur, les paiements dus aux éventuels co-séquenceurs, des payeurs à usage unique qui financent le tout, et des sorties de monnaie. Une borne est un prédicat sur une cellule que l'appel écrit, final-at-least, final-at-most, delta-at-least ou delta-at-most, et au moins une borne doit nommer un slot que l'appel a écrit. L'intent est toute l'autorisation de l'utilisateur ; le séquenceur ne peut pas changer ce qu'il fait, seulement le moment.

Fills. Le séquenceur exécute l'intent sur sa propre vue de l'état, la pointe de la chaîne plus chaque fill qu'il a déjà construit, et publie le résultat sous forme de fill : un certificat dont le programme est l'intent, dont le dépôt provient du solde persistant propre au séquenceur, et dont l'id est le hash de l'intent, si bien que deux fills d'un même intent partagent un id et qu'un seul peut être facturé. Le séquenceur n'est digne de confiance que pour la vivacité, jamais pour la sûreté : s'il ment sur les entrées, le fill est simplement omis face au fold canonique, et le mensonge coûte le dépôt du séquenceur, non les fonds de l'utilisateur.

Reçus. Un séquenceur répond à un intent signé en quelques millisecondes, bien avant qu'un bloc n'existe : il exécute l'intent, signe le fill, et renvoie au portefeuille le fill, ou un reçu signé qui nomme l'id de l'intent, le seq du pipeline et le résultat. C'est une pré-confirmation. C'est la promesse du séquenceur et non celle de la chaîne ; elle devient définitive lorsque le fill s'applique. Parce que chaque reçu est signé, une mauvaise conduite constitue une preuve : deux reçus d'une même clé qui donnent un même seq à des intents différents, ou des résultats différents à un même intent, sont une preuve que chacun peut vérifier à partir des octets. Le consensus ne le punit pas. Le marché le fait. Le format, le prix, l'identité et la réputation des reçus sont hors chaîne et libres par conception, si bien que les utilisateurs choisissent entre un séquenceur moins cher, un séquenceur publiquement identifié ou un séquenceur anonyme, et quittent celui qui est pris en flagrant délit de double signature.

Pipelines. La chaîne conserve, pour chaque paire (sequencer key, contract), le dernier seq appliqué. Un fill déclare un seq pour chaque pipeline dont il fait partie et ne peut entrer que lorsque le compteur se trouve à seq − 1 ; les compteurs n'avancent que lorsque le fill s'applique. Un fill omis laisse donc son compteur là où il était : les fills construits derrière lui ne peuvent pas entrer, et le séquenceur reconstruit à partir du même numéro. Deux fills au même seq : le premier dans l'ordre du fold entre, le second ne le peut pas. Le pipeline d'un séquenceur se valide dans l'ordre où il l'a signé, quel que soit l'ordre dans lequel un producteur l'a reçu, et un producteur qui mêle les pipelines de plusieurs séquenceurs n'a aucun choix sur le résultat.

Le compteur fence. Chaque contrat conserve un compteur, fid, dans son enregistrement. Un fill déclare le fid de chaque contrat qu'il lit de façon exacte ou dont il fixe une cellule ; une non-concordance signifie que le fill ne peut pas entrer. Le compteur avance de un lorsqu'un certificat forcé (§8) qui s'applique fixe une cellule du contrat, et lorsque la cellule de séquenceur du contrat est écrite. Une lecture ou un delta ne le fait pas avancer : une lecture ne change rien, et un delta commute avec tout ce qu'un fill garde ou modifie par delta. Un fill qui lit de façon exacte une cellule que d'autres font bouger par delta répond de cette lecture comme n'importe quel certificat, et son séquenceur paie l'omission si la cellule a bougé. C'est ainsi que le chemin forcé et un changement de séquenceur invalident chaque fill construit sur l'état qu'ils ont contourné, sans que personne soit facturé : le séquenceur voit le fence bouger, reconstruit et republie, ne perdant que de la latence.

Coséquençage. Un appel qui traverse des contrats liés à des séquenceurs différents arrive sur la chaîne comme un unique fill portant la signature de chaque séquenceur dont il touche le chemin exact, dans la limite de 16 signatures par certificat, chacune décomptée du plafond de signatures du bloc et en gas parallèle, chacune avec un seq dans son propre pipeline, chacune payée de ce que l'intent lui attribue. La coordination, qui mène, comment se font les réservations, ce que chacun facture, est hors chaîne et libre par conception ; la chaîne voit un seul certificat, atomique par construction. Un fill conjoint qui n'est jamais publié ne bloque que les pipelines dont il fait partie ; une fois sa fenêtre passée, chaque signataire réutilise le numéro qu'il a signé.

Qui paie une omission. Lorsqu'un fill entre et qu'une lecture est périmée ou qu'une écriture déborde, rien n'est écrit, personne n'est payé, et celui qui s'est trompé paie les frais d'omission : la première lecture ou écriture qui a échoué dans l'ordre du certificat décide, et la facture va au séquenceur qui s'est déclaré pour ce contrat si le contrat se trouve sur le chemin exact du fill et que l'enregistrement de la chaîne concorde ; dans tous les autres cas, elle va au chef de file, le séquenceur dont le fill nomme le dépôt. Chaque séquenceur listé dispose d'une réserve prélevée à la position du fill précisément pour cela. L'utilisateur ne paie jamais une omission. Le paiement de l'utilisateur à chaque séquenceur ne se règle que si le fill s'applique.

Ce qu'est un séquenceur. Un serveur ordinaire exploité par l'équipe de l'application, avec la mécanique qu'elle préfère : un processus unique, un rollup, une fédération. Il voit en premier le flux d'ordres de son application et est donc le lieu naturel de la valeur extractible de cette application ; la conception le rend explicite et permet à l'application de capter cette valeur au lieu de la laisser fuir vers les producteurs de blocs, tandis que le chemin forcé borne le pouvoir que cela implique. Des contrats lourds deviennent viables, la cryptographie, toute la logique d'un jeu, un système entier dans un seul contrat, parce que l'exécution lourde a lieu hors chaîne lors de la construction et que la chaîne la vérifie en parallèle. La construction est un marché concurrentiel : un séquenceur moins cher ou plus fiable attire les utilisateurs, et chaque nœud qui propose la construction ajoute de la capacité.

8. Le chemin forcé : l'inclusion est l'application#

Un contrat dont l'unique porte est son séquenceur est une prison si le séquenceur censure, surfacture ou disparaît. Chaque utilisateur dispose donc d'un chemin lent qui n'exige la permission de personne.

L'utilisateur signe un intent ouvert : un intent exactement comme au §7, sans séquenceur nommé et sans co-séquenceurs, financé par les propres payeurs à usage unique de l'utilisateur, et le relaie au réseau. Il circule dans le mempool en tant qu'intent, non en tant que certificat. Le producteur de blocs, qui détient l'état complet et a déjà réglé chaque certificat ordinaire du bloc, calcule l'état de fin de bloc et exécute contre cet état les intents ouverts qu'il choisit, dans l'ordre des ids d'intent, en ajoutant les certificats forcés qui en résultent comme derniers certificats du bloc. L'id d'un certificat forcé est le hash de son intent, comme celui d'un fill. L'inclusion est l'application : il n'y a ni file, ni bail, ni quota, ni échéance. Un certificat forcé dont les lectures déclarées ne tiennent pas contre l'état où il a été placé ne peut pas du tout entrer dans le bloc ; c'est le producteur qui l'a construit, si bien que c'est le producteur qui est la partie qui aurait pu le savoir.

Borné par construction. Un bloc porte au plus 16 certificats forcés, et chacun déclare au plus 4 000 unités de dérivation de budget parallèle (200 000 gas de machine). Chaque sortie qu'offre un contrat, retrait, annulation, mise au rebut, transfert, doit tenir dans ce budget ; la règle pour les auteurs de contrats est qu'un retrait tient dans le budget forcé. À pleine occupation, le chemin forcé prend un tiers du plafond parallèle de genèse et le trafic ordinaire garde le reste.

Un appel qui échoue atterrit tout de même. Un certificat forcé dont l'appel échoue (revert), enfreint ses bornes ou épuise son gas entre sous sa forme en échec, FORCED_FAILED : ses payeurs sont débités et brûlés, la monnaie revient à l'utilisateur, l'id est marqué comme vu, et rien d'autre n'est écrit. La validité n'accepte la forme en échec que lorsque la réexécution de l'appel sur les lectures déclarées échoue effectivement. C'est ce qui rend le chemin résistant aux abus : un attaquant qui relaie des intents ouverts qui ne peuvent pas réussir paie pour chacun d'eux, et un utilisateur dont l'intent est sain ne peut pas être affamé par eux, parce que le producteur est payé pour ce qu'il inclut et préfère l'excédent.

Le fence. Un certificat forcé qui s'applique et fixe une cellule d'un contrat fait avancer le compteur fence de ce contrat (§7), si bien que chaque fill construit sur l'état qu'il a changé ne peut pas entrer. Un certificat forcé qui ne fait que lire un contrat séquencé, de façon exacte ou au moyen de gardes, ou qui n'y fait que déplacer des deltas, laisse le fence intact, de même qu'un certificat qui atterrit sous sa forme en échec ; les fills en attente entrent toujours, et seul celui qui a lu de façon exacte une cellule que le certificat forcé a fait bouger est omis (§7). Le séquenceur perd de la latence, rien de plus, et un utilisateur qui force une transaction par bloc sur un contrat chaud paie chaque fois le prix forcé.

Paiement. Le paiement de l'intent couvre les frais du certificat aux frais de base du bloc ; la part correspondant aux frais de base est brûlée et le reste rejoint les pourboires du producteur. Le producteur reçoit ce que recevrait un séquenceur.

Aucun état n'est orphelin. Un contrat dont le séquenceur a disparu reste vivant grâce à ses méthodes delta, qui n'ont besoin d'aucun séquenceur, et grâce au chemin forcé, par lequel ses utilisateurs se retirent et par lequel son propre code, ou l'administrateur, peut appeler SETSEQ ou un enregistrement et le lier à un nouveau séquenceur. La censure s'inverse : elle coûte au censeur, en frais perdus et en utilisateurs qui le contournent, et ne coûte rien au réseau. Aucun opérateur ne porte la sûreté.

9. Deux marchés : gas séquentiel et gas parallèle#

Une chaîne consomme trois ressources appartenant à des classes de passage à l'échelle différentes, données, vérification et mutation, et les tarifer sur un marché unique revient à faire concourir en enchère une vérification de signature avec une écriture en mémoire. Zycord scinde les frais en deux marchés indépendants, chacun avec sa propre cible, son propre plafond et ses propres frais de base tenus dans l'état de consensus :

Le gas séquentiel tarifie la mutation d'état, la ressource rare, l'unique boucle que chaque nœud exécute dans l'ordre. Le gas parallèle tarifie la vérification, qui croît avec chaque cœur et chaque GPU qui rejoint le réseau, et son plafond est fixé haut et bon marché. La conséquence est un objectif de conception énoncé comme un invariant : la cryptographie lourde n'a pas d'impact sur le réseau, par construction économique. Un certificat qui vérifie une grosse preuve mais n'écrit que deux slots paie presque tout sur le marché bon marché.

Les deux marchés ont la forme d'EIP-1559 [12], chacun dans sa propre unité : les frais de base sont brûlés et les frais de priorité paient le producteur, sur les certificats qui s'appliquent, et sur eux seuls. Les frais d'un certificat omis sont brûlés en totalité et ne paient personne. C'est la règle porteuse du modèle économique. Si une omission rapportait un pourboire, la partie qui choisit le contenu d'un bloc serait payée pour organiser les échecs d'autrui. Le brûlage inverse cela : une omission consomme de la place sous le plafond et ne rapporte rien, si bien qu'un producteur qui maximise son revenu maximise l'application et s'oppose activement à provoquer des omissions.

Seul le gas appliqué fait bouger les frais de base. Trois quantités sont comptées par bloc : le gas inclus (chaque certificat, quelle que soit son issue) borne les plafonds ; le gas appliqué (seulement ce qui s'est appliqué) fait bouger les frais de base ; les octets du bloc bornent le plafond d'octets. Une omission est une tentative ratée d'utiliser la chaîne, non la preuve d'une demande pour elle ; si le gas inclus faisait bouger les frais, un nuisible pourrait remplir les blocs de certificats en conflit avec eux-mêmes au prix des frais d'omission fixes et évincer tout le monde par les prix à coût constant.

Le plafond séquentiel est élastique. La cible séquentielle T est un état de consensus dès le bloc 0, non une constante, et un contrôleur d'époque la fait évoluer :

• Au sein d'un bloc, le plafond souple est 2T et la limite stricte est 4T. Un producteur qui fait une pointe entre les deux renonce à une part quadratique de son propre revenu, une partie de la subvention plus les frais du bloc, et jamais à la part de quelqu'un d'autre.
• D'une époque à l'autre, T suit la demande : deux fois la médiane inférieure du gas appliqué dans l'époque, contrainte entre T − T/1024 et T + T/512, avec pour plancher la valeur de genèse et pour plafond la capacité de genèse (document compagnon). La croissance est retenue lorsque le contrôle de santé indique que le réseau n'est pas en bonne santé : des en-têtes concurrents cités au-dessus de 2 % des blocs de l'époque.
• Le nombre de certificats, le nombre de signatures et la limite d'octets évoluent avec T à partir de leurs valeurs de genèse, jusqu'à des capacités statiques (2²⁵ certificats, 8 MB).

Les certificats omis brûlent leurs frais et ne comptent pour rien, si bien que la seule manière de relever le plafond est d'obtenir l'application : un usage soutenu, sans conflit, qui brûle des frais de base. Forcer la croissance coûte à un attaquant exactement ce que l'adoption organique coûte à tous les autres. Le marché parallèle n'a besoin d'aucune de ces précautions : sa cible et son plafond sont fixés à un multiple constant, 3×, de la cible et du plafond séquentiels, soit 3T et 6T, et héritent de leur croissance. La filiation est la médiane de pénalité de Monero [15] et les travaux sur les limites adaptatives [16].

La marge de construction. Le même marché parallèle rémunère les séquenceurs pour leur travail de mise en forme : un séquenceur qui agrège de nombreuses transactions dans un seul certificat paie une seule offre parallèle pour celui-ci et facture ses utilisateurs par transaction, à l'intérieur de l'intent.

10. Réseau#

Les corps sont des données de la chaîne. Les corps de certificats d'un bloc doivent être récupérables pour que le bloc soit valide, si bien que l'état est toujours reconstructible à partir de la seule chaîne et qu'aucun opérateur, séquenceur compris, n'est jamais dépositaire de données. Les certificats sont plus gros que des transactions classiques parce qu'ils portent leurs lectures et leurs écritures ; les atténuations sont structurelles : les fills court-circuitent les écritures internes, les cellules à usage unique dépensées se compactent une fois enfouies au-delà de l'horizon d'annulation, et un nœud peut élaguer les corps en dessous d'un plancher qu'il annonce à ses pairs.

Transport. TCP, puis TLS 1.3 avec des identités de pairs Ed25519 dans des certificats auto-signés : le canal est lié à une clé, et rien de plus n'est affirmé. Chaque message est une trame de 5 octets, longueur et type, et la longueur est contrôlée par rapport au plafond propre au type avant toute allocation. Un type qu'une version plus récente a ajouté est lu et ignoré dans une petite limite au lieu de fermer la connexion.

Le relais se fait d'abord par hash. Les certificats circulent en gossip indépendamment et sont contrôlés pour leur validité, sans état et en parallèle, à leur arrivée. Un nœud relais n'a besoin d'aucun état pour borner le coût du filtrage du spam : la validité sans état est vérifiable à partir des octets, et un nœud qui détient l'état refuse aussi un certificat que son dépôt ne peut pas couvrir. Le relais traite des exemplaires, non des ids : un certificat dont les signatures échouent coûte à cet exemplaire, et rien n'est consigné contre l'id, parce qu'un exemplaire ultérieur de la même autorisation peut être bon. Les blocs sont relayés sous forme d'en-têtes plus des listes de hashs confrontées au mempool [11], si bien que la latence de propagation ne croît pas avec le contenu des blocs, et le destinataire vérifie le travail de l'en-tête avant de récupérer le moindre corps.

La synchronisation choisit selon le travail vérifié. Un nœud qui rattrape son retard préfère le pair dont les en-têtes ont effectivement prouvé le plus de travail au pair qui annonce la plus grande hauteur. Les en-têtes sont validés en tant que chaîne avant que les corps ne soient récupérés ; une branche concurrente n'est adoptée que si elle se raccorde dans l'horizon d'annulation et porte plus de travail que la chaîne qu'elle remplace (sous preuve d'enjeu, plus de slots, §11). Les points de contrôle fixés, intégrés à la version et acceptés seulement lorsqu'un bloc est vieux d'au moins une époque, refusent une chaîne contradictoire, quel que soit son poids, comme défense de l'ère de lancement contre la réécriture de l'historique ; un opérateur peut ajouter un point fixe par option.

Les pairs sont notés, par identité : un message invalide coûte 20, une violation de protocole 50, un corps non servi 10, une requête excessive 5 ; un message utile rapporte 1 ; un pair est banni à −100. Les contrôles coûteux, époques de clés et évaluations de preuve de travail, sont budgétés par pair et remboursés lorsque le bloc se révèle utile, si bien qu'un attaquant ne peut pas faire moudre du travail à un nœud sur des annonces qui ne mènent nulle part.

Citations. Un en-tête peut citer jusqu'à quatre en-têtes concurrents récents à la hauteur de son parent, sans rémunération : citer exige une véritable preuve de travail, tandis que supprimer le signal exigerait que presque tous les producteurs l'omettent. Le taux de forks cité est le signal de santé que lit le régulateur de frais (§9).

L'interface du nœud. Les lectures sont servies en HTTP, liées à localhost par défaut ; la soumission de certificats, d'intents ouverts et de cartes de service signées constitue les seules écritures. Les lectures sont limitées en débit par client, avec un jeton de confiance pour exempter les propres outils de l'opérateur. Un point d'accès Stratum, dans le dialecte que parlent les mineurs CPU courants, permet à un nœud de miner avec un logiciel externe.

11. Preuve d'enjeu#

Cette section spécifie le consensus de l'ère au cours de laquelle la production de blocs passe de la preuve de travail à l'enjeu. Les règles des §2 à §10 tiennent inchangées sauf là où cette section en dispose autrement ; le calendrier et chaque valeur se trouvent dans le document compagnon. Les constantes marquées ouverte sont fixées par la version de l'ère.

Ce qui change. Deux choses. Le droit de produire le bloc suivant, que la preuve de travail vend contre des hashs, est tiré au sort selon l'enjeu ; et l'intervalle entre blocs passe de 30 à 5 secondes. Tout le reste demeure : chaque règle de validité du §2 est contrôlée par chaque nœud, pour chaque certificat, à partir des octets ; le fold est le même ; les deux marchés de gas sont les mêmes ; un certificat invalide à l'intérieur d'un bloc rend le bloc invalide. La règle de citation du §10 demeure, avec la signature de slot de l'en-tête cité à la place de son travail. La surface qu'ouvre cette ère est celle d'une preuve d'enjeu, et aucune autre.

Où va le calcul. Un mineur en preuve de travail dépense du calcul en hashs, qui achètent la sécurité et rien d'autre. Un producteur de cette ère dépense le même calcul en vérification : contrôler les signatures, réexécuter les programmes, dériver les certificats, en parallèle, avant de les ordonner. Le travail que le réseau paie devient le travail dont le réseau a besoin. Un ordinateur ordinaire vérifie des milliers de certificats par bloc ; un producteur doté de plus de cœurs suit le rythme à mesure que le volume croît. La vérification parallèle place le plafond bien au-dessus de ce que consomme la boucle séquentielle ; ce qui se trouve au-delà est au §12.

Enjeu. Un participant engage de la pièce native au moyen d'une opération native, BOND, qui déplace un solde d'une adresse persistante vers une cellule d'enjeu liée à cette adresse. Les cellules d'enjeu sont des cellules de protocole : le certificat autorise le mouvement et le fold effectue l'écriture, comme il le fait pour les compteurs de séquenceur. La clé de cette adresse est la clé qui signe les blocs. Un enjeu devient actif une époque après son engagement, si bien que des enjeux ne peuvent pas être créés et abandonnés en série ; UNBOND restitue le solde après un délai plus long que l'horizon d'annulation. Le minimum est fixé par le document compagnon. Une clé, un enjeu.

Le tirage. Les blocs occupent des slots d'un intervalle fixe. Pour chaque slot, un producteur est tiré au sort parmi l'ensemble des enjeux actifs à l'ouverture de l'époque, avec une probabilité proportionnelle à l'enjeu, à partir d'une graine que la chaîne a fixée pendant l'époque précédente et écrite dans les cellules de la balise (§4) ; la graine ne doit pas pouvoir être biaisée par les producteurs des blocs qui la fixent. L'en-tête porte le slot et la signature du producteur tiré au sort à la place de la preuve de travail ; un en-tête signé par une autre clé, ou hors de son slot, est invalide. Un slot sans bloc reste vide, et le producteur tiré au sort suivant construit sur le dernier bloc qu'il connaît. Le tirage est une fonction d'un état fixé avant l'ouverture de l'époque, si bien que chaque nœud le dérive seul, et qu'aucun message de consensus n'est échangé en dehors du bloc lui-même. La filiation est la loterie des slot leaders d'Ouroboros [17] et le calendrier des leaders par époque de Solana [21] ; cacher le leader derrière une fonction aléatoire vérifiable [31], comme le fait Praos [18], est l'alternative si le déni de service contre des producteurs connus devient un problème.

Choix de la chaîne. Là où le §10 choisit selon le travail vérifié, cette ère choisit selon la longueur : parmi les chaînes valides, celle qui occupe le plus de slots [17] ; entre deux de même longueur, celle dont le premier bloc après le fork se trouve dans le slot le plus ancien. L'horizon d'annulation et les points de contrôle fixés du §10 demeurent et sont la défense contre la réécriture avec des clés désengagées depuis : un nœud qui rejoint le réseau accepte l'historique que fixe sa version, et aucune chaîne plus longue ne le contredit.

Récompense. La subvention de bloc et les frais de priorité vont au producteur tiré au sort, comme ils allaient au mineur, par le même anneau de maturité ; la part brûlée reste brûlée. Le revenu attendu d'un participant est proportionnel à son enjeu, et le coût de sa collecte est la vérification des certificats qu'il inclut. Un bloc invalide est rejeté et ne paie rien à celui qui l'a signé.

Double signature. Une seule faute est punie par le consensus : deux en-têtes signés par une même clé pour un même slot. Comme un certificat invalide, c'est une preuve en un seul message, vérifiable par quiconque à partir des octets. Un certificat de signalement porte les deux en-têtes ; le fold brûle la propre caution du signataire, retire la clé de l'ensemble actif et verse à l'auteur du signalement une fraction ouverte. Un signalement est accepté jusqu'à ce que la sortie de l'enjeu soit achevée. Aucune autre conduite n'est punie par le consensus, et aucune conduite d'un producteur n'atteint la pièce de quelqu'un d'autre. Le précédent est le slashing des proposeurs sur la beacon chain d'Ethereum [19].

Pools. Un pool est un enjeu qui accepte la délégation. Toute adresse persistante peut engager une caution et, au moyen d'une opération native DELEGATE, faire pointer sa caution vers la clé d'un pool ; une caution qui ne fait que déléguer a un minimum inférieur à celui d'une caution qui produit. Le solde ne quitte jamais le délégateur, qui le redirige ou le désengage sous le même délai de sortie. Le poids d'un pool dans le tirage est sa propre caution plus ce qui lui est délégué. La récompense des blocs qu'un pool produit est répartie par le fold une fois par époque, hors du chemin par bloc, entre le pool, à une marge qu'il déclare lors de son enregistrement, et ses délégateurs, au prorata de l'enjeu. En cas de double signature, la propre caution du pool est brûlée et ses délégations reviennent à leurs délégateurs. La manière dont la vérification est partagée à l'intérieur d'un pool est l'affaire du pool : chaque membre vérifie la part qu'il reçoit, un même certificat peut aller à plus d'un membre, et l'opérateur rassemble les réponses, assemble le bloc et le signe avec la clé tirée au sort. Tout cela relève de la construction, hors du consensus et libre par conception (§1) : la chaîne voit une table de délégations, un en-tête signé par une clé, et un bloc dont chaque nœud complet vérifie à nouveau les certificats. Un petit nœud apporte les cœurs dont il dispose ; un détenteur qui n'a que de la pièce apporte de l'enjeu. La filiation est celle des stake pools de Cardano [20], qui elles non plus ne sanctionnent jamais les délégateurs.

La rampe. L'ère entre en vigueur en trois étapes, chacune étant une règle de consensus.

1. Engagement. BOND, UNBOND et DELEGATE sont acceptés. La preuve de travail continue de produire chaque bloc et de recevoir toute la part du producteur.
2. Rampe, sur 90 époques. Chaque bloc est encore miné, et porte la signature de l'enjeu tiré au sort pour sa hauteur, dans l'en-tête, hors de la préimage de la preuve de travail ; l'id du bloc la couvre, si bien qu'un bloc signé et sa copie non signée sont deux blocs, et qu'à travail égal le bloc signé l'emporte. Le choix de la chaîne se fait encore selon le travail, et deux signatures à une même hauteur ne constituent pas une double signature. La part de la subvention revenant au producteur est partagée entre le mineur et le staker : un compteur k commence à 1 et augmente de un à chaque époque qui franchit la porte, et le staker touche k/180, si bien que le travail en garde au moins la moitié jusqu'à la bascule. Un bloc porté sans la signature est valide et ne paie personne : la part de la subvention revenant à son producteur et ses frais de priorité sont brûlés, si bien qu'un mineur ne gagne rien à écarter le staker, et qu'un staker ne gagne rien à être absent. Une époque franchit la porte lorsqu'au moins 90 % de ses blocs ont porté la signature et que l'enjeu actif, délégations comprises, détenait au moins 10 % de l'offre. La rampe démarre lorsque l'enjeu actif atteint 10 % de l'offre pendant 30 époques ou, au plus tard, à l'époque que fixe le document compagnon, avec l'enjeu qui existe alors. Aucun bloc n'est produit par l'enjeu seul avant que l'enjeu n'ait signé, en production, neuf blocs sur dix pendant 90 époques. Le précédent est l'hybride de Decred, dans lequel les blocs minés portent des votes d'enjeu et la subvention est partagée entre les deux [22], et la Merge, pour laquelle l'enjeu a fait tourner sa propre chaîne pendant près de deux ans avant de prendre en charge la production de blocs [23].
3. Bascule. Le premier bloc de l'époque qui suit la 90e époque à franchir la porte est le slot 0 : la preuve de travail prend fin, l'intervalle devient de 5 secondes et l'époque compte 17 280 slots. Ce qu'une époque paie en subvention ne change pas ; chaque bloc en paie un sixième, et un slot vide ne paie rien. Les plafonds par bloc (§9), avec leurs planchers et leurs limites, et le nombre de certificats du chemin forcé (§8) sont divisés par six, arrondis à l'inférieur, si bien que la capacité par jour est la même à l'instant de la bascule, et le contrôleur d'époque poursuit à partir de là. Chaque constante comptée en blocs qui mesure le temps (maturité, TTL maximal, fenêtre d'intent, horizon d'annulation, fenêtre du temps médian, durée de vie d'une entrée d'annuaire) est multipliée par six, et une maturité ou un TTL fixé avant la bascule est converti au bloc de bascule.

Finalité. Un bloc est final par la profondeur, comme sous preuve de travail. Les services financiers devraient attendre 10 minutes : 120 blocs, là où la preuve de travail en demandait 20. Les blocs plus vieux d'une époque peuvent être fixés comme points de contrôle.

12. Au-delà de la vérification complète#

Dans les ères de la preuve de travail et de la preuve d'enjeu, chaque nœud vérifie chaque certificat. Le calcul n'est pas la limite : la vérification est parallèle, et les plafonds du §9 sont refixés aux frontières d'ère jusqu'à la largeur structurelle de la liste de certificats, 2²⁵ par bloc. Ce qui limite avant ce mur, ce sont les données : la bande passante pour recevoir chaque corps et le stockage pour conserver chaque corps et chaque entrée du registre des dépensées. Cette section dit ce que l'on sait de la route au-delà et la laisse à une ère ultérieure, activée à la demande, lorsque le volume quotidien approchera de ce qu'un nœud ordinaire vérifie. C'est une direction, non une spécification : les problèmes ont plusieurs solutions aux compromis différents, le réseau répond à toute la demande qu'il rencontrera pendant longtemps sans aucune d'elles, et se préparer en détail à un avenir lointain ne vaut pas plus que de laisser la route balisée pour qui l'empruntera. Rien de ce qui précède ne change. La validité comme fonction des octets, le fold, l'accès typé, les deux marchés, les séquenceurs et le chemin forcé restent tels qu'ils sont. Ce qui change, c'est seulement qui vérifie chaque certificat.

Ce que permet le certificat. Dans les chaînes à réexécution, Ethereum, Solana et celles qui en dérivent, chaque validateur exécute chaque transaction contre l'état global, la vérification hérite des limites de l'état, et la réponse historique a été des machines plus grosses, c'est-à-dire moins de nœuds. L'exécution parallèle à l'intérieur du nœud, avec des listes d'accès déclarées comme dans Solana [21], rend chaque machine plus rapide et ne change pas qui en a besoin d'une. Cardano s'en est approché davantage : dans le modèle UTXO étendu, la validation est déterministe et locale [24], mais les scripts s'exécutent sur chaque nœud et l'état partagé est disputé, ce que le modèle résout en repoussant la sérialisation vers des batchers hors chaîne, que la chaîne ne reconnaît pas. Les rollups, optimistes comme de validité [25][26], ont sorti l'exécution de la chaîne de base et l'ont laissée vérifier : c'est la bonne division, payée par une seconde couche, un pont, un séquenceur unique dont le chemin forcé attend derrière un délai, et, selon le type, une semaine de contestation interactive ou un prouveur qui coûte des ordres de grandeur de plus que l'exécution. Un certificat Zycord est un lot de rollup que la chaîne de base contrôle à partir de ses propres octets et n'exécute jamais contre son état, et pour cette raison il n'a besoin d'aucune seconde couche : il n'y a pas de pont parce qu'il y a un seul état ; pas de contestation parce qu'un certificat invalide est sa propre preuve de fraude, en un seul message ; pas de prouveur parce que vérifier coûte ce que coûte exécuter ; le séquenceur est propre à chaque contrat, le chemin forcé atterrit dans le bloc suivant, et deux contrats sous des séquenceurs différents se composent en un seul certificat atomique (§7), là où deux rollups ont besoin d'un pont. Et là où la réponse à la croissance est le sharding, la trajectoire d'origine d'Ethereum, Near [27], les parachains [28], qui partitionne l'état et perd l'atomicité entre partitions, la partition de Zycord, quand elle viendra, partitionne la vérification et non l'état : l'état reste unique, le fold reste unique et chaque certificat reste atomique, parce que le choix de qui vérifie un certificat est libre lorsque la validité est une fonction des octets.

Vérification échantillonnée. Avec un enjeu engagé, la responsabilité de vérifier un certificat peut être attribuée par tirage à un sous-ensemble d'enjeux au lieu de reposer sur tous. Un certificat entre dans un bloc avec les attestations de son comité ; tout nœud reste libre de vérifier n'importe quoi ; un certificat invalide reste sa propre preuve de fraude, en un seul message, sans état et sans jeu interactif [29] ; et ce que l'ère ajoute, c'est la sanction (slashing) de quiconque a attesté. La taille du comité, la forme de l'attestation, la fenêtre de contestation et le sort de ce qui a été appliqué par-dessus un certificat annulé sont la spécification de cette ère, et restent ouverts. L'effet est d'inverser la courbe : la capacité croît avec chaque nœud qui rejoint le réseau, parce que chacun vérifie une part plus petite, et le comité croît avec l'ensemble.

Le cône de vérification. Celui qui reçoit un certificat n'a pas besoin de toute la chaîne pour lui faire confiance. Les lectures sont déclarées, si bien que l'ensemble des certificats dont il dépend est énumérable à partir de la chaîne : pour chaque cellule lue, les certificats qui l'ont écrite depuis la dernière racine d'état d'époque, et les leurs, récursivement. Ce cône, revérifié à partir des octets et ancré à une racine d'époque sur laquelle s'engage l'en-tête (§3), est une vérification complète de ce qui compte pour le destinataire, faite en quelques secondes, au rythme du réseau, sans circuit ni preuve spéciale. Une plateforme d'échange qui reçoit un dépôt vérifie le cône du dépôt, non le réseau ; sous vérification échantillonnée, ce qui reste est d'attendre la fin des réorganisations et de la fenêtre de contestation, ce qu'elle fait déjà aujourd'hui. Une preuve qu'une cellule détenait une valeur donnée à la racine d'époque est le seul objet nouveau que cela requiert, et sa forme est ouverte ; la filiation est la vérification de paiement simplifiée [1].

Stockage. Ce que le réseau fait déjà : les cellules à usage unique dépensées se compactent au-delà de l'horizon d'annulation (§4), et un nœud élague les corps en dessous d'un plancher qu'il annonce (§10). Ce qui reste un sujet d'étude : un registre des dépensées par époque, dans lequel les adresses à usage unique expirent et le registre se ferme ; un accumulateur à la place du registre [30] ; et la conservation des corps anciens par une fraction des nœuds, avec la racine d'époque comme garantie que ce qui est conservé est ce qui a été dépensé.

Bande passante. Deux routes. La première est la topologie dont la conception dispose déjà : portefeuille, séquenceur, producteur. Un fill n'a pas besoin d'inonder le réseau ; il va du séquenceur aux producteurs, et tous les autres reçoivent le hash, comme le relais le fait déjà avec les blocs (§10). La seconde est de séparer la tête d'un certificat de son corps. La tête est ce que touche le fold : id, lectures, écritures, dépôt et offre. Le corps est ce que consomme la vérification : programme, calldata, signatures. Sous vérification échantillonnée, un producteur n'a besoin du corps que des certificats qu'il est tiré au sort pour vérifier et de la tête de tous les autres, et sa bande passante chute de plusieurs ordres de grandeur. Le bloc continue de s'engager sur le hash de l'exemplaire entier, et les corps continuent d'être des données de la chaîne, servis par ceux qui les ont vérifiés et ceux qui les archivent ; la manière de garantir leur disponibilité lorsque tous les nœuds ne les détiennent pas est la question à laquelle l'ère doit répondre avant d'exister [29].

13. Risques acceptés#

Conséquences des règles qui sont acceptées telles quelles. Chacune est bornée, ou retombe sur une partie qui l'a choisie ; aucune ne permet à quiconque de s'emparer de la valeur native d'un tiers.

1. Un contrat dont le séquenceur, l'administrateur et le code de changement de séquenceur ont tous disparu ne peut être quitté que par le chemin forcé : lent et plus coûteux, mais vivant.
2. Avec des blocs vides, les deux frais de base se stabilisent à 7, au-dessus de leur plancher de 1 : en dessous de 8, le pas de baisse s'arrondit à zéro. Déplacer ce point de repos exige un changement de paramètre à une frontière d'ère.
3. Environ un bloc de nuisance payante par les frais sur un contrat chaud : les propres certificats forcés du producteur placés autour de celui d'un utilisateur, bornés par les bornes de l'utilisateur, et un certificat forcé par bloc obligeant le séquenceur à reconstruire son pipeline.
4. Un contrat ouvert, avec une clé de séquenceur nulle, n'est protégé que par son code, et l'auteur d'un certificat dirigé contre lui paie ses propres omissions : c'est l'auteur qui a choisi les lectures.
5. Un actif non natif crédité à une adresse à usage unique par quiconque d'autre que le certificat qui la brûle est gelé par le brûlage, qui ne déplace que le solde natif et les cellules que ce certificat écrit. Contrôler les soldes d'actifs d'une adresse avant de la brûler est une règle de portefeuille, non une règle de protocole.
6. Un certificat qui ne fait que déplacer des deltas ne fait pas avancer le fence (§7) ; un fill construit avant lui qui lit de façon exacte une cellule qu'il a fait bouger est omis dans un bloc ultérieur, aux frais du séquenceur. Un séquenceur évite cela en ne lisant pas de façon exacte une cellule que son contrat laisse n'importe qui faire bouger par delta.
7. Nuisance résiduelle envers l'exécutant du chemin forcé : un attaquant disposant de nombreux payeurs peut relayer des intents ouverts qu'aucun certificat ne peut transporter, par exemple un intent dont le payeur ne dispose pas du montant du paiement. Un appel qui est simplement annulé ou dépasse ses bornes n'en fait pas partie : il arrive sous sa forme d'échec et paie (§8). Chaque intent intransportable coûte une construction à l'exécutant ; la copie est ensuite évincée et mise en quarantaine, et un remplacement sur le même payeur doit payer strictement plus.
8. Un co-signataire ne verrouille aucune cellule. Un fill conjoint qu'il a signé occupe une place dans son pipeline jusqu'à ce que le fill soit porté ou que sa fenêtre passe (§7). Un fill conjoint qui n'est pas porté à temps peut rencontrer d'autres fills sur ces cellules ; celui qui entre en second dans le fold est omis, aux frais de son propre déposant.
9. Sur un contrat ouvert, le certificat dont l'adresse de dépôt se classe en premier remporte une course sur les lectures exactes, et les adresses ne coûtent pas cher à générer en masse ; un contrat dont l'état exact est disputé choisit un séquenceur, dont le pipeline fixe l'ordre.
10. Un appel simple sur le chemin exact d'un contrat ouvert déclare la cellule de séquenceur du contrat comme exactement nulle. Si le contrat acquiert une clé avant que le certificat n'arrive, la lecture est périmée et l'appel est omis, facturé à l'appelant ; le portefeuille avertit avant de construire un tel appel.
11. Les frais d'omission sont fixes, si bien que lorsque les frais de base sont élevés, une omission coûte moins qu'une application ; essayer plusieurs variantes d'un même certificat est peu coûteux, et chaque nœud vérifie chacune d'elles.
12. La bande passante et le stockage à haut débit sont un problème ouvert déclaré, non un problème résolu : les corps sont des données de la chaîne, chaque nœud porte chaque octet, un appel de machine porte le code qu'il exécute, et le registre des dépensées croît d'une entrée par dépense à usage unique. La route se trouve au §12.
13. Sous preuve d'enjeu (§11), la sécurité de la chaîne est celle d'une preuve d'enjeu conventionnelle : elle coûte ce que coûte la réunion d'une majorité du poids dans le tirage, délégations comprises. La rampe démarre à son échéance avec l'enjeu qui existe alors, et c'est la porte qui empêche la bascule de s'achever sans qu'un enjeu vivant détienne un dixième de l'offre ; un dixième de l'enjeu, absent, la suspend. La double signature d'un pool ne coûte que sa propre caution, quoi qu'il lui soit délégué ; les délégateurs choisissent leur pool en le sachant. La réécriture à longue portée avec des clés désengagées depuis n'est empêchée que par les points de contrôle fixés (§10), qu'un nœud qui rejoint le réseau accepte de sa version et ne dérive pas de la chaîne.

14. Conformité#

Les règles sont la spécification d'architecture, les vecteurs de référence sont le protocole, et là où deux d'entre eux divergent, le plus précis l'emporte et la divergence est un bug. Le protocole vit dans un répertoire spec/ publié : les fichiers de paramètres, le registre des ids de chaîne, les points de contrôle épinglés, les images de la bibliothèque prédéployée et trois corpus de vecteurs :

• vecteurs de fold : (pre-state, block) → (post-state | invalid, outcomes, fees) ; un vecteur invalide consigne l'unique règle qu'il enfreint ;
• vecteurs de dérivation : (program, declared reads and writes, deposit) → (reads, writes, artifact, parallel gas), ou la règle qui refuse le certificat avant que la machine ne soit atteinte ;
• vecteurs de difficulté : (parameters, headers) → next target, avec un verdict sur un en-tête candidat ; sous preuve d'enjeu, (stake set, seed, slot) → drawn key.

Les vecteurs sont générés, jamais édités à la main. La régénération pilote le fold de référence, rejoue le résultat à travers lui, puis rejoue le JSON validé à travers un second fold, délibérément naïf, qui ne partage aucun code avec le premier ; une régénération avec laquelle le second fold est en désaccord échoue. Une régénération qui modifie un vecteur existant est un changement de consensus et est examinée comme tel. Une implémentation est conforme lorsqu'elle reproduit l'id de genèse et passe les vecteurs ; elle est alors un pair, non un fork.

15. Relation avec la v1.0#

Cet article remplace intégralement la v1.0 [0]. Là où les deux diffèrent, cet article est le protocole et la v1.0 ne doit pas être lue en parallèle. La thèse est inchangée : des certificats auto-certifiants, un fold qui n'exécute jamais rien, un accès typé à l'état et deux marchés de frais. Les changements ci-dessous ont été découverts lors de l'implémentation de la conception ; chacun a supprimé de la surface de consensus et des classes d'erreurs.

16. Conclusion#

Zycord ordonne des certificats au lieu d'exécuter des transactions : une validité contrôlée par quiconque, n'importe où, en parallèle, à partir des seuls octets ; un état qui avance par un fold qui ne fait que comparer et additionner ; des conflits omis, tarifés et imputés à la partie qui les a choisis ; une concurrence déclarée plutôt que découverte ; des applications confirmées en quelques millisecondes par des séquenceurs auxquels on fait confiance pour la vivacité et jamais pour la sûreté ; un chemin forcé qui garde chaque contrat joignable ; et un consensus qui, une fois la pièce distribuée, dépense son calcul en vérification plutôt qu'en hashs. La vérification passe à l'échelle horizontalement avec du matériel que le réseau ne possède pas. La validation reste séquentielle, et presque gratuite.

Références#

[0] The Simstoshi. Zycord: A Peer-to-Peer Network of Self-Certifying State Transitions, v1.0. 2026. Remplacé par cet article.
[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 : lancement, ères et paramètres#

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

Ce document est le compagnon de Zycord : un réseau pair-à-pair de transitions d'état auto-certifiantes, v2.0 ("l'article"). L'article définit les mécanismes. Ce document expose comment le mainnet a été lancé, comment la pièce est émise, quelle ère active quoi, et la valeur de chaque paramètre. Il remplace intégralement les §13 et §14 de l'article v1.0 ; là où ils diffèrent, c'est ce document qui fait foi.

1. Lancement#

Genèse du mainnet : 2026-10-07 00:00 UTC (1791331200), id de chaîne 1.

• Des blocs toutes les 30 secondes sous preuve de travail ; toutes les 5 secondes à partir de la bascule vers la preuve d'enjeu (§6). Preuve de travail : RandomX v2, minable au CPU. Difficulté : LWMA sur une fenêtre de 90 blocs.
• Le bloc 0 ne contient aucun certificat, aucune adresse et aucune clé. Aucune pièce n'existe avant le bloc 0. La genèse est reproductible à partir de sources publiées.
• Pas de tour d'investisseurs ni de clés d'administration. Aucun chemin de code ne permet à une clé quelconque de suspendre, mettre à niveau, émettre, censurer ou réorganiser.

L'engagement de lancement. Le jeu de paramètres porte un engagement envers un message de lancement secret. Le bloc 1 doit ouvrir cet engagement dans son en-tête, si bien que seul le détenteur du message peut produire le bloc 1, et que personne d'autre ne peut accumuler du travail sur une chaîne qui commence avant la genèse annoncée ; la rampe d'émission fait que toute avance ne vaut pas grand-chose. À partir du bloc 2, n'importe quel mineur peut construire.

Les ids de chaîne sont consignés dans un registre. Le registre, avec l'id de genèse que porte chaque réseau actif, est intégré à chaque binaire et contrôlé au démarrage : le nœud refuse un id retiré, ainsi qu'un jeu de paramètres qui donnerait une genèse différente à un id consigné. Un nœud refuse de démarrer avec un moteur de travail autre que celui que le réseau déclare.

2. Émission#

La subvention décroît en douceur jusqu'à une queue perpétuelle. Le taux est constant au sein d'une époque d'un jour et diminue à chaque frontière d'époque, par une arithmétique entière exacte sur quatre constantes :

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

avec E0 = 21 ZCD par bloc, Q = 1054 et tail = 0,33 ZCD par bloc, à l'intervalle de la preuve de travail de 30 secondes. Le taux est divisé par deux environ tous les deux ans. Il n'y a ni nombres flottants ni table. Le bloc de genèse ne paie aucun coinbase. La queue commence à l'époque 4 376, vers l'année 12, avec 61 836 900,03 ZCD programmés : les 62 744 838,47 auxquels le calendrier se totalise, moins la rampe de lancement et le bloc de genèse. Ces chiffres sont ce que produit la récurrence ; aucun nœud ne calcule jamais de forme close. Un ZCD vaut 100 000 000 drops.

Un démarrage lent. Les 86 400 premiers blocs (30 jours) forment une rampe : le bloc h paie E(30) · h / 86,400, le taux de l'époque au cours de laquelle la rampe se termine, arrondi à l'inférieur, si bien que la récompense monte en ligne droite de presque zéro jusqu'au calendrier. Ce que la rampe retient, environ 907 917 ZCD, n'est jamais reversé.

Le changement d'intervalle. À partir de la bascule vers la preuve d'enjeu (§6), l'époque compte 17 280 slots et la subvention par bloc est E(n)/6, arrondie à l'inférieur en drops ; la récurrence ne change pas. Ce que paie une journée de slots pleins est le même sous les deux intervalles : 21 ZCD par bloc sur la courbe de genèse équivalent à 3,5 par bloc de 5 secondes, et la queue de 0,33 équivaut à 0,055. La queue commence à la même époque, 4 376. L'arrondi retient moins d'un millième de ZCD par époque et n'est jamais reversé.

La queue paie quiconque sécurise l'ère en cours sans enrôler les marchés de frais. Face à elle jouent le brûlage des frais de base des deux marchés et le brûlage de chaque certificat omis (article, §9), si bien que l'émission nette est la queue moins le brûlage et peut être négative sous charge. En fraction de l'offre, la queue tend vers zéro.

3. Répartition de la subvention#

Chaque subvention de bloc est répartie 94 / 3 / 3 par le consensus dès le bloc 0. La répartition ne s'applique qu'à la subvention, jamais aux frais, et de façon identique à chaque bloc. Pendant la rampe de la preuve d'enjeu (§6), les 94 % du producteur sont eux-mêmes partagés entre le mineur et le staker tiré au sort, selon la fraction que la rampe a atteinte.

Il n'y a pas de premine : la répartition est une règle appliquée à chaque bloc miné, non une allocation à la genèse. Sur ses trois ans, la part du fondateur totalise moins de 2 % de l'offre antérieure à la queue. Un producteur qui dépasse le plafond souple (article, §9) ne renonce qu'à une partie de sa propre part ; les parts de la trésorerie et du fondateur sont prélevées sur la subvention non réduite.

4. Trésorerie#

La cellule de trésorerie est le solde natif de l'adresse du protocole. Aucune clé n'a pour hash cette adresse, aucun certificat ne peut la débiter, et la genèse ne nomme aucun quorum. Elle s'accumule à partir du bloc 1, et cette version ne porte absolument aucun chemin de dépense. Un chemin de dépense est défini par une mise à niveau, pas avant la hauteur 259 200 (vers le 5 janvier 2027), avec des signataires choisis par la communauté et non par le fondateur. D'ici là, la cellule est un entier public que chacun peut auditer et que personne ne peut toucher.

5. Intendance : les trois premières années (proposition)#

Statut. Cette section est une orientation soumise à l'examen de la communauté. Rien de ce qu'elle contient n'est une règle de consensus tant que la mise à niveau de la trésorerie du §4 n'a pas fixé un ensemble de clés, et les détails ne sont spécifiés qu'après l'acceptation de l'orientation.

Ce que reçoit la trésorerie. Environ 533 000 ZCD en année 1, 396 000 en année 2 et 280 000 en année 3 : environ 1,21 million au total. À partir de l'année 4, elle reçoit aussi les 3 % du fondateur (§3), soit environ 396 000 au total cette année-là. Ce que cela permet d'acheter dépend d'un prix que personne ne connaît, et un marché étroit ne peut pas absorber de grosses ventes ; le plan doit donc fonctionner dans le bas de la fourchette :

Chaque montant ci-dessous est donc une part des entrées de la trésorerie, jamais un chiffre en dollars ou en ZCD.

Cinq sièges. Le siège est défini avant son titulaire. Chaque siège a une charte publique : ses fonctions, ses livrables, la manière dont il rend compte et ce qu'il est payé. N'importe qui peut postuler. Quiconque occupe le siège sert la charte, comme dans le cadre d'un contrat.

Décisions.

• Une dépense requiert 3 voix sur 5.
• Remplacer un titulaire, faire tourner les clés, dépenser la réserve ou amender une charte requiert 4 voix sur 5, et est rendu public 7 jours avant de prendre effet.
• Les mandats durent un an et sont renouvelables. Les candidatures sont publiques pendant 30 jours. Les cinq premiers titulaires constituent l'ensemble de clés fixé par la mise à niveau qu'adoptent les opérateurs de nœuds ; un hard fork ultérieur peut le fixer à nouveau.

La rémunération est une participation, non un salaire. La part d'un siège s'accumule de façon verrouillée et est libérée tous les six mois, sur présentation d'un rapport publié et avec les voix de 3 des 4 autres titulaires. Aucun titulaire ne vote sur la libération de sa propre rémunération. Ce qui n'est pas libéré retourne à la réserve. La rémunération des sièges est fixée par les chartes et n'est pas déterminée par un vote de dépense. Un plafond par siège, mesuré au prix du marché à la date de libération, envoie tout excédent à la réserve.

Budget, en parts des entrées.

L'infrastructure est prioritaire : les nœuds, les seeds, l'explorateur et les serveurs de compilation coûtent aujourd'hui environ 500 US$ par mois. Le remboursement est converti au prix du marché le jour où il est payé. La part couvre ce coût à environ 0,06 US$ par ZCD en année 1, 0,08 US$ en année 2 et 0,11 US$ en année 3 ; en dessous, le manque est reporté sans intérêts et payé lorsque la part le permet.

Le fondateur. Les 3 % de la subvention revenant au fondateur (§3) rémunèrent le travail accompli jusqu'au lancement et lors de celui-ci. Ils sont distincts du siège de développeur principal, qui est rémunéré comme tout autre siège pour le travail continu. Le fondateur détient une clé sur cinq et ne vote pas sur la libération de la rémunération de ce siège.

Ce que le consensus impose. Une fois la mise à niveau déployée : la dépense à 3 sur 5 et le renouvellement à 4 sur 5 avec son délai. Tout le reste de cette section est une norme. Ce qui fait respecter une norme, c'est que chaque dépense est un certificat ordinaire, public et dénombrable à partir de la seule chaîne.

Ouvert. Le plafond par siège. La forme juridique sous laquelle signe le représentant public. La question de savoir si le verrouillage de six mois sera imposé par un contrat de séquestre de la bibliothèque standard une fois la machine active.

6. Ères#

Les ères sont des constantes de hauteur compilées dans les versions publiques. Un bloc situé sous une porte qui porte un programme que cette porte active est invalide, et ce contrôle de hauteur est la seule chose qui sépare les ères, à l'exception de la rampe et de la bascule de l'ère 2, qui sont déclenchées par l'état entre des bornes de hauteur. Une nouvelle ère peut ajouter des règles et des types d'enregistrement ; elle ne change jamais ce que signifie un bloc existant sous sa hauteur d'activation.

Les ères 2 et S sortent chacune comme une version à part entière par hard fork, avec une spécification, un devnet adverse et une relecture. L'ère 2 ouvre l'engagement par la hauteur, démarre sa rampe par l'enjeu avec une échéance, et bascule lorsque la rampe s'achève : la bascule peut survenir au plus tôt à l'époque 303 (mois 10), et l'échéance du démarrage garantit que la rampe est en cours à la fin du mois 9. Pour le seuil de 10 %, l'enjeu est l'enjeu actif avec ses délégations et l'offre est la pièce émise, tous deux à l'ouverture de l'époque. La porte peut suspendre la bascule au-delà de l'époque 363 ; ce qu'elle ne peut pas faire, c'est l'empêcher de démarrer.

Enjeu. La caution minimale est de 1 000 ZCD, et un enjeu participe une époque après son engagement. Une caution qui ne fait que déléguer a un minimum inférieur, fixé par la version de l'ère, et ne quitte jamais la garde du délégateur. Le minimum est en ZCD et non en dollars parce qu'aucune règle ne peut lire un prix ; il est révisé aux frontières d'ère à mesure que le plafond de bloc croît.

L'ère 0 est délibérément minuscule et l'ère 1 est réduite à ce dont la conception a besoin : sans clés d'administration, il n'y a pas de bouton pause, si bien que chaque ligne de consensus est une ligne qui peut tuer le réseau sans remède. Du code de consensus inatteignable est du code de consensus inauditable, et il n'est pas livré. Une ère qui ne prouve pas qu'elle vaut sa complexité n'est jamais déclenchée.

La transition est maîtrisable parce que le fold est agnostique quant à qui ordonne : l'ère 2 change la signature qui figure sur l'en-tête.

Porte de l'ère 1. Le bloc de la porte écrit les constantes compilées de l'ère dans des cellules de protocole, si bien que la racine d'état s'engage sur elles à partir de ce moment. Dans les 240 premiers blocs après la porte, un certificat qui exécute SETSEQ doit porter un TTL d'au moins 240 blocs au-delà de la porte et attendre qu'il entre dans la plage.

L'ère 2 et les hauteurs qui mesurent le temps. Après la bascule, la hauteur avance six fois plus vite. Chaque constante de genèse qui est en réalité une durée (la fin de la part du fondateur, la maturité du coinbase, le TTL maximal, la fenêtre d'intent, la profondeur d'annulation, la fenêtre du temps médian, la durée de vie d'une entrée d'annuaire) est lue par l'ère 2 dans l'unité qu'elle mesure : la hauteur 3 153 600 correspond à 1 095 époques de 2 880 blocs, et l'ère met fin à la part du fondateur à l'époque 1 095. Le tableau des paramètres de genèse ne change pas, parce que la racine de consensus parcourt chaque paramètre et que modifier l'un d'eux modifierait l'id de genèse de chaque réseau actif ; les constantes de l'ère sont compilées, comme celles de l'ère 1.

7. Paramètres#

Le jeu de paramètres est figé à la genèse, intégré à chaque binaire à la compilation, et modifiable seulement par hard fork. Sa racine de consensus entre dans chaque signature. zcd params affiche les valeurs compilées d'une version ; zcd genesis affiche le réseau, l'id de chaîne, le hash des paramètres, l'id de genèse et la racine d'état.

Les constantes de l'ère 1 sont compilées, non des paramètres, parce que la racine de consensus parcourt chaque paramètre et qu'en ajouter un modifierait l'id de genèse de chaque réseau actif.

Les constantes de l'ère 2 sont compilées pour la même raison.