El nuevo ARK Core v2 ha estado funcionando de forma estable en la red pública de ARK durante más de dos semanas, y el desarrollo no se está ralentizando en un futuro próximo. Continuaremos mejorando e implementando nuevas funciones con las aportaciones de la comunidad y de un público más amplio.
Ya se ha comenzado a trabajar en varias características nuevas e interesantes para el núcleo ARK. Con la v2 terminada, el equipo de desarrollo lanzará un programa de lanzamiento mucho más agresivo. En este post, nos gustaría esbozar algunos de los próximos cambios y un esquema general para los próximos meses.
Estas actualizaciones utilizarán versiones estándar que se adhieren al modelo de Semver:
- MAJOR: 2.0.0 era la versión inicial no compatible con versiones anteriores en Mainnet.
- MINOR: 2.x.0 añadirá nuevas funcionalidades y cubrirá cambios más grandes y nuevas características que introducen impactos de gama alta (2.1.0, 2.2.0, ....).
- PATCH: 2.0.x serán correcciones de errores compatibles con versiones anteriores, pequeñas mejoras y pequeñas características adicionales (2.0.1, 2.0.11, ....).
Aunque siguiendo técnicamente el modelo de Semver, nuestros lanzamientos "Minor" van a ser mucho más que menores. En este post cubriremos características más grandes y cambios en las próximas actualizaciones de Core (por favor tenga en cuenta que el orden de las integraciones puede cambiar).
ARK core 2.1.0: Migración completa de JavaScript a TypeScript
El equipo de desarrollo de Core ya ha comenzado a trabajar en la migración completa de Core v2 de JavaScript a TypeScript. TS permite la comprobación estática del tipo junto con las últimas características de ECMAScript.
TypeScript es también un lenguaje mucho más estricto que JavaScript y le permite detectar errores que de otro modo podrían pasar desapercibidos. Es más cómodo de usar y permite una depuración de errores más rápida. Para los desarrolladores, muy poco cambiará ya que la sintaxis es casi la misma que la de JavaScript (Typescript es un superconjunto de JavaScript). TypeScript tiene perfecto sentido para proyectos en crecimiento que necesitan escalar y tener una variedad de desarrolladores contribuyentes.
Ya estamos en las etapas finales de pasar de JS a TS. Una vez que se complete la prueba de la nueva implementación de TS en la Red de Desarrolladores de ARK, el equipo de ARK lanzará el código base y los Delegados actualizarán la Red Pública de ARK.
ARK core 2.2.0: Mejoras de infraestructura para AIP 11 y AIP 18
La actualización de ARK Core 2.2.0 traerá consigo varias actualizaciones de infraestructura que son necesarias para el desarrollo de AIPs 11 y 18. Esto incluye aumentar el VendorField a 256 bytes para abrir más casos de uso y posibilidades de aprovechar al máximo nuestro enfoque SmartBridge.
También vamos a cambiar el ID del bloque. El nuevo identificador de bloque se almacenará como un identificador de 256 hexadecimal por defecto (igual que ya hacemos con los identificadores de transacción). Esto es para evitar que los posibles identificadores de bloque choquen con la altura del bloque de ARK.
En el lado de la comunicación P2P, comenzaremos a aprovechar el poder de la serialización, reduciendo el ancho de banda de la red y haciendo que nuestra cadena sea aún más eficiente. Los nodos ya no se comunicarán a través del formato de carga útil JSON legible por el ser humano, sino que activaremos los datos serializados y enviaremos búferes serializados de transacciones y bloques a través de la red P2P.
ARK core 2.3.0: Nuevas clases de movimiento (AIP 11 y AIP 18)
AIP 11 - Actualización del protocolo de transacción
Uno de los mayores, más lentos e interesantes cambios para los usuarios finales (y empresas) es la integración de nuevos tipos de transacciones que proporcionarán casos de uso y herramientas adicionales para el ecosistema ARK.
Habrá un total de 4 nuevos tipos de transacciones, uno de los cuales se está actualizando para soportar una mayor entrada de datos.
Los nuevos tipos de TX serán:
- Timelock - Este es básicamente un tipo de contrato inteligente simple que restringe el gasto de una cantidad de ARK en la dirección especificada hasta que se alcance un tiempo futuro predefinido o una altura de bloque. Esto es útil para contratos basados en hash y canales de pago. Los Timelocks también se pueden utilizar para bloquear ARK por cualquier razón (evitar gastos, seguridad,...).
- Multipagos - Para disminuir la carga útil en la cadena de bloqueo y contabilizar un gran volumen de transacciones, puede combinar pagos (por lotes) en transacciones multipago. Esto también reducirá las tarifas por pago. (es decir: el envío de 16 tx en un pago por lotes de una sola vez sólo produce una tasa de tx en lugar de 16 tasas diferentes). Esto será muy útil para los delegados que realizan pagos diarios a numerosos discursos de votación. Al principio limitaremos esto a 16 salidas posibles (16 pagos por transacción) y aumentaremos en función de las necesidades con pruebas adicionales.
- Dimisión del delegado - Esto le da a un delegado la opción de renunciar a su posición como delegado al hacer imposible que la comunidad vote por el delegado dimitido.
- IPFS - Similar a nuestro SmartBridge Vendorfield, con reglas específicas sobre lo que se puede poner en el campo IPFS (es decir: hash del archivo). El caso de uso para esto es para proporcionar una manera fácil de marcar la hora y opcionalmente encriptar y verificar los archivos a través de la interfaz que vamos a construir. Esta implementación del tipo IPFS tx no permitirá almacenar datos en la cadena de bloques, ya que para ello es necesario ejecutar nodos IPFS especiales, pero proporcionará el tipo tx para verificar la integridad de los datos de los archivos a través de la cadena de bloques.
Para saber más sobre AIP-11:https://github.com/ArkEcosystem/AIPs/blob/master/AIPS/aip-11.md
AIP 18 - Protocolo para múltiples firmas
ARK Core v2 ya soporta multi-firmas, pero la implementación actual es insuficiente. Como tal, hemos decidido implementar un protocolo mucho más potente y útil. Es probable que implementemos "Simple Schnorr Multi-Signatures" como se describe en este articulo https://eprint.iacr.org/2018/068
Protocolo del legado:
- Regla 1 - Registro multisignos: ownerPublickey (de donde se deriva la dirección), lista de claves públicas (N), lifetime (de 1 a 72 horas), minimo (0 < M < N+1), lista de N firmas.
- Regla 2 - Aceptación de la transacción: se debe incluir en la transacción un mínimo de M firmas diferentes correspondientes a diferentes claves públicas de confirmación.
- Regla 3 - si no hay suficientes firmas presentes, la transacción se almacena en el fondo común de transacciones durante horas de por vida hasta que se envíen suficientes firmas a través de la API (esta regla ya se ha eliminado de la implementación actual).
Nuevo protocolo:
- La vida útil se elimina del protocolo junto con la regla 3 anterior.
- La dirección se deriva de una combinación de confirmación de claves públicas, eliminando la necesidad de la base de claves públicas del propietario58_check(version + ripemd160(sha256(concat(pk1, ..., pkn)))).
- La versión propuesta es 0x05 para que coincida con la versión P2SH de Bitcoin (la dirección empieza por 3).
Para saber más sobre AIP-18 https://github.com/ArkEcosystem/AIPs/blob/master/AIPS/aip-18.md
Núcleo ARK 2.4.0: Core CLI y Core app a través de yarn global
Core se convertirá en un módulo npm que puede ser instalado e interactuado globalmente. Por ejemplo, podrá llamar a ark relay:mainnet después de instalar el núcleo a través de yarn global add @arkecosystem/core.
La configuración y las opciones se gestionarán de la misma manera a través de ark configure, que mostrará una interfaz para su gestión. Este será esencialmente un enfoque alternativo de Ark Core Commander para todos los que quieran tenerlo todo como parte del paquete Core para gestionar sus nodos con unos cuantos comandos simples (por ejemplo, ark update, ark relay:restart, ark forger:start, ark relay:monitor,...).
Núcleo ARK 2.5.0: A medio camino de la v3 - Dejando caer todo el soporte de APIs y RPCs (v1)
EOL (End of Life) para la API de la v1 y el antiguo RPC llegará a la mitad de nuestro ciclo de desarrollo de la v2. Esto probablemente será a mediados de 2019, lo que dará a todos los desarrolladores que aún confían en la API v1 tiempo suficiente para migrar a la API v2. Anunciaremos una fecha exacta de cuándo terminará el soporte para la v1 y el RPC una vez que estemos más cerca de finalizar la versión 2.3.0.
Si todavía está utilizando la antigua RPC o v1 API, por favor, eche un vistazo a nuestra documentación para la nueva API v2 y JSON-RPC:
- API v2 docs: https://docs.ark.io/api/public/v2/
- JSON-RPC docs: https://docs.ark.io/api/json-rpc/
Deshacerse del código de API heredado también limpiará aún más nuestra base de código y nos ayudará a cumplir con las últimas tendencias y estándares de API.
Núcleo ARK 2.6.0: Reescribir la capa P2P para utilizar diferentes tecnologías con el fin de mejorar el rendimiento y la fiabilidad.
P2P, o capa Peer to Peer, es donde ocurre la comunicación entre los nodos ARK. Es el nivel de comunicación para que los nodos interactúen entre sí - pasando datos de un lado a otro, llegando a conclusiones basadas en un conjunto predefinido de reglas, .... (p.e. nodo falsificador 1: "Hey, quiero incluir este bloque en la cadena", nodo falsificador 2: "OK, todo parece estar bien, tienes mi bendición").
Con las llamadas a la API sólo hay un problema: cada solicitud de API requiere que se abra una nueva conexión, y cada solicitud añade tiempo adicional.
Hay algunas opciones aquí y vamos a hacer una extensa investigación para proporcionar la mejor mejora general y el aumento del rendimiento sin poner en peligro la seguridad.
Actualmente estamos investigando el cambio de hacer P2P vía API a P2P vía Websockets. Como tal, primero vamos a hacer el POC del P2P vía Websockets y ver si es la solución más viable para mejorar la capa P2P. Haremos pruebas y comparaciones exhaustivas (todos los pros y contras) y si resulta ser la mejor solución que la implementación actual, la pasaremos a producción.
La ventaja de los Websockets sobre las solicitudes de API es que puede abrir una conexión persistente con otro nodo. Ahora, sólo tiene que enviar los datos a su antojo sin necesidad de abrir una nueva conexión para cada solicitud que realice. Esto no sólo reduce el ruido exterior, sino que también proporciona una transferencia de datos mucho más rápida entre los nodos.
Esta es sólo una de las ideas que están flotando actualmente, y nos sumergiremos más profundamente en esto una vez que estemos más cerca de este ciclo de desarrollo de la v2.
ARK Core 2.7.0: Implementar la descarga de bloques paralelos
Uno de los cuellos de botella de la capa actual de P2P sobre API también es el bloqueo de la descarga cuando se sincroniza el nodo desde la red.
Actualmente descargamos bloques en paquetes de 400, uno tras otro que es dos o tres veces más rápido que la v1, pero todavía toma mucho tiempo para sincronizar desde el bloque 0 hasta la altura actual (esto puede variar dependiendo de muchos factores - velocidad de conexión, hardware, otros pares de los que estás descargando). Actualmente, la sincronización desde cero tarda entre 8 y 15 horas.
Este proceso puede mejorarse mediante la implementación de "descargas paralelas". Las conexiones se pueden abrir con varios nodos en lugar de uno solo, y grandes trozos de bloques diferentes se pueden descargar simultáneamente desde diferentes nodos. El nodo receptor los "pega" en el orden apropiado, como cuando se descarga un archivo vía torrent donde se conecta a "semillas" y se descargan diferentes trozos de datos del mismo archivo final.
La implementación de descargas en paralelo proporcionará otro aumento en el rendimiento y reducirá el tiempo de sincronización en varias horas.
La descarga de bloques paralelos se hará muy probablemente a través de streams, ya que son una de las características más potentes del Node.JS.
ARK Core 2.8.0: Preconfiguraciones de configuración, recarga en caliente y actualizaciones más sencillas
Vamos a proporcionar más opciones preestablecidas al iniciar su nodo Core para cosas como intercambio, falsificación, retransmisión de API, retransmisión mínima (puramente una retransmisión, sin API pública o cualquier otro punto final de aparición pública) para proporcionar configuraciones de configuración cero más rápidas que le ayudarán exponencialmente a ponerse en marcha dependiendo de su caso de uso y de las especificaciones de sus necesidades.
Con esta versión también implementaremos la "recarga en caliente". Cuando se modifica la configuración, los plugins que se ven afectados por los cambios se recargan en tiempo de ejecución y no necesitan el proceso Core para reiniciar.
ARK Core 2.9.0: Implementar una API completamente pública compatible con JSON
El JSON-API se basará en nuestra ya mejorada API v2, pero se ampliará para ser 100% compatible con las especificaciones de la API de JSON.
Al seguir las convenciones compartidas de la API de JSON, podremos aumentar la productividad, aprovechar las herramientas generalizadas y centrarnos en proporcionar un formato estandarizado que pueda ser seguido fácilmente por cualquiera que desee implementar o interactuar con la cadena de bloques ARK.
JSON API es un formato que funciona con HTTP. Describe cómo los clientes deben solicitar o editar datos de un servidor, y cómo el servidor debe responder a solicitudes específicas. Uno de los principales objetivos de la API de JSON es optimizar las peticiones HTTP, tanto en términos del número de peticiones como del tamaño de los paquetes de datos intercambiados entre clientes y servidores; a veces eliminando por completo las peticiones de red.
ARK Core 3.0.0: Refactor del sistema de plugins
Al final del ciclo de actualización de la v2, se realizarán cambios y mejoras adicionales en el sistema de plugins actual.
Actualmente los plugins contienen un archivo index.js que simplemente exporta un objeto con información sobre el plugin y cómo registrarlo.
El sistema de plugins reacondicionados proporcionará soporte para la verificación de plugins y un desarrollo más racionalizado a través de interfaces proporcionadas que deben ser satisfechas por los plugins para garantizar las mismas implementaciones en todo el núcleo.
Espera, ¿dónde está ArkVM (AVM) en esto?
No te preocupes! ArkVM no forma parte del ciclo de desarrollo del marco básico y se desarrollará en paralelo como un proyecto independiente. Escribiremos más sobre este asunto una vez que tengamos las especificaciones finales y el plan completamente resuelto.
Epílogo
Esto resume nuestro plan para Core en 2019. Muchos de los principales planes de desarrollo se van a desarrollar en paralelo. Podrás seguir nuestro progreso a través de los proyectos GitHub aquí (hitos y tareas serán añadidos en los próximos días):
Tenga en cuenta que es posible que reorganicemos los objetivos intermedios. Algunas actualizaciones se pueden hacer antes que otras y, como tal, se pueden empujar cuando se hacen. Intentaremos seguir este diseño tanto como sea posible. Mantendremos a todos informados si decidimos tomar una ruta diferente en ciertas etapas del desarrollo.