Aumentarán el rendimiento de las transacciones de Cardano

rendimiento de las transacciones de Cardano ADA
Rate this post

Rendimiento de las transacciones de Cardano: La reciente habilitación de contratos inteligentes en Cardano ha llevado a un aumento significativo en la actividad de los usuarios. Simultáneamente, el tamaño promedio de las transacciones creció debido a las transacciones de scripts portadores de código. Con las primeras aplicaciones de finanzas descentralizadas (DeFi) ahora implementadas en el ecosistema de Cardano, y más en camino, esperamos que esta tendencia continúe. Para mantenerse al día con esta demanda elevada, se debe aumentar el rendimiento actual de transacciones del sistema.

La canalización de difusión, programada para este verano, aumentará el presupuesto para la propagación de bloques y los tiempos de validación, lo que permitirá bloques más grandes y un mayor rendimiento de transacciones. He aquí una perspectiva de investigación técnica. (Junto con una introducción a AV, su hermano aún más eficaz…)

Un enfoque obvio para aumentar el rendimiento de las transacciones es aumentar el límite de tamaño de bloque para que quepan más transacciones por bloque. El tamaño del bloque ya se incrementó en un 25 % este año, de 64 kB a los 80 kB actuales, y anticipamos nuevos aumentos. Sin embargo, existe un límite sobre el tamaño de un bloque que se puede mantener de forma segura mediante un protocolo de consenso de libro mayor si la tasa de producción de bloques se mantiene en el nivel actual. Para lograr un alto rendimiento sin comprometer la seguridad del sistema, se requieren medidas adicionales. Para entender por qué, debemos observar más de cerca cómo funciona el consenso del libro mayor en general:

Los protocolos de consenso de libro mayor se caracterizan por dos parámetros de tiempo:

  • Δp, el retraso máximo de la red para que un nuevo bloque alcance (por ejemplo) el 95 % de la red, y
  • Δb, el tiempo (esperado) entre la generación de dos nuevos bloques.

En los protocolos típicos, para argumentar la consistencia del consenso, 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 tanto, Δb se elige algo mayor que Δp. En Cardano tenemos Δp=5s (segundos) y Δb=20s.

Ahora bien, ¿cuántos datos puede transportar un bloque en estas condiciones? Para ver esto, necesitamos examinar con más detalle qué se debe lograr exactamente dentro de Δp.

Difusión y validación de la red de bloques de cardano ada
Difusión y validación de la red de bloques de cardano ada

Figura 1. Difusión y validación de la red de bloques dentro del presupuesto Δp=5s

Considere la Figura 1 anterior que muestra de manera simplificada cómo funciona la propagación de bloques en la red. El productor de bloques envía su nuevo encabezado de bloque al Peer 1 (caja h blanca), ocupando los enlaces de red de ambos nodos durante el período de tiempo indicado por la caja h blanca. El par 1 luego valida el encabezado (lo que implica el cálculo local durante el período de tiempo indicado por el cuadro hv gris). Si el encabezado es válido, es decir, el encabezado prueba el liderazgo de bloque elegible, etc., el cuerpo del bloque es descargado por el Peer 1 (caja b blanca), ocupando nuevamente los enlaces de red de ambos nodos. Finalmente, el Peer 1 valida el cuerpo del bloque (bv-box gris) y, solo si el cuerpo del bloque también es válido, el Peer 1 está listo para propagar el bloque a otros pares en la línea de lo que se acaba de describir.

Un efecto secundario desafortunado de este modo de operación es que la CPU y el enlace de red de un solo nodo solo se utilizan durante una pequeña fracción de Δp = 5 s mientras permanece (en su mayoría) inactivo durante el resto de los (esperados) Δb = 20 s.

Concretamente, la cantidad de datos que podemos incluir en un bloque está determinada por el retraso de la red peer-to-peer del bloque y el tiempo de validación requerido. Ambos crecen aproximadamente de forma lineal en el tamaño del bloque, multiplicado por el número máximo de saltos necesarios para alcanzar el 95 % de todos los nodos. Las mediciones muestran que, para garantizar la propagación de la red dentro de Δp=5s, el tamaño del bloque no debe exceder los 2 MB. Teniendo en cuenta los scripts computacionalmente intensos, el tiempo de validación puede incluso imponer un límite mucho más bajo.

La buena noticia es que, dentro de estas limitaciones, el rendimiento de las transacciones se puede superar aplicando cambios en la red de igual a igual o en las capas de consenso. A continuación explicamos estas técnicas.

Canalización de difusión

Al reconsiderar la Figura 1, vemos que las acciones de todos los nodos se realizan en secuencia estricta y, por lo tanto, Δp debe ajustarse al tiempo requerido por un solo nodo multiplicado por la cantidad de saltos en la ruta de igual a igual. Observamos que, si bien esto es necesario para la transmisión de red, no lo es para la validación de bloques.

