Il y a un mois, Vibhu, le fondateur de DRiP, la principale application grand public sur Solana distribuant des NFT gratuits d’artistes de premier plan, a déclenché un débat bien nécessaire avec sa déclaration :

Solana va avoir et a besoin d’avoir des L2 et / ou des rollups

Sa frustration est née du fait que DRiP a perdu une valeur importante (~ 20 000 $ / semaine) à la couche de base, grâce à la hausse des prix du SOL et à la congestion du réseau. L’augmentation de l’activité sur Solana entraîne :

• Avantages - Augmentation de la liquidité, du capital et des volumes de transactions (en raison de la composabilité)
• Inconvénients - Coûts d’infrastructure élevés, mauvaise expérience utilisateur et congestion

Cependant, DRiP, qui utilise principalement Solana comme infra pour distribuer des millions de NFT chaque semaine d’artistes à des milliers de portefeuilles, ne bénéficie pas d’une composabilité élevée. La croissance de la TVL de Solana et l’afflux de capitaux ont peu d’impact sur DRiP, qui souffre principalement d’inconvénients, tels que des coûts d’infrastructure élevés.

Vibhu souligne : « La composabilité a des rendements décroissants. » Il note également que les développeurs d’applications Solana discutent en privé de leur désir de rollups en raison de :

1. Augmentation du débit des transactions, réduction de la concurrence dans les espaces de blocs et réduction des frais.
2. Un meilleur contrôle sur la valeur économique générée par leurs entreprises.

Lien de publication

Au cours des derniers mois, Solana a connu de multiples incidents de congestion, allant des parachutages comme JUP à l’exploitation minière d’ORE et au trading de memecoins de pointe. Bien que l’on puisse dire que le Firedancer peut résoudre tous ces problèmes, soyons réalistes : le calendrier reste incertain, et il ne peut pas évoluer au-delà de 10x pour l’instant. Malgré cela, il est vrai que parmi toutes les grandes chaînes qui ont été testées au combat, Solana est le dernier véritable monolithe.

Solana doit-il rester un monolithe ou devenir modulaire ? Solana évoluera-t-il également comme Ethereum avec des solutions L2 et L3 fragmentées, entre autres ? Quel est le paysage actuel des appchains et des rollups sur Solana ?

Pour répondre à ces questions et résumer l’ensemble du débat, cet essai explorera toutes les possibilités, discutera de divers projets et évaluera leurs avantages et leurs inconvénients.

Cet article n’approfondira pas les détails techniques, mais adoptera plutôt une perspective plus axée sur le marché et pratique en discutant des différentes approches de mise à l’échelle pour fournir une vue d’ensemble.

Toutes les informations, pas de peluches - et beaucoup d’alpha.

En quelques mots, nous aborderons les sujets suivants :

1. Solana et la congestion
2. qui rend Solana modulaire
3. Solana Appchains - avec des exemples
4. Sollana Layer-2s et Rollups (RollApps) - avec des exemples
5. Infra Powering Rollups et Appchains

a publié un blog exhortant les projets à prendre des mesures immédiates pour améliorer les performances du réseau, notamment : Mettre en place des frais prioritaires – essentiels pour éviter les retards ou les abandons de transactions.Optimisation de l’utilisation de l’unité de calcul du programme (CU) – en utilisant uniquement ce qui est nécessaire.Mise en œuvre d’une qualité de service (QoS) pondérée par stake, permettant aux applications de hiérarchiser le traitement des transactions de leurs utilisateurs. Cependant, toutes ces mesures n’améliorent que quelque peu l’achèvement des transactions et ne garantissent pas une expérience utilisateur fluide des transactions. Une solution immédiate à ce problème est le nouveau planificateur de transactions très attendu, dont la sortie est prévue pour la version 1.18 prévue pour la fin avril. Il sera introduit avec le planificateur actuel mais ne sera pas activé par défaut, ce qui permettra aux validateurs de surveiller les performances du nouveau planificateur et de revenir facilement à l’ancien en cas de problème. Ce nouvel ordonnanceur vise à remplir les blocs de manière plus efficace et économique, en améliorant les inefficacités de l’ancien planificateur. Lisez cet article pour en savoir plus sur le new Scheduler. Anza (une entité dérivée de Solana Labs) a été cessayant continuellement de résoudre le congestion du réseau qui a été identifié comme des problèmes liés à l’implémentation de QUIC et au comportement du client validateur Agave (Solana Labs), lorsqu’on lui a demandé de traiter un grand nombre de demandes.

