O Bitcoin (BTC), como a primeira criptomoeda do mundo, tornou-se gradualmente a pedra angular dos ativos digitais e das finanças descentralizadas desde o seu advento em 2009. No entanto, à medida que o número de utilizadores e o volume de transações aumentam, os problemas da rede BTC tornam-se cada vez mais evidentes, principalmente os seguintes:

  • Altas taxas de transação: Quando a rede Bitcoin está congestionada, os usuários precisam pagar taxas mais altas para garantir que as transações sejam confirmadas o mais rápido possível.​

  • Tempo de confirmação da transação: O blockchain Bitcoin gera um novo bloco a cada 10 minutos em média, o que significa que as transações na cadeia geralmente precisam esperar por múltiplas confirmações de bloco antes de serem consideradas finais.​

  • Limitações dos contratos inteligentes: A linguagem de script do Bitcoin tem funções limitadas, dificultando a implementação de contratos inteligentes complexos.

Neste artigo, referimo-nos coletivamente a Lightning Network, Sidechains, Rollup e outras tecnologias como soluções de expansão BTC Layer2. Elas mantêm a descentralização e a segurança da rede BTC enquanto alcançam transações sexuais rápidas e de baixo custo. A introdução da tecnologia Layer2 pode melhorar a velocidade das transações e reduzir os custos de transação, otimizar a experiência do usuário e expandir a capacidade da rede, fornecendo suporte técnico importante e direção de inovação para o desenvolvimento futuro do BTC.

Atualmente, a Beosin tornou-se o parceiro oficial de segurança do BTC Layer2, como Merlin Chain, e auditou vários protocolos ecológicos BTC, como Bitmap.Games, Surf Protocol, Savmswap e Mineral. Em auditorias anteriores, muitas cadeias públicas conhecidas passaram na auditoria de segurança da cadeia pública da Beosin, incluindo Ronin Network, Clover, Self Chain, Crust Network, etc. Beosin lança agora uma solução de auditoria para BTC Layer2 para fornecer serviços de auditoria de segurança abrangentes e confiáveis ​​para todo o ecossistema BTC.

 

Rede relâmpago

O conceito mais antigo de Lightning Network é chamado de "canal de pagamento". Sua ideia de design é atualizar continuamente o status da transação não confirmada por meio da substituição da transação até que ela seja finalmente transmitida para a rede Bitcoin. Satoshi Nakamoto já havia proposto a ideia de canais de pagamento quando criou o Bitcoin em 2009, e incluiu um rascunho de código para canais de pagamento no Bitcoin 1.0, que permitia aos usuários atualizar o status da transação antes que a transação fosse confirmada pela rede. No entanto, foi somente com o lançamento do white paper “The Bitcoin Lightning Network: Scalable Off-Chain Instant Payment” que a Lightning Network realmente nasceu e entrou aos olhos do público.

Hoje, a implementação de canais de pagamento e Lightning Network está muito madura. A partir de agora, a Lightning Network tem um total de 13.325 nós, 49.417 canais, e o número total de BTC prometidos atingiu 4.975.

https://1ml.com/

Na Lightning Network, é muito importante garantir a segurança dos ativos do usuário durante o processo de transferência. A seguir será explicado como a Lightning Network opera e como proteger a segurança dos ativos do usuário com base na escala dos nós da rede.

Os usuários de ambas as partes enviam duas transações para a rede principal do Bitcoin: uma para abrir o canal e outra para fechar o canal. É basicamente dividido nas três etapas a seguir:

1. Abertura do canal:

Primeiro, os usuários de ambas as partes comprometem-se com Bitcoin na carteira com múltiplas assinaturas da Lightning Network no BTC. Assim que o Bitcoin for penhorado e bloqueado com sucesso, o canal de pagamento será aberto e ambas as partes poderão realizar transações fora da cadeia neste canal.

2. Transações fora da rede:

Assim que o canal for aberto, todas as transações de transferência entre usuários serão processadas na Lightning Network, e não há limite para o número dessas transações fora da rede. É claro que essas transações não precisam ser enviadas imediatamente à rede principal do Bitcoin, mas são concluídas instantaneamente por meio do mecanismo off-chain da Lightning Network.

 

