Chargement
keyboard_arrow_up
BitcoinEvénementsTechnique

La quatrième conférence Scaling Bitcoin s’est déroulée samedi 4 et dimanche 5 novembre à l’Université de Stanford, en Californie. Cette conférence est l’occasion annuelle pour les développeurs du projet Bitcoin de présenter leurs travaux et les futures améliorations du protocole.

Notre petite délégation française, représentant l’association Le Cercle du Coin, était composée d’Adli Takkal-Bataille, son président, d’Alexandre David (Eureka Certification) et de votre serviteur. En filigrane, l’un des objectifs était de convaincre le comité d’organisation que la France est désormais une destination incontournable pour accueillir un tel événement.

À quelques jours du hard fork SegWit2X, qui fut finalement abandonné, les organisateurs de la conférence ne souhaitaient pas mettre en avant le conflit opposant les partisans de l’augmentation de la taille des blocs aux défenseurs des blocs SegWit de 1 Mo. Néanmoins, de nombreuses discussions informelles concernaient ce hard fork controversé.

Cependant, l’objectif principal de l’événement, comme son nom l’indique, est de mettre en commun les efforts des nombreux développeurs du réseau Bitcoin afin d’améliorer sa scalabilité[1]. Des solutions ont été présentées en nombre, et l’utilisateur final ne peut que s’impatienter de les voir mises en pratique, car les frais de transaction ne cessent de croître, ainsi que le nombre de transactions en attente sur le réseau.

Les solutions permettant d’accroître la scalabilité de Bitcoin en créant des canaux de paiement secondaires à la blockchain (payment channels, Lightning Network) étaient à l’honneur pour cette édition californienne, ainsi que les différents types de signatures cryptographiques permettant d’améliorer le niveau d’anonymat des parties impliquées dans une transaction.

L’accent a donc été mis sur la scalabilité mais également sur la confidentialité des données et la préservation de la vie privée des utilisateurs du réseau. C’est aussi pour préserver la vie privée des nombreux anonymes qui développent Bitcoin que le code de conduite de la conférence n’autorisait pas à prendre des photos du public ni des intervenants dans l’enceinte de l’auditorium.

Après une première soirée en compagnie des participants à la conférence, où ce fut l’occasion de rencontrer en personne de nombreux développeurs et dirigeants de sociétés de l’écosystème que nous ne connaissions que par voie numérique, la conférence a débuté le matin suivant avec le discours d’introduction d’Anton Yemelyanov, qui a consacré les derniers mois à l’organisation de cette édition 2017.

Première journée

Discours d’ouverture, par Anton Yemelyanov

Anton YemelyanovAnton Yemelyanov, coordinateur du Comité d’organisation de Scaling Bitcoin, a remercié tous les organisateurs et les participants à l’événement pour le travail accompli. Il a également félicité les développeurs ayant pris part aux ateliers précédant la conférence durant la semaine.

Vie privée et fongibilité

Concurrency and privacy with payment-channel networks

Par Pedro Moreno-Sanchez (université de Purdue)

Le chercheur a présenté le travail conjoint de son équipe quant aux canaux de paiements après avoir mis en lumière les problèmes actuels du réseau, qui ne peut fournir plus de dix transactions par seconde, et dont les frais ne cessent de croître.

Payment channel (canal de paiement) : les payment channels permettent à deux parties d’effectuer des transactions sans toutefois en inscrire la totalité dans la blockchain. Ces deux parties ne se font pas forcément confiance et l’ouverture d’un canal nécessite donc de programmer un contrat qui va automatiquement créditer les parties de leurs coins au prorata du dernier état du canal ayant été approuvé par les deux participants à l’échange. Il faut donc mettre sous séquestre les coins utilisés, grâce à des contrats autonomes.

Hash time-lock contracts (HTLCs) : ce sont des contrats qui ne s’exécutent que sous certaines conditions (l’une des parties doit fournir le bon hash satisfaisant ces conditions pour que le paiement soit effectué).

Dans le cas où les parties sont multiples, il est possible d’utiliser un réseau de canaux de paiements plutôt que de se limiter à deux utilisateurs : cela permet aux utilisateurs de ne pas avoir à ouvrir sans cesse des canaux.

Sécurité et privacy (confidentialité) :

Le problème survenant lors de ces paiements conditionnels effectués off-chain est qu’il est possible, en étudiant les conditions requises pour effectuer les transactions, d’en déduire des informations sur les canaux utilisés. La solution présentée par Pedro Moreno-Sanchez s’appelle Fulgor; elle est basée sur les “multi-hop HTLCs” (HTLCs à sauts multiples) et ne nécessite pas de hard fork du protocole Bitcoin actuel pour être implémentée.

