introduction

function getAbsolutelyRandomNumer() {
        return 4; // returns absolutely random number!
}

Comme pour le concept de chiffrement absolument fort issu de la cryptographie, les véritables protocoles de « balise aléatoire publiquement vérifiable » (ci-après PVRB) tentent uniquement de se rapprocher le plus possible du schéma idéal, car dans les réseaux réels, elle n'est pas applicable sous sa forme pure : il faut se mettre d'accord strictement sur un bit, il doit y avoir plusieurs tours, et tous les messages doivent être parfaitement rapides et toujours délivrés. Bien entendu, ce n’est pas le cas dans les réseaux réels. Par conséquent, lors de la conception de PVRB pour des tâches spécifiques dans les blockchains modernes, outre l’impossibilité de contrôler le caractère aléatoire et la force cryptographique qui en résultent, de nombreux autres problèmes purement architecturaux et techniques surviennent.

Pour PVRB, la blockchain elle-même est essentiellement un support de communication dans lequel messages = transactions. Cela vous permet de faire partiellement abstraction des problèmes de réseau, de la non-livraison des messages, des problèmes de middleware - tous ces risques sont assumés par le réseau décentralisé, et sa principale valeur pour PVRB est l'incapacité de révoquer ou de corrompre une transaction déjà envoyée - cela ne ne permettra pas aux participants de refuser de participer au protocole, à moins qu’ils n’aient réussi à s’attaquer au consensus. Ce niveau de sécurité est acceptable, le PVRB devrait donc être résistant à la collusion des participants exactement dans la même mesure que la chaîne principale de blockchain. Cela laisse également entendre que le PVRB doit faire partie du consensus si le réseau s'accorde sur la blockchain principale, même s'il s'accorde également sur le seul résultat aléatoire équitable. Ou bien, PVRB est simplement un protocole autonome implémenté par un contrat intelligent qui fonctionne de manière asynchrone par rapport à la blockchain et aux blocs. Les deux méthodes ont leurs avantages et leurs inconvénients, et le choix entre elles est extrêmement simple.

Deux façons de mettre en œuvre le PVRB

Décrivons plus en détail deux options pour mettre en œuvre PVRB - la version autonome, qui fonctionne à l'aide d'un contrat intelligent indépendant de la blockchain, et la version intégrée par consensus, intégrée au protocole, selon laquelle le réseau s'accorde sur la blockchain et le opérations à inclure. Dans tous les cas, je parlerai des moteurs blockchain populaires : Ethereum, EOS et tous ceux qui leur ressemblent dans la manière dont ils hébergent et traitent les contrats intelligents.

Contrat autonome

Dans cette version, PVRB est un contrat intelligent qui accepte les transactions de producteurs aléatoires (ci-après dénommés RP), les traite, combine les résultats et, par conséquent, arrive à une certaine valeur que tout utilisateur peut recevoir de ce contrat. Cette valeur ne peut pas être stockée directement dans le contrat, mais plutôt être représentée uniquement par des données à partir desquelles une et une seule valeur de l'aléa résultant peut être obtenue de manière déterministe. Dans ce schéma, les RP sont des utilisateurs de la blockchain et n’importe qui peut être autorisé à participer au processus de génération.

L'option avec contrat autonome est bonne :

• portabilité (les contrats peuvent être glissés de blockchain en blockchain)
• facilité de mise en œuvre et de test (les contrats sont faciles à rédiger et à tester)
• commodité dans la mise en œuvre de schémas économiques (il est facile de créer votre propre jeton, dont la logique sert les objectifs du PVRB)
• possibilité de lancement sur des blockchains déjà fonctionnelles

Il présente également des inconvénients :

