Explore a atualização de Dencun do Ethereum e as possíveis oportunidades

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

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

Quase todas as atualizações do Ethereum são acompanhadas por tendências significativas do mercado. Analisando a última atualização em 12 de abril de 2023, conhecida como a atualização de Xangai, os projetos relacionados à Proof-of-Stake (PoS) tiveram um aumento na demanda do mercado.

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

No entanto, devido à complexidade técnica envolvida na atualização de Dencun, ela não pode ser resumida de forma tão sucinta quanto a atualização de Xangai com uma única frase como "Ethereum fazendo a transição de PoW para PoS". Essa complexidade dificulta a compreensão dos pontos focais para o posicionamento estratégico.

Portanto, este artigo tem o objetivo de explicar os detalhes técnicos do upgrade do Dencun em uma linguagem simples e compreensível. Ele guiará os leitores pelos meandros dessa atualização, destacando suas conexões com a disponibilidade de dados (DA), soluções de camada 2 e outros aspectos relevantes.

01. EIP 4484

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

Em termos leigos, as soluções atuais da Camada 2 da Ethereum exigem o envio de transações que ocorrem na Camada 2 para os calldata da rede principal da Ethereum. Esses dados de chamada são usados pelos nós para verificar a validade dos blocos na rede da Camada 2.

No entanto, essa abordagem apresenta desafios, pois, apesar dos esforços para compactar os dados das transações, o volume substancial de transações na Camada 2, multiplicado pelos altos custos de armazenamento na rede principal da Ethereum, ainda impõe despesas significativas aos nós e usuários da Camada 2. Esse alto custo, por si só, pode levar à migração de usuários para sidechains.

O EIP-4844 apresenta uma solução econômica ao estabelecer um novo tipo de área de armazenamento chamada Binary Large Object (BLOB). Ele introduz um novo tipo de transação conhecido como "BLOB-Carrying Transaction" para substituir os dados de transação armazenados anteriormente em calldata antes da atualização. Essa abordagem inovadora ajuda o ecossistema Ethereum Layer 2 a obter economia de custos de gás.

Por que o armazenamento de BLOBs é econômico？

Como todos sabemos, a eficiência de custo geralmente vem com uma contrapartida. O motivo pelo qual os dados BLOB incorrem em custos mais baixos em comparação com os calldata regulares do Ethereum de tamanho semelhante é que a camada de execução (EL) do Ethereum não pode acessar diretamente os dados BLOB em si.

Em vez disso, o EL só pode acessar referências aos dados do BLOB, e os dados reais do BLOB só podem ser baixados e armazenados pela camada de consenso da Ethereum (CL, também conhecida como nós de beacon). Os requisitos computacionais e de memória para armazenar dados BLOB são significativamente menores do que os calldata normais da Ethereum.

Além disso, o BLOB tem uma característica distinta: ele só pode ser armazenado por um período limitado (normalmente em torno de 18 dias) e não se expande infinitamente como o tamanho do livro-razão da Ethereum.

Período de validade do armazenamento de BLOBs

Em contraste com o registro permanente do blockchain, os BLOBs são armazenamentos temporários disponíveis 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 de sua existência anterior permanecerá na rede principal na forma de compromissos KZG e será permanentemente armazenada na rede principal Ethereum.

Por que 18 dias? Trata-se de uma compensação entre o custo e a eficácia do armazenamento.

Em primeiro lugar, devemos considerar os beneficiários mais intuitivos dessa atualização, os rollups otimistas (como Arbitrum e Optimism), porque há uma janela de tempo de Prova de Fraude de 7 dias nos Rollups otimistas. Os dados de transação armazenados no Blob são exatamente o que o Optimistic Rollups precisa ao lançar um desafio.

Portanto, o período de validade do Blob deve garantir que o Optimistic Rollups Fraud Proof esteja acessível. Por uma questão de simplicidade, a comunidade Ethereum escolheu 2 elevado à potência de 12 (4.096 épocas são derivadas de 2^12, e uma época é de aproximadamente 6,4 minutos).

