ViaBTC Capital | Une réintroduction aux nouvelles chaînes publiques méta liées du point de vue de la langue du mouvement (I)

En juillet 2022, sous l’impulsion des investisseurs en capital, de multiples nouvelles chaînes publiques liées à Meta sont progressivement apparues. Soutenues par des équipes solides, des technologies sous-jacentes remarquables, ainsi qu’un débit de transactions exceptionnel, ces chaînes ont été favorisées par les principaux investisseurs en capital et ont obtenu des valorisations élevées malgré des conditions de marché baissières. Par exemple, Aptos a levé 350 millions de dollars, Sui a reçu 236 millions de dollars et Linera a levé 6 millions de dollars lors d’un tour de table mené par a16z.

Dans la course aux chaînes publiques d’aujourd’hui, les chaînes publiques méta liées dirigées par Aptos et Sui sont en concurrence avec les chaînes publiques de niveau 1 et 2 telles qu’Ethereum. Pour résoudre le trilemme des chaînes de blocs, ces chaînes cherchent à assurer la sécurité et la facilité d’utilisation tout en accélérant les transactions par la parallélisation à l’aide de Move, un langage de programmation unique développé par Meta. Aujourd’hui, nous allons partir du langage Move, réintroduire Aptos et Sui, et expliquer leur popularité auprès des investisseurs en capital.

La langue de Move

Origine

Move, développé à l’origine par Facebook (maintenant Meta), est un langage de programmation de contrats intelligents pour la chaîne Libra (maintenant Diem). Il est conçu pour être un langage indépendant de la plateforme afin de permettre l’utilisation de bibliothèques, d’outils et de communautés de développeurs communs sur différentes chaînes de blocs avec des modèles de données et d’exécution très différents. Après l’échec de Libra, les développeurs de Move ont exploré différentes directions :

• Sui a apporté des améliorations à Move en imposant des restrictions supplémentaires aux codes écrits en Move ;
• Aptos a utilisé Move pour explorer l’exécution parallèle à haute performance ;
• Starkcoin s’est engagé dans une mise à l’échelle fractale de la couche 2 à la couche 3.$

Les origines de Move proviennent en grande partie des problèmes renommés des langages de programmation de chaînes de blocs existants.

Figure 1 : Développement des langages de contrats intelligents

Comme le montre la figure 1, les langages de programmation des chaînes de blocs n’ont cessé d’évoluer. À ses débuts, le BTC utilisait Script, un langage de programmation extrêmement léger, qui constituait également une excellente solution de multi-signature. Malgré cela, Script est Turing-incomplet, ce qui signifie qu’il ne permet pas de mettre en œuvre une logique complexe. Par conséquent, l’apparition de Solidity permet l’exécution de contrats intelligents, ce qui compense le manque de complétude de Turing de Script. De plus, Solidity et javascript sont très similaires dans leur utilisation, ce qui a minimisé le coût d’apprentissage : les développeurs de Dapp n’ont pas besoin d’apprendre comment fonctionnent les chaînes de blocs, il leur suffit d’écrire des codes en Solidity et de les faire déployer sur une EVM. Enfin, un contrat intelligent ou une Dapp fonctionnelle sera générée après que les mineurs auront emballé et mis les codes sur la chaîne de blocs.

La plupart des alternatives existantes de la couche 1 sont construites sur une EVM et développées en Solidity. Cependant, ces chaînes publiques souffrent également de certains défauts techniques, notamment le problème de mise à l’échelle d’Ethereum et l’insécurité de la mémoire de Solidity. D’autres solutions ont donc vu le jour. Par exemple, Solana aborde le problème de l’insécurité de la mémoire de Solidity en utilisant Rust, qui est un langage de programmation compilé qui permet aux développeurs de vérifier la sécurité du langage et du programme pendant le processus de compilation. En outre, compte tenu de la nécessité de développer un écosystème, Rust existe depuis longtemps et de nombreux développeurs ont déjà adopté ce langage. Comme il utilise Rust, ces développeurs sont prêts à développer des applications sur Solana et à emballer la chaîne par le biais de l’algorithme de consensus POH. Cela leur permet de compléter le processus de validation et de pallier enfin les défauts de la chaîne EVM.

