727 FinanceEin Vorfall nimmt nicht nur Vermögenswerte, sondern auch Vertrauen. Krypto kann so nicht weitermachen; wir müssen uns selbst retten.
Autor: Robert Mao, Gründer und CEO von ArcBlock
Dieser Artikel ist zur freien Vervielfältigung und Weiterleitung durch jedermann autorisiert, in der Hoffnung, dass mehr Menschen diesen Aufruf an die Branche zur Selbstrettung sehen.
Crypto kann so nicht weitermachen. Immer wieder nehmen massiven Diebstähle nicht nur Vermögenswerte, sondern auch das Vertrauen der Teilnehmer in die gesamte Branche. Wir müssen uns selbst retten.
Am 29. Oktober 2026 ereignete sich bei Binance ein schwerwiegender Sicherheitsvorfall. In seiner vorläufigen Ankündigung schätzte das Unternehmen, dass etwa 6,3 Milliarden US-Dollar an Vermögenswerten betroffen waren, und etwa 3 Milliarden US-Dollar der betroffenen Vermögenswerte eingefroren wurden; die Untersuchung deutete zunächst auf den Laptop eines DevOps-Ingenieurs hin, und in der Folge wurden auch weitere mögliche Eindringpunkte entdeckt. Binance erklärte zudem, dass keine Hinweise auf ein Leck der Wallet-Privatschlüssel gefunden worden seien. Der betroffene Betrag ist nicht der endgültige Nettoverlust, und die vollständige Angriffskette wird weiterhin untersucht. [[1]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-binance)
Diese Initiative richtet sich an die Erbauer von Blockchain-Projekten wie Ethereum und Solana sowie an Binance, Coinbase, Kraken und alle Börsen, Wallets, Protokolle und Sicherheitsentwickler, die bereit sind, teilzunehmen: Lasst uns gemeinsam das Fundament zum Schutz von Vermögenswerten wieder aufbauen. Ich bin bereit, teilzunehmen, und ich hoffe, dass mehr Menschen gemeinsam handeln.
Das ist bereits schwer genug. Was mir jedoch mehr Sorgen bereitet, ist, wie viel Vertrauen in Crypto dieser Vorfall zerstören wird und wie viele Angreifer er dazu bringen wird, diese Branche weiterhin als ein Ziel zu betrachten, das es wert ist, weiter angegriffen zu werden. Selbst wenn letztlich jemand die Verluste trägt, kann eine Entschädigung das Vertrauen der Nutzer nicht automatisch wiederherstellen, noch kann sie verhindern, dass dieselbe Art von Zerstörung erneut geschieht.
Binance ist nur der Einstiegspunkt, der uns heute zwingt, uns dem Problem zu stellen. Blickt man darüber hinaus, haben Börsen, Bridges, On-Chain-Protokolle und Wallets längst eine lange Spur von Wunden hinterlassen. Ständig erscheinen neue Netzwerke und Produkte, doch alte Fehlermuster wiederholen sich immer wieder. Wir können nicht eine Ankündigung herausgeben, eine Weile warten und dann den nächsten Vorfall als Routine behandeln.
Wir müssen auch anerkennen, dass Betrug und die Praxis, lediglich Konzepte zu schaffen, ohne Verantwortung für den Aufbau zu übernehmen, dieser Branche zu lange geschadet haben. Teams, die Technologie und Infrastruktur ernsthaft aufbauen, müssen ebenfalls die Konsequenzen des verlorenen Vertrauens mittragen. Wenn die Menschen erst einmal das gesamte Crypto-Ökosystem als Betrug ansehen, könnten auch die Technologie und die Erkundung, die es wirklich wert sind, bewahrt zu werden, mit ihm aufgegeben werden.
Als Gründer von ArcBlock und Praktiker in Crypto und Blockchain bin ich nicht bereit, ein solches Ergebnis zu akzeptieren. Ich glaube, dass diese Branche einen Wert hat, der es wert ist, geschützt zu werden, und ich glaube auch, dass wir Verantwortung für unser eigenes Sicherheitsfundament übernehmen müssen. Wenn wir weiterhin passiv auf den nächsten Vorfall warten, könnte das wiederholte Ausbluten letztlich alles zerstören, was wir gemeinsam aufgebaut haben.Ich möchte daher diese Initiative anstoßen: Betreiber von Börsen, Wallets und Blockchains sollten gemeinsam die Grundlage der Vermögensverwaltung und Sicherheitsüberprüfung neu aufbauen, damit der Schaden durch einen einzelnen Angriff begrenzt bleibt. Die folgende Zeitleiste erklärt, warum Veränderungen notwendig sind; der anschließende technische Vorschlag beschreibt die Arbeit, mit der wir aus meiner Sicht beginnen können.
Im Jahr 2008 schlug Satoshi Nakamoto ein Peer-to-Peer-Elektronikgeldsystem vor, um Zahlungen weniger abhängig von vertrauenswürdigen Intermediären zu machen. [[2]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-bitcoin) Doch die großen Vorfälle seither haben immer wieder das Problem offengelegt, dass Gelder, Autorisierungen und Softwareabhängigkeiten erneut konzentriert werden.
Nachfolgend eine chronologische Liste repräsentativer Vorfälle in Bereichen wie zentralisierte Börsen (CEX), dezentrale Börsen (DEX), Bridges und Wallets. Sie ist keine vollständige Vorfallsdatenbank und keine jährliche Verluststatistik. Sofern Beträge genannt werden, beziehen sie sich auf die ungefähre Bruttowirkung zum Zeitpunkt des Vorfalls; Diebstahl, Einfrieren und spätere Wiederherstellung werden getrennt beschrieben und können nicht als dauerhafte Verluste zusammengerechnet werden.
2008 · Bitcoin-Whitepaper
Ausgangspunkt
Das Bitcoin-Whitepaper schlug Peer-to-Peer-Zahlungen ohne Finanzinstitute als Intermediäre vor.
Quelle
2011–2014 · Mt. Gox langfristiger Diebstahl
CEX
Mt. Gox erlitt langfristigen Diebstahl und stellte den Betrieb schließlich ein. Eine spätere Anklage des US-Justizministeriums behauptete, dass zwischen 2011 und 2014 etwa 647.000 BTC gestohlen wurden. Dies war kein Angriff an einem einzigen Tag im Jahr 2014.
Quelle
2012 · Bitcoinica und Bitfloor
CEX / Verwahrinfrastruktur
Die Linode-Hosting-Umgebung von Bitcoinica wurde kompromittiert; im selben Jahr wurde das unverschlüsselte Wallet-Backup von Bitfloor zum Angriffspunkt. Die Server und Backups hinter der Plattform sind ebenfalls Teil der Vermögenssicherheitsgrenze.
Quelle
2015 · Bitstamp Hot Wallet
CEX
Die Hot Wallet von Bitstamp wurde kompromittiert, und die Betriebsumgebung wurde anschließend neu aufgebaut. Die offizielle Unterscheidung zwischen dem Umfang des Vorfalls und den Offline-Reserven zeigte, dass Isolation den Umfang der Exposition begrenzen kann.
Quelle
2016 · Bitfinex
CEX
Etwa 120.000 BTC wurden von Bitfinex gestohlen. Multisignatur-Vereinbarungen erfordern weiterhin eine durchgängige unabhängige Autorisierung und Verifizierung.
Quelle 1 · Quelle 2
2016 · The DAO
On-Chain-Protokoll
Der DAO-Vertrag erlitt einen Reentrancy-Angriff, und etwa 3,6 Millionen ETH wurden in eine Sub-DAO übertragen, was anschließend einen Ethereum-Fork auslöste. Ein legitimer Ausführungspfad kann katastrophale geschäftliche Ergebnisse erzeugen.
Quelle 1 · Quelle 2
2017 · Parity Shared Wallet Library
Contract Wallet
Die Parity Shared Wallet Library wurde zerstört, und etwa 513.000 ETH wurden eingefroren. Selbst wenn Gelder nicht übertragen werden, können sie aufgrund gemeinsamer Codeabhängigkeiten unbrauchbar werden.
Quelle
2018 · Coincheck
CEXDie NEM-Hot-Wallet von Coincheck wurde gestohlen. Die Grenze zwischen Offline-Reserven, Hot-Wallet-Berechtigungen und Geschäftsanforderungen wurde erneut zum Problem.
Quelle
2019 · Binance
CEX
Binance gab bekannt, dass 7.000 BTC in einer einzigen Transaktion abgezogen wurden. Großflächige Vermögensabflüsse müssen vor der Signierung eingeschränkt werden.
Quelle
2020 · KuCoin
CEX
Vorfall mit der KuCoin-Hot-Wallet, bei dem anschließend eine große Menge an Vermögenswerten durch mehrparteiische Zusammenarbeit wiedererlangt wurde. Der Bruttobetrag des Diebstahls und der endgültige Verlust sind nicht dieselbe Zahl.
Quelle
2021 · Poly Network
Cross-Chain-Protokoll
Etwa 612 Millionen US-Dollar an Vermögenswerten wurden aus Poly Network transferiert und anschließend in Etappen zurückgegeben. Cross-Chain-Autorisierung und Vermögenskontrolle können nicht allein über normale Geschäftspfade aufrechterhalten werden.
Quelle
2022 · Ronin Bridge
Bridge
Die Validator-Berechtigungen von Ronin wurden kompromittiert, und 173.600 ETH sowie 25,5 Millionen USDC wurden abgezogen. Die Schlüssel mehrerer Validatoren können ebenfalls in dieselbe Angriffskette fallen.
Quelle
2022 · Slope Wallet
Wallet
Der Vorfall mit der Slope Wallet im Solana-Ökosystem. Solana erklärte offiziell, dass Private-Key-Informationen versehentlich an einen Anwendungsüberwachungsdienst übertragen wurden; es handelte sich nicht um eine Kompromittierung des Solana-Konsenses.
Quelle
2023 · Euler
Lending-Protokoll
Etwa 197 Millionen US-Dollar an Vermögenswerten wurden aufgrund einer Protokollschwachstelle aus Euler transferiert und anschließend wiedererlangt. Komplexe Kombinationen in einer einzigen Transaktion können Geschäftslogikfehler verstärken.
Quelle
2023 · Ledger Connect Kit
Wallet-Verbindungstool
Ledger Connect Kit wurde Opfer eines Supply-Chain-Angriffs, und bösartiger Code gelangte in das Anwendungs-Frontend. Die Sicherheit von Hardware-Geräten kann die Verifizierung des Transaktionsinhalts nicht ersetzen.
Quelle
2024 · DMM Bitcoin
CEX
Etwa 308 Millionen US-Dollar wurden von DMM Bitcoin gestohlen. Das FBI und andere Behörden offenbarten anschließend Social-Engineering-Angriffe auf relevantes Personal und die Signierungskette.
Quelle
2024 · Radiant Capital
Lending-Protokoll / Signierung
Etwa 50 Millionen US-Dollar wurden von Radiant Capital gestohlen, und mehrere Entwicklergeräte wurden kompromittiert. Mehrparteiische Signierung kann dennoch kollektiv von kontaminierten Transaktionsinformationen abhängen.
Quelle
2025 · Bybit / Safe
CEX / Wallet-Frontend
Der Bybit-Vorfall mit etwa 1,5 Milliarden US-Dollar betraf die Safe-Entwicklungsumgebung und das Frontend, und Unterzeichner genehmigten eine Transaktion, die die Wallet-Kontrolllogik änderte.
Quelle 1 · Quelle 2
2025 · Cetus DEX
DEXDer Vorfall mit etwa 223 Millionen US-Dollar bei Cetus auf Sui, wobei Forscher auf einen Fehler in einer Mathematikbibliothek hinweisen. Nicht-EVM-Umgebungen müssen ebenfalls ihren Code und den Umfang der Vermögensrisiken prüfen.
Quelle
2026-07 · COLDCARD-Zufallszahlenfehler
Hardware-Wallet / Seed-GenerierungEin Firmware-Fehler schwächte die Seed-Generierung, sodass Angreifer die relevanten privaten Schlüssel rekonstruieren konnten, während das Gerät offline war. Ein Upgrade kann bereits generierte schwache Seeds nicht beheben; eine Migration gemäß der Advisory ist weiterhin erforderlich.
Quelle
2026-10 · Ledger-Hardware-Implantat
Hardware-Wallet-/Distributionsangriff
Ledger bestätigte, dass echte Geräte modifiziert und über Distributionskanäle in Südostasien verbreitet wurden, wobei implantierte Komponenten während der Initialisierung Wiederherstellungsphrasen stahlen. Der Hersteller erklärt, dass seine Chips, sein Betriebssystem und seine Server nicht kompromittiert wurden.
Quelle
2026 · Binance-Multi-Chain-Vorfall
CEX / Multi-Chain
Binance schätzte zunächst, dass etwa 6,3 Milliarden US-Dollar an Vermögenswerten betroffen waren, und Untersuchungen zu weiteren möglichen Eindringpunkten dauern an. Ein einziges Betriebssystem kann Vermögenswerte über mehrere Netzwerke hinweg gleichzeitig exponieren.
Quelle 1 · Quelle 2 · Quelle 3
Hier gibt es CEXs, aber auch dezentrale Börsen, Lending-Protokolle und Bridges; es gibt gestohlene Vermögenswerte und eingefrorene Vermögenswerte. Angriffe erfolgen auf unterschiedlichen Ebenen, und die Behebungsmethoden unterscheiden sich. Ich lehne es ab, all dies auf den einen Satz zu reduzieren: „Nutzer haben ihre privaten Schlüssel nicht geschützt.“ Wie können Nutzer wissen, dass die Entwicklungsumgebung eines bestimmten Tools, eine bestimmte gemeinsam genutzte Bibliothek oder eine unverständliche Autorisierung zum Einstiegspunkt für alle ihre Vermögenswerte wird?
Verteilte Netzwerke haben bereits viel geleistet, doch die Fehlerisolierung für die Kontrolle von Vermögenswerten ist bei Weitem nicht ausreichend. Die On-Chain-Ausführung schließt eine Transaktion getreulich ab, aber sie kann uns nicht beantworten, warum diese Transaktion das Recht hat, so viel zu bewegen.
Ethereums Beitrag ist bedeutend. Es ermöglichte mehr Menschen, On-Chain-Anwendungen zu schreiben, und förderte einen reichen Satz an Tools und Entwicklungserfahrung. Doch heute betrachten viele neue Chains und L2s (Layer-2-Skalierungsnetzwerke) EVM-Kompatibilität als ihr primäres Ziel. Die EVM, die virtuelle Maschine, die Ethereum-Smart-Contracts ausführt, wird zu einer breit replizierten technischen Prämisse. Kompatibilität macht die Migration von Anwendungen zwar bequem; die Dokumentation von Projekten wie Unichain nennt ausdrücklich die Wiederverwendung von Ethereum-Tooling als Wert einer äquivalenten Ausführungsumgebung. [[3]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-evm)
Ich bin der Ansicht, dass die Behandlung von EVM-Kompatibilität als Standardantwort der Branche eine strukturelle Risikokonzentration erzeugt. Es kann viele Netzwerknamen geben, und Validatoren können sich unterscheiden, aber Entwickler können wiederholt dieselben Contracts deployen, dieselben Autorisierungsgewohnheiten verwenden und sich auf dieselben Softwarebibliotheken verlassen. Fehler in gemeinsam genutzten Abhängigkeiten verschwinden nicht allein dadurch, dass das Deployment auf einer anderen Chain erfolgt. Dies ist ein Urteil über den technischen Pfad, nicht die Behauptung, dass jede EVM-Implementierung zwangsläufig dieselbe Schwachstelle aufweist.Hier liegt auch meine Kritik an Ethereum. Die allgemeine Vertragsausführungsfähigkeit ist direkt mit übertragbaren Vermögenswerten verbunden und legt damit eine enorme Verantwortung auf den Anwendungscode und die Wallet-Interaktionen. Verträge können Verträge aufrufen, Autorisierungen können lange bestehen bleiben, und eine scheinbar gewöhnliche Bestätigung kann die anschließende Kontrollart eines Kontos verändern. Die Sicherheit hängt zunehmend davon ab, dass jedes Entwicklungsteam diese Kombinationen korrekt versteht und dass jeder Nutzer korrekt versteht, was er signiert hat.
EIP-7702 macht dieses Problem sehr deutlich. Eine gewöhnliche Überweisung ist „wie viel an wen diesmal“; eine Delegationsautorisierung kann „von nun an soll dieses Stück Code Operationen im Namen meines Kontos ausführen“ bedeuten. Sie verfolgt die Ziele, die Benutzererfahrung zu verbessern und Berechtigungen zu verfeinern, aber das Einrichten einer Delegation gewährt selbst eine breite Ausführungsfähigkeit, und feingranulare Berechtigungen müssen noch immer durch den delegierten Code korrekt implementiert werden. [[4]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-7702) Das Preprint „EIP-7702 Phishing Attack“ von Minfeng Qi et al. untersucht den Weg, ein Konto dauerhaft zu kontrollieren, nachdem die Signierung solcher Autorisierungen herbeigeführt wurde. [[5]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-phishing) Mit zunehmender Bequemlichkeit wächst auch die Sicherheitsverantwortung; Erstere kann nicht einfach an die Nutzer abgegeben werden.
Dieser Binance-Vorfall erstreckt sich über mehrere Chains, und die Untersuchung ist noch nicht abgeschlossen, sodass die gesamte Auswirkung nicht direkt EIP-7702 oder der EVM zugeschrieben werden kann. Reentrancy, die Kompromittierung von Signierdiensten und Front-End-Manipulation sind ebenfalls nicht dieselbe Schwachstelle. Aber solche Unterscheidungen sollten nicht als Ausrede dienen, aufzuhören, die Architektur zu hinterfragen: Warum behält die unterste Ebene nicht mehr Einschränkungen bei, die nicht leicht umgangen werden können, stellvertretend für Fehler in den oberen Ebenen?
MEV missfällt mir ebenfalls. Es bezeichnet den Raum, in dem Teilnehmer durch die Aufnahme, den Ausschluss und die Reihenfolge von Transaktionen zusätzlichen Wert erlangen. Für mich sollte die Nutzung von Reihenfolgemacht, um Nutzertransaktionen zu sandwiching und ihre Ausführungsergebnisse zu verschlechtern, als ein Fehler behandelt werden, der behoben werden muss, und nicht als ein Merkmal verpackt werden, das es wert ist, bewahrt zu werden, nur weil jemand davon profitieren kann. Ethereums eigene Dokumentation erkennt ebenfalls ausdrücklich den Schaden von Transaktions-Sandwiching für Nutzer und das Risiko von MEV für die Netzwerkstabilität an. [[6]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-mev) MEV ist nicht einzigartig für Ethereum und umfasst auch verschiedene Aktivitäten wie Arbitrage und Liquidation; die Branche hat bereits Forschung zur Minderung. Meine Kritik ist, dass der Anreiz, das Netzwerk zu erhalten, nicht zu einem Grund werden darf, die Transaktionsbedingungen der Nutzer zu opfern. Ein besseres Transaktionssystem sollte das minimale Lieferergebnis und die zulässigen Gebühren in die Autorisierung schreiben und den Raum für Orderer begrenzen, unerfüllte Informationen zu nutzen, um Nutzern zu schaden.Ich habe immer das Gefühl gehabt, dass Ethereums Einfluss auf Crypto dem Einfluss von PHP auf das Internet ähnelt: Es hat vielen Menschen ermöglicht, Dinge zu bauen, und gleichzeitig eine technische Schuld hinterlassen, deren Rückzahlung lange dauern wird. PHP musste im Oktober 2026 immer noch eine schwerwiegende Remote-Code-Execution-Schwachstelle beheben. Reife und Popularität können kontinuierliche Härtung nicht ersetzen. [[7]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-php) Das Wertvolle am Internet ist, dass sich Sprachen, Frameworks und Cloud-Dienste getrennt voneinander weiterentwickeln können. Wir sollten auch zulassen, dass sich unterschiedliche Asset-Modelle und Ausführungsmethoden weiterentwickeln, anstatt „Kompatibilität mit derselben virtuellen Maschine“ als Eintrittskarte für die Teilnahme am Ökosystem zu betrachten.
Daher rufe ich die Ökosysteme Bitcoin, Solana und Ripple/XRP Ledger sowie Builder einschließlich ArcBlock dazu auf, sich ernsthaft am Aufbau einer gemeinsamen Sicherheitsgrundlage zu beteiligen. Die Teilnahme an Standards und Interoperabilität erfordert nicht, sich zuerst in Ethereum umzubauen. Vielfalt muss bei Asset-Kontrolle und Verifikationsmethoden umgesetzt werden und für die öffentliche Prüfung offen sein. Die Vorfälle Slope und Cetus haben bereits gezeigt, dass auch Nicht-EVM keine Sicherheitsbefreiung genießt.
Was ich entstehen sehen möchte, ist eine Sicherheitsspezifikation, die von unterschiedlichen Ausführungsumgebungen übernommen werden kann: Dieselben Asset-Limits und Verifikationsanforderungen können von der EVM und anderen Pfaden separat umgesetzt werden, und anschließend können die Garantien und Kosten jedes Ansatzes öffentlich geprüft werden.
1. Risikokontrollen auf der zugrunde liegenden Ebene sollen die Verfügungsmacht über Assets einschränken
Große Wallets sollten in der Lage sein, Empfänger-Whitelists, kumulative Ausgabenobergrenzen und Wartezeiten für neue Empfänger festzulegen. Der entscheidende Punkt ist, dass diese Regeln nicht sofort durch denselben alltäglichen Transaktionsschlüssel aufgehoben werden können. Die Änderung der Regeln erfordert eine unabhängige Autorisierung und muss Zeit für Überwachung und Widerruf lassen.Bestehende Smart Accounts verfügen bereits über eine Implementierungsgrundlage; beispielsweise können Safe Guards über Multisig hinaus Transaktionsbeschränkungen hinzufügen. [[8]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-guards) Wir müssen daraus eine einfacher zu übernehmende Grundfähigkeit machen, die alle Pfade der Asset-Kontrolle abdeckt. Wenn nur direkte Übertragungen eingeschränkt werden, während Umgehungen durch unbegrenzte Genehmigungen, Module oder Upgrades erlaubt sind, wird der Schutz scheitern. Ob der Whitelist-Vertrag aktualisiert werden kann und ob sich die Berechtigungen des Empfängers geändert haben, muss ebenfalls in den Prüfungsumfang einbezogen werden. Apples Activation Lock liefert eine Inspiration aus dem Alltag: Es beschränkt die Reaktivierung gestohlener Geräte und begrenzt die Kalibrierung bestimmter gestohlener Teile, mit dem Ziel, den nach einem Diebstahl ausnutzbaren Wert zu verringern. [[9]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-apple) Wallets sollten ebenfalls in diese Richtung gestaltet werden. Wenn ein Angreifer einen Schlüssel erlangt, bleibt die Bandbreite der Assets, die ausgelöst werden können, begrenzt, und die erwartete Rendite eines Angriffs kann sinken; Risiken wie die Störung von Diensten müssen weiterhin separat behandelt werden.
Das nenne ich die „Verfassung“ der Asset-Sicherheit: Die operative Autorität kann kompromittiert werden, aber die Autorität zur Änderung von Grenzen sollte unabhängig bleiben. Auch Wiederherstellungsprozesse müssen eingeschränkt werden, um zu verhindern, dass eine einzelne Fehlkonfiguration Assets dauerhaft sperrt.
II. Wallets sollen Sicherheitsverantwortung tragen, statt lediglich Mnemonic-Wörter auszuhändigen
Ich habe eine starke Unzufriedenheit mit den heutigen Wallet-Systemen: Wenn ein Produkt von einem gewöhnlichen Menschen verlangt, eine Reihe von Wörtern abzuschreiben, fordert, dass er sie niemals preisgibt, verliert oder sich herauslocken lässt, und dann alle späteren Fehler der Verantwortung des Nutzers zuschreibt, halte ich das für ein unverantwortliches Design. Selbstverwahrung sollte Menschen Kontrolle geben und ihnen auch nutzbare Schutz- und Wiederherstellungsfähigkeiten geben. Sie sollte nicht verlangen, dass jeder Nutzer zuerst ein Sicherheitsexperte wird. Das ist auch eine Schwelle, die Crypto überschreiten muss, um mehr gewöhnliche Nutzer zu erreichen.Jüngste Vorfälle haben dieses Problem unmissverständlich auf den Tisch gebracht. Im Oktober 2026 bestätigte Ledger, dass Angreifer echte Geräte manipuliert und sie anschließend über Vertriebskanäle in Südostasien wieder in den Markt gebracht hatten, wobei implantierte Komponenten während der Initialisierung die Recovery-Wörter stahlen. Ledger definierte dies als einen lokalisierten Vertriebsangriff, nachdem das Gerät die Fabrik verlassen hatte, und nicht als Kompromittierung seines Chips, Betriebssystems oder seiner Server. [[10]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-ledgerimplant) Der Vorfall bei COLDCARD im Juli betraf eine Firmware-Schwächung der Seed-Generierung: Das Gerät musste nicht ferngesteuert werden, damit ein Angreifer die relevanten privaten Schlüssel rekonstruieren konnte. Ein Firmware-Update behebt den Generierungsprozess für die Zukunft, aber bereits erzeugte schwache Seeds müssen weiterhin migriert werden. [[11]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-coldcard)
Diese beiden Vorfälle sind nicht dieselbe Art von Schwachstelle, doch zusammen zeigen sie: Selbst wenn Nutzer die Wörter sorgfältig abschreiben und das Gerät offline halten, können sie die Zufälligkeit und die Integrität der Lieferkette nicht stellvertretend für den Hersteller verifizieren. Dass das Gerät Backup-Wörter anzeigt, dient der Offline-Wiederherstellung, führt aber auch dazu, dass das vollständige Wiederherstellungsgeheimnis einen Anzeige- und Backup-Pfad durchläuft, der geschützt werden muss. Chip-Sicherheit kann die Verifikation des gesamten Geräts und des Auslieferungsprozesses nicht ersetzen.
Das Ziel der Verbesserung sollte der vollständige Wallet-Lebenszyklus sein: wie Schlüssel erzeugt werden, wie Transaktionen erklärt werden, wie Berechtigungen getrennt werden und wie die Wiederherstellung nach dem Verlust eines Geräts funktioniert. Account-Abstraktion, also die Möglichkeit, dass Konten die Autorisierung über programmierbare Regeln verifizieren, und Threshold-Backups wie SLIP-39 haben beide bereits Standards und Implementierungsgrundlagen, sodass man nicht sagen kann, niemand in der Branche arbeite daran. [[12]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-walletstandards) Aber wir müssen diese Fähigkeiten zu getesteten, benutzerfreundlichen Schutzmechanismen machen, statt Nutzer komplexe Schemata selbst zusammenbauen zu lassen.
Einfache Verschleierung von Mnemonic-Wörtern reicht nicht aus. Verlässlichere Richtungen umfassen geprüfte verschlüsselte Backups, Threshold-Wiederherstellung und unabhängige Geräteautorisierung sowie das Absolvieren von Wiederherstellungsübungen durch die Nutzer, bevor sie große Vermögenswerte einlegen. Backup-Shards und Multisig sind unterschiedliche Ebenen: Erstere können sich bei der Wiederherstellung wieder zu demselben Geheimnis zusammensetzen, während Letzteres mehrere unabhängige Unterzeichner erfordert, um eine Transaktion zu genehmigen. Wiederherstellungsdienste dürfen nicht stillschweigend zu einem neuen Master-Schlüssel werden, und ein zusätzliches Passwort darf nicht zu einer weiteren Falle werden, bei deren Verlust eine nicht wiederherstellbare Einbuße droht.Persönliche Wallets und Börsen-Wallet-Systeme können Sicherheitsspezifikationen für Transaktionsbeschreibungen, Signaturanfragen, Asset-Beschränkungen und Wiederherstellungsprozesse gemeinsam nutzen, während sie unterschiedliche Limits und Genehmigungsrichtlinien anwenden. Bitcoins PSBT bietet bereits ein Format für die Weitergabe unsignierter Transaktionen zwischen Tools, und diese gemeinsame Schnittstelle ist es wert, weiter ausgebaut zu werden. [[13]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-psbt) Gemeinsam sind die überprüfbaren Sicherheitsanforderungen; jede Chain muss jedoch noch ihre eigenen Anpassungsregeln klären. Wallets sollten klar darstellen, was diese Signatur überträgt und wie viel nachfolgende Befugnis sie wem gewährt, und unabhängige Richtlinien sollten Operationen außerhalb der Grenzen ablehnen; eine schönere Bestätigungsseite reicht nicht aus.
III. Überprüfbarkeit mit minimaler notwendiger Offenlegung erreichen
Der Nachweis, dass eine Bedingung erfüllt ist, sollte nicht immer erfordern, dass Nutzer alle zugrunde liegenden Daten offenlegen. Selektive Offenlegung, Zero-Knowledge-Beweise und bei Bedarf gewährter Audit-Zugriff sollten zu normalen Optionen in der Infrastruktur werden. Dies hängt auch mit der Asset-Sicherheit zusammen: Öffentliche Identität und Asset-Beziehungen können Hinweise für gezielte Täuschung liefern; Daten, die das Geschäft nicht benötigt, sollten so wenig wie möglich offengelegt werden.
Das verifizierbare Credential-System des W3C verfügt bereits über einen technischen Weg für selektive Offenlegung; jedoch muss noch geklärt werden, wie nachgewiesen wird, dass Eingaben authentisch sind, dass Credentials gültig bleiben und wie der Status widerrufen wird. [[14]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-privacy) Die Einführung von Zero-Knowledge-Beweisen (ZK) verbirgt nicht automatisch Transaktionsbeträge und -beziehungen; Skalierungsbeweise und Datenschutz sind unterschiedliche Ziele.
Wenn ein Geschäft beispielsweise nur die Berechtigung zur Teilnahme überprüfen muss, kann ein Nutzer eine gültige Berechtigungsbescheinigung vorlegen, die von einer vertrauenswürdigen Institution ausgestellt wurde, ohne vollständige Finanzunterlagen offenzulegen. Wenn nachgewiesen werden muss, dass ein verborgener Wert eine Bedingung erfüllt, kann anschließend ein geeigneter Beweismechanismus verwendet werden. Die vertrauenswürdige Quelle des Credentials und sein Widerrufsstatus müssen weiterhin verifiziert werden.
Meine Initiative besteht darin, zuerst zu klären, „wer was überprüfen muss“, und dann die Daten zu entwerfen, die öffentlich gemacht werden müssen. Diejenigen, die die Berechtigung überprüfen, benötigen möglicherweise nur die Berechtigungsbescheinigung; diejenigen, die spezifische Audit-Verantwortlichkeiten tragen, können eingeschränkte Nachweise erhalten. Öffentlich verifizierbare Einschränkungen sollten persönliche Informationen, die dauerhaft für alle offengelegt werden, minimieren.
IV. Transaktionsdienste so weit wie möglich von zentraler Verwahrung befreienHandelsabgleich, Pfadfindung und Asset-Settlement sollten getrennt voneinander gestaltet werden. Ein Dienst, der einen Handelseinstiegspunkt bereitstellt, sollte nur die Berechtigungen erhalten, die erforderlich sind, um das aktuelle Settlement so weit wie möglich abzuschließen, damit die Vermögenswerte der Nutzer die übrige Zeit unter ihrer jeweiligen Kontrolle bleiben. Bestehende intent-basierte Transaktionsprotokolle haben einen Teil des Weges bereits erkundet, und die Branche kann ihn weiter vervollständigen. [[15]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-routing)
Worum Nutzer zustimmen, sollten klare Settlement-Bedingungen sein, einschließlich dessen, was gezahlt wird, was mindestens empfangen wird, wann es abläuft und welche Gebühren zulässig sind. Nachdem ein Handelsdienst kompromittiert wurde, kann der Angreifer den Dienst verweigern, aber diese Bedingungen nicht willkürlich ändern. Unternehmen, die weiterhin zentrale Verwahrung benötigen, sollten ebenfalls Reserve- und Betriebsberechtigungen trennen und die Exposition von Hot Wallets sowie automatische Nachschublimits begrenzen.
IBIT ist das Bitcoin-Exchange-Traded-Product von iShares, und was am Markt gehandelt wird, sind seine Anteile. Seine Ausgestaltung liefert ein Beispiel für teilweise Isolation: Anteile und das zugrunde liegende Bitcoin werden getrennt erfasst, und die relevanten privaten Schlüssel für das Vault Balance (Verwahrungsguthaben) werden in Cold Storage gelegt. Änderungen im Anteilshandelsregister erfordern nicht, dass das zugrunde liegende Bitcoin bei jeder Transaktion mitbewegt wird. [[16]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-ibit) Daraus lässt sich die Trennung von Handelsrechten und Reserveverfügungsrechten lernen. Sein Trading Balance (Handelsdienstguthaben) hat eine andere Ausgestaltung, und die Verwahrung selbst birgt ebenfalls Risiken; Cold Storage muss mit unabhängiger Instruktions- und Signaturverifikation kombiniert werden.
Ich vergleiche den Handelseinstiegspunkt mit einem Router in der Hoffnung, dass er ersetzt werden kann, ohne einen Hauptschalter über die Vermögenswerte aller Nutzer zu tragen. Settlement ist komplexer als Packet Forwarding, und Asset-Lieferung und Autorisierung müssen weiterhin unabhängig verifiziert werden. Einen Dienst non-custodial zu machen und ihm dann unbegrenzte Auszahlungsrechte zu gewähren, bringt nur das zentrale Risiko zurück.
V. Eine geschichtete Architektur verwenden, um Fehler zu isolieren und Ersetzbarkeit zu bewahrenWir brauchen Identitäts- und Autorisierungsschnittstellen, Asset-Richtlinien und Settlement-Verifikationsmethoden, die sich unabhängig voneinander weiterentwickeln können. Verschiedene Chains können ihre eigenen Ausführungsmodelle beibehalten und sich über klare Schnittstellen verbinden. Schnittstellen sollten die Sicherheitsgarantien und ihre Bedingungen angeben, nicht bloß sagen: „Der Aufruf war erfolgreich.“Die Internet-Erfahrung stützt diesen Ansatz. In RFC 9518, „Centralization, Decentralization, and Internet Standards“, diskutiert Mark Nottingham speziell Situationen, in denen Zentralisierung hilfreich sein kann, und analysiert auch die Macht und die Risiken, die sie mit sich bringt. [[17]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-layers) Genau diese Haltung ist es wert, gelernt zu werden: Lassen wir die Architektur beantworten, welche Verantwortlichkeiten zentralisiert werden können, in welchem Maße und wie verhindert wird, dass diese Macht sich ausweitet. Einem Dienst kann erlaubt werden, Anomalien zentral zu identifizieren, während seine Berechtigung, Assets zu berühren, begrenzt ist; Nutzer sollten Dienste wechseln können, ohne ihre eigenen Asset-Richtlinien und Verifikationsaufzeichnungen zu verlieren.
Die wichtigste Abnahmefrage ist: Nachdem ein Geschäftsdienst kompromittiert wurde, welche unabhängige Schicht kann ihn noch ablehnen? Wenn alle Schichten einen gemeinsamen administrativen Schlüssel teilen, ist die sogenannte Schichtung nur Schichtung auf einem Deployment-Diagramm.
Dieses Ziel lässt sich als fünf Verantwortungsschichten betrachten: Der Transaktionsdienst reicht Anfragen ein, die Wallet drückt Nutzerabsicht aus, eine unabhängige Richtlinie begrenzt die Befugnis über die Verfügung über Assets, die Verifikationskomponente prüft Operationen und Nachweise, und die Settlement-Schicht setzt Beschränkungen durch und liefert verifizierbare Aufzeichnungen. Sie können von verschiedenen Teams implementiert werden, und ihre Abhängigkeiten und Fehlerbedingungen müssen ebenfalls getrennt beschrieben werden.
Die in diesem Artikel befürwortete Zielarchitektur. Die Settlement-Schicht muss die Asset-Richtlinie durchsetzen; Eingabeaufforderungen in der Wallet können diese Beschränkung nicht ersetzen. Tägliches Signieren, Regeländerungen und Wiederherstellungsbefugnis müssen isoliert und Bypass-Tests unterzogen werden.
6. Nutzer ihre eigenen Assets leicht verifizieren lassen
Normale Menschen sollten nicht die gesamte Historie der ganzen Chain speichern und ausführen müssen, um ihre eigenen Guthaben und Belege zu verifizieren; sie sollten auch nicht allein einem einzigen Server hinter der Wallet vertrauen müssen. Satoshi Nakamoto hat bereits in Abschnitt 8 des Whitepapers SPV vorgeschlagen, die vereinfachte Zahlungsverifikation. Bitcoins BIP-157 erkundet weiterhin, Clients Filter herunterladen und Blöcke finden zu lassen, die sie selbst betreffen; Ethereum hat ebenfalls Light-Client-Designs. [[18]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-lightclients) Das Problem ist also nicht, dass niemand daran gedacht hat, sondern dass wir immer noch Verifikationsfähigkeit mit klaren Sicherheitsbedingungen in die Wallets integrieren müssen, die Nutzer täglich verwenden.Nehmen wir als Beispiel eine Chain, die Account-State-Proofs unterstützt: Bei der Abfrage eines Guthabens sollte der Server sowohl das Guthaben als auch einen Proof zurückgeben. Die Wallet verifiziert zunächst einen kurzen Block-Digest, also den Block-Header, gemäß den Regeln dieser Chain und prüft dann, ob dieses Guthaben mit den durch den Digest committeten Daten übereinstimmt. Der Server liefert die Antwort, und die Wallet kann die Antwort verifizieren. Bitcoins SPV verifiziert den Nachweis, dass relevante Transaktionen enthalten waren; es kann nicht direkt als Guthabensnachweis kopiert werden. Die Wallet sollte außerdem klar anzeigen, bis wohin sie synchronisiert ist und welche Informationen verifiziert wurden; wenn Proofs fehlen, Daten veraltet sind oder Quellen einander widersprechen, sollte sie warnen oder risikoreiche Operationen, die auf diesen Informationen beruhen, stoppen und darf nicht stillschweigend auf blindes Vertrauen zurückfallen.
Leichtgewichtige Verifikation hat weiterhin Bedingungen. Zu beweisen, dass eine Transaktion in einen Block aufgenommen wurde, ist nicht dasselbe wie selbst zu prüfen, dass alle Transaktionen im Block gültig sind. Verschiedene Verfahren können darauf beruhen, dass eine Mehrheit der Hash-Power ehrlich ist, oder auf einem vertrauenswürdigen anfänglichen Datensatz, also einem Checkpoint; sie müssen sich auch davor schützen, dass Server Daten zurückhalten oder Nutzer auf einem veralteten Chain-Datensatz isolieren. Ob die Abfrage selbst die Adressen offenlegt, die einen Nutzer interessieren, muss ebenfalls behandelt werden. Full Nodes und Block-Produzenten sind nicht dieselbe Rolle; Ethereum verwendet heute Validatoren statt Miner für die Block-Produktion.
Wichtiger noch: Zu beweisen, dass „diese Überweisung wirklich on-chain stattgefunden hat“, kann nicht beweisen, dass „dies genau die Überweisung ist, die der Nutzer wollte“. Light Clients können die früheren Asset-Limits und Signaturprüfungen nicht ersetzen. Sie lassen Nutzer weniger auf eine nicht verifizierbare Antwort vertrauen, während die Asset-Policy sicherstellt, dass selbst eine gültige Signatur Assets nicht unbegrenzt verfügen kann. Nur wenn beide Ebenen gemeinsam aufgebaut werden, kann die Verifikationsfähigkeit unter den Teilnehmern verteilt werden.
7. Anomalieerkennung und Sicherheitsverifikation als öffentliche Infrastruktur aufbauen
Vor einer Transaktion sollte jemand prüfen, ob die Operation der Asset-Policy entspricht und ob sie das historische Verhalten plötzlich ändert. Offensichtliche Anomalien können eine Pause oder eine eskalierte Prüfung auslösen; die Ausweitung von Berechtigungen erfordert einen weiteren unabhängigen Pfad. KI kann an der Beurteilung mitwirken, sollte aber keinen Freischein erhalten, der harte Regeln außer Kraft setzt.
Gleichzeitig müssen wir gemeinsam AngriffsFälle, Berechtigungstests und wiederholt ausführbare Verifikationswerkzeuge pflegen. Nur durch gemeinsame Spezifikationen und die Bewahrung unabhängiger Implementierungen und unabhängiger Verifikation lassen sich Common-Mode-Fehler reduzieren. Stiftungen und Börsen haben bereits Sicherheitsinvestitionen, etwa die Trillion Dollar Security Initiative der Ethereum Foundation. [[19]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-initiative) Die nächste Frage ist, ob die Investition in öffentliche Infrastruktur umgewandelt werden kann, die auch andere Teams übernehmen und prüfen können.Keines dieser sieben Arbeitspakete kann absolute Sicherheit garantieren. Was sie liefern müssen, sind überprüfbare Grenzen: unter welchen Bedingungen einer Rechtekompromittierung wie viele Vermögenswerte maximal exponiert sind, wie schnell Anomalien entdeckt werden können und von wem die Wiederherstellung noch abhängt.
An diesem Punkt mag mancher sagen: Die Richtung klingt richtig, aber die Branche läuft schon seit so vielen Jahren; wie viele Menschen und wie viel Zeit würde ein Wiederaufbau erfordern? Ist das nicht immer noch Idealismus?
Schätzt man nach der bisherigen Art der Softwareproduktion, ist dieser Zweifel sehr realistisch. Doch bis 2026 haben Coding-Agenten und KI-gestützte Softwareentwicklung, so glaube ich, die uns verfügbare Baukapazität bereits verändert. Die hier genannten Coding-Agenten sind KI-Programmierassistenten, die Code lesen und schreiben, Werkzeuge aufrufen, Tests ausführen und auf Basis von Feedback in einer Entwicklungsumgebung weiterarbeiten können. Erbauer setzen Ziele, definieren Sicherheitsgrenzen, nutzen diese Werkzeuge zur Implementierung und Prüfung von Systemen und übernehmen Verantwortung für die Ergebnisse.
Arbeit, die früher große Teams für wiederholte Implementierung, Anpassung und Wartung erforderte, kann nun von kleinen Teams mit diesem neuen Engineering-Ansatz versucht werden. Ein Team verantwortet eine Schicht, liefert Komponenten rund um klare Schnittstellen und andere Teams prüfen und kombinieren sie. Menschliches Architektururteil, die Umsetzungskapazität von Coding-Agenten und unabhängige Sicherheitsverifikation zu organisieren, ist meiner Ansicht nach der Bauweg, der eine ernsthafte Neubewertung verdient.
Forschung von Anthropic und PNNL liefert ein konkretes Beispiel: In einer begrenzten Simulationsumgebung für kritische Infrastruktur berichteten Forscher, dass die Angriffsrekonstruktion von möglicherweise mehreren Wochen auf etwa drei Stunden verkürzt wurde. [[20]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-ai) Das kann nicht beweisen, dass ein kleines Team bereits die gesamte Branche sicher neu schreiben kann, aber es zeigt, dass zuvor teure Verifikations- und Angriff-Abwehr-Arbeit neue Kostenbedingungen haben kann.
Ein organisatorischer Ansatz, der jetzt begonnen werden kann, ist der gemeinsame Aufbau einer Build in Public AI Factory. Branchenexperten, Wissenschaftler und Praktiker schreiben offen Anforderungen und Abnahmespezifikationen (Spec), erklären, was geschützt werden soll, welche Operationen erlaubt sind und welche Grenzen nach welcher Rechtekompromittierung noch halten müssen, und verwandeln diese Anforderungen dann in Abnahmetests. Gruppen von Coding-Agenten übernehmen die Hauptarbeit an Codierung, Tests und Debugging; verschiedene Teams prüfen Designs und Ergebnisse, und Menschen tragen Urteils- und Abnahmeverantwortung.Teilnehmer können Ideen, Maschinen, Rechenleistung und Modellaufrufkontingente, also KI-Token, beisteuern. KI- und Cloud-Computing-Unternehmen können diesen öffentlichen Aufbau auch durch Modellkontingente, Rechenressourcen und Werkzeuge unterstützen. Spezifikationen, Prototypcode, Agent-Workflows, Testumgebungen und Verifikationsergebnisse können alle zu gemeinsam gepflegter Infrastruktur werden, sodass das nächste Team direkt darauf aufbauen kann. Das Ziel ist, Entwicklungskapazität in wiederverwendbare öffentliche Einrichtungen zu verwandeln und die Abhängigkeit von der Zeit einer einzelnen Person oder eines einzelnen Teams zu verringern.
Auch Angreifer nutzen KI, und wir haben keinen Grund mehr, Verteidigung in den Produktionsmethoden der Vergangenheit zu belassen. [[21]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-aiattacks) Aber dass Codegenerierung schnell ist, ist nur der Ausgangspunkt. Nur wenn Einschränkungen klar geschrieben, Tests wiederholt ausführbar und eine Komponente inspizierbar und austauschbar gemacht werden, kann KI-Fähigkeit in Infrastrukturverbesserung verwandelt werden.
Unabhängige Entwickler arbeiten mit Hilfe von Coding-Agenten und KI-Werkzeugen zusammen. Die Weltraumwerkstatt ist eine Metapher für öffentlichen Aufbau. Ich möchte diesen Aufruf besonders an diejenigen richten, die noch immer gern bauen. Der „Hacker" hier bezeichnet jemanden, der bereit ist, herauszufinden, wie ein System funktioniert, bereit ist, seine Entdeckungen zu teilen, und bereit ist, andere seine Arbeit testen zu lassen. Dieser Geist hat einst das Internet vorangebracht, und heute kann er auch Crypto voranbringen.
Ich glaube nicht, dass dieser Branche kluge Menschen fehlen, und ich glaube nicht, dass die Crypto- und KI-Branchen keine Ressourcen finden können, um diese Arbeit zu unterstützen. Schwieriger ist es, Talent, Finanzierung und dauerhafte Verantwortung zusammenzubringen. Stiftungen und leistungsfähige Unternehmen sollten bereit sein, die langfristigen Kosten für Grundlagenarbeit zu tragen, die nicht direkt Einnahmen erzeugt, aber allen zugutekommt.
Ich hoffe, dass alle zusammenarbeiten, um eine global gemeinsame kryptografische Infrastruktur aufzubauen. Verschiedene Netzwerke und Teams können unter gemeinsamen Sicherheitsbeschränkungen zusammenarbeiten, jeweils ihre eigenen Lösungen implementieren und die der anderen testen, und Nutzer können wählen und migrieren. Es kann mit einer einzelnen Komponente beginnen, aber die Richtung sollte groß genug sein, um die gesamte Branche gemeinsam bauen zu lassen. Alle Teilnehmer, einschließlich ArcBlock, sollten überprüfbare Arbeit beisteuern.
Wir sollten gemeinsam eine Art Infrastruktur aufbauen, bei der selbst dann, wenn ein Teil kompromittiert wurde, Vermögenswerte noch Grenzen haben, andere Systeme Fehler noch zurückweisen können und Nutzer noch Wege zur Wiederherstellung und zum Ausstieg haben. In Anlehnung an den Namen aus Star Wars ist dies unsere A New Hope. [[22]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-starwars) Die Hoffnung kommt von gewöhnlichen Entwicklern, die bereit sind zu handeln, und auch von diesem Moment, in dem Coding-Agenten und neue Engineering-Methoden es ihnen ermöglichen, mehr Bauarbeit zu übernehmen.Ich möchte eine Einladung an die Entwickler von Projekten wie Ethereum, Solana, Bitcoin und XRP Ledger, an Börsen wie Binance, Coinbase und Kraken sowie an Wallet-, Protokoll-, Sicherheitsforschungs-, KI- und Cloud-Computing-Teams aussprechen: Beginnt mit einem klar abgegrenzten Pilotprojekt und erarbeitet gemeinsam Verbesserungen, die andere Teams übernehmen und testen können.
Die genannten Namen sind nur Beispiele, in keiner bestimmten Reihenfolge. Unabhängig von der Größe oder dem gewählten technischen Weg seid ihr willkommen, teilzunehmen. Diese Einladung schließt auch die Entwickler der in diesem Artikel kritisierten technischen Wege ein; die gemeinsame Verbesserung der Asset-Sicherheit ist es wert, die Grenzen unserer jeweiligen Ökosysteme zu überschreiten.
Ich selbst bin bereit, teilzunehmen und unsere bestehenden Infrastruktur-, Software-Engineering- und KI-Kollaborationspraktiken beizusteuern. Wir sind nur ein kleines Team in der Branche, und was wir tun können, ist begrenzt. Ich hoffe, mit einem Prototyp und einer Reihe reproduzierbarer Tests zu beginnen.
Personen mit praktischer Betriebserfahrung können desensibilisierte Angriffsszenarien bereitstellen, Wallet- und Protokollteams können Schutzmaßnahmen implementieren, und unabhängige Forscher können versuchen, diese zu umgehen. Jedes Team übernimmt den Teil, den es bewältigen kann, testet gemeinsam die Lösung und entscheidet über den nächsten Schritt.
Ich bin bereit, an der Organisation der in diesem Artikel beschriebenen Anforderungen an Asset-Begrenzung und -Wiederherstellung in die erste öffentliche Spezifikation mitzuwirken, und ich bin auch bereit, relevante technische und Engineering-Praktiken beizusteuern, um gemeinsam mit anderen Teilnehmern eine öffentliche AI Factory für dieses Pilotprojekt aufzubauen. Wählt zuerst ein sehr konkretes Problem: Wie kann, sobald der Schlüssel für alltägliche Transaktionen kompromittiert wurde, dennoch verhindert werden, dass der Angreifer die Wallet auf einmal leerräumt? Schreibt den erlaubten Verlustbereich, die Befugnis zur Änderung von Regeln und die Wiederherstellungsbedingungen in Akzeptanztests, lasst dann Entwicklungsagenten einen Prototyp implementieren und eine andere Gruppe von Agenten und unabhängigen Forschern nach Umgehungswegen suchen. Datenserver, die falsche Salden zurückgeben, und die Wiederherstellung nach Geräteverlust können ebenfalls schrittweise in die Tests aufgenommen werden. Was der Prototyp erreicht, wo er scheitert und welche Abhängigkeiten verbleiben, sollte alles öffentlich erklärt werden, und der nächste Schritt sollte auf der Grundlage von Belegen entschieden werden.
Diejenigen, die teilnehmen möchten, sind eingeladen, diese Initiative öffentlich auf X zu reposten oder zu zitieren und @mave99a zu markieren sowie über das Problem zu sprechen, das ihr lösen wollt, desensibilisierte Angriffsfälle oder die Ressourcen, die ihr beitragen könnt. Ich hoffe, die Diskussion verläuft öffentlich, damit mehr Entwickler sie sehen und sich anschließen können.
Krypto kann so nicht weitermachen. Diejenigen, die bereit sind, zusammenzuarbeiten, lasst uns jetzt handeln, beginnend mit einer Verbesserung, die gebaut werden kann und Tests standhält.Binance, ursprüngliche Ankündigung offizieller Beitrag und Folgeuntersuchung offizielles Update, 2026-10-30; TRM Multi-Chain-Analyse. Dieser Entwurf wurde mit Stand vom 2026-10-30 verifiziert; Untersuchungs- und Wiederherstellungsstatus können sich ändern. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-binance)
Satoshi Nakamoto, Bitcoin: A Peer-to-Peer Electronic Cash System, 2008. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-bitcoin)
Uniswap, Unichain EVM Equivalence. Die Risikokonzentration gemeinsamer Abhängigkeiten ist die Einschätzung des Autors in diesem Artikel, nicht eine Schlussfolgerung jenes Dokuments. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-evm)
Vitalik Buterin, Sam Wilson, Ansgar Dietrichs, lightclient, EIP-7702: Set Code for EOAs, erstellt 2024-05-07. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-7702)
Minfeng Qi, Qin Wang, Ruiqiang Li, Tianqing Zhu, Shiping Chen, EIP-7702 Phishing Attack, 2025-12-13, arXiv v1 Preprint; keine Identifizierung dieses Binance-Vorfalls. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-phishing)
Ethereum, Maximal extractable value (MEV), Ordering-Mechanismen, verschiedene Typen und negative Auswirkungen; „sollte als Bug behoben werden" ist die ingenieurtechnische Position des Autors zu Verhalten, das Nutzern schadet. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-mev)
PHP offizielles News-Archiv 2026; CISA 2026-10-26 Known Exploited Vulnerabilities Update, CVE-2026-109618, CVE-2026-109619. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-php)
Safe, Guards and Modules, Beschreibung von Funktionalität und Berechtigungsrisiken. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-guards)
Apple, Apple to expand repair options with support for used genuine parts, 2024-04-11; aktuelle Beschreibung der Parts-Pairing-Unterstützung. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-apple)Ledger, Ledger's Response to the Hardware Implant Attack, 2026-10, Herstellererklärung zu einem Angriff in der Distributionskette; Joe Grand, Reverse-Engineering-Forschung zu Hardware-Implantaten. Unverifizierte Schätzungen zu Netzwerkverlusten nicht als endgültige Schlussfolgerungen darstellen. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-ledgerimplant)
Coinkite, Current COLDCARD Security Status, abgerufen am 2026-10-30, kontinuierlich aktualisierte Aufzeichnung des Vorfalls vom Juli 2026 und der Behebung; Upgrade und Seed-Migration sind zwei verschiedene Vorgänge. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-coldcard)
ERC-4337: Account Abstraction Using Alt Mempool; Trezor, SLIP39 FAQs, Threshold-Recovery, Kompatibilität und zusätzliche Passphrase-Risiken. Bestehende Mechanismen sind eine Grundlage zum Aufbauen und bedeuten nicht, dass jede Bereitstellung zuverlässig ist. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-walletstandards)BIP-174: Partially Signed Bitcoin Transaction Format, ein Austauschformat für unsignierte Transaktionen, keine kettenübergreifende allgemeine Asset-Strategiespezifikation. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-psbt)
W3C, Verifiable Credentials Overview v1.0, 2026-07-30 Group Note; Ethereum privacy notes. Der Standardisierungsstatus der in der Übersicht beschriebenen Technologien ist jeweils eigenständig. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-privacy)
CoW Protocol documentation, transaction intents and solver mechanisms; dieser Artikel bietet keine umfassende Sicherheitsbefürwortung für eine bestimmte Bereitstellung. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-routing)
iShares, IBIT 2025 Annual Report, PDF-Seiten 8–10 Verwahrungsvereinbarungen und Seite 45 Risikohinweise. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-ibit)
Mark Nottingham, RFC 9518: Centralization, Decentralization, and Internet Standards, 2023-12, unabhängig eingereicht, informativ RFC, keine Spezifikation auf dem Standards-Track. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-layers)
Bitcoin whitepaper Section 8 Simplified Payment Verification; BIP-157: Client Side Block Filtering; Ethereum, Light clients. Verschiedene Light Clients haben unterschiedliche Verifikationsumfänge und Vertrauensbedingungen. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-lightclients)
Ethereum Foundation, Announcing the Trillion Dollar Security Initiative, 2025-05-14. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-initiative)
Anthropic, AI to defend critical infrastructure, 2026-01-08, Forschung in eingeschränkter Umgebung in Zusammenarbeit mit PNNL. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-ai)
Anthropic, Mapping AI-enabled cyber threats, Forschung zu tatsächlichen Missbrauchsproben. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-aiattacks)
Lucasfilm, Star Wars: A New Hope (Episode IV), 1977; dieser Artikel entlehnt den Titel und die Bildsprache der gemeinsamen Selbstrettung. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-starwars)