Transação de transporte de BLOB e BLOB

Entender a relação entre os dois é importante para compreender a função dos BLOBs na disponibilidade de dados (DA).

A primeira é a proposta geral do EIP-4484 e é um novo tipo de transação, enquanto a segunda pode ser entendida como um local de armazenamento temporário para transações de camada 2.

A relação entre os dois pode ser entendida como o fato de que a maioria dos dados do primeiro (dados de transação da camada 2) é armazenada no segundo. Os dados restantes, ou seja, o compromisso de dados BLOB, serão armazenados nos calldata da rede principal. Em outras palavras, as promessas podem ser lidas pelo EVM.

O compromisso pode ser imaginado como a construção de todas as transações no BLOB em uma árvore Merkle e, em seguida, somente a raiz Merkle, que é o compromisso, pode ser acessada pelo contrato.

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

02. A relação entre o BLOB e a camada 2

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

O objetivo do upload dos dados da transação para o L1 é simplesmente permitir que todos os participantes visualizem os dados.

Antes da atualização do Dencun, conforme mencionado acima, os Optimistic Rollups publicarão dados de transação no Ethereum como calldata. Portanto, qualquer pessoa pode usar essas informações de transação para reproduzir o estado e verificar a exatidão da rede da Camada 2.

Não é difícil perceber que os dados de transações de rollup precisam ser baratos, abertos e transparentes. O Calldata não é um bom lugar para armazenar dados de transação especificamente para a Camada 2, e o BLOB-Carrying Transaction é feito sob medida para o Rollup.

Neste ponto, o senhor pode se perguntar sobre a importância dos dados de transação.

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

• Para o Optimistic Rollup, baseado em uma suposição de confiança, existe a possibilidade de desonestidade. Nesses casos, os registros de transação carregados pelo rollup tornam-se úteis, permitindo que os usuários iniciem provas de fraude.
• Para o ZK Rollup, a prova de conhecimento zero comprovou que a atualização do estado está correta. O upload de dados serve apenas para permitir que os usuários calculem o estado completo por conta própria. Quando o nó da camada 2 não consegue operar corretamente, o mecanismo de escape, que exige uma árvore de estado L2 completa, é ativado. Isso será discutido na última seção deste artigo.

Isso implica que o uso real dos dados de transação pelos contratos é muito limitado. Mesmo nas provas de fraude do Optimistic Rollup, é necessária apenas a prova de que os dados da transação "existiam" em um determinado momento, e não há 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 precisar de uma transação específica no futuro, o fornecimento dos dados dessa transação, desde que correspondam, poderá convencer o contrato e fornecer os dados da transação para o mecanismo de prova de fraude.

Isso não apenas aproveita a abertura e a transparência dos dados da transação, mas também evita o enorme custo de gás de inserir todos os dados no contrato com antecedência.

Ao registrar apenas o compromisso, os dados da transação são verificáveis e, ao mesmo tempo, otimizam bastante os custos. Essa é uma solução inteligente e eficiente para fazer upload de dados de transações usando a tecnologia Rollup.

Deve-se observar que, na operação real da Dencun, a árvore Merkle, semelhante à Celestia, não é usada para gerar compromisso, mas o algoritmo KZG (Kate-Zaverucha-Goldberg, Polynomial Commitment) é usado.

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

Para o agora popular projeto de DA Celestia, ele usa uma variante da árvore Merkle. Ao contrário do KZG, ele depende, até certo ponto, da integridade dos nós, mas ajuda a reduzir o limite de recursos computacionais entre os nós, mantendo a natureza descentralizada da rede.

03. Opportunities in Dencun (Oportunidades em Dencun)

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

Para entender o motivo, precisamos voltar ao mecanismo de escape ou de retirada forçada mencionado acima.

Quando o nó da Camada 2 é desativado, esse mecanismo pode garantir que os fundos do usuário sejam devolvidos com segurança à rede principal. O pré-requisito para ativar esse mecanismo é que o usuário precisa obter a árvore de estado completa da Camada 2.

