Os três atributos principais da blockchain são descentralização, segurança e escalabilidade. Segundo a teoria do trilema da blockchain, uma arquitetura de blockchain só pode implementar dois desses atributos. O Ethereum foi projetado com descentralização e segurança em mente e, portanto, tem um desempenho fraco em termos de escalabilidade. Atualmente, o Ethereum processa mais de 1 milhão de transações por dia, o que pode levar a taxas de transação elevadas e aumenta a necessidade de soluções de escalonamento do Ethereum.

Existem várias tipos diferentes de soluções de escalonamento do Ethereum, cada uma com seus próprios compromissos e modelos de segurança, incluindo shardagem na Camada 1, canais de estado na Camada 2, Plasma, sidechains, Rollups e Validium. Como a tecnologia de shardagem é lenta para evoluir e complexa de implementar, e as sidechains e o Validium não podem herdar segurança e disponibilidade de dados do Ethereum. Em resumo, o ecossistema Ethereum agora principalmente utiliza a solução de escalonamento Rollups.

Até agora, a Beosin tornou-se parceira de segurança da camada ETH Layer2, como a Manta Netowork e a StarkNet. Na auditoria anterior, várias blockchains conhecidas passaram pela auditoria de segurança da Beosin, incluindo Ronin Network, Manta Network, Merlin Chain, Clover, Self Chain, Crust Network, etc. A Beosin agora lança uma solução de auditoria para ETH Layer2 para fornecer serviços abrangentes de auditoria de segurança para o ecossistema ETH Layer2.

A camada 2 do ETH usa Rollups para agrupar centenas de transações em uma única submissão para a rede principal do Ethereum, assim as taxas de transação serão divididas entre todos os usuários de Rollup, reduzindo as taxas por usuário. Os dados da transação nos Rollups são enviados para a Camada 1, mas as execuções são realizadas de forma independente pelos Rollups. Ao enviar os dados da transação para a Camada 1, os Rollups podem herdar a segurança do Ethereum, pois uma vez que os dados são enviados para a Camada 1, reverter as transações dos Rollups requer que os dados sejam revertidos na Camada 1.

Atualmente, os Rollups podem ser implementados de duas maneiras principais:

Rollups otimistas: Usar incentivos econômicos e teoria dos jogos para verificar transações, como Arbitrum, Base, OP, Blast, etc.

Rollups de Conhecimento Zero: Use provas de conhecimento zero para segurança e privacidade, como Scroll, Linea, zkSync, StarkNet, etc.

Rollups Otimistas

Introdução

Optimistic Rollups é uma forma de escalonar a Ethereum, movendo a computação e o armazenamento do estado fora da cadeia. Ele executa transações fora da cadeia, mas publica os dados da transação na mainnet como calldata ou blob.

O Optimistic Rollups implementa um smart contract no Ethereum, chamado contrato Rollup, que gerencia o status do Rollup, rastreia os saldos dos usuários e lida com depósitos, saques e resolução de disputas. As transações são coletadas e resumidas off-chain por um sequenciador, e várias transações são agrupadas em um bloco Rollup que contém um resumo e uma prova criptográfica do novo estado da conta (raiz Merkle). O sequenciador, então, confirma o bloco Rollup na cadeia principal fornecendo raízes Merkle e calldata.

As Rollups Otimistas são considerados "otimistas" porque assumem que as transações off-chain são válidas e não publicam provas da validade dos lotes de transações enviados on-chain. Por outro lado, os Rollups Otimistas dependem de esquemas de prova de fraude para detectar casos em que as transações são calculadas incorretamente. Após enviar um lote de Rollup no Ethereum, há um período de tempo (chamado de período de desafio) durante o qual qualquer pessoa pode contestar os resultados de uma transação Rollup calculando uma prova de fraude. A prova de fraude contém detalhes de uma transação específica que o verificador acredita ser fraudulenta.

Como mostrado na figura abaixo, o período de desafio da maioria dos Optimistic Rollups no momento é de 7 dias, e o menor é de 1 dia.

Durante o período de desafio, qualquer pessoa pode desafiar os resultados da transação calculando a prova de fraude. Se a transação for inválida, o bloco Rollup é revogado, o desafiante é recompensado e o sequenciador é punido.