Este método de processamento fora da cadeia melhora significativamente a velocidade e a eficiência das transações, evitando o congestionamento e as altas taxas de transação da rede principal do Bitcoin.

3. Fechamento de canal e liquidação contábil:

Quando os usuários de qualquer um dos lados decidirem sair do canal, ocorrerá a liquidação final do razão. Este processo garante que todos os fundos do canal sejam alocados em dia. Ao mesmo tempo, os usuários de ambos os lados retirarão o saldo pós-liquidação da carteira com múltiplas assinaturas, o que reflete a distribuição real dos fundos quando o canal for fechado. Eventualmente, o canal enviará o estado final da transação contábil para a rede principal do Bitcoin.

As vantagens da Lightning Network são:

  • A velocidade de transação aumenta. A Lightning Network permite que os usuários realizem transações fora da cadeia, o que significa que as transações podem ser concluídas quase instantaneamente, sem esperar pelo tempo de confirmação do bloco. Isso pode atingir velocidades de transação de segundos e melhorar muito a experiência do usuário.

  • Privacidade aprimorada. As transações fora da rede da Lightning Network não precisam ser registradas publicamente na cadeia principal do Bitcoin, o que melhora a privacidade das transações. Apenas a abertura e o fechamento do canal precisam ser registrados na cadeia principal, portanto o comportamento da transação do usuário não será totalmente divulgado.

  • Suporte para micropagamento. A Lightning Network é muito adequada para processar pequenos pagamentos (micropagamentos), como pagamentos de conteúdo, pagamentos de dispositivos IoT, etc. As transações tradicionais de Bitcoin não são adequadas para pequenos pagamentos frequentes devido às altas taxas de manuseio, enquanto a Lightning Network resolve esse problema.​

Desafios enfrentados pela Lightning Network:

  • Problemas de liquidez da rede: A Lightning Network depende de Bitcoins pré-bloqueados em canais. Isso significa que os usuários devem depositar Bitcoin suficiente em seu canal de pagamento com antecedência para fazer uma transação. A liquidez insuficiente pode causar falhas nos pagamentos, especialmente em pagamentos maiores.

  • Problemas de roteamento: Encontrar um caminho eficiente entre um remetente de pagamento e um destinatário pode ser um problema complexo, especialmente se o tamanho da rede for grande. À medida que o número de nós e canais da rede aumenta, a dificuldade de garantir a conclusão tranquila dos pagamentos também aumenta.

  • Problemas de custódia de fundos: os nós podem estar sujeitos a ataques maliciosos e os usuários precisam confiar que os nós aos quais estão conectados não tentarão roubar fundos. Os nós podem evitar vazamentos de chaves privadas?

  • Padrões técnicos e interoperabilidade: São necessários padrões e protocolos técnicos consistentes entre diferentes implementações da Lightning Network para garantir a interoperabilidade. Atualmente, várias equipes de desenvolvimento estão trabalhando em diferentes implementações da Lightning Network, o que pode levar a problemas de compatibilidade.

  • Questões de privacidade: Embora a Lightning Network melhore a privacidade das transações Bitcoin, as informações das transações ainda podem ser rastreadas ou analisadas. Além disso, os operadores de nós de rede podem ver as transações passando por seus nós, revelando potencialmente certas informações privadas.