• fortes limitations sur les ressources informatiques, le volume de transactions et le stockage (en d'autres termes, cpu/mem/io)
• restrictions sur les opérations dans le cadre du contrat (toutes les instructions ne sont pas disponibles, il est difficile de connecter des bibliothèques externes)
• incapacité à organiser la messagerie plus rapidement que les transactions ne sont incluses dans la blockchain

Cette option convient à la mise en œuvre d'un PVRB qui doit être exécuté sur un réseau existant, ne contient pas de cryptographie complexe et ne nécessite pas un grand nombre d'interactions.

Intégré au consensus

Dans cette version, PVRB est implémenté dans le code du nœud blockchain, intégré ou exécuté en parallèle avec l'échange de messages entre les nœuds blockchain. Les résultats du protocole sont écrits directement dans les blocs produits et les messages du protocole sont envoyés sur le réseau p2p entre les nœuds. Étant donné que le protocole aboutit à des nombres qui doivent être écrits en blocs, le réseau doit parvenir à un consensus sur ceux-ci. Cela signifie que les messages PVRB, comme les transactions, doivent être validés par les nœuds et inclus dans des blocs afin que tout participant au réseau puisse valider la conformité au protocole PVRB. Cela nous amène automatiquement à la solution évidente : si le réseau s'accorde sur un consensus sur un bloc et les transactions qu'il contient, alors PVRB devrait faire partie du consensus, et non un protocole autonome. Sinon, il est possible qu'un blocage soit valide d'un point de vue consensuel, mais que le protocole PVRB ne soit pas suivi, et du point de vue PVRB le blocage ne puisse pas être accepté. Ainsi, si l’option « intégrée au consensus » est choisie, le PVRB devient un élément important du consensus.

Lorsqu’on décrit les implémentations du PVRB au niveau du consensus du réseau, on ne peut en aucun cas éviter les questions de finalité. La finalité est un mécanisme utilisé dans les consensus déterministes qui engage un bloc (et la chaîne qui y mène) qui est final et ne sera jamais jeté, même si un fork parallèle se produit. Par exemple, dans Bitcoin, un tel mécanisme n'existe pas - si vous publiez une chaîne plus complexe, elle remplacera toute chaîne moins complexe, quelle que soit la longueur des chaînes. Et dans EOS, par exemple, les derniers blocs sont ce qu'on appelle les derniers blocs irréversibles, qui apparaissent en moyenne tous les 432 blocs (12*21 + 12*15, pré-vote + pré-commit). Ce processus attend essentiellement la signature des 2/3 des producteurs de blocs (ci-après dénommés BP). Lorsque des forks plus anciens que la dernière LIB apparaissent, ils sont simplement supprimés. Ce mécanisme permet de garantir que la transaction est incluse dans la blockchain et ne sera jamais annulée, quelles que soient les ressources dont dispose l'attaquant. En outre, les blocs finaux sont des blocs signés par 2/3 BP dans Hyperledger, Tendermint et d'autres consensus basés sur pBFT. En outre, il est logique de faire d’un protocole garantissant la finalité un complément au consensus, car il peut fonctionner de manière asynchrone avec la production et la publication de blocs. En voici une bonne article sur la finalité dans Ethereum.

La finalité est extrêmement importante pour les utilisateurs, qui sans elle pourraient se retrouver victimes d'une attaque de « double dépense », où BP « détient » des blocs et les publie après que le réseau a « vu » une bonne transaction. S'il n'y a pas de finalité, alors le fork publié remplace le bloc d'une « bonne » transaction par un autre, issu d'un « mauvais » fork, dans lequel les mêmes fonds sont transférés à l'adresse de l'attaquant. Dans le cas du PVRB, les exigences de finalité sont encore plus strictes, puisque la construction de forks pour PVRB signifie la possibilité pour un attaquant de préparer plusieurs options aléatoires afin de publier la plus rentable, et limiter la durée d'une éventuelle attaque est une priorité. bonne solution.

Par conséquent, la meilleure option est de combiner PVRB et finalité en un seul protocole - alors le bloc finalisé = aléatoire finalisé, et c'est exactement ce que nous avions besoin d'obtenir. Désormais, les joueurs recevront un aléatoire garanti en N secondes et pourront être sûrs qu'il est impossible de l'annuler ou de le rejouer.

L’option intégrée au consensus est bonne :

• la possibilité d'une mise en œuvre asynchrone par rapport à la production de blocs - les blocs sont produits comme d'habitude, mais en parallèle, le protocole PVRB peut fonctionner, ce qui ne produit pas de caractère aléatoire pour chaque bloc
• la possibilité de mettre en œuvre une cryptographie même lourde, sans les restrictions imposées aux contrats intelligents
• la possibilité d'organiser l'échange de messages plus rapidement que les transactions ne sont incluses dans la blockchain, par exemple, une partie du protocole peut fonctionner entre les nœuds sans distribuer de messages sur le réseau

Il présente également des inconvénients :

• Difficultés de test et de développement - vous devrez émuler les erreurs réseau, les nœuds manquants, les hard forks du réseau
• Les erreurs d’implémentation nécessitent un hardfork réseau

Les deux méthodes de mise en œuvre du PVRB ont droit à la vie, mais la mise en œuvre de contrats intelligents dans les blockchains modernes est encore assez limitée en ressources informatiques, et toute transition vers une cryptographie sérieuse est souvent tout simplement impossible. Et nous aurons besoin d’une cryptographie sérieuse, comme nous le démontrerons ci-dessous. Bien que ce problème soit clairement temporaire, une cryptographie sérieuse dans les contrats est nécessaire pour résoudre de nombreux problèmes, et elle apparaît progressivement (par exemple, les contrats système pour les zkSNARK dans Ethereum)

La blockchain, qui fournit un canal de messagerie protocolaire transparent et fiable, ne le fait pas gratuitement. Tout protocole décentralisé doit prendre en compte la possibilité d'une attaque Sybil ; toute action peut être effectuée par les forces concertées de plusieurs comptes, par conséquent, lors de la conception, il est nécessaire de prendre en compte la capacité des attaquants à créer un nombre arbitraire de protocoles. participants agissant en collusion.

PVRB et variables de bloc.

Je n’ai pas menti en disant que personne n’a encore implémenté un bon PVRB, testé par de nombreuses applications de jeux d’argent, dans les blockchains. D’où viennent alors tant d’applications de jeu sur Ethereum et EOS ? Cela me surprend autant que cela vous surprend, d'où ont-ils trouvé autant d'aléas « persistants » dans un environnement complètement déterministe ?

Le moyen préféré d'obtenir du caractère aléatoire dans la blockchain est de prendre une sorte d'information « imprévisible » du bloc et d'en créer une aléatoire sur cette base - simplement en hachant une ou plusieurs valeurs. Bon article sur les problèmes de tels systèmes ici. Vous pouvez prendre n'importe laquelle des valeurs « imprévisibles » du bloc, par exemple le hachage du bloc, le nombre de transactions, la complexité du réseau et d'autres valeurs inconnues à l'avance. Hachez-les ensuite, un ou plusieurs, et, en théorie, vous devriez obtenir un véritable hasard. Vous pouvez même ajouter au papier blanc que votre système est « sécurisé post-quantique » (puisqu'il existe des fonctions de hachage à l'épreuve quantique :)).

