Comment fonctionne les transactions bitcoins pour les nuls.

Comprendre comment fonctionne le système de transactions des bitcoins n'est pas simple, on trouve bien ce schéma sur zerohedge qui a le mérite de faire une bonne synthèse mais ne s'adresse pas exactement à des "nuls". Je me propose donc de le faire ici, car je suis aussi un "nul".

Lorsque je parle de bitcoins avec mes amis l'idée d'une monnaie virtuelle ne plait pas beaucoup, parce que c'est virtuelle justement. J'ai souvent pas trop de mal à contrecarrer cet argument en expliquant que finalement une monnaie papier est tout aussi virtuelle, c'est une norme imposée par une banque centrale et qu'à tout moment on risque une très grosse inflation, si cette banque a envie de faire marcher son imprimerie.

Prenons l'or ou l'argent, bitcoins est beaucoup plus proche de ces valeurs d'échanges que ne pourrait l'être l'euro ou le dollar. Aucune banque ne peut émettre artificiellement de l'or. Si on veut mettre plus d'or sur le marché il faut le sortir des mines et de toute façon les ressources sont physiquement limités par les réserves naturelles de la planète, plus ça va plus obtenir de l'or devient dur.

Et bien bitcoins suit exactement cette règle. Il s'agit de séquences numériques obéissant à des propriétés mathématiques particulières qui font qu'elles sont  limitées en nombre (21 millions de séquences possibles) et plus ça va plus c'est difficile à trouver.

A ce stade vous me direz qu'à la différence de l'or le bitcoin n'est qu'une séquence numérique, je n'ai qu'à faire un copier coller. Avec de l'or ou de l'argent (ou avec sa copine) on ne peut pas faire de copier coller. Comment est-ce qu'on garantit que quelqu'un n'envoie pas deux fois le même bitcoins à des personnes différentes ?

Et bien c'est ici qu'intervient ce que l'on appelle le journal des transactions, à chaque fois que vous versez un bitcoins à quelqu'un vous le déclarez à tout le réseau et tous les nœuds l'enregistrent dans leur journal de transaction. Finalement le bénéficiaire du bitcoin recevra des confirmations des autres membres du réseau lui signifiant que cette transaction est valide.

Si par exemple le noeud 1 après avoir envoyé des bitcoins au noeud 2 tente d'envoyer maintenant les mêmes bitcoins au noeud 3 il pourra le faire mais cette transaction ne sera pas validée par les autres noeuds qui dans leur journal de transaction auront enregistré que les bitcoins sont bien en possessions du noeud 2 et ne peuvent donc plus être transférés depuis le noeud 1.

En fait si le noeud 3 a un journal de transaction à jour il pourra lui-même invalider ce transfert car il pourra y lire que le noeud 1 a déjà donné ces bitcoins au noeud 2.

Oui mais là vous pourriez m'opposer cet argument : qui détient la vérité ? Comme nous sommes sur un système décentralisé chacun maintient le journal des transaction. N'oublions pas que c'est le journal de toutes les transactions ! Tout les échanges qui ont pu avoir lieu depuis la création du bitcoin sont enregistrés dans ce journal.  Donc ça pèse assez lourd sur un PC ...

Dans cette capture vous constatez que mon journal fait bientôt 8 Go ...

Et puis encore une autre question : si le logiciel est hors ligne pendant trois mois, comment remet-il à jour son journal quand il revient en ligne.

Ici mon client bitcoins remet son journal des transactions à jour, il a 11 semaines de retards.

Et bien la réponse à ces deux questions (qui détient la vérité et comment un journal de transactions est-il mis à jour) est la même : c'est celui qui à la plus longue qui a raison !

Non non, ça n'est pas ce que vous croyez, quand je parle de la plus longue, je parle évidemment de la longueur du journal des transactions. Ce journal de transaction est plus connus sous le nom de chaîne de blocks. Donc celui qui a raison est celui qui a la chaîne de blocks la plus longue. Et quand un client doit se remettre à jour il recopie la chaîne de blocks la plus longue disponible sur le réseau.

A ce stade on peut se poser deux questions : pourquoi des chaines de blocks, et pourquoi la plus longue est-elle la gagnante ?

On parle de chaine blocks parce que les transactions ne sont pas ajoutées une à une au journal des transactions mais elles sont regroupées en blocks et sont ensuite intégrées au journal de transaction.

Mais ce processus d'intégration du block est un processus qui exige de la puissance processeurs et surtout qui peut être fait collectivement. Ainsi 10 processeurs répartis sur le réseau travaillant collectivement à l'intégration d'un block ira plus vite que 5 processeurs ayant les mêmes caractéristiques. Ce qui nous amène à ceci : s'il y a plus de gens honnêtes qui travaillent pour intégrer des blocks que de gens malhonnêtes alors la chaîne de blocks qui détient la vérité sera la plus longue ...

Pour ne pas aider ceux qui serait tenter de "réécrire l'histoire des transactions", l'intégration d'un block dépend toujours du block précédent.

Supposons que je sois un pirate qui décide de réécrire l'histoire des transactions et que je décide de changer une transaction située dans le bloc b3.

Je ne devrai pas seulement refaire l'intégration de b3 à la chaine mais aussi de b4, b5 et b6, ce qui va exiger du temps et de la ressource. Pendant ce temps les nœuds honnêtes continue d'ajouter des blocks, ils sont donc toujours en mesure de présenter une chaîne plus longue que celle je tente péniblement de réécrire.

En fait on montre que la probabilité qu'un pirate rattrape les blocks diminue exponentiellement a chaque bloc de retard. Et pendant que le bénéficiaire attend les validations de nouveaux blocks sont ajoutés.

Mais alors comment sont rémunérés ceux qui valident les blocks. Et bien vous pouvez accélérer les validations en intégrant des frais de transactions, le nœud qui aura intégré votre transaction dans la chaîne recevra ces frais.

Pour conclure on a un système qui est garanti par une information faisant autorité sans que cette information soit garantie par une autorité. C'est quelque chose de complètement nouveau qui n'a pas de précédent dans l'histoire.

Transformation vs Job in kettle

When I started to learn kettle I bump into two keywords : Job and Tranformation. And I was unable discriminate bettwen the two.

 Transformation is about managing a flow of column. By managing I mean getting it from an output like a csv file, adding new columns, transforming their values or assigning values, doing cartesian product, removing etc to finally send them to an output like a table in a database.

 Here is an example in the Spoon IDE of a transformation that load a dimension table:
A transformation is made of steps (max_dim_staff_last_update, Staff, Select values ...) that alterate the flow of columns.

Job manage the transformations. A job is made of  transformations. The job define in wich order the transformation are going to be called. For instance you first need to update all the dimensions tables before updating the facts table in an olap cube. Here is a Job in the Spoon IDE, you can notice that all the dims are loaded before the facts :

Another difference is about the flow of data. In a transformation when a line is done in a step, it's passed to the next step and doen't wait that all the lines are done. But in a Job the data is passed from a transformation to the next when all the lines in the previous transformations are treated.

Actually, often no data are passed from a transformation to another. For instance nothing is passed from load_dim_staff to load_dim_customer.