Écrit par : Pierre
Préface
Depuis l’avènement du BTC en 2009, Bitcoin, qui a connu trois itérations technologiques, est passé d’un simple concept d’actif numérique natif à un système financier décentralisé doté de fonctions et d’applications complexes.
Cet article est rédigé par le fondateur de BEVM, qui partage son point de vue sur l'évolution de la technologie BTC. Il explique également en détail comment BEVM, une étape clé dans le développement de la technologie BTC Layer2, réalise l'avenir du BTC au niveau technique. Prospérité écologique décentralisée.
Grâce à cet article, vous en apprendrez davantage sur :
La nécessité de BTC Layer2
Comment implémenter BTC Layer2 ?
Solution BEVM entièrement décentralisée
Rendez hommage aux trois grandes itérations technologiques révolutionnaires du BTC depuis sa naissance :
2009 : BTC est né, utilisant pour la première fois la structure blockchain pour ouvrir des applications monétaires décentralisées.
2017 : BTC Segregated Witness a été mis à niveau pour prendre en charge un stockage maximum de 4 Mo, résolvant ainsi le problème de stockage en chaîne de BTC. Cela constitue également la base du désormais populaire protocole Ordinals (émission d’actifs).
2021 : BTC Taproot est mis à niveau pour prendre en charge l'algorithme de signature de seuil BTC, qui fournit une prise en charge sous-jacente de la technologie BTC Layer2 complètement décentralisée.
1. Pourquoi souhaitez-vous créer BTC Layer2 ?
1. Il existe une demande : le réseau Bitcoin répond à la demande d'enregistrement des actifs, mais il existe encore un grand nombre d'actifs qui nécessitent un règlement en chaîne (couche 2)
La couche 2 actuelle d'ETH n'est qu'une copie de la couche ETH 1. Il n'y a aucun problème commercial pratique qui ne puisse être résolu par la couche 1 et doit être résolu par la couche 2.
Il faut dire qu’ETH Layer2 résout le problème d’ETH Layer1 : Layer2 résout le problème du coût élevé du gaz de Layer1. C’est précisément en raison de cette demande que des applications dérivées sur le plus grand arbitrage Layer2 de l’ETH, comme GMX, ont été créées.
Et la couche 2 de BTC n’est pas aussi pertinente que la couche 2 d’ETH.
Étant donné que la machine virtuelle en chaîne non complète de Turing de BTC ne peut enregistrer que les actifs mais ne peut pas effectuer de règlement, BTC Layer1 doit exiger que BTC Layer2 soit complet de Turing pour régler les actifs émis par BTC Layer1.
2. Capable : BTC peut devenir une couche 2 entièrement décentralisée
Avant la mise à niveau de BTC Taproot en 2021, il sera impossible de réaliser une couche 2 BTC entièrement décentralisée. Cependant, après cette mise à niveau, l'algorithme de signature de seuil BTC permet à BTC de prendre en charge une couche informatique de couche 2 entièrement décentralisée.
Deuxièmement, comment parvenir à un BTC L2 décentralisé ?
Les propositions d'amélioration Bitcoin (BIP) sont des documents de conception qui introduisent de nouvelles fonctionnalités et informations sur Bitcoin, tandis que la mise à niveau de la racine pivotante est une compilation de trois BIP, à savoir Schnorr Signature (BIP 340), Taproot (BIP 341) et Tapscript (BIP 342), ces trois mises à niveau sont collectivement appelées BIP Taproot.
Il apportera une méthode de transmission plus efficace, flexible et privée à Bitcoin, et son noyau réside dans l'utilisation des signatures Schnorr et des arbres de syntaxe abstraite de Merkel.
La signature Schnorr est un système de signature numérique connu pour sa simplicité et sa sécurité. Les signatures Schnoor offrent plusieurs avantages en termes d'efficacité informatique, de stockage et de confidentialité.
L'utilisateur confirme l'identité du signataire via la clé publique et confirme le contenu du contrat via les données, vérifiant ainsi la validité du contrat numérique.
La signature globale Schnorr peut compresser et fusionner plusieurs données de signature en une seule signature globale.
Le vérificateur vérifie une seule signature globale via une liste de toutes les données et clés publiques liées à la signature. Si la vérification réussit, l'effet est équivalent à une vérification indépendante de toutes les signatures associées et toutes réussissent.
La plupart des blockchains actuelles utilisent l'algorithme multi-signature ECDSA. Pour les données de bloc, chaque nœud utilise sa propre clé privée pour générer une signature numérique indépendante et la diffuser aux autres nœuds. D'autres nœuds vérifieront la signature et l'écriront dans le prochain bloc de données.
Grâce à cette méthode, lorsque le nombre de nœuds de consensus est important, les données de signature stockées dans chaque série de blocs de consensus continueront d'augmenter et d'occuper de l'espace de stockage.
Chaque fois qu'un nouveau nœud rejoint le réseau et doit synchroniser les blocs historiques, une grande quantité de données de signature constituera un défi majeur pour la bande passante du réseau.
Après avoir utilisé la technologie de signature agrégée, chaque nœud collectera les cartes de visite à signature agrégée diffusées par d'autres nœuds, puis regroupera et enregistrera les signatures en fragments, comme le montre la figure 2.
De cette manière, lorsqu'un nouveau nœud rejoint, la synchronisation des blocs historiques nécessite uniquement le téléchargement des données de signature agrégées, ce qui réduit considérablement l'occupation de la bande passante du réseau et réduit les frais de transaction.
De plus, l’agrégation de clés rend toutes les sorties Taproot similaires. Que les sorties multi-signatures, les sorties à signature unique ou d'autres contrats intelligents complexes se ressemblent tous sur la blockchain, de nombreuses analyses de blockchain seront indisponibles, préservant ainsi la confidentialité de tous les utilisateurs de Taproot.
MAST (Merkle Abstract Syntax Tree) utilise un arbre Merkle pour chiffrer des scripts de verrouillage complexes, dont les feuilles sont des scripts Schiller sans chevauchement (par exemple, des signatures multiples ou des verrouillages temporels).
Lors du décaissement, seuls le script concerné et le chemin depuis ce script jusqu'à la racine de l'arborescence Merck sont divulgués. Comme le montre la figure 3, pour utiliser script1, il vous suffit de divulguer script1, script2 et hash3.
Les principaux avantages de MAST comprennent :
Prend en charge des conditions de paiement complexes
Pas besoin de divulguer les scripts non exécutés ou les conditions de paiement non déclenchées, offrant ainsi une meilleure protection de la vie privée
Taille de transaction compressée : à mesure que le nombre de scripts augmente, la taille des transactions non MAST augmente de manière linéaire, tandis que la taille des transactions MAST augmente de manière logarithmique.
Cependant, il y a un problème dans la mise à niveau de Taproot, c'est-à-dire que P2SH se comporte différemment du Pay-to-Public-Key-Hash (P2PKH) courant, et il existe toujours des problèmes de protection de la vie privée.
Est-il possible de donner à P2SH et P2PKH la même apparence sur la chaîne ?
Pour cela, Taproot a proposé une solution, qui se décompose en deux parties pour les scripts avec un nombre limité de signataires :
La première partie est multi-signature, dans laquelle tous les signataires s'accordent sur un certain résultat de dépenses, appelé « dépenses collaboratives ».
La deuxième partie est appelée « dépenses non collaboratives » et peut avoir une structure de script très complexe.
Ces deux parties sont dans une relation « ou ».
Comme le montre la figure 3, Script3 est une multi-signature 2 sur 2, qui nécessite qu'Alice et Bob signent pour être valide. Il s'agit d'une « dépense collaborative », tandis que Script1 et 2 sont des « dépenses non collaboratives ».
Les « dépenses collaboratives » et les « dépenses non collaboratives » peuvent dépenser cette production, parmi lesquelles :
Pour le script « dépenses non collaboratives », adoptez la méthode MAST ci-dessus et utilisez MerkleRoot pour représenter la racine de l'arbre Merkle.
Pour les scripts « dépenses collaboratives », un algorithme multi-signature basé sur les signatures Schnoor est adopté. Soit Pa et Pb représentent respectivement les clés publiques d'Alice et Bob, et soit Da et Db représentent respectivement les clés privées d'Alice et Bob. Par conséquent, la clé publique globale est P=Pa+Pb et la clé privée correspondante est Da+Db.
Les « dépenses collaboratives » et les « dépenses non collaboratives » sont combinées sous la forme P2PKH. La clé publique est : PP+H(P||MerkleRoot)G ; la clé privée correspondante est Da+Db+H(P| |MerkleRoot). ).
Lorsqu'Alice et Bob acceptent des « dépenses collaboratives », ils utilisent Da+Db+H(P||MerkleRoot). Tout ce dont ils ont besoin est que l'un d'eux ajoute H(P||MerkleRoot) à leur clé privée.
En chaîne, cela se comporte comme une transaction P2PKH, avec une clé publique et une clé privée correspondante, sans qu'il soit nécessaire de divulguer le MAST sous-jacent.
3. Notre solution BTC layer2 entièrement décentralisée :
3.1 Noeud léger BTC + contrat de signature à seuil distribué
Dans cette solution, n (n peut être tous les validateurs sur BEVM) validateurs fixes sont sélectionnés pour compléter le contrat de garde agrégé sur la chaîne BTC avec des signatures à seuil distribuées.
La clé privée produisant des blocs de chaque validateur dans la couche 2 BEVM dérive également une partie de la clé privée agrégée de la signature de seuil de BTC. Les clés privées de seuil de n validateurs sont combinées dans l'adresse photo de signature agrégée de BTC. La plage de valeurs maximale de n peut être de 1 000 ou plus.
Lorsque l'utilisateur A souhaite effectuer un cross-chain BTC vers BEVM, il lui suffit d'envoyer du BTC au contrat de garde d'agrégation Bitcoin, et l'utilisateur peut recevoir du BTC sur la couche 2 de BEVM.
De manière correspondante, lorsque l'utilisateur A effectue une opération de retrait, il n'a besoin que de m des n nœuds de vérification pour former une signature agrégée afin de compléter automatiquement l'interopération du contrat de signature à seuil distribué, et le transfert du contrat de garde à l'utilisateur A peut être effectué sur Bitcoin. Une fois terminé, BTC sera détruit sur BEVM.
3.2 Implémenter BTC en tant que frais de gaz natifs et couche 2 compatible EVM
1) Principe EVM
La machine virtuelle Ethereum est l’environnement d’exécution des contrats intelligents Ethereum. Non seulement il est en bac à sable, mais il est en fait complètement isolé.
Cela signifie que le code exécuté dans l'EVM n'a pas accès au réseau, au système de fichiers et aux autres processus. Même l'accès entre les contrats intelligents est limité.
La couche inférieure d'Ethereum prend en charge l'exécution et l'appel des contrats via le module EVM. Lors de l'appel, le code du contrat est obtenu en fonction de l'adresse du contrat et chargé dans l'EVM pour être exécuté. Habituellement, le processus de développement de contrats intelligents consiste à utiliser Solidlity pour écrire du code logique, puis à le compiler en bytecode via un compilateur et enfin à le publier sur Ethereum.
2) Partie principale de l'EVM
3) Code EVM
Le code EVM est le code de la machine virtuelle Ethereum, qui fait référence au code du langage de programmation que peut contenir Ethereum. Le code EVM associé à un compte est exécuté chaque fois qu'un message est envoyé à ce compte et a la capacité de lire/écrire le stockage et d'envoyer lui-même des messages.
4) État de la machine
L'état Mchine est l'endroit où le code evm est exécuté, y compris le compteur de programme, la pile et la mémoire.
5) Stockage
Le stockage est un espace de stockage persistant lisible, inscriptible et modifiable. C'est également l'endroit où chaque contrat stocke les données de manière persistante. Le stockage est une immense carte avec un total de 2256 emplacements, chaque emplacement contenant 32 octets.
6) Utilisez BTC comme frais de gaz
Laissez le BTC transféré depuis le réseau Bitcoin être utilisé comme devise de calcul des frais de gaz pour l’exécution des transactions sur l’EVM.
