Actu-crypto

🔒
❌ About FreshRSS
There are new articles available, click to refresh the page.
☐ ☆ ✇ Comprendre la cryptomonnaie

Le bloc de genĂšse de Bitcoin

By: Ludovic Lars —

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. »

Bloc de genĂšse embranchements

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 1er 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.

The Times 3 janvier 2009 chancelier ministre des finances renflouement des banques

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

☐ ☆ ✇ Blockchain Partner

Découvrez quatre services de la DeFi à travers le démonstrateur CoFinance

By: blockchainpartner —

Nouveau systĂšme financier basĂ© sur les technologie blockchain et les cryptoactifs, la finance dĂ©centralisĂ©e (DeFi, pour Decentralized Finance en anglais) offre une alternative numĂ©rique au systĂšme traditionnel, qu’elle vient Ă  la fois complĂ©ter et concurrencer.

CaractĂ©risĂ© par sa modularitĂ©, ce systĂšme se compose de multiples services centrĂ©s sur des besoins spĂ©cifiques (Ă©changes de crypto-actifs, stablecoins, prĂȘts, produits dĂ©rivĂ©s, fonds d’investissement, marchĂ©s prĂ©dictifs
) qui se combinent les uns avec les autres faisant ainsi Ă©merger de nouveaux usages chez les clients.

Au mois de Juin 2021, 60 milliards de dollars sont gĂ©rĂ©s par les smart-contracts et applicatifs de la DeFi, en progression exponentielle de 6000% par rapport Ă  l’annĂ©e derniĂšre. On y retrouve  dĂ©jĂ  des services sur toutes les verticales financiĂšres existantes. Le nombre d’utilisateurs a grimpĂ© de 0,2 Ă  2,5 millions en 1 an, ne reprĂ©sentant encore que 2% des dĂ©tenteurs de cryptoactifs dans le monde. 

Convaincus de la dimension stratĂ©gique de cette transformation et Ă  l’image d’acteurs comme BNY Mellon, Morgan Stanley, JP Morgan, StateStreet ou Citi qui ont fait part de leur volontĂ© de proposer des services relatifs Ă  la DeFi, Blockchain Partner by KPMG se positionne sur cette industrie Ă©mergente avec un dĂ©monstrateur agrĂ©geant 4 des principales solutions actuelles de la DeFi.

Co.Finance agrĂšge 4 des principales solutions DeFi : Uniswap (Echange dĂ©centralisĂ©), Aave (PrĂȘts et emprunts), Yearn finance (Fond d’investissement) et Unslashed finance (Assurance)

Actuellement, la multiplication des projets rend l’agrĂ©gation de plusieurs solutions nĂ©cessaire afin d’identifier les meilleures opportunitĂ©s, d’optimiser les frais et de limiter les risques en favorisant la diversification de portefeuille. Notre objectif est d’aider les dĂ©cideurs Ă  comprendre les enjeux liĂ©s Ă  l’essor de la DeFi en construisant une solution permettant de contrĂŽler et de gĂ©rer ses actifs numĂ©riques depuis une seule et mĂȘme interface.

Le Dashboard de Co.Finance permet de monitorer et gérer ses investissements et positions en une seule interface

En outre, les projets blockchain et crypto, plus que jamais, ont besoin d’asseoir leur lĂ©gitimitĂ© et leur crĂ©dibilitĂ© face aux acteurs traditionnels. Un des challenges pour faciliter l’adoption de ces solutions est de proposer des interfaces facilement intelligibles, qui masquent  la complexité  lexicale et technique inhĂ©rente aux  blockchains. Ainsi, l’interface de Co.Fi a Ă©tĂ© pensĂ©e pour ĂȘtre intuitive, sĂ©curisante et agrĂ©able Ă  utiliser au quotidien, dans le but de rendre cet Ă©cosystĂšme plus accessible en simplifiant l’UX au maximum.

