Titlul original: Ce mi-ar plăcea să văd într-un portofel Autorul original: Vitalik Buterin Traducerea originală: Shen Chao TechFlow
Un mare mulțumesc lui Liraz Siri, Yoav Weiss și feedback-ului și revizuirilor dezvoltatorilor de la ImToken, Metamask și OKX.
Un strat cheie al 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 de orice atribute descentralizate, rezistente la cenzură, sigure, private sau alte atribute oferite de Ethereum și aplicațiile sale, cu condiția ca portofelul însuși să aibă aceste atribute.
Recent, am început să vedem progrese semnificative în ceea ce privește portofelele Ethereum în îmbunătățirea experienței utilizatorului, securității și funcționalității. Scopul acestui articol este de a oferi propria mea viziune asupra unor caracteristici pe care un portofel Ethereum ideal ar trebui să le aibă. Aceasta nu este o listă completă; reflectă tendințele mele de criptopunk, axate pe securitate și confidențialitate, și este aproape sigur incompletă în ceea ce privește experiența utilizatorului. Cu toate acestea, cred că lista de dorințe este mai puțin eficientă în optimizarea experienței utilizatorului decât simpla desfășurare și iterație bazată pe feedback, așa că consider că concentrarea asupra atributelor de securitate și confidențialitate este cea mai valoroasă.
Experiența utilizatorului în tranzacțiile între L2
Acum există o foaie de parcurs din ce în ce mai detaliată pentru îmbunătățirea experienței utilizatorilor între L2, care are părți pe termen scurt și părți pe termen lung. Aici voi discuta despre partea pe termen scurt: idei care pot fi implementate teoretic și astăzi.
Ideea de bază este (i) trimiterea încrucișată încorporată între L2 și (ii) adresele și solicitările de plată specifice lanțului. Portofelul dvs. ar trebui să fie capabil să vă ofere o adresă (urmând stilul acestui draft ERC), după cum urmează:
Când cineva (sau anumiți 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 apoi să faceți clic pe 'Trimite'. Portofelul ar trebui să gestioneze automat datele trimise în orice mod posibil:
· Dacă aveți deja suficient din tipul de token necesar pe lanțul țintă, trimiteți direct tokenul
· Dacă aveți tokenul necesar pe un alt lanț (sau pe mai multe lanțuri), folosiți protocoale precum ERC-7683 (de fapt, un DEX între lanțuri) pentru a trimite tokenul
· Dacă aveți diferite tipuri de tokenuri 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-o. Aceasta ar trebui să necesite permisiunea explicită a utilizatorului: utilizatorul va vedea cât a plătit în taxe și cât a primit receptorul.
Un model posibil de interfață pentru un portofel cu suport pentru adrese între lanțuri
Informațiile de mai sus se aplică cazului 'Ați copiat și lipit adresa (sau ENS, de exemplu, vitalik.eth @ optimism.eth) pentru care cineva vă face o plată'. Dacă dapp solicită un depozit (de exemplu, consultați acest exemplu Polymarket), atunci fluxul ideal este extinderea API-ului web3 și permiterea dapp-ului să emită solicitări de plată specifice lanțului. Apoi, portofelul dvs. va putea satisface această solicitare în orice mod necesar. Pentru a asigura o experiență bună pentru utilizatori, este necesară standardizarea solicitărilor getAvailableBalance, iar portofelul trebuie să ia în considerare cu seriozitate pe ce lanțuri va stoca activele utilizatorilor pentru a maximiza securitatea și ușurința transferului.
Solicitările de plată specifice lanțului pot fi de asemenea incluse în coduri QR, portofelul mobil putând scana codul QR. În scenariile de plată față în față (sau online), receptorul va genera 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 această solicitare în orice mod necesar. O altă opțiune este protocolul de revendicare a link-urilor, î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 său de pe lanț, iar munca receptorului este să descopere cum să transfere aceste fonduri în propriul său portofel.
O altă temă relevantă este plata pentru gaz. 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ă fie capabil să utilizeze automat protocolul (de exemplu, RIP-7755) pentru a plăti gazul pe lanț acolo unde aveți ETH. Dacă portofelul dorește să încurajeze 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) protejarea utilizatorului de atacurile externe ale dezvoltatorilor de portofel sau atacurile malițioase și (ii) protejarea utilizatorului de propriile greșeli.
Greșelile de pe stânga sunt neintenționate. Cu toate acestea, când le-am văzut, am realizat că se potrivesc foarte bine în context, așa că am decis să le păstrez.
Soluția mea preferată pentru aceasta, de mai bine de un deceniu, a fost recuperarea socială și portofelele cu semnături multiple, cu control de acces ierarhic. Conturile utilizatorilor au două niveluri de chei: o cheie 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 mare valoare, cum ar fi trimiterea întregii valori din cont, sau (ii) modificarea cheii principale sau a oricărui tutor. Dacă este necesar, se poate permite cheii principale să execute operațiuni de mare valoare printr-o blocare temporală.
Toate cele de mai sus sunt un design de bază care poate fi extins. Cheile de sesiune și mecanismele de permisiune, cum ar fi ERC-7715, pot ajuta la sprijinirea diferitelor echilibre între confort și securitate pentru diferite aplicații. Arhitecturi de tutori mai complexe, cum ar fi cele cu mai multe durate de blocare temporală la diferite praguri, pot ajuta la maximizarea șanselor de a recupera conturi legitime, reducând în același timp riscul de furt.
Toate cele de mai sus sunt un design de bază care poate fi extins. Cheile de sesiune și mecanismele de permisiune, cum ar fi ERC-7715, pot ajuta la sprijinirea diferitelor echilibre între confort și securitate pentru diferite aplicații. Arhitecturi de tutori mai complexe, cum ar fi cele cu mai multe durate de blocare temporală la diferite praguri, pot ajuta la maximizarea șanselor de a recupera conturi legitime, reducând în același timp riscul de furt.
Cine sau ce ar trebui să fie tutorii?
Pentru utilizatorii experimentați din comunitatea criptomonedelor, o opțiune viabilă este cheia prietenilor și familiei dvs. Dacă cereți fiecăruia să vă ofere o adresă nouă, nimeni nu trebuie să știe cine sunt - de fapt, tutorii dvs. nici măcar nu trebuie să știe cine sunt ceilalți. Dacă nu au de gând să vă anunțe, probabilitatea de a conspira este foarte mică. Totuși, pentru majoritatea utilizatorilor noi, această opțiune nu este disponibilă.
A doua opțiune este tutorii instituționali: companii care oferă servicii de semnare a tranzacțiilor doar atunci când primesc informații de confirmare suplimentare de la dvs.: de exemplu, un cod de confirmare sau un apel video pentru utilizatori de mare valoare. Oamenii au încercat de mult timp să creeze aceste lucruri, de exemplu, am prezentat CryptoCorp în 2013. Totuși, până acum, aceste companii nu au avut prea mult succes.
A treia opțiune este utilizarea mai multor dispozitive personale (de exemplu, telefon, desktop, portofel hardware). Acest lucru poate funcționa, dar este de asemenea greu de configurat și gestionat pentru utilizatorii neexperimentați. Există, de asemenea, riscuri de pierdere sau furt simultan al dispozitivelor, mai ales când acestea sunt într-o singură locație.
Recent, am început să vedem mai multe soluții bazate pe chei universale. Cheia poate fi salvată doar pe dispozitivul dvs., făcându-l o soluție de dispozitiv personal, de asemenea, poate fi salvată în cloud, făcând securitatea sa să depindă de o combinație complexă de securitate a parolelor, instituțională și ipoteze de hardware de încredere. În practică, cheia reprezintă o câștigare valoroasă a securității pentru utilizatorii obișnuiți, dar nu este suficientă pentru a proteja economiile de o viață ale utilizatorilor.
Din fericire, cu ZK-SNARK, avem acum a patra opțiune: ID-uri centralizate ambalate în ZK. Acest tip include zk-email, Anon Aadhaar, Myna Wallet și altele. Practic, puteți lua ID-uri centralizate de diverse forme (companie sau guvern) și le puteți transforma în adrese Ethereum, trimițând tranzacții doar prin generarea unei dovezi ZK-SNARK care demonstrează că dețineți ID-ul centralizat.
Odată 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, trebuie să fie realizat 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ă poată introduce adresa lor de email (precum și posibila valoare de sare privată stocată în acea adresă de email) într-o aplicație terță parte open-source și să confirme că adresa generată este corectă. Acest lucru ar trebui să fie valabil și pentru orice alt tip de tutor suportat.
Vă rugăm să rețineți că zk-email se confruntă astăzi cu o provocare practică, deoarece depinde de semnătura DKIM, care utilizează chei care se schimbă la fiecare câteva luni și aceste chei nu sunt semnate de nicio altă autoritate. Aceasta înseamnă că zk-email de astăzi are un anumit grad de cerință de încredere dincolo de furnizorul în sine; dacă zk-email ar utiliza TLSNotary în hardware de încredere pentru a verifica cheile actualizate, aceasta ar putea reduce această problemă, dar nu este ideal. Sperăm că furnizorii de email vor începe să-și semneze direct cheile DKIM. Astăzi, recomand ca un tutor să folosească zk-email, dar nu recomand majorității tutorilor să folosească: nu stocați fonduri în zk-email, deoarece deteriorarea acestuia înseamnă că nu puteți accesa 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 utilizarea zk-email pe adresa lor de email, cheile stocate local pe dispozitivul utilizatorului (poate o cheie universală) și o cheie de rezervă deținută de furnizor, pentru a face o alegere 2 din 3. Pe măsură ce utilizatorul devine mai experimentat sau acumulează mai multe active, ar trebui să li se sugereze să adauge mai mulți tutori la un moment dat.
Integrarea portofelului în aplicații este inevitabilă, deoarece aplicațiile care încearcă să atragă utilizatori non-criptomonedă 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 utilizare confuză. Cu toate acestea, utilizatorii portofelului aplicației ar trebui să poată lega toate portofelele lor împreună, astfel încât să se preocupe doar de o singură 'problemă de control al accesului'. Cea mai simplă metodă este adoptarea unei scheme ierarhice, în care există un proces rapid de 'legare' care permite utilizatorului să-și seteze portofelul principal ca tutor pentru toate portofelele din aplicație. Clientul Farcaster Warpcast susține deja acest lucru:
În mod implicit, recuperarea contului dvs. Warpcast este controlată de echipa Warpcast. Cu toate acestea, puteți 'prelua' contul dvs. Farcaster și modifica recuperarea pentru a fi adresa dvs. proprie.
Protejarea utilizatorilor împotriva escrocheriilor și altor amenințări externe
Pe lângă securitatea contului, portofelele de astăzi fac, de asemenea, multe lucruri pentru a identifica adresele false, phishing-ul, escrocheriile și alte amenințări externe, și depun eforturi pentru a proteja utilizatorii de astfel de amenințări. Între timp, multe măsuri de protecție sunt încă destul de primare: de exemplu, cerând un clic pentru a trimite ETH sau alte tokenuri către orice adresă nouă, fie că trimiteți 100 de dolari sau 100.000 de dolari. Aici nu există o soluție unică. Este un set de remedii și îmbunătățiri continue, lente, adresate diferitelor tipuri de amenințări. Cu toate acestea, continuarea eforturilor de îmbunătățire aici are o valoare mare.
Confidențialitate
Acum este timpul 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 pentru a reduce riscurile de reglementare (de exemplu, pool-uri 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. Totuși, până acum, efectuarea de transferuri private în Ethereum necesită ca utilizatorul să descarce explicit și să utilizeze 'portofele de confidențialitate', cum ar fi Railway (sau Umbra pentru adrese invizibile). Acest lucru adaugă o mare inconveniență și reduce numărul de oameni dispuși 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 pool-ul de confidențialitate. Atunci când utilizatorul face un transfer, acesta va ieși automat din pool-ul 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, protocol defi). Depozitele vor proveni dintr-un pool de confidențialitate, iar retragerile vor merge direct în pool-ul de confidențialitate. Acest lucru permite activităților utilizatorului într-o aplicație să fie decuplate de activitățile sale în alte aplicații.
Un avantaj al acestei tehnologii este că nu este doar o cale naturală de transfer de active care protejează confidențialitatea, ci și o cale naturală de protecție a identității. Identitatea a avut loc pe lanț: orice aplicație care utilizează dovezi de identitate controlate (cum ar fi Granturile Gitcoin), orice chat controlat de tokenuri, protocoalele Ethereum și așa mai departe sunt identitate on-chain. Ne dorim ca acest ecosistem să protejeze și confidențialitatea. Aceasta înseamnă că activitatea utilizatorului pe lanț nu ar trebui să fie colectată într-un singur loc: fiecare proiect ar trebui să stocheze separat, iar portofelul utilizatorului ar trebui să fie singurul cu 'viziune globală' care poate vedea toate dovezile dvs. în același timp. Un ecosistem nativ în care fiecare utilizator deține mai multe conturi contribuie la acest obiectiv, la fel ca protocoalele de dovezi off-chain precum EAS și Zupass.
Aceasta reprezintă viziunea pragmatică a confidențialității Ethereum pe termen mediu. Deși unele funcționalități pot fi introduse pe L1 și L2 pentru a face transferurile protejate de confidențialitate mai eficiente și mai fiabile, acestea pot fi realizate chiar acum. Unii susținători ai confidențialității consideră că singurul lucru acceptabil este confidențialitatea totală a tuturor: criptarea întregului EVM. Cred că aceasta ar putea fi rezultatul ideal pe termen lung, dar necesită o gândire mai fundamentală asupra modelului de programare, iar în prezent nu este pregătită să fie implementată în Ethereum. Avem într-adevăr nevoie de confidențialitate implicită pentru a obține un set de anonimat suficient de mare. Totuși, o primă preocupare ar trebui să fie (i) transferurile între conturi și (ii) identitatea și cazurile de utilizare asociate identității (de exemplu, dovezi private) este un prim pas pragmatic, mai ușor de realizat, iar portofelul ar putea începe să fie folosit imediat.
Portofelul Ethereum trebuie, de asemenea, să devină un portofel de date
O consecință a oricărei soluții de confidențialitate valide este că, fie pentru plăți, identitate sau alte cazuri de utilizare, va genera o nevoie pentru utilizatori de a stoca date off-chain. Acest lucru este evident în Tornado Cash, care solicită utilizatorilor să păstreze 'receptele' pentru fiecare depunere de 0.1-100 ETH. Protocoalele moderne de confidențialitate păstrează uneori date criptate pe lanț și le decriptează cu o cheie privată unică. Acest lucru este riscant, deoarece, dacă cheia este compromisă sau computerele cuantice devin viabile, datele vor fi complet expuse. Dovada off-chain, cum ar fi EAS și Zupass, evidențiază și mai mult nevoia de stocare a datelor off-chain.
Portofelul nu trebuie doar să devină software pentru a stoca accesul la lanț, ci și software pentru a stoca datele dvs. private. Lumea non-criptată devine, de asemenea, din ce în ce mai conștientă de acest lucru, de exemplu. Consultați munca recentă a lui Tim Berners-Lee în domeniul stocării datelor personale. Toate aceste probleme trebuie să fie abordate în jurul garantării robuste a controlului accesului, iar noi trebuie să abordăm și garantarea robustă a accesibilității datelor și a confidențialității 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 mod esențial mai greu de protejat, deoarece nu puteți revoca partea datelor cuiva, dar ar trebui să formulăm soluții de stocare descentralizate cât mai sigure posibil.
Acces sigur la lanț
În zilele noastre, portofelele cred că furnizorii lor RPC le vor spune orice informație despre lanț. Aceasta este o vulnerabilitate, având două aspecte:
1. Furnizorii RPC pot încerca să fure bani prin furnizarea de informații false, de exemplu, despre prețurile pieței.
2. Furnizorii RPC pot extrage informații private despre aplicațiile cu care interacționează utilizatorii și alte conturi.
Ideal, dorim să închidem aceste două vulnerabilități. Pentru a rezolva prima problemă, avem nevoie de clienți ușori standardizați atât pentru L1 cât și pentru L2, care pot verifica direct consensul blockchain-ului. Helios a făcut deja acest lucru pe L1 și a continuat să facă unele lucrări preliminare pentru a susține anumite L2-uri specifice. Pentru a acoperi corect toate L2-urile, avem nevoie de un standard prin care contractul de configurare care reprezintă L2 (de asemenea, utilizat pentru adrese specifice lanțului) poate declara o funcție, posibil într-un mod similar cu ERC-3668, care include logica de obținere a celui mai recent rădăcină de stare și de verificare a dovezilor pentru aceste rădăcini de stat. 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ă realistă de astăzi este să rulați propriul nod complet. Cu toate acestea, acum că L2 intră în vizorul oamenilor, devine din ce în ce mai dificil să rulați un nod complet pentru tot. Ceea ce corespunde unui client ușor este recuperarea informațiilor private (PIR). PIR implică servere care păstrează o copie a tuturor datelor și clienți care trimit cereri criptate serverului. Serverul realizează calcule pe toate datele, 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 serverului, fiecare proiect de bază de date este de fapt o ramură Merkle, astfel încât clientul să poată verifica folosind un client ușor.
Calculul PIR (Nota: de obicei se referă 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 extrem de intens. Există mai multe moduri de a aborda această problemă:
· Prin forță brută: îmbunătățiri ale algoritmilor sau hardware-ului dedicat ar putea face ca PIR să funcționeze suficient de rapid. Aceste tehnici pot 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 de a adapta aceste tehnici la seturi de date în continuă schimbare (la fel ca țările). Acest lucru face ca costurile de calcul în timp real să fie mai mici, dar va face probabil ca costurile totale de calcul și stocare să fie mai mari.
· 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 un milion de posibile valori la care clientul are acces, dar nu va ști nimic mai detaliat.
· PIR multi-server: Dacă utilizaț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.
· Anonim, nu confidențial: cererile pot fi trimise prin rețele de mixare, astfel încât să se ascundă expeditorul cererii, nu conținutul cererii. Totuși, realizarea eficientă a acestui lucru va crește inevitabil întârzierile, afectând astfel experiența utilizatorului.
Identificarea combinației corecte de tehnologie în mediul Ethereum pentru a maximiza confidențialitatea, păstrând în același timp utilitatea, este o problemă de cercetare deschisă, iar eu încurajez criptografii să încerce să facă acest lucru.
Portofelul ideal pentru chei de stocare
Pe lângă transferuri și acces la stări, un alt flux de lucru important care trebuie să funcționeze fără probleme în contextul între L2 este modificarea configurației de validare a contului: fie schimbarea cheii sale (de exemplu, recuperare), fie modificarea logicii întregului cont în mod mai profund. Există trei soluții în acest sens, ordonate după dificultate crescândă:
1. Replay Update: Atunci când utilizatorul își schimbă configurația, mesajul care autorizează această schimbare va fi reîntors pe fiecare lanț pe care portofelul detectează că utilizatorul are active. Este posibil ca formatul mesajului și regulile de validare să fie independente de lanț, astfel încât să poată fi reîntoarse automat pe cât mai multe lanțuri.
2. Cheia de stocare pe L1: informațiile de configurare se află pe L1, iar portofelul de pe L2 folosește L1SLOAD pentru a le citi sau apeluri statice la distanță. Astfel, este necesară actualizarea informațiilor de configurare doar pe L1, iar configurarea va fi aplicată automat.
3. Cheia de stocare pe L2: informațiile de configurare se află pe L2, iar portofelul de pe L2 le citește folosind ZK-SNARK. Acesta este similar cu (2), cu excepția că actualizările cheii de stocare pot fi mai ieftine, dar pe de altă parte, citirea este mai scumpă.
Soluția (3) este deosebit de puternică, deoarece se integrează bine cu confidențialitatea. În soluțiile 'de confidențialitate' obișnuite, utilizatorul deține secrete s, publicând pe lanț 'valoarea frunzelor' L, utilizatorul demonstrând că L = hash(s, 1) și N = hash(s, 2) pentru unele secrete (care nu au fost niciodată dezvăluite) pe care le controlează. Secretul invalid N este publicat, asigurând că orice cheltuială viitoare a acelei frunze va eșua fără a dezvălui L, ceea ce depinde de securitatea utilizatorului s. O soluție de confidențialitate prietenoasă cu recuperarea ar spune: s este un loc (de exemplu, o adresă și un slot de stocare) on-chain, utilizatorul trebuie să demonstreze interogarea stării: L = hash(sload(s), 1).
Securitate Dapp
Cel mai slab punct al securității utilizatorului este, de obicei, dapp-ul. De cele mai multe ori, utilizatorii interacționează cu aplicațiile prin accesarea site-urilor web, iar site-urile web descarcă implicit în timp real codul interfeței utilizatorului de la server și îl execută în browser. Dacă serverul este hack-uit sau DNS-ul este hack-uit, utilizatorul va obține o copie falsă a interfeței, ceea ce ar putea înșela utilizatorul să efectueze orice operație. Funcționalitățile portofelului, cum ar fi simularea tranzacțiilor, sunt foarte utile pentru reducerea riscurilor, dar sunt departe de a fi perfecte.
Ideal, am dori să mutăm ecosistemul către controlul versiunilor de conținut on-chain: utilizatorii ar accesa dapp-ul prin numele lor ENS, care va include hash-ul IPFS al interfeței. Actualizarea interfeței necesită tranzacții on-chain din partea unui semnatar multiplu sau a unui DAO. Portofelul ar putea arăta utilizatorului dacă interacționează cu o interfață on-chain mai sigură sau cu o interfață Web2 cu o securitate mai scăzută. Portofelul ar putea, de asemenea, să arate utilizatorului dacă interacționează cu un lanț sigur (de exemplu, faza 1+, audituri multiple de securitate).
Pentru utilizatorii care pun accent pe confidențialitate, portofelul ar putea adăuga un mod paranoic (paranoid mode), cerând utilizatorului să facă clic pentru a accepta cererile HTTP, nu doar operațiile web3:
Posibilele modele de interfață pentru modul paranoic
O abordare mai avansată este să depășim HTML + Javascript și să scriem logica de afaceri a dapp-ului în limbaje dedicate (posibil un strat relativ subțire deasupra Solidity sau Vyper). Apoi, browserul poate genera automat UI 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 construi o obligațiune, care, dacă dapp-ul este hack-uit sau dăunează utilizatorului într-un mod foarte înșelător, va plăti utilizatorii afectați (așa cum este determinat) de o DAC de arbitraj pe lanț. Portofelul ar putea arăta utilizatorului un scor bazat pe dimensiunea obligațiunii.
Viitorul pe termen lung
Toate cele de mai sus se desfășoară în contextul interfețelor tradiționale, care implică direcționarea și clicarea pe lucruri, precum și introducerea de lucruri în câmpuri de text. Cu toate acestea, ne aflăm, de asemenea, la marginea unei schimbări mai profunde a paradigmei:
· Inteligență artificială ar putea duce la o schimbare de la paradigma de tipare de clic la o paradigmă de 'spune ce vrei să faci și robotul va înțelege'
· Interfața creier-mașină: există metode 'blânde' precum urmărirea privirii, precum și tehnici mai directe sau chiar invazive (vezi: primul pacient Neuralink din acest an)
· Apărarea proactivă a clientului: browserul Brave protejează utilizatorii activ împotriva reclamelor, tracker-ilor și multor altor obiecte dăunătoare. Multe browsere, extensii și portofele criptografice au o întreagă echipă dedicată în mod activ protejării utilizatorilor de diverse amenințări de securitate și confidențialitate. Acești 'gardieni activi' vor deveni doar mai puternici în următorii zece ani.
Aceste trei tendințe vor conduce împreună la o reexaminare mai profundă a modului în care funcționează interfețele. Prin input de limbaj natural, urmărirea privirii sau, în cele din urmă, interfețe directe creier-mașină, împreună cu istoricul dvs. (poate include 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 pe lanț și off-chain pentru a finaliza ceea ce doriți. Aceasta 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ă gândească în mod adversar în numele utilizatorului, 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 cu diferite prejudecăți și structuri de stimulente.
Aceste idei mai radicale depind de tehnologie care este foarte imatură astăzi, așa că nu aș pune astăzi activele mele într-un portofel care depinde de acestea. Cu toate acestea, faptul că lucruri asemănătoare par a fi o tendință viitoare merită să începem să explorăm mai activ această direcție.
Link-ul original
