Por qué el rendimiento de Blockchain es difícil de medir

El rendimiento y la escalabilidad son desafíos muy discutidos en el espacio criptográfico, relevantes tanto para los proyectos de Capa 1 (cadenas de bloques independientes) como para las soluciones de Capa 2 (como acumulaciones y canales fuera de la cadena). Sin embargo, no tenemos métricas o puntos de referencia estandarizados. Los números a menudo se informan de manera incoherente e incompleta, lo que dificulta la comparación precisa de los proyectos y, a menudo, oscurece lo que más importa en la práctica. 

Necesitamos un enfoque más matizado y completo para medir y comparar el desempeño, uno que divida el desempeño en múltiples componentes y compare las compensaciones en múltiples ejes. En esta publicación, defino la terminología básica, describo los desafíos y ofrezco pautas y principios clave para tener en cuenta al evaluar el rendimiento de blockchain. 

Escalabilidad frente a rendimiento

Primero, definamos dos términos, escalabilidad y rendimiento, que tienen significados informáticos estándar que a menudo se usan incorrectamente en contextos de blockchain. Rendimiento mide lo que es un sistema actualmente capaz de lograr. Como veremos a continuación, las métricas de rendimiento pueden incluir transacciones por segundo o el tiempo medio de confirmación de la transacción. Escalabilidad, por otro lado, mide la capacidad de un sistema para mejorar el rendimiento mediante la adición de recursos.

Esta distinción es importante: muchos enfoques para mejorar el rendimiento no mejoran la escalabilidad en absoluto, cuando se definen correctamente. Un ejemplo simple es usar un esquema de firma digital más eficiente, como las firmas BLS, que tienen aproximadamente la mitad del tamaño de las firmas Schnorr o ECDSA. Si Bitcoin cambiara de ECDSA a BLS, la cantidad de transacciones por bloque podría aumentar entre un 20 y un 30 %, lo que mejoraría el rendimiento de la noche a la mañana. Pero solo podemos hacer esto una vez: no hay un esquema de firma aún más eficiente en el espacio al que cambiar (las firmas BLS también se pueden agregar para ahorrar más espacio, pero este es otro truco único).

Una serie de otros trucos únicos (como SegWit) son posibles en blockchains, pero necesita una arquitectura escalable para lograr una mejora continua del rendimiento, donde agregar más recursos mejora el rendimiento con el tiempo. Esta es la sabiduría convencional también en muchos otros sistemas informáticos, como la construcción de un servidor web. Con algunos trucos comunes, puede construir un servidor muy rápido; pero, en última instancia, necesita una arquitectura de varios servidores que pueda satisfacer la demanda cada vez mayor mediante la adición continua de servidores adicionales.

Comprender la distinción también ayuda a evitar el error de categoría común que se encuentra en afirmaciones como "¡Blockchain X es altamente escalable, puede manejar Y transacciones por segundo!" La segunda afirmación puede ser impresionante, pero es una actuación métrica, no una métrica de escalabilidad. No habla de la capacidad de mejorar el rendimiento mediante la adición de recursos.

La escalabilidad requiere inherentemente explotar el paralelismo. En el espacio de la cadena de bloques, el escalado de la Capa 1 parece requerir fragmentación o algo parecido a la fragmentación. El concepto básico de fragmentación (dividir el estado en partes para que diferentes validadores puedan procesar de forma independiente) coincide estrechamente con la definición de escalabilidad. Incluso hay más opciones en la Capa 2 que permiten agregar procesamiento paralelo, incluidos canales fuera de la cadena, servidores de resumen y cadenas laterales.

Latencia frente a rendimiento

Clásicamente, el rendimiento del sistema blockchain se evalúa en dos dimensiones, la latencia y el rendimiento: la latencia mide la rapidez con la que se puede confirmar una transacción individual, mientras que el rendimiento mide la tasa agregada de transacciones a lo largo del tiempo. Estos ejes se aplican tanto a los sistemas de capa 1 como a los de capa 2, así como a muchos otros tipos de sistemas informáticos (como motores de consulta de bases de datos y servidores web).

Desafortunadamente, tanto la latencia como el rendimiento son complejos de medir y comparar. Además, a los usuarios individuales en realidad no les importa el rendimiento (que es una medida de todo el sistema). Lo que realmente les importa es la latencia y las tarifas de transacción; más específicamente, que sus transacciones se confirmen de la manera más rápida y económica posible. Aunque muchos otros sistemas informáticos también se evalúan en función del costo/rendimiento, las tarifas de transacción son un eje de rendimiento un tanto nuevo para los sistemas de cadena de bloques que en realidad no existe en los sistemas informáticos tradicionales.

Desafíos en la medición de la latencia

