Titre original : Appchainer ou ne pas appchainer

Auteur original : André Cronje

Compilation originale : Deep Chao TechFlow

Tout a commencé par un tweet :

André Cronje：

· Pourquoi L2 en tant que chaîne d'applications est déraisonnable pour les développeurs :

· Il n'y a presque aucun support d'infrastructure lors du déploiement, comme les pièces stables, les oracles et la garde institutionnelle.

· Manque de soutien des fondations ou des laboratoires.

· Centralisé et vulnérable aux attaques.

· Conduit à une liquidité fragmentée et nécessite le recours à des mesures de transition.

· Manque de communauté d'utilisateurs et de développeurs. Du temps est consacré à traiter ces problèmes au lieu de se concentrer sur l'application et les utilisateurs.

· Réduire les effets de réseau. Les délais de confirmation des transactions sont encore longs (certains fournisseurs ne travailleront pas avec vous). Développé seul, sans support d'équipe.

Cette expérience m'a exposé à de nombreuses recommandations de produits, et une en particulier a retenu mon attention (avec de nombreux autres produits sympas bien sûr) ;

Étonnamment, ils ont lancé ma propre chaîne d'applications en quelques minutes seulement.

C'était très excitant pour moi d'un point de vue technologique, car il y avait beaucoup de nouvelles solutions auxquelles je n'avais jamais été exposé auparavant, et j'ai toujours envie d'apprendre de nouvelles technologies, alors j'ai commencé à les explorer.

L'idée d'avoir votre propre pile technologique, comprenant des pièces stables natives, des oracles, des systèmes de preuve, des effets de réseau, des ponts et l'interopérabilité, semble vraiment bonne.

Cela semble irréaliste (mais pas entièrement), je vais donc commencer par ce que je considère comme les deux plus grands obstacles : l’émission native de stablecoins et les oracles fiables. En passant par ce processus avec le lancement récent de Sonic (et en dépensant plus de 5 millions de dollars pour cela), j'ai réalisé à quel point il serait humiliant et légèrement embarrassant d'obtenir tout cela gratuitement.

Parmi les nombreuses recommandations, noble.xyz est celle qui m'intéresse le plus car elle prétend fournir des USDC et CCTP natifs pour toute chaîne compatible IBC. Tout d'abord, c'est un produit sympa, mais ce n'est pas de l'USDC ou du CCTP natif, mais un pont pour que les actifs soient émis via sa blockchain puis transférés vers IBC (la version interopérable de l'écosystème Cosmos, qui est géniale) Autres chaînes d'intégration . Ce n'est pas automatique, ce n'est pas gratuit et ce n'est ni natif ni CCTP.

Cela dit, on peut également s’intéresser à d’autres solutions comme LayerZero et AcrossProtocol, qui sont d’excellents protocoles. Nous travaillons beaucoup avec LayerZero et ils sont excellents et je recommanderais fortement à n'importe quelle chaîne de travailler avec eux, mais ce n'est toujours pas une version locale. Je sais que c'est pinailleur, mais après avoir rencontré divers problèmes avec les ponts, rien ne vaut la distribution locale en termes de confiance et d'échelle. Si vous souhaitez une distribution locale, vous devez disposer des fonds nécessaires.

Du côté d'Oracle, j'ai reçu des recommandations pour skipprotocol, storkoracle et redstone_defi, mais malheureusement aucun de ces produits n'est plug-and-play et ne nécessite une intégration, et je ne sais pas s'il y a un coût supplémentaire. Ici, je pense qu'il est nécessaire de discuter de la question de l'échelle. Mon hypothèse est que quiconque veut être L1 ou L2 veut être dans le top 50, 20 ou 10 (que ce soit en volume, en total verrouillé ou en capitalisation boursière). Cependant, cela ne s’applique pas toujours et certaines applications n’ont pas besoin d’être aussi volumineuses. J'ai vécu cela avec le réseau Keep3r, où tout le monde s'attendait à ce que ce soit un autre Yearn, mais cela n'a jamais été prévu. Yearn s'apparente à une société de gestion d'actifs, tandis que Keep3r est un outil d'exploitation et de maintenance de niche. Les deux n'ont pas besoin des mêmes critères d'évaluation. Donc, ce post n'a pas pour but de dévaloriser ces produits, comme je l'ai dit, ils sont tous excellents, mais si vous lancez hypothétiquement une chaîne d'applications L2 ou L1 pour concurrencer Arbitrum, Optimism, Solana, Avax, etc., ces plans ne semblent pas pour être suffisamment complet.

