Introduction

function getAbsolutelyRandomNumer() {
        return 4; // retourne un nombre absolument aléatoire !
}

Tout comme dans le cas du concept de chiffrement absolument résistant en cryptographie, les véritables protocoles de "Publicly Verifiable Random Beacon" (ci-après PVRB) essaient simplement de se rapprocher le plus possible d'un schéma idéal, car dans des réseaux réels, il ne peut pas être appliqué tel quel : il faut convenir d'un seul bit, le nombre de tours doit être important, et tous les messages doivent être parfaitement rapides et toujours livrés. Évidemment, ce n'est pas le cas dans les réseaux réels. Ainsi, lors de la conception de PVRB pour des tâches spécifiques dans des blockchains modernes, en plus de l'impossibilité de contrôler le random obtenu et de la résistance cryptographique, de nombreux problèmes purement architecturaux et techniques surgissent.

La blockchain elle-même constitue pour le PVRB un environnement de communication où les messages = transactions. Cela permet de s'abstraire partiellement des problèmes de réseau, de la non-livraison des messages, des problèmes de logiciels intermédiaires : tous ces risques sont pris en charge par un réseau décentralisé, et la principale valeur de celui-ci pour le PVRB est l'impossibilité de révoquer ou d'altérer une transaction déjà envoyée - cela empêche les participants de se retirer du protocole, sauf s'ils ont réussi une attaque sur le consensus. Ce niveau de sécurité est acceptable, donc le PVRB doit être résistant aux collusions des participants au même titre que la chaîne principale de la blockchain. De plus, cela sous-entend que le PVRB doit faire partie du consensus, si le réseau s'accorde sur la chaîne principale de blocs, il doit également s'accorder sur le seul random résultant honnête. Autrement, PVRB est simplement un protocole autonome, implémenté par un smart contract, fonctionnant de manière asynchrone par rapport à la blockchain et aux blocs. Chacune de ces méthodes a ses propres avantages et inconvénients, et le choix entre elles est extrêmement non trivial.

Deux façons d'implémenter le PVRB

Décrivons plus en détail deux variantes d'implémentation du PVRB - une version autonome, fonctionnant avec un smart contract indépendant de la blockchain, et une version intégrée au consensus - intégrée dans le protocole, selon lequel le réseau s'accorde sur la chaîne de blocs et les transactions incluses. Dans tous les cas, je ferai référence aux moteurs de blockchain populaires : Ethereum, EOS, et tous ceux qui leur ressemblent en termes de déploiement et de traitement des smart contracts.

Contrat autonome

Dans cette option, le PVRB est un contrat intelligent qui accepte les transactions des producteurs aléatoires (RP), les traite, combine les résultats et, en conséquence, aboutit à une certaine valeur, que tout utilisateur peut obtenir de ce contrat. Cette valeur peut ne pas être directement stockée dans le contrat, mais être représentée uniquement par des données à partir desquelles il est possible d'obtenir de manière déterministe une seule et unique valeur aléatoire résultante. Dans ce schéma, les RP sont des utilisateurs de la blockchain, et toute personne peut être autorisée à participer au processus de génération.

L'option du contrat autonome est bonne :

