De l'idée à la mise en œuvre: modifier le schéma de signature de courbe elliptique existant pour qu'il soit déterministe et lui fournir des fonctions pour obtenir une vérification dans les nombres pseudo-aléatoires de la chaîne de blocs.
Idée
À l'automne 2018, lorsque les premiers contrats intelligents ont été activés sur la blockchain Waves, le sujet de l'obtention de numéros pseudo-aléatoires de manière fiable s'est posé naturellement.
En y réfléchissant, je suis arrivé à la conclusion que toute blockchain est une sorte de cage et qu'il est impossible d'obtenir une source fiable d'entropie dans un système clos.
Cependant, j'ai aimé une idée. Si un oracle aléatoire signe les données utilisateur avec un algorithme déterministe, l'utilisateur sera toujours en mesure de vérifier une telle signature par la clé publique pour s'assurer que la valeur obtenue est unique. L'oracle ne pourrait pas apporter de modifications car l'algorithme fournit un résultat à valeur unique. Fondamentalement, l'utilisateur corrige le résultat mais ne le sait pas jusqu'à ce qu'il soit publié par l'oracle. Ainsi, vous ne pouvez pas du tout faire confiance à l'oracle, mais vous pouvez toujours vérifier le résultat de son fonctionnement. Ensuite, en cas de vérification réussie, une telle signature peut être une source d'entropie pour un nombre pseudo-aléatoire.
Sur la blockchain Waves, le schéma de signature EdDSA variant Ed25519 est utilisé. Dans ce schéma, la signature se compose des valeurs R et S. R dépend d'une valeur aléatoire et S est calculé sur la base d'un message signé, d'une clé privée et du même nombre aléatoire que R. Il n'y a pas de dépendance unique, et plusieurs signatures valides existent pour le même message utilisateur.
Apparemment, ce type de signature en soi ne peut pas être utilisé comme source de nombres pseudo-aléatoires car il est indéterminé et, par conséquent, peut être facilement manipulé par l'oracle.
Cependant, il s'avère qu'il est en fait possible de le rendre déterministe.
Mes grands espoirs étaient fixés pour la fonction aléatoire vérifiable (VRF) , mais, après avoir étudié ses spécificités, je dois rejeter cette option. Bien que VRF offre une version déterminée d'une signature et de ses preuves, l'algorithme a une place étrange qui ouvre un trou noir pour les manipulations par l'oracle (cette déclaration est fausse, voir Mise à jour ). Plus précisément, pour calculer la valeur de k ( section 5.1 ), une clé privée est utilisée, qui reste inconnue de l'utilisateur, de sorte que l'utilisateur ne peut pas vérifier l'exactitude du calcul de k. Par conséquent, l'oracle peut utiliser n'importe quelle valeur de k dont il a besoin et exécuter simultanément une base de données pour les corrélations entre k et les données signées pour pouvoir toujours recalculer un résultat correct pour VRF. Si vous voyez une tombola basée sur VRF sans révéler la clé privée, vous pouvez vous montrer et indiquer la nécessité de révéler la clé ou de la retirer du calcul de k afin qu'elle se révèle automatiquement après la première signature. Dans l'ensemble, comme indiqué ci-dessus, il s'agit d'un schéma étrange pour l'oracle aléatoire.
Après réflexion et avec le soutien d'analystes locaux, un plan de fonctionnement de VECRO est né.
VECRO signifie Oracle vérifiable à courbe elliptique aléatoire. Cela s'est avéré plutôt simple. Pour parvenir à la détermination, nous devons fixer la valeur de R avant l'apparition d'un message à signer. Si R est fixe et R fait partie du message, ce qui garantit en outre que R est fixe avant le message. La valeur de S est complètement déterminée par un message d'utilisateur et, par conséquent, peut être utilisée comme source de nombres pseudo-aléatoires.
Dans un schéma de ce type, la façon dont R est fixé est sans importance et reste dans la zone de responsabilité de l'oracle. Ce qui est important, c'est que S soit entièrement déterminé par l'utilisateur, mais sa valeur n'est révélée qu'après publication par l'oracle. C'est exactement ce que nous voulions!
En parlant de fixer R, notez que la réutilisation de R pour signer divers messages révèle complètement la clé privée dans le schéma EdDSA. Pour le propriétaire de l'oracle, il est essentiel d'exclure la réutilisation de R pour signer divers messages utilisateur. C'est-à-dire que, dans toute manipulation ou collusion, l'oracle risque toujours de perdre sa clé privée.
Ainsi, l'oracle offrira deux fonctions à l'utilisateur: l'initialisation, qui fixe la valeur de R et une signature, qui renvoie la valeur de S.En attendant, la paire R, S est une signature vérifiable régulière pour un message utilisateur contenant un fixe valeur de R et des données aléatoires de l'utilisateur.
On peut affirmer que pour la blockchain, ce n'est rien d'autre qu'un schéma de révélation de validation régulier. Fondamentalement, c'est ce que c'est. Mais il y a quelques nuances. Tout d'abord, l'oracle utilise la même clé dans toutes les transactions, ce qui, par exemple, est pratique pour les contrats. Deuxièmement, il y a un risque de perdre une clé privée par l'oracle en raison de performances incorrectes. Par exemple, si l'oracle facilite les tests du résultat, deux tests suffisent pour déterminer la clé privée et accéder au portefeuille. Troisièmement, une signature vérifiée en mode natif sur la blockchain, qui est la source du hasard, est tout simplement magnifique.
Pendant environ six mois, cette idée a germé, jusqu'à ce qu'une motivation pour la mettre en œuvre soit arrivée sous la forme d'une subvention de Waves Labs . Avec la grande subvention vient une grande responsabilité, cela signifie que le projet sera!
Implémentation
VECRO a été implémenté sur la blockchain Waves en mode demande / réponse en utilisant des transactions de transfert entre l'utilisateur et l'oracle. Sur le compte de l'oracle, un script est défini qui contrôle le fonctionnement strictement conformément à la logique décrite ci-dessus. Les transactions de l'oracle sont vérifiées en recréant toute la chaîne d'interaction des utilisateurs. Les quatre transactions sont impliquées dans la vérification de la valeur finale. Un contrat intelligent les ajoute tous à un fil de vérification strict, vérifiant les valeurs étape par étape et ne laissant aucune place à aucune manipulation.
Essayons de le dire en termes simples. L'oracle ne fonctionne pas seulement dans le cadre d'un schéma proposé. Son fonctionnement est entièrement contrôlé au niveau de la blockchain par un contrat intelligent extrêmement strict . Tout petit détournement entraînerait le rejet de la transaction. Donc, si la transaction est sur la blockchain, les utilisateurs n'ont rien à vérifier, car toute la vérification a déjà été effectuée par des centaines de nœuds de la blockchain.
À l'heure actuelle, un VECRO est exploitable sur le réseau principal de Waves. Vous pouvez réellement lancer le vôtre: c'est simple, il suffit de regarder l'exemple de configuration . Le code actuel fonctionne sur PHP (sur WavesKit , dont j'ai discuté plus tôt ).
Pour utiliser l'oracle, vous devez:
- Fixate R
- Envoyez un minimum de 0,005 VAGUES à l'alias de l'oracle init @ vecr;
- Recevez un code R dans le champ de pièce jointe du transfert de 1 jeton R-vecr de l'oracle à l'utilisateur;
- Obtenez une signature;
- Envoyez un minimum de 0,005 VAGUES à l'alias de l'oracle random @ vecr. Vous êtes également OBLIGATOIRE d'entrer dans le champ de pièce jointe le code R reçu et les données utilisateur supplémentaires;
- Recevez un code S dans le champ de pièce jointe 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 l'implémentation actuelle:
- Les ONDES envoyées à l'oracle sont utilisées comme frais pour la transaction de retour à l'utilisateur, jusqu'à un maximum de 1 ONDES;
- Le code R est une concaténation de l'octet de symbole «R» et de la valeur R de 32 octets dans le codage base58;
- Le code R dans la pièce jointe doit précéder les données utilisateur;
- Le code S est une concaténation de l'octet de symbole «S» et de la valeur S de 32 octets dans le codage base58;
- S est le résultat d'une division modulo et ne peut pas être utilisé comme un nombre pseudo-aléatoire de 256 bits (il peut être considéré comme un nombre pseudo-aléatoire de 252 bits au plus);
- L'option la plus simple est l'utilisation du hachage du code S comme source de nombre pseudo-aléatoire.
Exemples de réception de code S:
D'un point de vue technique, l'oracle est pleinement opérationnel, vous pouvez l'utiliser en toute sécurité. Du point de vue d'un utilisateur ordinaire, il n'y a pas assez de GUI conviviale, qui devra attendre.
Je serai heureux de répondre aux questions et d'accepter les commentaires, merci.
Mise à jour (8 mai 2019)
J'avais tort sur VRF. Oui, il est vrai que la signature ECVRF ne peut pas être utilisée comme source d'un numéro pseudo-aléatoire, mais elle n'est pas utilisée à cette fin. La signature est nécessaire pour prouver l'unicité de la valeur Gamma ( section 5.3 , étape 6). Et la valeur vérifiée de Gamma sera utilisée comme source d'un nombre pseudo-aléatoire ( section 5.2 , étape 5). Merci à Oleg Taraskin Crittografo d' avoir signalé ce moment, j'avoue mon erreur. L'ECVRF a le plein droit de vivre.
Malheureusement, il n'y a toujours pas de possibilité d'utiliser ECVRF au niveau de la chaîne de blocs Waves, en raison du manque de fonctionnalités mathématiques nécessaires dans les contrats intelligents.
Lorsque cette fonctionnalité ou le support RSA sera disponible, de nouveaux oracles pourront être créés. Quant au schéma VECRO, il occupe en tout cas sa niche et vous permet de travailler sans aucune fonctionnalité supplémentaire.