Mais même les hachages sécurisés post-quantiques ne suffisent pas, hélas. Le secret réside dans les exigences du PVRB, permettez-moi de vous les rappeler de l'article précédent :

1. Le résultat doit avoir une distribution dont il est prouvé qu'elle est uniforme, c'est-à-dire être basé sur une cryptographie dont la solidité est prouvée.
2. Il n'est possible de contrôler aucun des bits du résultat. En conséquence, l’issue ne peut être prédite à l’avance.
3. Vous ne pouvez pas saboter le protocole de génération en ne participant pas au protocole ou en surchargeant le réseau avec des messages d'attaque.
4. Tout ce qui précède doit résister à la collusion d'un nombre autorisé de participants malhonnêtes au protocole (par exemple, 1/3 des participants).

Dans ce cas, seule l'exigence 1 est remplie et l'exigence 2 n'est pas remplie. En hachant les valeurs imprévisibles du bloc, nous obtiendrons une distribution uniforme et de bons aléatoires. Mais BP a au moins la possibilité de « publier le bloc ou non ». Ainsi, BP peut au moins choisir parmi DEUX options aléatoires : « la sienne » et celle qui se révélera si quelqu'un d'autre fait le blocage. BP peut « espionner » à l'avance ce qui se passera s'il publie un bloc et décide simplement de le faire ou non. Ainsi, lorsqu'il joue par exemple « pair-impair » ou « rouge/noir » à la roulette, il ne peut publier un blocage que s'il constate un gain. Cela rend également irréalisable la stratégie consistant à utiliser, par exemple, un hachage de bloc « du futur ». Dans ce cas, ils disent que « le hasard sera utilisé, qui est obtenu en hachant les données actuelles et le hachage d'un futur bloc avec une hauteur, par exemple, N + 42, où N est la hauteur actuelle du bloc. Cela renforce un peu le système, mais permet toujours à BP, bien que dans le futur, de choisir de conserver le bloc ou de le publier.

