IOTA 2.0 es un protocolo complejo con varios módulos, pero su idea central es bastante simple. Este artículo explica resumidamente el mecanismo de consenso de IOTA 2.0 y el mantenimiento de la Base de Datos distribuida.
Los datos y las transacciones estarán contenidas en objetos llamados mensajes. Cada mensaje nuevo deberá conectarse a mínimo otros 2 mensajes que ya estaban en la red y podrá conectarse hasta con 8 mensajes. De esta forma el conjunto de todos los mensajes conforma una red llamada maraña (o Tangle en inglés) que es un DAG siempre en crecimiento (DAG son las siglas de Grafo Acíclico Direccional).
Actualmente, la red Chrysalis, está gobernada por un coordinador que es un tipo de nodo centralizado operado por la Fundación IOTA. El coordinador decide cuales transaccioes y datos se incluyen en la base de datos, es decir la lista de saldos de todos los usuarios.
Para que IOTA sea una red totalmente descentralizada debe eliminarse el coordinador y cuando esto suceda Chrysalis se convertirá en IOTA 2.0.
Al proyecto de retirar el coordinador se le llama coordicidio y el protocolo que sustituirá al coordinador ya está diseñado
Cuando ya no haya coordinador los mensajes entrantes deben tener una historia consistente, sin conflictos. Cuando aparecen conflictos, la red Tangle se divide en dos diferentes ramas. El protocolo deberá hacer dos cosas:
Decidir cuál rama de la maraña seguirá creciendo
Registrar esta decisión para informar a los futuros nodos
Esto permite que el protocolo IOTA mantenga una base de datos consistente con los saldos de todos los usuarios siempre disponibles.
Veámoslo con un ejemplo:
Juan tiene 5 MIOTAs y los envía a Pedro, en la transacción A. Luego Juan por accidente (o con malas intenciones) los vuelve a mandar a Pablo en la transacción B.
El conflicto hará que la maraña se divida en tres ramas: La Rama 1 que incluye la Transacción A para Pedro. La Rama 2 que incluye la transacción B para Pablo, y la rama 3, que rechaza ambas transacciones.
El protocolo debe decidir entre las siguientes opciones:
Rechazar la rama 1, que incluye la transacción A para Pedro, y entonces dará a Pablo los 5 MIOTA.
Rechazar la rama 2, que incluye la transacción B para Pablo, y entonces dará a Pedrolos 5 MIOTA
Rechazar ambas ramas 1 y 2, junto con ambas transacciones a Pablo y Pedro, dejando a Juan sus 5 MIOTA
Supongamos que el protocolo rechaza la Rama 1. Entonces las ramas 2 y 3 seguirán creciendo, pero eventualmente la rama 2 se comerá a la Rama 3, ya que en esencia estas dos ramas no tienen conflicto.
Sin embargo un miembro malicioso de la red puede conservar viva la Rama 1. El protocolo debe avisar a los nuevos nodos que se unan a la red que la Rama 1 ha sido rechazada.
Un atacante podría provocar muchos conflictos con dependencias complicadas creando una telaraña de ramas. Según la teoría de Hans Moog (Científico de Investigación Senior en IOTA) llamada “Teoría Multiverso”, el modulo “branch manager” siempre elegirá una sola rama y por lo tanto un solo estatus de la base de datos.
Para tomar estas decisiones, el protocolo IOTA 2.0 hace la siguiente rutina:
Antes de explicar cada módulo, resumimos brevemente el funcionamiento general de la rutina.
Los mensajes entran a la red a través del algoritmo de control de congestión.
Sólo cuando hay un conflicto se activa el protocolo de votación llamado FPC el cual decide la rama que debe rechazarse.
La votación está protegida contra los atacantes a través de un sistema de reputación llamado Maná, que limita quiénes serán los participantes en la votación.
Después de que el Protocolo FPC rechaza una rama, se seleccionan los mensajes o puntas a los que se deben conectar los mensajes entrantes.
Conforme estas puntas son aprobadas una y otra vez de manera directa o indirecta por lo mensajes entrantes adquieren mayor ponderación en las votaciones en conflictos futuros.
Cuando una rama tiene suficiente ponderación de aprobación sus transacciones se hacen inmutables y se registran en la base de datos. Es decir, se ha llegado al consenso.
El Maná se actualiza determinando los siguientes votantes del FPC
Maná: Para cada transacción los holders de tokens atribuyen maná a los nodos. Como esta operación de atribución requiere tokens, los atacantes únicamente podrán tener tantos maná como tokens. Para mayor información vea los artículos del Blog de IOTA Foundation “Explicación de Mana” Parte 1 y Parte 2.
Votación FPC: Cuando hay nuevos mensajes entrantes a la red, los conflictos activan el protocolo de votación FPC (Consenso Probabilístico Rápido). Primero los nodos deciden cuales transacciones en conflicto prefieren en base a su antiguedad. Luego cada nodo vota, preguntando directamente a otros nodos cuales transacciones prefieren. Si una cantidad suficiente de estos nodos prefieren una transacción (la cantidad suficiente es un umbral aleatorio), el nodo que está preguntando también lo preferirá. Entonces cada nodo vuelve a preguntar a algunos nodos diferentes sus opiniones, repitiendo el proceso varias veces hasta que todas las opiniones se estabilicen.
Maná proteje la votación FPC: Entre mayor maná tiene un nodo, más le preguntan su opinión otros nodos. Análisis y simulaciones matemáticas demuestran que FPC siempre concluye correctamente con todos los nodos honestos de acuerdo cuando el atacante tiene mucho mana.
Selección de Puntas: Después de que concluye el FPC, el protocolo ha elegido efectivamente cuáles ramas rechazar: Cualquier rama que contenga una transacción que no sea de la preferencia del FPC es rechazada. Al crear un nuevo mensaje, los nodos seleccionan aleatoriamente las puntas (mensajes sin referencias) de entre las ramas sobrevivientes.
Ponderación de Votación de Aprobación: La ponderación de aprobación de una rama esencialmente es la cantidad de maná que tiene un nodo que emite un mensaje en dicha rama. Todos los nodos honestos conectan sus mensajes a ramas no rechazadas y la ponderación de aprobación de estas ramas crece rápidamente, mientras tanto la ponderación de una rama rechazada permanece siendo poca.
Los nuevos nodos que se unen a la red pueden inferir los resultados de previos votos del FPC en el que no participaron si observan las ramas que tienen suficiente ponderación.
Inmutabilidad (Finality): La inmutabilidad (Finality) mide la probabilidad de que un mensaje no será abandonado. En IOTA 2.0, cuando el mensaje recibe las referencias directas o indirectas de otros mensajes en cantidades suficientes (con la ponderación de maná de sus emisores), el mensaje se vuelve inmutable (final), así se garantiza que el mensaje tiene “profundidad” en la maraña (tangle) y no será abandonado. En la red prototipo “Nectar” esto se lleva a cabo en segundos.
—----------
Gracias por leer este artículo. Deseamos haber explicado con claridad la operación interna de IOTA 2.0. Para maor información en relación a los módulos individuales por favor vea el sitio de la red de desarrollo de IOTA 2.0 (DevNet) haciendo click aquí.
Si tiene preguntas o si desea tener una conversación en relación a IOTA 2.0, usted podrá encontrar a los integrantes de nuestro equipo de Investigación al igual que a otros miembros de nuestra maravillosa comunidad en el canal #tanglemath de Discord. Lo invitamos cordialmente en nuestras conversaciones técnicas en nuestro foro público: IOTA.cafe.
Traduccion al español de Fully decentalized IOTA 2.0 explained in under 3 minutes
Comentários