Métricas, vectores de análisis y marco teórico para los sistemas blockchain eficientes

Los sistemas blockchain deben escalar para procesar miles de transacciones por segundo, mientras permanecen descentralizados y seguros contra potentes vectores de ataque. Sin embargo, la descentralización, la seguridad y el rendimiento siempre juegan un tira y afloja de 3 vías y, por lo general, se realizan compensaciones entre estas propiedades. ¡Estas propiedades son los pilares centrales de un sistema blockchain! Al mismo tiempo, lograr altos grados de estas tres es, para cualquier sistema, un gran desafío.

Métrica común necesaria

Uno de los problemas que vemos con el ecosistema es la falta de un marco común para analizar el rendimiento de los sistemas blockchain. Los diferentes proyectos se basan en medidas totalmente diferentes, lo que hace que la comparación significativa sea esencialmente imposible. A menudo, se reclaman cientos, miles o millones de transacciones por segundo sin aclarar las suposiciones o configuraciones subyacentes.

Vectores de análisis

Es importante darse cuenta de que hay muchos factores que afectan el rendimiento de la blockchain. Hay dos métricas de rendimiento importantes:

  1. Rendimiento: medido en transacciones por segundo (TPS), y
  1. Tiempos de finalidad: la cantidad de tiempo necesaria para asegurar que las transacciones y los bloques (ya no) cambiarán.

En esta publicación de blog, nos enfocamos en el rendimiento y haremos un seguimiento en una discusión separada sobre los tiempos finales. El siguiente conjunto de dimensiones afecta el rendimiento de blockchain:

  1. Modo con permiso versus sin permiso.

Un sistema de cadena de bloques puede operar en modo sin permiso (donde cualquiera puede unirse al sistema), o en modo con permiso (donde un usuario debe recibir una aprobación especial para unirse y realizar funcionalidades importantes para el sistema).

Los sistemas autorizados son a menudo más fáciles de construir y escalar, ya que uno no necesita preocuparse por una variedad de vectores de ataque (por ejemplo, ataques Sybil) que son posibles en sistemas sin permiso.

  1. Participación directa, delegación o grupos.

Los usuarios individuales pueden participar directamente en el protocolo de consenso o delegar sus «derechos de voto» a un grupo. Alternativamente, solo un equipo especialmente seleccionado de usuarios puede participar en el acuerdo (por ejemplo, en sistemas de prueba de participación vinculados).

En una cadena de bloques descentralizada ideal, cada usuario puede participar en el protocolo de consenso. Delegar su participación en un grupo más pequeño de representantes (solo si él / ella desea hacerlo) debe ser un derecho del usuario, no un requisito previo para que el sistema funcione. Ellos pueden imponer requisitos adicionales a los delegados. Por ejemplo, es posible que se requiera que los encargados mantengan el 99,9% de disponibilidad de sus nodos o se comprometan a asignaciones de ancho de banda más altas. (¡Y debería ser posible verificar el cumplimiento de estas obligaciones!) Del mismo modo, en los sistemas de prueba de participación vinculados, los usuarios especialmente seleccionados pueden tener que asignar más recursos (pero a su vez son más vulnerables a vectores de ataques adicionales que deben ser evaluados). El hecho de que ellos participen directamente en el protocolo o deleguen su participación es una elección o una imposición del sistema. Tanto el porcentaje del dinero y el número total de delegados deben ser reportados.

  1. Tipo de red de propagación.

Es importante comprender si se utiliza una red de propagación de igual a igual o una de transmisión (o entrega de contenido) que no es de confianza.

En una gestión clásica de blockchain, las transacciones y los mensajes de consenso se propagan en una red de igual a igual a cada nodo. Esto implica que un de ellos debe propagar cada intercambio a todos sus pares. Alternativamente, se puede utilizar una red de propagación de retransmisión para acelerar todo los descripto inicialmente. Éstas redes están diseñadas para optimizar el rendimiento, pero también deben resistir una variedad de vectores de ataques adicionales (por ejemplo, Denegación de servicio) y no introducir ataques propios (p. Ej., Un relé centralizado no debería poder censurar a los usuarios o bifurcar la cadena de bloques).

  1. Visibilidad de transacciones.