Les efforts pour rendre Solana modulaire ont déjà été commencés. Comme l’indique Anza DevRel, le validateur Solana et la SVM (environnement d’exécution qui traite les transactions et les smart contracts/programmes) sont étroitement couplés et maintenus par Anza (une entité dérivée de Solana Labs). Toutefois, le client de validation et le runtime de la SVM seront séparés au cours des prochains mois. Cette séparation facilitera la bifurcation de la SVM et la création facile de « chaînes d’applications Solana ».

Pour les rollups, l’avantage pourrait provenir de l’optimisation de la couche de disponibilité des données (DA)/blob de Solana, bien que cela puisse se produire à un stade ultérieur.

Source : Anza DevRel

Joe C (ingénieur chez Anza) a également dévoilé les plans pour rendre la SVM modulaire, où le pipeline de traitement des transactions sera retiré du validateur et placé dans la SVM. Cela permettra aux développeurs d’exécuter l’implémentation de SVM et d’opérer indépendamment de tout validateur.

La SVM isolée sera un assemblage de modules entièrement indépendants. Toute mise en œuvre de SVM pourrait piloter ces modules via des interfaces bien définies, ce qui réduirait davantage les obstacles pour les projets compatibles avec les SVM en réduisant considérablement les frais généraux nécessaires à l’architecture de solutions personnalisées. Les équipes peuvent implémenter uniquement les modules qui les intéressent, tout en utilisant des implémentations établies pour le reste, telles que celles d’Agave ou de Firedancer.

Dans Short, Solana serait plus plug-and-play, ce qui rendrait les chaînes d’applications et les rollups Solana beaucoup plus faciles.

D’une manière générale, il y a deux directions où cela peut aller : Layer-2s/Rollups et Appchains. Nous allons examiner les deux – un par un.

a fait sensation avec sa proposition de développer une Maker appchain (pour la gouvernance) basée sur la base de code Solana (SVM). Il a choisi SVM en raison de sa forte communauté de développeurs et de sa supériorité technique sur les autres machines virtuelles, dans le but de fork la chaîne la plus performante pour mieux répondre aux besoins des consommateurs. Bien que rien n’ait encore été mis en œuvre, cette décision a déclenché un débat bien nécessaire sur les chaînes d’applications Solana. D’une manière générale, il peut être de deux types : Sans autorisation – Tout le monde peut rejoindre le réseau, similaire au réseau principal actuel de Solana.Permissioned – Présenté sous le nom de « Pyth – La OG Solana Appchain : À un moment donné, Pyth représentait 10 à 20 % de toutes les transactions sur le réseau principal Solana. Cependant, cela ne nécessitait aucune composabilité, alors ils ont simplement forké la base de code de Solana. Cela leur a permis de tirer parti du temps de bloc rapide de 400 ms de Solana pour les mises à jour de prix à haute fréquence. Pythnet a été le premier réseau à adopter SVM pour sa chaîne d’applications. La chaîne d’applications Pythnet est un fork de preuve d’autorité du réseau principal de Solana, servant de couche de base de calcul pour le traitement et l’agrégation des données fournies par le réseau d’éditeurs de données de Pyth. Pourquoi Pyth a-t-il déménagé ? -Il ne nécessitait pas une composabilité élevée (en particulier pour les applications non-Solana) et était donc exempt de congestion du réseau principal. Il avait besoin d’un environnement autorisé pour la publication de données. Réduire les coûts d’infrastructure en internalisant les frais, qui étaient auparavant divulgués à la couche de base (Solana). Cube Exchange est un autre exemple, un CEX hybride déployé en tant que chaîne d’applications SVM souveraine (avec un livre et un règlement entièrement off-chain ordre sur leur chaîne d’applications SVM) Envisioning the Solana Appchain Stack :