La latencia parece simple al principio: ¿cuánto tiempo tarda una transacción en confirmarse? Pero siempre hay varias maneras diferentes de responder a esta pregunta.

Primero, podemos medir la latencia entre diferentes puntos en el tiempo y obtener diferentes resultados. Por ejemplo, ¿comenzamos a medir la latencia cuando el usuario presiona el botón "enviar" localmente o cuando la transacción llega al mempool? ¿Y detenemos el reloj cuando la transacción está en un bloque propuesto, o cuando un bloque se confirma con un bloque de seguimiento o seis?

El enfoque más común toma el punto de vista de los validadores, midiendo desde el momento en que un cliente transmite por primera vez una transacción hasta el momento en que una transacción se "confirma" razonablemente (en el sentido de que los comerciantes del mundo real considerarían un pago recibido y liberarían la mercancía) . Por supuesto, diferentes comerciantes pueden aplicar diferentes criterios de aceptación, e incluso un solo comerciante puede usar diferentes estándares según el monto de la transacción.

El enfoque centrado en el validador pierde varias cosas que importan en la práctica. Primero, ignora la latencia en la red peer-to-peer (¿cuánto tiempo pasa desde que el cliente transmite una transacción hasta que la mayoría de los nodos la escuchan?) y la latencia del lado del cliente (¿cuánto tiempo lleva preparar una transacción? en la máquina local del cliente?). La latencia del lado del cliente puede ser muy pequeña y predecible para transacciones simples como firmar un pago de Ethereum, pero puede ser significativa para casos más complejos como probar que una transacción de Zcash blindada es correcta.

Incluso si estandarizamos la ventana de tiempo que intentamos medir con la latencia, la respuesta casi siempre es eso depende. Ningún sistema de criptomonedas jamás construido ha ofrecido una latencia de transacción fija. Una regla general fundamental para recordar es:

La latencia es una distribución, no un solo número.

La comunidad de investigación de redes ha entendido esto desde hace mucho tiempo (ver, por ejemplo, este excelente charla de Gil Tene). Se pone un énfasis particular en la "cola larga" de la distribución, ya que una latencia muy elevada incluso en el 0.1 % de las transacciones (o consultas del servidor web) el impacto usuarios finales.

Con blockchains, la latencia de confirmación puede variar por varias razones:

Por lotes: la mayoría de los sistemas procesan por lotes las transacciones de alguna manera, por ejemplo, en bloques en la mayoría de los sistemas de Capa 1. Esto conduce a una latencia variable, porque algunas transacciones tendrán que esperar hasta que se llene el lote. Otros pueden tener suerte y unirse al último grupo. Estas transacciones se confirman de inmediato y no experimentan ninguna latencia adicional.

Congestión variable: la mayoría de los sistemas sufren de congestión, lo que significa que se publican más transacciones (al menos algunas veces) de las que el sistema puede manejar de inmediato. La congestión puede variar cuando las transacciones se transmiten en momentos impredecibles (a menudo abstraídos como un Proceso de Poisson) o cuando la tasa de nuevas transacciones cambia durante el día o la semana, o en respuesta a eventos externos como un popular lanzamiento de NFT.

Varianza de la capa de consenso: La confirmación de una transacción en la Capa 1 generalmente requiere un conjunto distribuido de nodos para llegar a un consenso sobre un bloque, lo que puede agregar demoras variables independientemente de la congestión. Los sistemas de prueba de trabajo encuentran bloques en momentos impredecibles (también, de manera abstracta, un proceso de Poisson). Los sistemas de prueba de participación también pueden agregar varios retrasos (por ejemplo, si hay una cantidad insuficiente de nodos en línea para formar un comité en una ronda, o si se requiere un cambio de vista en respuesta a la caída de un líder).

Por estas razones, una buena pauta es:

Las afirmaciones sobre la latencia deben presentar una distribución (o histograma) de tiempos de confirmación, en lugar de un solo número como la media o la mediana.

Si bien las estadísticas de resumen como la media, la mediana o los percentiles brindan una imagen parcial, la evaluación precisa de un sistema requiere considerar la distribución completa. En algunas aplicaciones, la latencia media puede brindar una buena perspectiva si la distribución de la latencia es relativamente simple (por ejemplo, gaussiana). Pero en las criptomonedas, casi nunca es así: por lo general, hay una larga cola de tiempos de confirmación lentos.

Las redes de canales de pago (por ejemplo, Lightning Network) son un buen ejemplo. Una solución clásica de escalado L2, estas redes ofrecen confirmaciones de pago muy rápidas la mayor parte del tiempo, pero ocasionalmente requieren un reinicio de canal que puede aumentar la latencia en órdenes de magnitud.