Se o lote Rollup permanecer sem desafio após o período de desafio (ou seja, todas as transações forem executadas corretamente), ele é considerado válido e aceito no Ethereum. Outros podem continuar a expandir blocos Rollup não confirmados, mas observe que os resultados da transação serão revertidos se a transação for executada com base em um erro previamente publicado.

Finalmente, o utilizador deve submeter um pedido de levantamento ao contrato Rollup para retirar fundos da Camada 2 para a Camada 1. O contrato verificará se o utilizador tem fundos suficientes no Rollup e atualizará o seu saldo na mainchain em conformidade.

Redes Líderes de Camada 2

1. Arbitrum

Com a construção e distribuições ecológicas, Arbitrum rapidamente se tornou a rede mais ativa na ETH Layer2, com TVL superando os $2.7 bilhões. Após a grande distribuição, a equipe Arbitrum lançou o programa Arbitrum Orbit: incentivando os desenvolvedores a construir a Layer3 usando as tecnologias relacionadas ao Arbitrum. A Beosin concluiu a auditoria de segurança do ArbSwap, Arbipad para ajudar o desenvolvimento de segurança do ecossistema Arbitrum.

1. Optimismo

Embora o Optimism seja menos ecologicamente ativo do que o Arbitrum, o OP Stack, lançado pelo Optimism em 2023, tem recebido reconhecimento generalizado da indústria como uma solução completa e viável para a construção de camada 2 modular. Mais de 25 redes de camada 2 foram construídas usando o OP Stack, incluindo projetos de destaque como Base, Mantle, Manta, OP BNB e Celo. DIPX Finance e Starnet construídos no Optimism passaram pela auditoria de segurança da Beosin.

1. Base

Base é uma rede Layer2 baseada em OP Stack, que é a segunda apenas para Arbitrum em termos de atividade e TVL ecológica. Anteriormente, a Beosin analisou detalhadamente a arquitetura e os riscos de segurança do Base e auditou o Surf Protocol e o EDA para ajudar os proprietários e usuários do projeto a evitar riscos de segurança.

1. Explosão

No final de sua competição de desenvolvedores "Big Bang", a Blast viu seu TVL disparar para mais de $2 bilhões, assumindo seu lugar no circuito Layer2. A Beosin analisou a segurança de rede da Blast antes do lançamento de sua mainnet. Como a Blast não implementa prova de fraude, os ativos são mantidos em uma carteira de múltiplas assinaturas, e não em uma ponte Rollup, o que tem um alto grau de risco de centralização. A Beosin auditou vários projetos ecológicos da Blast, como o Protocolo Wand, Zest, Kalax.

Análise de Arquitetura

OP Stack, uma estrutura madura para Optimistic Rollups, basicamente divide o processo complexo de construir cadeias de Rollups otimistas em um processo simplificado, fornecendo um conjunto completo de componentes de software, ferramentas e frameworks. Aqui, tomamos a estrutura Op Stack como exemplo para analisar a arquitetura típica dos Optimism Rollups.

● Nó de execução: Op-geth é um cliente de execução estendido para Ethereum que lida com funções específicas da Layer2, como receber depósitos de tokens da Layer1. Essa camada define todas as funções responsáveis por realizar variações de estado. Aqui, as transições de estado são acionadas com base nas entradas recebidas dos nós de resumo (sequências e validadores) por meio da API do mecanismo.

● Nó Rollup: inclui sequenciador e validador. O coletor é responsável por agrupar as transações processadas da camada 2 e publicá-las na Camada 1. O sequenciador define como as transações na cadeia Layer2 são coletadas e publicadas. O validador/validador verifica a validade da transação em lote e submete evidências se for detetada alguma fraude.

● Prova de Fraude: Cannon é uma versão atualizada do Geth e é responsável por executar o EVM durante a detecção de fraude e fase de prova. É essencialmente um mecanismo de disputa on-chain que coordena com sequentiers e validadores via APIs para provar transações falsas.

● Commit em lote: os Sequenciadores processam em lote todas as transações processadas de uma vez, verificadas pelos verificadores, e os Sequenciadores enviam as transações processadas em lote para a Layer1.

● Contratos de ponte: Implementados no Ethereum e Layer2, permitindo que os usuários passem mensagens e transfiram ativos entre Layer1 e Layer2.

