Depuis l’avènement du BTC en 2009, Bitcoin a subi trois itérations techniques et est passé d’un simple concept d’actifs numériques natifs à un système financier décentralisé avec des fonctions et des applications complexes.
Cet article est écrit par le fondateur de BEVM**, qui partage ses idées sur l’évolution de la technologie BTC, et répond également en détail à la manière dont BEVM, qui est une étape clé dans le développement de la technologie BTC Layer 2, peut réaliser la prospérité future de l’écosystème décentralisé de BTC au niveau technique. **
Dans cet article, vous en apprendrez plus sur :
La nécessité de la couche 2 du BTC
Comment atteindre la couche 2 du BTC ?
Solution BEVM entièrement décentralisée
Hommage aux 3 grandes itérations technologiques révolutionnaires du BTC depuis sa naissance :
2009 : BTC est né, la première fois à utiliser la structure de la blockchain pour ouvrir des applications monétaires décentralisées.
2017 : BTC Segregated Witness a été mis à niveau pour prendre en charge le stockage jusqu’à 4 Mo, résolvant ainsi le problème de stockage sur chaîne de BTC. C’est aussi la base du protocole Ordinals (émission d’actifs), désormais explosif.
2021 : BTC Taproot a été 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 entièrement décentralisée.
Tout d’abord, pourquoi voulez-vous faire BTC Layer2 ?**
1. Il y a de la demande : Le réseau Bitcoin répond aux besoins d’enregistrement des actifs, mais il y a encore un grand nombre d’actifs qui doivent être réglés sur la chaîne (couche 2)
À l’heure actuelle, la couche 2 de l’ETH n’est qu’une copie de la couche 1 de l’EPF, et il n’y a rien que la couche 1 ne puisse résoudre, mais les problèmes commerciaux réels que la couche 2 doit résoudre.
Il faut dire que la couche 2 de l’ETH résout le problème de la couche 1 de l’ETH : la couche 2 résout le problème du gaz coûteux de la couche 1. C’est précisément en raison de cette demande que la première application de produits dérivés de l’ETH sur Layer2 Arbitrum, comme GMX, a été réalisée.
Et la couche 2 du BTC n’est pas aussi peu pertinente que la couche 2 de l’ETH.
Étant donné que la machine virtuelle sur chaîne BTC non Turing-complete ne peut enregistrer que des actifs, mais ne peut pas effectuer de règlement, la couche 1 de BTC doit avoir besoin de la couche 2 de BTC Turing-complete pour régler les actifs émis par la couche 1 de BTC.
2.Capacité : Le BTC peut être transformé en une couche 2 entièrement décentralisée
Avant la mise à niveau de BTC Taproot en 2021, il était impossible d’obtenir 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 de calcul de couche 2 entièrement décentralisée.
II.Comment atteindre le BTC L2 décentralisé ?
Les propositions d’amélioration de Bitcoin (BIP) sont des documents de conception qui introduisent de nouvelles fonctionnalités et informations sur Bitcoin, tandis que les mises à niveau de la racine pivotante sont une compilation de trois BIP, à savoir Schnorr Signature (BIP 340), Taproot (BIP 341) et Tap (BIP 342), collectivement connus sous le nom de BIP Taproot.
Il apportera un moyen plus efficace, plus flexible et plus privé de transférer des bitcoins grâce à l’utilisation des signatures de Schnorr et des arbres de syntaxe abstraits de Merkel.
Les signatures Schnorr sont 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é de calcul, de stockage et de confidentialité.
! [Fondateur de BEVM : Pourquoi et comment faire BTC Layer2 ?] (https://cdn-img.panewslab.com//panews/2022/11/11/images/f2c90430573edf17b34bc2b81d6fba2e.)
L’utilisateur confirme l’identité du signataire par le biais de la clé publique et le contenu du contrat par le biais des données, afin d’authentifier la validité du contrat numérique.
Schnorr Aggregate Signatures peut compresser et fusionner plusieurs données de signature en une seule signature agrégée.
Le vérificateur vérifie une signature agrégée unique avec une liste de toutes les données et clés publiques associées aux signatures, ce qui équivaut à vérifier indépendamment toutes les signatures pertinentes.
! [Fondateur de BEVM : Pourquoi et comment faire BTC Layer2 ?] (https://cdn-img.panewslab.com//panews/2022/11/11/images/c7ed182df952263f95cd6b5da86e5aa3.)
À l’heure actuelle, la plupart des blockchains utilisent l’algorithme multisig ECDSA, dans lequel chaque nœud génère une signature numérique indépendante avec sa propre clé privée pour les données de bloc et la diffuse aux autres nœuds. L’autre nœud vérifie la signature et l’écrit dans le bloc de données suivant.
De cette façon, 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, occupant de l’espace de stockage.
Chaque fois qu’un nouveau nœud rejoint le réseau et doit synchroniser des blocs historiques, une grande quantité de données de signature pose un grand défi à la bande passante du réseau.
Après avoir utilisé la technologie de signature agrégée, chaque nœud collecte les cartes de visite de signature agrégées diffusées par d’autres nœuds, puis enregistre l’agrégat de partitions de signature, comme illustré à la figure 2.**
De cette façon, lorsqu’un nouveau nœud se joint, le bloc d’historique de synchronisation n’a qu’à télécharger les 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 donne à toutes les sorties Taproot un aspect similaire. Qu’il s’agisse d’une sortie multi-signature, d’une sortie à signature unique ou d’autres contrats intelligents complexes, ils se ressemblent tous sur la blockchain, de sorte que de nombreuses analyses blockchain ne seront pas disponibles, préservant ainsi la confidentialité de tous les utilisateurs de Taproot. **
! [Fondateur de BEVM : Pourquoi et comment faire BTC Layer2 ?] (https://cdn-img.panewslab.com//panews/2022/11/11/images/187dbc4fe20ec85e558eb12132a2a850.)
Le MAST (Merkle Abstract Syntax Tree) est une série de scripts qui ne se chevauchent pas (par exemple, multisig ou timelock) qui utilisent un arbre de Merkle pour chiffrer des scripts de verrouillage complexes.
Lors de la dépense, seuls le script en question et le chemin d’accès entre ce script et la racine de l’arborescence Merck doivent être divulgués. Comme le montre la figure 3, pour utiliser 1, il vous suffit d’indiquer 1, 2 et le hachage 3.
Les principaux avantages du MAST sont les suivants :
1) Prise en charge des conditions de dépenses complexes
2) Il n’est pas nécessaire de divulguer des scripts non exécutés ou des conditions de dépenses non déclenchées, ce qui offre une meilleure protection de la vie privée
**3) Compresser la taille de la transaction : à mesure que le nombre de scripts augmente, la taille de la transaction non-MAST augmente linéairement, tandis que la taille de la transaction MAST augmente de manière logarithmique. **
Cependant, il y a un problème dans la mise à niveau de Taproot, c’est-à-dire que P2SH n’est pas le même que le Pay-to-Public-Key-Hash (P2PKH), et il y a encore des problèmes de protection de la vie privée.
Est-il possible de faire en sorte que le P2SH et le P2PKH aient la même apparence sur la chaîne ?
Pour cela, Taproot propose une solution qui peut être décomposée en deux parties pour un script avec un nombre limité de signataires :
La première partie est multisig, où tous les signataires s’entendent sur un certain résultat de dépense, connu sous le nom de « dépenses collaboratives ».
La deuxième partie s’appelle « dépenses non collaboratives » et peut avoir des structures de script très complexes.
Ces deux parties sont la relation de « ou ».
Comme le montrent les figures 3 et 3, un 2 sur 2 multisig nécessite qu’Alice et Bob soient valides, ce qui correspond à des « dépenses collaboratives » et que 1 et 2 sont des « dépenses non collaboratives ».
Les « dépenses collaboratives » et les « dépenses non collaboratives » peuvent toutes deux dépenser cet extrant, lorsque :
Pour le script « dépenses non collaboratives », adoptez l’approche MAST décrite ci-dessus et utilisez MerkleRoot pour représenter la racine de l’arbre Merck.
Pour le script « dépenses collaboratives », un algorithme multisig basé sur les signatures de Schnoor est adopté. Pa et Pb sont utilisés pour représenter les clés publiques d’Alice et de Bob, respectivement, et Da et Db sont utilisés pour représenter les clés privées d’Alice et de Bob, respectivement.
Par conséquent, la clé publique agrégée est P=Pa+Pb, et la clé privée correspondante est Da+Db.
Combinez les « dépenses collaboratives » et les « dépenses non collaboratives » sous la forme de P2PKH, et sa clé publique est : PP+H(P||Racine de Merkle)G ; la clé privée correspondante est Da+Db+H(P||MerkleRoot)。
Quand Alice et Bob se mettent d’accord sur des « dépenses collaboratives », ils utilisent Da+Db+H(P||MerkleRoot) n’exige qu’un seul d’entre eux pour ajouter H(P||) à sa clé privéeMerkleRoot).
Sur la 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.
III. Notre solution BTC de couche 2 entièrement décentralisée :
3.1 Nœud léger BTC + contrat de signature de seuil distribué
! [Fondateur de BEVM : Pourquoi et comment faire BTC Layer2 ?] (https://cdn-img.panewslab.com//panews/2022/11/11/images/d6ddaf08422a0b02bc25e45cd2f5d947.)
Dans ce schéma, n (n peut être tous les validateurs sur BEVM) validateurs fixes sont sélectionnés pour compléter le contrat de garde agrégée BTC on-chain avec signature de seuil distribué.
La clé privée de chaque validateur dans la couche BEVM 2 est également dérivée d’une partie de la clé privée agrégée de la signature de seuil de BTC, et la clé privée de seuil de n validateurs est combinée dans l’adresse photo de signature agrégée de BTC. **n peut aller jusqu’à 1000 ou plus. **
Lorsque l’utilisateur A souhaite croiser des BTC vers des BEVM, il lui suffit d’envoyer des BTC au contrat de garde d’agrégation de Bitcoins, et l’utilisateur peut recevoir des BTC sur la couche BEVM2.
En conséquence, lorsque l’utilisateur A effectue une opération de retrait, il lui suffit d’interagir avec m contrats de signature de seuil distribué auto-complétés dans la signature agrégée entre n validateurs, et le transfert du contrat d’entiercement à l’utilisateur A peut être effectué sur Bitcoin, et le BTC sera brûlé sur le BEVM en même temps que le transfert est terminé.
3.2 Mettre en œuvre le 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 s’exécutant dans l’EVM ne peut pas accéder au réseau, au système de fichiers et à d’autres processus. Même l’accès entre les contrats intelligents est restreint.
La couche sous-jacente d’Ethereum prend en charge l’exécution et l’appel du contrat via le module EVM, et le code du contrat est obtenu en fonction de l’adresse du contrat lorsqu’il est appelé, et il est chargé dans l’EVM pour fonctionner. En règle générale, le processus de développement d’un contrat intelligent consiste à écrire du code logique dans solidlity, à le compiler en bytecode via un compilateur, puis à le publier sur Ethereum.
! [Fondateur de BEVM : Pourquoi et comment faire BTC Layer2 ?] (https://cdn-img.panewslab.com//panews/2022/11/11/images/2d2d923b8ae9ff718bac8dedbf6a9314.)
2) Pièces principales EVM
! [Fondateur de BEVM : Pourquoi et comment faire BTC Layer2 ?] (https://cdn-img.panewslab.com//panews/2022/11/11/images/67f265774f666ae9ab031a29230b5b8d.)
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 qu’Ethereum peut contenir. Le code EVM associé à un compte est exécuté chaque fois qu’un message est envoyé au compte et a la capacité de lire/écrire le stockage et d’envoyer des messages lui-même.
4)État de Mchine
L’état Mchine est l’endroit où le code EVM est exécuté, contenant les compteurs de programme, les piles et la mémoire.
5)Stockage
Le stockage est un espace de stockage persistant qui peut être lu, écrit et modifié, et c’est également l’endroit où chaque contrat stocke des données de manière persistante. Le stockage est une carte énorme, avec un total de 2256 emplacements, chacun de 32 octets chacun.
6) BTC comme frais de gaz
Laissez le BTC transféré du réseau Bitcoin être utilisé comme monnaie de calcul des frais de gaz pour l’exécution des transactions sur l’EVM.
Cette page peut inclure du contenu de tiers fourni à des fins d'information uniquement. Gate ne garantit ni l'exactitude ni la validité de ces contenus, n’endosse pas les opinions exprimées, et ne fournit aucun conseil financier ou professionnel à travers ces informations. Voir la section Avertissement pour plus de détails.
Fondateur de BEVM : Pourquoi et comment faire du BTC Layer 2 ?
Auteur : Peter
Préambule
Depuis l’avènement du BTC en 2009, Bitcoin a subi trois itérations techniques et est passé d’un simple concept d’actifs numériques natifs à un système financier décentralisé avec des fonctions et des applications complexes.
Cet article est écrit par le fondateur de BEVM**, qui partage ses idées sur l’évolution de la technologie BTC, et répond également en détail à la manière dont BEVM, qui est une étape clé dans le développement de la technologie BTC Layer 2, peut réaliser la prospérité future de l’écosystème décentralisé de BTC au niveau technique. **
Dans cet article, vous en apprendrez plus sur :
La nécessité de la couche 2 du BTC
Comment atteindre la couche 2 du BTC ?
Solution BEVM entièrement décentralisée
Hommage aux 3 grandes itérations technologiques révolutionnaires du BTC depuis sa naissance :
2009 : BTC est né, la première fois à utiliser la structure de la blockchain pour ouvrir des applications monétaires décentralisées.
2017 : BTC Segregated Witness a été mis à niveau pour prendre en charge le stockage jusqu’à 4 Mo, résolvant ainsi le problème de stockage sur chaîne de BTC. C’est aussi la base du protocole Ordinals (émission d’actifs), désormais explosif.
2021 : BTC Taproot a été 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 entièrement décentralisée.
Tout d’abord, pourquoi voulez-vous faire BTC Layer2 ?**
1. Il y a de la demande : Le réseau Bitcoin répond aux besoins d’enregistrement des actifs, mais il y a encore un grand nombre d’actifs qui doivent être réglés sur la chaîne (couche 2)
À l’heure actuelle, la couche 2 de l’ETH n’est qu’une copie de la couche 1 de l’EPF, et il n’y a rien que la couche 1 ne puisse résoudre, mais les problèmes commerciaux réels que la couche 2 doit résoudre.
Il faut dire que la couche 2 de l’ETH résout le problème de la couche 1 de l’ETH : la couche 2 résout le problème du gaz coûteux de la couche 1. C’est précisément en raison de cette demande que la première application de produits dérivés de l’ETH sur Layer2 Arbitrum, comme GMX, a été réalisée.
Et la couche 2 du BTC n’est pas aussi peu pertinente que la couche 2 de l’ETH.
Étant donné que la machine virtuelle sur chaîne BTC non Turing-complete ne peut enregistrer que des actifs, mais ne peut pas effectuer de règlement, la couche 1 de BTC doit avoir besoin de la couche 2 de BTC Turing-complete pour régler les actifs émis par la couche 1 de BTC.
2.Capacité : Le BTC peut être transformé en une couche 2 entièrement décentralisée
Avant la mise à niveau de BTC Taproot en 2021, il était impossible d’obtenir 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 de calcul de couche 2 entièrement décentralisée.
II.Comment atteindre le BTC L2 décentralisé ?
Les propositions d’amélioration de Bitcoin (BIP) sont des documents de conception qui introduisent de nouvelles fonctionnalités et informations sur Bitcoin, tandis que les mises à niveau de la racine pivotante sont une compilation de trois BIP, à savoir Schnorr Signature (BIP 340), Taproot (BIP 341) et Tap (BIP 342), collectivement connus sous le nom de BIP Taproot.
Il apportera un moyen plus efficace, plus flexible et plus privé de transférer des bitcoins grâce à l’utilisation des signatures de Schnorr et des arbres de syntaxe abstraits de Merkel.
Les signatures Schnorr sont 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é de calcul, de stockage et de confidentialité.
! [Fondateur de BEVM : Pourquoi et comment faire BTC Layer2 ?] (https://cdn-img.panewslab.com//panews/2022/11/11/images/f2c90430573edf17b34bc2b81d6fba2e.)
L’utilisateur confirme l’identité du signataire par le biais de la clé publique et le contenu du contrat par le biais des données, afin d’authentifier la validité du contrat numérique.
Schnorr Aggregate Signatures peut compresser et fusionner plusieurs données de signature en une seule signature agrégée.
Le vérificateur vérifie une signature agrégée unique avec une liste de toutes les données et clés publiques associées aux signatures, ce qui équivaut à vérifier indépendamment toutes les signatures pertinentes.
! [Fondateur de BEVM : Pourquoi et comment faire BTC Layer2 ?] (https://cdn-img.panewslab.com//panews/2022/11/11/images/c7ed182df952263f95cd6b5da86e5aa3.)
À l’heure actuelle, la plupart des blockchains utilisent l’algorithme multisig ECDSA, dans lequel chaque nœud génère une signature numérique indépendante avec sa propre clé privée pour les données de bloc et la diffuse aux autres nœuds. L’autre nœud vérifie la signature et l’écrit dans le bloc de données suivant.
De cette façon, 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, occupant de l’espace de stockage.
Chaque fois qu’un nouveau nœud rejoint le réseau et doit synchroniser des blocs historiques, une grande quantité de données de signature pose un grand défi à la bande passante du réseau.
Après avoir utilisé la technologie de signature agrégée, chaque nœud collecte les cartes de visite de signature agrégées diffusées par d’autres nœuds, puis enregistre l’agrégat de partitions de signature, comme illustré à la figure 2.**
De cette façon, lorsqu’un nouveau nœud se joint, le bloc d’historique de synchronisation n’a qu’à télécharger les 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 donne à toutes les sorties Taproot un aspect similaire. Qu’il s’agisse d’une sortie multi-signature, d’une sortie à signature unique ou d’autres contrats intelligents complexes, ils se ressemblent tous sur la blockchain, de sorte que de nombreuses analyses blockchain ne seront pas disponibles, préservant ainsi la confidentialité de tous les utilisateurs de Taproot. **
! [Fondateur de BEVM : Pourquoi et comment faire BTC Layer2 ?] (https://cdn-img.panewslab.com//panews/2022/11/11/images/187dbc4fe20ec85e558eb12132a2a850.)
Le MAST (Merkle Abstract Syntax Tree) est une série de scripts qui ne se chevauchent pas (par exemple, multisig ou timelock) qui utilisent un arbre de Merkle pour chiffrer des scripts de verrouillage complexes.
Lors de la dépense, seuls le script en question et le chemin d’accès entre ce script et la racine de l’arborescence Merck doivent être divulgués. Comme le montre la figure 3, pour utiliser 1, il vous suffit d’indiquer 1, 2 et le hachage 3.
Les principaux avantages du MAST sont les suivants :
1) Prise en charge des conditions de dépenses complexes
2) Il n’est pas nécessaire de divulguer des scripts non exécutés ou des conditions de dépenses non déclenchées, ce qui offre une meilleure protection de la vie privée
**3) Compresser la taille de la transaction : à mesure que le nombre de scripts augmente, la taille de la transaction non-MAST augmente linéairement, tandis que la taille de la transaction MAST augmente de manière logarithmique. **
Cependant, il y a un problème dans la mise à niveau de Taproot, c’est-à-dire que P2SH n’est pas le même que le Pay-to-Public-Key-Hash (P2PKH), et il y a encore des problèmes de protection de la vie privée.
Est-il possible de faire en sorte que le P2SH et le P2PKH aient la même apparence sur la chaîne ?
Pour cela, Taproot propose une solution qui peut être décomposée en deux parties pour un script avec un nombre limité de signataires :
La première partie est multisig, où tous les signataires s’entendent sur un certain résultat de dépense, connu sous le nom de « dépenses collaboratives ».
La deuxième partie s’appelle « dépenses non collaboratives » et peut avoir des structures de script très complexes.
Ces deux parties sont la relation de « ou ».
Comme le montrent les figures 3 et 3, un 2 sur 2 multisig nécessite qu’Alice et Bob soient valides, ce qui correspond à des « dépenses collaboratives » et que 1 et 2 sont des « dépenses non collaboratives ».
Les « dépenses collaboratives » et les « dépenses non collaboratives » peuvent toutes deux dépenser cet extrant, lorsque :
Pour le script « dépenses non collaboratives », adoptez l’approche MAST décrite ci-dessus et utilisez MerkleRoot pour représenter la racine de l’arbre Merck.
Pour le script « dépenses collaboratives », un algorithme multisig basé sur les signatures de Schnoor est adopté. Pa et Pb sont utilisés pour représenter les clés publiques d’Alice et de Bob, respectivement, et Da et Db sont utilisés pour représenter les clés privées d’Alice et de Bob, respectivement.
Par conséquent, la clé publique agrégée est P=Pa+Pb, et la clé privée correspondante est Da+Db.
Combinez les « dépenses collaboratives » et les « dépenses non collaboratives » sous la forme de P2PKH, et sa clé publique est : PP+H(P||Racine de Merkle)G ; la clé privée correspondante est Da+Db+H(P||MerkleRoot)。
Quand Alice et Bob se mettent d’accord sur des « dépenses collaboratives », ils utilisent Da+Db+H(P||MerkleRoot) n’exige qu’un seul d’entre eux pour ajouter H(P||) à sa clé privéeMerkleRoot).
Sur la 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.
III. Notre solution BTC de couche 2 entièrement décentralisée :
3.1 Nœud léger BTC + contrat de signature de seuil distribué
! [Fondateur de BEVM : Pourquoi et comment faire BTC Layer2 ?] (https://cdn-img.panewslab.com//panews/2022/11/11/images/d6ddaf08422a0b02bc25e45cd2f5d947.)
Dans ce schéma, n (n peut être tous les validateurs sur BEVM) validateurs fixes sont sélectionnés pour compléter le contrat de garde agrégée BTC on-chain avec signature de seuil distribué.
La clé privée de chaque validateur dans la couche BEVM 2 est également dérivée d’une partie de la clé privée agrégée de la signature de seuil de BTC, et la clé privée de seuil de n validateurs est combinée dans l’adresse photo de signature agrégée de BTC. **n peut aller jusqu’à 1000 ou plus. **
Lorsque l’utilisateur A souhaite croiser des BTC vers des BEVM, il lui suffit d’envoyer des BTC au contrat de garde d’agrégation de Bitcoins, et l’utilisateur peut recevoir des BTC sur la couche BEVM2.
En conséquence, lorsque l’utilisateur A effectue une opération de retrait, il lui suffit d’interagir avec m contrats de signature de seuil distribué auto-complétés dans la signature agrégée entre n validateurs, et le transfert du contrat d’entiercement à l’utilisateur A peut être effectué sur Bitcoin, et le BTC sera brûlé sur le BEVM en même temps que le transfert est terminé.
3.2 Mettre en œuvre le 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 s’exécutant dans l’EVM ne peut pas accéder au réseau, au système de fichiers et à d’autres processus. Même l’accès entre les contrats intelligents est restreint.
La couche sous-jacente d’Ethereum prend en charge l’exécution et l’appel du contrat via le module EVM, et le code du contrat est obtenu en fonction de l’adresse du contrat lorsqu’il est appelé, et il est chargé dans l’EVM pour fonctionner. En règle générale, le processus de développement d’un contrat intelligent consiste à écrire du code logique dans solidlity, à le compiler en bytecode via un compilateur, puis à le publier sur Ethereum.
! [Fondateur de BEVM : Pourquoi et comment faire BTC Layer2 ?] (https://cdn-img.panewslab.com//panews/2022/11/11/images/2d2d923b8ae9ff718bac8dedbf6a9314.)
2) Pièces principales EVM
! [Fondateur de BEVM : Pourquoi et comment faire BTC Layer2 ?] (https://cdn-img.panewslab.com//panews/2022/11/11/images/67f265774f666ae9ab031a29230b5b8d.)
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 qu’Ethereum peut contenir. Le code EVM associé à un compte est exécuté chaque fois qu’un message est envoyé au compte et a la capacité de lire/écrire le stockage et d’envoyer des messages lui-même.
4)État de Mchine
L’état Mchine est l’endroit où le code EVM est exécuté, contenant les compteurs de programme, les piles et la mémoire.
5)Stockage
Le stockage est un espace de stockage persistant qui peut être lu, écrit et modifié, et c’est également l’endroit où chaque contrat stocke des données de manière persistante. Le stockage est une carte énorme, avec un total de 2256 emplacements, chacun de 32 octets chacun.
6) BTC comme frais de gaz
Laissez le BTC transféré du réseau Bitcoin être utilisé comme monnaie de calcul des frais de gaz pour l’exécution des transactions sur l’EVM.