A versão Dencun testnet da atualização da rede Ethereum foi lançada na testnet Goerli em 17 de janeiro de 2024, e a testnet Sepolia foi lançada com êxito em 30 de janeiro. A atualização do Dencun está cada vez mais próxima.

Depois da atualização da Holesky testnet em 7 de fevereiro, será a vez da atualização da rede principal. O lançamento da atualização Cancun na rede principal foi oficialmente determinado para 13 de março de 2024.

Quase todas as actualizações do Ethereum são acompanhadas por tendências de mercado significativas. Olhando para trás, para a última atualização em 12 de abril de 2023, conhecida como a atualização de Xangai, os projectos relacionados com a prova de participação (PoS) registaram um aumento da procura no mercado.

Se seguirmos as experiências anteriores, é provável que haja oportunidades de posicionamento estratégico antes da próxima atualização de Dencun.

No entanto, devido à complexidade técnica envolvida na atualização de Dencun, esta não pode ser resumida de forma tão sucinta como a atualização de Xangai com uma única frase como "Ethereum em transição de PoW para PoS". Esta complexidade faz com que seja difícil compreender os pontos fulcrais para o posicionamento estratégico.

Por conseguinte, este artigo tem por objetivo explicar os pormenores técnicos da modernização do Dencun numa linguagem simples e compreensível. Irá guiar os leitores através dos meandros desta atualização, destacando as suas ligações com a disponibilidade de dados (DA), soluções de Camada 2 e outros aspectos relevantes.

01. EIP 4484

A EIP-4844 destaca-se como a proposta mais crucial na atualização Dencun, marcando um passo significativo para o Ethereum na sua jornada de escalonamento descentralizado.

Em termos leigos, as actuais soluções Ethereum Layer 2 requerem a submissão das transacções que ocorrem na Layer 2 aos calldata da rede principal Ethereum. Estes dados de chamada são então utilizados pelos nós para verificar a validade dos blocos na rede do nível 2.

No entanto, esta abordagem apresenta desafios, uma vez que, apesar dos esforços para comprimir os dados das transacções, o volume substancial de transacções na camada 2, multiplicado pelos elevados custos de armazenamento na rede principal Ethereum, continua a impor despesas significativas aos nós e utilizadores da camada 2. Este custo elevado pode, por si só, levar à migração de utilizadores para sidechains.

O EIP-4844 introduz uma solução rentável através da criação de um novo tipo de área de armazenamento denominado Binary Large Object (BLOB). Introduz um novo tipo de transação conhecido como "BLOB-Carrying Transaction" para substituir os dados de transação anteriormente armazenados em calldata antes da atualização. Esta abordagem inovadora ajuda o ecossistema Ethereum Layer 2 a obter poupanças nos custos do gás.

Porque é que o armazenamento BLOB é rentável？

Como todos sabemos, a relação custo-eficácia tem muitas vezes um custo-benefício. A razão pela qual os dados BLOB incorrem em custos mais baixos em comparação com os calldata Ethereum regulares de tamanho semelhante é que a camada de execução Ethereum (EL) não pode aceder diretamente aos dados BLOB.

Em vez disso, o EL só pode aceder a referências aos dados do BLOB, e os dados reais do BLOB só podem ser descarregados e armazenados pela Camada de Consenso Ethereum (CL, também conhecida como nós beacon). Os requisitos de memória e computacionais para armazenar dados BLOB são significativamente mais baixos do que os calldata Ethereum normais.

Além disso, o BLOB tem uma caraterística distintiva - só pode ser armazenado durante um período limitado (normalmente cerca de 18 dias) e não se expande infinitamente como o tamanho do livro-razão do Ethereum.

Período de validade do armazenamento de BLOBs

Em contraste com o livro-razão permanente da blockchain, os BLOBs são um armazenamento temporário que está disponível por 4.096 épocas, ou aproximadamente 18 dias.

Após a expiração, a maioria dos clientes de consenso não conseguirá recuperar dados específicos no BLOB. No entanto, a prova da sua existência anterior permanecerá na rede principal sob a forma de compromissos KZG e será permanentemente armazenada na rede principal Ethereum.

Porquê 18 dias? Trata-se de um compromisso entre o custo e a eficácia do armazenamento.

Em primeiro lugar, temos de considerar os beneficiários mais intuitivos desta atualização, os rollups optimistas (como o Arbitrum e o Optimism), porque existe uma janela temporal de 7 dias para a Prova de Fraude nos Rollups Optimistas. Os dados de transação armazenados no Blob são exatamente aquilo de que o Optimistic Rollups precisa quando lança um desafio.

Por conseguinte, o período de validade do Blob deve garantir que a prova de fraude dos Rollups optimistas está acessível. Por uma questão de simplicidade, a comunidade Ethereum escolheu 2 à potência de 12 (4.096 épocas são derivadas de 2^12, e uma época é aproximadamente 6,4 minutos).

Transação de transporte de BLOB e BLOB

