Proč titulní TPS často zkresluje reálnou škálovatelnost

Proč titulní TPS často zkresluje reálnou škálovatelnost

Komentáře

8 Minuty

Proč titulní TPS často zkresluje reálnou škálovatelnost

Transakce za sekundu (TPS) se v oblasti blockchainu často používají jako zkratka pro výkonnost. Nicméně uváděné titulní hodnoty TPS zřídka odrážejí to, co dokáže udržet živá, decentralizovaná síť. Vysoká čísla TPS znějí dobře v bílých knihách a marketingových prezentacích, ale každá další transakce zvyšuje výpočetní a síťovou zátěž uzlů, které zajišťují decentralizované vedení účetní knihy. Toto napětí — mezi surovou rychlostí zpracování a náklady na udržení decentralizace — vysvětluje, proč se teoretické TPS často zhroutí, jakmile je řetězec v provozu.

Benchmarky vs. produkční sítě

Mnoho raných benchmarků a testů před spuštěním mainnetu měří TPS v idealizovaných podmínkách: jeden uzel nebo přísně řízený testnet. Tyto podmínky měří rychlost virtuálního stroje nebo samotný výkon izolovaného zpracování místo skutečné škálovatelnosti celé sítě. Carter Feldman, zakladatel Psy Protocol a bývalý hacker a „block producer“, upozorňuje, že jednou uzlová měření jsou zavádějící, protože opomíjejí náklady na přeposílání a ověřování transakcí v distribuované topologii.

„Mnoho pre-mainnet, testnet nebo izolovaných benchmarků měří TPS při spuštěném pouze jednom uzlu. V tom okamžiku můžete stejně nazvat Instagram blockchainem, který dosáhne miliardy TPS, protože má jednu centrální autoritu, která ověřuje každé API volání,“ řekl Feldman.

Provedení je jen jedna část skládanky

Výkonový profil blockchainu zahrnuje více vrstev: jak rychle virtuální stroj vykonává transakce, jak spolu uzly komunikují (šířka pásma a latence) a jak lídři a validátoři přeposílají a potvrzují data. Benchmarky, které oddělují vykonávání od přeposílání a ověřování, měří spíše propustnost VM než škálovatelnost sítě. V reálu musí síť zajistit, že každý full node může transakce ověřit, a že neplatná data jsou odmítnuta — právě ta vlastnost zaručuje decentralizaci.

Nové projekty často inzerují vysoké TPS, ale provoz v reálné síti těmto limitům málokdy odpovídá.

Historické příklady: EOS a Solana

EOS zveřejnilo teoretický strop TPS v řádu milionů, přesto na mainnetu tohoto čísla nikdy nedosáhlo. Nároky ve whitepaperu až cca 1 milion TPS působily impozantně, ale realistické testy a výzkumy vykreslily odlišnou realitu. Testování Whiteblock a další analýzy z reálného provozu ukázaly, že propustnost klesá na přibližně 50 TPS při praktických síťových podmínkách.

Nověji klient validátora Jump Crypto s názvem Firedancer prokázal 1 milion TPS v řízených testech. Tento úspěch potvrzuje, jak daleko lze inženýrstvím posunout rychlost vykonávání. Přesto Solana v reálném provozu obvykle zpracovává spíše řád 3 000–4 000 TPS; podstatná část tohoto čísla je navíc spotřebována hlasovací nebo konsenzuální komunikací místo čistých uživatelských transakcí. Přibližně 40 % on-chain aktivity v Solaně může tvořit ne-uživatelský nebo ne-vote provoz, takže skutečná uživatelsky dostupná propustnost je nižší.

Solana zaznamenala 1 361 TPS bez hlasovacích transakcí dne 10. února.

Tyto příklady ilustrují konzistentní vzorec: izolovaná výkonová maxima nejsou totéž co udržitelná propustnost mainnetu, kde se projeví náklady decentralizace, propagace sítě a ověřování.

Lineární problém škálování a náklady decentralizace

Propustnost typicky škáluje lineárně s pracovní zátěží: dvojnásobek transakcí znamená přibližně dvojnásobek práce. Tento lineární vztah se stává problémem, protože každý uzel musí přijímat a ověřovat rostoucí objem dat. Omezení šířky pásma, limity CPU, I/O úložiště a zpoždění při synchronizaci nakonec vytvoří tvrdé úzká hrdla. Pokud zvyšujete TPS bez změny modelu ověřování, soubor strojů schopných provozovat full node se zúží, což soustřeďuje validační moc a eroduje decentralizaci.

Tento kompromis je fundamentální v mnoha existujících architekturách blockchainu: surové zvýšení TPS přichází na úkor rozmanitosti a geografického rozložení validátorů. Týmy projektů často tlaky mírní zvýšením požadavků na hardware, což však posouvá síť směrem k menšímu, profesionalizovanému okruhu validátorů.

Oddělení vykonávání a ověřování

Jedním ze způsobů, jak snížit zátěž na jednotlivý uzel, je oddělit vykonávání od ověřování. Místo toho, aby každý uzel vykonával každou transakci, ověřují uzly kompaktní důkaz, že transakce byly zpracovány správně. Tento přístup snižuje náklady ověřování pro běžné uzly a soustřeďuje intenzivní práci na specializované „provery“ (provers).