Ceci étant dit, Solana apporte aussi son lot de nouveaux problèmes. Par exemple, la chaîne a fait un compromis sur la décentralisation, et elle est gérée par les nœuds de manière centralisée. Cela signifie également que le réseau n’est pas aussi stable qu’Ethereum. Solana a fait ce compromis parce que ses utilisateurs sont plus sensibles au prix, avec une demande de stabilité plus faible. En outre, comme le langage Rust nécessite un coût d’apprentissage élevé, la plupart des développeurs choisissent encore d’utiliser Solidity. Rust n’a pas non plus réussi à attirer les développeurs vers la cryptoshère comme Solana l’avait prévu. Au contraire, il est devenu un obstacle, et de nombreux développeurs sont réticents à consacrer du temps à l’apprentissage de Rust.

Cela a déclenché l’apparition de Move. Avant que les développeurs ne commencent à travailler, le langage Move a déjà regroupé les protocoles, les actifs et les normes NFT en modules, avec Rust comme couche inférieure. En d’autres termes, les développeurs n’ont plus besoin d’étudier la logique sous-jacente de Rust, et ils peuvent se lancer après avoir appris les différents modules du langage. Move combine la stabilité et la sécurité de Rust avec la facilité d’utilisation de Solidity, ce qui permet aux développeurs de travailler à un rythme rapide tout en assurant la sécurité de leurs projets.

Malgré ses nombreux avantages, Move, comme toute autre technologie, n’est pas parfait. En tant que nouveau langage de programmation, Move n’est plus maintenu que par les membres du Mysten Labs. En outre, les développeurs rencontrent encore des problèmes lors de l’utilisation de Move, et les performances du langage doivent être vérifiées lors des futurs développements technologiques.

Caractéristiques

Dans la documentation du développeur d’Aptos, Move est présenté comme suit :

“Move met l’accent sur la rareté et le contrôle de l’accès. Un actif dans Move peut être représenté par ou stocké dans une ressource. La rareté est appliquée par défaut car les structs ne peuvent pas être dupliqués. Seuls les structs qui ont été explicitement définis au niveau de la couche bytecode comme étant des copies peuvent être dupliqués.”

La rareté est définie pour les types de données intégrés de Move, tels que les adresses, les signatures et les actifs. En particulier, les valeurs des actifs ne peuvent pas être copiées ou modifiées arbitrairement. Dans un langage de programmation ordinaire, de tels chiffres sont représentés par des types numériques courants qui permettent une addition et une soustraction arbitraires. Dans ces langages, les actifs ne sont donc jamais “rares”. En outre, Solidity ne dispose pas des modules bien remplis de Move, c’est pourquoi il reste inférieur à Move en termes de prise en charge de la rareté.

“Le contrôle d’accès provient à la fois de la notion de comptes et des privilèges d’accès aux modules. Un module dans Move peut être soit une bibliothèque, soit un programme qui peut créer, stocker ou transférer des biens. Move s’assure que seules les fonctions publiques du module sont accessibles aux autres modules. À moins qu’une structure ne possède un constructeur public, elle ne peut être construite que dans le module qui la définit. De même, les champs d’une structure ne peuvent être accédés et mutés qu’au sein de son module ou via des accesseurs et des régleurs publics.”

En d’autres termes, Move isole les différents modules et impose des restrictions plus rigoureuses. Cette isolation se traduit au niveau de l’exécution du code plutôt qu’au niveau du code. Par exemple, le module X ne peut pas appeler la fonction de transfert de Asset (l’objet) dans le module Y, ce qui les oblige à rester isolés.