Multi-hop HTLCs : Fulgor repose sur les preuves non-interactives à divulgation nulle de connaissance. Ces protocoles permettent de s’assurer de la validité d’une assertion sans connaître les parties engagées. Ils doivent respecter trois propriétés :

  • Completeness (consistance) : si le fournisseur de preuve et le vérificateur suivent le protocole alors le vérificateur doit toujours accepter la preuve.
  • Soundness (robustesse) : si la proposition est fausse, aucun fournisseur de preuve malicieux ne peut convaincre un vérificateur « honnête » que la proposition est vraie et ceci avec une forte probabilité – ce qui permet dans notre cas de s’assurer que Bob n’a pas perdu de coins lors de l’échange.
  • Zero knowledge (non-apport d’information) : le vérificateur n’apprend de la part du fournisseur de preuve rien de plus que la véracité de la proposition et n’obtient aucune information supplémentaire. Dans notre cas, cela permet de s’assurer que Bob ne puisse pas voler des coins lors de l’échange.

Concurrence dans les canaux de paiements : lorsque les transactions sont effectuées on chain, les mineurs peuvent aisément sélectionner celles qu’ils souhaitent inclure dans leurs blocs en regardant les frais associés, donnée qui est publique. Dans le cas d’un canal de paiement, aucun utilisateur n’a accès à l’ensemble de ces informations. La solution proposée par le chercheur et son équipe s’appelle Rayo.

Le chercheur a présenté les résultats de son prototype : 309 ms pour créer la preuve, 130 ms pour sa vérification et 1,65 Mo de taille. Un paiement non privé s’effectue en 609 ms et un paiement privé 1929 ms.

Il n’est pas possible d’avoir une solution offrant à la fois concurrence et anonymat. Le système proposé effectue donc un compromis entre les deux.

En conclusion, le chercheur a donc insisté sur ce compromis entre confidentialité et mise en concurrence, mis en oeuvre dans les deux solutions Fulgor et Rayo, totalement compatibles avec le système de script de Bitcoin, et qui ne requièrent pas de stockage de données sur la blockchain.

Les slides de la présentation.

BOLT Anonymous Payment Channels for Decentralized Currencies

Par Ian Miers (Johns Hopkins University)

Ian MiersEn introduction, le chercheur, connu pour ses travaux dans le cadre de Zcash, a rappelé les problèmes de scalabilité et d’anonymat des protocoles blockchain actuels. Il a pris l’exemple de la note d’un bar payée en fin de soirée pour illustrer un canal de paiement : le consommateur s’assoit à sa table, crée et augmente sa dette vis-à-vis du tenancier puis règle la totalité de ses consommations à la fin de la soirée : dans le cas d’un canal de paiement, c’est la même chose, à la différence notable qu’il n’y a pas de lien de confiance entre les parties.

Ian Miers a insisté sur le fait que les lightning networks sont loin d’être anonymes et a présenté son travail : BOLT, un ensemble de protocoles permettant d’établir des canaux de paiements anonymes.

Dans le cas de canaux “point à point” par exemple entre un consommateur et le gérant du bar, c’est l’interaction entre les deux personnes qui va lever l’anonymat du consommateur, ce dernier devant être identifié afin que le canal de paiement soit garanti. Avec les réseaux de canaux de paiement, les choses s’améliorent.

Atomic swaps et zero-knowledge proofs :

Pour reprendre l’image du consommateur au bar, il s’agit d’établir un système où chaque partie dispose d’un IOU (une reconnaissance de dette), par exemple 100$ pour le consommateur et 0$ pour le barman (au début), puis de 95 $ pour le consommateur et de 5 $ pour le marchand (à la fin). Les zero-knowledge proofs permettent d’effectuer cette transaction sans rien révéler des deux parties.

Mais il faut aussi que le premier IOU de 100 $ soit automatiquement remplacé par l’IOU de 95 $ pour empêcher le consommateur d’obtenir une bière gratuite : c’est le principe de l’atomic swap. C’est plus facile à dire qu’à faire : en effet, en invalidant en premier l’IOU de 100 $, le consommateur n’a pas la garantie d’obtenir les 95 $ restants; en faisant l’inverse, il peut tricher.

L’idée est d’identifier l’IOU le plus récent, de le faire signer par le marchand (il est alors possible de prouver qu’il est correct), puis de révéler un identificateur permettant alors de détruire l’ancien IOU. Le tour de magie cryptographique permettant d’effectuer cela n’a pas été présenté car très rébarbatif mais tout se trouve dans la publication du chercheur et ce dernier a assuré un délai de 100 ms par saut pour effectuer un paiement.

