Como lidar com mudanças de endereço crítico em contratos inteligentes

O que se entende por mudança de endereço crítico?

Os endereços críticos em contratos inteligentes devem ser alterados com duas transações simples:

1. A primeira transação (proveniente do endereço antigo/atual) registrando o novo endereço (concessão de propriedade) e
2. A segunda transação (originada do novo endereço) substituindo o endereço antigo pelo novo (ou seja, reivindica a propriedade).

Isto oferece uma chance de corrigir qualquer endereço impreciso que tenha sido usado acidentalmente na primeira etapa. Caso contrário, a funcionalidade do contrato pode perder a propriedade ou introduzir endereços maliciosos ou incorretos.

Entendendo o controle de acesso e reivindicação de propriedade em contratos inteligentes:

Gerenciamento do controle de acesso:

O conceito de controle de acesso, ou "quem tem permissão para realizar isto", é crucial no contexto de contratos inteligentes. O controle de acesso de seu contrato pode determinar quem pode emitir tokens, votar em iniciativas, interromper transferências e muitas outras coisas. Para evitar que outra pessoa roube todo o seu sistema, é crucial implementar modificadores de controle de acesso adequados.

Reivindicar Ownership e Ownable:

O conceito de propriedade (ownership) é o tipo mais prevalente e fundamental de controle de acesso: há uma conta que é a proprietária de um contrato e tem acesso administrativo a ele. Para contratos com um único usuário administrativo, esta estratégia é razoável.

A conta que implantou o Contrato Ownable por padrão é seu proprietário, que é normalmente o que você deseja.

O Ownable permite que você:

• transferOwnership: para uma nova conta a partir da conta do proprietário e
• renounceOwnership: após uma fase inicial de administração centralizada estar completa, a propriedade normalmente exige que o proprietário desista deste privilégio administrativo.

Controle de Acesso Baseado em Função (Papel):

Embora sistemas simples ou prototipagem rápida possam se beneficiar da simplicidade da propriedade, vários graus de autorização são frequentemente necessários. Você pode querer que uma conta possa remover usuários de um sistema, mas que não possa adicionar novos tokens. É aqui que o controle de acesso baseado em funções (RBAC) é flexível.

Em essência, vamos estabelecer vários papéis (funções), cada um dos quais terá um conjunto específico de ações permitidas. Ao invés de apenas usar o onlyOwner, você deve verificar se uma conta tem algum papel adicional, como "moderador", "minerador" ou "administrador". Você pode estabelecer diretrizes de como as contas podem receber um papel, revogá-lo e mais separadamente.

Como usar o Controle de Acesso?

O contrato Access Control do OpenZeppelin permite implementar o controle de acesso baseado em função (papel). Para cada função que você define, você produz um novo identificador de função, que é então utilizado para conceder, revogar e verificar se uma conta tem esse papel.

Mesmo sendo óbvio e explícito, o Ownable teria nos permitido realizar a mesma coisa. De fato, situações que requerem permissões granulares, que podem ser alcançadas através da criação de inúmeros papéis, são onde o AccessControl realmente se sobressai.

Melhores práticas para mudança de endereço crítico em contratos inteligentes:

Usando o Ownable2Step:

Recomenda-se usar o contrato Ownable2Step do OpenZeppelin, que faz uso de mudança de endereço em duas etapas ou implementa funções similares em duas etapas em seu contrato:

1. A função transferOwnership() define o valor de _pendingOwner :

function transferOwnership(address newOwner) public virtual override onlyOwner {
   _pendingOwner = newOwner;
   emit OwnershipTransferStarted(owner(), newOwner);
}

1. A função acceptOwnership() é usada pelo novo proprietário para aceitar seu endereço:

function acceptOwnership() external {
address sender = _msgSender();
require(pendingOwner() == sender, "Ownable2Step: caller is not the new owner");
_transferOwnership(sender);
}

Fazendo uso do TimelockControler:

OTimelockController é um contrato que impõe um bloqueio de tempo em todas as operações de funções onlyOwner. Isto dá tempo aos usuários do contrato controlado para saírem antes que uma operação de manutenção potencialmente perigosa seja aplicada, como a atualização de um endereço crítico ou a mudança de propriedade.

Usando MultiSig

Os administradores e proprietários devem ser contas multisig (múltipla assinatura) para evitar um único ponto de falha. Isto significa basicamente que a mudança de um endereço crítico exigirá que vários usuários assinem a transação.Implementando Controles de Acesso

Finalmente, é importante garantir que todas as funções críticas que estejam adicionando ou modificando parâmetros de endereço, tenham modificadores de controle de acesso adequados que impedirão que usuários externos chamem as funções.

Conclusão:

Neste artigo, falamos sobre como as mudanças de endereço crítico e de propriedade podem levar à exploração, drenando todos os fundos se não forem tomadas as devidas medidas de mitigação. Você pode confiar em SolidityScan para garantir que sejam tomadas as medidas adequadas para atingir o mais alto nível de segurança do contrato inteligente. Inscreva-se para um teste gratuito em
https://solidityscan.com/signup

Esse artigo foi escrito por Shashank e traduzido por Fátima Lima. O original pode ser lido aqui.