Mulțumiri speciale lui Liraz Siri, Yoav Weiss și dezvoltatorilor de la ImToken, Metamask și OKX pentru feedback-ul și revizuirile lor.
O componentă cheie a stivei de infrastructură Ethereum este portofelul, dar deseori este subestimat de cercetătorii și dezvoltatorii de bază L1. Portofelul este fereastra dintre utilizatori și lumea Ethereum, iar utilizatorii pot beneficia de orice proprietăți descentralizate, rezistente la cenzură, sigure, private sau altele oferite de Ethereum și aplicațiile sale, cu condiția ca portofelul în sine să aibă aceste proprietăți.
Recent, am observat progrese semnificative în portofelele Ethereum în ceea ce privește îmbunătățirea experienței utilizatorului, a securității și a funcționalității. Scopul acestui articol este de a oferi perspectiva mea asupra unor caracteristici pe care un portofel Ethereum ideal ar trebui să le aibă. Acesta nu este un listă completă; reflectă tendințele mele de criptopunk, care se concentrează pe securitate și confidențialitate și este aproape sigur că este incompletă în privința experienței utilizatorului. Totuși, cred că o listă de dorințe în optimizarea experienței utilizatorului nu este la fel de eficientă ca desfășurarea și iterația pe baza feedback-ului, așa că cred că accentul pe proprietățile de securitate și confidențialitate este cel mai valoros.
Experiența utilizatorului în tranzacțiile cross-L2
Acum există o foaie de parcurs din ce în ce mai detaliată pentru îmbunătățirea experienței utilizatorilor între L2, care are o parte pe termen scurt și una pe termen lung. Aici voi discuta despre partea pe termen scurt: idei care pot fi implementate teoretic chiar și astăzi.
Ideea centrală este (i) trimiterea cross-L2 integrată și (ii) cererile de plată și adresele specifice lanțului. Portofelul dumneavoastră ar trebui să fie capabil să vă ofere o adresă (urmând stilul acestui draft ERC), după cum urmează:
Când cineva (sau unele aplicații) vă oferă o adresă în acest format, ar trebui să puteți lipi aceasta în câmpul „destinatar” al portofelului și apoi să faceți clic pe „trimiteți”. Portofelul ar trebui să gestioneze automat datele trimise în orice mod posibil:
Dacă aveți deja suficiente tokenuri de tipul dorit pe lanțul țintă, trimiteți direct tokenurile.
Dacă aveți tokenuri de tipul dorit pe un alt lanț (sau pe mai multe alte lanțuri), folosiți protocoale precum ERC-7683 (de fapt, un DEX cross-chain) pentru a trimite tokenuri.
Dacă aveți tokenuri de tip diferit pe același lanț sau pe alte lanțuri, folosiți un schimb descentralizat pentru a le converti în moneda corectă pe lanțul corect și trimiteți-le. Acest lucru ar trebui să necesite permisiunea explicită a utilizatorului: utilizatorul va vedea cât a plătit și cât a primit destinatarul.
Un model de interfață posibil pentru portofele cu suport pentru adrese cross-chain
Conținutul de mai sus se aplică cazului de utilizare „îți copiezi și lipești adresa (sau ENS, de exemplu, vitalik.eth @ optimism.eth) când cineva îți trimite bani”. Dacă dapp-ul solicită un depozit (de exemplu, consultați acest exemplu Polymarket), atunci fluxul ideal este extinderea API-ului web3 și permiterea dapp-ului să emită cereri de plată specifice lanțului. Apoi, portofelul dumneavoastră va putea satisface cererea în orice mod necesar. Pentru a avea o experiență bună a utilizatorului, este necesară standardizarea cererilor getAvailableBalance, iar portofelul trebuie să ia în considerare cu seriozitate pe ce lanțuri să stocheze implicit activele utilizatorului pentru a maximiza securitatea și comoditatea transferului.
Cereri de plată specifice lanțului pot fi, de asemenea, incluse în coduri QR, iar portofelul mobil poate scana codul QR. În scenariile de plată față în față (sau online), destinatarul va emite un cod QR sau o apelare API web3, indicând „Vreau X unități de token Y Z pe lanț, cu ID de referință sau callback W”, iar portofelul va putea satisface cererea în orice mod. O altă opțiune este protocolul de linkuri de revendicare, în care portofelul utilizatorului generează un cod QR sau URL care conține autorizația de revendicare pentru a obține o sumă de fonduri din contractul lor on-chain, iar munca destinatarului este să descopere cum să transfere acele fonduri în propriul portofel.
Un alt subiect relevant este plata gazului. Dacă primiți active pe un L2 fără ETH și trebuie să trimiteți o tranzacție pe acel L2, portofelul ar trebui să poată plăti automat gazul pe lanț acolo unde aveți ETH, folosind protocoale (de exemplu, RIP-7755). Dacă portofelul dorește să vă încurajeze să efectuați mai multe tranzacții pe L2 în viitor, ar trebui să folosească doar DEX pentru a trimite, de exemplu, ETH în valoare de milioane de gaz, astfel încât tranzacțiile viitoare să poată cheltui gaz direct acolo (deoarece este mai ieftin).
Securitatea contului
O modalitate de a conceptualiza provocările de securitate ale contului este că un portofel bun ar trebui să funcționeze în ambele direcții: (i) protejarea utilizatorului de atacurile hackerilor sau atacurile malitioase din partea dezvoltatorilor portofelului și (ii) protejarea utilizatorului de greșelile proprii.
„Eroarea” de pe stânga este neintenționată. Totuși, când am văzut-o, mi-am dat seama că se potrivește foarte bine în context, așa că am decis să o păstrez.
Soluția mea preferată pentru aceasta, de mai bine de un deceniu, a fost recuperarea socială și portofelele multi-semnat, cu control de acces ierarhic. Conturile utilizatorilor au două niveluri de chei: o cheie principală și N tutori (de exemplu, N = 5). Cheia principală este capabilă să execute operațiuni de valoare mică și non-financiară. Majoritatea tutorilor trebuie să execute (i) operațiuni de mare valoare, cum ar fi trimiterea întregii valori din cont, sau (ii) schimbarea cheii principale sau a oricărui tutore. Dacă este necesar, se poate permite cheii principale să efectueze operațiuni de mare valoare prin blocări temporale.
Cele de mai sus reprezintă designul de bază, care poate fi extins. Cheile de sesiune și mecanismele de permisiune precum ERC-7715 pot ajuta la sprijinirea unui echilibru diferit între comoditate și securitate pentru diferite aplicații. Structuri de tutori mai complexe, cum ar fi cele cu mai multe perioade de blocare a timpului la praguri diferite, pot ajuta la maximizarea șanselor de recuperare a unui cont legitim, reducând în același timp riscurile de furt.
Cele de mai sus reprezintă designul de bază, care poate fi extins. Cheile de sesiune și mecanismele de permisiune precum ERC-7715 pot ajuta la sprijinirea unui echilibru diferit între comoditate și securitate pentru diferite aplicații. Structuri de tutori mai complexe, cum ar fi cele cu mai multe perioade de blocare a timpului la praguri diferite, pot ajuta la maximizarea șanselor de recuperare a unui cont legitim, reducând în același timp riscurile de furt.
Cine sau ce ar trebui să fie tutorele?
Pentru utilizatorii experimentați din comunitatea criptomonedelor, o opțiune viabilă este cheia prietenilor și familiei. Dacă cereți fiecăruia să vă ofere o adresă nouă, atunci nimeni nu trebuie să știe cine sunt - de fapt, tutorele vostru nu trebuie să știe nici ei cine sunt. Dacă nu s-au înțeles, probabilitatea ca ei să colaboreze este mică. Totuși, pentru majoritatea utilizatorilor noi, această opțiune nu este disponibilă.
A doua opțiune este tutorele instituțional: o companie care oferă servicii de semnare a tranzacțiilor doar atunci când primește informații suplimentare de confirmare de la dumneavoastră: de exemplu, un cod de confirmare sau un apel video pentru utilizatorii de mare valoare. Oamenii au încercat de mult să creeze aceste servicii, de exemplu, eu am prezentat CryptoCorp în 2013. Cu toate acestea, până acum, aceste companii nu au avut prea mult succes.
A treia opțiune este mai multe dispozitive personale (de exemplu, telefon, desktop, portofel hardware). Acest lucru poate funcționa, dar este, de asemenea, greu de configurat și gestionat pentru utilizatorii fără experiență. Există, de asemenea, riscul de a pierde sau de a fi furate mai multe dispozitive, mai ales când acestea se află în aceeași locație.
Recent, am început să vedem mai multe soluții bazate pe cheia universală. Cheia poate fi salvată doar pe dispozitivul dumneavoastră, făcându-l o soluție pe dispozitiv personal, dar poate fi, de asemenea, salvată în cloud, ceea ce face ca securitatea să depindă de ipoteze complexe de securitate a parolei, instituționale și hardware de încredere. De fapt, cheia reprezintă un câștig valoros de securitate pentru utilizatori obișnuiți, dar singură nu este suficientă pentru a proteja economiile de-o viață ale utilizatorului.
Din fericire, având ZK-SNARK, avem și o a patra opțiune: ID centralizat înfășurat în ZK. Acest tip include zk-email, Anon Aadhaar, Myna Wallet și altele. Practic, puteți lua mai multe forme de ID centralizat (companie sau guvern) și le puteți transforma în adrese Ethereum, pe care le puteți trimite doar generând o dovadă ZK-SNARK că dețineți ID-ul centralizat.
Cu acest complement, avem acum o gamă largă de opțiuni, iar ID-ul centralizat înfășurat în ZK are o „prietenie” unică pentru începători.
Pentru aceasta, trebuie să fie realizată printr-o interfață simplificată și integrată: ar trebui să puteți specifica doar că doriți „example@gmail.com” ca tutore, iar acesta ar trebui să genereze automat adresa zk-email Ethereum corespunzătoare sub capotă. Utilizatorii avansați ar trebui să poată introduce adresa lor de email (și, eventual, sarea de confidențialitate stocată în acest email) într-o aplicație terță parte open-source și să confirme că adresa generată este corectă. Acelasi lucru ar trebui să se aplice pentru orice alt tip de tutore acceptat.
Rețineți că o provocare practică cu care se confruntă zk-email în prezent este că se bazează pe semnătura DKIM, care utilizează o cheie care se schimbă la fiecare câteva luni, iar aceste chei nu sunt semnate de nicio altă entitate. Aceasta înseamnă că zk-email de astăzi are un anumit grad de cerințe de încredere care depășesc furnizorul în sine; dacă zk-email este utilizat în hardware de încredere pentru a valida cheile actualizate, ar putea reduce acest lucru, dar nu este ideal. Sperăm că furnizorii de email vor începe să semneze direct cheile lor DKIM. Astăzi, recomand un tutore să folosească zk-email, dar nu recomand majorității tutorilor să facă acest lucru: nu stocați fonduri în zk-email, deoarece deteriorarea acestuia înseamnă că nu veți putea utiliza fondurile.
Utilizatori noi și portofele în aplicații
Utilizatorii noi nu doresc în mod real să introducă mulți tutori la prima înregistrare. Așadar, portofelul ar trebui să le ofere o opțiune foarte simplă. O cale naturală ar fi utilizarea zk-email pe adresa lor de email, chei stocate local pe dispozitivul utilizatorului (posibil cheia universală) și o cheie de rezervă păstrată de furnizor, realizând astfel o alegere 2-din-3. Pe măsură ce utilizatorul devine mai experimentat sau acumulează mai multe active, ar trebui să fie avertizat la un moment dat să adauge mai mulți tutori.
Integrarea portofelului în aplicații este inevitabilă, deoarece aplicațiile care încearcă să atragă utilizatori non-crypto nu doresc ca utilizatorii să fie nevoiți să descarce simultan două aplicații noi (aplicația în sine, plus portofelul Ethereum), ceea ce aduce o experiență utilizator confuză. Cu toate acestea, mulți utilizatori ai portofelelor aplicațiilor ar trebui să fie capabili să-și conecteze toate portofelele, astfel încât să se preocupe doar de o „problemă de control al accesului”. Cea mai simplă metodă este adoptarea unei scheme ierarhice, în care există un proces rapid de „legare”, care permite utilizatorilor să-și seteze portofelul principal ca fiind tutorele tuturor portofelelor din aplicație. Clientul Farcaster Warpcast a susținut deja acest lucru:
În mod implicit, recuperarea contului dumneavoastră Warpcast este controlată de echipa Warpcast. Totuși, puteți „prelua” contul dumneavoastră Farcaster și să schimbați recuperarea pentru adresa dumneavoastră.
Protejarea utilizatorilor de escrocherii și alte amenințări externe
În afară de securitatea contului, portofelele de astăzi fac, de asemenea, o mulțime de muncă pentru a identifica adresele false, phishing-ul, escrocheriile și alte amenințări externe, încercând să protejeze utilizatorii de astfel de amenințări. Între timp, multe măsuri de precauție sunt încă destul de primitive: de exemplu, solicitând un clic pentru a trimite ETH sau alte tokenuri către orice adresă nouă, indiferent dacă trimiteți 100 de dolari sau 100.000 de dolari. Nu există o soluție unică pentru asta. Este o serie de remedii continue și lente pentru diferite categorii de amenințări. Totuși, continuarea efortului de îmbunătățire aici are o valoare uriașă.
Confidențialitate
Acum este timpul să începem să luăm mai în serios confidențialitatea Ethereum. Tehnologia ZK-SNARK este acum foarte avansată, iar tehnologiile de confidențialitate care nu se bazează pe backdoor pentru a reduce riscurile de reglementare (de exemplu, piscinele de confidențialitate) devin din ce în ce mai mature, iar infrastructuri secundare precum Waku și mempool-urile ERC-4337 devin, de asemenea, mai stabile. Cu toate acestea, până acum, efectuarea de transferuri private pe Ethereum necesită ca utilizatorii să descarce și să folosească în mod explicit „portofele de confidențialitate”, cum ar fi Railway (sau Umbra pentru adresele invizibile). Aceasta adaugă un inconvenient uriaș și reduce numărul de persoane dispuse să efectueze transferuri private. Soluția este ca transferurile private să fie integrate direct în portofel.
O implementare simplă ar fi următoarea. Portofelul poate stoca o parte din activele utilizatorului ca „sold privat” în piscina de confidențialitate. Când utilizatorul face un transfer, acesta va ieși automat din piscina de confidențialitate. Dacă utilizatorul trebuie să primească fonduri, portofelul poate genera automat o adresă invizibilă.
În plus, portofelul poate genera automat o adresă nouă pentru fiecare aplicație în care utilizatorul participă (de exemplu, protocoale defi). Depozitele vor proveni din piscina de confidențialitate, iar retragerile vor merge direct în piscina de confidențialitate. Acest lucru permite activităților utilizatorului într-o aplicație să fie deconectate de activitățile sale din alte aplicații.
Unul dintre avantajele acestei tehnologii este că nu este doar o modalitate naturală de transfer al activelor de protecție a confidențialității, ci și o modalitate naturală de protecție a identității. Identitatea a avut loc pe lanț: orice aplicație care folosește dovezi de identitate (de exemplu, Granturi Gitcoin), orice chat cu token controlat, protocolul Ethereum etc. sunt identități on-chain. Ne dorim ca acest ecosistem să protejeze și confidențialitatea. Acest lucru înseamnă că activitatea utilizatorului pe lanț nu ar trebui să fie colectată într-un singur loc: fiecare proiect ar trebui să fie stocat separat, iar portofelul utilizatorului ar trebui să fie singurul care are o „viziune globală” care poate vedea simultan toate dovezile dumneavoastră. Un ecosistem nativ în care fiecare utilizator are mai multe conturi ajută la realizarea acestui lucru, la fel ca și protocoalele de dovadă off-chain, cum ar fi EAS și Zupass.
Aceasta reprezintă o viziune pragmatică a confidențialității Ethereum pe termen mediu. Deși unele funcții pot fi introduse în L1 și L2 pentru a face protecția confidențialității mai eficientă și mai fiabilă, aceasta poate fi realizată chiar acum. Unii susținători ai confidențialității cred că singurul lucru acceptabil este confidențialitatea totală a tuturor lucrurilor: criptarea întregului EVM. Cred că acesta ar putea fi rezultatul ideal pe termen lung, dar necesită o rethink fundamentală a modelului de programare și nu este încă la un nivel de maturitate pregătit pentru a fi implementat pe Ethereum. Cu siguranță avem nevoie de confidențialitate implicită pentru a obține un set anonim suficient de mare. Totuși, concentrarea inițială pe (i) transferurile între conturi și (ii) identitate și cazuri de utilizare legate de identitate (de exemplu, dovezi private) este un prim pas pragmatic, mai ușor de realizat și portofelul poate începe să folosească acum.
Portofelul Ethereum trebuie să devină, de asemenea, un portofel de date.
Unul dintre efectele oricărei soluții valide de confidențialitate este că, fie pentru plăți, identitate sau alte cazuri de utilizare, aceasta va genera nevoia utilizatorilor de a stoca date off-chain. Acest lucru este evident în Tornado Cash, care cere utilizatorilor să păstreze fiecare „chitanță” care reprezintă o depunere de 0.1-100 ETH. Protocoalele de confidențialitate mai moderne păstrează uneori datele criptate on-chain și le decriptează cu o singură cheie privată. Acest lucru este riscant, deoarece, dacă cheia este compromisă sau dacă computerele cuantice devin viabile, datele vor fi complet expuse. Necesitatea stocării datelor off-chain este mai evidentă în cazuri precum EAS și Zupass.
Portofelul nu trebuie să fie doar software pentru stocarea accesului on-chain, ci și software pentru stocarea datelor personale. Lumea non-criptografică devine, de asemenea, din ce în ce mai conștientă de acest lucru, de exemplu, consultați lucrările recente ale lui Tim Berners-Lee în domeniul stocării datelor personale. Toate problemele pe care trebuie să le rezolvăm în jurul garantării robuste a controlului accesului, trebuie să le rezolvăm și în jurul garantării robuste a accesibilității datelor și a non-divulgării. Poate că aceste soluții pot fi suprapuse: dacă aveți N tutori, utilizați M-din-N partajarea secretelor pentru a stoca datele. Datele sunt în mod inerent mai greu de protejat, deoarece nu puteți revoca cota de date a cuiva, dar ar trebui să propunem soluții de găzduire descentralizate cât mai sigure.
Acces sigur la lanț
În prezent, portofelele cred că furnizorii lor RPC le vor spune orice informație despre lanț. Aceasta este o vulnerabilitate, având două aspecte:
Furnizorii RPC pot încerca să fure bani furnizându-le informații false, de exemplu. despre prețurile pe piață.
Furnizorii RPC pot extrage informații private despre aplicațiile și alte conturi cu care utilizatorul interacționează.
Ideal, dorim să închidem aceste două vulnerabilități. Pentru a rezolva prima problemă, avem nevoie de clienți ușori standardizați pentru L1 și L2, care pot verifica direct consensul blockchain. Helios a realizat deja acest lucru pentru L1 și a continuat să facă unele lucrări preliminare pentru a susține unele L2 specifice. Pentru a acoperi corect toate L2, avem nevoie de un standard prin care contractele de configurare care reprezintă L2 (de asemenea, folosite pentru adrese specifice lanțului) pot declara o funcție, posibil într-un mod similar cu ERC-3668, care include logica de a obține rădăcina de stare recentă și de a verifica dovezile pentru aceste rădăcini de stare. Astfel, putem avea un client ușor universal care permite portofelului să verifice în siguranță orice stare sau eveniment pe L1 și L2.
Pentru confidențialitate, singura metodă realizabilă în prezent este să rulați propriul nod complet. Cu toate acestea, acum L2 intră în vizorul oamenilor, devenind din ce în ce mai dificil să rulezi un nod complet pentru tot. Ceea ce corespunde clientului ușor în acest context este recuperarea informațiilor private (PIR). PIR implică păstrarea copiilor tuturor datelor pe servere și trimiterea de cereri criptate către servere de către clienți. Serverul execută calcule pe toate datele, returnând datele necesare clientului și criptându-le cu cheia clientului, fără a dezvălui serverului ce date a accesat clientul.
Pentru a menține onestitatea serverelor, diverse proiecte de baze de date sunt în sine ramuri Merkle, astfel încât clientul poate folosi un client ușor pentru a le verifica.
Calculul PIR (Privat Information Retrieval) este foarte mare. Există mai multe căi de a aborda această problemă:
Prin forță brută: îmbunătățirile algoritmilor sau ale hardware-ului dedicat ar putea face ca PIR să funcționeze suficient de rapid. Aceste tehnici ar putea depinde de preprocesare: serverul poate stoca date criptate și amestecate pentru fiecare client, iar clientul poate interoga acele date. Provocarea principală în mediul Ethereum este adaptarea acestor tehnici la seturi de date în rapidă schimbare (la fel ca țările). Aceasta face ca costul calculului în timp real să fie mai mic, dar cel mai probabil va crește costul total al calculului și stocării.
Slăbirea cerințelor de confidențialitate: de exemplu, fiecare căutare poate avea doar un milion de „mixins”, astfel încât serverul va ști că clientul poate accesa un milion de valori posibile, dar nu va ști nimic mai detaliat.
PIR multi-server: dacă folosiți mai multe servere și ipoteza de onestitate între aceste servere este 1-din-N, atunci algoritmul PIR va fi de obicei mai rapid.
Anonimat în loc de confidențialitate: cererile pot fi trimise prin rețele mixte, ascunzând expeditorul cererii, dar nu și conținutul cererii. Totuși, a face asta eficient va crește inevitabil latența, afectând experiența utilizatorului.
Identificarea combinației corecte de tehnologie în mediul Ethereum pentru a maximiza confidențialitatea, menținând în același timp utilitatea, este o problemă deschisă de cercetare, și încurajez criptografii să încerce să o rezolve.
Portofelul ideal pentru cheia de securitate
În afară de transferuri și accesul la starea contului, un alt flux de lucru important care trebuie să funcționeze fără probleme în contextul L2 este modificarea configurației de validare a contului: fie că este vorba de schimbarea cheii (de exemplu, recuperare), fie de modificări mai profunde ale logici contului. Există trei soluții în acest sens, aranjate în ordine crescătoare a dificultății:
Actualizări de replay: atunci când utilizatorul își schimbă configurația, mesajul care autorizează această schimbare va fi reîncărcat pe fiecare lanț în care utilizatorul deține active. Este posibil ca formatul mesajului și regulile de validare să fie independente de lanț, permițând reîncărcarea automată pe cât mai multe lanțuri posibil.
Portofelul pe L1: informațiile de configurare sunt stocate pe L1, iar portofelele de pe L2 folosesc L1S LOAD pentru a le citi sau apeluri statice externe. Astfel, este necesar să actualizăm configurația doar pe L1, aceasta va avea efect automat.
Portofelul pe L2: informațiile de configurare există pe L2, iar portofelele de pe L2 folosesc ZK-SNARK pentru a le citi. Acest lucru este similar cu (2), cu excepția faptului că actualizările portofelului pot fi mai ieftine, dar citirea este mai costisitoare.
Soluția (3) este deosebit de puternică, deoarece se potrivește bine cu confidențialitatea. În soluțiile obișnuite de „confidențialitate”, utilizatorul deține un secret s, publicând pe lanț „valoarea frunzei” L, utilizatorul demonstrează L = hash(s, 1) și N = hash(s, 2) pentru unele secrete (care nu au fost niciodată divulgate) pe care le controlează. Simbolul invalid N este publicat, asigurând că cheltuielile viitoare ale aceleași frunze eșuează fără a divulga L, în funcție de securitatea utilizatorului s. O soluție de confidențialitate prietenoasă cu recuperarea ar spune: s este o locație (de exemplu, adresă și slot de stocare) on-chain, utilizatorul trebuie să demonstreze interogarea stării: L = hash(sload(s), 1).
Securitatea dapp-ului
Cea mai slabă verigă în securitatea utilizatorului este adesea dapp-ul. De cele mai multe ori, utilizatorii interacționează cu aplicațiile prin accesarea site-urilor web, site-urile descărcând implicit codul interfeței utilizatorului de la server în timp real, apoi executându-l în browser. Dacă serverul este compromis sau DNS-ul este atacat, utilizatorul va obține o copie falsă a interfeței, care ar putea îndemna utilizatorul să execute acțiuni arbitrare. Funcțiile portofelului, cum ar fi simularea tranzacțiilor, sunt foarte utile pentru reducerea riscurilor, dar sunt departe de a fi perfecte.
Ideal ar fi să transferăm ecosistemul la controlul versiunilor de conținut pe blockchain: utilizatorii vor accesa dapp-ul prin numele lor ENS, care va conține hash-ul IPFS al interfeței. Actualizările interfeței vor necesita tranzacții on-chain din partea unor semnături multiple sau DAO. Portofelul va arăta utilizatorului dacă interacționează cu o interfață on-chain mai sigură sau cu o interfață Web2 cu securitate mai scăzută. De asemenea, portofelul poate arăta utilizatorului dacă interacționează cu un lanț sigur (de exemplu, etapa 1+, audituri de securitate multiple).
Pentru utilizatorii axați pe confidențialitate, portofelul ar putea adăuga un mod de paranoia (paranoid mode), cerând utilizatorului să facă clic pentru a accepta cererile HTTP, nu doar operațiunile web3:
Modelul de interfață pentru modul de paranoia posibil
O abordare mai avansată este de a depăși HTML + Javascript și de a scrie logica de afaceri a dapp-ului într-o limbaj dedicat (poate un overlay relativ subțire pe Solidity sau Vyper). Apoi, browserul poate genera automat UI pentru orice funcționalitate necesară. OKContract face deja asta.
O altă direcție este apărarea informațiilor economice criptate: dezvoltatorii dapp, companiile de securitate, desfășurătorii de lanț și alții pot stabili o obligație, care va plăti utilizatorii afectați (după determinarea acestora) dacă dapp-ul este atacat sau dăunează utilizatorilor într-un mod foarte înșelător, printr-un DAO de arbitraj on-chain. Portofelul poate arăta utilizatorului un scor bazat pe dimensiunea obligației.
Viitorul pe termen lung
Cele de mai sus au fost realizate în contextul interfețelor tradiționale, care implică indicarea și clicarea pe lucruri, precum și introducerea de lucruri în câmpurile de text. Totuși, ne aflăm și în mijlocul unei schimbări mai profunde de paradigma:
Inteligența artificială, ceea ce ar putea conduce la o schimbare de la paradigma de tipare de clicuri la o paradigmă în care „spui ce vrei să faci, iar robotul se va ocupa de asta”
Interfața creier-mașină, atât prin metode „blânde” precum urmărirea privirii, cât și prin tehnici mai directe sau chiar invazive (vezi: primul pacient Neuralink din acest an)
Defensiva proactivă a clientului: browserul Brave protejează activ utilizatorii de reclame, urmăriri și multe alte obiecte nedorite. Multe browsere, plugin-uri și portofele criptografice au echipe întregi dedicate activ protejării utilizatorilor de diverse amenințări la securitate și confidențialitate. Acești „gardieni activi” vor deveni din ce în ce mai puternici în următorii zece ani.
Aceste trei tendințe vor duce împreună la o reexaminare mai profundă a modului în care funcționează interfețele. Prin introducerea de input-uri în limbaj natural, urmărirea privirii sau, în cele din urmă, o interfață creier-mașină mai directă, împreună cu istoricul dumneavoastră (poate incluzând mesaje text, atâta timp cât toate datele sunt procesate local), „portofelul” poate înțelege clar ce doriți să faceți. Apoi, inteligența artificială poate transforma această intuiție într-un „plan de acțiune” concret: o serie de interacțiuni on-chain și off-chain pentru a realiza ceea ce doriți. Acest lucru poate reduce semnificativ nevoia de interfețe de utilizator terțe. Dacă utilizatorul interacționează cu aplicații terțe (sau alți utilizatori), inteligența artificială ar trebui să reprezinte utilizatorul în gândirea adversarială, identificând orice amenințări și propunând un plan de acțiune pentru evitarea amenințărilor. Ideal, aceste inteligențe artificiale ar trebui să aibă un ecosistem deschis, generat de grupuri diferite cu prejudecăți și structuri de stimulente diferite.
Aceste idei mai radicale depind de tehnologia care este foarte imatură astăzi, așa că astăzi nu aș pune activele mele într-un portofel care depinde de ele. Cu toate acestea, lucruri similare par a fi evident tendința viitorului, așa că merită să începem să explorăm mai activ această direcție.
