Valorificarea securității partajate pentru interoperabilitate sigură între lanțuri

Având în vedere că atacurile asupra punților blockchain conduc la pierderi de miliarde de dolari, nu este surprinzător că discuțiile despre securitatea cross-chain generează adesea dezbateri intense. Dar credem în adoptarea unei abordări mai pragmatice – una care implică analizarea problemei interoperabilității securizate de la primele principii și proiectarea mecanismelor pentru a crește garanțiile de siguranță pentru aplicațiile cross-chain și utilizatorii acestora.

În acest articol, vom explora conceptul de securitate partajată și vom explica modul în care proiectele de securitate partajată (cum ar fi Comitetele de stat Lagrange) pot reduce costul de bootstrapping a proprietăților de siguranță semnificative pentru protocoalele de interoperabilitate. În timp ce ne concentrăm pe securitatea partajată pentru protocoalele de comunicații cross-chain, orice aplicație descentralizată – indiferent de cazul de utilizare – poate valorifica această tehnologie emergentă pentru a obține o descentralizare suficientă și o minimizare a încrederii fără a suporta cheltuieli operaționale excesive.

O introducere informală în securitatea comună

„Securitate partajată” se referă la securitatea pe care un protocol o derivă dintr-o sursă externă. Într-o schemă de securitate partajată, resursele puse în comun de participanții la un protocol (de exemplu, capitalul sau puterea de calcul) sunt utilizate pentru a crea securitate economică pentru un alt protocol. Securitatea partajată diferă de modelul standard în care fiecare rețea este responsabilă pentru securitatea sa.

Blockchain-urile publice precum Bitcoin și Ethereum, de exemplu, combină algoritmi de consens cu mecanisme de rezistență Sybil-cum ar fi Proof of Work sau Proof of Stake-pentru a garanta vitalitatea și, în același timp, a crește costul atacurilor adverse (de exemplu, atacuri Sybil , atacuri pe distanță lungă , eclipse) . atacuri , atacuri de bandiți în timp și atacuri de mită ).

Deși schemele de securitate partajată funcționează diferit, obiectivele se învârt de obicei în jurul a două obiective:

• Creșterea eficienței capitalului în rețelele blockchain fără a crea riscuri suplimentare (stivuirea riscurilor) sau a introduce ipoteze de securitate suplimentare.
• Îmbunătățirea capacității rețelelor blockchain (în special a protocoalelor în curs de dezvoltare) de a se apăra împotriva tranzițiilor de stări nevalide, reorganizărilor, rezistenței la cenzură și altele împotriva atacurilor asupra vieții și siguranței unui protocol.

Securitatea partajată nu este tocmai un concept nou; de exemplu, merge-mining a fost introdusă în 2011, permițând minerilor să folosească aceeași Proof-of-Work (PoW) criptografică pentru a crea blocuri pe două (sau mai multe) lanțuri diferite PoW care implementează consensul Nakamoto . Acest lucru a permis protocoalelor mai noi bazate pe PoW (cum ar fi Namecoin și Rootstock), ale căror jetoane native nu dobândiseră suficientă valoare pentru a atrage un interes semnificativ din partea minerilor, să împărtășească securitatea prin reutilizarea resurselor de calcul dedicate securizării rețelei Bitcoin pentru a crește dificultatea blocurilor. asupra noului protocol.

Acestea fiind spuse, mineritul de fuziune este considerat a oferi o formă slabă de securitate economică pentru rețelele descentralizate din cauza lipsei de siguranță responsabilă. În literatura academică, siguranța responsabilă reflectă capacitatea unui protocol de a detecta noduri care (probabil) încalcă regulile protocolului și pedepsește comportamentul rău intenționat. De exemplu, protocoalele bazate pe Proof of Stake necesită ca nodurile să blocheze garanția (prin mizarea jetonului nativ al protocolului) înainte de a participa la consens și pot distruge/îngheța („slash”) această garanție dacă apar dovezi ale comportamentului incorect al validatorului.

În cazul merge mining, nodurile care acceptă în mod deliberat blocuri invalide pe lanțul merge-mined nu pot fi detectate în mod fiabil. Mai mult, este imposibil să pedepsești nodurile menționate (chiar dacă ar fi posibil să le identifici), deoarece aceasta ar necesita o măsură drastică, cum ar fi arderea sau distrugerea hardware-ului minier. În timp ce amenințarea ca jetonul lanțului extras de fuziune să piardă din valoare din cauza atacurilor la securitatea acestuia poate părea suficientă pentru a descuraja comportamentul bizantin, minerii rău intenționați au mai puțin de pierdut, deoarece valoarea lanțului original (de exemplu, Bitcoin) este puțin probabil să fie afectată.

Noțiunile moderne de securitate partajată nu numai că au evoluat pentru a încorpora siguranța responsabilă, dar au trecut și la utilizarea unei alte unități de investiții - capitalul - ca bază a securității partajate. În acest design, există un protocol de bază care oferă securitate pentru alte protocoale PoS construite pe acesta; nodurile se alătură mai întâi rețelei primare (prin blocarea jetonului nativ al rețelei ca miză) înainte de a participa la securizarea rețelei secundare.

Acest design poate lua diferite forme:

• Validatorii participă în rețeaua primară și în rețeaua secundară simultan
• Un subset de validatori (din rețeaua primară) este eșantionat aleatoriu pentru a valida și securiza rețeaua secundară
• Rețeaua secundară este securizată de un set independent de validatoare conectate la rețeaua primară
• Validatorii din rețeaua primară redelegă capitalul mizat către validatorii din rețeaua secundară

Indiferent de detaliile de implementare, detaliul crucial pentru schemele de securitate partajate descrise mai sus este că protocolul de bază trebuie să aibă mijloace de pedepsire a validatorilor care acționează rău intenționat în rețeaua secundară. Deoarece există mai puțin capital pentru securizarea rețelei secundare, posibilitatea ca o supermajoritate rău intenționată să deturneze protocolul este o preocupare reală.

Soluția este să ne asigurăm că unul sau mai mulți participanți onești (care formează minoritatea) pot trage majoritatea la răspundere prin inițierea unei dispute și publicarea dovezilor privind încălcarea protocolului la nivelul de bază. În cazul în care protocolul de bază (acționând ca „judecător”) acceptă aceste dovezi, părțile necinstite pot fi pedepsite prin reducerea garanțiilor (formate ca o garanție) pe rețeaua primară. Este important că stratul de bază trebuie doar să verifice dovezile furnizate și nu trebuie să execute un consens suplimentar înainte de a soluționa disputele - reducând cheltuielile generale de coordonare.

Ideea mai subtilă este că comportamentul greșit trebuie să fie atribuit unei părți pentru ca mecanismele de reducere să fie eficiente. În rețelele bazate pe PoS, validatorii sunt obligați să genereze o pereche de chei public-privată care servește ca o identitate criptografică unică în cadrul protocolului de consens. În timpul sarcinilor de rutină, cum ar fi propunerea de blocuri sau atestarea (validității) blocurilor, un validator semnează datele blocului cu cheia sa privată - legându-le efectiv de acea alegere.

Acest lucru face posibilă tăierea unui validator pentru diferite acțiuni care ar fi interpretate ca un atac la adresa siguranței sau a vieții protocolului (sau ambele în unele cazuri):

• Semnarea a două blocuri conflictuale în aceeași perioadă (cunoscută oficial ca „echivoc”)
• Semnarea unui blocaj nevalid (fie în timpul unei propuneri sau al unei atestări)
• Cenzurarea uneia sau mai multor tranzacții
• Ascunderea unora sau a tuturor părților datelor unui bloc

În timp ce primele două infracțiuni pot fi detectate în același mod (prin recuperarea cheii publice a unui validator din semnătura acestuia), ultimele două necesită alte mecanisme, cum ar fi listele de includere și codurile de ștergere . În toate cazurile, utilizarea criptografiei permite detectarea și pedepsirea de încredere a comportamentului rău intenționat care ar putea degrada anumite proprietăți de securitate dorite într-un protocol, cum ar fi rezistența la cenzură și valabilitatea tranzacțiilor. Acest lucru oferă un anumit context cu privire la semnificația „securității criptoeconomice”, care implică combinarea mecanismelor criptografice cu stimulente economice pentru securizarea rețelelor descentralizate.

Putem ilustra această idee – și o putem compara cu mine-mining-ul de fuziune – folosind exemplul unui nou blockchain PoS care împărtășește securitatea Ethereum. Protocolul nostru de jucărie are următoarele proprietăți (rețineți că este un exemplu prea simplist folosit în scopuri ilustrative):

• Operatorilor de noduri li se cere să depună o anumită cantitate de jetoane ETH ca garanție într-un contract inteligent Ethereum înainte de a se înscrie ca validatori în rețeaua PoS
• În timpul epocilor, cei care propun blocuri pe protocolul PoS trimit hashuri ale antetelor blocurilor (care includ semnăturile validatorilor) către Ethereum prin stocarea lor într-un contract inteligent
• Securitatea se bazează pe dovezi de fraudă — lanțul părinte (Ethereum) nu verifică tranzițiile de stare, dar poate verifica un contraexemplu care arată că o anumită tranziție de stare este invalidă
• Un mecanism de tăiere în lanț este activat dacă o anumită tranziție de stat este contestată de una sau mai multe părți

Acum, să presupunem că o majoritate rău intenționată a nodurilor din rețeaua secundară se complică pentru a finaliza un bloc invalid pentru a fura fondurile depuse în contractul de punte. În acest scenariu, un validator onest ar declanșa mecanismul de tăiere în lanț pe Ethereum prin publicarea unei dovezi de fraudă și identificarea validatorilor care încalcă protocolul. Dacă regulile de protocol permit reducerea întregii mize a unui validator, atunci costul coruperii lanțului PoS este proporțional cu suma mizată de majoritatea validatorilor.

Acest exemplu arată cum siguranța responsabilă stă la baza proiectelor de securitate partajată și permite în mod eficient securizarea rețelelor mai mici prin protocoale mai mari care au generat o securitate economică semnificativă și se laudă cu niveluri mai ridicate de descentralizare și lipsă de încredere. Putem vedea, de asemenea, că mecanica Proof-of-Stake duce la proiecte de securitate partajate cu noțiuni mai puternice de siguranță în comparație cu mine-mining (care folosește puterea de calcul ca bază a securității economice).

În plus, introduce ideea unui nou protocol care să utilizeze tokenul altei rețele pentru miza, pentru a atenua „problema bootstrapping” (unde un nou protocol blockchain are o securitate economică scăzută, deoarece tokenul său nu a dobândit suficientă valoare). În timp ce problema bootstrapping-ului poate fi rezolvată cu abordări, cum ar fi mine-mining, care utilizează investiția hardware ca unitate de securitate economică, acest tip de securitate partajată este suboptimă din anumite motive (unele dintre ele le-am identificat anterior):

