Unha pregunta favorita sobre calquera sistema distribuído dunha persoa non técnica é "Cantos tps hai na túa cadea de bloques?" Non obstante, o número que se dá na resposta adoita ter pouco en común co que lle gustaría escoitar ao preguntador. De feito, quería preguntar "se a túa cadea de bloques se axustará aos meus requisitos comerciais" e estes requisitos non son un número, senón moitas condicións: aquí están a tolerancia a fallos da rede, os requisitos de finalidade, os tamaños, a natureza das transaccións e moitos outros parámetros. Polo tanto, é improbable que a resposta á pregunta "cantas tps" sexa sinxela e case nunca completa. Un sistema distribuído con decenas ou centos de nodos que realizan cálculos bastante complexos pode estar nun gran número de estados diferentes relacionados co estado da rede, os contidos da cadea de bloques, fallos técnicos, problemas económicos, ataques á rede e moitas outras razóns. . As etapas nas que son posibles problemas de rendemento difiren dos servizos tradicionais, e un servidor de rede blockchain é un servizo de rede que combina a funcionalidade dunha base de datos, servidor web e cliente torrent, o que o fai extremadamente complexo en canto ao perfil de carga en todos os subsistemas. : procesador, memoria, rede, almacenamento

Acontece que as redes descentralizadas e as cadeas de bloques son un software bastante específico e pouco común para os desenvolvedores de software centralizado. Por iso, gustaríame destacar aspectos importantes do rendemento e a sustentabilidade das redes descentralizadas, os enfoques para medilos e atopar colos de botella. Analizaremos varios problemas de rendemento que limitan a velocidade de prestación de servizos aos usuarios de blockchain e observaremos as características características deste tipo de software.

Etapas dunha solicitude de servizo por parte dun cliente blockchain

Para falar honestamente da calidade de calquera servizo máis ou menos complexo, cómpre ter en conta non só os valores medios, senón tamén os máximos/mínimos, as medianas, os percentiles. Teoricamente, podemos falar de 1000 tps nalgunha cadea de bloques, pero se 900 transaccións se completaron cunha velocidade enorme e 100 se "atascaron" durante uns segundos, entón o tempo medio recollido en todas as transaccións non é unha métrica completamente xusta para un cliente. quen non puiden completar a transacción nuns segundos. Os "buratos" temporais causados por roldas de consenso perdidas ou divisións de rede poden arruinar en gran medida un servizo que mostrou un excelente rendemento nos bancos de probas.

Para identificar estes pescozos de botella, é necesario ter unha boa comprensión das etapas nas que unha cadea de bloques real pode ter dificultades para servir aos usuarios. Imos describir o ciclo de entrega e procesamento dunha transacción, así como a obtención dun novo estado da cadea de bloques desde o que o cliente pode verificar que a súa transacción foi procesada e contabilizada.

a transacción fórmase no cliente
a transacción está asinada no cliente
o cliente selecciona un dos nodos e envíalle a súa transacción
o cliente subscríbese ás actualizacións da base de datos de estado do nodo, á espera de que aparezan os resultados da súa transacción
o nodo distribúe a transacción pola rede p2p
varios ou un BP (produtor de bloques) procesa transaccións acumuladas, actualizando a base de datos estatal
BP forma un novo bloque despois de procesar o número necesario de transaccións
BP distribúe un novo bloque pola rede p2p
o novo bloque entrégase ao nodo ao que accede o cliente
base de datos de estado de actualizacións de nodos
o nodo ve a actualización relativa ao cliente e envíalle unha notificación de transacción

Agora vexamos estas etapas e describamos os posibles problemas de rendemento en cada etapa. A diferenza dos sistemas centralizados, tamén teremos en conta a execución de código en clientes de rede. Moitas veces, ao medir TPS, o tempo de procesamento da transacción recóllese dos nodos e non do cliente, isto non é totalmente xusto. Ao cliente non lle importa a rapidez con que o nodo procesou a súa transacción; o máis importante para el é o momento no que a información fiable sobre esta transacción incluída na cadea de bloques está dispoñible para el. É esta métrica a que é esencialmente o tempo de execución da transacción. Isto significa que distintos clientes, incluso enviando a mesma transacción, poden recibir tempos completamente diferentes, que dependen da canle, carga e proximidade do nodo, etc. Polo que é absolutamente necesario medir este tempo nos clientes, xa que este é o parámetro que hai que optimizar.

Preparación dunha transacción no lado do cliente

