Skip to content

Stack de Tecnologia do Projeto

Jump to bottom
Tiago de Paula edited this page Oct 28, 2025 · 2 revisions

Este documento registra a stack de tecnologia adotada para construir e operar o pipeline DevSecOps focado em contratos Solidity. As decisões aqui documentadas buscam garantir previsibilidade dos ambientes, compatibilidade com as ferramentas de análise qualificadas e uma base comum para evoluções futuras.

Domínio Decisão principal Tecnologia Secudária
Blockchain-alvo Sepolia: testnet pública, execução reproduzível Anvil como fork para testes locais
Framework de desenvolvimento Foundry: acelera testes e fuzzing Hardhat para plugins JS quando necessário
Compilador / EVM solc 0.8.30 com EVM Cancun: boa retrocompatibilidade solc 0.8.26 em caso de problemas com instruções recentes
Plataforma de CI/CD Jenkins + Docker: permite pipelines com gates formais Nenhum

Blockchain-alvo

Chamamos de "blockchain-alvo" a rede onde os contratos serão implantados ou simulados durante o ciclo de desenvolvimento. Ela pode ser uma testnet pública, uma rede privada ou um fork local controlado; define endereçamento, disponibilidade de faucet, limites de gás, regras de consenso e suporte das ferramentas de monitoramento que serão adotadas.

Como a rede escolhida influencia diretamente esses parâmetros operacionais, precisamos equilibrar previsibilidade de testes com representatividade do ambiente real para que os resultados das análises tenham validade. No nosso caso, isso garante que scanners e fuzzers possam reproduzir vulnerabilidades típicas de produção sem comprometer a cadência das PoCs.

Opções consideradas

  • Ethereum Sepolia (testnet pública)
    • Vantagens: ampla compatibilidade de ferramentas, carteiras e RPC; maturidade da rede; bom suporte de exploradores.
    • Desvantagens: sujeita a variações de disponibilidade de faucet; latência de rede externa.
  • Ethereum Holesky (testnet pública)
    • Vantagens: alinhada com features de protocolo em teste; boa para ensaios de validação de mudanças de rede.
    • Desvantagens: mudanças experimentais; testnet em processo de remoção após o fork Fusaka [1].
  • Execução local/fork (Anvil/Foundry)
    • Vantagens: velocidade, controle determinístico, sem dependência de faucet; ideal para CI.
    • Desvantagens: não valida integração end-to-end em uma testnet pública.

Escolha: Sepolia, com execução local (Anvil) para ciclos de desenvolvimento e CI.

Motivos: maturidade e compatibilidade ampla; riscos de mudanças de protocolo em testnets podem afetar demonstrações.

Framework de desenvolvimento

O framework de desenvolvimento é o conjunto de ferramentas, bibliotecas e convenções que padroniza como compilamos, testamos, simulamos e empacotamos contratos Solidity. Inclui CLI, templates de projeto, gerenciadores de dependência, harnesses de teste e conectores com nós Ethereum.

A escolha impacta a produtividade das squads e a confiabilidade das entregas, pois condiciona a forma como escrevemos testes, instrumentamos fuzzing, gerenciamos dependências e integramos scanners e automações ao pipeline. Para o projeto, isso se traduz em menos retrabalho na fase de integração das ferramentas de segurança e maior uniformidade entre os repositórios de exemplo e o estudo de caso final.

Opções consideradas

  • Foundry
    • Vantagens: testes e fuzzing nativos muito rápidos; boa integração com pipelines; tooling moderno (forge/cast); fuzzing integrado foi recomendado na avaliação.
    • Desvantagens: o ecossistema ainda é menor que o de Hardhat/JS.
  • Hardhat
    • Vantagens: ecossistema rico de plugins (JS/TS); integração simples com ferramentas web3; experimental para EOF junto ao solc.
    • Desvantagens: suíte de testes/fuzzing não é nativa como no Foundry (exige libs adicionais).

Escolha: Foundry como base (testes, build, fuzzing), mantendo Hardhat como apoio quando plugins do ecossistema JS forem convenientes.

Motivos: alinhado à toolchain recomendada (Foundry Fuzzing + SAST/DAST), velocidade e integração em CI.

Versão do compilador Solidity e EVM alvo

