Desde el inicio, una de las principales limitaciones que nos hemos encontrado en la tecnología Blockchain a la hora de desarrollar soluciones es la escalabilidad. Este concepto se refiere a la capacidad de poder seguir ofreciendo un servicio sin comprometer la funcionalidad de este con el aumento de las transacciones o peticiones que se realizan.

Esta limitación viene heredada de lo que se conoce como el trilema de la tecnología blockchain, el cual se basa en tres pilares fundamentales: la seguridad, la descentralización y la escalabilidad. Este trilema, al igual que otros, alude a que cualquier implementación de red tiene que escoger dos de esas tres características y dejar una de ellas en un segundo plano. Por ello, por definición, las redes blockchain públicas deben ser principalmente seguras y descentralizadas, por lo tanto, la escalabilidad queda relegada. Por el contrario, en el caso de las blockchain privadas, son seguras y escalables, pero no son tan descentralizadas como las públicas.

Ethereum, como red blockchain pública no iba a ser menos y, durante todos estos años han sucedido diferentes acontecimientos que han hecho que su funcionalidad se viese comprometida. El primero de ellos acaeció allá por finales del año 2017 cuando el mundo de las ICO (Initial Coin Offering) estaba en pleno auge. Además, esta tendencia coincidió con los primeros NFTs de la historia de esta plataforma, los Cryptokitties, los cuales llegaron a acaparar el 15% del tráfico de la red.

El segundo, lo estamos viviendo actualmente desde el verano de 2020, ya que hay dos ecosistemas que están siendo adoptados de manera masiva: el DeFI (decentralized Finance o finanzas descentralizadas) y el de los NFTs (Non Fungible Tokens).

Estos problemas de escalabilidad son debidos al algoritmo de consenso actual de la red principal (o mainnet) de Ethereum, el Proof of Work. Este el algoritmo es computacionalmente muy costoso y hace que el número de transacciones por segundo en esta red sea de aproximadamente de entre quince y veinte.

Impacto del gas

Por otro lado, otra de las limitaciones que no podemos olvidar y que, por tanto, podemos encontrar con esta tecnología a la hora de desarrollar soluciones, es el precio del gas. Para las personas que no estéis familiarizadas con este término, se utiliza para evitar ataques en la red o fallos de programación en los contratos inteligentes, los cuales podrían dejar la red inutilizable.

Toda transacción de escritura conlleva un coste asociado llamado gas y este coste, pagado en ether, se calcula teniendo como referencia el coste computacional de la operación.

Además, la transacción puede ser ejecutada de manera más rápida o lenta en función del ether que queremos pagar por cada unidad de gas. Por lo tanto, cuando la red está muy congestionada por esa mala escalabilidad y aumentamos lo que pagamos por el gas para acelerar la transacción, aumentamos lo que se conoce como precio del gas o “gas price”.

¿Y por qué puede ser esto considerado como un problema en el mundo empresarial?, os preguntaréis. La respuesta es sencilla y es por el coste asociado que encontramos a la hora de adquirir o vender un producto software.

Imaginad ahora que queréis hacer un servicio que se despliegue sobre la red pública Ethereum, ¿cómo sería su monetización si depende del valor de la moneda de ether y del gas que hay que pagar por esas transacciones? ¿Cómo haríamos para cubrir costes cuando hay picos de transacciones en la red y que acaban convirtiéndose en una subida de precios incontrolable?

Por último, y no menos importantes, otras dos limitaciones son el coste energético que supone la validación de los bloques utilizando el algoritmo de consenso de PoW y el espacio en disco que supone almacenar la cadena de bloques de la red en la actualidad.

Por esta razón cada vez son más las soluciones que aparecen en el ecosistema que de manera independiente o conjunta tratan de mitigar estas limitaciones. Las podemos dividir en dos grupos.

Soluciones de primera capa o “Layer 1”

Este tipo de soluciones requieren cambios en el protocolo de la red de Ethereum y están contempladas en lo que se conoce como Ethereum 2.0. Su objetivo es atacar el trilema de Blockchain y conseguir que la red sea capaz de gozar de las tres características de las que hablábamos al principio del artículo: seguridad, escalabilidad y descentralización.

Con este propósito, por un lado, la comunidad de Ethereum ha decidido cambiar el algoritmo de consenso de la red de Proof of Work (PoW) a Proof of Stake (PoS) y, por otro, fragmentar la red en distintas subredes realizando una técnica llamada “sharding”.

Centrándonos en el primer caso, es importante entender la principal diferencia entre los dos algoritmos de consenso. Mientras que PoW valida transacciones resolviendo un problema computacional, lo cual hace que energéticamente sea muy costoso, PoS utiliza las monedas que apuestan los usuarios (stake) para validar las transacciones, eliminando la necesidad de tener potencia de cálculo.

