Titolo originale: "Ethereum Core Developer Meeting Update 014"
Fonte originale: aggiornamento AllCoreDevs
Autore originale: Tim Beiko
Compilazione originale: Ethereum.cn
Benvenuti a una nuova edizione dell'aggiornamento AllCoreDevs (Ethereum Core Developer Conference), l'ultimo del 2022.
panoramica
Il contenuto dell'aggiornamento Shanghai/Capella è stato finalizzato: ritiri, EOF e alcune modifiche minori... purché non ritardino i ritiri.
Lo spazio blob sta arrivando: EIP-4844 sarà al centro del prossimo aggiornamento di Ethereum e la sua cerimonia di convocazione inizierà presto.
Dal punto di vista tecnico, sono in corso sforzi per coordinare i processi di aggiornamento del livello di esecuzione e del livello di consenso. Stiamo anche assistendo a discussioni attive su come incorporare meglio il contributo della comunità nel processo.
La Protocol Guild ha pubblicato un rapporto pilota a medio termine e un piano approssimativo per espandere le dimensioni dei manutentori di primo livello e supportarli meglio nel 2023.
Aggiornamento Shanghai/Capella
In un recente AllCoreDevs, il team del cliente ha raggiunto un consenso sulla portata finale dell'aggiornamento Shanghai/Capella. Anche se il nome dell’aggiornamento potrebbe essere oggetto di discussione, il team ha ben chiaro il suo scopo. La caratteristica principale dell'aggiornamento è l'introduzione dei prelievi di Beacon Chain per gli staker. L'implementazione di questa funzionalità il più rapidamente possibile è qualcosa su cui il team del cliente non vuole scendere a compromessi, quindi altre funzionalità nell'aggiornamento devono essere pronte contemporaneamente o rischiano di essere abbandonate.
La specifica Shanghai Executive Layer elenca tutti gli EIP inclusi:
EIP-3540: formato oggetto EVM (EOF) v1
EIP-3651: riduzione del costo del gas per l'accesso agli indirizzi COINBASE
EIP-3670: EOF - Verifica del codice
EIP-3855: aggiunto codice operativo PUSH 0
EIP-3860: Limita la dimensione del codice di avvio e introduce la misurazione del gas
EIP-4200: EOF - salto relativo statico
EIP-4750: EOF - Funzioni di importazione
EIP-4895: Prelievi push della catena di beacon come funzionamento del sistema
EIP-5450: EOF - Verifica dello stack
Sebbene l’elenco sia lungo, può essere suddiviso in tre parti diverse: miglioramenti minori, formati di oggetti EVM e ritiri. Successivamente li presenteremo uno per uno:
Piccoli miglioramenti
EIP-3651: Warm COINBASE (riduce il costo del gas per accedere agli indirizzi COINBASE)
Questo EIP corregge una svista nell'EIP-2929 in cui il costo del gas per l'accesso a determinati campi dati è stato modificato in base al fatto che i dati fossero già nella memoria del client (WARM) o dovessero essere recuperati dal disco (COLD).
EIP-2929 imposta due dati nella memoria del client su WARM all'inizio di ogni transazione: l'indirizzo di invio e l'indirizzo di ricezione. EIP-3651 aggiunge un terzo indirizzo a questo elenco, l'indirizzo COINBASE (ovvero feeRecipient), poiché è anche l'indirizzo che il client ha in memoria durante l'elaborazione delle transazioni a blocchi.
EIP-3855: istruzione PUSH 0 (nuovo codice operativo `PUSH 0)
Come suggerisce il nome, EIP-3855 introduce un codice operativo che inserisce un valore pari a 0 nello stack. Premendo gli 0 viene spesso utilizzato per inserire valori nell'EVM, questo codice operativo fornirà un modo più efficiente ed economico per farlo.
EIP-3860: Limita e misura il codice init (limita la dimensione del codice init e introduce la misurazione del gas)
Questo EIP aggiunge un limite alla dimensione del codice di avvio e introduce la misurazione del gas in base alla sua lunghezza. Il suo limite di dimensione superiore aggiunge un'invariante all'EVM, rendendone più semplice la comprensione e la proposta di modifiche.
Introduce un sovraccarico di 2 gas per 32 byte per l'initcode, che viene utilizzato per pagare l'analisi jumpdest che il client deve eseguire prima dell'esecuzione, che non è elencata nel contatore del gas.
formato dell'oggetto
La maggior parte dell'EIP incluso nell'aggiornamento di Shanghai fa in realtà parte di un'unica funzionalità: l'EVM Object Format (EOF). Il lavoro è stato suddiviso in 5 diversi EIP per aiutare gli sviluppatori clienti a comprendere ogni singola modifica, ma per fornire una panoramica di livello superiore, gli sviluppatori hanno rilasciato una specifica unificata. Gli EIP di questi cinque EOF sono:
EIP-3540: formato oggetto EVM versione 1
EIP-3670: EOF - Verifica del codice
EIP-4200: EOF - salto relativo statico
EIP-4750: EOF - Funzioni di importazione
EIP-5450: EOF - Verifica dello stack
Vale la pena notare che il primo passo di EOF è stato l'aggiornamento di Londra EIP-3541, che ha riservato il prefisso 0xEF 00 per il contratto EOF. Anche l’ambito EOF dell’aggiornamento di Shanghai è cambiato negli ultimi mesi.
A febbraio, il team del cliente ha deciso di prendere in considerazione l'aggiornamento a Shanghai per includere i due EIP EOF più piccoli: EIP 3540 e 3670. Serviranno tutti da elementi costitutivi, ma non forniranno la piena funzionalità senza l'introduzione di EIP 4200, 4750 e 5450. Sebbene sia possibile estendere EOF, l'incompatibilità con le versioni precedenti potrebbe richiedere una nuova versione. Poiché i contratti pre-EOF o EOF con una versione specifica devono essere sempre eseguibili, ogni nuova versione EOF implica che gli sviluppatori client devono mantenere un nuovo set di regole di esecuzione EVM parallelamente alle vecchie regole.
Prima di EOF, i client mantenevano solo un set di regole EVM alla volta. La base di codice supporta anche le precedenti regole EVM, che vengono modificate ad ogni aggiornamento della rete, ma una volta raggiunte la testa della blockchain, devono essere applicate solo le regole più recenti. Dopo aver distribuito EOF, il cliente manterrà due set paralleli di regole EVM, in modo da poter eseguire codice in contratti EOF e non EOF. In altre parole, l’aumento delle versioni di EOF aumenta il numero di set di regole EVM paralleli anziché consecutivi che devono essere mantenuti.
A tal fine, negli ultimi mesi, i team dei clienti hanno iniziato a favorire un approccio “big EOF”. In questo modo, anche se devono implementare set di modifiche più grandi, la versione EOF durerà più a lungo e ridurrà il numero di "EVM paralleli" che devono essere mantenuti. Pertanto, gli sviluppatori hanno considerato "grande EOF" e alla fine lo hanno incluso nell'aggiornamento di Shanghai.
Detto questo, le funzionalità più grandi sono ovviamente più difficili da implementare e testare, e il team non vuole vedere EOF ritardare gravemente il ritiro della catena di beacon. Pertanto, se l'implementazione di EOF non viene completata entro gennaio e non è possibile interagire rapidamente tra loro, il team del cliente accetta di spostare EOF fuori Shanghai per l'aggiornamento.
Tenendo presenti questi contesti, introduciamo ora brevemente ciascun EOF EIP:
EIP-3540: Formato oggetto EVM (EOF) v1 (formato oggetto EVM versione 1)
Questo EIP introduce il "contenitore" nel contratto EOF. Aggiunge tag per distinguere il codice e le parti di dati del contratto e impedisce la distribuzione di contratti EOF non conformi al formato. Ciò garantisce che qualsiasi contratto EOF sulla catena seguirà un formato valido, che semplifica l'interazione con questi contratti, nonché la loro analisi statica.
EIP-3670: EOF - Convalida del codice (EOF - Convalida del codice)
Basandosi sul contenitore introdotto da 3540, EIP-3670 garantisce che il codice nel contratto EOF sia valido o ne impedisce la distribuzione.
Ciò significa che i codici operativi non definiti non possono essere distribuiti nei contratti EOF, il che ha l'ulteriore vantaggio di ridurre il numero di versioni EOF che devono essere aggiunte. Se viene aggiunto un nuovo codice operativo, le regole di convalida possono essere semplicemente modificate per abilitarlo e garantire che nessun contratto EOF distribuito vi faccia riferimento nella sua sezione di codice.
EIP-4200: EOF - Salti relativi statici (EOF - Salti relativi statici)
EIP-4200 introduce i primi codici operativi specifici di EOF: RJUMP, RJUMPI e RJUMPV, che codificano le destinazioni come valori immediati con segno. Questi nuovi codici operativi JUMP possono essere utilizzati dai compilatori per ottimizzare il consumo di gas poiché eliminano la necessità dell'analisi jumpdest in fase di esecuzione, richiesta dai codici operativi JUMP e JUMPI esistenti.
EIP-4750: EOF - Funzioni (funzioni introdotte da EOF)
EIP-4750 fa un passo avanti rispetto al 4200: non consente l'uso dei codici operativi JUMP e JUMPI e aggiunge alternative per le funzioni che non possono essere copiate. È implementato introducendo sezioni di funzioni specifiche nel bytecode EOF. Queste funzioni possono saltare rispettivamente dai nuovi codici operativi JUMPF, CALLF e RETF e utilizzarli per chiamare e restituire.
EIP-5450: EOF - Convalida stack (Convalida stack EOF)
Infine, EIP-5450 aggiunge un altro controllo di convalida per i contratti EOF, questa volta sullo stack. Questo EIP impedisce ai contratti EOF di distribuire codice che potrebbe causare underflow e overflow dello stack in alcuni casi. Con questo EIP, i clienti possono ridurre il numero di controlli di convalida durante l'esecuzione di contratti EOF perché hanno migliori garanzie riguardo alle eccezioni relative allo stack.
Essendo un esperto non EVM molto concentrato sull’EIP stesso, non c’è molto che posso dire al riguardo! Se i lettori vogliono saperne di più su EOF, consiglio i tweet pertinenti pubblicati dai lightclient del team Geth e da Leo del team Solidity.
Ritiro della catena di segnalazione
Ultimo ma non meno importante, la parte principale di "Shapella" (Nota del traduttore: nome collettivo di Shanghai/Capella) è il ritiro della catena di fari. Questa parte della modifica è descritta nella specifica del livello di consenso e nell'EIP-4895. Ora esiste una meta-specifica leggermente obsoleta che collega insieme questi cambiamenti.
Ad alto livello, i meccanismi dei prelievi sono i seguenti:
Quando propone un blocco, il validatore esegue la scansione lineare dell'indice del validatore per trovare i primi 16 validatori con credenziali 0x01, che devono soddisfare una delle seguenti condizioni:
Avere un saldo superiore a 32 ETH (ovvero aver accumulato premi del validatore)
Sono prelevabili (vale a dire sono completamente usciti dal set di validatori)
Il saldo è maggiore di 32 ETH (ovvero il premio del validatore è stato ottenuto)
E' estraibile (estraibile, cioè è uscito completamente dal set di validatori)
Da questi, il validatore creerà un elenco di prelievi da includere nel proprio ExecutionPayload. Ciascun elemento dell'elenco contiene quanto segue:
Il validatore creerà un elenco di prelievi da questi validatori e lo inserirà nel loro ExecutionPayload. Ciascun elemento dell'elenco contiene quanto segue:
WithdrawalIndex: Indice di tutte le transazioni di prelievo effettuate - aiuta a distinguere i prelievi dello stesso importo dallo stesso indirizzo, dallo stesso validatore
ValidatorIndex: l'indice del validatore in cui è stato raccolto il saldo
ExecutionAddress: l'indirizzo ETH del livello di esecuzione, a cui devono essere inviati i prelievi
Importo: l'importo inviato a ExecutionAddress, questo importo è misurato in gwei (non wei)
I client del livello di esecuzione effettueranno questi prelievi dopo che le transazioni sono state eseguite durante la creazione o l'elaborazione dei blocchi. In altre parole, i prelievi vengono elaborati in modo simile alla registrazione dei premi di prova del lavoro e non competono con le transazioni degli utenti per lo spazio di blocco.
Ci sono altri dettagli degni di nota:
Quando si elaborano i prelievi, non c'è differenza nella priorità/ordine tra "fondi completi" e "fondi parziali". I prelievi completi avvengono quando un validatore lascia il team di uscita, mentre i prelievi parziali avvengono periodicamente, cioè quando viene eseguita una scansione lineare del set di validatori e viene scansionato il numero indice di un determinato validatore.
Affinché i prelievi possano essere elaborati, i validatori devono utilizzare le credenziali 0x01, che sono rappresentate da indirizzi ETH. Sono consentite solo le credenziali della coppia di chiavi BLS 0x00 quando la catena beacon va online. Per avviare un prelievo, un validatore con credenziali 0x00 dovrà firmare un messaggio BLSToExecutionChange. Questi verranno attivati nell'aggiornamento Capella. Ci saranno una varietà di strumenti utilizzati per firmare questo messaggio e i validatori possono aspettarsi supporto e tutorial per questi strumenti.
La scansione dei validatori è per blocco. Se non ci sono 16 prelievi da elaborare dopo la scansione di un sottoinsieme del set di validatori, il validatore interromperà la scansione e il validatore successivo inizierà dall'ultimo indice del validatore scansionato.
Come al solito, ci saranno diversi testnet e testnet per sviluppatori (forse anche alcuni nuovi testnet!) affinché i validatori possano eseguire l'intero processo e appianare eventuali problemi prima che la mainnet diventi attiva.
Shanghai/Capella non è l’unico aggiornamento che sta facendo progressi! Il team di sviluppatori sta ancora guardando avanti al prossimo aggiornamento.
Aggiornamento di Cancún
Poiché il contenuto dell'aggiornamento di Shanghai è già pieno, molti EIP (CFI) presi in considerazione per l'aggiornamento non sono stati in grado di accedere all'aggiornamento di Shanghai. Il team del cliente inizia a discutere quali EIP dovrebbero essere presi in considerazione per il prossimo aggiornamento: l'aggiornamento di Cancun (nome del livello di consenso da determinare)
In termini di livello di consenso, EIP-4844 è diventato il primo EIP scritto nelle specifiche dopo l'aggiornamento Capella. Non esiste (ancora) una specifica per il livello esecutivo in grado di implementare questo layout, ma il team del livello esecutivo ha accettato di seguire un percorso simile e di incentrare EIP-4844 sul prossimo aggiornamento.
Seguendo la convenzione degli aggiornamenti utilizzando i nomi delle città in cui si è tenuto Devcon, è stato creato cancun.md, con EIP-4844 ufficialmente incluso nell'aggiornamento.
Questa decisione è arrivata all’ultimo minuto dell’ultimo incontro AllCoreDevs del 2022, quindi non c’è stato tempo per lavorare su altre proposte. Gli EIP che sono entrati nell'aggiornamento CFI a Shanghai ma non sono stati inclusi alla fine sono stati spostati nell'elenco CFI per l'aggiornamento di Cancun. È stato anche aperto un post sul forum Ethereum Magicians per discutere degli EIP candidati a Cancun. Le discussioni sulla portata degli aggiornamenti a Cancun dovrebbero iniziare seriamente all'inizio del prossimo anno.
Cerimonia KZG
Un'altra cosa da aspettarsi in relazione all'aggiornamento di Cancun è la cerimonia KZG, che è un requisito di EIP-4844.
Questo rituale genererà la casualità necessaria per verificare la validità dei dati blob. Perché sia considerato sicuro, è necessario che solo un partecipante sia onesto. In altre parole, se tutti i partecipanti tranne uno sono collusi, l’intero processo è crittograficamente sicuro.
La cerimonia inizierà a gennaio e sarà aperta a tutti per diversi mesi. Con un obiettivo di 10.000 partecipanti, si prevede che sarà la cerimonia più grande del suo genere fino ad oggi! Se vuoi essere sicuro di non perderlo, segui Trent Van Epps su Twitter!
Processo di aggiornamento post-fusione
Come accennato nell'aggiornamento precedente, dopo la fusione, coordinare il processo di aggiornamento di Ethereum a livello di esecuzione e di consenso è un aspetto importante da fare. Da una prospettiva di alto livello, il livello di esecuzione utilizza Yellow Paper e EIP per descrivere le modifiche, mentre il livello di consenso utilizza le specifiche Python eseguibili.
Il vantaggio del processo del livello esecutivo è che l’EIP è ben noto alla comunità ed è formattato in modo da dimostrare chiaramente il ragionamento alla base della proposta. I libri gialli con molti contenuti matematici associati agli EIP e la necessità di reinserire le specifiche nel contesto di ciascun EIP rendono le specifiche del livello di esecuzione difficili da comprendere ed estendere.
Il problema con il livello di consenso è l’opposto: ha una specifica chiara e comprensibile in un unico repository, ma i cambiamenti non sono tangibili e le proposte sono sepolte in altre PR pubbliche nel repository.
Con l'introduzione delle specifiche del livello di esecuzione di Ethereum, speriamo di ridurre questo divario dal lato del livello di esecuzione. E, con qualche discussione sul processo, potremmo essere in grado di introdurre l’EIP nel processo del livello di consenso!
Detto questo, quando l’ambito dell’aggiornamento di Shanghai è stato discusso e finalizzato, è diventato chiaro che un’altra parte del processo potrebbe mancare: consentire alla comunità di esprimere le proprie preferenze relative ai cambiamenti e impegnarsi in discussioni sull’intero ambito dell’aggiornamento (piuttosto che singoli EIP) Discutilo sul posto e rendilo parte delle decisioni della riunione di AllCoreDevs e del livello di consenso.
Non è ancora chiaro come sarà: mi piacerebbe ricevere suggerimenti! — ma man mano che il numero delle parti interessate attivamente coinvolte nelle modifiche al protocollo cresceva, così come il numero di aree interessate dalle modifiche di livello 1, era chiaro che avevamo bisogno di qualcosa.
Fortunatamente non è necessario ripartire da zero. Ethereum Magicians esiste da anni e i suoi incontri offline, riunioni di gruppo dedicate o riunioni di comunità possono essere buoni punti di partenza per l'espansione.
Aspettatevi ulteriori progressi su questo fronte all’inizio del 2023!
Aggiornamento dell'Accordo Gilda
Con il progetto pilota di Protocol Guild (PG) ormai a metà, hanno pubblicato un rapporto per dare un'occhiata a come stanno andando le cose e considerare quali sono i prossimi passi per il progetto.
Ti ricordiamo che PG è un meccanismo di finanziamento senza autorizzazione per sviluppatori client Ethereum Layer 1, ricercatori di protocolli e contributori di supporto (come te).
Questo meccanismo è centrato sull’individuo, non sull’organizzazione. In breve, ogni membro ha diritto a una quota dei token della gilda, ponderata in base al tempo in cui ha contribuito a Ethereum. L'aggiunta e l'eliminazione dei membri avviene in vero stile Ethereum, sulla base di una serie di standard e di un consenso approssimativo all'interno di PG. Questo elenco verrà quindi messo in catena utilizzando il contratto diviso 0xSplit. Il donatore può quindi inviare i fondi direttamente all'indirizzo del destinatario o ad un contratto di maturazione che rilascia fondi all'indirizzo del destinatario.
Il rapporto provvisorio pilota è riassunto in questo tweet. Ecco alcuni punti salienti
Il progetto pilota ha raccolto 9,7 milioni di dollari da organizzazioni come Lido, Uniswap, ENS, NounsDAO e MolochDAO, nonché da donatori regolari di privati (grazie Tetranode!) - grazie a tutti per averlo reso possibile!
PG aveva 90 membri al momento del lancio e ora ne ha 128, con 5 milioni di dollari distribuiti tra loro
In media, ogni membro ha ricevuto $ 39.000, il minimo è stato di $ 13.000 e il massimo ha raggiunto $ 79.000
L'architettura di PG sta cambiando e supporterà L2 ed eliminerà la necessità di multi-sig per aggiornare i pesi
Questi primi risultati mostrano che PG sta funzionando come previsto: un meccanismo per distribuire un paniere di token a un gruppo crescente e autoincubante di contributori al protocollo. Questo progetto non sarebbe quello che è oggi senza il generoso sostegno dei donatori pilota.
Guardando al futuro, ora è il momento di espandere la portata di PG e realizzare il suo pieno potenziale: fornire ai manutentori di Ethereum compensi competitivi e adeguati al rischio. La cosa più semplice da fare qui è che il progetto faccia una donazione a PG fin dall'inizio, come ha detto Danny Ryan nel tweet di lancio di PG.
La maggior parte delle donazioni nel progetto pilota provenivano da grandi progetti con ingenti finanziamenti. Se la Protocol Guild riesce a convincere questi progetti a donare a PG fin dal primo giorno, quando i loro token sono ancora veramente “privi di valore”, allora i manutentori di Ethereum potranno beneficiare dell’intera traiettoria ascendente di questi progetti di successo.
Quando sono coinvolti un numero sufficiente di progetti, gli incentivi possono mantenere i migliori talenti negli accordi di manutenzione invece di allontanarli.
Per supportare questo, e molti altri tipi di donazioni, PG avrà bisogno di una revisione tecnologica. La prossima versione supporterà L1 e L2 e ridurrà ulteriormente la sua impronta di governance on-chain.
Se sei un progetto che vorrebbe donare alla Protocol Guild, contattami: i miei DM sono aperti!
Seguito
Questo conclude il 2022... Che anno straordinario! Tre mesi fa non eravamo nemmeno fusi! Ora che Ethereum ha la prova della partecipazione in esecuzione silenziosamente in background, l'attenzione si è spostata sulle transazioni future.
Dato che tutti ritorneranno a gennaio, puoi aspettarti:
Shanghai/Capella ha aggiornato il testnet degli sviluppatori e il fork ombra
La cerimonia KZG è online
Discussioni su Cancun e su come il processo di aggiornamento della rete dovrebbe evolversi per catturare meglio le preferenze della comunità
Il protocollo pilota della gilda terminerà e annunceremo la struttura post-pilota.