Originalautor: Vitalik Buterin
Übersetzung und Bearbeitung: DeFi 之道
Besonderer Dank geht an Ben DiFrancesco, Matt Solomon, Toni Wahrstätter und Antonio Sanso für ihr Feedback und ihre Prüfung.
Datenschutz bleibt eine der größten Herausforderungen im Ethereum-Ökosystem. Standardmäßig sind alle Inhalte, die auf einer öffentlichen Blockchain landen, für jeden einsehbar. Das betrifft inzwischen nicht nur Geld- und Finanztransaktionen, sondern auch ENS-Domains, POAPs, NFTs und seelengebundene Token („soulbound tokens“). Wer das volle Spektrum der Ethereum-Anwendungen nutzt, macht damit zwangsläufig einen erheblichen Teil seines digitalen Lebens öffentlich – für jeden sichtbar und analysierbar.
Wie sich dieser Zustand verbessern lässt, ist inzwischen als zentrale Frage anerkannt. Bisher konzentrierte sich die Debatte über Datenschutzverbesserungen jedoch vor allem auf einen speziellen Anwendungsfall: den privaten Transfer von ETH und gängigen ERC-20-Token (meist Selbstüberweisungen). Dieser Artikel beleuchtet Mechanismen und Anwendungsfälle einer anderen Klasse von Werkzeugen, die den Datenschutz auf Ethereum in weit mehr Szenarien stärken können: sogenannte „Stealth Addresses“ („versteckte Adressen“).
Was ist ein Stealth-Adress-System?
Nehmen wir an, Alice möchte Bob einen Vermögenswert schicken. Das könnte eine bestimmte Menge Kryptowährung sein (z. B. 1 ETH oder 500 RAI) oder auch ein NFT. Bob möchte, wenn er den Vermögenswert erhält, nicht, dass die ganze Welt mitbekommt, dass er der Empfänger ist. Dass eine Transaktion stattgefunden hat, zu verbergen, ist unmöglich – besonders bei einem NFT, von dem es nur ein einziges Exemplar auf der Blockchain gibt. Aber zu verschleiern, wer der Empfänger ist, das sollte möglich sein. Alice und Bob sind zudem bequem: Sie wünschen sich einen Zahlungsvorgang, der genauso einfach ist wie heute. Bob schickt Alice (oder hinterlegt unter seinem ENS-Namen) eine Art „Adresse“, die kodiert, wie ihm jemand etwas schicken kann. Allein mit dieser Information sollte Alice (oder jeder andere) ihm Vermögenswerte zusenden können.
Beachten Sie: Dies bietet eine andere Art von Datenschutz als Werkzeuge wie Tornado Cash. Zwar kann Tornado Cash den Transfer gängiger, austauschbarer Assets wie ETH oder wichtiger ERC-20-Token verschleiern (wobei Selbstüberweisungen am einfachsten sind), doch es eignet sich kaum, um Datenschutz für unbekannte ERC-20-Transfers zu bieten, und für NFT-Transfers bietet es überhaupt keinen Schutz.
Der übliche Ablauf einer Kryptowährungszahlung. Wir möchten den Datenschutz erhöhen (niemand soll erfahren, dass Bob der Empfänger ist), aber den Ablauf so einfach wie möglich halten.
Genau hier setzen Stealth Addresses an. Eine Stealth Address ist eine Adresse, die entweder von Alice oder Bob erzeugt werden kann, aber ausschließlich von Bob kontrolliert wird. Bob generiert einen geheimen Ausgabeschlüssel („spending key“) und nutzt ihn, um eine sogenannte „Stealth Meta-Adresse“ zu erstellen. Diese Meta-Adresse gibt er an Alice weiter (oder hinterlegt sie unter seinem ENS-Namen). Alice kann nun Berechnungen mit dieser Meta-Adresse durchführen, um eine Stealth Address zu generieren, die Bob gehört. Anschließend kann sie jeden gewünschten Vermögenswert an diese Adresse senden – Bob behält die volle Kontrolle darüber. Bei der Transaktion veröffentlicht sie zusätzlich einige kryptografische Daten (einen temporären öffentlichen Schlüssel) auf der Blockchain, die Bob dabei helfen, zu erkennen, dass diese Adresse tatsächlich ihm gehört.
Anders ausgedrückt: Stealth Addresses bieten Bob denselben Datenschutz, als würde er für jede Transaktion eine neue Adresse erstellen – allerdings ohne dass Bob selbst aktiv werden muss.
Der vollständige Ablauf eines Stealth-Adress-Systems sieht folgendermaßen aus:
1. Bob generiert seinen Wurzelausgabeschlüssel (m) und seine Stealth-Metaadresse (M).
2. Bob trägt M als seine Stealth-Metaadresse im ENS unter bob.eth ein.
3. Alice weiß, dass Bob bob.eth gehört. Sie sucht im ENS nach seiner Stealth-Metaadresse M.
4. Alice generiert einen einmaligen, geheimen temporären Schlüssel, den sie ausschließlich für die Erzeugung dieser spezifischen Stealth-Adresse verwendet.
5. Mithilfe eines Algorithmus kombiniert Alice ihren temporären Schlüssel mit Bobs Metaadresse, um eine Stealth-Adresse zu erzeugen. An diese Adresse kann sie nun Vermögenswerte senden.
6. Zusätzlich generiert Alice ihren temporären öffentlichen Schlüssel und veröffentlicht ihn im entsprechenden öffentlichen Register. Dies kann in derselben Transaktion geschehen, mit der sie die Vermögenswerte an die Stealth-Adresse überweist.
7. Um die ihm gehörenden Stealth-Adressen zu finden, muss Bob das Register der temporären öffentlichen Schlüssel durchsuchen. Dabei holt er sich alle Schlüssel ab, die seit seinem letzten Scan von irgendwem veröffentlicht wurden.
8. Für jeden gefundenen temporären öffentlichen Schlüssel kombiniert Bob diesen mit seinem eigenen Wurzelausgabeschlüssel, um eine potenzielle Stealth-Adresse zu berechnen. Enthält diese Adresse Vermögenswerte, berechnet Bob den dazugehörigen Ausgabeschlüssel und speichert ihn.
Dieses Verfahren basiert auf zwei kryptografischen Verheimlichungstechniken. Zunächst benötigen wir ein Paar Algorithmen zur Erzeugung eines gemeinsamen Geheimnisses: Einer nutzt Alices geheime Komponente (ihren temporären Schlüssel) und Bobs öffentliche Komponente (seine Metaadresse), der andere Bobs geheime Komponente (seinen Wurzelausgabeschlüssel) und Alices öffentliche Komponente (ihren temporären öffentlichen Schlüssel). Dies lässt sich auf verschiedene Arten umsetzen. Der Diffie-Hellman-Schlüsselaustausch, eine der wegweisenden Errungenschaften der modernen Kryptographie, erfüllt genau diesen Zweck.
Ein gemeinsames Geheimnis allein genügt jedoch nicht. Würden wir daraus einfach einen privaten Schlüssel ableiten, könnten sowohl Alice als auch Bob von dieser Adresse aus Transaktionen tätigen. Theoretisch könnte Bob die Mittel dann auf eine neue Adresse überweisen, aber das wäre ineffizient und würde die Sicherheit unnötig beeinträchtigen. Daher kommt ein Schlüssel-Blinding-Mechanismus zum Einsatz: Ein weiteres Algorithmenpaar ermöglicht es Bob, das gemeinsame Geheimnis mit seinem Wurzelausgabeschlüssel zu kombinieren, während Alice es mit Bobs Metaadresse verknüpfen kann. So kann Alice die Stealth-Adresse erzeugen und Bob den dazugehörigen Ausgabeschlüssel berechnen – ohne dass öffentliche Verbindungen zwischen der Stealth-Adresse und Bobs Metaadresse (oder zwischen verschiedenen Stealth-Adressen) entstehen.
Stealth-Adressen mit elliptischer Kurven-Kryptographie
Stealth-Adressen auf Basis elliptischer Kurven wurden im Bitcoin-Kontext erstmals 2014 von Peter Todd vorgestellt. Die Funktionsweise dieser Technik ist wie folgt (Grundkenntnisse in elliptischer Kurven-Kryptographie werden vorausgesetzt; Tutorials finden sich hier, hier und hier):
• Bob generiert einen privaten Schlüssel m und berechnet den öffentlichen Schlüssel M = G * m, wobei G der vereinbarte Generatorpunkt der elliptischen Kurve ist. Die Stealth-Metaadresse ist eine Kodierung von M.
• Alice generiert einen temporären privaten Schlüssel r und veröffentlicht den zugehörigen öffentlichen Schlüssel R = G * r.
• Alice kann das gemeinsame Geheimnis S = M * r berechnen, Bob hingegen S = m * R. Beide gelangen zum selben Wert S.
• Adressen in Bitcoin und Ethereum (einschließlich korrekt konzipierter ERC-4337-Konten) sind üblicherweise Hashes des für Transaktionen gültigen öffentlichen Schlüssels. Wer den öffentlichen Schlüssel kennt, kann also die Adresse ableiten. Den öffentlichen Schlüssel P berechnet man mit P = M + G * hash(S).
• Den privaten Schlüssel p für diese Adresse kann nur Bob berechnen: p = m + hash(S). Damit sind alle zuvor genannten Anforderungen erfüllt – und das auf elegante, einfache Weise!
Mittlerweile gibt es sogar ein EIP, das einen Standard für Stealth-Adressen in Ethereum definieren will. Es unterstützt sowohl die beschriebene Methode als auch alternative Ansätze – etwa separate Ausgabe- und Betrachtungsschlüssel für Bob oder quantensichere Kryptographie. Man könnte meinen, Stealth-Adressen seien theoretisch ausgereift und ihre Umsetzung eine rein technische Frage. Die Herausforderung liegt jedoch in den Details: Eine wirklich effektive Implementierung erfordert die Bewältigung einiger komplexer technischer Hürden.
Steganografische Adressen und Transaktionsgebühren
Nehmen wir an, jemand möchte Ihnen ein NFT senden. Um Ihre Privatsphäre zu wahren, schickt er es an eine von Ihnen kontrollierte steganografische Adresse. Sobald Ihre Wallet den ephemeren öffentlichen Schlüssel in der Blockchain erkennt, findet sie diese Adresse automatisch. Nun können Sie problemlos nachweisen, dass Sie der Besitzer des NFTs sind, oder es weitergeben. Doch es gibt ein Problem: Das Konto enthält kein ETH, sodass keine Transaktionsgebühren bezahlt werden können. Selbst ein ERC-4337-Token-Payer hilft hier nicht weiter, da dieser nur für fungible ERC-20-Token ausgelegt ist. Und ETH von Ihrer Haupt-Wallet dorthin zu überweisen, kommt ebenfalls nicht infrage – das würde eine öffentlich sichtbare Verbindung herstellen.
Für Autoren ist es eine bewährte Technik, sich als Kenner der Szene zu positionieren: Sie binden ein Meme einer bekannten Krypto-Betrugsfigur aus dem Jahr 2017 oder früher ein. Das signalisiert, dass sie schon lange dabei sind, über einen ausgeprägten Geschmack verfügen und sich nicht so leicht von Figuren wie SBF täuschen lassen.
Es gibt eine „einfache“ Lösung für das Gebührenproblem: Man überträgt die Mittel einfach per ZK-SNARKs, um die Kosten zu decken! Allerdings verbraucht dieser Ansatz enorme Mengen an Gas – eine einzige Transaktion schlägt bereits mit mehreren Zehntausend zusätzlichen Gas-Einheiten zu Buche.
Eine elegantere Lösung setzt auf spezialisierte Transaktions-Aggregatoren (im MEV-Jargon „Searcher“ genannt). Diese ermöglichen es Nutzern, einmalig zu bezahlen und dafür eine Reihe von „Tickets“ zu erwerben, mit denen sie später Transaktionsgebühren auf der Blockchain begleichen können. Möchte ein Nutzer ein NFT von einer leeren steganografischen Adresse ausgeben, übergibt er dem Aggregator eines dieser Tickets – verschlüsselt mit einem Chaumian-Blindungsschema. Dieses Protokoll stammt ursprünglich aus den zentralisierten, datenschutzorientierten E-Geld-Systemen der 1980er und 1990er Jahre. Der Searcher akzeptiert das „Ticket“ und sorgt dafür, dass die Transaktion kostenlos in sein Bundle aufgenommen wird, bis sie erfolgreich in einem Block bestätigt ist. Da es sich nur um kleine Beträge handelt, die ausschließlich für Gebühren verwendet werden, sind Vertrauens- und Regulierungsfragen hier deutlich weniger kritisch als bei einer vollständigen Implementierung eines solchen zentralisierten E-Geld-Systems.
Steganografische Adressen mit separaten Ausgabe- und Ansichtsschlüsseln
Angenommen, Bob möchte nicht nur einen einzigen „Root-Ausgabeschlüssel“ verwenden, der alle Funktionen übernimmt. Stattdessen setzt er auf separate Root-Ausgabeschlüssel und Ansichtsschlüssel. Der Ansichtsschlüssel erlaubt es, alle steganografischen Adressen von Bob einzusehen, gestattet jedoch keine Ausgaben daraus.
In der Welt der elliptischen Kurven lässt sich dies mit einem einfachen kryptografischen Trick umsetzen:
• Bobs Meta-Adresse M hat nun die Form (K, V), kodiert als G * k und G * v, wobei k der Ausgabeschlüssel und v der Ansichtsschlüssel ist.
• Der gemeinsame geheime Wert lautet nun S = V * r = v * R, wobei r weiterhin Alices temporärer Schlüssel ist und R ihr veröffentlichter temporärer öffentlicher Schlüssel.
• Der öffentliche Schlüssel der steganografischen Adresse ist P = K + G * hash(S), der private Schlüssel p = k + hash(S).
Interessant ist hier der kryptografische Ablauf: Der erste Schritt (die Generierung des gemeinsamen geheimen Werts) nutzt den Ansichtsschlüssel, während der zweite Schritt (der parallele Algorithmus von Alice und Bob zur Generierung der Adresse und ihres privaten Schlüssels) auf den Root-Ausgabeschlüssel zurückgreift.
Das eröffnet zahlreiche Anwendungsmöglichkeiten. Wenn Bob beispielsweise POAPs empfangen möchte, kann er seiner POAP-Wallet (oder sogar einer weniger sicheren Weboberfläche) seinen Ansichtsschlüssel übergeben. Diese kann dann die Blockchain scannen und alle seine POAPs anzeigen – ohne die Berechtigung zu haben, diese auch auszugeben.
Steganografische Adressen und vereinfachtes Scannen
Um das Scannen der vielen temporären öffentlichen Schlüssel zu erleichtern, kann man jedem von ihnen ein Ansichts-Tag hinzufügen. Eine Möglichkeit, dies im beschriebenen Mechanismus umzusetzen, ist, das Ansichts-Tag als ein Byte des gemeinsamen geheimen Werts zu definieren (z. B. die x-Koordinate von S mod 256 oder das erste Byte von hash(S)).
Auf diese Weise muss Bob für jeden temporären öffentlichen Schlüssel nur eine einzige elliptische Kurven-Multiplikation durchführen, um den gemeinsamen geheimen Wert zu berechnen. Die aufwändigeren Berechnungen zur Generierung und Prüfung der vollständigen Adresse sind dann nur noch in 1/256 aller Fälle nötig.
Steganografische Adressen und Quantensicherheit
Das beschriebene Schema basiert auf elliptischen Kurven – eine bewährte, aber leider anfällige Wahl gegenüber Quantencomputern. Sollten Quantencomputer zur realen Bedrohung werden, müssen wir auf quantensichere Algorithmen umsteigen. Zwei naheliegende Kandidaten hierfür sind Isogenien elliptischer Kurven und gitterbasierte Kryptografie („Lattices“).
Elliptische-Kurven-Isogenien sind eine völlig andere, auf elliptischen Kurven basierende mathematische Konstruktion. Ihre linearen Eigenschaften erlauben kryptografische Techniken, die den oben beschriebenen ähneln, dabei aber geschickt jene zyklischen Gruppen umgehen, die für Quantencomputer-Angriffe über diskrete Logarithmen anfällig sein könnten.
Die größte Schwäche isogeniebasierter Kryptografie liegt in ihrer hochkomplexen zugrundeliegenden Mathematik und dem Risiko, dass sich in dieser Komplexität mögliche Angriffsvektoren verbergen könnten. Zwar wurden im letzten Jahr einige isogeniebasierte Protokolle geknackt, andere gelten jedoch weiterhin als sicher. Der Hauptvorteil von Isogenien sind vergleichsweise kleine Schlüsselgrößen und die Möglichkeit, viele etablierte Verfahren von elliptischen Kurven direkt zu übernehmen.
3-Isogenien im CSIDH. Quelle: hier.
Gitter („Lattices“) bilden eine völlig andere kryptografische Struktur, die auf einfacherer Mathematik als elliptische Kurvenisogenien beruht und dennoch außergewöhnlich leistungsfähige Funktionen ermöglicht – wie etwa die vollständig homomorphe Verschlüsselung (FHE). Auch Stealth-Adressen-Schemata lassen sich auf Gittern aufbauen, wobei die Entwicklung optimaler Schemata noch ein offenes Forschungsproblem darstellt. Ein Nachteil gitterbasierter Strukturen sind jedoch oft deutlich größere Schlüsselgrößen.
Vollständig homomorphe Verschlüsselung (FHE) ist eine Anwendung von Gittern. FHE kann Stealth-Adressen-Protokolle auch auf alternative Weise unterstützen: Sie ermöglicht es Bob, die Berechnung auszulagern, ob in der gesamten Blockchain Vermögenswerte an seine Stealth-Adresse gesendet wurden – und das, ohne seinen View-Key preiszugeben.
Die dritte Methode besteht darin, Stealth-Adressen-Schemata aus universellen „Black-Box“-Primitiven aufzubauen – also aus grundlegenden Bausteinen, die viele Personen ohnehin aus anderen Gründen benötigen. Der Teil zur Generierung des gemeinsamen Geheimnisses entspricht direkt einem Schlüsselaustausch, einem Kernelement jedes Public-Key-Verschlüsselungssystems. Schwieriger ist die Entwicklung paralleler Algorithmen, bei denen Alice ausschließlich Stealth-Adressen (nicht aber Ausgabeschlüssel) generiert, während Bob die Ausgabeschlüssel erzeugt.
Leider lässt sich ein Stealth-Adressen-Schema nicht aus einfacheren Primitiven konstruieren als jenen, die für ein Public-Key-Verschlüsselungssystem nötig sind. Ein einfacher Beweis: Mit einem Stealth-Adressen-Schema lässt sich ein Public-Key-Verschlüsselungssystem bauen. Wenn Alice Bob eine Nachricht verschlüsseln möchte, kann sie N Transaktionen senden, wobei jede entweder an eine seiner Stealth-Adressen oder an eine eigene geht; Bob kann dann anhand der empfangenen Transaktionen die Nachricht decodieren. Das ist wichtig, weil mathematisch bewiesen ist, dass Public-Key-Verschlüsselung allein mit Hash-Funktionen unmöglich ist, während Zero-Knowledge-Beweise sehr wohl nur mit Hash-Funktionen realisierbar sind. Daher können Stealth-Adressen nicht ausschließlich auf Hash-Funktionen beruhen.
Es gibt jedoch einen Ansatz, der vergleichsweise einfache Bausteine nutzt: Zero-Knowledge-Beweise, die aus Hash-Funktionen und (schlüsselverbergender) Public-Key-Verschlüsselung bestehen können. Bobs Meta-Adresse besteht aus einem öffentlichen Verschlüsselungsschlüssel plus einem Hash h = hash(x); sein Ausgabeschlüssel umfasst den entsprechenden Entschlüsselungsschlüssel sowie x. Um eine Stealth-Adresse zu erstellen, generiert Alice einen Wert c und veröffentlicht die für Bob lesbare Verschlüsselung von c als ihren temporären öffentlichen Schlüssel. Die Adresse selbst ist ein ERC-4337-Konto, dessen Code Transaktionen nur dann validiert, wenn diese einen Zero-Knowledge-Beweis liefern, der den Besitz der Werte x und c nachweist, sodass k = hash(hash(x), c) gilt (wobei k der Account-Code ist). Kennt Bob x und c, kann er Adresse und Code selbst rekonstruieren.
Die Verschlüsselung von c verrät Bob gegenüber niemandem weitere Informationen, und k ist ein Hash-Wert, der praktisch keinerlei Rückschlüsse auf c zulässt. Der Wallet-Code selbst enthält lediglich k, während c privat bleibt – das bedeutet, dass k nicht auf h zurückverfolgt werden kann.
Allerdings erfordert dieser Ansatz einen STARK, und STARKs sind sehr groß. Langfristig bin ich überzeugt, dass die post-quantum-fähige Ethereum-Welt viele Anwendungen umfassen wird, die zahlreiche STARKs nutzen. Daher befürworte ich, wie hier beschrieben, ein Aggregationsprotokoll, das all diese STARKs in einen rekursiven STARK zusammenfasst, um Speicherplatz zu sparen.
Stealth-Adressen sowie Social Recovery und Multi-L2-Wallets
Ich bin seit langem ein Befürworter von Social-Recovery-Wallets: Wallets mit einem Multisignatur-Mechanismus, bei dem die Schlüssel zwischen Institutionen, Ihren anderen Geräten und Ihren Freunden verteilt sind. So kann die Mehrheit dieser Schlüssel den Zugriff auf Ihr Konto wiederherstellen, falls Sie Ihren Hauptschlüssel verlieren.
Social-Recovery-Wallets harmonieren jedoch nicht gut mit Stealth-Adressen. Falls Sie Ihr Konto wiederherstellen müssen (also den privaten Schlüssel ändern, der es kontrolliert), müssen Sie zusätzlich die Validierungslogik Ihrer N Stealth-Wallets anpassen – was N Transaktionen erfordert und hohe Kosten in Bezug auf Gebühren, Benutzerfreundlichkeit und Privatsphäre verursacht.
Auch die Interaktion zwischen einer Welt mit sozialer Wiederherstellung und mehreren Layer-2-Protokollen wirft Fragen auf: Wer Konten auf Optimism, Arbitrum, Starknet, Scroll und Polygon unterhält – und aus Skalierungsgründen auf einigen dieser Rollups vielleicht sogar dutzende parallele Instanzen mit jeweils eigenem Konto – für den kann ein Schlüsselwechsel zu einer äußerst komplexen Operation werden.
Den Schlüssel für mehrere Konten über verschiedene Blockchains hinweg zu wechseln, ist eine enorme Herausforderung.
Eine Möglichkeit ist, einfach davon auszugehen, dass Wiederherstellungen selten sind und hohe Kosten sowie Unannehmlichkeiten in Kauf genommen werden können. Vielleicht lassen sich automatisierte Tools nutzen, um Vermögenswerte über einen Zeitraum von zwei Wochen in zufälligen Abständen an neue verdeckte Adressen zu übertragen und so zeitbasierte Verknüpfungen zu erschweren. Doch das ist keine perfekte Lösung. Eine andere Möglichkeit wäre, den Root-Schlüssel geheim zwischen den Guardians zu teilen, anstatt auf eine Smart Contract-basierte Wiederherstellung zu setzen. Das würde jedoch die Möglichkeit ausschließen, Guardians später die Berechtigung zu entziehen, was langfristig ein Risiko darstellt.
Ein komplexerer Ansatz nutzt Zero-Knowledge-Beweise (ZKPs). Stellen Sie sich das oben beschriebene ZKP-basierte Schema vor, jedoch mit einer Modifikation: Das Konto speichert nicht direkt k = hash(hash(x), c), sondern eine (versteckte) Chain-basierte Commitment-Adresse für k. Um von diesem Konto aus Transaktionen durchzuführen, ist dann ein Zero-Knowledge-Beweis nötig, der (i) belegt, dass man die Chain-Position kennt, die zu diesem Commitment passt, und (ii) dass der Wert an dieser Position ein k enthält (das nicht offengelegt wird), und dass man Werte x und c besitzt, die die Gleichung k = hash(hash(x), c) erfüllen.
Dadurch lassen sich viele Konten – sogar über mehrere Layer-2-Protokolle hinweg – über einen einzigen k-Wert an einer zentralen Stelle (entweder auf der Basis-Chain oder einem bestimmten Layer-2) kontrollieren. Ein einziger Wertwechsel reicht aus, um den Besitz aller Konten zu übertragen – und das, ohne Verbindungen zwischen den Konten preiszugeben.
Fazit
Grundlegende Stealth-Adressen ließen sich schon heute relativ schnell implementieren und würden die Privatsphäre von Ethereum-Nutzern erheblich verbessern. Allerdings müssten Wallets entsprechende Anpassungen vornehmen, um sie zu unterstützen. Ich bin jedoch der Meinung, dass Wallets aus anderen Datenschutzgründen ohnehin zunehmend zu einem nativeren Multi-Adress-Modell übergehen sollten – etwa indem für jede Interaktion mit einer Anwendung eine neue Adresse generiert wird.
Stealth-Adressen bringen jedoch langfristig gewisse Usability-Probleme mit sich, etwa bei der sozialen Wiederherstellung. Diese Nachteile kann man vorerst in Kauf nehmen, indem man akzeptiert, dass soziale Wiederherstellung entweder mit einem Privatsphärenverlust einhergeht oder dass Wiederherstellungstransaktionen über zwei Wochen verteilt werden müssen, um verschiedene Vermögenswerte schrittweise zu übertragen – was externe Dienstleister übernehmen könnten. Langfristig sind diese Probleme lösbar; der dauerhafte Erfolg eines Stealth-Adress-Ökosystems scheint jedoch stark von Zero-Knowledge-Beweisen abzuhängen.