Původní název: Co bych rád viděl v peněžence
Autor: Vitalik, zakladatel Ethereum; Sestavil: Deng Tong, Golden Finance
Zvláštní poděkování Liraz Siri, Yoav Weiss a vývojářům ImToken, Metamask a OKX za jejich zpětnou vazbu a revizi.
Jednou z klíčových vrstev infrastruktury Ethereum je peněženka, ale často je podceňována jádrovými L1 výzkumníky a vývojáři. Peněženka je oknem mezi uživateli a světem Ethereum, uživatelé mohou čerpat výhody z jakýchkoli decentralizovaných, cenzurně odolných, bezpečných, soukromých nebo jiných vlastností, které Ethereum a jeho aplikace nabízejí, za předpokladu, že i samotná peněženka má tyto vlastnosti.
V poslední době jsme viděli velký pokrok v zlepšování uživatelské zkušenosti, bezpečnosti a funkcionality peněženek Ethereum. Cílem tohoto článku je poskytnout svůj pohled na některé z vlastností, které by ideální peněženka Ethereum měla mít. Není to vyčerpávající seznam; odráží mé zaměření na bezpečnost a soukromí, a téměř jistě není úplný z hlediska uživatelské zkušenosti. Nicméně si myslím, že seznam přání není tak efektivní pro optimalizaci uživatelské zkušenosti jako jednoduše nasazení a iterace na základě zpětné vazby, a proto považuji za nejcennější zaměřit se na vlastnosti bezpečnosti a soukromí.
Uživatelská zkušenost při transakcích přes L2
Nyní existuje stále podrobnější plán na zlepšení uživatelské zkušenosti napříč L2, který má krátkodobou a dlouhodobou část. Zde budu hovořit o krátkodobé části: nápadech, které je možné teoreticky implementovat i dnes.
Hlavní myšlenkou je (i) vestavěné odesílání přes L2 a (ii) adresy specifické pro blockchain a platební požadavky. Vaše peněženka by měla být schopna poskytnout adresu (následující styl tohoto ERC návrhu), jak je uvedeno:
0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045@optimism.eth
Když vám někdo (nebo některé aplikace) poskytne adresu v tomto formátu, měli byste ji být schopni vložit do pole "Příjemce" vaší peněženky a poté kliknout na "Odeslat". Peněženka by měla automaticky zpracovávat odesláná data jakýmikoli možnými způsoby:
Pokud již máte v cílovém blockchainu dostatek požadovaného typu tokenů, pošlete tokeny přímo;
Pokud máte požadovaný typ tokenů na jiném blockchainu (nebo více jiných blockchainů), použijte protokoly jako ERC-7683 (ve skutečnosti cross-chain DEX), abyste poslali tokeny;
Pokud máte různé typy tokenů na stejné nebo jiné blockchainy, použijte decentralizované burzy k jejich převodu na správný typ tokenů na správném blockchainu a odešlete je. To by mělo vyžadovat výslovný souhlas uživatele: uživatel uvidí, kolik poplatků zaplatil, a kolik poplatků příjemce obdržel.
Model možného rozhraní peněženky s podporou pro cross-chain adresy
Výše uvedené platí pro případy použití "kopírujete a vkládáte adresu (nebo ENS, například vitalik.eth@optimism.eth), abyste dostali platbu". Pokud dapp požaduje vklad (například viz příklad Polymarket), ideální proces je rozšířit web3 API a umožnit dapp vydat specifické platební požadavky pro blockchain. Poté bude vaše peněženka schopna splnit tuto žádost jakýmikoli potřebnými způsoby. Aby byla uživatelská zkušenost dobrá, je také potřeba standardizovat požadavky getAvailableBalance a peněženka by měla zvážit, na kterých blockchainových sítích by měla uživatelská aktiva ve výchozím nastavení ukládat, aby maximalizovala bezpečnost a pohodlí transakcí.
Specifické platební požadavky na blockchainu mohou být také vloženy do QR kódů, mobilní peněženka může QR kód skenovat. V kontextu plateb mezi spotřebiteli (osobně nebo online) příjemce vydá QR kód nebo web3 API volání, které říká: "Chci X jednotek tokenu Y na blockchainu Z, s referenčním ID nebo zpětným voláním W", peněženka by měla být schopna splnit tuto žádost jakýmikoli možnými způsoby. Další možností je protokol pro vykoupení odkazů, kde peněženka uživatele generuje QR kód nebo URL, která obsahuje autorizaci k výběru určitého množství prostředků z jeho on-chain kontraktu, úkolem příjemce je zjistit, jak tyto prostředky převést na svůj účet.
Dalším relevantním tématem je platba za Gas. Pokud obdržíte aktiva na L2, kde nemáte ETH, a potřebujete provést transakci na tomto L2, měla by být peněženka schopna automaticky použít protokoly (například RIP-7755) k zaplacení Gasu na blockchainu, kde máte ETH. Pokud peněženka chce, abyste v budoucnu prováděli více transakcí na L2, měla by rovněž použít DEX k odeslání ETH v hodnotě několika milionů Gas, aby budoucí transakce mohly být přímo tam pro výdaje na Gas (protože to je levnější).
Bezpečnost účtu
Jeden způsob, jak konceptualizovat výzvy v oblasti zabezpečení účtů, je, že dobrá peněženka by měla fungovat na dvou frontách: (i) chránit uživatele před hackery nebo zlými úmysly vývojářů peněženky a (ii) chránit uživatele před jejich vlastními chybami.
Levý "chyba" je neúmyslný. Když jsem to viděl, uvědomil jsem si, že se velmi hodí do kontextu, takže jsem se rozhodl to zachovat.
Po více než deset let byla mým preferovaným řešením sociální obnova a multi-sign peněženka s hierarchickou kontrolou přístupu. Účet uživatele má dvě úrovně klíčů: hlavní klíč a N poručníků (např. N = 5). Hlavní klíč je schopen provádět operace s nízkou hodnotou a nefinanční operace. Většina poručníků potřebuje provést (i) operace s vysokou hodnotou, například odeslat veškerou hodnotu v účtu, nebo (ii) změnit hlavní klíč nebo jakékoli poručníky. Pokud je to nutné, může být hlavní klíč povolen k provádění operací s vysokou hodnotou prostřednictvím časového zámku.
Výše uvedené je základní design, který lze rozšířit. Mechanismy oprávnění, jako je session key a ERC-7715, mohou pomoci podpořit různé rovnováhy mezi pohodlím a bezpečností různých aplikací. Složitější architektury poručníků, jako je více časových zámků s různými prahovými hodnotami, mohou pomoci maximalizovat úspěch při obnově legitimního účtu, zatímco minimalizují riziko krádeže.
Kdo by měl být poručníkem?
Pro zkušené uživatele kryptoměn v komunitě zkušených kryptoměnových uživatelů je proveditelnou možností klíč vašich přátel a rodiny. Pokud požádáte každého, aby vám poskytl novou adresu, nikdo nemusí vědět, kdo jsou – ve skutečnosti vaši poručníci nemusí ani vědět, kdo jsou navzájem. Pokud vás neupozornili, je velmi malá pravděpodobnost, že by se dohodli. Nicméně většině nových uživatelů tato možnost není k dispozici.
Druhou možností jsou institucionální poručníci: společnosti, které poskytují služby, a které podepisují transakce pouze v případě, že obdrží další potvrzení z vaší žádosti. Potvrzovací kód, nebo pro uživatele s vysokou hodnotou videohovor. Po dlouhou dobu se lidé snaží tyto věci vytvořit. V roce 2013 jsem představil CryptoCorp. Nicméně, dosud tyto společnosti nebyly příliš úspěšné.
Třetí možností je více osobních zařízení (například mobilní telefon, desktop, hardwarová peněženka). To je proveditelné, ale pro nezkušené uživatele je nastavení a správa také obtížné. Kromě toho existuje riziko ztráty nebo odcizení zařízení, zejména když se nacházejí na stejném místě.
V poslední době začínáme vidět stále více peněženek založených na klíčích. Klíče mohou být zálohovány pouze na vašem zařízení, což je činí řešením osobního zařízení, nebo zálohovány v cloudu, což zajišťuje jejich bezpečnost v závislosti na složité směsi bezpečnosti klíčů, institucí a důvěryhodných hardwarových předpokladů. Ve skutečnosti jsou klíče pro průměrné uživatele cenným bezpečnostním přínosem, ale samotné nejsou dostatečné k ochraně celoživotních úspor uživatelů.
Naštěstí s ZK-SNARK máme také čtvrtou možnost: ZK zabalenou centralizovanou identitu. Tento typ zahrnuje zk-email, Anon Aadhaar, Myna Wallet atd. V zásadě můžete vzít centralizovanou identitu v různých formách (společnost nebo vláda) a převést ji na Ethereum adresu, kterou můžete poslat transakcí pouze generováním důkazu o vlastnictví centralizované identity pomocí ZK-SNARK.
S tímto doplněním nyní máme širokou škálu možností a ZK zabalená centralizovaná identita má jedinečnou "uživatelskou přívětivost".
Aby toho bylo dosaženo, je třeba to realizovat prostřednictvím zjednodušeného a integrovaného UI: měli byste být schopni pouze specifikovat, že chcete, aby "example@gmail.com" byl poručníkem, a mělo by to automaticky generovat odpovídající zk-email Ethereum adresu pod kapotou. Pokročilí uživatelé by měli být schopni zadat svůj e-mail (a případně související soukromou sůl uloženou v tomto e-mailu) do open-source třetí strany aplikace a potvrdit, že generovaná adresa je správná. Totéž by mělo platit pro jakýkoli jiný typ podporovaného poručníka.
Možné modely bezpečnostního rozhraní
Všimněte si, že jedním z praktických problémů, kterým dnes zk-email čelí, je to, že se spoléhá na DKIM podpisy, které používají klíče, které se každých několik měsíců mění, a tyto klíče nejsou podepsány žádnou jinou institucí. To znamená, že dnešní zk-email má určitou úroveň důvěry, která přesahuje samotného poskytovatele; pokud by zk-email používal TLSNotary k ověření aktualizovaných klíčů na důvěryhodném hardwaru, mohlo by to tuto situaci zmírnit, ale to není ideální. Doufám, že poskytovatelé e-mailu začnou přímo podepisovat své DKIM klíče. Dnes doporučuji, aby jeden poručník používal zk-email, ale nedoporučuji většině poručníků: nenechte si uchovávat prostředky na zk-email, protože poškození znamená, že nemůžete použít nastavení prostředků.
Noví uživatelé a peněženky v aplikacích
Noví uživatelé ve skutečnosti nechtějí při prvním registračním zážitku zadávat velké množství poručníků. Proto by peněženka měla poskytnout velmi jednoduchou volbu. Přirozený způsob je použití zk-email na jejich e-mailové adrese, klíče uloženého na zařízení uživatele (možná univerzální klíč) a záložního klíče, který drží poskytovatel, pro výběr 2-of-3. Jakmile se uživatelé stanou zkušenějšími nebo nasbírají více aktiv, měli by být v určitém okamžiku vyzváni, aby přidali více poručníků.
Integrace peněženek do aplikací je nevyhnutelná, protože aplikace snažící se přilákat uživatele mimo kryptoměny nechtějí, aby uživatelé museli stahovat dvě nové aplikace zároveň (aplikaci samotnou a Ethereum peněženku), což by přineslo zmatený uživatelský zážitek. Mnoho uživatelů aplikací peněženek by však mělo být schopno propojit všechny své peněženky, aby se starali pouze o jeden "problém přístupu". Nejjednodušší způsob je zavést hierarchické schéma, kde existuje rychlý "propojení" proces, který uživatelům umožní nastavit svou hlavní peněženku jako poručníka pro všechny peněženky v aplikaci. Klient Farcaster Warpcast to již podporuje:
Ve výchozím nastavení je obnova vašeho účtu Warpcast kontrolována týmem Warpcast. Můžete však "převzít" svůj účet Farcaster a změnit obnovu na svou vlastní adresu.
Chrání uživatele před podvody a dalšími externími hrozbami
Kromě zabezpečení účtů dělají dnešní peněženky také spoustu práce při identifikaci falešných adres, phishingu, podvodů a dalších externích hrozeb a snaží se chránit uživatele před takovými hrozbami. Mezitím mnoho opatření zůstává poměrně primitivních: například vyžadují kliknutí, aby se ETH nebo jiné tokeny poslaly na jakoukoli novou adresu, ať už posíláte 100 USD nebo 100 000 USD. Neexistuje zde žádný jednotný zázrak. Je to série pomalých, neustálých oprav a vylepšení zaměřených na různé kategorie hrozeb. Nicméně, pokračování ve zlepšování zde má velkou hodnotu.
Soukromí
Nyní je čas začít brát soukromí Ethereum vážněji. Technologie ZK-SNARK je nyní velmi pokročilá, a technologie ochrany soukromí, které se nespoléhají na zadní vrátka, aby snížily regulační rizika (například privátní pooly), se stávají stále zralejšími, zatímco druhotné infrastruktury jako Waku a ERC-4337 mempools se pomalu stávají stabilnějšími. Nicméně, dosud provádění soukromých převodů na Ethereum vyžaduje, aby si uživatelé výslovně stáhli a používali "privátní peněženku", například Railway (nebo Umbra pro neviditelné adresy). To přidává značné nepohodlí a snižuje počet lidí ochotných provádět soukromé převody. Řešením je, že soukromé převody musí být přímo integrovány do peněženky.
Jednoduchá implementace je následující. Peněženka může uchovávat část uživatelských aktiv jako "privátní zůstatek" v privátním poolu. Když uživatel provede převod, automaticky se nejprve odhlásí z privátního poolu. Pokud uživatel potřebuje přijmout prostředky, peněženka může automaticky generovat neviditelnou adresu.
Dále může peněženka automaticky generovat novou adresu pro každou aplikaci, do které uživatel vstupuje (např. protokol defi). Vklady budou pocházet z privátního poolu a výběry půjdou přímo do privátního poolu. To umožňuje uživatelům odpojit své aktivity v jedné aplikaci od aktivit v jiných aplikacích.
Jednou z výhod této technologie je, že je to přirozený způsob, jak chránit soukromí při přenosu aktiv, a také přirozený způsob, jak chránit soukromí identity. Identita se již odehrává na blockchainu: jakákoli aplikace, která používá identifikační kontrolu (například Gitcoin Grants), jakýkoli tokenem chráněný chat, protokoly dodržující Ethereum atd., jsou identitou na blockchainu. Doufáme, že tento ekosystém také ochrání soukromí. To znamená, že činnosti uživatelů na blockchainu by neměly být shromažďovány na jednom místě: každý projekt by měl být uložen samostatně, a peněženka uživatele by měla být jediná věc, která má "globální pohled" na všechny vaše důkazy. Nativní ekosystém více účtů na uživatele tomu napomáhá, stejně jako off-chain protokoly pro důkazy jako EAS a Zupass.
To představuje pragmatickou vizi soukromí Ethereum ve střednědobém horizontu. I když by některé funkce mohly být zavedeny na L1 a L2, aby se ochrana soukromí při přenosu stala efektivnější a spolehlivější, již nyní je to možné. Někteří obhájci soukromí tvrdí, že jediná akceptovatelná možnost je úplné soukromí pro vše: šifrování celého EVM. Myslím, že to může být ideální dlouhodobý výsledek, ale vyžaduje to zásadní přehodnocení programovacího modelu a v současnosti ještě nedosáhlo úrovně připravenosti na nasazení na Ethereum. Opravu potřebujeme výchozí soukromí pro dostatečně velkou anonymní skupinu. Nicméně první zaměření (i) na převody mezi účty a (ii) na identity a případy použití související s identitou (např. soukromé důkazy) je pragmatickým prvním krokem, který je snadněji realizovatelný a peněženka může začít používat nyní.
Ethereum peněženky by se také měly stát datovými peněženkami
Jakýkoli efektivní řešení soukromí má za následek požadavek na ukládání dat offline uživatelem, ať už pro platby, identitu, nebo jiné případy použití. To je zřetelné v Tornado Cash, který vyžaduje, aby uživatelé uchovávali "stvrzenky" představující vklady 0.1-100 ETH. Modernější soukromé protokoly někdy ukládají šifrovaná data on-chain a dešifrují je pomocí jediného soukromého klíče. To je riskantní, protože pokud dojde k úniku klíče, nebo pokud se kvantové počítače stanou životaschopnými, data se stávají plně veřejnými. Potřeba ukládání dat off-chain se stává zřetelnější s off-chain důkazy jako EAS a Zupass.
Peněženka by neměla být jen softwarem pro ukládání přístupových práv na blockchainu, ale také softwarem pro uchovávání vašich soukromých dat. I nešifrovaný svět si toho stále více uvědomuje, například. Podívejte se na nedávnou práci Tima Berners-Leeho v oblasti ukládání osobních dat. Všechny problémy, které potřebujeme vyřešit kolem robustního zajištění kontroly přístupu, musíme také řešit kolem robustního zajištění přístupnosti dat a zabránění únikům. Možná by se tato řešení mohla kombinovat: Pokud máte N poručníků, použijte sdílení tajemství M-of-N k uložení vašich dat mezi těmito N poručníky. Uložení dat je v podstatě obtížnější, protože nemůžete odvolat něčí podíl na datech, ale měli bychom navrhnout co nejbezpečnější decentralizované hostingové řešení.
Bezpečný přístup na blockchain
Dnes peněženky věří, že jejich poskytovatelé RPC jim řeknou všechny informace o blockchainu. To je zranitelnost, která má dvě stránky:
Poskytovatelé RPC se mohou pokusit ukrást peníze tím, že jim poskytnou falešné informace, například o tržních cenách
Poskytovatelé RPC mohou extrahovat soukromé informace o aplikacích a dalších účtech, se kterými uživatel interaguje
Ideálně bychom chtěli zablokovat tyto dva průniky. Abychom vyřešili první problém, potřebujeme standardizované lehké klienty pro L1 a L2, které mohou přímo ověřovat konsensus blockchainu. Helios to pro L1 již udělal a provádí nějakou počáteční práci na podpoře některých specifických L2. Abychom správně pokryli všechny L2, potřebujeme standard, podle kterého mohou konfigurační kontrakty reprezentující L2 (také pro adresy specifické pro blockchain) deklarovat funkci, možná podobně jako ERC-3668, která zahrnuje získání nejnovějších state roots a prokazování a potvrzování na základě těchto state roots. Tímto způsobem bychom mohli mít univerzální lehký klient, který umožňuje peněženkám bezpečně ověřovat jakýkoli stav nebo událost na L1 a L2.
Pro ochranu soukromí je dnes jedinou realistickou možností provozovat svou vlastní plnou uzel. Nicméně nyní, když se L2 dostává do povědomí, se stává stále složitějším provozovat plný uzel pro vše. To, co je ekvivalentem lehkého klienta, je soukromé informace retrieval (PIR). PIR zahrnuje servery, které uchovávají všechny kopie dat a klienta, který posílá šifrované požadavky serveru. Server provádí výpočty na všech datech a vrací požadovaná data klientovi, šifrovaná klíčem klienta, aniž by serveru prozradil, která data klient navštívil.
Aby se zajistila čestnost serverů, jednotlivé databázové projekty jsou samy o sobě Merkle větve, takže klient může používat lehkého klienta k jejich ověření.
Výpočet PIR je velmi náročný. Existuje několik způsobů, jak tento problém vyřešit:
Brute force: Vylepšení algoritmů nebo specializovaného hardwaru mohou umožnit, aby PIR fungoval dostatečně rychle. Tyto technologie mohou záviset na předzpracování: servery mohou uchovávat šifrovaná a zamíchaná data pro každého klienta, a klienti mohou tyto data dotazovat. Hlavní výzvou v prostředí Ethereum je přizpůsobit tyto technologie rychle se měnícím datovým sadám (jako je národ). To snižuje náklady na výpočty v reálném čase, ale pravděpodobně zvyšuje celkové náklady na výpočty a úložiště.
Oslabení požadavků na soukromí: například při každém vyhledávání může být maximálně 1 milion "mixinů", takže server ví, že klient může mít přístup k jednomu milionu možných hodnot, ale neví o žádných jemnějších detailech.
Více serverů PIR: Pokud používáte více serverů a hypotéza o jejich čestnosti je 1-of-N, pak je algoritmus PIR obvykle rychlejší.
Anonymita místo utajení: požadavky mohou být zaslány prostřednictvím mixnetu, čímž se skryje odesílatel požadavku, místo aby se skryl obsah požadavku. Nicméně efektivní provedení tohoto nevyhnutelně zvýší latenci, což zhorší uživatelskou zkušenost.
Najít správnou kombinaci technologií v prostředí Ethereum pro maximalizaci soukromí při zachování praktičnosti je otevřeným výzkumným problémem, vítám, že se kryptografové snaží toto udělat.
Ideální peněženka pro knihovnu klíčů
Kromě přenosu a přístupu k stavu je dalším důležitým pracovním postupem, který musí hladce fungovat v kontextu napříč L2, změna ověřovací konfigurace účtu: ať už jde o změnu klíče (například pro obnovu) nebo pro hlubší změny v logice celého účtu. Zde existují tři vrstvy řešení se zvyšující obtížností:
Replaying Updates: Když uživatel změní svou konfiguraci, zpráva autorizující tuto změnu bude přehrána na každém blockchainu, na kterém má uživatel aktiva, jakmile peněženka detekuje, že uživatel má aktiva. Je možné, že formát zprávy a pravidla ověřování mohou být nezávislé na blockchainu, a proto mohou být automaticky přehrávány na co nejvíce blockchainů.
Klíčová knihovna na L1: Konfigurační informace jsou umístěny na L1, peněženky na L2 používají L1SLOAD nebo REMOTESTATICCALL k jejich čtení. Tímto způsobem stačí aktualizovat konfiguraci na L1, aby se konfigurace automaticky projevila.
Klíčová knihovna na L2: Konfigurační informace existují na L2, peněženky na L2 je čtou pomocí ZK-SNARK. To je stejné jako (2), kromě toho, že aktualizace knihovny klíčů mohou být levnější, ale na druhé straně čtení je dražší.
Řešení (3) je obzvlášť silné, protože se dobře kombinuje s ochranou soukromí. V normálních "řešeních pro ochranu soukromí" má uživatel tajemství s, "listové hodnoty" L se zveřejňují na blockchainu a uživatel prokazuje, že L = hash(s, 1) a N = hash(s, 2) pro nějaké (nikdy nezveřejněné) tajemství, které ovládá. Neplatný N je zveřejněn, aby se zajistilo, že budoucí výdaje stejného listu selžou, aniž by se prozradilo L. To závisí na uživatelském zajištění bezpečnosti s. Přátelské řešení pro ochranu soukromí by říkalo: s je umístění na blockchainu (například adresa a úložný slot) a uživatel musí prokázat dotaz na stav: L = hash(sload(s), 1).
Bezpečnost dappu
Nejslabším článkem v bezpečnosti uživatelů bývá často dapp. Většinou uživatelé interagují s aplikacemi prostřednictvím webových stránek, které implicitně stahují kód uživatelského rozhraní z serveru v reálném čase a poté jej vykonávají v prohlížeči. Pokud je server napaden hackery nebo DNS je napaden, uživatel obdrží falešnou kopii rozhraní, což může uživatele svést k provedení libovolných akcí. Funkce peněženky, jako je simulace transakcí, jsou velmi užitečné pro snížení rizika, ale stále nejsou dokonalé.
Ideálně bychom chtěli přenést ekosystém na verzi řízení obsahu na blockchainu: uživatelé by přistupovali k dappu prostřednictvím svého ENS jména, které by obsahovalo IPFS hash rozhraní. Aktualizace rozhraní by vyžadovaly on-chain transakce z multi-sign nebo DAO. Peněženka by uživatelům ukázala, zda interagují s bezpečnějším on-chain rozhraním nebo méně bezpečným Web2 rozhraním. Peněženka by také mohla uživatelům ukázat, zda interagují se zabezpečeným blockchainem (např. fáze 1+, více bezpečnostních auditů).
Pro uživatele dbající na soukromí by peněženka mohla také přidat paranoidní režim, který vyžaduje, aby uživatel kliknul na přijetí HTTP požadavků, nikoli pouze web3 operací:
Model možného rozhraní paranoidního režimu
Pokročilejší přístup je překonat HTML + Javascript a napsat obchodní logiku dappu v specializovaném jazyce (možná relativně tenké pokrytí na Solidity nebo Vyper). Poté může prohlížeč automaticky generovat UI pro jakoukoli potřebnou funkci. OKContract to již dělá.
Dalším směrem je obrana proti informacím v kryptoeconomice: vývojáři dapp, bezpečnostní společnosti, provozovatelé blockchainu a další mohou zřídit záruku, že pokud je dapp napaden nebo způsobí uživatelům velkou dezinterpretaci, tato záruka bude vyplacena postiženým uživatelům. Řídí to některé DAO pro rozhodování na blockchainu. Peněženka může uživatelům zobrazit skóre založené na velikosti záruky.
Dlouhodobější budoucnost
Výše uvedené se vše odehrává na pozadí tradičního rozhraní, kde se vše odkazuje a kliká a zadává se do textových polí. Nicméně, také jsme na pokraji hlubší změny paradigmatu:
Umělá inteligence, což by mohlo vést k přechodu od paradigmatu klikacího psaní k paradigmatu "řekněte, co chcete udělat, a robot to zjistí";
Rozhraní mozek-stroj, s "jemnými" metodami jako sledování pohybu očí, stejně jako přímějšími nebo dokonce invazivními technologiemi (viz: první pacient Neuralink letos);
Klientská aktivní obrana: Prohlížeč Brave aktivně chrání uživatele před reklamami, trackery a mnoha dalšími špatnými objekty. Mnoho prohlížečů, pluginů a kryptoměnových peněženek má celé týmy, které se aktivně snaží chránit uživatele před různými bezpečnostními a soukromými hrozbami. Tito "aktivní strážci" budou v příštím desetiletí jen silnější.
Tyto tři trendy společně povedou k hlubšímu přepracování toho, jak fungují rozhraní. Pomocí vstupu v přirozeném jazyce, sledování pohybu očí nebo nakonec přímějšího rozhraní mozek-stroj, spolu s vaší historií (možná zahrnující SMS, pokud jsou všechna data zpracovávána lokálně), může "peněženka" jasně a intuitivně rozumět tomu, co chcete udělat. Poté může umělá inteligence tuto intuici přetavit do konkrétního "plánu akcí": sadu on-chain a off-chain interakcí, aby se splnilo to, co chcete udělat. To může výrazně snížit potřebu uživatelského rozhraní třetích stran. Pokud uživatel skutečně interaguje s aplikacemi třetích stran (nebo jinými uživateli), měla by umělá inteligence provést protivní myšlení jménem uživatele, identifikovat jakékoli hrozby a navrhnout plán akcí, jak se vyhnout těmto hrozbám. Ideálně by tyto umělé inteligence měly mít otevřený ekosystém vyprodukovaný různými skupinami s různými předsudky a motivačními strukturami.
Tyto radikálnější myšlenky se spoléhají na dnes extrémně nezralé technologie, takže dnes bych své aktiva do peněženky, která na nich závisí, nedal. Přesto se zdá, že podobné věci jsou jasně budoucím trendem, takže je zajímavé začít se aktivněji prozkoumat tímto směrem.
