Vista previa para desarrolladores: tokens confidenciales en Stellar

Nota del editor: Las Vistas Previas para Desarrolladores de Stellar ponen nuevas herramientas para desarrolladores y capacidades del protocolo en manos de los desarrolladores antes de que estén listas para producción. Aunque aún no están aprobadas para mainnet, el contrato de Token Confidencial ya está activo en testnet. Previsualízalos y pruébalos ahora mientras las auditorías del contrato y del verificador están en curso.

Hoy presentamos nuestra última función de privacidad: Tokens Confidenciales, una suite de contratos de OpenZeppelin, conectada a un verificador UltraHonk implementado por Nethermind, que agrega saldos privados y montos de transferencia privados a cualquier token SEP-41.

La privacidad en una Blockchain pública no es una sola cosa. Diferentes casos de uso requieren propiedades distintas, y la arquitectura que elijas al principio decide lo que podrás hacer después.

Los Tokens Confidenciales tienen un alcance deliberado: ocultan saldos y montos de transferencia mientras mantienen visibles las direcciones del remitente y del destinatario. Para desarrolladores que ya realizan transacciones en cadena, donde los montos y saldos son públicos por defecto, es un avance significativo. Los casos de uso adecuados incluyen gestión de tesorería, nómina y liquidación institucional, entre otros.

En comparación, la otra opción en la pila de privacidad de Stellar—implementaciones de pools de privacidad como Stellar Private Payments (SPP)—protege tanto a las partes como a los montos. Esta publicación se centra en el caso de uso del Token Confidencial: contrapartes conocidas, montos ocultos.

A nivel de arquitectura, un Token Confidencial es un contrato envoltorio. Un usuario toma cualquier token SEP-41—USDC emitido mediante el Stellar Asset Contract, un token nativo de contrato, cualquier cosa que implemente el estándar— y lo deposita en un contrato de token confidencial.

Dentro del envoltorio, el saldo se codifica como un compromiso de Pedersen—oculto a la vista pública, pero totalmente verificable por la red. Las transferencias entre cuentas dentro del envoltorio mueven fondos sin revelar valores. Para salir, un usuario retira de vuelta al token SEP-41 subyacente.

El libro mayor base permanece abierto y auditable. La privacidad vive totalmente en la capa de aplicación, en el contrato envoltorio. Este aislamiento es intencional: si alguna vez se encontrara un bug en un circuito de token confidencial, solo podría afectar a los tokens dentro de ese envoltorio. Por diseño, cualquier vulnerabilidad queda contenida en el/los token(s) dentro de ese envoltorio, sin afectar al activo subyacente ni a la red más amplia.

Las pruebas se escriben en Noir y se verifican en cadena mediante el verificador UltraHonk de Nethermind, usando las funciones host criptográficas introducidas en Protocolo 25 (X-Ray). Esta es una implementación funcional en testnet con la que puedes desarrollar hoy.

Esta vista previa incluye primitivas diseñadas para brindar soporte a flujos de trabajo orientados al cumplimiento:

• Clave de vista del auditor. Un rol de auditor designado puede ver los montos de las transacciones y los saldos de cuenta de los activos en el envoltorio.
• Divulgación selectiva. Los titulares de cuenta pueden probar que ocurrió una transacción específica a una parte específica sin exponer el resto de su actividad.
• Congelamiento a nivel de cuenta. Se hereda de los controles existentes del Stellar Asset Contract (SAC).
• Motor de políticas de cumplimiento configurable. Te permite conectar contratos de políticas que actúan como registros de identidad de listas de permitidos o bloqueados.

El documento completo de extensiones de cumplimiento explica en detalle el congelamiento, el traspaso SAC y el diseño de los ganchos de política. Estas extensiones de cumplimiento son open-source y se están iterando activamente.

La forma más rápida de entender los Tokens Confidenciales es ejecutar la demo de OpenZeppelin localmente y hacer una transferencia confidencial en testnet.

La demo en Stellar Testnet recorre tres roles: titular de la cuenta, receptor de divulgación, y auditor. Para probarla en el navegador, conecta tu billetera—recomendamos Freighter en Stellar Testnet. Ve a Stellar Lab y selecciona "Fund account" para obtener XLM de prueba.

Para ejecutarlo localmente:

1. Clona stellar-confidential-token-demo
2. Revisa README para uso básico y más avanzado
3. Elige los módulos relevantes desde la lib
4. Envía issues durante la ventana de testnet.

Damos la bienvenida a socios de diseño y contribuciones de la comunidad—Si estás creando soluciones de privacidad centradas en el cumplimiento en Stellar, eres miembro de la cohorte de SCF o te uniste a nuestro reciente Stellar Hacks: Real-World ZK hackathon—comparte en qué estás trabajando en nuestro Discord de Desarrolladores.

Nos entusiasma contar con Boyan Barakov (Senior OSS Developer, OpenZeppelin) se una a Alessandro Voto (Senior PM, Stellar) para presentar los Tokens Confidenciales y el trabajo con OpenZeppelin que impulsa la privacidad en cadena.

Sintoniza el 2 de jul @ 4:00 PM UTC para ver la transmisión en @BuildOnStellar

Los Tokens Confidenciales son parte de una pila de privacidad más amplia en Stellar. Para contexto sobre las mejoras que hicieron esto posible, consulta: stellar.org/privacy, la documentación para desarrolladores de Stellar sobre privacidad, y la taxonomía en el Apéndice más abajo.

Una manera fácil de entender las soluciones de privacidad en cadena es preguntar:

¿Qué ve la red y qué permanece oculto?

Por qué existen ambas vías. Los Tokens Confidenciales están diseñados para flujos con contrapartes conocidas donde los montos no deberían ser públicos (p. ej., nómina, gestión de tesorería, liquidación B2B). Podrías tener dos bancos liquidando en USDC entre sí, donde cada parte ya sabe con quién está transaccionando, pero los montos de la liquidación (y los saldos resultantes dentro del envoltorio) permanecen razonablemente ocultos para la red más amplia.

Jerarquía de capas de privacidad de Stellar

Capa de aplicación: Contratos inteligentes de Stellar que implementan comportamientos de privacidad específicos. Esto incluye Tokens Confidenciales e implementaciones de pools de privacidad como Stellar Private Payments (SPP).

Capa de verificador: Un verificador en cadena es un contrato inteligente que acepta una prueba ZK compacta y confirma su validez sin re-ejecutar el cómputo original. Ejemplos incluyen el Verificador UltraHonk de Nethermind (usado por el contrato de Token Confidencial) y el Verificador RISC Zero (Groth16). El verificador original fue construido por un miembro de la comunidad, @yugocabrio. Nethermind asumió la titularidad y lo actualizó para usar las funciones del host del Protocolo de Stellar 25/26, haciéndolo más eficiente y práctico para la evaluación en testnet.

Funciones criptográficas del host: Desarrolladas en el protocolo de Stellar en la capa base: operaciones de curva elíptica en las curvas BN254 y BLS12-381, y la función hash Poseidon/Poseidon2. Introducidas en las actualizaciones X-Ray (Protocolo 25) y Yardstick (Protocolo 26).

Libro mayor base (público): La privacidad vive en las capas por encima de él, nunca en la base.