Na arquitetura técnica do Optimistic Rollup, é essencial garantir a segurança dos ativos dos usuários à medida que se deslocam entre L1 e L2. Os detalhes a seguir explicam como os usuários podem acessar ativos entre as duas camadas e como o sistema mantém a integridade e a segurança dessas transações.

● Transferência de ativos para Rollup: os usuários depositam fundos no contrato de ponte de cadeia da Rollup na camada 1. O contrato de ponte de cadeia transmite a transação para a camada 2, onde uma quantidade igual de ativos é criada e enviada para um endereço selecionado pelo usuário na Rollup Otimista.

As transações geradas pelo usuário, como depósitos da Camada 1 para a Camada 2, geralmente são colocadas em fila até que o sequestrador as reenvie para o contrato Rollup. No entanto, para manter a resistência à censura, o Optimistic Rollup permite que os usuários enviem transações diretamente para contratos Rollup on-chain se os atrasos das transações excederem o tempo máximo permitido.

● Levantamento de ativos do Rollup: Devido ao mecanismo de prova de fraude, retirar dinheiro do Optimistic Rollup para o Ethereum é mais complicado. Se um utilizador iniciar uma transação de Camada 2 para Camada 1 para retirar fundos geridos na Camada 1, eles precisam esperar pelo fim do período de desafio, que normalmente dura cerca de 7 dias.

Quando o usuário inicia uma solicitação de saque no Rollup, a transação é incluída no próximo lote e os ativos do usuário no Rollup são destruídos. Uma vez que o lote é publicado no Ethereum, os usuários podem calcular uma prova de Merkle para verificar se sua transação de saída está incluída no bloco. O próximo passo é aguardar o término do período de atraso para concluir a transação na Camada 1 e sacar os fundos para a mainnet.

Para evitar esperar uma semana antes de retirar dinheiro do Ethereum, os usuários do Optimistic Rollup podem solicitar um adiantamento de um provedor de liquidez (LP), que assume a propriedade de retiradas pendentes e paga os fundos do usuário na Camada1 em troca de uma taxa. Os provedores de liquidez podem verificar a validade das solicitações de retirada do usuário verificando os dados on-chain eles mesmos antes de liberar os fundos. Dessa forma, eles podem garantir que a transação será eventualmente confirmada, alcançando a certeza da confiança.

Itens de Auditoria

Layer2 é um sistema blockchain completo, portanto, a auditoria comum das cadeias públicas também se aplica ao Optimistic Rollup, conforme detalhado no apêndice no final deste artigo.

Além disso, devido à sua natureza especial, o Optimistic Rollup requer uma série de auditorias adicionais:

● Prova de disponibilidade de dados: Garantir que os dados de transação da Camada 2 estejam disponíveis na Camada 1 para evitar perda de dados.

● Mecanismo de sincronização de dados: Verificar se o mecanismo de sincronização de dados entre a Camada 1 e a Camada 2 está sólido e pode lidar com situações anormais, como a divisão de rede.

● Contrato à Prova de Fraude: Verifique se o contrato à prova de fraude está implementado corretamente.

● Mecanismo do período de desafio: Verificar se o comprimento do período de desafio é razoável e se a prova de fraude pode ser concluída dentro do tempo especificado.

● Processo de submissão de prova de fraude: Verifique se o processo de submissão de prova de fraude é seguro.

● Processo de depósito e retirada: Verifique o processo de depósito e retirada da Camada 1 para a Camada 2 e da Camada 2 para a Camada 1 para garantir que o processo seja seguro.

● Emissão e queima de ativos: Verifique a lógica de cunhagem e destruição do ativo na Camada 2 para garantir a correspondência correta com o ativo da Camada 1.

● Mecanismo de provedor de liquidez: Se houver um mecanismo de provedor de liquidez (LP), é necessário examinar o processo operacional do LP e sua segurança.

Rollups de Conhecimento Zero

Introdução

Zero-Knowledge (ZK) Rollup é uma camada 2 baseada em prova de conhecimento zero. Principalmente realiza cálculos complexos e geração de provas off-chain, verifica provas on-chain e armazena parte dos dados para garantir a disponibilidade dos dados.

