De l'idée à la réalisation : nous modifions le schéma existant de signature numérique sur courbe elliptique pour le rendre déterministe, et nous proposons à partir de celui-ci des fonctionnalités d'obtention de nombres pseudo-aléatoires vérifiables dans le cadre de la blockchain.

Idée

À l'automne 2018, la blockchain Waves a activé les premiers contrats intelligents, la question de la possibilité d'obtenir des nombres pseudo-aléatoires, dignes de confiance, est immédiatement apparue.

En réfléchissant à cette question, je suis finalement arrivé à la conclusion : toute blockchain est une cage, il est impossible d'obtenir une source d'entropie fiable dans un système fermé.

Mais une idée m'a tout de même plu : si un oracle aléatoire signait les données utilisateur avec un algorithme déterministe, alors l'utilisateur pourrait toujours vérifier une telle signature avec la clé publique et serait assuré que la valeur obtenue est unique. L'oracle, quoi qu'il en soit, ne peut rien modifier, l'algorithme produit un résultat unique. En substance, l'utilisateur fixe le résultat, mais ne le connaît pas tant que l'oracle ne l'a pas publié. Il s'avère qu'il est possible de ne pas faire confiance à l'oracle en général, mais de vérifier le résultat de son travail. Ainsi, en cas de vérification réussie, une telle signature peut être considérée comme une source d'entropie pour un nombre pseudo-aléatoire.

La plateforme blockchain Waves utilise un schéma de signature EdDSA une variante Ed25519. Dans ce schéma, la signature consiste en des valeurs R et S, où R dépend d'une valeur aléatoire, et S est calculé sur la base du message signé, de la clé secrète et de la même valeur aléatoire que R. Il en résulte qu'il n'y a pas de dépendance unique, pour le même message utilisateur, il existe de nombreuses signatures valides.

Il est évident qu'une telle signature, dans sa forme pure, ne peut pas être utilisée comme source de nombres pseudo-aléatoires, car elle est non déterministe et, par conséquent, peut facilement être manipulée par l'oracle.

Mais, comme il s'est avéré, il est en réalité possible de la rendre déterministe.

J'avais de grands espoirs pour la fonction aléatoire vérifiable (VRF), mais après avoir étudié la matière, il a fallu abandonner cette option. Bien que le VRF propose une variante déterministe de la signature et de sa preuve, il y a un aspect étrange dans l'algorithme qui ouvre une faille pour les manipulations de l'oracle. En effet, lors du calcul de la valeur k (section 5.1) un clé privée est utilisée, qui reste inconnue de l'utilisateur, ce qui signifie que l'utilisateur ne peut pas vérifier la validité du calcul de k, donc l'oracle peut utiliser n'importe quelle valeur k nécessaire et en même temps maintenir une base de données de correspondances entre k et les données signées, afin de toujours pouvoir recalculer un résultat correct selon le VRF. Si vous voyez un tirage basé sur le VRF sans divulguer la clé privée, vous pouvez faire la remarque : il est nécessaire soit de révéler la clé, soit de l'exclure du calcul de k, alors la clé privée se révélera d'elle-même à l'apparition de la première signature. En résumé, comme déjà mentionné, un schéma étrange pour un oracle aléatoire.

Après avoir réfléchi et obtenu le soutien d'analystes locaux, un schéma de fonctionnement pour VECRO a été élaboré.

VECRO est l'acronyme de Verifiable Elliptic Curve Random Oracle, ce qui signifie en français un oracle aléatoire vérifiable basé sur des courbes elliptiques.

Tout s'est révélé assez simple, pour atteindre la déterminité, il est nécessaire de fixer la valeur R avant l'apparition du message à signer. Si R est fixé et fait partie du message signé, ce qui garantit en outre la fixation de R dans le message lui-même, la valeur S est déterminée de manière unique par le message de l'utilisateur et peut donc être utilisée comme source de nombres pseudo-aléatoires.

Dans un tel schéma, peu importe comment R est fixé, cela reste de la responsabilité de l'oracle. L'important est que S soit déterminée de manière unique par l'utilisateur, mais sa valeur reste inconnue tant que l'oracle ne la publie pas. Tout comme nous le voulions !

En parlant de R fixé, notez que R réutilisé La signature de différents messages révèle indéniablement la clé secrète dans le schéma EdDSA. Pour le propriétaire de l'oracle, il devient crucial d'exclure la possibilité de réutiliser R pour signer plusieurs messages d'utilisateur. Cela signifie que, dans toutes les manipulations ou collusions, l'oracle risque toujours de perdre sa clé secrète.

Ainsi, l'oracle doit offrir aux utilisateurs deux fonctions : l'initialisation, qui fixe la valeur de R, et la signature, qui retourne la valeur de S. Dans ce cas, la paire R, S constitue une signature vérifiable classique d'un message utilisateur contenant la valeur fixe de R et des données utilisateur arbitraires.

