Helius cifra las transferencias de Solana sin eliminar la confianza del operador

Helius lanzó su Privacy Ring sin permisos en la red principal de Solana el 10 de noviembre con activos de pago y montos cifrados, mientras que las direcciones de las billeteras del remitente y del destinatario permanecen visibles.

Su probador predeterminado documentado, el servicio que construye pruebas de conocimiento cero, añade un requisito de hardware donde las entradas de transacciones secretas se procesan dentro de un enclave AWS Nitro atestado, un entorno de computación aislado.

Solana puede verificar que una transferencia cumple con las reglas del protocolo, pero proteger las entradas mientras se realiza esa prueba depende de la aislamiento, el código y las políticas de implementación del probador.

La pregunta práctica para los desarrolladores de billeteras que integran el lanzamiento es cuál de esas protecciones su software puede verificar.

Lo que llega al probador de Solana

La guía de integración de billeteras de Helius dice que la generación de pruebas necesita entradas en texto plano que cubran todos los datos de la transacción y claves de anulación. Identifica un enclave AWS Nitro atestado como el probador predeterminado de los SDK.

La especificación del protocolo enumera entradas privadas que incluyen el activo, el monto, los valores de ocultación y el secreto de anulación para las notas que se están gastando, junto con rutas que demuestran que esas notas pertenecen al árbol de estado. La prueba también incluye activos de salida, montos y valores de ocultación.

Esas entradas se vuelven legibles para el código de prueba dentro del enclave, y el cliente documentado las protege del operador anfitrión cifrando las solicitudes a una clave mantenida por el enclave atestado.

El secreto de anulación también deriva los marcadores utilizados para prevenir el gasto repetido. En la integración de billetera nativa, la billetera retiene la clave de firma, y el SDK de TypeScript deja la firma de la transacción final de Solana al firmante de la aplicación.

Helius documenta la descifrado local, que mantiene la clave de visualización en el dispositivo, y la descifrado delegada, que comparte una clave de visualización con un proveedor autorizado. La delegación le da a ese proveedor acceso de lectura a saldos e historial, sin otorgar autoridad de gasto.

AWS describe Nitro Enclaves como entornos aislados cuyo memoria no pueden acceder los procesos o administradores de la instancia principal. Los enclaves no tienen almacenamiento persistente, acceso interactivo o redes externas.

El documento firmado de AWS contiene huellas digitales criptográficas de su imagen y software. Las verificaciones documentadas de Privacy Rings verifican la cadena de certificados, la respuesta al desafío y la frescura, las mediciones aprobadas y la vinculación de la clave de cifrado de solicitud.

El SDK etiquetado rechaza una solicitud de probador remoto sin una, antes de hacer una llamada HTTP. Una billetera puede fijar una política de lanzamiento revisada o usar una política de red autenticada por los firmantes fijados del SDK. Las políticas firmadas se actualizan durante la atestación y expiran después de su uso.

Las entradas secretas viajan. La autoridad de firma se queda.

El camino predeterminado documentado de Helius envía entradas de prueba cifradas a un enclave AWS Nitro, luego devuelve la prueba a la billetera antes de la firma de la transacción.
Las entradas de prueba cifradas hacen un viaje de ida y vuelta; la billetera mantiene la autoridad de firma DOCUMENTED DEFAULT PROVING PATH Billetera AWS Nitro enclave Entradas cifradas Datos de transacción + secretos de anulación La prueba regresa a la billetera La clave de firma permanece en la billetera La billetera construye + firma La prueba viaja con la transacción Solana verifica Prueba + autorización del propietario Las entradas de prueba en texto plano se procesan dentro de La validez de la prueba no certifica la confidencialidad del probador.
La billetera cifra las entradas para el enclave, recibe una prueba y firma la transacción de Solana DOCUMENTED DEFAULT PATH Billetera La clave de firma permanece en la billetera Datos de tx cifrados + secreto de anulación La prueba regresa AWS Nitro enclave Entradas de prueba en texto plano procesadas dentro de La billetera construye + firma La transacción lleva la prueba Solana Prueba + autorización del propietario verificada La validez de la prueba no certifica la confidencialidad del probador.