Bien que l’établissement d’une chaîne d’applications puisse être relativement simple, assurer la connectivité entre toutes les chaînes d’applications est crucial pour l’interopérabilité. En s’inspirant des sous-réseaux Avalanche (connectés par la messagerie Avalanche Warp native) et des chaînes d’applications Cosmos (connectées par IBC), Solana pourrions également créer un cadre de messagerie natif pour connecter ces chaînes d’applications.

Lien de publication

On pourrait également créer un middleware de type Cosmos-SDK, offrant une solution clé en main pour créer des chaînes d’applications avec un support intégré pour les oracles (comme Pyth ou Switchboard), les RPC (comme Helius) et la connectivité de messagerie (comme Wormhole), entre autres.

Polygon AggLayer serait également une approche intéressante, où les développeurs peuvent connecter n’importe quelle chaîne L1 ou L2 à l’AggLayer, qui agrège les preuves ZK de toutes les chaînes connectées.

Solana Layer-2s :

Solana Les couches 2, ou rollups, sont des chaînes logiquement distinctes qui publient des données sur la couche de disponibilité des données (DA) de leur chaîne hôte et réutilisent le mécanisme de consensus de la chaîne hôte. Ils peuvent également utiliser d’autres couches DA comme Celestia, cependant, cela ne reste pas un véritable rollup. « RollApp » est un terme généralement utilisé pour les cumuls spécifiques à l’application (que la plupart des applications Solana explorent).

Solana Rollups serait-il le même qu’Ethereum ?
Apparemment, non. Pour Solana, les cumuls seraient principalement abstraits pour l’utilisateur final. Sur le front idéologique, Ethereum rollups étaient descendants, où la Fondation Ethereum et ses dirigeants ont décidé que la meilleure façon de se développer était de passer par rollups, et ils ont commencé à soutenir diverses L2 après le fiasco de CryptoKitties. Alors que sur Solana, la demande est ascendante, c’est-à-dire qu’elle provient des développeurs d’applications avec une adoption significative par les consommateurs. Par conséquent, la plupart des roll-up play actuels sont des jeux marketing et sont davantage axés sur la narration que sur la demande des consommateurs. C’est une différence significative et peut conduire à un avenir différent pour les rollups que ce que nous avons vu sur Ethereum.

Est-ce que Compression = Rollups ?

Les L2 mettent à l’échelle les blockchains de la couche de base (L1) en exécutant des transactions sur la L2, en regroupant les données de transaction et en les compressant. Les données compressées sont ensuite envoyées au L1 et utilisées dans la fraud proof (correctif cumulatif optimiste) ou la preuve de validité (correctif cumulatif zk). Ce processus de preuve est appelé « règlement ». De même, la compression décharge les transactions du réseau principal, ce qui réduit la contention d’état sur la couche de base. Notamment, Grass L2 tirera parti de la compression d’état pour son rollup.

1. GetCode :

Une application de paiement avec un SDK de micropaiements permet à quiconque de payer et d’accepter des paiements instantanément et utilise également un pseudo-rollup pour son application. Il crée des intentions pour toutes les transactions et utilise un séquenceur de type rollup, qui s’installe sur Solana après N intervalles.

L’utilisation d’une structure de type cumul permet : Flexibilité : les intentions peuvent représenter diverses activités futures, et pas seulement des transactions de paiement. De plus, Solana en tant que chaîne peut également être remplacée si nécessaire.Instantané et privé : Compte tenu de la finalité douce du séquenceur, les paiements sont instantanés même en cas de congestion Solana. Bien que les transactions soient visibles hors chaîne, la valeur et l’intention exactes restent obscurcies, ce qui garantit la confidentialité des utilisateurs. 2. Cumuls éphémères par

MagicBlocks MagicBlocks, une infrastructure de jeu web3 a développé des rollups éphémères (ou temporaires), en particulier pour les jeux. Il utilise la structure de compte de SVM et l’état du jeu est divisé en clusters. Il transfère temporairement l’état à une couche auxiliaire ou au « rollup éphémère », une couche dédiée configurable. Le cumul éphémère fonctionne comme un runtime ou un cumul SVM spécialisé pour faciliter le traitement des transactions à un débit élevé.

L’utilisation d’une structure de type cumul permet d’effectuer les opérations suivantes :

