Arquitectura de DApps en Midnight
Construir una DApp en Midnight es fundamentalmente diferente a construir en Cardano o Ethereum. El modelo de privacidad de Midnight requiere un nuevo marco mental: el estado en cadena se divide en compartimentos públicos y protegidos, las pruebas de cómputo se generan en el lado del cliente, y el lenguaje Compact se encarga de la definición de los circuitos ZK. Este artículo explica cómo encaja todo.
El modelo de programación de Midnight
Cada DApp de Midnight consta de dos componentes: lógica en cadena escrita en Compact (el lenguaje de definición de circuitos ZK de Midnight) y lógica off-chain escrita en TypeScript. Esto refleja la arquitectura de Cardano (Aiken en cadena, MeshJS off-chain), pero con la adición crucial de que el código Compact en cadena genera ZK proofs durante la ejecución.
La capa off-chain de TypeScript utiliza el Midnight SDK para interactuar con la red, gestionar el estado privado, generar pruebas y enviar transacciones. El SDK es la biblioteca principal orientada al desarrollador y maneja la complejidad criptográfica detrás de una API limpia.
Compact: definiendo circuitos ZK
Compact es un lenguaje tipado diseñado específicamente para escribir smart contracts de Midnight. Tiene cierto parecido con TypeScript, pero con construcciones específicas del dominio para circuitos ZK. Un contrato Compact define tanto un estado de ledger público (visible para todos) como un estado de testigo privado (conocido únicamente por el usuario).
Cuando un usuario interactúa con un contrato de Midnight, proporciona un testigo (witness): datos privados que satisfacen las restricciones del contrato. El compilador de Compact genera el circuito de ZK proof, y el Midnight SDK genera una prueba de que el testigo satisface las restricciones, sin revelar el testigo en sí. La prueba se adjunta a la transacción y es verificada por los nodos de Midnight.
Estado protegido vs. estado público
Cada contrato de Midnight tiene dos dominios de estado. El estado público se escribe en el blockchain de Midnight y es visible para todos los participantes de la red, equivalente a las variables de almacenamiento en un contrato de Ethereum. El estado protegido (shielded) existe únicamente en el wallet local de Midnight del usuario; nunca se revela a la red.
La magia de la privacidad ocurre en la frontera: una transacción de Midnight puede actualizar el estado público basándose en cómputos realizados sobre el estado protegido, con un ZK proof que garantiza que el cómputo se realizó correctamente. Por ejemplo, una DApp puede actualizar un mapeo público de 'usuarios verificados' basándose en la credencial KYC privada de un usuario, sin revelar el contenido de la credencial.
El modelo de testigo (witness)
Cuando un usuario llama a un contrato de Midnight, proporciona un testigo (witness), los inputs privados al cómputo. El SDK genera un ZK proof a partir de este testigo y el circuito del contrato. La prueba se envía a la red junto con cualquier actualización del estado público.
Gestionar el estado del testigo es uno de los desafíos únicos del desarrollo en Midnight. El Midnight SDK proporciona un almacén de estado local cifrado (llamado witness store) que persiste los datos protegidos entre sesiones. Los desarrolladores de DApps deben diseñar con cuidado su estado de testigo: qué debe ser privado, qué puede ser público y cómo se autorizan las transiciones de estado.
Interacción con la mainchain de Cardano
Midnight no está aislado de Cardano: las dos cadenas están diseñadas para interoperar. El valor puede moverse entre Cardano y Midnight a través de mecanismos de puente. En la fase de mainnet Kukolu, las características de interoperabilidad se están habilitando progresivamente a medida que son auditadas y probadas en condiciones reales.
Una característica clave de interoperabilidad es la capacidad de demostrar condiciones del lado de Cardano en los ZK proofs de Midnight, por ejemplo, demostrar la propiedad de un NFT de Cardano como credencial en una DApp de Midnight. Esta componibilidad entre cadenas abre casos de uso poderosos que aprovechan ambos ecosistemas.
Flujo de desarrollo con el Midnight SDK
Configurar un entorno de desarrollo para Midnight implica instalar el Midnight SDK mediante npm, instalar el compilador de Compact y conectarse a la devnet o testnet de Midnight. La documentación oficial de Midnight en docs.midnight.network ofrece guías de inicio rápido y un ejemplo de DApp de contador como implementación de referencia.
Un flujo de trabajo de desarrollo típico: escribir el contrato Compact → compilar con `compactc` → generar bindings de TypeScript → escribir la lógica off-chain de TypeScript usando el SDK → desplegar en testnet → probar con el wallet Midnight Lace. El wallet Midnight Lace es un fork de Lace con soporte para el estado protegido de Midnight y la generación de pruebas.
Conclusiones clave
- Las DApps de Midnight tienen dos capas: Compact (circuitos ZK en cadena) y TypeScript con el Midnight SDK (lógica off-chain y generación de pruebas).
- Compact define tanto el estado de ledger público como el estado de testigo privado; los ZK proofs permiten actualizar el estado público basándose en cómputos privados.
- El modelo de testigo requiere un diseño cuidadoso de qué es protegido vs. público; el Midnight SDK gestiona el almacén de testigos cifrado local.
- Midnight y Cardano son interoperables: el valor y las credenciales pueden fluir entre cadenas a través de mecanismos de puente.
- El wallet Midnight Lace es el wallet de referencia para probar DApps de Midnight en devnet y testnet.