De ce performanța blockchain este greu de măsurat

Performanța și scalabilitatea sunt provocări mult discutate în spațiul cripto, relevante atât pentru proiectele de nivel 1 (blockchain independente) cât și pentru soluțiile de nivel 2 (cum ar fi pachetele și canalele off-chain). Cu toate acestea, nu avem metrici sau benchmark-uri standardizate. Cifrele sunt adesea raportate în moduri inconsecvente și incomplete, ceea ce face dificilă compararea cu acuratețe a proiectelor și adesea ascund ceea ce contează cel mai mult în practică. 

Avem nevoie de o abordare mai nuanțată și mai amănunțită pentru măsurarea și compararea performanței – una care să descompună performanța în mai multe componente și să compare compromisurile pe mai multe axe. În această postare, definesc terminologia de bază, subliniez provocările și ofer linii directoare și principii cheie de care trebuie să țin cont atunci când evaluez performanța blockchain. 

Scalabilitate vs performanță

În primul rând, să definim doi termeni, scalabilitate și performanță, care au semnificații standard în informatică care sunt adesea folosiți greșit în contexte blockchain. Performanţă măsoară ce este un sistem capabil în prezent să realizeze. După cum vom discuta mai jos, valorile de performanță pot include tranzacții pe secundă sau timpul mediu de confirmare a tranzacției. scalabilitate, pe de altă parte, măsoară capacitatea unui sistem de a îmbunătăți performanța prin adăugarea de resurse.

Această distincție este importantă: multe abordări pentru îmbunătățirea performanței nu îmbunătățesc deloc scalabilitatea, atunci când sunt definite corespunzător. Un exemplu simplu este utilizarea unei scheme de semnătură digitală mai eficientă, cum ar fi semnăturile BLS, care au aproximativ jumătate din dimensiunea semnăturilor Schnorr sau ECDSA. Dacă Bitcoin ar trece de la ECDSA la BLS, numărul de tranzacții pe bloc ar putea crește cu 20-30%, îmbunătățind performanța peste noapte. Dar putem face asta o singură dată - nu există o schemă de semnătură și mai eficientă din punct de vedere al spațiului la care să trecem (semnăturile BLS pot fi, de asemenea, agregate pentru a economisi mai mult spațiu, dar acesta este un alt truc unic).

O serie de alte trucuri unice (cum ar fi SegWit) sunt posibile în blockchains, dar aveți nevoie de o arhitectură scalabilă pentru a obține o îmbunătățire continuă a performanței, unde adăugarea mai multor resurse îmbunătățește performanța în timp. Aceasta este înțelepciunea convențională și în multe alte sisteme informatice, cum ar fi construirea unui server web. Cu câteva trucuri comune, puteți construi un server foarte rapid; dar în cele din urmă, aveți nevoie de o arhitectură cu mai multe servere care să poată satisface cererea în continuă creștere prin adăugarea continuă de servere suplimentare.

Înțelegerea distincției ajută, de asemenea, la evitarea erorii comune de categorie găsită în declarații precum „Blockchain X este foarte scalabil, poate gestiona tranzacțiile Y pe secundă!” A doua afirmație poate fi impresionantă, dar este a performanță metrica, nu o metrica de scalabilitate. Nu se referă la capacitatea de a îmbunătăți performanța prin adăugarea de resurse.

Scalabilitatea necesită în mod inerent exploatarea paralelismului. În spațiul blockchain, scalarea stratului 1 pare să necesite sharding sau ceva care arată ca sharding. Conceptul de bază de sharding – împărțirea stării în bucăți, astfel încât validatorii diferiți să poată procesa independent – ​​se potrivește îndeaproape cu definiția scalabilității. Există și mai multe opțiuni pe Layer 2 care permit adăugarea de procesare paralelă - inclusiv canale off-chain, servere rollup și sidechain.

Latență vs

