Rand Protocol
Progression

Progression

Chaque version du nœud complet Rand, du premier tag jusqu'aux adresses lisibles par l'humain. Les versions publiées indiquent la date de leur tag. Les versions suivantes affichent une estimation, au rythme d'une version par semaine. Les estimations bougent quand le travail bouge.

Publiée
18
En cours
0
Prévue
1
  1. v0.1
    Publiée v0.1 · 16 Sept 2026

    Correctifs de la revue de sécurité et la pièce RAND

    • Le premier nœud complet taggé : HotStuff BFT, le pool shielded, le staking, les programmes confidentiels sur la zkVM.
    • Correctifs des constats de la revue de sécurité préalable à la publication.
    • La pièce native est RAND, et les frais sont payés en RAND.
  2. v0.2
    Publiée v0.2 · 17 Sept 2026

    Recherche sur les adresses lisibles par l'humain

    • Recherche sur des adresses que les personnes peuvent lire.
    • Les conclusions ont mené au partage d'adresses de la v0.5.10 : l'adresse reste d'environ 1 667 caractères, et gagne une empreinte, des liens de paiement et des codes QR.
  3. v0.3
    Publiée v0.3 · 18 Sept 2026

    La version RPC

    • Onze nouvelles méthodes JSON-RPC et deux topics WebSocket, alignés sur le RPC d'Ethereum et de Solana.
    • Les commandes de portefeuille rand viewing-key et rand tx-key.
    • Le plafond de programmes comme paramètre de genesis, inerte tant qu'une chaîne ne le définit pas.
  4. v0.4
    Publiée v0.4 · 19 Sept 2026

    La chaîne d'outils RISC-V et les transpileurs Solana et Ethereum

    • rand-guest : compiler, vérifier, empaqueter, exécuter et inspecter des programmes RV32IM depuis Rust ou C.
    • sbpf2rv et evm2rv : des programmes Solana et EVM traduits en RISC-V, avec des sorties identiques mot pour mot à celles des interpréteurs.
    • La chain 13, dont le genesis relève le plafond de programmes et les limites d'appels ; l'ERC-20 et le SPL Token traduits y ont été déployés.
  5. v0.5
    Publiée v0.5 · 20 Sept 2026

    Jetons RPL, zUSD et le bridge renforcé

    • La chain 14, créée et taggée le même jour. Un USDT a effectué l'aller-retour complet sur chacune des chaînes Ethereum, Binance Smart Chain, Tron et Solana : verrouillé, émis sous forme de zUSD, brûlé, libéré. Un second tour a laissé 36 zUSD émis contre 36 USDT en dépôt.
    • RPL, le standard de jetons : un jeton est une entrée du registre du ledger, créée par n'importe qui contre des frais en RAND, et il circule dans la même preuve que le RAND, ce qui masque l'actif déplacé.
    • Le zUSD est enregistré sur la chain 14 comme un jeton bridgé unique adossé à sept garanties : USDT et USDC sur Ethereum, Binance Smart Chain et Solana, et USDT sur Tron.
    • Renforcement du bridge : un plafond d'émission quotidien par garantie, une clé de pause, une co-signature post-quantique sur chaque émission, et des horodatages de bloc bornés.
    • Chaque preuve est liée à l'ensemble de sa transaction. À la suite de l'audit de sécurité : les dix-huit clés de validateur ont été renouvelées, et une émission du faucet ouvre désormais son engagement.
  6. v0.5.9
    Publiée v0.5.9 · 27 Sept 2026

    La chain 15 et les correctifs d'audit

    • La chain 15, créée le 26 septembre à partir de la position du bridge de la chain 14 : les 10 zUSD encore en circulation ont été reportés au genesis, adossés à 9 USDT sur Tron et 1 USDT sur Solana, de sorte que l'offre égale les fonds en dépôt dès le bloc 0. La flotte a ensuite été basculée en v0.5.9.
    • Les versions correctives v0.5.x jusqu'à la v0.5.9 ont réglé les constats de trois cycles d'audit interne menés par un cofondateur et de trois analyses internes (aucun audit indépendant n'a encore été réalisé) : un verrou de consensus qui survit aux redémarrages, un seul certificat de quorum stocké par bloc, des preuves d'appel plafonnées au tier 14, et des validateurs qui conservent un jour de blocs à côté d'une archive complète.
    • Le genesis de la chain 15 active les correctifs conditionnés : un faucet limité à 16 portefeuilles nommés et à un budget par epoch, un délai de bonding de deux epochs, chaque signature de consensus liée au genesis, et les règles v2 du bridge avec un plafond d'émission global et des clés post-quantiques renouvelables. 26 validateurs la signent désormais.
  7. v0.5.10 · v0.5.11
    Publiée v0.5.10 · v0.5.11 · 28 Sept 2026

    Partage d'adresses, mémo chiffré et registre de vesting

    • v0.5.10 : une empreinte d'adresse de 16 caractères, des liens de paiement randpay: et des codes QR, et un mémo chiffré scellé dans l'enveloppe de la note.
    • v0.5.11 : un registre de vesting public pour les allocations bloquées (équipe, investisseurs, partenaires), en dehors du pool shielded et conditionné au genesis ; le montant, le calendrier, les retraits et le validateur bondé de chaque entrée sont publics sous la clé du titulaire. Actif sur aucune chaîne pour l'instant.
  8. v0.6
    Publiée v0.6 · 28 Sept 2026

    Les correctifs de la zkVM, de la recursion-VM et de l'agrégation

    • La plupart des constats des revues des 27 et 28 septembre sur la zkVM, l'ISA et la recursion-VM corrigés dans le code : quatre ruptures de solidité de la recursion-VM (dormantes, puisque l'agrégation est désactivée partout), la fuite des entrées d'appel des petites tables fermée pour les nouvelles preuves, la pénalisation des agrégateurs retirée, et la clé du vérificateur de bundle maintenue au chaud hors de la boucle de consensus.
    • Le guest de bundle sans branchement et l'interrupteur de genesis hardening_v6 (plancher de la table de programmes, liaison des appels, déploiements inappelables refusés) conçus pour la prochaine création de chaîne. Déployés sur les 26 validateurs le 28 septembre.
    • Encore ouverts après la v0.6 : le contre-exemple de libération du verrou de consensus CON-4 (correctif conçu, non livré), la garde des clés du bridge, les requêtes de témoin des portefeuilles GUI vers le RPC public, et le test d'agrégat falsifié (#45) avant que l'agrégation puisse être activée.
  9. v0.6.1 · chain 16
    Publiée v0.6.1 · chain 16 · 28 Sept 2026

    Le jeu de contraintes 7 et un nouveau genesis

    • Le jeu de contraintes 7, un hard fork : chaque terminal LogUp masqué et chaque table plafonnée par le bas à 128 lignes, de sorte qu'une preuve révèle ses 34 valeurs publiques et rien de plus ; des contrôles de plage sur 32 bits pour les mots d'entrée ; des clés de vérificateur salées ; le vérificateur en circuit de la recursion VM.
    • La chain 16, en service le 28 septembre à 16:39 UTC avec le guest de bundle sans branchement et hardening_v6 : 26 validateurs à 1 000 RAND chacun, tous exploités par l'équipe fondatrice, un quorum de 18 ; les 10 zUSD reportés, adossés à 9 USDT sur Tron et 1 sur Solana ; aucune section d'agrégation.
    • Sur les chains 14 et 15, une preuve de transfert révélait si du RAND ou un jeton avait circulé ainsi qu'une empreinte des notes dépensées, et une preuve d'appel permettait de deviner des entrées à faible entropie ; la chain 16 corrige les deux.
  10. v0.6.2
    Publiée v0.6.2 · 29 Sept 2026

    Preuve déléguée, phase 1

    • rand-prover et rand-node run --prover : un service de preuve scellé que le propriétaire d'un portefeuille fait tourner, pour qu'une extension de navigateur ou un téléphone sans 8 Go de mémoire puisse envoyer. Les tâches sont scellées avec ML-KEM-768 et ChaCha20-Poly1305, le témoin est mis à zéro, et le portefeuille vérifie lui-même la preuve renvoyée.
    • La phase 1 confie la clé de dépense au prover : déléguer une preuve revient donc à remettre la garde des fonds, et il ne faut appairer qu'une machine que l'on exploite soi-même. Déployée sur les 26 nœuds le 29 septembre ; remplacée sur la chain 17 par l'autorisation scindée (v0.6.3).
    • La version v0.6.5 des clients permet d'appairer un prover depuis les Paramètres, et l'application de bureau peut en être un.
  11. v0.6.3 · v0.6.4 · chain 17
    Publiée v0.6.3 · v0.6.4 · chain 17 · 29 Sept 2026

    Preuve déléguée, phase 2 : autorisation scindée et nouveau genesis

    • La preuve de bundle ne prend plus la clé de dépense. Le portefeuille produit lui-même une petite preuve d'autorisation (tier 10, environ 7 s, 1,36 Mo) et tout prover appairé peut produire la lourde preuve de bundle à partir de la clé de visualisation : il peut lire l'historique de ce portefeuille, mais il ne peut pas dépenser. Un prover peut annoncer des frais en RAND, payés sous la forme d'une sortie shielded dans la même transaction ; le portefeuille les plafonne (1 RAND par défaut).
    • Un hard fork, donc un nouveau genesis : la chain 17 en service le 2026-09-29 à 03:03 UTC, créée à partir d'un instantané de la chain 16 avec les mêmes 26 validateurs, les 10 zUSD et leur garantie reportés ; le plafond de preuve est de 4 MiB, de sorte qu'un bloc a la place pour trois preuves. Un transfert porte désormais environ 2,85 Mo de preuves, sept par bloc de 20 MiB. La v0.6.4 est le relevé de lancement.
    • Mesuré le 29 septembre : une preuve de bundle v3 en 102 s en local, 108–111 s via un prover apparié ; un prover tiers a prouvé de bout en bout un envoi de 5 RAND.
  12. v0.6.6
    Publiée v0.6.6 · 29 Sept 2026

    Gas : payer à l'instruction en RAND (jeu de contraintes 8), conçu pour la chaîne 18

    • La zkVM mesure chaque exécution dans le circuit (une colonne de gas, une valeur publique) ; un appel déclare une limite de gas et la règle au prix du gas et au prix de l'octet de la chaîne, et, sous la section dynamique, les prix évoluent une fois par bloc en fonction du remplissage. Chaque bundle déclare la limite figée de 20 479.
    • Le jeu de contraintes 8 modifie toutes les clés de verifier ; il ne pouvait donc fonctionner que sur une nouvelle chaîne. La v0.6.6 a été étiquetée sans jamais être publiée telle qu'étiquetée : son contenu a atteint une chaîne le même jour que la v0.6.7-rc1, rebasé sur l'autorisation scindée.
  13. v0.6.7 · chaîne 18
    Publiée v0.6.7 · chaîne 18 · 29 Sept 2026

    Chaîne 18 : la mesure du gas et le mémo chiffré, en production

    • Chaîne 18, créée le 29 septembre à 04:56 UTC sur la v0.6.7-rc1 puis déployée nœud par nœud vers la v0.6.7 : la première chaîne à gas mesuré (jeu de contraintes 8), avec l'autorisation scindée héritée de la chaîne 17 et l'enveloppe de note de 1 860 octets qui transporte un mémo chiffré. 26 validateurs à 1 000 RAND chacun, un quorum de 18, des preuves jusqu'à 4 MiB. Les soldes en RAND et les 10 zUSD en circulation ont été repris à la genèse.
    • Un appel confidentiel déclare désormais une limite de gas que le circuit fait respecter, et la règle, ainsi que ses octets, à des prix qui évoluent à chaque bloc. Quatre appels mesurés le 30 septembre ont coûté entre 0,0057 et 0,0075 RAND.
    • Quatre programmes d'exemple ont été déployés et appelés sur la chaîne 18 le 30 septembre : un vote anonyme sur une liste d'autorisation Keccak, une preuve de passif sur un arbre de sommes SHA-256, un registre hors chaîne transmis d'un appel à l'autre, et une décision de crédit privée à partir d'un modèle publié.
  14. v0.6.7 · chaîne 19
    Publiée v0.6.7 · chaîne 19 · 1 Oct 2026

    Chaîne 19 : la chaîne 18 à nouveau, avec les points d'accès du bridge redéployés

    • La chaîne 19 est entrée en service le 1er octobre à 03:43 UTC, créée à partir de la chaîne 18 sur un instantané à la hauteur 141 935 et exécutée sur le même build v0.6.7 par les mêmes 26 validateurs. Toutes les règles et limites sont celles de la chaîne 18 ; la genèse désigne les points d'accès du bridge Ethereum, BNB Chain et Tron redéployés le 30 septembre.
    • Les portefeuilles opérateurs et les zUSD bridgés ont été repris. Les programmes ne survivent pas à une coupure de chaîne ; les quatre programmes d'exemple ont donc été redéployés sur la chaîne 19. Le pool de provers des validateurs, à prover.randprotocol.org, prouve pour la chaîne 19.
    • Rand Wallet v0.6.7 a été publié le même jour pour la chaîne 19 : le cœur de chaque client intègre le fullnode v0.6.7 et refuse toute autre chaîne, et la version du portefeuille correspond désormais à celle du nœud.
  15. v0.6.8 · chaîne 20
    Publiée v0.6.8 · chaîne 20 · 1 Oct 2026

    Chaîne 20 : l'état des programmes, les frais de bridge et les derniers correctifs de l'audit v6

    • La chaîne 20 est entrée en service le 1er octobre à 06:17 UTC sur la v0.6.8, un hard fork de l'état de la chaîne 19 à la hauteur 7 258, déployé en arrêt complet par les mêmes 26 validateurs. Chaque preuve et chaque message signé est désormais lié à la genèse de la chaîne : rien de ce qui est produit pour une chaîne ne se vérifie sur une autre, et un portefeuille doit être en v0.6.8 pour envoyer.
    • RPL-2 : un programme peut conserver un état dans des cellules et détenir un coffre, et un Invoke les lit et les écrit en une seule étape prouvée, à 0,01 RAND par nouvelle cellule. Le zUSD acquitte des frais de bridge de 0,1 % dans chaque sens, en zUSD, versés à une note de trésorerie, et la garde reste égale à l'offre.
    • Le reste de l'audit v6 : le verrou de consensus n'est plus levé automatiquement (CON-4) et les vues avancent sur des certificats de timeout (CH-1) ; un écouteur RPC public à ensemble de méthodes fixe ; des plafonds de prix du gas ; des validateurs admis par vote ; des rotations de guardian qui exigent la possession de la clé et un délai d'un jour.
  16. Wallet v0.6.8 · chaîne 20
    Publiée Wallet v0.6.8 · chaîne 20 · 1 Oct 2026

    Rand Wallet v0.6.8 : les applications envoient sur la chaîne 20

    • Le cœur de chaque application intègre désormais le fullnode v0.6.8 et lie ce qu'il prouve et signe à la genèse de la chaîne 20 ; les portefeuilles mobile, de bureau et navigateur envoient donc de nouveau sur la chaîne 20. Par défaut, un portefeuille utilise le prover RandProtocol pour la preuve du bundle, et un prover personnel reste le choix confidentiel.
  17. v0.8.0 · chain 21
    Publiée v0.8.0 · chain 21 · 12 Oct 2026

    Chain 21 : jeu de contraintes 9, frais brûlés, contrats perpétuels et multisignature

    • Chain 21 est entrée en service le 12 octobre à 10:31 UTC sur fullnode v0.8.0, un hard fork de chain 20 (son état du bridge issu du snapshot à la hauteur 814,702, les soldes des portefeuilles d'opérateurs) déployé en arrêt total par les mêmes 26 validateurs. La zkVM passe au jeu de contraintes 9, avec des portées de Merkle dans le vérificateur de récursion et une puce pour l'arithmétique de Dilithium2 ; toutes les clés de vérification et l'encodage des preuves ont donc changé : v0.8.0 refuse les chaînes 18 à 20, et un portefeuille doit être en v0.8.0 pour envoyer.
    • Le plancher de frais de chaque transaction est désormais brûlé au lieu d'être versé au proposant, qui ne conserve que le pourboire. Contrats à terme perpétuels RPL-3 : un seul marché, BTC-PERP réglé en zUSD avec un effet de levier de 20×, avec un prouveur hors chaîne. Comptes multisignature : clés Dilithium2 M-sur-N portant sur un solde public, 1 RAND pour les créer ; la trésorerie de la fondation, 100,000 RAND protégés par 2 clés sur 3, est le compte de genèse. Multisignature privée : une politique M-sur-N prouvée comme autorisation d'un lot au palier 18, de sorte que la chaîne apprend seulement qu'une multisignature a signé. Les preuves peuvent atteindre 6 MiB.
    • Modifications limitées au nœud depuis v0.6.8 : versions signées et compilées en CI à partir de v0.7.0 ; preuve sur tous les cœurs, ou sur le GPU, à partir de v0.7.1 ; blocs compacts, point de contrôle au démarrage, cache de vérification et application des blocs hors de la boucle principale dans v0.8.0 ; les scan heads réduisent de 2.26× le volume d'octets qu'un portefeuille synchronise. La ligne de commande rand de la version v0.8.0 envoie sur chain 21, tout comme Rand Wallet v0.8.0, ci-dessous.
  18. Wallet v0.8.0 · chain 21
    Publiée Wallet v0.8.0 · chain 21 · 12 Oct 2026

    Rand Wallet v0.8.0 : les applications envoient sur chain 21 et signent pour un multisig privé

    • Le cœur de chaque application intègre désormais fullnode v0.8.0 ; les portefeuilles mobile, de bureau, d'extension et web envoient donc sur chain 21. Les applications 0.7.x la refusent, et v0.8.0 refuse chain 20. Les clés, les adresses et les clés de visualisation sont conservées, et un portefeuille qui analysait chain 20 réanalyse depuis le bloc de genèse de chain 21 après une seule bannière. Chaque application peut signer une proposition multisig privée avec sa propre clé Dilithium2, en vérifiant le bénéficiaire avant de signer.
  19. à venir Estimation
    Prévue à venir · 19 Oct 2026 (estimation)

    Les programmes d'exemple sur chain 21 et le dernier test de l'agrégation

    • Estimation. Les quatre programmes d'exemple redéployés sur chain 21 ; le test d'agrégat falsifié dont l'agrégation de blocs dépend encore.

Les dates marquées « estimation » sont des projets, non des engagements. La documentation décrit ce qui fonctionne aujourd'hui sur le testnet.