O caminho da cadeia BNB para os grandes blocos

A estrada dos grandes blocos na cadeia BNB

À semelhança da Solana, da Heco e de outras cadeias públicas apoiadas por bolsas, a cadeia pública BNB Smart Chain (BSC) da BNB Chain há muito que procura um elevado desempenho. Desde o seu lançamento em 2020, a BSC fixou o limite de capacidade de gás para cada bloco em 30 milhões, com um intervalo de bloco estável de 3 segundos. Com estes parâmetros, a BSC atingiu um TPS máximo (TPS com várias transacções misturadas) superior a 100. Em junho de 2021, o limite de gás de bloco da BSC foi aumentado para 60 milhões. No entanto, em julho do mesmo ano, um jogo em cadeia chamado CryptoBlades explodiu na BSC, fazendo com que o volume de transacções diárias ultrapassasse os 8 milhões e resultando num aumento vertiginoso das taxas. Verificou-se que o estrangulamento da eficiência do BSC ainda era bastante óbvio nessa altura.

(Fonte: BscScan)

Para resolver os problemas de desempenho da rede, a BSC aumentou mais uma vez o limite de gás para cada bloco, que se manteve estável em cerca de 80-85 milhões durante muito tempo. Em setembro de 2022, o limite de gás por bloco da cadeia BSC foi aumentado para 120 milhões e, no final do ano, foi aumentado para 140 milhões, quase cinco vezes mais do que em 2020. Anteriormente, a BSC tinha planeado aumentar o limite da capacidade de gás dos blocos para 300 milhões, mas talvez devido à grande sobrecarga dos nós do Validador, a proposta de blocos tão grandes não foi implementada.

fonte: YCHARTS

Mais tarde, a BNB Chain parece ter-se concentrado mais na via modular/Layer2 em vez de persistir na expansão Layer1. Esta intenção tornou-se cada vez mais evidente desde o lançamento do zkBNB, no segundo semestre do ano passado, até ao GreenField, no início deste ano. Devido a um forte interesse em blockchain modular/Layer2, o autor deste artigo utilizará o opBNB como objeto de investigação para revelar os estrangulamentos de desempenho do Rollup, comparando-o com o Ethereum Layer2.

O impulso do elevado débito da BSC para a camada DA do opBNB

Como todos sabemos, a Celestia resumiu quatro componentes-chave de acordo com o fluxo de trabalho da cadeia de blocos modular: Camada de execução: Executa o código do contrato e completa as transições de estado; Camada de liquidação: Lida com provas de fraude/provas de validade e aborda questões de ponte entre L2 e L1. Camada de consenso: Chega a um consenso sobre a ordem das transacções. Camada de disponibilidade de dados (DA): Publica dados relacionados com o livro-razão da cadeia de blocos, permitindo que os validadores descarreguem esses dados.

Entre elas, a camada DA é frequentemente associada à camada de consenso. Por exemplo, os dados do DA do Rollup otimista contêm um lote de sequências de transacções em blocos L2. Quando os nós completos L2 obtêm dados DA, sabem a ordem de cada transação neste lote. (Por esta razão, a comunidade Ethereum acredita que a camada DA e a camada de consenso estão relacionadas quando se coloca o Rollup em camadas).

No entanto, para o Ethereum Layer2, a taxa de transferência de dados da camada DA (Ethereum) tornou-se o maior estrangulamento que limita o desempenho do Rollup. Isto deve-se ao facto de o atual débito de dados do Ethereum ser demasiado baixo, obrigando o Rollup a suprimir o seu TPS tanto quanto possível para evitar que a rede principal do Ethereum seja incapaz de suportar os dados gerados pelo L2. Ao mesmo tempo, a baixa taxa de transferência de dados faz com que um grande número de instruções de transação na rede Ethereum esteja num estado pendente, levando a que as taxas de gás sejam empurradas para níveis extremamente elevados e aumentando ainda mais o custo da publicação de dados para a Layer2. Por último, muitas redes Layer2 têm de adotar camadas DA fora da Ethereum, como a Celestia, e a opBNB, que está perto da água, optou por utilizar diretamente o elevado rendimento da BSC para implementar a DA, a fim de resolver o problema do estrangulamento da publicação de dados. Para facilitar a compreensão, vamos apresentar-lhe o método de publicação de dados DA para Rollup. Tomando o Arbitrum como exemplo, a cadeia Ethereum controlada pelo endereço EOA do sequenciador Layer2 enviará periodicamente transacções para o contrato especificado. Nos parâmetros de entrada calldata desta instrução, os dados de transação embalados são escritos e os eventos on-chain correspondentes são desencadeados, deixando um registo permanente nos registos do contrato.

