Mimblewimble dans l’IdO

INTChain French Community
INTChain French Community
18 min readJun 24, 2019

--

Implémenter le respect de la vie privée et l’anonymat dans les Transactions INT

Cet article est une traduction amateure de l’excellent article de Grayblock dont vous pouvez consulter la version originale ici.

Les années 2017 et 2018 ont concentré le débat autour du sujet de la flexibilité. Les monnaies ont vécu des fork, des projets ont suscité l’engouement sur la simple base de cette notion. Ce débat nous a apporté des solutions, et nous a permis de voir où nous en sommes, capables de répondre aux besoins actuels lorsqu’associés avec un plan pour l’avenir. Au cours des années à venir, le débat va se concentrer sur un autre aspect, l’anonymat et la fongibilité dans l’adoption de masse.

Dans le monde des données connectées, dont l’évolution est rapide, le respect de la vie privée est devenu une préoccupation de premier plan. Actuellement, nous confions nos données privées à des entreprises centralisées où leur sécurité est assurée par la force de vos mots de passe, et la détermination qu’aurait un pirate à les casser. Au fur et à mesure que nous progressons dans cette nouvelle ère de l’internet, où tout est connecté, les données privées cryptées et la méfiance doivent être la base sur laquelle nous nous reposons. Dans ce futur, nous ne risquons plus seulement nos photos et nos numéros de cartes de crédit, mais bien toutes les données collectées issues de nos interactions avec notre environnement.

Si l’objectif est de développer l’avenir dans un réseau décentralisé, le challenge consistera à trouver des solutions qui possèdent un champ d’application équivalent à la diversité de l’écosystème, avec la possibilité de répondre aux besoins et prédictions en terme de flexibilité.
Ayant compris cela, INT a commencé à mener des recherches relatives à l’implémentation de deux protocoles de respect de la vie privée dans son réseau, qui répondent à deux besoins majeurs de l’IoT : la flexibilité des transactions privées, et les contrats intelligents privés.

Mimblewimble

L’un des protocoles permettant le respect de la vie privée envers lequel INT s’est intéressé est Mimblewimble. Mimblewimble est une nouvelle implémentation des mêmes éléments de Cryptographie sur les Courbes Elliptiques sur la base desquels la plupart des cryptomonnaies sont développées.

Dans le channel IRC bitcoin-wizards en Août 2016, un utilisateur anonyme a posté un lien Tor vers un white paper promettant “une idée pour améliorer le respect de la vie privée dans le bitcoin.”
Le principe était une proposition de blockchain utilisant une construction des transactions radicalement différente de tout ce qui se faisait alors, illustrant l’une des plus élégantes mises en oeuvre de la cryptographie sur les courbes elliptiques vues à ce jour.

Le white paper était suffisant pour développer les idées, soutenir la théorie, mais il ne contenait aucune notion mathématique, aucune analyse de sécurité. Andrew Poelstra, un mathématicien, le Directeur de Recherche de Blockstream, a immédiatement commencé à analyser le document, et a créé en deux mois de temps un white paper détaillé [Poel16] développant la cryptographie, les théorèmes fondamentaux, et les protocoles impliqués dans la création d’une blockchain autonome.

Les objectifs fixés consistent en un protocole qui dissimule entièrement les valeurs dans les transactions, et qui élimine le besoin d’indiquer des adresses, tout en résolvant les problèmes de flexibilité.

Transactions confidentielles

Disons que vous voulez cacher le montant que vous envoyez. Un excellent moyen de cacher l’information, connue de tous et rapide : le hachage ! Le hachage vous permet de produire de façon déterministe une chaîne de caractères de longueur constante, quelque soit la taille de la saisie. Il est impossible d’inverser le processus. Nous pouvons alors hacher le montant, et envoyer le tout dans la transaction.

X = SHA256(amount)

ou

4A44DC15364204A80FE80E9039455CC1608281820FE2B24F1E5233ADE6AF1DD5 = SHA256(10)

