Autor | Vitalik Buterin
Compilare | Shenchao TechFlow
Unul dintre straturile cheie ale stivei de infrastructură Ethereum este portofelul, dar adesea este subestimat de cercetătorii și dezvoltatorii de bază L1. Portofelul este fereastra dintre utilizatori și lumea Ethereum, utilizatorii putând beneficia doar de orice proprietăți descentralizate, de rezistență la cenzură, securitate, confidențialitate sau alte proprietăți oferite de Ethereum și aplicațiile sale, cu condiția ca portofelul să aibă și aceste proprietăți.
Recent, am observat progrese semnificative în portofelele Ethereum în ceea ce privește îmbunătățirea experienței utilizatorului, securității și funcționalității. Scopul acestui articol este de a oferi propria mea opinie despre unele dintre caracteristicile ideale pe care ar trebui să le aibă un portofel Ethereum. Acesta nu este un listă completă; reflectă preferințele mele de criptografie care se concentrează pe securitate și confidențialitate, și este aproape sigur că nu este complet în ceea ce privește experiența utilizatorului. Cu toate acestea, cred că lista de dorințe nu este la fel de eficientă în optimizarea experienței utilizatorului ca simpla desfășurare și iterare bazată pe feedback, de aceea consider că concentrarea pe atributele de securitate și confidențialitate este cea mai valoroasă.
Experiența utilizatorului pentru tranzacții între L2
Acum există o foaie de parcurs din ce în ce mai detaliată pentru îmbunătățirea experienței utilizatorului între L2, care are părți pe termen scurt și pe termen lung. Aici voi discuta partea pe termen scurt: idei care teoretic pot fi implementate și astăzi.
Ideea principală este (i) trimiterea încrucișată încorporată între L2, și (ii) adresele specifice lanțului și cererile de plată. 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 anumite aplicații) vă oferă o adresă în acest format, ar trebui să puteți să o lipiți în câmpul „destinatar” al portofelului și să dați clic pe „trimiteți”. Portofelul ar trebui să gestioneze automat datele trimise în orice mod posibil:
· Dacă aveți deja suficiente tipuri de tokenuri necesare pe lanțul țintă, trimiteți direct tokenurile;
· Dacă aveți tipuri de tokenuri necesare pe un alt lanț (sau pe mai multe alte lanțuri), trimiteți tokenurile folosind protocoale precum ERC-7683 (de fapt, un DEX între lanțuri);
· Dacă aveți diferite tipuri de tokenuri pe același lanț sau pe alte lanțuri, folosiți un schimb descentralizat pentru a le transforma în moneda corectă pe lanț și a le trimite. Acest lucru ar trebui să necesite permisiunea explicită a utilizatorului: utilizatorul va vedea cât de multe taxe a plătit și cât a primit destinatarul.
Modelul unei interfețe de portofel cu suport pentru adrese între lanțuri
Cele de mai sus se aplică cazului de utilizare „copie și lipire a adresei (sau ENS, de exemplu, vitalik.eth @ optimism.eth) pentru a primi plata de la cineva”. Dacă dapp-ul solicită un depozit (de exemplu, vezi acest exemplu Polymarket), atunci fluxul ideal este extinderea API-ului web3 și permiterea dapp-ului să emită cereri de plată specifice lanțului. Atunci, portofelul dumneavoastră va putea satisface această cerere în orice mod necesar. Pentru a asigura o experiență bună utilizatorului, este nevoie de standardizarea cererilor getAvailableBalance, iar portofelul trebuie să ia în serios unde să stocheze implicit activele utilizatorilor pentru a maximiza securitatea și comoditatea transferului.
Cereri de plată specifice pentru lanțuri pot fi de asemenea incluse în coduri QR, iar portofelele mobile pot scana codurile QR. În scenariile de plată între consumatori (fie față în față, fie online), destinatarul va emite un cod QR sau un apel API web3, indicând „Vreau X unități de token Y Z pe lanț, cu ID de referință sau apel de întoarcere W”, iar portofelul va putea satisface această cerere în orice mod necesar. O altă opțiune este protocolul de revendicare, în care portofelul utilizatorului generează un cod QR sau un URL care conține autorizația de revendicare pentru a obține o anumită sumă de fonduri din contractul lor pe lanț, iar sarcina destinatarului este să descopere cum să transfere acele fonduri în propriul portofel.
Un alt subiect relevant este plata gazului. Dacă ați primit active pe un L2 care nu are ETH și trebuie să trimiteți o tranzacție pe acel L2, portofelul ar trebui să fie capabil să plătească automat gazul pe lanț în locul în care aveți ETH folosind un protocol (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 legate de securitatea contului este că un portofel bun ar trebui să funcționeze simultan în două direcții: (i) protejând utilizatorul de atacuri externe asupra dezvoltatorului portofelului, și (ii) protejând utilizatorul de propriile greșeli.
„Eroarea” din stânga este neintenționată. Cu toate acestea, când am văzut-o, mi-am dat seama că se potrivește foarte bine contextului, așa că am decis să o păstrez.
Soluția mea preferată pentru aceasta, timp de mai bine de un deceniu, a fost recuperarea socială și portofelele cu semnături multiple, cu control de acces ierarhic. Contul utilizatorului are două niveluri de chei: cheia principală și N tutori (de exemplu, N = 5). Cheia principală poate efectua operațiuni de valoare mică și non-financiare. Majoritatea tutorilor trebuie să execute (i) operațiuni de valoare mare, cum ar fi trimiterea întregii valori din cont sau (ii) modificarea cheii principale sau a oricărui tutor. Cheia principală poate fi autorizată să efectueze operațiuni de valoare mare prin blocări temporale, dacă este necesar.
De mai sus este designul de bază, care poate fi extins. Cheile de sesiune și mecanismele de permisiune, cum ar fi ERC-7715, pot ajuta la sprijinirea diferitelor echilibrări între comoditate și securitate în aplicații diferite. Arhitecturile mai complexe de tutori, cum ar fi cele cu mai multe perioade de blocare a timpului la diferite praguri, pot ajuta la maximizarea șanselor de recuperare cu succes a conturilor legitime, în timp ce minimizează riscurile de furt.
De mai sus este designul de bază, care poate fi extins. Cheile de sesiune și mecanismele de permisiune, cum ar fi ERC-7715, pot ajuta la sprijinirea diferitelor echilibrări între comoditate și securitate în aplicații diferite. Arhitecturile mai complexe de tutori, cum ar fi cele cu mai multe perioade de blocare a timpului la diferite praguri, pot ajuta la maximizarea șanselor de recuperare cu succes a conturilor legitime, în timp ce minimizează riscurile de furt.
Cine sau ce ar trebui să fie tutorii?
Pentru utilizatorii experimentați din comunitatea criptomonedelor, o opțiune viabilă este cheile prietenilor și familiei dumneavoastră. Dacă cereți fiecăruia să vă ofere o adresă nouă, nimeni nu trebuie să știe cine sunt - de fapt, tutorii dumneavoastră nu trebuie nici măcar să știe unul despre altul. Dacă nu s-au dus la voi să vă spună, este puțin probabil ca ei să fi colaborat. Totuși, pentru majoritatea utilizatorilor noi, această opțiune nu este disponibilă.
A doua opțiune este tutorii instituționali: companii care oferă servicii care semnează tranzacții doar după ce primesc alte informații de confirmare la cererea dumneavoastră: de exemplu, un cod de confirmare, sau un apel video pentru utilizatorii cu valoare mare. Oamenii au încercat de mult să creeze acestea, de exemplu. Am prezentat CryptoCorp în 2013. Cu toate acestea, până acum, aceste companii nu au avut 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, dificil de configurat și gestionat pentru utilizatorii neexperimentați. Există, de asemenea, riscul de a pierde sau de a avea furate dispozitivele simultan, în special atunci când acestea sunt amplasate în același loc.
Recent, am început să vedem mai multe soluții bazate pe chei unice. Cheile pot fi salvate doar pe dispozitivul dumneavoastră, făcându-le o soluție de dispozitiv personal, dar pot fi de asemenea salvate în cloud, ceea ce face ca securitatea lor să depindă de presupuneri complexe de criptografie, instituții și hardware de încredere. În practică, cheile sunt un câștig de securitate valoros pentru utilizatorii obișnuiți, dar nu sunt suficiente pentru a proteja economiile de-o viață ale utilizatorului.
Din fericire, cu ZK-SNARK, avem și a patra opțiune: ID-uri centralizate ambalate în ZK. Această tipologie include zk-email, Anon Aadhaar, Myna Wallet și altele. Practic, puteți lua ID-uri centralizate în diferite forme (companii sau guverne) și le puteți transforma în adrese Ethereum, pe care le puteți trimite doar generând o dovadă ZK-SNARK care demonstrează că dețineți ID-ul centralizat.
Cu acest supliment, avem acum o gamă largă de opțiuni, iar ID-urile centralizate ambalate în ZK au o „prietenie pentru începători” unică.
Pentru aceasta, este necesar să se realizeze printr-o interfață UI simplificată și integrată: ar trebui să puteți specifica doar că doriți „example@gmail.com” ca tutor, iar acesta ar trebui să genereze automat adresa zk-email Ethereum corespunzătoare sub capotă. Utilizatorii avansați ar trebui să fie capabili să introducă emailul lor (și poate sarea de confidențialitate care ar putea fi păstrată în acel email) într-o aplicație terță parte open-source și să confirme că adresa generată este corectă. Același lucru ar trebui să fie valabil și pentru orice alt tip de tutori acceptați.
Rețineți că o provocare practică cu care se confruntă zk-email în zilele noastre este că se bazează pe semnături DKIM, care utilizează chei care se rotesc la fiecare câteva luni, iar aceste chei nu sunt semnate de nici o altă autoritate. Acest lucru înseamnă că zk-email de astăzi are un anumit nivel de cerințe de încredere care depășește furnizorul în sine; dacă zk-email ar folosi TLSNotary pentru a verifica cheile actualizate în hardware de încredere, acest lucru ar putea reduce această problemă, dar nu este ideal. Sper că furnizorii de email vor începe să semneze direct cheile lor DKIM. Astăzi, sugerez unui tutor să folosească zk-email, dar nu sugerez majorității tutorilor să folosească: nu stocați fonduri în zk-email, deoarece deteriorarea acestuia înseamnă că nu puteți folosi fondurile.
Utilizatori noi și portofele în aplicație
Utilizatorii noi nu doresc de fapt să introducă un număr mare de tutori la prima înregistrare. Prin urmare, portofelul ar trebui să le ofere o opțiune foarte simplă. O cale naturală este să folosească zk-email pe adresa lor de email, cheia stocată local pe dispozitivul utilizatorului (poate o cheie unică) și cheia de rezervă deținută de furnizor, pentru o selecție 2-din-3. Pe măsură ce utilizatorul devine mai experimentat sau acumulează mai multe active, ar trebui să fie atenționat 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-cripto nu doresc ca utilizatorii să descarce simultan două aplicații noi (aplicația în sine, plus portofelul Ethereum), ceea ce ar crea o experiență de utilizator confuză. Totuși, utilizatorii portofelelor multe ar trebui să fie capabili să își conecteze toate portofelele, astfel încât să se preocupe doar de o „problemă de control al accesului”. Cel mai simplu mod este să adopte o schemă ierarhică, în care există un proces rapid de „legare” care le permite utilizatorilor să-și seteze portofelul principal ca tutor pentru toate portofelele 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 Farcaster și schimba recuperarea pentru adresa dumneavoastră.
Protejarea utilizatorilor de escrocherii și alte amenințări externe
Pe lângă securitatea contului, portofelele de astăzi fac, de asemenea, multe pentru a identifica adresele false, phishing, escrocherii și alte amenințări externe și depun eforturi pentru a proteja utilizatorii de astfel de amenințări. Între timp, multe măsuri sunt încă destul de primitive: de exemplu, cererea de confirmare pentru a trimite ETH sau alte tokenuri către orice adresă nouă, indiferent dacă trimiteți 100 de dolari sau 100.000 de dolari. Aici nu există un singur leac universal. Acesta este un set de remedii și îmbunătățiri lente și continue pentru diferite categorii de amenințări. Totuși, continuarea eforturilor de îmbunătățire aduce multă valoare.
Confidențialitate
Acum este timpul să începem să luăm mai în serios confidențialitatea în Ethereum. Tehnologia ZK-SNARK este acum foarte avansată, tehnologiile de confidențialitate care nu depind de backdoor-uri pentru a reduce riscurile de reglementare (de exemplu, piscinele de confidențialitate) devin din ce în ce mai mature, iar infrastructurile de nivel secundar, cum ar fi Waku și mempools ERC-4337, devin, de asemenea, mai stabile. Cu toate acestea, până acum, efectuarea de transferuri private pe Ethereum necesită ca utilizatorul să descarce explicit și să folosească „portofele de confidențialitate”, cum ar fi Railway (sau Umbra pentru adrese invizibile). Acest lucru a crescut foarte mult neplăcerile și a redus numărul celor dispuși să efectueze transferuri private. Soluția este ca transferurile private să fie integrate direct în portofele.
O implementare simplă este următoarea. Portofelul poate stoca o parte din activele utilizatorului ca „sold privat” în piscina de confidențialitate. Atunci când utilizatorul efectuează o 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 nouă adresă pentru fiecare aplicație în care utilizatorul participă (de exemplu, protocol defi). Depozitele vor proveni din piscina de confidențialitate, iar retragerile vor merge direct în piscina de confidențialitate. Acest lucru permite utilizatorului să deconecteze activitatea sa dintr-o aplicație de activitatea sa din alte aplicații.
Un avantaj al acestei tehnologii este că nu este doar o modalitate naturală de transfer de active pentru a proteja confidențialitatea, ci și o modalitate naturală de a proteja identitatea. Identitățile au avut loc pe lanț: orice aplicație care utilizează dovezi de identitate (de exemplu, Granturile Gitcoin), orice chat cu tokenuri de acces, protocoalele Ethereum etc. sunt identități pe lanț. Vrem ca acest ecosistem să protejeze și confidențialitatea. Acest lucru înseamnă că activitățile utilizatorului pe lanț nu ar trebui să fie colectate într-un singur loc: fiecare proiect ar trebui să stocheze individual, iar portofelul utilizatorului ar trebui să fie singurul care are „viziune globală”, putând vedea toate dovezile simultan. Un ecosistem nativ în care fiecare utilizator are multiple conturi ajută în acest sens, la fel ca protocoalele de dovezi off-chain, precum EAS și Zupass.
Aceasta reprezintă o viziune pragmatică a confidențialității Ethereum în termen mediu. Deși unele funcții pot fi introduse pe L1 și L2 pentru a face protecția confidențialității transferului mai eficientă și mai fiabilă, aceasta poate fi realizată acum. Unii susținători ai confidențialității consideră că singurul lucru acceptabil este confidențialitatea completă a tuturor lucrurilor: criptarea întregului EVM. Cred că acesta ar putea fi rezultatul ideal pe termen lung, dar necesită o reconsiderare mai fundamentală a modelului de programare și, în prezent, nu a ajuns la un nivel de maturitate pregătit pentru implementarea pe Ethereum. Avem cu adevărat nevoie de confidențialitate implicită pentru a obține un set de anonimat suficient de mare. Cu toate acestea, concentrându-ne mai întâi 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, iar portofelul poate începe să le utilizeze acum.
Portofelele Ethereum trebuie de asemenea să devină portofele de date
Unul dintre consecințele oricărei soluții eficiente de confidențialitate este că, fie că este vorba despre plăți, identitate sau alte cazuri de utilizare, aceasta va genera o cerere pentru utilizatorii de a stoca date off-chain. Acest lucru este evident în Tornado Cash, care cere utilizatorilor să păstreze „biletele” pentru fiecare depozit de 0.1–100 ETH. Protocoalele de confidențialitate mai moderne păstrează uneori datele criptate pe lanț și le decriptează cu o cheie privată unică. Acest lucru este riscant deoarece, dacă cheia este compromisă sau un computer cuantic devine viabil, datele vor fi expuse pe deplin. Cerința de stocare a datelor off-chain este mai evidentă în dovezile off-chain, cum ar fi EAS și Zupass.
Portofelul nu trebuie doar să devină software care stochează accesul pe lanț, ci și software care stochează datele dvs. private. Lumea non-cripto devine 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 asigurării robuste a controlului accesului, trebuie să le rezolvăm și în jurul asigurării robuste a accesibilității datelor și a neexploatării acestora. Poate că aceste soluții pot fi suprapuse: dacă aveți N tutori, utilizați partajarea secretelor M-din-N între acești N tutori pentru a vă stoca datele. Datele sunt în esență mai greu de protejat, deoarece nu puteți revoca o parte a datelor cuiva, dar ar trebui să propunem soluții de stocare descentralizate cât mai sigure.
Accesul sigur la lanț
În prezent, portofelele cred că furnizorii lor RPC le vor spune orice informație despre lanț. Aceasta este o vulnerabilitate cu două aspecte:
1. Furnizorii RPC pot încerca să fure bani oferindu-le informații false, de exemplu, despre prețurile de pe piață.
2. Furnizorii RPC pot extrage informații private despre aplicațiile și alte conturi cu care utilizatorul interacționează.
Ideal, dorim să închidem aceste două lacune. Pentru a aborda prima problemă, avem nevoie de clienți ușori standardizați pentru L1 și L2, care pot verifica direct consensul blockchain. Helios a făcut deja acest lucru pentru L1 și a lucrat la susținerea unor L2 specifice. Pentru a acoperi toate L2 corect, avem nevoie de un standard prin care contractele de configurare reprezentând L2 (folosite și pentru adrese specifice lanțului) pot declara o funcție, poate într-un mod similar cu ERC-3668, care include logica de obținere a celei mai recente rădăcini de stare și validarea dovezilor de stat și a chitanțelor pentru aceste rădăcini de state. 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ă reală astăzi este să rulați propriul nod complet. Totuși, acum L2 intră în atenția oamenilor, iar rularea unui nod complet pentru tot devine din ce în ce mai dificilă. Echivalentul unui client ușor aici este recuperarea informațiilor private (PIR). PIR implică servere care păstrează toate copiile de date și clienți care trimit cereri criptate către servere. Serverele efectuează calcule asupra tuturor datelor, returnând datele necesare clientului, criptate cu cheia clientului, fără a dezvălui serverului ce date a accesat clientul.
Pentru a menține onestitatea serverelor, diversele proiecte de bază de date sunt în sine ramuri Merkle, astfel încât clienții să poată verifica utilizând clienți ușori.
Calculul PIR (notă: se referă de obicei la „Recuperarea Informațiilor Private” - un protocol sau tehnologie care permite utilizatorilor să recupereze informații dintr-o bază de date fără a dezvălui informațiile recuperate) este foarte mare. Există mai multe modalități de a aborda această problemă:
· Prin forță brută: îmbunătățirile algoritmilor sau hardware-ului dedicat ar putea face ca PIR să ruleze suficient de repede. Aceste tehnici ar putea depinde de preprocesare: serverele pot stoca date criptate și amestecate pentru fiecare client, iar clienții pot interoga aceste date. Provocarea principală în mediu Ethereum este adaptarea acestor tehnici la seturi de date în continuă schimbare (la fel ca o națiune). Acest lucru face ca costurile de calcul în timp real să fie mai mici, dar cel mai probabil va crește costurile totale de calcul și stocare.
· Slăbirea cerințelor de confidențialitate: de exemplu, fiecare căutare poate avea doar 1 milion de „mixins”, astfel încât serverul va ști la ce un milion de valori poate accesa clientul, dar nu va ști nimic mai granular.
· PIR multi-server: Dacă folosiți mai multe servere și ipoteza de onestitate între aceste servere este de 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, mai degrabă decât conținutul cererii. Cu toate acestea, a face acest lucru eficient va crește inevitabil întârzierea, ceea ce va afecta experiența utilizatorului.
Găsirea combinației corecte de tehnologie în mediul Ethereum pentru a maximiza confidențialitatea, menținându-se totodată practică, este o problemă de cercetare deschisă, iar eu încurajez criptografii să încerce să facă acest lucru.
Portofelul ideal de chei
Pe lângă transferuri și acces la stare, un alt flux de lucru important care trebuie să funcționeze fără probleme în contextul L2 este schimbarea configurației de validare a contului: fie că este vorba despre schimbarea cheilor sale (de exemplu, recuperare), fie despre modificări mai profunde ale logicii contului. Aici există trei soluții, ordonate în funcție de dificultate:
1. Repetarea actualizărilor: atunci când utilizatorul își schimbă configurația, mesajul care autorizează această schimbare va fi reîntors pe fiecare lanț unde portofelul detectează că utilizatorul are active. Este posibil ca formatul mesajului și regulile de validare să fie independente de lanț, astfel încât să se poată reîntoarce automat pe cât mai multe lanțuri.
2. Cheia de rezervă pe L1: informațiile de configurare se află pe L1, iar portofelul de pe L2 le citește folosind L1SLOAD sau apeluri statice de la distanță. Astfel, actualizările de configurare trebuie să fie efectuate doar pe L1 și acestea vor intra automat în vigoare.
3. Cheia de rezervă pe L2: informațiile de configurare se află pe L2, iar portofelul de pe L2 le citește folosind ZK-SNARK. Acest lucru este similar cu (2), cu excepția faptului că actualizările cheii de rezervă pot fi mai ieftine, dar pe de altă parte citirea este mai scumpă.
Soluția (3) este deosebit de puternică, deoarece se potrivește bine cu confidențialitatea. În soluțiile „de confidențialitate” normale, utilizatorul deține secretul s, publicând pe lanț „valoarea frunzelor” L, utilizatorul dovedește că L = hash(s, 1) și N = hash(s, 2) pentru unele secrete (care nu au fost niciodată dezvăluite) pe care le controlează. Invalidul N este publicat, asigurându-se că cheltuielile viitoare ale aceleași frunze vor eșua fără a dezvălui L, în funcție de securitatea s a utilizatorului. O soluție de confidențialitate prietenoasă cu recuperarea ar spune: s este o locație (de exemplu, adresă și slot de stocare) pe lanț, utilizatorul trebuie să dovedească interogarea stării: L = hash(sload(s), 1).
Securitatea Dapp
Cel mai slab punct în securitatea utilizatorului este de obicei dapp. 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 în timp real de la servere și executându-l în browser. Dacă serverul este hack-uit sau DNS-ul este compromis, utilizatorii vor obține o copie falsă a interfeței, care ar putea induce în eroare utilizatorii să execute acțiuni arbitrare. Funcțiile portofelului, cum ar fi simularea tranzacțiilor, sunt foarte utile pentru reducerea riscurilor, dar acestea sunt departe de a fi perfecte.
Ideal, am dori să transferăm ecosistemul către controlul versiunii conținutului pe lanț: utilizatorii vor accesa dapp-ul prin numele lor ENS, care va conține hash-ul IPFS al interfeței. Actualizarea interfeței va necesita tranzacții pe lanț din partea unui semnatar multiplu sau a unui DAO. Portofelul va arăta utilizatorului dacă interacționează cu o interfață mai sigură pe lanț sau cu o interfață de Web2 cu securitate mai scăzută.
Pentru utilizatorii preocupați de confidențialitate, portofelul ar putea adăuga un mod paranoid, solicitând utilizatorului să apese pentru a accepta cererile HTTP, nu doar operațiile web3:
Model de interfață posibil în modul paranoid
Metodele mai avansate depășesc HTML + Javascript și scriu logica de afaceri a dapp-ului într-o limbă dedicată (probabil un strat relativ subțire peste Solidity sau Vyper). Apoi, browserul poate genera automat UI-ul pentru orice funcționalitate necesară. OKContract deja face acest lucru.
O altă direcție este apărarea informațiilor economice criptate: dezvoltatorii dapp, companiile de securitate, implementatorii de lanțuri și alții pot stabili o obligațiune, care va plăti utilizatorii afectați (determinati) de un hack asupra dapp-ului sau de o vătămare în mod extrem de înșelător, printr-un DAO de judecată pe lanț. Portofelul poate arăta utilizatorului un scor bazat pe mărimea obligațiunii.
Viitorul mai îndepărtat
Toate cele de mai sus se desfășoară în contextul interfețelor tradiționale, care implică indicarea și clicarea pe lucruri și introducerea de lucruri în câmpuri de text. Totuși, suntem, de asemenea, pe marginea unei schimbări mai profunde de paradigmă:
· Inteligența artificială ar putea duce la o schimbare de la paradigma de tip click-to-type la o paradigmă de tip „spune ce vrei să faci și robotul va înțelege”.
· Interfețe creier-computer: există metode „blânde” precum urmărirea mișcărilor ochilor, dar și tehnici mai directe sau chiar invazive (vezi: primul pacient Neuralink din acest an);
· Apărarea activă a clientului: browserul Brave protejează activ utilizatorii de reclame, trackeri și multe alte obiecte dăunătoare. Multe browsere, extensii și portofele criptografice au întreaga echipă dedicată activ protejării utilizatorilor împotriva diferitelor amenințări de securitate și confidențialitate. Acești „gardieni activi” vor deveni din ce în ce mai puternici în următorul deceniu.
Aceste trei tendințe vor duce împreună la o reconsiderare mai profundă a modului în care funcționează interfețele. Prin introducerea de inputuri naturale, urmărirea ochilor sau, în cele din urmă, prin interfețe creier-computer mai directe, împreună cu istoricul dumneavoastră (poate că 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 în „planuri de acțiune” concrete: o serie de interacțiuni pe lanț și off-chain pentru a finaliza ceea ce doriți să faceți. Acest lucru poate reduce semnificativ nevoia de interfețe de utilizator terță parte. Dacă utilizatorul interacționează cu aplicații terță parte (sau cu alți utilizatori), inteligența artificială ar trebui să gândească în mod adversarial în numele utilizatorului, identificând orice amenințări și propunând planuri de acțiune pentru a evita amenințările. Ideal, aceste inteligențe artificiale ar trebui să aibă un ecosistem deschis, generat de grupuri cu diferite prejudecăți și structuri de stimulente.
Aceste idei mai radicale depind de tehnologia care este foarte imatură astăzi, așa că nu voi pune activele mele în portofele care depind de ele. Cu toate acestea, lucruri similare par a fi evident tendința viitorului, așa că merită să începem să explorăm acest domeniu mai activ.
