Мифы о криптоинфраструктуре: почему «построил и придут» не работает?

Автор: Санил Шрини

Компилятор: Deep Tide TechFlow

Ниже приведен твит от Джейсона Яновица:

может быть частично вдохновлен следующими двумя вещами:

(1) Многие из недавно запущенных блокчейнов уровня 1 показали слабые результаты, и

(2) выдающийся успех Hyperliquid и HyperEVM

Для читателей, которые не знакомы с криптопространством, Hyperliquid — это децентрализованная платформа для бессрочной и спотовой торговли, которая быстро заняла доминирующее положение на рынке, даже превзойдя некоторые централизованные биржи. Они запустили собственный высокоскоростной блокчейн EVM, основанный на успехе торговой платформы. На момент написания статьи рыночная капитализация Hyperliquid составляла около $11 млрд, а полностью разводненная оценка (FDV) — $33 млрд.

Hyperliquid — один из первых кейсов, который успешно возглавил разработку нового блокчейна уровня 1 через свое основное приложение для получения дохода. В целом согласен с Джейсоном. Тем не менее, большинство новых блокчейнов уровня 1 не имеют тех же преимуществ, что и Hyperliquid; Ее основатель Джефф ранее руководил одной из лучших фирм высокочастотного трейдинга в криптопространстве и имеет достаточные резервы средств, чтобы избежать необходимости полагаться на внешнее финансирование.

В результате у меня появились некоторые идеи о стратегии и выходе на рынок (GTM) для новых блокчейнов уровня 1, а также альтернативные идеи для создания приложений на их основе, особенно при выборе более традиционных путей, таких как венчурное финансирование и создание совершенно новой инфраструктуры (если ваш блокчейн уровня 1 не имеет существенной функциональной дифференциации и просто имитирует другие проекты, эти предложения могут вам не подойти).

Мои взгляды в значительной степени основаны на моем практическом опыте работы в Ritual, а также на тщательном наблюдении за стратегией и реализацией других блокчейнов уровня 1 с сильными экосистемами. Я все еще учусь, так что, возможно, пересмотрю свои взгляды в будущем.

Подводя итог, вот некоторые из моих выводов:

Упреждающая загрузка против «

Строй, и они придут» — это стратегический образ мышления, который преобладал в криптопространстве до 2021 года, когда инфраструктура была далека от адекватной. В основе этой философии лежит то, что если вы создадите новую цепочку или Layer-2 (L2), разработчики придут спонтанно и попытаются привлечь новых пользователей и получить выгоду с помощью токенов вашей цепочки. Эта стратегия работала какое-то время, потому что технологически устойчивые цепочки с инвестиционной ценностью в то время были дефицитом, а сектор инфраструктуры пользовался долгосрочной премией. Однако со временем эта премия исчезает, тем более что большому количеству новых цепей не хватает практического применения и привлекательности для приложений (большинство из которых являются просто имитациями или форками).

Очевидно, что эта стратегия больше не работает, по крайней мере, для новых блокчейн-проектов. Одной из немногих экосистем, которая в последнее время успешно реализует эту стратегию, является HyperEVM, но даже в этом случае ее успех не полностью связан с этой стратегией. Успех HyperEVM в значительной степени зависит от Hyperliquid Core (биржи) в качестве основного приложения, создающего реальную ценность для держателей $HYPE и экосистемы Hype (и обогащающего многих активных пользователей до события генерации токенов (TGE)).

В отличие от этого, сейчас мы видим большое количество проектов Layer-1 (L1) и Layer-2 (L2), которые использовали этот подход с самого начала, полагая, что они могут компенсировать недостатки за счет раздачи грантов и чистого брендинга, но в конечном итоге потерпели неудачу.

Тем не менее, трудно построить «что-либо». Сложно создавать инфраструктуру и разрабатывать приложения. Особенно в криптопространстве сборка — это не только развертывание кода — предстоит проделать много работы, включая выход на рынок (GTM), эксплуатацию, соблюдение законодательства и многое другое, что часто недооценивается.

Когда вы создаете блокчейн уровня 1 (при условии, что вы создаете совершенно новую архитектуру, а не простой форк-проект), это одновременно и огромная техническая проблема, и огромная задача по выходу на рынок (GTM). Никто не может быть полностью уверен в том, каким будет «убийственное приложение», поэтому ваша задача — создать продукт и работать с разработчиками, чтобы максимально поддерживать рождение высококачественных приложений, чтобы максимизировать вероятность успеха для вашего Layer-1 и разработчиков, которые вам доверяют.

