Un ringraziamento speciale a Liraz Siri, Yoav Weiss e ai feedback e revisioni degli sviluppatori di ImToken, Metamask e OKX.
Uno strato chiave nello stack infrastrutturale di Ethereum è il portafoglio, ma spesso è sottovalutato dai ricercatori e sviluppatori core di L1. Il portafoglio è la finestra tra l'utente e il mondo Ethereum, e gli utenti possono trarre vantaggio da qualsiasi attributo decentralizzato, resistente alla censura, sicuro, privato o altro offerto da Ethereum e dalle sue applicazioni, a condizione che il portafoglio stesso possieda anche tali attributi.
Recentemente, abbiamo visto i portafogli Ethereum fare grandi progressi nel migliorare l'esperienza utente, la sicurezza e la funzionalità. L'obiettivo di questo articolo è fornire la mia visione su alcune delle caratteristiche che un ideale portafoglio Ethereum dovrebbe avere. Non è un elenco completo; riflette le mie inclinazioni da crittografo, focalizzate sulla sicurezza e sulla privacy, ed è quasi certo che sia incompleto in termini di esperienza utente. Tuttavia, credo che una lista dei desideri sia meno efficace nell'ottimizzare l'esperienza utente rispetto a un semplice dispiegamento e iterazione basati su feedback, quindi ritengo che sia più prezioso concentrarsi sulle proprietà di sicurezza e privacy.
Esperienza utente per transazioni cross-L2
Ora c'è una roadmap sempre più dettagliata per migliorare l'esperienza utente cross-L2, che ha parti a breve e lungo termine. Qui parlerò della parte a breve termine: idee che possono teoricamente essere implementate anche oggi.
L'idea centrale è (i) invii cross-L2 integrati e (ii) indirizzi e richieste di pagamento specifiche per la catena. Il tuo portafoglio dovrebbe essere in grado di fornirti un indirizzo (seguendo lo stile di questa bozza ERC), come segue:
Quando qualcuno (o alcune applicazioni) ti fornisce un indirizzo in questo formato, dovresti essere in grado di incollarlo nel campo "destinatario" del portafoglio e poi cliccare su "invia". Il portafoglio dovrebbe gestire automaticamente i dati da inviare in qualsiasi modo possibile:
Se hai già abbastanza dei token richiesti sulla catena di destinazione, invia i token direttamente.
Se hai il tipo di token richiesto su un'altra catena (o su più catene), utilizza protocolli come ERC-7683 (che è effettivamente un DEX cross-chain) per inviare i token.
Se hai diversi tipi di token sulla stessa catena o su altre catene, usa un exchange decentralizzato per convertirli nella valuta del tipo corretto 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 di interfaccia di portafoglio possibile con supporto per indirizzi cross-chain
Il contenuto sopra si applica al caso d'uso "Hai copiato e incollato l'indirizzo (o ENS, ad esempio, vitalik.eth @ optimism.eth) e qualcuno ti ha pagato". Se un dapp richiede un deposito (ad esempio, vedi questo esempio di Polymarket), allora il flusso ideale è espandere l'API web3 e consentire al dapp di emettere richieste di pagamento specifiche per la catena. Il tuo portafoglio sarà quindi in grado di soddisfare quella richiesta in qualsiasi modo necessario. Per garantire una buona esperienza utente, sarà necessario anche standardizzare la richiesta getAvailableBalance e il portafoglio dovrà considerare seriamente su quali catene memorizzare di default gli asset degli utenti, per massimizzare la sicurezza e la comodità delle transazioni.
Le richieste di pagamento specifiche per la catena possono essere messe anche in un codice QR, e i portafogli mobili possono scansionare il codice QR. In scenari di pagamento dei consumatori faccia a faccia (o online), il destinatario emetterà un codice QR o una chiamata API web3, indicando "Voglio X unità di token YZ sulla catena, con ID di riferimento o callback W", e il portafoglio sarà in grado di soddisfare quella richiesta in qualsiasi modo. Un'altra opzione è il protocollo di claim link, in cui il portafoglio dell'utente genera un codice QR o un URL contenente l'autorizzazione al claim per prelevare una certa quantità di fondi dal loro contratto sulla catena, e il compito del destinatario è capire come trasferire quei 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 pagare automaticamente il gas sulla catena in cui hai ETH usando protocolli (ad esempio, RIP-7755). 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 direttamente il gas lì (poiché è più economico).
Sicurezza dell'account
Un modo per concettualizzare le sfide della sicurezza degli account è che un buon portafoglio dovrebbe funzionare bene in due direzioni: (i) proteggere gli utenti dagli attacchi o dalle malefatte dei sviluppatori di portafogli, e (ii) proteggere gli utenti dagli effetti dei propri errori.
L'"errore" a sinistra è stato involontario. Tuttavia, quando l'ho visto, ho realizzato che si adattava perfettamente al contesto, quindi ho deciso di mantenerlo.
La mia soluzione preferita per questo, da oltre dieci anni, è stata il recupero sociale e portafogli multi-firma, con controllo di accesso gerarchico. Gli account degli utenti hanno due strati di chiavi: una chiave principale e N tutori (ad esempio, N = 5). La chiave principale è in grado di eseguire operazioni di basso valore e non finanziarie. La maggior parte dei tutori deve eseguire (i) operazioni di alto valore, come inviare tutto il valore nell'account, o (ii) cambiare la chiave principale o qualsiasi tutore. Se necessario, la chiave principale può essere autorizzata a eseguire operazioni di alto valore tramite un blocco temporale.
Quanto sopra è il design di base, che può essere ampliato. Le chiavi di sessione e meccanismi di autorizzazione come ERC-7715 possono aiutare a supportare diversi equilibri tra comodità e sicurezza per le varie applicazioni. Architetture di tutori più complesse, come avere più durate di blocco temporale a soglie diverse, possono aiutare a massimizzare le possibilità di recuperare con successo un account legittimo, riducendo al contempo il rischio di furto.
Quanto sopra è il design di base, che può essere ampliato. Le chiavi di sessione e meccanismi di autorizzazione come ERC-7715 possono aiutare a supportare diversi equilibri tra comodità e sicurezza per le varie applicazioni. Architetture di tutori più complesse, come avere più durate di blocco temporale a soglie diverse, possono aiutare a massimizzare le possibilità di recuperare con successo un account legittimo, riducendo al contempo il rischio di furto.
Chi o cosa dovrebbero essere i tutori?
Per un utente esperto di criptovalute nella comunità, una scelta praticabile è la chiave dei tuoi amici e familiari. Se chiedi a tutti di fornirti un nuovo indirizzo, nessuno deve sapere chi è - infatti, i tuoi tutori non devono nemmeno sapere l'uno dell'altro. Se non ti fanno la spia, è improbabile che stiano cospirando. Tuttavia, per la maggior parte dei nuovi utenti, questa opzione non è disponibile.
La seconda opzione è il tutore istituzionale: aziende che forniscono servizi di firma delle transazioni solo quando ricevono conferme di altre informazioni su richiesta: ad esempio, codici di conferma, o videochiamate per utenti di alto valore. Le persone hanno cercato a lungo di creare questi, ad esempio. ho presentato CryptoCorp nel 2013. Tuttavia, fino ad ora, queste aziende non hanno avuto molto successo.
La terza opzione è più dispositivi personali (come telefoni, desktop, portafogli hardware). Questo può funzionare, ma è anche difficile da configurare e gestire per utenti inesperti. C'è anche il rischio che più dispositivi vengano persi o rubati contemporaneamente, specialmente se si trovano nello stesso luogo.
Recentemente, abbiamo iniziato a vedere più basato su chiavi universali. Le chiavi possono essere solo backup sul tuo dispositivo, rendendole una soluzione personale, e possono anche essere backup nel cloud, rendendo la loro sicurezza dipendente da complesse ipotesi di sicurezza crittografica, istituzionale e hardware affidabile. In effetti, le chiavi rappresentano un prezioso guadagno di sicurezza per l'utente comune, ma da sole non sono sufficienti a 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, ecc. Fondamentalmente, puoi prendere ID centralizzati in varie forme (aziende o governi) e convertirli in un indirizzo Ethereum, e puoi inviare transazioni solo generando una prova di possesso dell'ID centralizzato tramite ZK-SNARK.
Con questo supplemento, ora abbiamo un ampio ventaglio di scelte, e l'ID centralizzato avvolto in ZK ha una "facilità d'uso per i principianti" unica.
Per questo, è necessario realizzarlo tramite un'interfaccia utente semplificata e integrata: dovresti essere in grado di specificare solo che desideri "example@gmail.com" come tutore, e dovrebbe generare automaticamente l'indirizzo Ethereum zk-email corrispondente sotto il cofano. Gli utenti esperti dovrebbero essere in grado di inserire la loro email (e potenzialmente il sale di privacy memorizzato in quella email) in un'applicazione di terze parti open source e confermare che l'indirizzo generato è corretto. Lo stesso dovrebbe valere per qualsiasi altro tipo di tutore supportato.
Da notare che oggi uno dei problemi pratici che affrontano i zk-email è la dipendenza dalla firma DKIM, che utilizza una chiave che cambia ogni pochi mesi e queste chiavi non sono state firmate da alcun altro ente. Questo significa che i zk-email di oggi hanno un certo grado di fiducia che va oltre il fornitore stesso; se zk-email utilizza TLSNotary su hardware fidato per verificare le chiavi aggiornate, questo potrebbe ridurre la situazione, ma non è ideale. Si spera che i fornitori di email inizino a firmare direttamente le loro chiavi DKIM. Oggi, suggerisco a un tutore di utilizzare zk-email, ma non consiglio la maggior parte dei tutori di usarlo: non memorizzare fondi in zk-email danneggiato significa che non puoi utilizzare i fondi.
Nuovi utenti e portafogli in-app
I nuovi utenti in realtà non vogliono inserire un gran numero di tutori al momento della prima registrazione. Pertanto, il portafoglio dovrebbe fornire loro un'opzione molto semplice. Un modo naturale è utilizzare zk-email sul loro indirizzo email, chiavi memorizzate localmente sul dispositivo dell'utente (potenzialmente una chiave universale) e una chiave di backup detenuta dal fornitore, per una scelta 2 di 3. Con l'aumentare dell'esperienza degli utenti o dell'accumulo di più asset, dovrebbe esserci un promemoria per aggiungere più tutori in un certo momento.
L'integrazione del portafoglio nelle applicazioni è inevitabile, poiché le applicazioni che cercano di attrarre utenti non crittografici non vogliono che gli utenti debbano scaricare simultaneamente due nuove applicazioni (l'app stessa, più il portafoglio Ethereum) per evitare un'esperienza utente disordinata. Tuttavia, molti utenti di portafogli delle applicazioni dovrebbero essere in grado di collegare tutti i loro portafogli insieme, in modo da doversi preoccupare solo di un "problema di controllo degli accessi". Il client Farcaster Warpcast ha già supportato questo:
Per impostazione predefinita, il recupero del tuo account Warpcast è controllato dal team Warpcast. Tuttavia, puoi "prendere il controllo" del tuo account Farcaster e cambiare il recupero nel tuo indirizzo.
Proteggere gli utenti da frodi e altre minacce esterne
Oltre alla sicurezza dell'account, i portafogli di oggi stanno facendo molto per identificare indirizzi falsi, phishing, frodi e altre minacce esterne e proteggere gli utenti da tali minacce. Nel frattempo, molte contromisure sono ancora piuttosto primitive: ad esempio, richiedere un clic per inviare ETH o altri token a qualsiasi nuovo indirizzo, sia che tu stia inviando 100 dollari o 100.000 dollari. Qui non esiste una soluzione unica. Si tratta di una serie di correzioni e miglioramenti lenti e continui per diverse categorie di minacce. Tuttavia, continuare a lavorare per migliorare qui ha molto valore.
Privacy
È ora di iniziare a prendere seriamente in considerazione la privacy su Ethereum. La tecnologia ZK-SNARK è ora molto avanzata e le tecnologie per la privacy che non si basano su backdoor per ridurre i rischi di conformità (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, fino ad ora, effettuare trasferimenti privati su Ethereum richiede che gli utenti scarichino e utilizzino esplicitamente "portafogli di privacy", come Railway (o Umbra per indirizzi invisibili). Ciò comporta un'enorme scomodità e riduce il numero di persone disposte a effettuare trasferimenti privati. La soluzione è che i trasferimenti privati devono essere integrati direttamente nel portafoglio.
Un'implementazione semplice è la seguente. Il portafoglio può 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 ha bisogno di 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, protocollo defi). I depositi provengono dal pool di privacy, e i prelievi vanno direttamente nel pool di privacy. Questo consente di disconnettere le attività dell'utente in una qualsiasi applicazione dalle sue attività in altre applicazioni.
Un vantaggio di questa tecnologia è che non è solo un modo naturale per il trasferimento di asset riservati, ma anche un modo naturale per l'identità riservata. L'identità è già avvenuta sulla catena: qualsiasi applicazione con prova di identità gated (ad esempio, Gitcoin Grants), qualsiasi chat gated da token, protocolli che seguono Ethereum, ecc. sono identità on-chain. Vogliamo che questo ecosistema protegga anche la privacy. Ciò significa che le attività degli utenti sulla catena non dovrebbero essere raccolte in un unico posto: ogni progetto dovrebbe essere memorizzato separatamente e il portafoglio degli utenti dovrebbe essere l'unica cosa che ha una "visione globale" in grado di vedere tutte le loro prove contemporaneamente. Un ecosistema nativo in cui ogni utente possiede più account aiuta a raggiungere questo obiettivo, così come i protocolli di prova off-chain come EAS e Zupass.
Questo rappresenta una visione pragmatica della privacy su Ethereum a medio termine. Sebbene alcune funzionalità possano essere introdotte su L1 e L2 per rendere la protezione della privacy più efficiente e affidabile, è già realizzabile ora. Alcuni sostenitori della privacy ritengono che l'unica cosa accettabile sia la privacy totale di ogni cosa: cifrare l'intero EVM. Penso che questo possa essere il risultato ideale a lungo termine, ma richiede una ripensamento più radicale del modello di programmazione e attualmente non è al livello di maturità pronto per essere implementato su Ethereum. Abbiamo davvero bisogno della privacy per default per ottenere un insieme anonimo sufficientemente grande. Tuttavia, concentrarsi prima su (i) trasferimenti tra account e (ii) identità e casi d'uso correlati all'identità (ad esempio, prove private) è un primo passo pragmatico, più facile da realizzare, e i portafogli possono iniziare a usarlo ora.
I portafogli Ethereum devono anche diventare portafogli di dati.
Una conseguenza di qualsiasi soluzione di privacy valida è che, sia per pagamenti, identità o altri casi d'uso, genera la necessità per gli utenti di memorizzare dati off-chain. Questo è evidente in Tornado Cash, che richiede agli utenti di conservare un "ricevuta" per ogni deposito che rappresenta da 0.1 a 100 ETH. I protocolli di privacy più moderni a volte memorizzano dati crittografati on-chain e li decrittografano con una singola chiave privata. Questo è rischioso, poiché se la chiave viene compromessa, o se i computer quantistici diventano praticabili, i dati verranno resi pubblici. Le prove off-chain come EAS e Zupass aumentano ulteriormente la necessità di memorizzare dati off-chain.
Il portafoglio deve non solo diventare il software per memorizzare l'accesso sulla catena, ma deve anche diventare il software per memorizzare i tuoi dati privati. Anche il mondo non crittografato sta diventando sempre più consapevole di questo, ad esempio. vedi il recente lavoro di Tim Berners-Lee sulla memorizzazione dei dati personali. Tutto ciò che dobbiamo risolvere riguarda il controllo robusto dell'accesso, dobbiamo anche risolvere il problema di garantire l'accessibilità dei dati e la non esposizione. Forse queste soluzioni possono sovrapporsi: se hai N tutori, utilizza la condivisione segreta M-of-N tra questi N tutori per memorizzare i tuoi dati. Proteggere i dati è essenzialmente più difficile, poiché non puoi revocare la quota di dati di qualcuno, ma dovremmo proporre soluzioni di hosting decentralizzate il più sicure possibile.
Accesso sicuro alla catena
Oggi, i portafogli si fidano dei loro fornitori RPC per dirgli qualsiasi informazione sulla catena. Questo è un difetto con due aspetti:
I fornitori RPC potrebbero tentare di rubare denaro fornendo informazioni false, ad esempio. sui prezzi di mercato.
I fornitori RPC possono estrarre informazioni private sugli utenti e sulle applicazioni e altri account con cui stanno interagendo.
Idealmente, vorremmo chiudere queste due falle. Per affrontare il primo problema, abbiamo bisogno di client leggeri standardizzati su L1 e L2, che possano verificare direttamente il consenso della blockchain. Helios ha già fatto così per L1 e ha iniziato a fare alcuni lavori preliminari per supportare alcune specifiche L2. Per coprire correttamente tutte le L2, abbiamo bisogno di uno standard per cui i contratti di configurazione rappresentativi delle L2 (utilizzati anche per indirizzi specifici per la catena) possano dichiarare una funzione, potenzialmente in modo simile a ERC-3668, contenente la logica per ottenere l'ultimo stato radice e verificare le prove di stato e le ricevute per queste radici di stato. In questo modo possiamo avere un client leggero universale, che consenta al portafoglio di verificare in modo sicuro qualsiasi stato o evento su L1 e L2.
Per privacy, l'unico modo pratico oggi è eseguire il proprio nodo completo. Tuttavia, ora che gli L2 stanno entrando nel campo visivo delle persone, è diventato sempre più difficile eseguire nodi completi per tutto. Ciò che equivale a un client leggero è la ricerca di informazioni private (PIR). La PIR comporta server che conservano copie di tutti i dati e client che inviano richieste crittografate ai server. I server eseguono calcoli su tutti i dati e restituiscono i dati richiesti al client, crittografandoli con la chiave del client, senza rivelare al server quali dati ha accesso il client.
Per mantenere l'onestà del server, i singoli progetti di database sono Merkle branch in sé, in modo che il client possa utilizzare un client leggero per verificarli.
Il carico computazionale della PIR (Private Information Retrieval, che normalmente indica un protocollo che consente agli utenti di recuperare informazioni da un database senza rivelare le informazioni recuperate) è molto elevato. Ci sono vari modi per affrontare questo problema:
Con la forza bruta: miglioramenti negli algoritmi o nell'hardware dedicato potrebbero far funzionare la PIR abbastanza velocemente. Queste tecnologie potrebbero dipendere dal pre-processing: i server possono memorizzare dati crittografati e mescolati per ogni cliente, e il cliente può interrogare quei dati. La principale sfida nell'ambiente Ethereum è adattare queste tecnologie a set di dati in rapida evoluzione (proprio come le nazioni). Questo rende il costo di calcolo in tempo reale più basso, ma probabilmente aumenta il costo complessivo di calcolo e archiviazione.
Requisiti di privacy attenuati: ad esempio, ci possono essere solo 1 milione di "mixins" per ogni ricerca, quindi il server saprà che il client può accedere a un milione di valori possibili, ma non saprà nulla di più dettagliato.
PIR multi-server: se utilizzi più server e l'ipotesi di onestà tra i server è 1 di N, allora l'algoritmo PIR sarà generalmente più veloce.
Anonimato invece di riservatezza: le richieste possono essere inviate tramite reti di miscelazione, nascondendo il mittente della richiesta, anziché nascondere il contenuto della richiesta. Tuttavia, farlo in modo efficace aumenterà inevitabilmente la latenza, peggiorando l'esperienza dell'utente.
Scoprire la giusta combinazione di tecnologie nell'ambiente Ethereum per massimizzare la privacy mantenendo l'utilità è una questione di ricerca aperta, e accolgo con favore i tentativi dei crittografi di farlo.
Portafoglio ideale per key store
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 validazione dell'account: sia per cambiare la propria chiave (ad esempio, recupero), sia per modifiche più profonde alla logica dell'account. Ci sono tre soluzioni a più strati, ordinate in base alla difficoltà crescente:
Aggiornamento di riproduzione: quando l'utente modifica la propria configurazione, il messaggio autorizzante questa modifica verrà riprodotto su ogni catena in cui il portafoglio rileva che l'utente possiede asset. È possibile che il formato del messaggio e le regole di convalida possano essere indipendenti dalla catena, quindi potrebbero essere riprodotti automaticamente su quante più catene possibile.
Key store su L1: le informazioni di configurazione risiedono su L1, e i portafogli su L2 utilizzano L1SLOAD per leggerle o chiamate statiche remote. In questo modo, è necessario aggiornare la configurazione solo su L1, e la configurazione avrà effetto automaticamente.
Key store su L2: le informazioni di configurazione risiedono su L2, e i portafogli su L2 utilizzano ZK-SNARK per leggerle. Questo è simile a (2), tranne per il fatto che l'aggiornamento del key store potrebbe essere più economico, ma d'altra parte la lettura è più costosa.
La soluzione (3) è particolarmente potente poiché si adatta bene alla privacy. Nelle normali "soluzioni di privacy", l'utente possiede segreti s, pubblica un "valore foglia" L sulla catena, e l'utente dimostra che L = hash(s, 1) e N = hash(s, 2) per alcuni segreti (mai rivelati) che controlla. Un simbolo non valido N viene pubblicato in modo che garantire che la spesa futura della stessa foglia fallisca senza rivelare L dipende dalla sicurezza dell'utente s. Una soluzione di privacy amichevole per il recupero dirà: s è una posizione (ad esempio, indirizzo e slot di archiviazione) on-chain, e l'utente deve dimostrare la query di stato: L = hash(sload(s), 1).
Sicurezza dei dapp
Il punto più debole della sicurezza degli utenti è spesso il dapp. La maggior parte delle volte, gli utenti interagiscono con le applicazioni accedendo a siti web, che scaricano implicitamente il codice dell'interfaccia utente dal server in tempo reale e lo eseguono nel browser. Se il server viene hackerato, o se il DNS viene hackerato, gli utenti riceveranno una copia falsa dell'interfaccia, che potrebbe indurli a eseguire qualsiasi operazione. Funzionalità come la simulazione delle transazioni nei portafogli sono molto utili per ridurre il rischio, ma sono ancora ben lontane dall'essere perfette.
Idealmente, sposteremmo l'ecosistema verso il versioning del contenuto on-chain: gli utenti accederanno al dapp tramite il loro nome ENS, che conterrà l'hash IPFS dell'interfaccia. Gli aggiornamenti dell'interfaccia richiederanno transazioni on-chain da una firma multi-firma o da un 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, che richiede all'utente di cliccare per accettare le richieste HTTP, non solo le operazioni web3:
Modello di interfaccia in modalità paranoica possibile
Metodi più avanzati consistono nel superare HTML + Javascript e scrivere la logica di business di un dapp in un linguaggio dedicato (potenzialmente uno strato relativamente sottile su Solidity o Vyper). Quindi, il browser può generare automaticamente l'interfaccia utente per qualsiasi funzionalità necessaria. OKContract sta già facendo questo.
Un'altra direzione è la difesa delle informazioni economiche crittografiche: gli sviluppatori di dapp, le aziende di sicurezza, i deployer di catene e altri possono stabilire un'obbligazione, se un dapp viene hackerato o danneggia gli utenti in modo altamente fuorviante, tale obbligazione pagherà agli utenti colpiti (determinati) da un DAO di arbitrato on-chain. Il portafoglio può mostrare agli utenti un punteggio basato sulla dimensione dell'obbligazione.
Futuro a lungo termine
Tutto quanto sopra avviene nel contesto di un'interfaccia tradizionale, che comporta puntare e cliccare su cose e inserire cose nei campi di testo. Tuttavia, siamo anche all'apice di un cambiamento di paradigma più profondo:
Intelligenza artificiale, che potrebbe portarci da un paradigma di digitazione cliccabile a uno in cui "dici cosa vuoi fare e i robot capiranno".
Interfacce cervello-macchina, con metodi "morbidi" come il tracciamento oculare e tecnologie più dirette o persino invasive (vedi: il primo paziente Neuralink di quest'anno).
Difesa attiva del client: il browser Brave protegge attivamente gli utenti da pubblicità, tracker e molti altri oggetti dannosi. Molti browser, plugin e portafogli crittografici hanno team interi attivamente impegnati 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 ripensamento più profondo di come funzionano le interfacce. Con input in linguaggio naturale, tracciamento oculare o, infine, interfacce cervello-macchina più dirette, insieme alla tua cronologia (forse includendo messaggi di testo, purché tutti i dati siano elaborati localmente), il "portafoglio" potrebbe chiaramente e intuitivamente capire cosa vuoi fare. Quindi, l'intelligenza artificiale può tradurre questa intuizione in un concreto "piano d'azione": una serie di interazioni on-chain e off-chain per completare ciò che desideri. Questo potrebbe ridurre notevolmente la necessità di interfacce utente di terzi. Se gli utenti interagiscono davvero con applicazioni di terzi (o altri utenti), l'intelligenza artificiale dovrebbe rappresentare gli utenti nel pensiero avverso, identificando qualsiasi minaccia e proponendo un piano d'azione per evitare la minaccia. Idealmente, queste intelligenze artificiali dovrebbero avere un ecosistema aperto, generato da diversi gruppi con bias e strutture di incentivi diversi.
Queste idee più radicali dipendono da tecnologie che oggi sono molto immature, quindi oggi non metterei i miei asset in un portafoglio che dipende da esse. Tuttavia, cose simili sembrano chiaramente essere una tendenza futura, quindi vale la pena iniziare a esplorare più attivamente in questa direzione.
