Это может быть отчасти вдохновлено двумя аспектами:
(1) Многие недавно запущенные блокчейны Layer-1 показывают слабые результаты, а также
(2) Выдающийся успех Hyperliquid и HyperEVM
Для читателей, не знакомых с криптовалютной сферой, Hyperliquid является децентрализованной платформой для бессрочных контрактов и спотовой торговли, которая быстро заняла доминирующее положение на рынке, даже превзойдя некоторые централизованные биржи. Они на основе успешной торговой платформы запустили свою собственную высокоскоростную EVM-блокчейн. На момент написания этой статьи рыночная капитализация Hyperliquid составляет около 11 миллиардов долларов, а полностью разводненная оценка (FDV) достигает 33 миллиардов долларов.
Hyperliquid является одним из первых примеров успешного развития нового Layer-1 блокчейна через его основной источник дохода. В целом, я согласен с мнением Джейсона. Однако большинство новых Layer-1 блокчейнов в начале не имеют тех же преимуществ, что и Hyperliquid; его основатель Джефф ранее управлял одной из лучших высокочастотных торговых компаний в криптовалютной сфере и имел достаточные финансовые ресурсы, что позволило избежать зависимости от внешнего финансирования.
Таким образом, я предложил несколько стратегий и альтернативных идей для маркетинга нового Layer-1 блокчейна (GTM) и создания приложений на его основе, особенно когда используются более традиционные пути, такие как венчурное финансирование и строительство совершенно новой инфраструктуры (если у вашего Layer-1 блокчейна нет значительных функциональных отличий и он просто копирует другие проекты, эти советы могут быть для вас неэффективными).
Моя точка зрения основана в основном на моем практическом опыте в Ritual, а также на пристальном наблюдении за стратегиями и исполнением других Layer-1 блокчейнов с мощными экосистемами. Я продолжаю учиться, поэтому, возможно, в будущем изменю свою точку зрения.
В общем, это некоторые из моих мнений:
Активное руководство против "Построите хорошо, и люди придут"
"Построить и они придут" (Build and they’ll come) — это стратегическое мышление, распространенное в криптоиндустрии до 2021 года, когда инфраструктура была крайне недостаточной. Суть этой идеи заключается в том, что если вы создадите новую цепочку или Layer-2 (L2), разработчики сами придут, пытаясь привлечь новых пользователей и захватить ценность через токены вашей цепочки. Эта стратегия на какое-то время сработала, поскольку в то время цепочки с хорошими технологиями и инвестиционной ценностью были крайне редки, а в области инфраструктуры существовал долгосрочный премиум. Однако с течением времени этот премиум постепенно исчез, особенно в условиях появления множества новых цепочек, которые не имели реального использования и привлекательных приложений (большинство приложений на цепочках просто имитируют или форкают).
Очевидно, что эта стратегия теперь больше не срабатывает, по крайней мере для новых блокчейн-проектов. Одной из немногих экосистем, которые недавно успешно реализовали эту стратегию, является HyperEVM, но даже в этом случае его успех не полностью связан с этой стратегией. Успех HyperEVM в основном зависит от Hyperliquid Core (биржа) в качестве основного приложения, которое создает реальную ценность для держателей $HYPE и экосистемы Hype (и позволило многим активным пользователям, которые участвовали до события генерации токенов (TGE), заработать состояние).
В сравнении с этим, сейчас мы видим множество проектов Layer-1 (L1) и Layer-2 (L2), которые с самого начала приняли такой подход, полагая, что могут компенсировать недостатки за счет предоставления субсидий и простой брендовой рекламы, но в конечном итоге потерпели неудачу.
Тем не менее, построить «что угодно» очень сложно. Создавать инфраструктуру сложно, так же сложно разрабатывать приложения. Особенно в области криптовалют, построение - это не просто развертывание кода; необходимо провести массу сопутствующих работ, включая маркетинг (GTM), операционную деятельность, юридическую и регуляторную соответствие, которые часто недооценены.
Когда вы создаете блокчейн уровня 1 (при условии, что вы разрабатываете совершенно новую архитектуру, а не просто проект форка), это является как огромным техническим вызовом, так и масштабной задачей по выходу на рынок (GTM). Никто не может с полной уверенностью сказать, что такое «убийственное приложение», поэтому ваша задача — создать хороший продукт и сотрудничать с разработчиками, чтобы максимально поддерживать появление качественных приложений, тем самым максимизируя шансы на успех вашего уровня 1 и доверие к вашим разработчикам.
Это означает для команды инфраструктуры несколько вариантов:
Создайте более сильную команду, чтобы завершить все внутри, включая разработку лучших приложений:
Этот способ может быть эффективным, но существуют следующие проблемы:
(a) Отличных специалистов трудно найти.
(b) Внутренний набор талантливых сотрудников означает необходимость привлечения большего количества средств от инвесторов, но на сегодняшний день инвесторы не заинтересованы в этом. (Я знаю, что Hyperliquid справился с этим с помощью 10 человек, но большинство основателей не обладают такими преимуществами и ресурсами на старте, как Джефф. Тем не менее, их результаты можно назвать безумными.)
Вам нужно не только нанять инженеров, но и людей, которые специализируются на GTM, операциях, маркетинге и юридических вопросах. Несмотря на то, что могут существовать возможности для масштабного межплатформенного сотрудничества, для этого потребуется много времени, тем более что каждое приложение может сильно различаться.
Идти по старому пути "построим хорошо, и люди придут" + массовое предоставление субсидий на развитие:
Эта стратегия обычно используется некоторыми командами со средними силами и отсутствием дифференциации приложений, называемыми "охотниками за субсидиями", и в долгосрочной перспективе она не очень эффективна.
Активное руководство развитием экосистемы:
Я имею в виду более активный подход, совместно с другими разработчиками/партнерами продвигать полное внедрение этих приложений, создавая прототипы или некоторые легковесные приложения на вашей инфраструктуре.
Разработчики хотят видеть, что вы не просто говорите это, а действительно вкладываете время и усилия. В конце концов, на начальном этапе проекта никто не знает его потенциал лучше, чем те, кто разрабатывает эту инфраструктуру. Таким образом, вы можете:
(a) демонстрирует привлекательные новые приложения;
(b) подтверждение возможности, которую можно реализовать на вашей инфраструктуре;
(c) имеет определенное влияние на направление развития экосистемы, а не только через распределение средств для руководства.
Сейчас метод (3) все еще требует наличия отличных специалистов по разработке приложений внутри, но это больше похоже на активную практику, направленную на помощь в создании реального протокола с нуля, без необходимости значительных вложений ресурсов или влияния на улучшения основной инфраструктуры. Функционально это почти как предоставление платформенной поддержки или инкубации для этих компаний.
Возможно ли, что этот метод является более трудным и медленным путем? Да. Но я считаю, что для тех проектов, которые все еще совершенствуют свою основную инфраструктуру/находятся на ранних стадиях, это более долгосрочный подход. Мы именно такой подход и используем в Ritual, строя приложения, которые мы хотим видеть на Ritual, через такие проекты, как Ritual Shrine, и считаем, что эти приложения могут стать убийственными приложениями в области криптовалют и искусственного интеллекта.
Но дело не только в нас — Solana активно занималась строительством в первые дни, работая с FTX, Jump и несколькими другими командами. Несколько новых проектов, популярных в крипто-Twitter (CT), таких как Plasma, MegaETH, Monad и другие, применили проактивный подход, создав основной набор протоколов, встроенных в их экосистему, поверх существующих протоколов.
Я ожидаю, что это станет доминирующей стратегией (и увеличит сложность выделиться на фоне действительно выдающихся технических работ).
В некоторых случаях я надеюсь, что мы сможем полностью построить множество прототипов Ritual Shrine внутри компании и управлять ими самостоятельно. Но я также понимаю, что для успешного выполнения этих проектов необходимы специализированные команды в области продукта и GTM (эти команды могут быть более подходящими для рынка, даже если у нас есть одна из самых сильных кросс-функциональных команд в этой области).
Если мы сможем строить вместе с этими командами и при этом предоставить внешним разработчикам хорошие экономические вознаграждения, это все равно будет победой. Это позволяет нам в метафорическом смысле "владеть" этим, одновременно привнося новые перспективы и новые таланты.
В общем, кратко говоря: да, было бы здорово, если бы у вас были первоклассные приложения от первого лица на вашей новой инфраструктуре. Но если ресурсы ограничены, то необходимо активно направлять развитие вашей экосистемы в виде прототипа, строя их вместе, а не бездействуя в этом процессе.
Содержание носит исключительно справочный характер и не является предложением или офертой. Консультации по инвестициям, налогообложению или юридическим вопросам не предоставляются. Более подробную информацию о рисках см. в разделе «Дисклеймер».
Шифрование инфраструктуры: почему "построив их, они придут" не работает?
Автор: Санеел Срини
Компиляция: Shenchao TechFlow
Следующее содержание - это твит Джейсона Яновица:
Это может быть отчасти вдохновлено двумя аспектами:
(1) Многие недавно запущенные блокчейны Layer-1 показывают слабые результаты, а также
(2) Выдающийся успех Hyperliquid и HyperEVM
Для читателей, не знакомых с криптовалютной сферой, Hyperliquid является децентрализованной платформой для бессрочных контрактов и спотовой торговли, которая быстро заняла доминирующее положение на рынке, даже превзойдя некоторые централизованные биржи. Они на основе успешной торговой платформы запустили свою собственную высокоскоростную EVM-блокчейн. На момент написания этой статьи рыночная капитализация Hyperliquid составляет около 11 миллиардов долларов, а полностью разводненная оценка (FDV) достигает 33 миллиардов долларов.
Hyperliquid является одним из первых примеров успешного развития нового Layer-1 блокчейна через его основной источник дохода. В целом, я согласен с мнением Джейсона. Однако большинство новых Layer-1 блокчейнов в начале не имеют тех же преимуществ, что и Hyperliquid; его основатель Джефф ранее управлял одной из лучших высокочастотных торговых компаний в криптовалютной сфере и имел достаточные финансовые ресурсы, что позволило избежать зависимости от внешнего финансирования.
Таким образом, я предложил несколько стратегий и альтернативных идей для маркетинга нового Layer-1 блокчейна (GTM) и создания приложений на его основе, особенно когда используются более традиционные пути, такие как венчурное финансирование и строительство совершенно новой инфраструктуры (если у вашего Layer-1 блокчейна нет значительных функциональных отличий и он просто копирует другие проекты, эти советы могут быть для вас неэффективными).
Моя точка зрения основана в основном на моем практическом опыте в Ritual, а также на пристальном наблюдении за стратегиями и исполнением других Layer-1 блокчейнов с мощными экосистемами. Я продолжаю учиться, поэтому, возможно, в будущем изменю свою точку зрения.
В общем, это некоторые из моих мнений:
Активное руководство против "Построите хорошо, и люди придут"
"Построить и они придут" (Build and they’ll come) — это стратегическое мышление, распространенное в криптоиндустрии до 2021 года, когда инфраструктура была крайне недостаточной. Суть этой идеи заключается в том, что если вы создадите новую цепочку или Layer-2 (L2), разработчики сами придут, пытаясь привлечь новых пользователей и захватить ценность через токены вашей цепочки. Эта стратегия на какое-то время сработала, поскольку в то время цепочки с хорошими технологиями и инвестиционной ценностью были крайне редки, а в области инфраструктуры существовал долгосрочный премиум. Однако с течением времени этот премиум постепенно исчез, особенно в условиях появления множества новых цепочек, которые не имели реального использования и привлекательных приложений (большинство приложений на цепочках просто имитируют или форкают).
Очевидно, что эта стратегия теперь больше не срабатывает, по крайней мере для новых блокчейн-проектов. Одной из немногих экосистем, которые недавно успешно реализовали эту стратегию, является HyperEVM, но даже в этом случае его успех не полностью связан с этой стратегией. Успех HyperEVM в основном зависит от Hyperliquid Core (биржа) в качестве основного приложения, которое создает реальную ценность для держателей $HYPE и экосистемы Hype (и позволило многим активным пользователям, которые участвовали до события генерации токенов (TGE), заработать состояние).
В сравнении с этим, сейчас мы видим множество проектов Layer-1 (L1) и Layer-2 (L2), которые с самого начала приняли такой подход, полагая, что могут компенсировать недостатки за счет предоставления субсидий и простой брендовой рекламы, но в конечном итоге потерпели неудачу.
Тем не менее, построить «что угодно» очень сложно. Создавать инфраструктуру сложно, так же сложно разрабатывать приложения. Особенно в области криптовалют, построение - это не просто развертывание кода; необходимо провести массу сопутствующих работ, включая маркетинг (GTM), операционную деятельность, юридическую и регуляторную соответствие, которые часто недооценены.
Когда вы создаете блокчейн уровня 1 (при условии, что вы разрабатываете совершенно новую архитектуру, а не просто проект форка), это является как огромным техническим вызовом, так и масштабной задачей по выходу на рынок (GTM). Никто не может с полной уверенностью сказать, что такое «убийственное приложение», поэтому ваша задача — создать хороший продукт и сотрудничать с разработчиками, чтобы максимально поддерживать появление качественных приложений, тем самым максимизируя шансы на успех вашего уровня 1 и доверие к вашим разработчикам.
Это означает для команды инфраструктуры несколько вариантов:
Создайте более сильную команду, чтобы завершить все внутри, включая разработку лучших приложений:
Этот способ может быть эффективным, но существуют следующие проблемы:
(a) Отличных специалистов трудно найти.
(b) Внутренний набор талантливых сотрудников означает необходимость привлечения большего количества средств от инвесторов, но на сегодняшний день инвесторы не заинтересованы в этом. (Я знаю, что Hyperliquid справился с этим с помощью 10 человек, но большинство основателей не обладают такими преимуществами и ресурсами на старте, как Джефф. Тем не менее, их результаты можно назвать безумными.)
Вам нужно не только нанять инженеров, но и людей, которые специализируются на GTM, операциях, маркетинге и юридических вопросах. Несмотря на то, что могут существовать возможности для масштабного межплатформенного сотрудничества, для этого потребуется много времени, тем более что каждое приложение может сильно различаться.
Идти по старому пути "построим хорошо, и люди придут" + массовое предоставление субсидий на развитие:
Эта стратегия обычно используется некоторыми командами со средними силами и отсутствием дифференциации приложений, называемыми "охотниками за субсидиями", и в долгосрочной перспективе она не очень эффективна.
Активное руководство развитием экосистемы:
Я имею в виду более активный подход, совместно с другими разработчиками/партнерами продвигать полное внедрение этих приложений, создавая прототипы или некоторые легковесные приложения на вашей инфраструктуре.
Разработчики хотят видеть, что вы не просто говорите это, а действительно вкладываете время и усилия. В конце концов, на начальном этапе проекта никто не знает его потенциал лучше, чем те, кто разрабатывает эту инфраструктуру. Таким образом, вы можете:
(a) демонстрирует привлекательные новые приложения;
(b) подтверждение возможности, которую можно реализовать на вашей инфраструктуре;
(c) имеет определенное влияние на направление развития экосистемы, а не только через распределение средств для руководства.
Сейчас метод (3) все еще требует наличия отличных специалистов по разработке приложений внутри, но это больше похоже на активную практику, направленную на помощь в создании реального протокола с нуля, без необходимости значительных вложений ресурсов или влияния на улучшения основной инфраструктуры. Функционально это почти как предоставление платформенной поддержки или инкубации для этих компаний.
Возможно ли, что этот метод является более трудным и медленным путем? Да. Но я считаю, что для тех проектов, которые все еще совершенствуют свою основную инфраструктуру/находятся на ранних стадиях, это более долгосрочный подход. Мы именно такой подход и используем в Ritual, строя приложения, которые мы хотим видеть на Ritual, через такие проекты, как Ritual Shrine, и считаем, что эти приложения могут стать убийственными приложениями в области криптовалют и искусственного интеллекта.
Но дело не только в нас — Solana активно занималась строительством в первые дни, работая с FTX, Jump и несколькими другими командами. Несколько новых проектов, популярных в крипто-Twitter (CT), таких как Plasma, MegaETH, Monad и другие, применили проактивный подход, создав основной набор протоколов, встроенных в их экосистему, поверх существующих протоколов.
Я ожидаю, что это станет доминирующей стратегией (и увеличит сложность выделиться на фоне действительно выдающихся технических работ).
В некоторых случаях я надеюсь, что мы сможем полностью построить множество прототипов Ritual Shrine внутри компании и управлять ими самостоятельно. Но я также понимаю, что для успешного выполнения этих проектов необходимы специализированные команды в области продукта и GTM (эти команды могут быть более подходящими для рынка, даже если у нас есть одна из самых сильных кросс-функциональных команд в этой области).
Если мы сможем строить вместе с этими командами и при этом предоставить внешним разработчикам хорошие экономические вознаграждения, это все равно будет победой. Это позволяет нам в метафорическом смысле "владеть" этим, одновременно привнося новые перспективы и новые таланты.
В общем, кратко говоря: да, было бы здорово, если бы у вас были первоклассные приложения от первого лица на вашей новой инфраструктуре. Но если ресурсы ограничены, то необходимо активно направлять развитие вашей экосистемы в виде прототипа, строя их вместе, а не бездействуя в этом процессе.