Vitalik: Um eine groß angelegte Implementierung zu erreichen, muss Ethereum drei Transformationen durchlaufen: L2, Wallet und Datenschutz

2023-06-12 01:46:22

Original: „Die drei Übergänge“

Geschrieben von: Vitalik Buterin

Kompilieren: MarsBit, MK

Wenn sich Ethereum von einer jungen experimentellen Technologie zu einem ausgereiften Technologie-Stack wandelt, der normalen Benutzern wirklich ein offenes, globales und erlaubnisfreies Erlebnis bieten kann, muss der Stack ungefähr gleichzeitig drei große technologische Transformationen durchlaufen:

L2-Skalierungsverschiebung – alle migrieren zu Rollups
Änderung der Wallet-Sicherheit – jeder migriert zu Smart-Contract-Wallets
Datenschutzverschiebung – Stellen Sie sicher, dass Geldtransfers die Privatsphäre wahren, und stellen Sie sicher, dass alle anderen Tools, die entwickelt werden (soziale Wiederherstellung, Identität, Reputation), die Privatsphäre wahren

![Vitalik: Um eine groß angelegte Implementierung zu erreichen, muss Ethereum drei Transformationen durchlaufen: L2, Wallet und Datenschutz] (https://img.gateio.im/social/moments-69a80767fe-898e667808-dd1a6f-62a40f)

Dies ist das Dreieck der Ökosystemtransformation. Sie können nur 3 von 3 auswählen.

Ohne das erste würde Ethereum scheitern, weil jede Transaktion 3,75 US-Dollar kosten würde (82,48 US-Dollar, wenn wir einen weiteren Bullenlauf hätten), und jedes Massenmarktprodukt am Ende die Kette vergessen würde und eine zentralisierte Lösung für alles nehmen würde.

Ohne die zweite Option würde Ethereum scheitern, da die Benutzer ihre Gelder (und nichtfinanziellen Vermögenswerte) nur ungern aufbewahren würden und alle auf zentralisierte Börsen umsteigen würden.

Ohne einen Dritten würde Ethereum scheitern, da alle Transaktionen (und POAPs usw.) für jedermann sichtbar wären, was für viele Benutzer einen übermäßigen Verlust der Privatsphäre bedeuten würde, und jeder würde sich dafür einsetzen, dass zumindest einige versteckte Daten zentralisiert werden Lösung.

Aus den oben genannten Gründen sind diese drei Übergänge von entscheidender Bedeutung. Sie stellen jedoch auch eine Herausforderung dar, da zu ihrer Lösung eine intensive Koordination erforderlich ist. Es muss nicht nur die Funktionalität des Protokolls verbessert werden, es gibt auch Fälle, in denen ziemlich grundlegende Änderungen an der Art und Weise vorgenommen werden müssen, wie wir mit Ethereum interagieren, was tiefgreifende Änderungen an Anwendungen und Wallets erfordert.

Diese drei Veränderungen werden die Beziehung zwischen Benutzern und Adressen revolutionieren

In einer L2-erweiterten Welt werden Benutzer in vielen L2s existieren. Sind Sie Mitglied von BeispielDAO, das sich auf Optimismus konzentriert? Dann haben Sie ein Konto bei Optimism! Halten Sie CDP im Stablecoin-System von ZkSync? Dann haben Sie ein Konto bei ZkSync! Haben Sie einige Apps ausprobiert, die zufällig auf Kakarot verfügbar sind? Dann haben Sie ein Konto bei Kakarot! Vorbei sind die Zeiten, in denen Benutzer nur eine Adresse hatten.

Laut meiner Brave Wallet-Ansicht habe ich ETH an vier Orten. Ja, Arbitrum und Arbitrum Nova sind unterschiedlich. Keine Sorge, das wird mit der Zeit immer komplizierter!

Smart-Contract-Wallets erhöhen die Komplexität und machen es schwieriger, auf L1 und verschiedenen L2s die gleiche Adresse zu haben. Heutzutage verwenden die meisten Benutzer externe Konten, deren Adressen tatsächlich der Hash des öffentlichen Schlüssels sind, der zur Überprüfung der Signatur verwendet wird – zwischen L1 und L2 ändert sich also nichts. Allerdings wird es bei Smart Contract Wallets schwieriger, eine Adresse zu verwalten. Obwohl viel Arbeit in den Versuch gesteckt wurde, Adressen im gesamten Netzwerk, insbesondere in CREATE2- und ERC-2470-Singleton-Factorys, zu einem Code-Hash zu machen, war es sehr schwierig, dies perfekt zu machen. Einige L2s (z. B. „ZK-EVMs vom Typ 4“) sind nicht vollständig äquivalent zu EVMs und verwenden stattdessen normalerweise Solidity oder eine Zwischenbaugruppe, wodurch eine Hash-Äquivalenz verhindert wird. Selbst wenn es eine Hash-Äquivalenz geben könnte, hat die Möglichkeit, dass Wallets durch Schlüsseländerungen den Besitzer wechseln, andere nicht intuitive Konsequenzen.

Der Datenschutz erfordert mehr Adressen pro Benutzer und kann sogar die Art der von uns verarbeiteten Adressen ändern. Wenn der Vorschlag für private Adressen weit verbreitet ist, könnte es statt nur ein paar Adressen pro Benutzer oder einer Adresse pro L2 eine Adresse pro Transaktion geben. Andere Datenschutzsysteme, auch bestehende wie Tornado Cash, ändern die Art und Weise, wie Vermögenswerte anders gespeichert werden: Die Gelder vieler Benutzer werden im selben Smart Contract (und damit an derselben Adresse) gespeichert. Um Geld an einen bestimmten Benutzer zu senden, muss sich der Benutzer auf das interne Adresssystem des Datenschutzsystems verlassen.

Wie wir gesehen haben, schwächten die drei Verschiebungen das mentale Modell „ein Benutzer ~ = eine Adresse“ auf unterschiedliche Weise, und einige dieser Effekte wirkten sich auf die Komplexität der Implementierung der Verschiebungen aus. Zwei besondere Komplikationen sind:

Wenn Sie jemanden bezahlen möchten, wie erhalten Sie die Informationen, um ihn zu bezahlen?
Wenn ein Benutzer viele Vermögenswerte an verschiedenen Orten in verschiedenen Ketten speichert, wie führt er dann den Schlüsselaustausch und die soziale Wiederherstellung durch?

Drei Übergänge hängen mit Zahlungen in der Kette (und Identität) zusammen.

Ich habe Münzen auf Scroll und möchte für Kaffee bezahlen (wenn „ich“ mich wörtlich als Autor dieses Artikels bezeichnet, dann ist „Kaffee“ natürlich ein Metonym für „grüner Tee“). Du verkaufst mir Kaffee, bekommst aber nur Münzen für Taiko. Was kann ich tun?

Grundsätzlich gibt es zwei Lösungen:

Die empfangende Wallet (könnte ein Händler oder auch nur eine normale Einzelperson sein) ist bestrebt, jedes L2 mit einigen automatischen Funktionen zur asynchronen Integration von Geldern zu unterstützen.
Der Empfänger gibt seinen L2 und seine Adresse an, und die Wallet des Absenders leitet das Geld automatisch über eine Art Inter-L2-Überbrückungssystem an den Ziel-L2 weiter.

Natürlich können diese Lösungen kombiniert werden: Der Empfänger stellt die L2-Liste zur Verfügung, die er akzeptieren möchte, und das Wallet des Absenders berechnet die Zahlung, die über eine direkte Übertragung (wenn er Glück hat) oder über einen überbrückten Pfad über die L2 erfolgen kann.

Aber das ist nur ein Beispiel für die größte Herausforderung, die die drei Schichten mit sich bringen: Für etwas so Einfaches wie das Bezahlen einer Person sind mehr Informationen erforderlich als nur eine 20-Byte-Adresse.

Die Umstellung auf Smart Contract Wallets hat das Adresssystem glücklicherweise nicht stark belastet, es gibt jedoch noch einige technische Probleme, die in anderen Teilen des Anwendungsstapels behoben werden müssen. Wallets müssen aktualisiert werden, um sicherzustellen, dass sie nicht nur 21.000 Gas in Transaktionen senden, sondern, was noch wichtiger ist, um sicherzustellen, dass die Zahlungsempfangsseite des Wallets nicht nur ETH-Transfers von EOAs verfolgt, sondern auch ETH, die per Smart-Contract-Code gesendet werden. Anwendungen, die auf der Annahme eines unveränderlichen Besitzes von Adressen beruhen (z. B. NFTs, die Smart Contracts verbieten, um Lizenzgebühren durchzusetzen), müssen andere Wege finden, um ihre Ziele zu erreichen. Smart-Contract-Wallets werden auch einige Dinge einfacher machen – insbesondere, wenn jemand nur Nicht-ETH-ERC20-Token akzeptiert, kann er einen ERC-4337-Zahler verwenden, um mit diesem Token für Benzin zu bezahlen.

Andererseits stellt der Datenschutz wiederum große Herausforderungen dar, die wir noch nicht wirklich gelöst haben. Beim ursprünglichen Tornado Cash traten diese Probleme nicht auf, da es keine internen Überweisungen unterstützte: Benutzer konnten nur in das System einzahlen und abheben. Sobald Sie interne Übertragungen durchführen können, müssen Benutzer das interne Adressschema des Datenschutzsystems verwenden. In der Praxis muss die „Zahlungsnachricht“ eines Benutzers (i) eine Art „öffentlichen Ausgabenschlüssel“ enthalten, das Versprechen eines Geheimnisses, mit dem der Empfänger Geld ausgeben kann, und (ii) der Absender eine verschlüsselte Nachricht senden, die nur der Der Empfänger kann eine Methode entschlüsseln, um den Empfängern dabei zu helfen, Zahlungen zu entdecken.

Das Privacy-Adress-Protokoll basiert auf dem Konzept einer Metaadresse, das folgendermaßen funktioniert: Ein Teil der Metaadresse ist eine blinde Version des Ausgabeschlüssels des Absenders und der andere Teil ist der Verschlüsselungsschlüssel des Absenders (allerdings nur minimale Implementierungen). kann dies einstellen. Beide Schlüssel sind gleich).

