Helius lancia pagamenti Solana cifrati sul mainnet, ma la fiducia nell'operatore resta necessaria

Helius ha attivato il suo Privacy Ring permissionless sul mainnet di Solana il 10 novembre, cifrando gli asset e gli importi dei pagamenti e lasciando visibili gli indirizzi wallet di mittente e destinatario. Il prover predefinito documentato dal sistema—il servizio che costruisce le prove a conoscenza zero—aggiunge un requisito hardware: gli input segreti delle transazioni vengono elaborati all'interno di un'enclave AWS Nitro attestata, un ambiente di calcolo isolato.

Poiché il registro di Solana è pubblico e i trasferimenti registrati sono osservabili da chiunque, la cifratura di asset e importi copre i campi più direttamente sensibili di un pagamento, anche se gli indirizzi ai due estremi restano visibili.

Solana può verificare che un trasferimento soddisfi le regole del protocollo, ma la protezione degli input durante la generazione della prova dipende dall'isolamento del prover, dal suo codice e dalle sue politiche di deployment.

Cosa arriva al servizio di prova

Per gli sviluppatori di wallet che integrano il lancio, la domanda pratica è quali di queste protezioni il loro software possa effettivamente verificare. Le loro scelte—decifratura locale o delegata, generazione di prove remota o lato client—determinano quali parti di una transazione i loro utenti devono affidare ad altri.

La guida all'integrazione wallet di Helius afferma che la generazione delle prove richiede input in chiaro che coprono l'intero set di dati della transazione e le nullifier key, e identifica un'enclave AWS Nitro attestata come prover predefinito degli SDK.

La specifica del protocollo elenca tra gli input privati l'asset, l'importo, i blinding values e il nullifier secret per le note spese, insieme ai percorsi che dimostrano che tali note appartengono all'albero di stato. La prova incorpora anche gli asset di output, gli importi e i blinding values.

Questi input diventano leggibili dal codice di prova all'interno dell'enclave. Il client documentato li protegge dall'operatore host cifrando le richieste verso una chiave detenuta dall'enclave attestata. Il nullifier secret deriva anche i marker utilizzati per impedire la spesa ripetuta.

Nell'integrazione wallet nativa, il wallet conserva la chiave di firma, e il TypeScript SDK lascia la firma della transazione Solana completata al signer dell'applicazione. Helius documenta due modalità di decifratura: la decifratura locale, che mantiene la viewing key sul dispositivo, e la decifratura delegata, che condivide una viewing key con un provider autorizzato. La delega concede a quel provider l'accesso in lettura a saldi e cronologia senza attribuire autorità di spesa.

Come funziona il modello a enclave

AWS descrive le Nitro Enclaves come ambienti isolati la cui memoria non è accessibile dai processi o dagli amministratori dell'istanza padre. Le enclave non hanno storage persistente, accesso interattivo o rete esterna. Il documento di attestazione firmato da AWS contiene le impronte crittografiche dell'immagine e del software dell'enclave.

Poiché la costruzione della prova è la fase in cui gli input privati esistono in chiaro, l'ambiente del prover è quello su cui il progetto a enclave concentra le sue protezioni.

I controlli Privacy Rings documentati verificano la catena dei certificati, la risposta alla challenge e la freshness, le misurazioni approvate e il binding della chiave di cifratura delle richieste. L'SDK etichettato rifiuta una richiesta a un prover remoto senza attestazione prima di effettuare qualsiasi chiamata HTTP. Un wallet può fissare una release policy esaminata o adottare una network policy autenticata dai signer fissati dall'SDK. Le policy firmate si rinnovano durante l'attestazione e scadono dopo l'uso.

Dove resta la fiducia

Un wallet può confermare automaticamente che l'enclave corrisponda a un'immagine software e a una chiave di cifratura approvate, ma decidere quale immagine approvare richiede ancora fiducia nel codice e nei suoi revisori.

Secondo la guida al deployment Nitro, l'immagine misurata include il prover, lo script di avvio, il bundle di certificati, gli host esterni consentiti, l'URL dell'indexer e l'identità della chiave KMS. Il progetto utilizza AWS Key Management Service per rilasciare il seed di cifratura condiviso solo alle enclave con attestazione corrispondente. I client non possono leggere la policy della chiave KMS, nota la guida, e fanno affidamento sul deployment dell'operatore per tale garanzia. La guida identifica AWS KMS, AWS Support, l'hardware Nitro e l'operatore come radici di fiducia durante il binding iniziale delle policy.

Anche le richieste correttamente cifrate lasciano metadati visibili all'istanza padre, come percorsi, query, tempi e dimensioni; il percorso rivela la forma del circuito della prova.

La guida TEE con versionamento registra una build mainnet basata su v0.6.0-alpha, con provenance di measured build, distinta dal tag di documentazione ts-sdk-v0.8.0-alpha. La specifica consente prove lato client, e il repository fornisce strumenti localnet e binari del prover scaricabili.

L'annuncio di lancio di Helius afferma che Certora, zkSecurity e OtterSec hanno auditato i programmi e i circuiti. La sua pagina di sicurezza elenca l'audit di Certora a ottobre e quello di zkSecurity ad agosto, segnando il report di OtterSec come in attesa. Per i team che valutano il lancio, gli elementi documentati da monitorare sono il report in attesa di OtterSec, il divario tra la build mainnet v0.6.0-alpha e il tag di documentazione ts-sdk-v0.8.0-alpha, e se le integrazioni adottino release policy fissate, network policy o l'opzione di prova lato client della specifica.

Il lancio lascia agli sviluppatori di wallet una decisione di fiducia: quale codice e quale politica di deployment approvare per gestire gli input delle prove.

Fonte: CryptoNewsNet | Segnalato originariamente da CryptoSlate