O caminho da BNB Chain para os grandes blocos

A estrada dos grandes blocos na cadeia do BNB

Assim como Solana, Heco e outras cadeias públicas apoiadas por bolsas, a cadeia pública BNB Chain, BNB Smart Chain (BSC), há muito tempo busca alto desempenho. Desde seu lançamento em 2020, a BSC definiu 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 esses parâmetros, a BSC atingiu um TPS máximo (TPS com várias transações misturadas) de mais de 100. Em junho de 2021, o limite de gás de bloco do 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 os volumes de transações diárias ultrapassassem 8 milhões e resultando em taxas altíssimas. Descobriu-se que o gargalo de eficiência do BSC ainda era bastante óbvio naquela época.

(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 permaneceu estável em torno de 80-85 milhões por um longo tempo. Em setembro de 2022, o limite de gás por bloco da BSC Chain 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 havia planejado aumentar o limite de capacidade de gás do bloco para 300 milhões, mas talvez considerando a carga pesada sobre os nós do Validador, a proposta para esses blocos supergrandes não foi implementada.

Fonte: YCHARTS

Mais tarde, a BNB Chain pareceu se concentrar mais na trilha modular/camada 2 em vez de persistir na expansão da camada 1. Essa intenção ficou cada vez mais evidente desde o lançamento do zkBNB, no segundo semestre do ano passado, até o GreenField, no início deste ano. Devido a um grande interesse em blockchain modular/Camada2, o autor deste artigo usará o opBNB como objeto de pesquisa para revelar os gargalos de desempenho do Rollup, comparando-o com o Ethereum Layer2.

O impulso da alta taxa de transferência do BSC para a camada DA do opBNB

Como todos sabemos, a Celestia resumiu quatro componentes principais de acordo com o fluxo de trabalho do blockchain modular: Camada de execução: Executa o código do contrato e conclui 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 transações. Camada de disponibilidade de dados (DA): Publica dados relacionados ao livro-razão do blockchain, permitindo que os validadores façam o download desses 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 transações em blocos L2. Quando os nós completos L2 obtêm dados DA, eles sabem a ordem de cada transação nesse lote. (Por esse motivo, a comunidade Ethereum acredita que a camada DA e a camada de consenso estão relacionadas ao estratificar o Rollup).

No entanto, para a Ethereum Layer2, a taxa de transferência de dados da camada DA (Ethereum) se tornou o maior gargalo que restringe o desempenho do Rollup. Isso ocorre porque a atual taxa de transferência de dados do Ethereum é muito baixa, forçando o Rollup a suprimir seu TPS o máximo 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 fique em um estado pendente, levando as taxas de gás a níveis extremamente altos e aumentando ainda mais o custo da publicação de dados para a Layer2. Por fim, muitas redes Layer2 precisam adotar camadas DA fora da Ethereum, como a Celestia, e a opBNB, que está perto da água, optou por usar diretamente o alto rendimento do BSC para implementar a DA e resolver o problema de gargalo da publicação de dados. Para facilitar a compreensão, vamos apresentar 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 transações para o contrato especificado. Nos parâmetros de entrada calldata dessa instrução, os dados de transação empacotados são gravados e os eventos on-chain correspondentes são acionados, deixando um registro permanente nos logs do contrato.

Dessa forma, os dados de transação da Layer2 são armazenados em blocos Ethereum por um longo período. As pessoas capazes de executar nós L2 podem baixar os registros correspondentes e analisar os dados correspondentes, mas os nós Ethereum em si não executam essas transações L2. É fácil ver que o L2 armazena apenas dados de transações em blocos Ethereum, incorrendo em custos de armazenamento, enquanto os custos computacionais da execução de transações são suportados pelos próprios nós L2. O método de implementação do DA da Arbitrum é o mencionado acima, enquanto o Optimism usa um endereço EOA controlado pelo sequenciador para transferir para outro endereço EOA especificado, carregando um novo lote de dados de transação da Camada 2 nos dados adicionais. Quanto ao opBNB, que usa o OP Stack, seu método de publicação de dados DA é basicamente o mesmo do Optimism.

É óbvio que a taxa de transferência da camada DA limitará o tamanho dos dados que o Rollup pode publicar em uma unidade de tempo, limitando assim o TPS. Considerando que, após o EIP1559, a capacidade de gás de cada bloco ETH se 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, de modo que a Ethereum pode lidar com um tamanho máximo de calldata de apenas 150 KB por segundo. Por outro lado, o tamanho médio máximo de calldata do BSC processado por segundo é de cerca de 2910 KB, o que é 18,6 vezes maior que o do Ethereum. A diferença entre os dois como camadas DA é óbvia.

Em resumo, a Ethereum pode transportar cerca de 150 KB de dados de transações L2 por segundo. Mesmo após o lançamento do EIP 4844, esse número não mudará muito, apenas reduzindo a taxa DA. Então, quantos dados de transações podem ser incluídos em cerca de 150 KB por segundo? Aqui precisamos explicar a taxa de compactaçã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 compactada para 12 bytes pelo Optimistic Rollup, as transferências ERC-20 podem ser compactadas para 16 bytes e as transações Swap no Uniswap podem ser compactadas para 14 bytes. De acordo com sua estimativa, a Ethereum pode registrar cerca de 10.000 transações L2 por segundo (com vários tipos misturados). No entanto, de acordo com os dados divulgados pela equipe do Optimism em 2022, a taxa real de compactação de dados pode atingir um máximo de apenas cerca de 37%, o que é 3,5 vezes menor do que a estimativa de Vitalik.

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

(Taxas de compactação reais obtidas por vários algoritmos de compactação divulgados pelo Optimism)

Portanto, vamos dar um número razoável: mesmo que a Ethereum atinja seu limite de throughput, o TPS máximo de todos os Optimistic Rollups combinados é de apenas um pouco mais de 2000. Em outras palavras, se os blocos de Ethereum fossem inteiramente usados para transportar os dados publicados pelos Rollups otimistas, como os distribuídos entre Arbitrum, Optimism, Base e Boba, o TPS combinado desses Rollups otimistas não chegaria nem a 3.000, mesmo com os algoritmos de compactação mais eficientes. Além disso, devemos considerar que, após o EIP1559, a capacidade de gás de cada bloco é, em média, de apenas 50% do valor máximo, de modo que o número acima deve ser reduzido à 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 mudará muito (já que uma mudança muito grande afetaria a segurança da cadeia principal do ETH), de modo que o valor estimado acima não progredirá muito.

De acordo com dados da Arbiscan e da Etherscan, um lote de transações na Arbitrum contém 1115 transações, consumindo 1,81 milhão de gás na Ethereum. Por extrapolação, se a camada DA for preenchida em cada bloco, 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 transações em cada bloco do Ethereum, portanto, os números acima são apenas teóricos no momento. Além disso, com a adoção generalizada de carteiras inteligentes relacionadas à EIP 4337, o problema de DA se tornará ainda mais grave. Porque, com o suporte ao EIP 4337, a forma como os usuários verificam sua identidade pode ser personalizada, como o upload de dados binários de impressões digitais ou íris, o que aumentará ainda mais o tamanho dos dados ocupados por transações regulares. Portanto, a baixa taxa de transferência de dados da Ethereum é o maior gargalo que limita a eficiência do Rollup, e esse problema pode não ser resolvido adequadamente por um longo 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 maior que o da Ethereum. Em 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 chegar a aproximadamente 18 vezes o da ARB ou OP. Esse número é calculado com base na capacidade máxima de gás de bloqueio da cadeia BNB atual de 140 milhões, com um tempo de bloqueio de 3 segundos.

Em outras palavras, o limite atual de TPS agregado de todos os Rollups no ecossistema da BNB Chain é 18,6 vezes maior que o da Ethereum (mesmo considerando o ZKRollup). A partir dessa perspectiva, é fácil entender por que tantos projetos da Layer2 usam a camada DA sob a cadeia Ethereum para publicar dados, pois a diferença é bastante evidente. No entanto, a questão não é tão simples. Além do problema da taxa de transferência de dados, a estabilidade da própria Camada 1 também pode afetar a Camada 2. Por exemplo, a maioria dos Rollups costuma esperar vários minutos antes de publicar um lote de transações na Ethereum, considerando a possibilidade de reorganização do bloco Layer1. Se um bloco da Camada 1 for reorganizado, isso afetará o livro-razão do blockchain da Camada 2. Portanto, o sequenciador aguardará a publicação de vários novos blocos da Camada 1 após cada liberação de um lote de transação L2, reduzindo significativamente a probabilidade de reversão do bloco, antes de publicar o próximo lote de transação L2. Na verdade, isso atrasa o momento em que os blocos L2 são finalmente confirmados, reduzindo a velocidade de confirmação de grandes transações (grandes transações exigem resultados irreversíveis para garantir a segurança). Em resumo, as transações que ocorrem em L2 só se tornam irreversíveis após serem publicadas nos blocos da camada DA e após a camada DA ter gerado um determinado número de novos blocos. Esse é um motivo importante que limita o desempenho do Rollup. No entanto, o Ethereum tem uma velocidade lenta de geração de blocos, levando 12 segundos para produzir um bloco. Supondo que o Rollup publique um lote de transações L2 a cada 15 blocos, haverá um intervalo de 3 minutos entre os diferentes lotes e, depois que cada lote for publicado, ele ainda precisará aguardar a geração de vários blocos da Camada 1 antes de se tornar irreversível (supondo que eles não sejam contestados). Obviamente, o tempo entre o início e a irreversibilidade das transações na Layer2 da Ethereum é bastante longo, resultando em uma velocidade de liquidação lenta; enquanto a BNB Chain leva apenas 3 segundos para produzir um bloco, e os blocos se tornam irreversíveis em apenas 45 segundos (o tempo necessário para produzir 15 novos blocos). Com base nos parâmetros atuais, assumindo o mesmo número de transações L2 e considerando a irreversibilidade dos blocos L1, o número de vezes que a opBNB pode publicar dados de transações em uma unidade de tempo pode chegar a 8,53 vezes o da Arbitrum (uma vez a cada 45 segundos para a primeira e uma vez a cada 6,4 minutos para a segunda). Claramente, a velocidade de liquidação de grandes transações na opBNB é muito mais rápida do que na Layer2 da Ethereum. Além disso, o tamanho máximo dos dados publicados pela opBNB a cada vez pode chegar a 4,66 vezes o 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. Isso representa a diferença entre o opBNB e o Arbitrum em termos de limite de TPS na implementação prática (atualmente, por motivos de segurança, o ARB parece reduzir ativamente o TPS, mas, teoricamente, se o TPS fosse aumentado, ele ainda seria muitas vezes menor em comparação com o opBNB).

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

(O sequenciador da opBNB publica um lote de transações a cada 1-2 minutos, sendo que a mais rápida leva apenas 45 segundos). Obviamente, há outra questão crucial a ser considerada, que são as taxas de gás na camada DA. Cada vez que o L2 publica um lote de transação, há um custo fixo de 21.000 gases não relacionado ao tamanho dos dados de chamada, que é uma despesa. Se as taxas de gás para a camada DA/L1 forem altas, fazendo com que o custo fixo de publicação de um lote de transações em L2 permaneça alto, o sequenciador reduzirá a frequência de publicação de lotes de transações. Além disso, ao considerar os componentes das taxas L2, o custo da camada de execução é muito baixo e, muitas vezes, pode ser ignorado, concentrando-se apenas no impacto dos custos de DA sobre as taxas 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 maior do que o da BNB Chain. Traduzidas em taxas de transação L2, as atuais taxas de transação do usuário no Ethereum Layer2 também são cerca de 10 a dezenas de vezes mais altas do que as 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 Optimism custa US$ 0,21)

