Pourquoi Git n'est-il pas considéré comme une «chaîne de blocs»?


174

La structure de données interne de Git est une arborescence d'objets de données, dans laquelle chaque objet pointe uniquement vers son prédécesseur. Chaque bloc de données est haché. En modifiant (erreur de bit ou attaque) un bloc intermédiaire sera remarqué lorsque le hachage enregistré et le hachage réel s'écartent.

En quoi ce concept est-il différent de la blockchain?
Git n'est pas répertorié comme un exemple de chaînes de blocs, mais au moins dans les résumés, les deux descriptions de structure de données se ressemblent: bloc de données, liaison inverse unidirectionnelle, hachages, ...).

Alors, où est la différence, que Git ne s'appelle pas une chaîne de blocs?


2
Git ne figure pas comme un exemple de chaînes de blocs Lorsque j'ai essayé d'apprendre ce qu'est un blockchain était, j'appelé git comme l'exemple le plus important (je n'ai pas le lien exact maintenant, mais il était de la partie supérieure de la liste retournée par la recherche Google pour "blockchain")
Leon

2
Git et blockchain utilisent tous deux des arbres de merkle comme structure de données sous-jacente fondamentale. Mais cela seul ne fait pas de Git une blockchain, ou l'inverse. - Si vous connaissez Git (et ses composants internes), vous connaissez les arbres de merkle, ce qui peut être une révélation très utile pour comprendre le fonctionnement des blockchains.
poke le

24
Chers électeurs proches, pouvez-vous expliquer vos raisons? Je vois 2 likes, de bons commentaires et une réponse. Pourquoi est-ce basé sur l'opinion? Il s'agit de structures de données et d'algorithmes, qui ne permettent pas de qualifier Git de chaîne de blocs.
Paebbels

2
Selon vous, "ce n'est PAS considéré ..." bitcoin.stackexchange.com/a/43627/77469
v.oddou

4
@ v.oddou Les arbres Merkle existent depuis 1979. Ce n'est pas parce que deux technologies utilisent les arbres Merkle en évidence dans leur concept que cela ne les rend pas identiques. Il est incorrect de réduire soit Git, soit les chaînes de blocs aux arbres de merkle, car aucun d'eux n'est des arbres de merkle. Ils ne les utilisent que. Cela rend la publication liée totalement inutile car elle parle en fait d'arbres de merkle et non de chaînes de blocs.
poke le

Réponses:


53

git n'est pas un exemple de technologie blockchain pour plusieurs raisons (ce sont les premières qui me viennent à l'esprit):

  1. Dans une implémentation de blockchain, chaque bloc est vérifié indépendamment plusieurs fois avant d'être ajouté à la blockchain. C'est en effet l'un des éléments les plus importants de la technologie blockchain et c'est ce qui garantit son "non piratage". D'un autre côté, de nombreux gitprojets ne nécessitent pas de vérification indépendante et, lorsqu'ils le font, ils exigent qu'une seule personne approuve une modification avant qu'elle ne soit validée dans le référentiel. Par conséquent, avec au plus un point de validation auquel vous devez faire confiance, gitrompt l'un des principes fondamentaux de la technologie blockchain.

  2. Un gitréférentiel n'est pas nécessairement dupliqué sur de nombreux serveurs. Vous pouvez travailler à partir d'un gitréférentiel localement et si votre disque local était corrompu, vous perdriez tout. La technologie blockchain implique la reproduction du registre sur les serveurs.

  3. Vous pouvez réécrire l' githistoire. Un git push <remote> <branch> --forcewhere <branch>est défini sur un état antérieur à celui de <remote>réécrirait l'historique. Dans les blockchains, le grand livre est une histoire immuable.


104
"Dans les blockchains, le grand livre est une histoire immuable." - L'histoire de git aussi. Lors de la "réécriture de l'historique", vous partez d'un point du passé et ajoutez de nouveaux commits. La même chose est possible avec les chaînes de blocs et en fait, cela se produit chaque fois qu'un fork se produit, même s'il est abandonné plus tard.
Holger Just

