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

Existem vários tipos diferentes de soluções de dimensionamento do Ethereum, cada um com seus próprios compromissos e modelos de segurança, incluindo sharding de Camada 1, canais de estado de Camada 2, Plasma, sidechains, Rollups e Validium. Porque a tecnologia de sharding é lenta para evoluir e complexa para implementar, e sidechains e Validium não podem herdar segurança e disponibilidade de dados do Ethereum. Em resumo, o ecossistema do Ethereum agora usa principalmente a solução de dimensionamento Rollups.

Até agora, a Beosin se tornou parceira de segurança da ETH Layer2, como Manta Netowork e StarkNet. No passado, várias blockchains conhecidas passaram na 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 a ETH Layer2 para fornecer serviços abrangentes de auditoria de segurança para o ecossistema da ETH Layer2.

A camada 2 da ETH usa Rollups para agrupar centenas de transações em uma submissão para a mainnet do Ethereum, assim as taxas de transação serão divididas entre todos os usuários do Rollup, reduzindo as taxas por usuário. Os dados da transação nos Rollups são submetidos à Camada 1, mas as execuções são realizadas de forma independente pelos Rollups. Ao submeter dados de transação para a Camada 1, os Rollups podem herdar a segurança do Ethereum, pois uma vez que os dados são carregados para a Camada 1, reverter 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: Use incentivos econômicos e teoria dos jogos para verificar transações, como Arbitrum, Base, OP, Blast, etc.

Zero-Knowledge Rollups: Use zero-knowledge proofs for security and privacy, such as Scroll, Linea, zkSync, StarkNet, etc.

Rollups Otimistas

Introdução

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

Os Rollups otimistas implementam um contrato inteligente no Ethereum, chamado contrato Rollup, que gerencia o status do Rollup, acompanha 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 prova criptográfica do novo estado da conta (raiz de Merkle). O sequenciador então compromete o bloco Rollup na main chain fornecendo raízes de Merkle e calldata.

Rollups otimistas são considerados "otimistas" porque assumem que as transações off-chain são válidas e não publicam prova 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á uma janela de tempo (chamada de período de desafio) durante o qual qualquer pessoa pode desafiar os resultados de uma transação de Rollup calculando a prova de fraude. A prova de fraude contém detalhes de uma transação específica que o verificador acredita ser fraudulenta.