A segurança da Lightning Network afeta diretamente a escalabilidade fora da cadeia do Bitcoin e a segurança dos fundos dos usuários. Portanto, além dos itens gerais de auditoria da cadeia pública (veja detalhes no apêndice no final deste artigo), a Lightning Network também precisa estar atenta aos seguintes pontos importantes de risco de segurança:

  • Congestionamento do canal: Verifique a abrangência do projeto do sistema Lightning Network e se isso levará ao congestionamento do canal devido a ataques de luto.

  • Interferência de canal: Verifique a segurança da estrutura do canal da Lightning Network e se ela estará sujeita a ataques de interferência de canal.

  • Bloqueio e desbloqueio de ativos de canal: Revise o processo de bloqueio e desbloqueio de ativos na Lightning Network para garantir que, ao abrir ou fechar um canal de pagamento, a transferência de fundos dentro e fora da cadeia seja segura e confiável.

  • Atualização e fechamento de status: Avalie o processo de atualização de status e o mecanismo de fechamento forçado do canal para garantir que o status mais recente possa ser corretamente identificado e executado quando ocorrerem condições anormais.

  • Contrato de bloqueio de tempo e bloqueio de hash (HTLC): Avalie a implementação do HTLC para garantir que as condições de bloqueio de tempo e bloqueio de hash possam ser executadas corretamente para evitar perdas de fundos causadas por problemas de janela de tempo.

  • Dependência do carimbo de data/hora do blockchain: Avalie a dependência da Lightning Network do carimbo de data/hora do blockchain do Bitcoin para garantir que o tempo dentro e fora da cadeia possa ser coordenado corretamente para evitar ataques de tempo.

  • Segurança do algoritmo de roteamento: verifique a eficiência e a segurança do algoritmo de roteamento para evitar a exposição da privacidade do usuário e riscos de manipulação maliciosa de roteamento.

  • Armazenamento de canal e recuperação de dados: Verifique o mecanismo de armazenamento e a estratégia de recuperação de dados do canal para garantir que o status do canal possa ser restaurado quando um nó falhar ou for desconectado acidentalmente para evitar perda de fundos.

cadeia lateral

Ao contrário da Lightning Network, a cadeia lateral é uma blockchain independente que funciona em paralelo com a cadeia principal (como a blockchain BTC) e interopera com a cadeia principal através de ancoragem bidirecional (Two-Way Peg). O objetivo da cadeia lateral é obter mais funções e melhorar a escalabilidade sem alterar o protocolo da cadeia principal.

Como uma blockchain independente, a cadeia lateral possui seu próprio mecanismo de consenso, nós e regras de processamento de transações. Pode adotar tecnologias e protocolos diferentes da cadeia principal de acordo com as necessidades de cenários de aplicação específicos. Através do mecanismo de ancoragem bidirecional (2WP), a cadeia lateral comunica-se com a cadeia principal para garantir que os ativos possam ser transferidos de forma livre e segura entre as duas. O mecanismo operacional do mecanismo de ancoragem bidirecional (2WP) é aproximadamente o seguinte:

1. O usuário bloqueia o BTC na cadeia principal e a instituição confiável 1 obtém e usa a verificação SPV 2 para garantir se a transação bloqueada do usuário é confirmada.

2. A instituição confiável emitirá tokens equivalentes para usuários da cadeia lateral.

3. Após transações gratuitas, os usuários bloqueiam os tokens restantes na cadeia lateral.

4. Após verificar a legalidade da transação, a instituição de confiança desbloqueia o BTC na cadeia principal e libera o valor correspondente do BTC ao usuário.

Nota 1: As instituições confiáveis ​​desempenham um papel fundamental no mecanismo de ancoragem bidirecional e são responsáveis ​​pela gestão do bloqueio e liberação de ativos. Estas instituições precisam de ter um elevado grau de credibilidade e capacidades técnicas para garantir a segurança dos activos dos utilizadores.

Nota 2: A verificação SPV permite que os nós verifiquem a validade de uma transação específica sem baixar o blockchain completo. Os nós SPV só precisam baixar o cabeçalho do bloco e verificar se a transação está incluída no bloco por meio da Árvore Merkle.

Projetos representativos de cadeias laterais:

CKB (Rede Nervos)

Nervos Network é um ecossistema blockchain público de código aberto que visa aproveitar as vantagens de segurança e descentralização do mecanismo de consenso POW do BTC, ao mesmo tempo que introduz um modelo UTXO mais escalável e flexível para processar transações. Seu núcleo é a Base de Conhecimento Comum (CKB), que é um blockchain de Camada 1 construído em RISC-V e usando PoW (Prova de Trabalho) como consenso. Ele expande o modelo UTXO para um modelo Cell, permitindo armazenar quaisquer dados e suportar a escrita de scripts em qualquer linguagem para execução na cadeia como um contrato inteligente.

Pilhas

