elcontable escribió:---------------------------------
PETERPAN
Recibi información de IOTA muy preocupante
No quiero revelar nada porque podría influir en su cotización
Te mando un analisis acerca de IOTA
Esta semana he analizado IOTA, un libro de contabilidad distribuido que no utiliza blockchain.
A primera vista, IOTA es tan diferente de Ardor como puede llegar a ser un libro de contabilidad distribuido. Utiliza un grafo acíclico dirigido (Directed Acyclic Graph – DAG), cuyos desarrolladores denominan el “Tangle”, para representar el historial de transacciones, en lugar de almacenar las transacciones en una blockchain. La intención es que se use primordialmente para microtransacciones de máquina a máquina en el Internet de las Cosas (Internet of Things – IoT), una visión motivada por el hecho de que IOTA no tiene tasas por transacción. Y no soporta (todavía) las características de “blockchain 2.0″ que forman parte principal del atractivo de Ardor. A simple vista, no parece que compita con Ardor.
Mi principal interés es explorar la aproximación que realizan diversos libros de contabilidad distribuidos al escalado y aquí es dónde la comunidad de IOTA ha hecho algunas afirmaciones extraordinarias. Conforme he ido aprendiendo más sobre IOTA para entender mejor como escala, he llegado a la conclusión de que IOTA y Ardor ofrecen soluciones complementarias (o directamente opuestas) al problema del escalado:
Ardor reduce drásticamente el crecimiento desmesurado de la blockchain pero requiere que todos los nodos de la red se pongan de acuerdo sobre el estricto orden de las transacciones; IOTA, por su lado, consigue un resultado mayor relajando para ello las reglas un poco, permitiendo discrepancias temporales entre las transacciones, pero se enfrenta a un reto importante al afrontar el crecimiento del tangle. Estas dificultades, junto a lo que he aprendido sobre la seguridad del tangle, me parecieron lo suficientemente interesantes para dedicarle un artículo en esta serie.
El Tangle
Sin lugar a dudas, la característica más representativa de IOTA es el tangle.
El resto de características únicas de IOTA, tales como la no existencia de tasas por transacción, el hecho de que las transacciones no siguen un orden estricto, aunque sigan siendo consistentes a largo plazo, y la noción de que (un poco de) spam realmente incrementa el rendimiento de la red, todas derivan del modo en que el tangle funciona.
Por esta razón, y también porque no quiero involucrarme en alguna de las controversias recientes entorno al proyecto IOTA, intentaré centrarme principalmente en entender y evaluar el tangle como conjunto, en lugar de diseccionar los detalles de su implementación específica en IOTA.
El tangle es un grafo acíclico dirigido cuyos vértices representan transacciones individuales y cuyos lados representan la “aprobación” de transacciones previas. Cada vez que un nodo transmite una nueva transacción a la red debe elegir dos transacciones previas para validarlas, a las cuales hace referencia en la nueva transacción que transmite. Conforme la nueva transacción penetra en la red, cada nodo la añade a su copia local del tangle, con un lateral apuntando a cada transacción que la nueva transacción aprobó.
He intento hacerlo lo mejor posible, pero esta descripción puede resultar confusa. Este diagrama debería ayudar.(ver mas abajo)
Cada cuadrado representa una transacción y las flechas que salen de cada transacción apuntando hacia otras dos representan la aprobación de las dos transacciones previas. La transacción génesis se encontraría fuera del diagrama por su lado izquierdo, y las transacciones más nuevas, llamadas “puntas” (tips) en el white paper, se encuentra a la derecha, coloreadas de color gris.
¿Qué significa validar, y por tanto aprobar, una transacción? Conceptualmente, el nodo que hace la validación debe partir de las dos transacciones que está validando y seguir todos los caminos en orden inverso hasta la transacción del génesis, asegurándose de que nunca encuentra una contradicción (por ejemplo, un doble gasto, saldo insuficiente o cosas parecidas). Si hay una contradicción, escogerá otro par de transacciones para aprobar, sabiendo que ningún otro nodo aprobaría nunca la transacción que trata de transmitir si hubiese aprobado una serie de transacciones inconsistentes.
Hay que darse cuenta de que esto significa que cada nueva transacción no solamente aprueba cada una de las dos transacciones que ha escogido para ser validadas, sino que también indirectamente aprueba las transacciones que esas dos han aprobado, y las transacciones que esas transacciones aprobaron… y así todo el camino hasta el génesis. Esto es parte básica del “consenso a largo plazo” (eventual consensus) en el tangle.
En caso de que te estés preguntando acerca de la sobrecarga computacional para realizar esta validación, en la práctica se puede optimizar substancialmente. En los gráficos de esta página puedes observar que conforme caminas en el tangle desde las puntas (a la derecha del todo) hacia el génesis, a la larga alcanzas un punto en el pasado en el que todas las transacciones han sido (indirectamente) aprobadas por todas las puntas. En esos gráficos, las transacciones aprobadas por todas las puntas están coloreadas en verde. Por este motivo, se podría cortar el tangle a través de flechas que apunten a las transacciones en verde, validar los caminos desde esas transacciones particulares en verde hasta el génesis una sola vez, almacenar en cache los resultados y, desde ese momento en adelante, solamente validar tus nuevas transacciones hasta esas transacciones en verde. Esta optimización te evita el tiempo necesario para validar todo el tangle cada vez que quieras emitir una transacción y además permite que el tangle sea podado.
Una característica interesante de un libro de contabilidad basado en tangle como en IOTA es que los nodos que reciben las nuevas transacciones desde los pares no tienen que validarlas inmediatamente. De hecho, el tangle puede contener temporalmente transacciones contradictorias. Sin embargo, a la larga, un nodo debe decidir cual de las transacciones contradictorias debe aprobar (posiblemente indirectamente) al tener que añadir una nueva transacción.
¿Cómo elige entre transacciones en conflicto? Asumiendo que cada transacción sería válida si fuese considerada por separado, entonces la respuesta corta es que un nodo podría elegir aprobar cualquiera de ellas. Sin embargo, tiene un incentivo para aprobar aquella sobre la que el resto de la red continuará construyendo, para que igualmente su propia transacción sea aprobada a la larga. Se supone que la mayoría de los nodos de la red ejecutan el algoritmo de selección de transacciones para la aprobación, así que en caso de conflicto, un nodo tiene un incentivo para elegir la transacción que el algoritmo de referencia elegirá.
Para entender el algoritmo de referencia, es importante entender primero el concepto de peso acumulado (cumulative weight) de una transacción.
Cada nodo que emite una transacción tiene que hacer un poco de Prueba de Trabajo (Proof-of-Work – PoW), el cual determina el “peso propio” de la transacción. El peso acumulado de una transacción es entonces la suma de su peso propio con los pesos de las transacciones que han sido directa o indirectamente aprobadas. En un tangle genérico, el nodo puede decidir cuanto trabajo hacer para una transacción, pero en IOTA todas las transacciones requieren del mismo PoW y, por consiguiente, todas cuentan con el mismo peso. Cómo resultado, el peso acumulado de una transacción es proporcional al número de transacciones que aprueba directa o indirectamente.
Entonces ¿Qué es el algoritmo de referencia? El autor del white paper lo llama Markov-Chain Monte Carlo (MCMC, ver sección 4.1), lo cual es una manera sofisticada de decir que es el viaje aleatorio por la tangle por aquellos caminos con mayor peso acumulado.
Cuando surgen transacciones en conflicto, el algoritmo MCMC resuelve el conflicto tendiendo a elegir aquella transacción que cuenta con el mayor peso acumulado tras ella. A la larga, un subtangle se convierte en dominante y el otro se queda huérfano. Esto proceso es análogo al que las blockchains usan para resolver forks y el peso acumulado de una transacción en IOTA es una media aproximada de su finalidad de la misma forma que al añadir bloques a una blockchain estamos confirmando transacciones cada vez con mayor certeza.
Por cierto, el hecho de que los nodos no necesiten validar inmediatamente cada nueva transacción recibida de sus pares tiene grandes implicaciones para el rendimiento. Cada nodo tiene que hacer menos trabajo de este modo, validando las transacciones solo cuando transmiten nuevas transacciones y tomando por seguro que las transacciones que han sido aprobadas indirectamente por todas las puntas han sido ya validadas por el resto de la red. Además, las validaciones corren en paralelo a través de la red, puesto que los diferentes nodos eligen diferentes subseries de transacciones para aprobar.
Seguridad
Hasta este momento, mayormente solo he regurgitado la información disponible en el white paper de IOTA. Por otro lado, el asunto de la seguridad del tangle es dónde la cosa se pone interesante. Recomiendo leer el análisis que se puede encontrar en el white paper sobre los diferentes posibles ataques sobre el tangle (también recomiendo leer el resto del whitepaper, porqué está muy bien redactado) y es por esto que no hablaré sobre la mayor parte de ese análisis aquí.
En su lugar, quiero centrarme en la amenaza más obvia, que es la de un ataque del 51%. Los desarrolladores de IOTA se refieren a ello como ataques del 34%, por unas razones que no estoy seguro de comprender. Creo que es porque si un atacante esperase hasta que suceda un fork de modo natural solo necesitaría un determinado poder de hash para sobrepasar el de los nodos en cada rama del fork, es decir, más de un 50% del poder de hash del resto de la red. De cualquier modo, el número exacto no es importante y para lo que queda de artículo haré referencia a él como “ataque del 34%”.
En IOTA, un ataque del 34% tendría la siguiente apariencia. Un atacante emite una transacción que supone el gasto de unos fondos, representado por el punto rojo de más a la derecha. A continuación, proceso (o quizá haya ya preprocesado) su propio subtangle “parásito”, el cual se ancla al tangle principal en algún lugar aguas arriba de su transacción y que contendrá una transacción de doble gasto, representada por el punto rojo de más a la izquierda. Su objetivo es añadir el suficiente peso acumulado a su tangle parásito para convencer al algoritmo MCMC de que debe dejar huérfano el tangle principal y pasará a seguir el parásito.
Afortunadamente, las analogías con la blockchain son claras hasta ahora, pero todavía existe una más importante. Cómo en una blockchain PoW, el tangle está asegurado por el poder de hash actual de la red, puesto que este poder de hash es lo que añade peso acumulado al tangle legítimo. Sin embargo, al contrario de lo que sucede en una blockchain PoW, los nodos de IOTA sólo hacen PoW cuando emiten transacciones. Por tanto, la seguridad del tangle depende solo de la frecuencia de transacciones y la cantidad de PoW por transacción. Tómate un segundo para asimilar esta idea, porque es absolutamente crucial para entender la seguridad del tangle.
Puesto que la red de IOTA es todavía pequeña y el ratio de transacciones es baja, el equipo de IOTA ha establecido un único nodo de confianza, llamado el Coordinador, que es responsable en último lugar de decidir el estado actual del tangle. Su propósito es proteger la red frente a ataques del 34%, entre otros ataques. No voy a dedicarle más tiempo, pero os animo a que leáis esta crítica y la respuesta de los desarrolladores, y entonces saquéis vuestras propias conclusiones acerca de si IOTA puede llamarse descentralizado cuando funciona bajo la supervisión del Coordinador.
Vamos a ver si podemos obtener una estimación del orden de magnitud de lo segura que la red podría ser sin el Coordinador. En un reciente test de stress se alcanzaron cómodamente las 100 transacciones por segundo (tps) en una pequeña red de pruebas. El equipo sugiere que 1.000 tps por segundo serían factibles. No se cual es el requisito de PoW en IOTA, pero supongamos que el dispositivo IoT medio sea aproximadamente una Raspberry Pi que utiliza el 100% de su CPU durante 10 segundos para realizar el PoW requerido. De nuevo, estoy tratando de ser generoso; muchos dispositivos IoT son considerablemente menos poderosos que una Raspberry Pi, y pedir el máximo de la CPU durante 10 segundos para cada transacción probablemente sería un quebradero de cabeza.
Con estas premisas, podemos concluir que el poder de computación medio que asegurará la red es aproximadamente 10.000 x (el número de computaciones de Raspberry Pi en 10s) por segundo, o su equivalente, 100.000 veces el poder de computación de una Raspberry Pi. Hay múltiples matices posibles sobre el benchmark de los dispositivos, pero no nos vamos a preocupar por variaciones de factor dos o tres, ya que sólo pretendemos obtener una estimación del orden de magnitud, así que usaré algunos números gordos que he encontrado en internet.
Una Raspberry Pi3 puede realizar cientos de MFLOPS (megaflops, o millones de operaciones de coma flotante por segundo), mientras que los relojes de las GPU’s de última generación pueden realizar miles de GFLOPS (gigaflops, o billones de FLOPS), 10.000 veces mayor poder de computación. Así que en nuestro caso hipotético, un atacante con ~10 GPUs podría sobrepasar el poder de cómputo de toda la red. Añádele otro factor de 10 porque haya sido descuidado en mis cálculos (quizá las operaciones con enteros son más lentas en una GPU que las operaciones como flotante, por ejemplo) y todavía necesitarías solamente 100 GPUs para ejecutar los ataques.
Quizá IOTA no se ejecutará continuamente en el extremo de la red, por ejemplo. En su lugar puede que se ejecute en routers y puertas de enlace a la que estos dispositivos IoT se conecten, los cuales suelen ser mucho más potentes.
De todos modos, lo que pretende decir es que PoW asegura con éxito blockchains como la de Bitcoin y Ethereum porque no está atado a la tasa de transacciones o a cualquier otro factor más allá del valor económico de la red. Conforme el valor de la recompensa por minado (en dinero fiat) aumenta según aumenta el valor de Bitcoin, los mineros añaden más hardware y consumen más energía para minarlo. El incentivo económico para minar asegura que la cantidad de poder de hash que asegura la red aumenta con el valor monetario de la red.
Por contra, en IOTA no hay incentivo económico para asegurar la red. Además, el poder de hash que asegura la red está ligado directamente al número de transacciones, el cual naturalmente tiene un límite superior que depende del ancho de banda y de la tipología de la red.
Sobre este último punto, los desarrolladores de IOTA han lanzado un argumento creativo, no mencionado en el whitepaper, que afirma que las limitaciones y la tipología de la red realmente mejoran la seguridad de la red. No he encontrado ningún argumento oficial sobre ello en ningún sitio, pero tras investigar un poco me encontré con esta conversación en Slack, que es el mayor argumento que he podido encontrar.
Esencialmente, uno de los desarrolladores de IOTA (en concreto Sergey Ivancheglo, alias Come-from-Beyond, posiblemente alias BCNext, uno de los creadores originales de Nxt), afirma que la red de IOTA consistirá en dispositivos IoT que se emparejarán exclusivamente con sus vecinos más próximos en una tipología de red en malla, en la que un atacante solo tendrá la posibilidad de emparejarse con un pequeño número de dispositivos en esa red en malla. Es decir, la gran mayoría de dispositivos no estarán disponibles desde internet u otra red de acceso y la única manera de enviarles mensajes sería a través de la malla del resto de dispositivos.
La idea general es que la malla como entidad será capaz de alcanzar un gran rendimiento, pero cada link individual en la malla tiene un ancho de banda lo suficiente bajo que haría que un atacante lo saturase al tratar de añadir el número de transacciones suficientes para que convencer a la red de que siguiese su subtangle parásito. Puesto que el atacante solo tiene unos pocos puntos de entrada a la malla, los saturará antes de que su tangle parásito acumule suficiente peso como para que su ataque sea fructífero.
Personalmente no creo que el equipo de IOTA haya publicado los suficientes detalles como para poder evaluarlo en profundidad.
Ya que estamos hablando de las limitaciones del ancho de bando, pasemos a hablar del escalado.
Escalabilidad
Puesto que cada nodo debe validar otras dos transacciones antes de poder emitir su propia transacción, al equipo de IOTA le gusta señalar que el spam realmente tiende a hacer la red más eficiente. Otros miembros de la comunidad IOTA se dejan llevar por este argumento, algunos veces hasta llegar a afirmar absurdamente que IOTA es “infinitamente escalable.”
Cada nodo de la red de IOTA debe, a largo plazo, recibir cada transacción para mantener un tangle mínimamente consistente. Sin embargo, transmitir transacciones a los nodos remotos requiere de tiempo y si el ratio de transacciones es lo suficientemente alto, de modo que un nodo recibe muchas transacciones de sus nodos cercanos antes de que reciba la próxima transacción desde los nodos lejanos, el algoritmo MCMC continuará seleccionando las puntas enviadas por los nodos cercanos. A la larga, el tangle se divide, con solo los nodos cercanos realizando transacciones en la copia local del tangle y los nodos lejanos realizando transacciones entre ellos, una copia divergente.
Así que el ancho de banda y la tipología de la red tiene que establecer ciertas limitaciones en el ratio de transacciones de IOTA si el tangle tiene que ser consistente a lo largo de toda la red. Tendremos que esperar a que se completen más test de estrés para descubrir cuales son las limitaciones.
Adicionalmente, como todos los libros de contabilidad distribuidos, IOTA tiene que lidiar con el problema del crecimiento desmesurado. Cada transacción de IOTA ocupa unos 1,6kB, así que un tasa de transacciones de 100tps hará crecer el tangle a un ritmo de 160 kB por segundo, o unos 14GB al día. No es necesario decir que eso es un valor de almacenamiento irreal para un dispositivo IoT.
IOTA soluciona este problema tomando capturas periódicas del tangle, que mapea su estado actual en una nueva transacción génesis, permitiendo que el historial de transacciones sea eliminado. En el supuesto límite de un podado muy frecuente, un nodo solo tendría que almacenar una parte suficiente del tangle para ser capaz de ejecutar el algoritmo MCMC.
Sin embargo, sincronizar un nuevo nodo con la red es una historia diferente. O bien el nodo descarga la última captura desde un par de confianza, o bien arranca desde la transacción génesis original y busca su camino hacia delante en todo el tangle. No hay manera de unirse de manera eficiente a la red sin depender de la confianza en un tercero.
Finalmente, hay que mencionar que el equipo de IOTA ha propuesto un tipo de partición horizontal del tangle al que llaman “manada” (swarm) dónde un grupo de nodos unidos almacenan todo el tangle, pero ninguno de ellos lo almacena en su totalidad. Desafortunadamente, todavía no contamos con muchos detalles sobre cual es su funcionamiento.
Comparado con Ardor
En mi opinión, hay dos comparaciones que establecer, concretamente en los aspectos de la seguridad y la escalabilidad.
Sobre la seguridad, no está claro para mí que IOTA pueda alcanzar un ratio de transacciones suficientemente alto para ser considerado seguro sin el Coordinador, debido al valor monetario de la red actual, sin elegir una exigencia muy alta de PoW.
Ardor, por su parte, tiene la ventaja de que sus child chains están aseguradas por una única cadena madre.
Una “pequeña” child chain no requerirá de un nodo de confianza como es el Coordinador de IOTA para protegerla, porque su consenso es establecido por la red al completo y almacenado (a través de los hashes de los bloques de las child chains) gracias a los forjadores en la cadena madre.
Sobre la escalabilidad, tanto IOTA como Ardor comparten el requisito de que cada nodo de la red debe procesar todas las transacciones. Con IOTA, esto simplemente significa añadir transacciones al tangle, lo que es computacionalmente barato, mientras que con Ardor, cada nodo debe validar cada transacción. Además, el diseño inteligente del tangle asegura que el tiempo de confirmación por una transacción realmente disminuye conforme la red tiene más trabajo. No me sorprendería que IOTA alcanzase un mayor rendimiento que Ardor si ambas redes crecen.
Por otro lado, IOTA se enfrenta a un tremendo reto para combatir los problemas de crecimiento desmesurado del tangle si alguna vez tiene que alcanzar cientos de transacciones por segundo, mientras que Ardor ya ha solucionado este problema.
Finalmente, hay que mencionar que la hoja de ruta de Ardor delegará el procesado de las transacciones de la child chains a sub-redes dedicadas dentro de la red. Esto podría potencialmente alcanzar una mejora computacional similar a la propuesta de “manada” de IOTA, posiblemente permitiendo un rendimiento similar.
Te habrás dado cuenta de que he dejado fuera multitud de detalles, incluyendo su algoritmo de hash casero, la falla introducida deliberadamente en el código por Come-from-Beyond como sistema anti-copia, el uso de codificación ternaria y el misterioso procesador Jinn que ofrecerá soporte hardware para IOTA en los dispositivos IoT. En el transcurso de mi investigación, me he formado unas posiciones bastante fuertes al respecto sobre estos temas, pero dudaba acerca de compartirlas aquí por dos motivos.
Primero, no tengo suficiente información para hacer afirmaciones objetivas sobre estos temas. No soy un criptógrafo y no conozco casi nada sobre la computación ternario o Jinn. Lo mejor que podría hacer es ofrecer afirmaciones subjetivas sobre las decisiones de diseño que el equipo de IOTA había hecho.
Segundo, y más importante, estoy más interesado en los conceptos fundamentales tras el tangle que en la implementación específica que IOTA hace de él. Sin importar si IOTA triunfa o fracasa, el tangle es una idea bella y se merece toda la atención que le podamos dedicarle.
Entonces ¿qué podemos decir sobre el tangle? Aunque me enamora lo elegante de su diseño y las sutilezas de su mecanismo de consenso, al final me temo que soy bastante escéptico de su usabilidad para el Internet of Things. Si quitas este aspecto, incrementa los requisitos de PoW varias órdenes de magnitud y encuentra un camino para ligar el umbral del PoW al valor monetario de la red sin evitar el acceso de los usuarios comunes a sus fondos y entonces creo que el tangle tiene un enorme potencial como libro de contabilidad distribuido.
La última pieza a encajar es como combinar la no necesidad de confianza, eficiencia y crecimiento desmesurado, un problema que Ardor ha solucionado extremadamente bien. Quizá alguien encontrará una manera de combinar los mejores elementos de ambos diseños en algún punto en el futuro. Un montón de cosas pueden suceder hasta entonces, especialmente en criptolandia.
este es el foro de cresud