1. Personnalisation de l’environnement d’exécution spécialisé pour inclure des fonctionnalités telles que les transactions sans gaz, des temps de bloc plus rapides et l’incorporation d’un mécanisme de tic-tac (par exemple, un système intégré de planification des transactions comme clockwork, exploité sans frais).
2. Les développeurs doivent déployer des programmes sur la couche de base (par exemple, Solana) plutôt que sur une chaîne ou un cumul séparé. Les RE ne fragmentent pas l’écosystème existant et permettent d’accélérer les opérations ciblées sans créer d’environnement isolé. Cela signifie que toute l’infrastructure Solana existante peut être utilisée.

Cette approche facilite un système hautement évolutif capable de lancer des rollups à la demande et une mise à l’échelle automatique horizontale pour accueillir les utilisateurs effectuant des millions de transactions, sans les compromis typiques des L2 traditionnels. Bien que MagicBlock soit spécifiquement axé sur les jeux, cette approche peut être appliquée à d’autres applications comme les paiements.

Grass : Un projet DePIN visant à résoudre des problèmes de données d’IA grâce à un scraping vérifié. Lorsque les nœuds Grass grattent le Web pour les données d’entraînement de l’IA, les validateurs stockent les données off-chain, en suivant précisément d’où proviennent les données et quel nœud est responsable de leur extraction, les récompensant proportionnellement. Grass nécessite 1 million de requêtes Web par seconde, ce qui est impossible sur le réseau principal de Solana. Par conséquent, ils prévoient de faire des preuves ZK des données d’origine pour tous les ensembles de données et de les regrouper pour le règlement sur Solana L1. Ils envisagent d’utiliser la compression d’état d’un autre cluster et d’installer les racines sur la version bêta du réseau principal. Ce développement positionnera Grass comme une couche de base pour un large éventail d’applications qui ne sont possibles qu’au sommet de Grass (notez que les plates-formes et l’infrastructure commandent souvent des valorisations beaucoup plus élevées et que Grass lancera le jeton bientôt :P). Zeta : L’un des plus anciens DEX perp sur Solana qui avait un livre de ordre perp complètement off-chain prévoit également de déplacer son matching off-chain via le rollup Solana. Les DEX Perp ont un PMF immédiat pour les rollups car ils améliorent considérablement l’expérience utilisateur. Il suffit de demander à quelqu’un qui a négocié sur Hyperliquid ou Aevo contre Solana perp DEX, où vous devez signer chaque transaction, un portefeuille apparaît, et vous devez attendre ~ 10-20 secondes. De plus, les perps ne nécessitent pas d’exécution synchronisée et offrent une composabilité élevée avec le reste de la DeFi, en particulier dans l’aspect du matching commercial. Sonic construit également une chaîne SVM modulaire (Hypergrid) qui permettra aux jeux de déployer leurs propres chaînes sur Solana. Il existe également des Ethereum rollups basées sur des SVM comme Eclipse et NitroVM qui utilisent SVM comme moteur d’exécution. Neon fonctionne comme un L2 compatible EVM sur Solana. De plus, il y a des projets au stade de l’idée, tels que Molecule (un Bitcoin Layer 2 SVM). Sovereign SDK est un autre framework similaire à node.js, mais pour la création de rollups. Les utilisateurs apportent leur code Rust, et nous le transformons en un rollup Optimistic ou ZK qui peut être déployé sur n’importe quelle blockchain. Le code Rust peut être votre logique d’application spécifique ou n’importe quelle VM.

1. Rollups = Being SOL-Aligned :
   Le terme « ETH-Aligned », ou un meilleur mot pour « ETH Bag Biases », est devenu un mème populaire. Pourquoi pensez-vous que Layer 2s et Restaking/EigenLayer sont devenus le récit le plus en vogue ? C’est parce qu’ils augmentent le « Moneyness of ETH », l’ETH étant utilisé comme actif de base partout.

Le même principe s’applique à Solana. La communauté Solana se ralliera à toute solution qui augmentera ses avoirs en SOL – c’est aussi simple que cela. Au fur et à mesure que l’écosystème Solana se développe, le « Moneyness of SOL » autrefois négligé prendra de l’importance. N’oubliez pas que la plupart des cumuls sont de toute façon des « jeux marketing » et donnent une meilleure valeur d’accumulation de jetons, car les marchés accordent toujours plus d’importance à l’infrastructure qu’aux applications.

