11 Minute
De ce TPS-ul afișat în titlu adesea denaturează scalabilitatea reală
Tranzacțiile pe secundă (TPS) sunt folosite pe scară largă ca o prescurtare pentru performanță, dar cifrele afișate în titlu rareori reflectă ceea ce o rețea live și descentralizată poate susține în practică. Numerele mari de TPS sunt atractive în white paper-e și materiale de marketing, însă fiecare tranzacție suplimentară crește povara computațională și de rețea asupra nodurilor care mențin un registru descentralizat. Această tensiune — între viteza brută de execuție și costul descentralizării — explică de ce TPS teoretic se prăbușește adesea odată ce un lanț rulează în producție. În plus, interpretarea eronată a unui TPS „în teorie” poate genera așteptări nerealiste pentru aplicațiile descentralizate, pentru dezvoltatori și pentru operatorii de noduri.
Benchmarks vs. rețele de producție
Multe benchmark-uri timpurii sau teste pre-mainnet măsoară TPS în condiții idealizate: un singur nod sau un testnet controlat strict. Aceste condiții evaluează viteza mașinii virtuale sau debitul execuției izolate, mai degrabă decât scalabilitatea întregii rețele. Carter Feldman, fondatorul Psy Protocol și fost hacker și producător de blocuri, menționează că măsurătorile efectuate pe un singur nod induc în eroare pentru că omit costurile de retransmisie și verificare a tranzacțiilor printr-o topologie distribuită.
„Multe teste pre-mainnet, testnet sau de benchmark izolat măsoară TPS cu un singur nod activ. În acel moment, la fel de bine ai putea numi Instagram un blockchain care poate atinge 1 miliard TPS, pentru că are o autoritate centrală ce validează fiecare apel API,” a spus Feldman. Afirmația subliniază pericolul de a confunda performanța izolată a unei mașini sau a unui client cu capacitatea unei rețele reale în care nodurile se află în locații geografice diferite și comunică prin canale publice cu latențe și pierderi ocazionale.
Execuția este doar o piesă din puzzle
Profilul de performanță al unui blockchain include mai multe straturi: cât de rapid execută mașina virtuală tranzacțiile, cum comunică nodurile (lățime de bandă și latență), și cum liderii și validatorii retransmit și confirmă datele. Benchmark-urile care sepără execuția de retransmisie și verificare măsoară ceva mai apropiat de debitul VM-ului decât de scalabilitatea rețelei. În practică, rețeaua trebuie să garanteze că fiecare nod complet poate verifica tranzacțiile și că datele invalide sunt respinse — tocmai acea caracteristică care asigură descentralizarea.
Proiecte noi promovează TPS mari, deși utilizarea reală pe rețelele live rareori se apropie de acele limite.
Exemple istorice: EOS și Solana
EOS a publicat un plafon teoretic de TPS în milioane, dar nu a atins niciodată acel nivel pe mainnet. Afirmațiile din whitepaper de până la ~1 milion TPS erau spectaculoase, însă teste realiste și analize independente au oferit o imagine diferită. Testările Whiteblock și alte analize din lumea reală au arătat că debitul scade la aproximativ 50 TPS în condiții practice de rețea, unde replicarea, latența și verificarea influențează puternic performanța.
Mai recent, clientul validator Firedancer dezvoltat de Jump Crypto a demonstrat 1 milion TPS în teste controlate. Această realizare validează până unde poate fi împinsă ingineria pentru a crește viteza de execuție. Totuși, rețeaua Solana în condiții live procesează în mod tipic pe ordinea a 3.000–4.000 TPS; o parte substanțială din acel volum este consumată de trafic de vot sau consens, nu de tranzacții ale utilizatorilor. Aproximativ 40% din activitatea on-chain din totalul raportat al Solana poate fi trafic non-utilizator sau non-vot, deci debitul efectiv pentru utilizatorii finali este mai scăzut.
Solana a înregistrat 1.361 TPS fără tranzacțiile de vot pe 10 feb.
Aceste exemple ilustrează un tipar consecvent: recordurile de performanță izolate nu sunt echivalente cu debitul sustenabil pe mainnet, unde descentralizarea, propagarea în rețea și costurile de verificare sunt toate în joc. Studiile empirice și măsurătorile de producție oferă o imagine mult mai fidelă a ceea ce pot suporta efectiv nodurile distribuite.
Problema scalării liniare și costurile descentralizării
Debitul (throughput) scalează de obicei liniar cu volumul de muncă: de două ori mai multe tranzacții înseamnă aproximativ de două ori mai multă muncă. Relația aceasta liniară devine o problemă pentru că fiecare nod trebuie să primească și să verifice un volum tot mai mare de date. Limitele de lățime de bandă, capabilitățile CPU, I/O-ul de stocare și întârzierile la sincronizare formează în cele din urmă blocaje dure. Pe măsură ce crești TPS fără schimbarea modelului de verificare, setul de mașini capabile să ruleze un nod complet se micșorează, concentrând puterea de validare și erodând descentralizarea.
Această compromisare este fundamentală în multe arhitecturi blockchain existente: câștigurile brute de TPS vin în detrimentul diversității și distribuției geografice a validatorilor. Echipele de proiect adesea atenuează presiunea prin creșterea cerințelor hardware, dar aceasta mută rețeaua către un set mai mic și mai profesionalizat de validatori, reducând participanții individuali care pot rula noduri complete cu resurse modeste.
Separarea execuției de verificare
O modalitate de a reduce povara pe nod este separarea execuției de verificare. În loc ca fiecare nod să execute fiecare tranzacție, nodurile verifică o dovadă compactă că tranzacțiile au fost procesate corect. Această abordare reduce costurile de verificare pentru nodurile obișnuite, concentrând munca intensă pe «proverii» specializați. Conceptul introduce un model hibrid în care responsabilitățile sunt împărțite pentru a menține accesibilitatea rulării unui nod complet.
Feldman evidențiază dovezile cu cunoștință zero (zero-knowledge sau ZK) ca instrument cheie pentru acest design. Criptografia zero-knowledge permite unui prover să convingă verificadorii că un lot de tranzacții a fost executat corect, fără a dezvălui toate datele intermediare sau fără a necesita ca fiecare nod să reexecuție fiecare tranzacție. Aceasta reduce încărcarea de verificare pe care fiecare nod complet trebuie să o suporte, facilitând astfel menținerea descentralizării la nivele mai mari de throughput.
Proof-uri recursive ZK și agregarea de dovezi
Proof-urile recursive ZK permit combinarea mai multor dovezi într-o singură dovadă care atestă corectitudinea unor dovezi anterioare multiple. Feldman a ilustrat acest concept cu un arbore de dovezi: 16 tranzacții ale utilizatorilor pot deveni opt dovezi, care la rândul lor se comprimă în patru, apoi două și în final într-o singură dovadă compactă. Rezultatul final este un artefact mic care dovedește corectitudinea unui lot mare de tranzacții.
Cum mai multe dovezi devin una singură.
Folosind dovezi recursive, debitul poate crește fără o creștere proporțională a costurilor de verificare per nod. Asta înseamnă TPS efectiv mai ridicat la nivel de rețea, menținând în același timp validarea ieftină pentru nodurile obișnuite. Cu toate acestea, costul nu dispare — el se mută. Generarea dovezilor ZK poate fi costisitoare din punct de vedere computațional și, de regulă, necesită hardware sau infrastructură specializată. Munca grea este transferată către proveri, care se pot centraliza dacă arhitectura nu este concepută atent, creând din nou compromisuri în privința descentralizării.
De ce majoritatea lanțurilor încă folosesc modele tradiționale
Adoptarea verificării bazate pe dovezi implică adesea redesenarea componentelor centrale ale unui blockchain: reprezentarea stării, modelele de execuție și modul în care se gestionează disponibilitatea datelor. Integrarea validării ZK într-un EVM convențional sau într-un model de execuție secvențial este complexă și necesită timp. Acesta este unul dintre motivele pentru care multe rețele consacrate continuă să se bazeze pe execuție și verificare tradițională, în ciuda beneficiilor teoretice ale abordărilor ZK.
Feldman a mai observat și dinamica istorică a finanțării: investitorii timpurii și echipele preferau proiecte care se potriveau cu modele familiare de execuție (de exemplu, lanțuri compatibile EVM). Construirea unui stack nativ ZK a necesitat mai mult timp și inginerie inovatoare, ceea ce a îngreunat inițial atragerea de capital pentru unele echipe. Pe termen lung însă, proiectele ZK-native pot oferi avantaje competitive, dar trecerea este greu de realizat fără sprijin tehnic și financiar robust.
Metrice de performanță dincolo de TPS brut
TPS este o metrică utilă atunci când este folosită corect — măsurată în producție și incluzând costurile de retransmisie și verificare —, dar nu este singurul indicator al sănătății rețelei. Metodele economice, precum taxele de tranzacție, comportamentul pieței de taxe și finalitatea medie a tranzacțiilor oferă semnale mai clare despre cerere și capacitate. Un blockchain cu taxe scăzute în pofida unui TPS mare „pe hârtie” poate indica o capacitate nefolosită, în timp ce creșterea taxelor la un TPS moderat poate semnala congestie și limite reale în condițiile de utilizare.
„Aș susține că TPS este al doilea benchmark al performanței unui blockchain, dar numai dacă este măsurat într-un mediu de producție sau într-un mediu în care tranzacțiile nu sunt doar procesate, ci și retransmise și verificate de alte noduri,” a subliniat Feldman. Măsurătorile din medii reale, care includ distribuția geografică a validatorilor, costurile de infrastructură și dinamica pieței de taxe, sunt esențiale pentru o evaluare riguroasă a scalabilității.
LayerZero Labs și alții au revendicat plafonuri dramatice de TPS combinând inovații de execuție cu primitive ZK. De exemplu, LayerZero a promovat un lanț Zero care susține că poate scalare la milioane de TPS folosind tehnologie ZK. Aceste abordări sunt promițătoare, dar viabilitatea lor descentralizată pe termen lung depinde de modul în care generarea și validarea dovadelor sunt distribuite în întreaga rețea.
Concluzii practice pentru dezvoltatori și utilizatori
- Citiți critic revendicările de TPS: întrebați cum s-au rulat testele și dacă costurile de retransmisie, lățime de bandă și verificare au fost incluse.
- Preferati benchmark-urile de producție: măsurările de pe mainnet sub încărcare normală de utilizatori sunt mai relevante decât demo-urile pre-mainnet.
- Urmăriți semnalele economice: taxele de tranzacție și comportamentul mempool-ului oferă dovezi practice despre limitele rețelei.
- Evaluați impactul asupra descentralizării: TPS mai mare este valoros, dar nu dacă concentrează validarea sau impune hardware prohibitiv pentru nodurile obișnuite.
- Monitorizați progresele în tooling-ul ZK: dovezile recursive și agregarea de dovezi pot sparge compromisurile liniare, dar introduc propriile compromisuri arhitecturale și economice.
Concluzie
Cifrele impresive de TPS sunt atractive, dar incomplete. Scalabilitatea din lumea reală trebuie să țină cont de modul în care tranzacțiile sunt difuzate, verificate și incentivizate economic într-o rețea descentralizată. Tehnici precum separarea execuției de verificare și utilizarea dovadelor cu cunoștință zero — în special ZK recursive — oferă căi promițătoare către un throughput utilizabil mai mare. Totuși, aceste soluții mută sarcina în loc să o elimine și necesită o inginerie atentă pentru a păstra descentralizarea. Pentru moment, cea mai bună metrică pentru a evalua capacitatea unui lanț de a scala rămâne debitul testat în producție, asociat cu indicatori economici precum taxe, distribuția validatorilor și comportamentul pieței.
Sursa: cointelegraph
Lasă un Comentariu