Die wichtigste Lektion hier ist, dass in einem datenschutzorientierten Ökosystem Benutzer über öffentliche Schlüssel für Ausgaben und Verschlüsselung verfügen und die „Zahlungsinformationen“ der Benutzer beide Schlüssel enthalten müssen. Neben der Bezahlung gibt es noch weitere gute Gründe, in diese Richtung zu expandieren. Wenn wir beispielsweise E-Mails auf Ethereum verschlüsseln wollten, müssten Benutzer öffentlich einen Verschlüsselungsschlüssel bereitstellen. In einer „EOA-Welt“ könnten wir Kontoschlüssel wiederverwenden, um dies zu erreichen, aber in einer Welt sicherer Smart-Contract-Wallets sollten wir wahrscheinlich über explizitere Funktionen verfügen, um dies zu erreichen. Dies wird auch dazu beitragen, die Kompatibilität von auf Ethereum basierenden Identitäten mit dezentralen Datenschutz-Ökosystemen zu verbessern, die nicht auf Ethereum basieren. Das bekannteste Beispiel sind PGP-Schlüssel.

Drei Transformationen und Schlüsselwiederherstellung

In einer Welt, in der ein Benutzer möglicherweise über mehrere Adressen verfügt, besteht die Standardmethode zur Implementierung wichtiger Änderungen und sozialer Wiederherstellung darin, dass der Benutzer Wiederherstellungsvorgänge für jede Adresse einzeln durchführt. Dies ist mit einem Klick möglich: Wallets können Software enthalten, um Wiederherstellungsvorgänge für die Adressen aller Benutzer gleichzeitig durchzuführen. Doch selbst bei einer solchen UX-Vereinfachung gibt es drei Probleme bei der naiven Wiederherstellung mehrerer Adressen:

