Traducción al español de “Enter the Hydra: scaling distributed ledgers, the evidence-based way”
Publicado por Aggelos Kiayias en el blog de IOHK el 26 de Marzo de 2020
Aprende sobre Hydra: el protocolo de libro contable de múltiples cabezas
La escalabilidad es el mayor desafío para la adopción blockchain. Aplicando un enfoque basado en principios y pruebas, hemos llegado a una solución para Cardano y redes similares: Hydra. Hydra es la culminación de una extensa investigación y un paso decisivo para permitir que las redes descentralizadas escalen de manera segura a los requerimientos globales.
¿Qué es la escalabilidad y cómo la medimos?
La escalabilidad de un sistema de libro mayor distribuido se refiere a la capacidad de proporcionar un alto rendimiento de transacción, baja latencia y un mínimo de almacenamiento por nodo. Estas propiedades han sido repetidamente promocionadas como críticas para el despliegue exitoso de protocolos blockchain como parte de sistemas del mundo real. En cuanto al rendimiento, se informa de que la red VISA maneja un promedio de 1.736 transacciones de pago por segundo (TPS) con capacidad para manejar hasta 24.000 TPS y se utiliza con frecuencia como comparación de referencia. Es evidente que se desea que la latencia de las transacciones sea lo más baja posible, con el objetivo último de que parezca instantánea para el usuario final. Otras aplicaciones de los libros mayores distribuidos tienen una amplia gama de requisitos diferentes en cuanto a estas mediciones. Cuando se diseña un libro mayor distribuido de uso general, es natural esforzarse por sobresalir en los tres aspectos.
El despliegue de un sistema que proporcione un escalado satisfactorio para un determinado caso de uso requiere una combinación apropiada de dos aspectos independientes: adoptar un diseño algorítmico adecuado y desplegarlo sobre una infraestructura de hardware y de red subyacente apropiada.
Cuando se evalúa un diseño algorítmico particular, considerar los números absolutos en términos de métricas específicas puede ser engañoso. La razón es que esas cantidades absolutas deben referirse a una determinada configuración subyacente de hardware y de red que puede desdibujar las ventajas y desventajas de determinados algoritmos. De hecho, un protocolo mal diseñado puede seguir funcionando lo suficientemente bien cuando se despliega sobre hardware y redes de calidad superior.
Por esta razón, es más perspicaz evaluar la capacidad de un protocolo para alcanzar los límites físicos de la red y el equipo informático subyacentes. Esto puede lograrse comparando el protocolo con protocolos sencillos de tipo “hombre de paja”, en los que se han eliminado todos los elementos de diseño. Por ejemplo, si queremos evaluar la sobrecarga de un algoritmo de encriptación, podemos comparar el rendimiento de comunicación de dos puntos finales que utilizan encriptación con su rendimiento cuando simplemente intercambian mensajes no cifrados. En tal experimento, la tasa absoluta de mensajes por segundo no es importante. La conclusión importante es la sobrecarga relativa que añade el algoritmo de encriptación. Además, en caso de que la sobrecarga se aproxime a 0 para alguna configuración de la configuración experimental, podemos concluir que el algoritmo se aproxima a los límites físicos de la capacidad de paso de mensajes de la red subyacente para esa configuración en particular, y por lo tanto es óptimo en este sentido.
Hydra - vista de 30.000 pies
Hydra es una arquitectura de escalabilidad fuera de la cadena para libros mayores distribuidos, que aborda los tres desafíos de escalabilidad mencionados anteriormente: alto rendimiento de las transacciones, baja latencia y almacenamiento mínimo por nodo. Si bien Hydra se ha diseñado conjuntamente con el protocolo Ouroboros y el libro mayor de Cardano, puede emplearse también en otros sistemas, siempre que compartan las características salientes necesarias con Cardano.
A pesar de ser un sistema integrado destinado a resolver un problema - la escalabilidad - Hydra consta de varios subprotocolos. Esto es necesario porque el propio ecosistema de Cardano es heterogéneo y consta de múltiples entidades con diferentes capacidades técnicas: el sistema presta apoyo a los productores de bloques con stake pools asociados, a las billeteras de alto rendimiento utilizadas por las centrales, pero también a los usuarios finales con una amplia variedad de características de rendimiento y disponibilidad computacional. No es realista esperar que un enfoque de un solo protocolo que sirva para todos sea suficiente para proporcionar una escalabilidad general a un conjunto tan diverso de participantes en la red.
La arquitectura de escalabilidad de Hydra puede dividirse en cuatro componentes: el protocolo de cabeza, el protocolo de cola, el protocolo de comunicación cruzada de cabeza y cola, así como un conjunto de protocolos de apoyo para el enrutamiento, la reconfiguración y la virtualización. La pieza central es el protocolo de “cabeza”, que permite a un conjunto de participantes de alto rendimiento y alta disponibilidad (como los stake pools) procesar muy rápidamente un gran número de transacciones con requisitos mínimos de almacenamiento mediante un canal estatal multipartito, concepto que generaliza los canales de pago bipartitos tal como se aplican en el contexto de la red Lightning. Se complementa con el protocolo de “cola”, que permite a esos participantes de alto rendimiento proporcionar escalabilidad a un gran número de usuarios finales que pueden utilizar el sistema desde dispositivos de baja potencia, como los teléfonos móviles, y que pueden estar desconectados durante largos períodos de tiempo. Si bien las cabezas y colas ya pueden comunicarse a través de la cadena principal de Cardano, el protocolo de comunicación cruzada de cabeza y cola proporciona una variante eficiente fuera de la cadena de esta funcionalidad. Todo esto está unido por el enrutamiento y la gestión de la configuración, mientras que la virtualización facilita una comunicación más rápida generalizando la comunicación de cabeza y cola.
El protocolo de cabeza Hydra
El protocolo de cabeza Hydra es el primer componente de la arquitectura de Hydra que se da a conocer públicamente. Permite a un conjunto de participantes crear un canal de estado fuera de la cadena (llamado cabeza) en el que pueden ejecutar contratos inteligentes (o procesar transacciones más sencillas) entre sí sin interactuar con la blockchain subyacente en el caso optimista de que todos los participantes de la cabeza se adhieran al protocolo. El canal de estado ofrece una liquidación muy rápida y un alto rendimiento de las transacciones; además, requiere muy poco almacenamiento, ya que el historial de transacciones fuera de la cadena puede borrarse tan pronto como su estado resultante se haya asegurado mediante una operación “instantánea” fuera de la cadena.
Incluso en el caso pesimista de que algún participante se comporte mal, se garantiza rigurosamente la plena seguridad. En cualquier momento, cualquier participante puede iniciar el ‘cierre’ de la cabeza con el efecto de que el estado de la cabeza se transfiera de nuevo a la blockchain (menos eficiente). Hacemos hincapié en que la ejecución de cualquier contrato inteligente puede continuar sin problemas en la cadena. No se pueden generar fondos fuera de la cadena, ni tampoco puede un solo participante de la cabeza que responda perder fondos.
Los canales estatales implementados por Hydra son isomórficos en el sentido de que utilizan el mismo formato de transacción y código de contrato que la blockchain subyacente: los contratos pueden moverse directamente de un lado a otro entre los canales y la blockchain. Por lo tanto, los canales estatales producen efectivamente hermanos de libro de cuentas paralelos y fuera de la cadena. En otras palabras, el libro mayor se convierte en multicabezas.
La confirmación de la transacción en la cabeza se logra en plena concurrencia mediante un proceso asincrónico de certificación fuera de la cadena utilizando firmas múltiples. Este alto nivel de paralelismo es posible gracias al uso del modelo UTxO extendido (EUTxO). Las dependencias de las transacciones en el modelo EUTxO son explícitas, lo que permite la actualización de los estados sin una secuencialización innecesaria de las transacciones que son independientes entre sí.
Validación experimental del protocolo de cabeza Hydra
Como primer paso para validar experimentalmente el funcionamiento del protocolo de la cabeza Hydra, implementamos una simulación. La simulación está parametrizada por el tiempo requerido por las acciones individuales (validación de las transacciones, verificación de las firmas, etc.), y lleva a cabo una simulación realista y con corrección de tiempo de un grupo de nodos distribuidos que forman una cabeza. Esto da lugar a cálculos realistas del tiempo de confirmación de las transacciones y del rendimiento.
Vemos que una sola cabeza Hydra alcanza hasta aproximadamente 1.000 TPS, por lo que ejecutando 1.000 cabezas en paralelo (por ejemplo, una por cada stake pool de la liberación Shelley), deberíamos alcanzar un millón de TPS. Eso es impresionante y nos pone muy por delante de la competencia, pero ¿por qué deberíamos detenernos ahí? 2.000 cabezas nos darán 2 millones de TPS - y si alguien demanda un billón de TPS, entonces podemos decirles que sólo corran un millón de cabezas. Además, varias mejoras de rendimiento en la implementación pueden mejorar la medición de 1.000 TPS de una sola cabeza, añadiendo aún más al rendimiento hipotético del protocolo.
Así que, ¿podemos alcanzar cualquier número de TPS que queramos? En teoría la respuesta es un sólido sí, y eso apunta a un problema con el uso dominante de TPS como métrica para comparar sistemas. Mientras que es tentador reducir la complejidad de la evaluación del desempeño del protocolo a un solo número, en la práctica esto lleva a una simplificación excesiva. Sin un contexto más amplio, un número de TPS está cerca de carecer de sentido. Para interpretarlo correctamente y hacer comparaciones, se debería al menos preguntar por el tamaño del grupo (que influye en la sobrecarga de las comunicaciones); su distribución geográfica (que determina el tiempo que tarda la información en transitar por el sistema); la forma en que la calidad del servicio (tiempos de confirmación de las transacciones, suministro de datos a los usuarios finales) se ve afectada por una alta tasa de transacciones; el tamaño y la complejidad de las transacciones (que influye en los tiempos de validación de las transacciones, el tiempo de propagación de los mensajes, los requisitos del sistema de almacenamiento local y la composición de los participantes principales); y el tipo de equipo informático y de conexiones de red que se utilizaron en los experimentos. El cambio de la complejidad de las transacciones por sí solo puede modificar la TPS en un factor de tres, como puede verse en las figuras del documento (véase la Sección 7 - Simulaciones).
Claramente, necesitamos un mejor estándar. ¿Es el protocolo de cabeza Hydra un buen diseño de protocolo? Lo que necesitamos preguntar es si alcanza los límites físicos de la red, y no un mero número de TPS. Por lo tanto, para esta primera iteración de la evaluación del protocolo de cabeza Hydra, utilizamos el siguiente enfoque para asegurarnos de que los datos que proporcionamos son debidamente significativos:
- Enumeramos claramente todos los parámetros que influyen en la simulación: tamaño de la transacción, tiempo para validar una sola transacción, tiempo necesario para las operaciones criptográficas, ancho de banda asignado por nodo, tamaño del grupo y distribución geográfica, y límites del paralelismo en el que se pueden emitir las transacciones. Sin este entorno controlado, sería imposible reproducir nuestros números.
- Comparamos el rendimiento del protocolo con líneas de base que proporcionan límites precisos y absolutos de la infraestructura de red y hardware subyacente. La forma en que nos acercamos a esos límites nos dice cuánto espacio habría para nuevas mejoras. Esto sigue la metodología explicada anteriormente usando el ejemplo de un algoritmo de encriptación.
Utilizamos dos líneas de base para Hydra. La primera, Full Trust (Confianza Total), es universal: se aplica a cualquier protocolo que distribuya transacciones entre los nodos e insiste en que cada nodo valide las transacciones una tras otra, sin siquiera asegurar el consenso. Esto produce un límite en las TPS simplemente añadiendo los tiempos de entrega y validación de los mensajes. La forma en que nos acercamos a este límite nos dice el precio que estamos pagando por el consenso, sin depender de la comparación con otros protocolos. La segunda línea de base, Hydra Unlimited, produce un límite de TPS específicamente para el protocolo principal y también proporciona la latencia y el almacenamiento ideales para cualquier protocolo. Logramos esto asumiendo que podemos enviar suficientes transacciones en paralelo para amortizar completamente los tiempos de ida y vuelta de la red y que todas las acciones se pueden llevar a cabo cuando se necesiten, sin la contención de los recursos. La línea de base nos ayuda a responder a la pregunta de qué se puede lograr en circunstancias ideales con el diseño general de Hydra (para un conjunto determinado de valores de los parámetros de entrada), así como a evaluar la latencia de confirmación y la sobrecarga de almacenamiento con respecto a cualquier protocolo posible. Se pueden encontrar más detalles y gráficos para los interesados en nuestro documento (de nuevo, Sección 7 - Simulaciones).
¿Qué viene después?
Resolver la cuestión de la escalabilidad es el santo grial para todo el espacio de la blockchain. Ha llegado el momento de aplicar un enfoque basado en principios y pruebas en el diseño y la ingeniería de soluciones de escalabilidad blockchain. Comparar las propuestas de escalabilidad con líneas de base bien definidas puede ser una ayuda significativa en el diseño de tales protocolos. Proporciona pruebas sólidas de la idoneidad de las opciones de diseño y, en última instancia, conduce a la ingeniería de protocolos de libro mayor distribuidos eficaces y eficientes que proporcionarán la mejor métrica absoluta posible para los casos de uso de interés. Mientras el protocolo de cabeza Hydra se implementa y se prueba, con el tiempo liberaremos el resto de los componentes de Hydra siguiendo el mismo enfoque de principios.
Como última nota, Hydra es el esfuerzo conjunto de varios investigadores, a quienes me gustaría agradecer. Estos incluyen a Manuel Chakravarty, Sandro Coretti, Matthias Fitzi, Peter Gaži, Philipp Kant, y Alexander Russel. La investigación también fue apoyada, en parte, por el proyecto de la UE No.780477, PRIVILEDGE, que reconocemos con gratitud.