În mod clasic, performanța sistemului blockchain este evaluată în două dimensiuni, latența și debitul: latența măsoară cât de repede poate fi confirmată o tranzacție individuală, în timp ce debitul măsoară rata agregată a tranzacțiilor în timp. Aceste axe se aplică atât sistemelor Layer 1 și Layer 2, cât și multor alte tipuri de sisteme informatice (cum ar fi motoarele de interogare a bazelor de date și serverele web).

Din păcate, atât latența, cât și debitul sunt complexe de măsurat și comparat. În plus, utilizatorilor individuali nu le pasă de fapt de debit (care este o măsură la nivelul întregului sistem). Ceea ce le pasă cu adevărat este latența și taxele de tranzacție - mai precis, că tranzacțiile lor sunt confirmate cât mai repede și cât mai ieftin posibil. Deși multe alte sisteme informatice sunt, de asemenea, evaluate pe o bază de cost/performanță, taxele de tranzacție sunt o axă oarecum nouă de performanță pentru sistemele blockchain care nu există cu adevărat în sistemele informatice tradiționale.

Provocări în măsurarea latenței

Latența pare simplă la început: cât durează o tranzacție pentru a fi confirmată? Dar există întotdeauna mai multe moduri diferite de a răspunde la această întrebare.

În primul rând, putem măsura latența între diferite momente în timp și putem obține rezultate diferite. De exemplu, începem să măsurăm latența atunci când utilizatorul apasă un buton de „trimite” la nivel local sau când tranzacția atinge mempool-ul? Și oprim ceasul atunci când tranzacția este într-un bloc propus, sau când un bloc este confirmat cu un bloc de urmărire sau șase?

Cea mai comună abordare ia punctul de vedere al validatorilor, măsurând de la momentul în care un client difuzează pentru prima dată o tranzacție până la momentul în care tranzacția este „confirmată” în mod rezonabil (în sensul că comercianții din lumea reală ar lua în considerare o plată primită și ar elibera marfa) . Desigur, diferiți comercianți pot aplica criterii de acceptare diferite și chiar și un singur comerciant poate folosi standarde diferite în funcție de valoarea tranzacției.

Abordarea centrată pe validator ratează câteva lucruri care contează în practică. În primul rând, ignoră latența în rețeaua peer-to-peer (cât timp durează de la momentul în care clientul difuzează o tranzacție până la momentul în care majoritatea nodurilor au auzit-o?) și latența pe partea client (cât timp durează pregătirea unei tranzacții). pe mașina locală a clientului?). Latența la nivelul clientului poate fi foarte mică și previzibilă pentru tranzacții simple, cum ar fi semnarea unei plăți Ethereum, dar poate fi semnificativă pentru cazuri mai complexe, cum ar fi dovedirea că o tranzacție Zcash protejată este corectă.

Chiar dacă am standardizat fereastra de timp pe care încercăm să o măsurăm cu latență, răspunsul este aproape întotdeauna depinde. Niciun sistem de criptomonede construit vreodată nu a oferit o latență fixă ​​a tranzacțiilor. O regulă fundamentală de reținut este:

Latența este o distribuție, nu un singur număr.

Comunitatea de cercetare în rețele a înțeles de mult acest lucru (a se vedea, de exemplu, aceasta excelentă discuție a lui Gil Tene). Un accent deosebit este pus pe „coada lungă” a distribuției, deoarece o latență foarte ridicată chiar și în 0.1% din tranzacții (sau interogări de la serverul web) va fi grav. Impactul utilizatori finali.

Cu blockchain-urile, latența de confirmare poate varia din mai multe motive:

Loturi: majoritatea sistemelor lotează tranzacțiile într-un fel, de exemplu în blocuri pe majoritatea sistemelor de nivel 1. Acest lucru duce la o latență variabilă, deoarece unele tranzacții vor trebui să aștepte până când lotul se umple. Alții s-ar putea să aibă noroc și să se alăture ultimului lot. Aceste tranzacții sunt confirmate imediat și nu experimentează nicio latență suplimentară.