La rareté et le contrôle d’accès rendent la programmation des chaînes de blocs plus sûre et plus facile : Les opérations telles que le traitement des transferts qui nécessitaient auparavant beaucoup de soins de la part des développeurs sont simplifiées par Move. Par exemple, auparavant, lorsque l’utilisateur A transférait 100 $ à l’utilisateur B, les développeurs devaient soustraire 100 $ du compte de l’utilisateur A et ajouter 100 $ au compte de l’utilisateur B (l’opération réelle est beaucoup plus compliquée), et les comptes ne seraient pas équilibrés si une erreur se produisait dans le processus. Cependant, avec Move, les développeurs peuvent simplement créer un type de compte et appeler la fonction de transfert, et la logique de transaction telle que le solde insuffisant est facilement disponible. En termes simples, Move regroupe différentes fonctions dans des modules et interdit aux développeurs de désassembler et d’exécuter les fonctions par eux-mêmes. Cela permet d’éviter de nombreux bogues issus de codes écrits à la main et permet une programmation sûre et facile. Bien entendu, cette approche a aussi, plus ou moins, sacrifié la flexibilité de la programmation.

Dans Move, l’expéditeur d’une transaction est représenté par un signataire, propriétaire vérifié d’un compte spécifique. Le signataire dispose du plus haut niveau de permission dans Move et est la seule entité capable d’ajouter des ressources à un compte. De plus, un développeur de module peut exiger la présence d’un signataire pour accéder aux ressources ou modifier les actifs stockés dans un compte. Le langage en lui-même est très simple, avec des concepts généraux tels que les structures, les entiers et les adresses. Cependant, il ne dispose pas de concepts spécifiques à la chaîne de blocs, tels que les comptes, les transactions, le temps, la cryptographie, etc. Nous pouvons donc constater que dans un tel cadre, les nouvelles chaînes publiques basées sur Move ont choisi une voie qui diffère des autres chaînes publiques, ce qui leur permet de proposer des fonctionnalités uniques.

Comparaison avec d’autres langues

Figure 2 : Une comparaison entre Move et d’autres langues

Source : https://aptos.dev/guides/move-guides/move-on-aptos

Ici, nous allons comparer Move, Solidity et SeaLevel de Solana sous cinq aspects :

• En termes de stockage de données, Move stocke les données dans le compte du propriétaire. En d’autres termes, avec Move, les propriétaires ont un contrôle total sur leurs données, et leurs comptes sont utilisés comme espace de stockage de base ; SeaLevel stocke les données dans le compte du propriétaire associé à un programme, et le programme constitue l’espace de stockage de base spécifique ; Solidity stocke les données dans le compte associé à un contrat intelligent, et le contrat intelligent représente l’espace de stockage de base.
• En ce qui concerne la parallélisation, Move est capable de déduire la parallélisation au moment de l’exécution ; Sealevel exige de spécifier dans la transaction tous les comptes et programmes auxquels on accède, ce qui constitue une parallélisation conditionnelle ; Solidity ne prend pas en charge la parallélisation.
• En ce qui concerne la sécurité des transactions, Move s’appuie sur les numéros de séquence (types de données natifs pris en charge par Move) ; SeaLevel adopte l’unicité des transactions et la mémorisation des transactions ; Solidity utilise des nonces pour simuler les numéros de séquence (tous les langages conventionnels génèrent des nonces temporaires pour atteindre un consensus).
• En ce qui concerne la sécurité des types, Move utilise des structures de module et des génériques (rareté et contrôle d’accès) ; comme les langages de programmation ordinaires, SeaLevel s’appuie sur des structures de programme ; Solidity adopte des types de contrats intelligents, et l’accès est contrôlé dans l’unité des contrats, ce qui crée certaines difficultés opérationnelles. De plus, toutes les logiques ne sont pas des contrats. En comparaison, Move utilise les comptes et les modules comme unité, ce qui est beaucoup plus intuitif.
• Pour ce qui est de l’appel de fonctions, Move présente une répartition statique non générique, et SeaLevel utilise également une répartition statique. Solidity, en revanche, adopte le dispatch dynamique parce qu’il s’agit d’une modification du moteur V8 basée sur Javascript et qu’il hérite de toutes les caractéristiques de ce langage dynamique. Le dispatching dynamique est souvent considéré comme plus flexible mais moins sûr.

