{"id":32343,"date":"2019-10-31T21:46:27","date_gmt":"2019-10-31T18:46:27","guid":{"rendered":"https:\/\/prohoster.info\/blog\/cluchajnyj-orakul-na-osnove-tsifrovoj-podpisi-v-blokchejne\/"},"modified":"2019-10-31T21:46:27","modified_gmt":"2019-10-31T18:46:27","slug":"cluchajnyj-orakul-na-osnove-tsifrovoj-podpisi-v-blokchejne","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/cluchajnyj-orakul-na-osnove-tsifrovoj-podpisi-v-blokchejne","title":{"rendered":"Oracule al\u00e9atoire bas\u00e9 sur une signature num\u00e9rique dans la blockchain","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

De l'id\u00e9e \u00e0 la r\u00e9alisation : nous modifions le sch\u00e9ma existant de signature num\u00e9rique sur courbe elliptique pour le rendre d\u00e9terministe, et nous proposons \u00e0 partir de celui-ci des fonctionnalit\u00e9s d'obtention de nombres pseudo-al\u00e9atoires v\u00e9rifiables dans le cadre de la blockchain.<\/p>\n

<\/p>\n

\"Oracule<\/p>\n

<\/a><\/noindex><\/p>\n

Id\u00e9e<\/h1>\n

<\/p>\n

\u00c0 l'automne 2018, la blockchain Waves a activ\u00e9 les premiers contrats intelligents<\/a><\/noindex>, la question de la possibilit\u00e9 d'obtenir des nombres pseudo-al\u00e9atoires<\/a><\/noindex>, dignes de confiance, est imm\u00e9diatement apparue.<\/p>\n

<\/p>\n

En r\u00e9fl\u00e9chissant \u00e0 cette question, je suis finalement arriv\u00e9 \u00e0 la conclusion : toute blockchain est une cage, il est impossible d'obtenir une source d'entropie fiable dans un syst\u00e8me ferm\u00e9.<\/p>\n

<\/p>\n

Mais une id\u00e9e m'a tout de m\u00eame plu : si un oracle al\u00e9atoire<\/a><\/noindex> signait les donn\u00e9es utilisateur avec un algorithme d\u00e9terministe, alors l'utilisateur pourrait toujours v\u00e9rifier une telle signature avec la cl\u00e9 publique et serait assur\u00e9 que la valeur obtenue est unique. L'oracle, quoi qu'il en soit, ne peut rien modifier, l'algorithme produit un r\u00e9sultat unique. En substance, l'utilisateur fixe le r\u00e9sultat, mais ne le conna\u00eet pas tant que l'oracle ne l'a pas publi\u00e9. Il s'av\u00e8re qu'il est possible de ne pas faire confiance \u00e0 l'oracle en g\u00e9n\u00e9ral, mais de v\u00e9rifier le r\u00e9sultat de son travail. Ainsi, en cas de v\u00e9rification r\u00e9ussie, une telle signature peut \u00eatre consid\u00e9r\u00e9e comme une source d'entropie pour un nombre pseudo-al\u00e9atoire.<\/p>\n

<\/p>\n

La plateforme blockchain Waves utilise un sch\u00e9ma de signature EdDSA<\/a><\/noindex> une variante Ed25519<\/a><\/noindex>. Dans ce sch\u00e9ma, la signature consiste en des valeurs R et S, o\u00f9 R d\u00e9pend d'une valeur al\u00e9atoire, et S est calcul\u00e9 sur la base du message sign\u00e9, de la cl\u00e9 secr\u00e8te et de la m\u00eame valeur al\u00e9atoire que R. Il en r\u00e9sulte qu'il n'y a pas de d\u00e9pendance unique, pour le m\u00eame message utilisateur, il existe de nombreuses signatures valides.<\/p>\n

<\/p>\n

Il est \u00e9vident qu'une telle signature, dans sa forme pure, ne peut pas \u00eatre utilis\u00e9e comme source de nombres pseudo-al\u00e9atoires, car elle est non d\u00e9terministe et, par cons\u00e9quent, peut facilement \u00eatre manipul\u00e9e par l'oracle.<\/p>\n

<\/p>\n

Mais, comme il s'est av\u00e9r\u00e9, il est en r\u00e9alit\u00e9 possible de la rendre d\u00e9terministe.<\/p>\n

<\/p>\n

J'avais de grands espoirs pour la fonction al\u00e9atoire v\u00e9rifiable (VRF)<\/a><\/noindex>, mais apr\u00e8s avoir \u00e9tudi\u00e9 la mati\u00e8re, il a fallu abandonner cette option. Bien que le VRF propose une variante d\u00e9terministe de la signature et de sa preuve, il y a un aspect \u00e9trange 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<\/a><\/noindex>) un cl\u00e9 priv\u00e9e est utilis\u00e9e, qui reste inconnue de l'utilisateur, ce qui signifie que l'utilisateur ne peut pas v\u00e9rifier la validit\u00e9 du calcul de k, donc l'oracle peut utiliser n'importe quelle valeur k n\u00e9cessaire et en m\u00eame temps maintenir une base de donn\u00e9es de correspondances entre k et les donn\u00e9es sign\u00e9es, afin de toujours pouvoir recalculer un r\u00e9sultat correct selon le VRF. Si vous voyez un tirage bas\u00e9 sur le VRF sans divulguer la cl\u00e9 priv\u00e9e, vous pouvez faire la remarque : il est n\u00e9cessaire soit de r\u00e9v\u00e9ler la cl\u00e9, soit de l'exclure du calcul de k, alors la cl\u00e9 priv\u00e9e se r\u00e9v\u00e9lera d'elle-m\u00eame \u00e0 l'apparition de la premi\u00e8re signature. En r\u00e9sum\u00e9, comme d\u00e9j\u00e0 mentionn\u00e9, un sch\u00e9ma \u00e9trange pour un oracle al\u00e9atoire.<\/p>\n

<\/p>\n

Apr\u00e8s avoir r\u00e9fl\u00e9chi et obtenu le soutien d'analystes locaux, un sch\u00e9ma de fonctionnement pour VECRO a \u00e9t\u00e9 \u00e9labor\u00e9.<\/p>\n

<\/p>\n

VECRO est l'acronyme de Verifiable Elliptic Curve Random Oracle, ce qui signifie en fran\u00e7ais un oracle al\u00e9atoire v\u00e9rifiable bas\u00e9 sur des courbes elliptiques.<\/p>\n

<\/p>\n

Tout s'est r\u00e9v\u00e9l\u00e9 assez simple, pour atteindre la d\u00e9terminit\u00e9, il est n\u00e9cessaire de fixer la valeur R avant l'apparition du message \u00e0 signer. Si R est fix\u00e9 et fait partie du message sign\u00e9, ce qui garantit en outre la fixation de R dans le message lui-m\u00eame, la valeur S est d\u00e9termin\u00e9e de mani\u00e8re unique par le message de l'utilisateur et peut donc \u00eatre utilis\u00e9e comme source de nombres pseudo-al\u00e9atoires.<\/p>\n

<\/p>\n

Dans un tel sch\u00e9ma, peu importe comment R est fix\u00e9, cela reste de la responsabilit\u00e9 de l'oracle. L'important est que S soit d\u00e9termin\u00e9e de mani\u00e8re unique par l'utilisateur, mais sa valeur reste inconnue tant que l'oracle ne la publie pas. Tout comme nous le voulions !<\/p>\n

<\/p>\n

En parlant de R fix\u00e9, notez que R r\u00e9utilis\u00e9<\/a><\/noindex> La signature de diff\u00e9rents messages r\u00e9v\u00e8le ind\u00e9niablement la cl\u00e9 secr\u00e8te dans le sch\u00e9ma EdDSA. Pour le propri\u00e9taire de l'oracle, il devient crucial d'exclure la possibilit\u00e9 de r\u00e9utiliser R pour signer plusieurs messages d'utilisateur. Cela signifie que, dans toutes les manipulations ou collusions, l'oracle risque toujours de perdre sa cl\u00e9 secr\u00e8te.<\/p>\n

<\/p>\n

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\u00e9rifiable classique d'un message utilisateur contenant la valeur fixe de R et des donn\u00e9es utilisateur arbitraires.<\/p>\n

<\/p>\n

On pourrait objecter que ce sch\u00e9ma pour la blockchain n'est autre qu'une simple sch\u00e9ma de commit-r\u00e9v\u00e9lation<\/a><\/noindex>. En effet, c'est le cas. Mais il y a plusieurs nuances. Tout d'abord, l'oracle utilise toujours la m\u00eame cl\u00e9 dans toutes les op\u00e9rations, ce qui est pratique dans les contrats. Deuxi\u00e8mement, il existe un risque de perte de la cl\u00e9 secr\u00e8te par l'oracle en cas de comportement incorrect, par exemple, si l'oracle permet des essais de r\u00e9sultats, alors il suffit de faire seulement deux essais pour conna\u00eetre la cl\u00e9 secr\u00e8te et obtenir un acc\u00e8s complet au portefeuille. Troisi\u00e8mement, une signature v\u00e9rifiable nativement dans la blockchain, qui est source d'al\u00e9atoire \u2014 c'est \u00e9l\u00e9gant.<\/p>\n

<\/p>\n

L'id\u00e9e de mise en \u0153uvre a m\u00fbri pendant six mois, jusqu'\u00e0 ce qu'une motivation apparaisse sous la forme de une subvention de Waves Labs<\/a><\/noindex>. Avec une grande subvention vient une grande responsabilit\u00e9, donc le projet doit voir le jour !<\/p>\n

<\/p>\n

Mise en \u0153uvre<\/h1>\n

<\/p>\n

Ainsi, dans ce projet VECRO a \u00e9t\u00e9 r\u00e9alis\u00e9<\/a><\/noindex> sur la blockchain Waves en mode requ\u00eate-r\u00e9ponse \u00e0 l'aide de transactions de transfert entre l'utilisateur et l'oracle. Dans ce cadre, un script est install\u00e9 sur le compte de l'oracle, qui contr\u00f4le le fonctionnement conform\u00e9ment \u00e0 la logique d\u00e9crite ci-dessus. Les transactions de l'oracle sont v\u00e9rifi\u00e9es en reconstruisant toute la cha\u00eene d'interaction avec l'utilisateur. La v\u00e9rification de la valeur finale implique toutes les quatre transactions, le contrat intelligent encha\u00eene celles-ci sur un fil de v\u00e9rification strict, v\u00e9rifiant pas \u00e0 pas toutes les valeurs et ne laissant aucune place pour des manipulations.<\/p>\n

<\/p>\n

Encore une fois, pour que ce soit bien clair. L'oracle ne fonctionne pas seulement selon le sch\u00e9ma propos\u00e9. Son fonctionnement est enti\u00e8rement contr\u00f4l\u00e9 au niveau de la blockchain par une installation d\u00e9finie. smart contract \u00e0 jamais<\/a><\/noindex>. Un pas \u00e0 gauche, et la transaction ne passera tout simplement pas. Ainsi, si la transaction est entr\u00e9e dans la blockchain, l'utilisateur n'a m\u00eame rien \u00e0 v\u00e9rifier, des centaines de n\u0153uds du r\u00e9seau ont d\u00e9j\u00e0 tout v\u00e9rifi\u00e9 pour lui.<\/p>\n

<\/p>\n

Actuellement, un VECRO est lanc\u00e9 sur le r\u00e9seau principal de Waves (vous pouvez lancer le v\u00f4tre, ce n'est pas compliqu\u00e9, il suffit de jeter un \u0153il \u00e0 l'exemple de configuration<\/a><\/noindex>). Le code actuel fonctionne sur PHP (sur WavesKit<\/a><\/noindex>, dont j'ai parl\u00e9 pr\u00e9c\u00e9demment.<\/a><\/noindex>).<\/p>\n

<\/p>\n

Pour utiliser le service oracle, il est n\u00e9cessaire de :<\/p>\n

<\/p>\n