Stablecoins confidenciales prácticas: una arquitectura controlada por el emisor

Esta es una publicación invitada de Boyan Barakov, Desarrollador OSS Senior en OpenZeppelin, quien trabajó en el contrato de token confidencial en Stellar.

Este es el primer artículo de una serie de dos partes. Partiendo del token confidencial open-source de OpenZeppelin para Stellar, examina cómo las stablecoins confidenciales pueden proteger los montos de las transacciones y los saldos, preservando a la vez los controles y la visibilidad necesarios en un sistema gestionado por el emisor. El segundo artículo detallará la implementación en sí.

Una blockchain pública funciona como una capa de liquidación transparente y sin necesidad de confianza, abierta a cualquier actor económico. Las partes que transaccionan usan claves públicas derivadas criptográficamente, que no revelan directamente sus identidades en el mundo real. Sin embargo, dado que el libro mayor es plenamente verificable, cada transacción y cada monto permanecen de forma permanente en el registro. Cualquiera puede reconstruir el historial completo de transacciones de una dirección: cómo fue financiada, con qué direcciones interactuó, cuánto se movió y cuándo. Cuando esta información se combina con las amplias huellas de datos que los usuarios dejan fuera de la blockchain, con frecuencia las identidades del mundo real pueden vincularse a la actividad onchain, lo cual a menudo se considera un riesgo potencial.

La web temprana que se construyó sobre protocolos abiertos y sin cifrar ofrece un paralelo útil. HTTP por sí solo no pudo desbloquear el potencial comercial de internet, y solo tras la introducción del cifrado SSL/TLS la actividad de consumo a gran escala se hizo posible. Las blockchains públicas están hoy en un punto de inflexión similar. Sin una capa de privacidad sólida, que equilibre la confidencialidad del usuario con el cumplimiento normativo, el uso comercial e institucional serio probablemente seguirá siendo de nicho y experimental.

Las stablecoins son una buena ilustración de este desafío. Representan uno de los casos de uso más sólidos de la blockchain: pueden liquidar pagos en segundos, reducir los costos de transacción y servir a usuarios minoristas, comerciales e institucionales sobre la misma infraestructura. Sin embargo, la transparencia que hace verificable su liquidación también dificulta su uso para muchas actividades financieras cotidianas.

El desafío, entonces, no es solo añadir privacidad. Es determinar qué tipo de privacidad necesita una stablecoin y cómo debe interactuar esa privacidad con las responsabilidades y los controles operativos del emisor.

El punto de partida: un token confidencial para Stellar

En OpenZeppelin, hemos desarrollado un token confidencial open-source para Stellar: un conjunto de módulos de contrato componibles, interfaces estandarizadas alineadas con ERC-7984 y una implementación de ejemplo, todo disponible públicamente en el repositorio.

El diseño usa el libro mayor públicamente verificable de la red de Stellar como capa de liquidación y construye la confidencialidad encima. Los saldos y los montos de transferencia se almacenan onchain como compromisos criptográficos y no como números legibles, y cada cambio de estado se verifica mediante una prueba de conocimiento cero.

Este artículo toma ese trabajo como punto de partida y acota la discusión a una clase de token: las stablecoins. Proporcionan un modelo útil para examinar qué información debe permanecer privada y qué controles debe habilitar la arquitectura del token.

Definir el espectro: anonimato y confidencialidad

Antes de avanzar, es importante separar dos formas distintas de privacidad: anonimato y confidencialidad.

Anonimato oculta quién está transaccionando, de modo que el grafo de transacciones no pueda reconstruirse. Mientras que confidencialidad oculta qué se está transaccionando: los montos que se mueven entre las partes y los saldos que mantienen, mientras que las direcciones participantes permanecen públicas.

El token confidencial para Stellar sigue el segundo modelo. Un observador puede ver que la cuenta A transfirió tokens a la cuenta B, pero no cuánto se movió entre ellas.

El caso de las identidades visibles

A primera vista, la confidencialidad sin anonimato podría parecer una medida a medias, pero en realidad estos dos modelos no necesariamente compiten: los sistemas que preservan el anonimato atienden casos de uso legítimos en los que el propio grafo de transacciones es sensible. Sin embargo, una gran parte de la actividad con stablecoins podría no requerir ocultar la relación entre las partes.

Considera ejemplos en los que las corporaciones mueven fondos entre sus propias filiales, o escenarios donde el empleo es conocido pero la remuneración es confidencial. En ambos casos, la existencia de la relación con la contraparte es pública, y el monto transaccionado es el dato sensible.

Mantener visibles las direcciones de los participantes en el límite del contrato inteligente, especialmente en una stablecoin controlada por el emisor, es una elección arquitectónica por sus beneficios prácticos en materia de cumplimiento. Cuando las direcciones permanecen públicas, el contrato del token puede aplicar controles a una cuenta específica. Un operador autorizado puede restringir una dirección identificada, mientras que los sistemas externos de políticas pueden determinar si una cuenta está autorizada a participar.

