Diário de Desenvolvimento de Contratos Inteligentes em Rust (7) Segurança do Contrato em Relação à Precisão de Cálculo
Este artigo apresentará o controle de permissões em contratos inteligentes Rust de duas perspectivas:
Visibilidade de acesso/chamada de métodos de contratos
Controle de acesso/funções de privilégio/divisão de responsabilidades
1. Visibilidade das funções de contrato
Definir adequadamente a visibilidade das funções do contrato é muito importante para proteger partes críticas de acessos ou manipulações acidentais. Tomemos como exemplo o incidente de segurança da Bancor Network em junho de 2020, onde a função de transferência crítica foi acidentalmente definida como pública, colocando os ativos dos usuários em risco.
Na programação de contratos inteligentes em Rust, a visibilidade das funções é principalmente das seguintes formas:
pub fn: função pública, pode ser chamada de fora do contrato
fn: Não pode ser chamado diretamente de fora, apenas pode ser chamado dentro do contrato.
pub(crate) fn: restringir chamadas ao escopo interno do crate
Outra forma de definir o método internal é definir um bloco de código impl Contract independente, sem usar o modificador #[near_bindgen].
A função de callback deve ser definida como pública, mas deve-se garantir que só pode ser chamada pelo próprio contrato. Pode-se usar a macro #[private] para implementar essa funcionalidade.
É importante notar que, por padrão, Rust considera todo o conteúdo como privado, exceto os itens em traits e enums.
2. Controle de acesso das funções privilegiadas
Além da visibilidade das funções, é necessário estabelecer um mecanismo completo de lista branca de controle de acesso a partir da camada semântica. Semelhante ao onlyOwner no Solidity, certas funções privilegiadas só podem ser chamadas pelo owner do contrato.
Em contratos inteligentes Rust, é possível implementar Trait personalizado para controlar o acesso a funções privilegiadas:
Esta página pode conter conteúdo de terceiros, que é fornecido apenas para fins informativos (não para representações/garantias) e não deve ser considerada como um endosso de suas opiniões pela Gate nem como aconselhamento financeiro ou profissional. Consulte a Isenção de responsabilidade para obter detalhes.
Práticas de segurança em contratos inteligentes Rust: visibilidade de funções e controlo de acesso privilegiado
Diário de Desenvolvimento de Contratos Inteligentes em Rust (7) Segurança do Contrato em Relação à Precisão de Cálculo
Este artigo apresentará o controle de permissões em contratos inteligentes Rust de duas perspectivas:
1. Visibilidade das funções de contrato
Definir adequadamente a visibilidade das funções do contrato é muito importante para proteger partes críticas de acessos ou manipulações acidentais. Tomemos como exemplo o incidente de segurança da Bancor Network em junho de 2020, onde a função de transferência crítica foi acidentalmente definida como pública, colocando os ativos dos usuários em risco.
Na programação de contratos inteligentes em Rust, a visibilidade das funções é principalmente das seguintes formas:
Outra forma de definir o método internal é definir um bloco de código impl Contract independente, sem usar o modificador #[near_bindgen].
A função de callback deve ser definida como pública, mas deve-se garantir que só pode ser chamada pelo próprio contrato. Pode-se usar a macro #[private] para implementar essa funcionalidade.
É importante notar que, por padrão, Rust considera todo o conteúdo como privado, exceto os itens em traits e enums.
2. Controle de acesso das funções privilegiadas
Além da visibilidade das funções, é necessário estabelecer um mecanismo completo de lista branca de controle de acesso a partir da camada semântica. Semelhante ao onlyOwner no Solidity, certas funções privilegiadas só podem ser chamadas pelo owner do contrato.
Em contratos inteligentes Rust, é possível implementar Trait personalizado para controlar o acesso a funções privilegiadas:
ferrugem pub trait Ownable { fn assert_owner(&self) { assert_eq!(env::predecessor_account_id(), self.get_owner()); } AccountId; fn set_owner(&mut self, owner: AccountId); }
Com base nisso, é possível implementar mecanismos de lista branca mais complexos, permitindo um controle de acesso em grupos mais detalhado.
3. Outros métodos de controlo de acesso
Há também outros métodos de controle de acesso, como:
Estes conteúdos serão detalhados em artigos posteriores.