La pregunta favorita de cualquier persona no técnica sobre un sistema distribuido es “¿Cuántos TPS tiene su blockchain?”. Sin embargo, el número mencionado en respuesta a menudo tiene poco que ver con lo que el preguntador desea escuchar. En realidad, quería preguntar “¿se adaptará su blockchain a mis requisitos comerciales?”, y estos requisitos no son un solo número, sino un conjunto de condiciones: la resiliencia de la red, los requisitos de finalización, el tamaño, la naturaleza de las transacciones y muchos otros parámetros. Así que la respuesta a la pregunta “¿cuántos TPS?” probablemente no será simple, y casi nunca será completa. Un sistema distribuido con decenas y cientos de nodos realizando cálculos bastante complejos puede estar en una enorme cantidad de estados diferentes, relacionados con el estado de la red, el contenido del blockchain, fallos técnicos, problemas económicos, ataques a la red y muchas otras razones. Las etapas en las que pueden surgir problemas de rendimiento son diferentes de los servicios tradicionales, y el servidor de la red blockchain es un servicio en red que combina las funciones de una base de datos, un servidor web y un cliente de torrent, lo que lo hace extremadamente complejo en términos de perfil de carga en todos los subsistemas: CPU, memoria, red, almacenamiento.

Resulta que las redes descentralizadas y los blockchains son un software bastante específico y poco familiar para los desarrolladores de software centralizado. Por lo tanto, me gustaría destacar aspectos importantes del rendimiento y la resiliencia de las redes descentralizadas, enfoques para medirlas y localizar bottlenecks. Abordaremos diversos problemas de rendimiento que limitan la velocidad de entrega del servicio a los usuarios de blockchains y señalaremos características que son propias de este tipo de software.

Fases de la solicitud de servicio del cliente de blockchain

Para hablar honestamente sobre la calidad de cualquier servicio más o menos complejo, no solo es necesario considerar los promedios, sino también los máximos/mínimos, medianas y percentiles. Teóricamente, se puede hablar de 1000 tps en algún blockchain, pero si 900 transacciones se realizaron a gran velocidad y 100 "se congelaron" durante varios segundos, el tiempo promedio recopilado de todas las transacciones no es una métrica completamente justa para un cliente que no pudo completar la transacción en unos pocos segundos. Los "baches" temporales, causados por rondas de consenso omitidas o división de red, pueden perjudicar gravemente un servicio que mostraba un excelente rendimiento en bancos de prueba.

Para identificar tales cuellos de botella, es necesario entender bien las etapas en las que un blockchain real puede experimentar dificultades para atender a los usuarios. Describamos el ciclo de entrega y procesamiento de transacciones, así como la obtención de un nuevo estado del blockchain, del cual el cliente puede asegurarse de que su transacción ha sido procesada y contabilizada.

la transacción se forma en el cliente
la transacción se firma en el cliente
el cliente elige uno de los nodos y envía su transacción a él
el cliente se suscribe a las actualizaciones de la base de datos de estado del nodo, esperando la aparición de los resultados de la ejecución de su transacción
el nodo propaga la transacción a través de la red p2p
varios o un BP (productor de bloques) procesan las transacciones acumuladas, actualizando la base de datos de estado
el BP forma un nuevo bloque, procesando la cantidad necesaria de transacciones
el BP propaga el nuevo bloque a través de la red p2p
el nuevo bloque es entregado al nodo al que se dirige el cliente
el nodo actualiza la base de datos de estado
el nodo ve una actualización relacionada con el cliente y le envía una notificación sobre la transacción

Ahora analicemos estos pasos con más detalle y describamos los posibles problemas de rendimiento en cada etapa. A diferencia de los sistemas centralizados, también consideraremos la ejecución del código en los clientes de la red. Es bastante común que al medir tps, el tiempo de procesamiento de las transacciones se obtenga de los nodos y no del cliente; esto no es del todo justo. Al cliente no le importa cuán rápido procesó el nodo su transacción, lo más importante para él es el momento en que la información verificada sobre esa transacción, incluida en la blockchain, esté disponible para él. Esta métrica es, en esencia, el tiempo de ejecución de la transacción. Esto significa que diferentes clientes, incluso al enviar la misma transacción, pueden obtener tiempos completamente diferentes, que dependen del canal, la carga y la cercanía del nodo, entre otros factores. Por lo tanto, es absolutamente necesario medir este tiempo en los clientes, ya que es este parámetro el que necesita ser optimizado.

Preparación de la transacción del lado del cliente

