Por Canuto  

Midnight presentó un adelanto de su hoja de ruta y un giro clave para su comunidad: la red “prepro” ya se puede usar para migrar DAPs, pero exige cambios técnicos profundos. En una sesión tipo fireside hang, el equipo detalló sus tres pilares (privacidad programable, smart compliance e interoperabilidad), mientras que la experiencia de desarrolladores se refuerza con una documentación reestructurada, una matriz de compatibilidad y nuevas librerías para manejar tokens shielded, unshielded y el nuevo concepto de “dust”.
***

  • Midnight enmarca su estrategia en tres pilares: privacidad programable, smart compliance y abstracción de cadena para mejorar adopción e interoperabilidad.
  • Prepro ya es usable para migraciones: el ejemplo “counter DAP” está actualizado y se prepara una versión prepro de Bboard DAP, aún pendiente por un bug con Lace wallet.
  • Mejoras para developers: nueva documentación en versión “canary”, matriz de compatibilidad por release estable y cambios de APIs y librerías para wallets, despliegues y manejo de dust.

 

Midnight compartió nuevas señales sobre el rumbo del ecosistema y, sobre todo, sobre el trabajo necesario para que los desarrolladores migren sus aplicaciones a “prepro”, un entorno que ya está disponible para pruebas. La actualización se presentó en un encuentro semanal tipo fireside hang, en el que participaron Carmel (directora de producto) y Nick Stanford (product manager enfocado en developer experience) junto al anfitrión de la sesión.

El objetivo de la llamada fue doble. Primero, dar un adelanto del mapa de producto y de los pilares estratégicos que guían el diseño de Midnight. Segundo, aterrizar cambios técnicos concretos para quienes ya construyen DAPs, incluyendo una guía de migración y un ejemplo funcional (counter DAP) que sirve como referencia para llevar proyectos desde entornos previos hacia prepro.

La conversación también destacó que el equipo planea publicar, en futuras actualizaciones, un roadmap completo con un alcance mejor delimitado y con líneas de tiempo específicas. Aun así, indicaron que preferían no “quedarse detrás de escenas” y ofrecer un vistazo temprano de lo que está en camino, debido a la expectativa dentro de la comunidad.

Los tres pilares: privacidad programable, smart compliance e interoperabilidad

Carmel explicó que Midnight está enfocando su propuesta en tres pilares. El primero es la tecnología habilitadora de privacidad, pero con un matiz: no se trata de “ocultar transacciones” de forma genérica, sino de ofrecer privacidad programable. En ese enfoque, los sistemas pueden equilibrar estados públicos y privados según la lógica de cada caso de uso.

Ese punto apunta a aplicaciones donde una parte de la información debe permanecer privada, mientras otra necesita mantenerse visible para operar en un entorno abierto. Desde la óptica del equipo, la oportunidad está en diseñar DAPs que administren de forma explícita esa tensión entre lo público y lo privado, en lugar de esconderlo todo por defecto.

El segundo pilar es el “smart compliance”, que Carmel describió como una puerta hacia la adopción en el mundo real. En su lectura, instituciones, gobiernos, salud y empresas operan dentro de marcos regulatorios concretos, por lo que Midnight busca habilitar “divulgaciones programables” que permitan revelar lo necesario, cuando sea necesario, y proteger el resto.

La directora de producto citó como ejemplos de necesidades regulatorias el KYC, AML y condiciones como inversionistas acreditados. La idea es que un caso de uso pueda apoyarse en reglas de divulgación bajo demanda, en lugar de obligar a exponer información sensible de manera permanente o total. Para el equipo, la precisión del nicho y del problema a resolver define cuánto valor se puede extraer de este componente.

El tercer pilar es la interoperabilidad, enmarcada como “abstracción de cadena” e “intents”. Carmel sostuvo que el reto de adopción aparece cuando se le pide al usuario migrar a otro ecosistema, lo que resulta difícil incluso para usuarios leales a una cadena. La intención, según la explicación, es que la experiencia se perciba como un servicio “por detrás”, donde la persona no tenga que pensar en qué red está.

Funciones en camino: block time, contract-to-contract, estándares de tokens y eventos

En cuanto a características, Carmel adelantó que “muy pronto” se agregará una variable de contexto asociada al tiempo de bloque (block time context variable), la cual llegará en una próxima versión. La sesión no proporcionó una fecha exacta, pero sí la describió como una adición inminente dentro de los releases cercanos.

