Estado inicial de la Tangle
A diferencia de las tecnologías blockchain, IOTA no crea una secuencia sincronizada de bloques estáticos con varias transacciones. En cambio, cada transacción se puede attachear a sí misma y, en paralelo, a otras transacciones. Las siguientes diapositivas describirán cómo funcionan los mecanismos para agregar transacciones, validarlas y el consenso en IOTA.
El gráfico de arriba muestra un ejemplo de la Tangle que se utilizará a lo largo de este artículo para recorrer algunos casos. En éste y en los siguientes ejemplos, las transacciones verdes ya están confirmadas por la red con gran nivel de certeza (descubriremos por qué más tarde. Spoiler: Al igual que con blockchain, se trata de probabilidades y nunca habrá una certeza 100%), mientras que las azules solo se confirman parcialmente (con menor certeza). Los cuadros grises (y luego «amarillos») representan «tips» sin ninguna validación. Las transacciones en rojo, en las diapositivas posteriores, son conflictivas o no válidas.
En el gráfico anterior, la transacción «α» es un ejemplo de una transacción inusual. Hace referencia a la transacción «h» y «l». Como la transacción «h» ya está referenciada por la transacción «l», «α» seleccionaría un tip («l») y una transacción que ha dejado de ser tip para ese momento («h»). Tal comportamiento parece no ser un problema y tolerado por la red, actualmente.
Agregando una transacción
Para agregar una nueva transacción a la Tangle, un usuario tiene que elegir aleatoriamente dos «tangle tips» (transacciones aún sin confirmación) y validarlas. Esto significa que el usuario está verificando la firma de esa tip, el PoW que ésta ha realizado (pequeña «Prueba de trabajo» como protección contra spam) y se asegura de que no entre en conflicto con ninguna de las transacciones anteriores (referenciadas directa o indirectamente). Si las tips elegidas son legítimas, el usuario agrega su nueva transacción haciendo referencia a ellas.
Las transacciones que no están referenciadas directa o indirectamente por las tips que se han elegido son irrelevantes para el proceso de validación actual. Alguien más, o una transacción posterior se encargará de validar e introducirlas a la Tangle.
Otra transacción
Al mismo tiempo (o bien antes o después, es indiferente) otro usuario puede estar a punto de agregar su nueva transacción en una posición diferente. Eligió las tips «z» e «y». Al hacerlo, valida una gran parte de las mismas transacciones que ya fueron validadas a través de la transacción «1» (desde «a» hasta «k», «m» y «n»), además de algunas adicionales que no estaban en la ruta de validación de la transacción «1» («l», «o», «r», «t», «v», «y» y «z»).
Nuevo estado en la Tangle
Al superponer las rutas de validación de las transacciones «1» y «2», observamos que algunas de las transacciones solo se confirman por una, mientras que otras fueron confirmadas por ambas. Las transacciones validadas y confirmadas por todos los tips existentes en determinado momento se consideran completamente confirmadas. De ahí que la transacción «n» se haya adentrado más en la Tangle, volviéndose verde. Todas las transacciones posteriores vinculadas a «1» y/o «2» o sus hijos o los hijos de sus hijos (y así sucesivamente) continuarán revalidando y confirmando la transacción «n» a partir de ahora.
¿Qué hemos aprendido?
- Nadie necesita ver y validar la totalidad de las transacciones existentes en la Tangle. Cada usuario selecciona y valida dos transacciones y sus padres. Al hacerlo, solo validan una parte de la Tangle. A medida que otros usuarios seleccionan y validan diferentes tips y rutas, sucede una validación colaborativa global de la Tangle.
- Transcurrido un tiempo, cuando una transacción ha profundizado suficientemente en la Tangle, existe una ruta directa o indirecta desde cualquiera de las últimas tips hacia ella. Dicha transacción se considera plenamente confirmada y se volverá a validar y a confirmar nuevamente con cada transacción nueva. Podemos suponer que fue confirmado por todos los usuarios (y máquinas) lo cual le confiere gran certeza.
- Para verificar confirmación, solo hay que verificar si la transacción en cuestión es referenciada directa o indirectamente por las tips disponibles (o por cierta tasa de ellas si aceptamos una certeza menor, como el 80%). Nota: Puede haber miles de tips. En lugar de verificar los padres de cada una de ellas, es posible seleccionar una muestra aleatoria y hacer una evaluación estadística a partir de ella.
Niveles de confirmación
La siguiente imagen agrega algunas nuevas tips para demostrar un ejemplo extendido. Para cada nueva tip, se resalta su ruta de validación. Por la coloración se puede ver bien qué transacciones se validan por la cantidad de tips así como sus niveles de confirmación.
Un comerciante puede elegir un nivel de confirmación/certeza personalizado. Si la velocidad de la transacción es más importante que su valor (por ejemplo, una transacción micro o cero), o si el remitente es un amigo, se puede aceptar algo como un nivel de confirmación del 75%. Con un nivel de certeza del 75% (3 de 4 tips), las transacciones «l», «o» y «t» también podrían considerarse confirmadas.
Demora en la propagación (propagation delay)
En teoría, podría suceder que una transacción lenta «5» aparezca un poco más tarde, debido a un PoW lento o a retrasos en la propagación. Ahora que sabemos de la transacción «5», la transacción «n» ya no está totalmente confirmada por todos las tips. Sin embargo, su nivel de certeza de confirmación es aún bastante alto con 4 de 5 tips o 75% (en un escenario real habrá miles de tips en lugar de 5). La alta probabilidad de certidumbre respecto a una validación es un aspecto fundamental, al igual que en las tecnologías de blockchain en que cada bloque aumenta la probabilidad de certidumbre.
Nótese que la adición de la transacción «5» en este ejemplo no cambia el estado de la transacción de «confirmada» a «no confirmada». Simplemente cambia el número matemáticamente exacto de certeza (por ejemplo, si hubo 100 tips en total, del 100% al 99%). Una vez que se hayan realizado algunas referencias de transacciones posteriores (por ejemplo, la transacción «1» y «5»), las transacciones «n» volverán a estar totalmente confirmadas por todos las tips.
Un nivel de confirmación/certeza del 100% puede ser difícil de conseguir de todos modos, ya que siempre puede haber tips troll en el sistema (por ejemplo, que referencian algo inútil o no siguen el protocolo).
Problema del doble gasto
Imagine una situación en la que un usuario agrega dos transacciones conflictivas en diferentes áreas de la Tangle («w» e «y»). Los usuarios subsiguientes pueden tener solo una de estas transacciones conflictivas en su ruta de validación (en función de su «tip selection» o por retrasos en la propagación). Por ejemplo, los usuarios attacheando las transacciones «1» y «2» no verán el conflicto (solo visualizan una de las partes) y confirmarán las tips elegidas. Por lo tanto, el intento de doble gasto obtuvo sus primeras confirmaciones. Sin embargo, tarde o temprano las transacciones en conflicto estarán juntas en la ruta de validación de una transacción. Por ejemplo, la transacción «5» verá el conflicto y no se attacheará a ninguna de las dos transacciones. En su lugar, volverá a seleccionar tips hasta que encuentre que no están en conflicto para asegurarse a si misma que llegará a ser una transacción válida.
Dependiendo del tip selection y el progreso de la Tangle, puede suceder que muchos más usuarios adjunten sus transacciones detrás de «w» o «y», antes de que el conflicto de doble gasto se aclare. Dependiendo de dónde los usuarios attachearon la mayoría de las transacciones nuevas (ya sea detrás de «w» o «y»), una de estas dos se confirmará en algún momento, mientras que la otra será abandonada. Las transacciones subsiguientes asociadas a las abandonadas (que no pudieron ver el conflicto) también serán abandonadas. Sin embargo, estas transacciones no están perdidas, pueden ser tomadas por cualquiera (muy probablemente será el destinatario o emisor quienes harán reattach) y volver a unirse a la Tangle para tener una nueva oportunidad de confirmación. El PoW necesitaría ser rehecho, pero no se requieren nuevas firmas del remitente.
Resolución del problema del doble gasto
En la imagen anterior, un usuario intentó conectar una transacción «5» con las tips «1» y «2». Debido a un conflicto, volvió a intentar la tip selection y decidió hacer attach con las tips «1» y «4». Otro usuario (o tal vez el mismo) eligió las tips «2» y «3» para hacer attach de la transacción «7». Surgieron algunas ramas, pero solo una puede sobrevivir, debido al doble gasto en «w» e «y». Según la selección aleatoria de tips (y el peso acumulado de las transacciones), una de las dos ramas recibirá más hilos de transacciones (y respectivamente, más peso) hasta que la Tangle alcance un estado en que ya no sea posible hacer attach a una de las ramas. En la muestra anterior, los usuarios podrían simplemente continuar adjuntando a las transacciones «5», «6» y «8», pero no a la transacción «7». Por lo tanto, las transacciones «y», «2», «3» y «7» nunca llegarán a un estado de confirmación pendiente.
Como se describió en la diapositiva anterior, las transacciones «y», «2», «3» y «7» podrían volverse a attachearse a la Tangle. En la medida en que (todavía) sean válidas, tendrán una nueva posibilidad de obtener confirmación. Las transacciones «2», «3» y «7» podrían confirmarse, mientras que la transacción «y» no será válida.
Offline Tangle
La Tangle permite a los usuarios la creación de transacciones mientras están offline (por ejemplo, dentro de un entorno de intranet de la compañía, o para continuar interactuando con sus vecinos durante una interrupción de Internet). Para hacerlo, las transacciones se crean y se conectan entre sí como se describe en el protocolo.
En el ejemplo anterior, las transacciones «1» y «2» son las primeras fuera de línea. Están conectados a las últimas tips conocidas de la Tangle online. Las transacciones posteriores se attachean como de costumbre. Una vez que se desea sincronizar con la Tangle principal (o posible, en caso de una interrupción de Internet), el subconjunto fuera de línea se finaliza creando la transacción «8», que fusiona la offline Tangle con una tip reciente de la online Tangle. Posteriormente, la transacción «8» se convierte en una tip legítima y puede ser seleccionada y validada por transacciones online posteriores. Los siguientes usuarios que se conecten a la transacción «8» incluirán todas las transacciones fuera de línea en su rutina de validación.
Tenga en cuenta que las transacciones offline solo pueden confirmarse por completo una vez que entran a la Tangle principal como cualquier otra transacción, tal como se muestra en las gráficas anteriores. Si cualquier transacción dentro de la rama offline entraba en conflicto con la mainnet (red principal de la Tangle), las transacciones «1» a «8» no se confirmarían. De nuevo, podría tomar algunas transacciones posteriores hasta que el conflicto sea visible desde todas (o la mayoría) de las tips de la Tangle principal (como se describe en la imagen de «Doble gasto»).
Aclaración del traductor: si bien se ha respetado el espíritu y estructura del artículo, algunas partes han sido fundidas o simplificadas debido a que en en Español tendían más a la confusión que al esclarecimiento.
Fuente: https://github.com/noneymous/iota-consensus-presentation
