L'agenda dei core developer del 6 agosto ha descritto quella data come una scadenza per la presentazione delle proposte, non come una decisione sul set finale di funzionalità di Hegota.

Frame Transactions è tra le proposte attualmente in revisione. Due bozze dipendenti, Keyed Nonces e Recent Roots, mostrano come quel modello transazionale potrebbe supportare i wallet e le applicazioni di privacy qualora venisse adottato.

Frame Transactions suddividono una transazione in fasi programmabili

EIP-8141, noto come Frame Transactions, propone un nuovo tipo di transazione Ethereum composto da frame programmabili.

Diversi frame potrebbero validare un'azione, approvare il pagamento del gas o eseguire la chiamata prevista dall'utente. Frame selezionati potrebbero inoltre essere raggruppati in un batch atomico: se uno fallisce, le modifiche di stato apportate dagli altri frame di quel batch verrebbero annullate.

La struttura potrebbe offrire ai wallet più opzioni native per il batching, la rotazione delle chiavi e l'autorizzazione di transazioni complesse. Potrebbe inoltre consentire a un account o a un servizio di pagare il gas mentre un altro account autorizza l'azione. Ciò rende la proposta rilevante oltre gli strumenti di privacy, poiché incide su come gli account delegano e coordinano le azioni on-chain.

Keyed Nonces creano domini di protezione dal replay separati

Ethereum utilizza normalmente un singolo nonce sequenziale per ciascun account. Quel numero determina l'ordine delle transazioni e impedisce che la stessa transazione venga eseguita due volte.

EIP-8250 sostituirebbe, per le Frame Transactions, quel singolo nonce con un insieme di chiavi nonce e un numero di sequenza. Le transazioni che utilizzano insiemi di chiavi non nulli e non sovrapposti sarebbero indipendenti dal punto di vista del replay.

Questo è importante per i protocolli di privacy che utilizzano un sender condiviso, affinché ogni utente non esponga un indirizzo sender pubblico distinto. Con un'unica sequenza di nonce, un'azione ritardata può interferire con azioni non correlate inviate tramite quel sender.

Keyed Nonces affrontano quel vincolo di protezione dal replay, ma non forniscono di per sé riservatezza. Le chiavi nonce restano visibili nei dati della transazione.

La proposta conserva inoltre la regola di EIP-8141 che consente una sola Frame Transaction in sospeso per sender nella mempool pubblica. Domini nonce separati non consentirebbero quindi, da soli, che più Frame Transactions dello stesso sender restino contemporaneamente in sospeso pubblicamente.

Recent Roots evitano letture da storage modificabile durante la validazione

Le applicazioni di privacy utilizzano spesso un albero di commitment, in cui una root recente rappresenta i commitment rispetto ai quali un utente può dimostrare una spesa.

La validazione delle Frame Transactions non può leggere storage esterno arbitrario controllato da un'altra applicazione. Quello storage potrebbe cambiare mentre una transazione è in sospeso.

EIP-8272, noto come Recent Roots, propone un'alternativa limitata. Una sorgente di root scriverebbe le root in un contratto di sistema, mentre una Frame Transaction potrebbe indicare una fonte, uno slot e una root specifici nei propri dati firmati.

I client Ethereum verificherebbero quel riferimento prima dell'esecuzione del frame. L'applicazione potrebbe quindi validare una proof rispetto a una root di commitment recente senza dipendere da storage esterno variabile durante la validazione.

La proposta consente fino a 16 riferimenti a root in una singola transazione e limita per quanto tempo ciascuno resta valido.

Non renderebbe private le normali transazioni in ETH. Fornirebbe un livello infrastrutturale che le applicazioni di privacy potrebbero utilizzare insieme alle Frame Transactions, ed è per questo che il design è presentato come un elemento costitutivo piuttosto che come un sistema di privacy completo.

La scadenza non ha finalizzato Hegota

Tutti e tre gli EIP sono ancora bozze. EIP-8250 ed EIP-8272 richiedono inoltre EIP-8141, quindi nessuno dei due potrebbe essere attivato in modo indipendente.

La scadenza del 6 agosto ha semplicemente chiuso la finestra per le nuove proposte non di rilievo. Gli sviluppatori devono ancora decidere se le Frame Transactions rientrano in Hegota e, in tal caso, se i design dipendenti sono pronti a seguirle. In pratica, ciò significa che il processo di revisione riguarda ancora idoneità e preparazione, non solo se le idee siano tecnicamente interessanti.

Quella combinazione di flessibilità degli account, privacy e resilienza crittografica è visibile anche nella roadmap in evoluzione di Ethereum. Ma per ora si tratta di proposte in revisione, non di funzionalità disponibili per gli utenti di Ethereum.

Avvertenza: l'articolo ha finalità esclusivamente informative. EIP-8141, EIP-8250 ed EIP-8272 sono proposte in bozza che potrebbero cambiare, essere escluse da Hegota o non essere mai attivate.

Metodologia: questo articolo si basa sull'agenda ufficiale degli sviluppatori di Hegota e sulle specifiche in bozza di EIP-8141, EIP-8250 ed EIP-8272.