Aglomeratie variabila: majoritatea sistemelor suferă de congestie, ceea ce înseamnă că sunt postate mai multe tranzacții (cel puțin o parte din timp) decât poate gestiona sistemul imediat. Cât de aglomerat poate varia atunci când tranzacțiile sunt difuzate la ore imprevizibile (deseori rezumate ca a Procesul Poisson) sau când rata noilor tranzacții se modifică pe parcursul zilei sau săptămânii sau ca răspuns la evenimente externe, cum ar fi o lansare populară a NFT.

Varianta stratului de consens: Confirmarea unei tranzacții pe Layer 1 necesită de obicei un set distribuit de noduri pentru a ajunge la un consens asupra unui bloc, care poate adăuga întârzieri variabile, indiferent de congestie. Sistemele de probă de lucru găsesc blocuri în momente imprevizibile (de asemenea, în mod abstract, un proces Poisson). Sistemele de verificare a mizei pot adăuga, de asemenea, diverse întârzieri (de exemplu, dacă un număr insuficient de noduri sunt online pentru a forma un comitet într-o rundă sau dacă este necesară o schimbare a vederii ca răspuns la prăbușirea unui lider).

Din aceste motive, un ghid bun este:

Afirmațiile despre latență ar trebui să prezinte o distribuție (sau histogramă) a timpilor de confirmare, mai degrabă decât un singur număr, cum ar fi media sau mediana.

În timp ce statisticile rezumative precum media, mediana sau percentilele oferă o imagine parțială, evaluarea cu acuratețe a unui sistem necesită luarea în considerare a întregii distribuții. În unele aplicații, latența medie poate oferi o perspectivă bună dacă distribuția latenței este relativ simplă (de exemplu, Gauss). Dar în criptomonedă, aproape niciodată nu este așa: de obicei, există o coadă lungă de timpi lenți de confirmare.

Rețelele de canale de plată (de exemplu, Lightning Network) sunt un bun exemplu. O soluție clasică de scalare L2, aceste rețele oferă confirmări de plată foarte rapide de cele mai multe ori, dar ocazional necesită o resetare a canalului care poate crește latența cu ordine de mărime.

Și chiar dacă avem statistici bune cu privire la distribuția exactă a latenței, acestea vor varia probabil în timp pe măsură ce sistemul și cererea asupra sistemului se schimbă. De asemenea, nu este întotdeauna clar cum să comparăm distribuțiile de latență între sistemele concurente. De exemplu, luați în considerare un sistem care confirmă tranzacțiile cu o latență distribuită uniform între 1 și 2 minute (cu o medie și o medie de 90 de secunde). Dacă un sistem concurent confirmă 95% din tranzacții exact într-un minut, iar celelalte 1% în 5 minute (cu o medie de 11 de secunde și o mediană de 90 de secunde), care sistem este mai bun? Răspunsul este probabil că unele aplicații le-ar prefera pe prima, iar altele pe cea din urmă.

În cele din urmă, este important de reținut că în majoritatea sistemelor, nu toate tranzacțiile au prioritate egală. Utilizatorii pot plăti mai mult pentru a obține o prioritate mai mare de includere, astfel încât pe lângă toate cele de mai sus, latența variază în funcție de taxele de tranzacție plătite. În concluzie:

Latența este complexă. Cu cât sunt raportate mai multe date, cu atât mai bine. În mod ideal, distribuțiile complete ale latenței ar trebui măsurate în diferite condiții de congestie. Defalcările latenței în diferite componente (local, rețea, loturi, întârziere de consens) sunt, de asemenea, utile.

Provocări în măsurarea debitului

De asemenea, randamentul pare simplu la prima vedere: câte tranzacții poate procesa un sistem pe secundă? Apar două dificultăți principale: ce este exact o „tranzacție” și măsurăm ce face un sistem astăzi sau ce ar putea să facă?

