Auteur : Neel Somani, fondateur d'Eclipse, ancien chercheur quantitatif chez Citadel ; traduction : Jinse Finance xiaozou
Chez Eclipse, nous construisons une infrastructure de cumul personnalisable spécifique à l'application pour prendre en charge des secteurs verticaux tels que Gaming & Social, DePIN et DeFi.
Nous y travaillons depuis environ 10 mois, et je ressens le besoin de dissiper certaines idées fausses. Voici quelques réflexions sur les cumuls spécifiques à l'application :
1. La division de marché existante est erronée
**(1)**Rollup Framework n'est pas une association caritative
Les frameworks de rollup comme OP Stack sont des bases de code qui déploient les composants clés des rollups. Ils ne vous factureront pas l'utilisation du code, mais ils doivent capturer la valeur d'une manière ou d'une autre. Pour résumer, il y a trois endroits où la valeur peut être obtenue :
Exécution : ordre des transactions, exécution et preuves (zk-rollup)
Règlement : relier et vérifier les preuves de validité ou les preuves d'erreur
· Disponibilité des données : Publier l'ordre de transaction
Mais seule l'exécution convient comme modèle commercial pour le framework de cumul :
Règlement : après la mise à niveau de Bedrock, Optimism ne paie à Ethereum que des frais de règlement d'environ 5 $ par jour. Le reste des frais généraux d'OP Stack provient de l'émission de blocs et des frais connexes. Les protocoles de règlement concurrents peuvent gagner encore moins.
Disponibilité des données : les couches DA fragmentées sont moins risquées pour sécuriser le réseau que les couches de disponibilité des données (DA) partagées telles que Celestia. De nombreux rollups ne veulent pas migrer leur DA hors d'Ethereum car cela sacrifierait leur cohérence avec Ethereum.
Tout segment de marché doit inclure des frameworks de cumul dans au moins une catégorie liée à l'exécution, et tout produit qui fournit des services d'exécution peut concurrencer les frameworks de cumul.
(2) Le cumul isolé en tant que service (RaaS) est intenable
L'explication naïve du RaaS est en fait Séquenceur isolé en tant que service (iSaaS). Ces entreprises n'ont pas leur propre protocole, mais elles déploient un framework de déploiement open source existant et exécutent un séquenceur. OP Stack a un partenariat avec iSaaS.
Le modèle commercial iSaaS consiste à facturer des frais statutaires récurrents en plus de facturer un pourcentage des frais du séquenceur. (Les services d'assistance supplémentaires, le conseil ou le développement de fonctionnalités personnalisées ne représentent pas un modèle commercial évolutif.) Pour être clair, ce serait un concurrent direct des réseaux de séquenceurs partagés tels qu'Espresso, Astria, Radius, etc. ; mais ils ont aussi Certains des faiblesses fatales.
Un gros problème avec iSaaS est qu'il ne s'aligne pas sur le cadre de déploiement. Comme mentionné ci-dessus, un cadre de cumul optimiste comme OP Stack doit monétiser les frais de tri. (Un framework zk-rollup peut ignorer les frais du donneur d'ordre et ne conserver que les frais du prouveur.)
D'autres problèmes de haut niveau avec ce type d'entreprise sont qu'il est banalisé, facile d'accès et n'a pas d'effets sur le réseau, contrairement à un ordonnateur partagé. iSaaS n'a pas les économies d'échelle des séquenceurs partagés car chaque séquenceur est isolé.
(3)Op****timistele framework de cumul doit fournir son propre S****aaS
Afin de bien fonctionner, iSaaS peut renvoyer les frais de séquenceur dans un cadre de cumul optimiste, ne laissant que des frais fiat récurrents.
Mais maintenant, les frameworks iSaaS et rollup doivent être rentables indépendamment. La tarification idéale pour les grandes entreprises serait des paiements fiat récurrents élevés, mais des frais de commande peu élevés. Cependant, iSaaS n'a pas la possibilité de réduire les frais de commande, car les frais de commande ne leur appartiennent pas à l'origine, mais sont renvoyés au cadre de cumul. Si l'iSaaS ne partage pas les revenus avec le framework de cumul, le framework de cumul peut déployer son propre iSaaS et, puisque la confiance est déjà établie, peut pénétrer le marché plus profondément.
La raison pour laquelle il y a tant d'iSaaS qui apparaît est parce qu'il semble attrayant pour les lecteurs moins expérimentés. Cela ressemble à du SaaS, donc les investisseurs non-crypto peuvent trouver plus facile d'extrapoler les revenus fiduciaires. Mais iSaaS aura du mal à rivaliser avec les frameworks de cumul qui ont leur propre SaaS avec des revenus et des jetons natifs du protocole. Ce dernier a plus d'options en termes de tarification, les jetons peuvent être utilisés pour subventionner des projets prometteurs, subventionner les coûts d'acquisition de clients et les coûts de fonctionnement fixes (voir ci-dessous).
Les effets de réseau natifs du protocole et le partage des coûts fixes créeront une économie unitaire plus forte pour les protocoles avec une plus grande visibilité, faisant des fournisseurs de déploiement un peu gagnant-gagnant.
(4) CARTE DU MARCHÉ AJUSTÉE
Maintenant, je peux montrer comment j'ai peaufiné les graphismes de l'article de Messari, ce qui, à mon avis, semblait raisonnable à l'époque :
(Messari Graphique du marché)
(Graphique du marché ajusté)
Je vais renommer la catégorie "Pas de déploiement de code" et le Rollup SDK en Rollup Frameworks car de nombreux frameworks Rollup ne fournissent pas de SDK complet aux développeurs. J'aimerais aussi modifier ce schéma de l'écosystème Celestia :
(Diagramme de l'écosystème Celestia)
(Diagramme ajusté de l'écosystème de Celestia)
Je supprimerai RaaS, la couche de facturation et les machines virtuelles. Pour les projets de la catégorie Rollup Framework, ils se retrouveront presque certainement dans une autre catégorie également, ou ils ne seront pas rentables.
2. Il n'y a pas de repas gratuit : contraintes économiques et techniques
(1) La plupart des applications ne devraient pas avoir leur propre r****ollup
Le moyen le plus simple de démontrer l'économie d'un cumul pour une application spécifique consiste à consulter les cumuls en direct : Optimisme (après la mise à niveau de Bedrock). C'est l'approche que l'équipe Optimism a adoptée pour créer le tableau de bord Dune.
Ce qui suit suppose que le prix du gaz sur Ethereum est d'environ 25 gwei :
· Le coût de déploiement unique de la chaîne de réseau principale OP Stack est d'environ 1 ETH
· Le coût fixe de la chaîne OP Stack (même si le nombre de transactions en cours est de 0) est d'environ 0,5 ETH par jour
· Le coût variable est de 7,5 * 10^-5 ETH par transaction
Pour obtenir le coût fixe, j'ai multiplié les frais généraux moyens par transaction par le nombre de transactions exécutées ce jour-là et confirmé en exécutant la chaîne OP Stack sur le réseau principal.
Ce coût variable est faible, mais pas au niveau de Solana, et le coût fixe peut être amorti sur de nombreuses transactions. Dans un futur EIP-4844, nous pouvons à peu près supposer que ce coût sera divisé par 10. Pourtant, disons qu'un prix ETH de 2000 $ représente un plancher de 0,015 $ par transaction plus quelques coûts fixes amortis.
Nous pourrions considérer 0,00001 ETH (environ 0,02 $ au moment de la rédaction) comme un jeton de transaction raisonnable pour couvrir ce coût fixe, nous aurions donc besoin de 50 000 transactions par jour pour qu'un déploiement d'application particulier en vaille la peine. Avant EIP-4844, il était d'environ 0,17 $ par transaction et, de manière optimiste, après EIP-4844, il était de 0,03 $ par transaction. Nous pouvons ajouter une petite prime, de sorte que la chaîne de support de trieuse (partagée) est économique.
Ainsi, bien que quelque chose comme Opclave soit cool (j'aime vraiment l'idée, nous discutons avec l'équipe Dogan que nous pourrions intégrer cette fonctionnalité dans le cumul Eclipse), cela n'a pas beaucoup de sens en tant que chaîne OP Stack du réseau principal. La contrainte ici est que la chaîne OP Stack est ancrée sur Ethereum, dont l'espace de bloc est cher, et l'intention d'Optimism est d'être cohérent avec Ethereum.
Compte tenu de ces économies unitaires, ces petits projets DeFi dApps et NFT n'ont pas beaucoup de sens sur leurs propres chaînes. Pour ces dApps, il pourrait être judicieux de subventionner les coûts du gaz si l'économie unitaire à long terme d'Ethereum L2 a du sens pour leurs dApps, ou ils pourraient être disposés à assumer la perte de leur chaîne d'applications.
Si une application nécessite trop de volume de transactions, un cumul lié à Ethereum ne fonctionnera pas non plus, car des frais de transaction supérieurs à 0,01 USD peuvent être trop élevés. Ces types d'applications nécessiteront une nouvelle approche, comme celle qu'Eclipse est en train de créer avec nos machines virtuelles hautement parallèles et notre architecture de cumul souverain.
(2) Le cumul personnalisable doit être limité
Comme mentionné ci-dessus, OP Hacks ne sera pas inclus dans la Superchain d'Optimism. Cela a du sens car pour régler correctement ou fournir un ordre d'état pour les cumuls, nous avons besoin que certains invariants soient vrais. Toute modification devra être auditée avant de soutenir la valeur économique réelle.
Une autre bonne raison de limiter les cumuls spécifiques à l'application est d'examiner l'adoption de Cosmos. Le SDK Cosmos est très général, mais il n'a jamais déclenché le grand nombre de chaînes différentes auxquelles vous pourriez vous attendre. Cela peut être dû au fait que le processus de personnalisation nécessite trop de complexité technique, ou plus probablement parce que la longue traîne de l'application est bien adaptée à un petit nombre d'architectures. Les modèles spécifiques à un domaine, en revanche, peuvent résoudre les problèmes courants dans différents secteurs verticaux et fournir une architecture reproductible.
Voir l'original
Cette page peut inclure du contenu de tiers fourni à des fins d'information uniquement. Gate ne garantit ni l'exactitude ni la validité de ces contenus, n’endosse pas les opinions exprimées, et ne fournit aucun conseil financier ou professionnel à travers ces informations. Voir la section Avertissement pour plus de détails.
Fondateur d'Eclipse : quelques incompréhensions sur le RaaS
Auteur : Neel Somani, fondateur d'Eclipse, ancien chercheur quantitatif chez Citadel ; traduction : Jinse Finance xiaozou
Chez Eclipse, nous construisons une infrastructure de cumul personnalisable spécifique à l'application pour prendre en charge des secteurs verticaux tels que Gaming & Social, DePIN et DeFi.
Nous y travaillons depuis environ 10 mois, et je ressens le besoin de dissiper certaines idées fausses. Voici quelques réflexions sur les cumuls spécifiques à l'application :
1. La division de marché existante est erronée
**(1)**Rollup Framework n'est pas une association caritative
Les frameworks de rollup comme OP Stack sont des bases de code qui déploient les composants clés des rollups. Ils ne vous factureront pas l'utilisation du code, mais ils doivent capturer la valeur d'une manière ou d'une autre. Pour résumer, il y a trois endroits où la valeur peut être obtenue :
Exécution : ordre des transactions, exécution et preuves (zk-rollup)
Règlement : relier et vérifier les preuves de validité ou les preuves d'erreur
· Disponibilité des données : Publier l'ordre de transaction
Mais seule l'exécution convient comme modèle commercial pour le framework de cumul :
Règlement : après la mise à niveau de Bedrock, Optimism ne paie à Ethereum que des frais de règlement d'environ 5 $ par jour. Le reste des frais généraux d'OP Stack provient de l'émission de blocs et des frais connexes. Les protocoles de règlement concurrents peuvent gagner encore moins.
Disponibilité des données : les couches DA fragmentées sont moins risquées pour sécuriser le réseau que les couches de disponibilité des données (DA) partagées telles que Celestia. De nombreux rollups ne veulent pas migrer leur DA hors d'Ethereum car cela sacrifierait leur cohérence avec Ethereum.
Tout segment de marché doit inclure des frameworks de cumul dans au moins une catégorie liée à l'exécution, et tout produit qui fournit des services d'exécution peut concurrencer les frameworks de cumul.
(2) Le cumul isolé en tant que service (RaaS) est intenable
L'explication naïve du RaaS est en fait Séquenceur isolé en tant que service (iSaaS). Ces entreprises n'ont pas leur propre protocole, mais elles déploient un framework de déploiement open source existant et exécutent un séquenceur. OP Stack a un partenariat avec iSaaS.
Le modèle commercial iSaaS consiste à facturer des frais statutaires récurrents en plus de facturer un pourcentage des frais du séquenceur. (Les services d'assistance supplémentaires, le conseil ou le développement de fonctionnalités personnalisées ne représentent pas un modèle commercial évolutif.) Pour être clair, ce serait un concurrent direct des réseaux de séquenceurs partagés tels qu'Espresso, Astria, Radius, etc. ; mais ils ont aussi Certains des faiblesses fatales.
Un gros problème avec iSaaS est qu'il ne s'aligne pas sur le cadre de déploiement. Comme mentionné ci-dessus, un cadre de cumul optimiste comme OP Stack doit monétiser les frais de tri. (Un framework zk-rollup peut ignorer les frais du donneur d'ordre et ne conserver que les frais du prouveur.)
D'autres problèmes de haut niveau avec ce type d'entreprise sont qu'il est banalisé, facile d'accès et n'a pas d'effets sur le réseau, contrairement à un ordonnateur partagé. iSaaS n'a pas les économies d'échelle des séquenceurs partagés car chaque séquenceur est isolé.
(3)Op****timiste le framework de cumul doit fournir son propre S****aaS
Afin de bien fonctionner, iSaaS peut renvoyer les frais de séquenceur dans un cadre de cumul optimiste, ne laissant que des frais fiat récurrents.
Mais maintenant, les frameworks iSaaS et rollup doivent être rentables indépendamment. La tarification idéale pour les grandes entreprises serait des paiements fiat récurrents élevés, mais des frais de commande peu élevés. Cependant, iSaaS n'a pas la possibilité de réduire les frais de commande, car les frais de commande ne leur appartiennent pas à l'origine, mais sont renvoyés au cadre de cumul. Si l'iSaaS ne partage pas les revenus avec le framework de cumul, le framework de cumul peut déployer son propre iSaaS et, puisque la confiance est déjà établie, peut pénétrer le marché plus profondément.
La raison pour laquelle il y a tant d'iSaaS qui apparaît est parce qu'il semble attrayant pour les lecteurs moins expérimentés. Cela ressemble à du SaaS, donc les investisseurs non-crypto peuvent trouver plus facile d'extrapoler les revenus fiduciaires. Mais iSaaS aura du mal à rivaliser avec les frameworks de cumul qui ont leur propre SaaS avec des revenus et des jetons natifs du protocole. Ce dernier a plus d'options en termes de tarification, les jetons peuvent être utilisés pour subventionner des projets prometteurs, subventionner les coûts d'acquisition de clients et les coûts de fonctionnement fixes (voir ci-dessous).
Les effets de réseau natifs du protocole et le partage des coûts fixes créeront une économie unitaire plus forte pour les protocoles avec une plus grande visibilité, faisant des fournisseurs de déploiement un peu gagnant-gagnant.
(4) CARTE DU MARCHÉ AJUSTÉE
Maintenant, je peux montrer comment j'ai peaufiné les graphismes de l'article de Messari, ce qui, à mon avis, semblait raisonnable à l'époque :
(Messari Graphique du marché)
(Graphique du marché ajusté)
Je vais renommer la catégorie "Pas de déploiement de code" et le Rollup SDK en Rollup Frameworks car de nombreux frameworks Rollup ne fournissent pas de SDK complet aux développeurs. J'aimerais aussi modifier ce schéma de l'écosystème Celestia :
(Diagramme de l'écosystème Celestia)
(Diagramme ajusté de l'écosystème de Celestia)
Je supprimerai RaaS, la couche de facturation et les machines virtuelles. Pour les projets de la catégorie Rollup Framework, ils se retrouveront presque certainement dans une autre catégorie également, ou ils ne seront pas rentables.
2. Il n'y a pas de repas gratuit : contraintes économiques et techniques
(1) La plupart des applications ne devraient pas avoir leur propre r****ollup
Le moyen le plus simple de démontrer l'économie d'un cumul pour une application spécifique consiste à consulter les cumuls en direct : Optimisme (après la mise à niveau de Bedrock). C'est l'approche que l'équipe Optimism a adoptée pour créer le tableau de bord Dune.
Ce qui suit suppose que le prix du gaz sur Ethereum est d'environ 25 gwei :
· Le coût de déploiement unique de la chaîne de réseau principale OP Stack est d'environ 1 ETH
· Le coût fixe de la chaîne OP Stack (même si le nombre de transactions en cours est de 0) est d'environ 0,5 ETH par jour
· Le coût variable est de 7,5 * 10^-5 ETH par transaction
Pour obtenir le coût fixe, j'ai multiplié les frais généraux moyens par transaction par le nombre de transactions exécutées ce jour-là et confirmé en exécutant la chaîne OP Stack sur le réseau principal.
Ce coût variable est faible, mais pas au niveau de Solana, et le coût fixe peut être amorti sur de nombreuses transactions. Dans un futur EIP-4844, nous pouvons à peu près supposer que ce coût sera divisé par 10. Pourtant, disons qu'un prix ETH de 2000 $ représente un plancher de 0,015 $ par transaction plus quelques coûts fixes amortis.
Nous pourrions considérer 0,00001 ETH (environ 0,02 $ au moment de la rédaction) comme un jeton de transaction raisonnable pour couvrir ce coût fixe, nous aurions donc besoin de 50 000 transactions par jour pour qu'un déploiement d'application particulier en vaille la peine. Avant EIP-4844, il était d'environ 0,17 $ par transaction et, de manière optimiste, après EIP-4844, il était de 0,03 $ par transaction. Nous pouvons ajouter une petite prime, de sorte que la chaîne de support de trieuse (partagée) est économique.
Ainsi, bien que quelque chose comme Opclave soit cool (j'aime vraiment l'idée, nous discutons avec l'équipe Dogan que nous pourrions intégrer cette fonctionnalité dans le cumul Eclipse), cela n'a pas beaucoup de sens en tant que chaîne OP Stack du réseau principal. La contrainte ici est que la chaîne OP Stack est ancrée sur Ethereum, dont l'espace de bloc est cher, et l'intention d'Optimism est d'être cohérent avec Ethereum.
Compte tenu de ces économies unitaires, ces petits projets DeFi dApps et NFT n'ont pas beaucoup de sens sur leurs propres chaînes. Pour ces dApps, il pourrait être judicieux de subventionner les coûts du gaz si l'économie unitaire à long terme d'Ethereum L2 a du sens pour leurs dApps, ou ils pourraient être disposés à assumer la perte de leur chaîne d'applications.
Si une application nécessite trop de volume de transactions, un cumul lié à Ethereum ne fonctionnera pas non plus, car des frais de transaction supérieurs à 0,01 USD peuvent être trop élevés. Ces types d'applications nécessiteront une nouvelle approche, comme celle qu'Eclipse est en train de créer avec nos machines virtuelles hautement parallèles et notre architecture de cumul souverain.
(2) Le cumul personnalisable doit être limité
Comme mentionné ci-dessus, OP Hacks ne sera pas inclus dans la Superchain d'Optimism. Cela a du sens car pour régler correctement ou fournir un ordre d'état pour les cumuls, nous avons besoin que certains invariants soient vrais. Toute modification devra être auditée avant de soutenir la valeur économique réelle.
Une autre bonne raison de limiter les cumuls spécifiques à l'application est d'examiner l'adoption de Cosmos. Le SDK Cosmos est très général, mais il n'a jamais déclenché le grand nombre de chaînes différentes auxquelles vous pourriez vous attendre. Cela peut être dû au fait que le processus de personnalisation nécessite trop de complexité technique, ou plus probablement parce que la longue traîne de l'application est bien adaptée à un petit nombre d'architectures. Les modèles spécifiques à un domaine, en revanche, peuvent résoudre les problèmes courants dans différents secteurs verticaux et fournir une architecture reproductible.