Stacks conecta cada bloco Stacks ao bloco Bitcoin por meio de seu mecanismo PoX (Proof of Transfer). Para desenvolver contratos inteligentes, Stacks projetou a linguagem de programação especializada Clarity. No Clarity, a função get-burn-block-info? permite passar a altura do bloco Bitcoin e obter o hash do cabeçalho do bloco. Ao mesmo tempo, a palavra-chave burn-block-height pode obter a altura atual do bloco da cadeia Bitcoin. Essas duas funções permitem que os contratos inteligentes do Clarity leiam o estado da cadeia base do Bitcoin, permitindo que as transações do Bitcoin sirvam como gatilhos de contrato. Ao automatizar a execução desses contratos inteligentes, Stacks amplia as capacidades do Bitcoin.

Para uma análise detalhada do Stacks, você pode ler o artigo de pesquisa anterior de Beosin: "O que é Stacks?" Que desafios as pilhas de rede da camada 2 do BTC podem enfrentar? 》

As vantagens das cadeias laterais são:

  • As cadeias laterais podem utilizar diferentes tecnologias e protocolos para conduzir vários experimentos e inovações sem afetar a estabilidade e segurança da cadeia principal.

  • As cadeias laterais podem introduzir funções que a cadeia principal não possui, como contratos inteligentes, proteção de privacidade, emissão de tokens, etc., para enriquecer os cenários de aplicação do ecossistema blockchain.

Desafios enfrentados pelas cadeias laterais:

  • As cadeias laterais têm mecanismos de consenso independentes e podem não ser tão seguras quanto a cadeia principal do BTC. Se o mecanismo de consenso da cadeia lateral for fraco ou apresentar lacunas, poderá levar a ataques de 51% ou outras formas de ataques, afetando a segurança dos ativos dos usuários. A segurança da cadeia principal do BTC depende de seu enorme poder computacional e ampla distribuição de nós, enquanto as cadeias laterais podem não atender aos mesmos padrões de segurança.

  • A implementação do mecanismo de ancoragem bidirecional requer algoritmos e protocolos de criptografia complexos. Se houver lacunas neles, isso poderá causar problemas na transferência de ativos entre a cadeia principal e a cadeia lateral, podendo até levar à perda ou roubo de ativos. .

  • Para encontrar um equilíbrio entre velocidade e segurança, a maioria das cadeias laterais são mais centralizadas do que a cadeia principal.

Layer2 é um sistema blockchain completo, portanto, os itens gerais de auditoria da cadeia pública também se aplicam à cadeia lateral. Para obter detalhes, consulte o apêndice no final deste artigo.

