{"id":36157,"date":"2019-10-31T22:09:55","date_gmt":"2019-10-31T19:09:55","guid":{"rendered":"https:\/\/prohoster.info\/blog\/skolko-tps-v-vashem-blokchejne\/"},"modified":"2019-10-31T22:09:55","modified_gmt":"2019-10-31T19:09:55","slug":"skolko-tps-v-vashem-blokchejne","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/skolko-tps-v-vashem-blokchejne","title":{"rendered":"Quantos TPS h\u00e1 no seu blockchain?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

A pergunta favorita de qualquer n\u00e3o t\u00e9cnico sobre um sistema distribu\u00eddo \u00e9 \"Quantos tps h\u00e1 na sua blockchain?\" No entanto, o n\u00famero mencionado em resposta geralmente tem pouco a ver com o que o questionador gostaria de saber. Na verdade, ele queria perguntar \"sua blockchain atende \u00e0s minhas necessidades empresariais?\", e essas necessidades n\u00e3o s\u00e3o um \u00fanico n\u00famero, mas sim uma s\u00e9rie de condi\u00e7\u00f5es \u2014 incluindo a resili\u00eancia da rede, requisitos de finaliza\u00e7\u00e3o, tamanhos, natureza das transa\u00e7\u00f5es e muitos outros par\u00e2metros. Portanto, a resposta \u00e0 pergunta \"quantos tps\" \u00e9 improv\u00e1vel que seja simples e quase nunca completa. Um sistema distribu\u00eddo com dezenas e centenas de n\u00f3s realizando c\u00e1lculos bastante complexos pode existir em uma enorme variedade de estados, relacionados ao estado da rede, ao conte\u00fado da blockchain, a falhas t\u00e9cnicas, problemas econ\u00f4micos, ataques \u00e0 rede e v\u00e1rias outras raz\u00f5es. As etapas nas quais problemas de desempenho podem ocorrer diferem dos servi\u00e7os tradicionais, e o servidor da rede blockchain \u00e9 um servi\u00e7o de rede que combina a funcionalidade de banco de dados, servidor web e cliente torrent, tornando-o extremamente complexo em termos de carga em todos os subsistemas: processador, mem\u00f3ria, rede, armazenamento.<\/p>\n

<\/p>\n

Acontece que redes descentralizadas e blockchains s\u00e3o softwares bastante espec\u00edficos e incomuns para desenvolvedores de software centralizado. Por isso, gostaria de destacar aspectos importantes de desempenho e resili\u00eancia das redes descentralizadas, abordagens para medi-los e identificar gargalos. Vamos examinar diversos problemas de desempenho que limitam a velocidade de servi\u00e7o para os usu\u00e1rios de blockchains e notar as caracter\u00edsticas que s\u00e3o peculiares a esse tipo de software.<\/p>\n

<\/a><\/noindex><\/p>\n

Etapas de solicita\u00e7\u00e3o de servi\u00e7o pelo cliente da blockchain<\/h2>\n

<\/p>\n

Para falar honestamente sobre a qualidade de qualquer servi\u00e7o mais ou menos complexo, \u00e9 preciso considerar n\u00e3o apenas os valores m\u00e9dios, mas tamb\u00e9m os m\u00e1ximos\/m\u00ednimos, medianas e percentis. Teoricamente, pode-se falar em 1000 tps em algum blockchain, mas se 900 transa\u00e7\u00f5es foram realizadas a uma velocidade incr\u00edvel, enquanto 100 'congelaram' por alguns segundos, a m\u00e9dia coletada de todas as transa\u00e7\u00f5es n\u00e3o \u00e9 uma m\u00e9trica totalmente justa para o cliente que n\u00e3o conseguiu concluir a transa\u00e7\u00e3o em alguns segundos. Fendas temporais, causadas por rodadas de consenso perdidas ou divis\u00e3o da rede, podem prejudicar consideravelmente um servi\u00e7o que mostrou um desempenho excelente em bancos de testes.<\/p>\n

<\/p>\n

Para identificar esses bottlenecks, \u00e9 necess\u00e1rio ter uma boa compreens\u00e3o das etapas em que um blockchain real pode enfrentar dificuldades ao atender os usu\u00e1rios. Vamos descrever o ciclo de entrega e o processamento de transa\u00e7\u00f5es, bem como a obten\u00e7\u00e3o de um novo estado do blockchain, do qual o cliente pode se certificar de que sua transa\u00e7\u00e3o foi processada e contabilizada.<\/p>\n

<\/p>\n

    \n
  1. a transa\u00e7\u00e3o \u00e9 formada no cliente<\/li>\n
  2. a transa\u00e7\u00e3o \u00e9 assinada no cliente<\/li>\n
  3. o cliente escolhe um dos n\u00f3s e envia sua transa\u00e7\u00e3o para ele<\/li>\n
  4. o cliente se inscreve para atualiza\u00e7\u00f5es da base de dados de estado do n\u00f3, esperando por resultados da execu\u00e7\u00e3o da sua transa\u00e7\u00e3o<\/li>\n
  5. o n\u00f3 espalha a transa\u00e7\u00e3o pela rede p2p<\/li>\n
  6. v\u00e1rios ou um BP (produtor de bloco) processam as transa\u00e7\u00f5es acumuladas, atualizando a base de dados de estado<\/li>\n
  7. o BP forma um novo bloco, processando o n\u00famero necess\u00e1rio de transa\u00e7\u00f5es<\/li>\n
  8. o BP espalha o novo bloco pela rede p2p<\/li>\n
  9. o novo bloco \u00e9 entregue ao n\u00f3 que o cliente est\u00e1 acessando<\/li>\n
  10. o n\u00f3 atualiza a base de dados de estado<\/li>\n
  11. o n\u00f3 v\u00ea a atualiza\u00e7\u00e3o relacionada ao cliente e envia uma notifica\u00e7\u00e3o sobre a transa\u00e7\u00e3o para ele<\/li>\n<\/ol>\n

    <\/p>\n

    Agora, vamos analisar esses est\u00e1gios em mais detalhes e descrever os potenciais problemas de desempenho em cada um deles. Ao contr\u00e1rio dos sistemas centralizados, tamb\u00e9m vamos considerar a execu\u00e7\u00e3o do c\u00f3digo nos clientes da rede. Com frequ\u00eancia, ao medir tps, o tempo de processamento das transa\u00e7\u00f5es \u00e9 coletado a partir dos n\u00f3s, e n\u00e3o dos clientes \u2014 o que n\u00e3o \u00e9 totalmente justo. Para o cliente, o qu\u00e3o r\u00e1pido o n\u00f3 processou sua transa\u00e7\u00e3o n\u00e3o \u00e9 relevante; o que realmente importa para ele \u00e9 o momento em que a informa\u00e7\u00e3o confi\u00e1vel sobre essa transa\u00e7\u00e3o, inclu\u00edda na blockchain, se torna dispon\u00edvel. Essa m\u00e9trica \u00e9, na ess\u00eancia, o tempo de execu\u00e7\u00e3o da transa\u00e7\u00e3o. Isso significa que diferentes clientes, mesmo enviando a mesma transa\u00e7\u00e3o, podem obter tempos completamente diferentes, dependendo do canal, da carga e da proximidade do n\u00f3, entre outros fatores. Portanto, \u00e9 absolutamente necess\u00e1rio medir esse tempo nos clientes, uma vez que esse \u00e9 o par\u00e2metro que precisa ser otimizado.<\/p>\n

    <\/p>\n

    Prepara\u00e7\u00e3o da transa\u00e7\u00e3o no lado do cliente<\/h2>\n

    <\/p>\n

    Come\u00e7aremos com os primeiros dois pontos: a transa\u00e7\u00e3o \u00e9 formada e assinada pelo cliente. Surpreendentemente, isso pode ser tamb\u00e9m um gargalo de desempenho da blockchain do ponto de vista do cliente. Isso \u00e9 incomum para servi\u00e7os centralizados, que realizam todos os c\u00e1lculos e opera\u00e7\u00f5es com dados por conta pr\u00f3pria, enquanto o cliente apenas prepara uma solicita\u00e7\u00e3o curta, capaz de requisitar um grande volume de dados ou c\u00e1lculos, recebendo o resultado pronto. Nas blockchains, o c\u00f3digo do cliente se torna cada vez mais potente, e o n\u00facleo da blockchain se torna cada vez mais leve, enquanto tarefas computacionais massivas tendem a ser entregues ao software do cliente. Existem clientes nas blockchains que podem levar um bom tempo para preparar uma \u00fanica transa\u00e7\u00e3o (estou falando sobre v\u00e1rias provas Merkle, provas sucintas, assinaturas threshold e outras opera\u00e7\u00f5es complexas do lado do cliente). Um bom exemplo de verifica\u00e7\u00e3o leve on-chain e prepara\u00e7\u00e3o pesada da transa\u00e7\u00e3o no cliente \u00e9 a prova de pertencimento a uma lista baseada em Merkle-tree, aqui est\u00e1. artigo<\/a><\/noindex>.<\/p>\n

    <\/p>\n

    Tamb\u00e9m n\u00e3o devemos esquecer que o c\u00f3digo do cliente n\u00e3o apenas envia transa\u00e7\u00f5es para a blockchain, mas primeiro solicita o estado da blockchain \u2014 e essa atividade pode impactar a carga da rede e dos nodos da blockchain. Portanto, ao realizar medi\u00e7\u00f5es, \u00e9 sensato emular o comportamento do c\u00f3digo do cliente da forma mais completa poss\u00edvel. Mesmo que em sua blockchain existam apenas clientes leves que assinam digitalmente uma transa\u00e7\u00e3o simples de transfer\u00eancia de algum ativo, a cada ano a quantidade de c\u00e1lculos massivos no cliente ainda aumenta, os algoritmos criptogr\u00e1ficos se fortalecem e essa parte do processamento pode se tornar um gargalo significativo no futuro. Por isso, tenha cuidado e n\u00e3o deixe passar a situa\u00e7\u00e3o em que, em uma transa\u00e7\u00e3o que leva 3,5s, 2,5s s\u00e3o gastos na prepara\u00e7\u00e3o e assinatura da transa\u00e7\u00e3o, e 1,0s no envio para a rede e aguardando uma resposta. Para avaliar os riscos de surgimento desse gargalo, \u00e9 necess\u00e1rio coletar m\u00e9tricas das m\u00e1quinas dos clientes, e n\u00e3o apenas dos nodos da blockchain.<\/p>\n

    <\/p>\n

    Envio de transa\u00e7\u00e3o e monitoramento do seu status<\/h2>\n

    <\/p>\n

    A pr\u00f3xima etapa \u00e9 enviar a transa\u00e7\u00e3o para o nodo da blockchain escolhido e obter o status de sua aceita\u00e7\u00e3o no pool de transa\u00e7\u00f5es. Esta etapa \u00e9 semelhante a uma solicita\u00e7\u00e3o comum a um banco de dados, o nodo deve registrar a transa\u00e7\u00e3o no pool e come\u00e7ar a disseminar informa\u00e7\u00f5es sobre ela atrav\u00e9s da rede P2P. A abordagem para avaliar o desempenho aqui \u00e9 semelhante \u00e0 avalia\u00e7\u00e3o do funcionamento de microservi\u00e7os tradicionais de Web API, sendo que as pr\u00f3prias transa\u00e7\u00f5es nas blockchains podem ser atualizadas, mudando ativamente de status. Na verdade, a atualiza\u00e7\u00e3o das informa\u00e7\u00f5es sobre uma transa\u00e7\u00e3o pode ocorrer v\u00e1rias vezes em algumas blockchains, por exemplo, ao alternar entre forks da cadeia ou quando os BP informam sobre a inten\u00e7\u00e3o de incluir a transa\u00e7\u00e3o em um bloco. Restri\u00e7\u00f5es sobre o tamanho desse pool e o n\u00famero de transa\u00e7\u00f5es nele podem influenciar o desempenho da blockchain. Se o pool de transa\u00e7\u00f5es estiver cheio at\u00e9 o tamanho m\u00e1ximo poss\u00edvel, ou n\u00e3o couber na mem\u00f3ria RAM, o desempenho da rede pode cair drasticamente. As blockchains n\u00e3o t\u00eam meios centralizados de prote\u00e7\u00e3o contra o fluxo de mensagens de lixo e, se a blockchain suporta transa\u00e7\u00f5es de grande volume e baixas taxas, isso pode levar ao transbordo do pool de transa\u00e7\u00f5es \u2014 este \u00e9 mais um potencial gargalo de desempenho.<\/p>\n

    <\/p>\n

    Nos blockchains, o cliente envia uma transa\u00e7\u00e3o para qualquer n\u00f3 do blockchain que lhe agrade, o hash da transa\u00e7\u00e3o geralmente \u00e9 conhecido pelo cliente antes do envio, portanto, tudo o que ele precisa fazer \u00e9 conseguir a conex\u00e3o e, ap\u00f3s a transmiss\u00e3o, aguardar at\u00e9 que o blockchain altere seu estado, incluindo sua transa\u00e7\u00e3o. Vale observar que, ao medir 'tps', \u00e9 poss\u00edvel obter resultados completamente diferentes para diferentes formas de conex\u00e3o com o n\u00f3 do blockchain. Isso pode ser uma chamada RPC HTTP comum ou WebSocket, permitindo implementar o padr\u00e3o 'subscribe'. No segundo caso, o cliente receber\u00e1 a notifica\u00e7\u00e3o mais cedo e o n\u00f3 consumir\u00e1 menos recursos (principalmente mem\u00f3ria e tr\u00e1fego) para responder sobre o estado da transa\u00e7\u00e3o. Portanto, ao medir 'tps', \u00e9 necess\u00e1rio considerar a forma como os clientes se conectam aos n\u00f3s. Assim, para avaliar os riscos de surgimento deste gargalo, o benchmark do blockchain deve ser capaz de emular clientes tanto com WebSocket quanto com solicita\u00e7\u00f5es RPC HTTP, em propor\u00e7\u00f5es correspondentes \u00e0s redes reais, al\u00e9m de alterar a natureza das transa\u00e7\u00f5es e seu tamanho.<\/p>\n

    <\/p>\n

    Para avaliar os riscos de surgimento desse bottleneck, tamb\u00e9m \u00e9 necess\u00e1rio coletar m\u00e9tricas das m\u00e1quinas dos clientes, e n\u00e3o apenas dos n\u00f3s do blockchain.<\/p>\n

    <\/p>\n

    Transfer\u00eancia de transa\u00e7\u00f5es e blocos pela rede p2p<\/h2>\n

    <\/p>\n

    Nos blockchains, para a transfer\u00eancia entre os participantes de transa\u00e7\u00f5es e blocos, utiliza-se uma rede peer-to-peer (p2p). As transa\u00e7\u00f5es se espalham pela rede, come\u00e7ando a partir de um dos n\u00f3s, at\u00e9 alcan\u00e7arem os peers-produtores de blocos, que empacotam as transa\u00e7\u00f5es em blocos e, atrav\u00e9s do mesmo p2p, distribuem novos blocos para todos os n\u00f3s da rede. A base da maioria das redes p2p modernas s\u00e3o diferentes modifica\u00e7\u00f5es do protocolo Kademlia. Aqui<\/a><\/noindex> uma boa vis\u00e3o geral deste protocolo, e aqui<\/a><\/noindex> \u2014 um artigo com v\u00e1rias medi\u00e7\u00f5es na rede BitTorrent, que pode ser entendido \u2014 que este tipo de rede \u00e9 mais complexo e menos previs\u00edvel do que uma rede de servi\u00e7o centralizado rigidamente configurada. Al\u00e9m disso, aqui<\/a><\/noindex> um artigo sobre a medi\u00e7\u00e3o de v\u00e1rias m\u00e9tricas interessantes para n\u00f3s Ethereum.<\/p>\n

    <\/p>\n

    Em resumo, cada peer nessas redes mant\u00e9m sua pr\u00f3pria lista din\u00e2mica de outros peers, de quem solicita blocos de informa\u00e7\u00f5es endere\u00e7ados por seu conte\u00fado. Ao receber uma solicita\u00e7\u00e3o, o peer pode devolver a informa\u00e7\u00e3o necess\u00e1ria ou passar o pedido para o pr\u00f3ximo peer pseudo-aleat\u00f3rio da lista, e ao receber uma resposta, a envia de volta ao solicitante e a cacheia por um tempo, oferecendo esse bloco de informa\u00e7\u00e3o mais rapidamente na pr\u00f3xima vez. Assim, informa\u00e7\u00f5es populares ficam armazenadas em muitos caches de diversos peers, enquanto as n\u00e3o populares s\u00e3o gradualmente eliminadas. Os peers controlam quem transferiu quantas informa\u00e7\u00f5es e a rede tenta estimular os compartilhadores ativos, elevando suas classifica\u00e7\u00f5es e garantindo-lhes um n\u00edvel de servi\u00e7o mais alto, automaticamente eliminando participantes inativos das listas de peers.<\/p>\n

    <\/p>\n

    Agora, a transa\u00e7\u00e3o precisa ser disseminada pela rede para que os block producers a vejam e a incluam em um bloco. O n\u00f3 ativamente \"distribui\" a nova transa\u00e7\u00e3o a todos os interessados e escuta a rede, aguardando um bloco no qual a transa\u00e7\u00e3o desejada aparecer\u00e1, para notificar o cliente que est\u00e1 esperando. O tempo em que a rede troca informa\u00e7\u00f5es sobre novas transa\u00e7\u00f5es e blocos em redes P2P depende de uma s\u00e9rie de fatores: o n\u00famero de n\u00f3s honestos e funcionando pr\u00f3ximos (do ponto de vista da rede), a \"aquecimento\" dos caches desses n\u00f3s, o tamanho dos blocos e das transa\u00e7\u00f5es, a natureza das mudan\u00e7as, a geografia da rede, o n\u00famero de n\u00f3s e muitos outros fatores. Medir complexamente as m\u00e9tricas de desempenho em tais redes \u00e9 uma tarefa dif\u00edcil, pois \u00e9 necess\u00e1rio avaliar simultaneamente o tempo de processamento de solicita\u00e7\u00f5es tanto nos clientes quanto nos peers (n\u00f3s da blockchain). Problemas em qualquer um dos mecanismos P2P, a expuls\u00e3o e o cache de dados incorretos, a gest\u00e3o ineficaz das listas de peers ativos e muitos outros fatores podem causar atrasos que impactam a efici\u00eancia de toda a rede como um todo, e esse gargalo \u00e9 o mais complicado de analisar, testar e interpretar os resultados.<\/p>\n

    <\/p>\n

    Processamento da cadeia de blocos e atualiza\u00e7\u00e3o do banco de dados de estados<\/h2>\n

    <\/p>\n

    A parte mais importante do funcionamento da blockchain \u00e9 o algoritmo de consenso, sua aplica\u00e7\u00e3o aos novos blocos recebidos da rede e o processamento de transa\u00e7\u00f5es com a grava\u00e7\u00e3o de resultados no banco de dados de estado. A adi\u00e7\u00e3o de um novo bloco \u00e0 cadeia e a escolha da cadeia principal subsequente deve ocorrer o mais r\u00e1pido poss\u00edvel. No entanto, na vida real, \"deve\" n\u00e3o significa \"funciona\", e podemos, por exemplo, imaginar uma situa\u00e7\u00e3o em que duas longas cadeias concorrentes alternam constantemente entre si, alterando os metadados de milhares de transa\u00e7\u00f5es no pool a cada troca e realizando constantes revertera\u00e7\u00f5es do estado do banco de dados. Esta etapa, em termos de defini\u00e7\u00e3o de gargalos, \u00e9 mais simples do que a camada de rede P2P, uma vez que a execu\u00e7\u00e3o de transa\u00e7\u00f5es e o algoritmo de consenso s\u00e3o estritamente determin\u00edsticos, e medir qualquer coisa aqui \u00e9 mais f\u00e1cil.
    \nO principal \u00e9 n\u00e3o confundir a degrada\u00e7\u00e3o aleat\u00f3ria do desempenho desta etapa com problemas de rede \u2014 os n\u00f3s entregam blocos e informa\u00e7\u00f5es sobre a cadeia principal mais lentamente, e para o cliente externo isso pode parecer uma rede lenta, embora o problema esteja em outro lugar.<\/p>\n

    <\/p>\n

    Para otimizar o desempenho nesta etapa, \u00e9 \u00fatil coletar e monitorar m\u00e9tricas diretamente dos n\u00f3s e incluir aquelas que dizem respeito \u00e0 atualiza\u00e7\u00e3o do banco de dados de estado: o n\u00famero de blocos processados no n\u00f3, seu tamanho, o n\u00famero de transa\u00e7\u00f5es, a quantidade de altern\u00e2ncias entre forks de cadeias, o n\u00famero de blocos inv\u00e1lidos, o tempo de opera\u00e7\u00e3o da m\u00e1quina virtual, o tempo de confirma\u00e7\u00e3o de dados etc. Isso permitir\u00e1 distinguir problemas de rede de erros nos algoritmos de processamento das cadeias.<\/p>\n

    <\/p>\n

    A m\u00e1quina virtual que processa transa\u00e7\u00f5es pode ser uma fonte de informa\u00e7\u00e3o \u00fatil para otimizar o funcionamento do blockchain. A quantidade de aloca\u00e7\u00f5es de mem\u00f3ria, o n\u00famero de instru\u00e7\u00f5es de leitura\/escrita e outras m\u00e9tricas relacionadas \u00e0 efici\u00eancia da execu\u00e7\u00e3o do c\u00f3digo dos contratos podem fornecer muitas informa\u00e7\u00f5es valiosas para os desenvolvedores. Ao mesmo tempo, contratos inteligentes s\u00e3o programas, e em teoria, eles podem consumir qualquer um dos recursos: cpu\/mem\u00f3ria\/rede\/armazenamento, ent\u00e3o o processamento de transa\u00e7\u00f5es \u00e9 uma etapa bastante indefinida, que tamb\u00e9m muda muito ao longo das vers\u00f5es e na altera\u00e7\u00e3o do c\u00f3digo dos contratos. Portanto, m\u00e9tricas relacionadas ao processamento de transa\u00e7\u00f5es tamb\u00e9m s\u00e3o necess\u00e1rias para uma otimiza\u00e7\u00e3o eficaz do desempenho do blockchain.<\/p>\n

    <\/p>\n

    Recebendo a notifica\u00e7\u00e3o do cliente sobre a ativa\u00e7\u00e3o da transa\u00e7\u00e3o na blockchain<\/h2>\n

    <\/p>\n

    Esta \u00e9 a etapa final para um cliente obter o servi\u00e7o de blockchain. Comparado a outras etapas, n\u00e3o existem muitos custos indiretos aqui, mas ainda assim, deve-se considerar a possibilidade de receber uma resposta volumosa do n\u00f3 (por exemplo, um smart contract que retorna um array de dados). De qualquer forma, este momento \u00e9 crucial para quem faz a pergunta \"quantos tps tem o seu blockchain?\", pois \u00e9 quando se registra o tempo de obten\u00e7\u00e3o do servi\u00e7o. <\/p>\n

    <\/p>\n

    Neste ponto, deve ser enviado o tempo total que o cliente teve que esperar pela resposta da blockchain. Este \u00e9 o tempo que o usu\u00e1rio aguardar\u00e1 a confirma\u00e7\u00e3o em seu aplicativo, e a otimiza\u00e7\u00e3o desse tempo \u00e9 a principal tarefa dos desenvolvedores.<\/p>\n

    <\/p>\n

    Conclus\u00e3o<\/h1>\n

    <\/p>\n

    Como resultado, podemos descrever os tipos de opera\u00e7\u00f5es realizadas em blockchains e dividi-las em v\u00e1rias categorias:<\/p>\n

    <\/p>\n

      \n
    1. transforma\u00e7\u00f5es criptogr\u00e1ficas, constru\u00e7\u00e3o de provas<\/li>\n
    2. rede peer-to-peer, replica\u00e7\u00e3o de transa\u00e7\u00f5es e blocos<\/li>\n
    3. processamento de transa\u00e7\u00f5es, execu\u00e7\u00e3o de contratos inteligentes<\/li>\n
    4. aplica\u00e7\u00e3o de mudan\u00e7as na blockchain ao state database, atualiza\u00e7\u00e3o de dados sobre transa\u00e7\u00f5es e blocos<\/li>\n
    5. consultas read-only ao state database, API da node de blockchain, servi\u00e7os de assinatura <\/li>\n<\/ol>\n

      <\/p>\n

      De fato, os requisitos t\u00e9cnicos para nodes de blockchains modernas s\u00e3o extremamente rigorosos \u2014 s\u00e3o necess\u00e1rios CPUs r\u00e1pidos para criptografia, uma grande quantidade de mem\u00f3ria RAM para armazenar e acessar rapidamente o state database, intera\u00e7\u00e3o de rede utilizando um grande n\u00famero de conex\u00f5es abertas simultaneamente e armazenamento amplo. Esses altos requisitos e a abund\u00e2ncia de diferentes tipos de opera\u00e7\u00f5es inevitavelmente resultam em insufici\u00eancia de recursos nas nodes, e ent\u00e3o, qualquer uma das etapas acima pode se tornar um gargalo para o desempenho geral da rede.<\/p>\n

      <\/p>\n

      Ao desenvolver e avaliar o desempenho de blockchains, voc\u00ea ter\u00e1 que levar em conta todos esses aspectos. Para isso, \u00e9 necess\u00e1rio coletar e analisar m\u00e9tricas tanto dos clientes quanto dos n\u00f3s da rede, buscar correla\u00e7\u00f5es entre eles, avaliar o tempo de fornecimento de servi\u00e7os aos clientes, considerar todos os principais recursos: cpu\/mem\u00f3ria\/rede\/armazenamento, e entender como eles s\u00e3o usados e influenciam uns aos outros. Tudo isso torna a compara\u00e7\u00e3o das velocidades de diferentes blockchains, na forma de \"quantos TPS\", uma tarefa extremamente ingrata, pois existe uma enorme quantidade de configura\u00e7\u00f5es e estados diversos. Em grandes sistemas centralizados, clusters de centenas de servidores, esses problemas tamb\u00e9m s\u00e3o complexos e exigem a coleta de um grande n\u00famero de m\u00e9tricas diferentes, mas nos blockchains, devido a redes P2P, m\u00e1quinas virtuais, execu\u00e7\u00e3o de contratos, e economias internas, o n\u00famero de graus de liberdade \u00e9 muito maior, o que torna o teste em apenas alguns servidores pouco representativo e fornece valores que s\u00e3o quase abstratos, com pouca ou nenhuma rela\u00e7\u00e3o com a realidade.<\/p>\n

      <\/p>\n

      Portanto, ao desenvolver no n\u00facleo do blockchain, para avaliar o desempenho e responder \u00e0 pergunta \"melhorou em compara\u00e7\u00e3o com a \u00faltima vez?\", usamos um software bastante complexo que orquestra a execu\u00e7\u00e3o do blockchain com dezenas de n\u00f3s e inicia automaticamente benchmarks e coleta de m\u00e9tricas. Sem essas informa\u00e7\u00f5es, \u00e9 extremamente dif\u00edcil depurar protocolos que operam com m\u00faltiplos participantes.<\/p>\n

      <\/p>\n

      Assim, ao receber a pergunta \"quantos TPS tem o seu blockchain?\", ofere\u00e7a uma x\u00edcara de ch\u00e1 ao interlocutor e pergunte se ele est\u00e1 disposto a analisar uma dezena de gr\u00e1ficos, al\u00e9m de ouvir sobre os diversos problemas de desempenho dos blockchains e suas sugest\u00f5es para solucion\u00e1-los...<\/p>\n

      Fonte: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

      \u041b\u044e\u0431\u0438\u043c\u044b\u043c \u0432\u043e\u043f\u0440\u043e\u0441\u043e\u043c \u043e \u043b\u044e\u0431\u043e\u0439 \u0440\u0430\u0441\u043f\u0440\u0435\u0434\u0435\u043b\u0435\u043d\u043d\u043e\u0439 \u0441\u0438\u0441\u0442\u0435\u043c\u0435 \u043e\u0442 \u043d\u0435\u0442\u0435\u0445\u043d\u0438\u0447\u0435\u0441\u043a\u043e\u0433\u043e \u0441\u043f\u0435\u0446\u0438\u0430\u043b\u0438\u0441\u0442\u0430 \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u201c\u0421\u043a\u043e\u043b\u044c\u043a\u043e tps \u0432 \u0432\u0430\u0448\u0435\u043c \u0431\u043b\u043e\u043a\u0447\u0435\u0439\u043d\u0435?\u201d. \u041e\u0434\u043d\u0430\u043a\u043e, \u043d\u0430\u0437\u0432\u0430\u043d\u043d\u043e\u0435 \u0432 \u043e\u0442\u0432\u0435\u0442 \u0447\u0438\u0441\u043b\u043e \u043e\u0431\u044b\u0447\u043d\u043e \u0438\u043c\u0435\u0435\u0442 \u043c\u0430\u043b\u043e \u043e\u0431\u0449\u0435\u0433\u043e \u0441 \u0442\u0435\u043c, \u0447\u0442\u043e \u0445\u043e\u0442\u0435\u043b \u0431\u044b \u0443\u0441\u043b\u044b\u0448\u0430\u0442\u044c \u0432\u043e\u043f\u0440\u043e\u0448\u0430\u044e\u0449\u0438\u0439. \u041d\u0430 \u0434\u0435\u043b\u0435, \u043e\u043d \u0445\u043e\u0442\u0435\u043b \u0441\u043f\u0440\u043e\u0441\u0438\u0442\u044c \u201c\u043f\u043e\u0434\u043e\u0439\u0434\u0435\u0442 \u043b\u0438 \u0432\u0430\u0448 \u0431\u043b\u043e\u043a\u0447\u0435\u0439\u043d \u043f\u043e\u0434 \u043c\u043e\u0438 \u0431\u0438\u0437\u043d\u0435\u0441 \u0442\u0440\u0435\u0431\u043e\u0432\u0430\u043d\u0438\u044f\u201d, \u0438 \u044d\u0442\u0438 \u0442\u0440\u0435\u0431\u043e\u0432\u0430\u043d\u0438\u044f \u2014 \u044d\u0442\u043e \u043d\u0435 \u043e\u0434\u043d\u043e \u0447\u0438\u0441\u043b\u043e, \u0430 \u043c\u043d\u043e\u0436\u0435\u0441\u0442\u0432\u043e \u0443\u0441\u043b\u043e\u0432\u0438\u0439 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-36157","post","type-post","status-publish","format-standard","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Quantos TPS no seu blockchain? | ProHoster","description":"A pergunta favorita de qualquer sistema distribu\u00eddo por um especialista n\u00e3o t\u00e9cnico \u00e9 \"Quantos tps no seu blockchain?\".","canonical_url":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/skolko-tps-v-vashem-blokchejne","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"pt_PT","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0421\u043a\u043e\u043b\u044c\u043a\u043e TPS \u0432 \u0432\u0430\u0448\u0435\u043c \u0431\u043b\u043e\u043a\u0447\u0435\u0439\u043d\u0435? | ProHoster","og:description":"\u041b\u044e\u0431\u0438\u043c\u044b\u043c \u0432\u043e\u043f\u0440\u043e\u0441\u043e\u043c \u043e \u043b\u044e\u0431\u043e\u0439 \u0440\u0430\u0441\u043f\u0440\u0435\u0434\u0435\u043b\u0435\u043d\u043d\u043e\u0439 \u0441\u0438\u0441\u0442\u0435\u043c\u0435 \u043e\u0442 \u043d\u0435\u0442\u0435\u0445\u043d\u0438\u0447\u0435\u0441\u043a\u043e\u0433\u043e \u0441\u043f\u0435\u0446\u0438\u0430\u043b\u0438\u0441\u0442\u0430 \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u201c\u0421\u043a\u043e\u043b\u044c\u043a\u043e tps \u0432 \u0432\u0430\u0448\u0435\u043c \u0431\u043b\u043e\u043a\u0447\u0435\u0439\u043d\u0435?\u201d.","og:url":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/skolko-tps-v-vashem-blokchejne","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T19:09:55+00:00","article:modified_time":"2019-10-31T19:09:55+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"36157","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-22 02:15:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 01:49:44","updated":"2026-01-22 02:15:19","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts\/36157","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/comments?post=36157"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts\/36157\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/media?parent=36157"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/categories?post=36157"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/tags?post=36157"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}