Besonderer Dank geht an Dan Finlay, Karl Floersch, David Hoffman und die Teams von Scroll und SoulWallet für Feedback, Überprüfung und Vorschläge.

Während Ethereum von einer jungen experimentellen Technologie zu einem ausgereiften Tech-Stack übergeht, der in der Lage ist, durchschnittlichen Nutzern tatsächlich ein offenes, globales und erlaubnisfreies Erlebnis zu bieten, gibt es drei große technische Übergänge, die der Stack ungefähr gleichzeitig durchlaufen muss:

• Der Übergang zur L2-Skalierung – alle wechseln zu Rollups
• Der Übergang zur Wallet-Sicherheit – alle, die auf Smart-Contract-Walletsumsteigen
• Der Übergang zum Datenschutz - Sicherstellung, dass geldtransfers, die die Privatsphäre schützen, verfügbar sind, und sicherstellen, dass alle anderen Gadgets, die entwickelt werden (soziale Erholung, Identität, Reputation), die Privatsphäre schützen

Das Dreieck des Ökosystemübergangs. Sie können nur 3 von 3 auswählen.

Ohne die erste scheitert Ethereum, weil jede Transaktion 3,75 US-Dollar kostet (82,48 US-Dollar, wenn wir einen weiteren Bullenlauf haben), und jedes Produkt, das auf den Massenmarkt abzielt, vergisst unweigerlich die Kette und übernimmt zentralisierte Workarounds für alles.

Ohne die zweite scheitert Ethereum, weil es den Nutzern unangenehm ist, ihre Gelder (und nicht-finanziellen Vermögenswerte) aufzubewahren, und alle wechseln zu zentralisierten Börsen.

Ohne die dritte scheitert Ethereum, weil es für viele Nutzer ein viel zu hohes Datenschutzopfer ist, alle Transaktionen (und POAPs usw.) öffentlich für buchstäblich jeden sichtbar zu haben, und jeder wechselt zu zentralisierten Lösungen, die Ihre Daten zumindest etwas verbergen.

Diese drei Übergänge sind aus den oben genannten Gründen von entscheidender Bedeutung. Aber sie sind auch eine Herausforderung wegen der intensiven Koordination, die erforderlich ist, um sie richtig zu lösen. Es sind nicht nur die Funktionen des Protokolls, die verbessert werden müssen. In einigen Fällen muss sich die Art und Weise, wie wir mit Ethereum interagieren, ziemlich grundlegend ändern, was tiefgreifende Änderungen von Anwendungen und Wallets erfordert.

Die drei Übergänge werden die Beziehung zwischen Nutzern und Adressen radikal verändern

In einer L2-Skalierungswelt werden die Benutzer auf vielen L2-Systemen existieren. Sind Sie Mitglied von ExampleDAO, das von Optimism lebt? Dann haben Sie ein Konto bei Optimism! Halten Sie eine CDP in einem Stablecoin-System auf ZkSync? Dann haben Sie ein Konto bei ZkSync! Haben Sie einmal eine Anwendung ausprobiert, die zufällig auf Kakarot lebte? Dann haben Sie ein Konto bei Kakarot! Die Zeiten, in denen ein Benutzer nur eine Adresse hatte, sind vorbei.

Ich habe ETH an vier Stellen, laut meiner Brave Wallet-Ansicht. Und ja, Arbitrum und Arbitrum Nova sind unterschiedlich. Keine Sorge, es wird mit der Zeit immer verwirrender!

Smart-Contract-Wallets erhöhen die Komplexität, indem sie es viel schwieriger machen, dieselbe Adresse über L1 und die verschiedenen L2s hinweg zu haben. Heutzutage verwenden die meisten Benutzer externe Konten, deren Adresse buchstäblich ein Hash des öffentlichen Schlüssels ist, der zur Überprüfung von Signaturen verwendet wird - zwischen L1 und L2 ändert sich also nichts. Bei Smart-Contract-Wallets wird es jedoch schwieriger, eine Adresse zu behalten. Obwohl viel Arbeit investiert wurde, um Adressen zu Code-Hashes zu machen, die in allen Netzwerken äquivalent sein können, vor allem in CREATE2 und der ERC-2470-Singleton-Factory, ist es schwierig, dies perfekt zum Laufen zu bringen. Einige L2s (z. "Typ 4 ZK-EVMs") sind nicht ganz EVM-äquivalent und verwenden stattdessen häufig Solidity oder eine Zwischenbaugruppe, wodurch eine Hash-Äquivalenz verhindert wird. Und selbst wenn Sie eine Hash-Äquivalenz haben können, führt die Möglichkeit, dass Wallets durch Schlüsseländerungen den Besitzer wechseln, zu anderen unintuitiven Konsequenzen.

