Helius lance des paiements Solana chiffrés sur le mainnet, la confiance en l'opérateur toujours requise
Points clés
- •Le Privacy Ring sans permission d'Helius est lancé sur le mainnet Solana le 10 novembre, apportant le chiffrement des actifs et des montants des paiements, même si les adresses des portefeuilles des deux côtés restent publiquement visibles.
- •Le prouveur par défaut des SDK traite les données secrètes des transactions, notamment les clés de nullifier et les valeurs de masquage, dans une enclave AWS Nitro attestée que les clients vérifient cryptographiquement avant toute requête.
- •Helius propose un déchiffrement local, qui conserve la clé de visualisation sur l'appareil, et un déchiffrement délégué, qui accorde à un prestataire autorisé un accès en lecture aux soldes et à l'historique sans autorité de dépense.
- •Le modèle d'enclave exige toujours la confiance envers l'opérateur, AWS KMS et le matériel Nitro, ainsi que l'image logicielle approuvée, tandis que les métadonnées des requêtes telles que les chemins, la temporisation et les tailles restent visibles pour l'instance parente.
- •Certora et zkSecurity ont achevé les audits des programmes et des circuits, mais le rapport d'OtterSec est en attente, et le build mainnet v0.6.0-alpha diffère du tag de documentation ts-sdk-v0.8.0-alpha.

Helius lance des paiements Solana chiffrés sur le mainnet, la confiance en l'opérateur toujours requise
Helius a activé son Privacy Ring sans permission sur le mainnet Solana le 10 novembre, en chiffrant les actifs et les montants des paiements tout en laissant les adresses des portefeuilles de l'expéditeur et du destinataire visibles. Le prouveur par défaut documenté du système—le service qui construit les preuves à divulgaison nulle—ajoute une exigence matérielle : les données secrètes des transactions sont traitées dans une enclave AWS Nitro attestée, un environnement informatique isolé.
Le registre de Solana étant public et ses transferts enregistrés observables par tous, le chiffrement des actifs et des montants répond aux champs les plus directement sensibles d'un paiement, même si les adresses de part et d'autre restent visibles.
Solana peut vérifier qu'un transfert respecte les règles du protocole, mais la protection des données pendant la génération de la preuve dépend de l'isolation du prouveur, de son code et de ses politiques de déploiement.
Ce qui parvient au service de preuve
Pour les développeurs de portefeuilles intégrant ce lancement, la question pratique est de savoir lesquelles de ces protections leurs logiciels peuvent réellement vérifier. Leurs choix—déchiffrement local ou délégué, génération de preuves à distance ou côté client—déterminent quelles parties d'une transaction leurs utilisateurs doivent confier à d'autres.
Le guide d'intégration des portefeuilles d'Helius indique que la génération de preuves nécessite des données en clair couvrant l'intégralité des données de transaction et les clés de nullifier, et identifie une enclave AWS Nitro attestée comme prouveur par défaut des SDK.
La spécification du protocole énumère les données privées, notamment l'actif, le montant, les valeurs de masquage et le secret de nullifier des billets dépensés, ainsi que les chemins prouvant que ces billets appartiennent à l'arbre d'état. La preuve intègre également les actifs de sortie, les montants et les valeurs de masquage.
Ces données deviennent lisibles par le code de preuve à l'intérieur de l'enclave. Le client documenté les protège de l'opérateur hôte en chiffrant les requêtes vers une clé détenue par l'enclave attestée. Le secret de nullifier sert également à dériver les marqueurs utilisés pour empêcher la dépense multiple.
Dans l'intégration native des portefeuilles, le portefeuille conserve la clé de signature, et le SDK TypeScript laisse la signature de la transaction Solana finale au signataire de l'application. Helius documente deux modes de déchiffrement : le déchiffrement local, qui conserve la clé de visualisation sur l'appareil, et le déchiffrement délégué, qui partage une clé de visualisation avec un prestataire autorisé. La délégation accorde à ce prestataire un accès en lecture aux soldes et à l'historique, sans autorité de dépense.
Fonctionnement du modèle d'enclave
AWS décrit les Nitro Enclaves comme des environnements isolés dont la mémoire est inaccessible aux processus ou aux administrateurs de l'instance parente. Les enclaves n'ont ni stockage persistant, ni accès interactif, ni réseau externe. Le document d'attestation signé d'AWS contient les empreintes cryptographiques de l'image et du logiciel de l'enclave.
La construction de preuve étant l'étape où les données privées existent en clair, l'environnement du prouveur concentre les protections du modèle d'enclave.
Les contrôles documentés de Privacy Rings vérifient la chaîne de certificats, la réponse au défi et sa fraîcheur, les mesures approuvées et la liaison de la clé de chiffrement des requêtes. Le SDK référencé refuse toute requête à un prouveur distant sans attestation avant tout appel HTTP. Un portefeuille peut épingler une politique de version révisée ou adopter une politique de réseau authentifiée par les signataires épinglés du SDK. Les politiques signées sont actualisées lors de l'attestation et expirent après usage.
Où la confiance demeure
Un portefeuille peut automatiquement confirmer que l'enclave correspond à une image logicielle et à une clé de chiffrement approuvées, mais décider quelle image approuver exige toujours de la confiance dans le code et ses réviseurs.
Selon le guide de déploiement Nitro, l'image mesurée comprend le prouveur, le script de démarrage, le faisceau de certificats, les hôtes externes autorisés, l'URL de l'indexeur et l'identité de la clé KMS. La conception utilise AWS Key Management Service pour ne libérer la graine de chiffrement partagée qu'aux enclaves attestées correspondantes. Les clients ne peuvent pas lire la politique de clé KMS, note le guide, et dépendent du déploiement de l'opérateur pour cette garantie. Le guide identifie AWS KMS, AWS Support, le matériel Nitro et l'opérateur comme racines de confiance lors de la liaison initiale des politiques.
Même les requêtes correctement chiffrées laissent des métadonnées visibles pour l'instance parente, notamment les chemins, les requêtes, la temporisation et les tailles ; le chemin révèle la forme du circuit de la preuve.
Le guide TEE versionné enregistre un build mainnet basé sur v0.6.0-alpha avec provenance de build mesuré, distinct du tag de documentation ts-sdk-v0.8.0-alpha. La spécification autorise les preuves côté client, et le dépôt fournit des outils localnet et des binaires de prouveur téléchargeables.
L'annonce de lancement d'Helius indique que Certora, zkSecurity et OtterSec ont audité les programmes et les circuits. Sa page de sécurité répertorie l'audit de Certora en octobre et celui de zkSecurity en août, tout en indiquant le rapport d'OtterSec comme en attente. Pour les équipes évaluant ce lancement, les points documentés à suivre sont le rapport OtterSec en attente, l'écart entre le build mainnet v0.6.0-alpha et le tag de documentation ts-sdk-v0.8.0-alpha, et le choix des intégrations entre politiques de version épinglées, politiques de réseau ou l'option de preuve côté client de la spécification.
Ce lancement laisse aux développeurs de portefeuilles une décision de confiance : quel code et quelle politique de déploiement ils approuvent pour traiter les données de preuve.
Source : CryptoNewsNet | Initialement rapporté par CryptoSlate