Un ringraziamento speciale a Liraz Siri, Yoav Weiss e ai feedback e alle revisioni degli sviluppatori di ImToken, Metamask e OKX.
Uno strato chiave dell'infrastruttura Ethereum è il portafoglio, ma è spesso sottovalutato dai ricercatori e sviluppatori core di L1. I portafogli sono la finestra tra gli utenti e il mondo di Ethereum, e gli utenti possono beneficiare solo delle proprietà decentralizzate, resistenti alla censura, sicure, private o altre fornite da Ethereum e dalle sue applicazioni, a condizione che anche il portafoglio stesso possieda queste proprietà.
Recentemente, abbiamo visto notevoli progressi nei portafogli Ethereum per migliorare l'esperienza utente, la sicurezza e la funzionalità. Lo scopo di questo articolo è dare la mia opinione su alcune delle caratteristiche che un ideale portafoglio Ethereum dovrebbe avere. Non è un elenco completo; riflette le mie inclinazioni da crittografo, concentrandosi su sicurezza e privacy, e senza dubbio è incompleto in termini di esperienza utente. Tuttavia, credo che un elenco dei desideri non sia così efficace nell'ottimizzare l'esperienza utente come il semplice dispiegamento e iterazione basati su feedback, quindi ritengo che concentrarsi sulle proprietà di sicurezza e privacy sia il più prezioso.
Esperienza utente per transazioni cross-L2
Ora c'è una mappa sempre più dettagliata per migliorare l'esperienza degli utenti tra L2, che ha parti a breve termine e a lungo termine. Qui parlerò della parte a breve termine: idee che possono ancora essere implementate teoricamente anche oggi.
L'idea centrale è (i) invio cross-L2 integrato, e (ii) indirizzi e richieste di pagamento specifici della catena. Il tuo portafoglio dovrebbe essere in grado di fornirti un indirizzo (seguendo lo stile di questo bozza ERC), come segue:
Quando qualcuno (o alcune applicazioni) ti forniscono un indirizzo in questo formato, dovresti essere in grado di incollarlo nel campo 'destinatario' del portafoglio e poi fare clic su 'invia'. Il portafoglio dovrebbe gestire automaticamente i dati inviati in qualsiasi modo possibile:
Se hai già abbastanza token del tipo richiesto sulla catena di destinazione, invia direttamente i token
Se hai token del tipo richiesto su un'altra catena (o su più catene), utilizza protocolli come ERC-7683 (in realtà un DEX cross-chain) per inviare i token
Se hai token di tipo diverso sulla stessa catena o su altre catene, utilizza un exchange decentralizzato per convertirli nella valuta corretta sulla catena corretta e inviarli. Questo dovrebbe richiedere il consenso esplicito dell'utente: l'utente vedrà quanto ha pagato in commissioni e quanto ha ricevuto il destinatario.
Modello possibile di interfaccia di portafoglio con supporto per indirizzi cross-chain
Il contenuto di cui sopra è applicabile all'uso caso 'copi e incolla l'indirizzo (o ENS, ad esempio, vitalik.eth @ optimism.eth) per ricevere un pagamento da qualcuno'. Se il dapp richiede un deposito (ad esempio, vedere questo esempio di Polymarket), allora il flusso ideale è estendere l'API web3 e consentire al dapp di emettere richieste di pagamento specifiche per la catena. Poi, il tuo portafoglio sarà in grado di soddisfare tale richiesta in qualsiasi modo necessario. Per garantire una buona esperienza utente, è necessario anche standardizzare la richiesta getAvailableBalance e il portafoglio deve riflettere attentamente su quali catene memorizzare per impostazione predefinita gli asset degli utenti, per massimizzare la sicurezza e la comodità dei trasferimenti.
Le richieste di pagamento specifiche della catena possono anche essere inserite in un codice QR, e i portafogli mobili possono scansionare il codice QR. In scenari di pagamento al consumatore (o online) faccia a faccia, il ricevente emetterà un codice QR o una chiamata API web3, indicando 'voglio X unità di token Y Z sulla catena, con riferimento ID o callback W', il portafoglio sarà in grado di soddisfare la richiesta in qualsiasi modo necessario. Un'altra opzione è il protocollo claim link, dove il portafoglio dell'utente genera un codice QR o un URL che autorizza il recupero di una certa quantità di fondi dal loro contratto on-chain, compito del ricevente è scoprire come trasferire tali fondi nel proprio portafoglio.
Un altro tema correlato è il pagamento del gas. Se ricevi asset su un L2 senza ETH e hai bisogno di inviare una transazione su quel L2, il portafoglio dovrebbe essere in grado di utilizzare automaticamente protocolli (ad esempio RIP-7755) per pagare il gas sulla catena dove hai ETH. Se il portafoglio desidera che tu faccia più transazioni in futuro su L2, dovrebbe anche utilizzare solo DEX per inviare, ad esempio, ETH del valore di milioni di gas, in modo che le future transazioni possano spendere gas direttamente lì (poiché questo è più economico).
Sicurezza dell'account
Un modo per concettualizzare le sfide della sicurezza degli account è che un buon portafoglio dovrebbe funzionare in entrambi i modi: (i) proteggere l'utente dagli attacchi o dalle malversazioni dei sviluppatori di portafogli e (ii) proteggere l'utente dagli errori che commette.
L' 'errore' a sinistra è involontario. Tuttavia, quando l'ho visto, mi sono reso conto che si adattava molto bene al contesto, quindi ho deciso di mantenerlo.
La mia soluzione preferita a questo, per oltre dieci anni, è sempre stata il recupero sociale e i portafogli multisig, con controlli di accesso gerarchici. Gli account degli utenti hanno due livelli di chiavi: una chiave principale e N custodi (ad esempio N = 5). La chiave principale è in grado di eseguire operazioni di basso valore e non finanziare. La maggior parte dei custodi deve eseguire (i) operazioni di alto valore, come inviare tutto il valore nell'account, o (ii) modificare la chiave principale o qualsiasi custode. Se necessario, è possibile consentire alla chiave principale di eseguire operazioni di alto valore tramite un blocco temporale.
Quanto sopra rappresenta un design di base, che può essere esteso. Le chiavi di sessione e i meccanismi di autorizzazione come ERC-7715 possono aiutare a supportare l'equilibrio tra facilità d'uso e sicurezza nelle diverse applicazioni. Strutture di custodia più complesse, come avere più durate di blocco temporale a diversi livelli, possono aiutare a massimizzare le possibilità di recupero di account legittimi, riducendo al contempo il rischio di furti.
Quanto sopra rappresenta un design di base, che può essere esteso. Le chiavi di sessione e i meccanismi di autorizzazione come ERC-7715 possono aiutare a supportare l'equilibrio tra facilità d'uso e sicurezza nelle diverse applicazioni. Strutture di custodia più complesse, come avere più durate di blocco temporale a diversi livelli, possono aiutare a massimizzare le possibilità di recupero di account legittimi, riducendo al contempo il rischio di furti.
Chi dovrebbe essere o cosa dovrebbe essere il custode?
Per gli utenti esperti della comunità delle criptovalute, un'opzione praticabile è la chiave di amici e familiari. Se chiedi a tutti di fornirti un nuovo indirizzo, nessuno deve sapere chi sono - in effetti, i tuoi custodi nemmeno devono sapere chi è l'uno o l'altro. Se non ti fanno trapelare informazioni, la possibilità che siano collusi è molto bassa. Tuttavia, per la maggior parte dei nuovi utenti, questa opzione non è disponibile.
La seconda opzione è il custode istituzionale: aziende che offrono servizi di firma delle transazioni solo quando ricevono ulteriori conferme della tua richiesta: ad esempio, un codice di conferma, o una videochiamata per utenti di alto valore. Le persone hanno cercato di realizzare queste cose per molto tempo, ad esempio, ho presentato CryptoCorp nel 2013. Tuttavia, finora queste aziende non sono state molto fortunate.
La terza opzione è più dispositivi personali (ad esempio, telefono, desktop, portafoglio hardware). Questo può funzionare, ma può anche essere difficile da configurare e gestire per gli utenti inesperti. C'è anche il rischio di perdere o rubare i dispositivi contemporaneamente, specialmente se si trovano nello stesso luogo.
Recentemente, abbiamo iniziato a vedere più soluzioni basate su chiavi universali. Le chiavi possono essere backup solo sul tuo dispositivo, rendendole una soluzione personale, e possono anche essere backup nel cloud, facendo dipendere la loro sicurezza da un mix complesso di sicurezza crittografica, istituzionale e assunzioni di hardware fidato. In effetti, le chiavi rappresentano un guadagno di sicurezza prezioso per gli utenti comuni, ma fare affidamento solo su di esse non è sufficiente per proteggere i risparmi di una vita.
Fortunatamente, con ZK-SNARK, abbiamo anche una quarta opzione: ID centralizzati avvolti in ZK. Questo tipo include zk-email, Anon Aadhaar, Myna Wallet e altro. Fondamentalmente, puoi adottare forme di ID centralizzati (aziende o governi) e convertirli in un indirizzo Ethereum, e puoi inviare transazioni solo generando una prova ZK-SNARK che dimostri di possedere l'ID centralizzato.
Con questo supplemento, ora abbiamo un'ampia gamma di opzioni e l'ID centralizzato avvolto in ZK ha una 'user-friendliness' unica per i principianti.
A tal fine, è necessario realizzarlo tramite un'interfaccia semplificata e integrata: dovresti essere in grado di specificare semplicemente di voler 'example@gmail.com' come custode, e dovrebbe automaticamente generare l'indirizzo Ethereum zk-email corrispondente sotto il cofano. Gli utenti esperti dovrebbero essere in grado di inserire la loro email (e possibilmente il sale di privacy memorizzato in quell'email) in un'applicazione open source di terze parti e confermare che l'indirizzo generato è corretto. Questo dovrebbe valere anche per qualsiasi altro tipo di custode supportato.
Si noti che una sfida pratica che affronta oggi zk-email è che si basa su firme DKIM, che utilizzano chiavi che vengono ruotate ogni pochi mesi, e queste chiavi non sono state firmate da alcuna altra entità. Questo significa che oggi zk-email ha un certo grado di requisiti di fiducia che vanno oltre il fornitore stesso; se zk-email utilizza TLSNotary su hardware fidato per verificare la chiave aggiornata, questo potrebbe ridurre la situazione, ma non è ideale. Spero che i fornitori di email possano iniziare a firmare direttamente le loro chiavi DKIM. Oggi, consiglio a un custode di utilizzare zk-email, ma non consiglio a molti custodi di farlo: non conservare fondi su zk-email danneggiati significa non poter utilizzare i fondi.
Nuovi utenti e portafogli in-app
I nuovi utenti in realtà non vogliono inserire un gran numero di custodi al momento della registrazione. Pertanto, il portafoglio dovrebbe fornire loro un'opzione molto semplice. Un percorso naturale è utilizzare zk-email sul loro indirizzo email, chiavi memorizzate localmente sul dispositivo dell'utente (potenzialmente la chiave universale) e una chiave di backup detenuta dal fornitore, per una scelta 2 su 3. Man mano che gli utenti diventano più esperti o accumulano più beni, dovrebbe essere suggerito loro di aggiungere più custodi in un certo momento.
L'integrazione dei portafogli nelle applicazioni è inevitabile, poiché le applicazioni che cercano di attrarre utenti non crittografici non vogliono che gli utenti debbano scaricare contemporaneamente due nuove applicazioni (l'app stessa, più il portafoglio Ethereum) creando un'esperienza utente confusa. Tuttavia, molti utenti di portafogli dovrebbero essere in grado di collegare tutti i loro portafogli, in modo da doversi preoccupare solo di un 'problema di controllo degli accessi'. Il modo più semplice è adottare uno schema gerarchico, in cui c'è un rapido processo di 'collegamento' che consente agli utenti di impostare il proprio portafoglio principale come custode di tutti i portafogli in-app. Il client Farcaster Warpcast supporta già questo:
Per impostazione predefinita, il recupero del tuo account Warpcast è controllato dal team di Warpcast. Tuttavia, puoi 'prendere il controllo' del tuo account Farcaster e cambiare il recupero al tuo indirizzo.
Proteggere gli utenti dalle frodi e da altre minacce esterne
Oltre alla sicurezza degli account, i portafogli di oggi fanno anche molto per identificare indirizzi falsi, phishing, frodi e altre minacce esterne, cercando di proteggere gli utenti da tali minacce. Nel frattempo, molte contromisure rimangono piuttosto primitive: ad esempio, richiedere un clic per inviare ETH o altri token a qualsiasi nuovo indirizzo, indipendentemente dal fatto che tu stia inviando 100 dollari o 100.000 dollari. Non esiste una soluzione unica a questo problema. Si tratta di una serie di riparazioni e miglioramenti lenti e continui per diverse categorie di minacce. Tuttavia, continuare a lavorare per migliorare in questo ambito ha un grande valore.
Privacy
È ora di iniziare a prendere più seriamente la privacy su Ethereum. La tecnologia ZK-SNARK è ora molto avanzata, e le tecnologie per la privacy che non dipendono da backdoor per ridurre i rischi normativi (come i pool di privacy) stanno diventando sempre più mature, mentre infrastrutture di secondo livello come Waku e mempool ERC-4337 stanno lentamente diventando più stabili. Tuttavia, finora, effettuare trasferimenti privati su Ethereum richiede che gli utenti scarichino esplicitamente e utilizzino 'portafogli di privacy', come Railway (o Umbra per indirizzi invisibili). Questo aumenta notevolmente l'inconveniente e riduce il numero di persone disposte a effettuare trasferimenti privati. La soluzione è che i trasferimenti privati debbano essere integrati direttamente nel portafoglio.
Una semplice implementazione è la seguente. I portafogli possono memorizzare una parte degli asset dell'utente come 'saldo privato' in un pool di privacy. Quando l'utente effettua un trasferimento, uscirà automaticamente dal pool di privacy. Se l'utente deve ricevere fondi, il portafoglio può generare automaticamente un indirizzo invisibile.
Inoltre, il portafoglio può generare automaticamente un nuovo indirizzo per ogni applicazione a cui partecipa l'utente (ad esempio, protocolli DeFi). I depositi provenienti dal pool di privacy, i prelievi andranno direttamente nel pool di privacy. Questo consente di disconnettere le attività in un'app da quelle in altre applicazioni.
Un vantaggio di questa tecnologia è che non è solo un modo naturale per il trasferimento di asset privati, ma anche un modo naturale per proteggere l'identità privata. L'identità si è già manifestata on-chain: qualsiasi applicazione che utilizza prove di identità a controllo d'accesso (come i Grant di Gitcoin), qualsiasi chat a controllo di token, protocollo Ethereum e così via sono tutte identità on-chain. Speriamo che anche questo ecosistema protegga la privacy. Questo significa che le attività on-chain degli utenti non dovrebbero essere raccolte in un unico luogo: ogni progetto dovrebbe essere memorizzato separatamente e il portafoglio dell'utente dovrebbe essere l'unica cosa con una 'visione globale' in grado di vedere tutte le proprie prove contemporaneamente. Un ecosistema nativo in cui ogni utente possiede più account contribuisce a questo, così come le prove off-chain come EAS e Zupass.
Questo rappresenta una visione pragmatica della privacy di Ethereum a medio termine. Sebbene alcune funzionalità possano essere introdotte in L1 e L2 per rendere la protezione della privacy più efficiente e affidabile, può già essere realizzata ora. Alcuni sostenitori della privacy sostengono che l'unica cosa accettabile sia la privacy totale di tutto: crittografare l'intero EVM. Credo che questo possa essere l'ideale risultato a lungo termine, ma richiede una ripensamento più radicale del modello di programmazione e attualmente non è raggiunto un livello di maturità pronto per essere implementato su Ethereum. Abbiamo davvero bisogno di privacy per impostazione predefinita per ottenere un insieme anonimo sufficientemente ampio. Tuttavia, concentrarsi prima su (i) trasferimenti tra account e (ii) identità e casi d'uso legati all'identità (come le prove private) è un primo passo pragmatico, più facile da realizzare e che i portafogli possono già iniziare a utilizzare.
I portafogli Ethereum devono anche diventare portafogli di dati
Una conseguenza di qualsiasi soluzione di privacy valida è che, sia per i pagamenti, l'identità o altri casi d'uso, crea una domanda per gli utenti di memorizzare dati off-chain. Questo è evidente in Tornado Cash, che richiede agli utenti di conservare 'ricevute' per ogni deposito rappresentante 0,1-100 ETH. I protocolli di privacy più moderni a volte memorizzano dati criptati on-chain e li decriptano usando una singola chiave privata. Questo è rischioso, poiché se la chiave viene compromessa, o se i computer quantistici diventano praticabili, i dati diventeranno completamente pubblici. Le prove off-chain come EAS e Zupass rendono più evidente la necessità di memorizzazione dei dati off-chain.
Il portafoglio non deve solo diventare il software per memorizzare l'accesso on-chain, ma deve anche diventare il software per memorizzare i tuoi dati privati. Anche il mondo non crittografico sta diventando sempre più consapevole di questo, ad esempio, vedere il lavoro recente di Tim Berners-Lee sulla memorizzazione dei dati personali. Tutti i problemi che dobbiamo risolvere intorno a garanzie robuste per il controllo degli accessi, dobbiamo anche affrontare per garantire l'accesso ai dati in modo robusto e senza perdite. Forse queste soluzioni possono sovrapporsi: se hai N custodi, utilizza una condivisione segreta M-of-N tra questi N custodi per memorizzare i tuoi dati. I dati sono intrinsecamente più difficili da proteggere perché non puoi revocare la quota di dati di qualcuno, ma dovremmo proporre soluzioni di hosting decentralizzato il più sicure possibile.
Accesso sicuro alla catena
Oggi, i portafogli si fidano che i loro fornitori RPC diranno loro qualsiasi informazione sulla catena. Questo è un difetto che ha due aspetti:
I fornitori RPC potrebbero cercare di rubare denaro fornendo informazioni false, ad esempio sui prezzi di mercato.
I fornitori RPC possono estrarre informazioni private sugli applicativi e altri account con cui l'utente sta interagendo.
Idealmente, vogliamo chiudere queste due vulnerabilità. Per risolvere il primo problema, abbiamo bisogno di client leggeri standardizzati per L1 e L2, che possano verificare direttamente il consenso della blockchain. Helios ha già fatto questo per L1 e ha lavorato su alcuni preliminari per supportare alcuni L2 specifici. Per coprire correttamente tutti gli L2, abbiamo bisogno di uno standard tramite il quale i contratti di configurazione che rappresentano L2 (utilizzati anche per indirizzi specifici della catena) possano dichiarare una funzione, possibilmente in modo simile a ERC-3668, contenente la logica per ottenere l'ultima radice di stato e verificare le prove per questi stati e le ricevute per queste radici di stato. In questo modo possiamo avere un client leggero universale che consenta ai portafogli di verificare in modo sicuro qualsiasi stato o evento su L1 e L2.
Per la privacy, l'unico metodo praticabile oggi è eseguire il proprio nodo completo. Tuttavia, ora che L2 sta entrando nel campo visivo, diventa sempre più difficile eseguire un nodo completo per tutto. Ciò che è equivalente a un client leggero è il recupero di informazioni private (PIR). Il PIR comporta server che mantengono copie di tutti i dati e client che inviano richieste crittografate ai server. I server eseguono calcoli su tutti i dati, restituendo i dati richiesti al client, crittografati con la chiave del client, senza rivelare al server quali dati ha accesso il client.
Per mantenere l'onestà dei server, i vari progetti di database sono essi stessi rami Merkle, quindi il client può utilizzarli per verificarli con un client leggero.
Il carico computazionale del PIR (recupero di informazioni private) è molto elevato. Ci sono vari modi per affrontare questo problema:
Con la forza bruta: i miglioramenti degli algoritmi o dell'hardware dedicato potrebbero rendere il PIR sufficientemente veloce. Queste tecnologie potrebbero dipendere dalla pre-elaborazione: i server possono memorizzare dati crittografati e mescolati per ciascun client e il client può fare richieste a questi dati. La principale sfida nell'ambiente Ethereum è adattare queste tecnologie a dataset in rapido cambiamento (come le nazioni). Ciò rende i costi di calcolo in tempo reale inferiori, ma può aumentare i costi totali di calcolo e archiviazione.
Allentare i requisiti di privacy: ad esempio, ogni ricerca può avere solo 1 milione di 'mixins', quindi il server saprà quali milioni di valori potenziali sono accessibili al client, ma non saprà nulla di più dettagliato.
PIR multi-server: se utilizzi più server e l'ipotesi di onestà tra questi server è 1 di N, gli algoritmi PIR di solito funzioneranno più velocemente.
Anonimato invece di riservatezza: le richieste possono essere inviate tramite reti di miscelazione, nascondendo il mittente della richiesta, piuttosto che il contenuto della richiesta. Tuttavia, farlo in modo efficace aumenterà inevitabilmente i ritardi, peggiorando l'esperienza utente.
Scoprire la giusta combinazione tecnologica nell'ambiente Ethereum per massimizzare la privacy, mantenendo la praticità, è una questione di ricerca aperta, e accolgo con favore i tentativi dei crittografi di farlo.
Portafoglio ideale per un key vault
Oltre al trasferimento e all'accesso allo stato, un altro flusso di lavoro importante che deve funzionare senza problemi nel contesto cross-L2 è la modifica della configurazione di verifica dell'account: sia essa una modifica della chiave (ad esempio, recupero) o una modifica più profonda della logica dell'account. Qui ci sono tre soluzioni stratificate, ordinate in base alla difficoltà crescente:
Aggiornamenti di replay: quando l'utente modifica la propria configurazione, il messaggio che autorizza questa modifica verrà riprodotto on-chain per ogni catena su cui l'utente possiede asset. È possibile che il formato del messaggio e le regole di verifica possano essere indipendenti dalla catena, consentendo la riproduzione automatica su quante più catene possibile.
Key vault su L1: le informazioni di configurazione sono su L1, e il portafoglio su L2 le legge usando L1S LOAD o chiamate statiche remote. In questo modo, è necessario aggiornare la configurazione solo su L1, e la configurazione diventerà automaticamente effettiva.
Key vault su L2: le informazioni di configurazione sono su L2, e il portafoglio su L2 le legge usando ZK-SNARK. Questo è simile a (2), tranne per il fatto che l'aggiornamento del key vault può essere più economico, ma d'altra parte la lettura è più costosa.
La soluzione (3) è particolarmente potente perché si integra bene con la privacy. Nelle normali 'soluzioni di privacy', l'utente possiede un segreto s, pubblica on-chain un 'valore foglia' L, e dimostra che L = hash(s, 1) e N = hash(s, 2) per alcuni segreti (mai rivelati) di cui ha il controllo. Il simbolo non valido N viene pubblicato, rendendo sicuro che la spesa futura della stessa foglia fallirà senza rivelare L, a condizione che la sicurezza di s sia mantenuta dall'utente. Una soluzione di privacy amichevole per il recupero direbbe: s è una posizione (ad esempio indirizzo e slot di archiviazione) on-chain, e l'utente deve dimostrare lo stato della query: L = hash(sload(s), 1).
Sicurezza del dapp
Il punto più debole nella sicurezza degli utenti è spesso il dapp. La maggior parte delle volte, gli utenti interagiscono con le applicazioni accedendo a siti web, dove il sito scarica implicitamente il codice dell'interfaccia utente dal server in tempo reale e poi lo esegue nel browser. Se il server viene compromesso, o se il DNS viene attaccato, l'utente otterrà una copia falsa dell'interfaccia, che potrebbe indurre l'utente a eseguire azioni arbitrari. Funzionalità del portafoglio come la simulazione delle transazioni sono molto utili per ridurre il rischio, ma sono ancora lontane dall'essere perfette.
Idealmente, trasferiremmo l'ecosistema al controllo delle versioni dei contenuti on-chain: gli utenti accederanno all'app tramite il loro nome ENS, che conterrà l'hash IPFS dell'interfaccia. L'aggiornamento dell'interfaccia richiede transazioni on-chain da multisig o DAO. Il portafoglio mostrerà agli utenti se stanno interagendo con un'interfaccia on-chain più sicura o con un'interfaccia Web2 meno sicura. Il portafoglio può anche mostrare agli utenti se stanno interagendo con una catena sicura (ad esempio fase 1+, audit di sicurezza multipli).
Per gli utenti attenti alla privacy, il portafoglio può anche aggiungere una modalità paranoica, richiedendo agli utenti di fare clic per accettare le richieste HTTP, e non solo le operazioni web3:
Modello di interfaccia possibile per la modalità paranoica
Un approccio più avanzato è andare oltre HTML + Javascript e scrivere la logica aziendale del dapp in un linguaggio dedicato (potenzialmente uno strato relativamente sottile sopra Solidity o Vyper). Poi, il browser potrebbe generare automaticamente l'interfaccia utente per qualsiasi funzionalità richiesta. OKContract sta già facendo questo.
Un'altra direzione è la difesa delle informazioni economiche criptate: gli sviluppatori di dapp, le società di sicurezza, i deployer di catena e altri possono stabilire un'obbligazione, che sarà pagata agli utenti colpiti (determinati) da un attacco hacker al dapp o in modo altamente fuorviante da qualche DAO di arbitrato on-chain. I portafogli possono mostrare agli utenti un punteggio basato sull'importo dell'obbligazione.
Un futuro più lontano
Tutto ciò avviene nel contesto delle interfacce tradizionali, in cui si tratta di puntare e cliccare su cose e inserire dati nei campi di testo. Tuttavia, siamo anche al culmine di un cambiamento di paradigma più profondo:
Intelligenza artificiale, il che potrebbe portarci a passare dal paradigma di digitazione a clic a uno in cui 'dici cosa vuoi fare e il robot lo scoprirà'
Interfacce cervello-macchina, che comprendono metodi 'soft' come il tracciamento oculare e tecnologie più dirette o addirittura invasive (vedi: il primo paziente Neuralink di quest'anno)
Difesa proattiva del client: il browser Brave protegge attivamente gli utenti da pubblicità, tracker e molti altri oggetti dannosi. Molti browser, plugin e portafogli crittografici hanno interi team dedicati a proteggere gli utenti da varie minacce alla sicurezza e alla privacy. Questi 'guardiani attivi' diventeranno solo più forti nei prossimi dieci anni.
Queste tre tendenze porteranno a una riflessione più profonda su come funzionano le interfacce. Con l'input in linguaggio naturale, il tracciamento oculare o, infine, interfacce cervello-macchina più dirette, insieme alla tua cronologia (forse includendo messaggi di testo, purché tutti i dati vengano elaborati localmente), il 'portafoglio' può chiaramente e intuitivamente capire cosa vuoi fare. Poi, l'intelligenza artificiale può tradurre questa intuizione in un 'piano d'azione' concreto: una serie di interazioni on-chain e off-chain per completare ciò che desideri fare. Questo potrebbe ridurre notevolmente la necessità di interfacce utente di terzi. Se gli utenti interagiscono con applicazioni di terzi (o altri utenti), l'intelligenza artificiale dovrebbe pensare in modo difensivo a nome dell'utente, identificando eventuali minacce e suggerendo un piano d'azione per evitarle. Idealmente, queste intelligenze artificiali dovrebbero avere un ecosistema aperto, sviluppato da gruppi con diversi bias e strutture di incentivo.
Queste idee più radicali si basano su tecnologie oggi molto immature, quindi oggi non metterò i miei beni in portafogli che fanno affidamento su di esse. Tuttavia, cose simili sembrano essere chiaramente una tendenza futura, quindi vale la pena iniziare a esplorare più attivamente in questa direzione.