(Uma transação que consome 130.000 gases no opBNB custa US$ 0,004). No entanto, o aumento da taxa de transferência de dados da camada DA, embora possa melhorar a taxa de transferência geral do sistema da Camada 2, ainda tem um impacto limitado na melhoria do desempenho de Rollups individuais. Isso ocorre porque a camada de execução geralmente não processa as transações com rapidez suficiente. Mesmo que as limitações da camada DA possam ser ignoradas, a camada de execução se torna o próximo gargalo que afeta o desempenho do Rollup. Se a velocidade de execução da camada de execução Layer2 for lenta, o excesso de demanda de transações se espalhará para outras Layer2s, causando, por fim, a fragmentação da liquidez. Portanto, melhorar o desempenho da camada de execução também é fundamental, servindo como outro limite acima da camada DA.

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

Quando a maioria das pessoas discute os gargalos de desempenho das camadas de execução de blockchain, elas inevitavelmente mencionam dois gargalos importantes: a execução em série de thread único do EVM, que não utiliza totalmente a CPU, e a pesquisa de dados ineficiente da Merkle Patricia Trie adotada pela Ethereum. Em essência, as estratégias de dimensionamento para a camada de execução giram em torno do uso mais eficiente dos recursos da CPU e da garantia de que a CPU possa acessar os dados o mais rápido possível.