Der Datenschutz erfordert, dass jeder Benutzer noch mehr Adressen hat, und kann sogar die Art der Adressen ändern, mit denen wir es zu tun haben. Wenn Stealth-Adressvorschläge weit verbreitet sind, kann es sein, dass jeder Benutzer nicht nur wenige Adressen oder eine Adresse pro L2 hat, sondern eine Adresse pro Transaktion. Andere Datenschutzprogramme, auch bestehende wie Tornado Cash, verändern die Art und Weise, wie Vermögenswerte gespeichert werden, auf andere Weise: Die Gelder vieler Benutzer werden im selben Smart Contract (und damit an derselben Adresse) gespeichert. Um Geld an einen bestimmten Benutzer zu senden, müssen sich die Benutzer auf das interne Adressierungssystem des Datenschutzsystems verlassen.

Wie wir gesehen haben, schwächt jede der drei Übergänge das mentale Modell "ein Benutzer ~= eine Adresse" auf unterschiedliche Weise, und einige dieser Effekte wirken sich auf die Komplexität der Ausführung der Übergänge aus. Zwei besondere Komplexitätspunkte sind:

1. Wenn Sie jemanden bezahlen möchten, wie erhalten Sie die Informationen, wie Sie ihn bezahlen können?
2. Wenn Benutzer viele Assets an verschiedenen Orten in verschiedenen Chains gespeichert haben, wie können sie dann wichtige Änderungen und soziale Wiederherstellungen vornehmen?

Die drei Übergänge und On-Chain-Zahlungen (und Identität)

Ich habe Münzen auf Scroll und möchte für Kaffee bezahlen (wenn das "Ich" buchstäblich ich bin, der Autor dieses Artikels, dann ist "Kaffee" natürlich eine Metonymie für "grüner Tee"). Du verkaufst mir den Kaffee, aber du bist nur darauf eingestellt, Münzen auf Taiko zu erhalten. Was tun?

Grundsätzlich gibt es zwei Lösungen:

1. Empfangende Wallets (bei denen es sich um Händler, aber auch um normale Personen handeln kann) bemühen sich sehr, jedes L2 zu unterstützen, und verfügen über einige automatisierte Funktionen zur asynchronen Konsolidierung von Geldern.
2. Der Empfänger gibt seine L2 zusammen mit seiner Adresse an, und die Wallet des Absenders leitet die Gelder automatisch über ein L2-übergreifendes Bridging-System an das Ziel-L2 weiter.

Natürlich können diese Lösungen kombiniert werden: Der Empfänger stellt die Liste der L2s zur Verfügung, die er zu akzeptieren bereit ist, und die Brieftasche des Absenders ermittelt die Zahlung, die entweder einen direkten Versand beinhalten kann, wenn er Glück hat, oder einen L2-übergreifenden Überbrückungspfad.

Dies ist jedoch nur ein Beispiel für eine zentrale Herausforderung, die die drei Übergänge mit sich bringen: Einfache Aktionen wie das Bezahlen von jemandem erfordern viel mehr Informationen als nur eine 20-Byte-Adresse.

Eine Umstellung auf Smart-Contract-Wallets ist glücklicherweise keine große Belastung für das Adressierungssystem, aber es gibt noch einige technische Probleme in anderen Teilen des Anwendungs-Stacks, die abgearbeitet werden müssen. Wallets müssen aktualisiert werden, um sicherzustellen, dass sie nicht nur 21000 Gas zusammen mit einer Transaktion senden, und es wird noch wichtiger sein, sicherzustellen, dass die Zahlungsempfängerseite einer Wallet nicht nur ETH-Überweisungen von EOAs, sondern auch ETH verfolgt, die per Smart-Contract-Code gesendet werden. Apps, die auf der Annahme beruhen, dass der Adressbesitz unveränderlich ist (z. NFTs, die Smart Contracts verbieten, um Lizenzgebühren durchzusetzen) werden andere Wege finden müssen, um ihre Ziele zu erreichen. Smart-Contract-Wallets werden auch einige Dinge einfacher machen - insbesondere, wenn jemand nur einen Nicht-ETH-ERC20-Token erhält, kann er ERC-4337-Zahlmeister verwenden, um mit diesem Token für Gas zu bezahlen.

