Mýty o krypto infrastruktuře: Proč nefunguje "stavět a oni přijdou"?

Původní autor: Saneel Sreeni

Původní kompilace: Deep Tide TechFlow

Následuje tweet od Jasona Yanowitze:

může být částečně inspirován dvěma věcmi

: (1) mnoho nedávno spuštěných blockchainů vrstvy 1 má nedostatečný výkon a

(2) Vynikající úspěch čtenářů Hyperliquid a HyperEVMPro

čtenáře, kteří nejsou obeznámeni s kryptoprostorem, je Hyperliquid decentralizovaná platforma pro trvalé kontrakty a spotové obchodování, která rychle ovládla trh a dokonce překonala některé centralizované burzy. Spustili svůj vlastní vysokorychlostní EVM blockchain založený na úspěchu obchodní platformy. V době psaní tohoto článku má společnost Hyperliquid tržní kapitalizaci přibližně 11 miliard dolarů a plně zředěné ocenění (FDV) 33 miliard dolarů.

Hyperliquid je jedním z prvních případů, které úspěšně vedly vývoj nového blockchainu vrstvy 1 prostřednictvím své primární aplikace pro tok příjmů. Obecně souhlasím s Jasonem. Většina nových blockchainů vrstvy 1 však nezačíná se stejnými výhodami jako Hyperliquid; Její zakladatel Jeff dříve provozoval jednu z nejlepších firem pro vysokofrekvenční obchodování v kryptoprostoru a má dostatečné rezervy finančních prostředků, aby se vyhnul nutnosti spoléhat se na externí financování.

V důsledku toho jsem přišel s několika nápady ohledně strategie a go-to-market (GTM) pro nové blockchainy vrstvy 1 a alternativní nápady, jak na nich stavět aplikace, zejména pokud se vydáte tradičnějšími cestami, jako je financování rizikovým kapitálem a budování zcela nové infrastruktury (pokud váš blockchain vrstvy 1 nemá výraznou funkční diferenciaci a jednoduše napodobuje jiné projekty, tyto návrhy pro vás nemusí fungovat).

Moje názory jsou z velké části založeny na mých zkušenostech z terénu ve společnosti Ritual a také na pečlivém sledování strategie a provádění dalších blockchainů vrstvy 1 se silnými ekosystémy. Stále se učím, takže možná v budoucnu své názory zreviduji.

Stručně řečeno, zde jsou některé z mých názorů:

Proaktivní bootstrapping vs. "

Build and they'll come" byl strategický způsob myšlení, který převládal v krypto prostoru před rokem 2021, kdy infrastruktura zdaleka nebyla dostatečná. Jádrem této filozofie je, že pokud vytvoříte nový řetězec nebo vrstvu 2 (L2), vývojáři přijdou spontánně a pokusí se přilákat nové uživatele a získat hodnotu prostřednictvím tokenů vašeho řetězce. Tato strategie nějakou dobu fungovala, protože technologicky zdravých řetězců s investiční hodnotou bylo v té době málo a infrastrukturní sektor se těšil dlouhodobé prémii. Postupem času se však tato prémie vytrácí, zejména proto, že velké množství nových řetězců postrádá praktické využití a přitažlivost pro aplikace (z nichž většina jsou jen napodobeniny nebo vidlice).

Je zřejmé, že tato strategie již nefunguje, alespoň u nových blockchainových projektů. Jedním z mála ekosystémů, který tuto strategii v poslední době úspěšně realizoval, je HyperEVM, ale ani tak není jeho úspěch zcela způsoben touto strategií. Úspěch HyperEVM do značné míry závisí na Hyperliquid Core (burze) jako základní aplikaci, která vytváří skutečnou hodnotu pro držitele $HYPE a ekosystém Hype (a obohacuje mnoho aktivních uživatelů před událostí generování tokenů (TGE)).

Naproti tomu nyní vidíme, že velký počet projektů vrstvy 1 (L1) a vrstvy 2 (L2) přijímá tento směr uvažování od samého začátku a věří, že mohou nedostatky napravit rozdáváním grantů a čistým brandingem, ale nakonec selžou.

Jak již bylo řečeno, je těžké vytvořit "něco". Je těžké vybudovat infrastrukturu a je těžké vyvíjet aplikace. Zejména v oblasti kryptoměn není stavění jen o nasazení kódu – je třeba udělat spoustu práce, včetně go-to-market (GTM), provozu, dodržování právních předpisů a dalších, které jsou často podceňovány.

