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

Zycord : un réseau pair-à-pair de transitions d'état auto-certifiantes. Par Simstoshi, v1.0, 2026. Chaque transaction transporte l'état qu'elle a lu et l'état qu'elle a écrit ; la vérifier est donc une fonction pure de ses octets — pas de disque, pas d'historique, pas de confiance, et aucune borne sur le parallélisme.

Citer ce document. L'enregistrement de référence, archivé et versionné, est doi:10.5281/zenodo.22167490. Un PDF est servi depuis ce site, 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. Le texte ci-dessous est ce document, non abrégé.

1. Introduction#

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

Les architectures existantes enchevêtrent les trois. Dans le modèle dominant, un nœud ne peut pas vérifier une transaction sans détenir l'état global, si bien que la vérification hérite des limites de passage à l'échelle de l'état ; et parce qu'un marché de gas unique tarife les trois ressources ensemble, une vérification de signature concourt dans la même enchère qu'une écriture en mémoire. Les chaînes haute performance récentes parallélisent l'exécution à l'intérieur du nœud, mais chaque nœud réexécute quand même tout, et la contrainte déterminante devient les E/S sur l'état. La réponse a consisté en des machines toujours plus grosses, c'est-à-dire en des nœuds toujours moins nombreux.

Cet article prend le chemin inverse. Nous ne parallélisons pas l'exécution contre un état partagé ; nous retirons entièrement l'état du chemin parallèle. Une transaction devient un certificat qui transporte ses propres entrées et sorties. Le vérifier est une fonction pure de ses octets. Le travail de la chaîne se réduit à ordonner des 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 font qu'un certificat particulier est omis, et chaque omission est facturée à un garant cautionné. La concurrence n'est pas découverte à l'exécution ; elle est déclarée, slot par slot, par l'auteur du contrat.

Les sections qui suivent définissent le certificat (§2), le fold (§3), l'accès typé à l'état (§4), l'économie de garantie (§5), les séquenceurs applicatifs (§6), la résistance à la censure (§7), le double marché de frais (§8), les preuves de fraude et la voie de l'échantillonnage (§9), la machine virtuelle (§10), les actifs natifs sans machine (§11), les paiements confidentiels (§12), le réseau (§13), le lancement en trois ères et sa trésorerie (§14), et les mesures issues de l'implémentation de référence (§15).

2. Certificats de transition d'état#

Un certificat est le seul type de transaction dans Zycord :

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

Un slot est un couple (address, word). Un certificat est valide si trois vérifications passent, dont aucune n'exige le moindre état :

1. chaque sig autorise les cellules qu'elle dépense ;
2. la signature du garant est bien formée sur (certificate, ttl) ;
3. réexécuter program contre les reads déclarés produit exactement les writes déclarés. Les signatures doivent être canoniques, et il s'agit d'une règle de consensus plutôt que de la bonne éducation d'une bibliothèque. L'id d'un certificat est le hash de ses champs d'autorisation — reads, writes, program, underwriter (le garant), ttl, et les enchères de frais. Les signatures n'en font pas partie, et le paragraphe suivant dit pourquoi. L'ensemble des vus indexé par cet id constitue à lui seul toute la défense contre le rejeu. Les frais sont un champ d'autorisation et non une préférence de relais, et la distinction est monétaire : une enchère est le signataire consentant à un coût, si bien qu'une enchère hors de l'id serait une enchère que n'importe qui, en transit, pourrait réécrire — gonflée pour brûler le solde de l'expéditeur via les frais de base, ou mise à zéro pour tenir le certificat hors de tout bloc. Ce qu'un certificat paie fait partie de ce que son signataire a autorisé, et l'id le dit. Ce que la canonicité apporte est plus étroit qu'un id et reste une règle de consensus : un schéma admettant deux encodages d'une même signature admet deux exemplaires d'un même certificat, et deux implémentations en désaccord sur celui des deux qui se vérifie ont forké sur un certificat qu'aucune ne peut déclarer invalide. La règle qui referme cela tient en une phrase : un encodage de signature non canonique est invalide, et une implémentation dont le vérificateur en accepte un n'est pas une implémentation de ce protocole. Les schémas sains rejettent déjà de tels encodages ; la raison de l'écrire noir sur blanc est que ceux qui ne le font pas sont également populaires, et qu'une implémentation indépendante qui en retiendrait un divergerait d'une manière qu'aucun de ses propres tests ne révélerait.

Les démonstrations randomisées font exception, et l'exception est structurelle et non affaire d'encodage. Une preuve d'intervalle (§12) est randomisée : pour un même énoncé, le prouveur choisit des nonces, si bien qu'un énoncé possède une infinité de preuves valides, toutes canoniques, et il n'existe aucun encodage non canonique à rejeter. Deux preuves valides d'un même énoncé ne sont pas deux encodages d'une preuve ; ce sont deux preuves, et le bénéficiaire — qui détient l'ouverture — peut toujours en produire une nouvelle. La canonicité ne les atteint donc pas. Une signature en fait partie, et c'est facile à manquer parce qu'elle n'est pas de la variété exotique. Ed25519 est une preuve de connaissance de Schnorr : le signataire choisit un nonce, et chaque nonce donne une signature différente sur le même message, chacune valide et chacune parfaitement canonique. La dérivation déterministe du nonce est une règle pour les signataires qu'aucun vérificateur ne peut contrôler et qu'aucune règle d'encodage ne peut imposer, car tout point de nonce est un point encodable canoniquement comme un autre. Ainsi une même autorisation possède une infinité de signatures, et un id qui les couvrirait aurait une infinité de valeurs — chacune productible par l'un quelconque des signataires requis du certificat, transportant intactes les signatures des autres, et chacune facturable dans un bloc à elle seule. Le modèle de menace est plus étroit que celui d'une preuve et la conclusion est la même : une preuve peut être re-randomisée par un bénéficiaire qui ne détient aucune clé, tandis qu'une seconde signature exige une clé que le certificat requiert déjà. L'id referme l'écart par construction : il s'engage sur ce qu'un certificat autorise et jamais sur ce qu'il ne fait que démontrer, si bien que signatures et preuves voyagent toutes deux hors de la préimage de l'id. Resigner ou re-randomiser donne le même id, l'ensemble des vus attrape le doublon, et un bloc qui porte les deux est invalide. Cela scinde les champs d'un certificat en deux espèces — l'autorisation, que l'id couvre et que les signatures signent, et la preuve, que ni l'un ni les autres ne couvrent. Cette scission n'est pas une préoccupation de §12 en attente des paiements confidentiels ; elle est porteuse dès le bloc 0, où la seule preuve que transporte un certificat est ses signatures. Un vérificateur contrôle la preuve à partir des octets, dans l'étape parallèle, puis la jette ; seule l'autorisation survit jusqu'à l'id, l'ensemble des vus et le fold.

La scission crée une obligation que l'id ne porte plus, et elle est nommée ici plutôt que découverte en production. Une preuve hors de la préimage de l'id est une preuve que n'importe qui, en transit, peut remplacer : prendre un certificat, substituer n'importe quoi à sa preuve, et propager — même id, exemplaire désormais invalide. Deux règles referment les deux brèches ainsi ouvertes. Premièrement, un bloc s'engage sur la preuve qu'il transporte. La liste de certificats du bloc est une liste de hashs d'exemplaires — une feuille par certificat, sur l'encodage entier, preuve comprise — de sorte que « ce bloc est valide » reste un énoncé portant sur des octets que le bloc lui-même épingle. L'id répond à cette autorisation a-t-elle déjà été facturée, le hash d'exemplaire répond à ces octets le prouvent-ils, et les deux questions ne partagent jamais une clé. Une seule feuille suffit tant que la preuve est inséparable de l'encodage, comme c'est le cas tant que la preuve se réduit aux signatures ; lorsque les preuves de §12 en feront un champ à part entière, la feuille deviendra le couple (id, hash de la preuve), et l'engagement restera le même engagement. Ce qu'elle ne doit jamais devenir, c'est une liste d'ids : cela ne s'engagerait sur aucune preuve en particulier, et puisque la racine de la liste de certificats est un champ d'en-tête et que l'en-tête est la préimage de la preuve de travail, échanger la preuve ne coûterait alors rien et laisserait le travail debout. C'est le précédent des transactions à témoin engagé, et il est suivi pour la raison même qui l'a fait inventer : un id qui couvrait la preuve était malléable, et un id qui ignore une preuve non engagée est aveugle. Deuxièmement, le relais traite des exemplaires, non des ids : un nœud qui reçoit un exemplaire dont la preuve échoue à la vérification jette cet exemplaire sans préjudice pour l'id — l'id n'est ni marqué, ni mis en cache comme invalide, et un exemplaire ultérieur qui se vérifie est relayé normalement. Une copie mutilée coûte à son mutilateur la bande passante de son envoi et ne coûte rien au certificat. L'aveuglement du proposeur reste intact : il inclut les exemplaires que sa propre vérification sans état a acceptés, et il ne peut donc pas plus être amené à inclure une preuve mutilée qu'une mauvaise signature ; l'assertion de §3 conserve le sens qu'elle avait.

La validité est une fonction pure des octets du certificat. N'importe quelle machine peut la contrôler, dans un pool de threads, sur un autre ordinateur, sur un GPU, sans base de données, sans historique et sans synchronisation. Les vérifications de signature se groupent d'un certificat à l'autre ; les certificats issus d'un même programme se groupent en charges de travail à instruction unique et threads multiples (§6) ; les preuves d'intervalle (§12) se groupent avec un coût marginal logarithmique. C'est la propriété sur laquelle tout le reste de cet article repose.

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. Nous scindons donc en deux la notion classique de validité d'une transaction : valide (sans état, parallèle, contrôlable par quiconque) et applicable (avec état, séquentiel, décidé seulement par la position dans le registre). La section suivante définit le second prédicat.

3. Le registre comme fold#

Un bloc contient un en-tête, une liste ordonnée de hashs de certificats, et les corps des certificats eux-mêmes. Les corps sont des données de chaîne : un bloc n'est valide que si ses corps sont disponibles (§13). Le proposeur d'un bloc n'exécute rien et ne détient aucun état applicatif ; il ordonne des octets dont il peut contrôler la validité à partir des octets eux-mêmes. Il n'est pas tout à fait sans état, et l'exception mérite d'être nommée plutôt qu'arrondie : il doit porter l'ensemble des ids de certificats vus dans la fenêtre du TTL, car en inclure un deux fois rend le bloc invalide et personne ne peut y être amené par accident. Cet ensemble est borné par le TTL et élagable, ce qui explique que le TTL soit un paramètre de consensus et non une préférence de relais. La proposition est délibérément bon marché et bête, non délibérément aveugle.

L'état de la chaîne est défini comme un fold sur les certificats ordonnés :

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

Les écritures sont contrôlées, et contrôlées avant qu'aucune ne se pose. Des ébauches antérieures de ce schéma appliquaient l'ensemble des écritures sans condition, ce qui se lisait comme si un crédit pouvait ressusciter une cellule dépensée et comme si un delta pouvait déborder par enroulement. Ni l'un ni l'autre n'est vrai et les deux seraient fatals, si bien que l'étape de préparation figure désormais dans le schéma plutôt que d'être laissée à la spécification. L'arithmétique est contrôlée partout où elle apparaît : un delta qui porterait au-delà de 2²⁵⁶ ou en dessous de zéro entraîne l'omission du certificat au lieu de son enroulement, ce qui explique aussi pourquoi les plafonds d'émission de §11 tiennent sous un nombre illimité d'émissions concurrentes. Une écriture vers une adresse dont l'autorité a été brûlée échoue bruyamment au lieu de s'évaporer — c'est bien à cela que sert le registre permanent des adresses dépensées, et c'est la source de l'unique exception au théorème d'attribution de §5.

