Una pregunta favorita de una persona sin conocimientos técnicos sobre cualquier sistema distribuido es "¿Cuántos tps hay en su cadena de bloques?" Sin embargo, el número dado en respuesta normalmente tiene poco en común con lo que al interrogador le gustaría escuchar. De hecho, quería preguntar "¿su cadena de bloques se ajustará a los requisitos de mi negocio?", y estos requisitos no son un número, sino muchas condiciones: aquí están la tolerancia a fallas de la red, los requisitos de finalidad, los tamaños, la naturaleza de las transacciones y muchos otros parámetros. Por lo tanto, es poco probable que la respuesta a la pregunta "cuántos tps" sea simple y casi nunca completa. Un sistema distribuido con decenas o cientos de nodos que realizan cálculos bastante complejos puede encontrarse en una gran cantidad de estados diferentes relacionados con el estado de la red, el contenido de la cadena de bloques, fallas técnicas, problemas económicos, ataques a la red y muchas otras razones. . Las etapas en las que son posibles los problemas de rendimiento difieren de los servicios tradicionales, y un servidor de red blockchain es un servicio de red que combina la funcionalidad de una base de datos, un servidor web y un cliente torrent, lo que lo hace extremadamente complejo en términos del perfil de carga en todos los subsistemas. : procesador, memoria, red, almacenamiento

Sucede que las redes descentralizadas y las blockchains son software bastante específicos e inusuales para los desarrolladores de software centralizados. Por lo tanto, me gustaría resaltar aspectos importantes del desempeño y la sostenibilidad de las redes descentralizadas, los enfoques para medirlas y encontrar cuellos de botella. Analizaremos varios problemas de rendimiento que limitan la velocidad de prestación de servicios a los usuarios de blockchain y notaremos las características características de este tipo de software.

Etapas de una solicitud de servicio por parte de un cliente blockchain

Para hablar honestamente sobre la calidad de cualquier servicio más o menos complejo, es necesario tener en cuenta no sólo los valores medios, sino también los máximos/mínimos, las medianas y los percentiles. Teóricamente, podemos hablar de 1000 tps en alguna cadena de bloques, pero si se completaron 900 transacciones a una velocidad enorme y 100 quedaron "atascadas" durante unos segundos, entonces el tiempo promedio recopilado en todas las transacciones no es una métrica completamente justa para un cliente. quien no pude completar la transacción en unos segundos. Los "agujeros" temporales causados por rondas de consenso perdidas o divisiones de red pueden arruinar en gran medida un servicio que ha mostrado un rendimiento excelente en los bancos de pruebas.

Para identificar estos cuellos de botella, es necesario comprender bien las etapas en las que una cadena de bloques real puede tener dificultades para atender a los usuarios. Describamos el ciclo de entrega y procesamiento de una transacción, así como la obtención de un nuevo estado de la blockchain, a partir del cual el cliente puede verificar que su transacción ha sido procesada y contabilizada.

la transacción se forma en el cliente
la transacción está firmada por el cliente
el cliente selecciona uno de los nodos y le envía su transacción
el cliente se suscribe a actualizaciones de la base de datos de estado del nodo, esperando que aparezcan los resultados de su transacción
el nodo distribuye la transacción a través de la red p2p
varios o un BP (productor de bloques) procesa transacciones acumuladas, actualizando la base de datos estatal
BP forma un nuevo bloque después de procesar la cantidad requerida de transacciones
BP distribuye un nuevo bloque a través de la red p2p
el nuevo bloque se entrega al nodo al que accede el cliente
El nodo actualiza la base de datos del estado.
el nodo ve la actualización sobre el cliente y le envía una notificación de transacción

Ahora echemos un vistazo más de cerca a estas etapas y describamos los posibles problemas de rendimiento en cada etapa. A diferencia de los sistemas centralizados, también consideraremos la ejecución de código en clientes de red. Muy a menudo, al medir TPS, el tiempo de procesamiento de transacciones se recopila de los nodos y no del cliente; esto no es del todo justo. Al cliente no le importa qué tan rápido el nodo procesó su transacción, lo más importante para él es el momento en que esté disponible para él información confiable sobre esta transacción incluida en la cadena de bloques. Esta métrica es esencialmente el tiempo de ejecución de la transacción. Esto significa que diferentes clientes, incluso enviando la misma transacción, pueden recibir tiempos completamente diferentes, que dependen del canal, carga y proximidad del nodo, etc. Por lo que es absolutamente necesario medir este tiempo en los clientes, ya que este es el parámetro que hay que optimizar.