As soluções de otimização para execução de EVM em série e Merkle Patricia Trie são geralmente complexas e difíceis de implementar, enquanto os esforços mais econômicos tendem a se concentrar na otimização do cache. Na verdade, a otimização do cache nos leva de volta a pontos frequentemente discutidos na Web2 tradicional e até mesmo em contextos de livros didáticos.

Normalmente, a velocidade com 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 busca de dados na memória pode levar apenas 0,1 segundo, enquanto a busca no disco pode levar 10 segundos. Portanto, a redução da sobrecarga gerada pelas leituras e gravações em disco, ou seja, a otimização do cache, torna-se um aspecto essencial da otimização da camada de execução da blockchain.

Na Ethereum e na maioria das outras cadeias públicas, o banco de dados que registra os estados de endereço na cadeia é armazenado inteiramente em disco, enquanto a chamada World State trie é meramente um índice desse banco de dados ou um diretório usado para pesquisa de dados. Toda vez que o EVM executa um contrato, ele precisa acessar os estados de endereço relevantes. A busca de dados do banco de dados baseado em disco, um a um, tornaria a execução da transação significativamente mais lenta. Portanto, a configuração de um cache fora do banco de dados/disco é um meio necessário para aumentar a velocidade.

O opBNB adota diretamente a solução de otimização de cache usada pelo BNB Chain. De acordo com as informações divulgadas pelo parceiro da opBNB, NodeReal, a cadeia mais antiga do BSC estabeleceu três camadas de cache entre o EVM e o banco de dados LevelDB que armazena o estado. O conceito de design é semelhante ao dos caches tradicionais de três níveis, em que os dados com maior frequência de acesso são armazenados no cache. Isso permite que a CPU procure primeiro os dados necessários no cache. Se a taxa de acerto do cache for alta o suficiente, a CPU não precisará depender excessivamente do disco para buscar dados, o que resultará em uma melhoria significativa na velocidade geral de execução.

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. Esse recurso é chamado de "pré-carregamento de estado".

