馃嚜馃嚫 Aumentando el rendimiento de las transacciones de Cardano

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 鈥淚ncreasing the transaction throughput of Cardano鈥, escrito por Matthias Fitzi, el 20 de marzo de 2022.


descarga

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 (鈥渂v鈥)).

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:

    1. 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).
    1. 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 :uk: 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 :uk: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.

  • :uk: indica que el enlace apunta a un contenido en idioma ingl茅s.

  • :es: indica que el enlace apunta a un contenido en idioma espa帽ol.


  • Desde :es:Cardanians Hispanos en Twitter, puede usted seguir a los tweets oficiales traducidos al espa帽ol, de la Fundaci贸n Cardano, EMURGO, IOG, Yoroi y Comunidad Cardano.

  • Desde :es:Anuncios de Cardano en Espa帽ol en Telegram, puede usted seguir los anuncios oficiales traducidos al espa帽ol, de Cardano, EMURGO y Yoroi.

  • Desde :es:Cardano en Castellano puede usted acceder a videos oficiales de Cardano doblados al espa帽ol.

  • Desde :es:El Blog de LiberLion puede usted acceder a art铆culos de Cardano en ingl茅s y espa帽ol.