• Investiția de capital – care ar trebui să impună costuri semnificative comportamentului rău intenționat pentru validarea nodurilor – este implicită și dificil de utilizat pentru securitatea economică. A face investiții de capital explicite în cazul merge-mining PoW ar necesita o măsură drastică, cum ar fi distrugerea hardware-ului de minerit în cazul unui comportament probabil rău intenționat, care este nerealist în situațiile din lumea reală și dificil de utilizat.
• Merge-mining (sau orice proiect de securitate partajat în care participarea la consens este legată de infrastructura de rulare) este dificil de scalat. De exemplu, există o limită superioară a câte lanțuri PoW se poate fuziona și mina simultan înainte ca rentabilitatea investiției minerului să înceapă să scadă.

În schimb, schemele de securitate partajată bazate pe PoS care utilizează investiția de capital ca unitate de investiție au anumite proprietăți care sunt utile pentru rezolvarea problemei de bootstrapping a noilor rețele în mod eficient și eficient:

• Investiția de capital este explicită (participanții investesc capital în cumpărarea de jetoane pentru a îndeplini cerințele de garanție) și poate fi valorificată pentru garanții puternice și concrete de securitate economică. De exemplu, este ușor de vizualizat că un protocol poate fi mai sigur atunci când are o miză în valoare de 1 ETH care asigură tranzacții în valoare de 0,9 ETH decât atunci când o miză de 0,9 ETH asigură tranzacții în valoare de 1 ETH.
• Întrucât participarea la consens este legată de investiția de capital „pură”, este mai ușor să se extindă securitatea economică și ca validatorii să securizeze mai multe protocoale fără a suporta cheltuieli de coordonare excesive (mai ales când cerințele hardware sunt scăzute).

Cu toate acestea, fiecare abordare va avea dezavantaje, iar securitatea partajată prin miza nu face excepție; de exemplu, determinarea cât de mult ar trebui să pună validatorii de garanții într-un protocol PoS este o problemă dificil de rezolvat. Vom pune acest lucru în context luând în considerare această afirmație din paragraful precedent: „ Este ușor de vizualizat că un protocol este probabil să fie mai sigur atunci când are o miză în valoare de 1 ETH care asigură tranzacții în valoare de 0,9 ETH decât atunci când valorează 0,9 ETH. miza asigură tranzacții în valoare de 1 ETH. ”

Deși această afirmație sună rezonabilă, o analiză mai profundă dezvăluie dificultatea de a alege o cerință optimă de obligație:

• Solicitarea a 1 ETH de la validatori pentru a asigura active în valoare de 0,9 ETH scade eficiența capitalului și duce la supracolateralizare.
• Asigurarea tranzacțiilor în valoare de 2 ETH cu o miză în valoare de 1 ETH reduce lățimea de bandă economică (sau „levierul”) într-un blockchain PoS și duce la subcolateralizare.

Într-un scenariu ideal, un proiectant de protocol ar prefera să aibă 1 ETH de miză care să asigure tranzacții în valoare de 1 ETH. Dar astfel de echilibre sunt greu de realizat în condițiile lumii reale din diferite motive; de exemplu, cantitatea de capital care trebuie asigurată pe unitatea de timp (o funcție de valoarea marginală a tranzacțiilor pe bloc/epocă) este dinamică. Acest lucru face ca stabilirea legăturii ideale într-un sistem PoS să fie o problemă de mecanism foarte dificilă și o considerație importantă pentru schemele de securitate partajate bazate pe mize, cum ar fi repetarea (despre care vom discuta în secțiunea următoare).

Securitate partajată de la repetarea și punctele de control

Reluarea

Restabilirea are rădăcinile în reipotecare - o practică în finanțele tradiționale prin care un împrumutător folosește active (anterior gajate ca garanție de către un împrumutat) ca garanție pentru a garanta un nou împrumut. Aici, noua contraparte își asumă drepturi asupra activului colateral inițial, astfel încât, în cazul în care entitatea care a contractat noul împrumut nu se rambursează, poate scoate la licitație activul pentru a recupera fondurile.

Atunci când este implementată corect, reipotecarea poate fi utilă. Pentru început, permite o mai mare eficiență a capitalului și lichiditate prin reutilizarea activelor – care altfel ar rămâne latente – pentru a asigura finanțare pe termen scurt pentru activități generatoare de profit. Dacă profitul obținut din contractarea unui împrumut depășește valoarea garanției reipotecate, toate părțile implicate (împrumutatul inițial, împrumutătorul și creditorul împrumutătorului) beneficiază.

Reipotecarea implică un mare risc (parte din motivele pentru care practica a căzut în mare parte din favoarea instituțiilor TradFi), în special pentru împrumutatul inițial care ar putea pierde drepturile asupra activului său atunci când are loc o lichidare. Creditorul care reutiliza garanția poartă, de asemenea, riscuri, cu atât mai mult dacă este obligat să ramburseze debitorilor după ce o nouă contraparte confiscă garanția depusă din cauza neplată a împrumutului.

Celălalt risc este unul pe care l-am descris pe scurt anterior și se învârte în jurul compromisului dintre supracolateralizare și subcolateralizare. În exemplul evidențiat anterior, dacă Banca B (banca lui John) intră într-o poziție cu efect de levier excesiv – în care se împrumută mai mult decât valoarea garanției lui John – și suferă o pierdere, devine dificil să rambursați împrumutul de la Banca B (sau să returnați creditul lui John). active). Banca B se poate proteja împotriva acestui caz marginal cerând Băncii A (băncii lui John) să împrumute mai puțin decât valoarea garanției lui John; cu toate acestea, aceasta crește ineficiența capitalului pentru Banca A și reduce câștigurile din reipotecarea garanției lui John în primul rând.

Același set de argumente pro și contra se aplică și reluării. Înainte de a merge mai departe, este important să clarificăm un detaliu important: miza unui restaker trece întotdeauna mai întâi prin protocolul de bază. De exemplu, un restaker pe Ethereum va trebui fie să depună 32 ETH în contractul Beacon Chain, fie să delege ETH unui validator operat de un serviciu de staking – în funcție de dacă se folosește restaking nativ sau lichid .

La un nivel înalt, refacerea în cazul Ethereum cuprinde următoarele:

#1: Acordarea drepturilor de proprietate a protocolului de refacere (sau a unei revendicări) ETH mizată

În restabilirea nativă, un validator este necesar să-și schimbe adresa de retragere într-un contract inteligent gestionat de protocolul de retragere. Astfel, în loc ca fondurile să ajungă direct la validator după ieșirea din Beacon Chain, miza trece mai întâi prin protocolul de restabilire înainte de a ajunge la validator (vom vedea de ce este cazul destul de curând).

De asemenea, este posibil să se depună reprezentări fungibile (derivate) ale ETH mizați în contractele inteligente ale protocolului de restaking (restaking lichid). Denumite „jetoane lichide cu miză”, astfel de jetoane sunt emise de operatorii de staking-as-service (de exemplu, RocketPool, Lido, Coinbase etc.). și reprezintă o revendicare pentru o parte din ETH mizată de un validator (inclusiv randamentul din recompense) și poate fi răscumpărat la un raport de 1:1 pentru jetoanele ETH native.

#2: Opțiunea pentru condițiile suplimentare de reducere impuse de protocolul de restabilire

Un protocol de refacere funcționează de obicei ca un „middleware” la care se pot conecta diverse rețele și aplicații descentralizate pentru securitate economică. Acestea ar include de obicei protocoale care necesită o anumită formă de validare de către un set de părți - de exemplu, o rețea oracle - dar al căror simbol nativ nu a acumulat suficientă valoare pentru a fi utilizat într-o setare Proof of Stake.

În loc să construiască un nou set de validatori de la zero, astfel de aplicații pot apela la serviciile validatorilor existenți printr-un protocol de refacere. Serviciile pot specifica condiții unice de reducere a garanției reipotecate a unui validator – pe care protocolul de refacere le poate aplica, deoarece acum controlează retragerea validatorului – scăzând bariera în calea securității economice.

O notă importantă: condițiile de reducere a AVS sunt independente de condițiile de reducere impuse de consensul Beacon Chain al Ethereum, astfel încât miza ETH a unui validator ar putea fi redusă chiar dacă nu a comis o infracțiune care poate fi redusă pe Ethereum în sine. Acest lucru ar putea duce la ceea ce descriem ca „stivuire a riscurilor”: în schimbul unei eficiențe mai mari a capitalului, rețeaua primară moștenește riscuri suplimentare decât ar fi altfel. (Stivuirea riscurilor are, de asemenea, implicații pentru protocolul de bază EigenLayer în sine, așa cum vom vedea ulterior.)

#3: Primirea de recompense suplimentare

Redistribuirea necesită asumarea unor riscuri semnificative (de exemplu, un validator repetat ar putea fi tăiat accidental din cauza unei erori în mecanismul de tăiere în lanț) Dar, la fel cum reipotecarea deblochează lichiditate în TradFi, reevaluarea poate îmbunătăți eficiența capitalului în ecosistemele PoS și poate genera o valoare mai mare decât -randament mediu pentru stakers.

Acest lucru se bazează pe faptul că serviciile care au folosit capitalul redistribuit pentru securitate sunt obligate să recompenseze validatorii pentru serviciile lor. Pentru a exemplifica, un validator repetat care participă la o rețea Oracle va primi taxe pentru validarea actualizărilor Oracle - cu plata provenind de la alte aplicații terțe care se bazează pe serviciile Oracle. Având în vedere că validatorii încă primesc recompense de la Beacon Chain, refacerea permite obținerea de venituri din mai multe protocoale PoS fără a fi nevoie să redistribuie capital proaspăt într-un nou ecosistem.

Deși în acest exemplu ne concentrăm pe refacerea Ethereum, alte protocoale Proof of Stake au implementat și variante de refacere pentru a atinge obiective similare (reducerea costului lansării de noi protocoale/aplicații, îmbunătățirea eficienței capitalului și creșterea securității economice). De fapt, următoarea secțiune discută EigenLayer—protocolul principal de restabilire al Ethereum—înainte de a trece la evidențierea restabilirii în alte ecosisteme:

EigenLayer

EigenLayer este un protocol de refacere creat pentru a extinde securitatea economică a Ethereum pentru a securiza noi aplicații distribuite, rețele și protocoale (pe care le descrie în mod colectiv drept „Servicii validate activ” sau pe scurt AVS). Dacă ați citit secțiunea anterioară care descrie exemplul de reluare pe Ethereum, atunci înțelegeți deja operațiunile EigenLayer la un nivel înalt; cu toate acestea, vom include câteva detalii suplimentare pentru context.

După refacerea ETH (prin direcționarea acreditărilor de retragere asociate cu un validator către contractele inteligente controlate de EigenLayer), este necesar un validator pentru a îndeplini sarcinile specificate de AVS pe care doresc să le opereze. De exemplu, dacă un AVS este un sidechain, validatorul repetat trebuie să ruleze software-ul client pentru ca sidechain să execute tranzacții și să verifice blocurile, câștigând în același timp recompense pentru îndeplinirea corectă a acestor sarcini. Mai larg, sarcinile pot varia în funcție de natura AVS:

• Stocarea datelor într-o rețea de disponibilitate a datelor