E incluso si tenemos buenas estadísticas sobre la distribución exacta de la latencia, es probable que varíen con el tiempo a medida que cambien el sistema y la demanda del sistema. Tampoco siempre está claro cómo comparar las distribuciones de latencia entre los sistemas de la competencia. Por ejemplo, considere un sistema que confirma transacciones con una latencia distribuida uniformemente entre 1 y 2 minutos (con una media y una mediana de 90 segundos). Si un sistema de la competencia confirma el 95% de las transacciones en 1 minuto exactamente y el otro 5% en 11 minutos (con una media de 90 segundos y una mediana de 60 segundos), ¿qué sistema es mejor? La respuesta es probablemente que algunas aplicaciones preferirían lo primero y otras lo segundo.

Finalmente, es importante tener en cuenta que en la mayoría de los sistemas, no todas las transacciones tienen la misma prioridad. Los usuarios pueden pagar más para obtener una mayor prioridad de inclusión, por lo que, además de todo lo anterior, la latencia varía en función de las tarifas de transacción pagadas. En resumen:

La latencia es compleja. Cuantos más datos se informen, mejor. Idealmente, las distribuciones de latencia completas deberían medirse en condiciones de congestión variables. También son útiles los desgloses de latencia en diferentes componentes (local, red, procesamiento por lotes, retraso de consenso).

Desafíos en la medición del rendimiento

El rendimiento también parece simple a primera vista: ¿cuántas transacciones puede procesar un sistema por segundo? Surgen dos dificultades principales: ¿qué es exactamente una "transacción" y estamos midiendo lo que hace un sistema hoy o lo que podría ser capaz de hacer?

Si bien las "transacciones por segundo" (o tps) son un estándar de facto para medir el rendimiento de la cadena de bloques, las transacciones son problemáticas como unidad de medida. Para los sistemas que ofrecen programabilidad de propósito general ("contratos inteligentes") o incluso características limitadas como las transacciones multiplexadas de Bitcoin u opciones para la verificación de múltiples firmas, el problema fundamental es:

No todas las transacciones son iguales.

Esto es obviamente cierto en Ethereum, donde las transacciones pueden incluir código arbitrario y modificar el estado arbitrariamente. La noción de gas en Ethereum se utiliza para cuantificar (y cobrar tarifas) la cantidad total de trabajo que realiza una transacción, pero esto es muy específico del entorno de ejecución de EVM. No existe una forma sencilla de comparar la cantidad total de trabajo realizado por un conjunto de transacciones EVM con, por ejemplo, un conjunto de transacciones Solana utilizando el entorno BPF. La comparación con un conjunto de transacciones de Bitcoin es igualmente complicada.

Las cadenas de bloques que separan la capa de transacción en una capa de consenso y una capa de ejecución pueden aclarar esto. En la capa de consenso (pura), el rendimiento se puede medir en bytes agregados a la cadena por unidad de tiempo. La capa de ejecución siempre será más compleja.

Las capas de ejecución más simples, como los servidores de resumen que solo admiten transacciones de pago, evitan la dificultad de cuantificar el cálculo. Sin embargo, incluso en este caso, los pagos pueden variar en la cantidad de insumos y productos. Canal de pago las transacciones pueden variar en la cantidad de "saltos" requeridos, lo que afecta el rendimiento. Y el rendimiento del servidor de resumen puede depender de la medida en que un lote de transacciones se puede "compensar" en un conjunto más pequeño de cambios de resumen.

Otro desafío con el rendimiento es ir más allá de medir empíricamente el rendimiento actual para evaluar la capacidad teórica. Esto introduce todo tipo de preguntas de modelado para evaluar la capacidad potencial. Primero, debemos decidir sobre una carga de trabajo de transacción realista para la capa de ejecución. En segundo lugar, los sistemas reales casi nunca alcanzan la capacidad teórica, especialmente los sistemas de cadena de bloques. Por razones de solidez, esperamos que las implementaciones de nodos sean heterogéneas y diversas en la práctica (en lugar de que todos los clientes ejecuten una sola implementación de software). Esto hace que las simulaciones precisas del rendimiento de la cadena de bloques sean aún más difíciles de realizar. 

En general:

Las afirmaciones de rendimiento requieren una explicación cuidadosa de la carga de trabajo de la transacción y la población de validadores (su cantidad, implementación y conectividad de red). En ausencia de un estándar claro, las cargas de trabajo históricas de una red popular como Ethereum son suficientes.

Compensaciones de latencia y rendimiento

La latencia y el rendimiento suelen ser una compensación. Como Esquemas de Lefteris Kokoris-Kogias, esta compensación a menudo no es suave, con un punto de inflexión en el que la latencia aumenta considerablemente a medida que la carga del sistema se acerca a su rendimiento máximo.