Preparar una transacción del lado del cliente

Empecemos por los dos primeros puntos: la transacción la forma y firma el cliente. Por extraño que parezca, esto también puede ser un cuello de botella en el rendimiento de blockchain desde el punto de vista del cliente. Esto es inusual en los servicios centralizados, que se hacen cargo de todos los cálculos y operaciones con datos, y el cliente simplemente prepara una breve solicitud que puede solicitar una gran cantidad de datos o cálculos, obteniendo un resultado listo. En las cadenas de bloques, el código del cliente se vuelve cada vez más poderoso, el núcleo de la cadena de bloques se vuelve cada vez más liviano y las tareas informáticas masivas generalmente se transfieren al software del cliente. En blockchains, hay clientes que pueden preparar una transacción durante bastante tiempo (me refiero a varias pruebas merkle, pruebas sucintas, firmas de umbral y otras operaciones complejas en el lado del cliente). Un buen ejemplo de verificación sencilla en cadena y preparación exhaustiva de una transacción con el cliente es la prueba de membresía en una lista basada en Merkle-tree, aquí artículo.

Además, no olvide que el código del cliente no simplemente 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 congestión de la red y los nodos de la cadena de bloques. Por lo tanto, al tomar medidas, sería razonable emular el comportamiento del código del cliente lo más completamente posible. Incluso si en su cadena de bloques hay clientes livianos comunes y corrientes que ponen una firma digital regular en la transacción más simple para transferir algún activo, cada año hay cálculos más masivos sobre el cliente, los algoritmos criptográficos se fortalecen y esta parte del procesamiento puede convertirse en un importante cuello de botella en el futuro. Por tanto, tenga cuidado y no se pierda la situación en la que, en una transacción que dura 3.5 segundos, se gastan 2.5 segundos en preparar y firmar la transacción, y 1.0 segundos en enviarla a la red y esperar una respuesta. Para evaluar los riesgos de este cuello de botella, es necesario recopilar métricas de las máquinas cliente, y no solo de los nodos de blockchain.

Enviar una transacción y monitorear su estado

El siguiente paso es enviar la transacción al nodo blockchain seleccionado y recibir el estado de aceptación en el grupo de transacciones. Esta etapa es similar a un acceso normal a una base de datos; el nodo debe registrar la transacción en el pool y comenzar a distribuir información sobre ella a través de la red p2p. El enfoque para evaluar el rendimiento aquí es similar a evaluar el rendimiento de los microservicios API web tradicionales, y las transacciones mismas en blockchains se pueden actualizar y cambiar activamente su estado. En general, la actualización de la información de las transacciones en algunas cadenas de bloques puede ocurrir varias veces, por ejemplo, cuando se cambia entre bifurcaciones de cadena o cuando los BP anuncian su intención de incluir una transacción en un bloque. Los límites en el tamaño de este grupo y la cantidad de transacciones en él pueden afectar el rendimiento de la cadena de bloques. Si el grupo de transacciones se llena hasta el tamaño máximo posible o no cabe en la RAM, el rendimiento de la red puede caer drásticamente. Las cadenas de bloques no tienen medios centralizados para protegerse contra una avalancha de mensajes basura, y si la cadena de bloques admite transacciones de gran volumen y tarifas bajas, esto puede causar que el grupo de transacciones se desborde, otro posible cuello de botella en el rendimiento.

En blockchains, el cliente envía una transacción a cualquier nodo de blockchain que desee, el cliente generalmente conoce el hash de la transacción antes de enviarla, por lo que todo lo que necesita hacer es lograr la conexión y, después de la transmisión, esperar a que cambie la blockchain. su estado, permitiendo su transacción. Tenga en cuenta que al medir "tps" puede obtener resultados completamente diferentes para diferentes métodos de conexión a un nodo de blockchain. Puede ser un RPC HTTP normal o un WebSocket que le permite implementar el patrón de "suscripción". En el segundo caso, el cliente recibirá una notificación antes y el nodo gastará menos recursos (principalmente memoria y tráfico) en respuestas sobre el estado de la transacción. Entonces, al medir los “tps” es necesario tener en cuenta la forma en que los clientes se conectan a los nodos. Por lo tanto, para evaluar los riesgos de este cuello de botella, la cadena de bloques de referencia debe poder emular clientes con solicitudes tanto WebSocket como HTTP RPC, en proporciones correspondientes a redes reales, así como cambiar la naturaleza de las transacciones y su tamaño.