Los sistemas anónimos también pueden admitir restricciones de cuenta y otras acciones administrativas, pero hacerlo generalmente requiere una maquinaria criptográfica más compleja porque el contrato no puede identificar directamente a los participantes. Mantener visibles las direcciones hace que estos controles sean más simples de implementar, examinar y explicar.

La confidencialidad, por supuesto, tiene sus límites. No es una respuesta definitiva a la privacidad en la blockchain, más bien debe considerarse como un punto pragmático en el espectro: uno diseñado para actividad de pagos en la que los valores financieros son sensibles y se requieren controles auditables a nivel de cuenta.

Requisitos de diseño para una stablecoin controlada por el emisor

Un emisor de stablecoin es responsable de operar el activo, mantener sus políticas y responder a eventos que involucren cuentas particulares. La confidencialidad, por lo tanto, debe coexistir con una serie de capacidades operativas.

Primero, el emisor necesita una forma de restringir cuentas identificadas. Una restricción debe aplicarse de manera consistente en las operaciones del token, incluyendo enviar, recibir, depositar y retirar.

Segundo, el token necesita hacer cumplir las decisiones tomadas por sistemas externos de políticas y verificación. La verificación de identidad, la elegibilidad de cuentas, la evaluación de riesgos y procesos similares ocurren fuera del contrato del token. El sistema onchain debería poder consumir sus resultados sin duplicar esos procesos en su propia lógica.

Tercero, las partes autorizadas pueden necesitar visibilidad acotada sobre transferencias y saldos. Un sistema confidencial debe proporcionar esa visibilidad sin crear una llave universal capaz de exponer la actividad financiera de cada usuario.

Cuarto, la arquitectura necesita un mecanismo controlado para intervenir que evite que un solo rol operativo pueda tanto obtener información financiera privada como ejercer control irrestricto sobre los activos.

Por último, un titular de cuenta puede necesitar revelar a un tercero un hecho específico, como el monto de un pago entrante o si un saldo cae por debajo de un umbral, sin revelar su historial completo.

Estas capacidades no hacen que una implementación de stablecoin cumpla por sí mismas. Definen los componentes técnicos que un emisor puede combinar con una gobernanza, seguridad, procesos legales y operativos adecuados.

De requisitos a mecanismos

El token confidencial de Stellar aborda cada uno de estos requisitos mediante un mecanismo separado. Juntos, forman una arquitectura en la que la privacidad no es ni absoluta ni controlada por un solo actor privilegiado.

Restricciones de cuenta

Los roles administrativos autorizados pueden congelar o descongelar una cuenta específica. El contrato almacena una marca persistente para esa dirección y la verifica durante cada operación relevante. Una vez restringida, la cuenta no puede enviar, recibir, depositar ni retirar fondos.

El sistema puede actuar sobre una cuenta identificada preservando la confidencialidad de la información financiera asociada.

Aplicación de políticas externas

La verificación de identidad y la evaluación de participantes son procesos offchain. Pueden involucrar sistemas internos del emisor, proveedores de servicios especializados o un registro compartido usado en múltiples activos. El contrato del token no necesita reproducir estos sistemas. Su función es hacer cumplir su resultado.

El token confidencial proporciona un gancho de políticas conectable para este propósito. Antes de que se asiente un cambio de estado, el token llama a un método de verificación externo para determinar si las cuentas participantes están autorizadas para esa operación.

Un emisor que opere varias stablecoins en diferentes jurisdicciones puede apuntar múltiples contratos de token a un registro de políticas común. La política puede evolucionar sin requerir rediseñar la capa confidencial principal.

Esta separación también crea un límite claro de responsabilidad: los sistemas externos deciden si una operación está permitida, mientras que el contrato del token asegura que la decisión se haga cumplir de forma consistente onchain.

Visibilidad de auditoría acotada

Para respaldar procesos de cumplimiento como reportes y monitoreo retrospectivo de transacciones sin recurrir a una “llave maestra de visualización” global, el token implementa un modelo acotado de doble auditor.

Cada transacción confidencial proporciona datos de reporte cifrados a través de dos canales asimétricos. El canal de entrada le da al auditor del destinatario visibilidad sobre la transferencia entrante. El canal de salida le da al auditor del remitente visibilidad sobre el monto transferido y el saldo restante del remitente después de la transacción.

Intervención autorizada de activos

Cuando se requiere por motivos legales y de cumplimiento, intervenir en los activos de una cuenta específica con fines de recuperación es especialmente difícil cuando los saldos son confidenciales. Un operador administrativo puede identificar la cuenta pero no puede ver el monto que posee. La parte con visibilidad de auditoría puede determinar ese monto, pero no debería poder mover los activos.

El token confidencial resuelve esta tensión mediante la coordinación entre roles administrativos y de auditoría separados.

Esta separación está diseñada para asegurar un sistema claro de frenos y contrapesos: el operador administrativo no puede iniciar una recuperación por sí solo porque carece de la visibilidad criptográfica para generar una prueba válida, y la entidad de auditoría no puede mover ni congelar fondos de manera independiente.

Probar bajo demanda: divulgación selectiva dirigida

