Por que o desempenho do Blockchain é difícil de medir

Desempenho e escalabilidade são desafios muito discutidos no espaço criptográfico, relevantes tanto para projetos de Camada 1 (blockchains independentes) quanto para soluções de Camada 2 (como rollups e canais fora da cadeia). No entanto, não temos métricas ou benchmarks padronizados. Os números são frequentemente comunicados de forma inconsistente e incompleta, dificultando a comparação precisa dos projetos e muitas vezes obscurecendo o que é mais importante na prática. 

Precisamos de uma abordagem mais matizada e completa para medir e comparar o desempenho – uma abordagem que divida o desempenho em múltiplos componentes e compare as compensações em vários eixos. Neste post, defino a terminologia básica, descrevo desafios e ofereço diretrizes e princípios-chave a serem considerados ao avaliar o desempenho do blockchain. 

Escalabilidade x desempenho

Primeiro, vamos definir dois termos, escalabilidade e desempenho, que têm significados padrão da ciência da computação que são frequentemente mal utilizados em contextos de blockchain. Performance mede o que é um sistema atualmente capaz de alcançar. Como discutiremos abaixo, as métricas de desempenho podem incluir transações por segundo ou tempo médio de confirmação de transação. AMPLIAR, por outro lado, mede a capacidade de um sistema de melhorar o desempenho adicionando recursos.

Esta distinção é importante: muitas abordagens para melhorar o desempenho não melhoram em nada a escalabilidade, quando definidas corretamente. Um exemplo simples é usar um esquema de assinatura digital mais eficiente, como as assinaturas BLS, que têm aproximadamente metade do tamanho das assinaturas Schnorr ou ECDSA. Se o Bitcoin mudasse de ECDSA para BLS, o número de transações por bloco poderia aumentar de 20 a 30%, melhorando o desempenho durante a noite. Mas só podemos fazer isso uma vez – não existe um esquema de assinatura ainda mais eficiente em termos de espaço para mudar (as assinaturas BLS também podem ser agregadas para economizar mais espaço, mas este é outro truque único).

Vários outros truques pontuais (como o SegWit) são possíveis em blockchains, mas é necessária uma arquitetura escalável para obter melhoria contínua de desempenho, onde a adição de mais recursos melhora o desempenho ao longo do tempo. Essa também é a sabedoria convencional em muitos outros sistemas de computador, como na construção de um servidor web. Com alguns truques comuns, você pode construir um servidor muito rápido; mas, em última análise, você precisa de uma arquitetura multiservidor que possa atender à demanda cada vez maior, adicionando continuamente servidores extras.

Compreender a distinção também ajuda a evitar o erro de categoria comum encontrado em afirmações como: “Blockchain X é altamente escalável, pode lidar com Y transações por segundo!” A segunda afirmação pode ser impressionante, mas é uma atuação métrica, não uma métrica de escalabilidade. Isso não se refere à capacidade de melhorar o desempenho adicionando recursos.

A escalabilidade requer inerentemente a exploração do paralelismo. No espaço blockchain, o dimensionamento da Camada 1 parece exigir fragmentação ou algo que se parece com fragmentação. O conceito básico de fragmentação – dividir o estado em partes para que diferentes validadores possam processar de forma independente – corresponde muito à definição de escalabilidade. Existem ainda mais opções na Camada 2 que permitem adicionar processamento paralelo – incluindo canais fora da cadeia, servidores rollup e cadeias laterais.

Latência versus taxa de transferência

Classicamente, o desempenho do sistema blockchain é avaliado em duas dimensões: latência e rendimento: a latência mede a rapidez com que uma transação individual pode ser confirmada, enquanto o rendimento mede a taxa agregada de transações ao longo do tempo. Esses eixos se aplicam a sistemas de Camada 1 e Camada 2, bem como a muitos outros tipos de sistemas de computador (como mecanismos de consulta de banco de dados e servidores web).

Infelizmente, tanto a latência quanto o rendimento são complexos de medir e comparar. Além disso, os usuários individuais não se importam com o rendimento (que é uma medida que abrange todo o sistema). O que realmente importa é a latência e as taxas de transação – mais especificamente, que suas transações sejam confirmadas da maneira mais rápida e econômica possível. Embora muitos outros sistemas de computador também sejam avaliados com base em custo/desempenho, as taxas de transação são um eixo de desempenho um tanto novo para sistemas blockchain que realmente não existe em sistemas de computador tradicionais.

Desafios na medição da latência