Para evaluar los riesgos de este cuello de botella, también es necesario recopilar métricas de las máquinas cliente, y no solo de los nodos de blockchain.

Transmisión de transacciones y bloques vía red p2p

En blockchains, las redes peer-to-peer (p2p) se utilizan para transferir transacciones y bloques entre participantes. Las transacciones se propagan por toda la red, comenzando desde uno de los nodos, hasta llegar a los productores de bloques pares, quienes empaquetan las transacciones en bloques y, utilizando el mismo p2p, distribuyen 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í está un buen resumen de este protocolo, y aquí - un artículo con varias mediciones en la red BitTorrent, del cual se puede entender que este tipo de red es más compleja y menos predecible que una red rígidamente configurada de un servicio centralizado. También, aquí artículo sobre la medición de varias métricas interesantes para nodos Ethereum.

En resumen, cada par en dichas redes mantiene su propia lista dinámica de otros pares a los que solicita bloques de información que se abordan por contenido. Cuando un par recibe una solicitud, proporciona la información necesaria o pasa la solicitud al siguiente par pseudoaleatorio de la lista y, una vez recibida una respuesta, se la pasa al solicitante y la almacena en caché por un tiempo, dándole esto bloque de información antes la próxima vez. Por lo tanto, la información popular termina en una gran cantidad de cachés de una gran cantidad de pares y la información impopular es reemplazada gradualmente. Los pares mantienen registros de quién ha transferido cuánta información a quién, y la red intenta estimular a los distribuidores activos aumentando sus calificaciones y brindándoles un mayor nivel de servicio, desplazando automáticamente a los participantes inactivos de las listas de pares.

Por lo tanto, la transacción ahora debe distribuirse por toda la red para que los productores de bloques puedan verla e incluirla en el bloque. El nodo "distribuye" activamente una nueva transacción a todos y escucha la red, esperando un bloque en cuyo índice aparecerá la transacción requerida para notificar al cliente en espera. El tiempo que tarda la red en transferirse información entre sí sobre nuevas transacciones y bloques en redes p2p depende de una gran cantidad de factores: la cantidad de nodos honestos que trabajan cerca (desde el punto de vista de la red), la "cálida- up” de las 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 las métricas de rendimiento en dichas redes son un asunto complejo; es necesario evaluar simultáneamente el tiempo de procesamiento de solicitudes tanto en los clientes como en los pares (nodos blockchain). Los problemas en cualquiera de los mecanismos p2p, el desalojo y el almacenamiento en caché de datos incorrectos, la gestión ineficaz de las listas de pares activos y muchos otros factores pueden causar retrasos que afectan la eficiencia de toda la red en su conjunto, y este cuello de botella es el más difícil de analizar. , ensayo e interpretación de resultados.

Procesamiento blockchain y actualización de bases de datos estatales.

La parte más importante de blockchain es el algoritmo de consenso, su aplicación a nuevos bloques recibidos de la red y el procesamiento de transacciones con registro de los resultados en la base de datos estatal. Agregar un nuevo bloque a la cadena y luego seleccionar la cadena principal debería funcionar lo más rápido posible. Sin embargo, en la vida real, "debería" no significa "funciona" y uno puede, por ejemplo, imaginar una situación en la que dos largas cadenas en competencia cambian constantemente entre sí, cambiando los metadatos de miles de transacciones en el grupo en cada cambio. y haciendo retroceder constantemente la base de datos estatal. Esta etapa, en términos de definición del cuello de botella, es más sencilla que la capa de red p2p, porque La ejecución de transacciones y el algoritmo de consenso son estrictamente deterministas y es más fácil medir cualquier cosa aquí.
Lo principal es no confundir la degradación aleatoria en el rendimiento de esta etapa con problemas de red: los nodos son más lentos a la hora de entregar bloques e información sobre la cadena principal, y para un cliente externo esto puede parecer una red lenta, aunque el problema radica en un lugar completamente diferente.

Para optimizar el rendimiento en esta etapa, es útil recopilar y monitorear métricas de los propios nodos e incluir en ellas aquellas relacionadas con la actualización de la base de datos de estado: la cantidad de bloques procesados en el nodo, su tamaño, la cantidad de transacciones, la cantidad de cambios entre bifurcaciones de cadena, la cantidad de bloques no válidos, el tiempo de operación de la máquina virtual, el tiempo de confirmación de datos, etc. Esto evitará que los problemas de la red se confundan con errores en los algoritmos de procesamiento de la cadena.