Unrealistische Gasrechnungen: Diese spricht für sich.
Kontrafaktische Adresse: eine Adresse, deren Smart Contract nicht veröffentlicht wurde (tatsächlich bedeutet dies ein Konto, von dem Sie noch kein Geld gesendet haben). Als Benutzer verfügen Sie über eine potenziell unendliche Anzahl kontrafaktischer Adressen: eine oder mehrere auf jedem L2, einschließlich L2s, die noch nicht existieren, und einen völlig anderen Satz unendlicher kontrafaktischer Adressen, die aus dem steganografischen Adressschema abgeleitet sind.
Datenschutz: Wenn ein Benutzer absichtlich viele Adressen hat, um eine Verknüpfung derselben zu vermeiden, möchte er auf keinen Fall alle öffentlich verknüpfen, indem er sie gleichzeitig oder ungefähr gleichzeitig wiederherstellt!

Die Lösung dieser Probleme ist schwierig. Glücklicherweise gibt es eine ziemlich elegante Lösung, die recht gut funktioniert: eine Architektur, die die Validierungslogik vom Asset-Halten trennt.

Jeder Benutzer verfügt über einen Keystore-Vertrag, der an einem Ort existiert (könnte das Mainnet oder ein bestimmtes L2 sein). Benutzer haben dann Adressen auf verschiedenen L2s, wobei die Verifizierungslogik für jede Adresse ein Zeiger auf den Keystore-Vertrag ist. Für Ausgaben von diesen Adressen ist ein Nachweis im Keystore-Vertrag erforderlich, der den aktuellen (oder realistischeren, neuesten) öffentlichen Schlüssel für die Ausgaben zeigt.