• Aprobarea tranzacțiilor de depunere și retragere pentru o punte cross-chain sau aprobarea mesajelor pentru un protocol de mesagerie cross-chain

• Generarea și verificarea dovezilor fără cunoștințe pentru o aplicație axată pe confidențialitate sau o rețea de plăți protejată

• Stocarea și verificarea antetelor de bloc și rularea de relee/oracole pentru protocoale de interoperabilitate încrucișată

  
  

Cititorii pricepuți vor observa două lucruri: (a) sarcinile specificate de un AVS pot fi destul de arbitrare (b) diferitele sarcini specificate de AVS necesită niveluri diferite de investiție și efort. Pentru a ilustra ultimul punct, este posibil să ne imaginăm că stocarea antetelor de bloc într-un protocol cross-chain va necesita mai puțin spațiu pe disc/memorie în comparație cu stocarea și furnizarea datelor într-o rețea de disponibilitate a datelor (chiar și acolo unde tehnici precum eșantionarea disponibilității datelor reduc sarcinile de stocare). pe noduri individuale).

Acesta este unul dintre motivele pentru care EigenLayer permite validatorilor repetate să delege executarea sarcinilor specificate de AVS unei alte părți (un operator) care împarte recompensele câștigate din AVS cu validatorul. Această abordare are niveluri diferite de risc pentru validatorii reevaluați, în funcție de măsura în care sarcina reducerii – ceea ce se poate întâmpla dacă operatorul nu reușește să îndeplinească corect sarcinile AVS – este împărțită între validatorul repetat și operatorul terță parte.

Fiecare AVS specifică un set de condiții în care miza unui restaker EigenLayer poate fi redusă. De exemplu, o rețea de disponibilitate a datelor care implementează mecanisme Proof of Space/Storage poate reduce operatorii care nu reușesc să stocheze datele pe durata convenită. Slashing declanșează înghețarea operatorului în EigenLayer - împiedicând participarea în continuare la unul sau mai multe servicii validate activ - și eventuala reducere a soldului ETH al validatorului.

Pentru ca slashing să aibă loc, infracțiunea trebuie să fie dovedibilă – ceea ce permite protocolului de bază (Ethereum în acest caz) – să judece disputele și să pedepsească partea necinstă. Designul actual al Ethereum permite reducerea cu până la 50% din miza unui validator (16 ETH), ceea ce lasă EigenLayer dreptul de a reduce restul de 50% (16 ETH) în cazul în care un operator încalcă regulile specificate de AVS în timpul executării sarcinilor.

Mecanica de reducere a lui EigenLayer sugerează, de asemenea, un risc subtil de reluare: a fi redus de un serviciu reduce echilibrul general al validatorului în contractele inteligente EigenLayer și în lanțul de faruri Ethereum. Este important, totuși, un scenariu limită apare atunci când slashing are loc din cauza unei erori în logica slashing a unui anumit AVS și nu ca urmare a unei infracțiuni dovedibile. În acest caz, pierderea recompenselor din validarea lanțului principal Ethereum - presupus a fi mai mare decât recompensele din validarea AVS - ar face ca rentabilitatea investiției din reevaluare să fie suboptimă din perspectiva unui validator.

Un alt risc legat de repetarea în stil EigenLayer se referă la riscul supracolateralizării și subcolateralizării validatorului și conceptul de stivuire a riscurilor. Din exemplul anterior de reipotecare, vedem că partea care reipotecă garanția poate fi îndatorată simultan față de primul împrumutat (a cărui garanție este utilizată pentru a contracta un nou împrumut) și împrumutătorul final din lanț (care are o creanță asupra garanției gajate). de către împrumutatul inițial).

O dinamică similară se poate desfășura în construcții de repetare precum EigenLayer dacă un validator repetat (intenționat sau deliberat) comite simultan infracțiuni care pot fi tăiate pe lanțul de baliză Ethereum și unul sau mai multe AVS. În funcție de locul unde are loc prima reducere, este posibil ca alte AVS să nu mai aibă nicio miză de tăiat - permițând efectiv un atac fără risc asupra aplicațiilor securizate de EigenLayer.

Echipa EigenLayer a recunoscut acest vector de atac (vezi Anexa B: Analiza riscului criptoeconomic al documentului EigenLayer ) și a făcut câțiva pași pentru a aborda acest risc. Aceasta include furnizarea unei euristice oficiale pentru evaluarea subcolateralizării și supracolateralizării staker-urilor în AVS și indicarea planurilor de a furniza informații de consiliere dezvoltatorilor AVS printr-un tablou de bord de gestionare a riscurilor la lansare.

Polkadot Parachains

Deși este cunoscut în mare parte pentru că permite interoperabilitatea între blockchain-uri eterogene, Polkadot se bazează în mare măsură pe securitatea partajată. De fapt, securitatea partajată este motivul pentru care diferitele lanțuri din ecosistemul lui Polkadot pot face schimb de mesaje fără a introduce ipoteze de încredere sau fără a implica riscuri de securitate.

Pe Polkadot, subseturile de validatoare (care au jetoane DOT stacked pe lanțul de releu) sunt alocate aleatoriu paralanțurilor (gândiți-vă la „lanțuri copii”) pentru a verifica blocurile – și Proof of Validity (PoV) asociată – produse de colatorul fiecărui parachain. Un colator este nodul responsabil pentru executarea tranzacțiilor unui parachain și creează un „para-bloc” trimis grupului de validatori al parachain-ului pentru verificare.

Deoarece verificarea PoV al unui bloc este intensivă din punct de vedere computațional, para-validatorii (numele validatorilor alocați unui paralanț) primesc recompense suplimentare pentru această sarcină. Blocurile aprobate de paravalidatori – sau mai precis, angajamentele criptografice față de acele blocuri – sunt trimise pentru includere în lanțul de releu (gândiți-vă la „lanțul părinte”). Un bloc paralanț devine final dacă un bloc care îl face referire este aprobat de majoritatea setului de validatori rămas din lanțul de releu.

Ultimul punct este destul de important: deoarece numărul de validatori de pe fiecare paralanț este scăzut (aproximativ cinci validatori per shard), costul coruperii fragmentelor individuale este scăzut. Pentru a se apăra împotriva unor astfel de atacuri, protocolul Polkadot necesită para-blocuri să fie supuse unei verificări secundare de către un alt grup de noduri selectate aleatoriu.

Dacă se dovedește că un bloc este invalid sau indisponibil (adică o parte din date lipsește), nodurile cinstite pot iniția o dispută pe lanțul de releu principal în care toți validatorii lanțului de releu sunt obligați să execute din nou blocul contestat. O dispută se termină după ce o ⅔ supermajoritate de validatori votează pentru ambele părți ale disputei, validatorii infractori fiind tăiați în lanț dacă reexecuția susține revendicarea tăierii.

Acest mecanism asigură că toate parachain-urile din protocolul Polkadot au același nivel de securitate, indiferent de dimensiunea validatorului setat pe fiecare fragment. Mai mult, paralanțurile obțin securitate din aceeași sursă (toate para-blocurile sunt aprobate de Relay Chain), pot avea încredere în validitatea mesajelor provenite de la un fragment de la distanță (fără a cunoaște neapărat detalii despre consensul sau starea acestuia din urmă).

Interchain Security

Securitatea interchain a fost descrisă ca răspunsul lui Cosmos la reluare și are similaritate cu modelul de securitate comun al lui Polkadot. Similar cu relația dintre lanțul de releu și paralanțuri de pe Polkadot, Cosmos adoptă un model hub-and-spoke în care mai multe lanțuri („Zone Cosmos”) se conectează la un lanț principal („Cosmos Hub”) și obțin securitate din acesta. Rațiunea este, de asemenea, similară cu cea a lui Polkadot: permiteți noilor lanțuri să rămână în siguranță fără a fi nevoie să porniți un set de validator de încredere de la zero (o sarcină destul de dificilă) și, în schimb, să împărtășiți securitatea economică - reunită pe un singur strat - cu alte lanțuri.

În versiunea sa actuală, securitatea interlanțului necesită un validator (care are jetoane ATOM staked) pentru a valida atât Cosmos Hub, cât și toate lanțurile de consumatori conectate la acesta. Un validator care acționează cu răutate asupra unui lanț de consumatori riscă să-și piardă miza pe lanțul de furnizori (Cosmos Hub în acest caz) din cauza reducerii.

Reducerea unui validator ofensator necesită, de obicei, transmiterea unui pachet care conține dovezi de comportament slashable prin canalul IBC (Inter-Blockchain Communication) între lanțul de furnizori și lanțul de consumatori. Astfel, securitatea interchain poate fi văzută ca o formă de refacere; în plus, atinge un obiectiv critic: facilitarea lansării blockchain-urilor specifice aplicației în ecosistemul Cosmos.

Anterior, proiectele care încercau să creeze blockchain-uri suverane erau necesare pentru a crea un token nativ pentru miza și pentru a atrage un număr suficient de validatori pentru a oferi noii utilizatori garanții minime de siguranță. Cu toate acestea, securitatea interchain asigură securitatea Cosmos Hub (securizată cu miza de aproximativ 2,5 miliarde USD în momentul scrierii) poate fi scalată pentru a securiza lanțuri mai noi, cu valoare redusă, fără a fi nevoie să extindeți dimensiunea setului de validatori existent al Cosmo.

Notă : versiunea actuală a Cosmos's Interchain Security dezactivează tăierea pe baza exclusivă a pachetelor transmise de lanțurile de consumatori din cauza riscului ca codul rău intenționat pe un lanț de consumatori să declanșeze transmiterea de pachete false și să reducă validatorii cinstiți – în schimb infracțiuni precum votul dublu (semnarea a două blocuri la aceeași înălțime) sunt supuse tăierii sociale prin guvernare. Cu toate acestea, reducerea socială vine cu propriile riscuri, așa cum s-a văzut în recenta dezbatere privind reducerea validatorilor pentru semnarea dublă pe un lanț de consumatori (care sugerează, de asemenea, unele dintre complexitățile elaborării protocoalelor de securitate partajate) .

Securitatea mesh este o alternativă la securitatea interchain și încearcă să îmbunătățească unele dintre deficiențele acestuia din urmă. În loc să ruleze software atât pentru lanțul de furnizori, cât și pentru lanțurile de consumatori, un validator mizat pe lanțul de furnizori poate delega miza unui validator din lanțul de consumatori. Acest lucru ridică sarcina validării a două lanțuri simultan - participarea la guvernare și consens - și reduce cheltuielile generale pentru validatorii repetate (de exemplu, reducerea cerințelor hardware).

La fel ca EigenLayer (unde un validator Ethereum poate solicita unui operator să valideze unul sau mai multe protocoale secundare (AVS) în numele său), un validator delegat nu este obligat să pună nicio miză care validează lanțul de consumatori. Dacă validatorul delegat nu își îndeplinește sarcinile în mod corect (de exemplu, suferă de un timp de nefuncționare sau creează/votează pentru blocuri invalide), delegatul este tăiat în lanțul de consumatori conform regulilor protocolului.