Luego enumeró “grandes” elementos en el roadmap que llegarán por entregas iterativas. Entre ellos mencionó “contract-to-contract”, una capacidad esperada por desarrolladores que trabajan en casos DeFi, ya que permitiría que un smart contract invoque directamente la lógica de otro contrato.

También mencionó estándares de tokens, incluyendo modalidades “shielded” y “unshielded”, así como el rol del metadata asociado. En paralelo, citó “events” como otra pieza relevante, con la aclaración de que algunos eventos podrían ser privados y otros públicos, dependiendo del caso de uso. El equipo indicó que compartirá más información sobre tiempos en el futuro cercano.

Developer experience: nueva documentación, versión canary y matriz de compatibilidad

Nick Stanford centró su participación en un objetivo: reducir fricción al construir DAPs mientras el ecosistema avanza hacia versiones estables y hacia un eventual lanzamiento de mainnet. Reconoció la complejidad típica de construir en ecosistemas jóvenes, donde las dependencias pueden estar en alpha o beta y mantener un estado funcional se vuelve difícil.

El primer gran cambio anunciado fue una reestructuración completa de la documentación, con una organización que prioriza “aprender haciendo”. Según Nick, el propósito es que el desarrollador llegue más rápido al código, entienda keywords del lenguaje Compact y de las herramientas de soporte, y aprenda a pensar en DAPs de privacidad con enfoque racional, incluyendo errores comunes y superficies que hay que endurecer.

En la transición, el equipo mantendrá la documentación existente como una versión “00” para no romper flujos de quienes ya la usan. En paralelo, publicaron una versión “canary” bajo el mismo sitio, con aviso de que está “under construction”. En esa canary, buena parte del contenido aparecerá como “coming soon” o incompleto, ya que se está portando información y validando precisión de forma manual.

Nick señaló una ventana tentativa para convertir canary en la fuente única de verdad, con la fecha de “Friday, February 20th”, descrita como tentativa. Tras ese hito, planean abrir bucles de retroalimentación para recopilar comentarios sobre cómo se usa el sitio, qué falta y qué se puede mejorar. También enfatizó que la documentación es open source y que la comunidad puede contribuir.

Además, presentó una mejora orientada a un dolor recurrente: saber qué versiones de herramientas funcionan juntas. Dentro de la sección de release notes, el equipo incorporó un apartado de “latest stable release” y una página de compatibilidad con una “compatibility matrix”. La intención es que el desarrollador no tenga que inspeccionar package.json de ejemplos para deducir combinaciones estables, sino acudir a una tabla mantenida al día.

De cara al futuro, Nick mencionó mejoras a la CLI, posibles herramientas basadas en IA para ayudar a construir DAPs y consumir documentación, y un esfuerzo por “empaquetar” tooling repetitivo. El ejemplo que dio fue automatizar tareas comunes como despliegues que, de otro modo, requieren repetir cientos de líneas de código entre proyectos.

Prepro ya es usable: migración de DAPs y el nuevo rol del “dust”

Tras la intervención del equipo de producto, la sesión pasó a un segmento práctico para hablar de migración de DAPs a prepro. El anfitrión informó que prepro ya es usable y que los desarrolladores pueden comenzar a migrar sus aplicaciones, aunque advirtió que hay que hacer muchos cambios porque se introdujeron nuevas funcionalidades y, por lo mismo, nuevas consideraciones.

El enfoque práctico se apoyó en un ejemplo: el “counter DAP” ya está listo para prepro y se publicó, según se indicó, “a little bit earlier this week”. También comentó que estaba listo para publicar una versión prepro de “Bboard DAP”, creado por Serge de Brick Towers, pero que aún revisaba un problema: un bug con la Lace wallet, que dijo debería corregirse pronto.

En el flujo del counter DAP, el usuario crea una wallet y recibe un seed junto con tres direcciones distintas: una para tokens unshielded, otra para shielded y otra para dust. Luego, debe tomar la dirección unshielded para ir al faucet y solicitar tokens de prueba. El presentador habló de recibir “1.000” test “tNight” para desplegar e interactuar con el contrato, y subrayó que se debe usar el faucet de prepro, no el de testnet u otros previos.

La gran novedad, según el segmento, es que los tokens que entrega el faucet se reciben como “tAI”, y el usuario debe esperar a que ese saldo genere “dust”, que luego se usa para transacciones. En el counter DAP, este proceso se automatiza y el CLI muestra el saldo de dust. Sin embargo, en otras aplicaciones, como Bboard usando Lace wallet, el usuario debe enviar tAI a su wallet y esperar, además de realizar una transacción inicial para comenzar la producción de dust.

