Helius lanceert versleutelde Solana-betalingen op mainnet, vertrouwen in operator blijft vereist

Helius activeerde zijn permissionless Privacy Ring op Solana mainnet op 10 november, waarbij betaalactiva en bedragen worden versleuteld terwijl de walletadressen van verzender en ontvanger zichtbaar blijven. De gedocumenteerde standaard prover van het systeem—de dienst die zero-knowledge proofs construeert—voegt een hardwarevereiste toe: geheime transactie-invoer wordt verwerkt binnen een geattesteerde AWS Nitro enclave, een geïsoleerde rekenomgeving.

Omdat Solana's ledger publiek is en de geregistreerde overdrachten door iedereen waarneembaar zijn, adresseren versleutelde activa en bedragen de meest direct gevoelige velden van een betaling, ook al blijven de adressen aan beide kanten zichtbaar.

Solana kan verifiëren dat een overdracht aan de regels van het protocol voldoet, maar de bescherming van de invoer tijdens het genereren van het proof hangt af van de isolatie van de prover, de code en de implementatiebeleid.

Wat de bewijsdienst bereikt

Voor walletontwikkelaars die de lancering integreren is de praktische vraag welke van die beschermingen hun software daadwerkelijk kan verifiëren. Hun keuzes—lokale of gedelegeerde decryptie, externe of client-side proofgeneratie—bepalen welke delen van een transactie hun gebruikers aan anderen moeten toevertrouwen.

De walletintegratiegids van Helius stelt dat proofgeneratie platte-tekstinvoer vereist die de volledige transactiedata en nullifier keys omvat, en identificeert een geattesteerde AWS Nitro enclave als de standaard prover van de SDK's.

De protocolspecificatie somt privé-invoer op waaronder het activum, het bedrag, blinding values en het nullifier secret voor de te besteden notes, samen met paden die bewijzen dat die notes tot de state tree behoren. Het proof omvat ook outputactiva, bedragen en blinding values.

Die invoer wordt leesbaar voor de bewijscode binnen de enclave. De gedocumenteerde client beschermt ze tegen de hostoperator door requests te versleutelen met een sleutel die door de geattesteerde enclave wordt gehouden. Het nullifier secret leidt ook de markers af die herhaalde besteding voorkomen.

In de native walletintegratie behoudt de wallet de signing key, en laat de TypeScript SDK het ondertekenen van de voltooide Solana-transactie over aan de signer van de applicatie. Helius documenteert twee decryptiemodi: lokale decryptie, waarbij de viewing key op het apparaat blijft, en gedelegeerde decryptie, waarbij een viewing key wordt gedeeld met een geautoriseerde provider. Delegatie geeft die provider leestoegang tot saldi en historie, zonder bestuursbevoegdheid.

Hoe het enclave-model werkt

AWS omschrijft Nitro Enclaves als geïsoleerde omgevingen waarvan het geheugen niet toegankelijk is voor processen of beheerders van de parent-instantie. Enclaves hebben geen persistente opslag, interactieve toegang of externen netwerken. Het ondertekende attestation-document van AWS bevat cryptografische vingerafdrukken van de image en software van de enclave.

Omdat de constructie van het proof de stap is waarin de privé-invoer in platte tekst bestaat, is de omgeving van de prover waar het enclave-ontwerp zijn beschermingen concentreert.

De gedocumenteerde Privacy Rings-controles verifiëren de certificaatketen, challenge response en versheid, goedgekeurde measurements en de binding van de request-versleutelingssleutel. De getagde SDK weigert een extern prover-request zonder attestation vóór het doen van een HTTP-call. Een wallet kan een beoordeeld releasebeleid vastpinnen of een netwerkbeleid aannemen dat is geverifieerd door de vastgepinde signers van de SDK. Ondertekende beleidsregels worden vernieuwd tijdens attestation en verlopen na gebruik.

Waar vertrouwen nog rust

Een wallet kan automatisch bevestigen dat de enclave overeenkomt met een goedgekeurde software-image en versleutelingssleutel, maar beslissen welke image moet worden goedgekeurd vereist nog steeds vertrouwen in de code en de beoordelaars ervan.

Volgens de Nitro-implementatiegids omvat de gemeten image de prover, het opstartscript, de certificaatbundel, toegestane externe hosts, de indexer-URL en de KMS-sleutelidentiteit. Het ontwerp gebruikt AWS Key Management Service om de gedeelde versleutelingsseed alleen vrij te geven aan enclaves met een overeenkomende attestation. Cliënten kunnen het KMS-sleutelbeleid niet lezen, merkt de gids op, en vertrouwen voor die garantie op de implementatie van de operator. Het identificeert AWS KMS, AWS Support, Nitro-hardware en de operator als trust roots tijdens de initiële beleidsbinding.

Zelfs correct versleutelde requests laten metadata zichtbaar voor de parent-instantie, waaronder paden, queries, timing en groottes; het pad onthult de circuitvorm van het proof.

De versiebeheerde TEE-gids registreert een mainnet-build gebaseerd op v0.6.0-alpha met measured-build provenance, verschillend van de ts-sdk-v0.8.0-alpha-documentatietag. De specificatie staat client-side proofs toe, en de repository levert localnet-tooling en downloadbare prover-binary's.

De lanceringsaankondiging van Helius zegt dat Certora, zkSecurity en OtterSec de programma's en circuits hebben geauditeerd. De beveiligingspagina vermeldt Certora's audit in oktober en die van zkSecurity in augustus, terwijl het rapport van OtterSec als in behandeling wordt gemarkeerd. Voor teams die de lancering evalueren, zijn de gedocumenteerde aandachtspunten het openstaande OtterSec-rapport, het verschil tussen de v0.6.0-alpha mainnet-build en de ts-sdk-v0.8.0-alpha-documentatietag, en of integraties vastgepinde releasebeleid, netwerkbeleid of de client-side proving-optie van de specificatie hanteren.

De lancering laat walletontwikkelaars met een vertrouwensbeslissing: welke code en welk implementatiebeleid ze goedkeuren om proof-invoer te verwerken.

Bron: CryptoNewsNet | Oorspronkelijk gemeld door CryptoSlate