🇪🇸 Reporte técnico semanal de IOHK sobre Cardano: 11 de Octubre de 2019

:es: Traducción al español de IOHK Cardano Weekly technical reports - 11 / Oct

Publicado en el blog de IOHK.

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

Wallet

Esta semana el equipo terminó la integración de los endpoints disponibles de la API v2, lo que permitirá el soporte de las características de Shelley. Se sigue trabajando en las modificaciones de las pruebas automatizadas end-to-end para comprobar que la integración de la API funciona según lo previsto. También se ha empezado a trabajar en nuevos instaladores de escritorio para la próxima versión de Daedalus compatible con la red de prueba incentivada.

En el ámbito de las tareas de mantenimiento programado, el equipo terminó de trabajar en la reorganización de las historias del Storybook, y en la mejora de la suite de pruebas automatizadas para que se adapten mejor a la estructura de la interfaz de usuario de Daedalus.

Plataforma

Las vistas de PostgreSQL se optimizaron aún más esta semana, basándose en algunos problemas de rendimiento que se descubrieron durante las pruebas. Las vistas mejoradas han sido enviadas al repositorio principal de Cardano Explorer, haciendo que las interfaces estén disponibles para todos los usuarios de la base de datos. La configuración de Hasura también se incorpora ahora en el repositorio del código, completando el setup del stack sin intervención.

La primera versión de pre-producción de Cardano GraphQL también fue lanzada esta semana, para que el equipo de Cardano Explorer la usara como target para la red principal de Byron.

Se continuó trabajando en la integración de Jörmungandr para la versión de la red de prueba incentivada, creándo una imagen Docker e incluyéndola en el stack del proyecto.

Por último, se ha creado una infraestructura de pruebas para testear el funcionamiento de Cardano GraphQL frente a una fuente de datos proveniente de la red principal de Byron totalmente sincronizada, donde se determinarán las estrategias de escalado para las implementaciones alojadas. También se determinó con el equipo de Plutus un scope para el nodo cliente de publicación en la cadena.

Cardano Explorer

Esta semana el equipo finalizó la implementación de las páginas de direcciones y de bloques, y comenzó a trabajar en las páginas de transacciones y de stake pools. El equipo también ha implementado el soporte de temas, lo cual es un paso importante ya que existirán múltiples instancias de Cardano Explorer (una para cada red), y cada una tendrá un tema diferente para distinguirla de las demás.

BACK-END DE LA WALLET

El equipo está trabajando ahora en tres frentes simultáneamente: Soporte para la wallet de Byron, rastreo de stake pools y seguimiento de cadenas en una red descentralizada en la que las bifurcaciones pueden producirse de forma arbitraria. Los dos últimos están terminando y están recibiendo la mayor parte de la atención del equipo en forma de pruebas.

El equipo también ha rediseñado la capa de redes para permitir que los nodos puedan cambiar a diferentes cadenas según lo consideren necesario. El cambio fue manejado de tal manera que la lógica pueda ser implementada para Jörmungandr, dejando la interfaz general lo suficientemente flexible para permitir la implementación usando una interfaz de red diferente, como el cardano-node de Haskell.

Por último, el equipo también está recopilando datos sobre los stake pools y devolviendo una lista de los stake pools existentes con el número de bloques que están produciendo. En la siguiente iteración, se introducirá una métrica de rendimiento para permitir a los clientes listar y ordenar los stake pools según su rendimiento.

NETWORKING

Esta semana el equipo ha dedicado tiempo a la planificación del próximo componente P2P, y ya ha comenzado a implementar el primer aspecto, que es la simulación gráfica. Pronto el equipo podrá desarrollar y evaluar directivas locales para los nodos que determinarán a qué nodos se deberá o no conectar. Esta es la primera vez que se crean políticas de este tipo para un sistema de prueba de participación que opera a nivel mundial, y el equipo está siendo especialmente cuidadoso en el proceso de evaluación de las políticas.

En otras noticias, luego de incluir la conexión del protocolo chain-sync, reducir el consumo de memoria del nodo, y actualizar las constantes del protocolo block-fetch, el equipo logró una velocidad de sincronización de descarga de 6,97 Mb/s para el nodo Shelley. Como resultado, el equipo pudo sincronizar la actual cadena de bloques en sólo 50 minutos.

Por último, el equipo está finalizando la implementación de un STM monad puro (memoria de transacciones del software), que incluye el último operador orElse que faltaba, junto con una prueba que traduce la especificación formal del STM. El equipo pudo validar su implementación con la ejecución de GHC, y no ha encontrado ni un solo error en millones de iteraciones de pruebas de propiedades QuickCheck (es decir, cada prueba de propiedad se ejecutó en millones de transacciones STM generadas al azar).

DEVOPS

Esta semana el equipo de DevOps actualizó los scripts Snappy y Nix para la v0.5.6, además de crear un nuevo paquete Chocolatey para la v0.5.6. Se ha creado un nuevo clúster de nodos para que el equipo pueda realizar algunas pruebas de rendimiento de la red de prueba, y se ha añadido una nueva herramienta al repositorio jormungandr-nix para analizar la producción de bloques, tanto en ciclos (epochs) individuales como en toda la cadena.

SHELLEY

Utilizando la infraestructura desarrollada para detectar pérdidas de espacio, esta semana el equipo pudo reparar todas las pérdidas de espacio del nodo, lo que resultó en un uso de memoria más bajo y predecible.

GOGUEN

Esta semana el equipo de Plutus ha añadido una nueva consulta UtxoAt, para permitir que los contratos consulten un subconjunto de UTxO a través del nodo cliente. Esto cambia la forma en que se implementa la WalletAPI en el emulador, ya que las billeteras actualmente realizan un seguimiento del set completo de UTxO, no sólo del subconjunto de salidas no utilizadas en las direcciones en las que están vinculadas.

El equipo también eliminó el tipo Sealed, y agregó un data type genérico para su uso en contratos. Además, simplificó la forma en que se representan las salidas de los scripts para que sean más consistentes con la forma en que se manejan en PlutusTx. También se hicieron cambios para facilitar la escritura de los analizadores.

El equipo de Marlowe actualizó el tutorial de Marlowe para incluir una nueva sección sobre el análisis estático. También se están preparando para la nueva versión del curso de Udemy que se publicará en breve.

ANUNCIOS

IOHK está buscando gente talentosa para trabajar con ellos. Por favor, accede a la página IOHK Careers para más detalles.

1 Like