*Forward the Original Title: Antes da atualização de Cancun, verificações de segurança essenciais para os desenvolvedores do projeto

TL;DR: Com a aproximação da atualização Cancun, inclui seis alterações propostas pelo EIP, principalmente EIP-1153, EIP-4788, EIP-4844, EIP-5656, EIP-6780 e EIP-7516. O EIP-4844 concentra-se em melhorar a escalabilidade do Ethereum, reduzir os custos de transação e acelerar as transações para soluções de Camada 2. A atualização foi testada em testnets do Ethereum e está agendada para ser ativada na mainnet em 13 de março. Salus compilou importantes considerações de segurança para os desenvolvedores verificarem antes da atualização.

Revisão das Propostas EIP

Considerações Oficiais de Segurança

Riscos relacionados com contratos inteligentes

Leitura adicional

Revisão das Propostas EIP

EIP-1153

EIP-1153 introduz opcode de armazenamento temporário, que são usados para manipular o estado de forma semelhante ao armazenamento, mas com o armazenamento temporário sendo descartado após cada transação. Isto significa que o armazenamento temporário não deserializa valores do armazenamento, nem serializa valores para o armazenamento, resultando em custos mais baixos devido à evitação do acesso ao disco. Com a introdução de dois novos opcodes, TLOAD e TSTORE (onde "T" significa "temporário"), contratos inteligentes podem acessar o armazenamento temporário. Esta proposta tem como objetivo fornecer uma solução dedicada e eficiente para a comunicação entre múltiplos quadros de execução aninhados durante a execução da transação no Ethereum.

EIP-4788

O EIP-4788 tem como objetivo expor as raízes da árvore de hash dos blocos da cadeia de beacons ao EVM, permitindo que essas raízes sejam acedidas dentro de contratos inteligentes. Isso possibilita o acesso ao estado da camada de consenso sem confiança, suportando vários casos de uso, como pools de stake, estruturas de restake, pontes de contratos inteligentes e mitigação de MEV. A proposta alcança isso armazenando essas raízes em um contrato inteligente e usando um buffer circular para limitar o consumo de armazenamento, garantindo que cada bloco de execução requer apenas espaço constante para representar essas informações.

EIP-4844

EIP-4844 introduz um novo formato de transação chamado "Transações de Bloco de Shard" projetado para expandir a disponibilidade de dados do Ethereum de forma simples e compatível com versões anteriores. Esta proposta alcança seu objetivo introduzindo "transações de transporte de blob" contendo grandes quantidades de dados que não podem ser acessados pelo EVM, mas podem ser acessados por seus compromissos. Este formato é totalmente compatível com o formato usado pelo futuro completo sharding, proporcionando um alívio temporário, mas significativo, para a escalabilidade do rollup.

EIP-5656

EIP-5656 introduz uma nova instrução EVM, MCOPY, para cópia eficiente de regiões de memória. Esta proposta tem como objetivo reduzir o overhead das operações de cópia de memória no EVM, copiando diretamente dados entre memórias usando a instrução MCOPY. MCOPY permite a sobreposição de endereços de origem e destino, projetada com compatibilidade retroativa em mente, e tem como objetivo melhorar a eficiência de execução em vários cenários, incluindo construção de estruturas de dados, acesso eficiente e cópia de objetos de memória.

EIP-6780

EIP-6780 modifica a funcionalidade do opcode SELFDESTRUCT. Nesta proposta, SELFDESTRUCT apenas elimina contas e transfere todo o ether na mesma transação de criação do contrato. Além disso, ao executar SELFDESTRUCT, o contrato não será eliminado, mas transferirá todo o ether para um destino especificado. Esta alteração acomoda o uso futuro de árvores Verkle, com o objetivo de simplificar a implementação do EVM, reduzir a complexidade das mudanças de estado, mantendo alguns casos de uso comuns de SELFDESTRUCT.

EIP-7516

O EIP-7516 introduz uma nova instrução EVM, BLOBBASEFEE, para devolver o valor da taxa base para blobs na execução do bloco atual. Esta instrução é semelhante à opcode BASEFEE introduzida no EIP-3198, com a diferença de que devolve a taxa base do blob definida de acordo com o EIP-4844. Esta funcionalidade permite que contratos considerem programaticamente o preço do gás de dados de blob, permitindo que contratos de rollup calculem os custos de utilização de dados de blob sem confiança ou implementem futuros de gás de blob para suavizar os custos de dados de blob.

Considerações Oficiais de Segurança

EIP-1153

Os desenvolvedores de contratos inteligentes devem compreender o ciclo de vida das variáveis de armazenamento transitório antes de as usar. Uma vez que o armazenamento temporário é automaticamente limpo no final de uma transação, os desenvolvedores de contratos inteligentes podem tentar evitar a limpeza de slots durante uma chamada para poupar gás. No entanto, isso poderia impedir uma interação adicional com o contrato na mesma transação (por exemplo, no caso de bloqueios recursivos) ou levar a outros erros. Portanto, os desenvolvedores de contratos inteligentes devem ser cautelosos e apenas reter valores não nulos quando o slot de armazenamento temporário estiver reservado para chamadas futuras dentro da mesma transação. Caso contrário, o comportamento destes opcodes é idêntico ao de SLOAD e SSTORE, portanto, todas as considerações de segurança comuns se aplicam, especialmente em relação aos riscos de recursividade.