Parlons ensuite des outils de développement et des portefeuilles, qui sont compatibles avec toute nouvelle chaîne, mais les utilisateurs et les développeurs doivent configurer ces RPC manuellement. Même si ce n’est pas grave, cela ajoute des frictions inutiles.

Enfin, il y a le navigateur bloc, il faut le mentionner Blockscout, c'est la référence des navigateurs gratuits. Il n'y a pas grand chose à dire, ils sont excellents. Cependant, les produits payants comme etherscan ont tendance à avoir un avantage car ils disposent d’équipes payantes dédiées.

Bien entendu, cela ne résout pas le problème de l’interopérabilité ou des effets de réseau. En prenant unichain comme exemple, si Uniswap est la seule application sur la chaîne (bien que cela soit peu probable, supposons), quel sera son volume de transactions ? Quelle part du volume correspond à l’arbitrage avec d’autres AMM, quelle part correspond à la liquidation de positions sur les marchés monétaires et quelle part représente d’autres activités de prêts flash douteux ? Dans l’isolement, les frais de transaction sont réduits, et c’est la composabilité et l’interopérabilité qui aident.

J'ai lu un peu sur les clusters et les hyperchaînes, et j'avoue que soit je ne l'ai pas bien compris (ce qui est probable), soit cela n'a pas vraiment de sens en pratique.

Passons maintenant à la dernière phrase, cela n’a aucun sens. Être capable de créer votre propre L1 ou L2 en quelques minutes, avec un navigateur, un RPC, un pontage et bien plus encore, est vraiment incroyable. Mais est-ce vraiment pratique ?

En prenant Unichain comme exemple (désolé, j'ai suivi Unichain, je pense qu'ils pourraient être l'une des rares exceptions car ils ont d'énormes effets de réseau, mais suivez-moi sur cet exemple), ils ont construit cette chaîne. Une raison importante est de capturer de la valeur. Découvrez ce tweet ci-dessous :

Uniswap sur Ethereum a généré à lui seul 2,439 milliards de dollars de frais de gaz pour les validateurs. Cela n'inclut pas l'extraction MEV (qu'ils peuvent capturer en tant que séquenceurs). Ces 2,5 milliards de dollars auraient pu être gagnés par Uniswap lui-même, mais sont allés aux validateurs. C'est un très grand nombre.

Alors, et si nous pouvions résoudre ce problème de manière plus pratique sans exécuter notre propre chaîne, navigateur, fournisseur RPC, ni demander aux utilisateurs et aux développeurs de configurer RPC dans les portefeuilles et les outils de développement, ni intégrer les oracles et la stabilité locale ? Quel est le problème que nous voulons résoudre ? La véritable idée est de récupérer la valeur dans l’application, plutôt que de la faire retirer par le réseau. N'y a-t-il pas une solution simple à cela ? Dans notre économie des créateurs, ce problème n’a-t-il pas été fondamentalement résolu ? La réponse est le partage des revenus. Des plateformes telles que YouTube, Twitch et X accordent toutes aux créateurs une part des revenus. Alors, une solution plus pratique ne serait-elle pas de répartir ces coûts de gaz sur l’application ?

Je demande, quelles sont les autres raisons pratiques ? Bien entendu, le problème de la faible latence a été essentiellement résolu par les blockchains modernes (telles que Sonic, Avax, en supposant que vous ayez besoin d'EVM, Solana SVM, Sui MoveVM). Notre débit est également suffisamment élevé pour que la plupart des chaînes que je viens de mentionner soient plus efficaces que la couche 2 actuelle. Donc, si le problème n’est pas la vitesse, ni le débit, alors il doit s’agir de capture de valeur. Qui peut leur en vouloir ? Les frais de tri sont le nouveau modèle de revenus (en gros, vous gardez tous les frais de réseau pour vous au lieu de les partager avec des validateurs d'extraction de valeur décentralisés, je plaisante, en fait, j'aime bien les validateurs).

Alors, partage des revenus, n’est-ce pas ? De cette façon, tous les problèmes sont résolus et tous les avantages sont obtenus.

La chaîne d'application apparaît comme une solution d'ingénierie qui existe pour résoudre des problèmes. Ne vous méprenez pas, le geek de la technologie en moi adore ça, mais en tant que véritable développeur, je ne peux m'empêcher de me demander : pourquoi diable ?

Lien d'origine