Der Nachweis kann auf mehreren Wegen erfolgen:

Nur lesender L1-Zugriff direkt in L2. L2 kann geändert werden, um ihnen die Möglichkeit zu geben, den Status von L1 direkt zu lesen. Wenn sich der Keystore-Vertrag auf L1 befindet, bedeutet dies, dass Verträge in L2 „freien“ Zugriff auf den Keystore haben.
Merkel-Filiale. Merkle-Zweige können L1-Zustände zu L2 oder L2-Zustände zu L1 beweisen, oder Sie können die beiden kombinieren, um Teile eines L2-Zustands zu einem anderen L2 zu beweisen. Die Hauptschwäche von Merkle-Proofs sind die hohen Gaskosten aufgrund der Prooflänge: Ein Proof benötigt möglicherweise 5 kB, obwohl dieser dank Verkle-Bäumen in Zukunft auf weniger als 1 kB reduziert werden wird.
ZK-SNARKs. Sie können die Datenkosten senken, indem Sie ZK-SNARKs von Merkle-Filialen anstelle der Filialen selbst verwenden. Off-Chain-Aggregationstechniken (z. B. basierend auf EIP-4337) können so aufgebaut werden, dass ein einziger ZK-SNARK alle kettenübergreifenden Zustandsnachweise in einem Block überprüft.
KZG-Engagement. L2 oder darauf aufbauende Schemata können ein sequentielles Adressierungssystem einführen, das es ermöglicht, dass Zustandsnachweise innerhalb dieses Systems nur 48 Bytes lang sind. Wie ZK-SNARKs kann ein Multi-Proof-Schema alle diese Beweise in einem einzigen Beweis für jeden Block kombinieren.

Wenn wir vermeiden möchten, für jede Transaktion einen Beweis zu erstellen, können wir eine einfachere Lösung implementieren und müssen bei der Wiederherstellung nur einen L2-übergreifenden Beweis durchführen. Die Ausgabe von einem Konto hängt von einem Ausgabenschlüssel ab, dessen entsprechender öffentlicher Schlüssel im Konto gespeichert ist. Für die Wiederherstellung ist jedoch eine Transaktion erforderlich, bei der der aktuelle öffentliche Ausgabenschlüssel im Keystore kopiert wird. Gelder in einer kontrafaktischen Adresse sind sicher, auch wenn Ihr alter Schlüssel dies nicht ist: Um eine kontrafaktische Adresse zu „aktivieren“ und sie in einen Arbeitsvertrag umzuwandeln, ist ein L2-übergreifender Nachweis erforderlich, der den aktuellen öffentlichen Schlüssel für Ausgaben repliziert. Dieser Thread in den Safe-Foren beschreibt, wie eine ähnliche Architektur funktionieren könnte.

Um einem solchen Schema mehr Privatsphäre zu verleihen, müssen wir nur den Zeiger verschlüsseln und dann alle Beweise in ZK-SNARKs durchführen:

Mit mehr Arbeit (z. B. indem wir diese Arbeit als Ausgangspunkt verwenden) können wir auch die Komplexität von ZK-SNARKs weitgehend reduzieren und ein einfacheres KZG-basiertes Schema erstellen.

Diese Szenarien können kompliziert werden. Es gibt jedoch viele potenzielle Synergien zwischen diesen Programmen. Beispielsweise könnte das Konzept eines „Keystore-Vertrags“ auch eine Lösung für die im vorherigen Abschnitt erwähnte „Adress“-Herausforderung sein: Wenn wir möchten, dass Benutzer dauerhafte Adressen haben, die sich nicht ändern, wenn Benutzer ihre Schlüssel aktualisieren, ist dies der Fall Es ist möglich, geheime Metaadressen, Verschlüsselungsschlüssel und andere Informationen in einen Keystore-Vertrag einzufügen und die Adresse des Keystore-Vertrags als „Adresse“ des Benutzers zu verwenden.

Viele sekundäre Infrastrukturen müssen aktualisiert werden

Die Verwendung von ENS ist teuer. Heute, im Juni 2023, sieht es nicht so schlecht aus: Die Transaktionsgebühren sind zwar hoch, aber vergleichbar mit den ENS-Domaingebühren. Die Registrierung bei zuzalu.eth kostete mich etwa 27 US-Dollar, davon 11 US-Dollar Transaktionsgebühren. Aber wenn wir einen weiteren Bullenmarkt haben, werden die Gebühren in die Höhe schnellen. Auch ohne die ETH-Preiserhöhung würde die Rückkehr der Gasgebühr auf 200 Gwei die Transaktionsgebühr für die Domainregistrierung auf 104 US-Dollar erhöhen. Wenn wir also möchten, dass die Leute ENS tatsächlich nutzen, insbesondere für Anwendungsfälle wie dezentrale soziale Medien, bei denen Benutzer eine nahezu kostenlose Registrierung verlangen (ENS-Domaingebühren sind kein Problem, da diese Plattformen Subdomains für ihre Benutzer bereitstellen), benötigen wir ENS Runs auf L2 .

Glücklicherweise ist das ENS-Team bereits unterwegs und ENS auf L2 findet tatsächlich statt! ERC-3668 (auch als „CCIP-Standard“ bekannt) bietet zusammen mit ENSIP-10 eine Methode zur automatischen Validierung von ENS-Subdomänen auf jedem L2. Der CCIP-Standard erfordert die Einrichtung eines Smart Contracts, der eine Methode zur Überprüfung von Nachweisen von L2-Daten beschreibt, und Domänennamen (z. B. ecc.eth für Optinames) können unter die Kontrolle eines solchen Vertrags gestellt werden. Sobald der CCIP-Vertrag ecc.eth auf L1 kontrolliert, erfordert der Zugriff auf einige subdomain.ecc.eth automatisch das Finden und Überprüfen des L2-Status des Beweises (z. B. Merkle-Zweig), der diese bestimmte Subdomain tatsächlich speichert.

Um tatsächlich Beweise zu erhalten, muss auf eine Reihe von im Vertrag gespeicherten URLs zugegriffen werden, was sich zugegebenermaßen wie eine Zentralisierung anfühlt, obwohl ich argumentieren würde, dass dies tatsächlich nicht der Fall ist: Es handelt sich um ein 1-aus-N-Vertrauensmodell (ungültige Beweise würden durch die CCIP-Verifizierung blockiert). Die Logik in der Rückruffunktion des Vertrags erfasst, dass es kein Problem gibt, solange es eine URL gibt, die einen gültigen Beweis zurückgibt. Diese URL-Liste kann Dutzende URLs enthalten.

Die Arbeit der ENS CCIP ist eine Erfolgsgeschichte und sollte als Zeichen dafür gesehen werden, dass die Art radikaler Reform, die wir brauchen, möglich ist. Es sind jedoch weitere Reformen auf Anwendungsebene erforderlich. Einige Beispiele sind:

Viele Dapps sind darauf angewiesen, dass Benutzer Signaturen außerhalb der Kette bereitstellen. Bei Externally Owned Accounts (EOAs) ist das ganz einfach. ERC-1271 bietet hierfür eine standardisierte Möglichkeit für Smart Contract Wallets. Allerdings unterstützen viele Dapps ERC-1271 immer noch nicht; sie müssen es unterstützen.