Canalización de difusión
Canalización de difusión

Considere la Figura 2. Al permitir que los bloques se propaguen antes de que haya tenido lugar la validación completa, podemos excluir la validación del cuerpo (repetida) de la ruta de propagación. Tan pronto como Peer 1 haya recibido el cuerpo del bloque (b-box), ya puede comenzar a propagar el bloque al mismo tiempo que valida el cuerpo del bloque, etc.

En contraste con el esquema de la Figura 1, el presupuesto de Δp ahora solo necesita tener en cuenta la validación del cuerpo una vez. Esto da como resultado un mayor presupuesto de tiempo para la transmisión de red entre pares y/o la validación del cuerpo, lo que permite un mayor rendimiento de transacciones (para facilitar la comparación con la Figura 1, esta ganancia se ilustra con una validación del cuerpo más grande ('bv' ) presupuesto).

Por las razones que se explican a continuación, es crucial que las siguientes dos comprobaciones de validación permanezcan completamente replicadas en la ruta de propagación:

Corrección del encabezado, es decir, el bloque hace referencia correctamente a su predecesor, y liderazgo de bloque correcto (función aleatoria verificable (VRF) y validación de firma de bloque).
Completitud del bloque, es decir, el hash del cuerpo del encabezado hace referencia al cuerpo recibido (pero aún no validado).

¿Cómo podría afectar la canalización de difusión (como se describe anteriormente) a la seguridad de las capas de consenso y de red?

Primero, tenga en cuenta que la capa de consenso no se ve afectada por este cambio:

  • Los bloques honestos siempre son válidos, ya que el líder del bloque valida completamente la cadena que se agregará al nuevo bloque, así como al nuevo bloque en sí, y,
  • Bloques incompletos no se propagan (debido al Punto 2 anterior) y,
  • Los bloques no válidos (completos), aunque posiblemente se propaguen a través de la red, siempre son descartados por un nodo honesto después de la validación del cuerpo.

En segundo lugar, con respecto a los ataques de denegación de servicio (DoS) en la capa de red, tenga en cuenta que el adversario puede intentar congestionar el sistema mediante la difusión de bloques no válidos. Sin embargo, el liderazgo de bloque correcto aún se verifica (debido al punto 1), lo que implica que dicho bloque solo 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 (excepto por el bloque no contribuye al rendimiento del sistema). Además, los operadores de grupos de participación (SPO) que generan bloques no válidos pueden identificarse y castigarse fácilmente; de ​​hecho, actualmente se está desarrollando un sistema de gestión de infracciones para realizar exactamente esta función.

Para concluir, la canalización de difusión aumenta el presupuesto para la propagación de bloques y los tiempos de validación dentro del límite Δp, lo que permite bloques más grandes y, por lo tanto, un mayor rendimiento de transacciones, sin modificar las reglas de consenso. Promete aumentar sustancialmente el rendimiento mientras se puede lograr mediante cambios mínimamente invasivos en el sistema y, por lo tanto, es un excelente candidato para la implementación a corto plazo. Aún así, el impacto de la canalización (solo) es limitado y nuestras ambiciones no se detienen aquí.

A continuación, ofrecemos un resumen de una técnica más poderosa que puede lograr un rendimiento de transacción aún mayor, pero también requiere algunos cambios de protocolo más drásticos.

Validación asíncrona

La idea detrás de la canalización de difusión (validación del cuerpo retrasada) se puede llevar al extremo: aún se requiere que un nuevo bloque llegue dentro de Δp, pero no exigimos que su validación del cuerpo se complete dentro de Δp. Nos referimos a esto como validación asíncrona (AV).

Validación asíncrona
Validación asíncrona

Considere la Figura 3. Se permite que la validación del cuerpo consuma esencialmente el presupuesto Δb restante (esperado) (además de la transmisión en bloque y la validación del encabezado), lo que virtualmente pone las CPU de los nodos en carga permanente. Sin embargo, tenga en cuenta que el enlace de red y la CPU también se asignan a otras tareas (como la sincronización de mempool), lo que significa que no queremos utilizar el resto completo de Δb para la validación del cuerpo, sino dejar un par de segundos asignados a ese otro Tareas.

Esto tiene un efecto secundario notable. A diferencia de la canalización de difusión, la validación del libro mayor generalmente va a la zaga de la cabeza de la cadena. En particular, incluso los líderes de bloque honestos ahora pueden crear bloques que son (parcialmente) inválidos, ya que es posible que no hayan terminado de validar el historial de transacciones que condujo al nuevo bloque.

