{"id":33888,"date":"2019-10-31T21:55:15","date_gmt":"2019-10-31T18:55:15","guid":{"rendered":"https:\/\/prohoster.info\/blog\/sluchajnye-chisla-i-detsentralizovannye-seti-implementatsii\/"},"modified":"2019-10-31T21:55:15","modified_gmt":"2019-10-31T18:55:15","slug":"sluchajnye-chisla-i-detsentralizovannye-seti-implementatsii","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/sluchajnye-chisla-i-detsentralizovannye-seti-implementatsii","title":{"rendered":"Nombres al\u00e9atoires et r\u00e9seaux d\u00e9centralis\u00e9s : impl\u00e9mentations","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<h1 id=\"vvedenie\">Introduction<\/h1>\n<p><\/p>\n<pre><code class=\"plaintext\">function getAbsolutelyRandomNumer() {\n        return 4; \/\/ retourne un nombre absolument al\u00e9atoire !\n}<\/code><\/pre>\n<p><\/p>\n<p>Tout comme dans le cas du concept de chiffrement absolument r\u00e9sistant en cryptographie, les v\u00e9ritables protocoles de \"Publicly Verifiable Random Beacon\" (ci-apr\u00e8s PVRB) essaient simplement de se rapprocher le plus possible d'un sch\u00e9ma id\u00e9al, car dans des r\u00e9seaux r\u00e9els, il ne peut pas \u00eatre appliqu\u00e9 tel quel : il faut convenir d'un seul bit, le nombre de tours doit \u00eatre important, et tous les messages doivent \u00eatre parfaitement rapides et toujours livr\u00e9s. \u00c9videmment, ce n'est pas le cas dans les r\u00e9seaux r\u00e9els. Ainsi, lors de la conception de PVRB pour des t\u00e2ches sp\u00e9cifiques dans des blockchains modernes, en plus de l'impossibilit\u00e9 de contr\u00f4ler le random obtenu et de la r\u00e9sistance cryptographique, de nombreux probl\u00e8mes purement architecturaux et techniques surgissent.<\/p>\n<p><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p>La blockchain elle-m\u00eame constitue pour le PVRB un environnement de communication o\u00f9 les messages = transactions. Cela permet de s'abstraire partiellement des probl\u00e8mes de r\u00e9seau, de la non-livraison des messages, des probl\u00e8mes de logiciels interm\u00e9diaires : tous ces risques sont pris en charge par un r\u00e9seau d\u00e9centralis\u00e9, et la principale valeur de celui-ci pour le PVRB est l'impossibilit\u00e9 de r\u00e9voquer ou d'alt\u00e9rer une transaction d\u00e9j\u00e0 envoy\u00e9e - cela emp\u00eache les participants de se retirer du protocole, sauf s'ils ont r\u00e9ussi une attaque sur le consensus. Ce niveau de s\u00e9curit\u00e9 est acceptable, donc le PVRB doit \u00eatre r\u00e9sistant aux collusions des participants au m\u00eame titre que la cha\u00eene principale de la blockchain. De plus, cela sous-entend que le PVRB doit faire partie du consensus, si le r\u00e9seau s'accorde sur la cha\u00eene principale de blocs, il doit \u00e9galement s'accorder sur le seul random r\u00e9sultant honn\u00eate. Autrement, PVRB est simplement un protocole autonome, impl\u00e9ment\u00e9 par un smart contract, fonctionnant de mani\u00e8re asynchrone par rapport \u00e0 la blockchain et aux blocs. Chacune de ces m\u00e9thodes a ses propres avantages et inconv\u00e9nients, et le choix entre elles est extr\u00eamement non trivial. <\/p>\n<p><\/p>\n<h2 id=\"dva-sposoba-implementacii-pvrb\">Deux fa\u00e7ons d'impl\u00e9menter le PVRB<\/h2>\n<p><\/p>\n<p>D\u00e9crivons plus en d\u00e9tail deux variantes d'impl\u00e9mentation du PVRB - une version autonome, fonctionnant avec un smart contract ind\u00e9pendant de la blockchain, et une version int\u00e9gr\u00e9e au consensus - int\u00e9gr\u00e9e dans le protocole, selon lequel le r\u00e9seau s'accorde sur la cha\u00eene de blocs et les transactions incluses. Dans tous les cas, je ferai r\u00e9f\u00e9rence aux moteurs de blockchain populaires : Ethereum, EOS, et tous ceux qui leur ressemblent en termes de d\u00e9ploiement et de traitement des smart contracts. <\/p>\n<p><\/p>\n<h3 id=\"standalone-contract\">Contrat autonome<\/h3>\n<p><\/p>\n<p>Dans cette option, le PVRB est un contrat intelligent qui accepte les transactions des producteurs al\u00e9atoires (RP), les traite, combine les r\u00e9sultats et, en cons\u00e9quence, aboutit \u00e0 une certaine valeur, que tout utilisateur peut obtenir de ce contrat. Cette valeur peut ne pas \u00eatre directement stock\u00e9e dans le contrat, mais \u00eatre repr\u00e9sent\u00e9e uniquement par des donn\u00e9es \u00e0 partir desquelles il est possible d'obtenir de mani\u00e8re d\u00e9terministe une seule et unique valeur al\u00e9atoire r\u00e9sultante. Dans ce sch\u00e9ma, les RP sont des utilisateurs de la blockchain, et toute personne peut \u00eatre autoris\u00e9e \u00e0 participer au processus de g\u00e9n\u00e9ration.<\/p>\n<p><\/p>\n<p>L'option du contrat autonome est bonne :<\/p>\n<p><\/p>\n<ul>\n<li>pour sa portabilit\u00e9 (les contrats peuvent \u00eatre transf\u00e9r\u00e9s d'une blockchain \u00e0 une autre)<\/li>\n<li>pour sa simplicit\u00e9 de mise en \u0153uvre et de test (les contrats sont faciles \u00e0 \u00e9crire et \u00e0 tester)<\/li>\n<li>pour la commodit\u00e9 de mise en \u0153uvre de sch\u00e9mas \u00e9conomiques (il est facile de cr\u00e9er son propre token dont la logique sert les objectifs du PVRB)<\/li>\n<li>pour la possibilit\u00e9 de d\u00e9ploiement sur des blockchains d\u00e9j\u00e0 en fonctionnement<\/li>\n<\/ul>\n<p><\/p>\n<p>Il pr\u00e9sente \u00e9galement des inconv\u00e9nients :<\/p>\n<p><\/p>\n<ul>\n<li>des restrictions s\u00e9v\u00e8res sur les ressources lors des calculs, le volume des transactions et le stockage (en d'autres termes, cpu\/mem\/io)<\/li>\n<li>des limitations sur les op\u00e9rations \u00e0 l'int\u00e9rieur du contrat (toutes les instructions ne sont pas accessibles, il est difficile de connecter des biblioth\u00e8ques externes)<\/li>\n<li>l'impossibilit\u00e9 d'organiser des \u00e9changes de messages plus rapidement que les transactions ne sont incluses dans la blockchain<\/li>\n<\/ul>\n<p><\/p>\n<p>Cette option convient pour la mise en \u0153uvre d'un PVRB qui doit \u00eatre lanc\u00e9 dans un r\u00e9seau existant, ne contenant pas de cryptographie complexe et ne n\u00e9cessitant pas beaucoup d'interactions.<\/p>\n<p><\/p>\n<h3 id=\"consensus-integrated\">Int\u00e9gr\u00e9 au consensus<\/h3>\n<p><\/p>\n<p>Dans cette version, le PVRB est impl\u00e9ment\u00e9 dans le code du n\u0153ud blockchain, int\u00e9gr\u00e9 ou fonctionnant parall\u00e8lement \u00e0 l'\u00e9change de messages entre les n\u0153uds de la blockchain. Les r\u00e9sultats du protocole sont directement inscrits dans les blocs produits, et les messages du protocole sont envoy\u00e9s via le r\u00e9seau P2P entre les n\u0153uds. Puisque le protocole aboutit \u00e0 des nombres qui doivent \u00eatre enregistr\u00e9s dans les blocs, le r\u00e9seau doit parvenir \u00e0 un consensus \u00e0 leur sujet. Cela signifie que les messages PVRB, tout comme les transactions, doivent \u00eatre valid\u00e9s par les n\u0153uds et inclus dans les blocs afin que tout participant au r\u00e9seau puisse valider le respect du protocole PVRB. Cela nous am\u00e8ne automatiquement \u00e0 une solution \u00e9vidente : si le r\u00e9seau parvient \u00e0 un consensus concernant le bloc et les transactions qu'il contient, alors le PVRB doit faire partie du consensus, et ne pas \u00eatre un protocole s\u00e9par\u00e9. Autrement, il pourrait y avoir une situation o\u00f9 le bloc est valide du point de vue du consensus, mais le protocole PVRB n'a pas \u00e9t\u00e9 respect\u00e9, et d'un point de vue PVRB, le bloc ne peut pas \u00eatre accept\u00e9. Donc, si l'option \u00ab int\u00e9gr\u00e9e au consensus \u00bb est choisie, le PVRB devient une partie importante du consensus.<\/p>\n<p><\/p>\n<p>En d\u00e9crivant les impl\u00e9mentations du PVRB au niveau du consensus dans le r\u00e9seau, il est imp\u00e9ratif de ne pas n\u00e9gliger les questions de finalit\u00e9. La finalit\u00e9 est un m\u00e9canisme utilis\u00e9 dans des consensus d\u00e9terministes, fixant un bloc (et la cha\u00eene le menant) comme final, et qui ne sera jamais abandonn\u00e9, m\u00eame si un fork parall\u00e8le appara\u00eet. Par exemple, le Bitcoin n'a pas ce m\u00e9canisme \u2014 si une cha\u00eene de plus grande complexit\u00e9 est publi\u00e9e, elle remplacera toute cha\u00eene de moindre complexit\u00e9, quelle que soit la longueur des cha\u00eenes. En revanche, dans EOS, les blocs finaux sont appel\u00e9s Last Irreversible Blocks, qui apparaissent en moyenne tous les 432 blocs (12*21 + 12*15, pr\u00e9-vote + pr\u00e9-engagement). Ce processus est essentiellement l'attente des signatures des block-producers (BP) \u00e0 un niveau de 2\/3. Lorsqu'il y a des forks plus anciens que le dernier LIB, ils sont simplement rejet\u00e9s. Ce m\u00e9canisme garantit que la transaction est incluse dans la blockchain et ne sera jamais annul\u00e9e, quelle que soit la puissance de l'attaquant. De plus, les blocs finaux sont ceux sign\u00e9s par 2\/3 des BP dans Hyperledger, Tendermint et d'autres consensus bas\u00e9s sur le pBFT. De plus, il est logique de rendre le protocole garantissant la finalit\u00e9 une surcouche du consensus, car il peut fonctionner de mani\u00e8re asynchrone avec la production et la publication des blocs. Voici un bon exemple. <noindex><a rel=\"nofollow\" href=\"https:\/\/arxiv.org\/pdf\/1710.09437.pdf\">article<\/a><\/noindex> sur la finalit\u00e9 dans Ethereum.<\/p>\n<p><\/p>\n<p>La finalit\u00e9 est extr\u00eamement importante pour les utilisateurs qui, sans elle, peuvent devenir victimes d'une attaque de \u00ab double d\u00e9pense \u00bb, lorsque le BP \u00ab retient \u00bb des blocs et les publie apr\u00e8s que le r\u00e9seau a \u00ab vu \u00bb une bonne transaction. S'il n'y a pas de finalit\u00e9, la fourche publi\u00e9e remplace le bloc contenant la transaction \u00ab bonne \u00bb par un autre, d'une \u00ab mauvaise \u00bb fourche, dans laquelle les m\u00eames fonds sont transf\u00e9r\u00e9s \u00e0 l'adresse de l'attaquant. Dans le cas du PVRB, les exigences en mati\u00e8re de finalit\u00e9 sont encore plus strictes, car la construction de fourches pour le PVRB signifie que l'attaquant peut pr\u00e9parer plusieurs variantes de randomness dans le but de publier celle qui lui est la plus favorable et de limiter le temps d'une attaque possible \u2014 une bonne solution.<\/p>\n<p><\/p>\n<p>Ainsi, la meilleure option serait de combiner PVRB et finalit\u00e9 en un seul protocole \u2014 alors le bloc finalis\u00e9 = randomness finalis\u00e9, et c'est exactement ce que nous devions obtenir. Maintenant, les joueurs recevront une randomness garantie en N secondes et peuvent \u00eatre s\u00fbrs qu'il est impossible de le revenir en arri\u00e8re ou de rejouer.<\/p>\n<p><\/p>\n<p>L'option avec consensus int\u00e9gr\u00e9 est bonne :<\/p>\n<p><\/p>\n<ul>\n<li>la capacit\u00e9 de mise en \u0153uvre asynchrone par rapport \u00e0 la production de blocs \u2014 les blocs sont produits comme d'habitude, mais parall\u00e8lement, le protocole PVRB peut fonctionner, qui produit des randoms pas \u00e0 chaque bloc<\/li>\n<li>la possibilit\u00e9 d'impl\u00e9menter m\u00eame une cryptographie lourde, sans les restrictions impos\u00e9es par les contrats intelligents<\/li>\n<li>la possibilit\u00e9 d'organiser des \u00e9changes de messages plus rapidement que les transactions ne sont int\u00e9gr\u00e9es dans la blockchain, par exemple, une partie du protocole peut fonctionner entre les n\u0153uds sans diffusion des messages sur le r\u00e9seau<\/li>\n<\/ul>\n<p><\/p>\n<p>Il pr\u00e9sente \u00e9galement des inconv\u00e9nients :<\/p>\n<p><\/p>\n<ul>\n<li>des difficult\u00e9s lors des tests et du d\u00e9veloppement \u2014 il faudra \u00e9muler des erreurs r\u00e9seau, des n\u0153uds manquants, des hard forks du r\u00e9seau<\/li>\n<li>des erreurs dans l'impl\u00e9mentation n\u00e9cessitent un hard fork du r\u00e9seau<\/li>\n<\/ul>\n<p><\/p>\n<p>Les deux m\u00e9thodes d'impl\u00e9mentation du PVRB ont droit de cit\u00e9, mais l'impl\u00e9mentation sur des contrats intelligents dans les blockchains modernes est tout de m\u00eame fortement limit\u00e9e en ressources de calcul, et toute transition vers une cryptographie s\u00e9rieuse est souvent simplement impossible. Et nous aurons besoin d'une cryptographie s\u00e9rieuse, comme cela sera d\u00e9montr\u00e9 plus loin. Cependant, ce probl\u00e8me est clairement temporaire, une cryptographie s\u00e9rieuse dans les contrats est n\u00e9cessaire pour r\u00e9soudre de nombreuses t\u00e2ches, et progressivement elle appara\u00eet (par exemple, les contrats syst\u00e8mes pour zkSNARKs dans Ethereum).<\/p>\n<p><\/p>\n<p>La blockchain qui assure un canal de communication transparent et fiable pour le protocole n'est pas gratuite. Tout protocole d\u00e9centralis\u00e9 doit tenir compte de la possibilit\u00e9 d'attaques Sybil ; toute action peut \u00eatre r\u00e9alis\u00e9e par le biais de la collusion de plusieurs comptes. Par cons\u00e9quent, lors de la conception, il est essentiel d'\u00e9valuer les capacit\u00e9s des attaquants \u00e0 cr\u00e9er un nombre arbitraire de participants au protocole agissant en accord. <\/p>\n<p><\/p>\n<h2 id=\"pvrb-i-peremennye-bloka\">PVRB et variables de bloc.<\/h2>\n<p><\/p>\n<p>Je n'ai pas menti en disant qu'il n'existe pas de bon PVRB, v\u00e9rifi\u00e9 par de nombreuses applications de jeux, dans les blockchains pour le moment. D'o\u00f9 alors un tel nombre d'applications de jeux sur Ethereum et EOS ? Cela m'\u00e9tonne autant que vous. D'o\u00f9 provient tant de 'hasards' 'robustes' dans un environnement enti\u00e8rement d\u00e9terministe ?<\/p>\n<p><\/p>\n<p>La m\u00e9thode pr\u00e9f\u00e9r\u00e9e pour obtenir du hasard dans la blockchain consiste \u00e0 prendre une information 'impr\u00e9visible' d'un bloc et \u00e0 s'en servir pour g\u00e9n\u00e9rer du hasard, simplement en hachant une ou plusieurs valeurs. Voici un bon article sur les probl\u00e8mes de tels sch\u00e9mas. <noindex><a rel=\"nofollow\" href=\"https:\/\/blog.positive.com\/predicting-random-numbers-in-ethereum-smart-contracts-e5358c6b8620\">ici<\/a><\/noindex>. Vous pouvez utiliser l'une des valeurs 'impr\u00e9visibles' d'un bloc, comme le hachage du bloc, le nombre de transactions, la difficult\u00e9 du r\u00e9seau et d'autres valeurs inconnues \u00e0 l'avance. Ensuite, vous les hachez, une ou plusieurs, et, en th\u00e9orie, cela devrait donner un v\u00e9ritable hasard. Vous pourriez m\u00eame ajouter dans le livre blanc que votre sch\u00e9ma est 'post-quantum secure' (puisqu'il existe des fonctions de hachage r\u00e9sistantes aux quantiques :)).<\/p>\n<p><\/p>\n<p>Mais m\u00eame les hachages post-quantiques ne suffisent pas, h\u00e9las. Le secret r\u00e9side dans les exigences relatives au PVRB, je rappelle celles-ci de l'article pr\u00e9c\u00e9dent :<\/p>\n<p><\/p>\n<ol>\n<li>Le r\u00e9sultat doit avoir une distribution prouv\u00e9e \u00e9quitable, c'est-\u00e0-dire reposant sur une cryptographie r\u00e9sistante \u00e0 la preuve.<\/li>\n<li>Il est impossible de contr\u00f4ler l'un des bits du r\u00e9sultat. Par cons\u00e9quent, le r\u00e9sultat ne peut pas \u00eatre pr\u00e9dit \u00e0 l'avance.<\/li>\n<li>Il est impossible de saboter le protocole de g\u00e9n\u00e9ration en ne participant pas au protocole ou en surchargeant le r\u00e9seau avec des messages attaquants.<\/li>\n<li>Tout ce qui pr\u00e9c\u00e8de doit \u00eatre r\u00e9sistant aux collusions d'un nombre admissible de participants malhonn\u00eates au protocole (par exemple 1\/3 des participants).<\/li>\n<\/ol>\n<p><\/p>\n<p>Dans ce cas, seule l'exigence 1 est respect\u00e9e, et l'exigence 2 n'est pas respect\u00e9e. En hachant des valeurs impr\u00e9visibles du bloc, nous obtiendrons une r\u00e9partition uniforme et de bons al\u00e9atoires. Cependant, le BP a au moins la possibilit\u00e9 de \u00ab publier le bloc ou non \u00bb. Ainsi, le BP peut au moins choisir entre DEUX options d'al\u00e9atoire : le sien et celui qui sera obtenu si le bloc est cr\u00e9\u00e9 par quelqu'un d'autre. Le BP peut \u00ab jeter un coup d'\u0153il \u00bb \u00e0 l'avance sur ce qui se passera s'il publie le bloc et d\u00e9cider simplement de le faire ou non. Ainsi, en jouant par exemple \u00e0 \u00ab pair\/impair \u00bb ou \u00ab rouge\/noir \u00bb \u00e0 la roulette, il peut publier le bloc seulement s'il voit un gain. Cela rend \u00e9galement non fonctionnelle la strat\u00e9gie d'utilisation, par exemple, du hachage du bloc \u00ab du futur \u00bb. Dans ce cas, on dit que \u00ab le random sera celui qui est obtenu par le hachage des donn\u00e9es actuelles et le hachage du futur bloc d'une hauteur, par exemple, N + 42, o\u00f9 N est la hauteur actuelle du bloc. Cela renforce un peu le sch\u00e9ma, mais permet quand m\u00eame au BP, m\u00eame dans le futur, de choisir de retenir le bloc ou de le publier.<\/p>\n<p><\/p>\n<p>Dans ce cas, le logiciel du BP est compliqu\u00e9, mais pas trop. Lors de la validation et de l'inclusion de la transaction dans le bloc, une v\u00e9rification rapide est effectu\u00e9e pour savoir s'il y aura un gain, et peut-\u00eatre un ajustement d'un des param\u00e8tres de la transaction pour obtenir une probabilit\u00e9 \u00e9lev\u00e9e de gain. Cependant, attraper un BP intelligent derri\u00e8re de telles manipulations est pratiquement impossible, chaque fois, de nouvelles adresses peuvent \u00eatre utilis\u00e9es, permettant de gagner petit \u00e0 petit sans \u00e9veiller de soup\u00e7ons.<\/p>\n<p><\/p>\n<p>Ainsi, les m\u00e9thodes utilisant des informations du bloc ne conviennent pas pour \u00eatre une impl\u00e9mentation universelle du PVRB. Dans une version limit\u00e9e, avec des restrictions sur les tailles de paris, des limites sur le nombre de joueurs et\/ou une inscription KYC (afin de ne pas donner \u00e0 un joueur la possibilit\u00e9 d'utiliser plusieurs adresses), ces sch\u00e9mas peuvent fonctionner pour de petites jeux, mais pas plus.<\/p>\n<p><\/p>\n<h2 id=\"pvrb-i-commit-reveal\">PVRB et commit-reveal.<\/h2>\n<p><\/p>\n<p>Eh bien, merci au hachage et \u00e0 la relative impr\u00e9visibilit\u00e9 du hachage du bloc et d'autres variables. S'il est possible de r\u00e9soudre le probl\u00e8me du front-running des mineurs, quelque chose de plus solide devrait \u00e9merger. Ajoutons \u00e0 ce sch\u00e9ma les utilisateurs - qu'ils influencent aussi le random : n'importe quel employ\u00e9 du support technique vous dira que la chose la plus al\u00e9atoire dans les syst\u00e8mes informatiques, ce sont les actions des utilisateurs \ud83d\ude42<\/p>\n<p><\/p>\n<p>Un sch\u00e9ma na\u00eff o\u00f9 les utilisateurs envoient simplement des nombres al\u00e9atoires et o\u00f9 le r\u00e9sultat est calcul\u00e9 comme, par exemple, le hachage de leur somme, n'est pas adapt\u00e9. Dans ce cas, le dernier joueur peut contr\u00f4ler le r\u00e9sultat en choisissant son propre al\u00e9a. C'est pourquoi on utilise un mod\u00e8le tr\u00e8s r\u00e9pandu de commit-reveal. Les participants envoient d'abord des hachages de leurs al\u00e9as (commits), puis r\u00e9v\u00e8lent leurs al\u00e9as r\u00e9els (reveals). La phase \"reveal\" commence seulement apr\u00e8s que les commits n\u00e9cessaires aient \u00e9t\u00e9 collect\u00e9s, permettant aux participants d'envoyer exactement l'al\u00e9a dont ils ont envoy\u00e9 le hachage pr\u00e9c\u00e9demment. Maintenant, assemblons tout cela avec les param\u00e8tres du bloc, pris de mani\u00e8re optimale dans le futur (l'al\u00e9a ne peut \u00eatre connu que dans l'un des blocs futurs), et voil\u00e0 \u2014 l'al\u00e9a est pr\u00eat ! D\u00e9sormais, chaque joueur influence l'al\u00e9a r\u00e9sultant et peut \u00ab battre \u00bb un BP malveillant en recouvrant son al\u00e9a avec le sien, qui est inconnu \u00e0 l'avance. On peut \u00e9galement ajouter une protection contre le sabotage du protocole par une non-r\u00e9v\u00e9lation \u00e0 l'\u00e9tape de reveal \u2014 en exigeant simplement lors du commit de joindre \u00e0 la transaction une certaine somme \u2014 un d\u00e9p\u00f4t de garantie, qui ne sera restitu\u00e9 qu'\u00e0 la proc\u00e9dure de reveal. Dans ce cas, faire un commit sans faire de reveal serait d\u00e9savantageux.<\/p>\n<p><\/p>\n<p>C'\u00e9tait une bonne tentative, et des sch\u00e9mas comme ceux-ci existent \u00e9galement dans des DApp de jeux, mais h\u00e9las, cela ne suffit toujours pas. Maintenant, le r\u00e9sultat peut \u00eatre influenc\u00e9 non seulement par le mineur, mais aussi par n'importe quel participant au protocole. Il est toujours possible de contr\u00f4ler la valeur elle-m\u00eame, avec une moindre variabilit\u00e9 et contre r\u00e9mun\u00e9ration, mais, comme dans le cas du mineur, si les r\u00e9sultats du tirage valent plus que le co\u00fbt de participation au protocole PVRB, alors le random-producer (RP) peut d\u00e9cider de faire le reveal et peut toujours choisir parmi au moins deux options d'al\u00e9a.<br \/>\nCependant, il existe maintenant la possibilit\u00e9 de punir ceux qui font un commit sans faire de reveal, et ce sch\u00e9ma sera encore utile. Sa simplicit\u00e9 est un avantage s\u00e9rieux \u2014 des protocoles plus complexes n\u00e9cessitent des calculs beaucoup plus puissants.<\/p>\n<p><\/p>\n<h2 id=\"pvrb-i-determinirovannye-podpisi\">PVRB et signatures d\u00e9terministes.<\/h2>\n<p><\/p>\n<p>Il existe un autre moyen de faire en sorte que le RP fournisse un nombre pseudo-al\u00e9atoire sur lequel il ne pourra pas influencer, en lui fournissant un \"mod\u00e8le\" : c'est une signature d\u00e9terministe. Une telle signature est, par exemple, RSA, et ne l'est pas en ECS. Si le RP poss\u00e8de une paire de cl\u00e9s : RSA et ECC, et qu'il signe une certaine valeur avec sa cl\u00e9 priv\u00e9e, alors dans le cas de RSA, il obtiendra UNE ET UNE SEULE signature, tandis qu'avec ECS, il peut g\u00e9n\u00e9rer un nombre quelconque de signatures valides diff\u00e9rentes. Cela est d\u00fb au fait que lors de la cr\u00e9ation de la signature ECS, un nombre al\u00e9atoire est choisi par le signataire, et il peut \u00eatre choisi comme bon semble, permettant au signataire de choisir parmi plusieurs signatures. Dans le cas de RSA : \"une valeur d'entr\u00e9e\" + \"une paire de cl\u00e9s\" = \"une signature\". Il est impossible de pr\u00e9dire quelle signature aura un autre RP, donc le PVRB avec des signatures d\u00e9terministes peut \u00eatre organis\u00e9 en combinant des signatures RSA de plusieurs participants qui ont sign\u00e9 la m\u00eame valeur. Par exemple - le pr\u00e9c\u00e9dent al\u00e9atoire. Ce sch\u00e9ma permet d'\u00e9conomiser de nombreuses ressources, car les signatures sont \u00e0 la fois une confirmation de la conformit\u00e9 au protocole et une source d'al\u00e9atoire.<\/p>\n<p><\/p>\n<p>Cependant, m\u00eame avec des signatures d\u00e9terministes, le sch\u00e9ma reste vuln\u00e9rable \u00e0 la probl\u00e9matique de \"l'acteur final\". Le dernier participant peut encore d\u00e9cider s'il publie sa signature ou non, contr\u00f4lant ainsi le r\u00e9sultat. Il est possible d'am\u00e9liorer le sch\u00e9ma, d'y ajouter des hachages de blocs, de cr\u00e9er des tours pour que le r\u00e9sultat ne puisse pas \u00eatre pr\u00e9dit \u00e0 l'avance, mais toutes ces techniques, m\u00eame avec de nombreuses am\u00e9liorations, laissent tout de m\u00eame la probl\u00e9matique de l'influence d'un participant sur le r\u00e9sultat collectif dans un environnement non fiable non r\u00e9solue et peuvent fonctionner uniquement dans des conditions de contraintes \u00e9conomiques et de temps. De plus, la taille des cl\u00e9s RSA (1024 et 2048 bits) est assez grande, et la taille pour les transactions blockchain est un param\u00e8tre extr\u00eamement important. Apparemment, il ne sera pas possible de r\u00e9soudre le probl\u00e8me simplement, avan\u00e7ons.<\/p>\n<p><\/p>\n<h2 id=\"pvrb-i-secret-sharing-shemy\">PVRB et les sch\u00e9mas de partage secret<\/h2>\n<p><\/p>\n<p>En cryptographie, il existe des sch\u00e9mas qui permettent \u00e0 un r\u00e9seau de convenir d'une valeur unique pour le PVRB, tout en \u00e9tant r\u00e9sistant \u00e0 toute action malveillante d'une partie des participants. Un des protocoles int\u00e9ressants \u00e0 conna\u00eetre est le sch\u00e9ma de partage de secret de Shamir. Ce sch\u00e9ma permet de diviser un secret (par exemple une cl\u00e9 secr\u00e8te) en plusieurs parts et de distribuer ces parts \u00e0 N participants. Le secret est distribu\u00e9 de mani\u00e8re \u00e0 ce que M parts sur N soient suffisantes pour le reconstituer, et cela peut \u00eatre n'importe quelle combinaison de M parts. Pour faire simple, ayant un graphique d'une fonction inconnue, les participants \u00e9changent des points sur ce graphique, et apr\u00e8s avoir re\u00e7u M points, toute la fonction peut \u00eatre reconstitu\u00e9e.<br \/>\nUne bonne explication est donn\u00e9e dans <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Shamir%27s_Secret_Sharing\">wiki<\/a><\/noindex> et pour s'y essayer pratiquement, il est utile de jouer avec sur la <noindex><a rel=\"nofollow\" href=\"http:\/\/point-at-infinity.org\/ssss\/demo.html\">d\u00e9mo<\/a><\/noindex> page.<\/p>\n<p><\/p>\n<p>Si le sch\u00e9ma FSSS (Fiat-Shamir Secret Sharing) \u00e9tait applicable tel quel, alors ce serait un PVRB infaillible. Dans sa version la plus simple, le protocole pourrait ressembler \u00e0 ceci :<\/p>\n<p><\/p>\n<ul>\n<li>Chaque participant g\u00e9n\u00e8re son propre random et distribue des parts de celui-ci aux autres participants.<\/li>\n<li>Chaque participant d\u00e9voile sa part des secrets des autres participants.<\/li>\n<li>Si un participant a recueilli plus de M parts, alors son num\u00e9ro peut \u00eatre calcul\u00e9 et il sera unique, quel que soit l'ensemble des participants qui ont d\u00e9voil\u00e9 leurs parts.<\/li>\n<li>La combinaison des randoms d\u00e9voil\u00e9s constitue le PVRB recherch\u00e9.<\/li>\n<\/ul>\n<p><\/p>\n<p>Ici, un participant individuel n'influence plus les r\u00e9sultats du protocole, sauf dans les cas o\u00f9 sa contribution est essentielle au seuil de r\u00e9v\u00e9lation du random. Ainsi, ce protocole, en pr\u00e9sence d'une fraction n\u00e9cessaire de participants fonctionnant selon le protocole et de RPs accessibles, fonctionne, remplissant les exigences de r\u00e9sistance cryptographique et \u00e9tant r\u00e9sistant au probl\u00e8me du \u00ab dernier acteur \u00bb.<\/p>\n<p><\/p>\n<p>Cela pourrait \u00eatre la solution id\u00e9ale, ce sch\u00e9ma PVRB bas\u00e9 sur le partage de secret de Fiat-Shamir est d\u00e9crit, par exemple, dans <noindex><a rel=\"nofollow\" href=\"https:\/\/eprint.iacr.org\/2017\/216.pdf\">celui-ci<\/a><\/noindex> l'article. Mais, comme mentionn\u00e9 pr\u00e9c\u00e9demment, essayer de l'appliquer directement dans une blockchain entra\u00eene d\u00e9j\u00e0 des limitations techniques. Voici un exemple d'impl\u00e9mentation de test du protocole dans un contrat intelligent EOS et la partie la plus importante \u2014 la v\u00e9rification de la part publi\u00e9e d'un participant : <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/mixbytes\/eoscraper\/blob\/master\/Proof.hh#L23\">code<\/a><\/noindex>Le code montre que la validation du proof exige plusieurs multiplications scalaires, et des nombres tr\u00e8s grands sont utilis\u00e9s. Il faut comprendre que dans les blockchains, la v\u00e9rification se produit au moment o\u00f9 le producteur de blocs traite la transaction, et chaque participant doit pouvoir v\u00e9rifier facilement la validit\u00e9 du protocole. Par cons\u00e9quent, les exigences de vitesse pour la fonction de v\u00e9rification sont tr\u00e8s strictes. Dans cette variante, le syst\u00e8me s'est av\u00e9r\u00e9 non fonctionnel, car la v\u00e9rification d\u00e9passait la limite de temps de la transaction (0,5 seconde).<\/p>\n<p><\/p>\n<p>L'efficacit\u00e9 de la v\u00e9rification est l'une des exigences les plus importantes pour l'utilisation de pratiquement tous les sch\u00e9mas cryptographiques avanc\u00e9s dans la blockchain. La cr\u00e9ation de proofs, la pr\u00e9paration de messages \u2014 ces proc\u00e9dures peuvent \u00eatre r\u00e9alis\u00e9es hors cha\u00eene et ex\u00e9cut\u00e9es sur des ordinateurs haute performance, mais il n'est pas possible d'\u00e9viter la v\u00e9rification \u2014 c'est une autre exigence essentielle pour le PVRB. <\/p>\n<p><\/p>\n<h2 id=\"pvrb-i-threshold-signatures\">PVRB et signatures seuil<\/h2>\n<p><\/p>\n<p>En d\u00e9couvrant le sch\u00e9ma de partage de secrets, nous avons ouvert toute une classe de protocoles, regroup\u00e9s sous le mot-cl\u00e9 \u00ab seuil \u00bb. Lorsque la divulgation d'informations requiert la participation de M participants honn\u00eates sur N, et que l'ensemble des participants honn\u00eates peut \u00eatre n'importe quel sous-ensemble de N, on parle de sch\u00e9mas \u00ab \u00e0 seuil \u00bb. Ces derniers permettent de r\u00e9soudre le probl\u00e8me du \u00ab dernier acteur \u00bb. Si un attaquant ne divulgue pas sa part du secret, un autre participant honn\u00eate le fera \u00e0 sa place. Ces sch\u00e9mas permettent de convenir d'une et d'une seule valeur, m\u00eame en cas de sabotage du protocole par certains participants. <\/p>\n<p><\/p>\n<p>La combinaison de signatures d\u00e9terministes et de sch\u00e9mas \u00e0 seuil a permis de d\u00e9velopper un sch\u00e9ma tr\u00e8s pratique et prometteur pour la r\u00e9alisation du PVRB \u2014 ce sont les signatures \u00e0 seuil d\u00e9terministes. Voici <noindex><a rel=\"nofollow\" href=\"https:\/\/eprint.iacr.org\/2002\/081.pdf\">article<\/a><\/noindex> sur les diff\u00e9rentes applications des signatures \u00e0 seuil, et voici encore un bon <noindex><a rel=\"nofollow\" href=\"https:\/\/blog.dash.org\/secret-sharing-and-threshold-signatures-with-bls-954d1587b5f\">longread<\/a><\/noindex> de Dash. <\/p>\n<p><\/p>\n<p>Le dernier article d\u00e9crit les signatures BLS (BLS signifie Boneh-Lynn-Shacham, <noindex><a rel=\"nofollow\" href=\"https:\/\/www.iacr.org\/archive\/asiacrypt2001\/22480516.pdf\">voici<\/a><\/noindex> Un article qui poss\u00e8de une qualit\u00e9 tr\u00e8s importante et extr\u00eamement pratique pour les programmeurs \u2014 les cl\u00e9s publiques, secr\u00e8tes et les signatures BLS peuvent \u00eatre combin\u00e9es entre elles gr\u00e2ce \u00e0 des op\u00e9rations math\u00e9matiques simples, tout en restant des cl\u00e9s et signatures valides, permettant ainsi d'agr\u00e9ger facilement de nombreuses signatures en une seule et de nombreuses cl\u00e9s publiques en une seule. Elles poss\u00e8dent \u00e9galement une d\u00e9terminisme et produisent le m\u00eame r\u00e9sultat avec les m\u00eames donn\u00e9es d'entr\u00e9e. Gr\u00e2ce \u00e0 cette qualit\u00e9, les combinaisons de signatures BLS elles-m\u00eames sont des cl\u00e9s valides, ce qui permet de r\u00e9aliser un sc\u00e9nario o\u00f9 M participants sur N produisent une seule et unique signature, qui est d\u00e9termin\u00e9e, publiquement v\u00e9rifiable et impr\u00e9visible jusqu'\u00e0 ce que le M\u00e8me participant ne l'ait r\u00e9v\u00e9l\u00e9e.<\/p>\n<p><\/p>\n<p>Dans le sch\u00e9ma des signatures BLS par seuil, chaque participant signe \u00e0 l'aide de BLS quelque chose (par exemple, un al\u00e9atoire pr\u00e9c\u00e9dent), et la signature globale par seuil est le random recherch\u00e9. Les propri\u00e9t\u00e9s cryptographiques des signatures BLS r\u00e9pondent aux exigences de qualit\u00e9 du random, la partie seuil prot\u00e8ge contre l'\u00ab acteur final \u00bb, et la combinabilit\u00e9 unique des cl\u00e9s permet de r\u00e9aliser de nombreux autres algorithmes int\u00e9ressants, qui, par exemple, permettent d'agr\u00e9ger efficacement les messages du protocole.<\/p>\n<p><\/p>\n<p>Donc, si vous construisez un PVRB dans votre blockchain, vous arriverez tr\u00e8s probablement \u00e0 un sch\u00e9ma de signatures BLS par seuil, qui est d\u00e9j\u00e0 utilis\u00e9 par plusieurs projets. Par exemple, DFinity (<noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/dfinity\/random-beacon\">ici<\/a><\/noindex> un benchmark impl\u00e9mentant le sch\u00e9ma, et <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/dfinity\/vss\/blob\/master\/docs\/index.md\">ici<\/a><\/noindex> un exemple d'impl\u00e9mentation du partage secret v\u00e9rifiable), ou Keep.network (voici leur random beacon <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/keep-network\/random-beacon-yellowpaper\">yellowpaper<\/a><\/noindex>, mais voici <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/keep-network\/random-beacon-box\">exemple<\/a><\/noindex> un contrat intelligent qui g\u00e8re le protocole).<\/p>\n<p><\/p>\n<h2 id=\"implementaciya-pvrb\">Impl\u00e9mentation PVRB<\/h2>\n<p><\/p>\n<p>Malheureusement, nous ne voyons toujours pas de protocole PVRB pr\u00eat, r\u00e9alis\u00e9 sur les blockchains, prouvant sa s\u00e9curit\u00e9 et sa robustesse. Bien que les protocoles eux-m\u00eames soient pr\u00eats, il est techniquement difficile de les appliquer aux solutions existantes. Pour les syst\u00e8mes centralis\u00e9s, PVRB n'a pas de sens, tandis que les syst\u00e8mes d\u00e9centralis\u00e9s sont strictement limit\u00e9s dans toutes les ressources informatiques : CPU, m\u00e9moire, stockage, I\/O. La conception de PVRB consiste \u00e0 combiner diff\u00e9rents protocoles pour cr\u00e9er quelque chose qui r\u00e9ponde \u00e0 toutes les exigences d'au moins un blockchain viable. Un protocole calcule efficacement, mais n\u00e9cessite davantage de messages entre les RP, tandis qu'un autre n\u00e9cessite tr\u00e8s peu de messages, mais la cr\u00e9ation d'une preuve peut prendre des dizaines de minutes, voire des heures.<\/p>\n<p><\/p>\n<p>Je vais \u00e9num\u00e9rer les facteurs que vous devez prendre en compte lors du choix d'un PVRB de qualit\u00e9 :<\/p>\n<p><\/p>\n<ul>\n<li><em>Solidit\u00e9 cryptographique<\/em>. Votre PVRB doit \u00eatre strictement inbiasable, sans possibilit\u00e9 de contr\u00f4ler un seul bit. Dans certains sch\u00e9mas, ce n'est pas le cas, donc faites appel \u00e0 un cryptographe.<\/li>\n<li><em>Probl\u00e8me de \u201cdernier acteur\u201d<\/em>. Votre PVRB doit \u00eatre r\u00e9sistant aux attaques, lorsque l'attaquant, contr\u00f4lant un ou plusieurs RP, peut choisir l'un des deux r\u00e9sultats.<\/li>\n<li><em>Probl\u00e8me de sabotage du protocole<\/em>. Votre PVRB doit \u00eatre r\u00e9sistant aux attaques, lorsque l'attaquant, contr\u00f4lant un ou plusieurs RP, d\u00e9cide s'il y a du hasard ou non et peut influencer cela de mani\u00e8re garantissant ou avec une probabilit\u00e9 donn\u00e9e.<\/li>\n<li><em>Probl\u00e8me du nombre de messages<\/em>. Vos RP doivent envoyer un minimum de messages \u00e0 la blockchain et \u00e9viter autant que possible les actions synchrones telles que 'j'ai envoy\u00e9 certaines informations, j'attends une r\u00e9ponse d'un participant sp\u00e9cifique'. Dans les r\u00e9seaux P2P, surtout g\u00e9ographiquement dispers\u00e9s, on ne peut pas compter sur une r\u00e9ponse rapide.<\/li>\n<li><em>Probl\u00e8me de complexit\u00e9 computationnelle<\/em>. La v\u00e9rification de toute \u00e9tape de PVRB on-chain doit \u00eatre extr\u00eamement simple, car elle est effectu\u00e9e par tous les clients complets du r\u00e9seau. Si la mise en \u0153uvre est faite via un smart contract, les exigences de vitesse sont tr\u00e8s strictes.<\/li>\n<li><em>Probl\u00e8me d'accessibilit\u00e9 et de vivacit\u00e9<\/em>. Votre PVRB doit aspire \u00e0 \u00eatre r\u00e9sistant aux situations o\u00f9 une partie du r\u00e9seau devient inaccessible pendant un certain temps et o\u00f9 une partie des RP cesse simplement de fonctionner.<\/li>\n<li><em>Probl\u00e8me de configuration de confiance et de distribution initiale des cl\u00e9s<\/em>. Si votre PVRB utilise un protocole de configuration primaire, c'est une autre histoire importante et complexe. Voici <noindex><a rel=\"nofollow\" href=\"https:\/\/z.cash\/ru\/blog\/the-design-of-the-ceremony\/\">exemple<\/a><\/noindex>. Si les participants doivent \u00e9changer leurs cl\u00e9s avant le d\u00e9but du protocole, c'est \u00e9galement un probl\u00e8me si la composition des participants change<\/li>\n<li><em>Probl\u00e8mes de d\u00e9veloppement<\/em>. La disponibilit\u00e9 des biblioth\u00e8ques dans les langues n\u00e9cessaires, leur s\u00e9curit\u00e9 et leur performance, leur accessibilit\u00e9, des tests complexes, etc.<\/li>\n<\/ul>\n<p><\/p>\n<p>Par exemple, avec les signatures BLS de seuil, il y a un probl\u00e8me majeur : avant de commencer \u00e0 travailler, les participants doivent absolument \u00e9changer leurs cl\u00e9s, en formant un groupe au sein duquel le seuil fonctionnera. Cela signifie qu'il faudra au moins un tour d'\u00e9change dans un r\u00e9seau d\u00e9centralis\u00e9, et \u00e9tant donn\u00e9 que le random g\u00e9n\u00e9r\u00e9, par exemple, est n\u00e9cessaire pour les jeux, pratiquement en temps r\u00e9el, cela signifie qu'un sabotage du protocole est possible \u00e0 ce stade, et les avantages du sch\u00e9ma de seuil sont perdus. Ce probl\u00e8me est d\u00e9j\u00e0 plus simple que les pr\u00e9c\u00e9dents, mais exige n\u00e9anmoins le d\u00e9veloppement d'une proc\u00e9dure distincte pour former des groupes de seuil, qui devra \u00eatre s\u00e9curis\u00e9e \u00e9conomiquement par le biais de d\u00e9p\u00f4ts et de p\u00e9nalit\u00e9s (slashing) pour les participants ne respectant pas le protocole. De plus, la v\u00e9rification BLS avec un niveau de s\u00e9curit\u00e9 acceptable ne peut tout simplement pas \u00eatre int\u00e9gr\u00e9e, par exemple, dans une transaction standard EOS ou Ethereum - il n'y a tout simplement pas assez de temps pour la v\u00e9rification. Le code des contrats est du WebAssembly ou de l'EVM, ex\u00e9cut\u00e9 par une machine virtuelle. Les fonctions cryptographiques ne sont pas encore impl\u00e9ment\u00e9es nativement et fonctionnent des dizaines de fois plus lentement que les biblioth\u00e8ques cryptographiques standard. De nombreux protocoles ne r\u00e9pondent pas aux exigences simplement en raison du volume des cl\u00e9s, par exemple 1024 et 2048 bits pour RSA, ce qui est 4 \u00e0 8 fois plus que la signature standard d'une transaction dans Bitcoin et Ethereum.<\/p>\n<p><\/p>\n<p>Le fait qu'il existe des impl\u00e9mentations dans diff\u00e9rentes langues de programmation joue \u00e9galement un r\u00f4le - elles sont assez rares, surtout pour les nouveaux protocoles. L'option d'int\u00e9gration dans le consensus n\u00e9cessite d'\u00e9crire le protocole dans le langage de la plateforme, il faudra donc chercher du code en Go pour geth, en Rust pour Parity, en C++ pour EOS. Le code en JavaScript devra \u00eatre recherch\u00e9 par tout le monde, et comme JavaScript et la cryptographie ne sont pas vraiment des amis, WebAssembly aidera, qui pr\u00e9tend d\u00e9sormais s\u00e9rieusement au r\u00f4le de prochain standard internet important.<\/p>\n<p><\/p>\n<h2 id=\"zaklyuchenie\">Conclusion<\/h2>\n<p><\/p>\n<p>J'esp\u00e8re que dans le pr\u00e9c\u00e9dent <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/448330\/\">article<\/a><\/noindex> J'ai pu vous convaincre que la g\u00e9n\u00e9ration de nombres al\u00e9atoires sur la blockchain est essentielle pour de nombreux aspects de la vie des r\u00e9seaux d\u00e9centralis\u00e9s. Cet article a montr\u00e9 que cette t\u00e2che est extr\u00eamement ambitieuse et complexe, mais de bonnes solutions existent d\u00e9j\u00e0. En r\u00e9alit\u00e9, la conception finale du protocole ne sera possible qu'apr\u00e8s de vasts tests prenant en compte tous les aspects, depuis la configuration jusqu'\u00e0 l'\u00e9mulation des pannes. C'est pourquoi vous ne trouverez probablement pas de recettes toutes faites dans les livres blancs des \u00e9quipes ou dans les articles, et nous ne nous risquerons pas \u00e0 \u00e9crire 'faites ceci, c'est assur\u00e9ment correct' dans les un \u00e0 deux prochaines ann\u00e9es. <\/p>\n<p><\/p>\n<p>Pour notre PVRB dans la blockchain en d\u00e9veloppement <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/mixbytes\/haya\">Haya<\/a><\/noindex>, nous avons opt\u00e9 pour l'application de signatures BLS \u00e0 seuil. Nous pr\u00e9voyons d'impl\u00e9menter le PVRB au niveau du consensus, car la v\u00e9rification dans les contrats intelligents avec un niveau de s\u00e9curit\u00e9 acceptable est encore impossible. Il est possible que nous utilisions deux sch\u00e9mas : d'abord un partage de secret co\u00fbteux pour cr\u00e9er un random_seed \u00e0 long terme, puis nous l'utiliserons comme base pour la g\u00e9n\u00e9ration haute fr\u00e9quence de random avec des signatures BLS d\u00e9terministes \u00e0 seuil, mais il se pourrait que nous nous contentions d'un seul sch\u00e9ma. Il est malheureusement impossible de dire \u00e0 l'avance \u00e0 quoi ressemblera le protocole ; ce qui est encourageant, c'est que, comme en science, dans les t\u00e2ches d'ing\u00e9nierie, un r\u00e9sultat n\u00e9gatif est aussi un r\u00e9sultat, et chaque nouvelle tentative de r\u00e9soudre un probl\u00e8me repr\u00e9sente une nouvelle \u00e9tape pour ceux qui travaillent sur la question. Pour r\u00e9pondre aux exigences commerciales, nous abordons une t\u00e2che pratique sp\u00e9cifique : fournir aux applications de jeu une source d'entropie fiable. C'est pourquoi nous devons \u00e9galement pr\u00eater attention \u00e0 la blockchain elle-m\u00eame, notamment aux questions de finalit\u00e9 de la cha\u00eene et de gouvernance du r\u00e9seau. <\/p>\n<p><\/p>\n<p>Et m\u00eame si nous ne voyons pas encore dans les blockchains un PVRB prouv\u00e9 et r\u00e9silient qui aurait \u00e9t\u00e9 utilis\u00e9 suffisamment longtemps pour passer les tests sur de v\u00e9ritables applications, \u00e0 travers de multiples audits, des charges et, bien s\u00fbr, de v\u00e9ritables attaques, le nombre de voies possibles prouve qu'il existe une solution. L'un de ces algorithmes r\u00e9soudra finalement le probl\u00e8me. Nous serons heureux de partager nos r\u00e9sultats et remercions les autres \u00e9quipes qui se penchent \u00e9galement sur cette question pour leurs articles et leur code, qui permettent aux ing\u00e9nieurs de ne pas retomber dans les m\u00eames pi\u00e8ges. <\/p>\n<p><\/p>\n<p>Ainsi, lorsque vous rencontrez un programmeur qui con\u00e7oit un hasard d\u00e9centralis\u00e9, faites preuve de prudence et de bienveillance, et offrez un soutien psychologique si n\u00e9cessaire \ud83d\ude42<\/p>\n<p>Source : <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/452340\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u0412\u0432\u0435\u0434\u0435\u043d\u0438\u0435 function getAbsolutelyRandomNumer() { return 4; \/\/ returns absolutely random number! } \u041a\u0430\u043a \u0438 \u0432 \u0441\u043b\u0443\u0447\u0430\u0435 \u0441 \u043a\u043e\u043d\u0446\u0435\u043f\u0446\u0438\u0435\u0439 \u0430\u0431\u0441\u043e\u043b\u044e\u0442\u043d\u043e \u0441\u0442\u043e\u0439\u043a\u043e\u0433\u043e \u0448\u0438\u0444\u0440\u0430 \u0438\u0437 \u043a\u0440\u0438\u043f\u0442\u043e\u0433\u0440\u0430\u0444\u0438\u0438, \u0440\u0435\u0430\u043b\u044c\u043d\u044b\u0435 \u043f\u0440\u043e\u0442\u043e\u043a\u043e\u043b\u044b \u201cPublicly Verifiable Random Beacon\u201d (\u0434\u0430\u043b\u0435\u0435 PVRB) \u043b\u0438\u0448\u044c \u043f\u044b\u0442\u0430\u044e\u0442\u0441\u044f \u043c\u0430\u043a\u0441\u0438\u043c\u0430\u043b\u044c\u043d\u043e \u043f\u0440\u0438\u0431\u043b\u0438\u0437\u0438\u0442\u044c\u0441\u044f \u043a \u0438\u0434\u0435\u0430\u043b\u044c\u043d\u043e\u0439 \u0441\u0445\u0435\u043c\u0435, \u0442.\u043a. \u0432 \u0440\u0435\u0430\u043b\u044c\u043d\u044b\u0445 \u0441\u0435\u0442\u044f\u0445 \u0432 \u0447\u0438\u0441\u0442\u043e\u043c \u0432\u0438\u0434\u0435 \u043e\u043d\u0430 \u043d\u0435\u043f\u0440\u0438\u043c\u0435\u043d\u0438\u043c\u0430: \u0434\u043e\u0433\u043e\u0432\u0430\u0440\u0438\u0432\u0430\u0442\u044c\u0441\u044f \u043d\u0430\u0434\u043e \u0441\u0442\u0440\u043e\u0433\u043e \u043e\u0431 \u043e\u0434\u043d\u043e\u043c \u0431\u0438\u0442\u0435, \u0440\u0430\u0443\u043d\u0434\u043e\u0432 \u0434\u043e\u043b\u0436\u043d\u043e [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-33888","post","type-post","status-publish","format-standard","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.2 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u0412\u0432\u0435\u0434\u0435\u043d\u0438\u0435 function getAbsolutelyRandomNumer() { return 4; \/\/ returns absolutely random number!\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/sluchajnye-chisla-i-detsentralizovannye-seti-implementatsii\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.2\" \/>\n\t\t<meta property=\"og:locale\" content=\"fr_FR\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u0421\u043b\u0443\u0447\u0430\u0439\u043d\u044b\u0435 \u0447\u0438\u0441\u043b\u0430 \u0438 \u0434\u0435\u0446\u0435\u043d\u0442\u0440\u0430\u043b\u0438\u0437\u043e\u0432\u0430\u043d\u043d\u044b\u0435 \u0441\u0435\u0442\u0438: \u0438\u043c\u043f\u043b\u0435\u043c\u0435\u043d\u0442\u0430\u0446\u0438\u0438 | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u0412\u0432\u0435\u0434\u0435\u043d\u0438\u0435 function getAbsolutelyRandomNumer() { return 4; \/\/ returns absolutely random number!\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/sluchajnye-chisla-i-detsentralizovannye-seti-implementatsii\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2019-10-31T18:55:15+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2019-10-31T18:55:15+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Nombres al\u00e9atoires et r\u00e9seaux d\u00e9centralis\u00e9s : impl\u00e9mentations | ProHoster","description":"Introduction function getAbsolutelyRandomNumer() { return 4; \/\/ renvoie un nombre absolument al\u00e9atoire !","canonical_url":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/sluchajnye-chisla-i-detsentralizovannye-seti-implementatsii","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"fr_FR","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0421\u043b\u0443\u0447\u0430\u0439\u043d\u044b\u0435 \u0447\u0438\u0441\u043b\u0430 \u0438 \u0434\u0435\u0446\u0435\u043d\u0442\u0440\u0430\u043b\u0438\u0437\u043e\u0432\u0430\u043d\u043d\u044b\u0435 \u0441\u0435\u0442\u0438: \u0438\u043c\u043f\u043b\u0435\u043c\u0435\u043d\u0442\u0430\u0446\u0438\u0438 | ProHoster","og:description":"\u0412\u0432\u0435\u0434\u0435\u043d\u0438\u0435 function getAbsolutelyRandomNumer() { return 4; \/\/ returns absolutely random number!","og:url":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/sluchajnye-chisla-i-detsentralizovannye-seti-implementatsii","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T18:55:15+00:00","article:modified_time":"2019-10-31T18:55:15+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"33888","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-21 17:06:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 02:31:23","updated":"2026-01-21 17:06:19","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts\/33888","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/comments?post=33888"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts\/33888\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/media?parent=33888"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/categories?post=33888"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/tags?post=33888"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}