Feldman upozorňuje na zero-knowledge (ZK) důkazy jako klíčový nástroj pro tento design. Kryptografie s nulovým vyzrazením umožňuje proverovi přesvědčit ověřovatele, že dávka transakcí byla vykonána správně, aniž by bylo potřeba odhalit všechna mezilehlá data nebo aby každý uzel přehrával každou transakci. To snižuje ověřovací zátěž, kterou musí nést každý full node, a zároveň zachovává bezpečnostní vlastnosti systému.

Rekursive ZK-důkazy a agregace důkazů

Rekurzivní ZK-důkazy umožňují kombinovat více důkazů do jednoho výsledného důkazu, který potvrzuje správnost mnoha předchozích důkazů. Feldman to ilustroval pomocí stromu důkazů: 16 uživatelských transakcí může vzniknout osm důkazů, které se následně zkomprimují do čtyř, pak do dvou a nakonec do jednoho kompaktního důkazu. Konečný výstup je jedno malé artefaktum dokazující správnost velkého balíku transakcí.

Jak se několik důkazů srovná do jednoho.

Použitím rekurzivních důkazů může propustnost vzrůst bez proporcionálního nárůstu ověřovací zátěže na uzel. To znamená vyšší efektivní TPS na úrovni sítě při zachování levného ověřování pro běžné uzly. Náklady však nezmizí — pouze se přesunou. Generování ZK-důkazů může být výpočetně náročné a typicky vyžaduje specializovaný hardware nebo robustní infrastrukturu. Těžká práce se přesouvá na provery (provers), které se mohou stát centralizovanými, pokud není návrh pečlivě promyšlen, čímž opět vznikají kompromisy vůči decentralizaci.

Proč většina řetězců stále používá tradiční modely

Přijetí verifikace založené na důkazech často znamená přepracování základních komponent blockchainu: reprezentace stavu, modely vykonávání a způsob, jak je řešena dostupnost dat (data availability). Retrofitování ZK-nativního ověřování do konvenčního EVM nebo sekvenčního modelu vykonávání je technicky komplexní. To vysvětluje, proč mnohé etablované sítě i nadále spoléhají na tradiční vykonávání a ověřování navzdory teoretickým výhodám ZK přístupů.

Feldman také poznamenal historickou dynamiku financování: raní investoři a týmy upřednostňovali projekty odpovídající známým modelům vykonávání (např. kompatibilní s EVM). Vybudování ZK-native stacku vyžadovalo více času a novátorského inženýrství, což některým týmům zpočátku ztěžovalo získávání prostředků.

Metriky výkonu nad rámec surového TPS

TPS je užitečná metrika, pokud je používána správně — tj. měřená v produkci a zahrnující náklady na přeposílání (relay) a ověřování — ale není jediným ukazatelem zdraví sítě. Ekonomické metriky, jako jsou poplatky za transakce, chování tržního mechanismu poplatků (fee market) a průměrná finalita transakcí, poskytují jasnější signály o poptávce a kapacitě. Blockchain s nízkými poplatky přestože má vysoké „on-paper“ TPS může naznačovat nevyužitou kapacitu, zatímco rostoucí poplatky při mírném TPS mohou signalizovat zácpu a reálná omezení.

„Domnívám se, že TPS je druhý ukazatel výkonu blockchainu, ale pouze pokud je měřen v produkčním prostředí nebo v prostředí, kde transakce nejsou jen zpracovávány, ale také přeposílány a ověřovány ostatními uzly,“ zdůraznil Feldman.

Firmy jako LayerZero Labs a další uváděly dramatické TPS stropy kombinací inovací ve vykonávání s ZK primitivy. Například LayerZero propagoval Zero chain, který má škálovat do milionů TPS využitím ZK technologií. Tyto přístupy jsou slibné, ale jejich dlouhodobá decentralizovaná životaschopnost závisí na tom, jak je generování důkazů a jejich validace distribuováno napříč sítí.

Praktická doporučení pro vývojáře a uživatele

  • Přečtěte si tvrzení o TPS kriticky: zeptejte se, jak byly testy prováděny a zda zahrnovaly náklady na přeposílání, šířku pásma a ověřování.
  • Dávejte přednost produkčním benchmarkům: měření na mainnetu při běžné uživatelské zátěži mají větší vypovídací hodnotu než pre-mainnet demo testy nebo laboratorní běhy.
  • Sledujte ekonomické signály: poplatky za transakce, chování mempoolu a délka finality poskytují praktické důkazy o limitech sítě.
  • Posuzujte dopad na decentralizaci: vyšší TPS je hodnotný, ale ne za cenu koncentrace validace nebo požadavků na přehnaný hardware.
  • Monitorujte pokrok v ZK nástrojích: rekurzivní důkazy a agregace důkazů mohou narušit lineární kompromis, avšak zavádějí vlastní architektonické a ekonomické kompromisy.

Závěr

Titulní čísla TPS jsou atraktivní, ale neúplná. Škálovatelnost v reálném světě musí zohlednit, jak jsou transakce vysílány, ověřovány a ekonomicky incentivizovány v decentralizované síti. Techniky jako oddělení vykonávání od ověřování a využití důkazů s nulovým vyzrazením — zejména rekurzivních ZK — nabízejí slibné cesty k vyšší použitelné propustnosti. Přesto tyto řešení nároky neodstraní, pouze je přesunou, a vyžadují pečlivé inženýrství, aby byla zachována decentralizace. Prozatím zůstává nejlepším ukazatelem schopnosti řetězce škálovat produkčně testovaná propustnost doplněná o ekonomické indikátory, jako jsou poplatky a rozložení validátorů.

Zdroj: cointelegraph

Zanechte komentář

Komentáře