La canalización [pipelining en inglés] de difusión -prevista para este verano- incrementará el alcance de los tiempos de propagación y validación de los bloques, haciendo posible bloques más grandes y un mayor rendimiento de las transacciones. He aquí una perspectiva de investigación técnica. (Junto con una introducción a AV, su hermano aún más eficaz…)
Traducción al español de “Increasing the transaction throughput of Cardano”, escrito por Matthias Fitzi, el 20 de marzo de 2022.
A raíz de la habilitación realizada recientemente de los contratos inteligentes en Cardano, se ha producido un aumento significativo de la actividad de los usuarios. Al mismo tiempo, el tamaño medio de las transacciones ha crecido debido a las transacciones de los scripts que llevan el código. Dado que ya se han desplegado las primeras aplicaciones de finanzas descentralizadas (DeFi) en el ecosistema de Cardano y que hay más en camino, prevemos que esta tendencia continúe. A fin de mantener esta elevada demanda, es necesario aumentar el rendimiento actual de las transacciones del sistema.
Aumentar el límite de tamaño de los bloques para que quepan más transacciones por bloque es un enfoque natural para aumentar el rendimiento de las transacciones. Este año, el tamaño de los bloques ya se ha incrementado en un 25%, pasando de 64kB a los actuales 80kB y se prevé que siga aumentando. Con todo, existe un límite en el tamaño de los bloques que puede mantener de forma segura un protocolo de consenso del libro mayor si se quiere mantener la tasa de producción de bloques al nivel actual. Si se desea conseguir un alto rendimiento sin comprometer la seguridad del sistema, se necesitan medidas adicionales. Si queremos entender por qué, tenemos que ver más de cerca cómo funciona el consenso del libro mayor en general:
Hay dos parámetros temporales que caracterizan a los protocolos de consenso de los libros mayores:
- Δp, es el máximo retraso de la red para que un nuevo bloque llegue (por ejemplo) al 95% de la red, y
- Δb, es el tiempo (esperado) entre la generación de dos nuevos bloques.
Para argumentar la consistencia del consenso en los protocolos típicos, la propagación de un bloque anterior debe terminar antes de que se genere el siguiente bloque, al menos la mayor parte del tiempo. Por ello, se elige que Δb sea algo mayor que Δp. En Cardano, tenemos Δp=5s (segundos) y Δb=20s.
Entonces, ¿cuántos datos puede transportar un bloque en estas condiciones? Para verlo, tenemos que examinar con más detalle qué es lo que hay que conseguir exactamente en Δp.
Figura 1. Distribución y validación de la red de bloques dentro del presupuesto de Δp=5s
La figura 1 muestra de forma simplificada cómo funciona la propagación de bloques en la red. El productor del bloque envía su nueva cabecera de bloque al Peer 1 (caja h blanca), ocupando los enlaces de red de ambos nodos durante el lapso de tiempo indicado por la caja h blanca. A continuación, el Peer 1 valida la cabecera (lo que implica un cálculo local durante el lapso de tiempo indicado por la caja hv gris). Si el encabezamiento es válido, es decir, el encabezamiento demuestra que el liderazgo del bloque es elegible, etc., el cuerpo del bloque es descargado por el Peer 1 (caja b blanca), ocupando de nuevo los enlaces de red de ambos nodos. Luego, el Peer 1 valida el cuerpo del bloque (bv-box gris), y, sólo si el cuerpo del bloque también es válido, el Peer 1 está listo para propagar el bloque a otros peers según lo que se acaba de describir.
Un efecto secundario desafortunado de este modo de funcionamiento es que la CPU y el enlace de red de un solo nodo sólo se utilizan durante una pequeña fracción de Δp=5s, mientras que permanecen (en su mayoría) inactivos durante el resto de los (esperados) Δb=20s.
Específicamente, la cantidad de datos que podemos incluir en un bloque viene determinada por el retardo de la red de pares del bloque y el tiempo de validación necesario. Estos dos factores crecen de forma aproximadamente lineal en función del tamaño del bloque y del número máximo de saltos necesarios para llegar al 95% de los nodos. El análisis revela que, para garantizar la propagación en la red dentro de Δp=5s, el tamaño del bloque no debe superar los 2 MB. Si se tienen en cuenta las secuencias de comandos intensas desde el punto de vista informático, el tiempo de validación puede incluso imponer un límite mucho menor.
La buena noticia es que, teniendo en cuenta estas limitaciones, el rendimiento de las transacciones puede superarse aplicando cambios en la red de pares y/o en las capas de consenso. A continuación explicamos estas técnicas.
Canalización de difusión
Si volvemos a examinar la figura 1, apreciamos que todas las acciones de los nodos se realizan en estricta secuencia, por lo que Δp debe ajustarse al tiempo requerido por un solo nodo multiplicado por el número de saltos en la ruta entre pares. Podemos afirmar que, si bien esto es necesario para la transmisión en red, no lo es para la validación de los bloques.
Analicemos la figura 2. Si se permite la propagación de los bloques antes de que se produzca la validación completa, podemos excluir la validación del cuerpo (repetida) de la ruta de propagación. En cuanto el Peer 1 ha recibido el cuerpo del bloque (b-box), ya puede empezar a propagar el bloque al tiempo que valida el cuerpo del bloque, etc.
Al contrario que en el esquema de la Figura 1, el presupuesto de Δp ahora sólo necesita tener en cuenta la validación del cuerpo una vez. El resultado es un mayor presupuesto de tiempo para la transmisión de la red entre pares y/o la validación del cuerpo, lo que permite un mayor rendimiento de las transacciones (para facilitar la comparación con la figura 1, esta ganancia se ilustra con un mayor presupuesto de validación del cuerpo (“bv”)).
Por razones que se explican a continuación, es esencial que las dos comprobaciones de validación siguientes se reproduzcan completamente en la ruta de propagación:
-
- Corrección de la cabecera, es decir, que el bloque haga referencia correctamente a su predecesor, y liderazgo correcto del bloque (función aleatoria verificable (VRF) y validación de la firma del bloque).
-
- Integridad del bloque, es decir, que el cuerpo recibido (pero aún no validado) esté efectivamente referenciado por el hash del cuerpo de la cabecera.
¿Cómo afecta la canalización de la difusión (como se ha descrito anteriormente) a la seguridad de las capas de consenso y de red?
En primer lugar, hay que tener en cuenta que la capa de consenso no se ve afectada por este cambio:
- Que los bloques honestos son siempre válidos, ya que el líder del bloque valida completamente la cadena que va a ser anexada por el nuevo bloque, así como el propio bloque, y,
- No se propagan los bloques incompletos (debido al punto 2 anterior), y,
- A pesar de que los bloques inválidos (completos) pueden propagarse por la red, un nodo honesto siempre los descarta después de la validación del cuerpo.
Segundo, en lo que respecta a los ataques de denegación de servicio (DoS) en la capa de red, nótese que el adversario puede intentar congestionar el sistema difundiendo bloques no válidos. No obstante, se continúa verificando un liderazgo de bloque correcto (debido al punto 1), lo que implica que dicho bloque sólo se propagará si el adversario está programado para hacerlo, es decir, no se genera más carga que si este líder de bloque fuera honesto (salvo que el bloque no contribuya al rendimiento del sistema). Por otra parte, los operadores de stake-pool (SPO) que generen bloques no válidos pueden ser fácilmente identificados y castigados; de hecho, actualmente se está desarrollando un sistema de gestión de infracciones para realizar exactamente esta función.
A modo de resumen, la canalización por difusión aumenta el presupuesto para la propagación de bloques y los tiempos de validación dentro del límite de Δp, lo que permite realizar bloques más grandes y, por tanto, aumentar el rendimiento de las transacciones, sin modificar las reglas de consenso. Promete aumentar sustancialmente el rendimiento y puede lograrse con cambios mínimamente invasivos en el sistema, por lo que es un excelente candidato para su aplicación a corto plazo. Sin embargo, el impacto de la canalización (por sí sola) es limitado, y nuestras ambiciones no se detienen aquí.
Seguidamente presentamos un resumen de una técnica más potente que puede lograr un rendimiento de las transacciones aún mayor, pero que requiere también unos cambios más drásticos en el protocolo.
Validación asíncrona
Se puede llevar el concepto de canalización de la difusión -validación del cuerpo retrasada- al extremo: se sigue exigiendo que un nuevo bloque llegue dentro de Δp, pero no exigimos que su validación del cuerpo se complete dentro de Δp. Lo denominamos validación asíncrona (AV).
Veamos la figura 3. La validación del cuerpo puede consumir esencialmente el presupuesto restante (esperado) de Δb (además de la transmisión de bloques y la validación de la cabecera), poniendo así prácticamente las CPUs de los nodos en carga permanente. Ahora bien, hay que tener en cuenta que el enlace de red y la CPU también están asignados a otras tareas (como la sincronización del mempool), lo que significa que no queremos utilizar todo el resto de Δb para la validación del cuerpo, sino dejar un par de segundos asignados a esas otras tareas.
La consecuencia es un efecto secundario notable. En contraste con la canalización de la difusión, la validación del libro mayor generalmente va por detrás de la cabeza de la cadena. Concretamente, incluso los líderes de bloque honestos pueden ahora crear bloques que son (parcialmente) inválidos, ya que pueden no haber terminado de validar el historial de transacciones que conducen al nuevo bloque.
Para hacer frente a este efecto secundario, es necesario adaptar las reglas del libro mayor: para garantizar que los bloques honestos contribuyan siempre a la seguridad del consenso, los bloques que lleven transacciones no válidas deben seguir considerándose extensiones válidas de la cadena. Las transacciones no válidas pueden entonces descartarse simplemente durante la validación del libro mayor.
Si bien es cierto que mejora sustancialmente con respecto a la canalización por difusión, la AV puede mejorarse aún más. El motivo es que, por lo general, no se pueden difundir suficientes datos durante Δp para producir suficiente trabajo de validación para maximizar las CPUs durante todo el resto del periodo Δb. A fin de aprovechar plenamente las ventajas de la AV, la combinaremos con el mecanismo de los endosantes de entrada, que describiremos en una próxima entrada del blog.
Impacto
¿Cuál es la repercusión en el rendimiento que podemos esperar de la canalización y la AV? Nuestros equipos de investigación y de red siguen trabajando para encontrar una respuesta precisa a esta pregunta, ya que realizar un análisis riguroso en el caso de un adversario malicioso (que intente perturbar al máximo el protocolo) es bastante complicado. De todos modos, para ofrecer una primera estimación, a continuación ofrecemos un análisis del rendimiento para el caso optimista en el que todos los SPO se comportan honestamente, esperando que los resultados para el caso malicioso no se desvíen sustancialmente (dada también la presencia del sistema de gestión de infracciones). No obstante, hay que tener en cuenta que el rendimiento real del sistema probablemente variará de las estimaciones dadas.
En la Tabla 1, mostramos estas estimaciones de rendimiento (en transacciones por segundo, TPS). Recordemos que el rendimiento depende tanto del tamaño de las transacciones como del tiempo de validación. Suponemos que todas las transacciones tienen las mismas características para una selección de pares tamaño/tiempo de validación, y damos las cifras de rendimiento respectivas. Hemos analizado cuatro protocolos diferentes:
- Praos: El protocolo de Cardano actualmente utilizado (tamaño de bloque 80 kB)
- Praos Max: Praos con el máximo tamaño de bloque posible que se puede mantener con seguridad (bajo los supuestos anteriores)
- Canalización de difusión
- AV (con el 20% del presupuesto de Δb descontado, y reservado para diferentes tareas)
Estudiamos cuatro tipos de transacciones diferentes con tamaños y tiempos de validación variados. Una simple transacción de pago se encuentra en algún lugar cerca de la categoría de 0,5 kB / 0,5 ms, en tanto que las transacciones de scripts pueden caer en cualquiera de los otros tipos, que requieren tanto un tamaño mayor como un mayor esfuerzo de validación. Obsérvese también la última columna (2 kB / 32 ms), en la que el tiempo de validación se vuelve sustancial en comparación con el retraso de la red: El incremento del tamaño de los bloques (de Praos a Praos Max) no ayuda a mejorar el rendimiento, ya que la validación supera el presupuesto de tiempo. Por lo tanto, la canalización y el AV proporcionan fuertes ganancias relativas exactamente en estos casos, ya que aumentan el presupuesto de tiempo de validación.
Perspectivas para Cardano
El aumento del rendimiento de una blockchain sin permisos es crítico para la seguridad, ya que admitir más carga en el sistema puede introducir oportunidades de ataques DoS. Así pues, es aconsejable introducir estos cambios en una secuencia de pequeños pasos mientras se observan atentamente los efectos en el sistema.
En diciembre y febrero de este año se dieron los primeros pasos, aumentando el límite de tamaño de los bloques (y de las unidades de memoria de los scripts de Plutus) de 64kB a 80kB (véase también este 
blog reciente de John Woods).
A lo largo de los próximos meses, continuaremos supervisando y ajustando estos parámetros, basándonos en la demanda de la red y en las limitaciones de capacidad. La implementación de la canalización de difusión aportará nuevas mejoras. Todavía se están desarrollando otras optimizaciones del consenso, incluidos los endosadores de entrada y oportunamente se anunciarán más detalles sobre cómo se ejecutarán.
Hay que señalar que el esfuerzo de optimización de la era de Cardano Basho se extiende más allá de las capas de red y de consenso, e incluye mejoras en los scripts de Plutus, así como en el procesamiento fuera de la cadena - véase este blog reciente de Tim Harrison. En particular, Hydra, un conjunto de protocolos de capa 2 que se está desarrollando, ofrece otra vía para una mejora dramática en el rendimiento total de las transacciones al permitir ejecutarlas fuera de la cadena.
*Agradecimientos. Deseo dar las gracias a Duncan Coutts, Sandro Coretti-Drayton, Neil Davies, Alexander Esgen, Nicolas Frisby, Peter Gaži, Philipp Kant, Aggelos Kiayias, Karl Knutsson, Tim Harrison, Giorgos Panagiotakos, Alexander Russell, Fernando Sánchez, Marcin Szamotulski, Peter Thompson, Spyros Voulgaris y John Woods.
Notas del traductor
-
Corchetes del traductor.
-
indica que el enlace apunta a un contenido en idioma inglés.
-
indica que el enlace apunta a un contenido en idioma español.