原文标题：Ethereum ar trebui să fie de acord cu consacrarea mai multor lucruri în protocol?

Autor: Vitalik Buterin

Compilat de: Nian Yin Si Tang, Planet Daily

De la începutul proiectului Ethereum, a existat o filozofie puternică de a încerca să facă Ethereum-ul de bază cât mai simplu posibil și de a realiza acest lucru cât mai mult posibil prin construirea de protocoale pe deasupra. În spațiul blockchain, dezbaterea „construiți pe L1” versus „concentrați-vă pe L2” este adesea considerată ca în principal despre scalare, dar, de fapt, există probleme similare în satisfacerea nevoilor mai multor utilizatori Ethereum: schimb de active digitale, confidențialitate. , nume de utilizator, criptare avansată, securitatea contului, rezistență la cenzură, protecție avansată și multe altele. Cu toate acestea, au existat câteva încercări prudente recente de a consacra mai multe dintre aceste caracteristici în protocolul de bază Ethereum.

Acest articol va aprofunda unele dintre raționamentele filozofice din spatele filozofiei originale a încapsulării minime, precum și câteva moduri recente de a gândi despre aceste idei. Scopul va fi acela de a începe construirea unui cadru pentru a identifica mai bine obiectivele posibile în care încapsularea anumitor funcționalități ar putea fi demnă de luat în considerare.

O filozofie timpurie a minimalismului protocolar

În istoria timpurie a ceea ce era cunoscut atunci sub numele de „Ethereum 2.0”, a existat o dorință puternică de a crea un protocol curat, simplu și frumos care a încercat cât mai puțin posibil să se construiască pe el însuși și a lăsat aproape toate astfel de lucrări în seama utilizatorilor. În mod ideal, protocolul este doar o mașină virtuală, iar validarea unui bloc este doar un apel de mașină virtuală.

Aceasta este o reconstrucție aproximativă a diagramei tablei albe pe care eu și Gavin Gavin am desenat Wood la începutul anului 2015, când vorbeam despre cum ar arăta Ethereum 2.0.

„Funcția de tranziție a stării” (funcția care se ocupă de bloc) va fi doar un singur apel VM și toată logica se va întâmpla prin contracte: unele contracte la nivel de sistem, dar mai ales contracte furnizate de utilizator. O caracteristică foarte frumoasă a acestui model este că chiar și o întreagă hard fork poate fi descrisă ca o singură tranzacție la contractul cu procesorul bloc, care va fi aprobat de guvernanța în afara lanțului sau în lanț și apoi va fi actualizată permisiunea de rulare.

Aceste discuții din 2015 se aplică în mod specific la două domenii pe care le luăm în considerare: abstracția conturilor și scalarea. În cazul scalării, ideea este să încercăm să creați o formă abstractă maximă de scalare care să se simtă ca o extensie naturală a diagramei de mai sus. Contractele pot apela date care nu sunt stocate de majoritatea nodurilor Ethereum, iar protocolul va detecta acest lucru și va rezolva apelul prin intermediul unor funcționalități de calcul extinse foarte generale. Din perspectiva mașinii virtuale, apelul va intra într-un subsistem separat și apoi va returna magic răspunsul corect ceva timp mai târziu.

Am explorat pe scurt această idee, dar am abandonat-o rapid pentru că eram prea concentrați să dovedim că orice fel de scalare blockchain era posibilă. Deși, așa cum vom vedea mai târziu, combinația dintre eșantionarea disponibilității datelor și ZK-EVM înseamnă că un posibil viitor pentru scalarea Ethereum arată de fapt foarte aproape de această viziune! Cu abstractizarea contului, pe de altă parte, am știut de la început că este posibil un fel de implementare, așa că cercetările au început imediat să încerce să facă ceva cât mai aproape de punctul de plecare pur al „o tranzacție este doar un apel”.

Există o mulțime de coduri standard între procesarea tranzacției și efectuarea apelului EVM subiacent de la adresa expeditorului și mai mult cod standard după aceea. Cum reducem acest cod cât mai aproape de zero?

Unul dintre codurile principale aici este validate_transaction(state, tx), care este responsabil pentru verificarea dacă nonce și semnătura tranzacției sunt corecte. Scopul real al abstracției contului de la început a fost acela de a permite utilizatorilor să înlocuiască verificarea de bază non-incrementală și verificarea ECDSA cu propria logică de verificare, astfel încât utilizatorii să poată utiliza mai ușor funcții precum recuperarea socială și portofelele cu semnături multiple. Deci, găsirea unei modalități de a re-arhitecta apply_transaction într-un apel simplu EVM nu este doar o sarcină de „a face codul curat de dragul de a face codul curat”, ci este despre mutarea logicii în codul de cont al utilizatorului, oferiți utilizatorilor flexibilitatea pe care o au; nevoie.

