De l'idée à la mise en œuvre : nous modifions le schéma de signature numérique à courbe elliptique existant afin qu'il soit déterministe, et sur cette base, nous fournissons des fonctions permettant d'obtenir des nombres pseudo-aléatoires vérifiables au sein de la blockchain.
Idée
À l'automne 2018, la blockchain Waves comprenait , la question s'est immédiatement posée de la possibilité d'obtenir vous pouvez croire.
Perplexe face à cette question, je suis finalement arrivé à la conclusion : toute blockchain est une cellule ; il est impossible d'obtenir une source d'entropie fiable dans un système fermé.
Mais j'aimais quand même une idée : si signera les données utilisateur avec un algorithme déterministe, l'utilisateur pourra alors toujours vérifier une telle signature à l'aide de la clé publique et sera sûr que la valeur résultante est unique. L'oracle, peu importe ses efforts, est incapable de changer quoi que ce soit ; l'algorithme produit un résultat sans ambiguïté. Essentiellement, l’utilisateur enregistre le résultat, mais ne le connaît pas jusqu’à ce que l’oracle le publie. Il s'avère que vous ne pouvez pas du tout faire confiance à l'oracle, mais vérifier le résultat de son travail. Ensuite, 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 вариант . Dans ce schéma, la signature est constituée des valeurs R et S, où R dépend d'une valeur aléatoire, et S est calculé en fonction du message signé, de la clé privée et du même nombre aléatoire que R. Il s'avère que il n'y a pas de dépendance unique pour le même message. Il existe de nombreuses signatures valides pour un message utilisateur.
Évidemment, dans sa forme pure, une telle signature ne peut pas être utilisée comme source de nombres pseudo-aléatoires, car elle est non déterministe et peut donc être facilement manipulée par l'oracle.
Mais il s’est avéré qu’il est effectivement possible de le rendre déterministe.
J'avais de grands espoirs pour , mais après avoir étudié le matériel, j'ai dû abandonner cette option. Bien que VRF propose une version déterministe de la signature et de sa preuve, il existe un endroit étrange dans l'algorithme qui ouvre un trou noir pour la manipulation de l'oracle. À savoir, lors du calcul de la valeur de k () on utilise une clé privée qui reste inconnue de l'utilisateur, ce qui signifie que l'utilisateur ne peut pas vérifier l'exactitude du calcul de k, ce qui signifie que l'oracle peut utiliser n'importe quelle valeur de k dont il a besoin et en même temps maintenir une base de données de correspondances de k et les données signées afin de toujours pouvoir recalculer le résultat correct du point de vue de VRF . Si vous voyez un dessin basé sur VRF sans divulguer la clé privée, vous pouvez être malin : indiquez la nécessité soit de révéler la clé, soit de l'exclure du calcul de k, alors la clé privée se révélera automatiquement lorsque la première signature apparaîtra . En général, comme déjà mentionné, un schéma étrange pour un oracle aléatoire.
Après quelques réflexions et avec le soutien d'analystes locaux, le programme de travail VECRO est né.
VECRO est l'abréviation de Verifiable Elliptic Curve Random Oracle, qui signifie en russe un oracle aléatoire vérifiable sur des courbes elliptiques.
Tout s'est avéré assez simple : pour atteindre le déterminisme, il faut fixer la valeur de R avant que le message à signer n'apparaisse. Si R est validé et fait partie du message en cours de signature, ce qui garantit en outre que R est validé dans le message en cours de signature, la valeur de 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, la manière dont R est fixé n'a pas d'importance ; cela reste de la responsabilité de l'oracle. Il est important que S soit déterminé de manière unique par l'utilisateur, mais sa valeur est inconnue jusqu'à ce que l'oracle la publie. Tout ce que nous voulions !
En parlant de R fixe, notez que Lors de la signature de divers messages, il révèle de manière unique la clé privée dans le schéma EdDSA. Il devient extrêmement important pour le propriétaire de l’oracle d’éliminer la possibilité de réutiliser R pour signer différents messages utilisateur. Autrement dit, en cas de manipulation ou de collusion, l'oracle risquera toujours de perdre sa clé privée.
Au total, l'oracle doit fournir aux utilisateurs deux fonctions : l'initialisation, qui fixe la valeur R, et la signature, qui renvoie la valeur S. Dans ce cas, la paire R, S est la signature vérifiable habituelle d'un message utilisateur contenant une valeur fixe. valeur R et données utilisateur arbitraires.
On peut affirmer que ce schéma de blockchain n’est rien d’autre qu’un schéma ordinaire. . En gros, oui, c'est elle. Mais il y a plusieurs nuances. Premièrement, l'oracle fonctionne toujours avec la même clé dans toutes les opérations, par exemple, cela est pratique à utiliser dans les contrats. Deuxièmement, il y a un risque que l'oracle perde la clé privée s'il se comporte mal, par exemple, l'oracle permet de faire des échantillons du résultat, alors il suffit de faire seulement deux tests pour connaître la clé privée et obtenir un résultat complet. accès au portefeuille. Troisièmement, une signature nativement vérifiable sur la blockchain et source d’aléatoire, c’est beau.
Pendant six mois, l'idée de mise en œuvre a mijoté dans ma tête, jusqu'à ce que finalement la motivation apparaisse sous la forme . Une grosse subvention implique une grande responsabilité, ce qui signifie que le projet sera là !
exécution
Donc, dans ce projet sur la blockchain Waves en mode requête-réponse utilisant des transactions de transfert entre l'utilisateur et l'oracle. Parallèlement, un script est installé sur le compte Oracle qui contrôle le travail en stricte conformité avec la logique décrite ci-dessus. Les transactions Oracle sont vérifiées et toute la chaîne d'interaction utilisateur est restaurée. Les quatre transactions sont impliquées dans la vérification de la valeur finale ; le contrat intelligent les enchaîne avec un fil de vérification strict, vérifiant toutes les valeurs étape par étape et ne laissant aucune place à aucune manipulation.
Encore une fois, pour mettre cela de côté et rendre les choses plus claires. L'oracle ne fonctionne pas seulement selon le schéma proposé. Son travail est entièrement contrôlé au niveau de la blockchain par les sociétés établies. . Faites un pas vers la gauche et la transaction n’aboutira tout simplement pas. Ainsi, si une transaction est incluse dans la blockchain, l’utilisateur n’a même pas besoin de vérifier quoi que ce soit : des centaines de nœuds du réseau ont déjà tout vérifié pour lui.
Actuellement, il existe un VECRO fonctionnant sur le réseau principal Waves (vous pouvez exécuter le vôtre, ce n'est pas difficile, il suffit de le faire). ). Le code actuel s'exécute en PHP (sur , a propos de ).
Pour utiliser le service Oracle, vous devez :
- Corriger R ;
- Envoyez au moins 0.005 Waves à Oracle alias init@vecr ;
- Recevez le R-code dans le champ de pièce jointe lors du transfert de 1 jeton R-vecr de l'oracle à l'utilisateur ;
- Obtenez une signature ;
- Envoyez au moins 0.005 Waves à l'alias Oracle random@vecr, et DOIT également indiquer le code R précédemment reçu et les données utilisateur supplémentaires dans le champ de pièce jointe ;
- Recevez le code S dans le champ de pièce jointe lors du transfert de 1 jeton S-vecr de l'oracle à l'utilisateur ;
- Utilisez le code S comme source de nombres pseudo-aléatoires.
Nuances de la mise en œuvre actuelle :
- Les vagues envoyées à l'oracle sont utilisées comme commission pour la transaction de retour à l'utilisateur, jusqu'à un maximum de 1 vague ;
- Le code R est la concaténation d'un octet du caractère « R » et d'une valeur R de 32 octets codée en base58 ;
- Le code R en pièce jointe doit être en premier, les données utilisateur viennent après le code R ;
- Le code S est la concaténation d'un octet du caractère « S » et d'une valeur de S codée en base32 sur 58 octets ;
- S est le résultat d'une division modulo, vous ne pouvez donc pas utiliser S comme un nombre pseudo-aléatoire complet de 256 bits (ce nombre peut être considéré comme un nombre pseudo-aléatoire maximum de 252 bits) ;
- L'option la plus simple consiste à utiliser le hachage du code S comme nombre pseudo-aléatoire.
Exemple de réception de code S :
- Initialisation :
- Obtenir le code R :
- Interrogation du résultat de la signature du code R et des données utilisateur « aléatoire » :
- Réception du code S :
D'un point de vue technique, l'oracle est complètement prêt à fonctionner, vous pouvez l'utiliser en toute sécurité. Du point de vue de l'utilisation par l'utilisateur moyen, il manque une interface graphique pratique, il faudra attendre pour cela.
Je serai heureux de répondre aux questions et d’accepter les commentaires, merci.
Source: habr.com