Google möchte der Tresor für Bank-Kryptowährungen werden.

Google entwickelt ein Produkt zur Krypto-Verwahrung für Banken und hat es am Mittwoch der Öffentlichkeit vorgestellt. Auf seinem ersten Symposium für digitale Vermögenswerte in New York präsentierte Google Cloud Google Multi-Party Compute (MPC), einen Dienst zum Speichern und Übertragen von Krypto- und tokenisierten Vermögenswerten, ohne dass eine einzelne Maschine über einen vollständigen privaten Schlüssel verfügt, wie CoinDesk berichtete. Der Dienst befindet sich derzeit in der privaten Testphase. Die Markteinführung ist für Anfang 2027 geplant, ein Preis steht noch nicht fest.

Die Nachricht verbreitete sich noch am selben Tag auf X, wo Scott Melker sie als „EILMELDUNG“ veröffentlichte.

Wer testet es? Google schweigt dazu. Mehrere Designpartner und große Finanzinstitute nehmen an der Vorabversion teil, ohne dass Namen genannt werden. Der einzige bestätigte Nutzer ist Alphabet, das damit begonnen hat, seine eigenen digitalen Vermögenswerte auf Ethereum und Solana mithilfe des Systems zu sichern. Welche Vermögenswerte und in welchem Umfang, bleibt geheim. Rich Widmann, Director of Digital Assets Strategy bei Google Cloud, erklärte gegenüber CoinDesk, dass Banken, die auf Blockchains umsteigen, „eine skalierbare und bewährte Infrastruktur benötigen, um die Vermögenswerte ihrer Kunden zu sichern“.

Ein Produkt, kein Bastelset

MPC an sich ist nicht neu. Man teilt einen privaten Schlüssel in Fragmente auf, verteilt diese auf separate Systeme, und so verhindert man, dass bei einem einzelnen Fehler das Geld verloren geht. Google veröffentlichte 2023 sogar eine Anleitung, die Kunden zeigte, wie sie dies auf der Confidential Space-Infrastruktur umsetzen können. Neu ist, dass Google die Lösung nun fertig anbietet. Das Unternehmen teilte CoinDesk mit, dass es bisher kein dediziertes MPC-Verwahrungsprodukt für Kryptowährungen angeboten hat. Bis jetzt erhielten Banken auf Google Cloud den Key Management Service und Cloud HSM und mussten anschließend Signatur, Richtlinien und Wiederherstellung selbst implementieren.

Beispiel von CoinDesk: Eine Bank verwahrt einen Schlüsselanteil in der Google Cloud, einen auf eigener Hardware und einen bei einem konkurrierenden Cloud-Anbieter. Für Geldtransfers wird die Transaktion in den Confidential Space, eine hardwareisolierte Umgebung, geleitet. Dort prüft eine Richtlinien-Engine die Transaktion anhand der bankinternen Regeln, bevor sie signiert wird. Diese Regeln können Beträge begrenzen, Ziel-Wallets einschränken oder die Genehmigung mehrerer Abteilungen erfordern. Die Schwellenwerte sind anpassbar (2 von 3 oder 5 von 7). Google gibt an, die Schlüsseldaten selbst für Anteile auf eigener Infrastruktur nicht unverschlüsselt lesen zu können.

Der Dienst ist nach allgemeiner Verfügbarkeit so konzipiert, dass er ECDSA- und Ed25519-Signaturen unterstützt. ECDSA ist das Standardverfahren der meisten Bitcoin- und Ethereum-Wallets, Ed25519 ist das von Solana.

Es gibt auch eine Dokumentation. Cointelegraph berichtete, dass Google die Servicedokumentation am Montag aktualisiert hat, und die Versionshinweise zeigen Änderungen seit August. Am 1. Oktober wurden Bitcoin-Regeln für Transaktionsbeträge, Zieladressentypen und Wechselgeldausgaben hinzugefügt. Das Produkt ist weiterhin als Vorschau gekennzeichnet, was bedeutet, dass es im aktuellen Zustand und möglicherweise mit eingeschränktem Support angeboten wird.

Eine Frage bleibt offen. Solana Compass merkte an, dass Solana in der öffentlichen Dokumentation weiterhin als „demnächst verfügbar“ geführt wird, während Google gegenüber CoinDesk erklärte, Alphabet betreibe das System bereits auf Solana. Google hat diese Diskrepanz nicht erklärt.

Warum Banken sich für Schlüssel interessieren

Denn bei den Schlüsseln liegt das Problem mit dem gestohlenen Geld. Laut Daten von Chainalysis, die von CoinDesk zitiert werden, sind kompromittierte private Schlüssel für 43,8% der im Jahr 2024 gestohlenen Kryptowährungen verantwortlich. Zahlen von DeFiLlama zeigen, dass bis Juni insgesamt 16,69 Milliarden US-Dollar durch Hacks und Exploits verloren gingen, wovon etwa 40% auf Schlüsselkompromittierung zurückzuführen sind.