Inspeccionar el límite de verificación

Verificación del límite de la cartera La cartera verifica la atestación contra una política aprobada antes de cifrar las solicitudes de prueba remota.

Verificaciones de la cartera contra una política aprobada Certificado + desafío Verificar identidad y frescura Mediciones de software Coincidir con la imagen aprobada Vinculación de clave de cifrado Las entradas van a la clave atestada La aprobación del código sigue siendo una elección de confianza.

Verificaciones de atestación del lado de la cartera

1. Certificado + desafío
2. Identidad y frescura
3. Mediciones de software
4. Coincidir con la imagen aprobada
5. Vinculación de clave de cifrado
6. Las entradas van a la clave atestada La aprobación del código sigue siendo una elección de confianza.

La revisión del código, la aislamiento de AWS y la vinculación de la política inicial de KMS del operador sustentan el diseño de confidencialidad documentado.

Dependencias de confianza detrás de la prueba confidencial Código revisado Aislamiento de AWS Vinculación de KMS del operador Los clientes no pueden inspeccionar la política de claves de KMS. Las verificaciones de atestación no eliminan esta dependencia de implementación.

Dependencias detrás de la prueba confidencial

1. Código revisado
2. Confianza en la implementación
3. Aislamiento de AWS
4. Garantías de hardware + plataforma
5. Vinculación de KMS del operador
6. El cliente no puede leer la política de claves Estas dependencias permanecen después de la atestación.

Las carteras verifican un enclave y una clave aprobados; la revisión del código y la política de implementación siguen siendo dependencias separadas.

Configuración predeterminada documentada solamente, no atestación en vivo independiente ni auditoría. Otros caminos de prueba o autorización pueden diferir. La firma nativa de la cartera, la prueba remota y el acceso a la visualización de saldo tienen roles separados.

Fuentes y evidencia

Fuentes

1. Cartera Privada
2. Especificación del protocolo Solana Privacy Rings
3. README del SDK de TypeScript en ts-sdk-v0.8.0-alpha
4. Garantías de cifrado y privacidad
5. README del probador TEE en ts-sdk-v0.8.0-alpha
6. Guía de implementación del probador Nitro Enclave
7. ¿Qué son los Nitro Enclaves?
8. Atestación criptográfica

Hechos de apoyo

• La guía de integración de billetera de Helius dice que la generación de pruebas requiere entradas en texto plano que cubran todos los datos de la transacción y las claves de anulación, e identifica un enclave AWS Nitro atestiguado como el probador predeterminado de los SDK.
• Las entradas de prueba privadas del protocolo incluyen el activo de nota gastada, la cantidad, el blinding, el secreto de anulación y la ruta Merkle, además del activo de salida, la cantidad y el blinding; estas son entradas secretas utilizadas para construir la prueba en lugar de datos revelados por la prueba en la cadena.
• En la integración de billetera nativa documentada, la billetera retiene su clave de firma de Solana; el SDK de TypeScript etiquetado dice que la transacción de Solana finalizada es firmada por el firmante de la aplicación.
• Los secretos de anulación ayudan a derivar los marcadores que previenen el gasto repetido; son distintos de la firma del propietario que autoriza un gasto normal de anillo predeterminado.
• El SDK etiquetado requiere una política TEE suministrada por la aplicación antes de hacer una solicitud de probador remoto y cifra las llamadas a la clave atestiguada; una política remota faltante falla antes de HTTP.
• Las verificaciones de atestación documentadas cubren la cadena de certificados, nonce, frescura, medidas de enclave aprobadas y la vinculación de la clave de cifrado HPKE; los pines de confianza deben provenir de una política aprobada en lugar de la respuesta del probador.
• AWS dice que Nitro aísla la memoria del enclave de la instancia principal, incluidos los usuarios raíz o administradores, y no proporciona almacenamiento persistente, acceso interactivo ni redes externas dentro del enclave.
• La guía de implementación de Nitro dice que la imagen medida incluye el binario del probador, el script de inicio, el paquete de certificados, los hosts de salida permitidos, la URL del indexador y la identidad de la clave KMS; PCR0 a PCR2 vinculan estos bytes.
• El diseño de Nitro libera una semilla compartida cifrada a través de AWS KMS solo a enclaves atestiguados coincidentes; su guía dice explícitamente que un cliente no puede leer la política de clave KMS y depende de la implementación del operador para esa garantía.
• El SDK admite ya sea una política JSON revisada fijada por la aplicación o políticas de red autenticadas por firmantes fijados a través de SignedTeePolicy; las políticas firmadas se actualizan durante la atestación y no se utilizan después de su vencimiento.
• La guía de Nitro dice que el padre no puede leer solicitudes o respuestas de prueba cifradas correctamente, pero puede ver rutas, consultas, tiempos y tamaños; la ruta revela la forma del circuito.
• Para transferencias ordinarias autorizadas por el propietario, las verificaciones de prueba del protocolo incluyen inclusión de nota, no inclusión de anulación, autorización del propietario y conservación del saldo; la verificación exitosa de la prueba no verifica por sí misma la confidencialidad de la máquina que generó la prueba.

