De la demanda a la arquitectura: una práctica de diseño de protocolo de moneda estable privada

El valor técnico de los sistemas complejos no solo se refleja en la implementación del código, sino también en cómo transformar las necesidades comerciales en soluciones técnicas claras, lógicas y viables.

Escrito por: Keegan

El año pasado, un amigo me pidió que lo ayudara a diseñar un protocolo de moneda estable privada descentralizada y a redactar un libro blanco técnico completo.

La concepción de este proyecto era bastante compleja, ya que no solo involucraba la emisión y gestión de monedas estables, sino que también deseaba soportar múltiples activos colaterales, transacciones privadas, interoperabilidad entre cadenas y funciones de gobernanza del protocolo.

Me tomó aproximadamente un mes completar de manera independiente el diseño de la arquitectura técnica del protocolo y la redacción del libro blanco.

Después de entregar el libro blanco, también participé en el desarrollo temprano del proyecto, ayudando a implementar un demo simple de transferencia privada, validando preliminarmente algunas de las soluciones técnicas.

Sin embargo, el proyecto no continuó avanzando según lo planeado inicialmente y finalmente se detuvo. No estoy seguro de las razones específicas.

Aunque este protocolo no se implementó completamente, al mirar hacia atrás, desde la recopilación inicial de requisitos, el diseño del mecanismo del protocolo, hasta la planificación de la arquitectura general y la validación de funciones parciales, esta colaboración aún tiene muchos aspectos que vale la pena revisar.

Este artículo comparte algunas ideas de diseño arquitectónico y decisiones técnicas basadas en la práctica de ese momento.

Requisitos del proyecto y concepción general

El objetivo inicial de este proyecto era construir un protocolo de moneda estable basado en mecanismos descentralizados que soportara múltiples activos colaterales, transacciones privadas e interoperabilidad entre cadenas.

En términos simples, no se trataba de emitir un token ERC-20 ordinario, sino de establecer un sistema financiero de moneda estable relativamente completo.

Según los requisitos de ese momento, el protocolo debía tener varias capacidades centrales:

• Emisión de moneda estable y colateralización múltiple. Los usuarios pueden colateralizar activos como BTC, ETH u otros activos mapeados en la cadena, y acuñar monedas estables vinculadas al dólar según la tasa de colateralización correspondiente. El sistema necesita gestionar posiciones colaterales, deudas, intereses y riesgos de liquidación.
• Transacciones privadas. Además de las transferencias de monedas estables ordinarias, se introduce un mecanismo de transacciones privadas basado en pruebas de conocimiento cero, permitiendo a los usuarios elegir entre transferencias públicas o privadas según sea necesario, manteniendo al mismo tiempo la capacidad de verificación de autorización necesaria.
• Interoperabilidad entre cadenas. Soporta la circulación de monedas estables entre diferentes blockchains y maneja problemas como el suministro de activos, la sincronización de estados y la recuperación de excepciones durante el proceso de interoperabilidad.
• Gobernanza y expansión del protocolo. A través de mecanismos de gobernanza, se gestionan los parámetros del protocolo y se reserva espacio para la futura integración de más activos colaterales, redes blockchain y monedas estables ancladas a diferentes monedas fiduciarias.

Vistos de manera aislada, estas funciones no son desconocidas en el ámbito de Web3, y hay muchos proyectos maduros que pueden servir de referencia. Pero cuando se combinan en un mismo protocolo, la complejidad del sistema aumenta notablemente.

Por ejemplo, ¿cómo se separa la gestión de activos colaterales de la emisión de monedas estables? ¿Cómo se conecta la transacción privada con el sistema de activos públicos? ¿Cómo se garantiza la consistencia del suministro de activos durante el proceso de transferencia entre cadenas? ¿Cómo se dividen las responsabilidades entre los diferentes módulos?

Por lo tanto, el desafío central del diseño de la arquitectura técnica no es solo cómo implementar una función específica, sino cómo organizar estos requisitos interrelacionados y complejos en una solución técnica integral que tenga responsabilidades claras, lógica completa y sea viable y escalable.

De la demanda a la arquitectura: cómo descomponer todo el protocolo

Después de aclarar los requisitos, finalmente opté por una arquitectura modular y jerárquica, dividiendo todo el sistema en cinco niveles:

• Capa de múltiples bóvedas colaterales: responsable de gestionar diferentes tipos de activos colaterales, incluyendo funciones de depósito y retiro de activos, obtención de precios, cálculo de tasas de colateralización y liquidación, proporcionando la base de activos para la emisión de monedas estables.
• Motor de moneda estable: responsable de la acuñación y quema de monedas estables, cálculo de intereses de deuda y gestión del suministro, y mediante mecanismos como tarifas de estabilidad, ayuda a mantener el anclaje del precio de la moneda estable.
• Capa de privacidad: basada en tecnología de pruebas de conocimiento cero, permite a los usuarios convertir entre monedas estables públicas y activos privados, logrando transferencias privadas y proporcionando la capacidad de divulgación selectiva de información y verificación de autorización.
• Capa de interoperabilidad entre cadenas: responsable de la circulación de monedas estables entre diferentes blockchains, verificación de mensajes entre cadenas y sincronización de estados, centrándose en resolver la consistencia del suministro de activos y la recuperación de excepciones durante el proceso de interoperabilidad.
• Capa de SDK y retransmisión: proporciona un método de acceso unificado para billeteras, DApps y otras aplicaciones externas, y asume funciones de servicio fuera de la cadena como retransmisión de transacciones y reenvío de mensajes.

A través de esta división modular, el protocolo forma límites de responsabilidad relativamente claros. La gestión de colaterales, la emisión de monedas estables, las transacciones privadas y la interoperabilidad entre cadenas pueden colaborar entre sí, manteniendo la independencia tanto como sea posible, proporcionando una base para el desarrollo por fases y la expansión de funciones.

Sin embargo, la división modular es solo el primer paso del diseño arquitectónico. Lo que realmente necesita ser ponderado son las relaciones entre los módulos y los posibles conflictos que pueden surgir de diferentes objetivos técnicos.

Algunas decisiones clave en el diseño arquitectónico

En el proceso de diseño de este protocolo, descubrí que lo que realmente necesitaba considerar no era solo si una tecnología podía implementarse de forma independiente, sino cómo permitir que diferentes mecanismos técnicos colaboren razonablemente dentro de un mismo sistema.

Entre ellos, hay tres problemas de diseño arquitectónico que son bastante representativos.

1. ¿Cómo desacoplar la gestión de activos colaterales de la emisión de monedas estables?

Para un protocolo de moneda estable que soporta múltiples activos colaterales, la volatilidad de precios, la liquidez y las características de riesgo de los diferentes activos colaterales son distintas, por lo que se necesitan diferentes tasas de colateralización, umbrales de liquidación y estrategias de control de riesgos.

Si se centralizan la gestión de activos colaterales, el control de riesgos y la emisión de monedas estables en un mismo módulo, no solo aumentará la complejidad del sistema, sino que también dificultará la futura expansión de más activos colaterales y variedades de monedas estables.

Por lo tanto, dividí todo el sistema en bóvedas colaterales (Collateral Vault) y un motor de moneda estable (Stablecoin Engine) relativamente independientes.

La bóveda colateral es responsable de la gestión de activos, obtención de precios, evaluación de riesgos y liquidación, mientras que el motor de moneda estable se encarga de la acuñación, quema, cálculo de intereses de deuda y gestión del suministro de monedas estables.

Los dos módulos colaboran a través de interfaces y restricciones de estado claras, manteniendo la independencia de responsabilidades y asegurando la relación entre los activos colaterales, las deudas y la emisión de monedas estables.

Este diseño no solo reduce el acoplamiento entre módulos, sino que también permite que el sistema ajuste de forma independiente los parámetros de riesgo para diferentes activos y proporciona espacio para el futuro soporte de más activos colaterales y monedas estables ancladas a diferentes monedas fiduciarias.

2. ¿Cómo equilibrar la protección de la privacidad con la verificabilidad?

Las transacciones privadas son uno de los diseños más característicos de este protocolo.

En una blockchain pública, los registros de transacciones y los flujos de fondos generalmente pueden ser consultados por cualquier persona. Pero para escenarios como pagos empresariales y liquidaciones institucionales, la información de transacción completamente pública puede no ser adecuada.

Por lo tanto, adopté un enfoque de diseño similar al de Zcash, utilizando pruebas de conocimiento cero para proteger la privacidad de las transacciones, al mismo tiempo que introduje un mecanismo de Clave de Visualización (Viewing Key) para lograr divulgación selectiva de privacidad (Selective Disclosure).

Los usuarios pueden optar por realizar transferencias públicas o privadas. En el modo privado, la información de la transacción está protegida, pero los usuarios aún pueden proporcionar la Clave de Visualización a terceros designados para ver la información de transacción dentro de un rango específico, y combinarla con pruebas criptográficas relevantes para realizar la verificación necesaria, sin tener que hacerla pública a toda la red.