Cependant, le hachage étant une fonction déterministe, il suffirait de faire une liste de tous les hashes de tous les montants possibles pour annuler l’objectif qui était à l’origine de masquer le montant. Donc, au lieu de simplement hacher le montant, nous allons le multiplier par un facteur aveuglant privé. S’il reste privé, il n’y a aucun moyen de connaître le montant réel figurant derrière le hash.

X = SHA256(blinding factor * amount)

C’est ce que l’on appelle un engagement, vous vous engagez pour une valeur sans la révéler, et d’une façon qui ne permet pas de modifier cette valeur sans changer la valeur résultante de l’engagement.

Mais alors, comment un noeud valide une transaction utilisant ce schéma d’engagement ? Nous devons prouver que vous remplissez deux conditions : la première, que vous disposez de suffisamment d’argent, la seconde, que vous ne créez pas d’argent via le processus. La manière avec laquelle la plupart des protocoles valident cela consiste à utiliser une ou plusieurs transactions de crédit, et de créer un débit qui n’excèdera pas la somme des crédits. Si nous hachons les valeurs et que nous n’avons plus la possibilité de valider cette condition, nous risquons alors de créer de la monnaie venue de nulle part.

input(commit(bf,10), Alice) -> output(commit(bf,9), BOB), outputchange(commit(bf,5), Alice)Orinput(4A44DC15364204A80FE80E9039455CC1608281820FE2B24F1E5233ADE6AF1DD5, Alice) ->output(19581E27DE7CED00FF1CE50B2047E7A567C76B1CBAEBABE5EF03F7C3017BB5B7, Bob)output(EF2D127DE37B942BAAD06145E54B0C619A1F22327B2EBBCFBEC78F5564AFE39D, Alice)

Comme montré ci-dessus, les valeurs hachées plus tard semblent tout à fait valides, et ont pour résultat la création de 4 unités pour Alice, qui les reçoit en guise de change de sa transaction. Dans n’importe quelle transaction, la somme des données entrantes doit être égale à la somme des données sortantes. Faisons un peu de mathématiques sur ces valeurs hachées pour le prouver :

commit(bf1,x) = commit(bf2,y1) + commit(bf3,y2)

ce qui, si la transaction est valide, correspond à :

commit(bf1,x) - commit(bf2+bf3,y1+y2) = commit(bf1-(bf2+bf3),0)

Soit simplement un engagement sur le reste des facteurs aveuglants.

Grâce aux algorithmes de hachage, ce n’est pas possible. Pour vérifier ces transactions, nous aurions à rendre publics tous les facteurs aveuglants ainsi que les montants. Cependant, cela reviendrait à ne plus rien protéger. Comment rendre publique une valeur qui est fabriquée à partir d’un élément privé d’une façon telle qu’il serait impossible de reproduire le processus à rebours, mais quand même valider les conditions nécessaires ? Tout ceci fait penser au couple clé privée/clé publique dans le domaine de la cryptographie…

Ce que nous avons appris auparavant concernant la Cryptographie sur Courbes Elliptiques, est qu’en utilisant une courbe elliptique pour définir notre espace de nombres, nous pouvons utiliser un point de la courbe, G, et le multiplier par n’importe quel nombre, x, pour obtenir un autre point valide de la même courbe, P. Le calcul est rapide, et en prenant le point P obtenu et le point G connu publiquement, il est est pratiquement impossible de déterminer la valeur du coefficient utilisé. De cette façon, nous pouvons utiliser le point P en tant que clé publique et le nombre x en tant que clé privée. Ce qui est intéressant, c’est qu’elles ont la propriété intéressante d’être additives et transitives.

Si vous prenez le point P qui est égal à xG et lui ajoutez le point Q qui est égal à yG, son point résultant, W=P+Q, est équivalent à un autre point créé à partir de la valeur x+y. Donc :

Cette propriété, l’homomorphisme, nous permet d‘opérer des calculs avec des valeurs que nous ne connaissons pas.

Donc, plutôt que d’utiliser le montant brut et le facteur aveuglant dans notre engagement, nous les utilisons multipliés par un point générateur connu de notre courbe elliptique. Notre engagement peut désormais être défini ainsi :

