2. Sobre mim
● Trabalho com Solidty há ~5 anos.
● ~3 Anos trabalhando exclusivamente com auditor de smart contracts.
● Desenvolvedor full time num protocolo de Defi.
● Desenvolvi alguns projetos de NFT paralelamente.
3. O que é segurança
1. Garantir que o smart contract faz o que você quer.
2. Garantir que o smart contract não faz o que você não quer.
6. Segurança é um espectro
● Nenhum Smart Contract é 100% seguro.
● Relativo ao "valor" do contrato.
● Relativo ao tempo de uso do contrato.
● SEGURANÇA É UM PROCESSO.
7. Vulnerabilidades comuns
● Ethereum Smart Contract Security Recommendations
● List of security vulnerabilities
● Smart contract vulnerabilities
11. Unit Test
● Garantir que a menor "unidade" do seu código funciona.
● Isolar ao máximo fatores e elementos externos.
● Mais fácil para funções puras.
● Geralmente, é o ponto mais fácil de começar.
● Faz-se o uso de mocks e harnesses.
13. Integration Tests
● Testar que diferentes elementos do código funcionam juntos.
● Testar que diferentes contratos do protocolo funcionam juntos.
● Preferencialmente não utilizar mocks e harnesses.
● Mais proveitoso quando já se sabe que os elementos funcionam
individualmente.
14. Fuzz Tests
Casos de testes que aceitam inputs aleatórios.
● Bom para descobrir edge cases.
● Bom para entender/definir quais são os limites do código.
● Delegar parte do trabalho de pensar em cenários para um software.
● Pode ser feito tanto em unit tests quanto em integration tests.
16. Invariant testing
Bombardear o contrato ou protocolo com transações aleatórias para garantir
que algumas condições sejam sempre verdadeiras.
● Bom para descobrir edge cases.
● Bom para determinar quais são os estados desejáveis do contrato.
● Requer um bom tempo para montar a infraestrutura do código.
18. User testing
Em um ambiente controlado, fazer exatamente o que o usuário fará.
● Inclui testar a interface.
● Idealmente feito por pessoas que não desenvolveram.
● Bom para achar erros que não são "exclusivos" dos smart contracts.
● É bastante trabalhoso.
● Umas das últimas fases antes do release.
19. Verificacao Formal
É o processo de elaborar uma prova matemática abstrata que corresponde ao
funcionamento do sistema.
● É uma mistura de teste e auditoria.
● É bem caro e complexo.
● Bom para tipos específicos de contratos.
22. O que é uma auditoria
Processo de analisar o código, por diversos métodos, a fim de achar falhas.
● É necessário que haja o distanciamento entre o auditor e o desenvolvedor.
● São custosas e demoradas.
● Bom para achar erros nos "pontos cegos" dos desenvolvedores.
24. Auditoria Externa
Delegar para terceiros, ou indivíduos ou empresas, que analisam o código.
● Cada auditor tem seu método próprio.
● Não é garantia de segurança.
● As baratas geralmente são ruins.
O "resultado" é um relatório para os desenvolvedores sobre potenciais
problemas no código.
25. Crowd Audits / Bug Bounties
Ao invés de contratar uma única empresa para realizar uma auditoria, pública-se
o código e se oferece recompensas para quem achar problemas.
● Os "incentivos" dos auditores são diferentes
● Tende a ser mais barata que uma auditoria externa.
● Não se tem a métrica de quem analisou o código.
Exemplos: Code4rena e Immunefi
26. Guarded Launches
Deployar o sistema com "guardas", que são removidas lentamente, à medida que
se ganha confiança no código.
● Forma de diminuir o risco e impacto de potenciais problemas.
● Recomendável para a maioria dos contratos/protocolos.
