Le contenu suivant est un tweet de Jason Yanowitz :
Cela pourrait être partiellement inspiré par les deux aspects suivants :
(1) De nombreuses nouvelles blockchains Layer-1 récemment lancées ont mal performé, ainsi que
(2) Le succès remarquable de Hyperliquid et HyperEVM
Pour les lecteurs qui ne connaissent pas le domaine de la cryptographie, Hyperliquid est une plateforme de trading décentralisée pour les contrats perpétuels et le trading au comptant, qui a rapidement pris le contrôle du marché, dépassant même certaines bourses centralisées. Ils ont lancé leur propre blockchain EVM à haute vitesse sur la base du succès de leur plateforme de trading. Au moment de la rédaction de cet article, la capitalisation boursière d'Hyperliquid est d'environ 11 milliards de dollars, avec une valorisation entièrement diluée (FDV) atteignant 33 milliards de dollars.
Hyperliquid est l'un des premiers cas de développement réussi de nouvelles blockchains Layer-1 guidées par leur principale source de revenus. Je suis globalement d'accord avec l'avis de Jason. Cependant, la plupart des nouvelles blockchains Layer-1 ne disposent pas des avantages qu'a Hyperliquid au départ ; son fondateur Jeff a précédemment dirigé l'une des meilleures sociétés de trading haute fréquence dans le domaine de la crypto et dispose de réserves de fonds suffisantes, évitant ainsi la dépendance à un financement externe.
En conséquence, j’ai trouvé quelques idées sur la stratégie et la mise sur le marché (GTM) pour les nouvelles blockchains de couche 1 et des idées alternatives pour créer des applications par-dessus, en particulier lorsque vous empruntez des voies plus traditionnelles comme le financement par capital-risque et la construction d’une infrastructure entièrement nouvelle (si votre blockchain de couche 1 n’a pas de différenciation fonctionnelle significative et imite simplement d’autres projets, ces suggestions peuvent ne pas fonctionner pour vous).
Mon point de vue est principalement basé sur mon expérience sur le terrain avec Ritual, ainsi que sur une observation étroite des stratégies et de l'exécution des blockchains Layer-1 avec un écosystème solide. J'apprends encore, donc il se peut que je modifie mon point de vue à l'avenir.
En résumé, voici quelques-unes de mes réflexions :
Orientation proactive vs. "Une fois construit, les gens viendront"
« Construisez et ils viendront » était un état d’esprit stratégique qui prévalait dans l’espace crypto avant 2021, lorsque l’infrastructure était loin d’être adéquate. Au cœur de cette philosophie se trouve que si vous construisez une nouvelle chaîne ou une couche 2 (L2), les développeurs viendront spontanément et essaieront d’attirer de nouveaux utilisateurs et de capturer de la valeur à travers les jetons de votre chaîne. Cette stratégie a fonctionné pendant un certain temps, car les chaînes technologiquement solides avec une valeur d’investissement étaient rares à l’époque, et le secteur des infrastructures bénéficiait d’une prime à long terme. Cependant, avec le temps, cette prime s’estompe, d’autant plus qu’un grand nombre de nouvelles chaînes manquent d’utilisation pratique et d’attrait pour des applications (dont la plupart ne sont que des imitations ou des fourchettes).
De toute évidence, cette stratégie ne fonctionne plus, du moins pour les nouveaux projets blockchain. L’un des rares écosystèmes à avoir récemment mis en œuvre avec succès cette stratégie est HyperEVM, mais même dans ce cas, son succès n’est pas entièrement dû à cette stratégie. Le succès d’HyperEVM repose en grande partie sur Hyperliquid Core (exchange) en tant qu’application principale, créant une valeur réelle pour les détenteurs de $HYPE et l’écosystème Hype (et enrichissant de nombreux utilisateurs actifs avant l’événement de génération de jetons (TGE)).
En revanche, nous voyons maintenant de nombreux projets de Layer-1 (L1) et de Layer-2 (L2) adopter cette approche depuis le début, pensant pouvoir compenser leurs lacunes par des subventions et une simple promotion de marque, mais qui ont finalement échoué.
Cela dit, construire "quoi que ce soit" est difficile. Construire une infrastructure est difficile, développer des applications l'est également. Surtout dans le domaine de la cryptographie, construire n'est pas aussi simple que de déployer du code - il y a une quantité considérable de travail d'accompagnement à réaliser, y compris le marketing (GTM), les opérations, la conformité légale, etc., qui sont souvent sous-estimés.
Lorsque vous construisez une blockchain de couche 1 (à condition que vous construisiez une architecture entièrement nouvelle, et non un simple projet de fork), il s’agit à la fois d’un énorme défi technique et d’une énorme tâche de mise sur le marché (GTM). Personne ne peut être complètement sûr de ce que sera une « killer app », c’est donc votre travail de construire le produit et de travailler avec les développeurs pour soutenir la naissance d’applications de haute qualité autant que possible afin de maximiser les chances de succès de votre couche 1 et des développeurs qui vous font confiance.
Cela signifie plusieurs options pour l'équipe d'infrastructure :
Construire une équipe plus forte, accomplir tout en interne, y compris le développement d'applications de premier plan :
Cette méthode peut être efficace, mais elle présente les problèmes suivants :
(a) Il est difficile de trouver des talents exceptionnels.
(b) Recruter les meilleurs talents en interne signifie lever plus d’argent auprès d’investisseurs, ce que les investisseurs n’achètent pas aujourd’hui. (Je sais qu’Hyperliquid a tout fait avec 10 personnes, mais la plupart des fondateurs n’ont pas les forces et les ressources pour se lancer comme Jeff.) Malgré cela, leur performance était folle. ）
Vous devez non seulement embaucher des ingénieurs, mais aussi recruter des talents spécifiquement responsables de la GTM, des opérations, du marketing et des affaires juridiques. Bien qu'il puisse y avoir des opportunités de synergie interplateformes après la mise à l'échelle, cela prendra beaucoup de temps à réaliser, surtout en raison des énormes différences qui peuvent exister entre chaque application.
Suivre le vieux chemin de "Construire et les gens viendront" + distribution massive de subventions au développement :
Cette stratégie est généralement exploitée par certains "chasseurs de subventions" dont les équipes sont médiocres et dont les applications manquent de différenciation, ce qui n'est pas efficace à long terme.
Encourager activement le développement écologique :
Je veux dire qu'il faut adopter une approche plus proactive en construisant des prototypes ou des applications légères sur votre infrastructure, afin de promouvoir conjointement le déploiement complet de ces applications avec d'autres développeurs/partenaires.
Les développeurs souhaitent voir que vous ne vous contentez pas de parler, mais que vous investissez réellement du temps et des efforts. En fin de compte, au début d'un projet, personne ne comprend mieux le potentiel de cette infrastructure que ceux qui l'ont développée. De cette manière, vous pouvez :
(a) présente de nouvelles applications attrayantes ;
(b) prouve la possibilité d'être réalisé sur votre infrastructure ;
(c) a une certaine influence dans la direction du développement de l'écosystème, et ne se limite pas seulement à guider par la distribution de fonds.
Maintenant, la méthode (3) nécessite toujours d'excellents talents internes pour construire des applications, mais cela ressemble davantage à une pratique proactive visant à aider à construire des protocoles réels à partir de zéro, sans nécessiter d'importants investissements en ressources ou d'impacts sur l'amélioration de l'infrastructure de base. Fonctionnellement, cela ressemble presque à fournir un soutien de plateforme ou un incubateur pour ces entreprises.
Cette méthode pourrait-elle être un chemin plus difficile et plus lent ? Oui. Mais je pense que pour les projets qui perfectionnent encore leur infrastructure de base / qui en sont au stade précoce, c'est une approche plus axée sur le long terme. C'est exactement l'approche que nous adoptons chez Ritual, en construisant les applications que nous aimerions voir sur Ritual à travers des projets comme Ritual Shrine, et nous pensons que ces applications pourraient devenir des applications révolutionnaires dans le domaine de la cryptographie et de l'intelligence artificielle.
Mais ce n'est pas seulement nous - Solana a eu de nombreuses activités de construction positives dès le début en collaborant avec FTX, Jump et d'autres équipes. Plusieurs nouveaux projets populaires sur Twitter Crypto (CT), tels que Plasma, MegaETH, Monad, etc., ont adopté une approche proactive en créant un ensemble de protocoles de base natifs à leur écosystème sur la base des protocoles existants.
Je m'attends à ce que cela devienne une stratégie dominante (et à augmenter la difficulté de se démarquer réellement au-dessus du travail technique).
Dans certaines situations, j'espère que nous pourrons construire en interne de nombreux prototypes de Ritual Shrine et les exploiter nous-mêmes. Mais je reconnais également que ces projets nécessitent des équipes spécialisées pour réussir dans l'exécution des produits et du GTM (ces équipes peuvent être plus adaptées au marché que nous, même si nous avons ce que je considère comme l'une des équipes interfonctionnelles les plus puissantes dans ce domaine).
Si nous pouvions construire aux côtés de ces équipes tout en offrant de solides retours économiques aux développeurs externes, ce serait toujours une victoire. Cela nous permet de « posséder » cela au sens métaphorique, tout en introduisant de nouvelles perspectives et de nouveaux talents.
En bref, en bref : oui, c’est génial si vous pouvez avoir des applications de première partie haut de gamme sur votre nouvelle infrastructure. Mais si les ressources sont limitées, essayez de guider activement votre écosystème sous la forme de prototypes, en construisant avec eux, plutôt que d’aborder paresseusement le processus.
Le contenu est fourni à titre de référence uniquement, il ne s'agit pas d'une sollicitation ou d'une offre. Aucun conseil en investissement, fiscalité ou juridique n'est fourni. Consultez l'Avertissement pour plus de détails sur les risques.
Chiffrement des infrastructures : pourquoi l'idée que "si nous les construisons, ils viendront" ne fonctionne pas ?
Auteur : Saneel Sreeni
Compilation : TechFlow de Shenchao
Le contenu suivant est un tweet de Jason Yanowitz :
Cela pourrait être partiellement inspiré par les deux aspects suivants :
(1) De nombreuses nouvelles blockchains Layer-1 récemment lancées ont mal performé, ainsi que
(2) Le succès remarquable de Hyperliquid et HyperEVM
Pour les lecteurs qui ne connaissent pas le domaine de la cryptographie, Hyperliquid est une plateforme de trading décentralisée pour les contrats perpétuels et le trading au comptant, qui a rapidement pris le contrôle du marché, dépassant même certaines bourses centralisées. Ils ont lancé leur propre blockchain EVM à haute vitesse sur la base du succès de leur plateforme de trading. Au moment de la rédaction de cet article, la capitalisation boursière d'Hyperliquid est d'environ 11 milliards de dollars, avec une valorisation entièrement diluée (FDV) atteignant 33 milliards de dollars.
Hyperliquid est l'un des premiers cas de développement réussi de nouvelles blockchains Layer-1 guidées par leur principale source de revenus. Je suis globalement d'accord avec l'avis de Jason. Cependant, la plupart des nouvelles blockchains Layer-1 ne disposent pas des avantages qu'a Hyperliquid au départ ; son fondateur Jeff a précédemment dirigé l'une des meilleures sociétés de trading haute fréquence dans le domaine de la crypto et dispose de réserves de fonds suffisantes, évitant ainsi la dépendance à un financement externe.
En conséquence, j’ai trouvé quelques idées sur la stratégie et la mise sur le marché (GTM) pour les nouvelles blockchains de couche 1 et des idées alternatives pour créer des applications par-dessus, en particulier lorsque vous empruntez des voies plus traditionnelles comme le financement par capital-risque et la construction d’une infrastructure entièrement nouvelle (si votre blockchain de couche 1 n’a pas de différenciation fonctionnelle significative et imite simplement d’autres projets, ces suggestions peuvent ne pas fonctionner pour vous).
Mon point de vue est principalement basé sur mon expérience sur le terrain avec Ritual, ainsi que sur une observation étroite des stratégies et de l'exécution des blockchains Layer-1 avec un écosystème solide. J'apprends encore, donc il se peut que je modifie mon point de vue à l'avenir.
En résumé, voici quelques-unes de mes réflexions :
Orientation proactive vs. "Une fois construit, les gens viendront"
« Construisez et ils viendront » était un état d’esprit stratégique qui prévalait dans l’espace crypto avant 2021, lorsque l’infrastructure était loin d’être adéquate. Au cœur de cette philosophie se trouve que si vous construisez une nouvelle chaîne ou une couche 2 (L2), les développeurs viendront spontanément et essaieront d’attirer de nouveaux utilisateurs et de capturer de la valeur à travers les jetons de votre chaîne. Cette stratégie a fonctionné pendant un certain temps, car les chaînes technologiquement solides avec une valeur d’investissement étaient rares à l’époque, et le secteur des infrastructures bénéficiait d’une prime à long terme. Cependant, avec le temps, cette prime s’estompe, d’autant plus qu’un grand nombre de nouvelles chaînes manquent d’utilisation pratique et d’attrait pour des applications (dont la plupart ne sont que des imitations ou des fourchettes).
De toute évidence, cette stratégie ne fonctionne plus, du moins pour les nouveaux projets blockchain. L’un des rares écosystèmes à avoir récemment mis en œuvre avec succès cette stratégie est HyperEVM, mais même dans ce cas, son succès n’est pas entièrement dû à cette stratégie. Le succès d’HyperEVM repose en grande partie sur Hyperliquid Core (exchange) en tant qu’application principale, créant une valeur réelle pour les détenteurs de $HYPE et l’écosystème Hype (et enrichissant de nombreux utilisateurs actifs avant l’événement de génération de jetons (TGE)).
En revanche, nous voyons maintenant de nombreux projets de Layer-1 (L1) et de Layer-2 (L2) adopter cette approche depuis le début, pensant pouvoir compenser leurs lacunes par des subventions et une simple promotion de marque, mais qui ont finalement échoué.
Cela dit, construire "quoi que ce soit" est difficile. Construire une infrastructure est difficile, développer des applications l'est également. Surtout dans le domaine de la cryptographie, construire n'est pas aussi simple que de déployer du code - il y a une quantité considérable de travail d'accompagnement à réaliser, y compris le marketing (GTM), les opérations, la conformité légale, etc., qui sont souvent sous-estimés.
Lorsque vous construisez une blockchain de couche 1 (à condition que vous construisiez une architecture entièrement nouvelle, et non un simple projet de fork), il s’agit à la fois d’un énorme défi technique et d’une énorme tâche de mise sur le marché (GTM). Personne ne peut être complètement sûr de ce que sera une « killer app », c’est donc votre travail de construire le produit et de travailler avec les développeurs pour soutenir la naissance d’applications de haute qualité autant que possible afin de maximiser les chances de succès de votre couche 1 et des développeurs qui vous font confiance.
Cela signifie plusieurs options pour l'équipe d'infrastructure :
Construire une équipe plus forte, accomplir tout en interne, y compris le développement d'applications de premier plan :
Cette méthode peut être efficace, mais elle présente les problèmes suivants :
(a) Il est difficile de trouver des talents exceptionnels.
(b) Recruter les meilleurs talents en interne signifie lever plus d’argent auprès d’investisseurs, ce que les investisseurs n’achètent pas aujourd’hui. (Je sais qu’Hyperliquid a tout fait avec 10 personnes, mais la plupart des fondateurs n’ont pas les forces et les ressources pour se lancer comme Jeff.) Malgré cela, leur performance était folle. ）
Vous devez non seulement embaucher des ingénieurs, mais aussi recruter des talents spécifiquement responsables de la GTM, des opérations, du marketing et des affaires juridiques. Bien qu'il puisse y avoir des opportunités de synergie interplateformes après la mise à l'échelle, cela prendra beaucoup de temps à réaliser, surtout en raison des énormes différences qui peuvent exister entre chaque application.
Suivre le vieux chemin de "Construire et les gens viendront" + distribution massive de subventions au développement :
Cette stratégie est généralement exploitée par certains "chasseurs de subventions" dont les équipes sont médiocres et dont les applications manquent de différenciation, ce qui n'est pas efficace à long terme.
Encourager activement le développement écologique :
Je veux dire qu'il faut adopter une approche plus proactive en construisant des prototypes ou des applications légères sur votre infrastructure, afin de promouvoir conjointement le déploiement complet de ces applications avec d'autres développeurs/partenaires.
Les développeurs souhaitent voir que vous ne vous contentez pas de parler, mais que vous investissez réellement du temps et des efforts. En fin de compte, au début d'un projet, personne ne comprend mieux le potentiel de cette infrastructure que ceux qui l'ont développée. De cette manière, vous pouvez :
(a) présente de nouvelles applications attrayantes ;
(b) prouve la possibilité d'être réalisé sur votre infrastructure ;
(c) a une certaine influence dans la direction du développement de l'écosystème, et ne se limite pas seulement à guider par la distribution de fonds.
Maintenant, la méthode (3) nécessite toujours d'excellents talents internes pour construire des applications, mais cela ressemble davantage à une pratique proactive visant à aider à construire des protocoles réels à partir de zéro, sans nécessiter d'importants investissements en ressources ou d'impacts sur l'amélioration de l'infrastructure de base. Fonctionnellement, cela ressemble presque à fournir un soutien de plateforme ou un incubateur pour ces entreprises.
Cette méthode pourrait-elle être un chemin plus difficile et plus lent ? Oui. Mais je pense que pour les projets qui perfectionnent encore leur infrastructure de base / qui en sont au stade précoce, c'est une approche plus axée sur le long terme. C'est exactement l'approche que nous adoptons chez Ritual, en construisant les applications que nous aimerions voir sur Ritual à travers des projets comme Ritual Shrine, et nous pensons que ces applications pourraient devenir des applications révolutionnaires dans le domaine de la cryptographie et de l'intelligence artificielle.
Mais ce n'est pas seulement nous - Solana a eu de nombreuses activités de construction positives dès le début en collaborant avec FTX, Jump et d'autres équipes. Plusieurs nouveaux projets populaires sur Twitter Crypto (CT), tels que Plasma, MegaETH, Monad, etc., ont adopté une approche proactive en créant un ensemble de protocoles de base natifs à leur écosystème sur la base des protocoles existants.
Je m'attends à ce que cela devienne une stratégie dominante (et à augmenter la difficulté de se démarquer réellement au-dessus du travail technique).
Dans certaines situations, j'espère que nous pourrons construire en interne de nombreux prototypes de Ritual Shrine et les exploiter nous-mêmes. Mais je reconnais également que ces projets nécessitent des équipes spécialisées pour réussir dans l'exécution des produits et du GTM (ces équipes peuvent être plus adaptées au marché que nous, même si nous avons ce que je considère comme l'une des équipes interfonctionnelles les plus puissantes dans ce domaine).
Si nous pouvions construire aux côtés de ces équipes tout en offrant de solides retours économiques aux développeurs externes, ce serait toujours une victoire. Cela nous permet de « posséder » cela au sens métaphorique, tout en introduisant de nouvelles perspectives et de nouveaux talents.
En bref, en bref : oui, c’est génial si vous pouvez avoir des applications de première partie haut de gamme sur votre nouvelle infrastructure. Mais si les ressources sont limitées, essayez de guider activement votre écosystème sous la forme de prototypes, en construisant avec eux, plutôt que d’aborder paresseusement le processus.