Conforme mostrado na figura abaixo, o período de desafio da maioria dos Optimistic Rollups atualmente é de 7 dias, e o mais curto é 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 não contestado após o período de desafio (ou seja, todas as transações foram 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 das transações serão revertidos se a transação for executada com base em um erro previamente publicado.

Finalmente, o usuário deve enviar uma solicitação de saque para o contrato Rollup para retirar os fundos da Camada 2 para a Camada 1. O contrato verificará se o usuário possui fundos suficientes no Rollup e atualizará seu saldo na mainchain de acordo.

Principais redes Layer2

1. Arbitrum

Com a construção ecológica e airdrops, Arbitrum rapidamente se tornou a rede mais ativa na camada 2 do ETH, com TVL superior a US$ 2,7 bilhões. Após o grande airdrop, a equipe da Arbitrum lançou o programa Arbitrum Orbit: incentivando os desenvolvedores a construir a camada 3 usando tecnologias relacionadas à Arbitrum. Beosin concluiu a auditoria de segurança do ArbSwap, Arbipad para ajudar no desenvolvimento seguro do ecossistema da Arbitrum.

1. Otimismo

Embora o Optimism seja menos ecologicamente ativo do que o Arbitrum, o OP Stack, lançado pelo Optimism em 2023, obteve ampla reconhecimento do setor como uma solução completa e viável para construir uma camada 2 modular. Mais de 25 redes da camada 2 foram construídas usando o OP Stack, incluindo projetos estrela como Base, Mantle, Manta, OP BNB e Celo. O DIPX Finance e o 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ógicos. Anteriormente, a Beosin analisou detalhadamente a arquitetura e os riscos de segurança do Base e auditou o Protocolo Surf e EDA para ajudar os proprietários e usuários do projeto a evitar riscos de segurança.

1. Explosão

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

Análise de Arquitetura

OP Stack, uma estrutura madura para Optimistic Rollups, basicamente simplifica o processo complexo de construir cadeias de Optimistic Rollups ao fornecer um conjunto completo de componentes de software, ferramentas e estruturas. 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 Camada 2, como receber depósitos de tokens da Camada 1. Esta camada define todas as funções responsáveis por realizar variações de estado. Aqui, as transições de estado são desencadeadas com base nas entradas recebidas dos nós de resumo (sequências e validadores) por meio da API de mecanismo.

● Nó de Rollup: inclui sequenciador e validador. O colator é 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 apresenta evidências se houver qualquer fraude detectada.

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

● Compromisso em lote: Sequencers processam em lote todas as transações processadas de uma vez, verificadas pelos verificadores, e Sequencers enviam as transações processadas em lote para a Camada1.

● Contratos de ponte: Implementados no Ethereum e na Camada 2, permitindo que os usuários enviem mensagens e transfiram ativos entre a Camada 1 e a Camada 2.

Sob a arquitetura técnica do Optimistic Rollup, é essencial garantir a segurança dos ativos do usuário ao se moverem 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 segurança dessas transações.

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

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

● Retirando ativos do Rollup: Devido ao mecanismo de prova de fraude, retirar dinheiro do Optimistic Rollup para o Ethereum é mais complicado. Se um usuário inicia uma transação da Camada 2 para a Camada 1 para retirar fundos gerenciados 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. Assim 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 período de atraso para concluir a transação no Layer1 e retirar 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 das retiradas pendentes e paga os fundos do usuário na Layer1 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 por si próprios 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 completo de blockchain, portanto, a auditoria comum das blockchains 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 da transação da Camada 2 estejam disponíveis na Camada 1 para evitar a perda de dados.

● Mecanismo de sincronização de dados: Verifique se o mecanismo de sincronização de dados entre a Camada1 e a Camada2 está correto e pode lidar com situações anormais, como a divisão de rede.

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

● Mecanismo do período de desafio: Verifique 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 envio de prova de fraude: Verificar se o processo de envio de prova de fraude é seguro.

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

● Cunhagem 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.

Zero-Knowledge Rollups

Introdução

Zero-Knowledge (ZK) Rollup é uma camada 2 baseada em prova de conhecimento zero. Ele realiza principalmente 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 escalabilidade híbrida" que é um protocolo off-chain que é executado de forma independente, mas obtém segurança do Ethereum. Especificamente, a rede Ethereum impõe a validade das atualizações de status no ZK Rollups e garante a disponibilidade de 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 esse status, 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 de estado proposta é realmente o resultado da execução de um determinado lote de transações. Isso significa que o ZK Rollups só precisa 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, pois 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 a prova de fraude para desafiar uma transação de saída.

Principais redes de Camada2

1. zkSync

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

1. StarkNet

StarkNet usa ZK-STARK para construir Layer2 a fim de aumentar a velocidade de transação e reduzir as taxas de transação. StarkNet possui uma máquina virtual nativa (Cairo VM) e uma linguagem de desenvolvimento Cairo para ajudar os desenvolvedores a escrever contratos inteligentes de forma mais segura e fácil. Beosin se tornou um parceiro oficial de segurança da StarkNet, concluindo auditorias de segurança para Option Dance e Reddio. Em 13 de agosto de 2024, a Reddio encerrou uma rodada de financiamento liderada pela Paradigm para construir uma rede paralela EVM Layer2 de alta performance.

1. Scroll

Scroll é dimensionado 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 a compatibilidade do EVM em nível de bytecode. Isso significa que os desenvolvedores podem usar diretamente o Solidity e as 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 a seguir:

● 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 usuários transfiram ativos entre Ethereum e Rollup. Ele recebe a raiz do estado da Camada 2 e o bloco do coletor, 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 de Layer2, recuperando 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 coletor gera um novo bloco e recebe um rastro de execução desse bloco do coletor. O rastro de execução é então enviado para um Roller selecionado aleatoriamente na rede Roller, que gera uma prova de validade.

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

● Rede de Rolos: O Rolo na rede de Rolos atua como provador e é responsável por gerar a prova 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 do 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 segurança dessas transações.

● Transferência de ativos para Rollup: Os usuários entram no Rollup depositando tokens em um contrato ZK Rollups implantado em uma camada da cadeia de rede. Essa transação precisa 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 submeterá ao contrato Rollup. Assim que os fundos forem depositados no Rollup, o usuário poderá iniciar o processamento da transação.

Os usuários podem verificar o saldo no Rollup, fazendo hash de sua conta, enviando o valor de hash para o contrato Rollup e fornecendo uma prova de Merkle que verifica contra a 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 próximo lote, o usuário poderá enviar uma solicitação de retirada ao 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 da transação

3. Lote a raiz

4. Endereço da rede Layer1 para recebimento de fundos depositados

O contrato Rollup faz o hash dos dados da transação, verifica se a raiz do lote existe e usa a 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 completo de blockchain, portanto, os 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: Verifique 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 subdimensionados

2. Circuitos superconstrangidos

3. Circuitos não determinísticos

4. Aritmética Over/Under Flows Aritmética over/under flows

5. Comprimentos de bits incompatíveis

6. Entradas públicas não utilizadas otimizadas

7. Coração Congelado: Forjando Provas de Conhecimento Zero

8. Vazamento de Configuração Confiável

9. Atribuído, mas não restrito

10. Uso Inseguro de Componentes

11. Precisão Variável

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

● Prova de disponibilidade de dados: certifique-se de 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: 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 saque: Verifique o processo de depósito e saque 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.

● Verificando dependências externas e vulnerabilidades conhecidas: ZK Rollup muitas vezes depende fortemente de repositórios criptográficos e matemáticos ou ferramentas de terceiros e deve verificar minuciosamente a segurança de suas dependências para escanear e validar vulnerabilidades conhecidas.

Apêndice

Blockchain & Layer2 Itens de auditoria geral:

● Estouro de inteiro: Verifique estouros de inteiros e subfluxos de inteiros

● 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 com que o programa saia ativamente

● Vulnerabilidade de divisão por 0: Verifique se há um caso de divisão 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 o acesso a elementos fora dos limites do array

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

● Segurança na implementação da função: 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 criptografado: verifique se um protocolo de transmissão criptografado, como TLS, é usado

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

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

● Segurança tradicional na Web: Verifique as seguintes vulnerabilidades: Cross-site scripting (XSS)/injeção de modelo/vulnerabilidade de componente de terceiros/contaminação de parâmetro HTTP/injeção de SQL/injeção de entidade XXE/vulnerabilidade de desserialização/vulnerabilidade SSRF/injeção de código/inclusão de arquivo local/inclusão de arquivo remoto/injeção de execução de comando e outras vulnerabilidades tradicionais

● Mecanismo de autenticação e identificação de identidade de nós da rede: verificar se há 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ó: Verifique se o algoritmo de descoberta de nó é equilibrado e imprevisível, por exemplo, o algoritmo de distância é desequilibrado

● Auditoria de uso de conexão: verifique se o limite e o gerenciamento do número de nós conectados à rede p2p são razoáveis

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

● Ataque Sybil: Avaliando mecanismos de consenso de votação e analisando estratégias de verificação de elegibilidade de votação

● Ataque de escuta: Verifique se o protocolo de comunicação revela privacidade

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

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

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

● Ataque de esgotamento do disco rígido: Verifique onde estão armazenados arquivos grandes

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

● Ataque de exaustão de manipulação do kernel: Verifique as limitações na criação de manipulação do kernel, como manipulação de arquivos

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

● Segurança do algoritmo de hash: Verifique 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 implementação do algoritmo

● Segurança do algoritmo de criptografia: Verifique a segurança do algoritmo de criptografia e a 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 da chave é razoável

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

● Regras de seleção de garfo: Verifique as regras de seleção de garfo 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 gasto duplo: Verifique se o consenso pode se defender contra ataques de gasto duplo

● Auditoria de ataque MEV: Examine o impacto do MEV do nó do pacote de blocos na equidade da cadeia

● Auditoria do processo de sincronização de blocos: Verifica 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: Verifique 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 bloco e a lógica de verificação são suficientes

● Auditoria da lógica de validação do bloco: Verificar se o algoritmo de validação do bloco e a implementação 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 maneira razoável

● Limites de recursos de processamento de blocos: Verifique se os limites de recursos de blocos órfãos, computação de verificação, endereçamento de disco rígido e outros 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ções: Examine como as colisões de hash de transações são construídas e como elas são tratadas

● Análise de formato de transação: Verificar problemas de segurança durante a análise de formato, como erros de análise que causam falhas

● Verificação de 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 da transação: se uma transação pode alterar campos internos (como ScriptSig) para alterar o hash da transação sem afetar a validade da transação

● Auditoria de ataque de repetição de transações: verifica a detecção de repetição de transações do sistema

● Verificação de bytecode de contrato: Verifique a segurança do processo de verificação de contrato da máquina virtual, como estouro de número inteiro e loops mortos

● Execução de bytecode de contrato: Verifique a segurança do processo de execução de bytecode da máquina virtual, como estouro de inteiro, loops mortos 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 estão registradas

● Segurança do registro: Verifique se o manuseio inadequado de registros causa problemas de segurança, como overflow de inteiro

● Logs contêm informações de privacidade: Verifique se os logs contêm informações de privacidade como chaves

● Armazenamento de logs: verifique se o conteúdo excessivo é registrado em logs, o que consome recursos do nó

● Segurança da cadeia de suprimentos de código de nó: Verificar todas as bibliotecas de terceiros, componentes e versões de estruturas de cadeias públicas em busca de problemas conhecidos

Aviso Legal:

1. Este artigo é reproduzido de [beosina]. Todos os direitos autorais pertencem ao autor original [beosin]. Se houver objeções a esta reimpressão, por favor entre em contato com o Gate Learnequipe e eles lidarão com isso prontamente.
2. Isenção de responsabilidade: As visões e 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.