**leased relève de la machinerie de l'Ère 1 et n'est pas présent à la genèse.** Il est montré ici parce que cette section spécifie le fold du protocole entier, mais l'ère de lancement n'a pas de baux, pas de file forcée et pas de cosignataires à défendre avec eux : la branche est donc inatteignable dans le binaire de genèse — et du code de consensus inatteignable est du code de consensus inauditable, si bien qu'il n'est pas livré. Une question ouverte est signalée plutôt que masquée : tel qu'il est écrit, LEASED facture un certificat à une position que son signataire ne pouvait pas prévoir, ce qui est exactement ce que l'assertion quatre lignes plus haut interdit. Ou bien ce résultat ne doit pas être facturé, ou bien il doit invalider le bloc. Le choix revient à l'ère qui introduit les baux, et il est consigné ici afin que cette ère ne puisse pas hériter de la contradiction en silence.

Propriétés qui méritent d'être énoncées explicitement :

L'omission est une sémantique, pas un échec. Un certificat dont les lectures ne tiennent plus est omis, ses frais d'omission sont facturés à son garant (§5), et le bloc reste valide. Inclusion et application sont deux événements distincts. C'est ce qui permet au proposeur d'être aveugle : il ne peut jamais produire un bloc invalide en incluant un certificat périmé.

Déterminisme. Chaque nœud dérive un état identique à partir d'une séquence de blocs identique. La clé de tri (underwriter, seq, certificate id) est un ordre total sur le contenu du bloc, si bien que le fold est insensible à la façon dont un proposeur entrelace les certificats de garants différents — et ne laisse au proposeur aucune latitude, pas même entre deux certificats qu'un même garant a signés au même seq. Le pipeline propre à un garant (seq croissant) est validé dans l'ordre où il a été signé, quel que soit l'ordre dans lequel le proposeur l'a soumis.

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. Tout cela a déjà eu lieu, en parallèle, lors du contrôle de validité.

Et aucune arithmétique sur courbe elliptique. Les paiements confidentiels (§12) placent des engagements de Pedersen dans des valeurs de slot, et un engagement est un point de courbe. Le schéma est homomorphe et la somme de deux engagements a un sens, ce qui invite le fold à les additionner. Le fold refuse. Une addition de points coûte des centaines de nanosecondes contre environ 1 ns pour une addition sur u256, et une seule opération sur courbe dans l'unique étape séquentielle dépenserait le budget que cette architecture protège. Le fold ne fait que ranger des octets d'engagement dans des cellules neuves et les comparer pour l'égalité — deux opérations de mémoire ; toute l'arithmétique sur courbe a lieu dans l'étape parallèle ou dans le portefeuille du propriétaire (§12). La même discipline gouverne le hachage, ci-dessous.

Un élément de cryptographie n'est pas retiré, et prétendre le contraire serait trop commode : l'id d'un certificat est un hash de ses champs d'autorisation (§2), et l'ensemble des vus est indexé par cet id ; quelqu'un doit donc le calculer. Ce qui importe est où, et la réponse est que ce n'est pas forcément ici. L'id dépend des octets du certificat et de rien d'autre — pas d'état, pas d'ordre, pas de position — si bien qu'il est calculé aux côtés des vérifications de signature dans l'étape parallèle et porté jusque dans le fold, exactement comme le certificat lui-même. Une implémentation qui le recalculerait plutôt dans la boucle séquentielle verrait le hachage dominer une étape censée porter sur la mémoire, une erreur qui mérite d'être nommée parce qu'elle est facile à commettre. Nous voulons être précis sur ce qui est retiré ici et sur ce qui ne l'est pas. Le fold effectue toujours un accès aléatoire sur l'état complet, un accès par slot déclaré, et un nœud qui valide détient toujours cet état. Ce qui quitte le chemin séquentiel, c'est tout ce qui entoure l'accès sur une chaîne classique — interprétation, vérifications de signature, hachage, authentification par opération d'un stockage merkleisé — de sorte que l'état peut vivre dans une table plate et que l'unique étape séquentielle du système est une boucle serrée sur de la mémoire. Le fold de référence soutient 883 000 opérations de slot par seconde et par cœur sur un poste de travail x86 à dix cœurs (§15), et c'est la seule étape qui ne se parallélise pas.

Égalité de valeurs, non de versions. L'applicabilité compare les valeurs de lecture déclarées, non des compteurs de version. Parce que l'exécution est une fonction pure de l'ensemble des lectures, un slot qui a changé puis est revenu à sa valeur initiale (le cas ABA) reste applicable : appliquer le certificat maintenant est sémantiquement identique à l'avoir exécuté alors. Le système omet donc strictement moins souvent qu'un contrôle de concurrence fondé sur les versions. Pour les slots dont la valeur est un engagement, la comparaison est l'égalité octet à octet de l'engagement : opaque, exacte et tout aussi bon marché, une fois imposées les conditions de canonicité de §4.

Rejeu et facturation unique. L'id d'un certificat est le hash de ce qu'il autorise et jamais des signatures qui démontrent cette autorisation (§2), et les certificats appliqués comme les certificats omis et facturés sont marqués comme vus. La distinction est ce qui fait de la règle une règle : un signataire qui resigne un même corps avec un nonce neuf produit le même id, si bien que l'ensemble des vus attrape la copie au lieu de la facturer. Inclure un certificat vu ou expiré invalide le bloc — une signature est donc facturable au plus une fois, et seulement à une position que son signataire a acceptée en signant. Sans cette règle, un producteur de blocs pourrait réinclure ou retarder délibérément les certificats d'autrui pour brûler les fonds de leurs garants. Les TTL sont bornés par le consensus, si bien que l'ensemble des vus reste élagable.

4. Accès typé à l'état#

Un fold qui ne prendrait en charge que des lectures exactes sérialiserait tout contrat populaire : mille certificats touchant une même réserve d'AMM donneraient une application et 999 omissions. La réponse de Zycord est que la concurrence est déclarée par l'auteur du contrat, slot par slot, dans le format de certificat lui-même. Il existe trois disciplines d'accès :

Exacte. À la manière de SLOAD : la lecture renvoie la valeur du slot dans le calcul et y épingle le certificat. Logique arbitraire ; conflits sur les slots chauds ; le domaine des séquenceurs applicatifs (§6).

Delta gardé. Le certificat affirme un prédicat sur le slot — balance ≥ 10 — sans faire entrer la valeur dans le calcul, et écrit un delta signé — balance += −10. Le fold contrôle le prédicat contre l'état courant et applique le delta. Un nombre quelconque de débits et de crédits gardés sur le même slot commutent : ils s'appliquent dans n'importe quel ordre, et une omission ne survient que lorsqu'une garde échoue véritablement (un vrai découvert), non lorsque le solde a simplement changé. Cette seule discipline couvre les transferts, les émissions à offre plafonnée, les autorisations de dépense et les parts de coffre, c'est-à-dire l'écrasante majorité des écritures on-chain.

Delta pur. Un delta signé sans garde. Il ne peut jamais entrer en conflit ni donner lieu à une omission. Pourboires, compteurs, accumulateurs, décomptes de récompenses.

La règle qui préserve la solidité du modèle : les valeurs gardées ne doivent pas s'écouler dans le calcul. Une assertion ne renvoie rien ; un delta ne lit rien. La réexécution demeure donc une fonction pure des lectures déclarées, et la validité sans état (§2) est préservée. La filiation de cette idée est ancienne et solide : transactions à séquestre dans les bases de données, transactional boosting, CRDT [9][10][11]. Mais les chaînes existantes exploitent au mieux la commutativité à l'intérieur de l'ordonnanceur d'un nœud ; Zycord en fait le contrat de concurrence entre nœuds, imposé par le format de certificat et tarifé par l'économie de garantie.

Une seconde règle du même rang, imposée par §12 : aucun slot détenant une valeur dissimulée n'admet de garde de tiers. Une garde dont l'issue est publiquement observable — appliquée ou omise — contre un solde censé rester secret est un oracle de solde : soumettre balance ≥ x, observer le fold, dichotomiser, et log₂(solde) tentatives lisent le nombre sans jamais ouvrir l'engagement. Le correctif est structurel, non statistique. La valeur dissimulée ne vit que dans des cellules à usage unique dépensables par la signature de leur propriétaire ; la discipline du delta gardé, dont tout l'intérêt est que des inconnus puissent toucher un slot sans danger, est réservée aux slots dont les valeurs sont publiques. Les paiements à l'initiative du bénéficiaire — autorisations de dépense, abonnements, balayages de coffre — n'existent donc que sur le rail transparent (§12).

Imposer cette règle exige que le fold puisse distinguer un slot dissimulé d'un slot public, et dans une table plate il ne le peut pas par inspection : un engagement compressé et un solde u256 font tous deux 32 octets. Une cellule à valeur dissimulée n'est donc pas une cellule ordinaire qui se trouverait contenir un engagement ; c'est une espèce de cellule distincte, créée uniquement par l'opération protégée native (§12) et vivant dans une région réservée et dérivable de l'espace d'adressage, de sorte que la discipline d'un slot est une fonction de son adresse et se contrôle à partir des octets comme tout le reste. À défaut, un delta gardé visant — par erreur ou par malveillance — un slot d'engagement ferait ajouter par le fold un u256 à l'encodage d'un point de courbe : les contrôles arithmétiques passent, le résultat n'est pas un engagement, et la cellule devient indépensable. De la valeur détruite en silence, sans que rien n'échoue dans le fold, est précisément ce que l'étape de préparation de §3 existe pour empêcher, et l'espèce de cellule est ce qui lui permet d'empêcher aussi ce cas-ci.

Deux primitives supplémentaires complètent le modèle :

Cellules à écriture 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 ; une signature issue de sa clé la fait passer à dépensée, définitivement. Écrire dans une cellule neuve est sans conflit par définition, si bien que payer une adresse nouvellement dérivée est le chemin rapide à contention nulle. C'est là l'héritage chimérique du réseau [8] : des cellules persistantes de style compte pour les contrats, des cellules à usage unique de style UTXO pour les paiements, dans un même registre. Les valeurs sous une cellule dépensée sont compactables une fois que le bloc qui l'a dépensée est enfoui plus profond que l'horizon de réorganisation — une profondeur en confirmations, non un dispositif de finalité, puisque l'ère de lancement n'a aucune finalité à attendre. L'entrée du registre qui consigne l'adresse comme dépensée n'est jamais compactée : c'est elle qui empêche l'adresse d'être ressuscitée, et c'est là le problème ouvert que le protocole assume honnêtement, partagé avec toute conception à ensemble de nullificateurs. Les sorties furtives de §12 empruntent ce rail sans changement, et font croître le registre exactement au rythme où les paiements transparents le font déjà : une entrée par dépense, dissimulée ou non.

Zéro vaut absence. Un slot qui n'a jamais été écrit et un slot écrit à zéro sont le même slot : écrire zéro supprime la cellule, et lire une cellule absente donne zéro. Ce n'est pas une commodité d'implémentation mais une exigence de consensus, et elle est porteuse à deux titres. C'est elle qui permet à une garde ou à une lecture exacte de nommer 0 sans avoir à demander si le slot existe — il n'y a pas de troisième réponse à lever. Et c'est elle qui fait que la racine d'état reste une fonction de l'état plutôt que de l'historique qui l'a produit : si une cellule vidée subsistait sous forme de zéro explicite, deux nœuds parvenus à des soldes identiques par des chemins différents s'engageraient sur des racines différentes, ce qui est une scission de chaîne survenant par comptabilité.

Cela contraint §12, avec une arête vive. Un engagement de Pedersen vG + rH n'est en général pas la chaîne nulle, si bien qu'un solde dissimulé ne devient pas absent par arithmétique et que nul autre que le propriétaire ne peut savoir qu'il est vide ; des slots dissimulés persistants seraient à jamais incompactables, ce qui est une raison de plus pour que le rail protégé ne repose que sur des cellules à usage unique, mourant en étant dépensées — une transition que « zéro vaut absence » n'a jamais eu à fournir. L'arête vive est que v = 0, r = 0 est l'élément neutre du groupe, et que dans un encodage Ristretto l'élément neutre est trente-deux octets nuls — la chaîne même qui signifie absent. Un engagement ne doit jamais entrer en collision avec une suppression : l'élément neutre n'est donc pas un engagement valide ; l'opération protégée le rejette à l'entrée, aux côtés des contrôles d'encodage canonique dont un point de courbe a déjà besoin (éléments de corps non canoniques, composantes de torsion), et le H de référence est un point NUMS à dérivation publiée. « L'égalité octet à octet est exacte » (§3) n'est une affirmation sur des points qu'une fois ces conditions réunies.