Cu toate acestea, insistarea că apply_transaction să conțină cât mai puțină logică fixă ​​a ajuns să creeze o mulțime de provocări. Ne putem uita la una dintre cele mai vechi propuneri de abstractizare a conturilor, EIP-86.

Dacă EIP-86 ar fi inclus așa cum este, ar reduce complexitatea EVM cu prețul creșterii masive a complexității altor părți ale stivei Ethereum, necesitând în esență scris același cod în altă parte, pe lângă introducerea unui întreg. noua clasă de ciudățenie De exemplu, aceeași tranzacție cu aceeași valoare hash poate apărea de mai multe ori în lanț, ca să nu mai vorbim de problema invalidării multiple.

Probleme multiple de invalidare în abstracția contului. O tranzacție inclusă în lanț ar putea invalida mii de alte tranzacții în mempool, ușurând umplerea mempool-ului ieftin.

De atunci, abstractizarea contului a evoluat în etape. EIP-86 a devenit ulterior EIP-208, iar în cele din urmă practic EIP-2938.

Cu toate acestea, EIP-2938 este orice altceva decât minimalist. Conținutul său include:

  • Nou tip de tranzacție

  • Trei noi variabile globale ale domeniului tranzacției

  • Două coduri operaționale noi, inclusiv codul operațional PAYgas foarte stângaci, pentru a gestiona prețul gazului și verificările limitelor de gaz, ca puncte de întrerupere a execuției EVM și pentru a stoca temporar ETH pentru plata unică a taxelor

  • Un set complex de strategii de extragere și redifuzare, inclusiv o listă de coduri operaționale interzise în timpul fazei de verificare a tranzacției

Într-un efort de a realiza abstracția contului fără a implica dezvoltatorii de bază Ethereum (care s-au concentrat pe optimizarea clienților Ethereum și pe implementarea fuziunilor), EIP-2938 a fost în cele din urmă re-arhitectat ca ERC-4337, care a fost în întregime în afara protocolului.

ERC-4337. Se bazează în întregime pe apelurile EVM!

Deoarece acesta este un ERC, nu necesită un hard fork și din punct de vedere tehnic există „în afara protocolului Ethereum”. Deci...problema rezolvata? Se dovedește că nu este cazul. Foaia de parcurs intermediară actuală a ERC-4337 implică, în cele din urmă, tranziția unor părți mari din ERC-4337 într-o serie de caracteristici de protocol, care este un exemplu util de îndrumare cu privire la motivul pentru care această cale ar trebui luată în considerare.

Pachetul ERC-4337

Există mai multe motive cheie discutate pentru eventuala reîncorporare a ERC-4337 în protocol:

Eficiența gazului: orice operațiune efectuată în interiorul EVM implică un anumit grad de supraîncărcare a mașinii virtuale, inclusiv ineficiențe atunci când se utilizează funcții costisitoare de gaz, cum ar fi sloturile de stocare. În prezent, aceste ineficiențe suplimentare însumează cel puțin 20.000 de gaze, dacă nu mai mult. Introducerea acestor componente în protocol este cea mai simplă modalitate de a elimina aceste probleme.

Risc de eroare de cod: Dacă „contractul punctului de intrare” ERC-4337 are o eroare suficient de teribil, toate portofelele compatibile ERC-4337 ar putea vedea toate fondurile se usucă. Înlocuirea contractelor cu funcționalitate în protocol creează o obligație implicită de a remedia erorile de cod prin hard forks, eliminând astfel riscul ca utilizatorii să rămână fără fonduri.

Suportă opcodes EVM, cum ar fi txt.origin. ERC-4337 în sine determină txt.origin să returneze adresa unui „bundler” care împachetează un set de acțiuni ale utilizatorului într-o tranzacție. Abstracția contului nativ rezolvă această problemă făcându-l pe txt.origin să indice contul real care trimite tranzacția, făcându-l să se comporte la fel ca EOA.

Rezistența la cenzură: Una dintre provocările separării propunetorului/constructorului este că devine mai ușor să revizuiți tranzacțiile individuale. Într-o lume în care protocolul Ethereum poate identifica tranzacții individuale, această problemă poate fi atenuată în mare măsură prin liste de includere, care permit propunerilor să specifice o listă de tranzacții care trebuie incluse în următoarele două sloturi în aproape toate cazurile. Cu toate acestea, ERC-4337 în afara protocolului încapsulează „operațiunile utilizatorului” într-o singură tranzacție, făcând operațiunile utilizatorului opace pentru protocolul Ethereum, prin urmare, lista de includere furnizată de protocolul Ethereum nu va putea oferi rezistență la cenzură utilizatorului ERC-4337; operațiuni. Încheierea ERC-4337 și transformarea acțiunii utilizatorului într-un tip de tranzacție „corespunzător” ar rezolva această problemă.