ZK Rollup é uma “solução de escalonamento” híbrida que é um protocolo off-chain que funciona independentemente, mas obtém segurança do Ethereum. Especificamente, a rede Ethereum faz cumprir a validade das atualizações de status sobre os ZK Rollups e garante a disponibilidade dos dados em segundo plano cada vez que o status do Rollup é atualizado. O estado do Rollup é mantido por contratos inteligentes implantados na rede Ethereum. Para atualizar este estado, o nó ZK Rollups deve enviar uma prova de validade para verificação. Uma prova de validade é uma garantia criptográfica de que uma mudança proposta no estado é de fato o resultado da execução de um determinado lote de transações. Isso significa que os ZK Rollups apenas precisam fornecer prova de validade para finalizar transações no Ethereum, sem ter que publicar todos os dados da transação.

Não há atraso na transferência de fundos dos ZK Rollups para o Ethereum, uma vez que a transação de saída é executada assim que o contrato ZK Rollups verifica a prova de validade. Em contraste, retirar fundos dos Optimistic Rollups cria atrasos porque qualquer pessoa pode usar uma prova de fraude para desafiar uma transação de saída.

Principais redes Layer2

1. zkSync

zkSync, uma solução L2 lançada há cinco anos pela equipa da Matter Labs, utiliza a tecnologia de prova de conhecimento zero para permitir a verificação eficiente de transações e angariou mais de $200 milhões. zkSync é uma das redes de Camada2 mais ecologicamente ativas que utiliza ZK Rollups, e zkSync também é controverso. Beosin conduziu anteriormente uma auditoria do seu principal projeto DeFi, SyncSwap, abrangendo a qualidade do código, lógica do contrato e segurança, modelo operacional e muito mais.

1. StarkNet

A StarkNet utiliza o ZK-STARK para construir a Layer2, aumentando a velocidade das transações e reduzindo as taxas das mesmas. A StarkNet possui uma máquina virtual nativa (Cairo VM) e uma linguagem de desenvolvimento chamada Cairo para ajudar os desenvolvedores a escrever contratos inteligentes de forma mais segura e fácil. A Beosin tornou-se um parceiro oficial de segurança da StarkNet, completando auditorias de segurança para a Option Dance e a Reddio. Em 13 de agosto de 2024, a Reddio encerrou uma rodada de financiamento semente liderada pela Paradigm para construir uma rede EVM Layer2 paralela de alto desempenho.

1. Scroll

Scroll é escalado pela tecnologia de prova de conhecimento zero, e o hardware acelera a geração e verificação de provas de conhecimento zero, com o objetivo de alcançar compatibilidade de nível de bytecode EVM. Isso significa que os desenvolvedores podem usar diretamente Solidity e ferramentas de desenvolvimento relacionadas ao Ethereum para construir contratos inteligentes.

Análise de Arquitetura

Os frameworks comuns para ZK Rollups incluem contratos Rollup e Bridge, coletores, agregadores, Repeaters e redes Roller que geram provas de conhecimento zero. A arquitetura específica é mostrada na figura seguinte:

● Contrato Rollup e contrato Bridge:

O contrato Rollup é responsável por fornecer disponibilidade de dados para transações Rollup, verificar a prova de validade zkEVM e permitir que os utilizadores transfiram ativos entre Ethereum e Rollup. Recebe a raiz do estado da Camada 2 e o bloco do compilador, a raiz do estado é armazenada no estado do Ethereum, e os dados do bloco da camada 2 são salvos como os dados de chamada do Ethereum.

Os contratos de ponte são implantados no Ethereum e na Layer2, permitindo que os usuários passem mensagens e transfiram ativos entre a Layer1 e a Layer2.

● Sequenciador: O sequenciador fornece a interface JSON-RPC e aceita transações Layer2, recupera periodicamente um lote de transações da memória para execução, gerando novos blocos Layer2 e raízes de estado. Sua implementação geralmente é baseada no Go-Ethereum (Geth), garantindo a melhor compatibilidade e segurança máxima.

● Coordenador: O coordenador é notificado quando o collator gera um novo bloco e recebe uma sequência de execução desse bloco do collator. A sequência de execução é então enviada para um Roller selecionado aleatoriamente na rede Roller, que gera uma prova de validade.