La balise d'époque. Les programmes ne doivent pas lire directement des valeurs ambiantes (horodatage, hauteur) ; cela ferait de l'exécution une fonction d'autre chose que des lectures déclarées. À la place, le protocole écrit une balise d'époque dans un slot réservé une fois par époque, et les programmes la lisent comme n'importe quel autre slot, idéalement avec une garde d'intervalle (epoch ∈ [e, e+2]), ce qui procure une conscience du temps sans péremption à chaque bloc.

5. Certificats garantis : tout conflit a un propriétaire#

L'omission ne doit pas être gratuite, sinon le mempool se noie : un attaquant pourrait publier des milliers de certificats valides contre la même entrée, remplir des blocs et n'en payer qu'un. Mais les certificats omis n'ont jamais touché le solde de l'expéditeur, il n'y a donc rien à lui facturer ; le slot des frais est précisément l'entrée périmée. La réponse de Zycord : aucun certificat n'existe sans garant, une partie dont les fonds cautionnés en répondent.

Il y a trois façons d'être garanti, un seul mécanisme sous trois formes :

1. Auto-garanti. L'expéditeur attache un petit dépôt issu d'une cellule non grevée. Rien n'est loué à l'avance : le fold réserve le dépôt à la position du certificat dans le bloc (le schéma de §3 escamote cette plomberie), et un certificat qui atteint l'application alors que son dépôt est déjà consommé est rejeté — non facturé, non marqué comme vu, libre d'être resoumis contre un dépôt neuf — de sorte que les utilisateurs honnêtes ne perdent rien aux courses sur leur propre cellule de dépôt. Une omission avec le dépôt intact en brûle une partie. Publier, en revanche, ne coûte rien : le mempool est donc borné par la politique de relais plutôt que par le consensus ; les nœuds plafonnent ce qu'ils acceptent de retenir par garant, la même division du travail que dans tous les mempools depuis celui de Bitcoin. C'est le plancher sans permission : n'importe qui peut toujours transiger sans contrepartie. C'est aussi le seul mode de l'ère de lancement (§14), ce qui garde la genèse minimale. La cellule de dépôt est publique et elle appartient à l'expéditeur, ce qui fait de l'auto-garantie un identifiant persistant agrafé à chaque certificat qu'elle signe. Pour les paiements transparents, cela ne révèle rien que le paiement ne révèle déjà ; pour un paiement protégé (§12), cela défait la sortie furtive qu'il paie, et c'est exactement pour cette raison que §12 se tourne vers la cosignature.
2. Cosigné. Un garant cautionné contrôle le certificat contre un état frais, cosigne (certificate, ttl, seq) et assume la responsabilité en cas d'omission. En échange, il peut facturer l'expéditeur hors bande, et sa cosignature est un produit : une pré-confirmation derrière laquelle se tient le capital propre d'un garant. Rien dans ce rôle n'exige de voir ce qu'un certificat déplace : la péremption est une propriété des cellules — vivantes ou dépensées — et non des montants ; un garant tarife donc un certificat protégé comme il tarife un certificat transparent, sans qu'on lui confie la valeur.

