Un vendredi sur deux

Block Chain (Part 2)

Block Chain

Dans la suite de la précédente journée, je continue à creuser du côté de la BlockChain. L’objectif est de continuer ce que j’ai initié la dernière fois en regardant les Smart Contract : mettre un peu les mains dans le cambouis pour mieux appréhender les choses. Bon, je pense que cela va commencer par pas mal de lecture :)

Liens

Définitions et autres …

Différence entre BlockChain et Distributed Ledger

Un point que je n’avais pas forcément vu la dernière fois : le lien entre Block Chain et “Distributed Ledger”. En fait, l’un est un sous-ensemble de l’autre. Je trouve que le lien suivant présente bien les choses :

  • Distributed Ledger : registre distribué.Peut-être vu comme une base de données décentralisées et donc la gestion est répartie entre différentes entités,
  • Block Chain : un type de Distributed Ledger dans lequel des transactions sont liées entre elles sous la forme de bloc.

PermissionLess vs Permissioned

  • PermissionLess: n’importe qui peut participer au réseau. C’est le mode de fonctionnement d’Ethereum par exemple,
  • Permissioned: il faut d’abord être enregistré dans une autorité centrale (ou non) pour participer au réseau.

Le mode de fonctionnement va avoir un impact fort sur le mode de consensus. En effet, un stockage distribué implique de la confiance. Or comme vu dans la partie 1, il ne faut faire confiance à personne dans le cas d’un système PermissionLess. Dans un système où les acteurs sont connus, il est possible d’avoir un niveau de confiance minimum.

Différents types de protocoles de consensus

Une block chain fonctionne avec des blocs qui doivent être validés. La question : sur quelle règle valider un bloc. Pour ce faire, il existe différents types de protocole de consensus.

Proof of work

Le plus connu car celui utilisé par la block chain derrière le BitCoin. Pour valider la transaction et le bloc, un calcul assez complexe doit être effectué. Le premier a gagné et le bloc est validé. Gourmand en ressource forcément …

Proof of Stake / Preuve d’enjeu

L’utilisateur doit prouver sa participation au système. Par exemple, les utilisateurs possédant le plus de crypto-monnaie dans le système peuvent être priorisés. Moins gourmand en ressource, cette solution possède également des défauts :

  • ne met plus les nœuds sur un pied d’égalité,
  • ouvre la porte à une plus grande centralisation (les plus riches gagnent plus souvent et deviennent plus riche),
  • Risques en cas de différentes branches (vu que le calcul ne coûte rien: je calcul tout pour avoir plus de chance de gagner…)

Practical Byzantine Fault Tolerance

L’idée ici est de trouver un consensus entre les différents noeuds. Chacun effectue le calcul et un consensus est trouvé entre les différents noeuds sur la réponse valide. Ce système est également beaucoup moins gourmand en terme de calcul par contre il nécessite une gestion centralisée des noeuds au niveau de l’identification.

Federated Byzantine Agreement (FBA)

J’ai pas trop vu/compris la différence avec le mode précédent … Ici aussi, l’idée est d’avoir un consensus entre les différents participants. Ils doivent tous se connaitre et savoir qui est important ou pas… Et ici, certains nœuds vont attendre que les nœuds important trouve un consensus pour accepter ce choix.

Autres

Il en existe d’autres :

  • Preuve d’importance: similaire à la preuve d’enjeu mais pour éviter le centralisation, le protocole ajoute une notion de réputation,
  • Delegated Proof of Stake: inclue un système de vote entre les noeuds pour déterminer qui va sécuriser les informations,
  • Preuve d’activité: mélange de la preuve de travail et la preuve d’enjeu avec la combinaison des avantages et inconvénients,
  • …

Choix d’une chaîne … Pas facile …

Bon maintenant pour commencer à mettre les mains, il faudrait commencer à installer / déployer des choses … Souci : quel système choisir ? Après pas mal de lecture, j’hésite entre Ethereum & Hyperledger Fabric. Les deux systèmes ont des approches (à priori) différentes.

Au regard des lectures, je dirais qu’Ethereum dans sa version actuelle est plus pour les systèmes ouverts mais clés en main. Fabric serait plus pour un système privée mais à définir soit même …

Le point qui me gêne avec Ethereum, c’est le fait qu’il semble que chaque action dans la chaîne implique une consommation d’Ether qui est la monnaie donc implique une notion de paiement ce qui ne semble pas être le cas de Fabric par défaut …

Bon, je vais sûrement me tromper mais je vais commencer par regarder Fabric :)

Hyperledger Fabric

Début

J’ai passé pas mal de temps à lire les différentes infos sur le site du projet en essayant de suivre les étapes. Je ne trouve pas forcément la documentation bien balisée. J’ai fini par effectuer le lancement du premier réseau. La bonne nouvelle c’est que cela fonctionne au travers d’images Docker.

Lancement du réseau

Dans le cadre de l’exemple (first network), il faut lancer /byfn.sh -m up -l node . Par défaut, les “chaincode” sont en Go. Comme je suis plus à l’aise avec nodejs que go, j’indique que je préfère le faire en node … D’après la documentation, il y a tout un test E2E qui est effectué et après quelques minutes :

Pour info, le script qui permet de couper le réseau est (/byfn.sh -m down)… violent. Il semble arrêter toutes les autres images et faire le ménage dans les images …

Bilan

Pas simple tout cela :). La technologie semble très prometteuse mais elle met en œuvre des concepts assez éloignés de mon quotidien donc pas forcément évident de les appréhender rapidement. Maintenant pour continuer, il faudrait un support, une idée …