Merită menționat faptul că, în forma sa actuală, ERC-4337 este semnificativ mai scump decât tranzacțiile „de bază” Ethereum: o tranzacție costă 21.000 de gaze, în timp ce ERC-4337 costă aproximativ 42.000 de gaze.

În teorie, ar trebui să fie posibilă ajustarea sistemului de cost al gazului EVM până când costul în protocol și costul accesării stocării în afara protocolului se potrivesc, nu există niciun motiv să fie nevoie să cheltuiți 9000 de gaz pentru a transfera ETH atunci când alte tipuri de editare de stocare; operațiunile sunt mai ieftine. De fapt, două EIP-uri legate de viitoarea transformare a arborelui Verkle încearcă de fapt să facă exact asta. Dar chiar dacă facem acest lucru, există un motiv evident pentru care, indiferent cât de eficient devine EVM, funcțiile de protocol încapsulat vor fi inevitabil mult mai ieftine decât codul EVM: codul încapsulat nu trebuie să plătească gaz pentru preîncărcare.

Un portofel ERC-4337 complet funcțional este mare, această implementare compilată și pusă în lanț ocupând aproximativ 12.800 de octeți. Desigur, puteți implementa acest cod o dată și utilizați DELEGATECALL pentru a permite fiecărui portofel să îl apeleze, dar ar trebui totuși să accesați codul în fiecare bloc în care este utilizat. În conformitate cu EIP costul de gaz al arborelui Verkle, 12.800 de octeți vor forma 413 bucăți, iar accesarea acestor bucăți va necesita plata de 2 ori mai mult decât costul branșamentului martor (un total de 3.800 de gaz) și de 413 ori mai mult decât costul porțiunii_martor (un total de 82.600 de gaz). Acest lucru nici măcar nu începe să menționeze punctul de intrare ERC-4337 în sine, care în versiunea 0.6.0 are 23.689 de octeți pe lanț (aproximativ 158.700 de gaze de încărcat conform regulilor EIP ale arborelui Verkle).

Acest lucru duce la o problemă: costul de gaz al accesării efective a acestor coduri trebuie amortizat într-un fel pentru fiecare tranzacție. Abordarea actuală folosită de ERC-4337 nu este foarte bună: prima tranzacție din pachet consumă un cost unic de stocare/citire a codului, ceea ce o face mult mai costisitoare decât alte tranzacții. Încapsularea intra-protocol va permite acestor biblioteci publice partajate să devină parte a protocolului și să fie liber accesibile pentru toată lumea.

Ce putem învăța din acest exemplu și când ar trebui practicată mai general încapsularea?

În acest exemplu, vedem câteva argumente diferite pentru încapsularea abstracțiilor conturilor în protocoale.

Abordările bazate pe piață care „împing complexitatea la margine” sunt cel mai probabil să eșueze atunci când costurile fixe sunt mari. De fapt, foaia de parcurs de abstractizare a contului pe termen lung pare să aibă o mulțime de costuri fixe pe bloc. 244.100 de gaz pentru încărcarea codului de portofel standardizat este un lucru, dar agregarea poate adăuga sute de mii de gaz pentru verificarea ZK-SNARK, precum și costul în lanț al verificării dovezilor. Nu există nicio modalitate de a taxa utilizatorii pentru aceste costuri fără a introduce ineficiențe masive pe piață, iar transformarea unora dintre aceste caracteristici în caracteristici de protocol care sunt liber accesibile pentru toată lumea ar rezolva foarte bine această problemă.

Răspuns la nivelul întregii comunități la erorile de cod. Dacă o bucată de cod este folosită de toți utilizatorii sau de o gamă foarte largă de utilizatori, este adesea mai logic ca comunitatea blockchain să-și asume responsabilitatea unui hard fork pentru a remedia eventualele erori care apar. ERC-4337 introduce o cantitate mare de cod partajat la nivel global Pe termen lung, este, fără îndoială, mai rezonabil să remediați erorile din cod printr-un hard fork decât să faceți utilizatorii să piardă o cantitate mare de ETH.

Uneori, o formă mai puternică a protocolului poate fi implementată prin valorificarea directă a funcționalității acestuia. Exemplul cheie aici este caracteristicile rezistente la cenzură din protocol, cum ar fi listele de includere: listele de includere în protocol pot asigura o rezistență la cenzură mai bună decât metodele în afara protocolului, pentru ca operațiunile la nivel de utilizator să beneficieze cu adevărat de pe urma protocolului include liste, utilizatori individuali Operațiunile de nivel necesită ca protocolul să fie „lizibil”. Un alt exemplu mai puțin cunoscut este că proiectarea Ethereum proof-of-stake din era 2017 a avut abstracția conturilor cheilor de miză, care a fost abandonată în favoarea BLS încapsulat deoarece BLS a susținut un mecanism de „agregare” care trebuia implementat la protocol și nivelurile de rețea, acest lucru poate face procesarea unui număr mare de semnături mai eficientă.