● Relayer: O repetidor monitoriza os contratos Rollup e os contratos de ponte implantados no Ethereum e Layer2. As principais responsabilidades são: 1) Rastrear a disponibilidade de dados e a validação de blocos Layer2 monitorando os contratos Rollup; 2) Monitorar os eventos de depósito e saque do Ethereum e Layer2 na interação da ponte e transmitir mensagens para o outro lado.

● Rede de rolos: O rolo na rede de rolos atua como provador e é responsável por gerar provas de validade para o ZK Rollup. Um rastreamento de execução de bloco é primeiro recebido do coordenador, convertido em uma testemunha de circuito, em seguida, uma prova é gerada para cada zkevm usando aceleração de hardware e, finalmente, uma agregação de prova é usada para aggreGate várias provas em uma única prova.

Sob a arquitetura técnica dos ZK Rollups, é essencial garantir a segurança dos ativos do usuário durante a transferência entre L1 e L2. Os seguintes detalhes explicam como os usuários podem acessar os ativos entre as duas camadas e como o sistema mantém a integridade e a segurança dessas transações.

● Transferência de ativos para Rollup: Os utilizadores entram no Rollup ao depositar tokens num contrato ZK Rollups implementado numa camada da cadeia de rede. Esta transação precisa de ser submetida ao contrato Rollup pelo lado do projeto.

Se a fila de depósitos pendentes começar a encher, o operador ZK Rollups aceitará essas transações de depósito e as enviará para o contrato Rollup. Uma vez que os fundos forem depositados no Rollup, o usuário poderá começar o processamento de transações.

Os usuários podem verificar o saldo no Rollup fazendo hash em sua conta, enviando o valor de hash para o contrato de Rollup e fornecendo uma prova Merkle que verifica em relação à raiz do estado atual.

● Retirada de ativos do Rollup: O usuário inicia uma transação de saída, enviando os ativos em seu Rollup para a conta especificada para destruição. Se o operador adicionar a transação ao lote seguinte, o usuário pode enviar uma solicitação de retirada para o contrato on-chain. Os pedidos de levantamento incluem:

1. Prova de Merkle, que prova que a transação do usuário é adicionada à conta destruída no lote de transações

2. Dados de transação

3. Agrupe a raiz

4. Endereço da rede Layer1 para receber fundos depositados

O contrato Rollup faz hash dos dados da transação, verifica se a raiz do lote existe e usa prova de Merkle para verificar se o hash da transação faz parte da raiz do lote. O contrato executa a transação de saída e envia fundos para um endereço na rede Layer1 selecionado pelo usuário.

Itens de auditoria

A camada 2 é um sistema blockchain completo, portanto, itens de auditoria comuns para blockchains também se aplicam ao ZK Rollup, conforme detalhado no apêndice no final deste artigo.

Além disso, devido à sua natureza especial, o ZK Rollup precisa realizar algumas auditorias adicionais:

● Prova de segurança do sistema: Verificar a segurança e correção dos esquemas de prova de conhecimento zero utilizados (por exemplo, Groth16, Plonk, Halo2, zk-STARK, etc.).

● Segurança do circuito: Verifique possíveis vulnerabilidades no design e implementação do circuito, principalmente incluindo o seguinte:

1. Circuitos sub-dimensionados

2. Circuitos Sobrecarregados

3. Circuitos não determinísticos

4. Sobrecarga/Subfluxo Aritmético Sobrecarga/subfluxo aritmético

5. Comprimentos de bits incompatíveis

6. Entradas públicas não utilizadas otimizadas

7. Frozen Heart: Forja de Provas de Conhecimento Zero

8. Vazamento de Configuração Confiável

9. Atribuído mas não limitado

10. Uso Inseguro de Componentes

11. Precisão Variável

● Geração e validação de provas: Rever o processo de geração e validação de provas para garantir que seja eficiente e seguro.

● Prova de disponibilidade de dados: Garantir que os dados das transações na camada 2 estejam disponíveis na camada 1 para evitar perda de dados.

● Mecanismo de sincronização de dados: Verifique se o mecanismo de sincronização de dados entre Layer1 e Layer2 é sólido e pode lidar com situações anormais, como particionamento de rede.