Comecemos polos dous primeiros puntos: a transacción está formada e asinada polo cliente. Curiosamente, isto tamén pode ser un pescozo de botella no rendemento da cadea de bloques desde o punto de vista do cliente. Isto é inusual para os servizos centralizados, que se encargan de todos os cálculos e operacións con datos, e o cliente simplemente prepara unha pequena solicitude que pode solicitar unha gran cantidade de datos ou cálculos, obtendo un resultado listo. Nas cadeas de bloques, o código do cliente faise cada vez máis poderoso e o núcleo da cadea de bloques faise cada vez máis lixeiro e as tarefas informáticas masivas adoitan transferirse ao software do cliente. Nas cadeas de bloques, hai clientes que poden preparar unha transacción durante bastante tempo (estou a falar de varias probas de merkle, probas sucintas, sinaturas de limiar e outras operacións complexas no lado do cliente). Un bo exemplo de verificación en cadea sinxela e preparación pesada dunha transacción no cliente é a proba de pertenza a unha lista baseada na árbore Merkle, aquí artigo.

Ademais, non esquezas que o código do cliente non simplemente envía transaccións á cadea de bloques, senón que primeiro consulta o estado da cadea de bloques, e esta actividade pode afectar a conxestión da rede e dos nós da cadea de bloques. Polo tanto, ao tomar medidas, sería razoable emular o comportamento do código do cliente o máis completamente posible. Aínda que na túa cadea de bloques hai clientes lixeiros comúns que poñen unha sinatura dixital regular na transacción máis sinxela para transferir algún activo, cada ano hai aínda máis cálculos masivos sobre o cliente, os algoritmos criptográficos son cada vez máis fortes e esta parte do procesamento pode converterse nun pescozo de botella importante no futuro. Polo tanto, teña coidado e non perda a situación na que, nunha transacción que dura 3.5 segundos, se gastan 2.5 segundos en preparar e asinar a transacción e 1.0 segundos en enviala á rede e esperar unha resposta. Para avaliar os riscos deste pescozo de botella, cómpre recoller métricas das máquinas clientes, e non só dos nodos blockchain.

Envío dunha transacción e seguimento do seu estado

O seguinte paso é enviar a transacción ao nodo de cadea de bloques seleccionado e recibir o estado de aceptala no grupo de transaccións. Esta etapa é semellante a un acceso normal a unha base de datos; o nodo debe rexistrar a transacción no grupo e comezar a distribuír información sobre ela a través da rede p2p. O enfoque para avaliar o rendemento aquí é semellante ao de avaliar o rendemento dos microservizos tradicionais da API web, e as propias transaccións en cadeas de bloques pódense actualizar e cambiar activamente o seu estado. En xeral, a actualización da información de transaccións nalgunhas cadeas de bloques pode ocorrer varias veces, por exemplo cando se cambia entre os garfos de cadea ou cando os BP anuncian a súa intención de incluír unha transacción nun bloque. Os límites sobre o tamaño deste grupo e o número de transaccións nel pode afectar o rendemento da cadea de bloques. Se o conxunto de transaccións se enche ata o máximo tamaño posible ou non cabe na memoria RAM, o rendemento da rede pode caer drasticamente. As cadeas de bloques non teñen medios centralizados para protexerse contra unha avalancha de mensaxes lixo, e se a cadea de bloques admite transaccións de gran volume e taxas baixas, isto pode provocar que o grupo de transaccións se desborde, outro posible pescozo de botella de rendemento.

Nas cadeas de bloques, o cliente envía unha transacción a calquera nodo de cadea de bloques que lle guste, o hash da transacción adoita ser coñecido polo cliente antes de enviar, polo que só ten que conseguir a conexión e, despois da transmisión, esperar a que cambie a cadea de bloques. o seu estado, permitindo a súa transacción. Teña en conta que ao medir "tps" pode obter resultados completamente diferentes para diferentes métodos de conexión a un nodo de cadea de bloques. Este pode ser un RPC HTTP normal ou un WebSocket que che permita implementar o patrón de "subscrición". No segundo caso, o cliente recibirá unha notificación antes e o nodo gastará menos recursos (principalmente memoria e tráfico) en respostas sobre o estado da transacción. Polo tanto, ao medir "tps" é necesario ter en conta a forma en que os clientes se conectan aos nodos. Polo tanto, para avaliar os riscos deste pescozo de botella, a cadea de bloques de referencia debe ser capaz de emular clientes tanto con solicitudes WebSocket como HTTP RPC, en proporcións correspondentes ás redes reais, así como modificar a natureza das transaccións e o seu tamaño.

Para avaliar os riscos deste pescozo de botella, tamén cómpre recoller métricas das máquinas clientes, e non só dos nodos blockchain.