Když vytváříte blockchain vrstvy 1 (za předpokladu, že vytváříte zcela novou architekturu, nikoli jednoduchý forkový projekt), je to obrovská technická výzva i obrovský úkol pro uvedení na trh (GTM). Nikdo si nemůže být zcela jistý, co bude "zabijácká aplikace", takže je vaším úkolem vytvořit produkt a spolupracovat s vývojáři, abyste co nejvíce podpořili zrod vysoce kvalitních aplikací, abyste maximalizovali pravděpodobnost úspěchu vaší vrstvy 1 a vývojářů, kteří vám důvěřují.

To znamená několik možností pro infrastrukturní týmy:

• Sestavit silnější tým a dělat vše interně, včetně vývoje aplikací na nejvyšší úrovni:

  Tento přístup může fungovat, ale má následující problémy:

• (a) Dobré talenty se hledají těžko.

• (b) Interní nábor nejlepších talentů znamená, že je třeba získat více peněz od investorů, které dnes investoři nekupují. (Vím, že Hyperliquid to všechno dělal s 10 lidmi, ale většina zakladatelů nemá silné stránky a zdroje, aby začali jako Jeff.) I tak byl jejich výkon šílený.

• Nejen, že musíte najmout inženýry, ale musíte také najmout lidi, kteří se specializují na GTM, provoz, marketing a právo. I když mohou existovat příležitosti pro spolupráci napříč platformami ve velkém měřítku, bude trvat dlouho, než se to projeví, zejména proto, že každá aplikace se může dramaticky lišit.

• Postupujte starou cestou "postavte to a někdo přijde" + rozdejte spoustu rozvojových grantů:

Tuto strategii obvykle používají někteří "lovci grantů" s průměrnými týmy a nedostatečnou diferenciací aplikací a z dlouhodobého hlediska nefunguje dobře.

• Aktivní vedení ekosystému:

Mám na mysli proaktivnější přístup vytvářením prototypů nebo některých odlehčených aplikací na vrcholu vaší infrastruktury a spoluprací s ostatními vývojáři/partnery na tom, aby se tyto aplikace plně využily.

Vývojáři chtějí vidět, že o tom jen mluvíte, ale skutečně do toho vkládáte svůj čas a úsilí. Konec konců, nikdo nerozumí potenciálu této infrastruktury lépe než lidé, kteří ji vyvinuli. Tímto způsobem můžete:

(a) předvést nové a poutavé aplikace;

(b) prokazují pravděpodobnost, že je to dosažitelné na vaší infrastruktuře;

(c) mít určitý vliv ve směru ekologického rozvoje, a to nejen prostřednictvím rozdělování finančních prostředků.

Přístup (3) stále vyžaduje velké talenty pro vytváření interních aplikací, ale jedná se spíše o proaktivní postup navržený tak, aby pomohl vybudovat protokol v reálném světě od základů, aniž by vyžadoval významné investice do zdrojů nebo ovlivňoval vylepšení základní infrastruktury. Funkčně je to skoro jako poskytování platformové podpory nebo inkubace pro tyto společnosti.

Mohl by být tento přístup obtížnější a pomalejší cestou? Ano. Ale myslím si, že je to dlouhodobější přístup pro projekty, které stále zdokonalují svou základní infrastrukturu / jsou v raných fázích. Právě tento přístup jsme zvolili v Ritualu, když jsme vytvářeli aplikace, které chceme vidět na Ritualu, s projekty jako Ritual Shrine, o kterých si myslíme, že mohou být zabijáckými aplikacemi v kryptoměnách a umělé inteligenci.

Ale nejsme to jen my – Solana měla v počátcích hodně aktivní stavební aktivity, když pracovala s FTX, Jumpem a několika dalšími týmy. Několik nových projektů, které jsou populární na krypto Twitteru (CT), jako je Plasma, MegaETH, Monad a další, zaujalo proaktivní přístup k vytvoření základní sady protokolů nativních pro jejich ekosystém nad rámec stávajících protokolů.

Očekávám, že se to stane dominantní strategií (a zvýší se obtížnost skutečného vyniknutí na vrcholu technické práce).

V některých případech bych si přál, abychom mohli plně prototypovat mnoho rituálních svatyní interně a provozovat je sami. Ale také si uvědomuji, že tyto projekty vyžadují specializované týmy, aby uspěly v realizaci produktů a GTM (což může být pro trh vhodnější než my, i když máme to, co považuji za jeden z nejsilnějších multifunkčních týmů v oboru).

Pokud dokážeme stavět bok po boku s těmito týmy a zároveň poskytovat silné finanční odměny externím vývojářům, je to stále výhra. To nám umožňuje "vlastnit" ji v přeneseném slova smyslu, zároveň přinášet nové perspektivy a nové talenty.

Stručně řečeno: ano, je skvělé, když můžete mít na své nové infrastruktuře špičkové aplikace první strany. Pokud jsou však zdroje omezené, snažte se aktivně vést svůj ekosystém ve formě prototypů, stavět s nimi, spíše než líně přistupovat k procesu.