Le logiciel BP dans ce cas devient plus compliqué, mais pas beaucoup. Simplement, lors de la validation et de l'inclusion d'une transaction dans un bloc, il y a une vérification rapide pour voir s'il y aura un gain et, éventuellement, une sélection des paramètres d'une transaction pour obtenir une forte probabilité de gain. En même temps, il est quasiment impossible d'attraper un BP malin pour de telles manipulations, on peut à chaque fois utiliser de nouvelles adresses et gagner petit à petit sans éveiller les soupçons.

Les méthodes utilisant les informations du bloc ne conviennent donc pas comme implémentation universelle de PVRB. En version limitée, avec des restrictions sur la taille des mises, des restrictions sur le nombre de joueurs et/ou l'enregistrement KYC (pour empêcher un joueur d'utiliser plusieurs adresses), ces schémas peuvent fonctionner pour des petits jeux, mais sans plus.

PVRB et commit-révélation.

D'accord, grâce au hachage et au moins à la relative imprévisibilité du hachage de bloc et d'autres variables. Si vous résolvez le problème des mineurs de pointe, vous devriez obtenir quelque chose de plus approprié. Ajoutons des utilisateurs à ce schéma - laissons-les également influencer le caractère aléatoire : 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, dans lequel les utilisateurs envoient simplement des nombres aléatoires et que le résultat est calculé comme, par exemple, un hachage de leur somme, ne convient pas. Dans ce cas, le dernier joueur peut, en choisissant son propre hasard, contrôler quel sera le résultat. C'est pourquoi le modèle commit-reveal, très largement utilisé, est utilisé. Les participants envoient d’abord les hachages de leurs randoms (commits), puis ouvrent eux-mêmes les randoms (révèle). La phase de « révélation » ne commence qu'une fois que les commits nécessaires ont été collectés, afin que les participants puissent envoyer exactement le hachage aléatoire à partir duquel ils ont envoyé précédemment. Maintenant, rassemblons tout cela avec les paramètres d'un bloc, et mieux que celui pris dans le futur (le hasard ne peut être trouvé que dans l'un des futurs blocs), et le tour est joué - le hasard est prêt ! Désormais, n'importe quel joueur influence le caractère aléatoire qui en résulte et peut « vaincre » le BP malveillant en le remplaçant par son propre caractère aléatoire, inconnu à l'avance... Vous pouvez également ajouter une protection contre le sabotage du protocole en ne l'ouvrant pas au stade de la révélation - simplement en exigeant qu'un certain montant soit attaché à la transaction lors de sa validation — un dépôt de garantie, qui ne sera restitué que lors de la procédure de révélation. Dans ce cas, s’engager et ne pas révéler ne sera pas rentable.

