Salus Insights: Algumas verificações de segurança imperdíveis para desenvolvedores de projetos antes da atualização de Cancun

Resumindo: A atualização de Cancun está se aproximando, e essa atualização inclui principalmente as mudanças de camada executiva propostas pelas seis EIPs, EIP-1153, EIP-4788, EIP-4844, EIP-5656, EIP-6780 e EIP-7516. O EIP-4844 é o protagonista desta atualização, que visa melhorar a escalabilidade do Ethereum, diminuir o Custo de Transação L2 e aumentar a velocidade da transação. A atualização de Cancun foi concluída em 17 de janeiro, 30 de janeiro, 7 de fevereiro no Ethereum Goerli, Sepolia e Holesky Testnet, e está programada para ser ativada em 13 de março no Ethereum Mainnet. Antes da atualização, Salus compilou considerações de segurança importantes para essa atualização para os desenvolvedores verificarem por conta própria.

Revisão da proposta do PIE

Considerações de segurança divulgadas oficialmente

Riscos associados a contratos inteligentes

Ler mais

Revisão da proposta do PIE

EIP-1153

O EIP-1153 introduz o Código de Operação de armazenamento efêmero, que é o Código de Operação usado para o estado operacional e se comporta de forma quase idêntica ao armazenamento, mas é descartado após a conclusão de cada transação. Isso significa que o armazenamento temporário não desserializa valores do armazenamento e não serializa valores para armazenamento, portanto, o armazenamento temporário é menos dispendioso porque não requer acesso ao disco. Com dois novos códigos de operação, TLOAD e TSTORE (onde “T” significa “temporário”), o Smart Contract pode acessar o armazenamento temporário. Esta proposta visa fornecer uma solução dedicada e eficiente para a comunicação entre estruturas de execução aninhadas longas na execução de transações do Ethereum.

EIP-4788

O EIP-4788 visa expor as raízes da árvore de hash dos Beacon Chain Blocks ao EVM para permitir o acesso a essas raízes dentro do Smart Contract. Isso fornece acesso sem confiança ao estado da camada de Consenso, suportando casos de uso longos, como pools de staking , estruturas de retomada, pontes de contrato inteligente, mitigação de MEV e muito mais. A proposta armazena essas raízes através de um Smart Contract e usa um buffer de anel para limitar o consumo de armazenamento, garantindo que cada Bloco de execução precise apenas de um Short constante para representar essas informações.

EIP-4844

O EIP-4844 introduz um novo formato de transação chamado “Sharding Blob Transactions” projetado para dimensionar a disponibilidade de dados do Ethereum de uma forma simples e compatível com o futuro. Esta proposta faz isso introduzindo “transações de transporte de blob” que contêm uma grande quantidade de dados que não podem ser acessados pela execução do EVM, mas podem acessar suas promessas. Este formato é totalmente compatível com o formato usado pelo Sharding completo no futuro, proporcionando um alívio temporário, mas significativo, para o dimensionamento contínuo.

EIP-5656

O EIP-5656 introduz uma nova instrução EVM, MCOPY, para replicação eficiente de regiões de memória. Esta proposta visa eliminar a sobrecarga de executar operações de cópia de memória no EVM, permitindo diretamente a replicação de dados entre a memória através da instrução MCOPY. O MCOPY PERMITE QUE O ENDEREÇO DE ORIGEM E O ENDEREÇO DE DESTINO SE SOBREPONHAM, É PROJETADO COM COMPATIBILIDADE COM VERSÕES ANTERIORES EM MENTE E FOI PROJETADO PARA MELHORAR A EFICIÊNCIA DE EXECUÇÃO EM CENÁRIOS LONGOS, INCLUINDO CONSTRUÇÃO DE ESTRUTURA DE DADOS, ACESSO EFICIENTE A OBJETOS NA MEMÓRIA E REPLICAÇÃO.

EIP-6780

EIP-6780 modifica a funcionalidade do código de operação SELFDESTRUCT. Nesta proposta, a SELFDESTRUCT apenas eliminaria a conta e transferiria todo o Ether na mesma transação em que o contrato foi criado, exceto que, quando a SELFDESTRUCT fosse executada, o contrato não seria eliminado, mas simplesmente transferiria todo o Ether para o destino especificado. Esta alteração destina-se a acomodar o uso de árvores Verkle no futuro, e destina-se a simplificar as implementações EVM e reduzir a complexidade das mudanças de estado, mantendo alguns dos cenários comuns usados pelo SELFDESTRUCT.

EIP-7516

O EIP-7516 introduz uma nova instrução EVM, BLOBBASEFEE, que retorna o valor da taxa base do blob na execução do bloco atual. Esta diretiva é semelhante ao Código de Operação BASEFEE no EIP-3198, exceto que retorna a taxa básica de blob, conforme definido pelo EIP-4844. Esse recurso permite que o contrato considere programaticamente o preço do gás dos dados de blob, por exemplo, permitindo que os contratos de rollup calculem de forma confiável o custo do uso de dados de blob, ou implementem futuros de gás de blob com base nisso para suavizar os custos de dados de blob.