Os programadores de contratos inteligentes também podem tentar utilizar o armazenamento transitório como alternativa ao mapeamento de memória. Devem estar cientes de que o armazenamento transitório não é descartado como a memória quando uma chamada retorna ou é revertida e devem priorizar a memória em tais casos de uso para evitar comportamentos inesperados durante a reentrada na mesma transação. O alto custo do armazenamento transitório na memória já deve desencorajar esse padrão de uso. A maioria dos casos de uso para mapeamentos em memória pode ser melhor implementada através de uma lista ordenada de entradas por chave, e o armazenamento transitório em mapeamentos de memória raramente é necessário em contratos inteligentes (ou seja, não existem casos de uso conhecidos em produção).

EIP-4844

Esta EIP aumenta os requisitos de largura de banda para cada bloco de farol em até aproximadamente 0,75 MB. Este é um aumento de 40% sobre o tamanho máximo teórico dos blocos de hoje (30M Gas / 16 Gas por byte de calldata = 1,875M bytes), portanto, não aumenta significativamente a largura de banda em cenários de pior caso. Após a fusão, os tempos de bloco são estáticos em vez de distribuídos de forma imprevisível de Poisson, fornecendo um período de tempo garantido para a propagação de blocos grandes.

Mesmo com dados de chamada limitados, a carga sustentada deste EIP é significativamente menor do que soluções alternativas que poderiam reduzir o custo dos dados de chamada, pois o armazenamento de Blob não precisa ser retido pelo mesmo período que a carga de execução. Isso torna possível implementar estratégias que exigem que esses blobs sejam retidos por pelo menos um período de tempo. O valor específico escolhido é o MIN_EPOCHS_FOR_BLOB_SIDECARS_REQUESTS epoch, que é aproximadamente 18 dias, muito mais curto do que o tempo de rotação proposto (mas ainda não implementado) de um ano para a execução de históricos de carga válidos.

EIP-5656

Os clientes devem estar atentos para que as suas implementações não usem buffers intermediários (por exemplo, a função de memmove da biblioteca padrão C não utiliza buffers intermediários) pois este é um potencial vetor de negação de serviço (DoS). A maioria das funções integradas de linguagem/funções de biblioteca padrão usadas para mover bytes têm as características de desempenho corretas aqui.

Além disso, a análise de ataques de negação de serviço (DoS) e de esgotamento de memória é a mesma que para outros códigos de operação que tocam a memória, uma vez que a expansão da memória segue as mesmas regras de preços.

EIP-6780

As seguintes aplicações de SELFDESTRUCT serão quebradas, e as aplicações que a utilizam desta forma já não são seguras:

Onde o CREATE2 é usado para redeploy um contrato no mesmo local para tornar os contratos atualizáveis. Esta funcionalidade já não é suportada e deve ser substituída pelo ERC-2535 ou outros tipos de contratos de proxy.

Se um contrato depende de queimar ether para um contrato via SELFDESTRUCT como beneficiário, o contrato não é criado na mesma transação.

Riscos Relacionados a Contratos Inteligentes

EIP1153

Considere dois cenários usando os opcodes TLOAD e TSTORE:

1. Contratos chamados usam esses opcodes.
2. Os contratos de chamada usam esses opcodes.

Risco 1:

Comparado com o SSTORE e SLOAD tradicionais, a introdução de armazenamento transitório altera principalmente a duração do armazenamento de dados. Os dados armazenados pelo TSTORE são lidos através do TLOAD e serão liberados após a execução de uma transação, em vez de serem registrados permanentemente no contrato como o SSTORE. Os desenvolvedores devem entender as características desses opcodes ao usá-los para evitar o uso incorreto, o que pode resultar em dados não sendo gravados corretamente no contrato, causando perdas. Além disso, os dados armazenados pelo TSTORE são privados e só podem ser acessados pelo contrato em si. Se for necessário acesso externo a esses dados, eles devem ser passados através de parâmetros ou armazenados temporariamente em uma variável de armazenamento pública.

Risco 2:

Outro risco potencial é que, se os desenvolvedores de contratos inteligentes não gerirem corretamente o ciclo de vida das variáveis de armazenamento transitório, isso pode levar a dados serem apagados em momentos inapropriados ou retidos incorretamente. Se um contrato espera usar dados armazenados em armazenamento transitório em chamadas subsequentes de uma transação, mas não consegue gerir corretamente o ciclo de vida desses dados, pode partilhar ou perder dados entre chamadas diferentes, resultando em erros lógicos ou vulnerabilidades de segurança. A falha em armazenar dados corretamente, como dados de saldo ou de permissão em projetos de tokens, pode levar a erros de lógica em contratos, causando perdas. Da mesma forma, usar estes opcodes para definir o endereço do proprietário pode resultar no endereço privilegiado não ser gravado corretamente, levando à perda de modificações em parâmetros importantes do contrato.

