Titlul original: „Actualizarea 014 a întâlnirii dezvoltatorilor Ethereum Core”
Sursa originală: AllCoreDevs Update
Autor original: Tim Beiko
Compilare originală: Ethereum.cn
Bun venit la o nouă ediție a actualizării AllCoreDevs (Ethereum Core Developer Conference) – ultima din 2022.
Prezentare generală
Conținutul upgrade-ului Shanghai/Capella a fost finalizat: retrageri, EOF și câteva modificări minore... cu condiția ca acestea să nu întârzie retragerile.
Se apropie spațiul blob: EIP-4844 va fi în centrul următoarei upgrade a lui Ethereum, iar ceremonia de convocare a acestuia va începe în curând.
Din punct de vedere tehnic, se depun eforturi pentru a coordona procesele de actualizare a stratului de execuție și a stratului de consens. De asemenea, asistăm la discuții active despre o mai bună încorporare a contribuțiilor comunității în proces.
Protocol Guild a lansat un raport pilot la mijlocul perioadei și un plan aproximativ pentru a extinde dimensiunea întreținerii de prim nivel și a-i sprijini mai bine în 2023.
Upgrade Shanghai/Capella
La un AllCoreDevs recent, echipa client a ajuns la un consens cu privire la scopul final al upgrade-ului Shanghai/Capella. În timp ce numele upgrade-ului poate fi dezbătut, echipa este clară asupra domeniului său de aplicare. Principala caracteristică a upgrade-ului este introducerea retragerilor Beacon Chain pentru stakers. Lansarea acestei funcții cât mai repede posibil este ceva asupra căruia echipa client nu dorește să facă compromisuri, așa că alte funcții din actualizare trebuie să fie gata în același timp, altfel riscă să fie abandonate.
Specificația Stratului Executiv de la Shanghai enumeră toate EIP-urile incluse:
EIP-3540: EVM Object Format (EOF) v1
EIP-3651: Reduceți costul gazului pentru accesarea adreselor COINBASE
EIP-3670: EOF - Verificare cod
EIP-3855: A fost adăugat cod operațional PUSH 0
EIP-3860: Limitați dimensiunea codului init și introduceți măsurarea gazului
EIP-4200: EOF - salt relativ static
EIP-4750: EOF - Funcții de import
EIP-4895: Retrageri de împingere a lanțului de faruri ca funcționare a sistemului
EIP-5450: EOF - Stack Verification
Deși lista este lungă, poate fi împărțită în trei părți diferite: îmbunătățiri minore, formate de obiecte EVM și retrageri. În continuare, le vom prezenta unul câte unul:
Mici îmbunătățiri
EIP-3651: Warm COINBASE (reduceți costul gazului pentru accesarea adreselor COINBASE)
Acest EIP remediază o omisiune în EIP-2929 în care costul gazului pentru accesarea anumitor câmpuri de date a fost modificat în funcție de faptul dacă datele erau deja în memoria clientului (WARM) sau trebuiau preluate de pe disc (RECE).
EIP-2929 setează două date din memoria clientului la WARM la începutul fiecărei tranzacții: adresa de expediere și adresa de primire. EIP-3651 adaugă o a treia adresă la această listă, adresa COINBASE (adică feeRecipient), deoarece este și adresa pe care clientul o are în memorie atunci când procesează tranzacțiile blocate.
EIP-3855: instrucțiune PUSH 0 (cod operațional nou `PUSH 0)
După cum sugerează și numele, EIP-3855 introduce un cod operațional care împinge o valoare de 0 în stivă. Apăsarea lui 0 este adesea folosită pentru a completa valori în EVM, acest cod operațional va oferi o modalitate mai eficientă și mai ieftină de a face acest lucru.
EIP-3860: Limitare și contor initcode (limitați dimensiunea initcode și introduceți măsurarea gazului)
Acest EIP adaugă un plafon pentru dimensiunea codului init și introduce măsurarea gazului pe baza lungimii acestuia. Limita sa superioară de dimensiune adaugă un invariant la EVM, făcând mai ușor de înțeles și de propus modificări.
Introduce o suprasarcină de 2 gaz pe 32 de octeți pentru initcode, care este folosit pentru a plăti cea mai mare analiză pe care trebuie să o efectueze clientul înainte de execuție, care nu este listată în contorul de gaz.
format obiect
Cea mai mare parte a EIP inclusă în upgrade-ul Shanghai face de fapt parte dintr-o singură caracteristică: EVM Object Format (EOF). Lucrarea a fost împărțită în 5 EIP-uri diferite pentru a ajuta dezvoltatorii clienți să înțeleagă fiecare modificare individuală, dar pentru a oferi o imagine de ansamblu la nivel superior, dezvoltatorii au lansat o specificație unificată. EIP-urile acestor cinci EOF sunt:
EIP-3540: formatul obiectului EVM versiunea 1
EIP-3670: EOF - Verificare cod
EIP-4200: EOF - salt relativ static
EIP-4750: EOF - Funcții de import
EIP-5450: EOF - Stack Verification
Este de remarcat faptul că primul pas al EOF a fost upgrade-ul Londra EIP-3541, care a rezervat prefixul 0xEF 00 pentru contractul EOF. Domeniul de aplicare EOF al upgrade-ului de la Shanghai s-a schimbat, de asemenea, în ultimele luni.
În februarie, echipa de clienți a fost de acord să ia în considerare modernizarea în Shanghai pentru a include cele mai mici două EIP-uri EOF: EIP-urile 3540 și 3670. Toate vor servi ca blocuri de construcție, dar nu vor oferi funcționalitate completă fără introducerea EIP 4200, 4750 și 5450. Deși este posibil să se extindă EOF, incompatibilitatea inversă poate necesita o nouă versiune. Deoarece contractele pre-EOF sau EOF cu o anumită versiune trebuie să fie întotdeauna executabile, fiecare nouă versiune EOF înseamnă că dezvoltatorii clienți trebuie să mențină un nou set de reguli de execuție EVM în paralel cu vechile reguli.
Înainte de EOF, clienții mențineau un singur set de reguli EVM la un moment dat. Baza de cod acceptă și regulile EVM anterioare, care sunt modificate cu fiecare actualizare a rețelei, dar odată ce ajung la șeful blockchain-ului, trebuie aplicate doar cele mai recente reguli. După implementarea EOF, clientul va menține două seturi paralele de reguli EVM, astfel încât să poată executa cod în contracte EOF și non-EOF. Cu alte cuvinte, versiunile în creștere ale EOF măresc numărul de seturi de reguli EVM paralele, mai degrabă decât consecutive, care trebuie menținute.
În acest scop, în ultimele luni, echipele de clienți au început să favorizeze o abordare „mare EOF”. În acest fel, deși trebuie să implementeze seturi de modificări mai mari, versiunea EOF va dura mai mult și va reduce numărul de „EVM-uri paralele” care trebuie menținute. Prin urmare, dezvoltatorii au considerat „mare EOF” și, în cele din urmă, l-au inclus în upgrade-ul de la Shanghai.
Acestea fiind spuse, funcțiile mai mari sunt, în mod evident, mai dificil de implementat și testat, iar echipa nu dorește să vadă că EOF întârzie grav retragerile lanțului de faruri. Prin urmare, dacă implementarea EOF nu a fost finalizată până în ianuarie și nu pot interopera rapid între ele, echipa client este de acord să mute EOF din Shanghai pentru upgrade.
Având în vedere aceste contexte, să prezentăm acum pe scurt fiecare EOF EIP:
EIP-3540: EVM Object Format (EOF) v1 (EVM Object Format versiunea 1)
Acest EIP introduce „container” în contractul EOF. Adaugă etichete pentru a distinge codul și părțile de date ale contractului și împiedică implementarea contractelor EOF care nu sunt conforme cu formatul. Acest lucru garantează că orice contract EOF din lanț va urma un format valid, ceea ce simplifică interacțiunea cu aceste contracte, precum și analiza statică a acestora.
EIP-3670: EOF - Validarea codului (EOF - Validarea codului)
Bazându-se pe containerul introdus de 3540, EIP-3670 asigură valabilitatea codului din contractul EOF sau împiedică implementarea acestuia.
Aceasta înseamnă că codurile operaționale nedefinite nu pot fi implementate în contractele EOF, ceea ce are avantajul suplimentar de a reduce numărul de versiuni EOF care trebuie adăugate. Dacă se adaugă un nou cod operațional, regulile de validare pot fi modificate pur și simplu pentru a-l activa și pentru a se asigura că niciun contract EOF implementat nu face referire la acesta în secțiunea sa de cod.
EIP-4200: EOF - Salturi relative statice (EOF - Salturi relative statice)
EIP-4200 introduce primele coduri operaționale specifice EOF: RJUMP, RJUMPI și RJUMPV, care codifică destinațiile ca valori imediate semnate. Aceste noi coduri operaționale JUMP pot fi utilizate de către compilatori pentru a optimiza supraîncărcarea gazului, deoarece elimină necesitatea analizei jumpdest la timpul de rulare, care este cerută de codurile operaționale JUMP și JUMPI existente.
EIP-4750: EOF - Funcții (funcții introduse de EOF)
EIP-4750 merge mai departe decât 4200: nu permite utilizarea codurilor operaționale JUMP și JUMPI și adaugă alternative pentru funcțiile care nu pot fi copiate. Este implementat prin introducerea de secțiuni specifice de funcție în bytecode EOF. Aceste funcții pot sări de la noile opcode JUMPF, CALLF și respectiv RETF și le pot folosi pentru a apela și a reveni.
EIP-5450: EOF - Validare stivă (Validare EOF-Stack)
În cele din urmă, EIP-5450 adaugă o altă verificare de validare pentru contractele EOF, de data aceasta în jurul stivei. Acest EIP împiedică contractele EOF să implementeze cod care poate cauza depășirea stivei și depășirea în unele cazuri. Cu acest EIP, clienții pot reduce numărul de verificări de validare atunci când execută contracte EOF, deoarece au garanții mai bune în privința excepțiilor legate de stiva.
În calitate de expert non-EVM care este foarte concentrat pe EIP în sine, nu pot spune multe despre asta! Dacă cititorii doresc să afle mai multe despre EOF, recomand tweet-urile relevante postate de lightclients din echipa Geth și Leo din echipa Solidity.
Retragerea lanțului farului
Nu în ultimul rând, partea principală a „Shapella” (Nota traducătorului: numele colectiv al lui Shanghai/Capella) este retragerea lanțului de faruri. Această parte a modificării este descrisă în specificația stratului de consens și EIP-4895. Există acum o meta-specificație ușor depășită care leagă aceste modificări.
La un nivel înalt, mecanica retragerilor este următoarea:
Când propune un bloc, validatorul scanează liniar indexul validatorului pentru a găsi primii 16 validatori cu acreditări 0x01, care trebuie să îndeplinească una dintre următoarele condiții:
Aveți un sold peste 32 ETH (adică ați acumulat recompense pentru validator)
Sunt retrabile (adică au ieșit complet din setul de validare)
Soldul este mai mare de 32 ETH (adică a fost obținută recompensa validatorului)
Este retras (retras, adică a ieșit complet din setul de validare)
Din acestea, validatorul va crea o listă de retrageri care vor fi incluse în ExecutionPayload. Fiecare articol din acea listă conține următoarele:
Validatorul va crea o listă de retragere de la acești validatori și o va împacheta în ExecutionPayload lor. Fiecare articol din listă conține următoarele:
WithdrawalIndex: Indexul tuturor tranzacțiilor de retragere care au fost efectuate - acest lucru ajută la distingerea retragerilor de aceeași sumă de la aceeași adresă, același validator
ValidatorIndex: indicele validatorului în care soldul a fost majorat
ExecutionAddress: adresa ETH a stratului de execuție, la care ar trebui trimise retragerile
Sumă: suma trimisă la ExecutionAddress, această sumă este măsurată în gwei (nu în wei)
Clienții din nivelul de execuție vor efectua aceste retrageri după ce tranzacțiile sunt executate atunci când construiesc sau procesează blocuri. Cu alte cuvinte, retragerile sunt procesate într-un mod similar cu înregistrarea recompenselor de dovadă a muncii și nu concurează cu tranzacțiile utilizatorilor pentru spațiul bloc.
Există și alte detalii care merită remarcate:
La procesarea retragerilor, nu există nicio diferență de prioritate/ordine între „fonduri complete” și „fonduri parțiale”. Retragerile complete apar atunci când un validator părăsește echipa de ieșire, în timp ce retragerile parțiale apar periodic, adică atunci când se efectuează o scanare liniară a setului de validatori și se scanează numărul de index al unui anumit validator.
Pentru ca retragerile să fie procesate, validatorii trebuie să folosească acreditările 0x01, care sunt reprezentate de adrese ETH. Numai acreditările 0x00 ale perechii de chei BLS sunt permise atunci când lanțul de baliză este online. Pentru a iniția o retragere, un validator cu acreditări 0x00 va trebui să semneze un mesaj BLSToExecutionChange. Acestea vor fi activate în upgrade-ul Capella. Vor fi folosite o varietate de instrumente pentru a semna acest mesaj, iar validatorii se pot aștepta la asistență și tutoriale pentru aceste instrumente.
Scanarea validatoarelor se face pe bloc. Dacă nu există 16 retrageri de procesat după scanarea unui subset al setului de validator, validatorul va opri scanarea și următorul validator va începe de la ultimul index de validator scanat.
Ca de obicei, vor exista mai multe rețele de testare și rețele de testare pentru dezvoltatori (poate chiar și câteva rețele de testare noi!) pentru validatori pentru a rula întregul proces și a rezolva eventualele probleme înainte ca rețeaua principală să funcționeze.
Shanghai/Capella nu este singura actualizare care face progrese! Echipa de dezvoltatori încă se așteaptă la următoarea actualizare.
Upgrade la Cancun
Deoarece conținutul upgrade-ului Shanghai este deja plin, multe EIP-uri (CFI) care au fost luate în considerare pentru upgrade nu au putut intra în upgrade-ul Shanghai. Echipa client începe să discute care EIP-uri ar trebui luate în considerare pentru următoarea actualizare: upgrade-ul Cancun (numele stratului de consens urmează să fie determinat)
În ceea ce privește nivelul de consens, EIP-4844 a devenit primul EIP scris în specificație după upgrade-ul Capella. Nu există (încă) o specificație pentru nivelul executiv care să poată implementa acest aspect, dar echipa de la nivelul executiv a fost de acord să urmeze o cale similară și să centreze EIP-4844 pe următoarea actualizare.
În urma convenției de upgrade-uri folosind numele orașelor în care a avut loc Devcon, a fost creat cancun.md, cu EIP-4844 inclus oficial în upgrade.
Această decizie a avut loc în ultimul moment al ultimei întâlniri AllCoreDevs din 2022, așa că nu a fost timp să lucrăm la alte propuneri. EIP-urile care au intrat în upgrade-ul CFI în Shanghai, dar nu au fost incluse în final, au fost mutate pe lista CFI pentru upgrade-ul Cancun. A fost deschisă și o postare pe forumul Ethereum Magicians pentru a discuta despre EIP-urile candidate la Cancun. Discuțiile privind amploarea upgrade-urilor în Cancun ar trebui să înceapă serios la începutul anului viitor.
Ceremonia KZG
Un alt lucru de așteptat legat de upgrade-ul Cancun este ceremonia KZG, care este o cerință a EIP-4844.
Acest ritual va genera aleatorietatea necesară pentru a verifica validitatea datelor blob. Pentru ca acesta să fie considerat sigur, doar un participant trebuie să fie sincer. Cu alte cuvinte, dacă toți participanții, cu excepția unuia, se înțeleg, întregul proces este sigur din punct de vedere criptografic.
Ceremonia începe în ianuarie și va fi deschisă tuturor timp de câteva luni. Cu o țintă de 10.000 de participanți, este planificată să fie cea mai mare ceremonie de acest gen până în prezent! Dacă doriți să vă asigurați că nu ratați, urmăriți-l pe Trent Van Epps pe Twitter!
Proces de actualizare post-fuziune
După cum sa menționat în actualizarea anterioară, după fuziune, coordonarea procesului de upgrade Ethereum la nivelul de execuție și la nivelul de consens este un element important de făcut. Dintr-o perspectivă la nivel înalt, stratul de execuție folosește Yellow Paper și EIP pentru a descrie modificările, în timp ce stratul de consens utilizează specificații executabile Python.
Avantajul procesului de nivel executiv este că EIP este bine cunoscut comunității și este formatat într-un mod care demonstrează clar raționamentul din spatele propunerii. Cărțile galbene cu mult conținut matematic asociat cu EIP-uri și necesitatea de a reintroduce specificațiile în contextul fiecărui EIP, fac ca specificațiile stratului de execuție să fie dificil de înțeles și extins.
Problema cu stratul de consens este invers: are o specificație clară și de înțeles într-un singur depozit, dar modificările nu sunt tangibile și propunerile sunt îngropate în alte PR-uri publice din depozit.
Odată cu introducerea specificației stratului de execuție Ethereum, sperăm să scurtăm acest decalaj din partea stratului de execuție. Și, cu unele dispute de proces, s-ar putea să putem introduce EIP în procesul stratului de consens!
Acestea fiind spuse, pe măsură ce s-a discutat și finalizat sfera actualizării de la Shanghai, a devenit clar că ar putea lipsi o altă parte a procesului: permiterea comunității să-și exprime preferințele relative pentru schimbări și să se angajeze în discuții despre întreaga sferă de actualizare (mai degrabă decât EIP-uri individuale) Discutați acest lucru în loc și faceți-l parte din deciziile reuniunii AllCoreDevs și ale stratului de consens.
Nu este clar încă cum va arăta – mi-ar plăcea sugestii! — dar, pe măsură ce numărul părților interesate implicate activ în modificările protocolului a crescut, la fel ca și numărul zonelor afectate de modificările nivelului 1, era clar că avem nevoie de ceva.
Din fericire, nu trebuie să începem de la zero. Ethereum Magicians există de ani de zile, iar întâlnirile sale offline, întâlnirile de grup dedicate sau întâlnirile comunitare pot fi puncte de plecare bune pentru extindere.
Așteptați-vă la mai multe progrese pe acest front la începutul lui 2023!
Actualizare breasla acord
Având în vedere că pilotul Protocol Guild (PG), ei au lansat un raport pentru a analiza cum merg lucrurile și a lua în considerare următorii pași pentru proiect.
Ca o reamintire, PG este un mecanism de finanțare fără permisiune pentru dezvoltatorii de clienți Ethereum Layer 1, cercetătorii de protocol și colaboratorii de sprijin (ca tine).
Acest mecanism este centrat pe individ, nu pe organizație. Pe scurt, fiecare membru este eligibil pentru o parte din jetoanele breslei, ponderată în funcție de cât timp a contribuit la Ethereum. Adăugarea și ștergerea membrilor se face într-un mod adevărat Ethereum - pe baza unui set de standarde și a unui consens brut în cadrul PG. Această listă va fi apoi pusă în lanț folosind contractul divizat 0xSplit. Donatorul poate trimite apoi fonduri direct la adresa destinatarului sau la un contract de atribuire care eliberează fonduri la adresa destinatarului.
Raportul intermediar pilot este rezumat în acest tweet. Iată câteva momente importante
Pilotul a strâns 9,7 milioane de dolari de la organizații precum Lido, Uniswap, ENS, NounsDAO și MolochDAO, precum și de la donatori obișnuiți de la persoane fizice (mulțumesc Tetranode!) - mulțumim tuturor pentru că au făcut acest lucru posibil!
PG avea 90 de membri la lansare și acum are 128, cu 5 milioane de dolari repartizați între ei
În medie, fiecare membru a primit 39.000 USD, cel mai mic fiind de 13.000 USD și cel mai mare ajungând la 79.000 USD
Arhitectura PG se schimbă și va suporta L2 și va elimina nevoia de multi-sig pentru a actualiza ponderile
Aceste rezultate timpurii arată că PG funcționează conform planului: un mecanism de distribuire a unui coș de jetoane unui grup de colaboratori de protocol care se auto-incuba, în creștere. Acest proiect nu ar fi ceea ce este astăzi fără sprijinul generos al donatorilor pilot.
Privind spre viitor, acum este momentul să extindem raza de acțiune a PG și să-i realizăm întregul potențial: oferind menținătorilor Ethereum o compensație competitivă, ajustată la risc. Cel mai ușor lucru de făcut aici este ca proiectul să doneze către PG de la început, așa cum a spus Danny Ryan în tweet-ul de lansare a PG.
Majoritatea donațiilor din cadrul pilotului au provenit din proiecte mari cu sume mari de finanțare. Dacă Protocol Guild poate convinge aceste proiecte să doneze către PG încă din prima zi, când tokenurile lor sunt încă cu adevărat „fără valoare”, atunci menținătorii Ethereum pot beneficia de întreaga traiectorie ascendentă a acestor proiecte de succes.
Atunci când sunt implicate suficiente proiecte, stimulentele pot menține cei mai buni talente în acorduri de întreținere în loc să-i retragă.
Pentru a sprijini acest lucru și multe alte tipuri de donații, PG va avea nevoie de o revizuire tehnologică. Următoarea versiune va sprijini L1 și L2 și va reduce în continuare amprenta de guvernare în lanț.
Dacă sunteți un proiect care doriți să doneze Breslei de Protocol, vă rugăm să mă contactați - DM-urile mele sunt deschise!
Urmare
Asta încheie 2022... Ce an extraordinar! Acum trei luni, nici măcar nu am fost comasați! Acum că Ethereum are dovada mizei care rulează în liniște în fundal, accentul s-a mutat pe tranzacțiile viitoare.
Pe măsură ce toată lumea se întoarce în ianuarie, vă puteți aștepta la:
Shanghai/Capella a actualizat pentru dezvoltatori testnet și shadow fork
Ceremonia KZG este online
Discuții despre Cancun și cum ar trebui să evolueze procesul de actualizare a rețelei pentru a capta mai bine preferințele comunității
Se va încheia pilotul breslei de protocol și vom anunța structura post-pilot.