Los sistemas de resumen de conocimiento cero presentan un ejemplo natural de la compensación entre rendimiento y latencia. Grandes lotes de transacciones aumentan el tiempo de prueba, lo que aumenta la latencia. Pero la huella en la cadena, tanto en términos de tamaño de prueba como de costo de validación, se amortizará con más transacciones con lotes más grandes, lo que aumentará el rendimiento.

Tarifas de transacción

Comprensiblemente, los usuarios finales se preocupan más por la compensación entre latencia y multas de cambio de vuelo, no latencia y rendimiento. Los usuarios no tienen ninguna razón directa para preocuparse por el rendimiento, solo porque pueden confirmar transacciones rápidamente por las tarifas más bajas posibles (algunos usuarios se preocupan más por las tarifas y otros más por la latencia). En un nivel alto, las tarifas se ven afectadas por múltiples factores:

1. ¿Cuánta demanda de mercado hay para realizar transacciones?
2. ¿Qué rendimiento total logra el sistema?
3. ¿Cuántos ingresos generales proporciona el sistema a los validadores o mineros?
4. ¿Cuánto de estos ingresos se basa en tarifas de transacción frente a recompensas inflacionarias?

Los dos primeros factores son aproximadamente curvas de oferta/demanda que conducen a un precio de equilibrio del mercado (aunque se ha afirmado que los mineros actúan como un cartel para aumentar las tarifas por encima de este punto). En igualdad de condiciones, un mayor rendimiento debería tender a generar tarifas más bajas, pero están sucediendo muchas cosas más.

En particular, los puntos 3 y 4 anteriores son cuestiones fundamentales del diseño del sistema blockchain, pero carecemos de buenos principios para cualquiera de ellos. Tenemos cierta comprensión de las ventajas y desventajas de dar a los mineros ingresos de recompensas inflacionarias frente a tarifas de transacción. Sin embargo, a pesar de muchos análisis económicos de los protocolos de consenso de blockchain, todavía no tenemos un modelo ampliamente aceptado sobre cuántos ingresos deben ir a los validadores. Hoy en día, la mayoría de los sistemas se basan en una suposición informada sobre cuántos ingresos son suficientes para que los validadores se comporten honestamente sin estrangular el uso práctico del sistema. En modelos simplificados, se puede demostrar que el costo de montar un ataque del 51 % aumenta con las recompensas para los validadores.

Aumentar el costo de los ataques es algo bueno, pero tampoco sabemos cuánta seguridad es "suficiente". Imagina que estás considerando ir a dos parques de diversiones. Uno de ellos afirma gastar un 50 % menos en el mantenimiento de las atracciones que el otro. ¿Es buena idea ir a este parque? Puede ser que sean más eficientes y obtengan una seguridad equivalente por menos dinero. Quizás el otro está gastando más de lo que se necesita para mantener los juegos seguros sin ningún beneficio. Pero también podría darse el caso de que el primer parque sea peligroso. Los sistemas de cadena de bloques son similares. Una vez que se excluye el rendimiento, las cadenas de bloques con tarifas más bajas tienen tarifas más bajas porque recompensan (y, por lo tanto, incentivan) menos a sus validadores. Hoy no tenemos buenas herramientas para evaluar si esto está bien o si deja al sistema vulnerable a un ataque. General:

La comparación de tarifas entre sistemas puede ser engañosa. Aunque las tarifas de transacción son importantes para los usuarios, se ven afectadas por muchos factores además del diseño del sistema en sí. El rendimiento es una mejor métrica para analizar un sistema como un todo.

Conclusión

Evaluar el desempeño de manera justa y precisa es difícil. Esto es igualmente cierto para medir el rendimiento de un automóvil. Al igual que con las cadenas de bloques, diferentes personas se preocuparán por diferentes cosas. Con los automóviles, algunos usuarios se preocuparán por la velocidad máxima o la aceleración, otros por el consumo de gasolina y otros por la capacidad de remolque. Todos estos no son triviales para evaluar. En los EE. UU., por ejemplo, la Agencia de Protección Ambiental mantiene pautas detalladas sobre cómo se evalúa el rendimiento de la gasolina y cómo se debe presentar a los usuarios en un concesionario.

El espacio blockchain está muy lejos de este nivel de estandarización. En ciertas áreas, podemos llegar allí en el futuro con cargas de trabajo estandarizadas para evaluar el rendimiento de un sistema o gráficos estandarizados para presentar distribuciones de latencia. Por el momento, el mejor enfoque para evaluadores y constructores es recopilar y publicar la mayor cantidad de datos posible, con una descripción detallada de la metodología de evaluación, para que pueda reproducirse y compararse con otros sistemas.