Dapps, die „Ist das EOA?“ verwenden, um zwischen Benutzern und Verträgen zu unterscheiden (z. B. um Übertragungen zu verhindern oder Lizenzgebühren durchzusetzen), werden nicht funktionieren. Im Allgemeinen würde ich davon abraten, eine rein technische Lösung zu finden; die Frage, herauszufinden, ob eine bestimmte Übertragung der kryptografischen Kontrolle eine Übertragung von wirtschaftlichen Interessen ist, ist eine schwierige Frage, die möglicherweise nicht gelöst werden kann, ohne auf eine Community außerhalb der Kette zurückzugreifen. angetriebene Mechanismen. Als nächstes lösen. Höchstwahrscheinlich müssen sich Anträge weniger auf die Sperrung von Überweisungen als vielmehr auf Techniken wie die Harberger-Steuer verlassen.

Die Interaktion von Wallets mit Ausgaben und Verschlüsselungsschlüsseln muss verbessert werden. Derzeit verwenden Wallets typischerweise deterministische Signaturen, um anwendungsspezifische Schlüssel zu generieren: Durch das Signieren einer Standard-Nonce (z. B. eines Hashs des Anwendungsnamens) mit dem privaten Schlüssel der EOA wird eine Nonce generiert, die ohne den privaten Schlüssel nicht generiert werden kann. Der deterministische Wert von , es ist also technisch sicher. Allerdings sind diese Techniken für das Wallet „undurchsichtig“ und verhindern, dass Wallets Sicherheitsüberprüfungen auf Benutzeroberflächenebene implementieren. In einem ausgereifteren Ökosystem müssen Signierung, Verschlüsselung und verwandte Funktionen expliziter von Wallets gehandhabt werden.

Light-Clients (z. B. Helios) müssen L2 verifizieren, nicht nur L1. Heutzutage konzentrieren sich Light-Clients auf die Überprüfung der Gültigkeit des L1-Headers (unter Verwendung des Light-Client-Synchronisierungsprotokolls) und auf die Validierung des L1-Status und der Merkle-Forks von Transaktionen, die vom L1-Header ausgehen. Morgen müssen sie auch den Beweis des L2-Zustands verifizieren, der aus der in L1 gespeicherten Zustandswurzel stammt (diese fortgeschrittenere Version befasst sich tatsächlich mit der Vorbestätigung von L2).

Wallets müssen Vermögenswerte und Daten schützen

Die Aufgabe des Wallets besteht nun darin, Vermögenswerte zu schützen. Alles ist in der Kette und das Einzige, was die Wallet schützen muss, sind die privaten Schlüssel, die diese Vermögenswerte derzeit schützen. Wenn Sie den Schlüssel ändern, können Sie Ihren bisherigen privaten Schlüssel am nächsten Tag sicher im Internet veröffentlichen. In einer Welt wissensfreier Beweise ist dies jedoch nicht mehr der Fall: Wallets schützen nicht nur Authentifizierungsdaten, sondern auch Ihre Daten.

Die ersten Anzeichen einer solchen Welt sahen wir mit Zupass, dem auf ZK-SNARK basierenden Identitätssystem, das bei Zuzalu verwendet wird. Benutzer verfügen über einen privaten Schlüssel, mit dem sie das System authentifizieren und mit dem sie grundlegende Beweise wie „Beweisen, dass ich in Zuzalu ansässig bin, aber nicht preisgeben, welcher“ durchgeführt werden können. Auf dem Zupass-System wurden jedoch auch andere Anwendungen aufgebaut, insbesondere Stamps (Zupass-Version von POAPs).

Einer meiner vielen Zupass-Stempel, der beweist, dass ich stolzes Mitglied von Team Cat bin.

Das Hauptmerkmal, das Stempel gegenüber POAPs bieten, besteht darin, dass Stempel privat sind: Sie speichern die Daten lokal und weisen ihnen den Stempel (oder eine darauf basierende Berechnung) nur dann nach, wenn Sie möchten, dass sie über diese Informationen über Sie verfügen. Damit erhöht sich jedoch das Risiko: Wenn Sie diese Informationen verlieren, verlieren Sie Ihren Stempel.