A versão do compilador solc e a configuração da EVM determinam o conjunto de instruções suportadas, otimizações aplicadas, semântica das operações e compatibilidade com recursos recentes (como EIPs específicos). Esses parâmetros também balizam a ferramenta de lint, os artefatos ABI e as bibliotecas de terceiros utilizadas.

Fixar esses parâmetros evita divergências entre ambientes, garante reproducibilidade do bytecode e dá previsibilidade a quem executa scanners e fuzzers, principalmente em fases de validação cruzada. Isso facilita o reaproveitamento dos mesmos artefatos nos testes automatizados e nos exercícios de hardening que antecedem o estudo de caso.

Mudanças relevantes (risco de quebra)

  • ≥0.8.20: PUSH0 habilitado por padrão (Shanghai). Ambientes que não suportam Shanghai podem falhar se não fixarmos a EVM.
  • ≥0.8.24 (Cancun): suporte a EIP-1153 (TSTORE/TLOAD); requer executores/ambientes atualizados.
  • 0.8.28: introduz transient (armazenamento transitório); demanda toolchain recente.
  • 0.8.29: suporte experimental a EOF; ecossistema ainda em evolução.
  • 0.8.30: evmVersion padrão passa a prague (Pectra).

Opções consideradas

  • 0.8.19 (pré-Shanghai)
    • Vantagens: máxima compatibilidade retro; evita PUSH0.
    • Desvantagens: fica atrás de correções/otimizador; desalinhado com redes atuais.
  • 0.8.26 (linha estável Cancun)
    • Vantagens: equilíbrio entre modernidade e compatibilidade de ferramentas (Slither/Echidna/Foundry).
    • Desvantagens: sem features mais novas (p.ex., transient).
  • 0.8.30 (padrão atual)
    • Vantagens: alinha com estado da arte do compilador; compatível com Sepolia.
    • Desvantagens: evmVersion padrão = prague; parte da tooling (especialmente execução simbólica/concólica) pode não cobrir plenamente novas instruções/semânticas.

Escolha: Solidity 0.8.30 com evmVersion = "cancun" no build.

Motivos: Sepolia já suporta Cancun; manter cancun como alvo reduz atrito com ferramentas dinâmicas enquanto preserva correções e otimizações recentes do compilador. Como alternativa de "compat máxima", manter perfil 0.8.26 (também cancun).

Notas operacionais

  • Evitar transient e EOF em produção por ora (usar apenas em branches de P&D).
  • Se houver necessidade de compatibilidade com ambientes pré-Shanghai, usar 0.8.19 ou compilar para 0.8.20+ com evmVersion = "paris".

Plataforma de CI/CD

A plataforma de CI/CD (Continuous Integration/Continuous Delivery) é o serviço que automatiza builds, testes, varreduras e entregas a partir dos commits no repositório. Ela provê orquestração de estágios, isolamento de jobs, infraestrutura compartilhada ou dedicada, gerenciamento de credenciais e coleta de artefatos para auditoria.

Escolher a plataforma adequada garante que os scanners de segurança sejam executados de forma consistente, que o feedback chegue rapidamente às squads e que os resultados fiquem rastreáveis para governança do pipeline. No contexto do projeto, essa decisão também viabiliza consolidação de métricas de qualidade e bloqueios automáticos antes dos marcos de entrega.

Opções consideradas

  • Jenkins + Docker
    • Vantagens: controle fino de ambiente e credenciais; paralelismo; fácil isolar scanners (SAST/DAST/SCA) em contêineres.
    • Desvantagens: demanda manutenção da infraestrutura.
  • GitHub Actions
    • Vantagens: integração nativa ao repositório; marketplace de actions pronto.
    • Desvantagens: runners compartilhados/limitações de rede; menos controle fino do ambiente.
  • GitLab CI
    • Vantagens: plataforma integrada (repo + CI); runners próprios.
    • Desvantagens: menos onipresente nos exemplos e integrações do ecossistema web3.

Escolha: Jenkins + Docker (com execução local via Anvil para testes), publicando resultados e gates.

Motivos: necessidade de orquestrar SAST/DAST/SCA como stages formais do pipeline e bloquear merge por severidade; os relatórios de pesquisa e a matriz de responsabilidades pressupõem pipeline e gates explícitos.

Clone this wiki locally