En el día de hoy abordaremos un tema especial relacionado a la escalabilidad de IOTA: el Sharding.
El Sharding es un proceso por el cual se segmenta un enorme conjunto de datos en varios grupos más pequeños. Cada uno de estos grupos más pequeños es totalmente independiente del resto. El sharding logra usar de forma más eficiente el poder de los nodos de la red y ofrecer respuestas más rápidas a las transacciones.
Una DLT sin sharding puede significar problemas de congestión graves porque cada participante de la red («nodo») debe procesar todas las transacciones válidas. Por tanto, el rendimiento total de la red (conocido informalmente como transacciones por segundo) está limitado en última instancia por los recursos disponibles, como la conectividad a Internet, el procesamiento de los dispositivos y la capacidad de almacenamiento.
Vamos a ver que no todas las soluciones de sharding son compatibles con IOTA y cuál es la visión de IOTA al respecto en el siguiente artículo escrito por Hans Moog.
Si bien el siguiente articulo fue publicado el año pasado y pueden existir algunas modificaciones respecto de los requisitos necesarios para IOTA la visión general se ve muy bien explicada.
Los invitamos a leer esta primer parte de «Scaling IOTA Part 1 – A Primer on Sharding»
Que lo disfruten!
Los siguientes posts van a introducir algunas de las ideas y conceptos fundamentales detrás de una nueva solución de fragmentación para IOTA Tangle. Discutiremos cómo funciona el mecanismo propuesto y por qué se tomaron ciertas decisiones al diseñar esta solución.
Aunque este tema todavía está siendo investigado y algunos de los detalles podrían cambiar a medida que la investigación progresa, es de todos modos lo suficientemente maduro como para ser discutido abiertamente y esperamos recibir comentarios.
Motivación
Uno de los mayores problemas de las DLT en la actualidad es el limitado rendimiento de las transacciones por segundo que pueden procesar las redes. Si la demanda es superior a la capacidad de procesamiento, la dinámica de la «oferta y la demanda» conduce a un aumento de las tarifas (fees) y a tiempos de confirmación más largos. Esto, a su vez, reduce la demanda haciendo que la red sea un poco menos «atractiva» para sus usuarios.
Esta forma de «gestionar» los recursos de una red funciona bastante bien para mantenerla operativa, pero las tarifas dinámicas son un problema muy real para la experiencia de los usuarios y dificultan enormemente la construcción de aplicaciones fiables en el mundo real sobre ella (véase el reciente colapso del sistema MakerDAO que se construye sobre Ethereum).
Debido a sus tarifas cero, IOTA obviamente no sufre estos costos por realizar transacciones fluctuantes. Sin embargo, los nodos de IOTA tienen un límite máximo de transacciones por segundo (TPS) que pueden procesar. Entonces, ¿cómo va a reaccionar IOTA a estas diferencias en la oferta y la demanda sin que la red colapse?
Veamos primero las razones de estas limitaciones y cómo otros proyectos las abordan.
Razones y soluciones para esta limitación
La razón principal de esta limitación de rendimiento es el hecho de que cada nodo de la red tiene que procesar cada transacción, y que las capacidades de hardware de los nodos son limitadas. Para optimizar el rendimiento, sólo hay dos opciones:
- Delegar todo el cálculo en un conjunto más pequeño de nodos muy potentes (por ejemplo, Hashgraph, EOS, etc.).
- Dividir las tareas y hacer que cada nodo realice sólo un subconjunto de la cantidad total de trabajo.
Aunque el primer enfoque podría resolver el problema durante un tiempo, al aumentar el rendimiento a niveles que probablemente no se superen en un futuro próximo, no resuelve realmente el problema en sí. A medida que aumente la adopción, las redes volverán a enfrentarse inevitablemente a las mismas limitaciones. Por ello, tiendo a llamar a estas soluciones micro-optimizaciones.
El segundo enfoque se denomina sharding y es la forma en que, por ejemplo, Ethereum intenta abordar el problema de la escalabilidad. En lugar de ejecutar una sola cadena de bloques, están planeando ejecutar 64 cadenas de bloques en paralelo, con cada fragmento teniendo sus propios validadores. Estas cadenas son completamente independientes, pero pueden interactuar a través de otra cadena que conecta todos los shards (la bacon chain).
Aunque esto aumenta la escalabilidad, sigue teniendo los mismos problemas de tener un límite superior de cuántas transacciones puede procesar cada sharding. Por lo tanto, esto requerirá el mismo mecanismo de fees dinámicas para regular la oferta y la demanda de rendimiento. Así que, aunque este enfoque se acerca más a una solución real (porque podemos simplemente aumentar el número de shards al cabo de unos años, a medida que aumenta la adopción), sigue sin resolver realmente los problemas de las tarifas y los tiempos de transacción imprevisibles; de hecho, incluso introduce algunos problemas nuevos.
Problemas adicionales con el sharding
Como los validadores tienen que repartirse entre todas las cadenas existentes (incluida la bacon chain), cada fragmento estará asegurado por menos validadores que antes. En consecuencia, la seguridad del sistema será menor que en un entorno no shardeado. Este problema existe en cualquier solución de sharding, ya que la idea misma de sharding es dividir el trabajo entre los validadores.
Las blockchains, sin embargo, tienen problemas adicionales específicos de la tecnología:
La ejecución de múltiples cadenas en paralelo requiere un consenso sobre el número de shards, y cambiar este número no es posible «sobre la marcha». Para estar preparados para el futuro es necesario dividir la red en más shards de los que requiere el rendimiento actual, lo que se traduce en una menor seguridad desde el primer día. Es imposible que la red reaccione orgánicamente a la creciente adopción o a las diferentes condiciones de la red.
Dado que el rendimiento de cada sharding está definido por parámetros del sistema como el tamaño y el tiempo de los bloques, cada nodo debe cumplir ciertos requisitos de hardware, lo que impide que los dispositivos IoT de baja potencia participen en la red.
Como no podemos aumentar arbitrariamente el número de shards (en algún momento la bacon chain se sobrecarga), esta solución tampoco ofrece una escalabilidad infinita real con el número de nodos.
Esta forma tradicional de sharding (simplemente ejecutando múltiples instancias de la misma tecnología) no ofrece, por tanto, una respuesta a la visión de IOTA.
La visión de IOTA
La visión de IOTA es proporcionar una plataforma DLT que sea capaz de mantenerse automáticamente al día con la creciente adopción, proporcionando un rendimiento cada vez mayor que se adapte al número de nodos en la red. Al mismo tiempo, el mecanismo utilizado debe ser lo suficientemente flexible y rápido como para reaccionar a cosas como los cambios en el supply y la demanda de rendimiento de la red, de modo que la red pueda seguir funcionando sin tener que recurrir a las tarifas para que los nodos decidan qué transacciones procesar.
Teniendo en cuenta cómo funcionan las soluciones de sharding hoy en día, esto parece ser un problema difícil, que no es fácil de resolver y IOTA, en consecuencia, ha recibido muchas críticas por comprometerse públicamente con estos objetivos sin revelar nunca cómo se supone que se va a lograr.
Mucha gente todavía considera que este es un problema irresoluble y culpa a IOTA de vender aceite de serpiente e incluso hay un vídeo que aparentemente «demuestra» que este problema no puede ser resuelto (volveremos a tratar el problema descrito más adelante).
Este post trata de arrojar finalmente algo de luz sobre cómo IOTA planea lograr esta escalabilidad.
Requisitos para la visión de IOTA
Antes de empezar a introducir los nuevos conceptos en las partes posteriores de este post, voy a desviarme un poquito y discutir algunos de los requisitos, ya que afectan directamente a ciertas decisiones de diseño de la solución de escalabilidad que se ha propuesto:
La solución tiene que incorporar alguna forma de sharding, ya que las micro optimizaciones no hacen más que retrasar los problemas en lugar de resolverlos.
La solución debe evitar el doble gasto sin depender de alguna forma complicada de comunicación entre fragmentos (véase el vídeo mencionado anteriormente).
La red sólo debe shardear si es realmente necesario, manteniendo la mayor seguridad posible del sistema en tiempos de baja actividad, pero al mismo tiempo ser capaz de crecer con el aumento de la adopción.
La disposición de la fragmentación tiene que ser lo suficientemente dinámica como para reaccionar instantáneamente a los cambios en la red sin que los nodos tengan que «hablar» entre sí para negociar una nueva disposición de la fragmentación o utilizar las tarifas para determinar qué transacciones favorecer (enfoque centrado en el agente).
El sharding debe utilizar un «mapeo significativo» del mundo real (es decir, un mapeo geográfico) para que los nodos que están cerca unos de otros siempre puedan comunicarse directamente sin tener que utilizar alguna forma complicada de comunicación entre los shards.
Los nodos deben poder decidir individualmente cuántos y qué datos quieren procesar, de modo que podamos tener una red heterogénea con dispositivos IoT de baja potencia junto a nodos más potentes.
Los nodos deben poder moverse libremente entre los shards (nodos móviles como los coches) sin tener que descargar y validar repentinamente enormes cantidades de datos.
Conclusión
Debido a la naturaleza sin fees de IOTA, tenemos requisitos muy concretos pero complejos para nuestra solución de escalabilidad, que nos impide utilizar los conceptos existentes, y tenemos que llegar a un enfoque completamente diferente que debe ser mucho más flexible que las formas tradicionales de sharding.
La segunda parte de este blog hará una introducción paso a paso a este nuevo concepto de sharding (desde las primeras ideas abstractas hasta una solución concreta).