Desta forma, os dados de transação da Layer2 são armazenados em blocos Ethereum durante muito tempo. As pessoas capazes de executar nós L2 podem descarregar os registos correspondentes e analisar os dados correspondentes, mas os nós Ethereum em si não executam estas transacções L2. É fácil ver que o L2 apenas armazena os dados das transacções em blocos Ethereum, incorrendo em custos de armazenamento, enquanto os custos computacionais da execução das transacções são suportados pelos próprios nós L2. O método de implementação do DA da Arbitrum é o acima referido, enquanto o Optimism utiliza um endereço EOA controlado pelo sequenciador para transferir para outro endereço EOA especificado, transportando um novo lote de dados de transação da camada 2 nos dados adicionais. Quanto ao opBNB, que utiliza a pilha OP, o seu método de publicação de dados DA é basicamente o mesmo que o do Otimismo.

É óbvio que a taxa de transferência da camada DA limitará o tamanho dos dados que o Rollup pode publicar numa unidade de tempo, limitando assim o TPS. Considerando que após o EIP1559, a capacidade de gás de cada bloco ETH estabiliza em 30 milhões, e o tempo de bloco após a fusão é de cerca de 12 segundos, o Ethereum pode lidar com um máximo de apenas 2,5 milhões de gás por segundo. Na maioria das vezes, o gás consumido pela acomodação de dados de transação L2 por byte em calldata é 16, pelo que o Ethereum pode lidar com um tamanho máximo de calldata de apenas 150 KB por segundo. Em contrapartida, o tamanho médio máximo de calldata processado por segundo pela BSC é de cerca de 2910 KB, o que é 18,6 vezes superior ao da Ethereum. A diferença entre os dois enquanto camadas DA é óbvia.

Em resumo, o Ethereum pode transportar cerca de 150 KB de dados de transação L2 por segundo. Mesmo após o lançamento do EIP 4844, este número não sofrerá grandes alterações, sendo apenas reduzida a taxa DA. Então, quantos dados de transacções podem ser incluídos em cerca de 150 KB por segundo? Aqui temos de explicar a taxa de compressão de dados do Rollup. Vitalik foi excessivamente otimista em 2021, estimando que o Optimistic Rollup pode comprimir o tamanho dos dados da transação para 11% do tamanho original. Por exemplo, uma transferência ETH básica, que originalmente ocupava um tamanho de calldata de 112 bytes, pode ser comprimida para 12 bytes pelo Optimistic Rollup, as transferências ERC-20 podem ser comprimidas para 16 bytes e as transacções Swap no Uniswap podem ser comprimidas para 14 bytes. De acordo com a sua estimativa, o Ethereum pode registar cerca de 10 000 transacções L2 por segundo (com vários tipos misturados). No entanto, de acordo com os dados divulgados pela equipa Optimism em 2022, a taxa de compressão de dados real pode atingir um máximo de apenas cerca de 37%, o que é 3,5 vezes inferior à estimativa de Vitalik.

(A estimativa de Vitalik do efeito de escalabilidade do Rollup desvia-se significativamente das condições reais)

(Taxas de compressão reais alcançadas por vários algoritmos de compressão divulgados pelo Optimism)

Por isso, vamos dar um número razoável: mesmo que o Ethereum atinja o seu limite de rendimento, o TPS máximo de todos os Optimistic Rollups combinados é apenas ligeiramente superior a 2000. Por outras palavras, se os blocos Ethereum fossem inteiramente utilizados para transportar os dados publicados pelos Optimistic Rollups, como os distribuídos entre Arbitrum, Optimism, Base e Boba, o TPS combinado destes Optimistic Rollups não chegaria sequer aos 3000, mesmo com os algoritmos de compressão mais eficientes. Além disso, devemos considerar que, após o PEI1559, a capacidade de gás de cada bloco é, em média, apenas 50% do valor máximo, pelo que o número acima referido deve ser reduzido para metade. Após o lançamento do EIP4844, embora as taxas de transação para a publicação de dados sejam significativamente reduzidas, o tamanho máximo do bloco do Ethereum não sofrerá grandes alterações (uma vez que demasiadas alterações afectariam a segurança da cadeia principal do ETH), pelo que o valor estimado acima não progredirá muito.