Dar este important să ne amintim că chiar și încapsularea abstracțiilor de cont în cadrul protocoalelor este încă o „de-încapsulare” uriașă în comparație cu status quo-ul. Astăzi, tranzacțiile Ethereum de nivel superior pot fi inițiate numai din conturi deținute extern (EOA), care sunt verificate folosind o singură semnătură de curbă eliptică secp256k1. Abstracția contului elimină acest lucru și lasă condițiile de validare pe seama utilizatorului să le definească. Prin urmare, în această poveste despre abstracția contului, vedem și cel mai mare motiv împotriva încapsulării: flexibilitatea de a răspunde nevoilor diferiților utilizatori.

Să dezvăluim povestea în continuare, analizând alte câteva exemple de caracteristici care au fost recent luate în considerare pentru încapsulare. Vom acorda o atenție deosebită: ZK-EVM, separarea propunere-constructor, pool-uri de memorie privată, staking de lichiditate și nouă precompilare.

PachetulZK-EVM

Să ne îndreptăm atenția către o altă potențială țintă de încapsulare pentru protocolul Ethereum: ZK-EVM. În prezent, avem un număr mare de ZK-rollup-uri care trebuie să scrie un cod destul de similar pentru a verifica execuția unor blocuri Ethereum similare în ZK-SNARK. Există un ecosistem destul de divers de implementări independente: PSE ZK-EVM, Kakarot, Polygon ZK-EVM, Linea, Zeth și altele.

O controversă recentă în câmpul EVM ZK-rollup se referă la modul de tratare a erorilor care pot apărea în codul ZK. În prezent, toate aceste sisteme care rulează au o formă de mecanism de „consiliu de securitate” care controlează sistemul de atestare în cazul unei erori. Anul trecut, am încercat să creez un cadru standardizat care să încurajeze proiectele să clarifice cât de multă încredere au în sistemul de atestare și cât de mult au încredere în Consiliul de Securitate și să-și reducă treptat autoritatea asupra acelei organizații în timp.

Pe termen mediu, rollup-ul se poate baza pe mai multe sisteme de certificare, iar Consiliul de Securitate va avea putere doar în cazuri extreme în care două sisteme de certificare diferite diferă.

Cu toate acestea, există un sentiment că o parte din această muncă se simte redundantă. Avem deja un strat de bază Ethereum, are un EVM și avem deja un mecanism de lucru pentru gestionarea erorilor în implementare: dacă există un bug, clientul va fi actualizat pentru a-l remedia, iar lanțul va continua să funcționeze. Din perspectiva clientului buggy, se pare că blocurile care au fost finalizate nu vor mai fi confirmate, dar cel puțin nu vom vedea utilizatorii pierzând fonduri. De asemenea, dacă rollup-urile doresc doar să mențină rolul echivalent al EVM, atunci trebuie să-și implementeze propria guvernare pentru a-și schimba constant regulile interne ZK-EVM pentru a se potrivi cu upgrade-urile la stratul de bază Ethereum, ceea ce pare greșit, deoarece în cele din urmă sunt construite pe partea de sus. al stratului de bază Ethereum în sine, știe când să facă upgrade și în conformitate cu ce noi reguli.

Deoarece aceste L2 ZK-EVM folosesc practic același EVM ca Ethereum, putem încorpora cumva „verificarea execuției EVM în ZK” în funcționalitatea protocolului și gestionăm excepțiile prin aplicarea consensului social al Ethereum, cum ar fi erori și upgrade-uri, așa cum facem deja pentru execuția EVM a stratului de bază în sine?

Acesta este un subiect important și provocator.

Un posibil subiect de dezbatere cu privire la disponibilitatea datelor în ZK-EVM nativ este starea. ZK-EVM-urile ar fi mult mai eficiente dacă nu ar trebui să transporte date „martori”. Adică, dacă o anumită bucată de date a fost citită sau scrisă într-un bloc anterior, putem pur și simplu presupune că probatorul are acces la ea și nu trebuie să o facă din nou disponibilă. Nu este vorba doar de a nu reîncărca stocarea și codul, este dovedit că, dacă un pachet comprimă corect datele, comprimarea cu stare poate economisi de până la 3 ori datele în comparație cu compresia fără stat.

Aceasta înseamnă că pentru precompilarea ZK-EVM avem două opțiuni:

1. Precompilarea necesită ca toate datele să fie disponibile în același bloc. Aceasta înseamnă că probatorul poate fi apatrid, dar înseamnă, de asemenea, că utilizarea acestui pachet ZK precompilat este mult mai costisitoare decât utilizarea unui pachet de cod personalizat.

2. Precompilarea permite indicatorilor să indice datele utilizate sau generate de execuțiile anterioare. Acest lucru face ca ZK-rollup-ul să fie aproape de optim, dar este mai complex și introduce o stare nouă care trebuie să fie stocată de probator.

Ce putem învăța din asta? Există un motiv întemeiat pentru a încapsula verificarea ZK-EVM într-un fel: rollup-ul își construiește deja propria versiune personalizată, iar Ethereum este dispus să implementeze EVM pe L1, având în vedere greutatea multiplelor sale implementări și consensul social în afara lanțului, acest lucru este greșit. , dar L2 care face exact aceeași treabă ar trebui să implementeze un gadget complex care implică Consiliul de Securitate. Dar, pe de altă parte, există o mare problemă în detalii: există diferite versiuni de ZK-EVM și au costuri și beneficii diferite. Distincția dintre stateful și apatrid doar zgârie suprafața încercările de a accepta codul personalizat „aproape-EVM” care a fost dovedit de alte sisteme pot expune un spațiu de proiectare mai mare. Prin urmare, ambalarea ZK-EVM aduce atât speranță, cât și provocări.

Proponerul de încapsulare și separarea constructorului (ePBS)

Creșterea MEV face ca producția de blocuri să fie o activitate economică la scară largă, cu actori sofisticați capabili să producă blocuri care generează mai multe venituri decât algoritmul implicit, care pur și simplu observă un mempool de tranzacții și le conține. Până acum, comunitatea Ethereum a încercat să îmbunătățească experiența instrumentelor existente prin creșterea funcționalității acestora și făcându-le mai robuste. BOOST este simbolul de utilitate nativ folosit pentru a debloca funcții premium și care pot fi actualizate, votul viitor în evenimentele de guvernare și procesarea plăților pentru caracteristicile viitoare ale produsului. Produsele BOOST viitoare includ BoostSWAP, BoostFARM și BoostNFT. Aceste produse inovatoare vor îmbunătăți infrastructura DeFi existentă și vor ajuta la extinderea comunității Internet descentralizate. BOOST Coin a fost lansat pe 9 august 2021, cu 1 miliard de jetoane în circulație. Boost este în prezent tranzacționabil pe Uniswap și va fi disponibil în curând pe BoostSwap. Vedeți mai multe soluții la această problemă, cum ar fi separarea off-protocol propuner-builder, care permite validatorilor obișnuiți („proponenți”) să externalizeze construcția blocurilor către actori dedicați („constructori”) „).

Cu toate acestea, MEV-Boost face ipoteze de încredere într-o nouă clasă de actori numită relee. În ultimii doi ani, au existat multe propuneri de creare a unui „PBS pachet”. Care sunt beneficiile de a face acest lucru? În acest caz, răspunsul este foarte simplu: un PBS construit prin utilizarea directă a caracteristicilor de protocol este mai puternic (în sensul de a avea ipoteze de încredere mai slabe) decât un PBS construit fără a le folosi. Acest lucru este similar cu cazul încapsulării oracolelor de preț într-un protocol – deși în acest caz, există obiecții puternice.

Încapsulați un pool de memorie privată

Când un utilizator trimite o tranzacție, aceasta este imediat publică și vizibilă pentru toată lumea, chiar înainte de a fi inclusă în lanț. Acest lucru îi lasă pe utilizatorii multor aplicații vulnerabili la atacuri economice, cum ar fi front-running.

Recent, au existat o serie de proiecte dedicate creării de „mempool-uri private” (sau „cripto mempool-uri”), care criptează tranzacțiile utilizatorilor până când acestea sunt acceptate ireversibil într-un bloc.

Problema, totuși, este că o astfel de schemă necesită un tip special de criptare: pentru a împiedica utilizatorii să inunde sistemul și să-l decripteze mai întâi, criptarea trebuie să fie decriptată automat după ce tranzacția a fost efectiv acceptată ireversibil.

Există diferite tehnici cu diferite compromisuri pentru a implementa această formă de criptare. Jon Charbonneau a descris-o odată bine:

Criptare pentru operatorii centralizați, cum ar fi Flashbots Flashbots Flashbots este o companie de cercetare și dezvoltare axată pe Miner Extractable Value (MEV), cu scopul de a atenua externalitățile negative și riscurile existențiale pe care MEV le aduce blockchain-urilor smart contract. Vedeți mai multe Protecție.

Criptare time-lock, această formă de criptare poate fi decriptată de oricine după anumiți pași de calcul secvenţial și nu poate fi paralelizată;