Para hacer frente a este efecto secundario, las reglas del libro mayor deben adaptarse: para garantizar que los bloques honestos siempre contribuyan a la seguridad del consenso, los bloques que contienen transacciones no válidas deben seguir considerándose extensiones de cadena válidas. Las transacciones no válidas pueden simplemente descartarse durante la validación del libro mayor.

Aunque mejora sustancialmente la tubería de difusión, AV se puede mejorar aún más. La razón es que, por lo general, no se pueden difundir suficientes datos durante Δp para producir suficiente trabajo de validación para maximizar las CPU durante el resto del período Δb. Para aprovechar al máximo los beneficios de AV, lo combinaremos con el mecanismo de respaldo de entrada, que describiremos en una próxima publicación de blog.

Impacto

¿Qué impacto en el rendimiento podemos esperar de la canalización y AV? Encontrar la respuesta precisa a esta pregunta es un trabajo en curso por parte de nuestra red y nuestros equipos de investigación, ya que es bastante complicado brindar un análisis riguroso en caso de que un adversario malicioso (intente interrumpir al máximo el protocolo). Aún así, para proporcionar una primera estimación, a continuación ofrecemos un análisis de rendimiento para el caso optimista en el que todos los SPO se comportan honestamente, con la expectativa de que los resultados del caso malicioso no se desvíen sustancialmente (dada también la presencia del sistema de gestión de infracciones). Aún así, tenga en cuenta que el rendimiento real del sistema probablemente variará de las estimaciones dadas.

estimaciones de rendimiento
estimaciones de rendimiento

En la Tabla 1, presentamos estas estimaciones de rendimiento (en transacciones por segundo, TPS). Recuerde que el rendimiento depende tanto del tamaño de las transacciones como de los tiempos de validación. Para una selección de pares de tamaño/tiempo de validación, asumimos que todas las transacciones tienen las mismas características y damos los números de rendimiento respectivos. Comparamos cuatro protocolos diferentes:

  • Praos: Protocolo desplegado actualmente por Cardano (tamaño de bloque 80 kB)
    Praos Max: Praos con el tamaño de bloque máximo posible que se puede mantener de forma segura (bajo los supuestos anteriores)
  • Canalización de difusión
  • AV (con 20% del presupuesto Δb descontado, y reservado para diferentes tareas)

Consideramos cuatro tipos de transacciones diferentes con tamaños variados y tiempo requerido para la validación. Una transacción de pago simple está cerca de la categoría de 0,5 kB/0,5 ms, mientras que las transacciones de script pueden caer en cualquiera de los otros tipos, que requieren un tamaño mayor y más esfuerzo para validar. Tenga en cuenta también la última columna (2 kB / 32 ms) donde el tiempo de validación se vuelve sustancial en comparación con el retraso de la red: aumentar el tamaño del bloque (de Praos a Praos Max) no ayuda a mejorar el rendimiento, ya que la validación ya maximiza el presupuesto de tiempo. En consecuencia, la canalización y AV proporcionan fuertes ganancias relativas exactamente en estos casos, ya que aumentan el presupuesto de tiempo de validación.

Perspectivas para Cardano

Aumentar el rendimiento de una cadena de bloques sin permisos es fundamental para la seguridad, ya que admitir más carga en el sistema puede generar oportunidades de ataques DoS. Por lo tanto, es aconsejable realizar dichos cambios en una secuencia de pequeños pasos mientras se observan cuidadosamente los efectos en el sistema.

Los primeros pasos de este tipo se tomaron en diciembre pasado y este febrero al aumentar el límite de tamaño de bloque (y las unidades de memoria Plutus-script) de 64kB a 80kB (ver también este blog reciente de John Woods).

En los próximos meses, continuaremos monitoreando de cerca y ajustando estos parámetros, según la demanda de la red y las limitaciones de capacidad. Otras mejoras vendrán con la implementación de canalización de difusión. Otras optimizaciones de consenso, incluidos los respaldos de entrada, aún están en desarrollo, y se anunciarán más detalles sobre cómo se ejecutarán a su debido tiempo.

Tenga en cuenta que el esfuerzo de optimización de la era Cardano Basho se extiende más allá de las capas de red y consenso, e incluye mejoras en el script de Plutus, así como el procesamiento fuera de la cadena; consulte este blog reciente de Tim Harrison. En particular, Hydra , un conjunto de protocolos de capa 2 en desarrollo, ofrece otra vía para una mejora drástica en el rendimiento total de transacciones al permitir ejecutar transacciones fuera de la cadena.

Fuente: https://iohk.io/en/blog/posts/2022/03/21/increasing-the-transaction-throughput-of-cardano/

Índice

    Deja una respuesta

    Tu dirección de correo electrónico no será publicada.

    Subir