NachrichtenKryptoHelius startet verschlüsselte Solana-Zahlungen im Mainnet – Betreibervertrauen bleibt weiterhin erforderlich

Helius startet verschlüsselte Solana-Zahlungen im Mainnet – Betreibervertrauen bleibt weiterhin erforderlich

Autor: CryptoNewsNet·

Wichtige Erkenntnisse

  • •Helius' erlaubnisfreier Privacy Ring ist am 10. November im Solana-Mainnet live gegangen und bringt Verschlüsselung für Zahlungs-Assets und Beträge, obwohl die Wallet-Adressen auf beiden Seiten öffentlich einsehbar bleiben.
  • •Der Standard-Prover der SDKs verarbeitet geheime Transaktionseingaben, darunter Nullifier-Schlüssel und Blinding-Werte, innerhalb einer attestierten AWS-Nitro-Enclave, die Clients kryptographisch verifizieren, bevor sie eine Anfrage senden.
  • •Helius bietet lokale Entschlüsselung, bei der der Viewing-Key auf dem Gerät bleibt, und delegierte Entschlüsselung, die einem autorisierten Anbieter Lesezugriff auf Guthaben und Historie ohne Ausgabenbefugnis gewährt.
  • •Das Enclave-Modell erfordert weiterhin Vertrauen in den Betreiber, AWS KMS und Nitro-Hardware sowie das freigegebene Software-Image, während Anfrage-Metadaten wie Pfade, Timing und Größen für die übergeordnete Instanz sichtbar bleiben.
  • •Certora und zkSecurity haben die Programme und Schaltungen auditiert, der Bericht von OtterSec steht jedoch aus, und der v0.6.0-alpha-Mainnet-Build unterscheidet sich vom Dokumentations-Tag ts-sdk-v0.8.0-alpha.
Helius startet verschlüsselte Solana-Zahlungen im Mainnet – Betreibervertrauen bleibt weiterhin erforderlich

Helius startet verschlüsselte Solana-Zahlungen im Mainnet – Betreibervertrauen bleibt weiterhin erforderlich

Helius hat am 10. November seinen erlaubnisfreien Privacy Ring im Solana-Mainnet aktiviert und verschlüsselt dabei Zahlungs-Assets und Beträge, während die Wallet-Adressen von Absender und Empfänger sichtbar bleiben. Der dokumentierte Standard-Prover des Systems – der Dienst, der Zero-Knowledge-Beweise erstellt – fügt eine Hardwareanforderung hinzu: Geheime Transaktionseingaben werden innerhalb einer attestierten AWS-Nitro-Enclave verarbeitet, einer isolierten Rechenumgebung.

Da Solanas Ledger öffentlich ist und seine aufgezeichneten Transfers von jedermann eingesehen werden können, adressiert die Verschlüsselung von Assets und Beträgen die unmittelbar sensibelsten Felder einer Zahlung, selbst wenn die Adressen auf beiden Seiten sichtbar bleiben.

Solana kann überprüfen, ob ein Transfer die Regeln des Protokolls erfüllt, doch der Schutz der Eingaben während der Beweiserstellung hängt von der Isolation des Provers, seinem Code und seinen Deployment-Richtlinien ab.

Was den Proving-Dienst erreicht

Für Wallet-Entwickler, die den Launch integrieren, ist die praktische Frage, welche dieser Schutzmaßnahmen ihre Software tatsächlich verifizieren kann. Ihre Entscheidungen – lokale oder delegierte Entschlüsselung, Remote- oder Client-seitige Beweiserstellung – bestimmen, welche Teile einer Transaktion ihre Nutzer anderen vertrauen müssen.

Helius' Wallet-Integrationsguide stellt fest, dass die Beweiserstellung Klartext-Eingaben erfordert, die die vollständigen Transaktionsdaten und Nullifier-Schlüssel umfassen, und eine attestierte AWS-Nitro-Enclave als Standard-Prover der SDKs ausweist.

Die Protokollspezifikation listet private Eingaben auf, darunter das Asset, den Betrag, Blinding-Werte und das Nullifier-Secret für die ausgegebenen Notes, sowie Pfade, die belegen, dass diese Notes zum State Tree gehören. Der Beweis enthält auch Ausgabe-Assets, Beträge und Blinding-Werte.

Diese Eingaben werden für den Proving-Code innerhalb der Enclave lesbar. Der dokumentierte Client schützt sie vor dem Host-Betreiber, indem Anfragen an einen Schlüssel verschlüsselt werden, der von der attestierten Enclave gehalten wird. Das Nullifier-Secret leitet auch die Marker ab, die used werden, um wiederholtes Ausgeben zu verhindern.