8
Autant que je comprends les chaînes de blocs par rapport à Git, vous pouvez également réécrire les chaînes de blocs, à moins que vous ne résolviez le problème de collision de hachage. Et pour Git, oui, vous pouvez réécrire, mais toutes les télécommandes ont toujours l'historique d'origine. La réécriture de l'historique crée de nouveaux hachages et une arborescence différente. Si la chaîne de blocs ne résout pas une telle opération, ce n'est pas un argument valide, car je pourrais l'implémenter si je le souhaite. Ou à l'inverse, je peux rejeter les poussées forcées en définissant une branche comme protégée.
Paebbels

4
@HolgerJuste l'historique de git est modifiable. En effectuant un push --forcesur une seule branche, vous perdez les références aux validations qui sont nettoyées par le garbage collector. C'est différent d'un fork qui n'est pas une réécriture de l'histoire mais plutôt une voie de développement alternative.
houtanb

24
Pouvons-nous résumer, que Git pourrait être exploité en mode blockchain en appliquant un workflow spécial et en interdisant plusieurs opérations?
Paebbels

4
@Paebbels oui, je suis d'accord avec ça. Par défaut et en utilisation régulière, ce n'est pas le cas, mais avec un workflow spécial, ce serait le cas.
houtanb

123

La raison pour laquelle Git et les blockchains semblent similaires est qu'ils utilisent tous les deux des arbres de merkle comme structure de données sous-jacente. Un arbre merkle est un arbre dans lequel chaque nœud est étiqueté avec la valeur de hachage cryptographique de son contenu, qui comprend les étiquettes de ses enfants.

Le graphe acyclique dirigé de Git est exactement cela, un arbre de merkle où chaque nœud (tag, commit, arbre ou objet blob) est étiqueté avec le hachage de son contenu et l'étiquette de son «enfant». Notez que pour les commits, le terme «enfant» est un peu en conflit avec la compréhension de Git des parents: les commits parents sont les enfants des commits, il vous suffit de regarder le graphique comme un arbre qui ne cesse de grandir en le re-rootant.

Les blockchains sont très similaires à cela, car elles continuent également de croître de cette façon et utilisent également sa propriété d'arbre de merkle pour garantir l'intégrité des données. Mais généralement, les blockchains sont comprises comme bien plus que de simples arbres de merkle où ils se séparent du «traqueur de contenu stupide» Git . Par exemple, les blockchains signifie généralement avoir un système hautement décentralisé au niveau du bloc (tous les blocs ne doivent pas nécessairement être au même endroit).

Comprendre les blockchains est un peu difficile (personnellement, je suis encore loin de tout comprendre), mais je considère que comprendre les internes de Git est un bon moyen de comprendre les arbres de merkle, ce qui aide définitivement à comprendre une partie fondamentale des blockchains.


24
Je suis désolé mais nulle part les blockchains n'apportent autre chose que git. les blockchains sont exactement aussi stupides que git. Si vous ne le croyez pas, vous êtes surexcité. Le réseau de pairs et les systèmes de consensus sont une chose distincte.
v.oddou

2
les grands livres privés (blockchains) sont conceptuellement identiques à git
Munhitsu

En règle générale, dans un référentiel git, il y a un commit racine mais il peut y avoir n'importe quel nombre de branches. Si vous voyez le dernier commit dans une branche comme un commit root et les parents comme des enfants, vous avez un arbre avec de nombreuses racines qui poussent ... Je pense que c'est juste une variation de l'arbre Merkle où les références parent sont dans le contenu au lieu de références enfants. Il peut y avoir plusieurs parents et enfants, donc ce n'est même pas un arbre.
herman

22

Les cyber-monnaies comme Bitcoin utilisent une chaîne cryptographique de consensus distribuée de blocs (arbre de merkle). L'utilisation courante a raccourci cela en `` blockchain ''

Bien que git utilise une chaîne de blocs (arbre merkle), il lui manque les composants cryptographiques de consensus distribués qu'implique l'utilisation courante du terme 'BlockChain'.


17

Blockchainn'est pas n'importe quelle chaîne de blocs.

Blockchainc'est quand il existe un moyen de déterminer la chaîne principale lorsque deux ou plus sont détournés , et lorsqu'aucune autorité centrale n'est nécessaire pour cette détermination.