C'était une bonne tentative, et de tels schémas existent également dans les DApps de jeu, mais hélas, cela n'est pas encore suffisant. Désormais, non seulement le mineur, mais également tout participant au protocole peut influencer le résultat. Il est toujours possible de contrôler la valeur elle-même, avec moins de variabilité et à un coût, mais, comme dans le cas du mineur, si les résultats du tirage ont plus de valeur que les frais de participation au protocole PVRB, alors le tirage aléatoire -producteur(RP) peut décider de révéler ou non et peut toujours choisir parmi au moins deux options aléatoires.
Mais il est devenu possible de punir ceux qui commettent et ne révèlent rien, et ce système s'avérera utile. Sa simplicité est un sérieux avantage : des protocoles plus sérieux nécessitent des calculs beaucoup plus puissants.

PVRB et signatures déterministes.

Il existe un autre moyen de forcer le RP à fournir un nombre pseudo-aléatoire sur lequel il ne peut pas influencer s'il reçoit une « préimage » : il s'agit d'une signature déterministe. Une telle signature est par exemple RSA et non ECS. Si RP a 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, et dans le cas d'ECS, il pourra générer n'importe quel nombre de différentes signatures valides. En effet, lors de la création d'une signature ECS, un nombre aléatoire est utilisé, choisi par le signataire, et il peut être choisi de n'importe quelle manière, donnant au signataire la possibilité de choisir l'une des nombreuses signatures. Dans le cas du RSA : « une valeur d'entrée » + « une paire de clés » = « une signature ». Il est impossible de prédire quelle signature obtiendra un autre RP, donc un PVRB avec des signatures déterministes peut être organisé en combinant les signatures RSA de plusieurs participants ayant signé la même valeur. Par exemple, le précédent aléatoire. Ce système permet d'économiser beaucoup de ressources, car les signatures sont à la fois une confirmation du bon comportement selon le protocole et une source d'aléatoire.

Cependant, même avec des signatures déterministes, le système reste vulnérable au problème du « dernier acteur ». Le dernier participant peut toujours décider de publier ou non la signature, contrôlant ainsi le résultat. Vous pouvez modifier le schéma, y ​​ajouter des hachages de blocs, faire des tours pour que le résultat ne puisse pas être prédit à l'avance, mais toutes ces techniques, même en tenant compte de nombreuses modifications, laissent toujours en suspens le problème de l'influence d'un participant sur le collectif. aboutissent à un environnement peu fiable et ne peuvent fonctionner que sous des contraintes économiques et temporelles. De plus, la taille des clés RSA (1024 et 2048 bits) est assez grande et la taille des transactions blockchain est un paramètre extrêmement important. Apparemment, il n’existe pas de moyen simple de résoudre le problème, passons à autre chose.

PVRB et systèmes de partage de secrets

En cryptographie, il existe des systèmes qui peuvent permettre au réseau de s'entendre sur une et une seule valeur PVRB, tandis que ces systèmes résistent à toute action malveillante de certains participants. Un protocole utile avec lequel il vaut la peine de se familiariser est le système de partage secret de Shamir. Il sert à diviser un secret (par exemple une clé secrète) en plusieurs parties, et à distribuer ces parties à N participants. Le secret est réparti de telle manière que M parties sur N suffisent pour le récupérer, et il peut s'agir de M parties quelconques. S'ils sont sur les doigts, alors qu'ils ont un graphique d'une fonction inconnue, les participants échangent des points sur le graphique, et après avoir reçu M points, la fonction entière peut être restaurée.
Une bonne explication est donnée dans wiki mais jouer avec pratiquement pour jouer le protocole dans votre tête est utile pour demo page.

Si le système FSSS (Fiat-Shamir Secret Sharing) était applicable dans sa forme pure, ce serait un PVRB indestructible. Dans sa forme la plus simple, le protocole pourrait ressembler à ceci :

• Chaque participant génère son propre hasard et en distribue les partages aux autres participants.
• Chaque participant dévoile sa part des secrets des autres participants
• Si un participant possède plus de M partages, alors le nombre de ce participant pourra être calculé, et il sera unique, quel que soit l'ensemble des participants révélés.
• La combinaison des aléas révélés est le PVRB souhaité