De acordo com os dados da Arbiscan e da Etherscan, um lote de transacções na Arbitrum contém 1115 transacções, consumindo 1,81 milhões de gás na Ethereum. Por extrapolação, se a camada DA for preenchida em todos os blocos, o limite teórico de TPS do Arbitrum é de aproximadamente 1500. Claro que, considerando a questão da reorganização do bloco L1, a Arbitrum não pode publicar lotes de transacções em cada bloco Ethereum, pelo que os números acima referidos são atualmente apenas teóricos. Além disso, com a adoção generalizada de carteiras inteligentes relacionadas com a EIP 4337, o problema da DA tornar-se-á ainda mais grave. Porque com o suporte para a EIP 4337, a forma como os utilizadores verificam a sua identidade pode ser personalizada, como o carregamento de dados binários de impressões digitais ou íris, o que aumentará ainda mais a dimensão dos dados ocupados por transacções regulares. Por conseguinte, o baixo débito de dados do Ethereum é o maior estrangulamento que limita a eficiência do Rollup, e este problema pode não ser devidamente resolvido durante muito tempo. Por outro lado, na cadeia BNB da cadeia pública BSC, o tamanho médio máximo de calldata processado por segundo é de aproximadamente 2910 KB, o que é 18,6 vezes superior ao da Ethereum. Por outras palavras, desde que a camada de execução consiga acompanhar o ritmo, o limite superior teórico de TPS da camada 2 no ecossistema da cadeia BNB pode atingir cerca de 18 vezes o da ARB ou OP. Este número é calculado com base na atual capacidade máxima de gás de bloqueio da cadeia BNB de 140 milhões, com um tempo de bloqueio de 3 segundos.

Por outras palavras, o atual limite agregado de TPS de todos os Rollups no ecossistema da BNB Chain é 18,6 vezes superior ao do Ethereum (mesmo quando se considera o ZKRollup). Nesta perspetiva, é fácil compreender porque é que tantos projectos Layer2 utilizam a camada DA sob a cadeia Ethereum para publicar dados, uma vez que a diferença é bastante evidente. No entanto, a questão não é assim tão simples. Para além do problema do débito de dados, a estabilidade da própria camada 1 pode também afetar a camada 2. Por exemplo, a maioria dos Rollups costuma esperar vários minutos antes de publicar um lote de transações no Ethereum, considerando a possibilidade de reorganização do bloco Layer1. Se um bloco da Camada 1 for reorganizado, isso afectará o livro-razão da Camada 2. Por conseguinte, o sequenciador aguardará a publicação de vários novos blocos da camada 1 após cada lançamento de um lote de transacções L2, reduzindo significativamente a probabilidade de reversão de blocos, antes de publicar o próximo lote de transacções L2. Na realidade, isto atrasa o momento em que os blocos L2 são finalmente confirmados, reduzindo a velocidade de confirmação das grandes transacções (as grandes transacções exigem resultados irreversíveis para garantir a segurança). Em resumo, as transacções que ocorrem em L2 só se tornam irreversíveis depois de serem publicadas nos blocos da camada DA e depois de a camada DA ter gerado um determinado número de novos blocos. Esta é uma razão importante que limita o desempenho do Rollup. No entanto, o Ethereum tem uma velocidade de geração de blocos lenta, levando 12 segundos para produzir um bloco. Assumindo que o Rollup publica um lote de transacções L2 a cada 15 blocos, haverá um intervalo de 3 minutos entre os diferentes lotes e, após a publicação de cada lote, ainda precisa de esperar que sejam gerados vários blocos Layer1 antes de se tornar irreversível (assumindo que não são contestados). Obviamente, o tempo que decorre entre o início e a irreversibilidade das transacções na camada 2 do Ethereum é bastante longo, o que resulta numa velocidade de liquidação lenta; ao passo que a cadeia BNB demora apenas 3 segundos a produzir um bloco e os blocos tornam-se irreversíveis em apenas 45 segundos (o tempo necessário para produzir 15 novos blocos). Com base nos parâmetros actuais, assumindo o mesmo número de transacções L2 e considerando a irreversibilidade dos blocos L1, o número de vezes que o opBNB pode publicar dados de transacções numa unidade de tempo pode atingir 8,53 vezes o do Arbitrum (uma vez a cada 45 segundos para o primeiro e uma vez a cada 6,4 minutos para o segundo). Claramente, a velocidade de liquidação de grandes transacções no opBNB é muito mais rápida do que na Layer2 do Ethereum. Além disso, a dimensão máxima dos dados publicados pela opBNB pode atingir 4,66 vezes a da Layer2 da Ethereum (o limite de gás de bloco L1 da primeira é de 140 milhões, enquanto o da segunda é de 30 milhões). 8.53 * 4.66 = 39.74. Isto representa a diferença entre o opBNB e o Arbitrum em termos de limite de TPS na aplicação prática (atualmente, por razões de segurança, o ARB parece reduzir ativamente o TPS, mas, teoricamente, se o TPS fosse aumentado, continuaria a ser muitas vezes inferior ao do opBNB).