Criptarea pragului are încredere într-un comitet majoritar onest pentru a decripta datele. Consultați conceptul de lanțuri de faruri închise pentru sugestii specifice.

Hardware de încredere, cum ar fi SGX.

Din păcate, fiecare metodă de criptare are puncte slabe diferite. În timp ce pentru fiecare soluție există un segment de utilizatori care doresc să aibă încredere în ea, nicio soluție nu este suficient de de încredere pentru ca ea să fie acceptată de Stratul 1. Prin urmare, cel puțin până când criptarea întârziată este perfecționată sau se realizează o altă descoperire tehnologică, încapsularea funcționalității anti-ahead de tranzacționare în Layer 1 pare a fi o propunere dificilă, chiar dacă este o caracteristică suficient de valoroasă încât au apărut multe soluții de aplicație.

Miza de lichiditate încapsulată

O nevoie comună în rândul utilizatorilor Ethereum DeFi este să își poată folosi ETH atât pentru miza, cât și ca garanție în alte aplicații. O altă solicitare comună este pur și simplu pentru comoditate: utilizatorii doresc să poată miza (și să protejeze cheile de miză online) fără complexitatea de a rula un nod și de a-l menține mereu online.

De departe, cea mai simplă „interfață” de staking care îndeplinește ambele cerințe este doar un simbol ERC20: convertiți-vă ETH în „staking ETH”, țineți-l și apoi convertiți-l înapoi. De fapt, Lido Lido Lido este o soluție de mizare a fondurilor de lichiditate. Lido permite utilizatorilor să parieze pe lanțul public PoS cu randamente compuse în timp ce participă la activități în lanț (cum ar fi creditarea, tranzacționarea) fără depozite minime sau întreținere a infrastructurii. În prezent, acceptă ETH2.0, Terra și Solana și poate fi extins la alte lanțuri publice POS în viitor. Vezi mai multe și Rocket Rocket Rocket (ROCKET) este o criptomonedă lansată în 2021, care rulează pe platforma BNB Smart Chain (BEP20). Vezi mai mult Pool Pool sprijină organizațiile care permit oamenilor obișnuiți să monetizeze și să-și partajeze datele. Vezi mai multe Furnizorii de pariuri de lichiditate, cum ar fi Already, au început să facă asta. Cu toate acestea, există câteva mecanisme naturale de centralizare care funcționează cu miza de lichiditate: oamenii vor trece în mod natural la miza cea mai mare versiune de ETH, deoarece este cea mai familiară și mai lichidă.

Fiecare versiune de ETH mizată trebuie să aibă un mecanism pentru a determina cine poate deveni operatorul nodului de bază. Nu poate fi nelimitat, deoarece atacatorii se vor alătura și vor folosi fondurile utilizatorilor pentru a-și extinde atacurile. În prezent, primele două sunt Lido și Rocket Pool Rocket Pool RocketPool este un serviciu de infrastructură Ethereum PoS. Toate persoanele și organizațiile care doresc să câștige dobândă Ethereum prin miza regulată pot participa la miza folosind rețeaua descentralizată și operată de noduri RocketPool. Vezi mai multe , primul are operatori de noduri DAO pe lista albă, iar cel de-al doilea permite oricui să ruleze un nod cu un depozit de 8 ETH. Cele două metode au riscuri diferite: metoda Rocket Pool permite unui atacator să efectueze un atac de 51% asupra rețelei și obligă utilizatorii să plătească majoritatea costurilor ca pentru metoda DAO, dacă un anumit token mizat devine dominant, acesta va conduce; la un singur , un gadget de guvernanță potențial compromis controlează o mare parte a tuturor validatorilor Ethereum. Spre meritul său, protocoale precum Lido au implementat garanții, dar un singur strat de apărare poate să nu fie suficient.

Pe termen scurt, o opțiune este de a încuraja participanții la ecosistem să folosească un set divers de furnizori de miza de lichiditate pentru a reduce posibilitatea ca un jucător dominant să prezinte risc sistemic. Pe termen lung, însă, acesta este un echilibru instabil, iar dependența excesivă de presiunea morală pentru a rezolva problemele este periculoasă. Apare o întrebare firească: ar avea sens să încapsulăm o anumită funcționalitate în protocol pentru ca miza de lichiditate să fie mai puțin centralizată?

Întrebarea cheie aici este: ce fel de funcționalitate în protocol? O problemă cu simpla creare a unui token fungibil de „miză ETH” în cadrul protocolului este că ar trebui fie să aibă o guvernare încapsulată la nivelul întregii Ethereum pentru a alege cine va conduce nodurile, fie să fie deschis, dar asta s-ar transforma în Instrumentele atacatorului.