Deux choses que cette promesse ne doit pas laisser se confondre, car l'article les a déjà confondues par le passé. La réponse du protocole à une omission est de brûler les frais d'omission prélevés sur le dépôt du garant — une pénalité, versée à personne, et c'est ce qui empêche quiconque de tirer profit des omissions qu'il provoque. Indemniser l'expéditeur est une autre transaction : c'est la promesse commerciale du garant, et cette conception ne la spécifie pas encore comme mécanisme de consensus. En faire un n'est pas affaire de formulation — il y faut une valeur de police déclarée dans la cosignature, un bénéficiaire nommé qui ne soit pas l'expéditeur (sans quoi le produit est une invitation à la fraude à l'assurance), et une exposition agrégée suivie sur la chaîne pour qu'une caution ne puisse pas être vendue deux fois. Tant que cela n'existe pas, « ma caution paie » est une affirmation qu'un garant avance et qu'un marché tarife, non une règle que le fold impose, et l'article le dit plutôt que de laisser l'ambiguïté vendre le produit.

1. Forcé. Le chemin de résistance à la censure (§7), garanti par un dépôt utilisateur et, fait unique, dont l'application est garantie. L'économie est asymétrique entre deux formes de mauvaise conduite, et l'asymétrie est le point même :

Les fautes objectives sont sanctionnées par slashing. Si un même garant cosigne deux certificats dont les lectures exactes entrent en conflit (même slot, même valeur déclarée, TTL qui se recouvrent), les deux signatures constituent une preuve d'équivocation autoportante et on-chain ; n'importe qui peut les soumettre, et la caution est slashée. De même, un garant qui cosigne un certificat qui échoue à la validité sans état (une mauvaise signature, une exécution erronée) est slashé par simple réexécution : le certificat est la preuve de fraude (§9).

Les fautes subjectives ne sont jamais sanctionnées par slashing. Deux garants différents en course sur le même slot n'ont commis aucune faute prouvable ; le second dans l'ordre du fold encaisse de petits frais d'omission, rien de plus. Les garants lents, hors ligne ou peu fiables perdent leur éligibilité et leur réputation, non leurs fonds. Les réseaux meurent quand la latence devient une confiscation ; Zycord ne confisque que ce qui se prouve à partir des octets.

Et la facture retombe sur une partie que le certificat nomme. Le titre de cette section est un théorème plutôt qu'un slogan, et il mérite d'être énoncé avec ses bords. Une omission facturée est toujours exactement l'une de trois choses : la lecture ou l'écriture défaillante relève d'une adresse dont la clé a signé le certificat ; ou bien c'est une émission en course avec une autre émission du même émetteur déclaré de l'actif, lequel a lui aussi signé ; ou bien c'est un crédit vers une adresse à usage unique que son propre détenteur a retirée (RETIRE, §11) après la signature du certificat. Aucune partie que le certificat ne nomme pas ne peut faire qu'il soit facturé. Seul le troisième cas sépare la facture de sa cause, et il est borné par construction : seules les cellules à usage unique peuvent être retirées, si bien qu'un bénéficiaire qui publie une adresse persistante ne présente aucune surface ; un certificat peut retirer au plus un nombre fixe d'adresses (§13), ce qui plafonne le nombre de paiements en vol qu'une rafale de retraits peut toucher ; et les frais d'omission sont brûlés plutôt que versés, si bien que personne ne profite de les déclencher.

Le dimensionnement de la caution découle d'une seule inégalité : la caution d'un garant doit excéder la responsabilité d'omission maximale qu'il peut accumuler à l'intérieur d'une fenêtre de TTL, et la sortie de caution doit prendre plus de temps que la fenêtre des preuves de fraude, afin que nul ne puisse mal se conduire, retirer ses fonds et disparaître.

6. Séquenceurs applicatifs#

Les deltas gardés dissolvent la contention sur les paiements. Ce qui subsiste, c'est la logique à lecture exacte sur de l'état chaud — un carnet d'ordres, une réserve d'AMM — où deux garants honnêtes en course produiront encore des omissions. La réponse du protocole est de laisser le contrat choisir son sérialiseur : un contrat peut enregistrer, sur la chaîne, la clé d'un séquenceur cautionné, après quoi seuls les certificats cosignés par ce séquenceur peuvent emprunter le chemin à lecture exacte du contrat.

Le séquenceur est un serveur ordinaire opéré par l'équipe applicative — websockets, files d'attente, autoscaling, toute la machinerie du web 2 — et il n'est de confiance que pour la vivacité, jamais pour la sûreté. Il ne peut pas falsifier l'état : s'il ment sur les entrées lors de la construction, le certificat est simplement omis face au fold canonique, et le mensonge coûte à sa caution. Ce qu'il apporte :

Sérialisation. Il loue des slots aux certificats en vol avec des TTL courts et chaîne chaque certificat sur les sorties déclarées du précédent (il numérote ses cosignatures avec seq ; l'ordre total du fold garantit que son pipeline est validé dans l'ordre, quel que soit le brassage du proposeur). La contention sur les slots chauds devient un problème d'ordonnancement hors chaîne, invisible pour la chaîne.

Certificats groupés. N transactions passant par le même chemin de code se replient en un seul certificat aux lectures et écritures agrégées, les écritures intermédiaires internes étant court-circuitées, et N sous-exécutions qui se vérifient comme une unique charge SIMT. C'est là que la thèse du GPU devient concrète : l'entité qui sérialise est aussi celle qui emballe le travail sous la forme que le matériel parallèle réclame, et elle est payée pour cela par le marché du gas parallèle (§8).

Composabilité atomique. Une transaction couvrant deux applications est coconstruite hors chaîne par les deux séquenceurs (une validation en deux phases sur des baux de slots) et atterrit sur la chaîne comme un seul certificat portant les deux cosignatures, atomique par construction. La coordination inter-applications a lieu là où la coordination est bon marché ; la chaîne ne voit que le résultat.

La divulgation honnête : un séquenceur voit en premier le flux d'ordres de son application et il est donc le lieu naturel de la MEV de cette application. Zycord rend l'arbitrage explicite : l'application capture sa propre MEV au lieu de la laisser fuir vers les proposeurs de blocs, et §7 borne le pouvoir que cela implique. Le même chemin forcé qui garantit la sortie discipline aussi l'extraction : un utilisateur à qui le traitement d'un séquenceur déplaît peut le contourner entièrement, ne payant que de la latence.

7. Inclusion forcée avec application garantie#

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

Un utilisateur (ou n'importe quel relayeur) reconstruit l'état à partir du fold public, construit un certificat, y attache un dépôt et le soumet à la file forcée. Les proposeurs doivent inclure les certificats en file dans un délai de F blocs (§13). À sa position d'inclusion, le fold contrôle ses lectures contre l'état courant ; si elles tiennent, le fold accorde un bail déterministe sur ses slots et programme l'application D blocs plus loin. Pendant le bail, les certificats cosignés qui touchent ces slots s'ordonnent après lui. Le certificat forcé ne peut donc pas être omis : l'admission implique l'application.

Le délai de grâce D est destiné au pipeline en vol du séquenceur honnête — la partie de ce pipeline qui ne touche pas les slots loués. Tout ce qui les touche s'ordonne après le certificat forcé, cosigné ou auto-garanti indifféremment, et c'est ce qui rend « ne peut pas être omis » vrai plutôt qu'aspirationnel : un certificat dont les lectures sont protégées pendant tout le délai de grâce ne peut pas se périmer pendant ce délai. Comme les écritures sont déclarées, l'état postérieur à l'application est prévisible : un séquenceur chaîne donc avec certitude par-dessus un certificat forcé non encore appliqué.

Un bail ne peut couvrir que des slots sur lesquels le certificat a autorité. C'est une contrainte que le mécanisme ne donne pas gratuitement et sans laquelle le reste de la conception ne survivrait pas. Déclarer une lecture n'exige aucune signature — seules les écritures dérivent une autorisation — de sorte que, sans cette règle, n'importe qui pourrait mettre en file un certificat forcé déclarant des lectures sur les slots d'autrui et les geler pendant D blocs au prix d'un dépôt. Le quota par contrat ne le borne pas davantage, puisque les paiements natifs n'appartiennent à aucun contrat. Un bail n'est donc admissible que sur des slots que le certificat a le droit d'écrire, ce qui est le même test d'autorité que le fold applique déjà, employé une étape plus tôt.

Autres bornes anti-nuisance : un quota par contrat et par époque ; un dépôt couvrant le coût imposé ; les slots loués refusent toute nouvelle entrée forcée jusqu'à leur libération.

Deux conséquences élèvent ce dispositif du rang de fonctionnalité à celui de mécanisme de survie. Premièrement, la censure s'inverse : elle coûte au censeur (frais perdus, utilisateurs qui le contournent) et ne coûte rien au réseau. Deuxièmement, un contrat dont le séquenceur disparaît — ou une chaîne dont toute la classe des garants est attaquée — se dégrade en mode forcé seul : lent, coûteux, et vivant. Aucun état n'est jamais orphelin, et aucun opérateur n'est porteur pour la sûreté. Pour un réseau conçu pour survivre à son fondateur, c'est la propriété qui compte.

8. 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, mutation — et les tarifer sur un marché unique revient à faire concourir en enchère la vérification d'une preuve à divulgation nulle avec une écriture en mémoire. Zycord scinde les frais en deux marchés indépendants :

Le gas séquentiel tarife les opérations du fold : contrôles de lecture, écritures, baux. C'est la ressource rare, l'unique boucle que chaque nœud exécute dans l'ordre, et elle est tarifée en conséquence.

Le gas parallèle tarife la vérification : contrôles de signature, unités de réexécution, octets, et précompilés lourds (vérification de preuves, agrégation de signatures, schémas post-quantiques). Il est abondant, son offre croissant avec chaque cœur et chaque GPU ajoutés au réseau, et son plafond par bloc est fixé haut et bon marché.

Les deux marchés ont la forme d'EIP-1559 [15], chacun dans son unité propre : les frais de base sont brûlés et les frais de priorité rémunèrent le producteur du bloc — sur les certificats qui s'appliquent, et sur ceux-là seulement. Les frais d'un certificat omis sont brûlés intégralement et ne rémunèrent personne, et ce n'est pas un détail de la grille tarifaire mais la règle porteuse de tout le modèle économique. Si une omission donnait un pourboire, la partie qui choisit le contenu d'un bloc serait payée pour orchestrer les échecs d'autrui, et la façon la moins coûteuse de gagner serait de cultiver les omissions plutôt que d'inclure du travail. Le brûlage inverse cela : une omission consomme du plafond et ne rapporte rien, si bien qu'un producteur qui maximise son revenu maximise l'application, et non seulement il est indifférent à provoquer des omissions mais il y est activement hostile. Brûler les frais de base séquentiels rend déflationniste la congestion de l'unique boucle rare (§14.2). Brûler les frais de base parallèles maintient le proposeur indifférent à savoir quels certificats lourds remplissent la voie bon marché, de sorte que la priorité sur la voie de vérification ne puisse pas être vendue hors livre. Cette scission suit la direction des conceptions de frais multidimensionnelles [18], poussée jusqu'à des marchés entièrement séparés. Ce qu'aucun des deux marchés ne décide, c'est la quantité de ressource rare qui devrait exister ; cela relève d'un plafond, et §8.1 donne la règle qui le déplace.

La conséquence est l'objectif de conception énoncé comme invariant : la cryptographie lourde n'affecte pas le réseau, par construction économique. Un certificat qui vérifie une grande preuve mais n'écrit que deux slots paie presque tout sur le marché bon marché. Zycord se positionne ainsi comme la couche de règlement où les protocoles cryptographiques trop lourds pour les chaînes à marché unique deviennent économiques. Le même marché rémunère les séquenceurs pour la mise en forme du travail : un séquenceur agrège N transactions en un certificat groupé, paie une enchère parallèle pour lui, et facture ses utilisateurs pour N — la marge est le prix de la mise en forme SIMT du travail (§6).

8.1 Le plafond séquentiel élastique#

Un marché de frais tarife la rareté ; il ne décide pas de la quantité de rareté qu'il devrait y avoir. Les deux réponses antérieures à cette question ont toutes deux échoué, dans des directions opposées. Un plafond fixe transforme l'adoption en une enchère que les utilisateurs perdent : quand les blocs de Bitcoin se sont remplis, les frais ont dépassé 50 dollars et les paiements ordinaires ont été purement et simplement chassés de la chaîne par le prix, au seul bénéfice de qui vendait l'espace. Un plafond ouvert sans demande échoue dans l'autre sens : ses forks à gros blocs ont acheté une capacité que personne n'a utilisée et l'ont payée en sécurité, car ce sont les volumes, et non la place, qui produisent les frais. Le plafond de Zycord n'est donc ni fixe ni voté — un réseau dont l'auteur ne sera pas là pour le forker ne peut pas traiter une croissance de routine comme un événement de gouvernance, et un vote est une prise : les mineurs profitent d'une offre restreinte, les gros opérateurs d'une offre étendue au-delà de ce que les petits nœuds peuvent suivre. Le plafond est une fonction de consensus de la demande mesurée, présente dans la genèse dès le bloc 0, et que nul ne déplace.

La règle comporte trois volets, un par échelle de temps. À l'intérieur d'un bloc, chaque marché a une cible T et une borne élastique stricte 2T ; les frais de base se rapprochent de l'équilibre par une fraction bornée à chaque bloc, dans la forme EIP-1559 de §8 — bornée parce qu'un ajustement non borné est connu pour osciller au lieu de converger. D'une époque à l'autre, la cible séquentielle suit la demande : T ← clamp(2·median_applied(e), T − T/Δ, T + T/Γ), avec un plancher à sa valeur de genèse — où median_applied ne compte que le gas séquentiel des certificats appliqués. Les certificats omis brûlent leurs frais et n'enregistrent rien, si bien que la seule façon de relever le plafond est de remporter l'application : un usage soutenu, non conflictuel, qui brûle des frais de base. Forcer la croissance coûte à un attaquant exactement ce que l'adoption organique coûte à tout le monde, c'est-à-dire que le mécanisme ne peut pas les distinguer et n'a pas besoin de le faire. La croissance est en outre conditionnée à un signal de santé d'époque — le taux observé d'en-têtes concurrents reste sous un seuil (Ère 0), les points de contrôle finalisent dans les temps (à partir de l'Ère 1) — de sorte que la capacité ne dépasse jamais ce que la propagation porte de façon démontrable. Un bloc orphelin est précisément l'événement que la chaîne n'enregistre pas ; le signal est donc importé de la seule manière honnête : les en-têtes peuvent citer des en-têtes concurrents récents, sans rémunération ; citer exige une véritable preuve de travail, tandis que supprimer le signal exigerait que presque tous les proposeurs omettent des citations qu'un seul honnête restaure. L'asymétrie fait pencher le garde-fou vers la prudence, ce qui est la direction vers laquelle un garde-fou doit pencher. Par bloc, une soupape de rafale : un proposeur peut dépasser 2T jusqu'à 4T, en abandonnant de façon quadratique ce que le bloc lui crédite — sa part de subvention plus les frais du bloc, au regard du calendrier de §14.2, sous forme d'un manque à gagner permanent redirigé vers personne — la pénalité étant calculée sur le gas séquentiel total, appliqué comme omis, afin que l'excédent ne puisse pas être bourré de conflits fabriqués à prix réduit. La base est le revenu du producteur et non sa seule subvention, parce que les deux ne décroissent pas ensemble : la subvention tombe à environ 1,6 % de sa valeur de genèse sur la courbe de §14.2, tandis que le revenu de frais pour lequel une rafale est achetée ne baisse pas du tout ; un moyen de dissuasion libellé en subvention seule cesse donc de dissuader exactement là où l'occasion est la plus grande. Une propriété permanente doit être tarifée en quelque chose qui suit le bénéfice, ce qui est l'argument qu'EIP-1559 avance pour coupler une charge à la valeur que la manipulation rapporte. À la genèse, cela ne change presque rien, les frais étant proches de zéro. La part de trésorerie de §14.1 est prélevée sur la subvention non réduite et n'est jamais abandonnée, car la rafale est le choix du producteur et la trésorerie n'y est pas partie. Les véritables pics d'activité achètent un passage immédiat et informent le contrôleur d'époque ; le spam achète une pénalité. Le précédent est le mécanisme à médiane pénalisée de Monero [19], dont le blocage documenté — la croissance se figeant lorsque l'unité de travail typique approche la médiane — est évité par construction, puisque les certificats groupés (§6) maintiennent l'unité typique petite devant la cible, et les bornes de taux suivent la lignée des limites adaptatives [20]. Le plafond parallèle n'exige aucune de ces précautions : il est épinglé comme un multiple élevé et fixe de la cible séquentielle et hérite de sa croissance, ce qui est l'invariant de §8 reformulé en termes de capacité.

Lisez le bras de fer à même le mécanisme. Les frais de l'utilisateur gravitent vers le plancher, parce qu'une congestion soutenue est, par définition, le signal qui relève le plafond puis le rabaisse — l'équilibre bitcoinien d'enchère permanente est inatteignable. Le producteur est rémunéré par la subvention tant que le réseau est jeune, et par le volume à maturité, jamais par la rareté ; le brûlage fait que chaque épisode de congestion revient à la pièce que le producteur détient, et §8 a déjà fait de l'application, non de l'exclusion, la stratégie qui maximise le revenu. Une honnêteté, à deux titres : l'élasticité garantit seulement que la capacité n'est jamais la raison pour laquelle l'adoption stagne — elle ne fabrique aucune demande, comme les forks à gros blocs l'ont prouvé — et un plafond qui croît laisse croître l'état, ce qui explique pourquoi les écritures dans des slots neufs se tarifent au-dessus des deltas en gas séquentiel : la table plate où vit le fold ne s'étend pas plus vite que le plafond qui l'alimente. Une règle de calibrage en découle, énoncée parce que sa violation est silencieuse : le rapport, à la genèse, entre la cible séquentielle et le plafond en octets doit se situer sous la densité du trafic pour lequel le réseau est bâti, afin qu'un bloc plein de paiements ordinaires relève les frais de base plutôt que de les abaisser. Un marché qui répond à l'envers à sa propre charge de conception ne tarife rien, et le rapport est fixé à partir du trafic mesuré avant le gel.

Capacité au fil des ères. Les plafonds de nombre de certificats et d'octets évoluent avec la cible séquentielle plutôt que de rester fixes à ses côtés : à la genèse, les trois se tiennent à un facteur deux les uns des autres, si bien qu'un plafond fixe deviendrait la véritable limite après un seul doublement et rendrait l'élastique décoratif. Derrière eux se tiennent des capacités statiques : la largeur de la liste de certificats, qui fixe la profondeur du merkle d'un bloc, et la capacité en octets qu'un bloc peut atteindre, appariée aux constantes de transport sous-jacentes — un bloc voyage par fragments, si bien qu'aucun message réseau unique ne borne un bloc. La largeur de la liste est dimensionnée à la genèse pour toute la courbe (2²⁵ certificats ; la réépingler plus tard mettrait deux largeurs de merkle dans une même chaîne, et le remplissage virtuel rend la marge gratuite). La capacité en octets est dimensionnée pour le réseau de lancement et réépinglée aux frontières d'ères — déjà des hard forks (§14) — au regard d'une propagation que le garde-fou de santé a mesurée ; jamais au sein d'une ère, jamais par vote. La courbe que cette échelle dessert découle de Γ : la cible se compose au plus par 2× par année de blocs pleins et sains, si bien que le plafond de genèse de ~90 certificats appliqués par seconde (un bloc de §15 par intervalle de 30 secondes) atteint ~11 000 par seconde en sept ans de demande soutenue, ~90 000 en dix, et en moins de quatorze les ~1,1 million par seconde que fixe la largeur de liste de 2²⁵ — l'unique mur qu'aucune ère ne déplace, et donc la fin de l'échelle plutôt qu'un barreau de celle-ci. L'unité est le certificat, non le paiement : un certificat transporte un paiement, ou les N qu'un séquenceur y a groupés (§6), si bien que chaque chiffre est un plancher sur les transactions et non une affirmation à leur sujet. Les conditions sont exactement au nombre de trois, chacune déjà un mécanisme exposé plus haut : la demande doit soutenir des blocs pleins, car le gas appliqué est le seul intrant qui relève T ; la propagation doit maintenir le garde-fou de santé ouvert, car la croissance est retenue l'époque où il se ferme ; et les réépinglages doivent tomber aux ères, car entre elles la capacité en octets est le mur. Le calcul n'est pas une condition — le fold franchit l'extrémité lointaine de la courbe sur un seul cœur mesuré (§15), et la vérification passe à l'échelle avec du matériel que le réseau ne possède pas (§2). La bande passante, elle, en est une : les corps sont des données de chaîne (§13) et l'échantillonnage (§9) divise la vérification, jamais les données, si bien que chaque nœud porte chaque octet, et un producteur au sommet de la courbe relève du centre de données par la seule bande passante — un état final accepté pour les producteurs, et pour personne d'autre, puisque le coût de vérification par nœud évolue en sens inverse (§9). Avant que la bande passante ne devienne contraignante, l'état l'est : le registre des adresses dépensées (§4) croît d'une entrée par dépense à usage unique, de l'ordre de 10² téraoctets par an à 10⁵ certificats par seconde, ce qui transforme le problème ouvert déclaré en §4 d'un point permanent en un travail que la courbe met à l'agenda.

Constantes (genèse, à titre indicatif, comme en §13) : diviseur de croissance Γ = 512 par époque (le plafond peut au plus doubler par année de blocs pleins) ; diviseur de décroissance Δ = 1024 (une capacité inutilisée est divisée par deux en ~2 ans, jamais sous la valeur de genèse) ; borne de rafale 4T, abandon de la part de subvention du producteur et des frais du bloc à la borne (la part de trésorerie de §14.1 est prélevée sur la subvention non réduite et n'est jamais abandonnée, car la rafale est le choix du producteur et la trésorerie n'y est pas partie) ; garde-fou de santé : en-têtes concurrents cités ≤ 2 % des blocs par époque ; capacité de la liste de certificats 2²⁵ (structurelle, cf. ci-dessus) ; plafond en octets de 2,5 Mo à la genèse, évoluant avec la cible jusqu'à une capacité structurelle en octets de 8 Mo (réépinglée aux ères) ; plafond de signatures par bloc de 6 000 à la genèse, évoluant avec la cible, contrôlé avant qu'aucune signature ne soit vérifiée — une borne sur la vérification, tenue distincte du prix du gas parallèle, car un même paramètre ne peut pas à la fois borner le travail et tarifer le marché.

9. Preuves de fraude instantanées et la voie de l'échantillonnage#

Parce que la validité est une fonction pure des octets d'un certificat, un certificat invalide est sa propre preuve de fraude. Quiconque le réexécute peut le réfuter en un message, immédiatement, sans état et sans jeu interactif de dichotomie. Dans la configuration de lancement, la question est sans objet de la meilleure façon qui soit : chaque nœud vérifie chaque certificat avant d'accepter un bloc, si bien qu'un certificat invalide ne survit jamais assez longtemps pour appeler une contestation. La fenêtre prend son sens une fois la vérification échantillonnée, et elle y est un paramètre de propagation plutôt qu'un protocole de litige : une poignée de blocs pour qu'un message traverse le réseau, à la charge du garant qui a attesté du certificat (§5). Comparez les alternatives : les rollups optimistes exigent des litiges interactifs longs d'une semaine parce que contester requiert l'état à l'étape contestée ; les systèmes fondés sur les preuves évitent les litiges mais paient des prouveurs qui coûtent des ordres de grandeur de plus que l'exécution. Les preuves de fraude de Zycord coûtent ce que coûte la vérification : ~1× une réexécution.

Cela ouvre la voie de passage à l'échelle que les chaînes à réexécution ne peuvent pas emprunter. Le réseau n'a pas besoin, en principe, que chaque nœud vérifie chaque certificat à jamais. Une fois les cautions de garants en place, la vérification peut être échantillonnée : un comité par certificat sélectionné par VRF, dimensionné de sorte que la probabilité qu'un certificat invalide reste non vérifié soit négligeable, tout nœud complet restant libre de contrôler n'importe quoi et un seul message suffisant à slasher. À la genèse, tout le monde vérifie tout ; c'est bon marché et parallèle. L'échantillonnage relève de la feuille de route, non du lancement. Mais c'est la feuille de route qui inverse la courbe du secteur : le coût par nœud décroît à mesure que le réseau grandit, là où le coût par nœud du paradigme de la réexécution croît avec le débit jusqu'à ce qu'il ne reste que des centres de données.

10. La machine : cEVM#

Zycord fait tourner une seule machine virtuelle : la cEVM, un dialecte de l'EVM d'Ethereum [2] adapté aux certificats. Le choix est délibéré. Le budget de nouveauté du projet est dépensé dans le modèle d'état, de concurrence et d'économie ; la machine devrait être la chose la plus familière du système. Solidity, ses compilateurs, ses auditeurs et son outillage sont repris tels quels.

Différences avec l'EVM standard :

• SLOAD se compile en une lecture exacte (déclarée dans le certificat) ; SSTORE en une écriture SET.
• De nouveaux opcodes SASSERT(slot, pred) et SDELTA(slot, ±v) exposent les deltas gardés et purs. Un SASSERT n'empile rien — les gardes ne renvoient pas de valeurs (§4).
• TIMESTAMP et NUMBER lisent le slot de la balise d'époque ; il n'y a pas d'autre entrée ambiante.
• Le comptage du gas est double (§8) : les opcodes de stockage comptent en gas séquentiel ; le calcul, les calldata et les précompilés comptent en gas parallèle.
• Le format de transaction est le certificat. Les contrats Ethereum se portent au niveau des sources ; la compatibilité brute avec les portefeuilles n'est pas revendiquée, et nous ne prétendons pas le contraire. Un contrat porté tourne en mode tout-exact : correct dès le premier jour, sérialisé via un séquenceur s'il est chaud. Le parallélisme s'active à la demande, slot par slot, généralement au prix d'un petit diff (la table de soldes d'un jeton passe de SLOAD/SSTORE à SASSERT/SDELTA en ~30 lignes). Afin que la fonctionnalité phare soit visible dès le premier bloc de l'ère VM plutôt que d'attendre des portages, la machine s'active de pair avec une bibliothèque standard native — jeton, cagnotte à pourboires, séquestre, acquisition progressive, et un carnet d'ordres/AMM hybride de référence — écrite en priorité delta et pré-déployée à des adresses connues.

11. Des actifs sans machine#

L'ère de lancement a besoin d'une économie avant d'avoir besoin d'un ordinateur. Zycord livre donc des actifs natifs sous forme d'opérations de certificat dès le bloc 0, sans aucune VM : ISSUE (créer un identifiant d'actif avec un plafond d'offre dans une cellule à écriture unique), MINT (gardé : minted + Δ ≤ cap), TRANSFER (garde balance ≥ Δ, deltas appariés ; un crédit visant un delta pur ou une cellule neuve à usage unique est le pourboire, si bien que donner un pourboire ne dépense aucun opcode propre), et RETIRE (brûler une adresse sans la dépenser : aucune lecture, aucune valeur déplacée, une écriture pure qui marque la cellule comme dépensée — la dépense proprement dite est automatique à l'intérieur de TRANSFER). RETIRE mérite sa place à double titre. C'est la primitive de compaction et de confidentialité, qui permet à un bénéficiaire d'effacer une adresse à usage unique dès qu'elle a servi ; et c'est l'opération qui sous-tend l'unique exception au théorème d'attribution de §5 — le troisième cas existe parce que le retrait existe, ce qui explique que le format de certificat plafonne le nombre d'adresses retirées par certificat (§13) et que le théorème soit énoncé avec ce bord plutôt qu'en le contournant. L'ensemble est clos : ces quatre opérations constituent tout le jeu d'instructions de la genèse, toute autre opération — le cautionnement compris — arrive avec le jeu de règles d'une ère ultérieure (§14), et le théorème d'attribution de §5 est prouvé contre exactement cette surface.

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. Les cultures du pourboire sur les chaînes antérieures vivaient au bon vouloir des API de plateformes et sont mortes avec elles ; ici, le pourboire est une primitive du protocole. C'est aussi, non par accident, un test de charge continu de l'affirmation centrale du système. Les plafonds d'offre de la pièce native vivent ici, sur le rail transparent, imposés par l'arithmétique contrôlée de §3, et §12 les laisse intacts.

12. Paiements confidentiels#

Les sections précédentes traitent le montant d'un paiement comme public. Cette section ajoute la possibilité de le dissimuler, et de dissimuler le destinataire derrière une adresse à usage unique, tout en préservant les propriétés des sections précédentes. La conception est plus étroite que les systèmes dont elle dérive : chacune des restrictions ci-dessous referme une attaque à laquelle une conception plus générale répondrait par une machinerie plus lourde.

Ce qui est dissimulé, et ce qui ne l'est pas. Un paiement protégé dissimule son montant et diffère le lien vers son destinataire. Soyons précis sur « diffère » : une sortie furtive fraîche est non liable au moment où elle est reçue, mais faute d'anneau, la dépenser plus tard nomme la sortie dépensée, et nommer la sortie révèle quel paiement antérieur l'a financée. La non-liabilité tient jusqu'à la première dépense et s'y arrête ; c'est un délai, non un effacement. La conception ne dissimule pas non plus la position de l'expéditeur dans le graphe : les certificats sont signés, garantis et ordonnés en public, si bien qu'un observateur voit qu'un paiement a eu lieu et qui l'a garanti — pas le montant, et pas, tant qu'une dépense ne le divulgue pas, laquelle des sorties d'un destinataire est allée où. La description honnête est : des transactions confidentielles avec adresses de destinataire à usage unique sur un graphe public, et le graphe désanonymise rétroactivement à mesure que les sorties sont dépensées. L'ambiguïté côté expéditeur — signatures en anneau, preuves d'appartenance sur des sorties historiques — est hors périmètre : un anneau référence les sorties d'autrui, ce qui fait de la validité une fonction de l'historique, or l'absence d'état de §2 est la propriété à laquelle le protocole ne renonce pas. Le modèle de menace de Monero exige un autre protocole.

La sortie protégée. Un paiement protégé écrit une cellule à écriture unique fraîche (§4) dont l'adresse est une adresse furtive : l'expéditeur dérive, à partir de la clé de vue publiée du destinataire et d'une clé éphémère qui lui est propre, une adresse à usage unique que seul le destinataire peut reconnaître et pour laquelle seule la clé de dépense du destinataire peut signer. La valeur de la cellule est un engagement de Pedersen C = vG + rH ; l'accompagnent une preuve d'intervalle que v ∈ [0, 2⁶⁴) et le couple (v, r) chiffré vers la clé de vue du destinataire, plus une étiquette de vue d'un octet qui permet à un portefeuille en balayage d'écarter tôt la plupart des sorties étrangères. Les primitives sont les transactions confidentielles avec adressage furtif : la moitié « dissimulation des montants » de RingCT sans l'anneau, chacune ayant un déploiement en production établi.

La validité reste une fonction des octets. Le contrôle d'équilibre d'un certificat protégé est l'équation des engagements : les engagements d'entrée déclarés moins les engagements de sortie déclarés égalent fee·G, avec des frais publics (voir la réserve ci-dessous). L'équation, les preuves d'intervalle et les signatures sont toutes contrôlées à partir des seuls octets du certificat, dans l'étape parallèle, par lots : la vérification Bulletproof s'amortit logarithmiquement sur un lot, et rien de tout cela ne touche l'état. Un certificat inflationniste forgé — dont les engagements ne s'équilibrent pas sous une hypothèse rompue ou un vérificateur défaillant — reste valide ou invalide purement par ses octets, et le fold ne le recontrôle jamais ; c'est la scission valide/applicable de §2 fonctionnant comme prévu, non une exception à celle-ci, et la règle de la réserve ci-dessous est ce qui empêche une rupture de solidité d'être sans borne. C'est aussi là que le double marché de frais (§8) cesse d'être un argument d'efficacité pour en devenir un argument d'habilitation : sur une chaîne à marché de gas unique, les transactions confidentielles sont coûteuses parce qu'une milliseconde de vérification de preuve concourt dans la même enchère qu'une écriture en mémoire, alors qu'ici la vérification retombe entièrement dans par_gas — bon marché par conception — et le marché séquentiel ne la voit jamais.

Le fold range des octets. À l'application, un paiement protégé est le certificat le moins coûteux que le fold rencontre : sa cellule de sortie est neuve, elle ne peut donc pas entrer en conflit (le chemin rapide à contention nulle de §4) ; ses cellules d'entrée sont vivantes ou dépensées, une simple consultation de registre ; et l'écriture range 32 octets d'engagement. Aucune arithmétique sur courbe n'entre dans l'étape séquentielle (§3). L'alternative que la règle exclut est un « slot d'accumulation » persistant, crédité de façon homomorphe par des inconnus, qui échoue sur trois fronts : elle place une addition sur courbe dans la boucle séquentielle (§3) ; elle crée un identifiant public réutilisé, l'heuristique de propriété commune que l'adresse furtive est censée éviter ; et un solde persistant dissimulé invite les gardes de tiers que §4 interdit. L'accumulation se fait dans le portefeuille : un destinataire détient de nombreuses sorties à usage unique, toutes reconnaissables au moyen d'une seule clé de vue, et les consolide en dépensant plusieurs de ses propres cellules dans une seule cellule fraîche, un certificat protégé ordinaire, au rythme qui lui convient, avec la balise d'époque (§4) pour horloge. La somme qu'un slot persistant maintiendrait sur la chaîne est maintenue hors chaîne par le propriétaire — et la consolidation n'est pas sans trace : déclarer plusieurs entrées dans un même certificat est un événement public de propriété commune, plus faible qu'un identifiant réutilisé mais réel ; la politique du portefeuille est donc de la minimiser et de ne jamais mêler des origines sans rapport dans une même consolidation.

Dépenses réservées au propriétaire, et ce que cela interdit. Une valeur dissimulée n'est dépensable que par la signature de son propriétaire sur sa propre cellule. Il n'existe aucune garde de tiers contre les soldes dissimulés (§4) et donc aucun paiement à l'initiative du bénéficiaire sur le rail protégé : pas d'autorisations de dépense, pas d'abonnements, pas de coffre balayant les fonds protégés d'un utilisateur. Ces schémas restent sur le rail transparent, et la frontière entre les rails a la largeur d'un certificat. La restriction élimine l'oracle de solde : puisque aucun inconnu ne peut soumettre une supposition contre un solde et lire l'omission, l'oracle n'a plus d'opérateur.

La réserve protégée est un entier public que le fold impose. Les frais sont publics. Le coinbase est public. Les paiements vers des slots de contrat sont publics. Chaque passage entre le rail transparent et le rail protégé déplace un v publiquement visible — un certificat de mise à l'abri ouvre v à l'entrée, un certificat de sortie d'abri ouvre v à la sortie. Le total de la réserve vit donc dans un slot réservé, en clair, déplacé uniquement par delta gardé (§4) : la mise à l'abri le crédite, pool += v ; la sortie d'abri garde pool ≥ v et le débite, pool += −v ; les frais d'un certificat protégé le débitent de même. Le slot est exactement Σ entrées − Σ sorties, et la discipline du delta gardé permet à un nombre illimité de passages de commuter sans contention.

Cela fait de la réserve une clôture, non une alarme. Dissimuler les montants troque l'arithmétique u256 contrôlée de §3 contre la solidité calculatoire d'une hypothèse de logarithme discret, et une rupture — de l'hypothèse, ou bien plus vraisemblablement d'un vérificateur — forge des engagements à l'intérieur de la réserve. Mais un engagement forgé ne porte aucun texte clair, et la valeur ne quitte la réserve que par sortie d'abri, laquelle débite le slot public sous sa garde. Le slot n'a monté que sur des mises à l'abri réelles, si bien qu'une sortie d'abri qui le ferait passer sous zéro est omise : la valeur forgée ne peut pas franchir la garde. L'inflation ne vide pas la réserve ; elle échoue à en sortir. Le rayon de souffle d'une défaillance cryptographique est borné, par une règle du fold plutôt que par la vigilance d'un auditeur, au contenu réel de la réserve, et le mode de défaillance n'est pas un vidage silencieux mais une course visible en temps réel dans laquelle les derniers détenteurs honnêtes à sortir de l'abri ne le peuvent pas — mauvais, borné et observable, ce qui est le confinement qu'un système sans équipe d'intervention d'urgence doit posséder par construction. Le précédent est concret : le bug de contrefaçon de Zcash Sprout était survivable parce que sa réserve protégée était une quantité bornée et auditable ; ici cette quantité n'est pas seulement auditable, elle est porteuse dans le fold. Les plafonds d'offre natifs de §11 vivent sur le rail transparent et restent imposés par l'arithmétique contrôlée, intacts.

La réserve a un coût en confidentialité, et il doit figurer au dossier : les franchissements de frontière exposent des montants publics exacts, et des montants distinctifs se corrèlent. Un observateur qui voit v quitter la réserve peu après que v + fee y est entré a appris quelque chose qu'aucun engagement ne dissimulait. Des dénominations standard à la frontière émoussent cela, et les portefeuilles les adoptent par défaut ; le protocole ne les impose pas, car une règle de consensus ne peut pas distinguer un montant distinctif d'un montant légitime. La liabilité sous analyse de trafic est énoncée, avec sa mitigation, plutôt que niée.

Le garant est une métadonnée, et confidentialité et résistance à la censure ne coexistent pas dans un même certificat. Un certificat protégé auto-garanti nomme la cellule de dépôt publique de l'expéditeur, ce qui relie de nouveau ce que l'adresse furtive avait délié (§5) ; le trafic protégé emprunte donc la garantie cosignée, où l'identifiant d'un garant agrège de nombreux expéditeurs et où la foule fait la couverture. Le garant tarife la vivacité des cellules, non les valeurs (§5), et il n'apprend donc pas le montant — mais il apprend tout le reste de ce qu'est le certificat : l'expéditeur qu'il doit facturer hors bande et donc identifier, les cellules dépensées, les sorties furtives créées, et la chronologie. C'est précisément ce que veut une injonction judiciaire, et cela se compose vers l'avant à travers le graphe public avec la désanonymisation rétroactive décrite plus haut. C'est aussi un point de KYC structurel, car l'unique mode privé a un opérateur identifiable. Cela expose une limitation que l'article énonce sans détour plutôt que de la masquer : les deux modes de garantie sont le cosigné (privé, mais soumis à permission — un garant peut vous refuser) et l'auto-garanti ou forcé (sans permission, mais qui vous identifie). Le chemin forcé de §7 garantit qu'un utilisateur censuré peut toujours transiger ; il ne garantit pas qu'il puisse transiger en privé. Un utilisateur refusé par tous les garants conserve le droit de dépenser et perd sa confidentialité dans le même mouvement — et c'est exactement l'utilisateur pour qui la confidentialité comptait. Le rail protégé n'hérite de la résistance à la censure de §7 qu'au prix de sa propre confidentialité ; les deux propriétés ne tiennent pas dans un seul certificat.

Une ère, pas la genèse. Deux arguments indépendants fixent le calendrier. En pratique, les certificats protégés recourent à des garants cosignataires, qui existent à partir de l'Ère 1. Par le principe de §3, du code de consensus inatteignable est du code de consensus inauditable et n'est pas livré : le binaire de genèse ne contient aucun engagement, aucun vérificateur de preuve d'intervalle, aucun slot de réserve — rien dont l'unique appelant soit une ère future. L'ère protégée n'est pas purement additive, et l'article le dit : le typage des cellules dissimulées et l'interdiction des gardes de tiers de §4 touchent le chemin des gardes du fold, une surface critique dès la genèse ; l'ère modifie donc autant qu'elle ajoute, et son activation est un hard fork audité comme le changement critique pour le consensus qu'il est. Une ère qui ne prouve pas qu'elle vaut sa complexité n'est tout simplement jamais déclenchée, et la chaîne de genèse n'a rien perdu à ne pas la contenir.

Les coûts, énoncés sans détour. Un certificat protégé fait 3 à 5 fois la taille d'un certificat transparent — un à deux kilooctets, dominés par la preuve d'intervalle même après agrégation par lots — ce que le bloc dynamique (§8) absorbe économiquement et que la diffusion de §13 paie en bande passante. Les destinataires découvrent leurs paiements par balayage : chaque nouvelle sortie protégée est testée contre la clé de vue du portefeuille, un coût en O(n) sur le volume du réseau que les étiquettes de vue réduisent par un rejet précoce sur un octet, un facteur constant borné par la dérivation du secret partagé qui le précède. Le balayage est la principale charge d'expérience utilisateur du rail protégé ; un balayage externalisé qui ne livre pas la clé de vue est un problème ouvert que cette conception hérite plutôt qu'elle ne le résout. La politique de relais doit également changer sur ce rail, et non facultativement : publier un certificat est gratuit (§5, §13) alors que vérifier un Bulletproof ne l'est pas, si bien qu'un relais qui exécute le vérificateur avant qu'aucun coût ne soit imposé au publieur est un amplificateur de déni de service — le rail protégé exige un relais qui contrôle le bon marché avant le coûteux (signature et vivacité déclarée d'abord, preuve en dernier, quota par garant), ce qui fait passer le « borné par la politique de relais » du mempool du statut de valeur par défaut à celui d'exigence.

