*Forward the Original Title：坎昆升级前，项目开发者必看的几项安全检查

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

Revisão das Propostas de EIP

Considerações Oficiais de Segurança

Riscos relacionados a contratos inteligentes

Leitura adicional

Revisão das Propostas EIP

EIP-1153

O EIP-1153 introduz opcodes 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. Isso significa que o armazenamento temporário não desserializa valores do armazenamento, nem serializa valores para o armazenamento, resultando em custos mais baixos devido a evitar o acesso ao disco. Com a introdução de dois novos opcodes, TLOAD e TSTORE (onde "T" significa "temporário"), os contratos inteligentes podem acessar o armazenamento temporário. Esta proposta visa fornecer uma solução dedicada e eficiente para a comunicação entre vários quadros de execução aninhados durante a execução de transações em Ethereum.

EIP-4788

EIP-4788 tem como objetivo expor as raízes da árvore de hash dos blocos da cadeia de beacons para o EVM, permitindo que essas raízes sejam acessadas 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 aposta, estruturas de recomposição, 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 exija apenas espaço constante para representar essas informações.

EIP-4844

EIP-4844 introduz um novo formato de transação chamado “Transações de Shard Blob” 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 ao introduzir “transações de blob-carregamento” contendo grandes quantidades de dados que não podem ser acessados pela 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 a cópia eficiente de regiões de memória. Esta proposta visa reduzir a sobrecarga das operações de cópia de memória na EVM, copiando diretamente dados entre memórias usando a instrução MCOPY. MCOPY permite a sobreposição de endereços de origem e destino, projetado com compatibilidade reversa em mente, e visa 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

A EIP-6780 modifica a funcionalidade do opcode SELFDESTRUCT. Nesta proposta, SELFDESTRUCT só exclui contas e transfere todo o ether na mesma transação de criação de contrato. Além disso, ao executar SELFDESTRUCT, o contrato não será excluído, mas transferirá todo o ether para um alvo especificado. Essa mudança acomoda o uso futuro de árvores Verkle, visando simplificar a implementação do EVM, reduzir a complexidade das alterações de estado, enquanto mantém alguns casos de uso comuns de SELFDESTRUCT.

EIP-7516

EIP-7516 introduz uma nova instrução EVM, BLOBBASEFEE, para retornar o valor da taxa base para blobs na execução do bloco atual. Esta instrução é semelhante ao opcode BASEFEE introduzido no EIP-3198, com a diferença de que retorna a taxa base do blob definida de acordo com o EIP-4844. Essa funcionalidade permite que contratos considerem programaticamente o preço do gás de dados de blob, permitindo que contratos rollup calculem os custos de uso 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 entender o ciclo de vida das variáveis de armazenamento transitório antes de usá-las. Como o armazenamento temporário é automaticamente limpo no final de uma transação, os desenvolvedores de contratos inteligentes podem tentar evitar limpar slots durante uma chamada para economizar gás. No entanto, isso poderia impedir uma interação adicional com o contrato na mesma transação (por exemplo, no caso de travas recursivas) ou levar a outros erros. Portanto, os desenvolvedores de contratos inteligentes devem ser cautelosos e reter apenas 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 desses opcodes é idêntico ao SLOAD e SSTORE, então todas as considerações de segurança comuns se aplicam, especialmente em relação aos riscos de recursão.

Os desenvolvedores de contratos inteligentes também podem tentar usar armazenamento transitório como uma alternativa ao mapeamento de memória. Eles 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 por meio de uma lista classificada 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

Este 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), então não aumenta significativamente a largura de banda em cenários de pior caso. Após a fusão, os tempos dos blocos são estáticos em vez de distribuídos de forma imprevisível de Poisson, fornecendo um prazo 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 de dados de chamada, porque o armazenamento de Blob não precisa ser retido pelo mesmo tempo 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 epoch MIN_EPOCHS_FOR_BLOB_SIDECARS_REQUESTS, que é aproximadamente 18 dias, muito mais curto do que o tempo de rotação proposto (mas ainda não implementado) de um ano para executar históricos de payload válidos.

EIP-5656

Os clientes devem estar atentos para garantir que suas implementações não usem buffers intermediários (por exemplo, a função memmove da C stdlib não usando buffers intermediários), pois isso é um vetor potencial 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 tem 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 acessam a memória, pois a expansão de memória segue as mesmas regras de precificação.