A latência parece simples à primeira vista: quanto tempo leva para uma transação ser confirmada? Mas sempre existem várias maneiras diferentes de responder a essa pergunta.

Primeiro, podemos medir a latência entre diferentes pontos no tempo e obter resultados diferentes. Por exemplo, começamos a medir a latência quando o usuário clica no botão “enviar” localmente ou quando a transação atinge o mempool? E paramos o relógio quando a transação está em um bloco proposto ou quando um bloco é confirmado com um ou seis blocos de acompanhamento?

A abordagem mais comum adota o ponto de vista dos validadores, medindo desde o momento em que um cliente transmite uma transação pela primeira vez até o momento em que uma transação é razoavelmente “confirmada” (no sentido em que os comerciantes do mundo real considerariam um pagamento recebido e liberariam a mercadoria). . É claro que diferentes comerciantes podem aplicar critérios de aceitação diferentes, e até mesmo um único comerciante pode usar padrões diferentes dependendo do valor da transação.

A abordagem centrada no validador deixa de lado vários aspectos que são importantes na prática. Primeiro, ele ignora a latência na rede ponto a ponto (quanto tempo leva desde o momento em que o cliente transmite uma transação até o momento em que a maioria dos nós a ouviu?) e a latência do lado do cliente (quanto tempo leva para preparar uma transação na máquina local do cliente?). A latência do lado do cliente pode ser muito pequena e previsível para transações simples, como assinar um pagamento Ethereum, mas pode ser significativa para casos mais complexos, como provar que uma transação Zcash protegida está correta.

Mesmo se padronizarmos a janela de tempo que estamos tentando medir com a latência, a resposta é quase sempre ela depende. Nenhum sistema de criptomoeda já construído ofereceu latência fixa de transação. Uma regra básica a ser lembrada é:

A latência é uma distribuição, não um único número.

A comunidade de pesquisa em redes já entendeu isso há muito tempo (veja, por exemplo, este excelente palestra de Gil Tene). Uma ênfase particular é colocada na “cauda longa” da distribuição, já que uma latência altamente elevada, mesmo em 0.1% das transações (ou consultas ao servidor web), afetará severamente impacto usuários finais.

Com blockchains, a latência de confirmação pode variar por vários motivos:

Lote: a maioria das transações em lote dos sistemas de alguma forma, por exemplo, em blocos na maioria dos sistemas da Camada 1. Isto leva a uma latência variável, porque algumas transações terão que esperar até que o lote seja preenchido. Outros podem ter sorte e entrar no lote por último. Essas transações são confirmadas imediatamente e não sofrem nenhuma latência adicional.

Congestionamento variável: a maioria dos sistemas sofre de congestionamento, o que significa que mais transações são lançadas (pelo menos algumas vezes) do que o sistema pode processar imediatamente. O quão congestionado pode variar quando as transações são transmitidas em horários imprevisíveis (muitas vezes abstraídos como um Processo de Poisson) ou quando a taxa de novas transações muda ao longo do dia ou da semana, ou em resposta a eventos externos, como um lançamento popular de NFT.

Variância da camada de consenso: A confirmação de uma transação na Camada 1 geralmente requer um conjunto distribuído de nós para chegar a um consenso sobre um bloco, o que pode adicionar atrasos variáveis, independentemente do congestionamento. Os sistemas de prova de trabalho encontram blocos em momentos imprevisíveis (também abstratamente um processo de Poisson). Os sistemas de prova de aposta também podem adicionar vários atrasos (por exemplo, se um número insuficiente de nós estiver online para formar um comitê em uma rodada ou se uma mudança de visão for necessária em resposta à queda de um líder).

Por estas razões, uma boa orientação é:

As afirmações sobre latência devem apresentar uma distribuição (ou histograma) de tempos de confirmação, em vez de um único número como média ou mediana.

Embora estatísticas resumidas como média, mediana ou percentis forneçam uma imagem parcial, avaliar com precisão um sistema requer considerar toda a distribuição. Em algumas aplicações, a latência média pode fornecer uma boa visão se a distribuição da latência for relativamente simples (por exemplo, Gaussiana). Mas na criptomoeda quase nunca é assim: normalmente, há uma longa cauda de tempos de confirmação lentos.

As redes de canais de pagamento (por exemplo, Lightning Network) são um bom exemplo. Uma solução clássica de escalonamento L2, essas redes oferecem confirmações de pagamento muito rápidas na maioria das vezes, mas ocasionalmente exigem uma redefinição de canal, o que pode aumentar a latência em ordens de magnitude.