Der Datenschutz hingegen stellt uns wieder einmal vor große Herausforderungen, mit denen wir uns noch nicht wirklich auseinandergesetzt haben. Das ursprüngliche Tornado Cash führte keines dieser Probleme ein, da es keine internen Überweisungen unterstützte: Benutzer konnten nur in das System einzahlen und abheben. Sobald Sie jedoch interne Übertragungen vornehmen können, müssen die Benutzer das interne Adressierungsschema des Datenschutzsystems verwenden. In der Praxis müssten die "Zahlungsinformationen" eines Benutzers sowohl (i) eine Art "Ausgaben-Pubkey" enthalten, eine Verpflichtung zu einem Geheimnis, das der Empfänger zum Ausgeben verwenden könnte, als auch (ii) eine Möglichkeit für den Absender, verschlüsselte Informationen zu senden, die nur der Empfänger entschlüsseln kann, um dem Empfänger zu helfen, die Zahlung zu entdecken.

Stealth-Adressprotokolle basieren auf einem Konzept von Metaadressen, die auf diese Weise funktionieren: Ein Teil der Metaadresse ist eine verblindete Version des Ausgabenschlüssels des Absenders, und ein anderer Teil ist der Verschlüsselungsschlüssel des Absenders (obwohl eine minimale Implementierung diese beiden Schlüssel auf die gleichen festlegen könnte).

Schematische Übersicht über ein abstraktes Stealth-Adressschema basierend auf Verschlüsselung und ZK-SNARKs.

Eine wichtige Lektion hier ist, dass ein Benutzer in einem datenschutzfreundlichen Ökosystem sowohl ausgebende Pubkeys als auch Verschlüsselungs-Pubkeys hat und die "Zahlungsinformationen" eines Benutzers beide Schlüssel enthalten müssen. Es gibt auch andere gute Gründe als die Zahlungen, in diese Richtung zu expandieren. Wenn wir beispielsweise Ethereum-basierte verschlüsselte E-Mails wünschen, müssen die Benutzer öffentlich eine Art Verschlüsselungsschlüssel angeben. In der "EOA-Welt" könnten wir dafür Kontoschlüssel wiederverwenden, aber in einer sicheren Smart-Contract-Wallet-Welt sollten wir dafür wahrscheinlich eine explizitere Funktionalität haben. Dies würde auch dazu beitragen, die Ethereum-basierte Identität mit dezentralen Nicht-Ethereum-Datenschutzökosystemen, insbesondere PGP-Schlüsseln, kompatibel zu machen.

Die drei Übergänge und die Wiederherstellung des Schlüssels

Die Standardmethode zum Implementieren von Schlüsseländerungen und sozialer Wiederherstellung in einer Welt mit vielen Adressen pro Benutzer besteht darin, dass Benutzer das Wiederherstellungsverfahren für jede Adresse separat ausführen. Dies kann mit einem Klick erfolgen: Die Wallet kann Software enthalten, um den Wiederherstellungsvorgang für alle Adressen eines Benutzers gleichzeitig auszuführen. Doch selbst mit solchen UX-Vereinfachungen hat die naive Wiederherstellung mehrerer Adressen drei Probleme:

1. Unpraktikabilität der Gaskosten: Dies ist selbsterklärend.
2. Kontrafaktische Adressen: Adressen, für die der Smart Contract noch nicht veröffentlicht wurde (in der Praxis bedeutet dies ein Konto, von dem Sie noch kein Geld überwiesen haben). Sie als Benutzer haben eine potenziell unbegrenzte Anzahl von kontrafaktischen Adressen: eine oder mehrere auf jedem L2, einschließlich L2s, die noch nicht existieren, und eine ganze andere unendliche Menge von kontrafaktischen Adressen, die sich aus Stealth-Adressschemata ergeben.
3. Datenschutz: Wenn ein Benutzer absichtlich viele Adressen hat, um zu vermeiden, dass sie miteinander verknüpft werden, möchte er sicherlich nicht alle öffentlich verknüpfen, indem er sie gleichzeitig oder etwa zur gleichen Zeit wiederherstellt!