L’analyse ci-dessus montre que Move est statique et garantit que les ressources sont sauvegardées et ne seront pas dupliquées ou détruites accidentellement. Par rapport aux autres langages, Move est supérieur en termes de sécurité, de vitesse et de facilité d’utilisation.

Aptos et Sui

Après avoir appris les caractéristiques de Move, intéressons-nous maintenant à Aptos et Sui, deux nouvelles chaînes publiques. Équipées de Move, elles ont chacune proposé une nouvelle solution pour résoudre le trilemme de la chaîne de blocs.

Aptos

Équipe

Avery Ching, cofondateur et directeur technique d’Aptos, a travaillé comme ingénieur logiciel en chef chez Meta pendant plus de dix ans. Il est également l’ancien chef de la technologie de Novi, un projet de portefeuille crypto de Meta. En outre, la plupart des développeurs et des chercheurs de l’équipe d’Aptos, dont Alden Hu et Dahlia Malkhi, ont participé au développement de Diem et de Novi. Récemment, Austin, l’ancien responsable du marketing chez Solana, a annoncé qu’il rejoindrait Aptos le mois prochain en tant que directeur de l’écosystème.

Investissement :

Performance : La chaîne de blocs d’Aptos est capable de traiter plus de 10 000 transactions par seconde. Idéalement, Aptos sera en mesure de traiter 160 000 transactions par seconde à l’avenir.

Caractéristiques :

I. Le moteur de parallélisation Block-STM : Aptos a conçu un moteur d’exécution parallèle en mémoire, efficace et multithreadé. Il est construit pour gérer tous les conflits en interne et s’adapter automatiquement aux charges de travail.

II. Le protocole de consensus BFT : A partir du consensus original hotstuff, le diemBFT d’Aptos a connu quatre itérations. Récemment, Aptos a ajouté un pacemaker actif qui utilise les timeouts pour synchroniser les validateurs beaucoup plus rapidement qu’en attendant des timeouts croissants. Grâce à cet ajout, les blocs sont validés en aussi peu que deux allers-retours sur le réseau, ce qui fait de la finalité en moins d’une seconde un cas courant. De plus, Aptos a introduit un système de réputation qui résout le problème des validateurs non réactifs en vérifiant les données on-chain et en changeant automatiquement la rotation des leaders.

IV. Synchronisation d’état : Une synchronisation d’état efficace est essentielle dans les systèmes à haut débit et à faible latence. Aptos exploite l’historique du grand livre authentifié et les preuves d’état certifiées offertes par les validateurs, les nœuds complets et les autres réplicateurs pour fournir un protocole de synchronisation flexible et configurable. Plus précisément, les participants au réseau peuvent choisir différentes stratégies de synchronisation pour optimiser leurs cas d’utilisation et leurs exigences.

Progrès :

• En mars, Aptos a activé son testnet, qui compte plus de 20 000 nœuds de validation ;
• Fin juin, Aptos a lancé un programme de subvention de l’écosystème de 200 millions de dollars, couvrant six catégories : outils pour développeurs, SDK, bibliothèques, documentation, guides et tutoriels. La subvention sera principalement utilisée pour les outils et les cadres de développement, la gouvernance, le DeFi et les NFTs ; les contributions au protocole de base : normes de jetons, bibliothèques, mises à niveau du protocole, etc. ; l’open source et les biens publics ; les initiatives d’éducation ; les applications. Aujourd’hui, il y a bien plus de 100 projets construits sur le réseau. Au stade actuel, de nombreuses équipes se sont engagées dans le développement et le déploiement sur le réseau de test, notamment le protocole CLOB ultra-parallèle Econia, le portefeuille multi-signatures Hive alimenté par Move, l’application de trading Pontem Network basée sur AMM, etc.
• Le réseau principal sera lancé en septembre.

Nous poursuivrons dans le prochain article.