Pour approfondir ces enjeux, venez dĂ©couvrir notre dĂ©monstrateur Ă  Vivatech sur le stand de KPMG, ou contactez-nous Ă  l’adresse suivante : cbalva@kpmg.fr

☐ ☆ ✇ Blockchain Partner

Blockchain Partner rejoint les Ă©quipes de KPMG France

By: blockchainpartner —

Cinq ans jour pour jour aprÚs la fondation de Blockchain Partner (15/03/2016), les équipes dirigées par Claire Balva, Présidente, Alexandre Stachtchenko, Directeur Général et Maxime Hagenbourger, Directeur technique, rejoignent les équipes de KPMG France pour former la référence du conseil blockchain et crypto-actifs.

En cinq ans, le marchĂ© des blockchains et cryptomonnaies a considĂ©rablement Ă©voluĂ© : aprĂšs une large phase de dĂ©couverte et d’expĂ©rimentations par les organisations, les projets impliquant des briques “blockchain” nĂ©cessitent de plus en plus d’expertises sectorielles pointues dans les divers domaines oĂč ces innovations se dĂ©veloppent (finance, assurance, industrie, distribution, immobilier, etc.). Nos clients sont de plus en plus demandeurs d’accompagnement en droit, fiscalitĂ© et gestion des risques tout au long de leurs projets. De façon logique, Ă  mesure que les usages des blockchains se dĂ©ploient et que les cryptomonnaies se font une place au sein des entreprises, la palette des compĂ©tences recherchĂ©es s’élargit.

Pour pouvoir rĂ©pondre au mieux Ă  ces besoins, nous avons dĂ©cidĂ© de nous allier Ă  KPMG France, leader de l’audit et du conseil.

Cette intĂ©gration nous permet en effet d’enrichir considĂ©rablement notre offre de services. Les expertises sectorielles sur lesquelles s’appuie KPMG France seront prĂ©cieuses pour accĂ©lĂ©rer le dĂ©ploiement de ces technologies dans les logiques « mĂ©tiers », au plus prĂšs des besoins existants des organisations. Par ailleurs, KPMG France dispose d’une expertise juridique et fiscale largement reconnue, qui profitera Ă  nos clients existants et Ă  venir.

Au-delĂ  de nos complĂ©mentaritĂ©s d’expertises, nous partageons avec KPMG France une vision commune de l’évolution de ce marchĂ©, qui n’en est qu’à ses dĂ©buts. La crypto-Ă©conomie, dont les usages restent encore Ă©mergents mais en forte croissance, constitue une vague d’innovations de grande ampleur qui rebat les cartes de l’économie numĂ©rique et ouvre la voie Ă  de multiples opportunitĂ©s.

☐ ☆ ✇ Blockchain Partner

Webinar Blockchain & Assurance

By: blockchainpartner —

Suite au succÚs de nos précédents webinars (Gaming, Immobilier, DeFi), Blockchain Partner organise le 24 novembre 2020 à 11h un webinar (gratuit) à destination des assureurs, sur le sujet blockchain & cryptoactifs.

Au programme : 

1- Comprendre les blockchains et les cryptoactifs
2- Exemples d’applications blockchain pour l’assurance : assurance indicielle, assurance P2P, polices d’assurance tokenisĂ©es, marchĂ©s prĂ©dictifs
3- Assurer les nouveaux risques liés aux cryptoactifs : un nouveau marché pour le secteur assurantiel
4- Questions & Réponses  

Le webinar aura lieu sur Google Meet. Le nombre de places étant limité, inscrivez-vous pour y participer !

☐ ☆ ✇ Blockchain Partner

IdentitĂ©s numĂ©riques : le CNNum soutient l’usage des ZKP

By: blockchainpartner —

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Ă©. »

☐ ☆ ✇ Blockchain Partner

IdentitĂ©s numĂ©riques : le CNNum soutient l’usage des ZKP

By: Blockchain Partner —

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.

❌