Diese Probleme zu lösen, ist schwierig. Glücklicherweise gibt es eine einigermaßen elegante Lösung, die einigermaßen gut funktioniert: eine Architektur, die Verifizierungslogik und Asset-Bestände trennt.

Jeder Benutzer verfügt über einen Keystore-Vertrag, der an einem Ort vorhanden ist (z. B. Mainnet oder ein bestimmtes L2). Benutzer haben dann Adressen auf verschiedenen L2s, wobei die Überprüfungslogik jeder dieser Adressen ein Zeiger auf den Keystore-Vertrag ist. Ausgaben von diesen Adressen würden einen Nachweis erfordern, der in den Keystore-Vertrag aufgenommen wird, aus dem der aktuelle (oder, realistischer, sehr kürzliche) öffentliche Schlüssel für die Ausgaben hervorgeht.

Der Beweis kann auf verschiedene Arten implementiert werden:

• Direkter schreibgeschützter L1-Zugriff innerhalb des L2. Es ist möglich, L2s zu modifizieren, um ihnen die Möglichkeit zu geben, den L1-Status direkt zu lesen. Wenn sich der Keystore-Vertrag auf L1 befindet, würde dies bedeuten, dass Verträge innerhalb von L2 "kostenlos" auf den Keystore zugreifen können
• Merkle-Zweige. Merkle-Verzweigungen können den L1-Zustand in einen L2-Zustand oder den L2-Zustand in einen L1-Zustand beweisen, oder Sie können die beiden kombinieren, um Teile des Zustands eines L2 in ein anderes L2 zu beweisen. Die größte Schwäche von Merkle-Proofs sind die hohen Gaskosten aufgrund der Proof-Länge: potentiell 5 kB für einen Proof, was sich jedoch aufgrund von Verkle-Bäumen in Zukunft auf < 1 kB reduzieren wird.
• ZK-SNARKs. Sie können die Datenkosten senken, indem Sie einen ZK-SNARK eines Merkle-Zweigs anstelle des Zweigs selbst verwenden. Es ist möglich, Off-Chain-Aggregationstechniken (z. B. auf EIP-4337) zu erstellen, um einen einzigen ZK-SNARK alle Cross-Chain-Zustandsnachweise in einem Block verifizieren zu lassen.
• KZG-Verpflichtungen. Entweder L2s oder darauf aufbauende Schemata könnten ein sequentielles Adressierungssystem einführen, das es ermöglicht, dass Zustandsnachweise innerhalb dieses Systems nur 48 Byte lang sind. Wie bei ZK-SNARKs könnte ein Multiproof-Schema all diese Beweise zu einem einzigen Beweis pro Block zusammenführen.

Wenn wir vermeiden wollen, einen Beweis pro Transaktion zu erstellen, können wir ein leichteres Schema implementieren, das nur einen Cross-L2-Beweis für die Wiederherstellung erfordert. Ausgaben von einem Konto hängen von einem Ausgabenschlüssel ab, dessen entsprechender Pubkey in diesem Konto gespeichert ist, aber die Wiederherstellung würde eine Transaktion erfordern, die die aktuelle spending_pubkey im Keystore kopiert. Gelder in kontrafaktischen Adressen sind auch dann sicher, wenn Ihre alten Schlüssel es nicht sind: Um eine kontrafaktische Adresse zu "aktivieren", um sie in einen Arbeitsvertrag umzuwandeln, müssten Sie einen L2-übergreifenden Nachweis erstellen, um die aktuelle spending_pubkey zu kopieren. In diesem Thread in den Safe-Foren wird beschrieben, wie eine ähnliche Architektur funktionieren könnte.

Um einem solchen Schema Privatsphäre zu verleihen, verschlüsseln wir einfach den Zeiger und führen alle unsere Tests innerhalb von ZK-SNARKs durch:

Mit mehr Arbeit (z. mit <a href="https://notes.ethereum.org/@vbuterin/non_index_revealing_proof">this Wir könnten auch den größten Teil der Komplexität von ZK-SNARKs entfernen und ein einfacheres KZG-basiertes Schema erstellen.

Diese Schemata können komplex werden. Auf der positiven Seite gibt es viele potenzielle Synergien zwischen ihnen. Zum Beispiel könnte das Konzept der "Keystore-Verträge" auch eine Lösung für die im vorherigen Abschnitt erwähnte Herausforderung der "Adressen" sein: Wenn wir möchten, dass Benutzer persistente Adressen haben, die sich nicht jedes Mal ändern, wenn der Benutzer einen Schlüssel aktualisiert, könnten wir Stealth-Metaadressen, Verschlüsselungsschlüssel und andere Informationen in den Keystore-Vertrag einfügen und die Adresse des Keystore-Vertrags als "Adresse" eines Benutzers verwenden.

Viele sekundäre Infrastrukturen müssen aktualisiert werden

Der Einsatz von ENS ist teuer. Heute, im Juni 2023, ist die Situation nicht allzu schlimm: Die Transaktionsgebühr ist erheblich, aber immer noch vergleichbar mit der ENS-Domaingebühr. Die Registrierung von 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. Selbst ohne ETH-Preiserhöhungen würde die Rückkehr der Gasgebühren auf 200 Gwei die TX-Gebühr für eine Domainregistrierung auf 104 US-Dollar erhöhen. Wenn wir also wollen, dass die Leute ENS tatsächlich nutzen, insbesondere für Anwendungsfälle wie dezentrale soziale Medien, in denen die Nutzer eine fast kostenlose Registrierung verlangen (und die ENS-Domaingebühr ist kein Problem, weil diese Plattformen ihren Nutzern Subdomains anbieten), brauchen wir ENS, um auf L2 zu arbeiten.

Glücklicherweise hat sich das ENS-Team verstärkt, und ENS auf L2 findet tatsächlich statt! ERC-3668 (auch bekannt als "CCIP-Standard") bietet zusammen mit ENSIP-10 eine Möglichkeit, ENS-Subdomains auf jedem L2 automatisch überprüfbar zu machen. Der CCIP-Standard erfordert die Einrichtung eines Smart Contracts, der eine Methode zur Überprüfung von Datennachweisen auf L2 und einer Domäne (z. Optinames verwendet ecc.eth) kann unter die Kontrolle eines solchen Vertrages gestellt werden. Sobald der CCIP-Vertrag ecc.eth auf L1 kontrolliert, erfordert der Zugriff auf eine Subdomain.ecc.eth automatisch das Finden und Verifizieren eines Nachweises (z. Merkle-Zweig) des Zustands in L2, der diese bestimmte Subdomain tatsächlich speichert.

Um die Beweise tatsächlich abzurufen, muss man zu einer Liste von URLs gehen, die im Vertrag gespeichert sind, was sich zugegebenermaßen wie eine Zentralisierung anfühlt, obwohl ich argumentieren würde, dass dies nicht wirklich der Fall ist: Es handelt sich um ein 1-of-N-Vertrauensmodell (ungültige Beweise werden von der Verifizierungslogik in der Callback-Funktion des CCIP-Vertrags abgefangen, und solange auch nur eine der URLs einen gültigen Beweis zurückgibt, Du bist gut). Die Liste der URLs könnte Dutzende von ihnen enthalten.

Die Bemühungen des ENS CCIP sind eine Erfolgsgeschichte, und sie sollten als Zeichen dafür gewertet werden, dass radikale Reformen, wie wir sie brauchen, tatsächlich möglich sind. Aber es gibt noch viel mehr Reformen auf Anwendungsebene, die durchgeführt werden müssen. Ein paar Beispiele:

• Viele Dapps sind darauf angewiesen, dass Benutzer Off-Chain-Signaturen bereitstellen. Mit externen Konten (EOAs) ist dies einfach. ERC-1271 bietet eine standardisierte Möglichkeit, dies für Smart-Contract-Wallets zu tun. Viele Dapps unterstützen ERC-1271 jedoch immer noch nicht. Das müssen sie auch.
• Dapps, die "Ist dies eine EOA?" verwenden, um zwischen Nutzern und Verträgen zu unterscheiden (z. B. um Übertragungen zu verhindern oder Lizenzgebühren durchzusetzen), werden kaputt gehen. Generell rate ich davon ab, hier eine rein technische Lösung zu suchen; Herauszufinden, ob eine bestimmte Übertragung der kryptografischen Kontrolle eine Übertragung des wirtschaftlichen Eigentums ist oder nicht, ist ein schwieriges Problem und wahrscheinlich nicht lösbar, ohne einige von der Off-Chain-Community betriebene Mechanismen aufzulösen. Höchstwahrscheinlich werden sich die Anwendungen weniger auf die Verhinderung von Überweisungen als vielmehr auf Techniken wie die Harberger-Steuern verlassen müssen.
• Die Art und Weise, wie Wallets mit Ausgaben und Verschlüsselungsschlüsseln interagieren, muss verbessert werden. Derzeit verwenden Wallets häufig deterministische Signaturen, um anwendungsspezifische Schlüssel zu generieren: Das Signieren einer Standard-Nonce (z. B. des Hashs des Anwendungsnamens) mit dem privaten Schlüssel eines EOA erzeugt einen deterministischen Wert, der ohne den privaten Schlüssel nicht generiert werden kann, und ist daher rein technisch sicher. Diese Techniken sind jedoch für die Wallet "undurchsichtig" und hindern die Wallet daran, Sicherheitsüberprüfungen auf Benutzeroberflächenebene zu implementieren. In einem ausgereifteren Ökosystem müssen Signierung, Verschlüsselung und damit verbundene Funktionen expliziter von Wallets gehandhabt werden.
• Light-Clients (z. Helios) muss L2s und nicht nur L1 verifizieren. Heute konzentrieren sich Light Clients auf die Überprüfung der Gültigkeit der L1-Header (unter Verwendung des Light-Client-Sync-Protokolls) und auf die Überprüfung von Merkle-Zweigen des L1-Status und der Transaktionen, die im L1-Header verwurzelt sind. Morgen müssen sie auch einen Nachweis des L2-Zustands verifizieren, der in der in L1 gespeicherten Zustandswurzel verwurzelt ist (eine fortgeschrittenere Version davon würde tatsächlich L2-Vorbestätigungen betrachten).

Wallets müssen sowohl Vermögenswerte als auch Daten schützen

Heutzutage dienen Wallets der Sicherung von Vermögenswerten. Alles befindet sich auf der Kette, und das Einzige, was die Wallet schützen muss, ist der private Schlüssel, der diese Vermögenswerte derzeit schützt. Wenn Sie den Schlüssel ändern, können Sie Ihren vorherigen privaten Schlüssel am nächsten Tag sicher im Internet veröffentlichen. In einer ZK-Welt ist dies jedoch nicht mehr der Fall: Die Wallet schützt nicht nur die Authentifizierungsdaten, sondern speichert auch Ihre Daten.

Die ersten Anzeichen einer solchen Welt sahen wir mit Zupass, dem ZK-SNARK-basierten Identitätssystem, das bei Zuzalu verwendet wurde. Die Benutzer hatten einen privaten Schlüssel, mit dem sie sich beim System authentifizierten, mit dem sie grundlegende Beweise wie "Beweise, dass ich ein Einwohner von Zuzalu bin, ohne zu verraten, welcher" erstellen konnten. Aber das Zupass-System begann auch, andere Apps darauf aufzubauen, vor allem Stempel (Zupass-Version von POAPs).

Einer meiner vielen Zupass-Stempel, der bestätigt, dass ich ein stolzes Mitglied von Team Cat bin.

Das Hauptmerkmal, das Stempel gegenüber POAPs bieten, ist, dass Stempel privat sind: Sie speichern die Daten lokal und Sie können einen Stempel (oder eine Berechnung über die Briefmarken) nur dann jemandem nachweisen, wenn Sie möchten, dass er diese Informationen über Sie hat. Dies birgt jedoch ein zusätzliches Risiko: Wenn Sie diese Informationen verlieren, verlieren Sie Ihre Briefmarken.

Natürlich lässt sich das Problem der Datenspeicherung auf das Problem reduzieren, einen einzigen Verschlüsselungsschlüssel zu besitzen: Ein Dritter (oder sogar die Kette) kann eine verschlüsselte Kopie der Daten enthalten. Dies hat den praktischen Vorteil, dass die von Ihnen ausgeführten Aktionen den Verschlüsselungsschlüssel nicht ändern und daher keine Interaktionen mit dem System erfordern, das Ihren Verschlüsselungsschlüssel sicher aufbewahrt. Aber selbst wenn Sie Ihren Verschlüsselungsschlüssel verlieren, verlieren Sie alles. Und auf der anderen Seite, wenn jemand Ihren Verschlüsselungsschlüssel sieht, sieht er alles, was mit diesem Schlüssel verschlüsselt wurde.

Die De-facto-Lösung von Zupass bestand darin, die Menschen zu ermutigen, ihren Schlüssel auf mehreren Geräten zu speichern (z. B. Laptop und Telefon), da die Wahrscheinlichkeit, dass sie den Zugriff auf alle Geräte gleichzeitig verlieren, gering ist. Wir könnten noch weiter gehen und die geheime Freigabe nutzen, um den Schlüssel zu speichern, der auf mehrere Wächter aufgeteilt ist.

Diese Art der sozialen Wiederherstellung über MPC ist keine ausreichende Lösung für Wallets, da dies bedeutet, dass nicht nur aktuelle Vormünder, sondern auch frühere Vormünder zusammenarbeiten könnten, um Ihr Vermögen zu stehlen, was ein inakzeptabel hohes Risiko darstellt. Aber Datenschutzlecks sind in der Regel ein geringeres Risiko als ein vollständiger Vermögensverlust, und jemand mit einem Anwendungsfall mit hohen Datenschutzanforderungen könnte immer ein höheres Verlustrisiko in Kauf nehmen, indem er den Schlüssel, der mit diesen datenschutzgefährdenden Aktionen verbunden ist, nicht sichert.

Um zu vermeiden, dass der Benutzer mit einem byzantinischen System mit mehreren Wiederherstellungspfaden überfordert wird, müssen Wallets, die die soziale Wiederherstellung unterstützen, wahrscheinlich sowohl die Wiederherstellung von Vermögenswerten als auch die Wiederherstellung von Verschlüsselungsschlüsseln verwalten.

Zurück zur Identität

Eine der Gemeinsamkeiten dieser Änderungen ist, dass sich das Konzept einer "Adresse", einer kryptografischen Kennung, die Sie verwenden, um "Sie" auf der Kette darzustellen, radikal ändern muss. «Anweisungen, wie ich mit mir interagieren kann» wäre nicht mehr nur eine ETH-Adresse; sie müssten in irgendeiner Form eine Kombination aus mehreren Adressen auf mehreren L2s, Stealth-Metaadressen, Verschlüsselungsschlüsseln und anderen Daten sein.

Eine Möglichkeit, dies zu tun, besteht darin, ENS zu Ihrer Identität zu machen: Ihr ENS-Eintrag könnte einfach all diese Informationen enthalten, und wenn Sie jemandem bob.eth (oder bob.ecc.eth, oder...), könnten sie nachschlagen und alles darüber sehen, wie sie bezahlen und mit Ihnen interagieren können, auch auf kompliziertere domänenübergreifende und datenschutzfreundliche Weise.

Dieser ENS-zentrierte Ansatz hat jedoch zwei Schwächen:

• Es bindet zu viele Dinge an Ihren Namen. Dein Name ist nicht du, dein Name ist eines von vielen Attributen von dir. Es sollte möglich sein, Ihren Namen zu ändern, ohne Ihr gesamtes Identitätsprofil zu verschieben und eine ganze Reihe von Datensätzen in vielen Anwendungen zu aktualisieren.
• Man kann keine vertrauenswürdigen kontrafaktischen Namen haben. Ein wichtiges UX-Merkmal jeder Blockchain ist die Möglichkeit, Coins an Personen zu senden, die noch nicht mit der Chain interagiert haben. Ohne eine solche Funktionalität gibt es einen Haken 22: Die Interaktion mit der Kette erfordert die Zahlung von Transaktionsgebühren, die... bereits Münzen haben. ETH-Adressen, einschließlich Smart-Contract-Adressen mit CREATE2, verfügen über diese Funktion. ENS-Namen tun dies nicht, denn wenn zwei Bobs beide außerhalb der Chain entscheiden, dass sie bob.ecc.eth sind, Es gibt keine Möglichkeit zu wählen, wer von ihnen den Namen bekommt.

Eine mögliche Lösung besteht darin, mehr Dinge in den Keystore-Vertrag einzufügen, der in der Architektur weiter oben in diesem Beitrag erwähnt wurde. Der Keystore-Vertrag könnte all die verschiedenen Informationen über Sie und die Interaktion mit Ihnen enthalten (und mit CCIP könnten einige dieser Informationen außerhalb der Kette liegen), und die Benutzer würden ihren Keystore-Vertrag als primäre Kennung verwenden. Aber die tatsächlichen Vermögenswerte, die sie erhalten, würden an allen möglichen verschiedenen Orten aufbewahrt. Keystore-Verträge sind nicht an einen Namen gebunden und kontrafaktfreundlich: Sie können eine Adresse generieren, die nachweislich nur durch einen Keystore-Vertrag initialisiert werden kann, der bestimmte feste Anfangsparameter hat.

Eine andere Kategorie von Lösungen hat damit zu tun, das Konzept der benutzerorientierten Adressen ganz aufzugeben, ähnlich wie beim Bitcoin-Zahlungsprotokoll. Eine Idee ist, stärker auf direkte Kommunikationskanäle zwischen Sender und Empfänger zu setzen; Der Absender könnte beispielsweise einen Reklamationslink (entweder als explizite URL oder als QR-Code) senden, über den der Empfänger die Zahlung nach Belieben annehmen kann.

Unabhängig davon, ob der Absender oder der Empfänger zuerst handelt, könnte eine stärkere Abhängigkeit von Wallets, die direkt aktuelle Zahlungsinformationen in Echtzeit generieren, die Reibungsverluste verringern. Persistente Identifikatoren sind jedoch praktisch (insbesondere bei ENS), und die Annahme einer direkten Kommunikation zwischen Absender und Empfänger ist in der Praxis sehr knifflig, so dass wir am Ende eine Kombination verschiedener Techniken sehen können.

Bei all diesen Designs ist es von größter Bedeutung, die Dinge sowohl dezentralisiert als auch für die Benutzer verständlich zu halten. Wir müssen sicherstellen, dass die Benutzer einfachen Zugang zu einer aktuellen Ansicht darüber haben, was ihre aktuellen Vermögenswerte sind und welche Nachrichten veröffentlicht wurden, die für sie bestimmt sind. Diese Ansichten sollten von offenen Tools abhängen, nicht von proprietären Lösungen. Es wird harte Arbeit erfordern, um zu verhindern, dass sich die größere Komplexität der Zahlungsinfrastruktur in einen undurchsichtigen "Turm der Abstraktion" verwandelt, in dem es den Entwicklern schwer fällt, die Vorgänge zu verstehen und an neue Kontexte anzupassen. Trotz der Herausforderungen ist das Erreichen von Skalierbarkeit, Wallet-Sicherheit und Datenschutz für normale Nutzer entscheidend für die Zukunft von Ethereum. Dabei geht es nicht nur um die technische Machbarkeit, sondern auch um die tatsächliche Zugänglichkeit für normale Nutzer. Wir müssen uns dieser Herausforderung stellen.

Verzichtserklärung:

1. Dieser Artikel ist ein Nachdruck von [vitalik], Alle Urheberrechte liegen beim ursprünglichen Autor [Vitalik Buterin]. Wenn es Einwände gegen diesen Nachdruck gibt, wenden Sie sich bitte an das Gate Learn-Team , das sich umgehend darum kümmern wird.
2. Haftungsausschluss: Die in diesem Artikel geäußerten Ansichten und Meinungen sind ausschließlich die des Autors und stellen keine Anlageberatung dar.
3. Übersetzungen des Artikels in andere Sprachen werden vom Gate Learn-Team durchgeführt. Sofern nicht anders angegeben, ist das Kopieren, Verbreiten oder Plagiieren der übersetzten Artikel verboten.