(O sequenciador do Arbitrum publica um lote de transacções a cada 6-7 minutos)

(O sequenciador do opBNB publica um lote de transacções a cada 1-2 minutos, sendo que a mais rápida demora apenas 45 segundos). Naturalmente, há outra questão crucial a considerar, que é a das taxas de gás na camada DA. Cada vez que o L2 publica um lote de transacções, há um custo fixo de 21 000 gases não relacionado com o tamanho dos dados de chamada, que é uma despesa. Se as taxas de gás para a camada DA/L1 forem elevadas, fazendo com que o custo fixo de publicação de um lote de transacções em L2 permaneça elevado, o sequenciador reduzirá a frequência de publicação de lotes de transacções. Além disso, quando se consideram as componentes das comissões L2, o custo da camada de execução é muito baixo e pode muitas vezes ser ignorado, centrando-se apenas no impacto dos custos DA nas comissões de transação. Em resumo, embora a publicação de calldata do mesmo tamanho consuma a mesma quantidade de gás na Ethereum e na BNB Chain, o preço do gás cobrado pela Ethereum é cerca de 10 a dezenas de vezes superior ao da BNB Chain. Traduzidas em taxas de transação L2, as actuais taxas de transação do utilizador no Ethereum Layer2 são também cerca de 10 a dezenas de vezes superiores às do opBNB. Em geral, as diferenças entre o opBNB e o Optimistic Rollup no Ethereum são bastante evidentes.

(Uma transação que consome 150.000 gases no Otimismo custa 0,21 USD)

(Uma transação que consome 130.000 gás no opBNB custa $0,004) No entanto, o aumento da taxa de transferência de dados da camada DA, embora possa melhorar a taxa de transferência global do sistema da camada 2, continua a ter um impacto limitado na melhoria do desempenho dos rollups individuais. Isto deve-se ao facto de a camada de execução não processar frequentemente as transacções com rapidez suficiente. Mesmo que as limitações da camada DA possam ser ignoradas, a camada de execução torna-se o próximo ponto de estrangulamento que afecta o desempenho do Rollup. Se a velocidade de execução da camada de execução Layer2 for lenta, o excesso de procura de transacções propagar-se-á a outras Layer2, causando, em última análise, a fragmentação da liquidez. Por conseguinte, a melhoria do desempenho da camada de execução é também crucial, servindo como outro limiar acima da camada DA.

O Boost da opBNB na camada de execução: Otimização da Cache

Quando a maioria das pessoas discute os estrangulamentos de desempenho das camadas de execução da cadeia de blocos, menciona inevitavelmente dois estrangulamentos importantes: a execução em série de um único segmento do EVM que não utiliza totalmente a CPU e a pesquisa de dados ineficiente da Merkle Patricia Trie adoptada pela Ethereum. Essencialmente, as estratégias de escalonamento para a camada de execução giram em torno da utilização mais eficiente dos recursos da CPU e da garantia de que a CPU pode aceder aos dados o mais rapidamente possível.

As soluções de otimização para a execução de EVM em série e Merkle Patricia Trie são frequentemente complexas e difíceis de implementar, enquanto os esforços mais rentáveis tendem a centrar-se na otimização da cache. De facto, a otimização da cache remete-nos para pontos frequentemente discutidos em contextos tradicionais da Web2 e mesmo em manuais escolares.

Normalmente, a velocidade a que a CPU recupera dados da memória é centenas de vezes mais rápida do que a recuperação de dados do disco. Por exemplo, a extração de dados da memória pode demorar apenas 0,1 segundos, enquanto a extração do disco pode demorar 10 segundos. Por conseguinte, a redução da sobrecarga gerada pelas leituras e gravações em disco, ou seja, a otimização da cache, torna-se um aspeto essencial da otimização da camada de execução da cadeia de blocos.

No Ethereum e na maioria das outras cadeias públicas, a base de dados que regista os estados dos endereços na cadeia é armazenada inteiramente em disco, enquanto a chamada World State trie é meramente um índice desta base de dados, ou um diretório utilizado para a pesquisa de dados. Sempre que o EVM executa um contrato, precisa de aceder aos estados de endereço relevantes. A obtenção de dados da base de dados em disco, um a um, tornaria a execução da transação significativamente mais lenta. Por conseguinte, a criação de uma cache fora da base de dados/disco é um meio necessário para aumentar a velocidade.