Natürlich läuft das Problem der Speicherung von Daten auf das Problem der Speicherung eines kryptografischen Schlüssels hinaus: Ein Dritter (oder sogar die Kette) kann eine verschlüsselte Kopie der Daten besitzen. Dies hat den praktischen Vorteil, dass die von Ihnen vorgenommene Aktion den Verschlüsselungsschlüssel nicht ändert, sodass keine Interaktion mit dem System erforderlich ist, das Ihren Verschlüsselungsschlüssel sicher verwahrt. Aber selbst dann verlieren Sie alles, wenn Sie Ihren Verschlüsselungsschlüssel verlieren. Wenn umgekehrt jemand Ihren Verschlüsselungsschlüssel sieht, kann er alles sehen, was mit diesem Schlüssel verschlüsselt ist.

Die De-facto-Lösung von Zupass besteht darin, Menschen dazu zu ermutigen, ihre Schlüssel auf mehreren Geräten (z. B. Laptop und Telefon) zu speichern, da die Wahrscheinlichkeit, dass sie alle gleichzeitig verlieren, gering ist. Wir können noch einen Schritt weiter gehen und eine geheime Freigabe zum Speichern des Schlüssels verwenden und den Schlüssel auf mehrere Wächter aufteilen.

Diese soziale Wiederherstellung über MPC ist keine adäquate Lösung für Wallets, da sie bedeutet, dass nicht nur aktuelle, sondern auch frühere Vormunde zusammenarbeiten können, um Ihr Vermögen zu stehlen, was ein inakzeptabel hohes Risiko darstellt. Allerdings stellt eine Verletzung der Privatsphäre in der Regel ein geringeres Risiko dar als ein vollständiger Verlust von Vermögenswerten, und wenn jemand einen Anwendungsfall mit hohem Datenschutz benötigt, kann er ein höheres Verlustrisiko in Kauf nehmen, indem er die zugehörigen Schlüssel, die die Privatsphäre erfordern, nicht sichert. bewahrende Handlungen.

Um Benutzer nicht mit einem komplexen System aus mehreren Wiederherstellungspfaden zu überfordern, müssen Wallets, die Social Recovery unterstützen, möglicherweise sowohl die Wiederherstellung von Vermögenswerten als auch die Wiederherstellung von Verschlüsselungsschlüsseln verwalten.

Zurück zur Identitätsfrage

Ein gemeinsames Thema dieser Änderungen ist, dass sich das Konzept einer „Adresse“, die Sie in der Kette als kryptografische Kennung verwenden, die „Sie“ repräsentiert, radikal ändern muss. „Anweisungen zur Interaktion mit mir“ sind nicht mehr nur eine ETH-Adresse; sie müssen in irgendeiner Form eine Kombination aus mehreren Adressen auf mehreren L2s, geheimen Metaadressen, Verschlüsselungsschlüsseln und anderen Daten enthalten.

Eine Möglichkeit, dies zu tun, besteht darin, ENS zu Ihrer Identität zu machen: Ihr ENS-Datensatz kann alle diese Informationen enthalten, und wenn Sie jemandem bob.eth (oder bob.ecc.eth oder …) senden, kann er es herausfinden und mehr darüber erfahren alle Dinge, die sich auszahlen und mit Ihnen interagieren, auch auf komplexere, bereichsübergreifende und die Privatsphäre schützende Weise.

Dieser ENS-zentrierte Ansatz weist jedoch zwei Schwächen auf:

Es bindet zu viele Dinge an deinen Namen. Ihr Name ist nicht Sie, Ihr Name ist nur eines Ihrer vielen Attribute. Sie sollten in der Lage sein, Ihren Namen zu ändern, ohne Ihr gesamtes Identitätsprofil zu verschieben und eine Reihe von Datensätzen in vielen Apps zu aktualisieren.
Sie können keine nicht vertrauenswürdigen kontrafaktischen Namen haben. Eine wichtige UX-Funktion jeder Blockchain ist die Möglichkeit, Münzen an Personen zu senden, die noch nicht mit der Kette interagiert haben. Ohne eine solche Funktionalität gibt es ein Henne-Ei-Problem: Für die Interaktion mit der Kette müssen Transaktionsgebühren gezahlt werden, und für die Zahlung von Gebühren müssen Sie bereits Münzen besitzen. ETH-Adressen, einschließlich Smart-Contract-Adressen mit CREATE2, verfügen über diese Funktion. Der ENS-Name gilt nicht, denn wenn zwei Bobs beide entscheiden, dass sie bob.ecc.eth außerhalb der Kette sind, gibt es keine Möglichkeit auszuwählen, welcher den Namen erhält.