1. Les cumuls seront ressentis comme une extension de Solana :
   au-delà des avantages de sécurité (c’est-à-dire hériter de la sécurité de la couche de base), un accès facile aux utilisateurs et aux actifs Solana sera un avantage significatif. Comme le note Jon Charbonneau, Ethereum Rollups tels que Base, Optimism et Arbitrum ressemblent davantage à des extensions de Ethereum. Les utilisateurs conservent les mêmes portefeuilles et adresses, le jeton gas natif est une version canonique unique de ETH, ETH domine DeFi avec toutes les paires de trading, les applications sociales fixent le prix des NFT en ETH et paient les créateurs en ETH (par exemple, friend.tech), et les dépôts dans la L2 sont instantanés, etc.

De même, cela se produira avec Solana. En apprenant d’Ethereum, la plupart des applications Solana Rollapps ne donneront pas aux utilisateurs l’impression d’utiliser une chaîne distincte (par exemple, Getcode).

1. Solana verra plus de « RollApps » que de « Rollups"
   Solana n’a pas de problème de scalabilité comme Ethereum où le réseau principal est tout simplement inutilisable en raison de frais de gaz élevés, il est hautement optimisé. Cependant, certaines applications qui ont besoin d’un espace de bloc dédié créeront leurs rollups. Bien que les Rollups à usage général sur Solana n’aient pas de sens pour moi, économiquement, cela a du sens pour les projets. Par exemple, les utilisateurs de Base ont généré 2 millions de dollars de revenus pour Coinbase en une seule journée ! Les incitations pour les constructeurs sont fortement biaisées vers la L2. Cependant, comme on l’a observé, chaque rollup EVM semble être un roll-up vanille, et beaucoup, comme Linea, Scroll ou zkSync, sont devenus des chaînes fantômes avec seulement les agriculteurs effectuant quelques transactions pour les airdrops de jetons.

En outre, je pense que les L2 à usage général sur Solana peuvent conduire aux mêmes vieux problèmes Ethereum, c’est-à-dire des rollups centralisés, de la congestion et de la fragmentation de la liquidité.

1. Pourquoi certaines applications voudraient-elles passer à Rollapps/appchain ?
   Chaque application commencera initialement sur le Solana Mainnet, car l’hébergement d’un plus grand nombre d’applications sur une infrastructure partagée réduit considérablement la complexité des développeurs et des utilisateurs. Cependant, au fur et à mesure que ces applications se développent, elles peuvent chercher à :
   • Capture de la valeur : il est plus difficile d’internaliser la valeur sur une couche Solana partagée qui n’est pas conçue pour une seule application. La capture MEV peut être une autre option lucrative pour les DEX.
   • Personnalisation de l’espace de bloc dédié
   • dans des cas d’utilisation tels que :
     • Confidentialité : Par exemple, Getcode utilise un séquenceur pour faciliter les paiements privés de ses utilisateurs.
     • Expérimentations du marché des frais
     • Mempools cryptés pour minimiser le MEV
     • Livres d’ordres sur mesure
2. Cependant, toutes les applications ne voudront pas lancer leur propre Rollup, en particulier celles qui n’ont pas atteint une certaine vitesse d’échappement (par exemple, suffisamment de TVL, d’utilisateurs, de volume). Lancer votre propre chaîne aujourd’hui implique des compromis douloureux et inutiles (complexité, coût, moins bonne expérience utilisateur, liquidité fragmentée, etc.), que la plupart des applications, en particulier celles qui en sont à leurs débuts, ne peuvent pas justifier pour les avantages supplémentaires. Solana reste le cœur et l’âme du développement SVM, et de nombreuses nouvelles applications seront probablement déployées en conséquence.
   Pour les créateurs d’applications : Solana Mainnet ou Appchain ou Rollup
   dépend complètement. S’il n’y a pas un fort besoin de composabilité avec toutes les autres applications, il est tout à fait logique de prendre quelques composants différents off-chain (appchain ou rollup). Un utilisateur ne devrait même pas avoir besoin de savoir qu’il utilise un cumul ou une chaîne d’applications. Grass, Zeta et Getcode font tous abstraction de toute infrastructure de type rollup qu’ils utilisent pour leurs utilisateurs.