Sobre esta base, también planifiqué una capa de acceso de verificación independiente (Verifiable Disclosure Layer), diferenciando la autorización para ver la información de transacción y las capacidades de verificación de autenticidad, reservando interfaces para futuras auditorías, cumplimiento y escenarios de aplicaciones institucionales.

El objetivo de este diseño no es solo ocultar la información de la transacción, sino permitir que las transacciones privadas, al proteger la información del usuario, aún tengan la necesaria verificabilidad.

3. ¿Cómo garantizar la consistencia de activos y estados en la interoperabilidad entre cadenas?

La interoperabilidad entre cadenas es otro problema que necesita ser considerado en este protocolo.

Para la transferencia de activos entre cadenas ordinarias, lo que los usuarios ven puede ser simplemente el envío de monedas estables de una cadena a otra, pero en el fondo se necesita manejar la transmisión de mensajes y los cambios de estado de activos entre diferentes blockchains.

Tomando como ejemplo el modo de Burn-and-Mint (quema y acuñación), en el fondo involucra la quema de activos en la cadena de origen, la transmisión de mensajes entre cadenas y la reacumulación de activos en la cadena de destino.

Por ejemplo, cuando un usuario transfiere monedas estables de la cadena A a la cadena B, si la cadena de origen ya ha completado la quema, pero la cadena de destino no ha logrado acuñar los activos correspondientes debido a una anomalía de red o un fallo en la ejecución del mensaje, ¿cómo debería manejar el sistema esto?

Por el contrario, si el mensaje entre cadenas se ejecuta repetidamente, ¿cómo evitar que las monedas estables sean acuñadas de nuevo?

Por lo tanto, en el diseño de la capa de interoperabilidad, consideré principalmente la consistencia del suministro de activos, la unicidad de los mensajes entre cadenas y los mecanismos de recuperación de estado en situaciones excepcionales.

Al mismo tiempo, traté de mantener los activos colaterales y las posiciones de deuda en sus respectivas cadenas, dejando que la capa de interoperabilidad se encargue de la circulación de monedas estables entre cadenas y la coordinación de estados relacionados.

Esto puede reducir la dependencia directa entre diferentes blockchains y disminuir el impacto de las anomalías en la comunicación entre cadenas sobre la lógica de gestión de colaterales y deudas en el fondo.

Para un protocolo financiero que involucra activos reales, el diseño de interoperabilidad no solo debe considerar si los activos pueden transferirse sin problemas, sino que lo más importante es cómo evitar la emisión duplicada de activos o el desequilibrio del estado del libro mayor en situaciones excepcionales.

Estos tres problemas, aunque involucran diferentes campos técnicos, comparten un pensamiento de diseño común: a través de límites de módulos claros, restricciones de estado definidas y un adecuado aislamiento de riesgos, satisfacer las necesidades comerciales mientras se controla la complejidad del sistema tanto como sea posible y se reserva espacio para futuras expansiones.

Desde el diseño arquitectónico hasta la validación preliminar

Después de completar el libro blanco técnico, el proyecto entró en la fase de desarrollo temprano.

Según los requisitos del cliente, la primera fase se centró principalmente en validar las funciones centrales de la capa de privacidad y proporcionar demostraciones y pruebas a través de un Bot de Telegram.

Para ello, implementé un demo simple de transferencia privada basado en zk-Mixer y lo integré en el Bot de Telegram, permitiendo a los usuarios experimentar la función de transferencia privada a través del Bot.

Este demo validó algunos de los mecanismos centrales de la transferencia privada, pero aún estaba lejos de la implementación completa del protocolo planificado en el libro blanco. Las funciones de colateralización múltiple, emisión de monedas estables e interoperabilidad entre cadenas aún no habían completado la implementación y validación correspondientes.

Más tarde, el proyecto no continuó avanzando, y no estoy seguro de las razones específicas.

Al reflexionar sobre esta colaboración, desde completar de manera independiente la arquitectura técnica del protocolo y el libro blanco, hasta implementar el demo de transferencia privada, tuve la oportunidad de experimentar el proceso desde el diseño de la solución técnica hasta la validación de funciones parciales.

Esto también me hizo darme cuenta de que el valor técnico de los sistemas complejos no solo se refleja en la implementación del código, sino también en cómo transformar las necesidades comerciales en soluciones técnicas claras, lógicas y viables.

Por supuesto, el diseño arquitectónico es solo el punto de partida. Especialmente para sistemas que involucran activos financieros y protección de la privacidad, la verdadera implementación del producto aún necesita pasar por un desarrollo de ingeniería completo, auditoría de seguridad y verificación de funcionamiento real.

Aunque este proyecto no llegó a ese punto, el diseño arquitectónico y la práctica técnica siguen siendo una experiencia que vale la pena resumir.