Securitatea prin rețea este, de asemenea, diferită de securitatea interchain, deoarece permite lanțurilor de consumatori să închirieze securitatea de la mai multe lanțuri de furnizori (în loc să fie limitată la Cosmos Hub) și permite validatorilor să aleagă la ce lanțuri să delege miza. În timp ce ultima caracteristică este planificată ca parte a lansării ICS v2, este puțin probabil ca prima să fie implementată (deși este, probabil, mai convingătoare).

Comitetul de sincronizare al Ethereum

Comitetul de sincronizare al Ethereum este un grup de 512 validatori responsabili de semnarea antetelor blocurilor Beacon finalizate. Un nou Comitet de sincronizare este reconstituit la fiecare 256 de epoci (aproximativ 27 de ore), cu membri selectați din setul de validatori existent al Beacon Chain. Rețineți că membrii sunt așteptați să continue sarcinile regulate de validator (inclusiv propuneri de atestare și blocare) în timp ce participă la Comitetul de sincronizare.

Comitetul de sincronizare a fost implementat pentru prima dată în timpul bifurcării Altair a Beacon Chain pentru a permite clienților ușoare să verifice blocuri noi (fără a cunoaște setul complet de validatori) și să urmărească modificările din starea Ethereum. Deoarece participarea la Comitetul de sincronizare necesită mai mult efort decât simpla participare la consensul Beacon Chain, membrii primesc o mică recompensă (în plus față de recompensele obișnuite pentru îndeplinirea sarcinilor Beacon Chain).

Cu toate acestea, membrii care semnează antetele blocurilor nevalide nu sunt supuși tăierii, spre deosebire de Beacon Chain. Dezvoltatorii de bază ai Ethereum au apărat acest design spunând că tăierea membrilor comitetului de sincronizare rău intenționați ar introduce mai multă complexitate, în timp ce alții au sugerat dificultatea coluziei dintre ⅔ supermajoritate a membrilor comitetului de sincronizare (ce ar fi nevoie pentru a păcăli clienții ușoare să accepte un rău). antetul blocului).

Dar cu aplicațiile de mare valoare, cum ar fi protocoalele de comunicare încrucișată, care se bazează pe clienți ușoare pentru a urmări starea Ethereum, subiectul reducerii comitetelor de sincronizare pentru semnarea antetelor de bloc invalide a atras un interes reînnoit (consultați o propunere în curs de desfășurare a echipei de clienți Nimbus ). Dacă va fi implementată, reducerea ar transforma participarea la Comitetul de sincronizare într-o formă de reluare prin care validatorii optează pentru condiții suplimentare de reducere și primesc recompense suplimentare pentru serviciul secundar de semnare a antetelor blocurilor.

Pentru a exemplifica, un validator ar putea fi tăiat – până la echilibrul maxim – dacă încalcă regulile protocolului în timp ce se află în Comitetul de sincronizare, chiar dacă acționează cinstit în timp ce participă la consensul Beacon Chain. Putem compara, de asemenea, Comitetul de sincronizare cu sistemul paralanț al lui Polkadot și alte forme de securitate partajată care eșantionează aleatoriu un subset de noduri pentru a valida un subprotocol în cadrul rețelei blockchain mai mare (de exemplu, Comitetele de stat Lagrange, Subrețelele Avalanche și protocolul State Proofs de la Algorand) .

Punct de control

Schemele de securitate partajate bazate pe puncte de control implică adesea un lanț consumator de securitate care postează angajamente criptografice la cea mai recentă stare pentru lanțul de furnizare de securitate la intervale. De exemplu, unui propunetor de bloc i se poate cere să posteze hash-ul celui mai nou antet de bloc în lanțul părinte înainte ca acesta să fie finalizat.

Aceste angajamente sunt descrise ca „puncte de control” deoarece lanțul părinte garantează ireversibilitatea istoricului lanțului copil care a condus la acel punct. Cu alte cuvinte, lanțul părinte garantează și impune o ordonare în timp (canonică) a lanțului copil, protejându-l împotriva încercărilor de a reorganiza blocurile și de a crea o furcă conflictuală (de exemplu, pentru a reveni la tranzacții vechi și a efectua o cheltuială dublă) .

Lanțul părinte poate garanta, de asemenea, valabilitatea lanțului copil, în special în cazul în care anteturile blocurilor au informații despre cine a atestat/produs un anumit bloc. Dacă un bloc se dovedește a fi invalid, un nod onest poate începe o provocare pe lanțul părinte (cu lanțul părinte arbitrând disputa) și poate declanșa o derulare a stării lanțului copil.

De asemenea, dacă un mecanism de gestionare a mizei validatorului (cum ar fi un contract inteligent) este implementat în lanțul părinte, devine posibil să se impună siguranța responsabilă prin reducerea validatorilor care încalcă protocolul după ce o dovadă validă de fraudă este acceptată în lanț. Faptul că lanțul părinte garantează istoria canonică a lanțului copil este important aici, deoarece împiedică nodurile să rescrie istoricul (prin eliminarea blocurilor) pentru a ascunde dovezile unui comportament rău intenționat.

Commit sidechains (Polygon PoS), optimiums (Arbitrum Nova/Metis), rollup-uri și lanțuri integrate cu protocoale de checkpointing precum Babylon implementează această formă de securitate partajată. În toate cazurile, un protocol își derivă securitatea economică dintr-un lanț blockchain extern, folosindu-l ca nivel de decontare (responsabil pentru finalizarea blocurilor). Pentru context, Polygon PoS și Arbitrum Nova/Metis stochează anteturi într-un contract în lanț pe Ethereum, în timp ce Babylon transmite anteturi din zonele Cosmos conectate către Bitcoin.

Rollup-urile Layer 2 (L2) utilizează un mecanism similar (postarea rădăcinilor blocurilor în blockchain-ul Layer 1), cu o diferență crucială: datele necesare pentru a recrea blocurile unui pachet sunt de asemenea publicate pe stratul de decontare. Aceasta înseamnă că stratul de decontare garantează pe deplin securitatea pachetului (eventual). În schimb, datele necesare pentru a reconstrui starea unui lanț lateral de comitere sau a unui lanț optimist pot fi indisponibile, în special în cazul unui sequencer rău intenționat sau al unui set de validatori care efectuează atacuri de reținere a datelor.

Securitate partajată pentru protocoalele de interoperabilitate încrucișată

După ce am oferit un fundal extins cu privire la semnificația și evoluția securității partajate, acum putem să ne aprofundăm în noi frontiere în proiectele de securitate partajată. Un astfel de domeniu de cercetare este securitatea partajată pentru protocoalele cross-chain , care urmărește să îmbunătățească abordările actuale ale mesageriei și a legăturii între blockchain-uri prin valorificarea beneficiilor securității (economice) comune.

Această definiție poate aduce întrebări în mintea cititorului, cum ar fi:

• De ce accentul explicit pe protocoalele de interoperabilitate?

• Ce beneficii are un protocol de interoperabilitate din integrarea cu tehnologia de securitate partajată?

  
  

Lagrange Labs construiește Comitete de stat Lagrange — o soluție de securitate partajată pentru protocoale care necesită acces la dovezi minime de încredere ale statelor încrucișate. (Comitetele de stat combină sistemul de verificare ZK Big Data de la Lagrange și infrastructura de refacere a lui EigenLayer pentru a crea o zonă de securitate comună pentru protocoalele de interoperabilitate între lanțuri.) Ca atare, ne simțim obligați să disecăm fiecare dintre întrebările anterioare și, în acest proces, să facem ca caz pentru integrarea aplicațiilor de conectare, indexare și mesagerie cu infrastructura Comitetului de stat.

Un scurt introductiv asupra protocoalelor de interoperabilitate

În Interoperability For Modular Blockchains: The Lagrange Thesis , am explicat că protocoalele de interoperabilitate sunt esențiale pentru conectarea blockchain-urilor izolate și atenuarea problemelor legate de fragmentarea lichidității și a stării pentru aplicațiile blockchain (și utilizatorii acestora). Câteva exemple cheie menționate în acel articol includ:

• Poduri care implementează mecanisme de blocare sau de ardere și permit transferul unui activ dintr-un blockchain nativ (unde a fost emis) pentru utilizare pe un blockchain non-nativ

• Protocoale de mesagerie care permit utilizatorilor să transmită în siguranță informații (prin pachete de date) între blockchain-uri care nu împărtășesc o singură sursă de adevăr și nu pot verifica reciproc stările celuilalt

  
  

De asemenea, am evidențiat valoarea diferitelor tipuri de soluții de interoperabilitate blockchain . De exemplu, punțile permit utilizatorilor să se deplaseze fără probleme între diferite ecosisteme, să obțină expunerea la mai multe aplicații și să mărească eficiența activelor (prin profit de oportunitățile de generare de randament care există pe alte blockchain-uri). Protocoalele de mesagerie deblochează, de asemenea, cazuri de utilizare mai avansate, cum ar fi creditarea în lanțuri încrucișate, arbitrajul în lanțuri încrucișate și marjarea în lanțuri încrucișate și încrucișate care se bazează pe transferul de informații (de exemplu, poziții și profiluri de datorie) între diferite domenii.

Deși concepute pentru scopuri diferite, toate soluțiile de interoperabilitate diferite împărtășesc unele proprietăți de bază. Cel mai important este un mecanism pentru verificarea faptului că unele informații despre blockchain(ele) implicate într-o tranzacție/operație cross-chain - furnizate de utilizator sau de o aplicație - sunt adevărate. Aceasta este de obicei o afirmație că există o anumită stare (de exemplu, valorile stocate în stocarea unui contract inteligent, soldul unui cont sau cel mai recent bloc finalizat) sau că o tranzacție a avut loc pe un alt lanț.

Luați exemplul unei punți între Ethereum și NEAR; operatorul podului va trebui să valideze următoarele informații despre starea fiecărui lanț atunci când un utilizator realizează o legătură cu un activ (de exemplu, DAI):

• Înainte de a bate jetoane nearDAI la adresa NEAR a utilizatorului, operatorul podului are nevoie de dovada că respectivul utilizator a depus DAI în contractul podului pe Ethereum
• Înainte de a elibera depozitul DAI inițial (atunci când face legătura de la NEAR la Ethereum), operatorul podului are nevoie de dovada că respectivul utilizator a ars jetoane nearDAI pe NEAR și a trimis chitanța necesară „dovada arderii” la contractul podului pe NEAR

Un protocol de mesagerie între lanțurile menționate mai sus va avea cerințe similare, dar ușor diferite. Dacă un utilizator Ethereum solicită executarea unei tranzacții încrucișate („call X contract on NEAR”), protocolul trebuie să verifice dacă cererea de mesaj a fost plasată inițial pe Ethereum (de obicei prin apelarea unui contract on-chain).

O modalitate simplă de a valida afirmațiile despre tranzacțiile încrucișate este de a rula un nod complet pentru lanțul în cauză. Nodurile complete care descarcă tranzacțiile din fiecare bloc și reexecută înainte de sincronizarea celei mai recente stări a lanțului sunt de obicei cea mai fără încredere modalitate de a verifica tranzițiile de stare pe orice blockchain. Cu toate acestea, rularea unui nod complet este atât grea, cât și inutilă; anevoios, deoarece nodurile complete necesită cerințe hardware ridicate și inutil deoarece un protocol cross-chain are nevoie doar de informații relevante pentru anumite seturi de tranzacții și contracte.