Além disso, devido à sua especificidade, as cadeias laterais requerem alguma auditoria adicional:

  • Segurança do protocolo de consenso: Revise se o protocolo de consenso da cadeia lateral (como PoW, PoS, DPoS) foi totalmente verificado e testado e se existem vulnerabilidades potenciais ou vetores de ataque, como ataques de 51%, ataques de longo alcance, etc.

  • Segurança dos nós de consenso: Avalie a segurança dos nós de consenso, incluindo gerenciamento de chaves, proteção de nós e backup redundante, para evitar que os nós sejam violados ou abusados.

  • Bloqueio e libertação de activos: Rever o mecanismo de ancoragem bidireccional de activos entre a cadeia lateral e a cadeia principal para garantir que os contratos inteligentes para bloqueio e libertação de activos são seguros e fiáveis, evitando gastos duplos, perda de activos ou falha de bloqueio.

  • Verificação entre cadeias: verifique a precisão e a segurança da verificação entre cadeias, garanta que o processo de verificação seja descentralizado e à prova de falsificação e evite falhas de verificação ou verificações maliciosas.

  • Auditoria do código do contrato: Auditoria aprofundada de todos os contratos inteligentes em execução na cadeia lateral para detectar possíveis brechas ou backdoors, especialmente a lógica do contrato ao lidar com operações entre cadeias.

  • Mecanismo de atualização: Verifique se o mecanismo de atualização dos contratos inteligentes é seguro e se existem processos apropriados de auditoria e consenso da comunidade para evitar atualizações maliciosas ou adulteração de contratos.

  • Comunicação entre nós: Verifique se o protocolo de comunicação entre os nós da cadeia lateral é seguro e se canais criptografados são usados ​​para evitar ataques man-in-the-middle ou vazamentos de dados.

  • Comunicação entre cadeias: Verifique o canal de comunicação entre a cadeia lateral e a cadeia principal para garantir a integridade e autenticidade dos dados e evitar que a comunicação seja sequestrada ou adulterada.

  • Carimbo de data e hora do bloco: verifique o mecanismo de sincronização de tempo da cadeia lateral para garantir a consistência e precisão do tempo de geração do bloco e evitar ataques ou reversões de bloco causadas por diferenças de horário.

  • Segurança de governação na cadeia: Rever o mecanismo de governação da cadeia lateral para garantir a transparência e a segurança dos processos de votação, proposta e tomada de decisão, e evitar controlos ou ataques maliciosos.

  • Auditoria económica simbólica: Verifique o modelo económico simbólico da cadeia lateral, incluindo a atribuição de tokens, mecanismo de incentivo e modelo de inflação, para garantir que os incentivos económicos não levarão a comportamento malicioso ou instabilidade do sistema.

  • Mecanismo de taxas: Verifique o mecanismo de taxas de transação da cadeia lateral para garantir que ele atenda às necessidades dos usuários da cadeia principal e da cadeia lateral para evitar manipulação de taxas ou congestionamento da rede.

  • Segurança de ativos: Audite o mecanismo de gestão de ativos da cadeia para garantir que o processo de armazenamento, transferência e destruição de ativos seja seguro e confiável e que não haja risco de acesso não autorizado ou roubo.

  • Gerenciamento de chaves: Verifique a política de gerenciamento de chaves da cadeia lateral para garantir a segurança e o controle de acesso da chave privada e evitar que a chave seja vazada ou roubada.​

Enrolamento

Rollup é uma solução de escalonamento de Camada 2 projetada para melhorar o rendimento e a eficiência das transações blockchain. Reduz significativamente a carga sobre a cadeia principal, empacotando (“Rollup”) um grande número de transações e processando-as fora da cadeia, enviando apenas os resultados finais para a cadeia principal.

Rollup é dividido principalmente em zk-Rollup e op-Rollup. No entanto, ao contrário do ETH, devido à incompletude de Turing do BTC, é impossível usar contratos no BTC para verificação de prova de conhecimento zero. As soluções tradicionais zk-Rollup não podem ser implementadas no BTC. Então, como implementar BTC Layer2 usando zk-Rollup? A seguir, tomemos como exemplo o projeto da Rede B²:

Para completar a verificação de prova de conhecimento zero no BTC, a B² Network criou o script Taproot, que combina a verificação de prova de conhecimento zero do zk-Rollup e o desafio de incentivo do op-Rollup. Seu mecanismo de funcionamento é aproximadamente o seguinte:

1. A Rede B² primeiro acumula todas as transações iniciadas pelos usuários.

2. Depois de usar o classificador para classificar as transações Rollup, salve as transações Rollup usando armazenamento descentralizado e entregue-as ao zkEVM para processamento ao mesmo tempo.

3. Depois que zkEVM sincroniza o status da cadeia BTC, ele processa transações como execução de contrato, mescla e empacota os resultados e os envia ao agregador.

4. O provador gera uma prova de conhecimento zero e a envia ao agregador. O agregador agrega as transações e envia a prova aos nós B².

5. B² Nodes realiza verificação de prova de conhecimento zero e cria scripts Taproot com base nos dados Rollup em armazenamento descentralizado.

6. Taproot é um UTXO com valor de 1 satoshi. A inscrição B² em sua estrutura de dados armazena todos os dados Rollup e Tapleaf armazena todos os dados de verificação. Após aprovação no mecanismo de desafio de incentivo, ele será enviado ao BTC como compromisso verificado com base na prova zk.

