Segundo o site oficial , os contratos inteligentes da Ethereum são executados “exatamente conforme programado, sem possibilidade de inatividade, censura, fraude ou interferência de terceiros”. Hoje, tentarei descobrir se tudo é tão otimista, tendo examinado alguns dos problemas que os usuários inteligentes de contratos enfrentam na prática.
No final do artigo, resumi meus pensamentos com um breve guia para escrever contratos inteligentes e seguros.
- Este artigo focará apenas nos contratos inteligentes da Ethereum. A comunidade identificou tacitamente os contratos inteligentes com os contratos inteligentes da Ethereum. Enquanto isso, o primeiro é mais um conceito, e o segundo é a implementação, e a questão de como essa implementação atende ao conceito pode ser discutida (bem como, em princípio, o próprio conceito de contratos inteligentes e outras implementações possíveis). Este tópico é complexo, subestimado e interessante, mas este não é o tópico deste artigo, por isso vou referir os interessados nos trabalhos de Nick Szabo . Assim, em todo o lado, onde digo "contratos inteligentes", na verdade quero dizer "contratos inteligentes Ethereum".
- O artigo focará apenas a linguagem dos contratos inteligentes Solidity como o mais popular e, para o usuário do Ethereum, de fato, o único no momento.
Problemas de segurança de contrato inteligente
Será sobre os problemas que os desenvolvedores de contratos inteligentes enfrentam no final, e não sobre a segurança da própria plataforma (embora um pouco sobre isso). Convencionalmente, dividimos esses problemas nos seguintes tipos:
- problemas no código do contrato inteligente;
- problemas no processo de desenvolvimento;
- problemas na linguagem;
- problemas no conceito.
1. Problemas no código do contrato inteligente
Por problemas no código de um contrato inteligente aqui, quero dizer problemas resolvidos com a edição do arquivo .sol. Isto é em particular:
- Construções vulneráveis conhecidas (por exemplo , reentrada ).
Exemplo de vida : reentrada ou, mais amplamente, violação do padrão Cheques-Efeitos-Interações - até mesmo vulnerabilidades amplamente conhecidas (e previamente exploradas ) continuam sendo encontradas em novos contratos. - Construções vulneráveis do autor (em particular, erros na lógica do código).
Exemplo de vida : uma carteira MultiSig que na verdade não é uma MultiSig. Para assinar uma transação e transferir fundos, você precisa do número de assinaturas dos proprietários da carteira igual ao required . Ao mesmo tempo, para alterar o required (por exemplo, por um, para assinar mais transações por si mesmo), basta a assinatura de um dos proprietários:
- Arquitetura ruim.
Exemplo de vida : uma tentativa de implementar um token, uma carteira e um armazenamento de chaves em um único contrato. O contrato acaba por ser excessivamente complicado, o código é difícil de manter, auditar, modificar. Como resultado, a segurança também sofre. - Código de baixa qualidade.
Exemplo de vida : contratos com recuos diferentes, quebras de linha arbitrárias e espaços. O código é difícil de ler, o que significa que a segurança sofre novamente. Apesar do fato de já existirem linters para Solidity ( Solium , Solhit ).
Problemas no código levam diretamente a ataques e perda de fundos. A boa notícia é que os problemas de código podem ser identificados durante o processo de auditoria e resolvidos. É importante entender de onde eles vêm para evitá-los no futuro. Portanto, passamos ao próximo parágrafo.
2. Problemas no processo de desenvolvimento
Os problemas no código são causados principalmente por um processo de desenvolvimento criado incorretamente. Parece que o desenvolvimento de software é um negócio estudado há muito tempo com as melhores práticas estabelecidas. No entanto, os jovens da área de contratos inteligentes, dinheiro desproporcionalmente grande e hype levam ao fato de que as pessoas, por um motivo ou outro, negligenciam os procedimentos padrão, o que geralmente leva a problemas sérios. Das mais típicas, vale ressaltar:
- TK: A maioria dos contratos inteligentes da Ethereum são escritos sem uma tarefa técnica. Para o que isso pode levar, para explicar desnecessariamente.
- Tempo: em média, muito pouco tempo é alocado para o desenvolvimento, cerca de um mês. Um exemplo extremo da minha prática: o cliente pediu ao desenvolvedor que escrevesse um contrato inteligente três dias antes da OIC.
- Nível de desenvolvedor: muitas pessoas entram em campo, inclusive sem um histórico de programação.
- Entendendo o ecossistema: e mesmo que com um histórico, geralmente os desenvolvedores não estão profundamente imersos no tópico e não entendem as especificidades dos contratos inteligentes.
- Custo de desenvolvimento: e, no entanto, aqueles que escrevem contratos inteligentes são poucos; menos ainda quem os escreve bem. Daí o custo irracionalmente alto do desenvolvimento.
3. Problemas no idioma
Adiciona alcatrão à linguagem do Solidity. Inicialmente, ele foi criado mais para que pudesse ser rapidamente dominado por um grande número de pessoas, do que para tornar conveniente a criação de contratos inteligentes e seguros. Aqui estão apenas alguns dos recursos que interferem na segurança:
- Herança múltipla,
using for , call / delegate call - tudo isso inicia o código, não da fonte atual, o que significa que reduz a legibilidade e, como resultado, a segurança do código. - Padrão Cheques-Efeitos-Interações - se construções que violam a CEI não são seguras, por que não proibi-las (e muitas outras) simplesmente no nível do idioma?
- Ao chamar outro contrato, você pode repentinamente cair na função de fallback com consequências inesperadas.
É claro que o projeto Ethereum está em desenvolvimento e é impossível levar tudo em conta com antecedência. Mas, no final, os desenvolvedores são forçados a se lembrar de muitos recursos e a usar muletas para garantir seu contrato inteligente.
4. Problemas no conceito
No entanto, o problema mais sério é ainda mais profundo - que muitos não entendem bem o porquê de contratos inteligentes serem necessários, o que podem, o que não podem e como funcionam. Na pior das hipóteses, isso leva ao fato de que o contrato inteligente:
Não é inteligente:
- Mal escrito - faz o que está escrito, mas não o que se destina.
- Está fortemente vinculado ao back-end e / ou front-end - e esse código não é mais um contrato inteligente, é executado da maneira usual e sua implementação é completamente controlada pelo administrador do servidor.
Não é um contrato:
- Ele não registra as obrigações das partes - por exemplo, a OIC vende seus tokens pela ETH, mas os tokens são essencialmente embalagens de doces, porque não imponha a quem os libertou quaisquer restrições ou obrigações.
- Permite alterações unilaterais - e uma das partes pode alterar o contrato após sua assinatura.
Exemplo de vida : o proprietário do contrato pode alterar arbitrariamente a capitalização, taxa e duração da venda do token:
Não é necessário:
- O contrato inteligente foi adicionado não porque era tecnicamente necessário, mas na tentativa de descobrir o que fazer nos contratos inteligentes e gerar uma onda de hype;
- Tentamos descobrir como vincular contratos inteligentes a um produto existente.
Contrato inteligente como uma ameaça de segurança para inicialização de blockchain
Qual é o resultado? Eles queriam que fosse moda, segura, blockchain, mas temos um código caro e não suportado, que ameaça a segurança e não é necessário. Queríamos que nossos contratos inteligentes fossem executados “exatamente como programado, sem possibilidade de tempo de inatividade, censura, fraude ou intervenção de terceiros” e, no final, eles realmente são executados conforme são escritos - eles são apenas escritos com vulnerabilidade. E tudo o que resta para nós é agitar uma caneta à nossa maneira. Bem, ou fazer um trabalho duro (com isso desacreditando a idéia original) se os criadores do Ethereum perderem dinheiro devido à vulnerabilidade.
Como escrever contratos inteligentes seguros
De fato, é claro, nem tudo é tão ruim. Eu apenas exagerei na tentativa de chamar a atenção para alguns pontos importantes, na minha opinião,. Em geral, a área está se desenvolvendo, as pessoas estão aprendendo, incluindo a segurança.
Se o leitor decidir escrever um contrato inteligente, aconselho:
- entender por que um contrato inteligente é necessário (e se é necessário);
- receber do cliente ou escrever TK;
- calcular tempo;
- use ferramentas de desenvolvimento e teste ( Trufa , Remix , SmartCheck , Solhint ou Solium );
- escrever testes;
- realizar várias auditorias independentes e recompensas por bugs;
- monitorar a segurança dos demais componentes do projeto (site, Twitter, etc.).
Seguindo essas recomendações simples, você pode evitar a maioria dos problemas descritos acima (de um garfo rígido, no entanto, isso ainda não será salvo).
O artigo foi criado em conjunto com Eugene Marchenko ( eMarchenko ).