Em circunstâncias normais, os usuários só precisam encontrar um nó completo da Camada 2 para solicitar dados, gerar uma prova de merkle e, em seguida, enviá-la ao contrato da rede principal para provar a legitimidade de sua retirada.

Mas não se esqueça de que o usuário deseja ativar o mecanismo de escape para sair do L2 justamente porque os nós do L2 agiram de forma maliciosa. Se isso acontecer, há uma grande probabilidade de que eles não obtenham os dados que desejam dos nós.

É a isso que Vitalik se refere com frequência como um ataque de retenção de dados.

Antes do EIP-4844, os registros permanentes da Camada 2 eram gravados na rede principal. Quando nenhum nó de camada 2 puder fornecer o status completo fora da cadeia, os usuários poderão implementar um nó completo por conta própria.

Esse nó completo pode obter todos os dados históricos liberados pelo sequenciador de camada 2 na rede principal por meio da rede principal da Ethereum. Os usuários podem construir a prova de Merkle necessária e enviar a prova para o contrato na rede principal para concluir com segurança a retirada do ativo L2.

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

Portanto, o método do parágrafo anterior para obter toda a árvore de estados sincronizando a rede principal não é mais viável. Se o senhor quiser obter a árvore de estado completa da Camada 2, só poderá contar com nós da rede principal de terceiros que tenham armazenado todos os dados Ethereum BLOB (que deveriam ter sido excluídos automaticamente após 18 dias) ou nós nativos da Camada 2 (que são raros).

Depois que o EIP-4844 entrar em operação, será muito difícil para os usuários obterem a árvore de status completa da Camada 2 de forma totalmente confiável.

Sem uma maneira estável de os usuários obterem a árvore de estado da Camada 2, eles não podem realizar operações de retirada forçada em condições extremas. Portanto, o EIP-4844 tornou-se, até certo ponto, uma falha de segurança para a Camada 2.

Para compensar essa falta de segurança, precisamos ter uma solução de armazenamento sem confiança e com um ciclo econômico positivo. O armazenamento aqui se refere principalmente à retenção de dados na Ethereum de forma não confiável, o que é diferente do espaço de armazenamento no passado porque há uma palavra-chave "não confiável" nesse caso.

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

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

O significado mais intuitivo do Ethstorage é que ele pode estender o tempo disponível do DA BLOB de forma totalmente descentralizada, compensando as deficiências da segurança da Camada 2 após o EIP-4844.

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

Por exemplo, a demanda por armazenamento de NFTs na cadeia é enorme, porque os usuários não apenas possuem tokens de contratos de NFT, mas também a imagem na cadeia. O Ethstorage pode resolver os problemas adicionais de confiança decorrentes do armazenamento dessas imagens em um terceiro.

Por fim, o Ethstorage também pode resolver as necessidades de front-end dos dApps descentralizados. As soluções existentes atualmente são hospedadas principalmente por servidores centralizados (com DNS). Essa configuração torna os sites vulneráveis à censura e a outros problemas, como sequestro de DNS, invasão de sites ou falhas no servidor, conforme evidenciado por incidentes como o Tornado Cash.

O Ethstorage ainda está em fase inicial de testes, e os usuários que estiverem otimistas quanto às perspectivas dessa faixa podem experimentá-la.

Isenção de responsabilidade：

1. Este artigo foi reimpresso de[Biteye]. Todos os direitos autorais pertencem ao autor original[Biteye]. Se houver alguma objeção a essa reimpressão, entre em contato com a equipe do Gate Learn, que tratará do assunto imediatamente.
2. Isenção de responsabilidade: Os pontos de vista e opiniões expressos neste artigo são de responsabilidade exclusiva do autor e não constituem consultoria de investimento.
3. As traduções do artigo para outros idiomas são feitas pela equipe do Gate Learn. A menos que mencionado, é proibido copiar, distribuir ou plagiar os artigos traduzidos.