Ici, un participant individuel n'influence plus les résultats du protocole, sauf dans les cas où l'atteinte du seuil de divulgation du caractère aléatoire dépend uniquement de lui. Par conséquent, ce protocole, s’il existe une proportion requise de RP travaillant sur le protocole et disponibles, fonctionne, mettant en œuvre les exigences de force cryptographique et étant résistant au problème du « dernier acteur ».

Cela pourrait être une option idéale, ce schéma PVRB basé sur le partage de secrets Fiat-Shamir est décrit par exemple dans cette article. Mais, comme mentionné ci-dessus, si l’on tente de l’appliquer de front dans la blockchain, des limitations techniques apparaissent. Voici un exemple de test d'implémentation du protocole dans le contrat intelligent EOS et sa partie la plus importante - la vérification du participant au partage publié : code. Vous pouvez voir dans le code que la validation de la preuve nécessite plusieurs multiplications scalaires et que les nombres utilisés sont très grands. Il faut comprendre que dans les blockchains, la vérification a lieu au moment où le producteur du bloc traite la transaction, et en général, tout participant doit facilement vérifier l'exactitude du protocole, de sorte que les exigences relatives à la rapidité de la fonction de vérification sont très sérieuses. . Dans cette option, l'option s'est avérée inefficace, car la vérification ne respectait pas la limite de transaction (0.5 seconde).

L’efficacité de la vérification est l’une des exigences les plus importantes pour l’utilisation, en général, de tout système cryptographique avancé dans la blockchain. Créer des preuves, préparer des messages - ces procédures peuvent être prises hors chaîne et effectuées sur des ordinateurs hautes performances, mais la vérification ne peut être contournée - c'est une autre exigence importante pour PVRB.

PVRB et signatures de seuil

Ayant pris connaissance du schéma de partage secret, nous avons découvert toute une classe de protocoles réunis par le mot-clé « seuil ». Lorsque la divulgation de certaines informations nécessite la participation de M participants honnêtes sur N, et que l’ensemble des participants honnêtes peut être un sous-ensemble arbitraire de N, on parle de schémas « à seuil ». Ce sont eux qui nous permettent de résoudre le problème du « dernier acteur », désormais si l'attaquant ne révèle pas sa part du secret, un autre participant honnête le fera à sa place. Ces schémas permettent de s'entendre sur un et un seul sens, même si le protocole est saboté par certains des participants.

La combinaison de signatures déterministes et de schémas de seuil a permis de développer un schéma très pratique et prometteur pour la mise en œuvre du PVRB - ce sont des signatures de seuil déterministes. Ici article sur les différentes utilisations des signatures de seuil, et en voici une autre bonne longread de Dash.

Le dernier article décrit les signatures BLS (BLS signifie Boneh-Lynn-Shacham, ici article), qui ont une qualité très importante et extrêmement pratique pour les programmeurs - les clés publiques, secrètes, publiques et les signatures BLS peuvent être combinées entre elles à l'aide d'opérations mathématiques simples, tandis que leurs combinaisons restent des clés et signatures valides, vous permettant d'agréger facilement de nombreuses signatures en une seule et plusieurs clés publiques en une seule. Ils sont également déterministes et produisent le même résultat pour les mêmes données d’entrée. Grâce à cette qualité, les combinaisons de signatures BLS sont elles-mêmes des clés valides, ce qui permet de mettre en œuvre une option dans laquelle M sur N participants produisent une et une seule signature déterministe, publiquement vérifiable et imprévisible jusqu'à son ouverture par le Mième. participante.

Dans un système avec des signatures BLS à seuil, chaque participant signe quelque chose en utilisant BLS (par exemple, l'aléatoire précédent), et la signature à seuil commune est l'aléatoire souhaité. Les propriétés cryptographiques des signatures BLS satisfont aux exigences de qualité aléatoire, la partie seuil protège contre le « dernier acteur » et la combinabilité unique des clés permet de mettre en œuvre de nombreux autres algorithmes intéressants qui permettent, par exemple, une agrégation efficace des messages de protocole. .

Ainsi, si vous construisez PVRB sur votre blockchain, vous vous retrouverez très probablement avec le système de signatures à seuil BLS, plusieurs projets l'utilisent déjà. Par exemple, DFinity (ici benchmark qui implémente le circuit, et ici exemple d'implémentation de partage de secret vérifiable), ou Keep.network (voici leur balise aléatoire papier jaune, Mais exemple contrat intelligent au service du protocole).

