Diário de Desenvolvimento de Contratos Inteligentes Rust (9) Atualização de Contrato

Os contratos inteligentes são essencialmente programas, e falhas são difíceis de evitar. Mesmo contratos inteligentes que passaram por muitos testes e auditorias ainda podem ter vulnerabilidades. Uma vez que uma vulnerabilidade do contrato é explorada por um atacante, pode resultar na perda de ativos dos usuários, com consequências graves. A correção de vulnerabilidades geralmente requer uma atualização do contrato. Além de corrigir vulnerabilidades, a adição de novas funcionalidades também exige a atualização do contrato. Portanto, a capacidade de atualização do contrato é muito importante. Este artigo irá introduzir os métodos de atualização de contratos Rust.

1. Formas comuns de atualização de contratos Solidity

Os contratos inteligentes do Ethereum têm imutabilidade, não podem ser alterados após a sua implementação. Se houver falhas no contrato ou se forem necessárias novas funcionalidades, apenas um novo contrato pode ser implementado na blockchain.

O desafio enfrentado por este método é que, após cada implantação de contrato, um novo endereço é atribuído. Todos os DApps que utilizam esse contrato precisam modificar o endereço do contrato para se adaptar ao novo contrato. Além disso, o estado do contrato da versão antiga precisa ser migrado para a nova versão, e a migração de estado de contratos complexos é trabalhosa e propensa a erros.

Portanto, normalmente utiliza-se uma arquitetura que separa os dados da lógica, armazenando os dados em um contrato de estado que não processa lógica, enquanto toda a lógica é implementada em outro contrato lógico. Assim, durante a atualização, é necessário apenas atualizar o contrato lógico, sem a necessidade de considerar a migração de estado.

Para resolver este problema, pode-se usar um contrato de proxy (Proxy Contract). O contrato de proxy é utilizado para armazenar dados e utiliza deleGatecall para chamar o contrato lógico A, assim os dados lidos e escritos pelo contrato A são armazenados no contrato de proxy. Na atualização, implanta-se um novo contrato B e, em seguida, envia-se uma transação para que o contrato de proxy aponte para o novo contrato lógico B.

2. Métodos Comuns para Atualização de Contratos NEAR

Usando o projeto StatusMessage como exemplo, apresentamos os métodos comuns de atualização de contratos NEAR.

2.1 A estrutura de dados do contrato não foi alterada

Se apenas modificar a lógica do contrato, sem envolver alterações na estrutura de dados, pode usar diretamente o near deploy para implantar o novo código. Os dados no contrato antigo podem ser lidos com sucesso.

2.2 A estrutura de dados do contrato foi alterada

Se a estrutura de dados do contrato for modificada, a reimplementação direta resultará na impossibilidade de desserializar o estado do contrato. Isso ocorre porque o estado do contrato é armazenado de forma persistente em formato de dados serializados; após a reimplementação, a estrutura de dados no código muda, mas o estado permanece o mesmo, e a nova estrutura de dados não consegue corresponder ao estado antigo.

2.3 Migrar contratos inteligentes

A NEAR oferece o método Migrate para ajudar a atualizar contratos. Adicione o método migrate ao novo contrato:

ferrugem #[private] #[init(ignore_state)] Self { let old_state: OldStatusMessage = env::state_read().expect('failed'); Self { taglines: old_state.records, bios: LookupMap::new(b'b'.to_vec)((, } }

Chamar o método migrate ao reimplantar contratos:

perto de implantar
--wasmFile target/wasm32-unknown-unknown/release/status_message.wasm
--initFunction 'migrate' \ --initArgs '{}'
--accountId statusmessage.blocksec_upgrade.testnet

Dessa forma, é possível implantar novos contratos e migrar dados antigos.

![])https://img-cdn.gateio.im/webp-social/moments-73f5e5195fa71f1f25f5d35ba1e8b8ec.webp)

3. Considerações de segurança sobre a atualização de contratos

A atualização de segurança do contrato deve considerar primeiro o controle de permissões. Geralmente, apenas o desenvolvedor ou o DAO pode atualizar o contrato. A função de atualização deve ser uma função only owner, garantindo que só possa ser chamada pelo owner.

Sugere-se que o owner do contrato seja definido como DAO, gerindo o contrato em conjunto através de propostas e votação. Contas pessoais como owner levarão a uma alta centralização do contrato, onde o owner pode alterar os dados do contrato à vontade, além do risco de perda da chave privada.

Além disso, os desenvolvedores ao realizar a migração de contratos, podem considerar as seguintes sugestões:

• Adicione #[init(ignore_state)] antes da função de migração, garantindo que o estado não seja carregado antes da execução da função de migração.
• Após a migração, elimine a função de migração para garantir que a função de migração seja chamada apenas uma vez.
• A nova estrutura de dados é inicializada durante a migração.