Escalabilidad y Sidechains

Tiempo de lectura estimado: 10 minutos

Los protocolos de consenso de Blockchain tienen una gran limitación : cada nodo debe procesar y almacenar cada transacción. Un uso masivo de dApps hará que el número de transacciones procesadas por la red no puedan exceder la cantidad de transacciones que los nodos que participen en la cadena pueden procesar. Con el crecimiento del número de nodos, aumentará la latencia y, el tiempo para lograr el consenso será cada vez más elevado. Sin embargo, es importante resaltar que esto es debido a una de las características intrínsecas de Blockchain, la descentralización. Esto requiere que cada nodo procese cada transacción y tenga una copia de su estado, haciendo que los nodos sean seguros, las transacciones válidas y coherentes con el estado histórico de la cadena, y evitar que cualquier actor malicioso acose la red. La descentralización ofrece beneficios críticos entre los que podríamos señalar la tolerancia a las fallas bizantinas, seguridad, neutralidad, autenticidad y protección de doble gasto.

Un enfoque tradicional para resolver la escalabilidad es añadir más potencia de computación al sistema, lo que podría ser relativamente fácil para las redes tradicionales en donde se puede agregar más servidores. En la cadena de bloques esto es poco realista porque implicaría agregar potencia computacional a cada nodo. Por otra parte, si pudiéramos controlar qué nodos pueden participar en el proceso de consenso, comprometeríamos su descentralización.

El objetivo en cuestión, para resolver los problemas de escalabilidad, pasa por entender que, si no todos los nodos validan cada transacción, necesitamos alguna manera de que los nodos, que no están validando un determinado bloque, garanticen que ese bloque es seguro, prestar especial atención a la disponibilidad de los datos y al orden canónico (serialización) de las transacciones procesadas por los nodos en paralelo. Podemos encontrarnos con un importante aumento de las tarifas de transacción, de las transacciones pendientes y del tamaño de las redes, cuyos problemas están básicamente relacionados con el tiempo que se tarda en poner una transacción en el bloque y en llegar al consenso.

La capacidad de transacción teórica de un nodo de Ethereum difiere de la capacidad real debido al gas limit. Digamos que el aumento del límite de bloques no depende linealmente del crecimiento de los usuarios. Este límite se establece para evitar que los actores malintencionados puedan dañar la red tratando de crear bloques muy grandes o sobrecargar nodos con la intención de saturarlos. Estos bloques podrían hacer que los nodos fallaran en la cadena al no poder participar en el consenso. En Ethereum esta característica se utiliza para prevenir ataques DoS y para evitar que cualquier actor malicioso desarrolle grandes bloques que sobrecarguen los nodos lentos o más pequeños. Esto provocaría, inoperabilidad y debilidad en la red dado que menos nodos están respaldando y utilizando los recursos necesarios para asegurar el correcto comportamiento de la cadena.

Entre las soluciones que se plantean podemos destacar, con su ventajas e inconvenientes, el aumento del tamaño de los bloques, la reducción del tiempo por bloque, el particionamiento, modificaciones en los protocolos de consenso y los canales fuera de la cadena o sidechains. Dos de los problemas genéricos que se han señalado han sido los relacionado con los incentivos, y los problemas de almacenamiento derivados de que bloques que acojan un mayor número de transacciones. En concreto estas son las soluciones que podríamos destacar:

1. Canales fuera de la cadena

Esta idea nació con Lightening Networks. En este punto es interesante transcribir unas declaraciones publicadas recientemente en beincrypto: “El proponente de Bitcoin Cash, Roger Ver, ha hecho una comparación entre el wrapped Bitcoin (Bitcoin tokenizado en Ethereum) y el Lightning Network, concluyendo que el aumento de uno ha demostrado que el otro ha sido un ‘fracaso total’ en términos de una solución de escalado”.