Este cambio, en el algoritmo de consenso, ya ha comenzado con una red conocida como “Beacon chain”, la cual ya ha sido implementada y se encuentra en periodo de prueba. El objetivo de esta cadena es utilizar el algoritmo de consenso de Proof of Stake y coordinar los shards o subredes. Esta cadena no puede manejar cuentas o contratos inteligentes. Estaba planeado que para el año 2021 esta red se fusionara con la red principal de Ethereum, sin embargo, todo apunta a que se va a retrasar. Además, esto facilita el funcionamiento de un nodo al mantener bajos los requisitos de hardware.

En cuanto al sharding, esto no es una técnica propia de Blockchain si no que ya es utilizada en bases de datos convencionales. Esta solución trata de dividir la cadena en 64 subredes o shards de manera horizontal para repartir la carga de las transacciones. Esta técnica permite un mayor rendimiento ya que cada subred opera un conjunto de transacciones de manera paralela. De esta manera, un validador (equivalente a lo que sería un minero en PoW) ya no tendrá que procesar todas las transacciones que suceden en toda la red, aligerando así la carga transaccional y mejorando la escalabilidad.

Soluciones de segunda capa o “Layer 2”

En cuanto a las soluciones de segunda capa, la intención final es minimizar el número de interacciones con la cadena principal de Ethereum agrupando así, las transacciones de manera segura.

De este modo, al eliminar el número de interacciones, se disminuye considerablemente el coste que deben de pagar los usuarios para escribir en la red y, por otro lado, se incrementa el rendimiento de transacciones procesadas, debido a que se procesa de manera grupal y no de manera individualizada.

Como soluciones de segunda capa encontramos dos tipos de enfoques: canales y sidechains y rollups.

• Canales: Esta técnica es utilizada cuando dos usuarios quieren realizar una serie de transacciones seguidas en un periodo de tiempo corto, como por ejemplo una partida de ajedrez. El objetivo es que, mediante un contrato inteligente, se realicen únicamente dos transacciones en la red: la inicial para abrir el canal y la final para cerrarlo. Mientras el canal esté abierto, los usuarios pueden intercambiar todas las transacciones que deseen de manera instantánea sin tener que depender de la validación de la cadena de bloques.

Por lo tanto, si estuviéramos en esa partida de ajedrez, se escribiría el inicio de la partida para abrir el canal, se interactuaría en cada una de las jugadas en el mismo, y en el momento del jaque mate se cerraría.

• Sidechains y rollups: Una sidechain, o cadena de bloques alternativa, es una red blockchain independiente que se utiliza para mejorar las características de la cadena principal. Una de las sidechains que más están siendo adoptadas en la actualidad es la red de Polygon compatible con Ethereum.

Asimismo, un rollup es una solución que permite agrupar un grupo de transacciones en una única transacción. Explicado de otra manera, las transacciones se realizan en una sidechain y, posteriormente, una vez terminada la interacción, se envían los datos estrictamente necesarios de manera agrupada a la cadena de bloques principal.

A su vez, los rollups se clasifican en dos tipos, en función del modelo de seguridad que se quiera implementar:

• ZK-Rollup: ejecuta el cálculo fuera de la cadena y envía una prueba de validez, siguiendo el protocolo de conocimiento cero (Zero Knowledge Proof), y envía una prueba de validez a la cadena principal.

• Optimistic Rollup: asume que las transacciones siempre son válidas por defecto y el cálculo solo es ejecutado en caso de un desafío. En otras palabras, se asume que toda transacción que se agrega funciona sin cometer fraudes y solo se proporcionan pruebas en caso de fraude. 

Por lo tanto, podemos determinar que en el ecosistema Blockchain hay una clara tendencia que se centra en solucionar los problemas de escalabilidad de las redes blockchain públicas. Una de las soluciones que más estamos observando en el corto plazo y que ya se encuentran operativas, son las soluciones de segunda capa. Un claro ejemplo es la adopción de Polygon como sidechain en el ecosistema DeFi. En concreto, esta red está teniendo más transacciones que la red de Ethereum.

Sin embargo, con respecto a las soluciones de primera capa, hoy en día, estas soluciones están todavía en un periodo de desarrollo o prueba por lo que no es usual verlas aplicadas en entornos productivos.

No obstante, próximamente podremos ver estas soluciones ya aplicadas en el ecosistema y podremos determinar cuál de ellas ha triunfado sobre todas las demás.

Ilustración 1 Photo by Max Ostrozhinskiy on Unsplash