Empezaremos con los primeros dos puntos: la transacción se forma y se firma por el cliente. Curiosamente, esto también puede ser un cuello de botella para el rendimiento de la blockchain desde el punto de vista del cliente. Esto es inusual para los servicios centralizados, que realizan todos los cálculos y operaciones con datos, mientras que el cliente solo prepara una breve solicitud capaz de solicitar grandes volúmenes de datos o cálculos, obteniendo un resultado listo. En las blockchains, el código del cliente se vuelve cada vez más poderoso, mientras que el núcleo de la blockchain se vuelve cada vez más liviano, y las tareas computacionales masivas se suelen delegar al software del cliente. En las blockchains, existen clientes que pueden preparar una transacción durante un tiempo considerable (hablo de diferentes pruebas de Merkle, pruebas concisas, firmas umbral y otras operaciones complejas del lado del cliente). Un buen ejemplo de verificación on-chain ligera y preparación pesada de la transacción en el cliente es la prueba de pertenencia a una lista basada en Merkle-tree. Windows.

También es importante recordar que el código del cliente no solo envía transacciones a la cadena de bloques, sino que primero consulta el estado de la cadena de bloques; y esta actividad puede afectar la carga de la red y de los nodos de la cadena de bloques. Por lo tanto, al realizar mediciones, es razonable emular lo más completamente posible el comportamiento del código del cliente. Incluso si en su cadena de bloques hay clientes ligeros comunes que solo firman digitalmente una transacción sencilla de transferencia de algún activo, cada año las computaciones masivas en el cliente siguen aumentando, los algoritmos criptográficos se van volviendo más robustos, y esta parte del procesamiento puede convertirse en un bottleneck significativo en el futuro. Así que tenga cuidado, y no pase por alto la situación en la que, durante una transacción que dura 3.5 segundos, 2.5 segundos se destinan a la preparación y firma de la transacción, y 1.0 segundos a su envío a la red y la espera de la respuesta. Para evaluar los riesgos de aparición de este bottleneck, es necesario recopilar métricas de las máquinas de los clientes, y no solo de los nodos de la cadena de bloques.

Envío de transacciones y monitoreo de su estado

El siguiente paso es enviar la transacción al nodo de la cadena de bloques elegido y recibir el estado de su aceptación en el grupo de transacciones. Este paso es similar a una consulta normal a una base de datos, el nodo debe registrar la transacción en el grupo y comenzar a difundir la información sobre ella a través de la red p2p. El enfoque para evaluar el rendimiento aquí es similar al de evaluar el funcionamiento de microservicios tradicionales de API web, de modo que las propias transacciones en las cadenas de bloques pueden actualizarse y cambiar de estado activamente. En general, la actualización de la información sobre la transacción en algunas cadenas de bloques puede ocurrir varias veces, por ejemplo, al cambiar entre bifurcaciones de la cadena o cuando los BP notifican sobre la intención de incluir la transacción en un bloque. Las limitaciones sobre el tamaño de este grupo y la cantidad de transacciones en él pueden influir en el rendimiento de la cadena de bloques. Si el grupo de transacciones está lleno hasta su tamaño máximo, o no cabe en la memoria RAM, el rendimiento de la red puede caer drásticamente. Las cadenas de bloques no tienen medios de protección centralizados contra flujos de mensajes basura, y si la cadena de bloques admite transacciones de gran volumen y comisiones bajas, esto puede llevar a un desbordamiento del grupo de transacciones; este es otro potencial bottleneck de rendimiento.

En las cadenas de bloques, el cliente envía una transacción a cualquier nodo de la cadena que le guste, el hash de la transacción generalmente es conocido por el cliente antes de enviarla, así que lo único que necesita hacer es establecer la conexión y después de enviar, esperar a que la cadena de bloques cambie su estado, incluyendo su transacción. Cabe señalar que al medir el «tps» se pueden obtener resultados muy diferentes para distintos métodos de conexión al nodo de la cadena de bloques. Esto puede ser una RPC HTTP normal o un WebSocket, que permite implementar el patrón de «suscripción». En el segundo caso, el cliente recibirá la notificación antes, y el nodo consumirá menos recursos (principalmente memoria y tráfico) al responder sobre el estado de la transacción. Por lo tanto, al medir el «tps», es necesario tener en cuenta la forma de conexión de los clientes a los nodos. Así que, para evaluar los riesgos de aparición de este bottleneck, el benchmark de la cadena de bloques debe ser capaz de emular clientes tanto con solicitudes de WebSocket como de RPC HTTP, en proporciones que correspondan a las redes reales, así como cambiar la naturaleza de las transacciones y su tamaño.