O princípio do pré-carregamento de estado é simples: as CPUs dos nós de blockchain são de vários núcleos, enquanto o EVM opera em um modo de execução serial de thread único, utilizando apenas um núcleo de CPU, deixando os outros núcleos de CPU subutilizados. Para resolver isso, os núcleos de CPU que não são usados pelo EVM podem ajudar nas tarefas prevendo os dados que o EVM precisará da sequência de transações que ainda não foi processada. Esses núcleos de CPU fora do EVM recuperarão os dados de que o EVM precisará do banco de dados, ajudando o EVM a reduzir a sobrecarga de recuperação de dados e, assim, acelerando a execução.

Com a otimização do cache e configurações de hardware suficientes, a opBNB efetivamente levou o desempenho da camada de execução de seu nó para perto do limite do EVM, processando até 100 milhões de gases por segundo. Esse gás de 100 milhões é essencialmente o limite de desempenho do EVM não modificado, conforme demonstrado por dados de testes experimentais de uma importante cadeia pública.

Em resumo, 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ções observados em exploradores de blockchain. Comparando os parâmetros atuais, o limite de TPS da opBNB é 40 vezes maior que o da Ethereum, mais de 2 vezes maior que o da BNB Chain e mais de 6 vezes maior que o da Optimism.

Obviamente, 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, ao considerar fatores como o tempo de geração e a estabilidade do bloco da camada DA.

Para a BNB Chain com uma camada DA de alto rendimento, como a opBNB, o efeito de duplicação do dimensionamento é valioso, especialmente considerando que a BNB Chain pode hospedar vários desses projetos de dimensionamento. Pode-se prever que a BNB Chain já incorporou as soluções Layer2 lideradas pela opBNB em seus planos estratégicos e continuará a integrar mais projetos modulares de blockchain, incluindo a introdução de provas ZK na opBNB e o fornecimento de camadas DA de alta disponibilidade com infraestrutura complementar, como a GreenField, em uma tentativa de competir ou cooperar com o ecossistema Layer2 da Ethereum.

Na era em que o escalonamento em camadas se tornou a tendência, ainda não se sabe se outras cadeias públicas também se apressarão em apoiar seus próprios projetos Layer2, mas, sem dúvida, a mudança de paradigma em direção à infraestrutura modular de blockchain já está acontecendo.

Isenção de responsabilidade：

1. Este artigo foi reimpresso de[极客 Web3], Todos os direitos autorais pertencem ao autor original[Faust, 极客web3]. Se houver alguma objeção a essa reimpressão, entre em contato com a equipe do Gate Learn, que tratará do assunto imediatamente.
2. Isenção de responsabilidade: Os pontos de vista e opiniões expressos neste artigo são de responsabilidade exclusiva do autor e não constituem consultoria de investimento.
3. As traduções do artigo para outros idiomas são feitas pela equipe do Gate Learn. A menos que mencionado, é proibido copiar, distribuir ou plagiar os artigos traduzidos.