Cuando se habla de la arquitectura blockchain, se mencionan con frecuencia los términos “capa 1” y “capa 2”. Se trata de conceptos importantes que sirven para dos propósitos: explicar cómo se construye una red blockchain y proporcionar una representación visual fácil de entender del aspecto de una red blockchain. Desglosemos estas ideas
Capa 1: definición
Imagina una tarta de boda, con diferentes pisos -capas, si quieres-, y la figura de una pareja en la parte superior. Esa hermosa tarta descansa sobre un soporte sólido, la base. A todos los efectos, ese robusto y sólido soporte de la tarta es la primera capa (capa 1) que sostiene la infraestructura de la tarta. Probablemente, puedes ver a dónde va esto. En una blockchain, la capa 1 es la red base sobre la que descansan las soluciones de la capa 2.
Capa 1: funcionalidad
Teniendo en cuenta este esquema visual, Cardano es la capa 1 (la red base), que a su vez incluye tres capas independientes:
- Capa de red
- Capa de consenso
- Capa del libro mayor
Capa de red
Esta capa mantiene las conexiones entre todos los nodos distribuidos en la red Cardano, obtiene nuevos bloques de la red a medida que son producidos por los nodos productores de bloques, construye las transacciones recién acuñadas en bloques y transmite los bloques entre los nodos.
Capa de consenso
Esta capa realiza dos funciones fundamentales:
- Ejecutar el protocolo de consenso Ouroboros. Esta capa toma decisiones como la adopción de bloques, la elección entre cadenas competidoras (si las hay) y la decisión de cuándo producir bloques propios; y
- Mantener todo el estado necesario para tomar las decisiones que se toman en la capa de consenso.
Capa del libro mayor
Esta capa especifica
-
Cómo es el estado del libro mayor; y
-
Cómo debe actualizarse el libro mayor para cada nuevo bloque.
La capa del libro mayor consiste exclusivamente en funciones puras que especifican las transiciones entre los sucesivos estados del libro mayor, tal y como se derivan de las reglas formales del libro mayor, utilizando el modelo contable Extended UTxO (EUTxO). Las transiciones de estado son impulsadas por el conjunto de transacciones contenidas en los bloques de Cardano, y por eventos importantes como las transiciones de límite de época.
La capa de consenso no necesita conocer la naturaleza exacta del estado del libro mayor, ni el contenido de los bloques, aparte de algunos campos de cabecera necesarios para ejecutar el protocolo de consenso.
En conjunto, estas tres capas forman la solución de capa 1 que es Cardano.
Capa 1: escalabilidad
Vuelve a mirar la tarta de bodas. Es grande, ¿verdad?, con todos esos pisos apilados unos encima de otros. Pero mira la base, el soporte de la tarta. Esa primera capa tiene unas dimensiones determinadas y no puede ser más grande. Igualmente, tiene que ser lo suficientemente grande como para soportar los pisos que están encima. Lo que se apoya en ella sólo puede tener un tamaño determinado, y ésta es exactamente la razón por la que las tartas de boda tienen varios pisos. Cada nivel (piense en una capa) añade algo a la base. Un nuevo relleno, glaseado, decoración, etc. En otras palabras, cada nivel amplía la capa base.
Las redes públicas descentralizadas se enfrentan a un problema similar. Al igual que en un puesto de pasteles sólo cabe una cantidad finita de rebanadas, la base (la capa 1) sólo puede procesar una cierta cantidad de transacciones. Si se intenta añadir más rebanadas de las que admite la tarta del soporte, empezarán a caerse de los bordes y el desorden arruinará el gran día de alguien. Del mismo modo, los nodos de una red de capa 1 sólo pueden procesar un número determinado de transacciones antes de que se produzca una congestión. A medida que la base de usuarios crece, también lo hace la necesidad de más nodos para procesar las transacciones. Para resolver este problema, la red debe escalarse, o de lo contrario las transacciones empezarán a caerse de los bordes, por así decirlo.
Hay formas de escalar una red de capa 1. Por ejemplo, aumentando el tamaño de los bloques para que éstos contengan más datos de las transacciones. El tamaño de los bloques se incrementó recientemente en 8KB hasta los 72KB (un aumento del 12,5%). Esta es una de las formas en que Cardano escalará en 2022.
Volviendo a nuestra imagen de la tarta de bodas, añadir niveles no sólo hace que la tarta sea más grande, sino que también introduce una característica muy útil: la capacidad de hacer que cada nivel sea diferente a la base. Podemos añadir diferentes sabores, rellenos, diseños, etc., independientemente de la primera capa. Para atender a diferentes “invitados” y diferentes preferencias. En blockchain, añadir una nueva capa (capa 2) no sólo permite que la capa 1 escale, sino que también permite que las transacciones y los procesos se realicen de forma independiente a la cadena principal (capa 1).
Soluciones de escalabilidad de la capa 1 en Cardano
Cardano se encuentra ahora en la fase de desarrollo Basho, que consiste en escalar y optimizar. Mientras que la red está gestionando actualmente la demanda de manera muy eficaz, el ecosistema de aplicaciones descentralizadas (DApp) está creciendo rápidamente y seguirá aumentando la demanda en el sistema. Para hacer frente a esto, se están desplegando múltiples métodos de escalabilidad (incluyendo soluciones de capa 1 y capa 2) en Cardano para incorporar primero cientos de miles, y luego millones de nuevos usuarios.
Aumento del tamaño de los bloques
Cuanto más grande sea el bloque, más transacciones podrá realizar. El primer bloque acuñado en Cardano tenía un tamaño de 665 bytes (0,665KB). Hoy en día, los bloques tienen un tamaño de 72KB. Esto supone un aumento de más del 10.000%. Con el tiempo se aplicarán nuevos aumentos basados en la monitorización continua del sistema y la salud general de la red.
Pipelining
Mejora los tiempos de propagación de los bloques al unir la validación y la propagación. El objetivo es que los bloques se propaguen al menos al 95% de los pares en cinco segundos, reduciendo el “tiempo muerto” entre bloques (la sobrecarga de propagación de bloques). Esto proporciona el margen necesario para realizar cambios de escala más agresivos, como aumentar el tamaño de los bloques o incrementar los límites de los parámetros de Plutus.
Endosantes de entrada
Más adelante, los endosantes de entrada mejorarán los tiempos de propagación de bloques y el rendimiento al permitir que las transacciones se separen en bloques preconstruidos. Esto mejora la consistencia de los tiempos de propagación de los bloques y permite una mayor tasa de transacciones.
Parámetros de memoria/CPU para Plutus
El uso de la memoria es más eficiente en toda la cadena. En concreto, hay mejoras de memoria en la gestión de la salida de transacciones no gastadas (UTXO), la distribución de participaciones, la distribución de participaciones en vivo y pools, y la representación de hash.
Mejoras en los scripts de Plutus
Uso aún más eficaz del potente modelo EUTxO a través de la optimización de los contratos inteligentes, incluyendo:
- Entradas de referencia (CIP-0031) - Los scripts de Plutus pueden inspeccionar las entradas de transacciones sin necesidad de gastarlas. Esto significa que no es necesario crear UTXOs simplemente para inspeccionar la información que contiene una entrada.
- Plutus Datums (CIP-0032) - Los datums pueden adjuntarse directamente a las salidas en lugar de los hashes de datum. Esto simplifica el uso de los datos, ya que el usuario puede ver el dato real en lugar de tener que proporcionar el dato que coincide con el hash dado.
- Compartir scripts (CIP-0033) - Las referencias a scripts de Plutus pueden asociarse a las salidas de las transacciones, lo que significa que pueden registrarse en la cadena para su posterior reutilización. No será necesario suministrar una copia de la secuencia de comandos con cada transacción, reduciendo enormemente la fricción para los desarrolladores. La reutilización de scripts en múltiples transacciones reduce significativamente el tamaño de las mismas, mejorando el rendimiento y reduciendo los costes de ejecución de los scripts.
Mejoras en el nodo
Las mejoras en el nodo ayudarán a distribuir uniformemente los cálculos de participación y recompensas entre las épocas, proporcionando así un mayor margen de maniobra para el aumento del tamaño de los bloques. Además, el uso de la memoria es ahora más eficiente. La compactación de la memoria reduce la huella del RSS, y el uso compartido de la memoria significa que necesitamos menos datos instanciados. La versión 1.34.1 del nodo, de marzo de 2022, reduce los picos de carga en los puntos críticos, incluido el límite de las épocas.
Almacenamiento en disco
Al almacenar partes del estado del protocolo en el disco, los nodos necesitarán guardar menos en la memoria, lo que significa que los sistemas con limitaciones de RAM podrán ejecutar nodos siempre que tengan suficiente almacenamiento, y la memoria no representará un cuello de botella para la escalabilidad. Esto permitirá un crecimiento significativo del estado de la blockchain.
Interludio: el trilema blockchain
La escalabilidad de un sistema distribuido -como una blockchain- es un dilema complejo.
Existe un consenso generalizado de que un sistema blockchain “adecuado” debe tener tres propiedades: escalabilidad, seguridad y descentralización. Pero una creencia igualmente extendida es el llamado trilema, que dicta que los sistemas descentralizados sólo pueden proporcionar dos de estas propiedades, sacrificando la tercera. Postulado por primera vez por el creador de Ethereum, Vitalik Buterin, el trilema sugiere que los desarrolladores siempre deben aceptar un compromiso, o una compensación, cuando diseñan redes de blockchain. Este compromiso significa que una propiedad debe “sufrir” para que las otras dos sean posibles.
Por ejemplo, cuantos más nodos tenga una red, más descentralizada estará, pero también significa que más nodos deben ser fiables para mantener la seguridad. Para mantener la seguridad, hay que introducir tarifas que hagan que el coste de un posible ataque sea prohibitivo. Sin embargo, una red debe incentivar la participación, por lo que los costes por nodo deben ser relativamente bajos. Además, la propia característica de inmutabilidad implica que los datos de la blockchain se añadirán mientras exista la blockchain, pero nunca se borrarán, lo que significa que la blockchain seguirá creciendo. Una red más grande significa que se necesitan más recursos computacionales para mantener el rendimiento. Un mejor rendimiento requiere un mejor hardware, lo que significa que las recompensas deben ser suficientes para que la inversión merezca la pena. Y así sucesivamente.
Escalado vertical y horizontal
Resolver este trilema requiere un enfoque cuidadoso y equilibrado, para que los tres elementos se mantengan en equilibrio.
En teoría, un sistema blockchain seguirá creciendo indefinidamente. A medida que más nodos formen parte del sistema, fluirán más datos y activos, y habrá que procesar más transacciones. Todo esto requiere potencia de cálculo y almacenamiento. Con el tiempo, la demanda seguirá creciendo, por lo que el sistema subyacente tendrá que escalar en consecuencia para evitar una caída drástica del rendimiento.
Existen dos opciones de escalado: vertical y horizontal.
Escalado vertical
Esta técnica consiste en ampliar las capacidades de cálculo de los nodos individuales añadiendo más memoria y mejores componentes. En otras palabras, se trata de actualizar el hardware de la red para conseguir un mayor rendimiento en general.
Contar con una red que incluya nodos de alto rendimiento permite, por ejemplo, tamaños de bloque mayores y una difusión de bloques más rápida. Pero las desventajas son que la descentralización será limitada, dados los elevados costes de funcionamiento, lo que hará que los nuevos operadores de nodos se lo piensen dos veces antes de unirse y, por tanto, frenará la expansión de la red. Además, una red de este tipo supondrá mayores costes para los nodos validadores.
Escalado horizontal
A diferencia del escalado vertical, el escalado horizontal puede lograrse de dos maneras. Una, simplemente añadiendo más ordenadores (nodos) a la red existente. La razón es que, al añadir más nodos, la red es capaz de procesar más transacciones.
Y dos, mediante el uso de cadenas laterales, que eliminarán parte de la carga computacional de la cadena principal y, como ventaja añadida, permitirán la personalización en forma de diferentes protocolos de consenso o modelos de gobernanza, por ejemplo, para adaptarse a un proyecto o industria concretos. Desde el punto de vista de la seguridad, las cadenas laterales pueden crear un ecosistema más seguro al aislar las posibles amenazas a la cadena principal. Si una cadena lateral se ve comprometida de alguna manera, el riesgo se limita a esa cadena lateral, salvaguardando así el resto de la red.
Capa 2: abordar el dilema de la escalabilidad
En términos generales, las soluciones de capa 2 abordan el problema de escalabilidad inherente a las cadenas de capa 1. Construidas sobre una blockchain existente (como si se añadiera un nuevo nivel a una tarta de boda), los protocolos de capa 2 realizan una gran cantidad de trabajo de procesamiento que, de otro modo, tendría lugar en la cadena principal. Esto aumenta el rendimiento de la cadena principal. Una ventaja añadida es que, mientras la solución de capa 2 hace el trabajo duro, la capa 1 conserva su seguridad.
Capa 2: definición
Un protocolo adicional, fuera de cadena, que funciona sobre la blockchain de la capa 1. Las partes pueden transferir fondos de forma segura desde la blockchain a un protocolo fuera de cadena, liquidar las transacciones en este protocolo independientemente de la cadena subyacente, y transferir de forma segura los fondos de vuelta a la cadena subyacente cuando sea necesario. Los protocolos de capa 2 mejoran el rendimiento general y la escalabilidad porque reducen la congestión de la red.
Soluciones de escalabilidad de capa 2 en Cardano
Cadenas laterales
Una cadena lateral, definida como una forma de permitir que varias blockchain se comuniquen entre sí y que una reaccione a los eventos de la otra, es una blockchain independiente conectada a una blockchain principal (la cadena “principal”, también conocida como cadena matriz), a través de un mecanismo bidireccional (el “puente”) que permite que los tokens y otros activos digitales de una cadena se utilicen en otra y los resultados se devuelvan a la cadena original. Los activos pueden moverse entre cadenas según sea necesario. Una sola cadena principal puede tener múltiples cadenas laterales interoperables conectadas a ella, que pueden funcionar de maneras completamente diferentes. Las cadenas laterales EVM en Cardano incluyen Milkomeda de dcSpark y el proyecto de cadena lateral EVM de IOG.
Hydra
Hydra es la solución de escalabilidad de capa 2 para Cardano, cuyo objetivo es aumentar la velocidad de las transacciones a través de una baja latencia y un alto rendimiento y minimizar el coste de las transacciones.
Hydra Head es el primer protocolo de la familia Hydra y representa la base para escenarios de despliegue más avanzados que dependen de canales de estado isomórficos y multipartitos. Al proporcionar medios más eficientes para procesar las transacciones fuera de cadena para un conjunto de usuarios, al tiempo que se utiliza el libro mayor de la cadena principal como capa de liquidación segura, Hydra Head mantiene las garantías de seguridad mientras permanece débilmente acoplado a la cadena principal. Al no requerir un consenso global, puede adaptarse a una amplia gama de aplicaciones. Además, Hydra Head permite que las tarifas de transmisión, los presupuestos de ejecución de scripts y otros parámetros del protocolo se configuren tan bajos o altos como lo requiera el caso de uso. Por ejemplo, esto es crucial para permitir las microtransacciones.
Además, Hydra Head introduce el concepto de canales de estado isomórficos: es decir, reutilizar la misma representación del libro mayor para producir hermanos de libro mayor uniformes y fuera de cadena, a los que llamamos Heads (de ahí el nombre Hydra). Específicamente para Cardano, esto significa que los activos nativos, los tokens no fungibles (NFT) y los scripts de Plutus están disponibles dentro de cada cabeza de Hydra. El isomorfismo permite una extensión natural del sistema, en lugar de uno atornillado.
Las cabezas Hydra se distinguen por lograr una finalidad casi instantánea dentro de una cabeza. El proceso de creación y cierre de una cabeza puede llevar unos cuantos bloques, pero una vez establecido, las transacciones pueden fluir rápidamente entre los participantes de la colaboración. Como las cabezas Hydra son isomórficas y también utilizan el modelo EUTXO, pueden procesar simultáneamente transacciones no conflictivas, lo que, unido a una buena conexión en red, permite un uso óptimo de los recursos disponibles.
Otras soluciones de escalabilidad
Computación fuera de cadena
La descarga de parte de la computación, por ejemplo con la ejecución asíncrona de contratos (ACE), puede impulsar una mayor eficiencia de la red central. Las transacciones se producen fuera de la propia blockchain, pero pueden ofrecer transacciones rápidas y baratas a través de un modelo de confianza.
Mithril
Para lograr una mayor escalabilidad, es necesario abordar la complejidad de las operaciones críticas que dependen logarítmicamente del número de participantes. Mithril es un protocolo desarrollado por IOG que actúa como un esquema de firma de umbral basado en la participación que permite un aprovechamiento transparente, seguro y ligero de la participación. Mithril mejorará la sincronización de la cadena manteniendo la confianza. El resultado es una rápida y eficiente agregación de múltiples firmas sin comprometer las características de seguridad.
Conclusión
Una red blockchain funciona de forma misteriosa, y algunos de los conceptos que rodean a un ecosistema de libro mayor descentralizado pueden ser difíciles de entender.
No así la capa 1 y la capa 2, si se utiliza la visualización de la tarta de capas aquí expresada.
- Capa 1 (el soporte de la tarta) = la red base robusta y segura sobre la que descansan las soluciones de la capa 2
- Capa 2 (los niveles del pastel) = soluciones construidas sobre la base para resolver los problemas de escalabilidad inherentes
Esta es la forma más sencilla de visualizar y entender qué son las capas 1 y 2.
Puntos clave
- Cardano es la capa 1 (la red base)
- Una solución de capa 2 es una estructura construida sobre una cadena de capa 1 para resolver los problemas de escalabilidad y velocidad de las transacciones de esta última. La red Lightning de Bitcoin es un ejemplo de solución de capa 2, al igual que Hydra para Cardano
- Hay dos opciones de escalado: vertical y horizontal
- El escalado vertical consiste en ampliar las capacidades de cálculo de los nodos individuales añadiendo más memoria y mejores componentes.
- El escalado horizontal puede lograrse de dos maneras. Una, simplemente añadiendo más ordenadores (nodos) a la red existente, y dos, utilizando cadenas laterales, que eliminarán parte de la carga computacional de la cadena principal.
- Cardano verá implementada una serie de métodos de escalabilidad a lo largo de 2022/2023
Traducción al español de “Layer 1 & Layer 2: all you need to know”, publicado por Fernando Sanchez, Escritor Técnico de IOG, el 4 de Agosto de 2022