Auteur : Yiping, IOSG Ventures
Le paysage de la couche 2 évolue rapidement à mesure que des ZKRU comme zkSync et StarkNet lancent le réseau principal. Traditionnellement, les OPRU comme Arbitrum sont les premiers à être commercialisés et disposent donc d'un écosystème plus solide. En revanche, les ZKRU constituent des avancées technologiques offrant un débit plus élevé et des frais inférieurs.
Ces derniers mois, davantage d’activités ont migré de la couche 1 vers la couche 2 à la recherche de transactions plus rapides et moins chères. La TVL d’Ethereum est passée de près de 40 milliards de dollars à 20 milliards de dollars au cours de l’année écoulée. Cependant, TVL pour la couche 2 présente une image différente, avec une croissance énorme indiquant que l'adoption de la couche 2 s'accélère.
Arbitrum ouvre la voie avec plus de 50 % de part de marché des TVL de couche 2, bien que les ZKRU aient également déployé leurs efforts. L'avantage d'Arbitrum en tant que premier arrivé lui permet de conserver sa position dominante.
L'analyse du nombre de transactions quotidiennes montre que les ZKRU comme zkSync et StarkNet surpassent légèrement les OPRU en termes de débit. Cependant, l’avantage écosystémique d’Arbitrum demeure, malgré un léger retard dans le TPS quotidien.
Les OPRU existent depuis plus longtemps que les ZKRU. Cependant, les ZKRU lancent leurs réseaux principaux et attirent des utilisateurs d'autres écosystèmes. En tant que leader dans le domaine des OPRU, Arbitrum devrait contrer la montée en puissance des ZKRU avec ses nouvelles mises à jour.
Décision : Style
À mesure que les développeurs optimisent la technologie et les coûts sans connaissance, les ZKRU continueront probablement à gagner des parts de marché en raison de leurs avantages en matière d’évolutivité. Cependant, les effets de réseau d'Arbitrum offrent la capacité de rester robuste malgré les pressions concurrentielles. Grâce à des solutions innovantes telles que Stylus, Arbitrum peut compléter sa position de leader avec des capacités techniques uniques et continuer à rester à l'avant-garde de la course à la couche 2.
En bref, Stylus est un nouvel environnement de contrat intelligent révolutionnaire conçu pour Arbitrum qui permet aux développeurs d'écrire des programmes efficaces et interopérables dans des langages de programmation comme Rust, C++ et Solidity.
Il ouvre l’informatique générale à la blockchain et accueille les développeurs utilisant différentes piles technologiques.
WASM
Stylus fonctionne en ajoutant une machine virtuelle WebAssembly (WASM) qui s'exécute en parallèle avec la machine virtuelle Ethereum (EVM) existante. Les contrats intelligents écrits dans un langage qui se compile en WASM peuvent s'exécuter nativement 10 fois ou plus plus rapidement que Solidity, réduisant considérablement les coûts de gaz. L'EVM reste entièrement fonctionnel, de sorte que les contrats Solidity existants fonctionnent toujours comme ils le font aujourd'hui. Deux VM fonctionnent de manière synchrone, permettant aux contrats écrits dans différents langages de programmation de s'appeler tout en modifiant également le même état sous-jacent de la blockchain.
Précompilation personnalisée
De plus, Stylus prend également en charge les précompilations personnalisées.
Les précompilations sont des modules de bas niveau sur Ethereum et Arbitrum utilisés pour exécuter très efficacement des fonctions cryptographiques ou utilitaires spécifiques. Par exemple, il existe des précompilations pour la vérification de la signature ECDSA et le calcul des hachages SHA256.
L'ajout de nouvelles précompilations nécessite que tous les validateurs coordonnent la mise à niveau de l'EVM, la barrière à l'entrée est donc élevée. Et avec Stylus, les développeurs peuvent facilement déployer leurs propres précompilateurs écrits en Rust ou C++.
Par exemple, une équipe peut prendre une bibliothèque cryptographique écrite en C et la déployer sur Arbitrum sans modification. Cela permettra à ces primitives cryptographiques de s’exécuter à des vitesses natives ultra-rapides.
D'autres contrats peuvent appeler ce Stylus « précompilation », tout comme ils appellent précompilation native pour tirer parti de cette technologie cryptographique. Tous les compteurs de gaz et la lutte contre la fraude fonctionnent automatiquement.
Cela permet à l’équipe de prototyper une cryptographie personnalisée, des courbes spéciales basées sur l’appariement et d’autres primitives nouvelles sans aucun support de chaîne spécial. Les chercheurs d'Ethereum peuvent même itérer rapidement sur les propositions EIP en les déployant sous forme de versions précompilées de Stylus sur Arbitrum.
En donnant aux développeurs la possibilité d'introduire de nouvelles primitives cryptographiques de manière native sur la chaîne, Stylus élargit considérablement la portée de ce qui peut être construit. La précompilation n'est plus limitée aux fonctionnalités prises en charge par l'EVM.
Comment fonctionne le stylet
Avant d’aborder le rôle plus large de WASM dans l’univers de la blockchain, il est crucial de comprendre comment Arbitrum orchestre la coexistence d’EVM et de WASM. Il ne s’agit pas seulement d’avoir deux moteurs distincts ; il s’agit d’une relation synergique qui renforce les atouts des deux.
L'architecture unique d'Arbitrum permet des opérations transparentes et synchronisées entre EVM et WASM, grâce à son état unifié, son invocation inter-VM et son modèle économique compatible.
Les contrats intelligents écrits en Solidity ou dans d'autres langages EVM sont compilés en bytecode EVM comme d'habitude. Une fois exécutés, ces contrats fonctionnent sur l’EVM, comme c’est le cas aujourd’hui.
Pour les langages compilés vers WASM, tels que Rust, C++ et C, le workflow est le suivant :
Les développeurs utilisent des compilateurs WASM disponibles dans le commerce, tels que Clang ou Rustc, pour compiler leurs contrats intelligents dans WASM.
Le bytecode WASM est téléchargé sur la chaîne Arbitrum sous forme compressée.
Le propriétaire du contrat appelle la méthode « compileProgram » précompilée « ArbWasm », qui configure les outils de sécurité pour WASM, les évalue et les compile en code natif optimisé pour le matériel du validateur.
Lorsqu'un contrat est appelé, il s'exécute sur un moteur d'exécution WASM comme Wasmer, qui est beaucoup plus rapide qu'EVM, ce qui permet d'économiser sur les frais de gaz.
Le comptage WASM facture le gaz avant chaque bloc de base plutôt que par opcode comme EVM. Ceci est plus efficace et garantit que le contrat ne devient pas incontrôlable.
EVM et WASM
Les deux machines virtuelles (VM) fonctionnent de manière synchrone, ce qui leur permet de s'appeler tout en partageant le même état global. Une transaction peut être exécutée partiellement dans EVM et partiellement dans WASM, et les résultats sont combinés de manière transparente.
Attendez, comment deux VM peuvent-elles fonctionner de manière transparente et synchronisée ?
Polkadot y parvient grâce à XVM. Contrairement à Polkadot, WASM et EVM fonctionnent de manière transparente et synchrone sur Arbitrum pour plusieurs raisons clés :
État unique : les deux machines virtuelles accèdent à la même structure de données sous-jacente et au même tri d'état. Un contrat dans une VM peut lire/écrire au même emplacement qu’un contrat dans une autre VM. Cela fournit une vue unifiée de l’état de la chaîne.
Appels cross-VM : lorsqu'une transaction interagit avec un contrat EVM, Geth la traite et fournit un résultat. Si le contrat EVM appelle ensuite un programme WASM, la VM WASM prend le relais pour calculer les résultats de cette partie.
Contexte partagé : les informations système telles que les données de bloc, l'adresse de l'expéditeur, etc. sont disponibles pour les deux VM. Un contrat WASM peut obtenir le numéro de bloc tout comme un contrat Solidity.
Consensus unique : les validateurs exécutent deux machines virtuelles pour valider les transactions et parvenir à un consensus sur l'état correct de la chaîne. Les litiges feront appel au système uniforme de lutte contre la fraude.
Économie compatible : des concepts tels que la mesure du gaz s'étendent aux machines virtuelles individuelles, garantissant des coûts et des ressources de calcul appropriés dans les deux environnements.
Pour les preuves de fraude, le vérificateur divise les exécutions EVM et WASM pour identifier toute étape invalide si nécessaire. La structure de WASM permet au système de garantir la résiliation et de faire respecter la validité des preuves.
Blockchain |
Arbitrum n'est pas la seule plateforme à reconnaître le potentiel de transformation de WebAssembly (WASM). Polkadot et Cosmos ont également intégré WASM dans leurs écosystèmes, chaque plate-forme offrant un ensemble unique d'avantages et de fonctionnalités.
Polkadot permet aux utilisateurs de développer des contrats intelligents avec WASM et prend en charge deux langages : AssemblyScript, un DSL intégré, et Ink !, qui est similaire à Rust.
Cosmos, quant à lui, utilise CosmWasm comme environnement d'exécution de contrat intelligent, permettant aux développeurs de rédiger des contrats dans Rust.
Avant d’examiner pourquoi l’industrie de la blockchain est si réceptive à WASM, il convient de comprendre les avantages spécifiques qui se démarquent de Cosmos et Polkadot :
Cosmos met en évidence les avantages suivants de WASM :
Compatibilité avec les bibliothèques Rust
Communauté de développeurs diversifiée
Sécurité améliorée, y compris la protection contre les attaques de réentrée
Facile à tester
haute performance
Le runtime WASM de Polkadot possède les fonctionnalités suivantes :
haute performance
Interopérabilité avec EVM
Indépendant de la plateforme
Taille binaire compacte
Prend en charge à la fois Rust et AssemblyScript (saveur TypeScript)
Bien que Polkadot, Cosmos et Arbitrum partagent certains avantages communs offerts par WASM, chaque plateforme possède également ses propres attributs uniques.
L'adoption généralisée de WASM par ces principales plateformes de blockchain témoigne de son importance croissante dans l'industrie, il est donc essentiel de comprendre pourquoi cette technologie devient rapidement la pierre angulaire de l'architecture blockchain moderne.
Pourquoi choisir WASM
Qu'est-ce que WASM
Afin de comprendre la synergie entre la blockchain et WebAssembly (WASM), il faut d'abord comprendre ce qu'est WASM et le moteur de son développement.
WebAssembly est un format d'instruction binaire qui permet au code de s'exécuter à une vitesse quasi native dans un navigateur Web. Il sert de cible de compilation pour une gamme de langages de programmation, notamment C et Rust, et est conçu pour être rapide, efficace et sûr. WASM comble efficacement le fossé entre la programmation basée sur le Web et celle au niveau du système, améliorant ainsi les performances et les fonctionnalités du Web.
"Web" dans WebAssembly met en évidence sa capacité à s'exécuter dans un environnement JavaScript (généralement trouvé dans un navigateur). Dans ces configurations, les développeurs ont un accès complet à l'API WASM et bénéficient d'une prise en charge complète de l'API Web, ce qui leur donne un contrôle considérable sur le comportement Web.
Histoire du WASM
Suivant le principe « écrire une fois, exécuter n'importe où », WASM est apparu comme une solution puissante à un ensemble de défis de longue date. Depuis 2016, de nombreux programmes introduisent de nouvelles fonctionnalités via des langages spécifiques à un domaine (DSL), qui impliquent souvent des compromis entre maintenance, efficacité et sécurité. Il existe un besoin croissant d’une solution capable de fournir de nouvelles fonctionnalités à d’innombrables serveurs sans compromettre ces aspects.
Les lacunes des différentes solutions existantes ont été évaluées :
- Machine virtuelle système
Les démarrages et arrêts fréquents entraînent une surcharge excessive
Manque de visibilité du code pour assurer la sécurité
Trop abstrait sur les exigences de performance
- conteneur
Manque de visibilité du code pour assurer la sécurité
Inefficace en raison d'une abstraction de haut niveau
Les opérations fréquentes entraînent des frais généraux importants
- Machine virtuelle au niveau du langage
Nécessite des modifications fréquentes pour assurer la sécurité
Les VM embarquées, comme la V8, sont gourmandes en ressources
Adaptation lente du nouveau langage au modèle de sécurité
encore trop abstrait
- Architecture du jeu d'instructions (ISA)
Difficile de mettre en place un sandbox efficacement
Les projets Google précédents ont été transférés vers WASM
Manque de mise en œuvre mature
En 2018, le développement de WASM a pris de l'ampleur en mettant l'accent sur l'exécution sur diverses architectures, serveurs, matériel embarqué et même sur la prise en charge de plusieurs langages. Contrairement à Java, WASM est conçu sans compromettre la sécurité. En 2019, un modèle de composant a été introduit pour améliorer le module WASM, permettant l'interopérabilité entre les langues. Cela permet des solutions telles que l'écriture unique d'une bibliothèque HTTP et son utilisation dans plusieurs langues.
À ce jour, WASM dispose d’une gamme de capacités et est de plus en plus adopté dans des scénarios cloud natifs, y compris la blockchain. Ses avantages incluent :
haute performance
Taille binaire compacte
Portabilité multiplateforme
Prend en charge plusieurs langages, tels que C/C++, Rust, AssemblyScript, etc.
Exécuter dans le moteur JavaScript
Sandbox puissant avec limites de mémoire et de processeur
Temps de démarrage extrêmement rapides, généralement en millisecondes ou moins
La communauté WASM continue de travailler pour une meilleure intégration et de meilleures performances dans toutes les langues.
Comprendre l'évolution historique de WASM fournit un contexte précieux pour comprendre ses rôles actuels et potentiels dans divers contextes, y compris des projets blockchain comme Stylus. Ce contexte nous donne une compréhension nuancée lors de l’exploration des problèmes et des préoccupations entourant la mise en œuvre de WASM dans l’écosystème blockchain.
Questions et réponses sur le stylet
Prise en charge linguistique
L'évolution de WASM révèle pourquoi Stylus est un ajout intéressant à l'écosystème Arbitrum, mais elle met également en évidence certaines limites et préoccupations. L'une des préoccupations concerne la prise en charge linguistique. Bien que Stylus ait élargi la communauté des développeurs Arbitrum pour inclure des langages comme C++ et Rust, il n'a pas réussi à adopter des langages populaires comme JavaScript et Python.
Bien qu'il existe des projets préliminaires visant à intégrer Python et JavaScript dans WASM, ces efforts ne sont pas encore prêts pour une adoption généralisée en raison de défis liés au garbage collection et de problèmes de performances.
Compatibilité linguistique
Actuellement, Stylus prend en charge les SDK C/C++ et Rust, s'intégrant de manière transparente aux chaînes d'outils pour ces langages. Les développeurs peuvent même intégrer des bibliothèques tierces, telles que des implémentations cryptographiques natives, lors de la création de contrats intelligents. La principale limitation d’une telle démarche réside dans les coûts de gaz associés.
Bien que le SDK Rust en soit encore à ses balbutiements, les SDK Rust et C manquent de fonctionnalités. Par exemple, le SDK C ne prend pas en charge les fonctions exportées ABI et les modificateurs ne sont pas encore pris en charge dans aucun des deux SDK.
Actuellement, il n'existe pas d'environnement de test Stylus local, mais les développeurs peuvent exécuter des tests directement dans le SDK. Pour déployer des contrats intelligents, testnet est actuellement la seule option et ne prend pas encore en charge la vérification des contrats intelligents. Des efforts sont actuellement en cours pour intégrer divers jetons ERC et **[Uniswap V2]** à l'écosystème Stylus.
Le dilemme du choix de la langue
Le choix entre les langages spécifiques à un domaine (DSL), les DSL intégrés (eDSL) et les langages à usage général nécessite un compromis entre contrôle de bas niveau et abstraction de haut niveau. Le développement d'un tout nouveau DSL nécessite des investissements importants dans le développement de la chaîne d'outils et de l'écosystème. En revanche, en tant que sous-ensemble d'un langage à usage général, eDSL permet une intégration plus facile avec les outils existants et présente une courbe d'apprentissage plus courte. Par exemple, il serait avantageux de créer un eDSL dans un langage populaire comme JavaScript ou Python.
Un langage commun nécessite l'utilisation d'un SDK, qui introduit des outils supplémentaires, augmente la verbosité et rend le code moins expressif, ainsi que des appels d'API et des opérations d'objet plus longs.
Trouver le bon équilibre entre le choix de la langue et le développement eDSL peut être la clé pour attirer une communauté de développeurs plus large tout en fournissant des outils conviviaux. Selon les données actuelles, la principale communauté de développeurs de cryptographie est toujours concentrée autour d’Ethereum. Cependant, les plates-formes qui exploitent Rust pour les contrats intelligents, telles que Polkadot, Cosmos et Solana, gagnent également du terrain et se développent rapidement au sein de leurs communautés de développeurs.
performance
WASM améliore considérablement la vitesse d'exécution et réduit la taille des paquets. Bien que Stylus n'ait pas encore été déployé sur le réseau principal, les tests d'autres réseaux peuvent servir de référence utile. Les temps d'exécution observés sont 4 à 8 fois plus rapides et la taille compilée est réduite d'environ 50 %.
Stylus a actuellement une limite de taille sur ses contrats, plafonnée à environ 128 Ko non compressés. Cette limitation rend difficile le portage de gros contrats intelligents à partir d’autres langages tels que Solidity. Dans la base de code Stylus, cette limite est décrite ci-dessous :
Il convient de noter que WASM entraîne des frais généraux lors du démarrage et de l'arrêt. Pour les opérations légères, EVM peut en fait être plus rentable que WASM.
Interopérabilité avec EVM
EVM et WASM partagent les mêmes emplacements de stockage et la même arborescence d'état, ce qui facilite l'interopérabilité de Stylus avec EVM. Ceci est réalisé grâce à l'API EVM implémentée dans WASM, en utilisant le modèle d'E/S hôte populaire. Une liste complète des API EVM prises en charge démontre que l'interopérabilité est entièrement prise en charge.
Contrat précompilé personnalisé
Cet aspect est particulièrement passionnant car il représente un territoire inexploré. Les contrats précompilés personnalisés ont le potentiel d’apporter des primitives cryptographiques supplémentaires en chaîne avec des coûts d’exécution inférieurs. Ils peuvent également réduire le coût de l’inférence en introduisant des calculs tensoriels sous forme de contrats précompilés. Cependant, il ne semble y avoir aucun code existant lié aux contrats précompilés personnalisés. Bien qu'il existe des contrats précompilés pour les composants EVM, ils ne sont pas remplaçables à chaud.
Cette fonctionnalité est peut-être encore en cours de développement, tirant parti des capacités de WASM. L'EVM peut appeler des fonctions écrites en WASM puis les compiler en code machine.
Fonctionnalité réentrante
Contrairement à CosmWasm (qui adopte un modèle Actor sans réentrance), le SDK Rust de Stylus désactive par défaut la réentrance en tant qu'indicateur de fonctionnalité. Les développeurs ont la possibilité d'activer cette fonctionnalité manuellement.
L'activation de la réentrance nécessitera quelques ajustements de l'API. Les développeurs doivent notamment être prudents en ce qui concerne les précautions de sécurité telles que l'actualisation des caches de stockage pendant les appels.
Aperçu
Stylus ouvre de nouveaux cas d'utilisation qui seraient trop gourmands en carburant en utilisant uniquement l'EVM, tels que le cryptage haute performance, les jeux et l'IA. Il permet également de personnaliser des contrats précompilés, permettant ainsi aux développeurs d'ajouter leur propre cryptage et d'autres fonctionnalités de base sans attendre les mises à niveau. Dans le passé, nous avons vu certains écosystèmes non Ethereum adopter WASM, comme Cosmos et Polkadot. C'est la première fois que WASM est adopté par la communauté Ethereum. Dans l’ensemble, Stylus représente une évolution significative dans le développement de contrats intelligents et aidera Ethereum et Arbitrum à évoluer tout en maintenant l’interopérabilité avec toutes les applications existantes.
L'intégration de Stylus dans le SDK de couche 2 d'Arbitrum offre une plus grande flexibilité aux développeurs de couche 3. Ils peuvent désormais déplacer sur la chaîne des calculs intensifs qui dépassaient auparavant les limites de gaz, ouvrant ainsi de nouvelles possibilités. Les développeurs ne sont plus limités à Solidity mais peuvent également choisir Rust ou C++ si ces langages répondent mieux à leurs besoins et à leur expertise. Les contrats précompilés personnalisés permettent une migration transparente des fonctions cryptographiques, utilitaires et autres fonctions d'assistance préférées sur la chaîne pour des performances optimales. Écrire de la logique de bas niveau directement dans un langage adapté à chaque cas d’usage permet un développement plus fluide. Les développeurs peuvent se concentrer sur les fonctionnalités de base du produit plutôt que de recourir à des solutions de contournement pour éviter les coûts de gaz. En supprimant les contraintes de langue et de gaz, Stylus permet aux constructeurs de troisième niveau de créer dès le départ les expériences utilisateur les plus efficaces, en utilisant les outils adaptés à leur domaine.
Stylus démontre également la capacité d'Arbitrum à innover à grande échelle et à intégrer de nouvelles machines virtuelles. Ed Felten, co-fondateur et scientifique en chef d'Arbitrum & Offchain Labs a mentionné qu'Arbitrum est développé sur la base d'outils et de langages de programmation populaires dans l'industrie. Ils peuvent rédiger des tests plus rapidement et développer de nouvelles fonctionnalités en plus de leurs systèmes existants. OP est allé plus loin sur la voie de la ZKisation et s'est progressivement orienté vers l'idée du rollup hybride. Optimism travaille actuellement avec Risc0 pour utiliser Zeth afin de générer des preuves sans connaissance pour OPRU. Grâce à cette solution, Optimism n'a pas besoin d'apporter de modifications supplémentaires à OPRU. Si Zeth vous intéresse, vous pouvez lire ce que j'ai écrit avant [Twitter].
Nous avons vraiment hâte de voir les applications d'IA à Arbitrum. Actuellement, l’apprentissage automatique en chaîne nécessite beaucoup de ressources, ce qui rend le développement coûteux. Le ML sans connaissance peut réduire les coûts, mais introduit également une complexité supplémentaire significative pour les développeurs. Si nous pouvions implémenter des opérations tensorielles sous forme de contrats précompilés personnalisés via Stylus et les exécuter de manière native à une fraction du coût, cela ouvrirait de nouvelles possibilités pour un apprentissage automatique en chaîne hautes performances. En permettant aux développeurs de créer et de déployer rapidement des algorithmes ML sous forme de contrats précompilés faciles à intégrer dans un langage qu'ils connaissent bien, tel que Python, Arbitrum peut piloter la prochaine génération d'innovation en IA dans DeFi, GameFi, et plus encore. Les performances et la flexibilité de Stylus nous permettront de nous concentrer sur des architectures ML innovantes plutôt que sur l'optimisation du gaz. Nous sommes impatients de voir la créativité de la communauté appliquée à ce paradigme émergent.
