10 Minutės
Kodėl antraštiniai TPS dažnai klaidina dėl realaus mastelio
Sandorių blokų grandinėje per sekundę (TPS) rodiklis plačiai naudojamas kaip našumo santrauka, tačiau antraštiniai TPS skaičiai retai atspindi tai, ką gyva, decentralizuota tinklo aplinka gali išlaikyti realybėje. Dideli TPS skaičiai yra patrauklūs baltuosiuose dokumentuose ir rinkodaros pristatymuose, tačiau kiekvienas papildomas sandoris padidina skaičiavimo ir tinklo apkrovą mazgams, kurie palaiko knygą decentralizuotą. Ši įtampa — tarp gryno vykdymo greičio ir decentralizacijos kainos — paaiškina, kodėl teorinis TPS dažnai subliūkšta, kai grandinė pradeda veikti gamybinėje aplinkoje. Papildomai reikia įvertinti operacijų tipų įvairovę, mempool elgseną ir konsensuso srautą, nes tai daro tiesioginį poveikį praktiškai pasiekiamam našumui.
Benchmarks prieš gamybinius tinklus
Daugelis ankstyvųjų etalonų arba pre-mainnet testų matuoja TPS idealizuotomis sąlygomis: vienas mazgas arba griežtai kontroliuojamas testnet tinklas. Tokios sąlygos fiksuoja virtualios mašinos greitį arba izoliuotą vykdymo pralaidumą, o ne pilną tinklo mastelį. Carter Feldman, Psy Protocol įkūrėjas ir buvęs programišius bei blokų gamintojas, atkreipia dėmesį, kad vieno mazgo matavimai yra klaidinantys, nes jie nepaiso perdavimo ir sandorių patvirtinimo tarp paskirstytos topologijos kaštų.
„Daugelis pre-mainnet, testnet ar izoliuotų etalonų testų matuoja TPS tik su vienu veikiančiu mazgu. Tokiu atveju galite taip pat vadinti Instagram blokų grandine, galinčia pasiekti 1 milijardą TPS, nes ji turi vieną centrinę instituciją, patvirtinančią kiekvieną API užklausą,“ – sakė Feldman.
Vykdymas yra tik viena iš dalelių
Blokų grandinės našumo profilis apima kelis sluoksnius: kaip greitai virtualioji mašina vykdo sandorius, kaip mazgai komunikuoja (pralaidumas ir vėlinimas), ir kaip lyderiai bei validatoriai perduoda ir patvirtina duomenis. Etalonai, atskiriantys vykdymą nuo perdavimo ir patikrinimo, matuoja tai, kas yra arčiau VM pralaidumo nei tinklo mastelio. Praktikoje tinklas turi užtikrinti, kad kiekvienas pilnas mazgas galėtų patikrinti sandorius ir kad neteisingi duomenys būtų atmesti — tai yra pati savybė, garantuojanti decentralizaciją. Be to, reikia vertinti duomenų prieinamumą (data availability) ir saugojimo I/O reikalavimus kaip integralius našumo komponentus.
Nauji projektai reklamuoja didelį TPS, nors gyvo tinklo naudojimas retai priartėja prie tų ribų.
Istoriniai pavyzdžiai: EOS ir Solana
EOS paskelbė teorinę TPS ribą milijonuose, tačiau ji niekada nepasiekė tokio lygio mainnet tinkle. Baltasis dokumentas su teiginiais apie ~1 milijono TPS maksimumą buvo dėmesį patraukiantis, tačiau realistinės bandymų sąlygos ir nepriklausomi tyrimai nupiešė kitokį vaizdą. Whiteblock testai ir kiti realaus pasaulio analizės rezultatai parodė, kad pralaidumas realiomis tinklo sąlygomis kristi iki maždaug 50 TPS, ypač kai įtraukta relė ir patikrinimo kaštai bei geografinis mazgų išsidėstymas.
Pastaruoju metu Jump Crypto projektas su Firedancer validatoriaus klientu demonstravo 1 milijono TPS rodiklius kontroliuotuose testuose. Šis pasiekimas patvirtina, kiek toli inžinerija gali stumti vykdymo greitį. Tačiau Solana tinkle gyvose sąlygose paprastai apdorojama maždaug 3 000–4 000 TPS: reikšmingą dalį šių skaičių „suvalgo“ balsavimo ar konsensuso srautas, o ne vien tik vartotojų sandoriai. Apie 40 % Solana grandinėje esančios veiklos gali būti nevartotojiška arba ne balsavimo tipo srautas, todėl vartotojams prieinamas pralaidumas iš esmės mažesnis. Tai akivaizdžiai parodo skirtumą tarp teorinio vykdymo ir tinklo lygio naudojimo.
Solana užfiksavo 1 361 TPS be balsavimo sandorių vasario 10 d.
Šie pavyzdžiai iliustruoja nuoseklią tendenciją: izoliuoti našumo rekordai nėra tas pats kaip tvarus mainnet pralaidumas, kai kartu veikia decentralizacija, tinklo propagacija ir patikrinimo sąnaudos. Realiame tinkle taip pat turi būti sprendžiamos operacijų kainodaros sistemos, mempool politikos ir validatorių paskirstymo poveikis, nes visi šie veiksniai riboja praktiškai pasiekiamą TPS.
Linearinio mastelio problema ir decentralizacijos kaštai
Pralaidumas paprastai auga lineariai su darbo krūviu: dvigubai daugiau sandorių reiškia maždaug dvigubai daugiau darbo. Šis linijinis ryšys tampa problema, nes kiekvienas mazgas turi gauti ir patikrinti augantį duomenų kiekį. Pralaidumo ribos, CPU apribojimai, saugojimo I/O ir sinchronizacijos vėlavimai galiausiai sudaro kietus kamščius. Kai didinate TPS be patikrinimo modelio pakeitimo, mažėja įrenginių, galinčių paleisti pilną mazgą, skaičius — tai sutelkia validavimo galią ir menkina decentralizaciją. Kartu auga tinklo priklausomybė nuo galingesnių mazgų ir profesionalių operatorių.
Toks kompromisas yra fundamentali problema daugelyje esamų blokų grandinių architektūrų: gryni TPS pelnai pasiekiami aukojant validatorių įvairovę ir geografinius paskirstymus. Projektų komandos dažnai stengiasi sumažinti spaudimą didindamos aparatinės įrangos reikalavimus, bet toks sprendimas tinklą stumia link mažesnio, labiau profesionalizuoto validatorių rinkinio, kas gali turėti nepageidaujamų politinių ir saugumo pasekmių. Be to, didesnės aparatinės sąnaudos mažina galimų decentralizacijos naujų dalyvių įėjimo prieinamumą.
Vykdymo ir patikrinimo atskyrimas
Vienas iš būdų sumažinti vieno mazgo apkrovą yra atskirti vykdymą nuo patikrinimo. Vietoje to, kad kiekvienas mazgas vykdytų kiekvieną sandorį, mazgai gali patikrinti kompaktinį įrodymą, kad sandoriai buvo apdoroti teisingai. Toks požiūris sumažina patikrinimo sąnaudas įprastiems mazgams, tuo pačiu intensyvų darbą perkelia į specializuotus įrodymų kūrėjus (provers). Tai leidžia palaikyti žemesnius aparatūros reikalavimus pilnam mazgui ir išlaikyti platesnį validatorių skaičių.
Feldman išskiria nulinės žinios (ZK) įrodymus kaip pagrindinį įrankį šiam dizainui. Nulinės žinios kriptografija leidžia įrodymo pateikėjui įtikinti tikrinančiuosius, kad sandorių partija buvo vykdyta teisingai, neatskleidžiant visų tarpinės būsenos duomenų ir nereikalaujant, kad kiekvienas mazgas perspėtų ar peržaidinėtų visus sandorius. Tai sumažina kiekvienam pilnam mazgui tenkantį patikrinimo krūvį ir atveria galimybes mastelio didinimui be proporcingo mažėjančio decentralizacijos lygio.
Rekursyvūs ZK-įrodymai ir įrodymų agregacija
Rekursyvūs ZK-įrodymai leidžia sudėti kelis atskirus įrodymus į vieną bendrą įrodymą, kuris patikrina daug ankstesnių įrodymų teisingumą. Feldman iliustravo tai įrodymų medžio pavyzdžiu: 16 vartotojų sandorių gali tapti aštuoniais įrodymais, kurie savo ruožtu suspaudžiami iki keturių, tada iki dviejų ir galiausiai vieno kompaktiško įrodymo. Galutinis rezultatas — vienas mažas artefaktas, patvirtinantis didelės sandorių partijos teisingumą. Toks algorithminis suspaudimas padeda palaikyti tinklo pralaidumą ir sumažina patikrinimo kaštus daugeliui mazgų vienu metu.
Kaip keli įrodymai tampa vienu.
Naudojant rekursyvinius įrodymus, pralaidumas gali didėti be proporcingo vieno mazgo patikrinimo kaštų augimo. Tai reiškia didesnį efektyvų TPS tinklo lygiu, tuo pačiu išlaikant žemas validacijos sąnaudas įprastiems mazgams. Tačiau kaštai neišnyksta — jie tiesiog pasislenka. ZK įrodymų generavimas gali būti kompiuteriškai intensyvus ir dažniausiai reikalauja specializuotos aparatinės įrangos arba infrastruktūros. Sunkus darbas perkeliamas į prover'us, kurie, jei nėra kruopščiai suprojektuoti ir paskirstyti, gali tapti centralizuotais mazgais ir vėl sukelti kompromisus su decentralizacija. Todėl svarbu kurti decentralizuotus prover tinklus ir paskatinimo mechanizmus, kurie paskirstytų įrodymų generavimo naštą plačiai.
Kodėl dauguma grandinių vis dar naudoja tradicinius modelius
Įrodymų pagrindu grindžiamas patikrinimo diegimas dažnai reiškia esminių blokų grandinės komponentų pertvarkymą: būsenos atvaizdavimo, vykdymo modelių ir duomenų prieinamumo (data availability) valdymo. Bandymas įdiegti ZK pagrindu veikiančią validaciją į tradicinį EVM arba sekvencinį vykdymo modelį yra sudėtingas. Tai paaiškina, kodėl daug brandžių tinklų toliau pasikliauja įprastais vykdymo ir patikrinimo modeliais, nepaisant teorinių ZK privalumų. Reikalinga daug darbo perėjimui prie ZK-native architektūrų, įskaitant kompatibilumo sluoksnius, smart contract pritaikymą ir programinės įrangos ekosistemos atnaujinimą.
Feldman taip pat pažymėjo istorinius finansavimo dinamikos aspektus: ankstyvieji investuotojai ir komandos dažnai rėmė projektus, atitinkančius pažįstamus vykdymo modelius (pvz., EVM suderinamas grandines). ZK-natyvios vykdymo sluoksnio kūrimas reikalavo daugiau laiko ir naujų inžinerinių sprendimų, kas pradžioje apsunkino lėšų pritraukimą kai kuriems komandoms. Dėl to tradiciniai modeliai išliko dominuojantys, nors ZK technologijos ir toliau vystosi ir pamažu integruojamos į įvairius sprendimus.
Našumo metrika, viršijančia gryną TPS
TPS yra naudingas rodiklis, kai jis matuojamas teisingai — gamyboje ir įtraukiant perdavimo bei patikrinimo kaštus — bet tai nėra vienintelis tinklo sveikatos indikatorius. Ekonominiai rodikliai, tokie kaip sandorių mokesčiai, kainų rinkos elgsena ir vidutinė sandorių finalizacija, suteikia aiškesnius signalus apie paklausą ir tinklo talpą. Blokų grandinė su žemais mokesčiais, nepaisant didelio popierinio TPS, gali rodyti nepakankamai išnaudotą pajėgumą, tuo tarpu kybančios mokesčių kainos prie vidutinio TPS gali reikšti realų užsikimšimą ir infrastruktūros ribotumą.
„Teigčiau, kad TPS yra antras pagal svarbą blokų grandinės našumo etalonas, bet tik jei jis matuojamas gamybinėje aplinkoje arba tokioje aplinkoje, kur sandoriai ne tik apdorojami, bet ir perduodami bei patikrinami kitų mazgų,“ — pabrėžė Feldman. Kitaip tariant, tinklo sveikatą geriau vertinti kombinacija: realus pralaidumas, ekonominiai rodikliai ir validatorių paskirstymas.
LayerZero Labs ir kiti teigė apie dramatiškas TPS ribas, derindami vykdymo inovacijas su ZK primityvais. Pavyzdžiui, LayerZero reklamuoja Zero grandinę, teigiančią, kad ji gali išsidėstyti iki milijonų TPS pasitelkdama ZK technologijas. Tokie požiūriai yra perspektyvūs, tačiau jų ilgalaikė decentralizuota gyvybingumas priklauso nuo to, kaip įrodymų generavimas ir validacija bus paskirstyti tinkle, taip pat nuo paskatinimų ir operacinės architektūros. Sėkmingai paskirstyta prover architektūra ir duomenų prieinamumo sprendimai yra būtini, kad ZK sprendimai realiai pagerintų tinklo mastelį be decentralizacijos nuostolių.
Praktiniai patarimai kūrėjams ir vartotojams
- Skaitykite TPS teiginius kritiškai: klauskite, kaip buvo vykdomi testai ir ar įtraukta perdavimas, pralaidumas ir patikrinimo kaštai.
- Rinkitės gamybinius etalonus: mainnet matavimai įprasto vartotojų krūvio metu yra informatyvesni nei pre-mainnet demonstracijos.
- Sekite ekonominius signalus: sandorių mokesčiai, mempool elgsena ir finalizacijos laikas suteikia praktinius įrodymus apie tinklo ribas.
- Įvertinkite decentralizacijos poveikį: didesnis TPS yra vertingas, bet ne jei jis sutelkia validaciją arba reikalauja neperžengiamos aparatinės įrangos.
- Sekite ZK įrankių pažangą: rekursyvūs įrodymai ir įrodymų agregacija gali sulaužyti linijinį kompromisą, tačiau jie įneša savo architektūrinių ir ekonominių kompromisų.
Išvados
Antraštiniai TPS skaičiai yra patrauklūs, bet neišsamūs. Realaus pasaulio mastelis turi atsižvelgti į tai, kaip sandoriai yra transliuojami, patikrinami ir ekonominiu požiūriu incentivizuojami decentralizuotame tinkle. Tokios technikos kaip vykdymo ir patikrinimo atskyrimas bei nulinės žinios įrodymai — ypač rekursyvus ZK — siūlo perspektyvius kelius į didesnį naudojamą pralaidumą. Vis dėlto šie sprendimai perkėlė naštas, o ne visiškai ją panaikina, ir reikalauja kruopštaus inžinerinio sprendimo decentralizacijos išsaugojimui. Dabar geriausias rodiklis grandinės mastelėjimo gebėjimui vertinti išlieka gamyboje išbandytas pralaidumas kartu su ekonominiais indikatoriais, tokiais kaip mokesčiai ir validatorių paskirstymas. Be to, svarbu stebėti duomenų prieinamumo modelius, prover paskirstymą ir aparatūros reikalavimų dinamiką, nes šie komponentai bus esminiai tolimesniam tinklo augimui ir saugumui.
Šaltinis: cointelegraph
Palikite komentarą