Szczególne podziękowania dla Liraz Siri, Yoav Weiss oraz deweloperów ImToken, Metamask i OKX za ich opinie i przegląd.
Kluczowym poziomem stosu infrastruktury Ethereum są portfele, które są często niedoceniane przez rdzeniowych badaczy i deweloperów L1. Portfel jest oknem między użytkownikami a światem Ethereum, a użytkownicy mogą korzystać z wszelkich zdecentralizowanych, opornych na cenzurę, bezpiecznych, prywatnych lub innych atrybutów oferowanych przez Ethereum i jego aplikacje, pod warunkiem że sam portfel ma te atrybuty.
Ostatnio widzieliśmy znaczny postęp w portfelach Ethereum w zakresie poprawy doświadczeń użytkowników, bezpieczeństwa i funkcjonalności. Celem tego artykułu jest przedstawienie mojej wizji niektórych cech, które idealny portfel Ethereum powinien mieć. Nie jest to pełna lista; odzwierciedla moje skłonności do kryptopunków, które koncentrują się na bezpieczeństwie i prywatności, a z pewnością nie jest kompletna pod kątem doświadczeń użytkowników. Uważam jednak, że lista życzeń nie jest tak skuteczna w optymalizacji doświadczeń użytkowników, jak po prostu wdrażanie i iteracja na podstawie opinii, dlatego uważam, że skupienie się na właściwościach bezpieczeństwa i prywatności jest najbardziej wartościowe.
Doświadczenie użytkownika w transakcjach cross-L2
Obecnie istnieje coraz bardziej szczegółowa mapa drogowa poprawy doświadczeń użytkowników w transakcjach cross-L2, która ma część krótkoterminową i długoterminową. Tutaj omówię część krótkoterminową: pomysły, które teoretycznie można wdrożyć już dziś.
Główna idea to (i) wbudowane wysyłanie cross-L2 oraz (ii) specyficzne dla łańcucha adresy i prośby o płatność. Twój portfel powinien być w stanie dostarczyć ci adres (zgodny z stylem niniejszego projektu ERC), jak poniżej:
Kiedy ktoś (lub niektóre aplikacje) podaje ci adres w tym formacie, powinieneś być w stanie wkleić go w pole „odbiorca” portfela, a następnie kliknąć „wyślij”. Portfel powinien automatycznie zająć się wysyłanymi danymi w jakikolwiek możliwy sposób:
Jeśli już masz wystarczającą ilość potrzebnych tokenów na docelowym łańcuchu, po prostu wyślij tokeny
Jeśli masz potrzebne tokeny na innym łańcuchu (lub wielu innych łańcuchach), użyj protokołów takich jak ERC-7683 (de facto cross-chain DEX), aby wysłać tokeny
Jeśli masz różne typy tokenów na tym samym lub innym łańcuchu, użyj zdecentralizowanej giełdy, aby zamienić je na odpowiednie tokeny na właściwym łańcuchu i wysłać. To powinno wymagać wyraźnej zgody użytkownika: użytkownik zobaczy, ile zapłacił za opłaty oraz ile otrzymał odbiorca.
Model potencjalnego interfejsu portfela z obsługą adresów cross-chain
Powyższe odnosi się do przypadku użycia „skopiowałeś i wkleiłeś adres (lub ENS, np. vitalik.eth @ optimism.eth) i ktoś ci płaci”. Jeśli dapp żąda depozytu (np. zobacz ten przykład Polymarket), to idealny proces to rozszerzenie API web3 i umożliwienie dapp wydawania płatności specyficznych dla łańcucha. Wówczas twój portfel będzie mógł spełnić tę prośbę w dowolny sposób, który będzie potrzebny. Aby użytkownik miał dobre doświadczenie, należy również ustandaryzować zapytanie getAvailableBalance, a portfel musi poważnie rozważyć, na których łańcuchach domyślnie przechowywać aktywa użytkowników, aby maksymalizować bezpieczeństwo i wygodę transferów.
Specyficzne dla łańcucha prośby o płatność mogą być również umieszczane w kodzie QR, a mobilny portfel może skanować kod QR. W scenariuszach płatności konsumenckich twarzą w twarz (lub online) odbiorca będzie wydawał kod QR lub wywołanie API web3, wskazując „chcę X jednostek tokena YZ na łańcuchu, z identyfikatorem referencyjnym lub powrotem W”, a portfel będzie mógł w dowolny sposób spełnić tę prośbę. Inną opcją jest protokół linków do roszczeń, w którym portfel użytkownika generuje kod QR lub URL zawierający autoryzację roszczenia, aby uzyskać określoną ilość funduszy z ich kontraktu na łańcuchu, a odbiorca musi dowiedzieć się, jak przenieść te fundusze do swojego portfela.
Innym istotnym tematem są płatności gazowe. Jeśli otrzymasz aktywa na L2 bez ETH, a potrzebujesz wysłać transakcję na tym L2, portfel powinien automatycznie korzystać z protokołu (np. RIP-7755), aby zapłacić gaz na łańcuchu, gdzie masz ETH. Jeśli portfel chce, abyś w przyszłości przeprowadzał więcej transakcji na L2, powinien również użyć DEX do wysyłania, np. ETH o wartości kilku milionów gazu, aby przyszłe transakcje mogły być bezpośrednio tam opłacane (bo to tańsze).
Bezpieczeństwo konta
Jednym ze sposobów konceptualizacji wyzwań związanych z bezpieczeństwem konta jest to, że dobry portfel powinien działać w dwóch aspektach: (i) chronić użytkownika przed atakami hakerskimi lub złośliwymi ze strony deweloperów portfela oraz (ii) chronić użytkownika przed skutkami własnych błędów.
„Błąd” po lewej stronie jest niezamierzony. Jednak gdy go zobaczyłem, zdałem sobie sprawę, że bardzo dobrze pasuje do kontekstu, więc postanowiłem go zachować.
Moim preferowanym rozwiązaniem od ponad dziesięciu lat są portfele z odzyskiwaniem społecznościowym i wieloma podpisami, z kontrolą dostępu na różnych poziomach. Konta użytkowników mają dwa poziomy kluczy: klucz główny i N opiekunów (np. N = 5). Klucz główny jest w stanie przeprowadzać operacje o niskiej wartości i niefinansowe. Większość opiekunów musi wykonać (i) operacje o wysokiej wartości, takie jak wysyłanie całej wartości na koncie, lub (ii) zmiana klucza głównego lub jakiegokolwiek opiekuna. Jeśli to konieczne, można pozwolić kluczowi głównemu na wykonywanie operacji o wysokiej wartości przez blokadę czasową.
Powyższe to podstawowy projekt, który można rozszerzyć. Mechanizmy uprawnień, takie jak klucze sesji i ERC-7715, mogą pomóc w zrównoważeniu wygody i bezpieczeństwa w różnych aplikacjach. Bardziej złożone struktury opiekunów, na przykład z wieloma czasowymi blokadami pod różnymi progami, mogą pomóc zwiększyć szanse na udane odzyskanie legalnych kont przy jednoczesnym minimalizowaniu ryzyka kradzieży.
Powyższe to podstawowy projekt, który można rozszerzyć. Mechanizmy uprawnień, takie jak klucze sesji i ERC-7715, mogą pomóc w zrównoważeniu wygody i bezpieczeństwa w różnych aplikacjach.
Kto lub co powinno być opiekunem?
Dla doświadczonej społeczności użytkowników kryptowalut, wykonalną opcją są klucze twoich przyjaciół i rodziny. Jeśli poprosisz każdego o podanie nowego adresu, nikt nie musi wiedzieć, kim są - w rzeczywistości twoi opiekunowie nawet nie muszą wiedzieć, kim są nawzajem. Jeśli nie ostrzegają cię nawzajem, prawdopodobieństwo, że są w zmowie, jest niewielkie. Jednak dla większości nowych użytkowników ta opcja nie jest dostępna.
Drugą opcją są instytucjonalni opiekunowie: firmy oferujące usługi podpisywania transakcji tylko po otrzymaniu dodatkowych informacji potwierdzających twoją prośbę: np. kodu potwierdzającego lub wideokonferencji dla użytkowników o wysokiej wartości. Ludzie od dawna próbują stworzyć takie firmy, np. w 2013 roku przedstawiłem CryptoCorp. Jednak do tej pory te firmy nie były zbyt udane.
Trzecią opcją są różne urządzenia osobiste (takie jak telefon, komputer stacjonarny, portfel sprzętowy). Może to działać, ale dla niedoświadczonych użytkowników może być również trudne do skonfigurowania i zarządzania. Istnieje również ryzyko jednoczesnej utraty lub kradzieży urządzeń, zwłaszcza gdy znajdują się w tym samym miejscu.
Ostatnio zaczynamy widzieć więcej rozwiązań opartych na kluczu głównym. Klucze mogą być przechowywane tylko na twoim urządzeniu, co czyni je rozwiązaniem osobistym, a także mogą być przechowywane w chmurze, co czyni ich bezpieczeństwo zależnym od złożonego bezpieczeństwa mieszanej kryptografii, instytucji i zaufanego sprzętu. W rzeczywistości klucze są cennym zyskiem bezpieczeństwa dla przeciętnych użytkowników, ale same w sobie nie wystarczą, aby chronić oszczędności użytkowników przez całe życie.
Na szczęście dzięki ZK-SNARK mamy czwarty wybór: scentralizowane ID opakowane w ZK. Ten typ obejmuje zk-email, Anon Aadhaar, Myna Wallet itd. W zasadzie można wziąć scentralizowane ID w różnych formach (firmowych lub rządowych) i przekształcić je w adres Ethereum, a transakcje można wysyłać tylko poprzez generowanie dowodu ZK-SNARK, że posiada się scentralizowane ID.
Dzięki tej uzupełniającej funkcji mamy teraz szeroki wybór, a scentralizowane ID opakowane w ZK mają unikalną „przyjazność dla nowicjuszy”.
Aby to osiągnąć, potrzebuje to uproszczonego i zintegrowanego interfejsu użytkownika: powinieneś być w stanie po prostu określić, że chcesz, aby „example@gmail.com” był opiekunem, a on powinien automatycznie wygenerować odpowiedni adres zk-email Ethereum pod maską. Zaawansowani użytkownicy powinni być w stanie wprowadzić swój adres e-mail (oraz ewentualnie prywatną sól przechowywaną w tym e-mailu) w otwartym, niezależnym od dostawcy aplikacji i potwierdzić, że wygenerowany adres jest poprawny. To samo powinno dotyczyć wszystkich innych typów wspieranych opiekunów.
Zwróć uwagę, że dzisiaj zk-email napotyka rzeczywiste wyzwanie, ponieważ polega na podpisie DKIM, który opiera się na kluczu wymienianym co kilka miesięcy, a te klucze same nie są podpisywane przez żadną inną instytucję. Oznacza to, że dzisiejszy zk-email ma pewien stopień wymagań zaufania wykraczających poza samego dostawcę; jeśli zk-email używa TLSNotary na zaufanym sprzęcie do weryfikacji aktualnych kluczy, można by to zminimalizować, ale nie jest to idealne. Mam nadzieję, że dostawcy e-mail będą mogli zacząć bezpośrednio podpisywać swoje klucze DKIM. Dziś sugeruję, aby jeden opiekun korzystał z zk-email, ale nie zalecałbym, aby większość opiekunów to robiła: nie przechowuj funduszy w zk-email, ponieważ uszkodzenie oznacza, że nie możesz korzystać z ustawienia funduszy.
Nowi użytkownicy i portfele w aplikacjach
Nowi użytkownicy w rzeczywistości nie chcą wprowadzać wielu opiekunów przy pierwszej rejestracji. Dlatego portfel powinien zapewnić im bardzo prostą opcję. Naturalnym sposobem jest użycie zk-email na ich adresie e-mail, klucza przechowywanego lokalnie na urządzeniu użytkownika (może to być klucz główny) oraz klucza zapasowego trzymanego przez dostawcę w celu utworzenia wyboru 2 z 3. W miarę zdobywania doświadczenia przez użytkownika lub gromadzenia większej ilości aktywów, w pewnym momencie powinien być zachęcany do dodania większej liczby opiekunów.
Integracja portfela z aplikacjami jest nieunikniona, ponieważ aplikacje próbujące przyciągnąć użytkowników spoza kryptowalut nie chcą, aby użytkownicy musieli jednocześnie pobierać dwa nowe aplikacje (aplikację samą w sobie oraz portfel Ethereum), co wprowadza chaotyczne doświadczenie użytkownika. Jednak wiele aplikacji powinna móc łączyć wszystkie swoje portfele, aby musieli się martwić tylko o jeden „problem kontroli dostępu”. Najprostszym sposobem jest przyjęcie hierarchicznego podejścia, w którym istnieje szybki proces „połączenia”, który pozwala użytkownikowi ustawić swój główny portfel jako opiekuna wszystkich portfeli aplikacji.
Domyślnie odzyskiwanie twojego konta Warpcast jest kontrolowane przez zespół Warpcast. Możesz jednak „przejąć” swoje konto Farcaster i zmienić odzyskiwanie na swój własny adres.
Ochrona użytkowników przed oszustwami i innymi zewnętrznymi zagrożeniami
Oprócz bezpieczeństwa konta, współczesne portfele robią wiele, aby identyfikować fałszywe adresy, phishing, oszustwa i inne zewnętrzne zagrożenia oraz starają się chronić użytkowników przed takimi zagrożeniami. W międzyczasie wiele działań wciąż pozostaje dość prymitywnych: na przykład, wymaganie kliknięcia, aby wysłać ETH lub inne tokeny na jakikolwiek nowy adres, niezależnie od tego, czy wysyłasz 100 dolarów, czy 100 000 dolarów. Nie ma tu jednego uniwersalnego rozwiązania. To seria powolnych, ciągłych poprawek i udoskonaleń skierowanych na różne kategorie zagrożeń. Niemniej jednak, kontynuowanie wysiłków na rzecz poprawy w tym obszarze przynosi wiele wartości.
Prywatność
Nadszedł czas, aby poważniej zająć się prywatnością Ethereum. Technologia ZK-SNARK jest teraz bardzo zaawansowana, a techniki ochrony prywatności (np. pule prywatności), które nie polegają na tylnych drzwiach w celu zmniejszenia ryzyka regulacyjnego, stają się coraz bardziej dojrzałe, podczas gdy infrastruktura drugiego poziomu, taka jak Waku i ERC-4337 mempools, powoli staje się bardziej stabilna. Jednak jak dotąd, aby przeprowadzić prywatne transakcje na Ethereum, użytkownik musi wyraźnie pobrać i używać „portfela prywatności”, takiego jak Railway (lub Umbra do niewidocznych adresów). To zwiększa ogromne niedogodności i zmniejsza liczbę osób chętnych do przeprowadzania prywatnych transakcji. Rozwiązaniem jest bezpośrednia integracja prywatnych transakcji w portfelach.
Prosta implementacja wygląda następująco. Portfel może przechowywać część aktywów użytkownika jako „prywatny bilans” w puli prywatności. Gdy użytkownik dokonuje transferu, automatycznie wypisuje się z puli prywatności. Jeśli użytkownik potrzebuje otrzymać fundusze, portfel może automatycznie wygenerować niewidoczny adres.
Ponadto portfel może automatycznie generować nowy adres dla każdego z aplikacji, w których uczestniczy użytkownik (np. protokoły defi). Wpłaty będą pochodziły z puli prywatności, a wypłaty będą trafiały bezpośrednio do puli prywatności. To pozwala użytkownikowi unikać powiązań między działaniami w jednym aplikacji a jego działaniami w innych aplikacjach.
Jedną z zalet tej technologii jest to, że jest to naturalny sposób ochrony prywatności w przenoszeniu aktywów, jak również naturalny sposób ochrony prywatności tożsamości. Tożsamość już występuje na łańcuchu: każda aplikacja, która używa kontroli dostępu do tożsamości (np. Gitcoin Grants), każdy czat oparty na tokenach, protokoły zgodne z Ethereum itd., to wszystko tożsamość na łańcuchu. Chcemy, aby ten ekosystem również chronił prywatność. Oznacza to, że aktywność użytkowników na łańcuchu nie powinna być zbierana w jednym miejscu: każdy projekt powinien być przechowywany osobno, a portfel użytkownika powinien być jedyną rzeczą, która ma „globalny widok”, mogącą jednocześnie zobaczyć wszystkie twoje dowody. Ekosystem, w którym każdy użytkownik ma wiele kont, sprzyja temu celowi, podobnie jak protokoły dowodów off-chain, takie jak EAS i Zupass.
To reprezentuje pragmatyczną wizję prywatności Ethereum w średnim okresie. Chociaż można wprowadzić pewne funkcje na L1 i L2, aby uczynić ochronę prywatności w transferach bardziej efektywną i niezawodną, można to już osiągnąć teraz. Niektórzy zwolennicy prywatności uważają, że jedyną akceptowalną rzeczą jest całkowita prywatność wszystkiego: zaszyfrowanie całego EVM. Uważam, że to może być idealny długoterminowy wynik, ale wymaga to bardziej fundamentalnego przemyślenia modelu programowania i obecnie nie osiągnięto jeszcze poziomu dojrzałości, który byłby gotowy do wdrożenia w Ethereum. Naprawdę potrzebujemy domyślnej prywatności, aby uzyskać wystarczająco dużą grupę anonimowych użytkowników. Jednak najpierw skoncentrowanie się na (i) transferach między kontami oraz (ii) tożsamości i związanych z nią przypadkach użycia (np. prywatne dowody) jest pragmatycznym pierwszym krokiem, łatwiejszym do wdrożenia, a portfel może już teraz zacząć to stosować.
Portfele Ethereum muszą również stać się portfelami danych
Konsekwencją każdego skutecznego rozwiązania prywatności jest to, że niezależnie od tego, czy chodzi o płatności, tożsamość czy inne przypadki użycia, prowadzi to do potrzeby przechowywania danych przez użytkownika poza łańcuchem. Jest to bardzo widoczne w Tornado Cash, które wymaga od użytkowników przechowywania „biletów” reprezentujących depozyty od 0,1 do 100 ETH. Nowoczesne protokoły prywatności czasami przechowują zaszyfrowane dane na łańcuchu i używają pojedynczego klucza prywatnego do ich odszyfrowania. To jest ryzykowne, ponieważ jeśli klucz wycieknie lub komputer kwantowy stanie się wykonalny, dane staną się publiczne. Dowody off-chain, takie jak EAS i Zupass, jeszcze bardziej uwydatniają potrzebę przechowywania danych poza łańcuchem.
Portfel musi nie tylko stać się oprogramowaniem do przechowywania dostępu na łańcuchu, ale także oprogramowaniem do przechowywania twoich danych prywatnych. Świat niekryptograficzny również coraz bardziej to dostrzega, np. zobacz pracę Tima Bernersa-Lee w zakresie przechowywania danych osobowych. Wszystkie problemy, które musimy rozwiązać wokół solidnego zapewnienia kontroli dostępu, musimy także rozwiązać wokół solidnego zapewnienia dostępności danych oraz braku ich wycieku. Może te rozwiązania można połączyć: jeśli masz N opiekunów, użyj M z N podziału tajemnic do przechowywania swoich danych. Dane są z natury trudniejsze do ochrony, ponieważ nie możesz cofnąć udziału w danych, ale powinniśmy dążyć do jak najbezpieczniejszego rozwiązania w zakresie zdecentralizowanego hostingu.
Bezpieczny dostęp do łańcucha
Dziś portfele ufają swoim dostawcom RPC, że powiedzą im wszystko o łańcuchu. To jest luka, która ma dwa aspekty:
Dostawcy RPC mogą próbować kraść pieniądze, podając im fałszywe informacje, np. o cenach rynkowych.
Dostawcy RPC mogą wyciągać prywatne informacje o aplikacjach i innych kontach, z którymi użytkownik wchodzi w interakcję.
W idealnym przypadku chcielibyśmy załatać te dwie luki. Aby rozwiązać pierwszy problem, potrzebujemy ustandaryzowanych lekkich klientów dla L1 i L2, które mogą bezpośrednio weryfikować konsensus blockchaina. Helios już to zrobił dla L1 i prowadzi pewne wstępne prace, aby wspierać niektóre konkretne L2. Aby prawidłowo objąć wszystkie L2, potrzebujemy standardu, w ramach którego umowa konfiguracyjna reprezentująca L2 (także używana do adresów specyficznych dla łańcucha) mogłaby zadeklarować funkcję, prawdopodobnie w sposób podobny do ERC-3668, obejmującą logikę uzyskiwania ostatniego stanu korzenia i weryfikacji dowodów stanów oraz paragonów dla tych korzeni stanów. W ten sposób będziemy mogli mieć uniwersalnego lekkiego klienta, który umożliwia portfelom bezpieczne weryfikowanie jakiegokolwiek stanu lub zdarzenia na L1 i L2.
Dla prywatności, jedynym realnym sposobem dzisiaj jest uruchomienie własnego pełnego węzła. Jednak obecnie L2 stają się bardziej widoczne, a uruchomienie pełnego węzła dla wszystkiego staje się coraz trudniejsze. Równoważnikiem lekkiego klienta jest prywatne wyszukiwanie informacji (PIR). PIR polega na serwerach przechowujących wszystkie kopie danych i klientach wysyłających zaszyfrowane zapytania do serwerów. Serwer wykonuje obliczenia na wszystkich danych, zwraca dane wymagane przez klienta i szyfruje je kluczem klienta, nie ujawniając serwerowi, które dane były dostępne dla klienta.
Aby zachować uczciwość serwera, poszczególne projekty baz danych są same w sobie gałęziami Merkle, więc klient może używać lekkiego klienta do ich weryfikacji.
Obliczenia PIR (Private Information Retrieval - prywatne wyszukiwanie informacji) są bardzo zasobożerne. Istnieje kilka sposobów rozwiązania tego problemu:
Z użyciem brute force: ulepszenia algorytmów lub dedykowanego sprzętu mogą sprawić, że PIR będzie działać wystarczająco szybko. Te technologie mogą polegać na wstępnym przetwarzaniu: serwery mogą przechowywać zaszyfrowane i zamieszane dane dla każdego klienta, a klienci mogą zapytywać te dane. Głównym wyzwaniem w środowisku Ethereum jest przystosowanie tych technologii do szybko zmieniających się zbiorów danych (tak jak w przypadku krajów). To obniża koszty obliczeń w czasie rzeczywistym, ale prawdopodobnie zwiększa całkowite koszty obliczeń i przechowywania.
Osłabienie wymagań prywatności: na przykład, że przy każdym wyszukiwaniu może być tylko 1 milion „mixins”, więc serwer będzie wiedział, że klient ma dostęp do miliona możliwych wartości, ale nie będzie wiedział o żadnej bardziej szczegółowej.
Wieloserwerowe PIR: Jeśli korzystasz z kilku serwerów, a założenie uczciwości między tymi serwerami wynosi 1 z N, to algorytmy PIR będą zazwyczaj szybsze.
Anonimowość zamiast poufności: Możesz wysyłać prośby przez sieć miksującą, co ukrywa nadawcę prośby, a nie ukrywa treści prośby. Jednak skuteczne zrobienie tego nieuchronnie zwiększa opóźnienia, co pogarsza doświadczenia użytkownika.
Znalezienie odpowiedniego zestawu technologii w środowisku Ethereum, aby zmaksymalizować prywatność przy jednoczesnym zachowaniu użyteczności, jest otwartym problemem badawczym, a ja zachęcam kryptografów do próby rozwiązania tego.
Idealny portfel skrytki kluczy
Oprócz przesyłania i dostępu do stanu, innym ważnym przepływem pracy, który musi działać płynnie w kontekście cross-L2, jest zmiana konfiguracji weryfikacji konta: niezależnie od tego, czy chodzi o zmianę jego kluczy (np. odzyskiwanie), czy też o głębsze zmiany w logice konta. Istnieją trzy poziomy rozwiązań, uporządkowane według rosnącej trudności:
Aktualizacje powtórzeń: Gdy użytkownik zmienia swoje ustawienia, wiadomość autoryzująca tę zmianę będzie powtarzana na każdym łańcuchu, na którym portfel wykryje, że użytkownik ma aktywa. Możliwe, że format wiadomości i zasady weryfikacji mogą być niezależne od łańcucha, umożliwiając automatyczne powtarzanie na jak największej liczbie łańcuchów.
Skrytka kluczy na L1: Informacje konfiguracyjne znajdują się na L1, a portfel na L2 używa L1SLOAD do ich odczytu lub zdalnego statycznego wywołania. W ten sposób wystarczy zaktualizować konfigurację na L1, aby automatycznie obowiązywała.
Skrytka kluczy na L2: Informacje konfiguracyjne znajdują się na L2, a portfel na L2 używa ZK-SNARK do ich odczytu. To jest podobne do (2), z wyjątkiem tego, że aktualizacje skrytki kluczy mogą być tańsze, ale z drugiej strony odczyt jest droższy.
Rozwiązanie (3) jest szczególnie potężne, ponieważ dobrze współpracuje z prywatnością. W normalnych „rozwiązaniach prywatności” użytkownik ma tajemnicę s, a na łańcuchu publikuje „wartość liścia” L, a użytkownik dowodzi, że L = hash(s, 1) i N = hash(s, 2) dla jakiejś (nigdy nie ujawnionej) tajemnicy, którą kontroluje. Nieważny symbol N jest publikowany, co zapewnia, że przyszłe wydatki tej samej liści nie powiodą się, nie ujawniając L, które zależą od bezpieczeństwa s użytkownika. Rozwiązanie prywatności przyjazne dla odzyskiwania mówi, że s to lokalizacja (np. adres i slot przechowywania) on-chain, a użytkownik musi udowodnić zapytanie o stan: L = hash(sload(s), 1).
Bezpieczeństwo Dapp
Najsłabszym ogniwem w bezpieczeństwie użytkowników jest zazwyczaj dapp. Najczęściej użytkownicy wchodzą w interakcję z aplikacjami poprzez odwiedzanie stron internetowych, które implicitnie pobierają kod interfejsu użytkownika w czasie rzeczywistym z serwera, a następnie wykonują go w przeglądarce. Jeśli serwer zostanie zhakowany lub DNS zostanie zhakowany, użytkownicy otrzymają fałszywą wersję interfejsu, co może skłonić ich do wykonania dowolnej operacji. Funkcje portfela, takie jak symulacja transakcji, są bardzo pomocne w redukcji ryzyka, ale wciąż są dalekie od doskonałości.
W idealnym przypadku chcielibyśmy przenieść ekosystem na kontrolę wersji treści na łańcuchu: użytkownicy będą uzyskiwać dostęp do dapp za pośrednictwem swojej nazwy ENS, która będzie zawierać IPFS hash interfejsu. Aktualizacje interfejsu będą wymagały transakcji na łańcuchu z wieloma podpisami lub DAO. Portfel pokaże użytkownikowi, czy wchodzi w interakcję z bardziej bezpiecznym interfejsem na łańcuchu czy mniej bezpiecznym interfejsem Web2. Portfel może również pokazać użytkownikowi, czy wchodzi w interakcję z bezpiecznym łańcuchem (np. etap 1+, wieloma audytami bezpieczeństwa).
Dla użytkowników dbających o prywatność portfel może również dodać tryb paranoidalny, wymagający od użytkownika kliknięcia akceptacji żądań HTTP, a nie tylko operacji web3:
Model interfejsu dla trybu paranoidalnego
Bardziej zaawansowanym podejściem jest wyjście poza HTML + Javascript i napisanie logiki biznesowej dapp w dedykowanym języku (prawdopodobnie stosunkowo cienkiej warstwie nad Solidity lub Vyper). Następnie przeglądarka może automatycznie generować interfejs użytkownika dla dowolnej wymaganej funkcji. OKContract już to robi.
Innym kierunkiem jest obrona informacji w ekonomii kryptograficznej: deweloperzy dapp, firmy bezpieczeństwa, wdrożeniowcy łańcuchów i inni mogą ustanowić obligację, która zapłaci poszkodowanym użytkownikom (po ustaleniu) w przypadku, gdy dapp zostanie zhakowany lub w inny sposób zaszkodzi użytkownikom w sposób wysoce wprowadzający w błąd, przez jakąś DAO arbitrażową na łańcuchu. Portfel może pokazać użytkownikowi wynik oparty na wielkości obligacji.
Dalsza przyszłość
Powyższe odbywa się w kontekście tradycyjnego interfejsu, w którym chodzi o wskazywanie, klikanie rzeczy i wprowadzanie rzeczy w pola tekstowe. Jednak znajdujemy się również na skraju głębszej zmiany paradygmatu:
Sztuczna inteligencja, co może doprowadzić nas do przejścia z paradygmatu klikania i pisania do paradygmatu „powiedz, co chcesz zrobić, a robot się tym zajmie”
Interfejsy mózg-komputer, zarówno z „łagodnymi” metodami, jak śledzenie ruchu oczu, jak i bardziej bezpośrednimi, a nawet inwazyjnymi technologiami (patrz: pierwszy pacjent Neuralink w tym roku)
Aktywna obrona klienta: przeglądarka Brave aktywnie chroni użytkowników przed reklamami, trackerami i wieloma innymi szkodliwymi obiektami. Wiele przeglądarek, wtyczek i portfeli kryptograficznych ma całe zespoły, które aktywnie pracują nad ochroną użytkowników przed różnymi zagrożeniami bezpieczeństwa i prywatności. Ci „aktywni strażnicy” tylko w ciągu następnej dekady staną się silniejsi.
Te trzy trendy wspólnie doprowadzą do głębszej refleksji na temat sposobu działania interfejsów. Dzięki naturalnemu wprowadzaniu danych, śledzeniu ruchu oczu lub ostatecznie bardziej bezpośrednim interfejsom mózg-komputer, w połączeniu z twoją historią (być może obejmującą SMS-y, o ile wszystkie dane będą przetwarzane lokalnie), „portfel” może jasno i intuicyjnie zrozumieć, co chcesz zrobić. Następnie sztuczna inteligencja może przekształcić tę intuicję w konkretny „plan działania”: szereg interakcji na łańcuchu i poza nim, aby zrealizować twoje cele. Może to znacznie zmniejszyć zapotrzebowanie na interfejsy użytkownika osób trzecich. Jeśli użytkownik rzeczywiście wchodzi w interakcję z aplikacjami osób trzecich (lub innymi użytkownikami), sztuczna inteligencja powinna reprezentować użytkownika w myśleniu konfrontacyjnym, identyfikując wszelkie zagrożenia i proponując plan działania, aby im zapobiec. Idealnie, te sztuczne inteligencje powinny mieć otwarty ekosystem, wytwarzany przez różne grupy o różnych uprzedzeniach i strukturach motywacyjnych.
Te bardziej radykalne pomysły opierają się na technologii, która jest obecnie bardzo niedojrzała, więc dzisiaj nie zamierzam inwestować moich aktywów w portfelach, które na nich polegają. Niemniej jednak podobne rzeczy wydają się być oczywistym kierunkiem na przyszłość, więc warto zacząć bardziej aktywnie badać tę drogę.