Para evaluar los riesgos de aparición de este bottleneck, también es necesario recopilar métricas desde las máquinas de los clientes, y no solo desde los nodos de la cadena de bloques.

Transmisión de transacciones y bloques a través de la red p2p

En las cadenas de bloques, se utiliza la red peer-to-peer (p2p) para la transmisión de transacciones y bloques entre los participantes. Las transacciones se propaguen por la red, comenzando desde uno de los nodos, hasta que alcanzan a los pares-productores de bloques, que empaquetan las transacciones en bloques y, utilizando el mismo p2p, distribuyen los nuevos bloques a todos los nodos de la red. La base de la mayoría de las redes p2p modernas son varias modificaciones del protocolo Kademlia. Aquí una buena visión general de este protocolo, y aquí — un artículo con diversas mediciones en la red BitTorrent, a partir del cual se puede entender — que este tipo de redes es más complejo y menos predecible que una red de servicio centralizada rígidamente configurada. Además, aquí un artículo sobre la medición de diversas métricas interesantes para los nodos de Ethereum.

En resumen, cada peer en estas redes mantiene su propia lista dinámica de otros peers a los que solicita bloques de información, los cuales se direccionan por contenido. Al recibir una solicitud, el peer proporciona la información requerida o reenvía la solicitud al siguiente peer pseudoaleatorio de la lista, y al obtener una respuesta, la envía al solicitante y la almacena en caché por un tiempo, entregando este bloque de información antes la próxima vez. Así, la información popular se encuentra en muchos cachés de un gran número de peers, mientras que la información impopular se desplaza gradualmente. Los peers llevan un registro de cuánta información ha transferido cada uno, y la red intenta incentivar a los donantes activos, aumentando su clasificación y proporcionándoles un mejor nivel de servicio, expulsando automáticamente a los participantes inactivos de las listas de peers.

Así que ahora es necesario difundir la transacción a través de la red para que los productores de bloques la vean e incluyan en el bloque. El nodo 'reparte' activamente la nueva transacción a todos los interesados y escucha la red, esperando un bloque en el índice que contenga la transacción necesaria para notificar al cliente que está esperando. El tiempo que toma para que la red pase información sobre nuevas transacciones y bloques en redes p2p depende de una gran cantidad de factores: la cantidad de nodos honestos y operativos cercanos (desde el punto de vista de la red), la 'temperatura' de los cachés de estos nodos, el tamaño de los bloques, las transacciones, la naturaleza de los cambios, la geografía de la red, la cantidad de nodos y muchos otros factores. Las mediciones complejas de métricas de rendimiento en estas redes son complicadas; es necesario evaluar simultáneamente el tiempo de procesamiento de solicitudes tanto en clientes como en peers (nodos de blockchain). Los problemas en cualquiera de los mecanismos p2p, la expulsión y el almacenamiento en caché de datos erróneos, la gestión ineficaz de listas de peers activos, y muchos otros factores pueden causar retrasos que afectan la eficiencia de toda la red en conjunto, y este cuellos de botella es el más complejo de analizar, probar e interpretar los resultados.

Procesamiento de la cadena de bloques y actualización de la base de datos de estado

La parte más importante del funcionamiento de la blockchain es el algoritmo de consenso, su aplicación a los nuevos bloques obtenidos de la red y el procesamiento de transacciones con registro de los resultados en la base de datos del estado. La adición de un nuevo bloque a la cadena y la selección de la cadena principal deben funcionar lo más rápido posible. Sin embargo, en la vida real, "debe" no significa "funciona", y se puede imaginar una situación en la que dos largas cadenas competidoras cambian constantemente entre sí, alterando los metadatos de miles de transacciones en el grupo en cada cambio, y produciendo constantes retrocesos en el estado de la base de datos. Esta etapa, en términos de identificación de cuellos de botella, es más simple que la capa p2p de red, ya que la ejecución de transacciones y el algoritmo de consenso son estrictamente deterministas, y es más fácil medir algo aquí.
Lo principal es no confundir la degradación aleatoria del rendimiento de esta etapa con problemas de red; los nodos devuelven bloques e información sobre la cadena principal más lentamente, y para un cliente externo esto puede parecer una red lenta, aunque el problema radica en otro lugar.

Para optimizar el rendimiento en esta etapa, es útil recopilar y supervisar métricas de los propios nodos e incluir aquellas que se relacionan con la actualización de la base de datos de estado: el número de bloques procesados en cada nodo, su tamaño, el número de transacciones, la cantidad de cambios entre bifurcaciones de cadenas, el número de bloques inválidos, el tiempo de ejecución de la máquina virtual, el tiempo de grabación de datos, etc. Esto permitirá no confundir problemas de red con errores en los algoritmos de procesamiento de cadenas.