Ceci est appelé l’Engagement de Pedersen et constitue le coeur des Transactions Confidentielles.

Appelons notre facteur aveuglant r, et les montants v, et utilisons les points du générateur Hand Gas positionnés sur la même courbe elliptique (sans plonger dans les signatures de Schnorr, nous allons simplement accepter que nous avons deux points différents pour le facteur aveuglant et les engagements pour les valeurs pour opérer la validation). Appliquons ceci à nos engagements précédents :

et appliquons les propriétés de transitivité :

ce qui, pour une transaction valide, serait équivalent à :

Avec ri, vi les valeurs en entrée, ro, vo les valeurs en sortie et rco, vbo les valeurs pour la différence sur la sortie.

La différence que nous obtenons est simplement l’engagement pour le reliquat du facteur aveuglant, également appelé l’engagement-à-zéro :

Vous remarquez que dans tous les cas, lorsque les facteurs aveuglants ont été choisis de façon aléatoire, l’engagement-à-zéro sera non nul, et, de fait, demeure un point valide de la courbe elliptique avec clé publique,

Et la clé privée égale à la valeur de la différence entre les coefficients aveuglants.

Par conséquent, si la somme des valeurs entrées moins la somme des valeurs en sortie produit une clé publique valide sur la courbe, vous savez que les montants échangés ont été équilibrés, que la balance finale est égale à zéro, et qu’aucune valeur n’a été créée à partir de rien. Si la différence résultante n’est pas de la forme :

pour un facteur aveuglant excédentaire, nous n’obtenons pas une clé publique valide sur la courbe, et nous savons que nous ne sommes pas dans le cas d’une transaction équilibrée. Pour le prouver, la transaction est alors signée par sa clé publique pour prouver qu’elle est bien équilibrée, et que tous les facteurs aveuglants sont bien connus. Au cours du processus, aucune information concernant la transaction n’est révélée (les détails étape par étape du processus de signature peuvent être lus dans [Arvan19]).

Le travail ci-dessus part du principe que les valeurs sont positives. Il serait tout à fait possible de créer une transaction tout à fait valide à partir de valeurs négatives, ce qui permettrait aux utilisateurs de créer de la valeur à partir de rien dans chaque transaction. Appelé Preuve d’intervalle (un accord sur un montant dans un certain intervalle sans que les 2 parties ne sachent quel est ce montant), chaque transaction doit être accompagnée d’un argument zero-knowledge qui prouvera que les valeurs liées à l’engagement se situent dans un intervalle prédéterminé de valeurs. Mimblewimble, comme Monero, utilise BulletProofs qui est une autre façon de calculer la preuve qui réduit la taille de la transaction de 80% à 90%.

Taille moyenne des transactions vues sur les réseaux actuels ou en considérant BLABLABLA

À ce stade, le protocole décrit est plus ou moins le même entre Mimblewimble et Monero. Le point de divergence est la façon dont les transactions sont signées.

Dans Monero, on trouve deux paires clé/adresse, les clés liées à la dépense, et les clés liées à la consultation. La clé de dépense est utilisée pour générer et signer les transactions, tandis que les clés de consultations sont utilisées pour “recevoir” les transactions. Les transactions sont signées avec ce qui s’appelle une Ring Signature qui est dérivée de la valeur dépensée de sortie, ce qui prouve qu’une clé en-dehors du groupe de clés possède la clé de dépense. Ceci est possible en créant une combinaison de signature Schnorr et de votre clé privée, et un mélange de clés leurres issues des clés publiques des transactions précédentes. Ces clés leurres sont toutes valides mathématiquement parlant, ce qui implique l’impossibilité de déterminer celle qui est la clé réelle. Cela dit, Monero utilise les Engagements de Pedersen décrits ci-dessus, les adresses ne sont donc jamais visibles publiquement mais sont simplement utilisés pour réclamer des fonds, signer des transactions et générer des facteurs aveuglants.

