La seconde moitié de l’année 2024 promet d’être vraiment intéressante pour Starknet, qui a récemment dévoilé sa Roadmap comprenant d’importantes nouveautés.
Deux aspects de Starknet seront considérablement améliorés : ses performances (TPS & finalité rapide) et ses frais de transactions. Nous vous proposons de revenir sur chacune des nouveautés tout au long de cet article à savoir : la parallélisation optimiste des transactions, Cairo Native & l’intégration de Volition.
Cet article vous est proposé en collaboration avec Starknet (en savoir plus)
Roadmap 2024 de Starknet
La feuille de route de Starknet de 2024 a été présentée sur le forum de community.starknet.io, il s’agit d’un espace plutôt dédié aux développeurs et les ressources sont en anglais, donc permettez nous de vous expliquer comment Starknet compte booster sa capacité d’exécution et réduire le temps des opérations de son écosystème, en cumulant chaque optimisation.
Pour rappel, Starknet a fait le choix de maintenir un coût pour chaque opération très bas, en limitant le temps de création des blocs et la finalité des transactions sur son Validity Rollup (Layer 2). En améliorant les capacités de son réseau, Starknet pourra progressivement baisser le temps de génération des blocs au fur et à mesure, ce qui rendra l’expérience utilisateur bien plus agréable.
Parallélisation Optimistic : une amélioration du traitement des transactions
Le problème avec les mécanismes actuels de Starknet :
L’une des principales limitations auxquelles sont exposés de nombreux protocoles de crypto monnaies est sans aucun doute leur capacité limitée à traiter un grand nombre de transactions simultanément.
En effet, généralement, les transactions sont exécutées de manière séquentielle, c’est-à-dire les unes après les autres. Cela signifie que chaque transaction doit attendre la fin de la précédente pour être traitée.
C’est pour cette raison que le concept de “parallélisation des transactions “ a vu le jour. Pour faire simple : la parallélisation permet de traiter plusieurs transactions simultanément au lieu de les exécuter une par une. Naturellement, cette approche améliore les capacités du protocole, car elle permet de mieux organiser la gestion des transactions dans le temps.
Maintenant, il faut savoir que cette parallélisation peut introduire quelques problématiques de “dépendance”. En effet, certaines transactions peuvent dépendre des résultats d’autres transactions. Par exemple, si Alice veut envoyer des ETH à Bob et Bob veut utiliser ces ETH pour acheter un NFT, la transaction de Bob dépend de celle d’Alice.
Cette dépendance demande donc le développement de stratégies de gestion de données assez complexes, ce qui peut ralentir le processus global. C’est donc à ce niveau que la parallélisation Optimistic entre en jeu.
Le nouveau mécanisme de parallélisation de Starknet
La parallélisation Optimistic est une technique qui permet d’exécuter plusieurs transactions en même temps, tout en étant prêt à gérer les conflits qui peuvent survenir avec d’autres transactions.
Avant toute chose, sachez que ce mécanisme est rendu possible grâce à la technologie BlockSTM développée par Aptos Labs dont Starknet s’est inspiré.
Si l’implémentation se passe comme prévu, la parallélisation Optimistic devrait permettre de multiplier la capacité des transactions par 3, voire même jusqu’à 10, sur le réseau Starknet. De fait, Starknet pourrait, en théorie, atteindre entre 300 et 1000 transactions par seconde rien qu’avec cette première optimisation !
Notez que cette technologie devrait voir le jour courant juillet 2024 sur le testnet de Starknet.
Revenons désormais sur les détails techniques de la parallélisation optimiste
Dans une parallélisation classique, chaque transaction est vérifiée à l’avance pour s’assurer qu’elle ne dépend pas d’une autre transaction avant d’être exécutée en parallèle. Cela nécessite donc beaucoup de coordination et ça peut ralentir le processus.
Avec la parallélisation optimiste (Optimistic Parallelization), partez du principe que la plupart transactions sont indépendantes (et non dépendantes d’une autre transaction) et qu’elles peuvent être parallélisées : exécutées en même temps. Si des transactions dépendent l’une de l’autre ou causent des conflits (transactions conflictuelles), elles sont corrigées après coup.
Voici le cycle d’une transaction optimiste:
- Exécution simultanée : les transactions sont initialement exécutées en parallèle sans vérifier les dépendances potentielles.
- Détection des conflits : pendant l’exécution, si une transaction A dépend d’une transaction B qui n’a pas encore été exécutée, un conflit est détecté.
- Réexécution : la transaction conflictuelle est reexécutée très rapidement en prenant en compte l’état (state) modifié par les transactions précédentes. Cela garantit que le résultat final est correct.
Il faut comprendre qu’avec ce processus, chaque transaction est exécutée dans une version spécifique de l’état (state) de la blockchain. Autrement dit : chaque transaction est traitée dans un environnement isolé. Cela permet de gérer efficacement les conflits, car chaque version reflète un instantané de l’état à un moment donné.
D’autre part, plusieurs threads (ou processus) sont utilisés pour exécuter les transactions en parallèle. Ces “threads” communiquent avec ce qu’on appelle « un planificateur central” (scheduler) qui leur attribue les tâches à effectuer. Le planificateur gère ensuite les transactions en cours et les tâches à venir. Il distribue les transactions aux threads de manière à optimiser l’exécution simultanée tout en minimisant les conflits.
Exemple concret de parallélisation optimiste
Supposons que nous ayons trois transactions à exécuter :
- Transaction A : Échanger USDC contre ETH ;
- Transaction B : Acheter un NFT avec des ETH ;
- Transaction C : Échanger USDT contre BTC ;
Toutes les transactions sont lancées en même temps, et non séquentiellement. A et C peuvent être exécutées sans problème, car elles ne sont pas liées. Cependant, B dépend de l’exécution de A, car elle nécessite des ETH. Le problème étant que cette “dépendance” entre A et B ne peut être connue avant que B soit exécuté par le séquenceur.
Techniquement parlant : la dépendance se produit parce que la transaction B utilise des données à partir des « cellules de stockages » qui ont été modifiées par la transaction A.
Comme évoqué plus haut, la parallélisation optimiste permet de réexécuter les transactions conflictuelles dès lors qu’un problème de dépendance est détecté (après avoir exécuté toutes les transactions en parallèle).
Si nous reprenons l’exemple : le séquenceur détecte alors que B essaie d’utiliser des ETH qui ne sont pas encore disponibles, car A est en cours. Un conflit est détecté. La transaction B est mise en attente et réexécutée après l’achèvement de A. Une fois que A a fourni les ETH nécessaires, B peut être exécuté correctement.
Cette illustration devrait vous permettre d’y voir plus clair :
Dans l’exemple ci-dessus, chaque transaction, ou plutôt chaque colonne de transactions est exécutée de manière parallèle. Si le séquenceur détecte une dépendance (exemple : la transaction 4 qui dépend de la transaction 1), alors le réseau réexécute la transaction « problématique » (la transaction 4).
Au final, tout ce processus permettra à au Rollup de Starknet de traiter un grand nombre de transactions bien plus rapidement et efficacement.
Cairo Native : un moyen de réduire le blocktime du réseau Starknet
La roadmap de Starknet comprend également l’ajout de “Cairo Native” prévu pour le mois d’octobre 2024. Concrètement, cette mise à jour a pour but de réduire la finalité des transactions et donc le blocktime au sein du réseau Starknet.
Le problème aujourd’hui étant que Starknet se doit d’avoir un blocktime relativement élevé afin de maintenir des frais de transactions très bas. En effet, le blocktime est bien plus élevé comparé à ce que l’on peut voir sur des réseaux comme Arbitrum ou encore Optimism.
Pour info, le blocktime actuel de Starknet est d’environ 6 minute, contre 0,25 seconde pour Arbitrum et 2 secondes pour Optimism.
Revenons désormais sur les détails techniques de Cairo Native :
Les transactions sur Starknet sont actuellement exécutées via une machine virtuelle appelée “Cairo VM”. Cette machine virtuelle émule une autre machine pour exécuter les transactions. C’est-à-dire qu’elle crée un environnement simulé qui imite une autre machine où le séquenceur de Starknet peut exécuter les transactions. Le problème, c’est qu’elle introduit une “couche d’émulation” qui peut ralentir le processus.
L’idée derrière Cairo Native est donc d’éliminer cette couche d’émulation, ou du moins faire en sorte que le séquenceur la contourne, afin d’améliorer les performances du réseau. Pour ce faire, Cairo Native permettra le traitement des transactions directement sur le processeur (CPU), sans passer par la machine virtuelle.
Comment c’est possible ? Eh bien, Cairo Native utilise une représentation du compilateur “Sierra”. Sierra contient des “libfuncs”, soit des fonctions intégrées qui implémentent directement les fonctionnalités du langage Cairo.
Ces libfuncs permettent de compiler le code Cairo en “bytecode natif” (code directement exécutable par le CPU), et donc : permettent au CPU de traiter directement les instructions du code en utilisant ses propres OPCODEs, c’est-à-dire les instructions de base qu’il comprend et peut exécuter sans processus de traduction supplémentaire.
Pour faire très simple : les contrats intelligents ne seront donc pas compilés via la machine virtuelle de Cairo, mais bien en code natif exécutable directement via le processeur (CPU).
Volition : une réduction considérablement des frais de transaction
Une autre grande nouveauté de Starknet très attendue n’est autre que l’intégration de Volition, prévue pour décembre 2024.
Volition se présente comme une technologie conçue pour optimiser l’utilisation des données sur la blockchain en permettant une “gestion hybride” des transactions. Le but de cette gestion hybride est de réduire les frais de transaction en diminuant l'empreinte des données sur la couche 1 (L1) de la blockchain, soit Ethereum.
Pour y parvenir, Volition permettra aux utilisateurs de choisir entre stocker certaines parties de leurs transactions directement sur le layer 1 (Ethereum) ou directement sur le layer 2 (Starknet) avec moins de frais.
En permettant aux utilisateurs de stocker certaines données hors d’Ethereum (L1), Volition réduit la quantité de données qui doivent être écrites directement sur Ethereum, ce qui signifie moins de coûts de stockage et donc des frais réduits pour les développeurs de projets sur Starknet et les utilisateurs finaux. De plus, Volition utilise des techniques de compression pour réduire la taille des données stockées sur L1.
Au final, Volition contribue à améliorer la scalabilité de Starknet. En effet, moins de données à traiter signifient que le réseau peut gérer un plus grand nombre de transactions simultanément.
Pour en apprendre davantage sur le fonctionne de la technologie Volition de Starknet 👉 cliquez sur ce lien
Liens utiles
📜 Starknet Parallélisation optimiste
🗂️ Starknet Volition : vos données, votre choix
