Helius lanza pagos cifrados en Solana en la mainnet, aunque aún se requiere confianza en el operador

Helius activó su Privacy Ring sin permisos en la mainnet de Solana el 10 de noviembre, cifrando los activos y montos de los pagos mientras deja visibles las direcciones de las billeteras del remitente y el destinatario. El prover predeterminado documentado del sistema—el servicio que construye las pruebas de conocimiento cero—añade un requisito de hardware: los datos sensibles de la transacción se procesan dentro de un enclave AWS Nitro certificado, un entorno de cómputo aislado.

Dado que el registro de Solana es público y sus transferencias registradas son observables por cualquiera, el cifrado de activos y montos aborda los campos más directamente sensibles de un pago, incluso cuando las direcciones a ambos lados siguen siendo visibles.

Solana puede verificar que una transferencia cumple las reglas del protocolo, pero proteger los datos mientras se genera la prueba depende del aislamiento del prover, su código y sus políticas de despliegue.

Qué llega al servicio de generación de pruebas

Para los desarrolladores de billeteras que integran este lanzamiento, la pregunta práctica es cuáles de esas protecciones puede verificar realmente su software. Sus decisiones—descifrado local o delegado, generación de pruebas remota o en el cliente—determinan en qué partes de una transacción sus usuarios deben confiar en terceros.

La guía de integración de billeteras de Helius indica que la generación de pruebas requiere datos en texto plano que cubren la información completa de la transacción y las claves de nullifier, e identifica un enclave AWS Nitro certificado como el prover predeterminado de los SDK.

La especificación del protocolo enumera datos privados que incluyen el activo, el monto, los valores de blinding y el secreto de nullifier de las notas que se gastan, junto con las rutas que demuestran que esas notas pertenecen al árbol de estado. La prueba también incorpora activos, montos y valores de blinding de salida.

Esos datos se vuelven legibles para el código de generación de pruebas dentro del enclave. El cliente documentado los protege del operador del host al cifrar las solicitudes hacia una clave que posee el enclave certificado. El secreto de nullifier también deriva los marcadores utilizados para evitar el gasto repetido.

En la integración nativa de billetera, la billetera conserva la clave de firma, y el SDK de TypeScript deja la firma de la transacción final de Solana al firmador de la aplicación. Helius documenta dos modos de descifrado: el descifrado local, que mantiene la clave de visualización en el dispositivo, y el descifrado delegado, que comparte una clave de visualización con un proveedor autorizado. La delegación otorga a ese proveedor acceso de lectura a saldos e historial sin conceder autoridad de gasto.

Cómo funciona el modelo de enclave

AWS describe los Nitro Enclaves como entornos aislados cuya memoria no puede ser accedida por los procesos o administradores de la instancia principal. Los enclaves no tienen almacenamiento persistente, acceso interactivo ni conexión de red externa. El documento de atestación firmado por AWS contiene huellas criptográficas de la imagen y el software del enclave.

Como la construcción de la prueba es el paso en el que los datos privados existen en texto plano, el entorno del prover es donde el diseño del enclave concentra sus protecciones.

Las comprobaciones de Privacy Rings documentadas verifican la cadena de certificados, la respuesta al desafío y su frescura, las mediciones aprobadas y la vinculación de la clave de cifrado de solicitudes. El SDK etiquetado rechaza una solicitud a un prover remoto sin atestación antes de realizar cualquier llamada HTTP. Una billetera puede fijar una política de lanzamiento revisada o adoptar 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.

Dónde sigue descansando la confianza

Una billetera puede confirmar automáticamente que el enclave coincide con una imagen de software aprobada y una clave de cifrado; sin embargo, decidir qué imagen aprobar todavía requiere confianza en el código y en quienes lo revisaron.

Según la guía de despliegue de Nitro, la imagen medida incluye el prover, el script de arranque, el paquete de certificados, los hosts externos permitidos, la URL del indexador y la identidad de la clave KMS. El diseño utiliza AWS Key Management Service para liberar la semilla de cifrado compartida solo a enclaves con una atestación coincidente. Los clientes no pueden leer la política de la clave KMS, señala la guía, y en cambio dependen del despliegue del operador para esa garantía. Identifica AWS KMS, AWS Support, el hardware Nitro y el operador como raíces de confianza durante la vinculación inicial de políticas.

Incluso las solicitudes correctamente cifradas dejan metadatos visibles para la instancia principal, incluyendo rutas, consultas, tiempos y tamaños; la ruta revela la forma del circuito de la prueba.

La guía de TEE versionada registra una compilación de mainnet basada en v0.6.0-alpha con procedencia de compilación medida, distinta de la etiqueta de documentación ts-sdk-v0.8.0-alpha. La especificación permite pruebas en el cliente, y el repositorio ofrece herramientas de localnet y binarios del prover descargables.

El anuncio de lanzamiento de Helius indica que Certora, zkSecurity y OtterSec auditaron los programas y circuitos. Su página de seguridad enumera la auditoría de Certora en octubre y la de zkSecurity en agosto, mientras marca el informe de OtterSec como pendiente. Para los equipos que evalúan el lanzamiento, los puntos documentados a seguir son el informe pendiente de OtterSec, la diferencia entre la compilación de mainnet v0.6.0-alpha y la etiqueta de documentación ts-sdk-v0.8.0-alpha, y si las integraciones adoptan políticas de lanzamiento fijadas, políticas de red o la opción de pruebas en el cliente de la especificación.

El lanzamiento deja a los desarrolladores de billeteras una decisión de confianza: qué código y qué política de despliegue aprueban para manejar los datos de las pruebas.

Fuente: CryptoNewsNet | Reportado originalmente por CryptoSlate