Compreender a relação entre os dois é importante para entender o papel dos BLOBs na disponibilidade de dados (DA).

A primeira é a proposta global da EIP-4484 e constitui um novo tipo de transação, enquanto a segunda pode ser entendida como um local de armazenamento temporário para transacções de nível 2.

A relação entre os dois pode ser entendida como o facto de a maior parte dos dados do primeiro (dados de transação do nível 2) ser armazenada no segundo. Os restantes dados, ou seja, o compromisso de dados BLOB, serão armazenados nos calldata da rede principal. Por outras palavras, as promessas podem ser lidas pela EVM.

A autorização pode ser imaginada como a construção de todas as transacções no BLOB numa árvore Merkle, e depois apenas a raiz Merkle, que é a autorização, pode ser acedida pelo contrato.

Isto pode ser conseguido de forma inteligente: embora o EVM não possa conhecer o conteúdo específico do BLOB, o contrato EVM pode verificar a autenticidade dos dados da transação conhecendo o compromisso.

02. A relação entre BLOB e Layer 2

A tecnologia Rollup atinge a disponibilidade de dados (DA) carregando dados para a rede principal Ethereum, mas não se destina a que os contratos inteligentes da L1 leiam ou verifiquem diretamente esses dados carregados.

O objetivo do carregamento de dados de transacções para L1 é simplesmente permitir que todos os participantes visualizem os dados.

Antes da atualização do Dencun, como mencionado acima, o Optimistic Rollups publicará dados de transação no Ethereum como calldata. Por conseguinte, qualquer pessoa pode utilizar estas informações de transação para reproduzir o estado e verificar a correção da rede da camada 2.

Não é difícil perceber que os dados das transacções de rollup têm de ser baratos, abertos e transparentes. O Calldata não é um bom local para armazenar dados de transação especificamente para o nível 2, e o BLOB-Carrying Transaction é feito à medida para o Rollup.

Nesta altura, pode interrogar-se sobre a importância dos dados de transação.

Na realidade, os dados de transação só são utilizados em cenários específicos:

• Para o Rollup otimista, baseado num pressuposto de confiança, existe a possibilidade de desonestidade. Nestes casos, os registos de transacções carregados pelo rollup tornam-se úteis, permitindo aos utilizadores iniciar provas de fraude.
• Para o ZK Rollup, a prova de conhecimento zero provou que a atualização do estado está correcta. O carregamento de dados destina-se apenas a permitir que os utilizadores calculem o estado completo por si próprios. Quando o nó da camada 2 não pode funcionar corretamente, o mecanismo de escape, que requer uma árvore de estado L2 completa, é ativado. Esta questão será abordada na última secção deste artigo.

Isto implica que a utilização efectiva dos dados relativos às transacções pelos contratos é muito limitada. Mesmo nas provas de fraude do Optimistic Rollup, apenas é necessária a prova de que os dados da transação "existiram" num determinado momento, não havendo necessidade de armazenar antecipadamente os detalhes de cada transação na rede principal.

Ao colocar os dados da transação no BLOB, embora inacessíveis aos contratos, o contrato da rede principal pode armazenar o compromisso do BLOB.

Se o mecanismo de prova de fraude necessitar de uma transação específica no futuro, o fornecimento dos dados relativos a essa transação, desde que correspondam, pode convencer o contrato e fornecer os dados da transação ao mecanismo de prova de fraude.

Isto não só tira partido da abertura e transparência dos dados da transação, como também evita o enorme custo do gás de introduzir antecipadamente todos os dados no contrato.

Ao registar apenas o compromisso, os dados da transação são verificáveis, optimizando ao mesmo tempo os custos. Esta é uma solução inteligente e eficiente para carregar dados de transação utilizando a tecnologia Rollup.

Note-se que, no funcionamento real do Dencun, a árvore de Merkle, semelhante à do Celestia, não é utilizada para gerar o compromisso, mas sim o algoritmo KZG (Kate-Zaverucha-Goldberg, Polynomial Commitment).

Em comparação com a prova da árvore de Merkle, o processo de geração da prova KZG é relativamente complexo, mas o seu volume de verificação é menor e os passos de verificação são mais simples. No entanto, a desvantagem é que requer configurações de confiança (ceremony.ethereum.org, que já terminou) e não tem capacidade para impedir ataques de computação quântica (o Dencun utiliza o método Version Hash e outros métodos de verificação podem ser substituídos, se necessário).

Para o agora popular projeto DA Celestia, utiliza uma variante da árvore Merkle. Ao contrário da KZG, depende, em certa medida, da integridade dos nós, mas ajuda a reduzir o limiar de recursos computacionais entre nós, mantendo a natureza descentralizada da rede.

03. Oportunidades em Dencun

Embora o EIP-4844 reduza os custos e aumente a eficiência da camada 2, também aumenta os riscos de segurança, o que também traz novas oportunidades.

Para compreender porquê, temos de voltar ao mecanismo de escape ou de retirada forçada acima referido.

