Pourquoi dit-on qu'Arbitrum Stylus est l'innovation technologique la plus importante de cette année pour les L2 ?
TechFlow SélectionTechFlow Sélection
Pourquoi dit-on qu'Arbitrum Stylus est l'innovation technologique la plus importante de cette année pour les L2 ?
L'intégration de Stylus dans le SDK Layer2 d'Arbitrum peut offrir une plus grande flexibilité aux développeurs de la couche trois.
Dédié à des analyses Web3 approfondiesAuteur : Yiping, IOSG Ventures
Avec le lancement en production de ZKRUs tels que zkSync et StarkNet, le paysage des Layer 2 évolue rapidement. Traditionnellement, les OPRUs comme Arbitrum ont été les premiers sur le marché, bénéficiant ainsi d’un écosystème plus développé. En revanche, les ZKRUs réalisent des percées technologiques en offrant un débit plus élevé et des frais réduits.
Ces derniers mois, davantage d’activités migrent de la couche 1 vers les couches 2 afin de profiter de transactions plus rapides et moins coûteuses. La TVL (valeur totale verrouillée) d’Ethereum est passée de près de 40 milliards de dollars à 20 milliards au cours de l’année écoulée. Cependant, la TVL des Layer 2 peint un tableau différent, avec une croissance significative indiquant une accélération dans leur adoption.
Arbitrum domine avec plus de 50 % de part de marché de la TVL sur les Layer 2, malgré les efforts des ZKRUs. Son avantage du premier entrant lui permet de conserver une position dominante.
L’analyse du nombre quotidien de transactions montre que les ZKRUs comme zkSync et StarkNet dépassent légèrement les OPRUs en termes de débit. Toutefois, l’avantage d’écosystème d’Arbitrum demeure, même s’il accuse un léger retard en TPS journalier.
Les OPRUs existent depuis plus longtemps que les ZKRUs. Néanmoins, ces derniers lancent leurs réseaux principaux et attirent des utilisateurs d’autres écosystèmes. En tant que leader du domaine OPRU, Arbitrum devrait contrer la montée des ZKRUs grâce à ses nouvelles mises à jour.
Arbitrum : Stylus
À mesure que les développeurs optimisent les technologies zero-knowledge et leurs coûts, les ZKRUs pourraient continuer à gagner des parts de marché grâce à leur avantage en matière d’évolutivité. Cependant, l’effet réseau d’Arbitrum lui confère une résilience face aux pressions concurrentielles. Grâce à des solutions innovantes telles que Stylus, Arbitrum peut compléter sa position de leader par des capacités techniques uniques et rester en tête de la course aux Layer 2.
En résumé, Stylus est un nouvel environnement révolutionnaire de contrats intelligents conçu pour Arbitrum, permettant aux développeurs d’écrire des programmes efficaces et interopérables en langages tels que Rust, C++ et Solidity.
Il ouvre le calcul universel à 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 des langages compilables en WASM peuvent s'exécuter nativement jusqu'à 10 fois plus vite qu’en Solidity, réduisant considérablement les frais de gaz. L’EVM reste pleinement opérationnelle, donc les contrats Solidity existants continuent de fonctionner normalement. Les deux machines virtuelles fonctionnent de manière synchronisée, permettant aux contrats écrits dans différents langages de s'appeler mutuellement tout en modifiant le même état sous-jacent de la blockchain.
Précompilations personnalisées
De plus, Stylus prend également en charge les précompilations personnalisées (« precompiles »).
Les précompilations sont des modules bas niveau utilisés sur Ethereum et Arbitrum pour exécuter très efficacement certaines fonctions cryptographiques ou utilitaires spécifiques. Par exemple, il existe des précompilations pour la vérification de signatures ECDSA ou le calcul de hachages SHA256.
Ajouter une nouvelle précompilation nécessite une mise à jour coordonnée de l’EVM par tous les validateurs, ce qui représente un seuil élevé. Avec Stylus, les développeurs peuvent facilement déployer leurs propres précompilations écrites en Rust ou C++.
Par exemple, une équipe pourrait utiliser une bibliothèque cryptographique écrite en C et la déployer inchangée sur Arbitrum. Cela permettrait à ces primitives cryptographiques de s’exécuter à une vitesse native ultra-rapide.
D'autres contrats peuvent appeler cette « précompilation » Stylus exactement comme ils appelleraient une précompilation native, afin d'utiliser cette technologie cryptographique. Toute la comptabilisation du gaz et les preuves de fraude fonctionnent automatiquement.
Cela permet aux équipes de prototyper des cryptosystèmes personnalisés, des courbes à couplage spécial ou d'autres primitives novatrices sans aucun support spécifique de chaîne. Même les chercheurs Ethereum pourraient itérer en amont des propositions EIP en les déployant sous forme de précompilations Stylus sur Arbitrum.
En donnant aux développeurs la capacité d’introduire nativement de nouvelles primitives cryptographiques sur la chaîne, Stylus élargit considérablement le champ des possibles. Les précompilations ne se limitent plus aux fonctionnalités prises en charge par l’EVM.
Fonctionnement de Stylus
Avant d’approfondir le rôle plus large du WASM dans l’univers blockchain, il est essentiel de comprendre comment Arbitrum orchestre la coexistence harmonieuse entre l’EVM et le WASM. Il ne s’agit pas simplement d’avoir deux moteurs indépendants ; c’est une relation synergique qui amplifie les forces de chacun.
L’architecture unique d’Arbitrum permet des opérations transparentes et synchronisées entre l’EVM et le WASM, grâce à un état unifié, aux appels inter-VM et à un modèle économique compatible.
Les contrats intelligents écrits en Solidity ou d'autres langages EVM sont compilés comme d'habitude en bytecode EVM. À l’exécution, ces contrats tournent sur l’EVM exactement comme aujourd’hui.
Pour les langages compilables en WASM, tels que Rust, C++ et C, le flux de travail est le suivant :
-
Les développeurs utilisent des compilateurs WASM standards comme Clang ou Rustc pour compiler leurs contrats intelligents en WASM.
-
Le bytecode WASM est téléchargé compressé sur la chaîne Arbitrum.
-
Le propriétaire du contrat appelle la méthode `compileProgram` du précompilé `ArbWasm`, qui configure en toute sécurité le programme WASM, calcule son coût en gaz et le compile en code natif optimisé pour le matériel des validateurs.
-
Lorsque le contrat est appelé, il s’exécute sur un runtime WASM tel que Wasmer, beaucoup plus rapide que l’EVM, économisant ainsi des frais de gaz.
La tarification WASM prélève du gaz avant chaque bloc de base, contrairement à l’EVM qui facture opcode par opcode. Cette méthode est plus efficace et garantit que les contrats ne s’emballent pas.
EVM vs WASM
Les deux machines virtuelles (VM) fonctionnent simultanément, permettant des appels mutuels tout en partageant le même état global. Une transaction peut être partiellement exécutée dans l’EVM, partiellement dans le WASM, les résultats étant combinés de manière fluide.
Attendez, comment deux VM peuvent-elles fonctionner ensemble de manière fluide et synchronisée ?
Polkadot y parvient via XVM. Contrairement à Polkadot, le WASM et l’EVM peuvent fonctionner de manière fluide et synchronisée sur Arbitrum pour plusieurs raisons clés :
-
État unique : les deux VM accèdent aux mêmes structures de données sous-jacentes et au même arbre d’état. Un contrat dans une VM peut lire/écrire à l’emplacement utilisé par un contrat dans l’autre VM. Cela assure une vision unifiée de l’état de la chaîne.
-
Appels inter-VM : lorsque une transaction interagit avec un contrat EVM, Geth la traite et fournit un résultat. Si ce contrat EVM appelle ensuite un programme WASM, la VM WASM prend le relais pour calculer cette partie du résultat.
-
Contexte partagé : les informations système comme les données de bloc ou l’adresse de l’expéditeur sont accessibles aux deux VM. Un contrat WASM peut obtenir le numéro de bloc comme un contrat Solidity.
-
Consensus unique : les validateurs exécutent les deux VM pour valider les transactions et parvenir à un consensus sur l’état correct de la chaîne. En cas de litige, le système unifié de preuve de fraude est activé.
-
Économie compatible : des concepts comme la mesure du gaz s’étendent aux deux VM, assurant un coût de calcul et une utilisation des ressources appropriés dans chaque environnement.
Pour les preuves de fraude, les validateurs effectuent une dichotomie (bissection) entre l’exécution EVM et WASM afin d’identifier si nécessaire toute étape invalide. La structure du WASM permet au système de garantir la terminaison et d’imposer la validité des preuves.
Blockchain | WASM
Arbitrum n’est pas le seul à reconnaître le potentiel transformatif du WebAssembly (WASM). Polkadot et Cosmos ont également intégré le WASM dans leurs écosystèmes, chacun offrant un ensemble d’avantages et de fonctionnalités uniques.
Polkadot autorise les utilisateurs à développer des contrats intelligents en WASM, avec deux langages supportés : AssemblyScript (un DSL intégré) et Ink! (similaire à Rust).
Cosmos, quant à lui, utilise CosmWasm comme runtime de contrat intelligent, permettant aux développeurs d’écrire des contrats en Rust.
Avant d’explorer pourquoi l’industrie blockchain adopte massivement le WASM, examinons les avantages spécifiques mis en avant par Cosmos et Polkadot :
Cosmos souligne les avantages suivants du WASM :
-
Compatibilité avec les bibliothèques Rust
-
Communauté diversifiée de développeurs
-
Sécurité renforcée, notamment contre les attaques de réentrance
-
Facilité de test
-
Hautes performances
Le runtime WASM de Polkadot présente ces caractéristiques :
-
Hautes performances
-
Interopérabilité avec l’EVM
-
Indépendance vis-à-vis de la plateforme
-
Taille binaire compacte
-
Support simultané de Rust et d’AssemblyScript (style TypeScript)
Bien que Polkadot, Cosmos et Arbitrum partagent certains avantages communs liés au WASM, chaque plateforme possède aussi ses attributs uniques.
L’adoption généralisée du WASM par ces principales blockchains témoigne de son importance croissante dans l’industrie, rendant crucial de comprendre pourquoi cette technologie devient rapidement un pilier de l’architecture blockchain moderne.
Pourquoi choisir WASM ?
Qu’est-ce que le WASM ?
Pour comprendre la synergie entre la blockchain et le WebAssembly (WASM), il est essentiel de d’abord saisir ce qu’est le WASM et les motivations derrière son développement.
Le WebAssembly est un format d'instructions binaire qui permet à du code de s’exécuter dans les navigateurs web à une vitesse proche du natif. Destiné à servir de cible de compilation pour divers langages de programmation (notamment C et Rust), il vise rapidité, efficacité et sécurité. Le WASM comble efficacement le fossé entre programmation web et programmation système, améliorant ainsi les performances et les fonctionnalités du web.
Le terme « Web » dans WebAssembly souligne sa capacité à fonctionner dans des environnements JavaScript (généralement dans les navigateurs). Dans ces contextes, les développeurs ont un accès complet aux API WASM et bénéficient d’un support étendu des API web, leur offrant un grand contrôle sur le comportement web.
Historique du WASM
Conforme au principe « écrivez une fois, exécutez partout », le WASM est apparu comme solution puissante à une série de défis persistants. En 2016, de nombreux programmes introduisaient de nouvelles fonctionnalités via des langages spécifiques au domaine (DSL), impliquant souvent des compromis entre maintenance, efficacité et sécurité. Il devenait urgent de trouver une solution capable d’ajouter de nouvelles fonctionnalités à d’innombrables serveurs sans sacrifier ces aspects.
Les insuffisances des solutions existantes ont été évaluées :
- Machines virtuelles système
-
Surcoût excessif dû aux démarrages et arrêts fréquents
-
Absence de visibilité sur le code pour garantir la sécurité
-
Abstraction trop élevée pour les besoins de performance
- Conteneurs
-
Absence de visibilité sur le code pour garantir la sécurité
-
Inefficacité due aux abstractions de haut niveau
-
Surcoût important lors d’opérations fréquentes
- Machines virtuelles linguistiques
-
Modifications fréquentes requises pour assurer la sécurité
-
VM intégrées (ex. V8), gourmandes en ressources
-
Adaptation lente des nouveaux langages au modèle de sécurité
-
Encore trop abstrait
- Architecture de jeu d'instructions (ISA)
-
Difficulté à sandboxer efficacement
-
Des anciens projets Google ont migré vers le WASM
-
Implémentations matures absentes
En 2018, le développement du WASM a pris de l’élan, avec un accent mis sur l’exécution sur diverses architectures, serveurs, matériels embarqués, et le support de multiples langages. Contrairement à Java, le design du WASM ne fait aucun compromis sur la sécurité. En 2019, un modèle de composants a été introduit pour améliorer les modules WASM et permettre l’interopérabilité entre langages — rendant possible par exemple d’écrire une bibliothèque HTTP une seule fois et de l’utiliser dans plusieurs langages.
Aujourd'hui, le WASM dispose d’une gamme complète de fonctionnalités et est de plus en plus adopté dans des scénarios cloud-native, y compris la blockchain. Ses atouts incluent :
-
Hautes performances
-
Taille binaire compacte
-
Portabilité multiplateforme
-
Support de multiples langages comme C/C++, Rust, AssemblyScript, etc.
-
Exécution dans les moteurs JavaScript
-
Sandboxing robuste avec limites mémoire et CPU
-
Temps de démarrage extrêmement rapides, généralement en millisecondes ou moins
La communauté WASM continue de travailler à une intégration et des performances accrues entre langages.
Comprendre l’évolution historique du WASM nous donne un contexte précieux pour appréhender son rôle actuel et potentiel dans divers environnements, y compris des projets blockchain comme Stylus. Ce contexte nous permet d’aborder avec nuance les questions et inquiétudes relatives à l’implémentation du WASM dans l’écosystème blockchain.
Stylus Q&A
Support des langages
L'évolution du WASM explique pourquoi Stylus constitue un ajout passionnant à l’écosystème Arbitrum, mais elle met aussi en lumière certaines limitations et inquiétudes. L'une d’entre elles concerne le support des langages. Bien que Stylus élargisse la communauté des développeurs Arbitrum à des langages comme C++ et Rust, il reste en retrait concernant des langages populaires tels que JavaScript et Python.
Bien qu’il existe des projets préliminaires visant à intégrer Python et JavaScript au WASM, ces tentatives ne sont pas encore prêtes pour une adoption massive en raison de défis liés à la gestion de la mémoire (garbage collection) et aux performances.
Compatibilité linguistique
Actuellement, Stylus prend en charge les SDK C/C++ et Rust, s’intégrant parfaitement aux chaînes d’outils associées. Les développeurs peuvent même intégrer des bibliothèques tierces, comme des implémentations cryptographiques natives, lors de la création de contrats intelligents. La principale limitation ici reste le coût en gaz associé.
Bien que le SDK Rust en soit encore à ses débuts, les SDK C et Rust manquent encore certaines fonctionnalités. Par exemple, le SDK C ne prend pas en charge l’exportation de fonctions ABI, et les modificateurs ne sont pas encore disponibles dans les deux SDK.
Actuellement, aucun environnement de test Stylus natif n’existe, mais les développeurs peuvent exécuter des tests directement dans le SDK. Pour le déploiement de contrats intelligents, seul le réseau de test est disponible, et la vérification de contrat n’est pas encore prise en charge. Des efforts sont en cours pour intégrer divers jetons ERC et **[Uniswap V2]** à l’écosystème Stylus.
Dilemme du choix du langage
Le choix entre langages spécifiques au domaine (DSL), DSL intégrés (eDSL) et langages généraux implique un compromis entre contrôle de bas niveau et abstraction de haut niveau. Créer un nouveau DSL nécessite un investissement massif dans la chaîne d’outils et l’écosystème. En revanche, un eDSL, en tant que sous-ensemble d’un langage général, permet une intégration plus facile avec les outils existants et une courbe d’apprentissage plus douce. Par exemple, créer un eDSL dans des langages populaires comme JavaScript ou Python serait bénéfique.
Les langages généraux nécessitent l’utilisation de SDK, ce qui ajoute des outils supplémentaires, augmente la verbosité, réduit l’expressivité du code et allonge les appels d’API et manipulations d’objets.
Trouver le bon équilibre entre choix du langage et développement d’eDSL pourrait être la clé pour attirer une communauté plus large de développeurs tout en fournissant des outils conviviaux. Selon les données actuelles, les principales communautés de développeurs crypto restent concentrées autour d’Ethereum. Toutefois, les plateformes utilisant Rust pour les contrats intelligents, comme Polkadot, Cosmos et Solana, gagnent en notoriété et voient leur communauté de développeurs croître rapidement.
Performance
Le WASM améliore considérablement la vitesse d’exécution et réduit la taille des paquets. Bien que Stylus ne soit pas encore déployé en production, les benchmarks d’autres réseaux peuvent servir de référence utile. Des gains de 4 à 8 fois en temps d’exécution et une réduction d’environ 50 % de la taille compilée ont été observés.
Stylus impose actuellement une limite de taille à ses contrats, d’environ 128 Ko non compressés. Cette limite rend difficile le portage de grands contrats intelligents depuis d’autres langages comme Solidity. Dans le dépôt de code de Stylus, cette limite est définie comme suit :
Notons que le WASM entraîne un certain surcoût au démarrage et à l’arrêt. Pour les opérations légères, l’EVM peut en réalité être plus rentable que le WASM.
Interopérabilité avec l’EVM
L’EVM et le WASM partagent les mêmes emplacements de stockage et l’arbre d’état, facilitant ainsi l’interopérabilité de Stylus avec l’EVM. Ceci est rendu possible par l’implémentation dans le WASM des API EVM, utilisant le modèle courant d’entrée/sortie hôte. La liste complète des API EVM supportées indique un soutien exhaustif de l’interopérabilité.
Contrats de précompilation personnalisés
Ce point est particulièrement excitant car il explore un territoire inconnu. Les contrats de précompilation personnalisés pourraient introduire sur la chaîne de nouvelles primitives cryptographiques à moindre coût d’exécution. Ils pourraient aussi réduire le coût de l’inférence en introduis
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
IOSG Ventures