Mimblewimble, d’un autre côté, n’utilise aucune adresse de quelque sorte que ce soit. Oui. C’est bien cela, aucune adresse. C’est là tout le génie de ce protocole. Ce que Jedusor a démontré est que les facteurs aveuglants au sein des engagements de Pedersen ainsi que l’engagement-à-zéro peuvent être utilisés en tant que paire clé privée/publique à utilisation unique pour créer et signer les transactions.

N’importe quelle adresse basée sur les protocoles utilisant la cryptographie sur courbes elliptiques génère des paires clé privée/clé publique globalement de la même façon. En multipliant un très grand nombre aléatoire (k_priv) par un point (G) d’une courbe elliptique, le résultat (K_pub) est un autre point valide de la même courbe.

Cele permet d’obtenir une base pour toutes les autres générations d’adresses. Est-ce que cela vous semble familier ?

Souvenez-vous de l’engagement situé plus haut :

Chaque facteur aveuglant multiplié par un point G (en rouge) est exactement ce de quoi nous parlons ! r•G est la clé publique, avec r la clé privée ! Donc, au lieu d’utiliser des adresses, nous pouvons utiliser ces facteurs aveuglants comme preuves que nous possédons les entrées et sorties en utilisant ces valeurs pour construire la signature.

Ce changement, en apparence mineur, supprime simplement la possibilité de relier les adresses entre elles, et le besoin pour un script Sig de calculer pour vérifier la validité d’une signature, ce qui simplifie grandement la structure et la taille des Transactions Confidentielles. Bien sûr, cela signifie (actuellement) que le processus de transaction nécessite une interaction entre les différentes parties pour créer les signatures.

CoinJoin

Même si toutes les adresses et les montants sont désormais cachés, il y a toujours certaines informations qui peuvent être récoltées grâce aux transactions. Dans le format de transaction ci-dessus, il est toujours possible de voir quelles sorties sont utilisée et ce qui sort des transactions. Ce “graphe de transaction” peut révéler des informations relatives aux possesseurs du coefficient aveuglant et aboutir à la création d’une image de l’utilisateur sur la base de l’activité de ses transactions apparente. Pour masquer plus encore et condenser l’information, Mimblewimble implémente une idée de Greg Mawxell intitulée Coinjoin [Max13] qui a été développée à la base pour le Bitcoin. CoinJoin est une méthode qui ne nécessite pas de relation de confiance et qui combine de multiples entrées et sorties, issues de multiples transactions pour en faire une unique transaction. Cette méthode masque à la fois l’émetteur et le bénéficiaire d’un paiement. Pour mettre cela en place dans le Bitcoin, les utilisateurs ou les portefeuilles doivent interagir pour assembler les transactions de montants similaires afin de ne pas pouvoir les distinguer les unes des autres. Si vous étiez capable de combiner les signatures sans partager les clés privées, vous pourriez créer une signature combinée pour une quantité de transactions (comme ring signatures) et ne pas être dépendant des montants en transaction.

Dans cette transaction CoinJoin, 3 adresses ont 4 destinataires, et aucun moyen ne permet de relier un émetteur à un bénéficiare.

Dans le protocole Mimblewimble, réaliser l’équilibre pour une transaction ou pour plusieurs fonctionne de la même façon, sur la base de l’engagement-à-zéro. Tout ce que nous aurions besoin de faire est de créer une signature combinée pour l’ensemble des transactions combinées.
Mimblewimble est intrinsèquement développé pour construire ces signatures combinées avec le challenge de la construction des transactions inmpliqué par l’engagement de Schnorr. En utilisant le protocole OWAS, les noeuds peuvent combiner les transactions, lors de la création d’un bloc, dans une unique transaction avec une signature agrégée. Grâce à cela, Mimblewimble relie toutes les transactions au niveau des blocs, en créant effectivement pour chaque bloc une unique transaction de toutes les entrées et de toutes les sorties créées. Cela permet de flouter simultanément le graphe des transactions et peut supprimer les transactions intermédiaires qui ont été déclenchées pendant la création du bloc, raccourcissant considérablement la taille totale des blocs et donc la taille de la blockchain.

Tailler dans la masse