El presentador estimó que, en general, la recepción de tAI toma alrededor de dos minutos, y que luego, en el caso del counter DAP, la generación de dust es rápida. También destacó que existe una opción para monitorear el balance en dust y observar cómo se va generando con el tiempo, algo que describió como una funcionalidad esperada desde hace tiempo.

Guía de migración: breaking changes, compiler pre-release y nuevas APIs

La sesión resaltó que la migración a prepro no es “out of the box”. La guía de migración dentro del repositorio reúne pasos generales que aplican a distintas aplicaciones, no solo al counter DAP. Entre los puntos iniciales, se enfatizó la necesidad de usar versiones correctas de NodeJS, del compilador Compact, de librerías y del proof server, ya que todo debe estar alineado para evitar fallos típicos de incompatibilidad.

Uno de los pasos críticos es actualizar la versión del lenguaje en el contrato, porque, de lo contrario, la compilación falla. El documento también orienta sobre la instalación del compilador, que en prepro se maneja como una versión pre-release. En la sesión, ante una pregunta directa, se sugirió que puede convenir desinstalar la versión anterior, aunque también se mencionó que existe un procedimiento para instalar el nuevo compilador y decirle a la herramienta Compact que lo use.

En el lado de JavaScript, el presentador detalló que se deben instalar versiones distintas de librerías de Midnight JS y librerías nuevas, debido a que ahora se manejan nuevos tipos de tokens. La guía describe APIs actualizadas para despliegue de contratos, manejo de “witnesses” y cambios de tipos, además de ajustes para consultar estado, donde se indicó que ahora se usa un método “ledger” y no “state”.

Otro cambio señalado es el manejo de seeds. Según el segmento, antes se requerían librerías de terceros, pero ahora esa funcionalidad queda integrada en Midnight JS. La guía incluye ejemplos de inicialización de wallets shielded y unshielded, configuraciones que siguen siendo necesarias (como network ID y URL del proving server), y secciones específicas para el manejo de dust.

También se advirtió sobre el formateo de direcciones: con prepro existe un prefijo que indica la red, y hay tres formatos asociados a los tres tipos de dirección (shielded, unshielded y dust). La guía dedica un apartado a registrar direcciones para generar dust y al hecho de que, si no hay dust, no se pueden crear transacciones, un punto que el presentador dijo haber sufrido en pruebas al olvidar ese requisito.

Infraestructura: proof server en Docker, indexer, nodo y variables de red

La guía incluye un apartado para ejecutar componentes con Docker, con énfasis en el proof server. El presentador recomendó correr el proof server en la computadora local para pruebas, aunque mencionó la existencia de alternativas públicas, incluyendo una asociada a Lace. Para indexer y nodo, dijo que él utiliza servicios públicos, pero recalcó que el proof server local suele ser preferible en escenarios de testing.

El documento también lista URLs relevantes para prepro, incluyendo el endpoint del proof server local, el faucet, el indexer y el RPC node. La sesión remarcó que estas direcciones son indispensables para que una aplicación conecte contra infraestructura funcional, y que un error común es apuntar a endpoints equivocados, especialmente si se viene de testnet u otros entornos anteriores.

Como cierre, la sesión reiteró un pedido de feedback a los “early adopters” de prepro. Aunque el presentador afirmó que probó el flujo y funciona, invitó a reportar bugs, bloqueos o dudas en Discord o en el foro, con la promesa de que el equipo busca mejorar la experiencia para desarrolladores con más documentación, tutoriales y DAPs de ejemplo.

La discusión también dejó una nota de producto: para el público final, una interfaz que evite enviar el tipo de token equivocado (shielded vs unshielded) se considera “crítica”. Ese comentario subraya un foco práctico del ecosistema: el nuevo modelo de activos y direcciones aumenta potencia, pero también eleva el riesgo de errores si la UX no guía de forma explícita.

Imagen original de DiarioBitcoin, creada con inteligencia artificial, de uso libre, licenciada bajo Dominio Público.

Este artículo fue escrito por un redactor de contenido de IA y revisado por un editor humano para garantizar calidad y precisión.


ADVERTENCIA: DiarioBitcoin ofrece contenido informativo y educativo sobre diversos temas, incluyendo criptomonedas, IA, tecnología y regulaciones. No brindamos asesoramiento financiero. Las inversiones en criptoactivos son de alto riesgo y pueden no ser adecuadas para todos. Investigue, consulte a un experto y verifique la legislación aplicable antes de invertir. Podría perder todo su capital.

Suscríbete a nuestro boletín

Artículos Relacionados