Din fericire, clienții ușoare oferă o modalitate ușoară/eficientă de a urmări evenimentele și schimbările de stare fără a necesita rularea unui nod complet. Cu condiția să avem încredere în designul clientului ușor, putem descărca pur și simplu anteturi de bloc pentru a verifica informații specifice, cum ar fi apariția depunerilor/retragerilor într-o punte și starea solicitărilor/execuției mesajelor într-un protocol de mesagerie.

Pentru a permite comunicarea între două lanțuri - pe care le vom numi lanțul A și lanțul B - un protocol de interoperabilitate ar rula un client ușor al lanțului A pe lanțul B care stochează anteturile de bloc ale lanțului B (și invers). Acest lucru îi permite să verifice diferite dovezi de stare/stocare (anteturi de bloc, dovezi Merkle etc.) transmise de utilizatori (sau orice terță parte) de la o aplicație din lanțul sursă la o altă aplicație din lanțul de destinație. Clientul light funcționează ca o sursă de informații (un „oracol”) despre stările celor două blockchain, așa cum este ilustrat în imaginea de mai jos:

Cu toate acestea, această abordare a verificării validității statelor încrucișate se confruntă cu problema încrederii. Articolul lui Vitalik Buterin Modele de încredere oferă o definiție concisă a încrederii: „ Încrederea este utilizarea oricăror presupuneri despre comportamentul altor oameni. ” Articolul definește, de asemenea, conceptul de lipsă de încredere (cu o avertizare):

Una dintre cele mai valoroase proprietăți ale multor aplicații blockchain este lipsa de încredere: capacitatea aplicației de a continua să funcționeze într-un mod așteptat, fără a fi nevoie să se bazeze pe un anumit actor pentru a se comporta într-un mod specific, chiar și atunci când interesele lor s-ar putea schimba și îi împinge să acționeze. într-un alt mod neașteptat în viitor. Aplicațiile blockchain nu sunt niciodată complet fără încredere, dar unele aplicații sunt mult mai aproape de a nu avea încredere decât altele. — Vitalik Buterin

În contextul nostru (interoperabilitate blockchain), încrederea devine inevitabilă atunci când starea a două sau mai multe lanțuri sunt validate independent unul de celălalt. Luați în considerare un scenariu în care aplicația lui Bob pe lanțul A primește o dovadă că Alice a inițiat un mesaj („blocați 5 ETH pe lanțul B și menționați 5 Wrapped ETH (WETH) pe lanțul A”). Dovada mesajului este o dovadă Merkle care arată includerea tranzacției lui Alice într-un bloc, pe care Bob - pentru că conduce un client ușor în lanț pentru lanțul B - o poate verifica prin compararea dovezii cu rădăcina Merkle a tranzacțiilor derivate din antetul de un bloc B valid din lanț.

Cu toate acestea, „valid” în contextul unui bloc poate însemna diferite lucruri: (a) „Antetul blocului aparține unui bloc aprobat de majoritatea validatorilor lanțului sursă.” (b) „Antetul blocului aparține unui bloc ale cărui tranzacții sunt valide conform regulilor de valabilitate a tranzacțiilor din lanțul sursă.”

Bob poate trata numărul 1 ca o dovadă concretă a validității unui bloc, dar aceasta se bazează pe ipoteze despre validatorii din lanțul sursă:

• „ Majoritatea validatorilor din lanțul A sunt onești și nu ar aproba un bloc cu una sau mai multe tranzacții invalide. ”
• „ Majoritatea validatorilor din lanțul A sunt actori raționali din punct de vedere economic și au stimulente scăzute pentru a aproba un bloc cu tranzacții invalide. ”

Aici, este ușor de observat unde se pot strica oricare dintre aceste ipoteze (sau ambele) - de exemplu, dacă valoarea mizei < valoarea tranzacțiilor din lanțul A (de exemplu, suma care poate fi furată de pe o punte prin tranzacții frauduloase) , validatorii sunt motivați să finalizeze un bloc invalid – chiar dacă înseamnă să fie tăiați – deoarece profitul dintr-un atac depășește costurile.

În general, fiecare mecanism de verificare a stărilor încrucișate este supus ipotezelor de încredere (vom discuta câteva dintre aceste ipoteze de încredere în detaliu). Obiectivul cheie – și aceasta este o temă care se repetă în acest articol – este că dorim să minimizăm încrederea în comunicarea încrucișată la un nivel în care diferitele ipoteze de încredere nu reprezintă un risc mare de securitate pentru aplicațiile axate pe interoperabilitate.

Acesta este un obiectiv important pentru că, după cum se dovedește, atunci când construiești un protocol de interoperabilitate pentru a lega diferite blockchain-uri și o aplicație care rulează de o parte a diviziunii acceptă o afirmație falsă că un eveniment arbitrar s-a întâmplat pe de altă parte, lucruri rele - lucruri foarte rele — se pot întâmpla. Pentru a exemplifica, exploatările bridge s-au întâmplat deoarece o eroare le-a permis hackerilor pricepuți să trimită cu succes dovezi (false) ale solicitărilor de mesaje inexistente și jetoane pe un lanț de destinație fără a depune garanții pe lanțul sursă.

Analizarea mecanismelor de securitate cross-chain existente

De atunci, designerii de protocol au venit cu soluții la problema validării informațiilor în comunicarea încrucișată; cea mai frecventă fiind utilizarea unei terțe părți pentru a verifica existența/validitatea unei tranzacții încrucișate. Rațiunea este simplă: o aplicație pe lanțul A ar putea fi în imposibilitatea de a verifica starea lanțului B, dar o putem pune să verifice că un grup de oameni (în care avem încredere sau în care ne așteptăm să fim sinceri printr-un mecanism) au validat o parte din informații (sau revendicare) care fac referire la starea lanțului B.

Aceasta se numește „verificare externă”, deoarece o altă parte externă blockchain-ului acționează ca o sursă de adevăr pentru evenimentele din lanț și (de obicei) implică unul sau mai mulți verificatori care execută semnături pe anteturile blocurilor din lanțul sursă. Odată ce aplicația de pe lanțul de destinație primește acest antet semnat, poate verifica apoi diferite dovezi de stat furnizate de un utilizator (solduri, evenimente, depuneri/retrageri etc.) împotriva acestuia.

Pentru a stabili un anumit nivel de toleranță la erori, unele protocoale de interoperabilitate folosesc o schemă de semnare de prag care necesită un număr minim de chei private pentru a executa o semnătură pentru valabilitate (portofele cu semnătură multiplă și portofele multipartite (MPC) sunt exemple comune). Dar a avea o pluralitate ( k din n ) sau a verificatorilor care atestă stări încrucișate nu este tocmai un glonț de argint pentru securitate, în special pentru seturi mici de verificatori.

De exemplu, cineva ar putea compromite doar destui semnatari într-o schemă multisig și ar putea proceda la autorizarea retragerilor frauduloase dintr-un pod cross-chain. O configurare MPC este puțin mai sigură (pragul de aprobare poate fi schimbat și partajările de chei pot fi rotite mai frecvent), dar este încă susceptibilă la atacuri (mai ales în cazurile în care o parte controlează majoritatea partajărilor de chei).

Miza

O modalitate de a reduce ipotezele de încredere pentru protocoalele de interoperabilitate și de a spori siguranța comunicării încrucișate este ca verificatorii externi să mizeze garanția ca garanție înainte de a-și asuma sarcinile de verificare. Stakingul creează securitate pentru sistemele verificate extern, mai ales că garanția legată poate fi redusă dacă un nod de verificare execută o semnătură pe un antet de bloc nevalid sau aprobă o tranzacție încrucișată nevalidă).

Dar chiar și această abordare vine cu probleme, în funcție de dacă staking-ul este permis sau fără permisiune. Un sistem autorizat (în care validatorii trebuie să fie înscriși pe lista albă) este adesea limitat la câteva entități pre-aprobate și este mai ușor de dezvoltat — nu este nevoie să investiți într-un proiect extins de stimulente, mai ales acolo unde validatorii sunt cunoscuți public și sunt motivați să acționeze cinstit pentru a-și păstra reputaţie. De asemenea, este eficientă, deoarece comunicarea – necesară pentru a ajunge la un consens – are loc între puține părți care se cunosc deja.

Desigur, a avea un sistem autorizat cu participanți identificabili deschide ușa pentru atacuri adverse; de exemplu, un atacator poate uzurpa identitatea sau poate mitui cu succes unii dintre acești validatori și, prin urmare, își poate asuma controlul majoritar. Mai rău, un sistem Proof of Authority (PoA) în care validatorii nu sunt de fapt mizați (și sunt pur și simplu numiți) reduce costul atacării sistemului la zero (atacatorii pot pur și simplu compromite validatorii PoA prin scheme de inginerie socială și deturnează sistemul, de exemplu) .

Un sistem de miză fără permisiune crește costul coruperii unui sistem, permițând oricărei părți interesate (cu suma potrivită de capital) să înceapă validarea operațiunilor încrucișate. Dacă este combinat cu un protocol de consens care necesită ≥ ⅔ majoritate pentru a atesta blocarea anteturilor, costul coruperii sistemului ar fi efectiv egal cu suma minimă necesară pentru a corupe majoritatea verificatorilor din sistem. În plus, utilizatorii au mai puține ipoteze de încredere (validatorii pot fi tăiați), iar un set dinamic de verificatori crește dificultatea de a compromite anumite noduri prin tehnici precum ingineria socială.

Ce ar putea merge prost? Multe, de fapt. Pentru început, valoarea mizei care asigură sistemul trebuie să fie egală sau mai mare decât valoarea totală a activelor expuse riscului în cazul în care are loc un incident de securitate (degradând siguranța sau vitalitatea protocolului de interoperabilitate). Dacă inversul este adevărat ( miza totală care securizează sistemul < valoarea totală la risc ), atunci chiar și amenințarea de tăiere devine ineficientă pentru garantarea securității, deoarece profitul din coruperea sistemului depășește costul coruperii acestuia.

În plus, încercarea de a implementa proprietatea de securitate menționată mai sus ar necesita probabil stabilirea unor cerințe mai mari de miză pentru potențialii validatori. Aceasta, la rândul său, introduce problema ineficienței capitalului, deoarece securitatea se bazează pe nodurile validatoare care fac două lucruri:

• Depunând o mulțime de bani în avans (ca miză) înainte de a participa la sarcinile de validare

• Lăsarea banilor neutilizați pentru o perioadă lungă de timp (pentru siguranță, protocoalele PoS impun întârzieri îndelungate la retrageri – unele până la săptămâni sau luni – pentru a preveni cazurile marginale în care un validator comite o infracțiune care poate fi redusă și încearcă să se retragă imediat pentru a evita pierderea fondurilor din cauza tăierii). )

  
  