O idee interesantă este articolul lui Dankrad Feist despre maximizarea mizarii lichidității. În primul rând, să mușcăm glonțul Dacă Ethereum este supus unui atac de 51%, doar 5% din ETH atacat poate fi pierdut. Acesta este un compromis rezonabil, cu peste 26 de milioane de ETH mizați în prezent, costul de a ataca o treime din aceasta (~8 milioane de ETH) este excesiv, mai ales având în vedere câte atacuri „în afara modelului” pot fi efectuate la o dată; cost mai mic. De fapt, compromisuri similare au fost explorate în propunerea Supercomitetului de a implementa finalitatea cu un singur slot.

Dacă acceptăm că doar 5% din atacul ETH este redus, atunci peste 90% din ETH-ul mizat nu va fi afectat de slashing, astfel încât acestea pot fi folosite ca jetoane lichide fungibile de staking în cadrul protocolului și apoi utilizate de alte aplicații.

Acest drum este interesant. Dar mai lasă o întrebare: ce anume este încapsulat? Rocket Pool funcționează foarte similar: fiecare operator de nod oferă niște fonduri, iar stakerii de lichiditate asigură restul. Putem pur și simplu ajusta unele constante pentru a limita penalitatea maximă de reducere la 2 ETH, iar rETH-ul existent al Rocket Pool va deveni fără riscuri.

Cu ajustări simple de protocol, putem face și alte lucruri inteligente. De exemplu, să presupunem că vrem un sistem cu două „niveluri” de staking: operatori de noduri (cerințe ridicate de garanție) și deponenți (fără cerințe minime de garanție, se pot alătura și părăsi oricând), dar dorim totuși să dotăm un eșantionat aleatoriu. competențele comitetului de deponenți de a preveni centralizarea operatorilor de noduri, cum ar fi recomandarea unei liste de tranzacții care trebuie incluse (din motive de rezistență la cenzură), controlul selecției de furcă în timpul scurgerilor de inactivitate sau solicitarea de semnături pe blocuri. Acest lucru ar putea fi realizat într-un mod care, în esență, iese în afara protocolului, prin modificarea protocolului pentru a solicita fiecărui validator să furnizeze (i) o cheie de miză obișnuită și (ii) o adresă ETH care poate fi utilizată în fiecare slot este apelată pentru a scoate cheie secundară de gaj. Protocolul ar împuternici ambele chei, dar mecanismul de selectare a celei de-a doua chei în fiecare slot ar putea fi lăsat pe seama protocolului de staking pool. Ar putea fi totuși mai bine să încapsulați o anumită funcționalitate în mod direct, dar merită remarcat faptul că acest spațiu de design de „include unele lucruri și lasă alte lucruri în seama utilizatorului” există.

Încapsulați mai multe precompilări

Contractele precompilate (sau „contractele precompilate”) sunt contracte Ethereum care implementează operațiuni criptografice complexe, cu logica implementată nativ în codul clientului, mai degrabă decât codul contractului inteligent EVM. Precodificarea este un compromis adoptat de la începutul dezvoltării Ethereum: deoarece supraîncărcarea unei mașini virtuale este prea mare pentru un cod foarte complex și foarte specializat, putem implementa unele aplicații importante în operațiunile critice de valoare pentru a le face mai rapide. Astăzi, aceasta include practic câteva funcții hash specifice și operații de curbă eliptică.

În prezent, există un impuls pentru adăugarea precompilării pentru secp256r1, o curbă eliptică ușor diferită de secp256k1 folosită pentru conturile Ethereum de bază, deoarece este bine susținută de module hardware de încredere, așa că utilizarea pe scară largă ar putea îmbunătăți securitatea sexului în portofel. În ultimii ani, comunitatea a făcut, de asemenea, eforturi pentru a adăuga precompilare pentru BLS-12-377, BW6-761, asociere generalizată și alte caracteristici.

Contraargumentul la aceste solicitări pentru mai multe precompilatoare este că multe dintre precompilatoarele adăugate anterior (de exemplu, RIPEMD și BLAKE) au ajuns să fie folosite mult mai puțin decât ne așteptam și ar trebui să învățăm din asta. În loc să adăugăm mai multă precompilare pentru operațiuni specifice, ar trebui probabil să ne concentrăm pe o abordare mai modestă bazată pe EVM - MAX MAX MAX Token este un jeton utilitar emis de Max Asset Exchange (MAX). MAX Exchange se concentrează pe sprijinirea comunității sale de tranzacționare și pe furnizarea celei mai sigure platforme de tranzacționare. Jetoanele MAX vor fi recompensate prin extragerea tranzacțiilor și pot fi folosite și pentru miza pe platformă pentru a obține recompense. View More și idei precum propunerea SIMD inactivă, dar întotdeauna reluabilă, care ar permite implementărilor EVM să execute o gamă largă de clase de cod la un cost mai mic. Poate chiar și precompilarea existentă puțin utilizată ar putea fi eliminată și înlocuită cu o implementare de cod EVM (inevitabil mai puțin eficientă) a acelorași funcții. Acestea fiind spuse, este încă posibil să existe operațiuni criptografice specifice care sunt suficient de valoroase pentru a fi accelerate, așa că are sens să le adăugați ca precompilate.