Quando o nó da camada 2 é desativado, este mecanismo pode garantir que os fundos do utilizador são devolvidos em segurança à rede principal. O pré-requisito para ativar este mecanismo é que o utilizador tenha de obter a árvore de estados completa da camada 2.

Em circunstâncias normais, os utilizadores só precisam de encontrar um nó completo da camada 2 para solicitar dados, gerar uma prova de merkle e depois submetê-la ao contrato da rede principal para provar a legitimidade do seu levantamento.

Mas não se esqueça de que o utilizador quer ativar o mecanismo de escape para sair de L2 precisamente porque os nós de L2 agiram maliciosamente. Se isso acontecer, há uma grande probabilidade de não obter os dados que pretende dos nós.

É a isto que Vitalik se refere frequentemente como um ataque de retenção de dados.

Antes do EIP-4844, os registos permanentes da camada 2 eram registados na rede principal. Quando nenhum nó da camada 2 podia fornecer um estado completo fora da cadeia, os utilizadores podiam implementar eles próprios um nó completo.

Este nó completo pode obter todos os dados históricos libertados pelo sequenciador da camada 2 na rede principal através da rede principal Ethereum. Os utilizadores podem construir a prova Merkle necessária e submeter a prova ao contrato na rede principal para completar com segurança a retirada de activos L2.

Após o EIP-4844, os dados da camada 2 só existem no BLOB dos nós completos Ethereum, e os dados históricos anteriores a 18 dias serão automaticamente eliminados.

Por conseguinte, o método descrito no parágrafo anterior para obter a árvore de estados completa através da sincronização da rede principal já não é viável. Se quiser obter a árvore de estado completa da Camada 2, só pode confiar em nós da rede principal de terceiros que tenham armazenado todos os dados Ethereum BLOB (que deveriam ter sido automaticamente eliminados após 18 dias), ou nós nativos da Camada 2 (que são raros).

Depois de a EIP-4844 entrar em funcionamento, será muito difícil para os utilizadores obterem a árvore de estado completa da camada 2 de uma forma totalmente fiável.

Sem uma forma estável de os utilizadores obterem a árvore de estado da camada 2, não podem efetuar operações de retirada forçada em condições extremas. Por conseguinte, o EIP-4844 tornou-se, em certa medida, uma lacuna na segurança da camada 2.

Para compensar esta falta de segurança, precisamos de ter uma solução de armazenamento sem confiança e com um ciclo económico positivo. O armazenamento aqui refere-se principalmente à retenção de dados no Ethereum de uma forma sem confiança, o que é diferente do espaço de armazenamento no passado porque existe uma palavra-chave "sem confiança" neste caso.

A Ethstorage pode resolver o problema da falta de confiança e recebeu duas rondas de financiamento da Fundação Ethereum.

Na verdade, este conceito pode realmente responder ao potencial trazido pela atualização do Dencun, e merece a nossa atenção.

O significado mais intuitivo do Ethstorage é o facto de poder prolongar o tempo disponível do DA BLOB de uma forma completamente descentralizada, compensando as falhas de segurança da camada 2 após o EIP-4844.

Além disso, a maioria das soluções L2 existentes centra-se principalmente no aumento da capacidade de computação do Ethereum, ou seja, no aumento do TPS. No entanto, a procura de armazenamento seguro de grandes quantidades de dados na rede principal Ethereum aumentou, especialmente devido à popularidade de dApps como NFTs e DeFi.

Por exemplo, a procura de armazenamento de NFTs na cadeia é enorme, porque os utilizadores não só possuem tokens de contratos NFT, mas também a imagem na cadeia. O Ethstorage pode resolver os problemas adicionais de confiança que advêm do armazenamento destas imagens num terceiro.

Finalmente, o Ethstorage também pode resolver as necessidades de front-end de dApps descentralizados. Atualmente, as soluções existentes são alojadas principalmente em servidores centralizados (com DNS). Esta configuração torna os sítios Web vulneráveis à censura e a outros problemas, como o sequestro de DNS, a pirataria de sítios Web ou falhas no servidor, como evidenciado por incidentes como o Tornado Cash.

O Ethstorage ainda se encontra na fase inicial de testes e os utilizadores que estão optimistas quanto às perspectivas desta via podem experimentá-la.

Declaração de exoneração de responsabilidade：

1. Este artigo foi reimpresso de[Biteye], Todos os direitos de autor pertencem ao autor original[Biteye]. Se houver objecções a esta reimpressão, contacte a equipa da Gate Learn, que tratará prontamente do assunto.
2. Declaração de exoneração de responsabilidade: Os pontos de vista e opiniões expressos neste artigo são da exclusiva responsabilidade do autor e não constituem um conselho de investimento.
3. As traduções do artigo para outras línguas são efectuadas pela equipa Gate Learn. A menos que seja mencionado, é proibido copiar, distribuir ou plagiar os artigos traduzidos.