Un canal de estado fuera de la cadena es el nombre que recibe las interacciones que se realizan fuera de Blockchain. Esto se hace en un entorno seguro proporcionado por la criptografía que hace que estas interacciones fuera de la cadena no impliquen un riesgo creciente para los participantes, al tiempo que proporciona avances significativos en coste y velocidad. Se cree que esta solución es una de las más importantes para hacer que las cadenas de bloques sean capaces de escalar con el fin de soportar unos mayores niveles de uso y en especial para la realización de micro pagos en Ethereum o Bitcoin, donde la alta demanda ha hecho crecer las tarifas para aquellas transacciones restrictivas y que no se pueden llevar a cabo de manera eficiente.

Un ejemplo es Raiden Network.

2. Cálculos fuera de la Cadena

Tenemos el ejemplo de TrueBit que ejecuta de forma verificable cálculos fuera de la cadena que serían muy caros de ejecutar dentro de la cadena. En resumen, los participantes de la red, llamados Solvers, realizan los cálculos mediante contratos inteligentes fuera de la cadena y envían una solución del problema junto con un depósito. Si el Solver es correcto, entonces el solucionador será recompensado y el depósito devuelto. Si por el contrario el Solver hiciera trampa, el depósito se perdería. Las disputas se resuelven en la cadena de bloques utilizando el Juego de Verificación (Los "Verificadores" comprueban el trabajo fuera de la cadena).

3. Childchains

Las childchains se basan en la creación de nuevas cadenas de bloques con características especiales, reglas y, por lo general, disponen de su propio token nativo. Se ejecutan en la “sombra” de una cadena superior llamada raíz o cadena principal. Existen dos sub tipologías:

3.1. Cadenas secundarias integradas dentro de la cadena raíz y que funcionan como una extensión de esta. Estas cadenas no tienen sus propios validadores, sino los llamados forgers (falsificadores) que envían bloques con transacciones desde la cadena secundaria a la cadena raíz (bundlers). Lo que persigue este caso de uso, es mantener la cadena raíz lo más simple posible, verificando la validez de los bloques secundarios en su conjunto. Con esto, la cadena principal sólo necesita centrarse en su trabajo principal: la verificación y el consenso. El problema con este tipo de cadenas es que interactúan completamente con la cadena raíz. Suelen están destinadas a fines semiprivados y constituyen una solución para desarrolladores y empresas.

3.2. La cadena raíz sólo se encarga de las validaciones de los bloques en caso de disputas o fallos bizantinos. Decide, si o cual bloque es válido. Este tipo de cadenas tienen sus propios mineros y validadores y actúan como un Blockchain completamente separado, asegurado en última instancia por su cadena raíz. Las cadenas secundarias procesan y almacenan transacciones secundarias para que la cadena raíz se libere de trabajo al recaer sobre las cadenas secundarias.

El principal problema para este tipo de cadena está relacionado con su independencia de la cadena raíz. Las childchain son responsables de su propia seguridad y por su tamaño menor en comparación con la cadena raíz, pueden ser atacadas más fácilmente. El principal problema de las cadenas secundarias, en cualquiera de sus formas, es la complejidad de su protocolo. Para su implementación, debemos asegurarnos de que un fallo en la cadena secundaria no pondrá en peligro la seguridad y el funcionamiento de la cadena raíz, abriendo una puerta a los atacantes.

Algunos ejemplos de este tipo de sidechains son Lumino, Raidos y Omisego (que se asemeja la Loom Network), Ardor y Jerulida.

Y debemos hacer especial mención a:

4. Plasma

Introducida en primer lugar en Ethereum, parte de la idea de la creación de una capa que ayuda a distribuir el esfuerzo computacional de la red dependiendo de las diferentes funcionalidades de alto nivel que un Blockchain raíz puede controlar. El aspecto nuclear de Plasma es su intento de enviar la menor información posible a la cadena raíz. En las cadenas secundarias de plasma la verificación sólo se realiza en caso de fallos bizantinos. Los childchains sólo divulgan el hash de encabezado de bloque con el fin de determinar la validez del bloque. Ninguna otra información se envía a la cadena raíz.