Método

Diagrama de flujo de datos cualitativos del probador predeterminado de billetera nativa documentada. Sin escala numérica ni valores calculados. El panel seleccionable distingue las verificaciones de atestación del cliente de las dependencias de confianza de código, hardware y despliegue.

Alcance

Configuración predeterminada documentada únicamente, no atestación en vivo independiente ni auditoría. Otros caminos de prueba o autorización pueden diferir. La firma de billetera nativa, la prueba remota y el acceso a la visualización de saldo tienen roles separados. Infografía de CryptoSlate

Donde permanece la confianza en el despliegue de Solana

Una billetera puede verificar automáticamente que el enclave coincide con una imagen de software aprobada y una clave de cifrado, sin embargo, decidir qué imagen aprobar aún requiere confianza en el código y sus revisores.

La guía de implementación de Nitro dice que la imagen medida incluye el probador, el script de inicio, el paquete de certificados, los hosts externos permitidos, la URL del indexador y la identidad de la clave KMS. Su diseño utiliza el Servicio de Gestión de Claves de AWS para liberar la semilla de cifrado compartida solo a enclaves atestiguados coincidentes.

La guía indica que los clientes no pueden leer la política de claves KMS y dependen de la implementación del operador para esa garantía. Identifica AWS KMS, AWS Support, hardware Nitro y al operador como raíces de confianza durante la vinculación inicial de políticas.

Incluso las solicitudes correctamente cifradas dejan metadatos visibles para el padre, como rutas, consultas, tiempos y tamaños. La ruta revela la forma del circuito de la prueba.

La guía de TEE versionada registra una construcción de mainnet basada en v0.6.0-alpha, con procedencia de construcción medida, distinta de la etiqueta de documentación ts-sdk-v0.8.0-alpha.

La especificación permite pruebas del lado del cliente, y el repositorio proporciona herramientas de localnet y binarios de probadores descargables.

El anuncio de lanzamiento de Helius dice que Certora, zkSecurity y OtterSec auditaron programas y circuitos. Su página de seguridad lista a Certora en octubre y a zkSecurity en agosto, mientras marca a OtterSec como a la espera de un informe.

El lanzamiento brinda a los desarrolladores de billeteras una decisión de confianza sobre qué código y política de implementación aprueban para manejar las entradas de prueba.

Este contenido se ofrece únicamente con fines informativos generales y no constituye un asesoramiento financiero, de inversión, legal ni fiscal. Cualquier evento, recompensa, promoción en línea o información relacionada que se mencione en el presente documento no debe considerarse como una recomendación, solicitud o invitación a comprar, vender, operar o de negociar de otra manera con cualquier criptoactivo. Los criptoactivos son sumamente volátiles y pueden provocar pérdidas. La disponibilidad de los servicios, productos y eventos relacionados de WEEX puede variar según la región. Tienes la responsabilidad de asegurarte de que tu participación esté de acuerdo con las leyes y regulaciones locales vigentes.