Ethereum travaille toujours sur un plan complémentaire pour l’EVM parallèle, mais Bitcoin pourrait bientôt s’attendre à sa propre couche 2 de VM parallèle.

Comprenons d’abord pourquoi Ethereum ne peut pas réaliser un EVM parallèle.

Pour maintenir la cohérence et la sécurité du réseau, EVM possède une caractéristique cruciale dans sa conception : les transactions sont exécutées de manière séquentielle. L’exécution séquentielle garantit que les transactions et les contrats intelligents peuvent être exécutés dans un ordre déterministe, ce qui facilite la gestion et la prévision de l’état de la blockchain. Ce choix de conception donne la priorité à la sécurité, réduisant ainsi les complexités et vulnérabilités potentielles associées à l'exécution parallèle. Cependant, en cas de charges élevées de demandes de transaction, cette exécution séquentielle peut entraîner une congestion et des retards du réseau, à l'instar d'une autoroute à voie unique.

Est-il possible d’ajouter simplement des voies ? Référencement de solutions existantes de VM dites parallèles, y compris des chaînes de partitionnement comme Near. Ces chaînes proposaient de faire évoluer la blockchain en introduisant davantage de machines virtuelles pour faire évoluer les contrats intelligents. Essentiellement, la charge de travail d’un contrat intelligent réside toujours dans une certaine VM. Si tous les contrats intelligents de cette chaîne consomment une quantité égale de TPS, alors le problème est résolu. Cependant, si seulement quelques contrats, tels que les protocoles Aave et Uniswap, consomment plus de 90 % de l'espace de bloc, avoir des contrats exécutés sur un seul fragment signifie uniquement évoluer au niveau de la chaîne sans bénéficier des améliorations apportées par le partitionnement. L'ajout de voies sans possibilité de changer de voie représente le dilemme actuel de la parallélisation des machines virtuelles.

L'EVM parallèle implique la coupe ou la mise en cache des données au niveau de la couche de données. Cependant, limité par le modèle de programmation d’EVM, Solidity, en tant que langage de programmation de contrats intelligents le plus populaire, ne peut pas maximiser le potentiel de l’architecture blockchain parallèle. Cela revient à ne pas programmer avec SQL sur le GPU de NVIDIA. Solidity manque d'expressions pour les architectures parallèles comme Relay Execution et n'a pas d'atomicité finale définie pour les transactions parallèles.

Le véritable parallélisme dans l’architecture blockchain nécessite d’atteindre le résultat selon lequel les transactions d’un contrat intelligent peuvent s’exécuter simultanément sur plusieurs machines virtuelles. Un modèle de programmation tel que CUDA est nécessaire pour tirer pleinement parti d'un modèle parallèle dans l'architecture blockchain.

BitReXe mentionne que Bitcoin introduit la couche 2 de VM parallèle complète de Turing pour fournir une prise en charge de l'infrastructure sous-jacente pour les applications réelles dans l'écosystème Bitcoin et un modèle de programmation exclusif pour les VM parallèles, PREDA.

Comment BitReXe réalise des Vms parallèles sur Bitcoin

Machines virtuelles parallèles

L'illustration suivante met en évidence les distinctions entre BitReXe et d'autres initiatives promouvant les machines virtuelles parallèles. Comme le montre le segment le plus à gauche de la figure, Ethereum adhère à un modèle d'état à machine unique, dans lequel tous les codes (contrats intelligents) et états (données) sont répliqués et gérés par chaque nœud de blockchain via sa machine virtuelle Ethereum (EVM). Les projets existants utilisent des EVM parallèles, comme le montre la section centrale de la figure, où un seul contrat intelligent est déployé sur une VM dédiée (ou des VM au sein d'une partition désignée pour maintenir le consensus). Toutes les transactions relatives au contrat intelligent sont traitées par la VM (ou les VM du fragment de manière entièrement dupliquée).

Dans le modèle de parallélisation unifié de BitReXe, comme le montre le segment le plus à droite de la figure, tous les contrats intelligents sont déployés sur toutes les machines virtuelles du réseau. Les états d'un contrat intelligent sont partitionnés et distribués sur des instances de VM distinctes, garantissant une allocation sans chevauchement. En conséquence, les transactions du contrat intelligent sont segmentées et distribuées pour un traitement indépendant et parallèle sur les machines virtuelles. Dans le cas idéal, cette approche facilite une mise à l’échelle linéaire du débit global des transactions et de la capacité de l’état avec un nombre croissant de machines virtuelles.

Le principal défi réside dans la gestion efficace des dépendances entre la logique d'exécution (code) et l'état du contrat (données) tout en permettant une exécution indépendante des VM et en évitant la synchronisation, puisque la logique d'exécution globale d'une transaction peut impliquer l'accès à plusieurs segments d'états du contrat, chacun résidant dans dans des machines virtuelles distinctes après le partitionnement de l’état.

enseigner

Nous présentons l'architecture distribuée d'exécution de relais parallèle (PREDA), un modèle de programmation révolutionnaire conçu pour étendre les contrats intelligents sur les blockchains de partitionnement, les systèmes de parachain et les blockchains de couche 2. PREDA prend en charge une architecture parallèle : si Solidity pour Ethereum est assimilé à une programmation sur un processeur monocœur, l'architecture parallèle de PREDA pour BitReXe s'apparente à CUDA pour le GPU de NVIDIA.