17

Contrairement aux blockchains de crypto-monnaie ; git n'a pas de mécanisme de consensus p2p sans confiance.


Pourquoi considérez-vous un système de consensus sans confiance comme faisant partie d'une chaîne de blocs? Il existe de nombreuses façons de créer la confiance dans une chaîne de blocs, pour git c'est juste que vous savez que tout ce qui se trouve dans votre copie locale ne peut pas être supprimé par le prochain pull et que vous spécifiez que vous voulez les changements dans la copie distante. Vous n'avez besoin d'un consensus sans confiance que si vous ne savez pas ce qui est juste. Dans git, plusieurs branches peuvent être "correctes" et fusionner eventuell ensemble.
allo

@allo GitHub est généralement utilisé comme source centrale de vérité, mais qu'est-ce qui empêche un administrateur de forcer et de remplacer l'historique? S'il n'y avait pas de GitHub et que vous tiriez parti de vos pairs, comment gérez-vous les conflits de fusion? Comment déterminez-vous à qui?
Miguel Mota

1
Rien ne vous empêche de pousser la force. Mais comme une blockchain me le garantit, je peux la détecter car ma chaîne ne peut pas vérifier que ces commits sont basés sur elle. C'est le point avec une blockchain, pas le consentement décentralisé. Et dans git, je ne veux explicitement pas avoir de protocole de consentement pour ce que je fusionne (le développement n'est pas une démocratie), mais je lis en fait les nouveaux commits lors de leur fusion dans ma chaîne. Donc, ma copie est correcte, car elle se compose de choses que j'ai déjà et que je peux donc vérifier (c'est-à-dire en voyant des conflits de fusion) et de choses que j'examine et que j'accepte.
allo

1
@allo vous avez raison à cet égard, mais j'ai déclaré dans la réponse "blockchains crypto-monnaie", pas les blockchains en général, mais maintenant que j'y pense, ma réponse ne semble pas vraiment correspondre à la question posée parce que j'étais penser au système dans son ensemble plutôt qu'aux structures de données sous-jacentes
Miguel Mota

Vous avez tout à fait raison sur la différence entre les chaînes de blocs utilisées dans git et les crypto-monnaies. Ce n'est tout simplement pas une réponse à la question de savoir pourquoi (ou si) git n'est pas considéré comme une chaîne de blocs, en utilisant le terme rigoureusement. Même la réponse actuellement acceptée est similaire à votre réponse. Je préfère toujours la réponse qui a obtenu la prime.
allo

1

Les objectifs sont différents pour la blockchain et git bien que les deux utilisent des arbres de merkle comme structure de données.

A blockchainest généralement géré par un réseau peer-to-peer adhérant à un protocole de communication inter-nœuds et de validation de nouveaux blocs. Une fois enregistrées, les données d'un bloc donné ne peuvent pas être modifiées rétroactivement sans modification de tous les blocs suivants, ce qui nécessite le consensus de la majorité du réseau.

Comme selon le livre blanc Bitcoin:

Une version purement peer-to-peer de la monnaie électronique permettrait d'envoyer des paiements en ligne directement d'une partie à une autre sans passer par une institution financière. Les signatures numériques fournissent une partie de la solution, mais les principaux avantages sont perdus si un tiers de confiance est toujours nécessaire pour éviter les doubles dépenses. Nous proposons une solution au problème de la double dépense en utilisant un réseau peer-to-peer. Le réseau horodate les transactions en les hachant dans une chaîne continue de preuves de travail basées sur le hachage, formant un enregistrement qui ne peut pas être modifié sans refaire la preuve de travail. La plus longue chaîne sert non seulement de preuve de la séquence des événements observés, mais aussi de preuve qu'elle provenait du plus grand pool de puissance CPU. Tant que la majorité de la puissance du processeur est contrôlée par des nœuds qui ne coopèrent pas pour attaquer le réseau, ils ' ll génère la chaîne la plus longue et dépasse les attaquants. Le réseau lui-même nécessite une structure minimale. Les messages sont diffusés au mieux, et les nœuds peuvent quitter et rejoindre le réseau à volonté, en acceptant la plus longue chaîne de preuve de travail comme preuve de ce qui s'est passé pendant leur absence