Der Hack des Humanity Protocol im Juni gilt als Paradebeispiel. Am 9. Juni gab Gründer Terence Kwok bekannt, dass die privaten Schlüssel eines Mitglieds der Humanity Foundation kompromittiert worden seien, und riet Nutzern dringend, sich von der Bridge und den Liquiditätspools fernzuhalten. Der Onchain-Analyst Specter hatte den Abfluss bereits verfolgt und in diesem Beitrag Verluste von über 20 Millionen US-Dollar gemeldet. CoinDesk bezifferte die Gesamtsumme später auf über 32 Millionen US-Dollar, verteilt auf mindestens 17 Wallets, und der H-Token fiel um mehr als 80%. Die Zahlen stimmten nie ganz überein: PeckShield verzeichnete monatliche Verluste von 31 Millionen US-Dollar, während die eigene Schätzung des Teams laut The Block auf rund 36 Millionen US-Dollar stieg.

Nicht alle glaubten der Erklärung. ZachXBT sagte, er glaube der Version des Teams nicht und brachte die Vermutung ins Spiel, dass ein Market Maker Gewinne realisieren wollte. Das ist seine Vermutung, keine gesicherte Erkenntnis.

So oder so, genau dieses Versagen soll laut Google mit MPC verhindert werden: Ein gestohlener Zugangscode sollte nicht ausreichen, um Gelder zu transferieren. CoinDesk analysiert, dass eine Richtlinienprüfung vor der Signierung Überweisungen verhindern könnte, die vordefinierte Limits oder Genehmigungsregeln überschreiten. Ob das in einem Fall wie dem von Humanity etwas geändert hätte, lässt sich von außen nicht beurteilen.

Was es nicht abdeckt

Google positioniert das Produkt auch als Schutz gegen KI-gestützte Angriffe und Quantencomputer. Lesen Sie diesen Abschnitt aufmerksam. CoinDesk weist darauf hin, dass die aktuellen Schutzmaßnahmen gestohlene Zugangsdaten und unautorisierte Transaktionen abfangen, nicht aber einen Einbruch in der zugrundeliegenden Kryptografie.

Diese Unterscheidung ist diesen Monat von Bedeutung. Am 7. Oktober rief Justin Drake, Forscher der Ethereum Foundation, die Branche dazu auf, sich auf den „Bunkermodus“ vorzubereiten. Er bezeichnete damit das Umschichten von Guthaben auf Adressen, deren öffentlicher Schlüssel nie offengelegt wurde. Hintergrund war die Sorge, dass KI die Signaturen, die Bitcoin- und Ethereum-Wallets schützen, im schlimmsten Fall innerhalb von Monaten statt Jahren knacken könnte. Laut CoinDesk erreichte der Beitrag fast 4 Millionen Aufrufe. Vitalik Buterin riet, das Risiko ernst zu nehmen, aber nicht übereilt Guthaben umzuschichten, und Samson Mow empfahl seinen Followern, Ruhe zu bewahren. Bisher hat kein KI-System bewiesen, dass es diese Signaturen knacken kann.

Google gibt an, dass seine Architektur spätere Upgrades nach der Quantentechnologie ermöglicht, ohne dass Banken ihre Systeme neu aufbauen müssen. Ein Zeitplan wurde nicht genannt.

Ein überfüllter Markt

Google betritt einen Markt, auf dem bereits Fireblocks, Fordefi und BitGo etabliert sind. Laut CoinDesk setzt Google auf Bankbeziehungen, Sicherheitsexpertise und Neutralität für Banken, die keine Infrastruktur von einem Konkurrenten mieten möchten, der um dieselben Kunden wirbt.

Die Nachfrage ist nicht die Frage. Laut crypto.news prüfte UniCredit im September die Infrastruktur für die Verwahrung und das Brokerage digitaler Vermögenswerte, und Finance Magnates berichtete, dass JPMorgan plant, Bitcoin und Ether als Kreditsicherheiten für institutionelle Kunden zu akzeptieren und dafür einen externen Verwahrer einzusetzen.

Die Einschränkungen sind jedoch berechtigt. Selbst bei breiter gestreuten Anteilen könnten Banken weiterhin auf Google angewiesen sein, beispielsweise bei Teilen der Software, den Transaktionsrichtlinien und dem operativen Geschäft. Die Sicherheit hängt davon ab, wie eine Bank Genehmigungen konfiguriert und wer die Regeln bearbeiten darf. Ein rechtmäßiger Unterzeichner, der durch Täuschung zu einer ungültigen Überweisung verleitet wird, bleibt ein Problem. Zudem hat Google keinen unabhängig verifizierten Leistungsvergleich mit bestehenden Verwahrungsprodukten vorgelegt.

Die Kryptografie ist meiner Meinung nach der unbedenkliche Aspekt. Schwieriger ist die Frage, ob der Risikoausschuss einer Bank eine weitere kritische Abhängigkeit von Google eingehen möchte. Als Nächstes würde ich beobachten, ob eine der Testbanken ihre Daten offenlegt und welche Gebühren Google erhebt.