Nous pouvons amener cette étape un peu plus loin encore. Pour valider ce bloc complètement “unifié”, le noeud devrait faire la somme de tous les engagements en sortie ensemble, puis lui soustraire tous les engagements en entrée et vérifier que le résultat est un engagement-à-zéro valide.
Qu’est-ce qui nous empêche alors de rejoindre uniquement les transactions au sein d’un bloc ? Nous pourrions théoriquement combiner deux blocs, supprimer toutes les transactions qui sont crées et dépensées dans ces blocs, et le résultat sera de nouveau une transaction valide représentant uniquement les engagements non dépensés, et rien d’autre. Nous pourrions alors faire cela sur toute la route jusqu’au bloc Genesis, réduisant toute la blockchain qui ne contiendrait alors plus que les engagements pas encore dépensés. Ceci est appelé Cut-through (tailler dans la masse). Ce faisant, nous n’avons plus besoin de recycler les preuves des sorties dépensées, qui ont été vérifiées et peuvent être abandonnés. Ceci amène naturellement à une diminution massive de la croissance de la blockchain, réduisant la croissance de O(nombre de txs) vers O(nombre de sorties non dépensées).

Pour illustrer l’impact de cette méthode, imaginons que Mimblewimble soit implémenté sur le réseau Bitcoin depuis le début, la blockchain des 576.000 premiers blocs pèse 210 GB, avec 413.675.000 transactions au total et 55.400.000 sorties non dépensées au total. Dans Mimblewimble, les transactions en sortie représentent 5 kB (en incluant les preuves de range ~5 kB et les engagements de Pedersen ~33 bytes), les transactions en entrée représentent 23 bytes et les preuves de transactions 105 bytes (engagement-à-zéro et signature), les headers de blocs représentent 250 bytes (preuves de Merkle et PoW) et les transactions non confidentielles sont négligeables. La somme de tout cela représente la taille vertigineuse de 5.3 TB pour une synchronisation totale de toutes les informations de la blockchain, pour “seulement” 279 GB représentant les UTXOs. Lorsque nous taillons dans la masse, nous ne voulons pas perdre tout l’historique des transactions, donc nous conservons les preuves de toutes les transactions, mais également les UTXO et tous les headers de blocs. Cela réduit la blockchain à une taille de 322 GB, soit une réduction de 94%. Le résultat correspond à un état de consensus relatif uniquement à ce qui n’a pas été dépensé avec un historique total des preuv es, ce qui réduit drastiquement le temps de synchronisation pour les nouveaux nodes.

Si les Bulletproofs sont implémentées, la preuve des variations est réduite de plus de 5kB à moins de 1kB, ce qui réduit encore l’ensemble des UTXO dans l’exemple précédent de 279GB à 57 GB.

*Basé sur les considérations et calculs ci-dessus.

Il existe une autre implication intéressante dans les blockchains basées sur le PoS, l’irrévocabilité explicite. Une fois que l’irrévocabilité a été obtenue, ou une fois que qu’une transaction est située à une profondeur arbitrairement définie de la blockchain, il n’y a plus besoin de conserver les preuves de range. Ces transactions ont été validées, l’état de consensus a été construit dessus, et elles constituent une grosse majorité de la taille de la blockchain. Si nous disons dans cet exemple que l’irrévocabilité est décrétée à 100 blocs de profondeur, et considérons que 10% de l’ensemble des UTXO est en pré-irrévocabilité, cela réduirait la blockchain de 250GB supplémentaires, ce qui aboutirait à une synchonisation totale pour un poids de 73GB, soit une réduction de 98,6% (even down from its current state). Imaginez cela. Une blockchain de 73 GB pour 10 ans de transactions Bitcoin parfaitement anonymes, et 1/3 de la taille de la blockchain actuelle.