Un alt lucru pe care nu l-am menționat este povara dezvoltatorilor care acum trebuie să raționeze cu privire la stimulentele criptoeconomice pentru a descuraja comportamentul necinstit și pentru a proiecta funcționalități complexe de miză pentru simbolul protocolului. Pe lângă faptul că elimină atenția de la activități mai importante, cum ar fi dezvoltarea de produse și implicarea comunității, se adaugă, de asemenea, la complexitatea și suprasolicitarea cognitivă a ciclului de dezvoltare pentru echipele care construiesc infrastructura de interoperabilitate.

Verificare optimistă

„Verificarea optimistă” este o altă abordare a problemei securității încrucișate: în loc să cerem unei părți sau unui grup de încredere să ateste starea încrucișată, permitem oricui să o facă. În mod esențial, partea care face pretenții cu privire la stările încrucișate la o aplicație de interoperabilitate client (denumită de obicei „relayer”) nu este obligată să furnizeze dovada că starea atestată este validă. Acest lucru vine din ipoteza „optimistă” conform căreia releerii vor acționa cinstit și vor face doar afirmații valide despre stările încrucișate.

Dar, desigur, ne așteptăm pe deplin ca unul sau două (sau mai multe) relee să devină necinstite, motiv pentru care sistemele verificate în mod optimist necesită ca releele să posteze o mică obligație înainte de a trimite dovezile de stat. Execuția tranzacțiilor – cele care fac referire la stările încrucișate raportate de un retransmisor – este, de asemenea, întârziată pentru a oferi oricui urmărește sistemul suficient timp pentru a contesta revendicările nevalide în perioada de contestare . Dacă cererea unui releu se dovedește a fi nevalidă, obligațiunea depusă este tăiată - o parte din ea fiind îndreptată către contestator.

Verificarea optimistă transformă problema de a avea încredere într-o pluralitate ( k din n ) sau majoritate ( m din n ) de verificatori în problema de a avea încredere într-un verificator ( 1 din n ) pentru a acționa cinstit. Pentru ca protocoalele verificate optimist să rămână sigure, este suficient să existe un actor care are suficiente date de stat pentru a reexecuta tranzacțiile și pentru a crea dovezi de fraudă pentru a contesta tranzacțiile frauduloase în perioada de întârziere (de unde ipoteza de securitate 1 of n ).

Acest lucru reduce cheltuielile generale, deoarece sistemul poate funcționa corect cu un singur releu (deși este posibil să avem nevoie de două sau mai multe pentru a ne asigura de viață). De asemenea, reduce cantitatea de miză necesară pentru securitate și încurajează stabilirea unui timp mai rapid de dezlegare a mizei (garanția legată poate fi retrasă odată ce perioada de întârziere a expirat).

În plus, protocoalele de interoperabilitate bazate pe verificare optimistă sunt descrise ca „moștenind securitatea blockchain-ului de bază”; acest lucru se bazează pe ideea că, dacă blockchain-ul de bază este activ și nu cenzurează dovezile de fraudă, un releu rău intenționat nu poate scăpa cu un comportament necinstit. Mai mult, atacarea protocolului ar necesita atacarea blockchain-ului în sine, deoarece cenzura tranzacțiilor pentru o perioadă prelungită necesită controlul majorității nodurilor – și, prin extensie, a puterii de miză/exploatare – în rețea.

Dar chiar și verificarea optimistă are dezavantaje unice. De exemplu, impunerea unei întârzieri la finalizarea și execuția tranzacțiilor de legătură sau a solicitărilor de mesaje crește latența și degradează experiența generală a utilizatorului. Acest tip de securitate încrucișată are, de asemenea, mai multe „obstacole” subtile cu implicații pentru securitate, cum ar fi posibilitatea ca o parte rău intenționată să provoace tranzacții valide pentru a „îndurera” relaerii cinstiți și a executa un tip de atac DDoS.

Deoarece dovezile de fraudă sunt (în cea mai mare parte) interactive prin natură, o provocare nevalidă ar duce la risipa de resurse de către relatorii cinstiți, inclusiv de fonduri cheltuite pentru taxele de gaz pentru tranzacțiile în lanț. În consecință, releerii cinstiți pot pierde stimulentele de a transmite informații în lanț încrucișat, lăsând potențial o oportunitate pentru releerii necinstiți de a transmite informații în lanț încrucișat. Solicitarea solicitanților să posteze o depunere minimă ar putea descuraja durerea, dar o depunere minimă ridicată ar putea descuraja observatorii cinstiți (care nu au capital) să conteste actualizările de stat nevalide.

Unele protocoale rezolvă această problemă limitând provocările la un set de observatori autorizați, dar asta ne readuce la problema inițială de a avea un set mic de participanți (de încredere) pentru a securiza un sistem. Această abordare poate produce, de asemenea, câteva consecințe neintenționate, cum ar fi reducerea barierei de coluziune între nodurile observatoare și îmbunătățirea șanselor atacatorului de a corupe majoritatea nodurilor care urmăresc sistemul.

Verificare criptografică

Abordarea finală a securizării protocoalelor de interoperabilitate încrucișată pe care o vom lua în considerare vine din domeniul dovezilor criptografice. Ideea este simplă: în loc să avem încredere în oameni pentru a verifica stările încrucișate (pe care secțiunile anterioare s-au dovedit a fi periculoase în anumite cazuri), putem folosi în schimb mecanisme de verificare criptografică - reducând ipotezele de încredere la minimum.

Aici, unul sau mai mulți actori generează dovezi SNARK (Succinct Non-Interactive Argument of Knowledge) ale stării (valide) a unui lanț pentru a fi utilizate în cadrul unei aplicații de interoperabilitate. Aceste dovezi sunt verificabile : putem lua o dovadă criptografică a unei stări încrucișate, cum ar fi una derivată dintr-un antet de bloc și să confirmăm validitatea acesteia. Ele sunt, de asemenea, non-interactive : o dovadă generată de o singură parte poate fi verificată de n părți diferite fără ca nimeni să comunice (spre deosebire de dovezile interactive de fraudă). Protocoalele de interoperabilitate concepute astfel au adesea ipotezele cele mai scăzute de încredere, în măsura în care sistemul de dovezi de bază este solid (adică, un adversar nu poate crea dovezi valide pentru revendicările invalide, cu excepția unei probabilități neglijabile).

Astfel de protocoale sunt, de asemenea, diferite de sistemele verificate extern, în special în cazul în care dovezile criptografice verifică dacă fiecare bloc este corect în conformitate cu protocolul de consens al unui lanț. Ca atare, un adversar ar trebui să controleze o supermajoritate din setul de validatori al lanțului sursă - necesar pentru a finaliza blocurile invalide - pentru a corupe un protocol de interoperabilitate folosind dovezi criptografice ale stării încrucișate.

De asemenea, este ușor de observat cum această abordare elimină unele dintre dezavantajele asociate cu unele mecanisme de securitate încrucișate discutate anterior:

1. Zero ineficiență a capitalului : utilizarea zkSNARK-urilor pentru a verifica stările încrucișate elimină necesitatea unui mecanism de staking/legare și ineficiența asociată de a supune token-urile unei perioade de blocare. În mod similar, nu trebuie să posteze o garanție (spre deosebire de verificarea optimistă) înainte de a face afirmații cu privire la tranzacțiile încrucișate, deoarece dovada însoțitoare verifică succint cererea.
2. Latență scăzută : Fără a fi necesară implementarea unei perioade de întârziere - pentru a permite dovezi de fraudă în timp util - un protocol de interoperabilitate poate executa un mesaj încrucișat sau o operațiune de legătură odată ce o dovadă SNARK care o securizează este verificată. Acestea fiind spuse, generarea dovezilor este de obicei intensivă în calcul, astfel încât un sistem verificat extern poate fi mai eficient în comparație cu un protocol de interoperabilitate bazat pe SNARK.

Atunci când se evaluează securitatea unei soluții de interoperabilitate „verificată criptografic”, este important să se analizeze îndeaproape ce informații despre statele încrucișate sunt de fapt dovedite și verificate. Dovezile cu cunoștințe zero au devenit un cuvânt de moda de care s-au agățat multe protocoale pentru a înfunda ipotezele reale de încredere care stau la baza protocoalelor lor.

De exemplu, deoarece verificarea tuturor semnăturilor din setul de validatori Ethereum ( peste 925.000 de validatori pe cifrele curente ) într-un circuit zkSNARK poate fi costisitoare, unele protocoale au adoptat istoric și alte mijloace de a obține dovezi ale stării Ethereum. Un exemplu este un pod „ Ethereum to X ” (unde X poate fi orice blockchain) care generează o dovadă că antetele blocurilor au fost semnate de majoritatea Comitetului de sincronizare al Ethereum (pe care l-am introdus mai devreme).

Aceasta este o abordare mai fezabilă (comparativ cu verificarea cheilor publice ale miilor de validatori care au atestat un bloc). Dar, după cum s-a explicat mai devreme, validatorii din Comitetul de sincronizare nu sunt tăiați pentru semnarea antetelor de bloc incorecte - lăsând o probabilitate deloc neglijabilă ca majoritatea membrilor comitetului de sincronizare să se poată înțelege sau să fie mituiți pentru a înșela clienții ușoare și pentru a pune efectiv în pericol securitatea podurilor. /protocoale de mesaje care se bazează pe Comitetul de sincronizare pentru informații.

Mai mult decât atât, așa cum se explică în articolul original de introducere a Comitetelor de stat Lagrange , am explicat că, într-o lume ideală în care comitetele de sincronizare rău intenționate ar putea fi tăiate, securitatea economică ar fi limitată la suma maximă care poate fi redusă. Iată câteva fragmente din acea postare pentru context:

Securitatea punților de clienți ușoare, a podurilor ZK și a dovezilor comitetului de sincronizare se bazează toate pe verificarea semnăturilor de la comitetul de sincronizare a clientului de lumină Ethereum. Deoarece dimensiunea comitetului de sincronizare este fixă, securitatea economică care îl sprijină este, de asemenea, limitată la o fereastră de 27 de ore. Odată ce reducerea este implementată în cele din urmă pentru comitetele de sincronizare Ethereum, securitatea economică va fi limitată după cum urmează:

• Securitatea economică a Comitetului de sincronizare = 512 noduri * 32 Eth * 1650 USD/ETH = 27.033.600 USD
• Pragul de compromitere a Comitetului de sincronizare = 27.033.600 USD * 2/3 = 18.022.400 USD

În timp ce podurile pentru clienți ușoare și podurile pentru clienți ușoare ZK sunt considerate un standard de aur pentru interoperabilitatea cross-chain, cantitatea de active pe care le pot securiza cu comitete de sincronizare aleatorie este sever limitată. După cum s-a arătat anterior, cantitatea de garanții pe care nodurile de coluziune ar trebui să o ardă pentru a compromite simultan toate podurile clientului light Ethereum și ZK este plafonată la 18 milioane USD.

