Traducción al español de IOHK Cardano Weekly Development Report - 21 / Feb 2020
Publicado en el blog del roadmap de Cardano, el 21 de Febrero de 2020.
Este informe es producido por IOHK cada semana para mantener a la comunidad informada sobre el progreso realizado en el desarrollo de Cardano. El alcance de este informe cubre el trabajo que se está llevando a cabo en todos los equipos y proporciona información y transparencia al proyecto.
HECHOS DESTACADOS DE LA SEMANA
DAEDALUS
Billetera
Esta semana el equipo ha trabajado en la preparación de la próxima versión de Daedalus para la Red de Prueba Incentivada (ITN), Daedalus 2.1.0-ITN1, que incluye una mejor representación de las preferencias de delegación pendientes, un nuevo conjunto de herramientas para identificar características experimentales, y una mejor visualización del estado de la delegación al restaurar una billetera. El equipo también implementó algunos pequeños cambios en la copia, y mejoras generales en la interfaz de usuario.
Plataforma de Aplicaciones
Esta semana el equipo ha trabajado en la implementación del nuevo launcher de Cardano, una librería de orquestación para aplicaciones Node.js basadas en el nodo completo, usando Daedalus como banco de pruebas. El objetivo inicial es loguear los dominios de salida, pero el objetivo final de la librería es eliminar el comportamiento agnóstico de las aplicaciones de Daedalus, haciéndolo accesible para otras aplicaciones de nodo completo, incluida la propia Plataforma de Aplicaciones.
Explorador de Cardano
El equipo de control de calidad completó una primera revisión de la aplicación esta semana, y el equipo de desarrollo ha estado trabajando en conjunto para resolver los problemas que se descubrieron.
BACKEND DE LA BILLETERA
Esta semana el equipo ha continuado mejorando e integrando correcciones de errores para asegurar la liberación de una versión lo más estable posible. También se ha seguido trabajando en la integración del nuevo nodo basado en Haskell, cerrando la brecha en los endpoints de la API que faltaban en la billetera integrada. Ahora se trata de realizar pruebas y análisis de integración en profundidad para asegurar que la integración sea realmente un éxito.
NETWORKING
La semana pasada el equipo de networking continuó su refactorización de la capa mux, y el protocolo del handshake se mejoró para soportar los parámetros de negociación requeridos para la versión P2P. Este cambio introduce una negociación de handshake que anuncia a un par (peer) como iniciador (o cliente) solamente.
También se completó esta semana una refactorización sustancial de la biblioteca de red asíncrona de Windows, que eliminó casi todos los wrappers en C, asegurando que todo esté ahora en Haskell. También se siguió trabajando en el gestor de conexiones, y el equipo está más confiado ahora que han tenido la oportunidad de probar los nuevos cambios en una rama local de cardano-nodo.
DEVOPS
Esta semana el equipo de DevOps se ha estado preparando para el hard-fork de Ouroboros BFT. El equipo también ha estado finalizando la transición de haskell.nix a la última versión en todos los repositorios, y ha comenzado a probar la nueva versión 1.6 de Cardano. También se está trabajando en un constructor en la Amazon Machine Imagine (AMI) que se puede utilizar para simular más de 10K conexiones en Daedalus, para ayudar a identificar cualquier problema de desempeño en la sincronización a gran escala, antes de que el nuevo Daedalus y el backend de la billetera estén listos.
SHELLEY
Luego de mucho trabajo, el equipo consiguó trabajar esta semana en una nueva generación de propuestas de actualización. Ahora que los generadores están produciendo cadenas que abarcan múltiples epochs, el equipo se está encontrando con una nueva capa de fallos subyacentes que deben ser resueltos, ya que los límites de los epochs imponen exigencias mucho mayores a los generadores para producir datos válidos de la cadena. Estos fallos son muy probablemente el resultado de que los generadores necesiten algunos ajustes. Existe una posibilidad externa de que las pruebas revelen fallos en la especificación, aunque el equipo considera que esto es poco probable.
El equipo ha terminado con el pull request que permitió introducir los metadatos de las transacciones en el ledger de Shelley, que incluyó varias discusiones sobre cómo se integrará con Plutus en el futuro.
Por otra parte, se añadió una nueva comprobación a la especificación formal y al modelo ejecutable, para asegurar que el número de bloque en el cuerpo del bloque se incremente siempre en uno. Anteriormente, los cálculos utilizaban el anterior hash de cabecera y slot incremental para lograr lo mismo, pero se hizo evidente que esto debe ser explícito en la capa de consenso.
El equipo también ha efectuado muchos progresos para poder garantizar que el CDDL de Shelley (formato de cable) es correcto (es decir, que lo que la herramienta Ruby genera a partir de nuestro archivo CDDL pueda ser deserializado por el código de Haskell). Sin embargo, todavía hay un buen trabajo por hacer. Hasta ahora, la mayoría de las inconsistencias provienen del uso de un simulacro de criptografía para fines de prueba. El equipo también ha estado eliminando las restricciones canónicas que fueron impuestas en cardano-base.
GOGUEN
Esta semana el equipo añadió un campo de número de slot al estado de la cadena, para que sea más fácil consultar el slot actual. También actualizaron la implementación del oráculo, para verificar las firmas criptográficas de los mensajes. Además, continuaron trabajando en las políticas de gasto para las monedas, y comenzaron un borrador de un glosario completo de conceptos de Plutus.
El equipo de Marlowe comenzó a trabajar en la exhibición de nuevas advertencias en Marlowe Playground, para advertir a los usuarios sobre los pagos negativos y los depósitos negativos, así como sobre el uso de asignaciones que no se han inicializado. Además, investigaron la posibilidad de tener un tutorial interactivo en Marlowe Playground.