Questions ouvertes que cette section laisse à une version ultérieure, signalées plutôt qu'enfouies. Savoir si le rail protégé transporte seulement la pièce native ou aussi les actifs de §11 : un générateur unique H fait de vG + rH un engagement sur un scalaire, non sur un couple (actif, valeur), si bien qu'un rail protégé multi-actifs exige des générateurs par actif (Confidential Assets), ce qui modifie la taille des preuves et le facteur « 3 à 5× » ci-dessus ; jusqu'à décision, le rail est limité à la pièce native par règle, non par omission. Savoir si RETIRE (§11) agit sur les cellules protégées : si oui, de la valeur peut quitter la réserve sans sortie d'abri publique, si bien que le slot de réserve devient une borne supérieure (Σ entrées − Σ sorties ≥ contenu) et que la direction de la détection d'inflation doit être reformulée en inégalité ; si non, le rail protégé perd son ramasse-miettes et les sorties inouvrables (ci-dessous) s'accumulent. Savoir si le couple (v, r) chiffré vit dans le corps du certificat (bon marché aujourd'hui, irrécupérable si les corps sont élagués, ce qui fait échouer la restauration d'un portefeuille à partir de la seule graine) ou dans la valeur de la cellule (coûte de l'état par sortie, disparaît lorsque la cellule est dépensée, et s'accorde avec « l'accumulation se fait dans le portefeuille »). Et savoir si un garant peut cautionner un tiers tout en facturant à l'intérieur du certificat en valeur publique, ce qui supprimerait l'exigence d'identité ci-dessus et constitue la voie la plus prometteuse pour dépasser la limitation confidentialité/censure — ce sont là des questions de conception, non de formulation, et elles sont nommées ici afin que la prochaine version ne puisse pas en hériter en silence.

13. Réseau#

Les corps sont des données de chaîne. Les corps de certificats d'un bloc doivent être récupérables pour que le bloc soit valide ; l'état est donc toujours reconstructible à partir de la seule chaîne, et aucun opérateur — séquenceur compris — n'est jamais dépositaire de données. Les certificats sont plus gros que les transactions classiques (ils transportent lectures et écritures), et les mitigations sont structurelles : les certificats groupés court-circuitent les écritures internes (§6), et les cellules à usage unique dépensées se compactent une fois enfouies au-delà de l'horizon de réorganisation (§4).

Une troisième mitigation est prospective et elle est nommée comme telle plutôt que tenue pour acquise : une lecture pourrait référencer l'écriture d'un certificat antérieur par (cert_id, index) au lieu d'en répéter la valeur — l'astuce UTXO. Elle ne fait pas partie du protocole décrit ici, et elle n'en fera pas partie tant qu'une question n'aura pas de réponse, car cette question relève du consensus et non de l'encodage : que résout une référence lorsque le certificat qu'elle nomme a été omis, ou n'a jamais été inclus du tout. Une référence qui se résoudrait silencieusement à la valeur courante n'est plus une lecture déclarée, et la validité sans état meurt avec elle ; une référence qui échoue emporte des certificats dont la propre autorisation n'a jamais fait de doute. Une compression qui coûte la propriété sur laquelle toute la conception repose n'est pas une compression qui vaille, et le champ est donc absent tant que la sémantique n'est pas arrêtée.

Le relais procède par hash d'abord. Les certificats se propagent indépendamment par gossip et leur validité est contrôlée (sans état, en parallèle) à l'arrivée ; les blocs se relaient sous forme d'en-têtes et de listes de hashs rapportées au mempool, à la manière des blocs compacts [13], si bien que la latence de propagation ne croît pas avec le contenu des blocs. Un nœud de relais n'a besoin d'aucun état pour filtrer intégralement le spam — la validité sans état plus la signature du garant se contrôlent à partir des octets, ce qui rend l'exploitation d'une infrastructure de relais quasi gratuite sur le rail transparent. Le rail protégé (§12) est l'exception tarifée : son contrôle sans état inclut une vérification de preuve d'intervalle qui coûte trois ordres de grandeur de plus qu'une signature, si bien que là le principe de la publication gratuite devient un amplificateur, et le relais est tenu par la discipline « le bon marché avant le coûteux » et par les quotas par garant dont §12 fait une exigence plutôt qu'une préférence. Le relais d'un rail est quasi gratuit ; celui de l'autre n'est bon marché que parce que sa politique est obligatoire.

Paramètres (genèse, à titre indicatif). Blocs de 30 secondes ; TTL de certificat par défaut de 240 blocs (~2 h) ; adresses retirées par certificat ≤ 64 ; époque de 2 880 blocs (~1 jour) ; délai d'application forcée D = 4 blocs ; borne d'inclusion forcée F = 16 blocs ; fenêtre d'enjeu de déclenchement d'ère K = 14 époques (~2 semaines) ; part de trésorerie de 300 points de base (3 %) de la subvention de bloc dès le bloc 0, cellule scellée jusqu'à l'Ère 2, puis 3 signatures sur 5 sur un jeu de clés épinglé par hard fork, délai de rotation de clé R = 20 160 blocs (~7 jours) (§14.1) ; constantes d'émission en §14.2.

14. Lancement : trois ères, aucun premine#

Zycord est lancé sans premine, sans allocation aux fondateurs, sans tour d'investissement et sans clés d'administration. La genèse est reproductible à partir de sources publiées. Un testnet tourne d'abord ; ce n'est qu'une fois celui-ci stable qu'une date de mainnet est annoncée, ouvertement et à l'avance, afin que le bloc 0 soit atteignable par quiconque le souhaite. Ce qui est imposé à l'auteur, c'est l'absence de privilège, et cela se contrôle ligne à ligne dans la genèse. Les mises à niveau se font par consensus social et hard fork.

Cet article est l'argumentaire. 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, c'est le plus précis qui l'emporte et la divergence est un bug. Publié à leurs côtés se trouve le compte rendu des attaques menées contre cette conception — lectures adverses successives, constats qu'elles ont produits, ceux qui ont changé les règles, et ceux qui ont été réfutés et pourquoi. Ce compte rendu est publié intégralement et sans retouche, y compris les revues qui ont trouvé de véritables défauts et les instruments qui annonçaient un succès tout en ne mesurant rien. Pour un projet dont l'auteur ne se portera pas garant en personne, une conception sans historique visible d'attaques se lit comme une conception que personne n'a attaquée, et il n'existe aucun moyen de regagner ce que la dissimuler coûterait.

« Sans retouche » est une promesse portant sur les constats, et il vaut la peine de dire exactement ce qu'elle couvre, car le compte rendu est republié sous forme de fichiers et non d'archive vivante. Chaque constat, chaque mesure, chaque argument et chaque alternative écartée survit tel qu'il a été écrit, y compris ceux qui étaient erronés et les instruments qui annonçaient un succès tout en ne mesurant rien ; rien n'est allégé, adouci, fusionné ni supprimé. Deux classes de modifications sont apportées, et deux seulement. La première est le caviardage des identités — noms, pseudonymes, adresses, noms de machines et chemins locaux, qui ne disent rien de la conception. La seconde est l'autosuffisance : un renvoi vers un gestionnaire de tickets ou un historique de commits que l'arborescence publiée ne transporte pas est remplacé par le raisonnement qu'il représentait, énoncé sur place. Un lecteur qui ne dispose que de ces fichiers peut ainsi suivre chaque affirmation, ce qui était l'objet de la promesse ; un renvoi qui ne résout vers rien respecterait la lettre de « sans retouche » et en perdrait toute la finalité.

La preuve d'enjeu ne peut pas réaliser un lancement équitable — l'enjeu initial doit venir de quelque part, et toutes les voies classiques (vente, premine, allocation) ou bien concentrent le réseau, ou bien identifient son auteur. La preuve de travail est donc employée comme mécanisme de distribution assorti d'une date d'expiration, et non comme consensus permanent :

Notes de conception sur la transition. L'Ère 0 est délibérément minuscule. En l'absence de clés d'administration, il n'y a pas de bouton pause : chaque ligne de la genèse est donc une ligne susceptible de tuer le réseau sans remède ; le fold (§3) plus les opérations natives (§11) constituent toute la surface critique pour la sûreté (assez petite pour que cet article en contienne la spécification complète), et elles sont livrées auditées et simulées en conditions adverses. Le minage sur CPU (RandomX) correspond au public visé : miner sur l'ordinateur portable que l'on possède déjà. Cela attire aussi les botnets ; toutes les pièces minables sur CPU les ont combattus, et nous ne comptons pas faire exception. Nous acceptons cet arbitrage les yeux ouverts : une distribution biaisée par des botnets reste plus large qu'une distribution décidée lors d'une vente, et maintenir compétitif le matériel grand public honnête est tout le cahier des charges de RandomX [14]. La cosignature est en service dès l'instant où les garants peuvent s'enregistrer ; la finalité par points de contrôle ne l'est pas tant que l'enjeu ne se maintient pas, et nous nommons cet intervalle au lieu de le dissimuler : la caution tarife les omissions, jamais les réorganisations, si bien qu'aucune règle du protocole n'empêche un garant de vendre des pré-confirmations dans cet intervalle — ce qu'aucune règle ne peut faire, c'est rendre la vente honnête. « S'applique en quelques secondes ou ma caution paie » n'est garantissable qu'une fois les réorganisations profondes écartées : le produit de pré-confirmation assurée suit donc la finalité au titre de l'honnêteté du marché plutôt que de la loi du protocole. Les attestateurs sont rémunérés sur l'émission dès l'activation de la surcouche — les deux transitions hybrides antérieures l'ont fait toutes deux (Decred verse aux votants PoS une part de chaque récompense de bloc [17] ; les validateurs de la beacon chain d'Ethereum ont perçu de l'émission pendant deux ans avant de proposer des blocs de mainnet) — et la répartition 77/20/3, favorable au producteur, est confinée à la phase de distribution, puisque le même précédent montre qu'une répartition favorable aux mineurs est le mauvais état permanent : la décroissance progressive la retire. L'Ère 1 scinde son déclencheur, et la scission est porteuse : le jeu d'instructions s'active par la hauteur — BOND d'abord, l'enregistrement des garants et des séquenceurs puis la cEVM ensuite, deux hauteurs que les paramètres de genèse tiennent distinctes et ordonnées — tandis que la surcouche de finalité ne s'active qu'une fois qu'un enjeu cautionné ≥ 1 % de l'offre s'est maintenu pendant K époques, car l'enjeu ne peut pas être mesuré avant que l'opération qui le crée n'existe. L'Ère 2 conserve un double déclencheur (hauteur et enjeu maintenu), de sorte que le réseau ne transitionne ni sur un enjeu dérisoire ni ne laisse les mineurs en place le bloquer à jamais ; les hauteurs sont des seuils, non des dates, et aucun calendrier n'est promis. Une réserve que nous énonçons plutôt que d'enfouir : au plancher d'activation de 1 %, bloquer la finalité en demande le tiers (0,33 % de l'offre), si bien que la finalité sur laquelle reposent les premières pré-confirmations assurées est elle-même jeune. L'exigence de maintien pendant K époques relève la barre au fil du temps, la fuite d'inactivité rend un blocage coûteux à tenir, et l'on attend des garants qu'ils tarifent une finalité jeune dans des polices jeunes ; une sécurité plus profonde arrive avec un enjeu plus profond, non par décret. L'Ère 1 est la chaîne fantôme : l'ensemble des validateurs finalise en production pendant toute l'ère — vraies cautions, vrai slashing — avant de proposer le moindre bloc, la propriété qui a rendu sûre l'unique transition PoW→PoS réussie à grande échelle. C'est aussi un état de repos, non un couloir : si l'enjeu n'atteint jamais durablement le seuil de l'Ère 2, le réseau demeure indéfiniment un hybride fonctionnel. La décroissance progressive de la récompense, plutôt qu'une falaise, prive un ralliement autour d'un fork de mineurs de son moment, et cette décroissance est interruptible : si les points de contrôle échouent à finaliser pendant deux époques consécutives, elle se met en pause à son niveau courant jusqu'au retour de la finalité. Les mineurs ne peuvent pas acheter la pause : bloquer la finalité demande un tiers de l'enjeu cautionné, que la fuite d'inactivité saigne jusqu'au retour de la finalité, si bien que l'attaque coûte plus que ne rapporte la récompense mise en pause. Les mineurs de l'Ère 0 qui cautionnent leur coinbase reçoivent une priorité — non des pièces supplémentaires — dans les premières rotations de séquenceurs, ce qui convertit la communauté minière en communauté d'opérateurs au lieu de l'écarter.