• pour sa portabilité (les contrats peuvent être transférés d'une blockchain à une autre)
• pour sa simplicité de mise en œuvre et de test (les contrats sont faciles à écrire et à tester)
• pour la commodité de mise en œuvre de schémas économiques (il est facile de créer son propre token dont la logique sert les objectifs du PVRB)
• pour la possibilité de déploiement sur des blockchains déjà en fonctionnement

Il présente également des inconvénients :

• des restrictions sévères sur les ressources lors des calculs, le volume des transactions et le stockage (en d'autres termes, cpu/mem/io)
• des limitations sur les opérations à l'intérieur du contrat (toutes les instructions ne sont pas accessibles, il est difficile de connecter des bibliothèques externes)
• l'impossibilité d'organiser des échanges de messages plus rapidement que les transactions ne sont incluses dans la blockchain

Cette option convient pour la mise en œuvre d'un PVRB qui doit être lancé dans un réseau existant, ne contenant pas de cryptographie complexe et ne nécessitant pas beaucoup d'interactions.

Intégré au consensus

Dans cette version, le PVRB est implémenté dans le code du nœud blockchain, intégré ou fonctionnant parallèlement à l'échange de messages entre les nœuds de la blockchain. Les résultats du protocole sont directement inscrits dans les blocs produits, et les messages du protocole sont envoyés via le réseau P2P entre les nœuds. Puisque le protocole aboutit à des nombres qui doivent être enregistrés dans les blocs, le réseau doit parvenir à un consensus à leur sujet. Cela signifie que les messages PVRB, tout comme les transactions, doivent être validés par les nœuds et inclus dans les blocs afin que tout participant au réseau puisse valider le respect du protocole PVRB. Cela nous amène automatiquement à une solution évidente : si le réseau parvient à un consensus concernant le bloc et les transactions qu'il contient, alors le PVRB doit faire partie du consensus, et ne pas être un protocole séparé. Autrement, il pourrait y avoir une situation où le bloc est valide du point de vue du consensus, mais le protocole PVRB n'a pas été respecté, et d'un point de vue PVRB, le bloc ne peut pas être accepté. Donc, si l'option « intégrée au consensus » est choisie, le PVRB devient une partie importante du consensus.

En décrivant les implémentations du PVRB au niveau du consensus dans le réseau, il est impératif de ne pas négliger les questions de finalité. La finalité est un mécanisme utilisé dans des consensus déterministes, fixant un bloc (et la chaîne le menant) comme final, et qui ne sera jamais abandonné, même si un fork parallèle apparaît. Par exemple, le Bitcoin n'a pas ce mécanisme — si une chaîne de plus grande complexité est publiée, elle remplacera toute chaîne de moindre complexité, quelle que soit la longueur des chaînes. En revanche, dans EOS, les blocs finaux sont appelés Last Irreversible Blocks, qui apparaissent en moyenne tous les 432 blocs (12*21 + 12*15, pré-vote + pré-engagement). Ce processus est essentiellement l'attente des signatures des block-producers (BP) à un niveau de 2/3. Lorsqu'il y a des forks plus anciens que le dernier LIB, ils sont simplement rejetés. Ce mécanisme garantit que la transaction est incluse dans la blockchain et ne sera jamais annulée, quelle que soit la puissance de l'attaquant. De plus, les blocs finaux sont ceux signés par 2/3 des BP dans Hyperledger, Tendermint et d'autres consensus basés sur le pBFT. De plus, il est logique de rendre le protocole garantissant la finalité une surcouche du consensus, car il peut fonctionner de manière asynchrone avec la production et la publication des blocs. Voici un bon exemple. article sur la finalité dans Ethereum.

La finalité est extrêmement importante pour les utilisateurs qui, sans elle, peuvent devenir victimes d'une attaque de « double dépense », lorsque le BP « retient » des blocs et les publie après que le réseau a « vu » une bonne transaction. S'il n'y a pas de finalité, la fourche publiée remplace le bloc contenant la transaction « bonne » par un autre, d'une « mauvaise » fourche, dans laquelle les mêmes fonds sont transférés à l'adresse de l'attaquant. Dans le cas du PVRB, les exigences en matière de finalité sont encore plus strictes, car la construction de fourches pour le PVRB signifie que l'attaquant peut préparer 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 — une bonne solution.

Ainsi, la meilleure option serait de combiner PVRB et finalité en un seul protocole — alors le bloc finalisé = randomness finalisé, et c'est exactement ce que nous devions obtenir. Maintenant, les joueurs recevront une randomness garantie en N secondes et peuvent être sûrs qu'il est impossible de le revenir en arrière ou de rejouer.

L'option avec consensus intégré est bonne :

• la capacité de mise en œuvre asynchrone par rapport à la production de blocs — les blocs sont produits comme d'habitude, mais parallèlement, le protocole PVRB peut fonctionner, qui produit des randoms pas à chaque bloc
• la possibilité d'implémenter même une cryptographie lourde, sans les restrictions imposées par les contrats intelligents
• la possibilité d'organiser des échanges de messages plus rapidement que les transactions ne sont intégrées dans la blockchain, par exemple, une partie du protocole peut fonctionner entre les nœuds sans diffusion des messages sur le réseau

Il présente également des inconvénients :

• des difficultés lors des tests et du développement — il faudra émuler des erreurs réseau, des nœuds manquants, des hard forks du réseau
• des erreurs dans l'implémentation nécessitent un hard fork du réseau

Les deux méthodes d'implémentation du PVRB ont droit de cité, mais l'implémentation sur des contrats intelligents dans les blockchains modernes est tout de même fortement limitée en ressources de calcul, et toute transition vers une cryptographie sérieuse est souvent simplement impossible. Et nous aurons besoin d'une cryptographie sérieuse, comme cela sera démontré plus loin. Cependant, ce problème est clairement temporaire, une cryptographie sérieuse dans les contrats est nécessaire pour résoudre de nombreuses tâches, et progressivement elle apparaît (par exemple, les contrats systèmes pour zkSNARKs dans Ethereum).

La blockchain qui assure un canal de communication transparent et fiable pour le protocole n'est pas gratuite. Tout protocole décentralisé doit tenir compte de la possibilité d'attaques Sybil ; toute action peut être réalisée par le biais de la collusion de plusieurs comptes. Par conséquent, lors de la conception, il est essentiel d'évaluer les capacités des attaquants à créer un nombre arbitraire de participants au protocole agissant en accord.

PVRB et variables de bloc.

Je n'ai pas menti en disant qu'il n'existe pas de bon PVRB, vérifié par de nombreuses applications de jeux, dans les blockchains pour le moment. D'où alors un tel nombre d'applications de jeux sur Ethereum et EOS ? Cela m'étonne autant que vous. D'où provient tant de 'hasards' 'robustes' dans un environnement entièrement déterministe ?

La méthode préférée pour obtenir du hasard dans la blockchain consiste à prendre une information 'imprévisible' d'un bloc et à s'en servir pour générer du hasard, simplement en hachant une ou plusieurs valeurs. Voici un bon article sur les problèmes de tels schémas. ici. Vous pouvez utiliser l'une des valeurs 'imprévisibles' d'un bloc, comme le hachage du bloc, le nombre de transactions, la difficulté du réseau et d'autres valeurs inconnues à l'avance. Ensuite, vous les hachez, une ou plusieurs, et, en théorie, cela devrait donner un véritable hasard. Vous pourriez même ajouter dans le livre blanc que votre schéma est 'post-quantum secure' (puisqu'il existe des fonctions de hachage résistantes aux quantiques :)).

Mais même les hachages post-quantiques ne suffisent pas, hélas. Le secret réside dans les exigences relatives au PVRB, je rappelle celles-ci de l'article précédent :

1. Le résultat doit avoir une distribution prouvée équitable, c'est-à-dire reposant sur une cryptographie résistante à la preuve.
2. Il est impossible de contrôler l'un des bits du résultat. Par conséquent, le résultat ne peut pas être prédit à l'avance.
3. Il est impossible de saboter le protocole de génération en ne participant pas au protocole ou en surchargeant le réseau avec des messages attaquants.
4. Tout ce qui précède doit être résistant aux collusions d'un nombre admissible de participants malhonnêtes au protocole (par exemple 1/3 des participants).

Dans ce cas, seule l'exigence 1 est respectée, et l'exigence 2 n'est pas respectée. En hachant des valeurs imprévisibles du bloc, nous obtiendrons une répartition uniforme et de bons aléatoires. Cependant, le BP a au moins la possibilité de « publier le bloc ou non ». Ainsi, le BP peut au moins choisir entre DEUX options d'aléatoire : le sien et celui qui sera obtenu si le bloc est créé par quelqu'un d'autre. Le BP peut « jeter un coup d'œil » à l'avance sur ce qui se passera s'il publie le bloc et décider simplement de le faire ou non. Ainsi, en jouant par exemple à « pair/impair » ou « rouge/noir » à la roulette, il peut publier le bloc seulement s'il voit un gain. Cela rend également non fonctionnelle la stratégie d'utilisation, par exemple, du hachage du bloc « du futur ». Dans ce cas, on dit que « le random sera celui qui est obtenu par le hachage des données actuelles et le hachage du futur bloc d'une hauteur, par exemple, N + 42, où N est la hauteur actuelle du bloc. Cela renforce un peu le schéma, mais permet quand même au BP, même dans le futur, de choisir de retenir le bloc ou de le publier.

Dans ce cas, le logiciel du BP est compliqué, mais pas trop. Lors de la validation et de l'inclusion de la transaction dans le bloc, une vérification rapide est effectuée pour savoir s'il y aura un gain, et peut-être un ajustement d'un des paramètres de la transaction pour obtenir une probabilité élevée de gain. Cependant, attraper un BP intelligent derrière de telles manipulations est pratiquement impossible, chaque fois, de nouvelles adresses peuvent être utilisées, permettant de gagner petit à petit sans éveiller de soupçons.

Ainsi, les méthodes utilisant des informations du bloc ne conviennent pas pour être une implémentation universelle du PVRB. Dans une version limitée, 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 à un joueur la possibilité d'utiliser plusieurs adresses), ces schémas peuvent fonctionner pour de petites jeux, mais pas plus.

PVRB et commit-reveal.

Eh bien, merci au hachage et à la relative imprévisibilité du hachage du bloc et d'autres variables. S'il est possible de résoudre le problème du front-running des mineurs, quelque chose de plus solide devrait émerger. Ajoutons à ce schéma les utilisateurs - qu'ils influencent aussi le random : n'importe quel employé du support technique vous dira que la chose la plus aléatoire dans les systèmes informatiques, ce sont les actions des utilisateurs 🙂

Un schéma naïf où les utilisateurs envoient simplement des nombres aléatoires et où le résultat est calculé comme, par exemple, le hachage de leur somme, n'est pas adapté. Dans ce cas, le dernier joueur peut contrôler le résultat en choisissant son propre aléa. C'est pourquoi on utilise un modèle très répandu de commit-reveal. Les participants envoient d'abord des hachages de leurs aléas (commits), puis révèlent leurs aléas réels (reveals). La phase "reveal" commence seulement après que les commits nécessaires aient été collectés, permettant aux participants d'envoyer exactement l'aléa dont ils ont envoyé le hachage précédemment. Maintenant, assemblons tout cela avec les paramètres du bloc, pris de manière optimale dans le futur (l'aléa ne peut être connu que dans l'un des blocs futurs), et voilà — l'aléa est prêt ! Désormais, chaque joueur influence l'aléa résultant et peut « battre » un BP malveillant en recouvrant son aléa avec le sien, qui est inconnu à l'avance. On peut également ajouter une protection contre le sabotage du protocole par une non-révélation à l'étape de reveal — en exigeant simplement lors du commit de joindre à la transaction une certaine somme — un dépôt de garantie, qui ne sera restitué qu'à la procédure de reveal. Dans ce cas, faire un commit sans faire de reveal serait désavantageux.

C'était une bonne tentative, et des schémas comme ceux-ci existent également dans des DApp de jeux, mais hélas, cela ne suffit toujours pas. Maintenant, le résultat peut être influencé non seulement par le mineur, mais aussi par n'importe quel participant au protocole. Il est toujours possible de contrôler la valeur elle-même, avec une moindre variabilité et contre rémunération, mais, comme dans le cas du mineur, si les résultats du tirage valent plus que le coût de participation au protocole PVRB, alors le random-producer (RP) peut décider de faire le reveal et peut toujours choisir parmi au moins deux options d'aléa.
Cependant, il existe maintenant la possibilité de punir ceux qui font un commit sans faire de reveal, et ce schéma sera encore utile. Sa simplicité est un avantage sérieux — des protocoles plus complexes nécessitent des calculs beaucoup plus puissants.

PVRB et signatures déterministes.

Il existe un autre moyen de faire en sorte que le RP fournisse un nombre pseudo-aléatoire sur lequel il ne pourra pas influencer, en lui fournissant un "modèle" : c'est une signature déterministe. Une telle signature est, par exemple, RSA, et ne l'est pas en ECS. Si le RP possède une paire de clés : RSA et ECC, et qu'il signe une certaine valeur avec sa clé privée, alors dans le cas de RSA, il obtiendra UNE ET UNE SEULE signature, tandis qu'avec ECS, il peut générer un nombre quelconque de signatures valides différentes. Cela est dû au fait que lors de la création de la signature ECS, un nombre aléatoire est choisi par le signataire, et il peut être choisi comme bon semble, permettant au signataire de choisir parmi plusieurs signatures. Dans le cas de RSA : "une valeur d'entrée" + "une paire de clés" = "une signature". Il est impossible de prédire quelle signature aura un autre RP, donc le PVRB avec des signatures déterministes peut être organisé en combinant des signatures RSA de plusieurs participants qui ont signé la même valeur. Par exemple - le précédent aléatoire. Ce schéma permet d'économiser de nombreuses ressources, car les signatures sont à la fois une confirmation de la conformité au protocole et une source d'aléatoire.

Cependant, même avec des signatures déterministes, le schéma reste vulnérable à la problématique de "l'acteur final". Le dernier participant peut encore décider s'il publie sa signature ou non, contrôlant ainsi le résultat. Il est possible d'améliorer le schéma, d'y ajouter des hachages de blocs, de créer des tours pour que le résultat ne puisse pas être prédit à l'avance, mais toutes ces techniques, même avec de nombreuses améliorations, laissent tout de même la problématique de l'influence d'un participant sur le résultat collectif dans un environnement non fiable non résolue et peuvent fonctionner uniquement dans des conditions de contraintes économiques et de temps. De plus, la taille des clés RSA (1024 et 2048 bits) est assez grande, et la taille pour les transactions blockchain est un paramètre extrêmement important. Apparemment, il ne sera pas possible de résoudre le problème simplement, avançons.

PVRB et les schémas de partage secret

En cryptographie, il existe des schémas qui permettent à un réseau de convenir d'une valeur unique pour le PVRB, tout en étant résistant à toute action malveillante d'une partie des participants. Un des protocoles intéressants à connaître est le schéma de partage de secret de Shamir. Ce schéma permet de diviser un secret (par exemple une clé secrète) en plusieurs parts et de distribuer ces parts à N participants. Le secret est distribué de manière à ce que M parts sur N soient suffisantes pour le reconstituer, et cela peut être n'importe quelle combinaison de M parts. Pour faire simple, ayant un graphique d'une fonction inconnue, les participants échangent des points sur ce graphique, et après avoir reçu M points, toute la fonction peut être reconstituée.
Une bonne explication est donnée dans wiki et pour s'y essayer pratiquement, il est utile de jouer avec sur la démo page.

Si le schéma FSSS (Fiat-Shamir Secret Sharing) était applicable tel quel, alors ce serait un PVRB infaillible. Dans sa version la plus simple, le protocole pourrait ressembler à ceci :

• Chaque participant génère son propre random et distribue des parts de celui-ci aux autres participants.
• Chaque participant dévoile sa part des secrets des autres participants.
• Si un participant a recueilli plus de M parts, alors son numéro peut être calculé et il sera unique, quel que soit l'ensemble des participants qui ont dévoilé leurs parts.
• La combinaison des randoms dévoilés constitue le PVRB recherché.

Ici, un participant individuel n'influence plus les résultats du protocole, sauf dans les cas où sa contribution est essentielle au seuil de révélation du random. Ainsi, ce protocole, en présence d'une fraction nécessaire de participants fonctionnant selon le protocole et de RPs accessibles, fonctionne, remplissant les exigences de résistance cryptographique et étant résistant au problème du « dernier acteur ».

Cela pourrait être la solution idéale, ce schéma PVRB basé sur le partage de secret de Fiat-Shamir est décrit, par exemple, dans celui-ci l'article. Mais, comme mentionné précédemment, essayer de l'appliquer directement dans une blockchain entraîne déjà des limitations techniques. Voici un exemple d'implémentation de test du protocole dans un contrat intelligent EOS et la partie la plus importante — la vérification de la part publiée d'un participant : codeLe code montre que la validation du proof exige plusieurs multiplications scalaires, et des nombres très grands sont utilisés. Il faut comprendre que dans les blockchains, la vérification se produit au moment où le producteur de blocs traite la transaction, et chaque participant doit pouvoir vérifier facilement la validité du protocole. Par conséquent, les exigences de vitesse pour la fonction de vérification sont très strictes. Dans cette variante, le système s'est avéré non fonctionnel, car la vérification dépassait la limite de temps de la transaction (0,5 seconde).

L'efficacité de la vérification est l'une des exigences les plus importantes pour l'utilisation de pratiquement tous les schémas cryptographiques avancés dans la blockchain. La création de proofs, la préparation de messages — ces procédures peuvent être réalisées hors chaîne et exécutées sur des ordinateurs haute performance, mais il n'est pas possible d'éviter la vérification — c'est une autre exigence essentielle pour le PVRB.

PVRB et signatures seuil

En découvrant le schéma de partage de secrets, nous avons ouvert toute une classe de protocoles, regroupés sous le mot-clé « seuil ». Lorsque la divulgation d'informations requiert la participation de M participants honnêtes sur N, et que l'ensemble des participants honnêtes peut être n'importe quel sous-ensemble de N, on parle de schémas « à seuil ». Ces derniers permettent de résoudre le problème du « dernier acteur ». Si un attaquant ne divulgue pas sa part du secret, un autre participant honnête le fera à sa place. Ces schémas permettent de convenir d'une et d'une seule valeur, même en cas de sabotage du protocole par certains participants.

La combinaison de signatures déterministes et de schémas à seuil a permis de développer un schéma très pratique et prometteur pour la réalisation du PVRB — ce sont les signatures à seuil déterministes. Voici article sur les différentes applications des signatures à seuil, et voici encore un bon longread de Dash.

Le dernier article décrit les signatures BLS (BLS signifie Boneh-Lynn-Shacham, voici Un article qui possède une qualité très importante et extrêmement pratique pour les programmeurs — les clés publiques, secrètes et les signatures BLS peuvent être combinées entre elles grâce à des opérations mathématiques simples, tout en restant des clés et signatures valides, permettant ainsi d'agréger facilement de nombreuses signatures en une seule et de nombreuses clés publiques en une seule. Elles possèdent également une déterminisme et produisent le même résultat avec les mêmes données d'entrée. Grâce à cette qualité, les combinaisons de signatures BLS elles-mêmes sont des clés valides, ce qui permet de réaliser un scénario où M participants sur N produisent une seule et unique signature, qui est déterminée, publiquement vérifiable et imprévisible jusqu'à ce que le Mème participant ne l'ait révélée.

Dans le schéma des signatures BLS par seuil, chaque participant signe à l'aide de BLS quelque chose (par exemple, un aléatoire précédent), et la signature globale par seuil est le random recherché. Les propriétés cryptographiques des signatures BLS répondent aux exigences de qualité du random, la partie seuil protège contre l'« acteur final », et la combinabilité unique des clés permet de réaliser de nombreux autres algorithmes intéressants, qui, par exemple, permettent d'agréger efficacement les messages du protocole.

Donc, si vous construisez un PVRB dans votre blockchain, vous arriverez très probablement à un schéma de signatures BLS par seuil, qui est déjà utilisé par plusieurs projets. Par exemple, DFinity (ici un benchmark implémentant le schéma, et ici un exemple d'implémentation du partage secret vérifiable), ou Keep.network (voici leur random beacon yellowpaper, mais voici exemple un contrat intelligent qui gère le protocole).

Implémentation PVRB

Malheureusement, nous ne voyons toujours pas de protocole PVRB prêt, réalisé sur les blockchains, prouvant sa sécurité et sa robustesse. Bien que les protocoles eux-mêmes soient prêts, il est techniquement difficile de les appliquer aux solutions existantes. Pour les systèmes centralisés, PVRB n'a pas de sens, tandis que les systèmes décentralisés sont strictement limités dans toutes les ressources informatiques : CPU, mémoire, stockage, I/O. La conception de PVRB consiste à combiner différents protocoles pour créer quelque chose qui réponde à toutes les exigences d'au moins un blockchain viable. Un protocole calcule efficacement, mais nécessite davantage de messages entre les RP, tandis qu'un autre nécessite très peu de messages, mais la création d'une preuve peut prendre des dizaines de minutes, voire des heures.

Je vais énumérer les facteurs que vous devez prendre en compte lors du choix d'un PVRB de qualité :

• Solidité cryptographique. Votre PVRB doit être strictement inbiasable, sans possibilité de contrôler un seul bit. Dans certains schémas, ce n'est pas le cas, donc faites appel à un cryptographe.
• Problème de “dernier acteur”. Votre PVRB doit être résistant aux attaques, lorsque l'attaquant, contrôlant un ou plusieurs RP, peut choisir l'un des deux résultats.
• Problème de sabotage du protocole. Votre PVRB doit être résistant aux attaques, lorsque l'attaquant, contrôlant un ou plusieurs RP, décide s'il y a du hasard ou non et peut influencer cela de manière garantissant ou avec une probabilité donnée.
• Problème du nombre de messages. Vos RP doivent envoyer un minimum de messages à la blockchain et éviter autant que possible les actions synchrones telles que 'j'ai envoyé certaines informations, j'attends une réponse d'un participant spécifique'. Dans les réseaux P2P, surtout géographiquement dispersés, on ne peut pas compter sur une réponse rapide.
• Problème de complexité computationnelle. La vérification de toute étape de PVRB on-chain doit être extrêmement simple, car elle est effectuée par tous les clients complets du réseau. Si la mise en œuvre est faite via un smart contract, les exigences de vitesse sont très strictes.
• Problème d'accessibilité et de vivacité. Votre PVRB doit aspire à être résistant aux situations où une partie du réseau devient inaccessible pendant un certain temps et où une partie des RP cesse simplement de fonctionner.
• Problème de configuration de confiance et de distribution initiale des clés. Si votre PVRB utilise un protocole de configuration primaire, c'est une autre histoire importante et complexe. Voici exemple. Si les participants doivent échanger leurs clés avant le début du protocole, c'est également un problème si la composition des participants change
• Problèmes de développement. La disponibilité des bibliothèques dans les langues nécessaires, leur sécurité et leur performance, leur accessibilité, des tests complexes, etc.

Par exemple, avec les signatures BLS de seuil, il y a un problème majeur : avant de commencer à travailler, les participants doivent absolument échanger leurs clés, en formant un groupe au sein duquel le seuil fonctionnera. Cela signifie qu'il faudra au moins un tour d'échange dans un réseau décentralisé, et étant donné que le random généré, par exemple, est nécessaire pour les jeux, pratiquement en temps réel, cela signifie qu'un sabotage du protocole est possible à ce stade, et les avantages du schéma de seuil sont perdus. Ce problème est déjà plus simple que les précédents, mais exige néanmoins le développement d'une procédure distincte pour former des groupes de seuil, qui devra être sécurisée économiquement par le biais de dépôts et de pénalités (slashing) pour les participants ne respectant pas le protocole. De plus, la vérification BLS avec un niveau de sécurité acceptable ne peut tout simplement pas être intégrée, par exemple, dans une transaction standard EOS ou Ethereum - il n'y a tout simplement pas assez de temps pour la vérification. Le code des contrats est du WebAssembly ou de l'EVM, exécuté par une machine virtuelle. Les fonctions cryptographiques ne sont pas encore implémentées nativement et fonctionnent des dizaines de fois plus lentement que les bibliothèques cryptographiques standard. De nombreux protocoles ne répondent pas aux exigences simplement en raison du volume des clés, par exemple 1024 et 2048 bits pour RSA, ce qui est 4 à 8 fois plus que la signature standard d'une transaction dans Bitcoin et Ethereum.

Le fait qu'il existe des implémentations dans différentes langues de programmation joue également un rôle - elles sont assez rares, surtout pour les nouveaux protocoles. L'option d'intégration dans le consensus nécessite d'écrire 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 être recherché par tout le monde, et comme JavaScript et la cryptographie ne sont pas vraiment des amis, WebAssembly aidera, qui prétend désormais sérieusement au rôle de prochain standard internet important.

Conclusion

J'espère que dans le précédent article J'ai pu vous convaincre que la génération de nombres aléatoires sur la blockchain est essentielle pour de nombreux aspects de la vie des réseaux décentralisés. Cet article a montré que cette tâche est extrêmement ambitieuse et complexe, mais de bonnes solutions existent déjà. En réalité, la conception finale du protocole ne sera possible qu'après de vasts tests prenant en compte tous les aspects, depuis la configuration jusqu'à l'émulation des pannes. C'est pourquoi vous ne trouverez probablement pas de recettes toutes faites dans les livres blancs des équipes ou dans les articles, et nous ne nous risquerons pas à écrire 'faites ceci, c'est assurément correct' dans les un à deux prochaines années.

Pour notre PVRB dans la blockchain en développement Haya, nous avons opté pour l'application de signatures BLS à seuil. Nous prévoyons d'implémenter le PVRB au niveau du consensus, car la vérification dans les contrats intelligents avec un niveau de sécurité acceptable est encore impossible. Il est possible que nous utilisions deux schémas : d'abord un partage de secret coûteux pour créer un random_seed à long terme, puis nous l'utiliserons comme base pour la génération haute fréquence de random avec des signatures BLS déterministes à seuil, mais il se pourrait que nous nous contentions d'un seul schéma. Il est malheureusement impossible de dire à l'avance à quoi ressemblera le protocole ; ce qui est encourageant, c'est que, comme en science, dans les tâches d'ingénierie, un résultat négatif est aussi un résultat, et chaque nouvelle tentative de résoudre un problème représente une nouvelle étape pour ceux qui travaillent sur la question. Pour répondre aux exigences commerciales, nous abordons une tâche pratique spécifique : fournir aux applications de jeu une source d'entropie fiable. C'est pourquoi nous devons également prêter attention à la blockchain elle-même, notamment aux questions de finalité de la chaîne et de gouvernance du réseau.

Et même si nous ne voyons pas encore dans les blockchains un PVRB prouvé et résilient qui aurait été utilisé suffisamment longtemps pour passer les tests sur de véritables applications, à travers de multiples audits, des charges et, bien sûr, de véritables attaques, le nombre de voies possibles prouve qu'il existe une solution. L'un de ces algorithmes résoudra finalement le problème. Nous serons heureux de partager nos résultats et remercions les autres équipes qui se penchent également sur cette question pour leurs articles et leur code, qui permettent aux ingénieurs de ne pas retomber dans les mêmes pièges.

Ainsi, lorsque vous rencontrez un programmeur qui conçoit un hasard décentralisé, faites preuve de prudence et de bienveillance, et offrez un soutien psychologique si nécessaire 🙂

Source : habr.com