La máquina virtual que procesa transacciones puede ser una fuente útil de información capaz de optimizar el funcionamiento de la blockchain. La cantidad de asignaciones de memoria, el número de instrucciones de lectura/escritura y otras métricas relacionadas con la eficiencia de la ejecución del código de contratos pueden proporcionar mucha información útil a los desarrolladores. Al mismo tiempo, los contratos inteligentes son programas, y eso significa que, en teoría, pueden consumir cualquiera de los recursos: CPU/memoria/red/almacenamiento, por lo que el procesamiento de transacciones es una etapa bastante indefinida, que además cambia significativamente al pasar entre versiones y al modificar el código de los contratos. Por lo tanto, las métricas relacionadas con el procesamiento de transacciones también son necesarias para una optimización eficiente del rendimiento de la blockchain.

Notificación del cliente sobre la activación de la transacción en la blockchain

Esta es la etapa final en la recepción del servicio de la blockchain por parte del cliente. A diferencia de otras etapas, aquí no hay grandes costos adicionales, pero aún así se debe considerar la posibilidad de que el cliente reciba una gran cantidad de datos de la nodo (por ejemplo, un contrato inteligente que devuelve un array de datos). En cualquier caso, este es el momento más importante para quien se pregunta: "¿cuántos tps tiene su blockchain?", ya que en este momento se registra el tiempo de recepción del servicio.

En este punto, se debe enviar el tiempo completo que el cliente ha tardado en esperar la respuesta de la blockchain. Este es el tiempo que el usuario esperará para recibir la confirmación en su aplicación, y la optimización de este tiempo es la principal tarea de los desarrolladores.

Conclusión

Como resultado, se pueden describir los tipos de operaciones que se realizan en las blockchains y dividirlas en varias categorías:

transformaciones criptográficas, construcción de pruebas
redes peer-to-peer, replicación de transacciones y bloques
procesamiento de transacciones, ejecución de contratos inteligentes
aplicación de cambios en la blockchain a la base de datos de estado, actualización de datos sobre transacciones y bloques
consultas de solo lectura a la base de datos de estado, API de nodos de blockchain, servicios de suscripción

En general, los requisitos técnicos para los nodos de las blockchains modernas son extremadamente serios: se necesitan CPUs rápidas para la criptografía, una gran cantidad de memoria RAM para almacenar y acceder rápidamente a la base de datos de estado, interacciones de red que utilicen un gran número de conexiones abiertas simultáneamente, y un almacenamiento voluminoso. Estas altas exigencias y la variedad de tipos de operaciones conducen inevitablemente a que los nodos puedan no tener suficientes recursos, lo que puede hacer que cualquiera de las etapas discutidas anteriormente se convierta en un nuevo cuello de botella para el rendimiento general de la red.

Al desarrollar y evaluar el rendimiento de las blockchain, deberá tener en cuenta todos estos aspectos. Para ello, es necesario recopilar y analizar métricas tanto de los clientes como de los nodos de la red, buscar correlaciones entre ellas, evaluar el tiempo de prestación del servicio a los clientes, considerar todos los recursos principales: cpu/memoria/red/almacenamiento, y comprender cómo se utilizan y afectan entre sí. Todo esto hace que comparar la velocidad de diferentes blockchain en términos de 'cuántos TPS' sea una tarea ingrata, ya que existe una enorme cantidad de diferentes configuraciones y estados. En grandes sistemas centralizados, clústeres de cientos de servidores, estos problemas también son complejos y requieren la recopilación de un gran número de diferentes métricas, pero en las blockchain, debido a las redes p2p, máquinas virtuales, contratos procesales y economías internas, el número de grados de libertad es mucho mayor, lo que hace que las pruebas en unos pocos servidores sean poco representativas y que solo muestren valores aproximados, casi sin relación con la realidad.

Por lo tanto, al desarrollar en el núcleo de la blockchain, para evaluar el rendimiento y responder a la pregunta '¿ha mejorado en comparación con la última vez?', utilizamos un software bastante complejo que orquesta el lanzamiento de la blockchain con decenas de nodos y la ejecución automática de benchmarks y recopilación de métricas. Sin esta información, es extremadamente difícil depurar protocolos que funcionan con múltiples participantes.

Así que, al recibir la pregunta '¿cuántos TPS tiene su blockchain?', ofrezca a su interlocutor un té y pregunte si está listo para conocer una docena de gráficos, así como escuchar todos los inconvenientes del rendimiento de las blockchain junto con sus propuestas para solucionarlos...

Fuente: habr.com