E mesmo que tenhamos boas estatísticas sobre a distribuição exata da latência, elas provavelmente variarão ao longo do tempo, à medida que o sistema e a demanda do sistema mudam. Também nem sempre é claro como comparar as distribuições de latência entre sistemas concorrentes. Por exemplo, considere um sistema que confirma transações com latência uniformemente distribuída entre 1 e 2 minutos (com média e mediana de 90 segundos). Se um sistema concorrente confirma 95% das transações exatamente em 1 minuto e os outros 5% em 11 minutos (com média de 90 segundos e mediana de 60 segundos), qual sistema é melhor? A resposta é provavelmente que alguns aplicativos prefeririam o primeiro e outros o último.

Finalmente, é importante notar que na maioria dos sistemas, nem todas as transações são priorizadas de forma igual. Os usuários podem pagar mais para obter uma prioridade de inclusão mais alta; portanto, além de tudo isso, a latência varia em função das taxas de transação pagas. Resumindo:

A latência é complexa. Quanto mais dados forem relatados, melhor. Idealmente, distribuições completas de latência deveriam ser medidas sob diversas condições de congestionamento. A divisão da latência em diferentes componentes (local, rede, lote, atraso de consenso) também é útil.

Desafios na medição do rendimento

A taxa de transferência também parece simples à primeira vista: quantas transações um sistema pode processar por segundo? Surgem duas dificuldades principais: o que é exactamente uma “transacção” e estamos a medir o que um sistema faz hoje ou o que poderá ser capaz de fazer?

Embora “transações por segundo” (ou tps) seja um padrão de fato para medir o desempenho do blockchain, as transações são problemáticas como unidade de medida. Para sistemas que oferecem programabilidade de uso geral (“contratos inteligentes”) ou mesmo recursos limitados, como transações multiplex de Bitcoin ou opções para verificação multi-sig, a questão fundamental é:

Nem todas as transações são iguais.

Isto é obviamente verdade no Ethereum, onde as transações podem incluir código arbitrário e modificar arbitrariamente o estado. A noção de gás no Ethereum é usada para quantificar (e cobrar taxas) a quantidade total de trabalho que uma transação está realizando, mas isso é altamente específico para o ambiente de execução EVM. Não há uma maneira simples de comparar a quantidade total de trabalho realizado por um conjunto de transações EVM com, digamos, um conjunto de transações Solana usando o ambiente BPF. Comparar qualquer um deles com um conjunto de transações Bitcoin é igualmente complicado.

Blockchains que separam a camada de transação em uma camada de consenso e uma camada de execução podem tornar isso mais claro. Na camada de consenso (pura), o rendimento pode ser medido em bytes adicionados à cadeia por unidade de tempo. A camada de execução será sempre mais complexa.

Camadas de execução mais simples, como servidores rollup que suportam apenas transações de pagamento, evitam a dificuldade de quantificar a computação. Mesmo neste caso, porém, os pagamentos podem variar no número de entradas e saídas. Canal de pagamento as transações podem variar no número de “saltos” necessários, o que afeta o rendimento. E o rendimento do servidor de rollup pode depender da extensão em que um lote de transações pode ser “compensado” a um conjunto menor de alterações resumidas.

Outro desafio com o rendimento é ir além da medição empírica do desempenho atual para avaliar a capacidade teórica. Isto introduz todos os tipos de questões de modelagem para avaliar a capacidade potencial. Primeiro, devemos decidir sobre uma carga de trabalho de transação realista para a camada de execução. Em segundo lugar, os sistemas reais quase nunca atingem a capacidade teórica, especialmente os sistemas blockchain. Por razões de robustez, esperamos que as implementações de nós sejam heterogêneas e diversas na prática (em vez de todos os clientes executarem uma única implementação de software). Isso torna as simulações precisas do rendimento do blockchain ainda mais difíceis de realizar. 

Geral:

As declarações de rendimento exigem uma explicação cuidadosa da carga de trabalho da transação e da população de validadores (sua quantidade, implementação e conectividade de rede). Na ausência de qualquer padrão claro, as cargas de trabalho históricas de uma rede popular como a Ethereum são suficientes.

Compensações entre latência e taxa de transferência

Latência e taxa de transferência geralmente são uma compensação. Como Contornos de Lefteris Kokoris-Kogias, essa compensação muitas vezes não é suave, com um ponto de inflexão em que a latência aumenta acentuadamente à medida que a carga do sistema se aproxima do seu rendimento máximo.