Cette solution est supérieure selon le chercheur à TumbleBit et Lightning car elle offre une protection supplémentaire pour l’anonymat de l’utilisateur, même dans le cas où les nœuds du canal de paiement trichent par collusion. Cependant, elle nécessite l’implémentation d’un nouvel opcode dans le protocole Bitcoin, donc un fork de la blockchain.

Les slides de la présentation.

ValueShuffle: Mixing Confidential Transactions

Par Tim Ruffing (Saarland University)

Tim RuffingAprès avoir étudié des solutions offrant l’anonymat des parties au niveau secondaire du protocole, il s’agit ici d’une solution d’anonymat sur la couche primaire : ValueSuffle, un service de mixage.

Les solutions de mixages pair-à-pair habituelles reposent sur l’honnêteté des parties engagées. Afin de les améliorer, il doit être possible d’exclure les utilisateurs malicieux : c’est désormais possible avec DiceMix.

Cependant, mixer des coins n’est pas chose aisée, par exemple dans le cas où les parties concernées ne possèdent pas le même nombre de coins, il est possible par déduction d’en “dé-anonymiser” certains.

On peut donc améliorer le degré d’anonymat en utilisant à la fois DiceMix et CoinJoin (CoinShuffle++) :

  • Une nouvelle adresse de réception est générée ;
  • Les coins entrants sont mixés ;
  • S’il n’y a pas de disruption (anonymat rompu) lors du mixage, on peut signer la transaction CoinJoin ;
  • S’il y a disruption, il faut éliminer l’adresse de sortie, identifier les utilisateurs malicieux, les éliminer puis recommencer l’opération avec une nouvelle adresse de sortie.

Ce protocole de mixage pair à pair fonctionne car il est possible d’éliminer facilement des adresses publiques compromises.

Cependant, ce n’est toujours pas pleinement satisfaisant, car dès que l’une des transactions impliquées est identifiée, l’anonymat disparaît. De même, si Bob a mixé par exemple 0,7 BTC mais qu’il n’en dépense que 0,5, les 0,2 BTC restants pourraient à l’avenir permettre de remonter jusqu’aux adresses d’où les 0,5 BTC anonymes proviennent.

Le fait que la valeur des transactions soit publique est à la racine du problème. Il faudrait donc trouver le moyen de cacher les montants de ces transactions : c’est ce que propose Tim Ruffing avec les transactions confidentielles de ValueShuffle basées sur “l’engagement homomorphe”. La propriété utile de ces commitments (engagements) de type c = Com (x, r) est que connaissant c (une clef publique), il est impossible de retrouver x (le montant de la transaction), mais il est tout à fait possible de vérifier que la somme des engagements correspond à l’engagement des sommes (c’est-à-dire qu’il n’y a pas eu de création de monnaie).

Les avantages de ValueShuffle sont donc nombreux :

  • Il est facile de changer les adresses ;
  • Il n’y a pas besoin de deux transactions pour dépenser ses coins (il est possible de réaliser le mixage et le paiement dans la même transaction) ;
  • Il n’y a aucun problème lors de la dépense des coins en surplus ;
  • Il n’y a pas besoin d’avoir des sommes identiques en entrée et en sortie (il est donc facile de trouver des participants au mécanisme de mixage) ;
  • L’utilisation de l’espace sur la blockchain est minimale ;
  • Le temps de vérification des transactions est réduit ;
  • Les frais de transactions sont réduits.

Ce protocole permet donc d’assurer deux propriétés essentielles : cacher le montant des transactions et l’origine des coins dans le même temps, le tout pour un coût faible. Il y a bien sûr des variantes qui ont seulement été mentionnées mais qui sont disponibles sur GitHub en plus du code source principal. Quelques problèmes de mise en pratique ont également été cités (bannissement des utilisateurs malicieux, tentatives de doubles dépenses durant le CoinJoin…)

Les slides de la présentation.

Break

Le premier break de la journée fut l’occasion pour de nombreux participants de poser des questions techniques précises aux développeurs ayant présenté leur projet, mais aussi d’échanger avec les autres spectateurs ou acteurs de la conférence.

À suivre !

Commentaires

Indice des prix

Sécurisez vos cryptos

Ledger Nano S
Ledger Blue
Trezor Hardware wallet

Flux Twitter

Achetez des bitcoins/ethers

Acheter bitcoins et ethers sur Coinhouse
Acheter des bitcoins sur ZeBitcoin
Achat / Vente de crypto-monnaies sur coinbase