Le déclencheur de l'ère protégée est délibérément taillé autrement que les autres. Les hauteurs et les seuils d'enjeu sont des faits qu'un nœud mesure ; la maturité d'un vérificateur cryptographique n'en est pas un, si bien que le déclencheur est plutôt une liste de contrôle qu'un hard fork doit pouvoir invoquer : audits publiés, époques de testnet servies, vecteurs dans l'artefact. La forme importe plus que les éléments. Ce réseau n'a pas d'équipe d'intervention d'urgence — le bug de contrefaçon de Zcash était survivable en partie parce qu'une organisation dotée de personnel a livré un correctif en quelques jours, et rien ici ne peut le promettre — si bien que l'activation de l'ère est conçue pour créer ses mainteneurs plutôt que pour les présupposer : une communauté incapable de produire deux audits indépendants et de tenir un testnet adverse est une communauté incapable de maintenir un vérificateur de consensus, et la liste de contrôle rend la seconde incapacité visible comme une défaillance de la première, avant l'activation plutôt qu'après une rupture. La règle de fold de §12 borne ce qu'un bug survivant peut coûter ; la liste de contrôle borne le degré d'inexamen d'un vérificateur au moment où il commence à coûter quoi que ce soit. Ni l'une ni l'autre ne remplace la seconde, et l'ère est livrée avec les deux ou pas du tout.