Это означает несколько вариантов для команд по инфраструктуре:

1. собрать более сильную команду и делать все своими силами, включая разработку приложений верхнего уровня:

   Этот подход может работать, но у него есть следующие проблемы:

   1. (а) Хороших специалистов трудно найти.

   2. b) внутренний набор наиболее талантливых специалистов означает, что необходимо привлекать больше денег от инвесторов, которые инвесторы сегодня не покупают. (Я знаю, что Hyperliquid сделала все это с 10 людьми, но у большинства основателей нет сил и ресурсов, чтобы начать, как у Джеффа.) Несмотря на это, их выступление было безумным.

   3. Вам нужно нанимать не только инженеров, но и людей, которые специализируются на GTM, операциях, маркетинге и юриспруденции. Несмотря на то, что могут существовать возможности для масштабного межплатформенного сотрудничества, для этого потребуется много времени, тем более что каждое приложение может сильно различаться.

2. Идите по старому пути «построй и кто-то придет» + раздайте много грантов на разработку:

эту стратегию обычно используют некоторые «охотники за грантами» с посредственными командами и отсутствием дифференциации приложений, и она плохо работает в долгосрочной перспективе.

1. Активное лидерство в экосистеме:

я имею в виду использование более активного подхода путем создания прототипов или некоторых облегченных приложений поверх вашей инфраструктуры и работы с другими разработчиками/партнерами для полного использования этих приложений.

Разработчики хотят видеть, что вы не просто говорите, а на самом деле вкладываете в это свое время и усилия. В конце концов, никто не понимает потенциал этой инфраструктуры лучше, чем люди, которые ее создали. Таким образом, вы можете:

(а) продемонстрировать новые и привлекательные приложения;

(b) продемонстрировать вероятность того, что это достижимо в вашей инфраструктуре;

в) оказывать определенное влияние на экологическое развитие, а не только путем распределения средств.

В настоящее время подход (3) по-прежнему требует больших собственных талантов для создания приложений, но это скорее упреждающая практика, предназначенная для создания реального протокола с нуля, не требуя значительных вложений ресурсов или влияния на улучшения базовой инфраструктуры. Функционально это почти как предоставление поддержки платформы или инкубации для этих компаний.

Может ли этот подход быть более сложным и медленным путем? Да. Но я думаю, что это более долгосрочный подход для проектов, которые все еще совершенствуют свою основную инфраструктуру / находятся на ранних стадиях. Именно такой подход мы использовали в Ritual, создавая приложения, которые мы хотим видеть в Ritual, с такими проектами, как Ritual Shrine, которые, по нашему мнению, могут стать убойными приложениями для криптовалют и искусственного интеллекта.

Но дело не только в нас — Solana активно занималась строительством в первые дни, работая с FTX, Jump и несколькими другими командами. Несколько новых проектов, популярных в крипто-Twitter (CT), таких как Plasma, MegaETH, Monad и другие, применили упреждающий подход к созданию основного набора протоколов, встроенных в их экосистему, поверх существующих протоколов.

Я ожидаю, что это станет доминирующей стратегией (и усложнит задачу действительно выделиться на вершине технической работы).

В некоторых случаях мне хотелось бы, чтобы мы могли полностью создать прототип многих ритуальных святилищ внутри компании и управлять ими самостоятельно. Но я также признаю, что эти проекты требуют специальных команд для достижения успеха в создании продукта и GTM (что, возможно, лучше подходит для рынка, чем мы, даже если у нас есть, как я считаю, одна из самых сильных кросс-функциональных команд в этой области).

Если мы сможем работать бок о бок с этими командами, обеспечивая при этом сильное финансовое вознаграждение внешним разработчикам, это все равно победа. Это позволяет нам «владеть» им в переносном смысле, привнося при этом новые перспективы и новые таланты.

Короче говоря, да, это здорово, если вы можете иметь первоклассные собственные приложения в своей новой инфраструктуре. Но если ресурсы ограничены, то старайтесь активно руководить своей экосистемой в виде прототипов, строя с их помощью, а не лениво подходить к процессу.