O opBNB adopta diretamente a solução de otimização da cache utilizada pela cadeia BNB. De acordo com as informações divulgadas pelo parceiro da opBNB, NodeReal, a cadeia BSC mais antiga criou três camadas de cache entre o EVM e a base de dados LevelDB que armazena o estado. O conceito de conceção é semelhante ao das caches tradicionais de três níveis, em que os dados com maior frequência de acesso são armazenados na cache. Isto permite que a CPU procure primeiro os dados necessários na cache. Se a taxa de acerto da cache for suficientemente elevada, a CPU não precisa de depender excessivamente do disco para ir buscar dados, o que resulta numa melhoria significativa da velocidade de execução global.

Posteriormente, o NodeReal adicionou um recurso que aproveita os núcleos de CPU não utilizados para ler preventivamente os dados que o EVM precisará processar no futuro a partir do banco de dados e armazená-los no cache. Esta funcionalidade é designada por "pré-carregamento de estado".

O princípio do pré-carregamento de estado é simples: as CPUs dos nós de blockchain são multi-core, enquanto o EVM opera em um modo de execução serial single-threaded, utilizando apenas um núcleo de CPU, deixando outros núcleos de CPU subutilizados. Para resolver este problema, os núcleos de CPU que não são utilizados pelo EVM podem ajudar nas tarefas, prevendo os dados de que o EVM necessitará a partir da sequência de transacções que ainda não foram processadas. Estes núcleos de CPU fora do EVM recuperarão então os dados de que o EVM necessitará da base de dados, ajudando o EVM a reduzir a sobrecarga de recuperação de dados e acelerando assim a execução.

Com a otimização da cache e configurações de hardware suficientes, a opBNB conseguiu efetivamente levar o desempenho da camada de execução do seu nó para perto do limite do EVM, processando até 100 milhões de gases por segundo. Estes 100 milhões de gás são essencialmente o limite máximo de desempenho da EVM não modificada, tal como demonstrado pelos dados de testes experimentais de uma cadeia pública proeminente.

Resumindo, o opBNB pode processar até 4761 transferências simples por segundo, 15003000 transferências de tokens ERC20 por segundo e aproximadamente 5001000 operações SWAP por segundo com base em dados de transação observados em exploradores de cadeias de blocos. Comparando os parâmetros actuais, o limite de TPS da opBNB é 40 vezes superior ao da Ethereum, mais de 2 vezes superior ao da BNB Chain e mais de 6 vezes superior ao da Optimism.

Naturalmente, para as soluções Ethereum Layer2, devido às graves limitações da própria camada DA, o desempenho é significativamente descontado com base no desempenho da camada de execução, quando se consideram factores como o tempo de geração de blocos da camada DA e a estabilidade.

Para a cadeia BNB com uma camada DA de elevado débito como a opBNB, o efeito de duplicação da escala é valioso, especialmente se considerarmos que a cadeia BNB pode acolher vários projectos de escala deste tipo. Pode prever-se que a BNB Chain já incorporou as soluções Layer2 lideradas pela opBNB nos seus planos estratégicos e continuará a integrar mais projectos modulares de cadeias de blocos, incluindo a introdução de provas ZK na opBNB e o fornecimento de camadas DA de elevada disponibilidade com infra-estruturas complementares como a GreenField, numa tentativa de competir ou cooperar com o ecossistema Layer2 da Ethereum.

Na era em que o escalonamento em camadas se tornou a tendência, resta saber se outras cadeias públicas também se apressarão a apoiar os seus próprios projectos Layer2, mas, sem dúvida, a mudança de paradigma para a infraestrutura modular da cadeia de blocos já está a acontecer.

Declaração de exoneração de responsabilidade：

1. Este artigo foi reimpresso de[极客 Web3], Todos os direitos de autor pertencem ao autor original[Faust, 极客web3]. Se houver objecções a esta reimpressão, contacte a equipa da Gate Learn, que tratará prontamente do assunto.
2. Declaração de exoneração de responsabilidade: Os pontos de vista e opiniões expressos neste artigo são da exclusiva responsabilidade do autor e não constituem um conselho de investimento.
3. As traduções do artigo para outras línguas são efectuadas pela equipa Gate Learn. A menos que seja mencionado, é proibido copiar, distribuir ou plagiar os artigos traduzidos.