Una máquina virtual que procesa transacciones puede ser una fuente útil de información que puede optimizar el funcionamiento de la cadena de bloques. La cantidad de asignaciones de memoria, la cantidad de instrucciones de lectura/escritura y otras métricas relacionadas con la eficiencia de la ejecución del código del contrato pueden proporcionar mucha información útil a los desarrolladores. Al mismo tiempo, los contratos inteligentes son programas, lo que 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 incierta, que, además, cambia mucho al pasar de una versión a otra. y al cambiar los códigos de contrato. Por lo tanto, también se necesitan métricas relacionadas con el procesamiento de transacciones para optimizar eficazmente el rendimiento de la cadena de bloques.

Recepción por parte del cliente de una notificación sobre la inclusión de una transacción en blockchain

Esta es la etapa final en la que el cliente blockchain recibe el servicio; en comparación con otras etapas, no hay grandes costos generales, pero aún así vale la pena considerar la posibilidad de que el cliente reciba una respuesta voluminosa del nodo (por ejemplo, un contrato inteligente). devolver una serie de datos). En cualquier caso, este punto es el más importante para quien hizo la pregunta “¿cuántos tps hay en tu blockchain?”, porque En este momento se registra la hora de recepción del servicio.

En este lugar siempre se envía el tiempo completo que el cliente tuvo que pasar esperando una respuesta de la blockchain, es este tiempo que el usuario esperará la confirmación en su aplicación, y es su optimización la que tarea principal de los desarrolladores.

Conclusión

Como resultado, podemos describir los tipos de operaciones realizadas en 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
aplicar cambios en la cadena de bloques a la base de datos estatal, actualizar datos sobre transacciones y bloques
solicitudes de solo lectura a la base de datos estatal, API del nodo blockchain, servicios de suscripción

En general, los requisitos técnicos para los nodos blockchain modernos son extremadamente serios: CPU rápidas para criptografía, una gran cantidad de RAM para almacenar y acceder rápidamente a la base de datos estatal, interacción de red utilizando una gran cantidad de conexiones abiertas simultáneamente y un gran almacenamiento. Requisitos tan altos y la abundancia de diferentes tipos de operaciones conducen inevitablemente al hecho de que los nodos pueden no tener suficientes recursos, y entonces cualquiera de las etapas discutidas anteriormente puede convertirse en otro cuello de botella para el rendimiento general de la red.

Al diseñar y evaluar el rendimiento de blockchains, deberás tener en cuenta todos estos puntos. Para hacer esto, necesita recopilar y analizar métricas simultáneamente de los clientes y los nodos de la red, buscar correlaciones entre ellos, estimar el tiempo que lleva brindar servicios a los clientes y tener en cuenta todos los recursos principales: CPU/memoria/red/almacenamiento. , comprender cómo se utilizan y cómo se influyen entre sí. Todo esto hace que comparar las velocidades de diferentes blockchains en forma de "cuántos TPS" sea una tarea extremadamente ingrata, ya que hay una gran cantidad de configuraciones y estados diferentes. En los grandes sistemas centralizados, grupos de cientos de servidores, estos problemas también son complejos y también requieren la recopilación de una gran cantidad de métricas diferentes, pero en blockchains, debido a las redes p2p, las máquinas virtuales que procesan contratos, las economías internas, la cantidad de grados La libertad es mucho mayor, lo que hace que la prueba, incluso en varios servidores, no sea indicativa y muestre sólo valores extremadamente aproximados que casi no tienen conexión con la realidad.

Por lo tanto, cuando desarrollamos en el núcleo de la cadena de bloques, para evaluar el rendimiento y responder a la pregunta "¿ha mejorado en comparación con la última vez?", utilizamos un software bastante complejo que organiza el lanzamiento de una cadena de bloques con docenas de nodos y automáticamente lanza un punto de referencia y recopila métricas. ; sin esta información es extremadamente difícil depurar protocolos que funcionan con múltiples participantes.

Entonces, cuando reciba la pregunta "¿cuántos TPS hay en su cadena de bloques?", ofrezca un poco de té a su interlocutor y pregúntele si está listo para mirar una docena de gráficos y también escuchar los tres recuadros de problemas de rendimiento de la cadena de bloques y sus sugerencias para resolviéndolos...

Fuente: habr.com

¿Cuántos TPS hay en tu blockchain?