En una instancia estándar de blockchain, todas las transacciones se registran y están disponibles para que cualquiera las inspeccione. Se pueden implementar varias técnicas (por ejemplo, fragmentación, redes relámpago) para dividir el almacenamiento de la cadena de bloques o realizar transacciones adicionales fuera de ella.

A menudo, estas técnicas se construyen como una capa por encima del protocolo de consenso subyacente. Al analizar el rendimiento, por lo tanto, uno tiene que especificar cuántas transacciones se rastrean explícitamente en la cadena de bloques y cuántas se pueden manejar fuera de ésta. De hecho, algunas transacciones son menos significativas, o nada significativas, si se manejan fuera de la cadena.

  1. Asignaciones de ancho de banda.

Los nodos que asignan más ancho de banda pueden propagar bloques de transacciones más rápido a sus pares. Al realizar un análisis de rendimiento de un sistema blockchain, es importante hacer suposiciones precisas sobre las asignaciones de la velocidad de su red en todos los nodos participantes.

  1. Modelo de seguridad previsto.

Siempre existe un compromiso entre seguridad y rendimiento. Es muy fácil ser rápido e inseguro. De hecho, ¡todo en un sistema blockchain puede ser atacado! Una cadena de bloques debe ser segura contra ataques de nodos bizantinos, externos a nodos que participan en el consenso (por ejemplo, denegación de servicio), a mecanismos de incentivos, a la red, etc.

  1. Mecanismos de compresión.

La calidad de los mecanismos de compresión utilizados para codificar transacciones y bloques afecta en gran medida el rendimiento general del sistema. Los esquemas de cifrados precisos pueden ayudar a minimizar el ancho de banda requerido de los nodos. Los sistemas deben indicar claramente las suposiciones sobre el tamaño de las transacciones subyacentes o cualquier mensaje adicional que se propague a través de la red.

Ejemplo de análisis teórico

Como ejemplo, demostremos un cálculo teórico sobre la tasa de transacción en un entorno específico.

  • Modo sin permisos.
  • Cada usuario participa directamente en el protocolo de consenso.
  • Todas las transacciones y bloques se propagan a todos los nodos del sistema a través de una red de igual a igual. Cada nodo está conectado a 8 pares.
  • Todas las transacciones se confirman y se publican en la cadena de bloques.
  • Cada nodo asigna 56 Mb/s de subida y 112 Mb/s de velocidad de descarga (es decir, el ancho de banda medio asignado por los participantes de Bitcoin).
  • Cada transacción se codifica en 200 bytes y se confirma un bloque cada segundo.
  • No hay gastos generales para que el protocolo de consenso acuerde un bloque de transacciones.

Dados los parámetros anteriores, un rendimiento máximo absoluto que puede admitir un sistema blockchain es (56 Mb / s) / (200 bytes * 8 pares) = 4375 TPS.

Es importante resaltar que el análisis anterior ignora las propiedades estándar de la red, como la pérdida de paquetes, los retrasos en la propagación o transmisión, el número de usuarios en el sistema, la retransmisión, etc., y proporciona un límite superior en la tasa de transacción dados los parámetros anteriores.

Hacia la estandarización

Creemos que es importante iniciar una discusión sobre la estandarización del análisis tanto teórico como empírico de los sistemas blockchain.

Algorand se compromete a ayudar a la comunidad a navegar a través de la variedad de proyectos y aclarar algunas confusiones frecuentes. Alentamos a los internautas a considerar especificar la lista de parámetros anteriores al evaluar o explicar un nuevo proyecto de blockchain.

También fomentamos a la comunidad a sugerir parámetros adicionales y proporcionar comentarios en el formulario de contacto a continuación. Actualizaremos la lista para reflejar los aportes que recibamos.


Este artículo ha sido escrito originalmente por Algorand en el  «Community Blog» de Algorand y traducido por AlgoLatam.

Original Article: https://www.algorand.com/resources/blog/towards-a-unified-metric-for-performance-evaluation-of-proof-of-stake-blockchains

Deja una respuesta

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