La décroissance progressive est une redistribution et non une réduction : quelle que soit la part que la preuve de travail abandonne, les proposeurs en preuve d'enjeu la prennent, si bien que le calendrier de subvention de §14.2 est indifférent à l'endroit où le réseau se trouve dans sa transition. C'est ce qui permet au calendrier de rester une fonction pure de la hauteur, calculable par n'importe quel nœud à partir de quatre constantes sans consulter le registre.

La transition est réalisable pour une raison architecturale qui mérite d'être énoncée : le fold est indifférent à l'identité de qui ordonne. Un mineur PoW est déjà le proposeur aveugle que la conception exige ; l'Ère 2 change la signature qui figure sur l'en-tête et pas une seule règle de sémantique d'état. Il n'y a aucun moteur d'exécution à faire traverser la frontière.

Une frontière d'ère est aussi l'endroit où la capacité se déplace : la capacité en octets de §8.1 et les constantes de transport sous-jacentes y sont réépinglées, au regard d'une propagation mesurée sur le réseau en fonctionnement, si bien que la croissance de routine emprunte les mises à niveau que ce calendrier contient déjà au lieu de devenir un événement de gouvernance à part entière.

14.1 La trésorerie#

Trois pour cent de chaque subvention de bloc sont crédités à la cellule de trésorerie ; quatre-vingt-dix-sept pour cent rémunèrent le consensus — le producteur du bloc et, à partir de l'Ère 1, les attestateurs de points de contrôle (§14). La part est fixée dans la genèse, s'applique dès le bloc 0 et s'applique identiquement à chaque bloc. Les frais ne sont jamais touchés (la trésorerie n'a aucun droit sur les marchés de §8), si bien que le coût retombe sur l'émission, réparti sur chaque détenteur au prorata de ses avoirs.