In der nativen Wallet-Integration behält die Wallet den Signaturschlüssel, und das TypeScript SDK überlässt die Signatur der fertigen Solana-Transaktion dem Signer der Anwendung. Helius dokumentiert zwei Entschlüsselungsmodi: lokale Entschlüsselung, bei der der Viewing-Key auf dem Gerät bleibt, und delegierte Entschlüsselung, bei der ein Viewing-Key mit einem autorisierten Anbieter geteilt wird. Die Delegation gewährt diesem Anbieter Lesezugriff auf Guthaben und Historie, ohne Ausgabenbefugnis zu übertragen.

Wie das Enclave-Modell funktioniert

AWS beschreibt Nitro Enclaves als isolierte Umgebungen, deren Speicher weder von Prozessen noch Administratoren der übergeordneten Instanz zugänglich ist. Enclaves verfügen über keinen persistenten Speicher, keinen interaktiven Zugriff und kein externes Netzwerk. AWS' signiertes Attestierungsdokument enthält kryptographische Fingerabdrücke des Images und der Software der Enclave.

Da die Beweiskonstruktion der Schritt ist, in dem die privaten Eingaben im Klartext vorliegen, ist die Umgebung des Provers der Ort, an dem das Enclave-Design seine Schutzmaßnahmen konzentriert.

Die dokumentierten Privacy-Rings-Prüfungen verifizieren die Zertifikatskette, Challenge-Response und Frische, die freigegebenen Messwerte und die Bindung des Anfrage-Verschlüsselungsschlüssels. Das getaggte SDK lehnt eine Remote-Prover-Anfrage ohne Attestierung ab, bevor ein HTTP-Aufruf erfolgt. Eine Wallet kann eine überprüfte Release-Richtlinie pinnen oder eine Netzwerkrichtlinie übernehmen, die von den gepinnten Signern des SDKs authentifiziert wird. Signierte Richtlinien werden während der Attestierung aktualisiert und laufen nach der Verwendung ab.

Wo das Vertrauen weiterhin liegt

Eine Wallet kann automatisch bestätigen, dass die Enclave einem freigegebenen Software-Image und Verschlüsselungsschlüssel entspricht, doch die Entscheidung, welches Image freigegeben wird, erfordert weiterhin Vertrauen in den Code und seine Prüfer.

Laut dem Nitro-Deployment-Guide umfasst das gemessene Image den Prover, das Startskript, das Zertifikatsbündel, erlaubte externe Hosts, die Indexer-URL und die KMS-Schlüsselidentität. Das Design nutzt den AWS Key Management Service, um den gemeinsamen Verschlüsselungs-Seed nur an Enclaves mit übereinstimmender Attestierung freizugeben. Clients können die KMS-Schlüsselrichtlinie nicht lesen, so der Guide, und verlassen sich stattdessen auf das Deployment des Betreibers für diese Garantie. Er benennt AWS KMS, AWS Support, Nitro-Hardware und den Betreiber als Vertrauensanker während der anfänglichen Richtlinienbindung.

Auch korrekt verschlüsselte Anfragen lassen Metadaten für die übergeordnete Instanz sichtbar, darunter Pfade, Abfragen, Timing und Größen; der Pfad verrät die Schaltungsform des Beweises.

Der versionierte TEE-Guide verzeichnet einen Mainnet-Build auf Basis von v0.6.0-alpha mit gemessener Build-Herkunft, deutlich unterscheidbar vom Dokumentations-Tag ts-sdk-v0.8.0-alpha. Die Spezifikation erlaubt Client-seitige Beweise, und das Repository stellt Localnet-Tooling sowie herunterladbare Prover-Binaries bereit.

Helius' Launch-Ankündigung nennt Certora, zkSecurity und OtterSec als Auditoren der Programme und Schaltungen. Seine Sicherheitsseite listet das Certora-Audit im Oktober und das zkSecurity-Audit im August auf, während der Bericht von OtterSec als ausstehend markiert ist. Für Teams, die den Launch bewerten, sind die dokumentierten Punkte zur Beobachtung der ausstehende OtterSec-Bericht, die Lücke zwischen dem v0.6.0-alpha-Mainnet-Build und dem Dokumentations-Tag ts-sdk-v0.8.0-alpha sowie die Frage, ob Integrationen gepinnte Release-Richtlinien, Netzwerkrichtlinien oder die Client-seitige Proving-Option der Spezifikation übernehmen.

Der Launch lässt Wallet-Entwickler mit einer Vertrauensentscheidung zurück: welchen Code und welche Deployment-Richtlinie sie zur Verarbeitung von Beweiseingaben freigeben.

Quelle: CryptoNewsNet | Ursprünglich berichtet von CryptoSlate