În timp ce „tranzacțiile pe secundă” (sau tps) este un standard de facto pentru măsurarea performanței blockchain, tranzacțiile sunt problematice ca unitate de măsură. Pentru sistemele care oferă programabilitate de uz general („contracte inteligente”) sau chiar caracteristici limitate, cum ar fi tranzacțiile multiplex ale Bitcoin sau opțiuni pentru verificarea multi-sig, problema fundamentală este:

Nu toate tranzacțiile sunt egale.

Acest lucru este evident adevărat în Ethereum, unde tranzacțiile pot include cod arbitrar și pot modifica în mod arbitrar starea. Noțiunea de gaz în Ethereum este folosită pentru a cuantifica (și percepe taxe pentru) cantitatea totală de muncă pe care o face o tranzacție, dar aceasta este foarte specifică mediului de execuție EVM. Nu există o modalitate simplă de a compara cantitatea totală de muncă efectuată de un set de tranzacții EVM cu, de exemplu, un set de tranzacții Solana folosind mediul BPF. Compararea fiecăreia cu un set de tranzacții Bitcoin este la fel de grea.

Blockchain-urile care separă stratul de tranzacție într-un strat de consens și un strat de execuție pot face acest lucru mai clar. La nivelul de consens (pur), debitul poate fi măsurat în octeți adăugați lanțului pe unitate de timp. Stratul de execuție va fi întotdeauna mai complex.

Straturile de execuție mai simple, cum ar fi serverele rollup care acceptă doar tranzacții de plată, evită dificultatea de cuantificare a calculului. Chiar și în acest caz, totuși, plățile pot varia în ceea ce privește numărul de intrări și ieșiri. Canal de plată tranzacțiile pot varia în ceea ce privește numărul de „hopuri” necesar, ceea ce afectează debitul. Iar debitul serverului de acumulare poate depinde de măsura în care un lot de tranzacții poate fi „regrupat” la un set mai mic de modificări rezumative.

O altă provocare cu debitul este să depășească măsurarea empirică a performanței actuale pentru a evalua capacitatea teoretică. Aceasta introduce tot felul de întrebări de modelare pentru a evalua capacitatea potențială. În primul rând, trebuie să decidem asupra unui volum de lucru realist al tranzacției pentru nivelul de execuție. În al doilea rând, sistemele reale nu ating aproape niciodată capacitatea teoretică, în special sistemele blockchain. Din motive de robustețe, sperăm că implementările nodurilor sunt eterogene și diverse în practică (mai degrabă decât toți clienții care rulează o singură implementare software). Acest lucru face simulările precise ale fluxului blockchain și mai dificil de realizat. 

În total:

Afirmațiile privind debitul necesită o explicație atentă a volumului de lucru al tranzacției și a populației de validatori (cantitatea acestora, implementarea și conectivitatea la rețea). În absența oricărui standard clar, sarcinile istorice de la o rețea populară precum Ethereum sunt suficiente.

Compensații latență-debit

Latența și debitul sunt de obicei un compromis. La fel de Lefteris Kokoris-Kogias conturează, acest compromis nu este adesea neted, cu un punct de inflexiune în care latența crește brusc pe măsură ce sarcina sistemului se apropie de debitul maxim.

Sistemele de acumulare de cunoștințe zero prezintă un exemplu natural al compromisului debit/latență. Loturi mari de tranzacții măresc timpul de probă, ceea ce crește latența. Dar amprenta pe lanț, atât în ​​ceea ce privește dimensiunea probei, cât și costul de validare, va fi amortizată pentru mai multe tranzacții cu dimensiuni mai mari de loturi, crescând debitul.

Taxele de tranzacție

De înțeles, utilizatorilor finali le pasă mai mult de compromisul dintre latență și Taxele de, nu latența și debitul. Utilizatorii nu au niciun motiv direct să le pese de debit, doar că pot confirma tranzacțiile rapid pentru cele mai mici taxe posibil (cu unii utilizatori le pasă mai mult de taxe, iar alții mai mult de latență). La un nivel ridicat, taxele sunt afectate de mai mulți factori:

1. Câtă cerere de piață există pentru a face tranzacții?
2. Ce randament global este realizat de sistem?
3. Cât de mult venit total oferă sistemul validatorilor sau minerilor?
4. Cât de mult din acest venit se bazează pe comisioane de tranzacție față de recompense inflaționiste?

Primii doi factori sunt aproximativ curbele ofertei/cererii care conduc la un preț de compensare a pieței (deși s-a susținut că minerii acționează ca un cartel pentru a ridica taxele peste acest punct). Toate celelalte fiind egale, un randament mai mare ar trebui să aibă tendința de a duce la comisioane mai mici, dar se întâmplă mult mai mult.

În special, punctele 3 și 4 de mai sus sunt întrebări fundamentale ale proiectării sistemului blockchain, dar ne lipsesc principiile bune pentru oricare dintre ele. Avem o oarecare înțelegere a avantajelor și dezavantajelor de a oferi minerilor venituri din recompense inflaționiste față de taxele de tranzacție. Cu toate acestea, în ciuda multor analize economice ale protocoalelor de consens blockchain, încă nu avem un model larg acceptat pentru cât de mult venituri trebuie să meargă către validatori. Astăzi, majoritatea sistemelor construiesc o presupunere educată despre cât de mult venit este suficient pentru ca validatorii să se comporte cinstit, fără a sugruma utilizarea practică a sistemului. În modelele simplificate, se poate demonstra că costul instalării unui atac de 51% crește cu recompense pentru validatori.

Creșterea costurilor atacurilor este un lucru bun, dar nici nu știm cât de multă securitate este „suficientă”. Imaginează-ți că te gândești să mergi în două parcuri de distracție. Unul dintre ei susține că cheltuiește cu 50% mai puțin pentru întreținerea călătoriei decât celălalt. Este o idee bună să mergi în acest parc? S-ar putea să fie mai eficienți și să obțină o siguranță echivalentă pentru mai puțini bani. Poate că celălalt cheltuiește mai mult decât este necesar pentru a menține călătoriile în siguranță fără niciun beneficiu. Dar s-ar putea întâmpla și ca primul parc să fie periculos. Sistemele blockchain sunt similare. Odată ce luați în considerare debitul, blockchain-urile cu taxe mai mici au taxe mai mici, deoarece răsplătesc (și, prin urmare, stimulează) validatorii lor mai puțin. Nu avem instrumente bune astăzi pentru a evalua dacă acest lucru este în regulă sau dacă lasă sistemul vulnerabil la atac. Per total:

Compararea taxelor între sisteme poate induce în eroare. Chiar dacă taxele de tranzacție sunt importante pentru utilizatori, acestea sunt afectate de mulți factori, în afară de designul sistemului în sine. Debitul este o măsură mai bună pentru analiza unui sistem ca întreg.

Concluzie

Evaluarea corectă și corectă a performanței este dificilă. Acest lucru este valabil și pentru măsurarea performanței unei mașini. La fel ca în cazul blockchain-urilor, diferiților oameni le va păsa de lucruri diferite. În cazul mașinilor, unor utilizatori le va păsa de viteza maximă sau de accelerație, altora de consumul de carburant și alții de capacitatea de remorcare. Toate acestea nu sunt banale de evaluat. În SUA, de exemplu, Agenția pentru Protecția Mediului menține linii directoare detaliate doar pentru modul în care este evaluată consumul de gaz, precum și modul în care trebuie prezentată utilizatorilor la o reprezentanță.

Spațiul blockchain este departe de acest nivel de standardizare. În anumite zone, putem ajunge acolo în viitor cu sarcini de lucru standardizate pentru a evalua debitul unui sistem sau grafice standardizate pentru prezentarea distribuțiilor de latență. Deocamdată, cea mai bună abordare pentru evaluatori și constructori este să colecteze și să publice cât mai multe date, cu o descriere detaliată a metodologiei de evaluare, astfel încât să poată fi reprodusă și comparată cu alte sisteme.