Lorsqu'il a conçu le prototype de Bitcoin en janvier 2009, Satoshi Nakamoto a dû construire un premier bloc à partir duquel la chaîne s'est allongée. Ce bloc il l'a appelé le bloc de genèse (« genesis block » en anglais) en référence au premier livre de la Torah et de la Bible, qui raconte la création du monde par Dieu.

Par convention, on considère qu'il s'agit du bloc de hauteur 0 (ou « bloc 0 ») au-dessus duquel les autres blocs sont successivement empilés. Examinons plus en détail ce que contient cet élément fondateur de Bitcoin en procédant à une dissection minutieuse !

 

Un bloc fondateur

Le bloc de genèse est une donnée essentielle du protocole Bitcoin car il constitue la base à partir de laquelle on peut déterminer la chaîne la plus longue (c'est-à-dire celle ayant le plus de preuve de travail accumulée) et par conséquent la validité des transactions du registre. Il est théoriquement le seul bloc à devoir être inscrit en dur dans le protocole, même si d'autres l'ont été par la suite.

Tel que l'écrivait Satoshi Nakamoto :

« La chaîne de blocs est une structure en forme d'arbre qui a pour racine le bloc de genèse, chaque bloc pouvant avoir plusieurs candidats à sa suite. »

Le code de novembre 2008 (fourni par Satoshi à Hal Finney, Ray Dillinger et James A. Donald notamment) contenait déjà une première version du bloc de genèse, horodatée au 10 septembre 2008, 18:02:08 UTC. Néanmoins, un nouveau bloc a été construit en janvier 2009 spécialement pour le lancement du prototype.

Le bloc de genèse que nous connaissons est ainsi présent dans la version 0.1 du logiciel de Bitcoin, publiée le 8 janvier 2009. Un commentaire au sein du code le décrit :

Genesis Block:
GetHash()      = 0x000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f
hashMerkleRoot = 0x4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b
txNew.vin[0].scriptSig     = 486604799 4 0x736B6E616220726F662074756F6C69616220646E6F63657320666F206B6E697262206E6F20726F6C6C65636E61684320393030322F6E614A2F33302073656D695420656854
txNew.vout[0].nValue       = 5000000000
txNew.vout[0].scriptPubKey = 0x5F1DF16B2B704C8A578D0BBAF74D385CDE12C11EE50455F3C438EF4C3FBCF649B6DE611FEAE06279A60939E028A8D65C10B73071A6F16719274855FEB0FD8A6704 OP_CHECKSIG
block.nVersion = 1
block.nTime    = 1231006505
block.nBits    = 0x1d00ffff
block.nNonce   = 2083236893
CBlock(hash=000000000019d6, ver=1, hashPrevBlock=00000000000000, hashMerkleRoot=4a5e1e, nTime=1231006505, nBits=1d00ffff, nNonce=2083236893, vtx=1)
  CTransaction(hash=4a5e1e, ver=1, vin.size=1, vout.size=1, nLockTime=0)
    CTxIn(COutPoint(000000, -1), coinbase 04ffff001d0104455468652054696d65732030332f4a616e2f32303039204368616e63656c6c6f72206f6e206272696e6b206f66207365636f6e64206261696c6f757420666f722062616e6b73)
    CTxOut(nValue=50.00000000, scriptPubKey=0x5F1DF16B2B704C8A578D0B)
  vMerkleTree: 4a5e1e

Ce bloc pèse très exactement 285 octets. Le voici représenté en hexadécimal brut :

0100000000000000000000000000000000000000000000000000000000000000000000003ba3edfd7a7b12b27ac72c3e67768f617fc81bc3888a51323a9fb8aa4b1e5e4a29ab5f49ffff001d1dac2b7c0101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff4d04ffff001d0104455468652054696d65732030332f4a616e2f32303039204368616e63656c6c6f72206f6e206272696e6b206f66207365636f6e64206261696c6f757420666f722062616e6b73ffffffff0100f2052a01000000434104678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5fac00000000

Le bloc de genèse est composé d'un entête de 80 octets et d'une unique transaction, la transaction de récompense. Son identifiant (le résultat du hachage de l'entête par double SHA-256) est 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f. Les zéros qui débutent cet identifiant indiquent qu'une preuve de travail a été réalisée.

Notez que les différentes informations contenues dans le bloc sont souvent transmises avec un ordre des octets inverse (dit « little-endian » ou « petit-boutiste »). Nous donnerons ici les informations dans l'ordre ordinaire (qu'on appelle « big-endian » ou « gros-boutiste ») à l'aide du préfixe 0x.

 

L'entête

Comme tous les blocs dans le protocole, le bloc de genèse possède un entête donnant 6 informations différentes. Voici cet entête en détail :

01000000 - version
0000000000000000000000000000000000000000000000000000000000000000 - identifiant du bloc précédent
3ba3edfd7a7b12b27ac72c3e67768f617fc81bc3888a51323a9fb8aa4b1e5e4a - racine de Merkle
29ab5f49 - horodatage
ffff001d - valeur cible
1dac2b7c - nonce

 

La version du bloc

0x00000001

La version du bloc indique l'ensemble des règles respectées par le bloc. Cette version 1 indiquait un respect des règles du protocole originel défini par Satoshi. D'autres versions ont été introduites plus tard : la version 2 pour l'application du BIP-34 en mars 2013, la version 3 pour l'activation du BIP-66 en juillet 2015, et la version 4 pour celle du BIP-65 en décembre 2015. Le champ de version a par la suite été utilisé pour que les mineurs signalent leur intention d'appliquer un soft fork (conformément au BIP-9).

 

L'identifiant du bloc précédent

0x0000000000000000000000000000000000000000000000000000000000000000

Puisqu'il s'agit du premier bloc de la chaîne, le champ utilisé pour donner l'identifiant du bloc précédent est fixé à zéro par convention.

 

La racine de Merkle

0x4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b

La racine de Merkle correspond à l'empreinte finale de l'arbre de Merkle des transactions. Puisqu'il n'y a qu'une seule transaction dans le bloc de genèse, il s'agit simplement de l'identifiant de cette transaction.

 

L'horodatage

0x495fab29

L'horodatage indique la date et l'heure à laquelle le mineur a trouvé le bloc. Il est donné par le nombre de secondes depuis le 1^er janvier 1970 00:00:00 UTC. Ici, le nombre correspond à 1 231 006 505 secondes : le bloc de genèse est donc horodaté au 3 janvier 2009 à 18:15:05 UTC.

Toutefois, il ne faut pas croire que cet horodatage indique l'instant précis du lancement effectif du réseau. Ce dernier a en effet été réalisé un peu plus tardivement : le bloc 1 est ainsi horodaté au 9 janvier 2009 à 02:54:25 UTC, soit 5 jours, 8 heures, 39 minutes et 20 secondes plus tard.

 

La valeur cible

0x1d00ffff

La valeur cible est la valeur minimale que l'identifiant du bloc peut avoir pour que ce dernier constitue une solution au problème de preuve de travail de Bitcoin. Moins cette valeur cible est haute, plus il est facile de trouver une solution et de miner un bloc. Elle est donc inversement proportionnelle à la difficulté du réseau.

La valeur cible du bloc de genèse correspond à la plus grande valeur possible dans Bitcoin, ou la difficulté la plus basse pour le dire autrement. Elle est encodée comme un nombre flottant où le premier octet représente un exposant et où la mantisse est déterminée par les 3 octets suivants. Ici, elle est égale à 0x00ffff × 256(0x1d - 3) c'est-à-dire 0x00000000ffff0000000000000000000000000000000000000000000000000000.

La preuve de travail du bloc est valide car l'identifiant est effectivement (largement) inférieur à cette valeur cible :

0x000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f ≤
0x00000000ffff0000000000000000000000000000000000000000000000000000

On définit la difficulté du minage comme l'inverse de la valeur cible multipliée par la valeur cible de base :

difficulté = cible_de_base / cible

La difficulté du bloc de genèse est donc de 1.

Après le lancement du réseau, la difficulté a stagné à ce niveau pendant près d'un an avant d'enfin commencer à augmenter le 30 décembre 2009.

Au sein du code, le champ de la valeur cible est appelé nBits, car ce paramètre désignait (avant que Satoshi n'en modifie le sens) le nombre de bits de tête à mettre à zéro pour que la solution soit valide. Dans la version de novembre 2008, le champ était en effet fixé à 20, ce qui correspondait à 5 zéros de tête en représentation hexadécimale, soit une valeur cible de 0x00000fffff....

 

Le nonce

0x7c2bac1d

Le nonce (mot qui provient de l'expression anglaise « for the nonce » signifiant « pour la circonstance, pour l'occasion ») désigne le nombre que le mineur fait varier pour calculer la preuve de travail. Il n'a aucune signification particulière, étant déterminé au hasard.

 

L'ensemble des transactions

L'ensemble des transactions forme la seconde partie du bloc. Le voici en détail :

01 - nombre de transactions
01000000 - version
01 - nombre d'entrées
0000000000000000000000000000000000000000000000000000000000000000 - identifiant de transaction de la sortie précédente
ffffffff - index de la sortie précédente
4d - taille du script de déverrouillage
04ffff001d0104455468652054696d65732030332f4a616e2f32303039204368616e63656c6c6f72206f6e206272696e6b206f66207365636f6e64206261696c6f757420666f722062616e6b73 - script de déverrouillage
ffffffff - numéro de séquence
01 - nombre de sorties
00f2052a01000000 - montant
43 - taille du script de verrouillage
4104678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5fac - script de verrouillage
00000000 - temps de verrouillage

 

Le nombre de transactions

0x01

Le bloc contient une seule transaction : la transaction de récompense qui rémunère le mineur (ici Satoshi) pour la preuve de travail réalisée. Le bloc ne comporte ainsi aucune autre transaction, tout comme les blocs minés dans les premiers jours. Il a fallu attendre le 12 janvier et le bloc 170 pour voir la première transaction effective du réseau être confirmée : celle entre Satoshi et Hal Finney.

Toutes les données restantes du bloc appartiennent à la transaction de récompense.

 

La version de la transaction

0x00000001

La version de la transaction indique comment celle-ci doit être interprétée. Elle est fixée à 1 conformément au protocole initial. Aujourd'hui, il existe également une version 2 qui autorise l'usage des verrous temporels relatifs (voir BIP-68).

 

Le nombre d'entrées de la transaction

0x01

La transaction contient une seule entrée : la base de pièce, ou coinbase, qui permet de créer ex nihilo les nouveaux bitcoins et de recueillir les frais de transaction. Cette entrée est donc purement superflue, mais permet de conserver une certaine cohérence dans l'implémentation logicielle. Elle est constituée des champs identifiant la sortie précédente (théorique), d'un script de déverrouillage et d'un numéro de séquence.

 

L'identifiant de transaction de la sortie précédente

0x0000000000000000000000000000000000000000000000000000000000000000

Ce champ est utilisé dans les transactions pour dire à quel sortie transactionnelle correspond une entrée, en donnant l'identifiant de la transaction qui a créé la sortie. Puisqu'il s'agit d'une transaction de récompense qui ne fait pas référence à une sortie transactionnelle précédente, ce champ est fixé à 0 par convention.

 

L'index de la sortie précédente

0xffffffff

Ce champ est utilisé dans les transactions pour dire à quel sortie transactionnelle correspond une entrée, en donnant la position de la sortie dans la transaction qui l'a créée. Puisqu'il s'agit d'une transaction de récompense qui ne fait pas référence à une sortie transactionnelle précédente, ce champ est fixé au maximum par convention.

 

Le script de déverrouillage (scriptSig)

0x04ffff001d0104455468652054696d65732030332f4a616e2f32303039204368616e63656c6c6f72206f6e206272696e6b206f66207365636f6e64206261696c6f757420666f722062616e6b73

Dans Bitcoin, le script de déverouillage est combiné à un script de verrouillage précédent et détermine la validité d'une dépense. Il contient généralement les signatures nécessaires à la dépense d'une pièce et est par conséquent souvent appelé scriptSig. Dans le cas d'une transaction de récompense, l'entrée ne fait référence à aucune sortie transactionnelle existante et ce script peut donc contenir des données arbitraires.

Ici, le script se présente de la manière suivante :

<valeur cible> <nonce supplémentaire> <chaîne de caractères>

Ainsi, il est constitué de trois informations :

• Tout d'abord, la valeur cible du bloc, donnée en sens inverse, conformément à la façon dont elle est représentée dans le code : 0xffff001d
• Ensuite, un nonce supplémentaire (0x04), ou extra nonce, mis en place par Satoshi dans le code du logiciel. Le nonce supplémentaire du bloc de genèse a pour valeur 4, et ceux des blocs suivants sont croissants : celui du bloc 1 est aussi égal à 4, celui du bloc 2 à 11, celui du bloc 3 à 14, etc. La variation de ce nonce supplémentaire au sein des blocs a permis de mettre en évidence un motif particulier, appelé le « Patoshi Pattern », qui détermine précisément les blocs minés par Satoshi et qui démontre que sa fortune s'élève à plus de 1 125 150 bitcoins.
• Enfin, une chaîne de caractères aujourd'hui emblématique, encodée en UTF-8, qui est :

  The Times 03/Jan/2009 Chancellor on brink of second bailout for banks

  Cette courte phrase correspond à la une du Times du 3 janvier 2009, qui annonçait que le ministre des finances du Royaume-Uni était sur le point de renflouer les banques pour la deuxième fois. Le Times étant un quotidien anglais, cela a mené à des spéculations quant à l'identité de Satoshi, qui écrivait également dans un anglais britannique.

Cette phrase présente dans le script de la transaction de récompense possède un rôle double :

• Premièrement, elle prohibe l'antidatage : sa présence dans le premier bloc, à partir duquel toute la chaîne est construite, prouve que le réseau de Bitcoin n'a pas été lancé avant le 3 janvier 2009. Cependant, cela ne veut pas dire que le bloc de genèse date bien du 3 janvier : en effet, il a pu être construit entre le 3 janvier (date de l'horodatage déclaré) et le 8 janvier (date de publication du code).
• Deuxièmement, elle indique symboliquement ce à quoi Bitcoin s'oppose en faisant référence au contexte monétaire et financier de l'époque : le renflouement des grandes banques d'investissement par les États et par les banques centrales suite à la crise financière de 2007-2008. Il est d'ailleurs possible que Satoshi ait choisi cette date précisément pour sélectionner cette une.

Ce script de la base de pièce est encore utilisé de nos jours par les mineurs pour de multiples raisons. À l'instar de Satoshi, ils peuvent inclure des informations arbitraires dans le bloc et faire passer un message public au monde. Ç'a été le cas de la coopérative F2Pool qui, le 11 mai 2020, a évoqué l'injection de liquidité de la Réserve Fédérale en réaction à la crise du covid-19 au sein du bloc 629 999 (le bloc précédant le troisième halving) :

NYTimes 09/Apr/2020 With $2.3T Injection, Fed's Plan Far Exceeds 2008 Rescue

Les regroupements de mineurs peuvent également s'identifier en indiquant leur nom, ce qui permet de juger de la décentralisation du réseau, même si cette pratique reste purement déclarative.

Enfin, les mineurs se servent encore de ce champ pour faire varier un nonce supplémentaire, le nonce de l'entête ne permettant plus depuis 2012 d'essayer suffisamment de possibilités par rapport à la difficulté élevée du réseau.

 

Le numéro de séquence (nSequence)

0xffffffff

Le numéro de séquence de l'entrée est maximal, ce qui fait que la transaction est considérée comme finale.

À l'origine, le numéro de séquence dans les entrées avait pour objectif de permettre les échanges répétés au sein de contrats, tels que les canaux de paiement. Ce modèle imaginé par Satoshi n'était pas suffisamment sécurisé et a par conséquent été abandonné. Cependant, la règle de finalité, qui fait que la transaction est considérée comme finale (pas de temps de verrouillage) si les numéros de séquence de toutes les entrées sont maximaux (comme ici), a été conservée.

Aujourd'hui, ce numéro de séquence est utilisé pour déterminer le temps de verrouillage relatif d'une entrée et pour signaler Replace-by-Fee.

 

Le nombre de sorties de la transaction

0x01

La transaction contient une seule sortie, celle créditant Satoshi de son revenu de minage. Cette sortie est constituée d'un montant et d'un script de verrouillage.

 

Le montant

0x000000012a05f200

Le montant de la sortie est donné dans la plus petite unité du système, unité qu'on a appelé le satoshi en hommage au créateur de Bitcoin. Ce montant correspond ici à 5 milliards de satoshis, soit 50 bitcoins. Il s'agit de la limite maximale du taux de création monétaire de l'époque (50 bitcoins par bloc).

 

Le script de verrouillage (scriptPubKey)

0x4104678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5fac

Le scrpt de verrouillage est l'ensemble des conditions à fournir pour pouvoir dépenser la pièce correspondante. Ici, il possède la forme :

<clé publique> CHECKSIG

où la clé publique est 04678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5f. Il s'agit donc d'une sortie transactionnelle de type Pay to Public Key (P2PK), un schéma utilisé dans les débuts de Bitcoin, qui demande une simple signature pour débloquer les fonds. Cela explique le nom donné couramment à ce script : scriptPubKey.

Bien souvent, cette sortie est rétrospectivement attribuée à l'adresse 1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa, obtenue en prenant l'empreinte de la clé publique. Cela est néanmoins purement esthétique car c'est bien la clé publique elle-même qui a servi à recevoir les bitcoins, pas l'adresse.

Fait intéressant : cette sortie transactionnelle n'est pas considérée comme dépensable par le protocole en raison de la façon dont le bloc de genèse est exprimé dans le code. Cette erreur de programmation pourrait être corrigée par un hard fork, mais cela ne serait ni utile (Satoshi n'a pas touché à ses bitcoins depuis qu'il a disparu), ni même souhaitable (incompatibilité du protocole). Les 50 premiers bitcoins créés sont donc probablement brûlés à tout jamais.

 

Le temps de verrouillage (nLocktime)

0x00000000

Le temps de verrouillage (donnée globale appartenant à la transaction) détermine la date à partir de laquelle cette transaction pourra être confirmée. En étant fixé à zéro, celui-ci est désactivé.

 

Les autres chaînes

Si le bloc de genèse constitue un fondement du protocole Bitcoin, il sert également de base aux différentes branches minoritaires de Bitcoin qui possèdent le même historique jusqu'à leurs scissions respectives : Bitcoin Cash, Bitcoin SV, Bitcoin Gold ou encore eCash/XEC. D'autres protocoles possèdent leur propre bloc de genèse et certains d'entre eux ont également incorporé la une d'un journal ou d'un magazine pour garantir que le lancement du réseau ne s'est pas réalisé avant la date donnée. Ainsi, le bloc de genèse de Litecoin (datant du 7 octobre 2011) contient la phrase suivante :

NY Times 05/Oct/2011 Steve Jobs, Apple’s Visionary, Dies at 56

Celui de Dash (datant du 19 janvier 2014) inclut la une suivante :

Wired 09/Jan/2014 The Grand Experiment Goes Live: Overstock.com Is Now Accepting Bitcoins

 

---

Source

Bitcoin Wiki, Genesis block

Le Conseil National du Numérique a publié lundi la synthèse de ses travaux sur les « identités numériques » comme « clés de voûte de la citoyenneté numérique ». Le groupe de travail, composé de Karine Dognin-Sauze, Mohammed Boumediane, Jean-Michel Mis, Gilles Babinet, Olivier Clatz et Gaël Duval, a conduit ses travaux de janvier 2019 à mars 2020 et a présenté son rapport à Cédric O, Secrétaire d’Etat chargé du numérique.

Nous relevons avec intérêt que le CNNum plaide pour « offrir des moyens de vérification d’informations sans diffusion des données d’identité des citoyens à travers des solutions s’appuyant sur le zero knowledge proof » (ZKP).

Les ZKP sont effectivement très prometteuses dans le cadre de l’identité numérique : c’est le sens de nos travaux de R&D sur le sujet, entamés l’an dernier et présentés dans notre synthèse intitulée « Vers une identité numérique private by design ».

Le sujet est particulièrement d’actualité avec le débat autour du contrôle de l’âge concernant les sites pour adultes, qui a été approuvé par l’Assemblée nationale et le Sénat. La question de la méthode de vérification de l’âge peut se prêter à l’exploration des ZKP.

L’exemple britannique a montré que cette volonté de contrôler l’âge des visiteurs des sites pornographiques est condamnée à rester un vœu pieux tant qu’elle n’est pas accompagnée d’une solution technique crédible pour préserver la confidentialité des internautes. Les ZKP, couplées aux technologies blockchain, pourraient répondre à ce problème : à tout le moins, elles mériteraient d’être étudiées et testées comme solution potentielle.

Nous sommes donc heureux de constater que les réflexions autour de l’usage des ZKP pour l’identité essaiment, et espérons pouvoir approfondir et mettre en pratique ces travaux au cours des prochains mois, comme nous avons commencé à le faire avec certains acteurs publics. Nous sommes à disposition pour avancer sur le sujet.

***

Ci-dessous, retrouvez le passage entier du rapport du CNNum sur l’usage des ZKP pour l’identité numérique (page 89 du document) :

« Afin que l’identité numérique réponde aux besoins des citoyens en termes de protection de la vie privée, et pour qu’elle puisse faire émerger des nouveaux usages respectueux, celle-ci doit pouvoir offrir des moyens de vérification d’information sans une diffusion complète des données d’identité des citoyens à travers des solutions s’appuyant sur le zero knowledge proof (ZKP, en français : preuve à divulgation nulle de connaissance). Il s’agit d’un prérequis pour répondre au principe de proportionnalité et à l’idée de frugalité des données.

En effet, le choix d’inclure ce type de technologies dans l’identité numérique permettrait d’améliorer le rapport de confiance qu’ont les individus à l’identité numérique, répondant aux craintes de surveillance et au nécessaire besoin d’espace de vie privée. Combiné à une CNIe, l’utilisation du ZKP permettrait aux usagers d’accéder à certains services sans avoir à donner l’ensemble de leur identité, qui est une information non pertinente pour l’usage visé. Par exemple, obtenir des tarif d’accès préférentiels aux équipements sportifs pour les habitants d’une collectivité locale sans avoir à révéler l’ensemble de leurs données d’identité. »

Le Conseil National du Numérique a publié lundi la synthèse de ses travaux sur les « identités numériques » comme « clés de voûte de la citoyenneté numérique ». Le groupe de travail, composé de Karine Dognin-Sauze, Mohammed Boumediane, Jean-Michel Mis, Gilles Babinet, Olivier Clatz et Gaël Duval, a conduit ses travaux de janvier 2019 à mars 2020 et a présenté son rapport à Cédric O, Secrétaire d’Etat chargé du numérique.

Nous relevons avec intérêt que le CNNum plaide pour « offrir des moyens de vérification d’informations sans diffusion des données d’identité des citoyens à travers des solutions s’appuyant sur le zero knowledge proof » (ZKP).

Les ZKP sont effectivement très prometteuses dans le cadre de l’identité numérique : c’est le sens de nos travaux de R&D sur le sujet, entamés l’an dernier et présentés dans notre synthèse intitulée « Vers une identité numérique private by design ».

Le sujet est particulièrement d’actualité avec le débat autour du contrôle de l’âge concernant les sites pour adultes, qui a été approuvé par l’Assemblée nationale et le Sénat. La question de la méthode de vérification de l’âge peut se prêter à l’exploration des ZKP.

L’exemple britannique a montré que cette volonté de contrôler l’âge des visiteurs des sites pornographiques est condamnée à rester un vœu pieux tant qu’elle n’est pas accompagnée d’une solution technique crédible pour préserver la confidentialité des internautes. Les ZKP, couplées aux technologies blockchain, pourraient répondre à ce problème : à tout le moins, elles mériteraient d’être étudiées et testées comme solution potentielle.

Nous sommes donc heureux de constater que les réflexions autour de l’usage des ZKP pour l’identité essaiment, et espérons pouvoir approfondir et mettre en pratique ces travaux au cours des prochains mois, comme nous avons commencé à le faire avec certains acteurs publics. Nous sommes à disposition pour avancer sur le sujet.

***

Ci-dessous, retrouvez le passage entier du rapport du CNNum sur l’usage des ZKP pour l’identité numérique (page 89 du document) :

« Afin que l’identité numérique réponde aux besoins des citoyens en termes de protection de la vie privée, et pour qu’elle puisse faire émerger des nouveaux usages respectueux, celle-ci doit pouvoir offrir des moyens de vérification d’information sans une diffusion complète des données d’identité des citoyens à travers des solutions s’appuyant sur le zero knowledge proof (ZKP, en français : preuve à divulgation nulle de connaissance). Il s’agit d’un prérequis pour répondre au principe de proportionnalité et à l’idée de frugalité des données.

En effet, le choix d’inclure ce type de technologies dans l’identité numérique permettrait d’améliorer le rapport de confiance qu’ont les individus à l’identité numérique, répondant aux craintes de surveillance et au nécessaire besoin d’espace de vie privée. Combiné à une CNIe, l’utilisation du ZKP permettrait aux usagers d’accéder à certains services sans avoir à donner l’ensemble de leur identité, qui est une information non pertinente pour l’usage visé. Par exemple, obtenir des tarif d’accès préférentiels aux équipements sportifs pour les habitants d’une collectivité locale sans avoir à révéler l’ensemble de leurs données d’identité. »

L’article Identités numériques : le CNNum soutient l’usage des ZKP est apparu en premier sur Blockchain Partner.