Eine mögliche Lösung besteht darin, mehr Dinge in den Keystore-Vertrag aufzunehmen, der weiter oben in diesem Beitrag in der Architektur erwähnt wurde. Der Keystore-Vertrag kann verschiedene Informationen über Sie und Ihre Interaktion mit ihm enthalten (über CCIP, einige davon können außerhalb der Kette erfolgen), und Benutzer können ihren Keystore-Vertrag als primäre Kennung verwenden. Die eigentlichen Vermögenswerte, die sie erhalten, werden jedoch an verschiedenen Orten gespeichert. Keystore-Verträge sind nicht an Namen gebunden, sondern kontrafaktisch: Sie können eine Adresse generieren, die nur durch einen Keystore-Vertrag mit einigen festen Anfangsparametern initialisiert werden kann.

Eine weitere Lösungskategorie besteht darin, das Konzept der benutzerorientierten Adressen aufzugeben, das im Geiste dem Bitcoin-Zahlungsprotokoll ähnelt. Eine Idee besteht darin, stärker auf direkte Kommunikationskanäle zwischen Absender und Empfänger zu setzen; der Absender könnte beispielsweise einen Anspruchslink (als explizite URL oder QR-Code) senden, den der Empfänger verwenden könnte, um Zahlungen nach seinen Wünschen anzunehmen.

Unabhängig davon, ob der Absender oder der Empfänger zuerst handelt, verringert sich die Reibung, wenn man sich stärker auf Wallets verlässt, um aktuelle Zahlungsinformationen direkt und in Echtzeit zu generieren. Allerdings sind persistente Identifikatoren praktisch (insbesondere bei ENS) und in der Praxis stellt die Annahme einer direkten Kommunikation zwischen Sender und Empfänger ein sehr heikles Problem dar, sodass wir möglicherweise eine Kombination verschiedener Technologien in Betracht ziehen.

Bei all diesen Designs ist es wichtig, die Dinge sowohl dezentral als auch für die Benutzer verständlich zu halten. Wir müssen sicherstellen, dass Benutzer problemlos auf die aktuellste Ansicht ihrer aktuellen Vermögenswerte sowie auf für sie bestimmte veröffentlichte Informationen zugreifen können. Diese Ansichten sollten sich eher auf offene Tools als auf proprietäre Lösungen stützen. Es wird harte Arbeit erfordern, zu verhindern, dass eine komplexere Zahlungsinfrastruktur zu einem undurchsichtigen „Turm der Abstraktion“ wird, in dem Entwickler Schwierigkeiten haben, zu verstehen, was vor sich geht, und es an neue Umgebungen anzupassen. Trotz der Herausforderungen ist es von größter Bedeutung, die Skalierbarkeit, Wallet-Sicherheit und den Datenschutz von Ethereum für normale Benutzer zu erreichen. Dabei geht es nicht nur um die technische Machbarkeit, sondern auch um die tatsächliche Zugänglichkeit für den durchschnittlichen Benutzer. Dieser Herausforderung müssen wir uns stellen.

Besonderer Dank geht an Dan Finlay, Karl Floersch, David Hoffman und die Scroll- und SoulWallet-Teams für ihr Feedback, ihre Rezensionen und Vorschläge.

Original anzeigen

Diese Seite kann Inhalte Dritter enthalten, die ausschließlich zu Informationszwecken bereitgestellt werden (keine Zusicherungen oder Garantien), und sie sind nicht als Billigung der darin geäußerten Ansichten durch Gate oder als finanzielle bzw. fachliche Beratung zu verstehen. Weitere Informationen finden Sie im Haftungsausschluss.