Los controles administrativos y la visibilidad del auditor aplican en situaciones en las que una parte autorizada necesita visibilidad por motivos de cumplimiento o debe actuar sobre una cuenta en particular. Otras solicitudes son mucho más acotadas.

El equipo de revisión de un banco podría pedirle a un cliente que demuestre que un pago entrante específico coincide con una factura. Un proveedor de incorporación podría solicitar evidencia de que el saldo corporativo está por encima de un umbral particular. En cada caso, el titular de la cuenta necesita revelar un hecho aislado a una contraparte, no exponer todo un historial de transacciones.

El mecanismo de auditoría es demasiado amplio para este fin. Lo que se necesita en su lugar es un mecanismo mediante el cual el titular de la cuenta pueda probar una sola afirmación en una forma que el destinatario pueda verificar contra el libro mayor público.

El diseño del token confidencial brinda soporte a esto mediante una capa de divulgación selectiva que opera completamente fuera de la cadena:

1. La contraparte solicitante le proporciona al titular de la cuenta una referencia única, de una sola vez, vinculada a la consulta.
2. El titular genera una prueba de conocimiento cero que establece que la afirmación solicitada es verdadera y está vinculada a un compromiso en cadena existente.
3. El titular envía la prueba a la contraparte fuera de la cadena.
4. La contraparte verifica la prueba contra el registro en cadena y conoce únicamente el hecho solicitado.

Debido a que la divulgación selectiva ocurre completamente fuera de la cadena, no agrega sobrecarga a los contratos del token y no deja registro en cadena del evento de divulgación individual.

Rutas de despliegue

El diseño del token confidencial brinda soporte a dos modelos de despliegue.

Para una stablecoin existente, el token confidencial puede operar como un contenedor adyacente alrededor del activo base. Esto permite que las formas transparente y confidencial del activo coexistan, dejando sin cambios la infraestructura de tokens existente del emisor.

En este modelo, el activo base sigue siendo la única fuente de verdad para el suministro total. Los usuarios depositan el activo transparente en el contrato confidencial, transaccionan usando saldos y montos confidenciales, y luego retiran nuevamente al token transparente. Por lo tanto, el pool confidencial puede introducirse como un modo adicional de uso en lugar de como un reemplazo del activo existente.

Este enfoque crea una ruta de adopción gradual. Un emisor puede poner la confidencialidad a disposición para las actividades que la necesiten, mientras preserva la liquidación transparente para otros usuarios e integraciones.

Para una nueva stablecoin, el contrato confidencial puede, en cambio, funcionar como el propio activo. En este modelo independiente, el límite de emisión también es confidencial: los montos de acuñación y quema permanecen ocultos, y el contrato mantiene el suministro total como un compromiso criptográfico actualizado con cada operación de emisión.

Aunque el suministro total no es legible públicamente, el emisor puede probar afirmaciones al respecto cuando sea necesario. Por ejemplo, puede atestiguar una cifra exacta o demostrar que el suministro satisface una condición definida generando una prueba que cualquiera puede verificar contra el compromiso en cadena.

Los modelos de contenedor y de independiente ofrecen diferentes compensaciones. El contenedor prioriza la compatibilidad y la adopción gradual. El modelo independiente extiende la confidencialidad a la emisión y al suministro, pero requiere que el sistema de stablecoin más amplio esté diseñado en torno a compromisos criptográficos desde el principio.

Confidencialidad sin ceder el control

Las stablecoins confidenciales no tienen que elegir entre exponer cada valor financiero y eliminar la capacidad del emisor de operar el activo.

Manteniendo visibles las direcciones de cuenta mientras se ocultan los saldos y los montos de transferencia, la arquitectura preserva los controles a nivel de cuenta, la aplicación de políticas externas, la visibilidad de auditoría acotada, la intervención de activos autorizada y la divulgación dirigida. Las pruebas de conocimiento cero permiten que el contrato y las contrapartes designadas verifiquen lo que necesitan sin hacer públicos los datos financieros subyacentes.

Este enfoque no intenta resolver todas las formas de privacidad en Blockchain. Su objetivo es más acotado y práctico: proteger la información financiera que requiere la actividad de pagos ordinaria, al tiempo que conserva los mecanismos necesarios para gestionar activos controlados por el emisor.

El siguiente artículo de esta serie examinará cómo se implementan estos mecanismos en el token confidencial de OpenZeppelin para Stellar, incluidos los módulos del contrato, los flujos de pruebas, los canales de auditoría y la separación de roles que hacen que la arquitectura funcione.

Las opiniones, declaraciones y evaluaciones de este artículo son únicamente de su(s) autor(es) individual(es) y no constituyen asesoría legal, ni necesariamente reflejan las opiniones de OpenZeppelin. Dada la naturaleza inherente de la información en este artículo, su contenido se basa en la información recopilada y entendida en el momento de su creación. Está sujeto a cambio. La información se proporciona “tal cual”, sin representación ni garantía, y el autor no acepta responsabilidad por ninguna acción o falta de acción tomada en respuesta a la información contenida o referenciada en este artículo.