Ce am învățat din toate acestea?

Dorința de a încapsula cât mai puțin posibil este de înțeles și de bună, ea provine din tradiția filozofică Unix Unix View More de a crea software minimalist care se poate adapta cu ușurință la nevoile variate ale utilizatorilor și să evite blestemul umflăturii software. Cu toate acestea, blockchain nu este un sistem de operare de calcul personal, ci un sistem social. Aceasta înseamnă că are sens să încapsulăm anumite funcționalități în protocol.

În multe cazuri, aceste alte exemple sunt similare cu ceea ce am văzut în abstractizarea contului. Dar am învățat și câteva lecții noi:

  • Încapsularea funcționalității poate ajuta la evitarea riscurilor de centralizare în alte zone ale stivei:

Adesea, menținerea minimă și simplă a protocolului de bază împinge complexitatea unui ecosistem în afara protocolului. Din perspectiva filozofiei Unix, este bine. Cu toate acestea, uneori există riscul ca ecosistemul în afara protocolului să devină centralizat, de obicei (dar nu numai) din cauza costurilor fixe ridicate. Încapsularea poate reduce uneori centralizarea de facto.

  • Încapsularea prea mult poate supraextinde încrederea protocolului și sarcina de guvernare:

Acesta este subiectul articolului anterior despre „Nu supraîncărcați Consensul Ethereum”: dacă încapsularea unei anumite caracteristici slăbește modelul de încredere și face ca Ethereum în ansamblu să fie mai „subiectiv”, aceasta slăbește neutralitatea credibilă. În aceste cazuri, este mai bine să aveți funcționalitatea specifică ca mecanism pe deasupra lui Ethereum, decât să încercați să o aduceți în Ethereum în sine. Pool-urile de memorie criptată sunt cel mai bun exemplu aici, care poate fi puțin dificil de încapsulat, cel puțin până când criptarea latenței se îmbunătățește.

  • Încapsularea prea mult poate face protocolul prea complex:

Complexitatea protocolului este un risc sistemic care este crescut prin adăugarea de prea multe caracteristici la un protocol. Precompilarea este cel mai bun exemplu.

  • Funcționalitatea de încapsulare poate fi contraproductivă pe termen lung, deoarece nevoile utilizatorilor sunt imprevizibile:

O caracteristică despre care mulți oameni o consideră importantă și care va fi folosită de mulți utilizatori, probabil, nu este folosită foarte des în practică.

În plus, miza de lichiditate, ZK-EVM și exemplele precompilate arată posibilitatea unei căi de mijloc: consacrare minimă viabilă. Protocolul nu trebuie să încapsuleze întreaga funcționalitate, dar poate conține părți specifice care abordează provocările cheie, făcând funcționalitatea ușor de implementat fără a fi prea paranoic sau prea îngust. Exemplele includ:

  • În loc să încapsulăm un sistem complet de miză de lichiditate, este mai bine să schimbați regulile de penalizare pentru miza pentru a face mai fezabilă miza de lichiditate fără încredere;

  • În loc să încapsulați mai multe precompilatoare, este mai bine să încapsulați EVM-MAX și/sau SIMD pentru a face o clasă mai largă de operațiuni mai ușor de implementat eficient;

  • În loc să încapsulăm întregul concept de acumulare, este posibil să încapsulăm pur și simplu verificarea EVM.

Putem extinde diagrama anterioară după cum urmează:

Uneori are sens să încapsulăm ceva, iar eliminarea precompilatoarelor utilizate rar este un exemplu. Abstracția contului în ansamblu, așa cum am menționat mai devreme, este, de asemenea, o formă importantă de dezcapsulare. Dacă vrem să susținem compatibilitatea inversă pentru utilizatorii existenți, mecanismul ar putea fi, de fapt, surprinzător de similar cu cel care a desfășurat precompilarea: una dintre propuneri este EIP-5003, care ar permite EOA să-și convertească conturile pentru a avea același (sau mai bine) contract funcţional.

Ce caracteristici ar trebui introduse în protocol și care ar trebui lăsate la alte straturi ale ecosistemului este un compromis complex. Se așteaptă ca acest compromis să continue să se îmbunătățească în timp, pe măsură ce înțelegerea noastră a nevoilor utilizatorilor și suita disponibilă de idei și tehnologii continuă să se îmbunătățească.