Il est important de noter que tailler dans la masse n’a aucun impact sur le respect de la vie privée ou la sécurité. Chaque noeud peut choisir ou pas de stocker la totalité de la chaîne sans tailler dans la masse, ce qui a pour unique conséquence d’augmenter l’espace disque nécessaire. La taille est une option parfaitement flexible qui a pour conséquence d’obtenir des blockchain basées sur Mimblewimble en moyenne trois fois plus petites que celle du Bitcoin, et quinze fois plus petites que Monero (même malgré la récente implémentation de Bulletproofs).

Qu’est-ce que cela signifie pour INT et l’IoT ?

Les transactions au sein d’un réseau IoT doivent être rapides, flexibles pour s’adapter à d’énormes volumes, adptatives à une multitude d’usages et d’appareils avec la capacité de conserver privées des information sensibles. Jusqu’à présent, les réseaux IoT se sont concentrés uniquement sur la flexibilité, créant des réseaux qui peuvent assurer la transmission de volumes conséquents à de niveaux de décentralisation variés, mais aucune attention n’a été portée sur le respect de la vie privée. Sans respect de la vie privée, ces réseaux vont simplement permettre à ceux qui les utilisent de fournir des munitions à ceux qui les attaquent.

L’utilisation révolutionnaire que fait Mimblewimble de la cryptographie sur les courbes elliptiques nous amène à un protocole respectant la vie privée en utilisant les engagements de Pedersen pour des transactions confidentielles, tout en supprimant la dépendance aux adresses et clés privées, que nous n’utiliserons plus comme nous le faisions jusqu’à présent. Cette structure des transactions, combinée avec Bulletproofs amène une protection de la vie privée nécessitant peu de ressources, et un anonymat similaire à celui de Monero, dans une blockchain 15 fois plus légère si on utilise la taille intégrale. Cela fournit une solution aux transactions privées qui correspond à la flexibilité attendue sur le réseau INT.

Le protocole Mimblewimble a été implémenté dans deux réseaux actifs, Grin et Beam. Les deux sont des réseaux purement transactionnels, qui se concentrent sur des transferts de valeurs privés et anonymes. Grin a opté pour une approche similaire à celle du Bitcoin avec un développement financé par la communauté, sans aucun préminage ni récompenses, tandis que Beam a l’état d’esprit d’une startup, avec un financement VC et un fort accent mis sur une expérience user-friendly.

INT d’un autre côté, cherche à implémenter ce protocole à la fois sur la chaîne principale, créer tous les transferts d’actifs INT de façon confidentielle ou en tant que sous-chaîne optionnelle supplémentaire, permettant aux utilisateurs de transférer leurs INT d’une chaîne non confidentielle vers une chaîne confidentielle, ou vice-versa, à volonté.

Les limites du système

Ce qui rend ce protocole révolutionnaire est également ce qui définit ses limites. Presque tous les protocoles, comme le Bitcoin, Ethereum, etc., utilisent un langage de script basique contenant une fonction appellée depuis la transaction pour indiquer au vérificateur quel script utiliser pour la valider. Dans le cas le plus simple, les données fournies avec l’entrée appellent “scriptSig” et lui founit deux données, la signature qui correspond à la transaction ainsi que la clé publique qui prouve que vous possédez la clé privée qui l’a créée. Le script en sortie utilise ces données avec l’algorithme logique qui vient avec pour montrer au validateur comment prouver qu’elles ont le droit de les dépenser. En utilisant la clé publique fournie, le validateur la hash, vérifie que le hash correspond au hash de la clé publique en sortie, et si c’est le cas vérifie que la signature fournie correspond à la signature en entrée.

Ce protocole de vérification autorise une capacité limitée de script à dire aux validateurs quoi faire avec les données fournies. Le réseau Bitcoin peut être mis à jour avec de nouvelles fonctions lui permettant de s’adapter à de nouveaux processus ou données. Grâce à cela, le protocole Bitcoin peut vérifier plusieurs signatures, verrouiller les transactions pour une période définie et effectuer des tâches plus complexes, telles que verrouiller des bitcoin dans un compte jusqu’à ce qu’une action extérieure soit entreprise.

Pour pouvoir conclure des contrats intelligents publics plus largement applicables, comme ceux d’Ethereum, vous devez fournir des données de manière non blindée ou créer des preuves blindées prouvant que vous remplissez les conditions du contrat intelligent.

