jakiro
Auteur: Chakra; Traduction: 0xjs @ Bitchain Vision
Bitcoin est la blockchain de valeur marchande la plus ancienne, la plus sûre, la plus décentralisée et la plus élevée au monde.Cependant, son faible volume de transactions par seconde (TPS) et ses capacités de programmation limités sont souvent critiqués pour leur difficulté à soutenir des applications à grande échelle, entravant sérieusement le développement de l’écosystème Bitcoin.En tant que constructeur de l’écosystème Bitcoin, cet article vous guidera à travers le passé, le présent et l’avenir des solutions d’extension Bitcoin.
Cet article est le premier article d’une série d’articles d’évolutivité Bitcoin, présentant principalement les solutions d’extension natives implémentées dans l’histoire du réseau principal de Bitcoin.Le prochain article discutera des solutions d’extension hors chaîne avec une évolutivité plus élevée.Restez à l’écoute.
Augmenter la limite de taille du bloc
En 2010, Satoshi Nakamoto a introduit une limite de taille de bloc de 1 Mo dans Bitcoin-core.Cette restriction claire n’a pas été révisée depuis plus de dix ans depuis lors.
Fait intéressant, Satoshi Nakamoto n’a pas expliqué publiquement pourquoi il a proposé la limite de taille du bloc, qui est « cachée » dans le RP de la fusion de code et n’a aucune explication détaillée.Quelques années après le départ de Satoshi Nakamoto, la communauté a eu un désaccord grave sur les restrictions de taille des blocs, et la demande de blocs plus importants a déclenché une discussion généralisée.
Plus le bloc est grand, plus il s’adapte aux transactions.En supposant que le temps de consensus reste inchangé, plus le bloc est grand, plus le TPS est élevé.
Pourquoi TPS est-il si important?Parce que dans la limite de bloc de 1 Mo, avec l’échelle de transaction à ce moment-là, le nombre de transactions qui peuvent être effectuées par seconde ne peuvent être que 3-7 transactions, ce qui est loin d’être suffisant pour les applications à grande échelle, et il est impossible de réaliser Le « système de trésorerie électronique point à point de Bitcoin ».
Cependant, les blocs plus grands entraînent également des problèmes à des degrés divers.
Premièrement, les blocs plus grands ont des exigences plus élevées pour le matériel tel que le stockage, l’informatique et la bande passante, entraînant une augmentation des coûts d’exploitation pour l’ensemble du nœud.Les données de transaction historiques de Bitcoin se développent rapidement, nécessitant de nouveaux nœuds complets pour passer plus de temps à se synchroniser avec le réseau.Ces exigences réduisent la volonté des utilisateurs de faire fonctionner les nœuds complets, réduisant ainsi le degré de décentralisation.
Deuxièmement, plus le bloc est grand, plus le temps de synchronisation entre les nœuds est long, plus la possibilité de blocs orphelins apparaissait, entraînant une réorganisation plus fréquente des blocs, augmentant le risque de fournir, réduisant considérablement la sécurité.
Plus tard, ce problème a été appelé le triangle de blockchain impossible par Vitalik, c’est-à-dire que la blockchain ne peut pas atteindre la décentralisation, l’évolutivité et la sécurité en même temps.Plus le bloc est grand, plus l’évolutivité est forte, mais le coût est faible, la décentralisation et la sécurité sont faibles.
La chose la plus importante est que la modification de la limite de taille de bloc nécessite une fourche dure, ce qui nécessite que tous les nœuds de l’ensemble du réseau soient mis à niveau en même temps, sinon il conduira à la division du réseau.Ce n’est pas un bon choix pour le bitcoin qui s’appuie sur un consensus décentralisé.Sous l’influence de Satoshi Nakamoto, éviter les fourches dures semble être devenue le principe de facto du bitcoin.
Malheureusement, la scission s’est produite.Malgré le manque de consensus au sein de la communauté, certains mineurs et développeurs ont changé la limite de taille du bloc chez le client, ce qui conduit finalement à une fourche de réseau.En 2016, Bitcoin Classic a utilisé BIP 109 pour débarquer la limite de taille du bloc à 2 MoCependant, la grande majorité des mineurs et des utilisateurs restent sur le Bitcoin MainNet tel que nous le connaissons maintenant.
L’effort pour augmenter explicitement la taille du bloc par la fourche dure a échoué.
Témoin en quarantaine
Si les fourches dures sont inacceptables, les fourches souples peuvent-elles être utilisées comme solution?Segwit est l’une des méthodes.
Le témoin est le bon pour déverrouiller UTXO, et pendant longtemps, le témoin a été placé dans le champ de script d’entrée d’UTXO pour terminer la transaction.Cependant, cette méthode a des problèmes potentiels tels que la dépendance circulaire, la ductilité des transactions tierces et la ductilité des transactions secondaires.
Dès 2011, les développeurs ont remarqué ce problème et ont proposé une solution à Segwit, qui est sur le point de séparer les témoins des autres données de transaction.Cependant, la proposition de Fork Hard à l’époque n’était pas soutenue, et ce n’est que lors de la proposition de Segwit Soft Fork en 2015 que la fusion a finalement été réalisée.
Comment SEGWIT réalise-t-il la compatibilité en arrière à travers des fourchettes souples?Cela comprend principalement les deux aspects suivants:
-
Les nouveaux nœuds de version peuvent reconnaître et accepter les blocs et les transactions générés par les anciens nœuds de version.
-
Bien que les anciens nœuds de version ne puissent pas reconnaître les nouvelles règles et fonctionnalités introduites par de nouvelles versions, elles traitent toujours les blocs générés par les nouvelles versions comme valides.
Segwit Soft Fork permet aux nouvelles transactions d’utiliser des scripts d’entrée vides et d’ajouter des champs de témoins dans la structure du bloc pour stocker des témoins.Étant donné que le noyau Bitcoin avant la mise à niveau prend en charge les scripts d’entrée vides, l’ancien nœud de version ne rejetera pas les blocs générés par la nouvelle version.De plus, en utilisant le champ de version, les anciens types de transactions sont toujours disponibles et les nœuds les traitent de différentes manières en fonction de la version.
L’extension de Segwit est mise en œuvre sous forme de poids, les poids des octets de témoin de 1 et les autres octets de données étant 4, limitant ainsi le poids maximum de chaque bloc à 4 millions.Pourquoi voulez-vous attribuer des poids différents à différents types de données?Une idée de bon sens est que les données des témoins ne servent de fonction de vérification que lorsqu’elles sont utilisées et n’ont pas besoin d’être stockées en stockage pendant longtemps, donc il est relativement faible en coût et a un poids faible.
Cela augmente en fait la limite de taille du bloc déguisée.À en juger par l’ancienne structure de blocs, cela adhère toujours à la limite d’origine du bloc de Satoshi Nakamoto d’au plus 1 Mo par bloc.
Racine pivotante
En utilisant les opcodes de Bitcoin tels que OP_IF, nous pouvons définir des conditions complexes pour les scripts de dépenses Bitcoin, tels que les verrous de temps, les multi-signatures, etc.Cependant, les conditions de dépenses complexes nécessitent souvent plusieurs entrées et signatures de vérification, augmentant ainsi la charge de bloc et réduisant les vitesses de transaction tout en exposant toutes les conditions de paiement, entraînant des fuites de confidentialité.
Taproot utilise le mât pour améliorer le bitcoin, et les utilisateurs utilisent Merkle Trie pour indiquer des conditions de dépenses.Chaque nœud feuille représente un script de dépense.Cela réduit la consommation d’espace de bloc et augmente la confidentialité.
La mise à niveau de la racine de tapoot introduit également une signature Schnorr qui possède des propriétés homomorphes additives qui permettent une agrégation de signature et une validation par lots, augmentant ainsi les transactions globales par seconde (TPS).L’avantage de signature d’agrégation des signatures Schnorr simplifie considérablement la logique de validation des transactions multi-signature.Auparavant, les signatures ECDSA ont nécessité l’envoi de plusieurs signatures à la chaîne pour correspondre au script, tandis que les signatures Schnorr ne nécessitaient que l’envoi d’une seule signature globale hors chaîne à la chaîne, réduisant l’utilisation de l’espace sur chaîne par des paiements multi-signature.
Les codes de contrat complexes sont soumis via la racine de mât en combinant les signatures schnorr avec le mât et en utilisant le concept Pay to Contrac (P2C) pour modifier et générer une clé publique Bitcoin standard qui prend en charge les paiements avec une seule signature Schnorr.
Fait intéressant, parce que la signature unique et les signatures multiples des signatures Schnorr se ressemblent sur la chaîne, la logique des scripts complexes, des signatures multiples et des signatures uniques est indiscernable sur la chaîne, améliorant davantage la confidentialité.
en conclusion
Les solutions d’évolutivité de Bitcoin reflètent son approche évolutive pour améliorer les performances tout en maintenant la décentralisation et la sécurité.
Initialement, en considérant l’augmentation de la taille du bloc, résolvant directement le problème des faibles taux de transaction, mais en augmentant les problèmes liés aux coûts des nœuds et aux fourches de réseau, posant des défis au consensus communautaire.
L’introduction de Segwit marque un progrès significatif en optimisant la capacité de bloc à travers des fourchettes souples, garantissant une compatibilité vers l’arrière et en évitant les fourches dures divisées.
La racine de tapoot a ensuite amélioré l’évolutivité et la confidentialité par le biais de signatures de mât et de Schnorr, réduisant l’espace de transaction et améliorant l’efficacité de vérification.Plus important encore, Taproot peut implémenter des scripts complexes sur Bitcoin, ouvrant la voie à de futures tentatives d’expansion.
Ces développements mettent en évidence la progression prudente et innovante de Bitcoin vers un réseau plus évolutif et puissant, ce qui est crucial pour son avenir en tant que système de paiement mondial.
Cependant, l’impact de ces solutions d’extension ne suffit pas pour réaliser la vision d’un « système de trésorerie électronique point à point ».