On pourrait objecter que ce schéma pour la blockchain n'est autre qu'une simple schéma de commit-révélation. En effet, c'est le cas. Mais il y a plusieurs nuances. Tout d'abord, l'oracle utilise toujours la même clé dans toutes les opérations, ce qui est pratique dans les contrats. Deuxièmement, il existe un risque de perte de la clé secrète par l'oracle en cas de comportement incorrect, par exemple, si l'oracle permet des essais de résultats, alors il suffit de faire seulement deux essais pour connaître la clé secrète et obtenir un accès complet au portefeuille. Troisièmement, une signature vérifiable nativement dans la blockchain, qui est source d'aléatoire — c'est élégant.

L'idée de mise en œuvre a mûri pendant six mois, jusqu'à ce qu'une motivation apparaisse sous la forme de une subvention de Waves Labs. Avec une grande subvention vient une grande responsabilité, donc le projet doit voir le jour !

Mise en œuvre

Ainsi, dans ce projet VECRO a été réalisé sur la blockchain Waves en mode requête-réponse à l'aide de transactions de transfert entre l'utilisateur et l'oracle. Dans ce cadre, un script est installé sur le compte de l'oracle, qui contrôle le fonctionnement conformément à la logique décrite ci-dessus. Les transactions de l'oracle sont vérifiées en reconstruisant toute la chaîne d'interaction avec l'utilisateur. La vérification de la valeur finale implique toutes les quatre transactions, le contrat intelligent enchaîne celles-ci sur un fil de vérification strict, vérifiant pas à pas toutes les valeurs et ne laissant aucune place pour des manipulations.

Encore une fois, pour que ce soit bien clair. L'oracle ne fonctionne pas seulement selon le schéma proposé. Son fonctionnement est entièrement contrôlé au niveau de la blockchain par une installation définie. smart contract à jamais. Un pas à gauche, et la transaction ne passera tout simplement pas. Ainsi, si la transaction est entrée dans la blockchain, l'utilisateur n'a même rien à vérifier, des centaines de nœuds du réseau ont déjà tout vérifié pour lui.

Actuellement, un VECRO est lancé sur le réseau principal de Waves (vous pouvez lancer le vôtre, ce n'est pas compliqué, il suffit de jeter un œil à l'exemple de configuration). Le code actuel fonctionne sur PHP (sur WavesKit, dont j'ai parlé précédemment.).

Pour utiliser le service oracle, il est nécessaire de :

• Fixer R;
  • Envoyer au minimum 0.005 Waves à l'alias de l'oracle init@vecr;
  • Recevoir le R-code dans le champ attachment lors du transfert de 1 R-vecr token de l'oracle à l'utilisateur;
• Obtenir la signature;
  • Envoyer au minimum 0.005 Waves à l'alias de l'oracle random@vecr, et indiquer OBLIGATOIREMENT dans le champ attachment le R-code obtenu précédemment et des données utilisateur supplémentaires ;
  • Recevoir le S-code dans le champ attachment lors du transfert de 1 S-vecr token de l'oracle à l'utilisateur ;
• Utiliser le S-code comme source de nombre pseudo-aléatoire.

Nuances de l'implémentation actuelle :

• Les Waves envoyés à l'oracle sont utilisés comme commission pour la transaction de retour à l'utilisateur, jusqu'à un maximum de 1 Waves ;
• Le R-code est la concaténation d'un octet du symbole 'R' et de 32 octets de valeur R en encodage base58 ;
• Le R-code dans l'attachment doit être en premier, les données utilisateur viennent après le R-code ;
• Le S-code est la concaténation d'un octet du symbole 'S' et de 32 octets de valeur S en encodage base58 ;
• S est le résultat d'une division modulo, il ne faut donc pas utiliser S comme numéro pseudo-aléatoire de 256 bits (ce nombre peut être considéré comme un nombre pseudo-aléatoire de maximum 252 bits) ;
• La solution la plus simple consiste à utiliser le hash du S-code comme nombre pseudo-aléatoire.

Exemple d'obtention du S-code :

• Initialisation : https://wavesexplorer.com/tx/8gc8jwM7JrPNehoDs7NVyos7BsufYktvkwVW1B6FAY6
• Obtention du R-code : https://wavesexplorer.com/tx/9eB25SbzEwvHEbm8pcKj7MGDrYv1u3Fxpj696FkJ96hd
• Demande du résultat de la signature du R-code et des données utilisateur 'random': https://wavesexplorer.com/tx/6faoFJobEsugDFYmYmfsbtQYABmckNuE2kevaLh7ifzz
• Obtention du S-code : https://wavesexplorer.com/tx/C5VrFLQcprbA1KXAToaNvMP4Kg2rq43NkwWuADAA7wXX

D'un point de vue technique, l'oracle est entièrement opérationnel, vous pouvez l'utiliser sans crainte. D'un point de vue utilisateur, il manque une interface graphique conviviale, cela devra attendre.

Je serais heureux de répondre à vos questions et de prendre vos remarques, merci.

Source : habr.com