Considerações de segurança divulgadas oficialmente

EIP-1153

Os desenvolvedores de contratos inteligentes devem entender o ciclo de vida das variáveis de armazenamento transitórias antes de usá-las. Como o armazenamento temporário é automaticamente liberado no final de uma transação, os desenvolvedores de contratos inteligentes podem tentar evitar a liberação de slots durante as chamadas para economizar gás. No entanto, isso pode impedir uma maior interação com o contrato na mesma transação (por exemplo, no caso de um bloqueio de reentrante) ou causar outros erros, portanto, os desenvolvedores de contratos inteligentes devem ter cuidado para preservar valores diferentes de zero apenas quando o slot temporário for reservado. Destina-se a ser utilizado por futuras chamadas na mesma transação. SSTORE Caso contrário, esses códigos de operação se comportam exatamente da mesma forma que e SLOAD, portanto, todas as considerações de segurança comuns se aplicam, especialmente quando se trata de riscos de re-entrincheira.

Os desenvolvedores de contratos inteligentes também podem tentar usar o armazenamento transitório como uma alternativa ao mapeamento de memória. Eles devem estar cientes de que o armazenamento efêmero não é descartado como a memória quando a chamada retorna ou é retomada, e a memória deve ser priorizada nesses casos de uso para evitar um comportamento inesperado ao re-entrincheirar na mesma transação. O armazenamento transitório na memória é necessariamente dispendioso, o que deveria ter evitado este padrão de utilização. O grande uso longo do mapeamento na memória pode ser melhor alcançado com listas de entrada ordenadas por chaves, e o mapeamento na memória raramente é necessário no Smart Contract (ou seja, o autor sabe que não há casos de uso conhecidos na produção).

EIP-4844

Este EIP aumenta o requisito de largura de banda em cerca de 0,75 MB a um máximo de comprimento por bloco de beacon. Isso é 40% maior do que o tamanho máximo teórico do bloco atual (30 M de Gás / 16 Gás por byte de dados de chamada = 1,875 M bytes), portanto, não aumenta significativamente a largura de banda do pior caso. Após a fusão, o tempo de Bloco é estático em vez de uma distribuição de Poisson imprevisível, fornecendo um período de tempo garantido para a propagação de Bloco grande.

Mesmo com dados de chamada limitados, a carga sustentada deste EIP é muito menor do que as alternativas que podem reduzir o custo dos dados de chamada, porque você não precisa armazenar blobs por tanto tempo quanto a carga de execução. Isso torna possível implementar uma política de que esses blobs devem ser mantidos por pelo menos um determinado período de tempo. O valor específico selecionado é a época MIN_EPOCHS_FOR_BLOB_SIDECARS_REQUESTS, que é de aproximadamente 18 dias, com uma latência de Long em comparação com a rotação recomendada (mas ainda não implementada) de um ano do histórico de carga útil de execução.

EIP-5656

Os clientes devem estar cientes de que suas implementações não usam buffers intermediários (por exemplo, a função C stdlibmemmove não usa buffers intermediários), pois este é um vetor potencial de negação de serviço (DoS). Muitas das funções de biblioteca incorporadas/padrão da linguagem para mover bytes têm as características de desempenho corretas aqui.

Fora isso, a análise de ataques de negação de serviço (DoS) e esgotamento de memória é a mesma de outros códigos de operação para tocar na memória, porque a expansão de memória segue as mesmas regras de preço.

EIP-6780

AS SEGUINTES APLICAÇÕES DO SELFDESTRUCT SERÃO COMPROMETIDAS E AS APLICAÇÕES QUE O UTILIZAM DESTA FORMA DEIXAM DE SER SEGURAS:

WhereCREATE 2 é usado para reimplantar o contrato no mesmo local para que o contrato seja atualizável. Este recurso não é mais suportado e ERC-2535 ou outro tipo de contrato de proxy deve ser usado em vez disso.

Se o contrato se baseia na queima de Ether tomando o contrato SELFDESTRUCT como beneficiário, o contrato não é criado na mesma transação.

Riscos associados aos contratos inteligentes

EIP 1153

Considere dois cenários usando o código de operação TLOAD e TSTORE:

1. O contrato denominado utiliza o Código de Operação
2. O Código de Operação é usado para iniciar o contrato de chamada

Risco 1 :

Em comparação com o SSTORE e o SLOAD tradicionais, o novo armazenamento transitório altera principalmente o período de armazenamento dos dados, os dados armazenados pelo tstore são lidos através do tload e os dados serão liberados após a execução de uma transação, em vez de serem gravados no contrato, pois o sstore é gravado permanentemente. Os desenvolvedores devem reconhecer as características do Código de Operação ao usar o Código de Operação, de modo a evitar perdas causadas pelo uso incorreto de dados que não podem ser escritos no contrato corretamente. Além disso, os dados da tstore são uma variável privada e só podem ser acessados pelo próprio contrato. Se você quiser usar os dados externamente, você só pode passá-los como um parâmetro ou colocá-los em uma variável pública stroage.

Risco 2 :