Dans Mimblewimble, l’utilisation des facteurs aveuglants en tant que paires de clés simplifie grandement le processus de vérification de la signature, il n’y a pas d’opportunités de script normales dans le protocole de base. Ce qui est enregistré sur la blockchain est simplement :

  • Entrées utilisées — qui sont des anciens engagements consommés
  • Nouveaux résultats — qui sont de nouveaux engagements à publier
  • Noyau de transaction: contient la signature de la transaction avec un facteur aveuglant excessif, des frais de transaction et lock_height.

Et aucun de ces éléments ne peut être relié aux autres et ne contient aucune donnée utile pour piloter une action.

Il existe quelques propositions de solutions créatives à ce problème en faisant ce que l’on appelle des scripts sans script †. En utilisant les propriétés des signatures de Schnorr utilisées, vous pouvez réaliser des transactions multisig et des transactions plus complexes basées sur des conditions telles que les échanges inter-chaînes atomiques et peut-être même des canaux d’état de type réseau lightning. Néanmoins, cette complexité n’est pas suffisante pour répondre à tous les besoins des contrats intelligents IoT.

Et en plus, la mise en place de cut-through éliminerait les transactions qui pourraient être des contrats intelligents ou se reposer dessus.

Vous pouvez donc voir que dans cette conception nous pouvons masquer les valeurs et la propriété, mais uniquement pour un une dimension des données, la quantité. Faire quelque chose de plus complexe que de transférer la propriété de monnaies va au-delà de ses capacités. Cependant, la preuve de propriété et l’engagement à zéro ne sont en réalité qu’un type spécifique de preuve à Zéro-Connaissance (ZK). Alors, que se passe-t-il si, au lieu d’aveugler une valeur, nous aveuglons une preuve?

La partie 2 de cette série couvrira la mise en œuvre de contrats intelligents privés avec zkSNARK.

Références etNotes

https://github.com/ignopeverell/grin/blob/master/doc/intro.md

https://github.com/mimblewimble/grin/blob/master/doc/pow/pow.md

https://github.com/mimblewimble/grin/wiki/Grin-and-MimbleWimble-vs-ZCash

*https://bitcointalk.org/index.php?topic=305791.0

[poel16] http://diyhpl.us/~bryan/papers2/bitcoin/mimblewimble-andytoshi-INCOMPLETE-DRAFT-2016-10-06-001.pdf

** In order to prove that v=0 and therefore the commit to zero, in fact, has no Hcomponent without revealing r, we must use Schnorr protocol:

  • prover generates random integer n, computes and sends point 𝑇←n𝐻
  • verifier generates and sends random integer 𝑖
  • prover computes and sends integer 𝑠←𝑖𝑏+n modq, where q is the (public) order of the curve
  • verifier knowing point r𝐻 computes point 𝑖(r𝐻), then point 𝑖(r𝐻)+𝑇; computes point 𝑠𝐻; and ensures 𝑖(r𝐻)+𝑇=𝑠𝐻.

[Arvan19] https://medium.com/@brandonarvanaghi/grin-transactions-explained-step-by-step-fdceb905a853

[Bulletproofs] https://eprint.iacr.org/2017/1066.pdf

[Max13] https://bitcointalk.org/?topic=279249

[MaxCT]https://people.xiph.org/~greg/confidential_values.txt

[Back13]https://bitcointalk.org/index.php?topic=305791.0

http://diyhpl.us/wiki/transcripts/grincon/2019/scriptless-scripts-with-mimblewimble/

https://tlu.tarilabs.com/cryptography/scriptless-scripts/introduction-to-scriptless-scripts.html#list-of-scriptless-scripts

http://diyhpl.us/~bryan/papers2/bitcoin/2017-03-mit-bitcoin-expo-andytoshi-mimblewmble-scriptless-scripts.pdf

--

--

INTChain French Community
INTChain French Community

Nous détaillons ici des informations publiées par INTchain et traduites à la destination des francophones, ainsi que des articles relatifs au projet.