La cellule est scellée jusqu'à l'Ère 2. Elle s'accumule dès le bloc 0 et aucune clé ne l'ouvre avant cette date : aucun quorum dans la genèse, aucune adresse, aucune clé d'auteur, aucun chemin d'urgence. Au bloc 0, il n'existe pas de communauté mûre pour détenir les clés. Si aucune n'apparaît, la cellule ne s'ouvre jamais et les pièces ne sont jamais émises. La règle d'accumulation figure dans la genèse dès le premier bloc afin de n'être jamais un changement ; rien de nouveau ne se produit à l'Ère 2, sinon qu'une règle convenue devient opérante.

Rien de tout cela n'est un premine, et la différence est vérifiable plutôt que rhétorique. Un premine est une allocation : des pièces, une adresse et une clé qui existent à la genèse et appartiennent à quelqu'un. La genèse ici n'en contient aucune des trois. Aucune pièce de trésorerie n'est dépensable, aucune adresse n'est désignée, aucune clé n'existe, et aucune partie n'est nommée ; ce que la genèse contient, c'est une règle, appliquée identiquement à chaque bloc jamais miné, plus une seconde règle sur la manière dont un quorum pourra un jour être épinglé sur le résultat accumulé. Que ce jour vienne ne relève pas de la décision de l'auteur. Comme le jeu de clés est épinglé par hard fork, le mécanisme de sélection est celui qu'emploie tout changement de consensus : quelqu'un propose cinq détenteurs publiquement identifiés, les opérateurs de nœuds adoptent le fork qui les épingle ou refusent de l'exécuter, et un quorum candidat incapable de convaincre le réseau d'exécuter son fork détient les clés de rien. Il n'y a pas de vote à capturer, pas de registre de contributeurs à manipuler, et aucun moment où la voix de l'auteur pèse plus que celle de tout autre opérateur de nœud.

À partir de l'Ère 2, la cellule n'est débitée que par un certificat portant trois signatures sur cinq issues d'un jeu de clés épinglé par hard fork. Les dépenses sont des certificats ordinaires : publiques, définitives, et dénombrables à partir de la seule chaîne. Le quorum est tiré parmi les contributeurs actifs au moment de l'ouverture et publiquement identifiés avant que le jeu ne prenne effet ; chaque clé se trouve chez une partie distincte, aucune sous contrôle commun. Une dépense 3 sur 5 valide peut au contraire nommer cinq clés de remplacement, effectives après R blocs, durant lesquels la rotation est publique et l'ancien jeu reste en vigueur : la rotation porte le seuil d'une dépense et la visibilité d'une dépense.

Les Ères 0 et 1 sont financées par les dons : propositions publiques avant paiement, jalons et budget annoncés d'avance, versement contre travail livré, montants non dépensés rendus au fonds. Le quorum hérite de cette discipline à l'ouverture de la cellule. C'est une norme et non une règle de consensus ; ce qui la fait respecter, c'est que tout écart est visible dans le registre.

La part n'expire pas. C'est une fraction de l'émission plutôt qu'une quantité de pièces : elle décroît donc avec la subvention de §14.2 et persiste dans la queue sous forme de flux nominal fixe ; rapportée à l'offre, elle tend vers zéro. La supprimer coûte ce que coûte tout changement de consensus : un hard fork. À partir de l'Ère 2, le 3 sur 5 est l'unique quorum de confiance du protocole.

14.2 Émission#

La subvention décroît régulièrement vers une queue perpétuelle. Le taux est constant à l'intérieur d'une époque et descend d'un cran à chaque frontière d'époque, par arithmétique entière exacte sur quatre constantes :

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

où L est l'époque exprimée en blocs, Q le diviseur de décroissance, E₀ la subvention de genèse, et E(n) la subvention par bloc tout au long de l'époque n. Ces quatre-là — L, Q, E₀, tail — sont les constantes ; C, l'offre pré-queue à laquelle le calendrier somme, en est dérivée en déroulant la récurrence et n'en est pas une entrée. Des révisions antérieures écrivaient la première ligne E(0) = C / (L · Q), ce qui se lit comme si C était une constante dont la subvention serait le quotient ; c'est la forme close de la décroissance géométrique infinie, et le calendrier fini ci-dessous n'y somme pas. Il n'y a ni flottants ni table à se tromper, et pas de falaises de halving : le pas est assez petit pour qu'aucun bloc isolé n'en voie un, le même raisonnement qui fait de la récompense de l'Ère 2 une décroissance progressive. Une fois la formule passée sous la queue, la subvention est un montant fixe par bloc, à jamais.

Le calendrier est une fonction pure de la hauteur. Il ne consulte pas ce qui a effectivement été versé, ce qui signifie qu'un bloc qui verse moins que le calendrier — un coinbase dû à une adresse que son détenteur a brûlée, par exemple — constitue un manque à gagner permanent au regard de C plutôt qu'une dette que la courbe rembourserait plus tard. C est donc le chiffre auquel le calendrier somme, non un plafond qu'il garantit d'atteindre.

La queue existe parce que la sécurité est une dépense permanente : elle rémunère quiconque sécurise l'ère courante — les mineurs, puis les mineurs et les attestateurs, puis les validateurs — sans réquisitionner les marchés de §8. Elle est dimensionnée pour que l'émission annuelle de queue démarre sous 1 % de l'offre en circulation ; comme le numérateur est fixe et que l'offre croît, ce pourcentage ne fait que baisser. En regard court le brûlage des frais de base séquentiels de §8, si bien que l'émission nette vaut la queue moins le brûlage et peut être négative sous charge. La répartition 97/3 de §14.1 s'applique à toute subvention, queue comprise.

Constantes (genèse, à titre indicatif, comme en §13) : époque L = 2 880 blocs ; diviseur de décroissance Q = 1054 ; subvention de genèse E₀ = 21 par bloc ; queue 0,33 par bloc. Avec des blocs de 30 secondes, cela donne un facteur annuel de 0,70702, c'est-à-dire que le taux d'émission est divisé par deux tous les deux ans — et exactement, non approximativement : E(730) = 10.50230028 contre E₀ = 21. La formule passe sous la queue à l'époque 4 376, hauteur 12 602 880, ≈ année 12 ; le bras décroissant court donc sur les époques 0 à 4 375 et C, l'offre à laquelle il somme, vaut 62 744 838,47. Là-dessus, 62 744 817,47 sont effectivement émis : la différence est le 21 du bloc de genèse, qui ne verse aucun coinbase parce qu'il n'y a pas de mineur à payer et qu'une genèse reproductible ne doit créditer aucune adresse. L'émission annuelle de queue est alors d'environ 347 000, soit 0,55 % de l'offre émise, en baisse à partir de là. **La forme close L · E₀ · Q = 63 745 920 est une borne supérieure de C, non sa valeur**, et l'écart n'est pas une erreur d'arrondi : ce produit est la somme de la décroissance géométrique infinie, tandis que le calendrier est fini, arrondit vers le bas à chaque pas et s'arrête à la queue. Il dépasse C de 1 001 081,53, soit 1,60 %. Citez la somme et jamais la forme close. La conformité consiste à reproduire la récurrence — aucun nœud ne calcule jamais C, ni aucun autre chiffre de ce paragraphe, à quelque hauteur que ce soit.

15. Mesures#

Une conception dont l'affirmation centrale est une asymétrie de débit doit des chiffres à son lecteur. Les valeurs ci-dessous proviennent de l'implémentation de référence et peuvent être redérivées à partir de ses sources publiées. Matériel : un processeur x86 de bureau à dix cœurs. Les valeurs sont des médianes sur 5 exécutions.

• Débit du fold : 883 000 opérations de slot par seconde et par cœur sur un ensemble de travail de 100 000 slots, soit 294 000 certificats appliqués par seconde à raison de 3 slots par certificat.
• Vérification sans état : 1 470 certificats par seconde et par cœur de CPU, et 5 220 par seconde sur 10 cœurs — le rapport est l'affirmation de parallélisme, mesurée plutôt qu'assénée.
• Vérification de signature : 1 500 par seconde, en une seule fois, avec les contrôles d'ordre petit et de torsion inclus.
• De bout en bout : un bloc de 2 900 certificats se valide en 1 963 ms et se replie en 9,9 ms. Les deux sont rapportés séparément parce qu'ils sont les deux moitiés de l'argument : la première passe à l'échelle avec des cœurs que le réseau ne possède pas, la seconde est l'unique boucle qu'il possède.

La mesure du fold est une soustraction, et le dire fait partie du fait de la rapporter : valider un bloc exécute ensemble les contrôles sans état et le fold séquentiel, si bien que le chiffre du fold est le tout moins les contrôles chronométrés à part. Les deux moitiés figurent dans l'artefact.

Nous ne rapportons que ce que l'implémentation de référence exécute, ce qui pose deux limites qu'il vaut mieux nommer que de laisser un lecteur découvrir. La vérification de signature est mesurée une signature à la fois : la vérification par lots est une technique réelle et un choix manifestement adapté, mais c'est de la cryptographie critique pour la sécurité que ce projet n'a pas écrite, et un chiffre pour du code qui n'existe pas n'est pas une mesure. Les valeurs sur GPU et SIMT qu'anticipent §2 et §6 relèvent des certificats groupés du séquenceur, qui arrivent avec l'Ère 1. Les deux sont des attentes de conception. Ni l'une ni l'autre n'est porteuse pour les chiffres ci-dessus : l'affirmation de parallélisme repose sur le fait que les certificats sont contrôlables indépendamment, ce que le groupement rendrait plus rapide et ne saurait rendre vrai.

16. Travaux connexes#

Le pipeline de Zycord — exécuter d'abord, ordonner à l'aveugle, valider à la validation — a un ancêtre en environnement à permissions : l'execute-order-validate de Hyperledger Fabric [3], dont les faiblesses documentées sont son taux d'abandon sous contention et sa dépendance à des politiques d'endossement institutionnelles. Les apports de Zycord par rapport à cette lignée sont (i) une applicabilité fondée sur l'égalité de valeurs, avec l'omission comme sémantique de première classe et tolérante au cas ABA ; (ii) l'attribution économique du conflit — une garantie cautionnée qui rend l'équivocation objectivement sanctionnable par slashing et fait de la péremption un service tarifé et assurable, ce qui manquait à execute-order-validate pour se passer de permissions ; et (iii) l'inclusion forcée avec application garantie, là où les issues de secours des rollups ne garantissent que l'inclusion. Les ensembles de lectures et d'écritures prédéclarés de façon déterministe descendent de Calvin [4] et apparaissent dans les listes d'accès de Solana [16] ; les méthodes de séquestre commutatif remontent à O'Neil [9] et vivent aujourd'hui dans des ordonnanceurs mononœuds tels que les agrégateurs d'Aptos par-dessus Block-STM [5] — Zycord déplace le contrat de commutativité entre les nœuds et le tarife. Les systèmes à EVM parallèle [5] et les chaînes à exécution différée réexécutent malgré tout partout et heurtent le mur des E/S sur l'état ; Narwhal [6] sépare la diffusion des données de l'ordonnancement, comme le faisaient nos premières conceptions ; les objets possédés de Sui font écho à nos cellules à écriture unique ; la scission pending/base de Zether [7] a inspiré la discipline du delta gardé (et revient, avec les racines de confidentialité du registre chimérique [8], dans les paiements confidentiels de §12 — le premier occupant de la voie de cryptographie lourde, montants dissimulés et adresses à usage unique tarifés en gas parallèle plutôt qu'intégrés à la couche de base). Les surcouches de finalité chaînée suivent Casper FFG [12].

17. Conclusion#

Nous avons proposé un réseau qui ordonne des certificats au lieu d'exécuter des transactions : une validité contrôlable par quiconque, n'importe où, en parallèle, à partir des seuls octets ; un état que fait avancer un fold assez simple pour tenir en une page de spécification ; des conflits omis, tarifés et attribués ; une concurrence déclarée plutôt que découverte ; une censure à laquelle on survit par construction ; et un lancement qui distribue la pièce avant de demander à quiconque de faire confiance à un ensemble de validateurs. 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 quasi gratuite.

Zycord ne court pas après le travail. Il se tient immobile, et c'est le réseau qui travaille.

Références#

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