Autor: Vitalik Buterin, překládal: Yangz, Techub News Peněženka je klíčovou vrstvou v infrastruktuře Ethereum, ale často není dostatečně ceněna jádrovými výzkumníky a vývojáři L1. Peněženka je oknem mezi uživateli a světem Etherea, z něhož mohou uživatelé těžit, pouze pokud má peněženka také vlastnosti decentralizace, odolnosti vůči cenzuře, bezpečnosti, soukromí nebo jiné vlastnosti poskytované Ethereem a jeho aplikacemi. V posledních letech jsme viděli značný pokrok v peněženkách ekosystému Ethereum, co se týče zlepšení uživatelského zážitku, bezpečnosti a funkcionality. Cílem tohoto dokumentu je sdílet mé osobní názory na některé vlastnosti, které by ideální peněženka Ethereum měla mít. Tento seznam nebude vyčerpávající, ale odráží moje preference kryptopunky. U peněženek kladu větší důraz na bezpečnost a soukromí, protože v oblasti uživatelského zážitku prakticky neexistuje dokonalá peněženka. Myslím, že seznam přání nebude mít takový účinek na optimalizaci uživatelského zážitku jako jednoduché nasazení a iterace na základě zpětné vazby, a z mého pohledu je zaměření na atributy bezpečnosti a soukromí nejcennější. Uživatelé zkušenosti při transakcích na L2 V současnosti je cesta ke zlepšení uživatelského zážitku při transakcích na L2 stále podrobnější, obsahuje jak krátkodobé, tak dlouhodobé části. Zde bych chtěl hovořit o krátkodobé části, což jsou myšlenky, které lze teoreticky realizovat již dnes. Klíčový koncept této části je vestavěný převod mezi L2 a specifickými adresami řetězců a žádostmi o platbu. Peněženka by měla poskytovat takovou adresu: 
Když vám někdo (nebo nějaká aplikace) poskytne adresu v tomto formátu, měli byste ji být schopni vložit do pole „to“ vaší peněženky a poté kliknout na „odeslat“, peněženka by to měla automaticky zpracovat:
Pokud již na cílovém řetězci existuje dostatečné množství požadovaného typu tokenu, odešlete je přímo;
Pokud máte požadovaný typ tokenu na jiném řetězci (nebo více řetězcích), můžete použít protokol podobný ERC-7683 (ve skutečnosti křížový DEX) k odeslání tokenů;
Pokud máte na stejném nebo jiném řetězci různé typy tokenů, můžete je pomocí DEX převést na správný typ tokenu na správném řetězci a odeslat. Samozřejmě to také vyžaduje výslovný souhlas uživatele, což znamená, že uživatel uvidí, kolik zaplatil a kolik dostal příjemce.
Výše uvedené je příklad použití „kopírovat a vložit adresu (nebo ENS, například vitalik.eth@optimism.eth), aby vám ostatní mohli poslat peníze“. Pokud jde o vklady do DApp (viz příklad Polymarket), ideální proces by byl rozšířit Web3 API, které by umožnilo DApp požadovat platby pro specifické řetězce. Tím by peněženka uživatele mohla splnit tuto žádost jakýmikoli způsoby. Aby byla uživatelská zkušenost dobrá, je také třeba standardizovat požadavek getAvailableBalance a peněženka by měla zvážit, na kterém řetězci by měly být uživatelovy aktivum ve výchozím nastavení uložena, aby se maximalizovala bezpečnost a pohodlí převodů.
Žádosti o platby pro konkrétní řetězce mohou být také umístěny do QR kódů, což usnadňuje skenování přímo mobilními peněženkami. V případech, kdy platíte v reálném čase (nebo online), může příjemce požádat prostřednictvím QR kódu nebo volání Web3 API: „Chci Z jednotek Y tokenu na řetězci X, a připojit referenční ID nebo zpětné volání W“, a peněženka může tuto žádost splnit jakýmikoli způsoby. Další možností je protokol pro žádost o odměny, kde může peněženka uživatele generovat QR kód nebo URL obsahující autorizaci pro odnětí určité částky prostředků z jejich smlouvy na řetězci, a úkolem příjemce je najít způsob, jak tyto prostředky převést do své peněženky.
Další související téma je platba za plyn. Pokud obdržíte aktiva na L2, kde ještě nemáte ETH, a potřebujete poslat transakci na tomto L2, pak by peněženka měla být schopna automaticky použít protokol (například RIP-7755) k zaplacení plynu na řetězci, kde máte ETH. Pokud peněženka očekává, že v budoucnu provedete více transakcí na tomto L2, měla by také používat DEX k odeslání ETH v hodnotě milionů plynu, aby budoucí transakce mohly probíhat přímo bez potřeby plynu (což také snižuje náklady).
Bezpečnost účtu
Můj pohled na výzvy bezpečnosti účtů je, že dobrá peněženka by měla chránit uživatele nejen před hackery nebo zlými úmysly vývojářů peněženky, ale také před poškozením způsobeným vlastními chybami uživatele.
Překlep „mistakles“ na vertikální ose je neúmyslná chyba. Myslím, že tato chyba se velmi hodí do kontextu, a proto jsem ji neupravoval.
Více než deset let jsem preferoval řešení, které zahrnuje sociální obnovu a peněženky s multipodpisem, a to s hierarchickou kontrolou přístupu. Jednotlivý uživatelský účet má nastaveny dva úrovňové klíče, včetně hlavního klíče a N signatářů (například N = 5). Hlavní klíč může provádět operace s nízkou hodnotou a nefinanční operace. Ale pro provádění operací s vysokou hodnotou, jako je odeslání všech aktiv v účtu nebo změna hlavního klíče či jakéhokoli signatáře, je vyžadován podíl většiny signatářů. Pokud je to potřeba, může být umožněno hlavnímu klíči provádět vysoce hodnotné operace s časovým zámkem.
Výše uvedené je pouze základní design, můžeme jej rozšířit. Například mechanismy pro sdílení klíčů a oprávnění (například ERC-7715) mohou pomoci podpořit různé aplikace v dosažení různých rovnováh mezi pohodlím a bezpečností. Složitější architektury signatářů, jako je nastavení více časových zámků s různými prahy, pomáhají maximalizovat šance na úspěšné obnovení legitimního účtu, zatímco minimalizují riziko krádeže.
Kdo by měl být signatářem peněženky s multipodpisem?
Pro zkušené uživatele kryptoměn je životaschopnou možností vaše přátelé a rodina. Ve skutečnosti signatáři vaší peněženky s multipodpisem nemusí ani vědět, kdo jsou navzájem. Jejich dohoda bez vašeho vědomí je velmi nepravděpodobná. Nicméně pro většinu nových uživatelů není tato možnost životaschopná.
Druhou možností jsou instituce, tedy společnosti, které se specializují na poskytování služeb. Tito signatáři podepisují transakce pouze poté, co obdrží další potvrzující informace (například potvrzovací kód nebo videohovor s uživateli s vysokou čistou hodnotou). Už dlouhou dobu se lidé snaží vytvořit takové společnosti, například jsem v roce 2013 představil CryptoCorp. Až dosud však takové společnosti nemají žádného úspěšného zástupce.
Třetí možností je využití více osobních zařízení (například mobilních telefonů, stolních počítačů, hardwarových peněženek). Tento přístup může fungovat, ale pro nezkušené uživatele je nastavení a správa také obtížné. Kromě toho existuje riziko současného ztráty nebo krádeže zařízení, zejména pokud jsou na stejném místě.
V poslední době začínáme vidět více peněženek založených na passkey. Passkey může být zálohován pouze na zařízení, což z něj činí řešení osobního zařízení, nebo může být zálohován v cloudu, čímž jeho bezpečnost závisí na složitém mixu bezpečnosti hesla, institucí a důvěryhodného hardwaru. Ve skutečnosti je passkey pro běžného uživatele cenným bezpečnostním ziskem, ale spoléhat se pouze na něj nestačí k ochraně celoživotních úspor uživatele.
Naštěstí máme díky ZK-SNARK čtvrtou možnost, a to centralizované ID zpracované pomocí ZK. Tento typ zahrnuje zk-email, Anon Aadhaar, Myna Wallet a další. V podstatě můžete použít různé formy (podnikové nebo vládní) centralizovaných ID a převést je na adresu Ethereum, z níž můžete posílat transakce pouze tehdy, když vygenerujete důkaz ZK-SNARK o vlastnictví tohoto ID.
S touto novou funkcí máme více možností a centralizované ID zpracované pomocí ZK jsou velmi přívětivé pro nováčky.
Abychom toho dosáhli, potřebujeme použít zjednodušené integrované uživatelské rozhraní. Uživatel by jednoduše uvedl „example@gmail.com“ jako signátora a peněženka by automaticky vygenerovala odpovídající zk-email Ethereum adresu. Kromě toho by měli pokročilí uživatelé mít možnost zadat svou vlastní e-mailovou adresu (a případně související soukromý sůl, který by mohl být uložen v e-mailu) v open-source aplikacích třetích stran a potvrdit, že vygenerovaná adresa je správná. Jakýkoli jiný podporovaný typ signátora by měl fungovat stejně.
Je třeba poznamenat, že aktuálním praktickým problémem, kterému čelí zk-email, je, že se spoléhá na DKIM podpis, přičemž klíče používané pro DKIM podpisy se každých několik měsíců mění a tyto klíče nemají žádný jiný podpis od jiné autority. To znamená, že kromě samotného poskytovatele existuje určité množství důvěry; pokud by zk-email používal TLSNotary pro ověřování aktualizovaných klíčů na důvěryhodném hardwaru, mohlo by to snížit požadavek na důvěru, ale to není ideální. Doufejme, že poskytovatelé e-mailu začnou přímo podepisovat DKIM klíče. Doporučuji používat zk-email pouze na jednom signatáři, nikoli na většině signatářů. Tím se zajistí, že i když zk-email selže, neztratíte přístup k prostředkům.
Noví uživatelé a peněženky v aplikacích
Ve skutečnosti noví uživatelé nechtějí při prvním registraci zadávat mnoho informací o signatářích peněženky s multipodpisem. Proto by měly peněženky nabízet velmi jednoduchou možnost. Jedním z přirozených přístupů je, že 2 z 3 signatářů používají zk-email, tedy klíč místně uložený na zařízení uživatele (může to být passkey) a záložní klíč držený poskytovatelem. Jakmile uživatelé získají více zkušeností nebo aktiv, mohou být v některých případech vyzváni k přidání dalších signatářů.
Integrace peněženky do aplikací je nevyhnutelná, protože aplikace, které se snaží přilákat uživatele, kteří nejsou kryptoměnoví, nechtějí, aby uživatelé museli stahovat dvě nové aplikace (aplikaci samotnou a peněženku Ethereum), což by vedlo k špatnému uživatelskému zážitku. Uživatelé, kteří používají více peněženek, by měli být schopni propojit všechny své peněženky, aby se nemuseli starat pouze o „problémy s kontrolou přístupu“. Nejjednodušší způsob je použít hierarchické schéma, prostřednictvím rychlého procesu „propojení“ si uživatel může nastavit svou hlavní peněženku jako signátora všech peněženek uvnitř aplikace. V současné době klient Warpcast Farcaster tuto možnost již podporuje.
Ve výchozím nastavení obnovu účtu Warpcast kontroluje tým Warpcast. Uživatel však může „převzít“ účet Farcaster a změnit ho na svou adresu.
Ochrana uživatelů před podvody a jinými externími hrozbami
Kromě bezpečnosti účtů dnes peněženky také dělají 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 těmito hrozbami. Nicméně mnoho protiopatření je stále poměrně primitivních. Například poslat ETH nebo jiné tokeny na jakoukoli novou adresu lze provést pouze jedním kliknutím bez ohledu na to, zda posíláte 100 dolarů nebo 100 000 dolarů. V této oblasti neexistuje jednoznačné řešení, ale je třeba provést řadu pomalých, trvalých oprav a vylepšení pro různé kategorie hrozeb. Pokračování ve zlepšování však má velkou hodnotu.
Soukromí
Technologie ZK-SNARK je nyní velmi pokročilá a související technologie ochrany soukromí, jako jsou soukromé bazény (Privacy Pools), které snižují regulační riziko bez zadních vrátek, se také stále více vyvíjejí, infrastruktury druhého řádu, jako jsou Waku a ERC-4337, se také pomalu stávají stabilnějšími. Nicméně, až dosud, provádění soukromých transakcí na Ethereu stále vyžaduje, aby uživatelé výslovně stáhli a použili „privátní peněženku“, jako je Railway (nebo Umbra pro anonymní adresy). To přináší uživatelům značné nepohodlí a snižuje počet takových uživatelů. Řešení tohoto problému spočívá v integraci takových transakcí přímo do peněženek.
Jednoduchou implementací je, že peněženka může uchovávat část aktiv uživatele jako „privátní zůstatek“ v soukromém bazénu. Když uživatel provede převod, automaticky se nejprve vybere z privátního bazénu. Pokud uživatel potřebuje přijmout prostředky, peněženka automaticky vygeneruje anonymní adresu. Kromě toho může peněženka automaticky generovat novou adresu pro každou aplikaci, které se uživatel účastní (například DeFi protokol). Vklady pocházejí z privátního bazénu, výběry přímo do privátního bazénu. Tím se aktivity uživatele v jakékoli aplikaci stávají nezávislými na jejich aktivitách v jiných aplikacích.
Jednou z výhod této technologie je, že realizuje soukromí nejen při převodu aktiv, ale také při identifikaci. V současnosti je identifikace realizována na řetězci a jakékoli aplikace využívající proof-of-personhood (například Gitcoin Grants), jakékoli, které vyžadují specifické tokeny pro chatování, a Ethereum Follow protokol jsou příklady identifikace na řetězci. Doufáme, že tento ekosystém bude také mít soukromí, což znamená, že aktivity uživatelů na řetězci by neměly být shromažďovány na jednom místě, každý projekt by měl být ukládán samostatně a peněženka uživatele by měla být jediným místem, které má „globální pohled“, schopným vidět všechny vaše důkazy. Stejně jako u protokolů pro ověřování mimo řetězec, jako je EAS a Zupass, nativní ekosystém, kde má každý uživatel více účtů, pomáhá toho dosáhnout.
To představuje pragmatickou vizi soukromí Etherea v střednědobé budoucnosti. Ačkoli to může být realizováno již dnes, zavedení některých funkcí ve fázích L1 a L2 učiní transakce chránící soukromí efektivnějšími a spolehlivějšími. Někteří obhájci ochrany soukromí tvrdí, že jedině přijatelným řešením je úplná privatizace všeho a šifrování celého EVM. Ale myslím, že to může být ideální výsledek dlouhodobě, který vyžaduje zásadní přepracování programovacího modelu a v současnosti není dostatečně zralé k nasazení na Ethereu. Opravu potřebujeme „výchozí soukromí“ (privacy-by-default), abychom dosáhli dostatečné úrovně anonymity. Nicméně zaměření na ochranu soukromí transakcí mezi účty, stejně jako na identitu a případy použití související s identitou, je pragmatickým prvním krokem, který je snáze dosažitelný a může být pro peněženku v současné fázi rozvoje.
Ethereum peněženka by se také měla stát datovou peněženkou.
Jakékoli účinné řešení soukromí, ať už pro platby, identifikaci nebo jiné případy použití, povede k tomu, že uživatelé budou muset uložit data mimo řetězec. To je zvláště patrné u Tornado Cash, které vyžaduje, aby uživatelé uchovávali každou „poznámku“ představující vklady 0,1-100 ETH. Modernější protokoly ochrany soukromí někdy uchovávají šifrovaná data na řetězci a používají jeden soukromý klíč k dešifrování. To však nese riziko, protože pokud dojde k úniku klíče nebo pokud se kvantové počítače stanou možnými, všechna data by byla zveřejněna. V té době budou potřeby ukládání dat mimo řetězec, jako jsou EAS a Zupass, ještě patrnější.
Peněženka musí nejen stát se softwarem pro ukládání přístupu k řetězci, ale také softwarem pro ukládání soukromých dat. To je v ne-kryptoměnovém světě stále více uznáváno, konkrétně se můžete podívat na nedávný výzkum Tima Berners-Leeho v oblasti ukládání osobních dat. Musíme vyřešit všechny problémy, které nejen silně zajišťují kontrolu přístupu, ale také silně zajišťují dostupnost a nedožadovatelnost dat. Možná mohou být tato dvě řešení kombinována, předpokládáme-li, že máte N signatářů multipodpisu, pak můžete použít M-of-N tajné sdílení k ukládání dat mezi těmito N signatáři. V podstatě je obtížnější zajistit bezpečnost dat, protože nemůžete zrušit podíl ostatních na datech, ale měli bychom navrhnout bezpečné decentralizované hostingové řešení, jak nejlépe to jde.
Bezpečný přístup k blockchainu
Mnoho peněženek věří, že poskytovatelé RPC jim sdělí jakékoli informace o řetězci. To představuje dvě zranitelnosti. První je, že poskytovatelé RPC mohou zkusit ukrást prostředky poskytováním falešných informací (například tržních cen); za druhé, poskytovatelé RPC mohou extrahovat soukromé informace o tom, s jakými aplikacemi a jinými účty uživatelé interagují.
Ideálně bychom měli zabránit vzniku těchto dvou zranitelností. Abychom zabránili první zranitelnosti, potřebujeme standardizované lehké klienty L1 a L2, které přímo ověřují shodu blockchainu. Helios tuto funkci implementoval pro L1 a již začal s některými předběžnými pracemi na podpoře některých konkrétních L2. Abychom pokryli všechny L2, potřebujeme standard, podle kterého mohou smlouvy představující L2 (také pro konkrétní adresy řetězců) publikovat funkci (možná podobně jako ERC-3668), která obsahuje logiku pro získání nedávného kořene stavu a ověření důkazů stavu a příjmu na základě těchto kořenů stavu. Takto můžeme mít univerzální lehký klient, který umožní peněženkám bezpečně ověřit jakýkoli stav nebo událost na L1 a L2.
Pokud jde o druhou zranitelnost, v současnosti je jediným životaschopným způsobem provozování vlastního plného uzlu. Nicméně s popularizací L2 se stává stále obtížnější provozovat kompletní uzel, který obsahuje vše. V této souvislosti je srovnatelným řešením soukromé informace o vyhledávání (PIR). PIR zahrnuje server, který má všechny kopie dat, a klienta, který odesílá šifrované požadavky na server. Server provádí výpočty na všech datech a vrací požadovaná data klientovi (šifrovaná pomocí klientova klíče), aniž by serveru prozradil, jaká data klient navštívil.
Aby server zůstal poctivý, musí být jednotlivý databázový prvek sám o sobě větví Merkleova stromu, takže klient může použít svůj vlastní lehký klient k jeho ověření.
Výpočetní náklady PIR jsou velmi vysoké, ale existuje několik způsobů, jak tento problém řešit:
Brute force: Zlepšení algoritmů nebo specializovaného hardwaru může potenciálně urychlit provoz PIR dostatečně rychle. Tyto technologie mohou záviset na předzpracování, kde server uchovává šifrovaná a zamíchaná data pro každého klienta, který může dotazovat tato data. V prostředí Etherea spočívá hlavní výzva v přizpůsobení těchto technologií rychle se měnícím datovým sadám (například změnám stavu). To sníží náklady na výpočet v reálném čase, ale pravděpodobně zvýší celkové náklady na výpočet a úložiště.
Snížení požadavků na soukromí: Například každé dotazování může mít maximálně 1 milion „mixins“, takže server ví, které hodnoty klient může pravděpodobně přistupovat, ale neví o jemnějším detailu.
Více serverů PIR: Pokud používáte více serverů a předpokládáte, že čestnost mezi těmito servery je 1 z N, pak je rychlost běhu algoritmu PIR obvykle mnohem rychlejší.
Anonymita místo utajení: Požadavky mohou být zasílány přes mixovací síť, která skrývá odesílatele požadavku, ale neobsahuje obsah požadavku. To však nevyhnutelně zvyšuje zpoždění a zhoršuje uživatelskou zkušenost.
V prostředí Etherea je nalezení kombinace technologií, která maximálně chrání soukromí a zároveň zajišťuje užitečnost, otevřeným výzkumným tématem, vítáme nadšence kryptografie, aby se aktivně pokusili.
Ideální peněženka pro ukládání klíčů
Kromě přenosu a přístupu ke stavu je dalším důležitým pracovním tokem, který musí hladce fungovat v křížovém prostředí L2, změna ověřovací konfigurace účtu (ať už změna klíče nebo hlubší změna logiky účtu). Zde je tříúrovňové řešení, kde obtížnost postupně narůstá:
Replaying updates: Když uživatel změní konfiguraci, zpráva o autorizaci změn se přehraje na každém řetězci, na kterém má uživatel aktiva, když je peněženka detekuje. Formát zprávy a pravidla ověřování mohou být nezávislé na řetězci, a proto mohou být automaticky přehrávána na co nejvíce řetězcích.
Ukládání klíčů na L1: Konfigurační informace jsou uloženy na L1 a peněženka na L2 načítá konfigurační informace prostřednictvím L1SLOAD nebo REMOTESTATICCALL. Takto stačí aktualizovat konfiguraci na L1, aby se automaticky projevila.
Ukládání klíčů na L2: Konfigurační informace jsou uloženy na L2 a peněženka na L2 načítá konfigurační informace pomocí ZK-SNARK. To je stejné jako druhý případ, pouze náklady na aktualizaci uchovávání klíčů jsou nižší, zatímco náklady na čtení jsou vyšší.
Třetí řešení je zvlášť silné, protože se dobře integruje s ochranou soukromí. V běžných „řešeních pro ochranu soukromí“ se předpokládá, že uživatel má tajemství s, která na řetězci zveřejnila „leaf value“ L, a uživatel prokazuje, že L = hash(s,1) a N = hash(s,2) je nějaké (nikdy zveřejněné) tajemství, které ovládá. N bude zveřejněno, aby se zajistilo, že budoucí útraty pro stejný leaf selžou a neodhalí L. Avšak v řešeních přátelských k obnově účtu je s umístěním na řetězci (např. adresa a slot úložiště), uživatel musí prokázat dotaz stavu, tj. L = hash(sload(s), 1).
Bezpečnost DApp
Nejzranitelnějším článkem v uživatelské bezpečnosti bývá často DApp. Většinou se uživatelé interagují s aplikací prostřednictvím webové stránky, která stahuje kód uživatelského rozhraní v reálném čase ze serveru a poté jej vykonává v prohlížeči. Pokud je server hacknut, nebo pokud je DNS hacknut, uživatel dostane falešnou kopii rozhraní, což uživatele může přimět k tomu, aby udělal něco libovolného. Funkce peněženky, jako je simulace transakcí, mohou pomoci snížit riziko, ale stále to není dostatečné.
Ideálně bychom měli přesunout ekosystém na verzi obsahu na řetězci, kde by uživatelé přistupovali k DApp prostřednictvím svého ENS názvu, který by obsahoval IPFS hash rozhraní. K aktualizaci rozhraní by byly potřeba on-chain transakce z více ID nebo DAO. Peněženka by uživatelům ukázala, zda interagují s rozhraním na řetězci, které má vyšší úroveň bezpečnosti, nebo s rozhraním Web2 s nižší úrovní bezpečnosti.
Pro uživatele, kteří kladou důraz na soukromí, může být peněženka také přísnější a požadovat, aby uživatelé klikli na přijetí HTTP požadavku, a to nejen na operace Web3.
Pokročilejší přístup spočívá v překonání HTML + Javascript a napsání obchodní logiky DApp v nějakém specializovaném jazyce, například na vrcholu Solidity nebo Vyperu, což umožní prohlížeči automaticky generovat uživatelské rozhraní pro jakoukoli potřebnou funkci. OKContract to již udělal. Dalším směrem je obrana informací kryptoeconomy, kde mohou vývojáři DApp, bezpečnostní společnosti, nasazovatelé na řetězci a další vytvořit záruku, pokud je DApp hacknut nebo jinak značně klamavě poškodí uživatele, tato záruka bude zaplacena po rozhodnutí DAO na řetězci. Peněženka může uživatelům zobrazit hodnocení na základě velikosti záruky.
Dlouhodobější budoucnost
Vše, co bylo uvedeno výše, se odehrává v tradičním kontextu a nyní stojíme na okraji hlubokých změn v modelech:
Umělá inteligence (AI) by mohla přetvořit náš přístup z modelu „klikni a napiš“ na model „řekni a robot to pochopí“.
Rozhraní pro mozek a počítač: zahrnuje jak relativně „jemné“ metody, jako je sledování očí, tak i přímočařejší a dokonce invazivní technologie (např. první pacient Neuralink)
Klient účastnící se aktivní obrany: prohlížeč Brave aktivně chrání uživatele před reklamami, trackery a mnoha dalšími škodlivými objekty. Mnoho prohlížečů, pluginů a peněženek kryptoměn má celé týmy, které aktivně chrání uživatele před různými bezpečnostními a soukromí hrozbami. V příštích deseti letech se tyto „aktivní ochránce“ stanou silnějšími.
Tyto tři trendy dohromady přimějí lidi hlouběji přemýšlet o fungování peněženek. Díky vstupu v přirozeném jazyce, sledování očí nebo nakonec přímojším biometrickým technologiím (BCI), spolu s porozuměním uživatelským historiím, by „peněženka“ mohla intuitivně vědět, co chce uživatel udělat. Poté by AI mohla tuto intuici proměnit v konkrétní „akční plán“, jako je série interakcí na a mimo řetězec, což by realizovalo uživatelské záměry. To by výrazně snížilo potřebu uživatelského rozhraní třetí strany. Pokud uživatel skutečně interaguje s aplikacemi třetích stran (nebo jinými uživateli), AI by také měla jednat jménem uživatele, aby prováděla protivní úvahy, identifikovala jakákoli rizika a navrhla akční plány, jak se těmto hrozbám vyhnout. Ideálně by tyto AI vytvořily otevřenou ekosystém, generovaný různými skupinami s různými zaujatostmi a motivacemi.
Samozřejmě tyto radikálnější myšlenky závisí na technologiích, které jsou nyní ještě velmi nezralé, takže bych své aktivum nedal do peněženky, která se na těchto technologiích spoléhá. Nicméně se tyto technologie zdají být trendem budoucnosti, takže je dobré začít se aktivně zkoumat tímto směrem.
