Technologie de génération de nombres aléatoires sécurisée pour les applications blockchain
TechFlow SélectionTechFlow Sélection
Technologie de génération de nombres aléatoires sécurisée pour les applications blockchain
Il existe de nombreuses méthodes pour générer des nombres aléatoires sur la blockchain. Cet article explique et analyse certaines de ces méthodes ainsi que leurs avantages et inconvénients.
Dédié à des analyses Web3 approfondies
De nombreuses applications blockchain ont besoin de nombres aléatoires générés à partir de sources de données sécurisées.
Par exemple, un lancement gratuit (airdrop) d'une collection NFT PFP nécessite de choisir aléatoirement une combinaison d'attributs pour chaque image NFT ; un jeu sur chaîne peut avoir besoin de tirer aléatoirement des objets lors de l'ouverture d'un coffre. Dans les deux cas, un générateur de nombres aléatoires sécurisé garantit l'équité des utilisateurs face à l'application. Ce ne sont là que quelques exemples possibles parmi bien d'autres — en général, le caractère aléatoire est un outil utile pour résoudre de nombreux types de problèmes algorithmiques.
Malheureusement, les propriétés inhérentes aux blockchains rendent la génération de nombres aléatoires particulièrement difficile. L'état d'une blockchain évolue selon un ensemble de règles déterministes : chaque transaction produit un état de sortie spécifique étant donné ses entrées. Ces règles doivent être déterministes car la blockchain exige que chaque validateur puisse vérifier le traitement de chaque transaction. Si les règles n’étaient pas déterministes, les validateurs pourraient être en désaccord sur l’état du système.
Il existe plusieurs méthodes pour générer des nombres aléatoires sur une blockchain. Cet article explique et analyse certaines de ces méthodes ainsi que leurs avantages et inconvénients respectifs.
Participants
Les protocoles de génération de nombres aléatoires impliquent généralement plusieurs participants distincts. Chaque participant est soit un acteur du protocole, soit intéressé par le résultat généré. Selon la méthode utilisée, différents sous-ensembles de participants peuvent être impliqués. Les participants possibles sont :
Développeurs d'applications — Les développeurs rédigent le logiciel qui demande et utilise les nombres aléatoires. Bien qu'ils ne participent généralement pas directement à la génération des nombres aléatoires, ils souhaitent souvent que les résultats soient véritablement aléatoires. Par exemple, un développeur d'une série NFT souhaite s’assurer que personne ne puisse tricher dans le processus de minting afin d’obtenir un NFT doté de tous les attributs rares.
Utilisateurs — Les utilisateurs lancent une requête de génération de nombre aléatoire en interagissant avec le protocole. Par exemple, un utilisateur peut être celui qui effectue le minting d’un NFT.
Validateurs — De nombreux protocoles de génération de nombres aléatoires utilisent des données d'entrée provenant de la blockchain. Les validateurs (ou mineurs/séquenceurs, selon le cas) de la blockchain peuvent exercer un certain contrôle sur ces données d'entrée.
Fournisseurs de services — De nombreux protocoles incluent un fournisseur de service désigné hors chaîne chargé de certaines parties du processus de génération. Ce fournisseur doit idéalement être une tierce partie neutre, mais cela nécessite des méthodes de génération plus complexes afin de minimiser la confiance accordée à ce participant.
Notez qu'une même personne peut jouer plusieurs rôles. Par exemple, un utilisateur peut lui-même exécuter un validateur sur le réseau blockchain. De nombreuses vulnérabilités dans ces protocoles proviennent de la collusion secrète entre plusieurs participants.
Propriétés
Avant d’examiner les différentes méthodes de génération de nombres aléatoires, il convient de définir clairement les propriétés attendues d’un bon générateur.
Tout générateur de nombres aléatoires fonctionne en deux phases. Premièrement, durant la phase de requête, l'utilisateur demande un nombre aléatoire au générateur. Ensuite, durant la phase de publication, le générateur produit le nombre aléatoire et le publie sur la blockchain. Chaque phase nécessite au moins une transaction blockchain — il est impossible de générer de manière sécurisée un nombre aléatoire entièrement sur chaîne en une seule transaction. Toutefois, les calculs exacts réalisés à chaque étape varient selon les protocoles.
Nous nous concentrons principalement sur trois propriétés de sécurité :
Imprévisibilité — Aucun participant ne peut prédire le nombre aléatoire avant sa requête. Cette propriété correspond à la définition formelle du caractère « aléatoire ».
Déterminisme — Une fois la requête effectuée, il n'existe qu'une seule valeur possible pour le nombre aléatoire. Cette propriété garantit qu'aucun participant ne peut influencer le résultat après la requête.
Activité — Après la requête d'un nombre aléatoire, le protocole s'achève immédiatement. Autrement dit, la fin de la phase de requête coïncide avec la fin de la phase de révélation.
La question centrale concernant les protocoles de génération de nombres aléatoires est : sous quelles conditions ces propriétés sont-elles satisfaites ? Par exemple, un protocole peut exiger que le fournisseur de services reste honnête. Ces conditions constituent les hypothèses de confiance du protocole. Moins il y a d'hypothèses de confiance, plus le protocole est sécurisé.
Méthodes de génération de nombres aléatoires
Tierce partie de confiance
Le protocole le plus simple consiste à faire appel à un fournisseur de services pour générer le nombre aléatoire. Lorsqu'un utilisateur en fait la demande, le fournisseur génère simplement un nombre aléatoire hors chaîne et le renvoie à la blockchain.
Cette méthode est très simple, mais repose sur de fortes hypothèses de confiance : les participants doivent faire confiance à l'intégrité du fournisseur de services. Ce dernier peut choisir librement la valeur du nombre aléatoire ou décider d'interrompre le protocole. Ces hypothèses peuvent être partiellement atténuées si le fournisseur effectue les calculs dans un environnement sécurisé isolé (comme Intel SGX), bien que de tels environnements aient déjà été prouvés imparfaits à plusieurs reprises (attaque SgxPectre).
Hachage de bloc
Une stratégie simple de génération de nombres aléatoires consiste à utiliser le hachage d'un bloc futur. La transaction de requête enregistrera le numéro du bloc courant (ou futur). Les validateurs du réseau calculeront ensuite le hachage de ce bloc. Dès que le hachage est disponible, le générateur publie la transaction finale.
La méthode du hachage de bloc est simple et facilement utilisable sur toute blockchain. Toutefois, elle suppose une forte confiance envers l’honnêteté des validateurs. En effet, ceux-ci peuvent modifier le hachage du bloc en réorganisant ou en ignorant certaines transactions. Il existe donc un risque d'attaque si l'utilisateur exécute lui-même un validateur ou collabore avec un validateur afin d'obtenir un nombre aléatoire favorable.
Fonction de randomisation vérifiable (VRF)
Les méthodes précédentes présentent un problème majeur : un seul participant peut influencer le résultat de la génération aléatoire (le rendant ainsi prévisible). La fonction de randomisation vérifiable (VRF) supprime cette vulnérabilité en exigeant que plusieurs participants collaborent pour influencer le résultat.
Une VRF est une fonction f_s(x) = (y, p), dont la sortie y semble aléatoire, mais est déterminée par l'entrée x et une clé secrète s. En outre, la fonction renvoie une preuve p, que n'importe qui peut utiliser pour vérifier que y est bien la sortie correcte (cette explication est simplifiée. Pour une description plus détaillée des VRF, voir IETF RFC).
Sur une blockchain, une VRF fonctionne généralement comme suit. L'entrée x est partiellement fournie par l'utilisateur et partiellement issue du hachage d'un bloc. Un fournisseur de services hors chaîne surveille les requêtes sur la blockchain et soumet une paire (y, p) sur chaîne. La transaction de publication vérifie la preuve p pour s'assurer que y est correct, puis publie le résultat.
L'avantage de la VRF est qu'elle améliore les hypothèses de confiance par rapport aux méthodes précédentes : l'utilisateur, le validateur et le fournisseur de services doivent tous collaborer pour prédire le nombre aléatoire. Le principal point de vigilance concerne l'activité : les participants doivent faire confiance au fournisseur pour ne pas censurer la transaction. En effet, le fournisseur voit le nombre aléatoire généré et peut choisir de ne pas le soumettre à la blockchain. Par exemple, une attaque possible consisterait pour un utilisateur à demander un tirage à pile ou face, puis à s'entendre avec le fournisseur VRF pour ne finaliser la requête que si le résultat est « pile ». Toutefois, les développeurs d'applications peuvent atténuer ces attaques — en particulier, tant que l'utilisateur ne tire aucun bénéfice d’un échec de publication, il n’a aucun motif de lancer une telle attaque.
Un autre inconvénient de la VRF est que la cryptographie impliquée est relativement complexe et gourmande en calcul. La plupart des blockchains ne disposent pas nativement de toutes les primitives cryptographiques nécessaires, ce qui signifie que la publication d’un nombre aléatoire peut consommer beaucoup de gas ou nécessiter plusieurs transactions.
Commit-reveal
La VRF n’est pas la seule méthode permettant d’améliorer les hypothèses de confiance dans la génération de nombres aléatoires. Une autre approche est le protocole commit-reveal, utilisé pour générer un nombre aléatoire entre deux parties qui ne se font pas confiance. Le fonctionnement de base est le suivant :
-
Durant la phase de requête, l'utilisateur et le fournisseur de services génèrent chacun un nombre aléatoire secret. Ils soumettent ensuite le hachage de ce nombre à la blockchain. Ce hachage est appelé valeur de commit.
-
Durant la phase de révélation, l'utilisateur et le fournisseur publient leurs nombres aléatoires. Chaque participant vérifie que le nombre publié par l'autre correspond bien à son valeur de commit. Une fois cette vérification terminée, le nombre aléatoire final est obtenu en hachant les deux nombres. Pour les déploiements blockchain, le hachage du bloc de la transaction initiale peut également être inclus dans le calcul final.
Comparé aux méthodes initiales, le protocole commit-reveal améliore également les hypothèses de confiance : l'utilisateur, le validateur et le fournisseur doivent tous coopérer pour prédire le nombre aléatoire. De plus, ce protocole utilise uniquement des techniques cryptographiques simples — il ne nécessite qu’une fonction de hachage — ce qui le rend facile à mettre en œuvre. Toutefois, il présente un problème d’activité similaire à celui de la VRF : l’un ou l’autre participant (utilisateur ou fournisseur) peut bloquer le protocole en refusant de publier son nombre. Comme avec la VRF, les développeurs d’applications peuvent atténuer ce risque en appliquant les mêmes stratégies mentionnées précédemment.
Notez que l'implémentation la plus basique de ce protocole nécessite plus de deux transactions, car l'utilisateur et le fournisseur doivent chacun envoyer une transaction à chaque étape. Ce défaut peut être atténué par des déploiements plus sophistiqués, permettant au fournisseur de pré-engager plusieurs nombres aléatoires. Pyth Entropy constitue une implémentation avancée du protocole commit-reveal.
La VRF et le protocole commit-reveal permettent aux développeurs d'applications d’obtenir de l'imprévisibilité au détriment de l’activité. Si un développeur craint le risque lié à la confiance en un seul fournisseur, il peut simplement demander des nombres aléatoires à N fournisseurs et combiner les résultats. Cette approche augmente l'imprévisibilité — tous les N fournisseurs doivent coopérer pour influencer le résultat — mais diminue l’activité — n’importe lequel des N fournisseurs peut empêcher la publication du nombre. Toutefois, notez qu’aucun des N fournisseurs ne connaît à l’avance le nombre aléatoire final, et ne peut donc pas utiliser cette connaissance pour décider quand interrompre le protocole.
Autres méthodes
D'autres méthodes plus avancées existent pour générer des nombres aléatoires sécurisés. Elles visent à améliorer le compromis entre imprévisibilité et activité, de sorte qu’il faille plus d’un fournisseur pour bloquer le protocole. Parmi celles-ci figurent la VRF seuil, où la clé secrète s est fragmentée entre plusieurs participants, ou encore les balises aléatoires (random beacons). Bien que ces méthodes offrent un meilleur compromis de sécurité que celles décrites précédemment, elles sont souvent excessives pour la plupart des applications, car les problèmes d’activité peuvent être atténués par une conception appropriée de l’application.
Conclusion
Cet article a présenté plusieurs méthodes de génération de nombres aléatoires sur blockchain, en analysant leurs avantages et inconvénients. Si vous développez une application nécessitant un générateur de nombres aléatoires sécurisé, consultez Pyth Entropy et contactez les contributeurs de Pyth via Discord, Telegram ou d'autres canaux sociaux pour découvrir comment utiliser ce produit innovant.
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
@PythNetwork