Considere um contrato inteligente que utiliza armazenamento transitório para registar temporariamente o preço da transação numa plataforma de negociação de criptomoedas. O contrato atualiza o preço após cada transação e permite aos utilizadores consultar o preço mais recente num curto período de tempo. No entanto, se o design do contrato não considerar a limpeza automática do armazenamento transitório no final de uma transação, pode haver um período entre o final de uma transação e o início da próxima em que os utilizadores possam receber um preço incorreto ou desatualizado. Isso não só poderia levar os utilizadores a tomar decisões com base em informações incorretas, mas também poderia ser explorado maliciosamente, afetando a reputação da plataforma e a segurança dos ativos dos utilizadores.

EIP-6780

Esta proposta altera o comportamento do código de operação de autodestruição anterior, onde o contrato não é queimado, mas apenas a transferência de tokens ocorre, e apenas os contratos criados na mesma transação que o contrato de autodestruição serão queimados. O impacto deste EIP é relativamente significativo.

Usar create2 para reimplantar contratos no mesmo endereço para atualizações de contrato já não é suportado. Esta funcionalidade deve ser substituída por ERC-2535 ou outros tipos de contratos de procuração. (Isso pode afetar a segurança decontratos on-chainimplementando contratos atualizáveis usando create2).

A operação SELFDESTRUCT em contratos inteligentes permite que os contratos sejam queimados, e o saldo do contrato seja enviado para um endereço de destino especificado. Neste caso, o contrato usa SELFDESTRUCT para queimar Ether e envia o Ether queimado para o contrato. No entanto, este contrato só deve ser criado na mesma transação que outros contratos (contratos criados por este contrato ou outros contratos na mesma transação). Caso contrário, o Ether será apenas transferido sem queimar o contrato (por exemplo, a auto-destruição com o beneficiário sendo o contrato de auto-destruição, o que não produzirá quaisquer mudanças). Isto afetará todos contratosque dependem da função selfdestruct para levantamentos ou outras operações.

Um Token de Gás semelhante ao Token CHI 1inch funciona da seguinte forma: mantendo um deslocamento, sempre implementando CREATE2 ou SELFDESTRUCT neste deslocamento. Após esta atualização, se o contrato no deslocamento atual não tiver sido corretamente auto-destruído, os CREATE2 subsequentes não poderão implantar contratos com sucesso.

Esta implementação de proposta não pode atacar diretamente contratos, mas irá danificar a lógica normal dos contratos existentes que dependem de operações de autodestruição (contratos que dependem apenas de autodestruição para transferências de fundos não são afetados, mas contratos que exigem operações subsequentes para excluir contratos de autodestruição são afetados), causando que os contratos funcionem inesperadamente, e pode levar a greves de contratos, perda de fundos, etc. (por exemplo, contratos que originalmente usavam create2 para implantar novos contratos no endereço original e autodestruíam o contrato original para atualização, não podem mais ser implantados com sucesso). A longo prazo, modificar a funcionalidade de um opcode pode trazer problemas de centralização.

Por exemplo, existe um contrato de cofre existente para atualizações:

• Contratos de armazenamento temporário, create2, são usados para reservar temporariamente fundos para o cofre.
• Destruir o contrato da cúpula, transferindo fundos para o contrato temporário (apenas os fundos são transferidos sem queimar o contrato).
• Criar um novo contrato de cofre no endereço original usando create2 (falha porque o contrato de cofre original não foi queimado).
• Autodestruir o contrato temporário para devolver os fundos ao cofre (fundos perdidos, o contrato do cofre não foi criado).

Leitura adicional:

A atualização de Cancun irá melhorar ainda mais a vantagem competitiva do Ethereum. No entanto, as alterações na camada central do contrato inteligente nesta atualização trazem riscos que afetarão a operação segura das DApps existentes. Durante o desenvolvimento do contrato inteligente, essas alterações e os riscos potenciais que podem trazer precisam ser monitorados de perto. Você pode contatar Salus para verificações de riscos ou suporte de auditoria, ou leitura adicional para entender as mudanças.

Especificação da Atualização da Rede Cancun

EIP-1153

EIP-4788

EIP-4844

EIP-5656

EIP-6780

EIP-7516

contrato Metapod

contrato GasToken2

Aviso legal：

1. Este artigo é reimpresso de [Aicoin]Reencaminhe o Título Original 'Salus Insights: Antes da atualização de Cancún, várias verificações de segurança essenciais para os desenvolvedores de projetos'. Todos os direitos autorais pertencem ao autor original [*Odaily Planeta Diário]. Se houver objeções a esta reimpressão, por favor entre em contato com o Gate Learnequipa e eles vão lidar com isso prontamente.
2. Responsabilidade Legal: As opiniões expressas neste artigo são exclusivamente do autor e não constituem qualquer conselho de investimento.
3. As traduções do artigo para outros idiomas são realizadas pela equipe Gate Learn. Salvo indicação em contrário, é proibido copiar, distribuir ou plagiar os artigos traduzidos.