● Processo de depósito e levantamento: Verifique o processo de depósito e levantamento da camada 1 para a camada 2 e da camada 2 para a camada 1 para garantir que o processo seja seguro.

● Emissão e queima de ativos: Verifique a lógica de cunhagem e destruição do ativo na Camada 2 para garantir a correspondência correta com o ativo da Camada 1.

● Verificação de dependências externas e vulnerabilidades conhecidas: O ZK Rollup geralmente depende fortemente de repositórios criptográficos e matemáticos ou ferramentas de terceiros e deve verificar minuciosamente sua segurança de dependência para varredura e validação de vulnerabilidades conhecidas.

Apêndice

Itens gerais de auditoria de Blockchain e Layer2:

● Transbordamento de inteiro: Verificar transbordamentos de inteiro e subfluxos de inteiro

● Loop: Verifique o loop do programa para ver se a condição é razoável

● Chamada recursiva infinita: Verifique se a condição de saída da chamada recursiva do programa é razoável

● Condição de corrida: Verifica o acesso a recursos compartilhados no estado concorrente

● Exceção de falha: Verifique o código de lançamento de exceção que faz o programa sair ativamente

● Dividir por 0 vulnerabilidade: Verifique se há um caso de dividir por 0

● Conversão de tipo: Verifique se a conversão de tipo está correta e se informações importantes são perdidas durante a conversão

● Array out of bounds: Verificações para acesso a elementos fora dos limites do array

● Vulnerabilidade de deserialização: Verifique problemas durante a deserialização

● Segurança na implementação de funções: Verificar se a implementação das interfaces RPC apresenta riscos de segurança e está de acordo com o design funcional das interfaces RPC

● Se as configurações de permissão da interface RPC sensível são razoáveis: Verifique as configurações de permissão de acesso da interface RPC sensível

● Mecanismo de transmissão criptografada: Verificar se é utilizado um protocolo de transmissão criptografada, como o TLS

● Análise do formato de dados de solicitação: Verifica o processo de análise de formato para dados de solicitação

● Ataque de desbloqueio de carteira: Quando um nó desbloqueia sua carteira, é solicitado pelo RPC para roubar fundos

● Segurança tradicional da Web: Verifique as seguintes vulnerabilidades: Cross-site scripting (XSS)/template injection/third-party component vulnerability/HTTP parameter contamination/SQL injection/XXE entity injection/deserialization vulnerability/SSRF vulnerability/Code injection/local file inclusion/Remote file inclusion/command execution injection e outras vulnerabilidades tradicionais

● Mecanismo de autenticação e identificação de nós da rede: verificar se existe um mecanismo de identificação de identidade de nós, mecanismo de identificação de identidade de nós pode ser contornado

● Contaminação da tabela de roteamento: Verifique se a tabela de roteamento pode ser inserida ou sobrescrita arbitrariamente

● Algoritmo de descoberta de nós: Verifique se o algoritmo de descoberta de nós está equilibrado e imprevisível, por exemplo, o algoritmo de distância está desequilibrado

● Auditoria de utilização da conexão: Verificar se o limite e a gestão do número de nós conectados à rede p2p são razoáveis

● Ataques de Eclipse Solar: Avaliar os custos e perigos dos ataques de eclipse solar, fornecendo análise quantitativa, se necessário

● Ataque Sybil: Avaliação de mecanismos de consenso de votação e análise de estratégias de verificação de elegibilidade para votação

● Ataque de espionagem: verifique se o protocolo de comunicação divulga privacidade

● Ataque alienígena: Avalia se o nó pode reconhecer o mesmo tipo de nó da cadeia

● Sequestro de tempo: Verifique o mecanismo de cálculo do tempo de rede de um nó

● Ataque de exaustão de memória: Verificar o consumo excessivo de memória

● Ataque de exaustão do disco rígido: Verificar onde estão armazenados os arquivos grandes

● ataque de pressão de soquete: Verifique a política de limite sobre o número de conexões

● Ataque de esgotamento de manipulação de kernel: Verifique as limitações na criação de manipulação de kernel, como manipulação de arquivo

● Vazamentos de memória persistentes: Verificar vazamentos de memória

● Segurança do algoritmo de hash: Verificar a resistência à colisão do algoritmo de hash

● Segurança do algoritmo de assinatura digital: Verifique a segurança do algoritmo de assinatura e a implementação do algoritmo