Luați în considerare o situație în care suma valorii tuturor activelor securizate de toate podurile clienților lumini și clienților lumini ZK este de o sumă k. Când k < 18 milioane USD, toate activele securizate peste poduri sunt în siguranță, deoarece un atac nu este viabil din punct de vedere economic. Pe măsură ce k crește astfel încât k > 27 milioane USD, devine profitabil pentru un grup de actori răi din comitetul de sincronizare să ateste blocurile rău intenționate pentru a compromite activele securizate.

Vă încurajăm să citiți întregul articol, în special secțiunea despre limitările punților de clienți ușoare ale Ethereum , pentru mai mult context cu privire la problemele legate de bazarea pe comitetele de sincronizare randomizate pentru a obține dovezi ale stărilor încrucișate. De asemenea, vă sugerăm să urmați eforturile Polyhedra Network de a demonstra consensul complet Ethereum PoS într-un circuit ZK .

Comitete de stat Lagrange: Securitate partajată ca serviciu pentru protocoalele de comunicare încrucișată

Având în vedere că o mare parte a introducerii acestui articol se concentrează pe securitatea partajată, este bine să introducem o soluție de securitate partajată la care am lucrat la Lagrange Labs: Comitetele de stat Lagrange . În această secțiune, vom explora funcționarea interioară a rețelei Comitetului de stat Lagrange și vom înțelege legătura acesteia cu stiva de date mari ZK a Lagrange și scopul de a construi instrumente care să permită accesul sigur și expresiv la stat pe lanțuri și între lanțuri.

Ce sunt comitetele de stat Lagrange?

Rețeaua Lagrange State Committee (LSC) este un protocol de client light ZK simplu și eficient pentru rollup-uri optimiste (ORU) care se stabilesc pe Ethereum (de exemplu, Optimism, Arbitrum, Base și Mantle). LSC-urile sunt similare din punct de vedere conceptual cu Comitetul de sincronizare al Ethereum și acceptă aplicații ușoare bazate pe client - cum ar fi punți și straturi de mesaje interchain - care doresc să folosească o stare optimistă a acumularii fără a asuma presupuneri excesive de încredere.

Un comitet de stat Lagrange este un grup de noduri clienți care au relocat garanții în valoare de 32 ETH pe Ethereum prin EigenLayer. Cu alte cuvinte, o rețea a Comitetului de stat Lagrange este un AVS sau un serviciu validat activ . Fiecare comitet de stat Lagrange atestă finalitatea blocurilor pentru o anumită acumulare optimistă odată ce loturile de tranzacții asociate sunt finalizate pe un strat de disponibilitate a datelor (DA). Aceste atestări sunt apoi folosite pentru a genera dovezi de stare, pe care aplicațiile le pot trata ca o sursă de adevăr pentru starea respectivului pachet optimist.

În timp ce Comitetul de sincronizare al Ethereum este limitat la 512 noduri, fiecare rețea a Comitetului de stat Lagrange acceptă un set nelimitat de noduri. Acest lucru asigură că securitatea economică nu este limitată artificial și că numărul de noduri care atestă starea unui roll up optimist se poate scala, crescând astfel în mod dinamic securitatea economică din spatele dovezilor de stat Lagrange.

Cum funcționează rețeaua Comitetului de Stat Lagrange?

Două componente cheie ale protocolului Comitetului de stat Lagrange sunt nodurile secvențiale și client („nodurile client” este un alt nume pentru validatorii înregistrați la un comitet de stat Lagrange). Sequencerul este o entitate centrală responsabilă de coordonarea atestărilor într-o rețea a Comitetului de stat Lagrange și de a furniza atestări dovezorilor care produc dovezi de stat. Nodul Sequencer este de fapt o combinație de trei module cu funcții diferite: Sequencer , Consensus și Governance .

La anumite intervale de timp, modulul Sequencer solicită atestări de la nodurile client la blocuri rollup rezultate din executarea unui lot de tranzacții care au fost scrise pe un strat DA. În loc să executăm această rutină pentru fiecare bloc optimist, vom prezenta mai jos o scurtă analiză a fiecărui element din mesajul blocului:

(1). Block_header : un antet al unui bloc finalizat optimistic rollup (ORU). „Finalitate” înseamnă aici un bloc derivat de nodurile de acumulare din datele tranzacțiilor finalizate pe un anumit strat DA. De exemplu, finalitatea este definită de capul L2 sigur pentru pachetele de stivă Optimism/OP și un bloc L2 cu finalitate echivalentă Ethereum pentru lanțurile Arbitrum și Arbitrum Orbit. (Aflați mai multe despre finalitatea acumulatorului în acest articol .)

(2). current_committee : un angajament criptografic față de setul de chei publice asociate nodurilor client permise să semneze un bloc b. Se așteaptă ca un nod client să construiască un arbore Merkle, cu frunze reprezentând cheile publice ale tuturor membrilor activi ai comitetului și să semneze rădăcina arborelui Merkle cu cheia sa BLS12–381.

(3). next_committee : un angajament criptografic față de setul de chei publice asociate nodurilor permise să semneze următorul bloc (b+1). Nodurile care doresc să părăsească un comitet de stat trebuie să depună o tranzacție la sfârșitul perioadei de atestare la contractul Lagrange Service pe Ethereum care se ocupă de înregistrarea și radierea operatorilor în Comitetul de stat AVS.

La sfârșitul fiecărei perioade de atestare, setul de noduri de comitet poate fi modificat dacă operatorii solicită să părăsească sau să se alăture înainte de începerea următoarei perioade de atestare. Se așteaptă ca nodurile client să construiască un arbore Merkle al next_committee prin preluarea setului curent de noduri înregistrate pentru fiecare comitet din Contractul de servicii Lagrange.

ELI5: Ce sunt dovezile de stat?

O dovadă de stare este o dovadă criptografică a stării unui blockchain: o dovadă a unui antet de bloc dintr-un lanț sursă (lanțul A), care poate fi utilizată pentru a demonstra lanțului de destinație existența unei stări pe lanțul sursă, cum ar fi un anumită tranzacție. Cu alte cuvinte, o dovadă a stării reprezintă o dovadă a stării lanțului sursă la o înălțime specificată a blocului.

Pentru a ilustra folosind un exemplu anterior: antetul blocului din lanțul sursă (lanțul A), pe care aplicația lui Bob pe lanțul de destinație (lanțul B) îl folosește pentru a verifica existența tranzacției de legătură Alice, este o dovadă de stare. Acesta reprezintă un rezumat al modificărilor aduse stării lanțului sursă între blocul anterior și blocul curent. Dacă dovada Merkle a lui Alice se verifică în raport cu rădăcina arborelui de tranzacții stocată în antetul bloc al lanțului A, Bob poate aproba cu încredere tranzacția de legătură pe lanțul B (lanțul de destinație), deoarece dovada de stare atestă executarea cererii de mesaj a Alice pe lanțul de origine.

Rețeaua Comitetului de stat Lagrange este concepută pentru a genera dovezi de stat pentru rollup-uri optimiste securizate de Ethereum. Dovezile de stat sunt generate prin agregarea semnăturilor BL12–381 pe tuplu descris mai devreme ( block_header , prev_committee și next_committee ) de la cel puțin două treimi din nodurile din comitetul de stat. Dovada stării este apoi generată de un circuit SNARK bazat pe greutatea colectivă a semnăturilor care atestă un antet de bloc dat.

Abordarea de a cere atestatorilor să se angajeze la comitetele de stat actuale și viitoare este similară cu protocolul Ethereum Sync Committee și atinge un obiectiv similar: permiterea clienților ușoare să verifice validitatea unui antet optimist de bloc rollup în mod eficient și sigur. Fiecare dovadă de stare este legată criptografic printr-o serie de angajamente next_committee care indică nodurile care ar trebui să semneze următorul bloc. Astfel, este suficient să verificăm o dovadă SNARK care dovedește următoarele proprietăți recursive în obiectul bloc semnat de nodurile de atestare:

• Cel puțin ⅔ dintre cele n noduri din comitetul de stat au semnat antetul blocului b.

• current_committee din blocul b este egal cu next_committee arborele din blocul b-1.

• Blocul b-1 este fie blocul genezei, fie este valabil în raport cu aceste trei condiții.

  
  

Protocoalele de interoperabilitate și alte aplicații care necesită o stare optimistă sigură de acumulare cu finalitate rapidă (de exemplu, punți încrucișate și protocoale de mesagerie) pot folosi dovezile de stare de la Comitetele de stat Lagrange cu presupuneri minime de încredere. Este important că rețeaua Comitetului de stat Lagrange este capabilă să garanteze securitatea dovezilor de stat prin implementarea reducerii deterministe a atestatorilor rău intenționați și a dovezilor de validitate inductive .

Cum interoperează rețeaua Comitetului de stat Lagrange cu stiva de date mari ZK?

În prima postare a seriei despre suita de produse Lagrange, am evidențiat relația dintre diferitele părți ale stivei de date mari ZK : Comitetele de stat Lagrange, Recproofs, zkMapReduce și coprocesorul Lagrange. Fiecare dintre aceste componente, atunci când sunt combinate împreună, oferă în mod colectiv acces sigur și eficient la calculul de stare și expresiv și dinamic asupra datelor de stare:

#1. Rețeaua Lagrange State Committee se integrează cu celelalte componente ale ZK Big Data Stack pentru o performanță mai bună

Folosim Recproofs și zkMapReduce pentru a crea dovezi actualizabile de cheie publică agregată (APK) pentru comitetele de stat, permițându-ne să evităm procesul costisitor și consumator de timp de dezagregare și re-agregare a cheilor publice ale nesemnatorilor ori de câte ori trebuie să fie o nouă semnătură agregată. creat creat.

Agregarea eficientă a cheilor publice BLS ale operatorilor din Comitetele de stat Lagrange AVS facilitează rate mai mari de participare la AVS fără a crește costul de calcul al verificării atestărilor de la nodurile comitetelor de stat. Acesta este motivul pentru care comitetele de stat Lagrange sunt capabile să susțină un set potențial nelimitat de noduri și să prezinte securitate superliniară pe măsură ce mai mult capital este pus în comun în comitetele de stat. Puteți afla mai multe despre această proprietate în postarea noastră despre scalarea încrederii programabile pe EigenLayer cu ZK Big Data .

Integrarea comitetelor de stat Lagrange cu stiva ZK Big Data are, de asemenea, beneficii mai directe pentru aplicațiile client care folosesc dovezile de stat Lagrange. De exemplu, putem folosi caracteristica zkMapReduce a coprocesorului Lagrange pentru a combina mai multe dovezi de stare de la n lanțuri de acumulare optimiste într-o singură demonstrație de stare cu mai multe lanțuri . Acest lucru permite „verificarea imbricată”, în care o singură tranzacție în lanț verifică simultan starea mai multor pachete optimiste și reduce costurile de verificare pentru serviciile clienților.

#2: Coprocesorul Lagrange se integrează cu rețeaua Comitetului de stat Lagrange pentru a alimenta calculul fără încredere în afara lanțului

