La récente mise à jour d'Arbitrum comprend la mise à niveau de Stylus VM, offrant plusieurs améliorations : Prise en charge linguistique étendue Coûts et utilisation de la mémoire réduits Pré-compilateurs personnalisables Compatibilité EVM Ces améliorations proviennent de l’intégration de WASM, réputé pour ses nombreux avantages au sein des environnements cloud natifs. De plus amples détails sur le rôle de WASM seront abordés dans les sections suivantes. Pionniers Arbitrum a introduit WASM dans sa chaîne, mais ce n'est pas la première plateforme pour le faire. Polkadot autorisait auparavant la création de contrats intelligents WASM. Il propose pour cela deux langages : un script assembleur similaire à un DSL embarqué et un langage inspiré de Rust appelé ink ! De même, Cosmos utilise CosmWasm pour l'exécution de ses contrats intelligents. Les développeurs peuvent créer des contrats intelligents en utilisant Rust ici. Avant d'explorer l'affinité de la blockchain pour WASM, passons en revue les raisons pour lesquelles Cosmos et Polkadot ont choisi WASM. Cosmos vante WASM pour ces avantages : Compatibilité de la bibliothèque Rust Une large communauté de développeurs Sécurité améliorée, y compris la prévention des attaques de réentrée Procédures de test simplifiées Une performance supérieure Le runtime WASM de Polkadot présente des fonctionnalités telles que : Performance exceptionnelle Interopérabilité EVM Indépendance de la plateforme matérielle et logicielle Format compact Prise en charge de Rust et Assembly Script, semblable à Typescript Polkadot, Cosmos et Arbitrum partagent plusieurs avantages induits par WASM. Cependant, Arbitrum propose des offres distinctives dont nous parlerons plus tard, ainsi que les spécificités de Cosmos. ÉTAIT M Examinons ce qu'est WASM et ses motivations. Qu’est-ce que WASM ? WebAssembly (WASM) est un format d'instruction binaire. Il permet au code de s'exécuter à des vitesses comparables à celles des applications natives, notamment dans les navigateurs Web. En tant que cible de compilation pour des langages tels que C et Rust, elle est optimisée pour la vitesse, l'efficacité et la sécurité. WASM améliore considérablement les performances Web et étend les fonctionnalités Web. WASM est étroitement lié au Web, car il fonctionne dans des environnements JavaScript tels que les navigateurs. Dans ces environnements, les développeurs ont un accès complet aux API WASM ainsi qu'à une prise en charge complète des API Web. Ce contrôle permet aux développeurs d'affiner les interactions Web. L’évolution du WASM Le concept de WASM tourne autour de l’idéal d’écrire du code une seule fois pour l’exécuter n’importe où. En 2016, les programmes ont fréquemment introduit de nouvelles fonctionnalités via les langages spécifiques au domaine (DSL). La création d'un DSL impliquait d'équilibrer la maintenance, l'efficacité et la sécurité. L'industrie recherchait une méthode permettant de déployer des fonctions sur de nombreux serveurs sans compromettre ces aspects. Différentes solutions ont été examinées, chacune comportant son propre ensemble de défis : souffraient de surcharge, de manque de visibilité du code pour des raisons de sécurité et étaient trop abstraites pour des performances élevées. Les machines virtuelles système manquaient également de visibilité sur le code et étaient tout aussi abstraits, avec une surcharge importante. Les conteneurs nécessitaient de fréquentes modifications pour des raisons de sécurité, entraînaient une surcharge des machines virtuelles intégrées comme la V8 et mettaient du temps à adopter de nouveaux langages pour s'adapter aux modèles de sécurité. Les machines virtuelles au niveau du langage étaient difficiles à modifier pour un sandboxing efficace et manquaient d'implémentations matures. Les architectures de jeux d'instructions (ISA) WASM est apparu comme une solution. Le développement des compilateurs WASM a commencé et, en 2018, le concept de compatibilité universelle du code sur diverses architectures et appareils a été élargi. Contrairement à Java, l’objectif n’était pas de faire de compromis sur la sécurité. En 2019, le modèle de composants a été introduit, élevant les modules WASM pour l'interopérabilité entre les langues. Cette innovation a permis, par exemple, la création d'une bibliothèque HTTP universelle applicable dans différents langages, abordant de manière innovante des problèmes complexes. WASM aujourd'hui WASM possède une gamme de fonctionnalités impressionnantes : : le code WASM s'exécute efficacement et rapidement. Haute performance : Le format binaire de WASM garantit un faible encombrement. Taille compacte : il permet au même bytecode de fonctionner sur n'importe quel environnement d'exécution compatible WASM. Portabilité : WASM prend en charge un large éventail de langages, du C/C++ à Rust en passant par Go et Swift, entre autres. Prise en charge des langages : WASM fonctionne de manière transparente avec les moteurs JS. Compatibilité des moteurs JavaScript : un bac à sable par défaut robuste restreint l'accès à la mémoire et au processeur pour éviter les interférences externes. Sandboxing : les modules WASM démarrent généralement en millisecondes. Démarrage rapide La communauté WASM améliore activement l'intégration et les performances dans différents langages de programmation. Style Explorer le potentiel de WASM et son utilisation dans les blockchains nous ramène aux limites d’Arbitrum Stylus. Fonctionnement du stylet Voici une description simplifiée du fonctionnement de Stylus : Les développeurs utilisent des compilateurs WASM standard, comme Clang ou Rustc, pour compiler leurs contrats intelligents vers WASM. Le bytecode WASM résultant est ensuite téléchargé sur la chaîne Arbitrum dans un état compressé. Grâce à la méthode de la précompilation , le bytecode subit une instrumentation pour la sécurité, le comptage de gaz et est compilé en code natif adapté au matériel du validateur. Cette étape est cruciale pour améliorer les performances et la sécurité. compileProgram ArbWasm Lors de son appel, le contrat s'exécute sur un moteur d'exécution WASM, tel que Wasmer, qui est nettement plus rapide et plus économe en gaz que l'EVM. La troisième étape, apparemment supplémentaire, est en réalité vitale. La conversion du code WASM en code machine natif accélère les vitesses d'exécution. De plus, cette phase de compilation supplémentaire permet d'éviter les « bombes de compilation ». Une « bombe de compilation » est un code malveillant conçu pour épuiser les ressources du système pendant la compilation, pouvant potentiellement planter ou bloquer le compilateur. Il s'agit d'une attaque par déni de service visant à entraver le processus de développement logiciel. Préoccupations concernant le stylet Support linguistique Stylus a élargi la communauté des développeurs d'Arbitrum pour inclure C++ et Rust. Cependant, il doit encore englober les communautés de développeurs les plus répandues d’aujourd’hui. Il facilite l'exécution de contrats intelligents dans les navigateurs mais ne prend pas encore en charge JavaScript et Python. Il existe des projets à leurs débuts qui tentent de relier Python et JavaScript à WASM. Mais ceux-ci ne sont pas prêts à être adoptés à grande échelle en raison de la complexité du garbage collection et des problèmes de performances. Compatibilité linguistique Stylus prend actuellement en charge C/C++ et Rust via ses SDK. Ces SDK sont compatibles avec les outils des langages respectifs. Ils permettent également l’intégration de bibliothèques tierces, comme la cryptographie native. La principale contrainte est le coût du gaz associé à ces bibliothèques. Le SDK Rust en est à sa phase naissante et manque de certaines fonctionnalités. Le SDK C ne prend pas en charge l'exportation de fonctions avec ABI. De plus, aucun des deux SDK ne prend en charge l’utilisation de modificateurs. Pour l’instant, Stylus ne dispose pas d’environnement de test local. Les développeurs sont encouragés à effectuer des tests dans les SDK. Le testnet est la seule option pour exécuter des contrats intelligents sur Stylus. Cependant, le testnet n’a pas encore mis en œuvre la vérification des contrats intelligents. Des travaux sont en cours pour porter divers jetons et plates-formes ERC comme vers Stylus. Uniswap V2 Choix de la langue Choisir entre un langage spécifique au domaine (DSL), un DSL intégré (eDSL) ou un langage de programmation général est un véritable défi. Les développeurs doivent peser les avantages de travailler « au plus près du métal » pour le contrôle et la facilité d'utilisation offerte par des abstractions de niveau supérieur, qui peuvent limiter la flexibilité. La création d'un nouveau DSL nécessite du temps pour développer ses chaînes d'outils et son écosystème. Un eDSL, en tant que sous-ensemble d'un langage de programmation général, conserve la même sémantique et la même syntaxe. Il permet aux développeurs d'utiliser des langages et des outils existants, ce qui peut simplifier le processus d'apprentissage. Un eDSL offre également une meilleure interopérabilité avec le code à usage général. Par exemple, un eDSL pour JavaScript ou Python serait stratégique pour impliquer les plus grandes communautés de développeurs. Les langages de programmation généraux nécessitent l'utilisation d'un SDK pour le développement. Cela ajoute des couches d'outils, augmente la verbosité et réduit l'expressivité. Cela peut également entraîner de longs appels d'API et des opérations d'objet complexes. Choisir la bonne langue et créer un eDSL pourrait être un compromis idéal. Il pourrait attirer des développeurs issus de communautés populaires et proposer des outils conviviaux. Les données actuelles montrent que la communauté Ethereum reste la plus grande parmi les développeurs de cryptographie. Cependant, des écosystèmes comme Polkadot, Cosmos et Solana, qui utilisent Rust pour les contrats intelligents, attirent également un nombre important de développeurs et connaissent une croissance rapide. Performance WASM a le potentiel d’améliorer considérablement la vitesse d’exécution et de réduire la taille du bundle. Bien que Stylus n'ait pas été déployé sur le réseau principal, les tests d'autres réseaux servent de référence utile. Ces benchmarks indiquent que les temps d'exécution peuvent être réduits de 4 à 8 fois et que la taille compilée peut être réduite de moitié. Stylus impose une limite sur la taille des contrats, qui est d'environ 128 Ko non compressés. Cette contrainte rend difficile la migration de très gros contrats intelligents depuis des langages comme Solidity vers Stylus. Cette limitation est évidente dans la base de code Stylus : // arbos/programs/programs.go const MaxWasmSize = 128 * 1024 // Maximum WASM size allowed const initialFreePages = 2 // Number of initial free pages const initialPageGas = 1000 // Gas cost for an initial page const initialPageRamp = 620674314 // Adjusts for a target size cost const initialPageLimit = 128 // Maximum number of pages allowed const initialInkPrice = 10000 // Ink price per EVM gas const initialCallScalar = 8 // Scalar for call cost Il est important de noter que WASM entraîne des frais généraux pour le démarrage et l'arrêt. Pour les opérations très légères, EVM peut être plus rentable que WASM. Interopérabilité EVM-WASM EVM et WASM utilisent les mêmes emplacements de stockage et la même arborescence d'état. Stylus atteint l'interopérabilité avec EVM en implémentant des API EVM dans WASM. Cette intégration utilise le mode Host I/O largement adopté dans WASM. Vous trouverez ci-dessous la liste complète des API EVM prises en charge dans WASM, indiquant une prise en charge complète de l'interopérabilité. read_args write_result storage_load_bytes32 storage_store_bytes32 call_contract delegate_call_contract static_call_contract do_call create1 create2 do_create read_return_data return_data_size emit_log account_balance account_codehash evm_gas_left evm_ink_left block_basefee block_coinbase block_gas_limit block_number block_timestamp chainid contract_address msg_reentrant msg_sender msg_value native_keccak256 tx_gas_price tx_ink_price tx_prigin memoery_grow console_log_text console_log console_tee Précompilations personnalisées Les précompilations personnalisées sont un concept innovant. Ils ont le potentiel d’intégrer des primitives cryptographiques avancées en chaîne à des coûts d’exécution réduits. Par exemple, les calculs tensoriels pourraient être précompilés pour réduire les coûts de l’apprentissage automatique en chaîne. Cependant, il n'existe aucune preuve d'une fonctionnalité de précompilation personnalisée dans la base de code actuelle. Bien que des précompilations existent pour l'EVM, elles ne sont pas conçues pour être échangeables. Il est probable que ces fonctionnalités soient encore en cours de développement, exploitant les capacités de WASM. Cela permettrait à EVM d'appeler des fonctions écrites par WASM, qui sont ensuite compilées en code machine. Réentrée Contrairement au modèle d'acteur de CosmWasm, qui ne prend pas en charge la réentrance, le SDK Rust de Stylus inclut la réentrance comme fonctionnalité facultative. Par défaut, cette fonctionnalité est désactivée. Les développeurs ont le choix d’activer la réentrée dans leurs contrats. L'activation de la réentrance affecte l'API puisque les développeurs doivent s'assurer de vider le cache de stockage pendant les appels et prendre en compte d'autres mesures de sécurité. Cette précaution est essentielle pour prévenir les vulnérabilités potentielles associées aux appels réentrants. Conclusion WASM gagne en popularité dans le domaine cloud natif, de nombreuses blockchains l'adoptant pour l'exécution de contrats intelligents. Bien qu'Arbitrum ne soit pas le pionnier de cette intégration, sa mise en œuvre pourrait avoir un impact considérable. WASM n'est pas en mesure de remanier complètement le paysage de la blockchain ou de remplacer EVM. Cependant, cela pourrait renforcer l'avantage d'Arbitrum face aux zk-rollups émergents. Le terme « EVM+ » utilisé par Arbitrum décrit bien ce scénario. EVM pose les bases des plateformes de contrats intelligents, et WASM pourrait apporter une amélioration supplémentaire des performances à Arbitrum.
