Olá queridos leitores!
Hoje vamos olhar algumas dicas profissionais na auditoria de contratos inteligentes na blockchain NEAR. Nesta série, vamos nos concentrar apenas nos aspectos que podem ser realmente úteis para a auditoria de projetos baseados na NEAR. Tudo o que você verá abaixo é baseado na nossa experiência pessoal!
Em primeiro lugar, gostaríamos de expressar nossa sincera gratidão aos criadores da NEAR e seus projetos do ecossistema, a todos que a apóiam, aos autores de todos os materiais de recursos e, claro está, aos nossos brilhantes auditores que nos ajudaram revelando informações muito necessárias e levantando o véu do segredo. E hoje, queridos leitores, isso estará disponível para vocês.
Podemos dizer com confiança que dicas como essas podem ser lidas publicamente em poucos lugares e nosso blog é um desses lugares! O seguinte será nossas observações – apenas fatos diretos para auditores, truques e os melhores macetes compartilhados pelos nossos melhores auditores. Vamos começar!
A propósito, há alguns espaços vacantes neste momento, portanto, se o seu projeto precisar de uma auditoria – sinta-se à vontade para nos escrever (write), visite nossa página de relatórios públicos here (aqui).
I — O que é NEAR?
NEAR é uma plataforma de desenvolvimento construída sobre uma blockchain de primeira camada, fragmentada, e com prova de participação. Usando a tecnologia sharding (fragmentação), a NEAR oferece soluções para problemas como, baixa velocidade de processamento, congestionamento de rede e altas cargas de gás, permitindo uma escalabilidade significativa da plataforma sem sacrificar a segurança do protocolo.
É importante ter em mente que NEAR é uma blockchain fragmentada escalável o que significa que os contratos inteligentes implantados são compilados para WebAssembly (WASM) e podem ser escritos nas seguintes linguagens :
- Rust
- AssemblyScript (uma linguagem de programação TypeScript para WebAssembly)
- Solidity (via Aurora EVM)
- Javascript (via JS-VM)
O uso de WASM resulta em um alto limite de gás e eficiência, geração rápida de blocos e taxas de transação mais baixas. Os contratos inteligentes na NEAR podem ser considerados microsserviços contendo dados e códigos executáveis. As interações entre contratos são realizadas de forma assíncrona.
Com tudo o dito, desde nossa perspectiva, o ecossistema NEAR é principalmente baseado em Rust.
https://github.com/rust-in-blockchain/awesome-blockchain-rust
A plataforma reúne milhares de membros da comunidade para entregar a experiência mais confortável, além de um ecossistema multifuncional de ampla gama.
A plataforma está baseada em vários recursos principais:
Em termos de segurança de produção de blocos, eles empregam um mecanismo conhecido como Doomslug. Doomslug, apesar de seu nome sinistro, é bastante simples e assume que diferentes validadores se revezam produzindo blocos com base em quantos tokens NEAR foram postos em stake.
Não entraremos em detalhes neste artigo porque assumimos que você, caro leitor, já possui um conhecimento suficiente do ecossistema NEAR, por isso recomendamos fortemente que você visite sua base de conhecimento e estude a documentação do projeto para um melhor entendimento:
II — Procedimento de Revisão de Projeto NEAR do Time Pessimistic.io:
Como os principais obstáculos que o auditor pode encontrar ao auditar projetos no NEAR são lógicos, a primeira sugestão para qualquer empresa estará em um desenvolvimento competente, o que resulta em documentação sólida e testes confiáveis. Parece simples demais para ser verdade, mas tenha certeza de que funciona e só se prova com o tempo!
Então, nossa brilhante equipe de auditoria gostaria de apresentar-lhe o nosso próprio regulamento, acumulado ao longo de muitos meses e anos de trabalho, no qual tentaremos evitar redundâncias e tentar transmitir tudo de forma muito concisa e profissional. Com tudo dito, realizamos nossa auditoria de acordo com os seguintes procedimentos:
Análise automatizada:
- Compilamos contratos;
- Executamos testes fornecidos e verificamos a cobertura do código;
- Executamos ferramentas de análise e verificamos manualmente (rejeitamos ou confirmamos) todos os problemas relatados (veja abaixo);
Análise manual:
- Revisamos manualmente o código e avaliamos sua qualidade;
- Verificamos o código à procura de vulnerabilidades conhecidas;
- Verificamos se a lógica do código está de acordo com a documentação fornecida;
- Sugerimos possíveis otimizações de gás e armazenamento;
Problemas:
Estamos ativamente à procura de:
- Problemas de controle de acesso (identificação/autorização incorreta do administrador ou dos usuários);
- Problemas de ativos perdidos/roubados (ativos presos no contrato ou enviados para lugar nenhum ou para uma conta errada);
- DoS devido a problemas lógicos (deadlock, erro de máquina de estado, etc);
- DoS devido a problemas técnicos (erros por falta de Gas, outras limitações);
- Problemas de interação do contrato, (reentrância, chamadas inseguras, suposições do chamador) ;
- A Problemas aritméticos (overflow, underflow, problemas de arredondamento);
- Uso incorreto da Near SDK;
- Outros problemas.
Gas:
Verificamos se as operações com uso intensivo de gás são realizadas de forma eficiente:
- Coleções: As coleções de std::collections são lidas todas juntas, o que aumenta o consumo de gás. Você deve usar near_sdk::collections ou near_sdk::store; As coleções estão vinculadas a um armazenamento e você pode acidentalmente esquecer de sincronizá-las;
- Mapas: LookupMap / UnorderedMap / TreeMap — Você precisa escolher de acordo com a funcionalidade necessária (a primeira é a mais barata e a última a mais poderosa);
- LazyOption — para “big data” raramente usado (só pode ser usado no construtor); Borsh/JSON para serialização de mensagens (parâmetros/valores de retorno) — afeta o consumo de gás;
- Dê uma olhada mais de perto em The “million cheap data additions” attack para evitar problemas semelhantes.
Ferramentas:
Vamos dar uma olhada mais de perto nas ferramentas de análise automática que você pode usar em seu trabalho e suas características:
- Valgrind — pode ser usado se o código incluir blocos inseguros com alocação de memória perigosa. No entanto, tal prática levanta uma bandeira vermelha para a auditoria. Em geral, executar valgrind não faz muito sentido!
- Cargo Geiger é uma ferramenta que exibe estatísticas sobre o uso de código Rust não seguro em uma caixa Rust e todas as suas dependências. Sua capacidade de se concentrar em possíveis problemas é uma característica benéfica. A existência de códigos perigosos já é um problema em tais projetos, e qualquer uma dessas entradas deve ser verificada duas vezes.
- Cargo Audit — verifica os arquivos em busca de caixas que contenham vulnerabilidades de segurança. Ou seja, exibe bibliotecas desatualizadas que todos ainda usam. No entanto, você deve usá-lo para fins de auditoria.
- Clippy O analisador estático é um código linter, incrível para detectar erros comuns e melhorar seu código Rust.
- Cargo Tarpaulin — para cobertura de teste — uma ferramenta muito útil que revela o número de linhas de código que não são cobertas por testes.
III — Relatórios Públicos de Auditoria
Nossos Relatórios Públicos de Auditoria dos projetos do ecossistema NEAR são estruturados de acordo com um esquema de fluxo de auditoria apresentado acima, por isso recomendamos que você compare esses relatórios, principalmente seus resultados, com os seguintes:
Esperamos que este artigo tenha sido informativo e útil para você! Obrigado por ler! Que instrumentos devemos rever? Sobre o que você estaria interessado em ler em nosso blog?
Se você ainda tiver dúvidas, sinta-se à vontade para perguntar! Teremos o maior prazer em responder a todas as perguntas que você tiver! As melhores perguntas e respostas poderão ser incluídas na próxima postagem do blog!
A propósito, há alguns espaços vacantes no momento, portanto, se o seu projeto precisar de uma auditoria – sinta-se à vontade para nos escrever, visite nossa página de reportes públicos aqui.
