Peněženky jsou oknem mezi uživateli a světem Etherea a myslím, že zaměření na atributy zabezpečení a soukromí je to nejcennější.
Zvláštní poděkování patří Liraz Siri, Yoav Weiss a vývojářům ImToken, Metamask a OKX za jejich zpětnou vazbu a recenzi.
Kritická vrstva infrastruktury Ethereum, která je často podceňována hlavními výzkumníky a vývojáři L1, je peněženka. Peněženky jsou oknem mezi uživateli a světem Etherea a uživatelé mohou těžit z jakékoli decentralizace, odolnosti proti cenzuře, bezpečnosti, soukromí nebo jiných atributů, které nabízí Ethereum a jeho aplikace, pokud tyto atributy vlastní i samotná peněženka.
Nedávno jsme viděli, jak peněženky Ethereum dělají velké pokroky ve zlepšování uživatelského zážitku, zabezpečení a funkčnosti. Účelem tohoto článku je poskytnout můj vlastní názor na některé funkce, které by ideální peněženka Ethereum měla mít. Toto není úplný seznam, který odráží mé cypherpunkové sklony, je zaměřen na bezpečnost a soukromí a je téměř jistě neúplný z hlediska uživatelské zkušenosti. Nemyslím si však, že seznamy přání jsou při optimalizaci uživatelského zážitku tak účinné jako pouhé nasazení a opakování na základě zpětné vazby, takže si myslím, že zaměřit se na atributy zabezpečení a soukromí je nejcennější.
Uživatelská zkušenost pro transakce napříč L2
Nyní existuje stále podrobnější plán pro zlepšení uživatelské zkušenosti napříč L2, s krátkodobými a dlouhodobými částmi. Zde budu hovořit o krátkodobé části: nápady, které je teoreticky možné realizovat i dnes.
Základní myšlenkou je (i) vestavěné odesílání napříč L2 a (ii) požadavky na adresy a platby specifické pro řetězec. Vaše peněženka by vám měla být schopna poskytnout adresu (podle stylu tohoto návrhu ERC):
Když vám někdo (nebo nějaká aplikace) poskytne adresu v tomto formátu, měli byste být schopni ji vložit do pole „Komu“ ve vaší peněžence a kliknout na „Odeslat“. Peněženka by měla automaticky zpracovávat odeslaná data jakýmkoli možným způsobem:
Pokud již máte dostatek žetonů požadovaného typu na cílovém řetězci, pošlete žetony přímo
Pokud máte požadovaný typ tokenu na jiném řetězci (nebo více dalších řetězcích), odešlete token pomocí protokolu, jako je ERC-7683 (ve skutečnosti cross-chain DEX)
Pokud máte různé typy tokenů ve stejném řetězci nebo jiných řetězcích, použijte decentralizovanou burzu k jejich přeměně na správný typ měny ve správném řetězci a jejich odeslání. To by mělo vyžadovat výslovné povolení od uživatele: uživatelé uvidí, kolik zaplatili a kolik příjemce obdržel.
Model možného rozhraní peněženky s podporou cross-chain adres
Výše uvedené je pro případ použití „zkopírujete a vložíte adresu (nebo ENS, např. vitalik.eth @optimism.eth ) a někdo vám zaplatí“. Pokud dapp požaduje zálohu (např. viz tento příklad Polymarket), pak by bylo ideálním postupem rozšířit rozhraní web3 API a umožnit dapp zadávat požadavky na platby specifické pro daný řetězec. Vaše peněženka pak bude moci splnit požadavek jakýmkoli potřebným způsobem. Pro dobrou uživatelskou zkušenost je také potřeba standardizovat požadavky getAvailableBalance a peněženky musí pečlivě zvážit, na kterých řetězcích budou uživatelská aktiva ve výchozím nastavení uložena, aby se maximalizovala bezpečnost a pohodlí přenosu.
Požadavky na platby specifické pro daný řetězec lze také vložit do QR kódů, které lze naskenovat mobilními peněženkami. Při osobním (nebo online) spotřebitelském platebním scénáři příjemce vydá QR kód nebo volání webového rozhraní API se slovy „Chci X jednotek tokenu Y Z v řetězci, s referenčním ID nebo zpětným voláním W“ a peněženka bude moci k Neváhejte tento požadavek jakýmkoliv způsobem splnit. Další možností je protokol pro propojení nároků, kdy uživatelova peněženka vygeneruje QR kód nebo URL obsahující oprávnění k reklamaci, aby získal určitou částku finančních prostředků ze své on-chain smlouvy, a je úkolem příjemce zjistit, jak tyto prostředky převést na sami v peněžence.
Dalším souvisejícím tématem jsou platby za plyn. Pokud obdržíte aktivum na L2, které ještě nemá ETH, a potřebujete odeslat transakci na L2, peněženka by měla být schopna automaticky použít protokol (jako je RIP-7755) k platbě za plyn v řetězci. kde máte ETH. Pokud peněženka chce, abyste v budoucnu prováděli více transakcí na L2, měla by také odesílat například pouze pomocí DEX. ETH v hodnotě několika milionů plynu, aby tam budoucí transakce mohly utratit plyn přímo (protože je levnější).
Zabezpečení účtu
Jedním ze způsobů, jak konceptualizuji problém zabezpečení účtu, je, že dobrá peněženka by měla dělat dvě věci najednou: (i) chránit uživatele před hackováním nebo škodlivými útoky ze strany vývojářů peněženek a (ii) chránit uživatele před tím, aby byli ovlivněni vlastními chybami.
"Chyba" vlevo je neúmyslná. Když jsem to však viděl, uvědomil jsem si, že to dokonale zapadá do kontextu, a tak jsem se rozhodl si to nechat.
Mým upřednostňovaným řešením pro tento účel je již více než deset let sociální obnova a peněženky s více podpisy s hierarchickou kontrolou přístupu. Uživatelský účet má dvě úrovně klíčů: hlavní klíč a N opatrovníků (například N = 5). Primární klíče jsou schopny provádět operace s nízkou hodnotou a nefinanční operace. Většina opatrovníků musí provádět (i) operace s vysokou hodnotou, jako je odeslání celé hodnoty na účet nebo (ii) změna hlavního klíče nebo jakéhokoli opatrovníka. V případě potřeby lze primárním klíčům umožnit provádět operace s vysokou hodnotou prostřednictvím časových zámků.
Výše uvedené je základní provedení a lze jej rozšířit. Mechanismy oprávnění, jako jsou klíče relace a ERC-7715, mohou pomoci podporovat různé rovnováhy mezi pohodlím a zabezpečením pro různé aplikace. Složitější architektury strážců, jako například vícenásobné trvání časového zámku na různých prahových hodnotách, mohou pomoci maximalizovat šanci na úspěšné obnovení legitimních účtů a zároveň minimalizovat riziko krádeže.
Výše uvedené je základní provedení a lze jej rozšířit. Mechanismy oprávnění, jako jsou klíče relace a ERC-7715, mohou pomoci podporovat různé rovnováhy pohodlí a zabezpečení pro různé aplikace. Složitější architektury strážců, jako například vícenásobné trvání časového zámku na různých prahových hodnotách, mohou pomoci maximalizovat šanci na úspěšné obnovení legitimních účtů a zároveň minimalizovat riziko krádeže.
Kdo nebo co by měl být opatrovníkem?
Schůdnou možností pro zkušené uživatele kryptoměn v komunitě zkušených uživatelů kryptoměn jsou klíče vašich přátel a rodiny. Pokud všechny požádáte, aby vám poskytli novou adresu, nikdo nemusí vědět, kdo jsou – vaši opatrovníci ve skutečnosti ani nemusí vědět, kdo jsou. Pokud vás netipovali, šance, že se domluví, je mizivá. Pro většinu nových uživatelů však tato možnost není dostupná.
Druhou možností jsou ústavní opatrovníci: společnosti, které se specializují na poskytování služeb, které pouze podepisují transakce, když obdrží dodatečné potvrzení vaší žádosti: např. Potvrzovací kódy nebo videohovory pro uživatele s vysokou hodnotou. Lidé se dlouho pokoušeli vyrobit například ty. CryptoCorp jsem profiloval v roce 2013. Těmto firmám se však zatím příliš nedaří.
Třetí možností je více osobních zařízení (např. telefon, desktop, hardwarová peněženka). To funguje, ale pro nezkušené uživatele je také obtížné nastavit a spravovat. Existuje také riziko ztráty nebo odcizení zařízení současně, zejména pokud jsou na stejném místě.
V poslední době jsme začali vidět více řešení založených na hlavním klíči. Klíče lze zálohovat pouze na vašem zařízení, takže jde o řešení pro osobní zařízení, nebo v cloudu, takže jejich zabezpečení závisí na komplexní kombinaci kryptografického zabezpečení, autority a předpokladů důvěryhodného hardwaru. Ve skutečnosti jsou klíče pro běžného uživatele cenným bezpečnostním přínosem, ale samy o sobě nestačí k ochraně životních úspor uživatele.
Naštěstí u ZK-SNARKů máme čtvrtou možnost: centralizované ID balíčku ZK. Tento typ zahrnuje zk-email, Anon Aadhaar, Myna Wallet atd. V zásadě vezmete centralizované ID v jakékoli formě (firemní nebo vládní) a převedete ho na adresu Ethereum a můžete odesílat transakce pouze vygenerováním ZK-SNARK, který prokáže, že máte centralizované ID.
S tímto dodatkem nyní máme širokou škálu možností a jedinečnou „přívětivost pro nováčky“ centralizovaných ID zabalených v ZK.
Chcete-li to provést, musí být implementováno prostřednictvím zjednodušeného a integrovaného uživatelského rozhraní: měli byste být schopni zadat pouze to, že chcete „example@gmail.com“ jako opatrovníka, a mělo by to automaticky vygenerovat odpovídající zk-email Ethereum adresu pod kapuce. Pokročilí uživatelé by měli mít možnost zadat svůj e-mail (a možná i bezpečnostní sůl uloženou v tomto e-mailu) do open source aplikace třetí strany a potvrdit, že výsledná adresa je správná. Totéž by mělo platit pro jakýkoli jiný podporovaný typ opatrovníka.
Všimněte si, že praktickým problémem, kterému dnes zk-email čelí, je to, že se spoléhá na podpisy DKIM, které používají klíče, které se každých několik měsíců střídají a samy o sobě nejsou podepsány žádnou jinou autoritou. To znamená, že dnešní zk-email má určitou úroveň požadavků na důvěryhodnost nad rámec samotného poskytovatele, což lze snížit, pokud zk-email používá TLSNotary v důvěryhodném hardwaru k ověření aktualizovaných klíčů, ale to není ideální. Doufejme, že poskytovatelé e-mailu začnou podepisovat své klíče DKIM přímo. Dnes doporučuji zk-email pro jednoho opatrovníka, ale ne pro většinu opatrovníků: neukládejte prostředky v nastavení, kde nefunkční zk-e-mail znamená, že prostředky nemůžete použít.
Noví uživatelé a peněženka v aplikaci
Noví uživatelé ve skutečnosti nechtějí při první registraci zadávat velký počet opatrovníků. Peněženka by jim proto měla poskytnout velmi jednoduchou možnost. Přirozenou cestou by bylo provést 2-z-3 pomocí zk-email na jejich e-mailové adrese, klíč uložený lokálně na zařízení uživatele (možná hlavní klíč) a záložní klíč, který si vybere poskytovatel. Jakmile budou uživatelé zkušenější nebo nahromadí více prostředků, měli by být v určitém okamžiku vyzváni, aby přidali další opatrovníky.
Integrace peněženky do aplikací je nevyhnutelná, protože aplikace, které se snaží oslovit uživatele, kteří nepoužívají kryptoměny, nechtějí matoucí uživatelskou zkušenost uživatelů, kteří si stahují dvě nové aplikace (samotnou aplikaci a peněženku Ethereum) současně. Uživatelé mnoha peněženek s aplikacemi by však měli mít možnost propojit všechny své peněženky dohromady, aby se museli starat pouze o jeden „problém s řízením přístupu“. Nejjednodušším přístupem je přijmout vrstvené schéma, kde existuje rychlý proces „propojení“, který uživatelům umožňuje nastavit svou hlavní peněženku jako strážce všech peněženek v aplikaci. Klient Farcaster Warpcast již toto podporuje:
Ve výchozím nastavení je obnovení vašeho účtu Warpcast řízeno týmem Warpcast. Svůj účet Farcaster však můžete „převzít“ a změnit obnovu na vlastní adresu.
Chraňte uživatele před podvody a jinými vnějšími hrozbami
Kromě zabezpečení účtu se dnešní peněženky hodně snaží identifikovat falešné adresy, phishing, podvody a další externí hrozby a snaží se uživatele před takovými hrozbami chránit. Zároveň je mnoho protiopatření stále dosti primitivních: například požadavek na kliknutí pro odeslání ETH nebo jiných tokenů na jakoukoli novou adresu, ať už posíláte 100 nebo 100 000 $. Tady neexistuje jediná kouzelná kulka. Jedná se o pomalou, pokračující sérii oprav a vylepšení pro různé třídy hrozeb. Zde však má velkou hodnotu pokračovat v práci na vylepšeních.
soukromí
Je čas začít brát soukromí na Ethereu vážněji. Technologie ZK-SNARK je nyní velmi pokročilá, technologie ochrany osobních údajů, které se nespoléhají na zadní vrátka při snižování regulačního rizika (jako jsou soukromé fondy), jsou stále vyspělejší a sekundární infrastruktura, jako jsou mempooly Waku a ERC-4337, se pomalu stávají stabilnější. Až dosud však provádění soukromých převodů na Ethereu vyžadovalo, aby si uživatelé výslovně stáhli a používali „peněženku na ochranu soukromí“, jako je železnice (nebo Umbra pro tajné adresy). To přináší 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 je potřeba integrovat přímo do peněženky.
Jednoduchá implementace je následující. Peněženky mohou ukládat část majetku uživatele jako „soukromý zůstatek“ ve fondu soukromí. Když uživatelé provádějí převody, automaticky nejprve opustí fond soukromí. Pokud uživatel potřebuje přijímat prostředky, peněženka může automaticky vygenerovat tajnou adresu.
Kromě toho může peněženka automaticky vygenerovat novou adresu pro každou aplikaci, které se uživatel účastní (např. protokol defi). Vklady budou pocházet z fondu soukromí a výběry půjdou přímo do fondu soukromí. To umožňuje odpojit aktivitu uživatele v libovolné aplikaci od aktivity v jiných aplikacích.
Jednou z výhod této technologie je, že se jedná o přirozenou cestu nejen pro převody majetku, který zachovává soukromí, ale také pro identity zachovávání soukromí. Identita již probíhá v řetězci: jakákoli aplikace, která používá ověřování identity (např. Gitcoin Grants), jakýkoli chat s tokenem, protokoly Ethereum atd. je identita v řetězci. Chceme, aby tento ekosystém chránil i soukromí. To znamená, že aktivita uživatele v řetězci by neměla být shromažďována 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 jedinou věcí s „globálním pohledem“, která může vidět všechny vaše důkazy současně. . K dosažení tohoto cíle přispívá nativní ekosystém více účtů na uživatele, stejně jako protokoly mimo řetězec, jako jsou EAS a Zupass.
To představuje pragmatickou vizi ochrany soukromí Ethereum ve střednědobém horizontu. Zatímco některé funkce mohou být zavedeny na L1 a L2, aby byl přenos chránící soukromí efektivnější a spolehlivější, dnes je to možné. Někteří zastánci soukromí se domnívají, že jedinou přijatelnou věcí je úplné soukromí všech věcí: zašifrovat celý EVM. Myslím, že by to mohl být ideální dlouhodobý výsledek, ale vyžadovalo by to zásadnější přehodnocení programového modelu a ještě není na úrovni vyspělosti připravené k nasazení na Ethereum. Potřebujeme výchozí soukromí, abychom získali dostatečně velkou sadu anonymity. Zaměření se nejprve na (i) převody mezi účty a (ii) případy použití související s identitou a identitou (jako jsou soukromé doklady) jsou první pragmatické kroky, které se snáze implementují a peněženky mohou začít používat hned.
Ethereum peněženky musí být také datové peněženky
Jedním z důsledků jakéhokoli účinného řešení ochrany osobních údajů, ať už pro platby, identitu nebo jiné případy použití, je, že vytváří potřebu uživatelů ukládat svá data mimo řetězec. To je evidentní v Tornado Cash, který vyžaduje, aby si uživatelé ukládali „vstupenky“, z nichž každá představuje vklad 0,1–100 ETH. Modernější protokoly ochrany osobních údajů někdy uchovávají zašifrovaná data v řetězci a k jejich dešifrování používají jeden soukromý klíč. To je riskantní, protože pokud dojde k úniku klíčů nebo budou kvantové počítače proveditelné, všechna data budou veřejná. Důkazy mimo řetězec, jako jsou EAS a Zupass, mají zjevnější potřebu ukládání dat mimo řetězec.
Peněženka musí být software, který nejen ukládá přístupová práva na řetězci, ale také vaše soukromá data. To například stále více uznává i nekryptosvět. Podívejte se na nedávnou práci Tima Berners-Leeho o ukládání osobních údajů. Všechny problémy, které musíme vyřešit kolem robustního zajištění řízení přístupu, musíme také vyřešit kolem robustního ujištění, že data jsou přístupná a neunikají. Možná se tato řešení mohou naskládat: pokud máte N opatrovníků, použijte k uložení dat tajné sdílení M-of-N mezi těmito N opatrovníky. Data je ze své podstaty těžší chránit, protože nemůžete zrušit něčí podíl na datech, ale měli bychom přijít s decentralizovanými hostingovými řešeními, která jsou co nejbezpečnější.
Zabezpečený přístup k řetězu
Dnes peněženky důvěřují svému poskytovateli RPC, že jim řekne cokoliv o řetězci. Jedná se o zranitelnost dvěma způsoby:
Poskytovatelé RPC se mohou například pokusit ukrást peníze tím, že jim budou poskytovat nepravdivé informace. O tržní ceně.
Poskytovatelé RPC mohou extrahovat soukromé informace o aplikacích a dalších účtech, se kterými uživatel komunikuje.
V ideálním případě bychom chtěli uzavřít obě tyto skuliny. K vyřešení prvního problému potřebujeme standardizované lehké klienty pro L1 a L2, kteří mohou přímo ověřit blockchainový konsenzus. Helios to již dělá pro L1 a provedl několik přípravných prací na podpoře některých konkrétních L2. Abychom správně pokryli všechny L2, potřebujeme standard, kterým konfigurační kontrakt reprezentující L2 (také používaný pro adresy specifické pro řetězec) může deklarovat funkci, možná podobným způsobem jako ERC-3668, obsahující funkci získání nejbližší státní kořen a Ověřte logické stavy certifikace a účtenky proti kořenům těchto stavů. Můžeme tak mít univerzálního lehkého klienta, který umožňuje peněženkám bezpečně ověřit jakýkoli stav nebo událost na L1 a L2.
Pro ochranu soukromí je dnes jediným realistickým přístupem spuštění vlastního úplného uzlu. Nyní, když se však začíná objevovat L2, je provozování plného uzlu se vším všudy stále obtížnější. Ekvivalentem lehkého klienta je zde Private Information Retrieval (PIR). PIR zahrnuje server, který uchovává kopii všech dat, a klienta, který posílá šifrovaný požadavek na server. Server provádí výpočty se všemi daty a vrací data, která klient potřebuje, zašifrovaná do klientského klíče, aniž by serveru prozradila, ke kterému datu klient přistupoval.
Aby byl server poctivý, jednotlivé databázové projekty jsou samy o sobě Merkle forky, takže klienti mohou k jejich ověření používat lehké klienty.
PIR (Deep Chao Note: Obvykle se odkazuje na "Private Information Retrieval" (Private Information Retrieval), protokol nebo technologii, která umožňuje uživatelům získávat informace z databáze bez odhalení získaných informací.) Množství výpočtů je velmi velké. Existuje několik způsobů, jak tento problém vyřešit:
S hrubou silou: vylepšení v algoritmech nebo specializovaném hardwaru mohou způsobit, že PIR bude fungovat dostatečně rychle. Tyto techniky mohou záviset na předběžném zpracování: server může ukládat šifrovaná a kódovaná data pro každého klienta a klienti mohou tato data dotazovat. Hlavní výzvou v prostředí Etherea je přizpůsobení těchto technologií rychle se měnícím datovým souborům (stejně jako země). To zlevňuje výpočet v reálném čase, ale pravděpodobně zvyšuje celkové náklady na výpočet a úložiště.
Oslabené požadavky na soukromí: Například může existovat pouze 1 milion "mixinů" na vyhledávání, takže server bude znát 1 milion možných hodnot, ke kterým má klient přístup, ale nebude znát jemnější granularitu.
Multi-server PIR: Pokud používáte více serverů a předpokládá se, že poctivost mezi těmito servery je 1-z-N, pak je algoritmus PIR obvykle rychlejší.
Anonymita místo důvěrnosti: Požadavky lze odesílat prostřednictvím hybridní sítě, čímž se skryje odesílatel požadavku, nikoli obsah požadavku. Efektivní provedení však nevyhnutelně zvýší latenci, a tím zhorší uživatelský dojem.
Vymyslet správnou kombinaci technologií pro maximalizaci soukromí při zachování praktičnosti v prostředí Etherea je otevřená výzkumná otázka a vítám kryptografy, aby se o to pokusili.
Ideální peněženka na klíče
Kromě transportního a stavového přístupu je dalším důležitým pracovním postupem, který musí hladce fungovat napříč kontexty L2, změna konfigurace ověřování účtu: ať už se jedná o změnu jeho klíčů (například obnovení), nebo o hlubší změny v celé logice účtu. změnit. Zde jsou tři úrovně řešení v pořadí podle rostoucí obtížnosti:
Přehrát aktualizace: Když uživatel změní svou konfiguraci, zpráva povolující tuto změnu se přehraje v každém řetězci, kde peněženka zjistí, že uživatel vlastní aktiva. Formáty zpráv a ověřovací pravidla mohou být potenciálně nezávislé na řetězcích, a proto mohou být automaticky přehrávány v co největším počtu řetězců.
Úložiště klíčů na L1: Konfigurační informace jsou umístěny na L1 a peněženka na L2 je čte pomocí L1SLOAD nebo vzdálených statických volání. Tímto způsobem stačí pouze aktualizovat konfiguraci na L1 a konfigurace se automaticky projeví.
Úložiště klíčů na L2: Konfigurační informace existují na L2 a peněženka na L2 je čte pomocí ZK-SNARK. To je stejné jako (2), s tím rozdílem, že aktualizace úložiště klíčů mohou být levnější, ale čtení na druhou stranu je dražší.
Řešení (3) je obzvláště výkonné, protože si dobře pohrává s ochranou soukromí. V normálním „řešení ochrany soukromí“ má uživatel tajné s, publikuje „hodnotu listu“ L v řetězci a uživatel prokáže, že L = hash(s, 1) a N = hash(s, 2) pro některé (s, 2) ovládají tajemství, která nikdy nebyla odhalena). Invalidátor N je vydán tak, že budoucí výdaje stejného listu selžou bez odhalení L, což závisí na bezpečnosti uživatele. Řešení ochrany osobních údajů vhodné pro obnovení by řeklo: s je umístění (např. adresa a úložný slot) v řetězci a uživatel musí prokázat dotaz na stav: L = hash(sload(s), 1) .
Zabezpečení Dapp
Nejslabším článkem uživatelské bezpečnosti je často dapp. Uživatelé většinou komunikují s aplikacemi tak, že navštíví webovou stránku, která implicitně stáhne kód uživatelského rozhraní v reálném čase ze serveru a poté jej spustí v prohlížeči. Pokud je server hacknut nebo je hacknut DNS, uživatelé získají falešnou kopii rozhraní, která by je mohla přimět k provádění libovolných akcí. Funkce peněženky, jako jsou simulace obchodování, jsou velmi užitečné při snižování rizika, ale zdaleka nejsou dokonalé.
V ideálním případě bychom ekosystém přesunuli na verzování obsahu on-chain: uživatelé by přistupovali k dapps přes svůj ENS název, který by obsahoval IPFS hash rozhraní. Aktualizace rozhraní vyžaduje transakci v řetězci od multisig nebo DAO. Peněženka uživatelům ukáže, zda interagují s bezpečnějším rozhraním on-chain nebo méně bezpečným rozhraním Web2. Peněženky také mohou uživatelům ukázat, zda interagují s bezpečnostním řetězcem (např. Fáze 1+, několik bezpečnostních auditů).
Pro uživatele, kteří si uvědomují soukromí, může peněženka také přidat paranoidní režim, který vyžaduje, aby uživatelé kliknutím přijali požadavky HTTP, nejen operace web3:
Možný model rozhraní pro paranoidní režim
Pokročilejším přístupem by bylo jít nad rámec HTML + Javascript a napsat obchodní logiku dapp ve vyhrazeném jazyce (možná relativně tenký překryv na Solidity nebo Vyper). Prohlížeč pak může automaticky vygenerovat uživatelské rozhraní pro jakoukoli požadovanou funkci. OKContract to již dělá.
Dalším směrem je ochrana kryptoekonomických informací: vývojáři dapp, bezpečnostní společnosti, nasazení řetězců a další mohou vytvořit dluhopis, který bude vyplacen příjemci, pokud je dapp hacknut nebo poškodí uživatele vysoce zavádějícím způsobem posuzován nějakým on-chain DAO. Peněženka může uživateli zobrazit skóre na základě velikosti vazby.
dlouhodobější budoucnost
Výše uvedené je vše v kontextu tradičního rozhraní, které zahrnuje ukazování a klikání na věci a psaní věcí do textových polí. Jsme však také na pokraji hlubší změny paradigmatu:
Umělá inteligence, která nás může přivést od paradigmatu klikání a psaní k paradigmatu „řekni, co chceš udělat, a robot na to přijde“
Rozhraní mozek-počítač, od „jemných“ metod, jako je sledování očí, až po přímější a dokonce invazivní techniky (viz: letošní první pacient Neuralink)
Proaktivní obrana na straně klienta: Brave Browser proaktivně chrání uživatele před reklamami, sledovači a mnoha dalšími nežádoucími objekty. Mnoho prohlížečů, pluginů a kryptopeněženek má celé týmy, které aktivně pracují na ochraně uživatelů před různými bezpečnostními hrozbami a hrozbami pro soukromí. Tito „pozitivní strážci“ budou v příštím desetiletí jen sílit.
Společně tyto tři trendy povedou k hlubšímu přehodnocení toho, jak rozhraní fungují. Prostřednictvím přirozeného jazyka, sledování očí nebo případně přímějšího rozhraní mozek-počítač ve spojení s vaší historií (možná včetně textových zpráv, pokud jsou všechna data zpracovávána lokálně), může „peněženka“ jasně a intuitivně pochopit, kam chcete jít. Umělá intuice pak může tuto intuici převést do konkrétního „akčního plánu“: série interakcí v řetězci a mimo něj, abyste dosáhli toho, co chcete. To může výrazně snížit potřebu uživatelských rozhraní třetích stran. Pokud uživatel interaguje s aplikací třetí strany (nebo jiným uživatelem), umělá inteligence by měla myslet protichůdně jménem uživatele, identifikovat případné hrozby a navrhnout akční plán, jak se jim vyhnout. V ideálním případě by tyto umělé inteligence měly mít otevřený ekosystém produkovaný různými skupinami s různými předsudky a pobídkovými strukturami.
Tyto radikálnější myšlenky závisí na technologii, která je dnes velmi nevyzrálá, takže bych svůj majetek nedal do peněženky, která se na ně dnes spoléhá. Zdá se však jasné, že něco takového je cesta budoucnosti, a tak stojí za to začít v tomto směru bádat aktivněji.
