La semana pasada se lanzó una nueva versión de la testnet de Pollen, la versión 0.5.5. Estas actualizaciones son muy importantes ya que las nuevas implementaciones que acompañaran al tan esperado Coordicide están siendo testeadas en esta red de pruebas. Con esta nueva actualización que nos preapara para la eventual llegada de Nectar, se pueden empezar a usar algunos modulos cláve del Coordicide: el FPC o Fast Probabilistic Concensus y el autopeering.
Recordemos que con el Coordicide, el Coo será removido de la red y de esta manera IOTA se convertirá en una red completamente descentralizada.
Con la ayuda de la testnet de Pollen, se podrán ajustar algunos parámetros de rendimiento y seguridad de la red.
La lista completa de cambios incluye
- Integrar Mana con el FPC
- Integrar Mana con el Autopeering
- Añadir varias optimizaciones de FPC
- Añadir la API de diagnóstico dRNG
- Simplificar el uso de memoria del dashboard y alinearlo con Grafana
- Añadir un gráfico para MPS almacenados, solidificadores, planificadores y reservadores
- Actualización a la última versión de hive.go
Repasemos muy (muy) brevemente acerca del Consenso
Los algoritmos de consenso distribuido permiten que los sistemas en red se pongan de acuerdo sobre un estado o una opinión requeridos en situaciones en las que la toma de decisiones descentralizada es difícil o incluso imposible.
La informática distribuida es intrínsecamente poco fiable. Alcanzar el consenso permite que un sistema distribuido funcione como una sola entidad. La importancia de este desafío radica en su omnipresencia en la que la tolerancia a fallas es uno de los aspectos más fundamentales.
Los sistemas distribuidos son complejos de explicar y por lo general la información que existe acerca de los mismos está (demasiado) distribuida, pero podemos encarar ese tema en futuros posts. Sigamos con Mana.
Mana en FPC
El protocolo Fast Probabilistic Consensus (FPC) se utiliza como parte del mecanismo de consenso en la solución Coordicide. Hasta ahora este módulo de consenso ha tratado por igual las opiniones de cada nodo, sin embargo esto no ofrece ninguna protección contra los ataques Sybil, donde los adversarios dirigen cientos o incluso miles de nodos, para interrumpir el consenso. En cambio, con la integración de Mana, los nodos formarán su quórum seleccionando los nodos que serán consultados proporcionalmente a su Mana.
Esta integración es sumamente importante ya que permitirá probar el funcionamiento de maná como sistema de protección y reputación contra ataques Sybil en una red de pruebas.
Mana en Autopeering
En el protocolo IOTA, un nodo (o peer) es una máquina que almacena la información sobre el Tangle, la estructura de datos subyacente de IOTA. Para que la red funcione eficazmente y los nodos se mantengan al día sobre el estado del ledger, los nodos intercambian información, como mensajes y transacciones, entre sí. Cada nodo establece un canal de comunicación con un pequeño subconjunto de nodos (es decir, vecinos) a través de un proceso denominado peering. Este proceso debe ser resistente a los ataques de Eclipse: si todos los vecinos de un nodo están controlados por un atacante, éste tendrá un control total sobre la visión del nodo en el Tangle.
Peering en la Actualidad
En la actualidad, se utiliza un proceso de peering o conexión manual para que los nodos se registren mutuamente como vecinos. Sin embargo, el peering manual puede ser objeto de ataques para afectar a la topología de la red. Para evitar estos ataques, y para simplificar el proceso de configuración de los nuevos nodos, se introdujo un mecanismo que permite a los nodos elegir a sus vecinos automáticamente. El proceso de elección de los vecinos por parte de los nodos sin la intervención manual del operador del nodo se denomina autopeering.
Por qué el Autopeering y Mana
Para prevenir/limitar los ataques Sybil, el autopeering hace uso del Mana: se pueden crear nodos arbitrarios sin Mana, pero hay un límite en cuanto al número de nodos que se pueden crear con una determinada cantidad de Mana. Específicamente, se vuelve prohibitivo ya que costaría muchos recursos para un atacante el producir muchos nodos con alto nivel de Mana.
En su núcleo, el módulo de autopeering utiliza un proceso de selección llamado Mana rank, que selecciona un subconjunto de todos los nodos conocidos basándose en su similitud de Mana. Esto significa que los nodos con un Mana similar tendrán más probabilidades de convertirse en vecinos.
Al introducir Mana en el módulo de Autopeering, podremos aprovechar la red de prueba Pollen para investigar qué parámetros son seguros y estables para la faucet de la red, y cuáles son sus efectos en la red.
Con la distribución del Mana de consenso se espera que se arrojen resultados interesantes que sirvan para la investigación respecto de Coordicide
Por ejemplo, la figura siguiente muestra el cambio en la topología de la red al disminuir el parámetro R, que determina la separación en el espacio de la red de los nodos de alto Maná con respecto a los de bajo Maná.
En el último IOTA Talk Dominik Schiener dijo:
«El objetivo de Coordicide (hablando de las redes de prueba) es que no tengan que esperar hasta final de año para participar, pueden unirse a la red Nectar y se los incentivará por unirse a esta red.»
Como últimos hitos antes de Nectar, se introdicirán las Snapshots y Timestamp voting. Una vez terminados, Nectar estará listo para su lanzamiento al público y será una red incentivada.
Fuentes:
Pollen Testnet v0.5.5 Release Notes
Coordicide update — Autopeering: Part 1
IOTA Talks