Transmisión de transaccións e bloques a través da rede p2p

Nas cadeas de bloques, a rede peer-to-peer (p2p) úsase para transferir transaccións e bloques entre participantes. As transaccións esténdense por toda a rede, comezando desde un dos nodos, ata chegar aos produtores de bloques pares, que empaquetan as transaccións en bloques e, utilizando o mesmo p2p, distribúen novos bloques a todos os nodos da rede. A base da maioría das redes p2p modernas son varias modificacións do protocolo Kademlia. Aquí un bo resumo deste protocolo, e velaquí - un artigo con varias medidas na rede BitTorrent, do que se pode entender que este tipo de rede é máis complexa e menos previsible que unha rede configurada de forma ríxida dun servizo centralizado. Ademais, velaquí artigo sobre a medición de varias métricas interesantes para os nodos de Ethereum.

En resumo, cada peer de tales redes mantén a súa propia lista dinámica doutros pares aos que solicita bloques de información aos que se aborda o contido. Cando un peer recibe unha solicitude, dá a información necesaria ou pasa a solicitude ao seguinte peer pseudoaleatorio da lista e, unha vez recibida unha resposta, pásaa ao solicitante e almacena en caché durante un tempo, dándolle isto. bloque de información antes a próxima vez. Así, a información popular acaba nun gran número de cachés dun gran número de pares e a información impopular vaise substituíndo gradualmente. Os compañeiros gardan rexistros de quen transferiu canta información a quen, e a rede trata de estimular aos distribuidores activos aumentando as súas valoracións e proporcionándolles un nivel de servizo superior, desprazando automaticamente aos participantes inactivos das listas de pares.

Entón, a transacción agora debe ser distribuída por toda a rede para que os produtores de bloques poidan vela e incluíla no bloque. O nodo "distribúe" activamente unha nova transacción a todos e escoita a rede, á espera dun bloque no índice do cal aparecerá a transacción necesaria para notificar ao cliente en espera. O tempo que tarda a rede en transferirse información entre si sobre novas transaccións e bloqueos en redes p2p depende dun gran número de factores: o número de nodos honestos que traballan nas proximidades (desde o punto de vista da rede), o up” dos cachés destes nodos, o tamaño dos bloques, as transaccións, a natureza dos cambios, a xeografía da rede, o número de nodos e moitos outros factores. As medicións complexas de métricas de rendemento en tales redes son unha cuestión complexa; é necesario avaliar simultaneamente o tempo de procesamento de solicitudes tanto en clientes como en pares (nodos de cadea de bloques). Os problemas nalgún dos mecanismos p2p, o desaloxo e almacenamento en caché de datos incorrectos, a xestión ineficaz das listas de pares activos e moitos outros factores poden provocar atrasos que afectan á eficiencia de toda a rede no seu conxunto, e este pescozo de botella é o máis difícil de analizar. , proba e interpretación de resultados.

Procesamento de blockchain e actualización de bases de datos de estado

A parte máis importante da cadea de bloques é o algoritmo de consenso, a súa aplicación a novos bloques recibidos da rede e o procesamento de transaccións con rexistro dos resultados na base de datos estatal. Engadir un novo bloque á cadea e seleccionar a cadea principal debería funcionar o máis rápido posible. Non obstante, na vida real, "debería" non significa "funciona", e pódese, por exemplo, imaxinar unha situación na que dúas longas cadeas competidoras están cambiando constantemente entre si, cambiando os metadatos de miles de transaccións no grupo en cada cambio. , e revertir constantemente a base de datos do estado. Esta etapa, en canto á definición do pescozo de botella, é máis sinxela que a capa de rede p2p, porque A execución de transaccións e o algoritmo de consenso son estritamente deterministas, e aquí é máis fácil medir calquera cousa.
O principal é non confundir a degradación aleatoria no desempeño desta etapa con problemas de rede: os nós son máis lentos na entrega de bloques e información sobre a cadea principal, e para un cliente externo isto pode parecer unha rede lenta, aínda que o problema reside en un lugar completamente diferente.

Para optimizar o rendemento nesta fase, é útil recoller e supervisar as métricas dos propios nodos, e incluír neles as relacionadas coa actualización da base de datos de estado: o número de bloques procesados no nodo, o seu tamaño, o número de transaccións, o número de cambios entre as bifurcacións de cadea, o número de bloques non válidos, o tempo de funcionamento da máquina virtual, o tempo de entrega de datos, etc. Isto evitará que os problemas de rede se confundan con erros nos algoritmos de procesamento en cadea.

