Especificaciones en la Investigación – IOTA 2.0 Coordicide

1011

Este post pretende presentar brevemente las especificaciones de investigación que pusimos a disposición con el lanzamiento de la IOTA 2.0 DevNet (Nectar). Las especificaciones se pueden encontrar aquí. Su propósito es explicar cuidadosamente el estado actual del protocolo IOTA 2.0 a los desarrolladores, tanto internos como externos, que deseen construir o probar Nectar, a los académicos que quieran analizar, modelar y optimizar el protocolo y necesiten una descripción rigurosa de cada módulo, y a los miembros de la comunidad y a cualquiera que simplemente quiera aprender más sobre el protocolo.

Esperamos que este post sea una guía útil para las especificaciones de investigación de IOTA 2.0, y esperamos que te sumerjas en ellas para aprender todo lo que puedas sobre el funcionamiento de IOTA 2.0 DevNet. Sin embargo, antes de leer las especificaciones, nos gustaría explicar algunos puntos al lector.

¿Qué son las especificaciones en investigación?

Esta colección incluye especificaciones sobre cada componente experimental clave de Coordicide. Sin embargo, hay dos advertencias importantes con respecto a estos documentos.

En primer lugar, ninguno de los parámetros es definitivo. Aunque nuestros estudios previos dan ciertos rangos para cada uno de estos parámetros, el ajuste de cada parámetro a su valor óptimo requiere muchas pruebas e investigación. Por suerte, podemos llevar a cabo esta investigación mientras se desarrolla el software, ya que los parámetros que estamos afinando son muy fáciles de cambiar en el código. En estas especificaciones, cada parámetro se ajusta a una estimación educada.

En segundo lugar, en este documento se omiten varios componentes no experimentales del protocolo. Por ejemplo, se omite el snapshotting (el módulo que gestiona la poda de los mensajes antiguos en los perma-nodos) y una descripción del protocolo gossip. Ambos componentes son partes bien entendidas de la actual mainnet de Chrysalis, y por lo tanto pensamos que incluirlos no valía la pena retrasar la publicación de las especificaciones. En la tabla de contenidos del archivo readme, se puede ver que todavía faltan algunas de las especificaciones. Se añadirán a lo largo del verano.

Un último punto a tener en cuenta es que estas especificaciones no son estables ni están sujetas a un estricto sistema de versiones. Nectar es un prototipo de investigación. Como tal, se utilizará para realizar investigaciones y perfeccionar las especificaciones según sea necesario para optimizar el protocolo. A lo largo de los próximos meses recogeremos datos y realizaremos experimentos en la IOTA 2.0 DevNet. Hemos aprendido mucho sobre el protocolo simplemente construyéndolo, y la información obtenida de las pruebas en esta fase mejorará aún más el protocolo y las futuras implementaciones.

En concreto, vamos a

  • Optimizar los parámetros
  • Mejorar las implementaciones de software del protocolo junto con el desarrollo de los nodos Bee y Hornet.
  • Identificar y eliminar los posibles cuellos de botella en el rendimiento
  • Optimizar el rendimiento de cada módulo
  • Simplificar el protocolo eliminando cualquier elemento que se considere innecesario
  • A medida que vayamos introduciendo estas mejoras en el protocolo, estas especificaciones irán cambiando.

Cualquier protocolo que alcanza la adopción evoluciona y mejora continuamente, y el protocolo IOTA no será diferente. El Departamento de Investigación de la Fundación IOTA siempre se esforzará por hacer nuevos descubrimientos para perfeccionar el protocolo, y también mantendremos siempre algún tipo de especificaciones de investigación para seguir los cambios propuestos.

Documentación de Nectar vs Especificaciones de Investigación

El lector puede notar que el repositorio GoShimmer en GitHub contiene su propia documentación que describe el protocolo. ¿Cómo se relaciona esa documentación con estas especificaciones? ¿Cuál es la relación entre Nectar y estas especificaciones?

La documentación de Nectar describe cómo funciona el protocolo en la DevNet de IOTA 2.0, mientras que las especificaciones de investigación de IOTA 2.0 describen cómo debería ser el protocolo de IOTA 2.0. En teoría deberían ser lo mismo (y algún día lo serán), pero actualmente hay algunas diferencias.

La documentación de Nectar se desarrolló con dos propósitos. En primer lugar, para ayudar a nuestros ingenieros de investigación a saber cómo codificar ciertos módulos, ya que algunas partes del prototipo se escribieron antes que las especificaciones. En segundo lugar, la documentación ayuda a otros, tanto interna como externamente, a navegar por la base de código. Por ello, la documentación de Nectar no es completa, ya que sólo cubre las partes fundamentales del protocolo.

Además, como Nectar es un prototipo, se han tomado algunos atajos en la implementación. Por ejemplo, el comité dRNG es fijo, en lugar de rotar en función del maná consensuado. Esto simplifica la implementación al tiempo que nos permite llevar a cabo la investigación necesaria. Las especificaciones de la investigación indican cómo debe seleccionarse el comité.

Protocolo frente a especificaciones de implementación

Un protocolo es un acuerdo entre varios nodos sobre cómo intercambiar e interpretar datos. La implementación del protocolo es el software que realiza las operaciones reales dictadas por el protocolo. El protocolo es único y fijo, mientras que la implementación varía. Por ejemplo, el HTTP (HyperText Transfer Protocol) dicta cómo debe comunicarse el navegador con los servidores de Internet. Hay varios navegadores (Firefox, Chrome, Safari, etc.) que ejecutan este protocolo. Internamente, estos navegadores funcionan de manera muy diferente entre sí, con características y diseños distintos, pero todos se comunican con un servidor de la misma manera.

IOTA 2.0 es un protocolo estandarizado, y por lo tanto tendrá especificaciones especiales de protocolo que dictan cómo deben comportarse los nodos IOTA. La Fundación IOTA creará dos implementaciones de software de este protocolo: Bee y Hornet, escritas en rust y go respectivamente. Sin embargo, cada una de estas implementaciones tendrá especificaciones de implementación que describen exactamente cómo funciona el software. Utilizando las especificaciones del protocolo, cualquiera puede (y esperemos que finalmente lo haga) escribir sus propias implementaciones de software con sus propias especificaciones de implementación.

Estas especificaciones de investigación son una mezcla de las especificaciones del protocolo y de las especificaciones de implementación. ¿Por qué es así? Porque todas nuestras ideas deben probarse en código, tenemos que desarrollar el protocolo y una implementación del mismo al mismo tiempo. Cualquier idea que no pueda ser implementada de manera eficiente tiene que ser rechazada. Ahora que tenemos un prototipo que funciona, podemos empezar a separar el protocolo de estas especificaciones mientras el departamento de ingeniería trabaja en la implementación.

Esperamos que este post haya sido informativo, y que incluso los lectores no tan técnicos se tomen el tiempo de hojear las especificaciones de la investigación, o incluso de leerlas en detalle si les apetece. Naturalmente, nos sentimos muy orgullosos de haber desarrollado el protocolo hasta este punto, y es maravilloso que una comunidad bien informada se interese por nuestro trabajo.


Post original: IOTA 2.0 Research Specifications

Comentarios

comentarios

pasarela de pagos con criptomonedas