Hay muchas métricas relacionadas con la lógica y la calidad de la cadena de bloques. Ayudan a identificar cuellos de botella en el código y a encontrar problemas lógicos y de optimización en el consenso y los algoritmos finales en blockchains. Cualquier desarrollo de sistemas distribuidos, incluidas las cadenas de bloques, requiere un análisis del trabajo de muchos nodos a la vez. Permiten al equipo del proyecto monitorear el estado de toda la red blockchain, ver problemas con nodos individuales, detectar la ocurrencia de ataques DoS en la red y mucho más. Veamos los principales. Vamos a sumergirnos.
"Transacciones por segundo"
En el caso de los sistemas distribuidos, TPS es un número muy cambiante y ambiguo, que no siempre refleja la calidad real del servicio prestado a los usuarios. Las mediciones de TPS nos llegaron de bases de datos distribuidas. Los TPS en las bases de datos están estandarizados para las transacciones de prueba o sus conjuntos (algunos INSERT, algunos ACTUALIZACIÓN, muchos DELETEs en el contexto de SELECCIÓN constante) para una configuración de clúster codificada o incluso en la misma máquina. Estas métricas generalmente dan solo estimaciones aproximadas del rendimiento de las bases de datos distribuidas o blockchains, ya que el tiempo de procesamiento de las transacciones puede variar mucho dependiendo de muchos factores.
Las bases de datos orientadas a la coherencia (consulte “Teorema CAP”) no confirman la transacción hasta que reciben un número suficiente de confirmaciones de otros nodos y esto es lento. Y las bases de datos orientadas a la disponibilidad consideran que una transacción que simplemente se escribió en el disco fue un éxito. Inmediatamente le dan al cliente datos actualizados y es muy rápido (aunque en el futuro, esta transacción puede revertirse). Además, si las transacciones utilizadas en el punto de referencia actualizan solo una celda con datos, el TPS obviamente será mayor que en los casos en que las transacciones pueden afectar muchas celdas y bloquearse entre sí. Los algoritmos para trabajar con estos bloqueos en cada base de datos se implementan a su manera, por eso no vemos "competencias TPS" entre Oracle, MSSQL, PostgreSQL, por un lado, y MongoDB, Redis, Tarantool, por el otro, estos son mecanismos internos muy diferentes y tareas diferentes. .
En mi opinión, "medir TPS" de la cadena de bloques significa tomar una gama completa de mediciones de su rendimiento:
- en condiciones repetibles
- con un número cercano a la realidad de validadores de bloque
- utilizando varios tipos de transacciones:
- típico de la cadena de bloques estudiada (por ejemplo, transferencia () de la criptomoneda principal)
- cargando subsistema de almacenamiento (una gran cantidad de cambios de cada transacción)
- ancho de banda de carga (gran volumen de transacciones)
- Carga de CPU (en caso de transformaciones o cálculos criptográficos masivos)
Para hablar sobre las "transacciones por segundo" apreciadas, debe describir todas las condiciones (el número de validadores, su distribución geográfica, el nivel de pérdida de paquetes, etc.) y la lógica de la evaluación comparativa. En blockchains, simplemente transferir una transacción a una base de datos interna no significa su aceptación por consenso. Por ejemplo, en el caso de Prueba de trabajo, estadísticamente, las transacciones nunca se completan en absoluto, y si una transacción se incluye en un bloque en una máquina, esto no significa que será aceptada por toda la red (por ejemplo, si gana otra bifurcación).
Si la cadena de bloques tiene un algoritmo adicional para garantizar la finalidad de las transacciones (EOS, Ethereum 2.0, Polkadot parachains que utilizan el consenso con la finalidad de GRANDPA), entonces el tiempo de procesamiento puede considerarse la brecha entre el nodo "vio" la transacción y el siguiente bloque finalizado donde se realizó esta transacción incluido. Tal, más cerca de la realidad, "TPS" rara vez se ve en las promesas del proyecto. Naturalmente, son más bajos que los descritos en el Whitepaper, pero son lo más informativos posible.
Así que les advierto nuevamente, se pueden incluir muchos significados diferentes en el término "TPS". Sea escéptico y solicite detalles.
Métricas específicas de blockchain
Tps locales
Es muy conveniente medir el número de transacciones procesadas por el nodo y el tiempo máximo / promedio / mínimo de su procesamiento en el nodo local, ya que las funciones que realizan esta operación generalmente se asignan explícitamente en el código. Simplemente puede medir cuánto tiempo funcionó la transacción actualizando la base de datos de estado. Es posible que estas transacciones aún no se acepten por consenso, pero ya han pasado la validación y el nodo ya puede proporcionar al cliente datos actualizados (suponiendo que la cadena de la bifurcación no aparece).
Esta métrica no es muy honesta: si se elige otra bifurcación de la cadena como la principal, entonces las estadísticas sobre las transacciones revertidas también deben revertirse. Pero para las pruebas, esto casi siempre se puede descuidar.
A menudo, este es el número que se escribe en informes breves: "nuestra cadena de bloques recibió 8,000 tps ayer", ya que es fácil de medir: solo un nodo en ejecución y un script que lo carga son suficientes. En este caso, no hay demora en la red, lo que ralentiza el alcance de la red y la métrica muestra el rendimiento de la base de datos del estado sin la influencia de la red. Este número no es el ancho de banda real de la red blockchain, pero muestra el límite al que se esforzará si el consenso y la red son lo suficientemente rápidos.
El resultado de cualquier transacción de blockchain son varias actualizaciones atómicas del almacenamiento. Por ejemplo, una transacción de pago en Bitcoin es la eliminación de varios UTXO antiguos (eliminar) y la adición de varios nuevos UTXO (insertar), y en Ethereum es la ejecución de un breve código de contrato inteligente y, nuevamente, actualizar varios pares clave-valor. El número de estas operaciones de escritura "atómicas" puede ser una métrica excelente que le permite identificar cuellos de botella en el subsistema de almacenamiento y la lógica de transacción interna.
Además, los nodos de blockchain se pueden implementar en varios lenguajes de programación, esto es más confiable. Esto debe tenerse en cuenta al evaluar el rendimiento de la red, por ejemplo, el nodo Ethereum existe en implementaciones en Rust and Go. Otras blockchains también buscan tener implementaciones adicionales para la confiabilidad.
Cantidad de bloques producidos localmente
Esta métrica simple muestra qué validador produjo cuántos bloques. Es un producto de consenso y puede considerarse el principal para evaluar la "utilidad" de una red de validadores individuales.
Al ganar dinero en cada bloque, los validadores están interesados en la operación estable y la seguridad de sus máquinas. Este número ayuda a determinar cuál de los validadores candidatos es el más calificado, protegido y preparado para trabajar en una red pública con los activos de los usuarios reales. El valor de la métrica se puede verificar públicamente simplemente descargando la cadena de bloques y calculando quién produjo cuántos bloques.
Finalidad y último bloque irreversible
En redes con una finalidad claramente implementada (EOS, Ethereum, Tendermint, Polkadot, etc.), además del consenso básico y rápido (en el que una firma de validación por bloque es suficiente), algunos bloques requieren la coordinación de un grupo de validadores. Estos bloques se consideran finales, y el algoritmo de recopilación de firmas se considera final. La tarea de la finalidad es asegurarse de que todas las transacciones incluidas en la cadena de bloques antes del bloque finalizado nunca se expulsen y no sean reemplazadas por otra bifurcación de la cadena. Esta es una protección contra ataques de doble gasto en redes de prueba de participación, y una forma de devolver rápidamente, en unos segundos, una confirmación confiable de una transacción de criptomonedas a un usuario.
Desde el punto de vista del usuario de blockchain, la transacción no se completa en el momento en que es aceptada por el nodo, sino cuando aparece un bloque que finaliza la cadena en la que se encuentra la transacción. Para finalizar un bloque, los validadores deben recibir este bloque en una red p2p e intercambiar firmas entre ellos. Es aquí donde se verifica la velocidad real de la cadena de bloques, porque el usuario está interesado en el momento de finalizar el bloque con su transacción, y no solo aceptarlo y escribirlo en el disco de uno de los nodos.
Los algoritmos de finalidad también difieren, se cruzan y se combinan con el consenso principal (para leer: Casper en Ethereum, Últimos bloques irreversibles en EOS, GRANDPA en Parity Polkadot y sus modificaciones, por ejemplo MixBytes RANDPA).
Para redes donde no todos los bloques están finalizados, una métrica útil es el retraso del último bloque finalizado del último bloque actual. Este número muestra cómo los validadores están rezagados, acordando la cadena correcta. Si la brecha es grande, entonces el algoritmo de finalización requiere análisis y optimización adicionales.
Otras métricas de blockchain
El resto de las métricas generalmente dependen en gran medida del tipo de consenso, por lo que no es muy correcto representarlas entre las principales. Entre estos parámetros, por ejemplo: el número de horquillas de cadena, su longitud en bloques, la ocupación de bloques con transacciones, etc. Se pueden usar para identificar situaciones de separación de red o localizar rápidamente problemas de un validador específico.
Capa P2P
Es extremadamente importante recordar la base intermedia de las redes blockchain: el subsistema punto a punto. Es ella quien introduce retrasos vagos en la entrega de bloques y transacciones entre validadores. Cuando el número de validadores es pequeño, están localizados, las listas de pares están codificadas, todo funciona bien y rápidamente. Pero vale la pena agregar validadores, distribuir nodos geográficamente y emular la pérdida de paquetes, ya que aparecen fallas significativas en "tps".
Por ejemplo, cuando se prueba el consenso EOS con el algoritmo de finalidad opcional, aumentar el número de validadores incluso a 80-100 máquinas espaciadas en cuatro continentes no afectó significativamente la velocidad de alcanzar la finalidad. Al mismo tiempo, un aumento en la pérdida de paquetes afectó fuertemente el retraso de la finalidad, lo que indica la necesidad de una configuración adicional de la capa p2p para una mayor resistencia a la pérdida de paquetes de red y no a una latencia grande. Desafortunadamente, hay muchas configuraciones y factores diferentes, por lo tanto, solo los puntos de referencia nos permiten comprender la cantidad efectiva de validadores que proporcionan una velocidad bastante cómoda de la cadena de bloques.
El subsistema p2p del dispositivo se puede entender a partir de la documentación, por ejemplo, en libp2p o la documentación en el protocolo Kademlia o BitTorrent .
Las métricas importantes para p2p son:
- tráfico entrante-saliente
- cantidad de conexiones exitosas / no exitosas con otros pares
- cuántas veces se devolvieron datos de fragmentos almacenados en caché anteriormente y cuántas veces fue necesario reenviar la solicitud en busca del fragmento deseado (análogo de aciertos / errores de caché)
Por ejemplo, una gran cantidad de errores al acceder a los datos significa que solo un pequeño número de nodos tiene los datos solicitados, y no tienen tiempo para distribuirlos a todos, y la cantidad de tráfico p2p recibido / dado le permitirá establecer un nodo que tiene problemas con la configuración de la red o el canal.
Métricas del sistema de nodo de blockchain
Las métricas del sistema estándar de los nodos de blockchain se describen en una gran cantidad de fuentes, por lo que las describiré brevemente. Su función es ayudar a buscar cuellos de botella y errores en todas las partes del código, mostrando qué subsistemas de los nodos están más cargados y qué tareas.
CPU
Hablan sobre cuántos cálculos realiza el procesador. Si la carga de la CPU es alta, entonces el nodo está calculando algo, usando activamente lógica o FPU (casi nunca se usa en blockchains). En blockchains, esto puede deberse, por ejemplo, al hecho de que el nodo verifica las firmas electrónicas, procesa transacciones con criptografía pesada o realiza cálculos complejos.
La CPU se puede "cortar" en varias métricas más útiles para comprender qué partes del código son las más costosas. Por ejemplo, el sistema es el código del núcleo, el usuario es el proceso del usuario, io está esperando la E / S de dispositivos externos lentos (disco / red), etc. Aquí hay un buen artículo relacionado.
Memoria
Las cadenas de bloques modernas usan bases de datos de valores clave (LevelDB, RocksDB), que mantienen constantemente los datos calientes en la memoria. Al igual que con cualquier servicio cargado, las pérdidas de memoria siempre son posibles como resultado de errores o ataques dirigidos al código de nodo. Si el consumo del nodo de memoria aumenta o ha aumentado bruscamente, lo más probable es que esto se deba a un aumento en el número de claves en la base de datos de estado, grandes colas de transacciones o un aumento en el número de mensajes entre diferentes subsistemas del nodo. La carga insuficiente de la memoria puede indicar un posible aumento en los límites de datos en bloques o la máxima complejidad de la transacción.
Para los nodos completos, que es https://habrastorage.org/webt/qa/sn/m5/qasnm5bougkjuagneevjkpg9x0w.png que corresponden a clientes de red, las métricas de caché de archivos también son importantes. Los clientes acceden a varias partes de la base de datos estatal y el registro de transacciones. Esto crea un aumento de bloques viejos del disco, que puede desplazar nuevos bloques, lo que a su vez ralentiza la respuesta al cliente.
Red
Las principales métricas de la red interna son la cantidad de tráfico en bytes, la cantidad de paquetes de red enviados y recibidos para cada uno y los protocolos, la relación de pérdida de paquetes. En blockchains, estas métricas a menudo no reciben mucha atención, porque blockchains aún no procesa transacciones a una velocidad de 1 Gbit / seg.
Hay proyectos de blockchain que permiten a los usuarios compartir su wifi o proporcionar servicios para almacenar y transferir archivos o mensajes. Al probar dichas redes, la cantidad y calidad del tráfico a través de la interfaz de red se convierte en una métrica extremadamente importante, ya que un canal de red abarrotado afecta a todos los demás servicios en la máquina, sin excepción.
Almacenamiento
El subsistema de disco es el componente más lento en cualquier servicio y, a menudo, causa serios problemas de rendimiento. El registro excesivo, una copia de seguridad inesperada, un patrón de lectura / escritura inconveniente, un gran volumen total de blockchain: todo esto puede conducir a una desaceleración significativa en el funcionamiento del nodo o a requisitos muy excesivos para el hardware.
El registro de transacciones puede considerarse técnicamente como WAL ( WAL ) para la base de datos estatal, por lo tanto, esas métricas de almacenamiento son importantes que le permiten buscar cuellos de botella en los mecanismos de las bases de datos modernas de valores clave. Estos son el número de IOPS de lectura / escritura, latencia máxima / mínima / promedio y muchas otras métricas que ayudan a optimizar las operaciones del disco.
Conclusión
Entonces, examinamos varios conjuntos de métricas que pueden proporcionar información muy valiosa sobre el funcionamiento de la red blockchain y las posibilidades para su optimización. Para resumir, puede reunirlos en tres grupos:
- métricas de blockchain de nodos:
la cantidad de bloques producidos, la cantidad de transacciones procesadas, su tiempo de procesamiento, tiempo de finalización, etc. - métricas del subsistema p2p:
la cantidad de solicitudes de hit / miss, la cantidad de pares activos, el volumen y la estructura del tráfico p2p, etc. - métricas del sistema de nodos:
CPU, memoria, almacenamiento, red, etc.
Cada uno de los grupos es importante a su manera, ya que en cada uno de los subsistemas puede haber errores que restrinjan el funcionamiento de otros componentes, y la desaceleración incluso de un pequeño número de validadores puede tener un grave impacto en toda la red. Además, los errores más complicados en los algoritmos de consenso y finalidad surgen solo con un gran flujo de transacciones o cambios en los parámetros de consenso. Su análisis requiere condiciones de prueba reproducibles y escenarios de carga complejos.
El desarrollo de blockchains es siempre la orquestación de varias máquinas, scripts para diseñar configuraciones y el lanzamiento coordinado de nodos y puntos de referencia, un servidor para recopilar métricas y registros de todas las máquinas. Por lo tanto, cuando desarrolle su cadena de bloques, considere contratar a un proveedor calificado: proporcionará un apoyo invaluable para el equipo de desarrollo. Buena suerte