● Segurança do algoritmo de criptografia: Verifique a segurança do algoritmo de criptografia e implementação do algoritmo

● Segurança do gerador de números aleatórios: Verifique se o algoritmo de geração de números aleatórios-chave é razoável

● Segurança da implementação BFT: Avaliar a segurança da implementação de algoritmos BFT

● Regras de seleção de bifurcação: Verifique as regras de seleção de bifurcação para garantir a segurança

● Teste de grau de centralização: Identificar se há um design excessivamente centralizado no design do sistema

● Auditoria de incentivos: Avaliar o impacto dos incentivos na segurança

● Ataques de gastos duplos: verifique se o consenso pode se defender contra ataques de gastos duplos

● Auditoria de Ataque MEV: Examinar o impacto do MEV do nó de pacote de bloco na justiça da cadeia

● Auditoria do processo de sincronização de blocos: verifica se há problemas de segurança durante a sincronização

● Auditoria do processo de análise de formato de bloco: Verifica problemas de segurança durante a análise de formato, como erros de análise que causam falhas

● Auditoria do processo de geração de blocos: Verificar problemas de segurança no processo de geração de blocos, incluindo se a raiz da árvore de Merkle é construída de maneira razoável

● Auditoria do processo de verificação de blocos: Verificar se os itens de assinatura de blocos e a lógica de verificação são suficientes

● Auditoria da lógica de validação do bloco: Verificar se o algoritmo e a implementação de validação do bloco são razoáveis

● Colisão de hash de bloco: Verifique como a colisão de hash de bloco é construída e se a colisão é tratada de forma razoável

● Bloquear limites de recursos de processamento: Verifique se pools de blocos órfãos, computação de verificação, endereçamento de disco rígido e outros limites de recursos são razoáveis

● Auditoria do processo de sincronização de transações: Verifica problemas de segurança no processo de sincronização

● Colisões de hash de transação: Examine como as colisões de hash de transação são construídas e como são tratadas

● Análise de formatação de transações: Verifique problemas de segurança durante a análise de formatação, como erros de análise que causam falhas

● Verificação da validade da transação: Verifique se os itens de assinatura de cada tipo de transação e a lógica de verificação são suficientes

● Limites de recursos de processamento de transações: Verifique se os limites de recursos, como pools de transações, computação de verificação e endereçamento de disco rígido, são razoáveis

● Ataque de maleabilidade de transações: se uma transação pode alterar os campos internos (como ScriptSig) para alterar o hash da transação sem afetar a validade da transação

● Auditoria de ataque de reprodução de transação: Verifica a detecção do sistema de reprodução de transação

● Verificação do código do contrato: Verificar a segurança do processo de verificação do contrato da máquina virtual, como o estouro de inteiro e loops infinitos

● Execução de bytecode do contrato: Verifique a segurança do processo de execução do bytecode da máquina virtual, como overflow de inteiros, loops infinitos, e assim por diante

● Modelo de Gás: Verifique se as taxas para cada operação atômica do processamento da transação/execução do contrato são proporcionais ao consumo de recursos

● Integridade do log: verifique se as principais informações são registradas

● Segurança de registro: Verifique se o manuseio impróprio de registros causa problemas de segurança, como overflow de inteiro

● Os logs contêm informações de privacidade: verifique se os logs contêm informações de privacidade, como chaves

● Armazenamento de logs: Verificar se há conteúdo excessivo registrado nos logs, o que consome recursos do nó

● Código do nó Segurança da cadeia de suprimentos: Verifique todas as bibliotecas, componentes e versões de terceiros de estruturas de cadeia pública para problemas conhecidos

Aviso Legal:

1. Este artigo é reproduzido a partir de [beosin]. Todos os direitos autorais pertencem ao autor original [ beosin]. Se houver objeções a esta reimpressão, contacte o Gate Learnequipa e eles vão tratar disso prontamente.
2. Aviso de responsabilidade: As opiniões expressas neste artigo são exclusivamente do autor e não constituem qualquer conselho de investimento.
3. As traduções do artigo para outros idiomas são feitas pela equipe Gate Learn. A menos que mencionado, copiar, distribuir ou plagiar os artigos traduzidos é proibido.