L’Outil Surpuissant pour Exploser ton Chiffre d'Affaires en 2024 !
Modèles de confiance dans les grands livres distribués
Le consensus, obtenir des processus distribués pour s'entendre sur une valeur unique, est un problème fondamental en informatique. Le traitement distribué est difficile. En fait, il existe des preuves logiques qui montrent de façon assez concluante qu’il n’y aura pas un seul algorithme parfait pour gérer le consensus dans un système asynchrone constitué de nœuds imparfaits. Tant qu'il y a possibilité de faute, il y a certitude d'un problème.
Algorithmes de consensus
Tous les algorithmes de consensus traitent des propriétés de terminaison, d'accord et d'intégrité. La terminaison, une propriété de vivacité, signifie que tous les processus corrects (non défectueux) produisent finalement une valeur. L'accord, une propriété de sécurité, signifie que tous les processus corrects sélectionnent la même valeur et que ces valeurs sont valides dans les conditions du protocole. En d'autres termes, l'état d'être «correct» est déterminé par le nombre d'autres processus qui partagent votre valeur (tous, un certain quorum ou même un). L'intégrité concerne la capacité de récupérer après la défaillance d'un nœud participant. Lorsqu'un processus cesse de communiquer en cas d'échec, cela s'appelle un échec. Une faute byzantine fait référence à un processus où un processus continue de communiquer mais envoie des erreurs, éventuellement malveillantes. Les données. À ce stade, tous ces réseaux de réseaux privés autorisés et d'acteurs malveillants ont été traités comme des incidents de détection de menaces internes, ce qui est principalement une préoccupation des RH. La proposition Satoshi Nakamoto a été la première à gérer la tolérance de panne byzantine dans un réseau public, asynchrone décentralisé et sans confiance utilisant les technologies existantes dans un cadre pratique. L'idée principale consistait en une nouvelle mise en œuvre de l'algorithme de preuve de travail pour parvenir à un consensus dans un réseau d'égal à égal.
Imaginez un grand livre distribué de comptes accessible à tous sur Internet. Il s'agit d'un modèle totalement sans confiance; n'importe qui pourrait techniquement créer un registre frauduleux. Imaginez qu'une entité malveillante crée un état de grand livre indiquant qu'elle est l'expéditeur d'une transaction, reçoit une compensation, puis présente un autre état de grand livre qui annule la transaction précédente. Nous devons non seulement convenir qu'un état est valide, mais nous devons également convenir que cet état ne sera pas modifié ultérieurement. Satoshi a proposé que s'il y a deux états en conflit, l'état qui était le plus difficile à générer gagne en calcul. Satoshi avait un certain nombre d'algorithmes de consensus parmi lesquels choisir, mais la preuve de travail correspondait le plus directement à sa proposition.
La preuve de travail
La preuve de travail fournit un mécanisme pour injecter une complexité de calcul artificielle au processus d'ajout à un registre. . Dans Bitcoin, cette unité de travail implique de trouver une valeur de hachage inférieure à un certain nombre défini par le réseau appelé niveau de difficulté. Le premier nœud à résoudre le puzzle gagne et peut ajouter son bloc proposé à la blockchain et recevoir une récompense d'exploration. En cas d'égalité, la chaîne de blocs la plus longue finira par l'emporter, offrant ainsi une cohérence éventuelle. Avec cette solution, nous supposons qu'un adversaire ne peut pas casser la cryptographie utilisée dans une blockchain existante ni disposer de la puissance de calcul nécessaire pour concurrencer l'ensemble du réseau existant. Mais que faire s'ils le font?
Il y a deux hypothèses clés dans la mise en œuvre Bitcoin de la blockchain: nous supposons qu'un adversaire ne peut pas casser la cryptographie utilisée dans un environnement existant la blockchain ni la puissance de calcul nécessaire pour concurrencer l'ensemble du réseau existant. Une menace pour l'intégrité d'un système d'égal à égal se concentrera probablement sur l'un de ces vecteurs. Il y a aussi la possibilité qu'un écart exploitable se trouve dans l'algorithme de consensus lui-même parce qu'il n'est pas mathématiquement possible qu'un système puisse en être autrement.
En 1985, Michael Fischer, Nancy Lynch et Michael Paterson ont publié un petit papier joyeux montrant que dans un réseau asynchrone où les messages peuvent être retardés mais pas perdus, il n'y a pas d'algorithme de consensus qui est garanti de se terminer à chaque exécution pour toutes les conditions de démarrage si au moins un nœud peut échouer. Puisqu'il n'y a pas de limite supérieure à f, il n'y a aucune garantie qu'un échec s'est produit; cela peut être un très long f. Il ne peut exister de protocole de consensus déterministe qui puisse garantir la sécurité, la vivacité et la tolérance aux pannes dans un système asynchrone où l'échec est une possibilité. FLP implique en outre qu'aucun accord ne peut être garanti dans un système asynchrone avec des défauts byzantins, car ils sont plus difficiles. Il y a eu énormément de travail dans ce domaine au cours des décennies qui ont suivi ce document et vous verrez toutes les bonnes solutions renvoyant à cette limitation.
Limitations
La plupart des considérations pratiques se concentrent sur les échecs techniques et les mauvais acteurs . Un système peer-to-peer distribué comme la blockchain n'est pas vulnérable aux défaillances du système car des défaillances de nœuds sont réellement attendues. Une défaillance technique dans la blockchain serait probablement concentrée autour de la cryptographie qui lie réellement les transactions individuelles. Il y a aussi l'hypothèse qu'aucun mauvais acteur n'aurait la puissance de calcul nécessaire pour promouvoir un mauvais registre. Ce sont deux hypothèses, cependant.
En tant que propriétaire de Bitcoin, vous avez une clé privée qui prouve la propriété et autorise les transactions. Une clé privée ne peut jamais être réinitialisée ou récupérée en cas de perte. Pour chaque clé privée du réseau Bitcoin, il existe exactement une clé publique. Dans Bitcoin, les clés privées produisent des clés publiques à l'aide d'un algorithme appelé algorithme de signature numérique à courbe elliptique (ECDSA). ECDSA garantit que la même clé privée produira toujours la même clé publique, mais la clé privée ne peut pas être reconstituée à partir de la clé publique.
La clé privée Bitcoin est un nombre de 256 bits créé à l'aide de l'algorithme de chiffrement SHA-256. . Cela avait été considéré comme pratiquement incassable. Bruce Schneider dans Applied Cryptography, citant des limitations thermodynamiques, a laissé entendre que les attaques par force brute contre des clés de 256 bits seraient irréalisables jusqu'à ce que les ordinateurs soient construits à partir d'autre chose que de la matière et occupent autre chose que de l'espace. Google avait fait valoir qu'ils pouvaient briser le cryptage en utilisant l'informatique quantique, mais cela semble peu pratique. Les Qubits sont les unités de base de l'information quantique. Les chercheurs estiment qu'il faudrait 1500 quibits pour commencer le problème d'enchevêtrement Même le supercalculateur de Google n'a que 50 quibits.
Conclusion
Le traitement distribué est intrinsèquement difficile. S'accorder sur la vérité est un compromis. Différents algorithmes de consensus abordent ce problème en faisant des compromis différents. Connaître votre problème métier vous permet de faire un choix éclairé parmi les différents algorithmes disponibles. Comme il n'y a pas de réponse correcte unique, vous devez connaître les détails des compromis de vos algorithmes sélectionnés.
Source link