EIP-6780

As seguintes aplicações de SELFDESTRUCT serão quebradas e as aplicações que a utilizam dessa forma não são mais seguras:

Onde CREATE2 é usado para reimplantar um contrato no mesmo local para tornar os contratos atualizáveis. Esta funcionalidade não é mais suportada e deve ser substituída por 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 códigos de operação TLOAD e TSTORE:

1. Chamados contratos usam esses opcodes.
2. Chamando contratos usam esses códigos de operação.

Risco 1:

Em comparação com o SSTORE e o SLOAD tradicionais, a introdução do armazenamento transitório muda principalmente a duração do armazenamento dos 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 corretamente gravados no contrato, causando perdas. Além disso, os dados armazenados pelo TSTORE são privados e só podem ser acessados pelo próprio contrato. Se for necessária a acesso externo a esses dados, eles devem ser passados por 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 gerenciarem corretamente o ciclo de vida das variáveis de armazenamento transitório, isso pode levar a dados sendo apagados em momentos inapropriados ou retidos de forma incorreta. Se um contrato espera usar dados armazenados em armazenamento transitório em chamadas subsequentes de uma transação, mas falha em gerenciar corretamente o ciclo de vida desses dados, pode compartilhar erroneamente 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 permissão em projetos de token, pode levar a erros lógicos em contratos, causando perdas. Da mesma forma, o uso desses opcodes para definir o endereço do proprietário pode resultar no endereço privilegiado não sendo registrado corretamente, levando à perda de modificações para parâmetros importantes do contrato.

Considere um smart contract que utiliza armazenamento transitório para registrar temporariamente o preço da transação em uma plataforma de negociação de criptomoedas. O contrato atualiza o preço após cada transação e permite que os usuários consultem o preço mais recente dentro de um curto período. 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 usuários podem receber um preço incorreto ou desatualizado. Isso não só pode levar os usuários a tomar decisões com base em informações incorretas, mas também pode ser explorado maliciosamente, afetando a reputação da plataforma e a segurança dos ativos dos usuários.

EIP-6780

Esta proposta altera o comportamento do opcode anterior de autodestruição, onde o contrato não é queimado, mas apenas a transferência de tokens ocorre, e somente 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 redeploy 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 de contratos on-chain implementando 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-alvo especificado. Neste caso, o contrato usa SELFDESTRUCT para queimar Ether e envia o Ether queimado para o contrato. No entanto, este contrato deve ser criado apenas 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, selfdestruct com o beneficiário sendo o contrato selfdestruct, o que não produzirá quaisquer alterações). Isso afetará todos contratosque dependem da função de auto-destruição para saques ou outras operações.

Um Token de Gás semelhante ao Token CHI de 1polegada funciona da seguinte forma: mantendo um deslocamento, sempre implantando CREATE2 ou SELFDESTRUCT neste deslocamento. Após essa atualização, se o contrato no deslocamento atual não tiver sido corretamente autodestruído, as CREATE2 subsequentes não conseguirão implantar contratos com sucesso.

Essa implementação de proposta não pode atacar diretamente contratos, mas 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), fazendo com que os contratos funcionem inesperadamente e possam levar a paralisações de contrato, 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, a modificação da 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.
• Auto-destrua o contrato do cofre, 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).
• Destrua 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á aprimorar ainda mais a vantagem competitiva do Ethereum. No entanto, as mudanças na camada central do contrato inteligente nesta atualização trazem riscos que afetarão a operação segura dos DApps existentes. Durante o desenvolvimento do contrato inteligente, essas mudanças e os riscos potenciais que podem trazer precisam ser monitorados de perto. Você pode entrar em contato com Salus para verificações de risco ou suporte de auditoria, ou para uma leitura mais aprofundada para entender as mudanças.

Especificação de 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 é reproduzido a partir de [Aicoin], Encaminhe o Título Original‘Salus Insights：坎昆升级前，项目开发者必看的几项安全检查’. Todos os direitos autorais pertencem ao autor original [*Odaily Planeta Diário]. Se houver objeções a esta reimpressão, entre em contato com o Gate Learnequipe, e eles vão lidar com isso prontamente.
2. Responsabilidade de Isenção: As opiniões e pontos de vista expressos 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 feitas pela equipe Gate Learn. Salvo indicação em contrário, copiar, distribuir ou plagiar os artigos traduzidos é proibido.