TL;DR
En las tecnologías de ledger distribuido, la escalabilidad indica la capacidad de un sistema para aumentar su rendimiento a medida que se genera más demanda. Blockchain ve la escalabilidad como un gran reto debido a su diseño de libro de contabilidad que impone que las transacciones estén totalmente ordenadas. En esta entrada del blog, primero ampliamos las diferencias entre escalabilidad y rendimiento; después, exploramos la solución de fragmentación, en la que los mensajes se entregan sólo a un subconjunto de nodos de la red, reduciendo la redundancia para construir una red de alto rendimiento.
Érase una vez, Tangle City y Las Iotas estaban conectadas por una autopista de dos carriles. Era la única ruta por la que podían circular los coches entre las dos ciudades. Con el tiempo, las ciudades crecieron, lo que provocó largos atascos en la autopista. Un día soleado, los alcaldes de las dos ciudades decidieron que era hora de solucionar el problema. Su primera idea fue: «¡Construyamos una autopista más grande con cuatro carriles en lugar de dos!». La idea parecía buena, pero la puesta en práctica fue difícil: un río, una vieja iglesia y un agricultor testarudo cerca de la carretera principal pusieron varios obstáculos en el camino hacia la finalización. Pero finalmente, la autopista se completó. Lamentablemente, no resolvió el problema del tráfico: los coches seguían teniendo que pasar por el mismo cuello de botella y las dos ciudades seguían creciendo, lo que pronto planteó a los dos alcaldes el mismo problema de siempre. ¿Deberían los alcaldes volver a construir autopistas más grandes para garantizar una fuerte conexión entre Tangle City y Las Iota? ¿O hay otras soluciones?
Acabamos de describir el concepto de rendimiento y la correspondiente congestión debida a la creciente demanda en una solución no escalable. Con demasiada frecuencia, estos dos conceptos, rendimiento y escalabilidad, se confunden en el contexto de la tecnología de ledger distribuido (DLT).
El rendimiento indica cuánta información puede procesarse, validarse y entregarse en la red por unidad de tiempo, y se mide en bytes por segundo (en el caso de los mensajes de tamaño variable, la métrica comúnmente utilizada de transacciones por segundo es sólo una forma aproximada de medir el rendimiento). El rendimiento es el equivalente al número de carriles de la autopista en el ejemplo anterior.
La escalabilidad, por su parte, es la capacidad de la red para hacer frente a una cantidad creciente de trabajo añadiendo recursos al sistema, por ejemplo, aumentando el número de nodos. Aunque los dos alcaldes mejoraron el rendimiento mejorando la infraestructura vial existente, la creciente demanda pronto alcanzó de nuevo la plena capacidad. Así que deberían haberse considerado varias alternativas para mejorar la vida de los ciudadanos: por ejemplo, construir más autopistas, sustituir los coches por un transporte público más eficiente (por ejemplo, autobuses o trenes), construir nuevas ciudades para distribuir a los ciudadanos sin crear cuellos de botella en las grandes metrópolis, etc. En esta entrada del blog, aclararemos la definición de escalabilidad y explicaremos cómo afecta a las DLT.
El término escalabilidad es aplicable a una amplia gama de contextos y dominios, como los protocolos de enrutamiento, los sistemas distribuidos, las redes, las bases de datos y los modelos de negocio. En el contexto de las DLT, nos interesa la escalabilidad de la carga, que es la capacidad de un sistema distribuido de expandirse (y contraerse) para acomodar cargas más pesadas (o más ligeras). Por ejemplo, Bitcoin no puede definirse como una DLT escalable; esto es por diseño, porque se ha preferido la seguridad al rendimiento. De hecho, independientemente del número de mensajes en espera de confirmación y del número de nodos en la red, el rendimiento total y el tiempo de finalización permanecen invariables. Algunas soluciones recientes han intentado superar este problema añadiendo, por ejemplo, Lightning Network en la capa 2 para crear canales de pago fuera de la cadena y reducir la carga de la cadena principal.
Aunque la externalización de las transacciones a otra capa aumenta fácilmente el rendimiento general, el reto de la escalabilidad de la cadena principal sigue sin resolverse: Abrir y cerrar canales Lightning sigue requiriendo una transacción cada uno en la capa base. Por lo tanto, incluso si la capa base sólo se utiliza para abrir y cerrar canales Lightning y todas las demás transacciones se producen en los canales Lightning, la escalabilidad seguiría estando limitada al número de canales Lightning que pueden abrirse y cerrarse, que en la red Bitcoin actualmente asciende a entre cinco y siete por segundo. Básicamente, Bitcoin ha añadido una segunda capa de carriles de autopista de alta velocidad por encima de la autopista real, pero la gente todavía tiene que tomar las mismas rampas de acceso para entrar en la autopista antes de poder utilizar los carriles de alta velocidad.
Otras soluciones no se embarcan en la externalización del rendimiento a capas adicionales, sino que presumen de la capacidad de la cadena principal para soportar varios cientos de miles de transacciones por segundo. Esto, sin embargo, conlleva un reto diferente: si una sola transacción tiene un tamaño de sólo 1024 bytes, 250.000 de esas transacciones por segundo equivaldrían a que dos nodos tuvieran que estar conectados a través de una conexión de datos de alta velocidad que permitiera más de 2 Gbps ¹. Esto llevaría a limitar en gran medida la participación en una red descentralizada a aquellos que pudieran permitirse una infraestructura costosa. Por lo tanto, esta solución podría imaginarse como una superautopista con cientos de carriles, pero difícil y extremadamente cara de construir y con ramales de salida bajo el control de unas pocas personas ricas seleccionadas.
Para lograr la escalabilidad, hay que superar el trilema de la blockchain (que afirma que sólo se puede elegir entre descentralización, seguridad y escalabilidad). Bitcoin elige la seguridad y la descentralización pero se queda corto en cuanto a la escalabilidad, mientras que otros competidores eligen la seguridad y la escalabilidad pero se quedan cortos en cuanto a la descentralización. Entonces, ¿cómo se pueden mantener las tres características?
Las soluciones más populares para abordar la escalabilidad en las DLT están representadas por un concepto llamado sharding: dividir la cantidad total de transacciones en particiones más pequeñas. La palabra sharding fue introducida en 1988 por el informe técnico «Overview of SHARD: a System for Highly Available Replicated Data» ², cuyo objetivo era utilizar hardware redundante para facilitar la replicación de datos. Con sharding en DLT, solemos referirnos al particionamiento horizontal, en el que las filas de una base de datos, que forman una única partición, son mantenidas por separado por diferentes servidores. Actualmente, varios proyectos de blockchain están desarrollando soluciones de fragmentación, como Ethereum, Zilliqa y Polkadot.
La fragmentación en las DLT permite a los nodos validar y almacenar sólo un subconjunto de los mensajes intercambiados en la red. Al reducirse la redundancia, el número de mensajes que la red puede manejar aumenta en comparación con una solución no shardeada. Sin embargo, con la fragmentación un atacante puede obtener más fácilmente una mayor influencia dentro de un solo shard, ya que la seguridad del shard (fragmento) es directamente proporcional a la tasa de hash acumulada (para los sistemas Proof of Work) o a el stack total (en los sistemas Proof of Stake y similares). En esencia, al dividir la cantidad de transacciones en trozos, se corre el riesgo de dividir también las características de seguridad y, por tanto, de reducir la seguridad por fragmento individual, a menos que se introduzca algún mecanismo de mitigación.
La estructura de Grafos Acíclicos Dirigidos (DAG) del ledger de IOTA ofrece un excelente punto de partida para construir una DLT escalable. Un ledger basado en un DAG no introduce el cuello de botella conceptual presente en la blockchain, en la que todos los mensajes están sujetos a un ordenamiento total, lo que conduce a fricciones inevitables en el protocolo: En IOTA, no hay un líder central que defina la creación del siguiente bloque de transacciones. Además, IOTA es un protocolo sin líder, lo que significa que cualquier nodo puede tener una percepción diferente del statu quo del estado del ledger mientras sigue acordando qué transacciones son válidas y cuáles no. Como resultado, en IOTA más mensajes significan una finalización más rápida.
Sin embargo, como se ha comentado anteriormente, los recursos también son limitados en IOTA, por lo que sigue siendo necesaria una solución al reto de la escalabilidad de la carga. El protocolo de IOTA es ligero y no requiere fees, lo que supone una ventaja fundamental en comparación con otras tecnologías similares. El departamento de investigación de la Fundación IOTA está estudiando soluciones que, de acuerdo con la visión de IOTA, exploten todo su potencial. Esperamos poder compartir pronto nuestros hallazgos.
Post original: Sharding: Throughput, Scalability and Why We Need Them
