La Ethereum Foundation sta esplorando le asserzioni sulle transazioni, che consentirebbero agli utenti di associare a una transazione condizioni vincolanti sul suo esito finale, anziché basarsi soltanto sull’approvazione dell’azione richiesta. La ricerca, parte dell’iniziativa Trillion Dollar Security, punta a colmare una lacuna nella sicurezza delle transazioni: una firma valida non garantisce che i saldi, i permessi o i controlli dell’account risultanti corrispondano a ciò che il firmatario intendeva.
Punti chiave
- I controlli proposti valuterebbero i risultati della transazione durante l’esecuzione e annullerebbero le azioni che violano una regola firmata.
- La protezione dipende da regole approvate indipendentemente da chi crea la transazione, che potrebbe essere compromesso.
- La ricerca potrebbe supportare le politiche di sicurezza dei wallet, gli agenti delegati e i flussi di lavoro dei solver, ma non è stato annunciato alcun lancio.
Indice
- Perché approvare una transazione può comunque causare una perdita
- Come le asserzioni sulle transazioni verificherebbero il risultato
- Quali informazioni renderebbe accessibili l’implementazione proposta
- Dove wallet e protocolli dovrebbero cambiare
- Quali vantaggi potrebbero ottenere gli agenti e i flussi di lavoro dei solver
- Conclusione
Perché approvare una transazione può comunque causare una perdita
Ethereum esegue la richiesta autorizzata da un utente in base al codice e allo stato disponibili al momento dell’esecuzione. Queste condizioni possono differire da quelle esaminate dall’utente. Per esempio, l’implementazione di un proxy può cambiare prima dell’esecuzione, mentre l’ordine delle transazioni può modificare il prezzo applicato a uno swap.
La fondazione distingue tra richieste fuorvianti e risultati indesiderati. Negli attacchi a Bybit e BadgerDAO, interfacce compromesse hanno presentato richieste di firma diverse da quelle che gli utenti credevano di approvare. Al contrario, anche una richiesta visualizzata correttamente può consentire un esito economicamente dannoso.
L’esempio riguarda uno swap di collaterale su Aave e CoW, con circa 50,4 milioni di dollari in aEthUSDT. La scarsa liquidità di AAVE e il limite al gas di CoW hanno lasciato disponibile una quotazione verificata di circa 329 aEthAAVE. Nonostante un avviso visibile di impatto sul prezzo del 99,9% e la conferma che l’intero valore poteva andare perduto, l’utente ha firmato e ricevuto token del valore di circa 36.000 dollari.
Questa distinzione spiega perché descrivere meglio le transazioni non sia sufficiente. Clear Signing aiuta gli utenti a comprendere l’azione richiesta. La simulazione stima gli effetti in base a uno stato selezionato della blockchain. Nessuna delle due, da sola, impone una condizione indipendente sul risultato che si verifica effettivamente.
| Elemento | Dettagli |
|---|---|
| TXTRACE | Elenca le variazioni nette dello stato e gli eventi generati dalla transazione. |
| TXDIFF | Recupera i valori iniziali e finali degli indirizzi e degli slot di storage specificati. |
| EVENTDATACOPY | Copia i dati di un evento in memoria per consentirne l’ispezione. |
| Informazioni sul deployment | I dati proposti sulle variazioni dello stato includono i contratti appena distribuiti e gli hash del loro codice. |
Come le asserzioni sulle transazioni verificherebbero il risultato
Un’asserzione confronterebbe lo stato iniziale e quello finale di una transazione tramite logica di sola lettura, dopo l’esecuzione delle sue azioni. La condizione sarebbe inclusa nella transazione e firmata insieme alle azioni. In caso di mancato rispetto, le azioni verrebbero annullate.
Tra le possibili regole figurano un importo minimo da ricevere, un limite massimo di spesa, restrizioni sulle nuove autorizzazioni dei token o la conservazione della logica di controllo di un account. La capacità di ispezione proposta va oltre i saldi e comprende storage, codice, contratti appena distribuiti ed eventi generati.
I controlli già presenti negli smart contract proteggono alcuni risultati specifici. Uniswap può rifiutare gli swap al di sotto di un output minimo specificato, mentre una guardia Safe può ispezionare lo stato dell’account dopo l’esecuzione. Il limite riguarda ciò che è possibile vedere: questi controlli devono prevedere cosa esaminare e, in genere, dipendono dalle interfacce esposte dagli altri contratti. Un proxy, per esempio, non è tenuto a fornire una funzione che riveli l’indirizzo della propria implementazione.
Le asserzioni native renderebbero disponibili per i controlli tutti gli effetti netti della transazione, comprese le modifiche che una guardia ordinaria potrebbe non sapere di dover cercare. Una visibilità più ampia è però utile solo se la regola è affidabile. Un’interfaccia malevola potrebbe fornire una condizione che consente il proprio attacco; la politica deve quindi derivare da intenzioni approvate in modo indipendente, dalla politica dell’account o dalla logica protetta del protocollo.
Quali informazioni renderebbe accessibili l’implementazione proposta
L’annuncio della fondazione sulle asserzioni native delle transazioni descrive EIP-7906 come una possibile implementazione, non come un progetto definitivo. La proposta si basa sulle transazioni a frame di EIP-8141, che organizzano le fasi di convalida e di azione in una sequenza ordinata. EIP-8141 è previsto per Hegotá; EIP-7906 ha raggiunto lo stato «Considered for Inclusion», ma non è confermato per quell’aggiornamento.
Con questo approccio, un frame POST_TX di sola lettura ispezionerebbe i risultati al termine dell’esecuzione. Le istruzioni proposte per accedere ai dati opererebbero esclusivamente all’interno di quel frame, anziché in tutta la EVM.
Le informazioni descriverebbero gli effetti netti, non la cronologia di ogni scrittura intermedia. Uno slot di storage modificato più volte sarebbe mostrato con i valori iniziale e finale; uno slot ripristinato al valore originario non comparirebbe. Per questo è importante distinguere tra l’applicazione di regole sullo stato finale e il monitoraggio di ogni fase dell’esecuzione.
In caso di esito negativo di un controllo, il corpo dell’esecuzione verrebbe annullato, ma la transazione resterebbe nel blocco come non riuscita. Chi paga il gas continuerebbe a pagare per il gas consumato, impedendo alle transazioni deliberatamente destinate a fallire di imporre ai builder l’esecuzione gratuita del lavoro.
Dove wallet e protocolli dovrebbero cambiare
La proposta fornisce un meccanismo di controllo, non un obbligo automatico di utilizzarlo. Per le transazioni di un utente, il wallet dovrebbe includere la propria politica di sicurezza nella creazione della transazione, anziché lasciare a chi la costruisce la libertà di ometterla. Tale politica potrebbe derivare dalla simulazione del wallet o applicarsi come regola permanente dell’account.
Per i protocolli, la protezione dovrebbe essere incorporata nelle condizioni di accesso a una funzione protetta. Non basterebbe fornire una transazione compatibile con le asserzioni: la chiamata dovrebbe includere il controllo specifico richiesto dal protocollo. Ciò modificherebbe i requisiti di integrazione per chi effettua le chiamate, mentre i contratti immutabili già distribuiti non potrebbero aggiungere retroattivamente tale controllo di accesso.
Queste dipendenze separano una capacità potenzialmente potente della EVM da una garanzia rivolta agli utenti. Perché la protezione sia efficace, servirebbero sia una condizione solida sia software che la renda sistematicamente inevitabile.
Quali vantaggi potrebbero ottenere gli agenti e i flussi di lavoro dei solver
Gli agenti delegati potrebbero essere vincolati non solo in base ai permessi, ma anche ai risultati. I limiti sui contratti che un agente può utilizzare o su quanto può spendere potrebbero essere affiancati da requisiti che stabiliscano cosa deve rimanere dopo ogni transazione.
Nell’esecuzione basata sui solver, un protocollo potrebbe specificare un risultato accettabile lasciando al solver la scelta del percorso. La garanzia sarebbe limitata a una transazione su una singola rete, non a un percorso che attraversa più blockchain.
Le asserzioni potrebbero anche verificare le operazioni di chiusura di un flusso di lavoro, per esempio la restituzione dei token inutilizzati e la revoca delle autorizzazioni residue. La fondazione sta raccogliendo contributi dai team di wallet e protocolli mentre il progetto prosegue: queste potenziali applicazioni sono quindi direzioni di ricerca, non funzionalità di prodotto annunciate.
Conclusione
Le asserzioni native sulle transazioni sposterebbero una parte della sicurezza delle transazioni Ethereum dall’interpretazione di una richiesta all’applicazione del suo risultato. Il loro valore pratico dipenderebbe da politiche affidabili e dall’adozione da parte dei wallet e dei protocolli incaricati di applicarle.
Leggi altre notizie
Avvertenza
Questo articolo di FinanceVelix fornisce informazioni generali e non costituisce consulenza finanziaria, d’investimento, legale o fiscale personalizzata. I prezzi delle criptovalute possono variare rapidamente e potresti perdere tutti i fondi investiti. I fatti rispecchiano le informazioni disponibili al momento della pubblicazione e possono cambiare. Verifica autonomamente le informazioni importanti e, se necessario, rivolgiti a un professionista qualificato. La menzione di un asset, di una società o di un servizio non costituisce un’approvazione.