Outro risco potencial é que, se os desenvolvedores de contratos inteligentes não gerenciarem adequadamente o ciclo de vida das variáveis de armazenamento transitórias, isso pode levar a que os dados sejam limpos ou retidos incorretamente em momentos indevidos. Se um contrato espera usar dados armazenados em armazenamento transitório em chamadas subsequentes para uma transação, mas não consegue gerenciar adequadamente o ciclo de vida desses dados, os dados podem ser compartilhados por engano ou perdidos entre chamadas diferentes, resultando em erros lógicos ou violações de segurança. Considerando que os dados de saldo ou provisão de um projeto de Token semelhante não são armazenados corretamente, isso levará a erros na lógica do contrato e causará perdas. Ou o uso deste Código de Operação ao definir o Endereço do proprietário fará com que o Endereço privilegiado não seja registrado corretamente, perdendo assim a modificação de parâmetros importantes do contrato.

Considere um contrato inteligente que usa armazenamento transitório para registrar temporariamente os preços de transação em uma plataforma de negociação de criptoativos. O contrato atualiza o preço à medida que cada transação é concluída e permite que os usuários consultem o preço mais recente por um curto período de tempo. No entanto, se a conceção do contrato não levar em conta o fato de que o armazenamento transitório é automaticamente liberado no final da negociação, então o usuário pode obter um preço errado ou desatualizado no período entre o final de uma negociação e o início da próxima. Isso pode não apenas levar os usuários a tomar decisões com base em desinformação, mas também pode ser explorado de forma maliciosa, afetando a reputação da plataforma e a segurança dos ativos dos usuários.

EIP-6780

A proposta altera o comportamento anterior do Código de Operação de autodestruição, não destruindo o contrato, apenas transferindo o token, e apenas o contrato criado na mesma transação que a autodestruição será destruído. O impacto desta PEI é relativamente grande.

Reimplante o contrato no mesmo endereço com create 2 para atualizar o contrato. Este recurso não é mais suportado e ERC-2535 ou outro tipo de contrato de proxy deve ser usado em vez disso. (Isso pode afetar a segurança de contratos on-chain que usam create 2 para implementar contratos escaláveis)

A operação SELFDESTRUCT no Smart Contract permite que o contrato seja destruído e o saldo do contrato seja enviado para o endereço de destino especificado. Neste caso, o contrato usa SELFDESTRUCT para queimar Ether e envia o Ether queimado para o contrato. No entanto, o contrato só pode ser um contrato criado na mesma transação (um contrato criado por este contrato ou outro contrato na mesma transação). Caso contrário, apenas o Ether será transferido sem destruir o contrato (por exemplo, autodestrutivo e o beneficiário é um contrato autodestrutivo, que não mudará nada). Isso afetará quaisquer contratos que dependam da autodestruição para retiradas ou outras operações.

Um token de gás semelhante ao CHI Token de 1 polegada funciona: mantenha um offset, execute sempre CREATE 2 ou SELFDESTRUCT nesse offset. Após essa atualização, se o contrato com o deslocamento atual ainda não tiver se autodestruído corretamente, o CREATE 2 subsequente não poderá implantar o contrato com êxito.

A implementação desta proposta não levará a um ataque direto ao contrato, mas prejudicará a lógica normal do contrato implantado original que se baseia na operação de autodestruição (o contrato que depende apenas de autodestruição para transferência de fundos não será afetado, e se a operação subsequente exigir que o contrato de autodestruição seja excluído, ele será afetado), resultando no contrato não funcionando como pretendido, e apenas para o contrato e usuários, pode levar à greve do contrato, perda de fundos e outros danos (como o uso original do create 2). Implante um novo contrato no endereço original e o contrato que autodestrói o contrato original de atualização não poderá mais ser implantado com êxito). A longo prazo, a capacidade de modificar um Código de Operação pode levar a problemas de centralização.

Por exemplo, há um cofre de contrato de cofre existente para atualizar:

• Criar 2 Contrato de Armazenamento Temporário é usado para reservar temporariamente fundos para o cofre
• Contrato de cofre de autodestruição, transferência de fundos para contrato temporário (apenas fundos são transferidos, nenhum contrato é queimado)
• Novo contrato do vault no endereço original create 2 (falhou porque o contrato do vault original não foi destruído)
• Auto-destrua contrato temporário para devolver fundos ao cofre (perda de fundos, contrato do cofre não foi criado)

Ler mais

A atualização de Cancun aumentará ainda mais a vantagem competitiva do Ethereum. No entanto, essa atualização representa um risco para alterações na camada principal do Smart Contract, o que afetará a operação segura dos DApps existentes. No processo de desenvolvimento de contratos inteligentes, essas mudanças e os riscos que podem surgir também precisam ser muito atentos. Pode contactar a Salus para obter verificações de risco ou apoio de auditoria, ou pode ler mais para compreender as alterações.

Especificação de atualização de rede de Cancun

EIP-1153

EIP-4788

EIP-4844

EIP-5656

EIP-6780

EIP-7516

Contrato Metapod

Contrato GasToken 2