As vantagens do Rollup são:

  • Rollup herda os recursos de segurança e descentralização da cadeia principal. Ao enviar regularmente os dados e o status das transações à cadeia principal, a integridade e a transparência dos dados são garantidas.

  • O Rollup pode ser perfeitamente integrado às redes blockchain existentes, como Ethereum, permitindo que os desenvolvedores aproveitem facilmente seus benefícios sem modificar significativamente os contratos e aplicativos inteligentes existentes.

  • Ao processar um grande número de transações fora da cadeia e empacotá-las em um lote para envio à cadeia principal, o Rollup melhora muito os recursos de processamento de transações e aumenta significativamente o número de transações por segundo (TPS).

  • As transações rollup só precisam ser processadas fora da cadeia, o que reduz bastante os recursos de computação e o espaço de armazenamento necessários para transações na cadeia, reduzindo significativamente as taxas de transação do usuário.

Desafios enfrentados pelo Rollup:

  • Se os dados fora da cadeia não estiverem disponíveis, os usuários podem não conseguir verificar as transações e restaurar o status.

  • As transações de rollup precisam ser processadas em lotes e finalmente submetidas à cadeia principal, o que pode resultar em tempos de liquidação mais longos. Especialmente no op-Rollup, há um período de disputa e os usuários podem ter que esperar muito tempo antes que a transação seja finalmente confirmada.

  • Embora o ZK Rollup forneça maior segurança e confirmação instantânea, seus requisitos de computação e armazenamento são altos e a geração de provas de conhecimento zero requer uma grande quantidade de recursos computacionais.​

Como a solução adotada é o Rollup, seus principais itens de auditoria de segurança são basicamente os mesmos do ETH Layer2.​

Outros (Babilônia)

Além do BTC Layer2 tradicional, também existem alguns novos conceitos de protocolos de terceiros relacionados ao ecossistema BTC recentemente, como o Babylon:

O objetivo da Babylon é converter 21 milhões de BTC em ativos de staking descentralizados. Ao contrário de outras camadas 2 do BTC, o Babylon não expande a cadeia do BTC. É uma cadeia única em si, com um protocolo especial de hipoteca BTC. O objetivo principal é conectar-se à cadeia PoS BTC para fornecer segurança mais forte para a cadeia PoS e resolver o risco de ataques da extremidade remota da cadeia. questão centralizada.

A arquitetura é dividida em três camadas:

Camada Bitcoin: Esta é a base sólida da Babylon, aproveitando a conhecida segurança do Bitcoin para garantir que todas as transações sejam superseguras, assim como na rede Bitcoin.

Camada Babylon: No coração da Babylon está a camada Babylon, um blockchain personalizado que conecta Bitcoin a várias cadeias de Prova de Participação (PoS). Ele processa transações, executa contratos inteligentes e garante que tudo funcione perfeitamente em todo o ecossistema.

Camada de cadeia PoS: A camada superior é composta por múltiplas cadeias PoS, cada cadeia PoS selecionada por suas vantagens exclusivas. Isso dá à BabylonChain incrível escalabilidade e flexibilidade, permitindo que os usuários aproveitem os melhores recursos de diferentes blockchains PoS.

A forma como funciona é proteger a cadeia PoS usando blocos finais assinados na cadeia BTC. Basicamente, isso estende o protocolo básico com rodadas de assinatura adicionais. Essas assinaturas na rodada final +1 têm uma característica única: são assinaturas únicas extraíveis (EOTS). O objetivo é integrar pontos de verificação PoS no BTC para resolver o longo período de desvinculação e problemas de ataque remoto do PoS.

As vantagens da Babilônia são:

  • Torne o período de desvinculação do PoS mais rápido

  • Como o BTC está penhorado, o preço está vinculado ao BTC, o que pode reduzir a pressão inflacionária na rede PoS correspondente.

  • Abre novos caminhos para ganhos BTC

Desafios enfrentados pela Babilônia:

  • Projetos econômicos, como taxa de retorno de piquetagem, têm um impacto maior no entusiasmo de piquetagem do BTC

  • Falta de disposições de consistência de recompensa entre cadeias de PoS

Protocolos de terceiros possuem diferentes pontos de segurança dependendo de sua implementação. Tomando o Babylon como exemplo, alguns itens de auditoria de segurança que precisam de atenção são os seguintes:

1. Segurança do contrato inteligente: O contrato de penhor no BTC é implementado por meio de scripts UTXO e sua segurança precisa ser atenta.