Mise en œuvre du PVRB

Malheureusement, nous ne voyons toujours pas de protocole prêt à l’emploi implémenté dans les blockchains PVRB qui ait prouvé sa sécurité et sa stabilité. Même si les protocoles eux-mêmes sont prêts, leur application technique aux solutions existantes n’est pas facile. Pour les systèmes centralisés, le PVRB n'a pas de sens, et les systèmes décentralisés sont strictement limités dans toutes les ressources informatiques : CPU, mémoire, stockage, E/S. La conception d'un PVRB est une combinaison de différents protocoles afin de créer quelque chose qui répond à toutes les exigences d'au moins une blockchain viable. Un protocole calcule plus efficacement, mais nécessite plus de messages entre les RP, tandis que l'autre nécessite très peu de messages, mais la création d'une preuve peut être une tâche qui prend des dizaines de minutes, voire des heures.

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

• Force cryptographique. Votre PVRB doit être strictement impartial, sans aucune capacité à contrôler un seul bit. Dans certains schémas, ce n'est pas le cas, alors appelez un cryptographe
• Le problème du « dernier acteur ». Votre PVRB doit être résistant aux attaques où un attaquant contrôlant un ou plusieurs RP peut choisir l'un des deux résultats suivants.
• Problème de sabotage de protocole. Votre PVRB doit être résistant aux attaques où un attaquant contrôlant un ou plusieurs RP décide s'il doit être aléatoire ou non et peut être garanti ou avec une probabilité donnée d'influencer cela.
• Problème de nombre de messages. Vos RP doivent envoyer un minimum de messages à la blockchain et éviter autant que possible les actions synchrones telles que des situations telles que « J'ai envoyé des informations, j'attends une réponse d'un participant spécifique ». Dans les réseaux p2p, en particulier ceux géographiquement dispersés, il ne faut pas compter sur une réponse rapide
• Le problème de la complexité informatique. La vérification de n'importe quelle étape du PVRB en chaîne devrait être extrêmement simple, car elle est effectuée par tous les clients complets du réseau. Si la mise en œuvre se fait à l'aide d'un contrat intelligent, les exigences de vitesse sont alors très strictes.
• Le problème de l’accessibilité et de la vivacité. Votre PVRB doit s'efforcer d'être résilient aux situations dans lesquelles une partie du réseau devient indisponible pendant un certain temps et une partie du RP cesse tout simplement de fonctionner.
• Le problème de la configuration fiable et de la distribution initiale des clés. Si votre PVRB utilise la configuration principale du protocole, il s'agit alors d'une autre histoire importante et sérieuse. Ici exemple. Si les participants doivent se communiquer leurs clés avant de commencer le protocole, cela pose également problème si la composition des participants change.
• Problèmes de développement. Disponibilité des bibliothèques dans les langages requis, leur sécurité et leurs performances, publicité, tests complexes, etc.