Le modèle PREDA introduit deux composants clés : (1) « Portées de contrat programmables », permettant aux programmeurs de définir le partitionnement de l'état du contrat en fonction du modèle d'accès aux données de l'application, en réduisant la plage d'accès aux données et en minimisant la dépendance aux données ; et (2) « Relais fonctionnel asynchrone », permettant aux programmeurs d'articuler la logique de transaction avec des dépendances de données implicites pour une exécution flexible sur plusieurs moteurs d'exécution (VM). Implémenté en tant que langage Solidity étendu, PREDA inclut une syntaxe supplémentaire pour les étendues de contrat programmables et les instructions pour le relais fonctionnel asynchrone.

La figure illustre la version PREDA d'un contrat ERC20 simplifié. Le mot-clé « @address » définit la portée des soldes des utilisateurs, équivalent à la définition de carte de Solidity mais spécifie des états fins et séparables pour le partitionnement par adresse. Au moment de l'exécution, les états partitionnés par adresse sont gérés par un ensemble de machines virtuelles dans la chaîne BitReXe. Différents états ne sont pas gérés par différents ensembles de machines virtuelles. La fonction de transfert dans la portée « @address », invoquée par les payeurs (c'est-à-dire les adresses des utilisateurs initiant les transactions de transfert), initie un « relais » pour le dépôt vers le bénéficiaire. Ce relais, exécuté par une VM hébergeant les états d’adresse du bénéficiaire, ajoute des fonds au solde du bénéficiaire.

Dans PREDA, un contrat intelligent peut avoir plusieurs portées avec des variables et des fonctions définies. Plusieurs fonctions et variables de types arbitraires, y compris des conteneurs, peuvent être définies dans une portée. Plusieurs relais, conditionnellement ou inconditionnellement, peuvent être lancés dans un seul appel de fonction, permettant une initiation récursive et permettant au flux d'exécution de transactions d'être déplacé sur plusieurs sauts entre différentes instances de VM. Cette approche d'exécution par relais décompose une transaction en plusieurs micro-transactions, garantissant un accès limité à l'état dans une seule machine virtuelle et évitant les conditions de concurrence. Dans le contrat intelligent de transfert PREDA, décomposer la transaction en une micro-transaction « retrait » et une micro-transaction « dépôt » permet d'exécuter en parallèle ces deux types de micro-transactions, pour autant que leurs cibles (les adresses en l'occurrence) soient mappés à différentes machines virtuelles.

BitReXe organise les machines virtuelles en plusieurs groupes de consensus, chacun exécutant indépendamment un protocole de consensus (basé sur PoW dans l'implémentation) pour parvenir à un consensus sur les transactions exécutées. Un consensus au sein du groupe est mis en œuvre pour maintenir l'exactitude et la cohérence des relais fonctionnels asynchrones, implémentés en tant que transactions de relais dans BitReXe.

Bitcoin Couche 2

Le paradigme d'émission d'actifs sur la couche Bitcoin comme l'inscription exploite constamment une vulnérabilité de Bitcoin, explique Luke. Tandis que l’argent ne dort jamais, tout comme les inscriptions ne peuvent jamais mourir. Bitcoin a désespérément besoin d’une couche 2 véritablement évolutive qui puisse relâcher une telle pression et empêcher la taille du grand livre de croître trop rapidement, ce qui affaiblirait la décentralisation. Il est très peu probable qu’un tel objectif puisse être atteint par une solution EVM+Bridge.

BitReXe propose des VM parallèles et PREDA pour faire évoluer le bitcoin. En attendant, il s’adapte à la sécurité du Bitcoin. Il utilise BTC comme frais de gaz, partage la sécurité de Bitcoin et fournit un règlement d'actifs sans confiance entre les deux chaînes.

BitReXe réutilise la puissance de calcul de hachage du réseau Bitcoin qui est transportée par des blocs en chaîne, des blocs orphelins et des blocs prématurés comme preuve de travail pour créer des blocs valides dans le réseau de couche 2 sans modifier le protocole Bitcoin. Les mineurs de fusion reçoivent du rxBTC en récompense, un bitcoin indexé 1:1 sur le réseau BitReXe. Les utilisateurs paient des frais de gaz avec rxBTC pour les transactions, l'interaction avec les contrats intelligents et d'autres activités en chaîne. Le laboratoire Fullnodes, l'équipe de développement de PREDA et BitReXe, est sur le point d'introduire une solution de pont de règlement d'actifs sans confiance entre Bitcoin et BitReXe, où le rxbtc est en même temps le rattachement BTC de quelqu'un. Les adresses officielles de rattachement ne sont plus nécessaires, l'hypothèse de confiance est donc éliminée.

Nos attentes élevées à l’égard de l’écosystème Bitcoin proviennent de sa capacité à résoudre des problèmes qu’Ethereum – en tant que réseau de test de Bitcoin – n’a pas résolu.

@Bit_ReXe estime que ce problème provient du manque de mécanismes parallèles d'EVM conduisant au trilemme de la blockchain et vise à le résoudre directement sur Bitcoin Layer 2.

Si ce problème peut être résolu sur Bitcoin, alors l’analyse comparative TVL ou même le dépassement d’Ethereum de plus de trois fois sur Bitcoin Layer 2 présenterait une avancée fondamentale.

Ceci est un article invité de BitPnova. Les opinions exprimées sont entièrement les leurs et ne reflètent pas nécessairement celles de BTC Inc ou de Bitcoin Magazine.

Source : Bitcoin Magazine

L'article BitReXe : Activation des machines virtuelles parallèles sur le réseau Bitcoin apparaît en premier sur Crypto Breaking News.