2. Segurança do algoritmo de assinatura: As assinaturas são utilizadas em contratos para gerenciar promessas de usuários, e a segurança do algoritmo está relacionada à geração e verificação de assinaturas.

3. Concepção do modelo económico do protocolo: Se o modelo económico do protocolo é razoavelmente definido em termos de recompensas e penalidades, e se levará à perda de activos do utilizador.​

apêndice:

Cadeia pública e itens de auditoria geral da camada 2

  • Estouro de número inteiro: verifique se há estouro de número inteiro e estouro de número inteiro

  • Loop infinito: verifique se as condições de julgamento do loop do programa são razoáveis

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

  • Condições de corrida: verifique as operações de acesso a recursos compartilhados em condições simultâneas

  • Falha anormal: verifique o código de lançamento de exceção que permite que o programa saia ativamente

  • Vulnerabilidade de divisão por 0: Verifique se há divisão por 0

  • Conversão de tipo: verifique se a conversão de tipo está correta e se informações importantes foram perdidas durante o processo de conversão

  • Matriz fora dos limites: verifique se um elemento além dos limites da matriz é acessado

  • Vulnerabilidade de desserialização: verifique se há algum problema durante o processo de desserialização

  • Segurança de implementação funcional: Verifique se há riscos de segurança em cada implementação da interface RPC e se ela é consistente com a função da interface RPC.

  • Pode ser projetado para combinar

  • Se as configurações de permissão da interface RPC confidencial são razoáveis: Verifique as configurações de permissão de acesso da interface RPC confidencial

  • Mecanismo de transmissão criptografado: Verifique se um protocolo de transmissão criptografado é usado, como TLS, etc.

  • Análise de formato de dados de solicitação: verifique o processo de análise de formato de dados de solicitação

  • Ataque de desbloqueio de carteira: quando um nó desbloqueia sua carteira, o RPC solicita que ele roube fundos.

  • Segurança Web Tradicional: Verifique as seguintes vulnerabilidades: Cross-site scripting (XSS) / Injeção de modelo /

  • Vulnerabilidades de componentes de terceiros/poluição de parâmetros HTTP/injeção de SQL/injeção de entidade XXE/desserialização

  • vulnerabilidades/vulnerabilidades 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ó de rede: Verifique se existe um mecanismo de identificação de nó e se o mecanismo de identificação de nó pode ser ignorado.

  • Poluição da tabela de roteamento: verifique se a tabela de roteamento pode ser inserida aleatoriamente ou substituída por dados

  • Algoritmo de descoberta de nó: verifique se o algoritmo de descoberta de nó é balanceado e imprevisível, como algoritmo de distância desequilibrado e outros problemas

  • Auditoria de ocupação do número de conexão: verifique se o limite e o gerenciamento do número de nós de conexão de rede p2p são razoáveis

  • Ataque Eclipse: Avalie o custo e os danos de um ataque Eclipse e forneça análises quantitativas, se necessário

  • Ataque Sybil: avaliar o mecanismo de consenso de votação e analisar a estratégia de verificação de qualificação de voto

  • Ataque de espionagem: verificando protocolos de comunicação em busca de vazamentos de privacidade

  • Ataque alienígena: avalie se o nó pode identificar nós de cadeia semelhantes

  • Time Hijacking: Verificando o mecanismo de cálculo de tempo de rede de um nó

  • Ataque de exaustão de memória: verificação de locais com grande consumo de memória

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

  • Ataque de pressão de soquete: verifique a política de limite no número de conexões

  • Ataque de esgotamento do identificador do kernel: verifique os limites de criação do identificador do kernel, como identificadores de arquivo, etc.

  • Vazamentos de memória persistentes: verifique se há vazamentos de memória

  • Segurança do algoritmo Hash: verificando a resistência à colisão de um algoritmo Hash

  • Segurança do algoritmo de assinatura digital: verifique a segurança do algoritmo de assinatura e a segurança da implementação do algoritmo

  • Segurança do algoritmo de criptografia: verifique a segurança do algoritmo de criptografia, segurança da implementação do algoritmo

  • Segurança do gerador de números aleatórios: verificando se os algoritmos críticos de geração de números aleatórios são sólidos

  • Segurança de implementação BFT: Avaliando a segurança de implementação do algoritmo BFT

  • Regras de escolha do garfo: verifique as regras de escolha do garfo para garantir a segurança

  • Detecção de centralização: identifique se há centralização excessiva no design do sistema

  • Auditoria de incentivos: Avalie o impacto dos incentivos na segurança

  • Ataque de gastos duplos: verifique se o consenso pode defender contra ataques de gastos duplos

  • Auditoria de ataque MEV: verifique o impacto do MEV dos nós de empacotamento em bloco na justiça da cadeia

  • Auditoria do processo de sincronização de blocos: verifique problemas de segurança durante o processo de sincronização

  • Auditoria do processo de análise de formato de bloco: verifique problemas de segurança no processo de análise de formato, como erros de análise que levam a falhas

  • Auditoria do processo de geração de blocos: verifique os problemas de segurança durante o processo de geração de blocos, incluindo se o método de construção da raiz da árvore Merkle é razoável

  • Auditoria do processo de verificação de bloco: verifique se os itens de conteúdo da assinatura do bloco e a lógica de verificação são suficientes

  • Auditoria da lógica de confirmação de bloco: verifique se o algoritmo e a implementação de confirmação de bloco são razoáveis

  • Colisão de hash de bloco: verifique o método de construção da colisão de hash de bloco e se o tratamento da colisão é razoável.

  • Limites de recursos de processamento de blocos: Verifique se os limites de recursos, como pool de blocos órfãos, cálculo de verificação, endereçamento de disco rígido, etc., são razoáveis.

  • Auditoria do processo de sincronização de transações: verifique problemas de segurança durante o processo de sincronização

  • Colisão de hash de transação: verifique o método de construção da colisão de hash de transação e o processamento da colisão

  • Análise de formato de transação: verifique problemas de segurança durante o processo de análise de formato, como erros de análise que levam a falhas

  • Verificação da legalidade da transação: verifique se cada tipo de item de conteúdo de assinatura de transação e 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, cálculos de verificação, endereçamento de disco rígido, etc., são razoáveis.

  • Ataque de maleabilidade de transação: 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ção: verifique a detecção do sistema de repetição de transação

  • Verificação de bytecode do contrato: verifique os problemas de segurança do processo de verificação da máquina virtual do contrato, como estouro de número inteiro, loop infinito, etc.

  • Execução de bytecode do contrato: verifique os problemas de segurança no processo de execução do bytecode da máquina virtual, como estouro de número inteiro, loop infinito, etc.

  • Modelo gas: Verifique se as taxas de movimentação correspondentes a cada operação atômica de processamento de transações/execução de contratos são proporcionais ao consumo de recursos

  • Integridade de registro: verifique se as informações principais estão registradas

  • Segurança dos registros de log: Verifique se há problemas de segurança causados ​​pelo manuseio inadequado durante o processamento do log, como estouro de número inteiro, etc.

  • O log contém informações privadas: verifique se o log contém informações privadas, como chaves

  • Armazenamento de log: verifique se o log registra muito conteúdo, causando consumo de recursos do nó

  • Segurança da cadeia de suprimentos do código do nó: verifique os problemas conhecidos de todas as bibliotecas de terceiros, componentes e versões correspondentes da estrutura da cadeia pública

Como uma das primeiras empresas de segurança blockchain do mundo a se envolver na verificação formal, a Beosin concentra-se no negócio totalmente ecológico de "segurança + conformidade". Estabeleceu filiais em mais de 10 países e regiões ao redor do mundo, e seus negócios abrangem código. auditorias de segurança antes dos projetos ficarem on-line, produtos de conformidade de blockchain "one-stop" + serviços de segurança, como monitoramento e bloqueio de riscos de segurança durante a operação do projeto, recuperação de roubos, combate à lavagem de dinheiro (AML) de ativos virtuais e avaliações de conformidade que atendem às regulamentações locais. requisitos. As partes do projeto com necessidades de auditoria podem entrar em contato com a equipe de segurança da Beosin.