Par exemple, les signatures à seuil BLS présentent un problème important : avant de commencer à travailler, les participants doivent se distribuer les clés, en organisant un groupe au sein duquel le seuil fonctionnera. Cela signifie qu'il faudra attendre au moins un tour d'échange dans un réseau décentralisé, et étant donné que le rand généré, par exemple, est nécessaire dans les jeux, presque en temps réel, cela signifie que le sabotage du protocole est possible à ce stade. , et les avantages du système de seuils sont perdus . Ce problème est déjà plus simple que les précédents, mais nécessite néanmoins le développement d'une procédure distincte pour la formation de groupes de seuil, qui devront être protégés économiquement, par des dépôts et des retraits de fonds (slashing) des participants qui ne suivent pas les protocole. De plus, la vérification BLS avec un niveau de sécurité acceptable ne rentre tout simplement pas, par exemple, dans une transaction EOS ou Ethereum standard - il n'y a tout simplement pas assez de temps pour la vérification. Le code du contrat est WebAssembly ou EVM, exécuté par une machine virtuelle. Les fonctions cryptographiques ne sont pas (encore) implémentées de manière native et fonctionnent des dizaines de fois plus lentement que les bibliothèques cryptographiques conventionnelles. De nombreux protocoles ne répondent pas aux exigences simplement basées sur le volume de clé, par exemple 1024 2048 et 4 8 bits pour RSA, soit XNUMX à XNUMX fois plus grand que la signature de transaction standard dans Bitcoin et Ethereum.

La présence d'implémentations dans différents langages de programmation joue également un rôle - qui sont peu nombreux, notamment pour les nouveaux protocoles. L'option avec intégration dans le consensus nécessite d'écrire un 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. Tout le monde devra rechercher du code JavaScript, et comme JavaScript et la cryptographie ne sont pas des amis particulièrement proches, WebAssembly sera utile, qui prétend désormais être le prochain standard Internet important.

Conclusion

j'espère dans le précédent article J'ai réussi à vous convaincre que générer des nombres aléatoires sur la blockchain est critique pour de nombreux aspects de la vie des réseaux décentralisés, et avec cet article j'ai montré que cette tâche est extrêmement ambitieuse et difficile, mais que de bonnes solutions existent déjà. En général, la conception finale du protocole n'est possible qu'après avoir effectué des tests massifs prenant en compte tous les aspects, de la configuration à l'émulation des pannes. Il est donc peu probable que vous trouviez des recettes toutes faites dans les livres blancs et les articles de l'équipe, et nous ne le ferons certainement pas. Décidez d’ici un an ou deux, écrivez « faites-le de cette façon, exactement comme il faut ».

Au revoir, pour notre PVRB dans la blockchain en cours de développement haya, nous avons opté pour l'utilisation de signatures BLS à seuil, nous prévoyons de mettre en œuvre le PVRB au niveau du consensus, car la vérification dans les contrats intelligents avec un niveau de sécurité acceptable n'est pas encore possible. Il est possible que nous utilisions deux schémas à la fois : d'abord, un partage de secret coûteux pour créer un random_seed à long terme, puis nous l'utilisons comme base pour une génération aléatoire à haute fréquence utilisant des signatures BLS à seuil déterministe, peut-être nous limiterons-nous à seulement l'un des régimes. Malheureusement, il est impossible de dire à l'avance quel sera le protocole ; la seule bonne chose est que, comme en science, dans les problèmes d'ingénierie, un résultat négatif est aussi un résultat, et chaque nouvelle tentative de résolution du problème est une nouvelle étape pour la recherche de toutes les personnes impliquées dans le problème. Pour répondre aux exigences de l'entreprise, nous résolvons un problème pratique spécifique : fournir aux applications de jeux une source d'entropie fiable. Nous devons donc également prêter attention à la blockchain elle-même, en particulier aux questions de finalité de la chaîne et de gouvernance du réseau.

Et même si nous ne voyons pas encore de PVRB résistant et éprouvé dans les blockchains, qui aurait été utilisé pendant suffisamment de temps pour être testé par des applications réelles, de multiples audits, charges et bien sûr, des attaques réelles, le nombre de chemins possibles le confirme. une solution existe, et lesquels de ces algorithmes finiront par résoudre le problème. Nous serons heureux de partager les résultats et de remercier les autres équipes qui travaillent également sur cette problématique pour les articles et le code qui permettent aux ingénieurs de ne pas marcher deux fois sur le même râteau.

Alors, lorsque vous rencontrez un programmeur concevant du hasard décentralisé, soyez attentif et bienveillant, et apportez une aide psychologique si nécessaire :)

Source: habr.com