Unha máquina virtual que procesa transaccións pode ser unha fonte útil de información que pode optimizar o funcionamento da cadea de bloques. O número de asignacións de memoria, o número de instrucións de lectura/escritura e outras métricas relacionadas coa eficiencia da execución do código do contrato poden proporcionar moita información útil aos desenvolvedores. Ao mesmo tempo, os contratos intelixentes son programas, o que significa que en teoría poden consumir calquera dos recursos: cpu/memoria/rede/almacenamento, polo que o procesamento das transaccións é unha etapa bastante incerta, que, ademais, cambia moito ao moverse entre versións. e ao cambiar os códigos de contrato. Polo tanto, tamén se necesitan métricas relacionadas co procesamento de transaccións para optimizar eficazmente o rendemento da cadea de bloques.

Recepción por parte do cliente dunha notificación sobre a inclusión dunha transacción na cadea de bloques

Esta é a fase final do cliente blockchain que recibe o servizo; en comparación con outras etapas, non hai grandes custos xerais, pero aínda paga a pena considerar a posibilidade de que o cliente reciba unha resposta voluminosa do nodo (por exemplo, un contrato intelixente). devolver unha matriz de datos). En calquera caso, este punto é o máis importante para quen fixo a pregunta "cantas tps hai na túa cadea de bloques?", porque Neste momento, rexístrase o momento de recepción do servizo.

Neste lugar, sempre hai un envío do tempo completo que o cliente tivo que pasar á espera dunha resposta da cadea de bloques; é nesta ocasión na que o usuario agardará a confirmación na súa aplicación, e é a súa optimización a que se refire. tarefa principal dos desenvolvedores.

Conclusión

Como resultado, podemos describir os tipos de operacións realizadas nas cadeas de bloques e dividilas en varias categorías:

transformacións criptográficas, construción de probas
redes peer-to-peer, transaccións e replicación de bloques
procesamento de transaccións, execución de contratos intelixentes
aplicando cambios na cadea de bloques á base de datos estatal, actualizando datos sobre transaccións e bloques
solicitudes de só lectura á base de datos estatal, API do nodo de cadea de bloques, servizos de subscrición

En xeral, os requisitos técnicos dos nodos de cadea de bloques modernos son extremadamente serios: CPUs rápidas para a criptografía, unha gran cantidade de RAM para almacenar e acceder rapidamente á base de datos do estado, interacción de rede usando un gran número de conexións abertas simultáneamente e gran almacenamento. Eses requisitos tan altos e a abundancia de diferentes tipos de operacións levan inevitablemente ao feito de que os nós poden non ter recursos suficientes e, a continuación, calquera das etapas comentadas anteriormente pode converterse nun pescozo de botella para o rendemento global da rede.

Ao deseñar e avaliar o rendemento das cadeas de bloques, terás que ter en conta todos estes puntos. Para iso, cómpre recoller e analizar simultaneamente as métricas dos clientes e dos nodos da rede, buscar correlacións entre eles, estimar o tempo que se tarda en prestar servizos aos clientes, ter en conta todos os recursos principais: cpu/memoria/rede/almacenamento. , comprender como se usan e inflúen mutuamente. Todo isto fai que comparar as velocidades de diferentes cadeas de bloques en forma de "cantos TPS" sexa unha tarefa extremadamente ingrata, xa que hai un gran número de configuracións e estados diferentes. En grandes sistemas centralizados, clusters de centos de servidores, estes problemas tamén son complexos e tamén requiren a recollida dunha gran cantidade de métricas diferentes, pero nas cadeas de bloques, debido ás redes p2p, as máquinas virtuais que procesan contratos, as economías internas, o número de graos. de liberdade é moito maior, o que fai que a proba mesmo en varios servidores non sexa indicativa e só mostra valores extremadamente aproximados que case non teñen conexión coa realidade.

Polo tanto, ao desenvolver no núcleo de blockchain, para avaliar o rendemento e responder á pregunta "mellorou en comparación coa última vez?", utilizamos un software bastante complexo que orquestra o lanzamento dunha cadea de bloques con decenas de nodos e lanza automaticamente un punto de referencia e recolle métricas. ; sen esta información é extremadamente difícil depurar protocolos que funcionen con varios participantes.

Entón, cando recibas a pregunta "cantas TPS hai na túa cadea de bloques?", ofrécelle ao teu interlocutor un pouco de té e pregúntalle se está preparado para mirar unha ducia de gráficos e tamén escoita as tres caixas de problemas de rendemento da cadea de bloques e as túas suxestións para resolvéndoos...

Fonte: www.habr.com

Cantos TPS hai na túa cadea de bloques?