Os sistemas cumulativos de conhecimento zero apresentam um exemplo natural da compensação taxa de transferência/latência. Grandes lotes de transações aumentam o tempo de prova, o que aumenta a latência. Mas a pegada na cadeia, tanto em termos de tamanho da prova como de custo de validação, será amortizada em mais transações com lotes maiores, aumentando o rendimento.

Taxas de transação

Compreensivelmente, os usuários finais se preocupam mais com a compensação entre latência e Taxas, não latência e taxa de transferência. Os usuários não têm nenhum motivo direto para se preocupar com o rendimento, apenas que podem confirmar as transações rapidamente pelas taxas mais baixas possíveis (com alguns usuários se preocupando mais com as taxas e outros mais com a latência). Em um nível elevado, as taxas são afetadas por vários fatores:

1. Quanta demanda de mercado existe para fazer transações?
2. Qual rendimento geral é alcançado pelo sistema?
3. Quanta receita geral o sistema fornece aos validadores ou mineradores?
4. Quanto dessa receita é baseada em taxas de transação versus recompensas inflacionárias?

Os dois primeiros fatores são aproximadamente curvas de oferta/demanda que levam a um preço de equilíbrio de mercado (embora tenha sido afirmado que mineiros atuam como um cartel para aumentar as taxas acima deste ponto). Se todo o resto for igual, mais rendimento tende a levar a taxas mais baixas, mas há muito mais coisas acontecendo.

Em particular, os pontos 3 e 4 acima são questões fundamentais do design do sistema blockchain, mas faltam-nos bons princípios para qualquer um deles. Temos alguma compreensão das vantagens e desvantagens de dar aos mineiros receitas provenientes de recompensas inflacionárias versus taxas de transação. No entanto, apesar de muitas análises económicas dos protocolos de consenso da blockchain, ainda não temos um modelo amplamente aceite sobre a quantidade de receitas que deve ser canalizada para os validadores. Hoje, a maioria dos sistemas baseia-se em uma estimativa fundamentada sobre quanta receita é suficiente para manter os validadores se comportando honestamente, sem estrangular o uso prático do sistema. Em modelos simplificados, pode ser demonstrado que o custo de montar um ataque de 51% aumenta com recompensas para validadores.

Aumentar o custo dos ataques é uma coisa boa, mas também não sabemos até que ponto a segurança é “suficiente”. Imagine que você está pensando em ir a dois parques de diversões. Um deles afirma gastar 50% menos com manutenção de passeios do que o outro. É uma boa ideia ir a este parque? Pode ser que sejam mais eficientes e obtenham segurança equivalente por menos dinheiro. Talvez o outro esteja gastando mais do que o necessário para manter as viagens seguras, sem nenhum benefício. Mas também pode acontecer que o primeiro parque seja perigoso. Os sistemas Blockchain são semelhantes. Depois de levar em consideração o rendimento, os blockchains com taxas mais baixas têm taxas mais baixas porque recompensam (e, portanto, incentivam menos) seus validadores. Não temos hoje boas ferramentas para avaliar se isso está certo ou se deixa o sistema vulnerável a ataques. Geral:

Comparar taxas entre sistemas pode ser enganoso. Embora as taxas de transação sejam importantes para os usuários, elas são afetadas por muitos fatores além do próprio design do sistema. A taxa de transferência é uma métrica melhor para analisar um sistema como um todo.

Conclusão

Avaliar o desempenho de forma justa e precisa é difícil. Isto é igualmente verdadeiro para medir o desempenho de um carro. Assim como acontece com os blockchains, pessoas diferentes se preocuparão com coisas diferentes. Com os carros, alguns usuários se preocuparão com a velocidade máxima ou aceleração, outros com o consumo de combustível e outros ainda com a capacidade de reboque. Tudo isso não é trivial de avaliar. Nos EUA, por exemplo, a Agência de Proteção Ambiental mantém diretrizes detalhadas apenas sobre como o consumo de combustível é avaliado e também sobre como ele deve ser apresentado aos usuários em uma concessionária.

O espaço blockchain está muito longe desse nível de padronização. Em certas áreas, poderemos chegar lá no futuro com cargas de trabalho padronizadas para avaliar o rendimento de um sistema ou gráficos padronizados para apresentar distribuições de latência. Por enquanto, a melhor abordagem para avaliadores e construtores é coletar e publicar o máximo de dados possível, com uma descrição detalhada da metodologia de avaliação, para que possam ser reproduzidos e comparados com outros sistemas.