While Gitest un système de contrôle de version distribué pour suivre les modifications du code source pendant le développement de logiciels.Il est conçu pour coordonner le travail entre les programmeurs, mais il peut être utilisé pour suivre les modifications dans n'importe quel ensemble de fichiers. Ses objectifs incluent la vitesse, l'intégrité des données et la prise en charge des flux de travail distribués et non linéaires.

Comme selon Linus Torvalds:

À bien des égards, vous pouvez simplement voir git comme un système de fichiers - il est adressable par le contenu, et il a une notion de gestion des versions, mais je l'ai vraiment conçu en abordant le problème du point de vue d'un système de fichiers (hé, les noyaux, c'est ce que je fais) , et je n'ai en fait aucun intérêt à créer un système SCM traditionnel.


0

Comme l'a dit Poke :

Git et Blockchains semblent similaires car ils utilisent tous les deux des arbres Merkle pour stocker des transactions horodatées ordonnées. Un arbre merkle est une structure de données arborescente où chaque nœud est étiqueté avec la valeur de hachage cryptographique de son contenu, qui comprend les étiquettes de ses enfants.

La première différence est la fonction Hash : Blockchain a une fonction de hachage très coûteuse de sorte que chaque bloc doit être miné, alors qu'un "bloc" Git peut être créé avec un simple message de validation.

Le but de Bitcoin est d'ajouter de la confiance à l'ordre des transactions. L'accent est mis sur la chaîne la plus longue, car elle est la plus coûteuse à calculer et donc la plus susceptible d'être la vérité.

Bitcoin accomplit cela en exigeant que le hachage réponde à certains paramètres (commence par un nombre spécifique de 0), en incrémentant une valeur ("nonce") dans le message jusqu'à ce qu'un hachage satisfaisant soit trouvé. Cela demande un effort pour trouver, mais un seul calcul pour vérifier un nonce; et si plusieurs nonces produisent un hachage satisfaisant, alors l'un sera inférieur et considéré comme la vérité. D'autres schémas d'authentification rendent le hachage digne de confiance en centralisant l'émission du hachage à une autorité, peut-être votée par accord de réseau, ou par une autre méthode.

Les données de la blockchain sont limitées aux transactions, qui doivent être conformes à la validation. La transaction doit être valide pour être incluse dans le bloc suivant. Une transaction Bitcoin correspond à quelque chose d'important dans le monde réel qui justifie l'utilisation d'un bloc coûteux pour enregistrer ce transfert, comme l'échange de valeur monétaire. Nous ne nous soucions pas vraiment du grand livre final, c'est une métaphore de quelque chose dans le monde réel.

En revanche, les blocs Git sont arbitraires, car un commit peut contenir n'importe quelle quantité de données. La valeur réside dans les changements de données organisés dans l'arbre git car nous nous soucions du produit final, il est validé par l'existence du référentiel git.

Le but de Git est de permettre à des «registres» bon marché de suivre plusieurs alternatives de produits. Le "grand livre" dans Git est ce qui nous tient à cœur, c'est notre produit final; les données de transaction enregistrent simplement la façon dont le produit a été construit. Nous voulons rendre très bon marché la création de plusieurs versions de produits finaux, juste assez de frais généraux pour obliger le créateur à enregistrer comment il a construit ce produit. Aucune validation explicite n'est faite sur les données, vous maintenez le produit final s'il semble bon, et cette existence rend utile la chaîne de création de ce produit. Si le produit final est incorrect ou si l'ordre des validations n'est pas valide, ce «grand livre» est supprimé lors du garbage collection.

La deuxième différence est que les transactions Blockchain doivent provenir d'une source valide antérieure. Dans Git, nous ne nous soucions pas des données que vous utilisez pour étendre l'arborescence. Dans Blockchain, les transactions doivent provenir d'une source valide préalable. En ce sens, Git suit l'extension de notre environnement, tandis que Blockchain suit l'échange de valeur dans un environnement fermé.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.