Encombrement persistant : Solana a-t-elle besoin de couches 2 et de rollups ?
TechFlow SélectionTechFlow Sélection
Encombrement persistant : Solana a-t-elle besoin de couches 2 et de rollups ?
Solana a-t-il besoin d'une âme sœur ? Les appchains et les rollups sont-ils son choix parfait ?
Dédié à des analyses Web3 approfondiesRédaction : Yash Agarwal
Traduction : TechFlow
Il y a un mois, Vibhu, le fondateur de DRiP, a lancé un débat nécessaire dans une déclaration : Solana a besoin de L2 et de Rollups.
Sa conviction vient du fait que, en raison de la hausse du prix du SOL et de la congestion du réseau, DRiP a perdu beaucoup de valeur vers la couche de base (environ 20 000 $ par semaine). L’augmentation des activités sur Solana entraîne :
-
Avantages : liquidité accrue, capitalisation et volume de transactions (grâce à la composable)
-
Inconvénients : coûts d'infrastructure croissants, mauvaise expérience utilisateur, congestion
Cependant, DRiP utilise principalement Solana comme infrastructure, distribuant chaque semaine des millions de NFT à des milliers de portefeuilles. Il ne bénéficie donc pas pleinement de la haute composable. La croissance de la TVL et des flux de capitaux sur Solana n’affecte pratiquement pas DRiP, qui souffre surtout des inconvénients tels que les coûts élevés d'infrastructure.
Vibhu souligne : « Les rendements décroissants de la composable ». Il ajoute que les développeurs d'applications Solana discutent en privé de leur désir pour les Rollups, notamment pour :
-
Un débit transactionnel accru, moins de concurrence pour l'espace bloc et des frais réduits
-
Un meilleur contrôle sur la valeur économique générée par leurs activités
Ces derniers mois, Solana a connu plusieurs épisodes de congestion, allant des airdrops comme JUP aux pics de minage ORE ou aux transactions de Meme coins. Bien qu’on puisse penser que Firedancer résoudra tous ces problèmes, soyons réalistes : son calendrier reste incertain, et il ne peut actuellement pas s’étendre au-delà d’un facteur 10. Pourtant, parmi toutes les principales blockchains ayant subi divers tests, Solana est considérée comme la dernière chaîne monolithique véritablement opérationnelle.
Solana devrait-elle rester monolithique ou devenir modulaire ? Évoluera-t-elle comme Ethereum, en adoptant des solutions L2 et L3 décentralisées ? Quel est l'état actuel des appchains et des Rollups sur Solana ?
Pour répondre à ces questions et résumer tout ce débat, cet article explorera toutes les possibilités, examinera divers projets et évaluera leurs avantages et inconvénients.
Cet article n’entrera pas dans les détails techniques, mais adoptera une approche plus orientée marché et pratique afin de donner un aperçu général des différentes méthodes de scalabilité.
En bref, nous aborderons :
-
Solana et la congestion
-
La modularité de Solana
-
Les appchains Solana avec exemples
-
Les L2/Rollups Solana (RollApps) avec exemples
-
L’infrastructure soutenant les Rollups et les appchains
Solana et la congestion
Commençons par l’éléphant dans la pièce : Solana a été très congestionnée récemment (la majorité des problèmes sont désormais résolus), principalement à cause d’événements comme des airdrops ou des pics massifs de transactions autour des Meme coins, entraînant un taux élevé de pings, un grand nombre d’échecs de transactions et des frais réseau accrus dus aux frais prioritaires. Malgré cela, Solana maintient environ 1 à 2 kTPS, soit plus que la somme de toutes les chaînes EVM combinées. On peut dire que c’est un bon problème pour une blockchain, car cela met à l’épreuve sa nature monolithique.
Récemment, la Fondation Solana a publié un article encourageant les projets à agir immédiatement pour améliorer les performances du réseau, notamment :
-
Mettre en œuvre des frais prioritaires, essentiels pour éviter les retards ou pertes de transactions.
-
Optimiser l’utilisation des unités de calcul (CU) via un système de pénalités, en utilisant uniquement ce qui est nécessaire.
-
Mettre en œuvre une qualité de service (QoS) pondérée par priorité, permettant aux applications de prioriser le traitement des transactions des utilisateurs.
Toutes ces mesures peuvent seulement améliorer partiellement le taux de réussite des transactions, sans garantir une expérience utilisateur fluide. Une solution immédiate attendue est le nouveau planificateur de transactions, dont la version 1.18 est prévue fin avril. Il sera déployé aux côtés de l’ancien planificateur, mais non activé par défaut, permettant aux validateurs de surveiller ses performances et de revenir facilement à l’ancien en cas de problème. Ce nouveau planificateur vise à remplir les blocs de manière plus efficace et économique, corrigeant les inefficacités du précédent. Lire cet article pour plus de détails.
Anza (entité issue de Solana Labs) travaille continuellement à résoudre les problèmes de congestion, identifiés comme liés à l’implémentation QUIC et au comportement du client validateur Agave (Solana Labs) lorsqu’il traite un grand nombre de requêtes.
Bien que les partisans de la modularité plaident fortement pour que Solana adopte une « feuille de route modulaire », Solana Labs/Anza (les mainteneurs principaux du protocole) restent concentrés sur l’optimisation du débit et de la latence de la couche de base. Parmi les améliorations envisagées :
-
Une refonte complète du marché des frais et une augmentation des frais de base (actuellement fixés à 5 000 Lamports ou 0,000005 SOL)
-
Des frais exponentiels pour les écritures verrouillées sur les comptes, augmentant progressivement avec le temps pour éviter le spam
-
Optimisation budgétaire des UC via un système de pénalités
-
Renforcement global de l’architecture réseau
Même après ces améliorations verticales (chaîne unique), on ne peut exclure que Solana adopte également un scalabilité horizontale (Rollup). En effet, Solana pourrait devenir un hybride, servant d’excellente couche de base pour les Rollups grâce à son temps de bloc extrêmement faible (~400 ms), bénéficiant grandement aux Rollups, par exemple en permettant des confirmations douces ultra-rapides depuis les séquenceurs. Le meilleur point étant que Solana a historiquement mis en œuvre rapidement les changements, ce qui pourrait en faire une couche Rollup plus efficace qu'Ethereum.
Mise à jour : Anza a maintenant déployé certains correctifs aidant à atténuer la congestion actuelle, suivis d'autres améliorations dans la v1.18.
Vers une modularité de Solana
Les efforts pour modulariser Solana ont déjà commencé. Comme indiqué dans un post du DevRel d’Anza, les validateurs Solana et SVM (l’environnement d’exécution des transactions et contrats intelligents / programmes) sont étroitement couplés et maintenus par Anza. Toutefois, le client validateur et le runtime SVM seront séparés dans les prochains mois. Cette séparation facilitera le fork de SVM et la création aisée de « appchains Solana ».
Pour les Rollups, les bénéfices pourraient venir d’une optimisation de la disponibilité des données (DA) / couche blob de Solana, bien que cela intervienne probablement à une étape ultérieure.
Joe C., ingénieur chez Anza, a également révélé un plan visant à modulariser SVM, où le pipeline de traitement des transactions serait retiré du validateur pour être intégré à SVM. Cela permettrait aux développeurs d’exécuter leurs propres implémentations de SVM indépendamment de toute opération de validation.
Un SVM isolé consisterait en une collection entièrement indépendante de modules. Toute implémentation de SVM pourrait piloter ces modules via des interfaces clairement définies, abaissant davantage la barrière d'entrée pour les projets compatibles SVM, car elle réduit considérablement les coûts nécessaires à la mise en place de solutions personnalisées. Les équipes pourraient implémenter uniquement les modules qui les intéressent tout en tirant parti de ceux provenant d'implémentations établies comme Agave ou Firedancer.
En résumé, Solana deviendra plus plug-and-play, facilitant ainsi la création d’appchains et de Rollups Solana.
Globalement, deux directions sont possibles : les Layer-2/Rollups et les appchains. Nous examinerons chacune d’entre elles.
Appchains Solana
Également appelées forks SVM, il s’agit essentiellement de forks de la chaîne Solana dédiés à une application spécifique. Pyth fut la première appchain Solana, mais ce concept a vraiment pris de l’ampleur lorsque Rune, fondateur de Maker, a proposé de développer une appchain Maker (pour la gouvernance) basée sur le codebase Solana (SVM). Il a choisi SVM pour sa solide communauté de développeurs et ses avantages techniques surpassant d’autres machines virtuelles, dans le but de forker la chaîne la plus performante pour mieux répondre aux besoins des consommateurs. Bien qu’aucune action n’ait encore été prise, cette annonce a suscité un débat urgent autour des appchains Solana.
On peut grossièrement les diviser en deux catégories :
-
Sans permission : tout le monde peut rejoindre le réseau, similaire au mainnet Solana actuel
-
Avec permission : empaquetées par la Fondation Solana sous le nom d’« Environnements Solana Permis (SPEs) », destinés aux institutions, permettant aux entités de construire et gérer leurs propres instances de chaîne supportées par SVM.
Pyth : la première appchain Solana
À un moment donné, Pyth représentait 10 à 20 % de toutes les transactions sur le mainnet Solana. Mais n’ayant pas besoin de composable, ils ont simplement forké le codebase Solana. Cela leur a permis d’utiliser le temps de bloc rapide de 400 ms de Solana pour des mises à jour fréquentes des prix. Pythnet est ainsi devenu le premier réseau à utiliser SVM comme appchain.
L’appchain Pythnet est un fork Proof-of-Authority du mainnet Solana, servant de couche de calcul pour traiter et agréger les données fournies par les éditeurs de données du réseau Pyth.
Pourquoi Pyth a-t-il migré ?
-
Il n’a pas besoin de composable, donc peut échapper à la congestion du mainnet
-
Il a besoin d’un environnement autorisé pour publier les données
Cube Exchange est un autre exemple, un CEX hybride déployé comme appchain SVM souveraine (avec un carnet d’ordres hors chaîne, réglant les transactions sur sa propre appchain SVM).
Quelques exemples d’appchains Solana incluent :
-
DEX perp : comme Hyperliquid, un DEX perp peut fonctionner comme une L1 autonome. Pour les cas d’usage trading, on peut personnaliser le nombre de transactions par bloc, ou implémenter une logique conditionnelle, par exemple intégrant directement l’exécution des ordres stop-loss dans la L1, assurant leur exécution comme transition d’état, ou introduire une logique atomique spécifique à l’application.
-
IA et DePIN : peuvent disposer d’une liste de fournisseurs de services contrôlés, comme Pyth. Par exemple, Akash fonctionne comme un marché informatique via une appchain Cosmos.
-
Appchains de gouvernance : l’intérêt de MakerDAO pour une appchain SVM a été validé. Une appchain de gouvernance souveraine pourrait être attrayante. La gouvernance cryptographique évolue encore, et disposer d’une chaîne dédiée pour forker peut devenir un mécanisme utile de coordination.
-
Futures appchains d’entreprise : applications potentielles incluant des fonds (comme BlackRock) ou des systèmes de paiement (comme Visa ou CBDC).
-
Appchains gaming : un projet de jeu de casino sur Solana envisage sa propre appchain.
-
Forks modifiés de Solana : comme Monad ou Sei offrent un EVM optimisé (parallélisation), quelqu’un pourrait construire une version plus optimisée de Solana. Cette tendance pourrait devenir plus courante dans les années à venir, surtout si le mainnet Solana explore de nouvelles architectures.
Imaginer la pile d’appchains Solana
Bien que créer une appchain puisse être relativement simple, assurer la connectivité entre toutes les appchains est crucial pour l’interopérabilité. Inspiré des sous-réseaux Avalanche (connectés via Avalanche Warp Messaging natif) et des appchains Cosmos (connectées via IBC), Solana pourrait aussi créer un cadre de messagerie natif reliant ces appchains.
On pourrait aussi créer un middleware similaire à Cosmos-SDK, offrant une solution tout-en-un pour créer des appchains avec support intégré pour Oracle (comme Pyth ou Switchboard), RPC (comme Helius) et connectivité de messagerie (comme Wormhole).
Polygon AggLayer est aussi une approche intéressante : les développeurs peuvent connecter n’importe quelle chaîne L1 ou L2 à AggLayer, qui agrège ensuite les preuves ZK de toutes les chaînes connectées.
Les appchains sont-elles positives pour l'écosystème Solana ?
Bien que les appchains n’augmentent pas directement la valeur du SOL — car elles ne paient pas de frais en SOL ni n’utilisent le SOL comme jeton gas, sauf si du SOL re-staké assure la sécurité économique — elles profitent grandement à l’écosystème SVM. Comme il existe un « effet réseau EVM », davantage de forks SVM et d’appchains renforceront l’effet réseau SVM. La même logique fait que Eclipse (un L2 SVM sur Ethereum) est positif pour SVM, même s’il est un concurrent direct du mainnet Solana.
Les couches 2 de Solana
Les L2 de Solana, ou Rollups, sont des chaînes logiquement indépendantes qui publient leurs données sur la couche de disponibilité de données (DA) de leur chaîne principale et réutilisent son mécanisme de consensus. Elles peuvent aussi utiliser d'autres couches DA, comme Celestia, mais alors ce ne sont plus de vrais Rollups. Le terme « RollApp » désigne généralement un Rollup dédié à une application spécifique (ce que la plupart des applications Solana explorent).
Les Rollups Solana sont-ils comme ceux d’Ethereum ?
Clairement non. Pour Solana, les Rollups sont largement abstraits pour l'utilisateur final. Idéologiquement, les Rollups Ethereum sont top-down : la Fondation Ethereum et ses leaders ont décidé d’évoluer via les Rollups, soutenant divers L2 dès l’événement CryptoKitties. Sur Solana, la demande est bottom-up, venant des développeurs d'applications ayant une forte adoption utilisateur. Ainsi, la plupart des Rollups actuels relèvent davantage d'une stratégie marketing, motivés par le récit plutôt que par la demande réelle. Cette différence importante pourrait conduire à un avenir des Rollups différent de celui observé sur Ethereum.
Compression = Rollup ?
Les L2 étendent la blockchain de base (L1) en exécutant les transactions sur le L2, en regroupant et compressant les données, puis en envoyant ces données compressées sur la L1, accompagnées de preuves de fraude (Rollups optimistes) ou de validité (Rollups zk). Ce processus est appelé « règlement ». De même, la compression peut décharger les transactions du mainnet, réduisant la contention sur l’état de base. À noter que le L2 Grass utilisera la compression d’état pour son Rollup.
État des lieux des Rollups sur Solana
Actuellement, deux applications « un peu comme des Rollapps » sont en fonctionnement :
GetCode
Une application de paiement dotée d’un SDK micro-paiements, permettant à quiconque de payer et recevoir instantanément, utilisant aussi une pseudo-structure de Rollup. Elle crée des intentions pour toutes les transactions et utilise un séquenceur similaire à un Rollup, réglant par lots sur Solana tous les N intervalles.
Cette structure similaire à un Rollup permet :
-
Flexibilité : les intentions peuvent représenter diverses actions futures, pas seulement des paiements. En outre, si nécessaire, Solana peut être remplacée par une autre chaîne.
-
Instantanéité et confidentialité : grâce à la finalité douce du séquenceur, les paiements sont instantanés même en cas de congestion sur Solana. Bien que les transactions soient visibles sur chaîne, la valeur exacte et l’intention restent floues, préservant la vie privée.
Le Rollup éphémère de MagicBlocks
MagicBlocks est une infrastructure Web3, spécialisée dans les jeux, développant des Rollups temporaires (ou éphémères). Il utilise la structure de compte SVM, divisant l’état du jeu en clusters. Il transfère temporairement l’état vers une couche secondaire ou « Rollup éphémère », une couche dédiée configurable. Ce Rollup éphémère fonctionne comme un runtime SVM spécialisé ou un Rollup, permettant un traitement transactionnel à débit élevé.
Cette structure similaire à un Rollup permet :
-
Personnalisation du runtime spécialisé, incluant des transactions sans gas, des temps de bloc plus rapides, et intégrant un mécanisme de tic (ex : un système de planification intégré sans frais, similaire à une horloge).
-
Les développeurs peuvent déployer leurs programmes sur la couche de base (ex : Solana) plutôt que sur une chaîne distincte ou un Rollup. Les ER ne cassent pas l’écosystème existant et permettent d’accélérer les opérations ciblées sans créer d’environnement isolé. Ainsi, toute l’infrastructure Solana existante reste utilisable.
Cette approche aide à construire un système hautement scalable, capable de lancer des Rollups à la demande et de s’étendre horizontalement pour gérer des millions de transactions sans les compromis typiques des L2 traditionnels. Bien que MagicBlock se concentre sur les jeux, cette méthode pourrait s’appliquer à d’autres cas, comme les paiements.
Prochains Rollups Solana
Grass : projet DePIN visant à résoudre les problèmes de données IA via des crawlers réseau vérifiés. Lorsque les nœuds Grass extraient des données d’entraînement IA, les validateurs stockeront ces données sur chaîne, traquant précisément leur origine et les nœuds responsables, et les récompensant proportionnellement.
Grass nécessite un million de requêtes réseau par seconde, irréalisable sur le mainnet Solana. Ils prévoient donc de générer des preuves ZK sur les données brutes de tous les jeux de données, puis de régler par lots sur la L1 Solana. Ils envisagent d’utiliser la compression d’état depuis un autre cluster, en réglant le hash racine sur le mainnet-beta.
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
@yashhsm