Coprocesorul Lagrange – pe care îl vom analiza pe larg într-o postare ulterioară – acceptă calcule ieftine și scalabile pe date în lanț prin efectuarea de calcule în afara lanțului. Protocoalele de interoperabilitate cross-chain care se integrează cu comitetele de stat Lagrange se pot integra și cu coprocesorul Lagrange, pentru a facilita extinderea ofertelor lor încrucișate pentru a include calcule verificabile.

De exemplu, un dezvoltator care construiește o aplicație de împrumut cu mai multe lanțuri poate dori să calculeze suma garanțiilor depuse de un utilizator în n pachete diferite. Dezvoltatorul nostru prietenos poate folosi coprocesorul Lagrange pentru a calcula această valoare, folosind orice sursă de antet bloc pe care se bazează deja protocolul cross-chain.

De ce rețeaua de comitete de stat a lui Lagrange este un schimbător de joc pentru interoperabilitate în pachete optimiste

Securitate partajată, superliniară pentru clienți optimiști

În prezent, protocoalele de interoperabilitate care susțin legătura între lanțurile de acumulare optimiste sunt responsabile în mod independent de verificarea stării lanțurilor sursă. Securitatea acestor protocoale de interoperabilitate depinde de mecanismul de verificare a faptului că antetul unui bloc este corect.

Unele protocoale de comunicare cross-chain încearcă să reducă ipotezele de încredere prin implementarea staking-ului nativ și solicitând unui set de verificatori să depună garanții înainte de a atesta blocarea anteturilor lanțurilor sursă. Cu toate acestea, acest lucru fragmentează securitatea economică în diferite protocoale încrucișate, deoarece costul coruperii unui subset ( k din n ) din setul de validator al fiecărui protocol este mai mic.

În schimb, comitetele de stat Lagrange permit mai multor protocoale încrucișate să obțină securitate dintr-un singur set dinamic de validatori care se pot scala la o dimensiune nelimitată. Acest lucru schimbă status quo-ul - în care fiecare protocol de interoperabilitate este responsabil în mod independent de verificarea acurateței stărilor cross-chain - într-unul în care mai multe aplicații pot consuma starea cross-chain dintr-o singură sursă.

Spre deosebire de alte protocoale de client ușoare, rețeaua Comitetului de stat Lagrange acceptă un set dinamic, nelimitat de noduri de atestare. Ponderea economică a semnăturilor care asigură fiecare atestare poate, prin urmare, să se extindă dinamic, pe măsură ce mai multe mize sunt puse în comun în comitetele de stat, permițând o creștere superliniară a securității și ridicând dificultatea de a ataca izolat protocoalele cross-chain integrate.

Acest lucru face efectiv din Comitetul de stat Lagrange o „zonă de securitate partajată” la care se poate conecta orice protocol încrucișat (indiferent de dimensiunea acestuia) pentru o securitate maximă – similar cu modul în care Lanțul de releu de pe Polkadot și Cosmos Hub pe rețelele secundare securizate Cosmos din ecosistem multilanț. În plus, integrarea cu middleware-ul EigenLayer permite rețelei Comitetului de Stat Lagrange să extindă securitatea economică a Ethereum pentru a securiza un număr arbitrar de protocoale de comunicație cross-chain în aval.

Reducerea cheltuielilor generale pentru echipele de dezvoltare a produselor încrucișate

Un dezvoltator care construiește astăzi un protocol de interoperabilitate încrucișată trebuie să dezvolte infrastructura pentru a rula în mod independent observatorii pentru a verifica starea fiecărui pachet optimist pe care îl acceptă. Pe măsură ce numărul de pachete optimiste integrate crește, costul general al infrastructurii de gestionare a securității în fiecare lanț de origine crește.

Integrarea cu Comitetul de stat Lagrange permite dezvoltatorului să-și externalizeze securitatea și, în schimb, să concentreze resursele pe optimizarea caracteristicilor produsului. Pentru a pune acest lucru în context: Fiecare dovadă de stare Lagrange este suficient de ușoară pentru a fi verificată eficient pe orice lanț compatibil EVM.

Securitate suplimentară pentru protocoalele de interoperabilitate existente

Dovezile de stare Lagrange sunt agnostice față de stratul de transport utilizat pentru a le transporta către unul sau mai multe lanțuri de destinație, permițând aplicațiilor de interoperabilitate să stivuească fără probleme dovezile de stare Lagrange cu mecanismele de securitate existente. De exemplu, un oracol încrucișat sau un protocol de mesagerie încrucișat cu un set de verificator independent poate verifica o dovadă a stării Lagrange ca măsură de securitate suplimentară înainte de a transmite solicitările de mesaje încrucișate din pachetele optimiste.

Mai mult, un protocol de interoperabilitate existent – odată integrat cu rețeaua Comitetului de stat Lagrange – poate adăuga suport pentru rollup-uri optimiste, fără a necesita validatori să mărească numărul de lanțuri pe care le monitorizează. Folosind dovezile de stat din rețeaua Comitetului de stat Lagrange, validatorii trebuie să transmită doar solicitările de mesaje între pachete. Un contract de gateway pe lanțul de destinație poate valida apoi existența mesajelor transmise de releere prin verificarea unei dovezi a stării Lagrange.

Cum se compară rețeaua Comitetului de stat Lagrange cu alte mecanisme de securitate încrucișate?

Comitetele de stat Lagrange se compară favorabil cu infrastructura de interoperabilitate existentă care utilizează staking/slashing legat, validare autorizată și mecanisme optimiste de verificare (printre altele) pentru a spori securitatea dovezilor de stat încrucișate. Mai jos sunt câteva comparații:

Verificare externă de către validatori fără permisiune

Modelul de restaking al lui Lagrange atenuează o problemă cheie în mecanismele de securitate cross-chain care implementează staking pur PoS pentru securitate: stivuirea riscurilor . Luați, de exemplu, un protocol încrucișat care solicită validatorilor să cumpere și să blocheze tokenul nativ al unui protocol pentru perioada de legare. Pe măsură ce popularitatea simbolului nativ al protocolului cross-chain se modifică, volatilitatea prețului activului afectează securitatea economică totală a rețelei.

Volatilitatea prețurilor este mai puțin o problemă pentru rețeaua Comitetului de stat Lagrange, deoarece securitatea nodurilor comitetului se bazează pe garanția restabilită prin EigenLayer. În plus, garanția reformulată a redus costurile de oportunitate pentru potențialii validatori, ceea ce înseamnă mai multă participare la comitetele de stat și un nivel mai ridicat de securitate economică pentru protocoalele de interoperabilitate. Pentru utilizatori, acest lucru înseamnă taxe mai mici și mai multă securitate în comparație cu protocoalele de interoperabilitate care le pornesc în mod independent securitatea.

De asemenea, menționăm că protocoalele de consens utilizate în Proof-of-Stake tradiționale impun limitări asupra numărului de validatori (de exemplu, Tendermint BFT limitează participarea la 100-200 de validatori) și împiedică protocoalele tradiționale PoS să crească securitatea economică ori de câte ori este necesar. În schimb, rețeaua Comitetului de stat Lagrange utilizează un mecanism de atestare care sprijină un set potențial nelimitat de noduri care participă la consens. Acest lucru asigură că rețeaua poate crește în mod dinamic numărul de atestatori și, prin extensie, poate oferi garanții mai solide de securitate economică pentru aplicațiile client.

Verificare externă de către validatori autorizați

Protocoalele încrucișate bazate pe Proof-of-Authority (PoA) se bazează pe atestări pentru a bloca antetele unui set mic de noduri autorizate. Aceste abordări s-au dovedit istoric nesigure cu incidente de mare profil, inclusiv hack-ul Ronin (5 din 7 validatori compromis) și hack-ul Harmony One (2 din 5 validatori compromis).

Utilizarea unui sistem validat fără permisiune, cum ar fi rețeaua Comitetului de stat Lagrange, reduce oarecum eficiența în comparație cu anteturile de semnare a unui set de operator sau validator centralizat. Dar, având în vedere cantitatea de risc, considerăm că aceasta este un compromis sensibil. Sistemele validate fără permisiune reduc, de asemenea, suprafața de atac pentru companiile care, de cele mai multe ori, pot ajunge să ruleze majoritatea validatorilor într-un sistem autorizat.

Legătura canonică

Rețeaua Comitetului de stat Lagrange elimină latența trimiterii mesajelor încrucișate din pachetele optimiste. Fiecare LSC acționează ca un „mod rapid” pentru podurile și protocoalele de mesagerie ai căror utilizatori ar dori să facă legătura de la o acumulare optimistă fără a aștepta să iasă din fereastra provocării. Rollup-urile optimiste beneficiază, de asemenea, direct de proprietatea de finalitate rapidă a LSC, deoarece rezolvă un punct cheie UX pentru utilizatorii L2.

Această garanție derivă din observația că: (a) mecanismul de tăiere este conceput pentru a crește costul acțiunilor adverse și (b) tăierea nodurilor de coluziune într-un LSC poate avea loc în lanț în modul lent, deoarece există o întârziere variabilă pe retragerea mizei. În rezumat, participanții la un LSC au întotdeauna stimulentul să ateste pentru a corecta stările cross-chain - ceea ce permite aplicațiilor cross-chain să utilizeze dovezi de stare dintr-un LSC imediat și cu ipoteze minime de încredere susținute de puntea canonică a pachetului .

Concluzie

Acest articol a acoperit destul de mult teren și sperăm că citirea lui a fost educațională – dacă nu valoroasă – pentru constructori, investitori, entuziaști și utilizatori din spațiul de interoperabilitate. Pe parcursul acestui articol, am explorat definiția securității partajate, ce înseamnă aceasta pentru proiectarea protocoalelor securizate și modul în care interoperabilitatea inter-lanț poate beneficia de integrarea cu infrastructura de securitate partajată.

Am explorat, de asemenea, Comitetele de stat Lagrange: soluția noastră comună de securitate ca serviciu, concepută având în vedere protocoalele de comunicare încrucișată. Comitetele de stat Lagrange face parte din viziunea noastră de a permite interoperabilitate sigură, minimizată din punct de vedere al încrederii și eficientă și va face parte dintr-o stivă mai mare care le va permite dezvoltatorilor să creeze aplicații puternice cross-chain pentru utilizatori.

Viitorul cu mai multe lanțuri este inevitabil și este important ca utilizatorii să poată trece de la utilizarea unui lanț la 10.000 de lanțuri fără a experimenta pierderi semnificative de securitate. Soluții precum Comitetele de stat Lagrange (împreună cu alte progrese în securitatea inter-lanțului) sunt esențiale pentru acest obiectiv. Întrucât interoperabilitatea primește mai multă atenție ca niciodată, o lume în care deplasarea peste lanțuri este sigură și eficientă este foarte bine la îndemâna utilizatorilor cripto din întreaga lume.

Mulțumiri

Emmanuel Awosika ( 2077 Research ), Omar Yehia ( Lagrange Labs ), Ismael Hishon-Rezaizadeh ( Lagrange Labs ) și Amir Rezaizadeh ( Lagrange Labs ) au contribuit la acest articol. Emmanuel a fost contractat de Lagrange Labs pentru a sprijini scrierea acestui articol.

O versiune a acestui articol a fost publicată anterior aici .