Pour les cas d’utilisation autorisés et de personnalisation, l’extension Jeton répond également à la plupart des besoins tels que la logique de KYC/transfert tout en conservant la composabilité.
Alors, DRiP sera-t-il un L2/appchain ?
Actuellement, DRiP utilise Solana pour :

* Création de portefeuilles par l’utilisateur (peut être sur L2/appchain)
* Distribution de NFT compressés (peut être sur L2/appchain)
* Trading de NFT compressés (peut se faire sur L2/appchain, mais les fonds doivent être pontés)

1. Nous pouvons clairement voir qu’il n’y a pas un fort besoin d’être sur Solana Layer 1, en plus de la technologie que L2s / appchains peut également fournir. Étant donné que la cible principale de DRiP a toujours été les utilisateurs de web2, il peut très bien les intégrer directement à leur chaîne, ce qui lui donne un contrôle beaucoup plus élevé à long terme car il ne laissera pas toute la valeur à la chaîne de base (Solana). De plus, DRiP a atteint la vitesse d’échappement (la plus grande application grand public sur Solana) pour maintenant passer à sa propre chaîne. Une structure pseudo-rollup comme Getcode a tout à fait du sens pour DRiP.

Caldera peuvent facilement entrer sur le marché des SVM au fur et à mesure que la demande émerge. Des Ethereum rollups SVM comme Eclipse et NitroVM surveillent également attentivement cette opportunité. De plus, Sovereign Labs propose un adaptateur Solana SDK >

Certainement pas. Soyons réalistes : même en tenant compte de la loi de Moore (selon laquelle les performances matérielles continueront de s’améliorer et que Solana est optimisé pour de telles avancées matérielles), ce n’est pas pratique. Je pense que toutes les transactions moins critiques (comme l’envoi de NFT DRiP) finiront par se déplacer vers leurs propres chaînes, tandis que les transactions les plus précieuses resteront sur la chaîne principale, où une véritable composabilité est essentielle (par exemple, les DEX Spot).

Et non, cela ne signifie pas que Solana a perdu dans la bataille du monolithe et de la composabilité ; il gérera mieux les cas qui dépendent de la composabilité et de la faible latence que les autres chaînes. Et non, Sui/Aptos/Sei/Monad, etc etc ne sont pas encore meilleurs, car nous ne le savons pas et ils n’ont pas encore été testés pour l’activité réelle élevée des utilisateurs.

Contrairement à Ethereum, le Solana Mainnet n’a pas pour objectif d’être la « chaîne B2B », c’était et sera toujours la chaîne de consommation. Construire des systèmes distribués à grande échelle est incroyablement difficile, et Solana a le meilleur potentiel pour devenir le grand livre partagé mondial pour les transactions les plus précieuses.

Solana a besoin d’âmes sœurs : Appchains et Rollups pourraient-ils être son match parfait ?

N’hésitez pas à me contacter à Yash Agarwal (@yashhsm sur Twitter) pour toute suggestion ou si vous avez des opinions. Si vous trouvez cela même un peu perspicace, partagez-le s’il vous plaît - justifie mes semaines d’efforts et attire plus de globes oculaires :)

Remerciements particuliers à Karthik (PepperDEX), Brian Breslow (Dorahacks), Parth (Arana Ventures), Rex (Anza), Het Dagli (Superteam), Kash (Superteam), et Akshay (Superteam), qui a révisé et fourni des informations à différentes étapes du repêchage.

The Superteam Blog]. Tous les droits d’auteur appartiennent à l’auteur original [YASH AGARWA]. S’il y a des objections à cette réimpression, veuillez contacter l’équipe Gate Learn, et ils la traiteront rapidement.

Clause de non-responsabilité : Les points de vue et opinions exprimés dans cet article sont uniquement ceux de l’auteur et ne constituent pas un conseil en investissement.

Les traductions de l’article dans d’autres langues sont effectuées par l’équipe de Gate Learn. Sauf mention contraire, il est interdit de copier, de distribuer ou de plagier les articles traduits.