A atualização do Ethereum Cancun está se aproximando, revisando o passado, presente e futuro da atualização de Cancun

Autor: Fat Bird Finance

vidas passadas

Por que a atualização de Cancun é necessária?

A visão do Ethereum é tornar-se mais escalável e mais seguro sob a premissa de descentralização. A actual atualização do Ethereum também está empenhada em resolver este trilema, mas tem enfrentado grandes desafios.

Problemas com Ethereum:

Atualmente, há baixo TPS e desempenho, altas taxas de gás e sérios congestionamentos. Ao mesmo tempo, o espaço em disco necessário para executar um cliente Ethereum também está crescendo rapidamente. No fundo, a carga de trabalho de garantir a segurança e descentralização do Ethereum O impacto do algoritmo de consenso em todo o ambiente também está se tornando cada vez mais significativo.

Portanto, sob a premissa da descentralização, como transmitir mais dados e reduzir o gás para aumentar a escalabilidade e como otimizar o algoritmo de consenso para garantir a segurança são todos os esforços que a Ethereum está fazendo atualmente.

A fim de resolver o trilema de segurança, descentralização e escalabilidade, a Ethereum usou o mecanismo PoW-to-PoS para reduzir ainda mais o limite do nó e também planeja usar a cadeia de sinalizadores para designar verificadores aleatoriamente para otimizar a segurança. de escalabilidade, a Ethereum considera o uso de sharding para reduzir a carga de trabalho dos nós, o que também permite que a Ethereum crie vários blocos ao mesmo tempo e aprimore sua escalabilidade.

Atualmente, o espaço de cada bloco de Ethereum é de cerca de 200 ~ 300 KB, o tamanho mínimo de cada transação é de cerca de 100 bytes, cerca de 2.000 transações, divididas pelo tempo de bloco de 12 segundos, o limite superior de TPS de Ethereum é limitado a cerca de 100 . Esses dados obviamente não podem atender às necessidades do Ethereum.

Portanto, Ethereum Layer 2 se concentra em como colocar uma grande quantidade de dados no blockspace e garantir a segurança por meio de provas de fraude e validade. É por isso que a camada DA determina o limite superior de segurança, que também é o conteúdo principal do Atualização de Cancún.

A rota iterativa da ecologia Ethereum não pode construir o desempenho do benchmark Solana (em termos de atraso e throughput), e o desempenho de fragmentação de Near não será visto no curto prazo, nem o desempenho de execução paralela de Sui e Aptos. a curto prazo, o Ethereum só pode construir uma estrutura multicamadas com Rollup como núcleo, portanto, a atualização de Cancun para resolver TPS, taxa de gás e experiência do desenvolvedor é crucial para o roteiro do Ethereum.

Como o roteiro do Ethereum é planejado?

Atualizações importantes recentes e seus objetivos

Em 1º de dezembro de 2020, a cadeia de sinalizadores foi lançada oficialmente, abrindo caminho para atualizações de PDV

A atualização de Londres em 5 de agosto de 2021, EIP1559 mudou o modelo econômico da Ethereum;

Em 15 de setembro de 2022, a atualização de Paris (TheMerge) concluiu a mudança de POW para POS;

Em 12 de abril de 2023, Xangai foi atualizada para resolver o problema de retirada de promessa;

O modelo econômico e as atualizações relacionadas ao POS foram concluídas, e as próximas atualizações resolveram os problemas de desempenho do Ethereum, TPS e experiência do desenvolvedor;

O próximo passo é focado no roteiro do TheSurge no Ethereum.

Objetivo: atingir mais de 100.000 TPS em Rollup.

Existem principalmente 2 soluções, on-chain e off-chain:

Solução off-chain: refere-se a Layer2, incluindo rollup, etc.

Esquema on-chain: refere-se a fazer alterações diretamente em L1, que é um esquema de fragmentação popular.Um entendimento simples de fragmentação é dividir todos os nós em diferentes áreas e concluir as tarefas de cada área, o que efetivamente aumentará a velocidade;

Análise do esquema de fragmentação:

O dilema do esquema de sharding: Sharding costumava incluir sharding de estado, sharding de transação, etc., mas a sincronização entre diferentes shards é um problema. No momento, é tecnicamente difícil concluir uma sincronização de dados de nó de rede em grande escala. pode não resolver a situação do MEV, mas também pode ser necessário um grande número de patches para compensar vários problemas que possam surgir, que não podem ser realizados a curto prazo.

Danksharding é um novo projeto de sharding proposto para Ethereum. Sua ideia central é geração centralizada de blocos + verificação descentralizada + resistência à censura. Isso também está relacionado à amostragem de disponibilidade de dados (DAS) e aos produtores de blocos mencionados abaixo. - Separação de empacotador (PBS) e censura Listas Resistentes (Crlist) relacionadas. O maior significado da ideia central de Danksharding é transformar o Ethereum L1 em uma camada unificada de liquidação e disponibilidade de dados (DataAvailability).

O esquema de sharding é dividido em 2 etapas. Atualmente, ele é dividido em Proto-danksharding e Fully-Rollup.

Proto-danksharding:

Introdução: ao introduzir blobs para ajudar o L2 a reduzir as taxas e aumentar a taxa de transferência, ele também abre caminho para o full sharding como um pré-esquema para danksharding. Espera-se que, após o proto-danksharding, leve de 2 a 5 anos para a implementação do danksharing.

Conteúdo: A principal característica do proto-danksharding é introduzir um novo tipo de transação blob. Blob tem as características de grande capacidade e baixo custo. Adicionar tais pacotes de dados ao Ethereum pode permitir que todos os dados de rollup sejam armazenados em blob, reduzindo bastante o armazenamento da pressão da corrente principal, mas também reduz o custo de rollup.

Rollup completo

Introdução: Rollup expande totalmente a capacidade, com foco na utilização da disponibilidade de dados.

contente:

Projeto P2P de DAS: Alguns trabalhos e pesquisas relacionados ao problema de conexão de rede de fragmentação de dados;

Cliente de amostragem de disponibilidade de dados: desenvolva um cliente leve que possa determinar rapidamente se os dados estão disponíveis por amostragem aleatória de alguns kilobytes;

Autocorreção de DA eficiente: capaz de reconstruir com eficiência todos os dados nas piores condições de rede (por exemplo, ataque de validador malicioso ou longo tempo de inatividade de grandes nós de bloco).

Encontro de Desenvolvedores do Ethereum Core

Cada atualização do Ethereum depende da reunião do desenvolvedor principal, por meio da discussão conjunta dos principais contribuidores e, de acordo com uma série de propostas dos desenvolvedores, a direção futura do desenvolvimento é determinada

Definição: A reunião de desenvolvedores principais é uma teleconferência semanal realizada pela comunidade de desenvolvimento do Ethereum, onde os principais colaboradores de diferentes organizações discutem questões técnicas e coordenam o trabalho futuro no Ethereum. Eles determinam a direção técnica futura do protocolo Ethereum e também são a autoridade que realmente toma as decisões sobre a atualização do Ethereum. Eles são responsáveis por decidir se o EIP está incluído na atualização, se é necessário alterar o roteiro e outros importantes assuntos.

Processo principal: O processo de atualização centrado no EIP é basicamente o seguinte: primeiro, um EIP é inicialmente aceito na conferência de desenvolvedores principais (ACD para abreviar) e, em seguida, a equipe do cliente o testará, independentemente de o EIP estar incluído na atualização Após o teste final, revise-o novamente e decida se deseja incluí-lo na atualização real com base na discussão.

Existem dois tipos de reuniões, a saber, a reunião da camada de consenso e a reunião da camada executiva, que são realizadas alternadamente a cada duas semanas:

Conferência da Camada de Consenso (AllCore Developers Consensus - ACDC), com foco na camada de consenso do Ethereum (Proof of Stake, Beacon Chain, etc.);

Conferência da camada executiva (solução AllCore Developers - ACDE), que tem como foco a camada de execução do Ethereum (EVM, cronograma de gás, etc.).

Existem três tipos de mantenedores do núcleo Ethereum, principalmente organizações oficiais ou fóruns voluntários que discutem propostas:

AllCoreDevs: mantenedores de código, responsáveis pelo cliente da rede ETH1, atualização, manutenção do código Ethereum e arquitetura principal;

Seção "Gerenciamento de Projetos": suporte a desenvolvedores Ethereum, coordene hard forks, monitore EIP, etc., e ajude diretamente AllCoreDevs com comunicação e operações;

EthereumMagicians: Um "fórum" para discussões sobre EIP e outros tópicos técnicos.

Cronograma das reuniões relacionadas ao escalonamento de Cancun

De acordo com o conteúdo da discussão, esta atualização de Cancun pode ser dividida em cinco etapas.

A primeira etapa - apresentando o tema de atualização

Introduzir novas tarefas proto-danksharding, EOF e opcodes "autodestruição", discutir brevemente o conteúdo da atualização de Xangai

Depois que a fusão da Ethereum foi concluída em 15 de setembro de 22, a reunião de desenvolvedores foi suspensa por 4 semanas, permitindo que os desenvolvedores verificassem o EIP discutido na atualização subsequente por um mês;

Em 28 e 22 de outubro, a primeira reunião de desenvolvedores após a fusão propôs a implementação de proto-danksharding, EOF e o opcode "selfdestruct" pela primeira vez. No momento, o escopo específico do proto-danksharding não foi determinado e alguns desenvolvedores inicialmente pensam que a atualização de Xangai pode ser dividida em várias pequenas atualizações, como permitir retiradas prometidas de ETH primeiro e, em seguida, atualizar EIP4844, mas alguns desenvolvedores acham que é mais significativo implementar uma atualização maior em uma etapa.

Fase 2 - Determinação do cronograma e preparação para a cerimônia KZG

No final de 2022, a conferência Ethereum se concentrará principalmente em EOF e EIP4844. Ao mesmo tempo, continuaremos a promover a cerimônia de configuração pré-credível exigida pelo EIP4844 - a cerimônia KZG. Os desenvolvedores determinarão formalmente em qual atualização 4844 será aparecer em 23 de janeiro

Em 22 de novembro, EOF ou proto-danksharding foi mencionado na teleconferência nº 149 de todos os principais desenvolvedores do Ethereum.No momento, os desenvolvedores ainda estão considerando colocá-lo na atualização de Xangai;

Na reunião da Camada de Consenso em 02/12/22, Trent Van Epps, head do ecossistema Ethereum, atualizou sobre o andamento da cerimônia de configuração confiável necessária para a implementação do EIP4844, que visa gerar um pedaço de código seguro que será usado em EIP4844. VanEpps espera que a cerimônia seja uma das maiores de todos os tempos no espaço criptográfico, coletando contribuições de 8.000 a 10.000. O período de contribuição pública da cerimônia durará cerca de 2 meses e começará em dezembro;

Na reunião de desenvolvedores do núcleo no mesmo dia, houve alguma discussão sobre EOF e a desativação do opcode de autodestruição. vai entrar A possibilidade de Cancun é muito pequena. Em relação ao código de autodestruição, alguns desenvolvedores defenderam o avanço do EIP4758 na época, mas desabilitar diretamente esse opcode irá quebrar algumas aplicações. Os desenvolvedores acreditam que antes de criar um caso extremo para proteger esse tipo de contrato, Este EIP deve ser pesado novamente por um período de tempo;

Na reunião de desenvolvedores do núcleo em 9 de dezembro de 22, foi promovida a implementação da cerimônia KZG em relação à atualização de Cancun. Atualmente, a cerimônia de configuração credível exigida pelo EIP4844 está pronta;

Na reunião da Camada de Consenso em 16/12/22, sobre o tópico EIP4844, os desenvolvedores discutiram a fusão de duas solicitações pull (PRs) diferentes na especificação para proto-danksharding, uma relacionada a como os nós lidam com dados removidos de Um é que quando faltar informação sobre blobs em um determinado bloco, um novo código de erro será introduzido nos nós de alerta;

Na reunião de desenvolvedores do núcleo em 5 de janeiro de 23, os desenvolvedores chegaram a um consenso sobre a remoção das modificações de código relacionadas à implementação do EOF da atualização de Xangai. Nesse momento, Beiko sugeriu decidir se o EOF deveria ser incluído no obstáculo após duas semanas. Kun está sendo atualizado;

Fase 3 - Discussão Preliminar do Escopo da Proposta

No final de 23 de janeiro, o EOF foi transferido para Cancun para atualização após ser removido de Xangai. Nos dois meses seguintes, as discussões se concentraram principalmente em outras propostas, exceto EOF e EIP4844. Ao mesmo tempo, foi proposto que o EOF saísse de Cancun . Este período de tempo foi gasto principalmente em delinear o escopo das propostas para a modernização de Cancún.

Na reunião do desenvolvedor principal em 20 de janeiro de 23, o EOF foi transferido para Cancun para atualização;

Na reunião de desenvolvedores do núcleo em 6 de março de 23, as propostas preliminares para a atualização de Cancun foram: EIP4788 (raiz do estado da cadeia de beacons públicos), EIP2537 (realizar com eficiência operações como verificação de assinatura BLS e verificação SNARKs), EIP-5920 (introdução de novos opcode PAY) e uma implementação combinada de EIP6189 (para tornar SELFDESTRUCT compatível com árvores Verkle) e EIP-6190 (mudança da função SELFDESTRUCT para causar apenas um número limitado de mudanças de estado);

Na reunião de desenvolvedores do núcleo em 16 de março de 23, além de EOF e EIP4844, as seguintes propostas foram consideradas para inclusão em Cancun: formato SSZ, exclusão SELFDESTRUCT, EIP2537, EVMMAX, EIP1153, instruções SWAP e DUP ilimitadas, introdução de PAY Beacon raiz de estado em código e EVM;

Na reunião de desenvolvedores do núcleo em 30 de março de 23, a proposta EIP-6780 sobre desabilitar SELFDESTRUCT foi apresentada pela primeira vez, que também é a proposta para desabilitar SELFDESTRUCT que Cancun finalmente decidiu usar. Mas com relação à implementação do EOF, um desenvolvedor da equipe do cliente Erigon(EL) afirmou que o EOF "mudou muito" para ser combinado com a proposta de melhoria Ethereum EIP4844 na próxima atualização de Cancun, que foi proposta para ser atualizada em Cancun Implement EOF no hard fork logo depois;

A quarta etapa - determine a direção clara da atualização da proposta e exclua propostas irrelevantes

Em 23 de abril, havia uma direção clara para as propostas que deveriam ser cobertas pela atualização de Cancun. O ponto principal foi a reunião de desenvolvedores em 13 de abril. Essa reunião propôs 9 EIPs, e o próprio Tim também teve uma compreensão mais profunda de as propostas alternativas. Discussão, na reunião de 27 de abril, EIP6780, EIP6475 e EIP1153 foram determinados para serem incluídos em Cancun, enquanto EOF e EVMMAX (subconjuntos de EIP relacionados à implementação de EOF) foram removidos da atualização de Cancun, a atualização de EOF pode ajudar principalmente O controle de versão EVM e vários conjuntos de regras de contrato podem ser executados ao mesmo tempo, o que é propício para a expansão subsequente do Ethereum. No entanto, considerando a viabilidade de toda a atualização, a atualização EOF pode ser promovida com atualizações diárias nos seguintes acima

Em 12 de abril de 23, a atualização do Ethereum Shanghai foi concluída;

Além da reunião de desenvolvimento principal em 13.04.23, onde os desenvolvedores discutiram EIP4844 (para expor dados sobre a raiz do estado CL no EL), há pelo menos nove outros EIPs sendo considerados para a atualização, eles são EIP4844, remoção SELFDESTRUCT ( EIP-6780, EIP4758, EIP6046, EIP6190), EIP5920, EIP1153, EIP2537, EIP4788, EVMMAXEIPs (EIP6601 e EIP6690), SSZchanges (EIP6475, EIP6493, EIP 6465, EIP6404 e EIP6466), EIP 5656 e EIP6193;

Na reunião de desenvolvedores principais em 27 e 23 de abril, vários progressos e compensações foram focados. Primeiro, EIP4844 continua a ser identificado para inclusão na atualização de Cancun, enquanto os seguintes EIPs foram adicionados: EIP6780 (muda a funcionalidade do opcode SELFDESTRUCT), EIP6475 (um novo tipo de serialização simples (SSZ) para representar valores opcionais), EIP1153 ( acrescenta novo em segundo lugar, os EIPs que estão sendo considerados, mas não oficialmente incluídos na atualização são EIP6913 (apresentando a instrução SETCODE), EIP6493 (definindo o esquema de assinatura para transações codificadas em SSZ), EIP4788 (divulgando a raiz da cadeia de sinalizadores no bloco EL cabeçalho), EIP2537 (adiciona a curva BLS12-381 como pré-compilação) e EIP5656 (introduz novas instruções EVM para copiar regiões de memória); finalmente, EOF e EVMMAX (subconjunto de EIP relacionado à implementação de EOF) foram removidos da atualização de Cancun. A atualização EOF foi removida da atualização de Xangai na Ethereum Developers Conference no início de janeiro de 2023 e foi padronizada para aparecer na atualização de Cancun do final de janeiro de 2023 ao início de abril de 2023, mas o desenvolvimento em 29 de abril de 23 EOF é removido novamente durante a reunião dos autores.

A quinta etapa - determinação da proposta final e melhoria detalhada

Em 23 de maio, os detalhes finais da proposta foram simplificados e aprimorados. A mudança de SSZ->RLP significará que os dois SSZEIPs em Cancun não serão mais necessários, então os EIPs6475 e 6493 serão transferidos de Cancun para atualização. Também no caucus do dia 26, Tim Beiko sugeriu que as conversas futuras sobre a expansão do escopo de Cancun sejam limitadas aos cinco EIPs a seguir: EIP-5920, 5656, 7069, 4788 e 2530. Os desenvolvedores agora determinaram a extensão total da atualização de Cancun.

A Ethereum Core Consensus Meeting em 5 de maio de 23 discutiu o EIP4788, que foi mencionado na última vez, e adicionou discussões sobre EIP6987 e EIP6475, que são sobre validadores e transações SSZ, respectivamente;

Na 161ª reunião da camada executiva da Ethereum em 11 de maio de 23, TimBeiko disse que o escopo da atualização de Cancun ainda pode ser modificado nas próximas semanas, mas se não houver uma sugestão clara do desenvolvedor, o escopo da atualização de Cancun será be Mantenha o status "padrão", e a discussão sobre o EIP-4844 mostra que os desenvolvedores concordam em remover o SSZ da implementação EL do EIP-4844, mas isso não afetou o avanço contínuo do 6475. Além disso, os desenvolvedores também discutiram brevemente dois EIPs para consideração em Cancun, a saber, EIP6969 (uma versão modificada do EIP1559) e EIP5656 (instruções EVM eficientes para copiar regiões de memória);

O desenvolvimento do 4844 foi brevemente discutido na reunião do Developer Consensus em 18.05.23, como permitir aplicativos de contrato inteligente no EL para verificar provas do estado CL;

A desativação de SELFDESTRUCT, alterações na especificação EIP-4844, gerenciamento de opcode e possíveis adições de Cancun foram discutidas na 162ª reunião do Ethereum Core em 25 de maio de 2023. Tim Beiko sugeriu que conversas futuras sobre a expansão do escopo de Cancun sejam limitadas aos cinco EIPs a seguir: EIP-5920, 5656, 7069, 4788 e 2530. O desenvolvedor determinará a gama completa de Dencun (Deneb+Cancun) nas próximas semanas;

No 110º Ethereum Consensus Layer Meeting em 1º de junho de 2023, um pesquisador da Ethereum Foundation apresentou os resultados de um experimento de dados sobre a capacidade dos nós da rede principal Ethereum de disseminar grandes quantidades de dados. A partir desse resultado, o pesquisador sugeriu que o EIP4844 The a especificação aumentou de um máximo de 4 blobs para 6 por bloco. Ao mesmo tempo, os desenvolvedores estão considerando incorporar o EIP4788 na atualização de Cancun;

Na reunião de desenvolvedores principais em 13 de junho de 2023, os desenvolvedores confirmaram oficialmente o escopo da atualização, incluindo EIP4844, EIP1153, EIP5656, EIP6780 e EIP4788;

Na reunião de consenso em 15 de junho de 2023, foi discutido quais EIPs centrados em CL incluir no Deneb, entre os quais, EIP-6988, EIP-7044, EIP-7045 foram propostos para serem adicionados, e a equipe do cliente CL concordou em o próximo Teste o aumento do número de blobs na rede de teste EIP-4844 Devnet6 e tome uma decisão final sobre esse assunto dentro de duas semanas. Ao mesmo tempo, Michael Neuder, pesquisador da Ethereum Foundation, propôs cancelar o 32 ETH limite de promessa para ajudar a reduzir o crescimento do conjunto de validadores ativos;

Na reunião de 22 de junho de 2023, Tim propôs mover o endereço pré-compilado de 4844 para 0xA, empacotá-los e mover o BLS para outro endereço, embora este pré-compilado tenha sido introduzido por meio do EIP2537, não será considerado no plano Cancun;

Na reunião de consenso em 29 de junho de 2023, os desenvolvedores continuaram a discutir o número de blobs, aumentaram o limite de blob alvo de 2 para 3 e aumentaram o limite máximo de blob de 4 para 6. Ao mesmo tempo, o 4844 testnet Devnet #7 será lançado em breve.

essa vida

O conteúdo principal é EIP4844, Proto-Danksharding

As faixas EIP finais para a atualização de Cancún são: EIP4844, EIP1153, EIP5656, EIP6780 e EIP4788. Ao mesmo tempo, na 111ª reunião do Ethereum ACDC em 19 de junho, os desenvolvedores continuaram a discutir EIP6988, EIP7044 e EIP7045 para inclusão no Deneb. Os desenvolvedores disseram que planejam fundir os três EIPs mencionados na especificação Deneb nas próximas semanas.

Análise dos principais EIPs

EIP4844

Introdução:

O nome da proposta EIP4844 é Proto-Danksharding, que é a solução de pré-sharding para a versão completa do Danksharding.Todo o conjunto de esquemas de sharding na verdade gira em torno do Rollup para expansão na cadeia. O objetivo da solução é expandir o Rollup da camada 2 - ajudando o L2 a reduzir as taxas e aumentar o rendimento, ao mesmo tempo em que abre caminho para o sharding total.

Na teleconferência de 23 de fevereiro, os desenvolvedores do Ethereum atualizaram o EIP4844 e o nomearam Deneb, que é o nome de uma estrela de primeira classe em Cygnus. Ou seja, o nome do EIP4844 na versão relevante do GitHub será atualizado para Deneb no futuro; Na reunião de 1º de março, houve algumas mudanças na próxima especificação de atualização do Ethereum, que se chama Deneb no lado CL e Cancun no lado EL;

Na reunião de desenvolvedores em 23 de junho de 23, os desenvolvedores atualizariam o endereço pré-compilado de EIP4844. Atualmente, os principais desenvolvedores adicionaram 9 pré-compilações ao EVM e criarão duas pré-compilações nos endereços "0xA" e "0xB" ativando EIP4844 e 4788, respectivamente. Na reunião de consenso em 29 de junho, foi preparada a Devnet#7, uma rede dedicada de teste de curto prazo para EIP4844.

EIP-4844 apresenta um novo tipo de transação - BlobTranscation.

Introdução aos blobs:

O Blob, semelhante a um pacote de dados plug-in, tem apenas um espaço de armazenamento de 128KB no início. No início da discussão da proposta, o alvo e o limite do Blob eram 2/4. Na reunião de desenvolvedores em 9 de junho , 23, foi ajustado para 3/6 . Ou seja, atualmente, cada transação no Ethereum pode transportar até três transações Blob, que é 384 KB, e a capacidade targetBlob de cada bloco é 6, que é 768 KB, e pode transportar no máximo 16 transações Blob, que é 2 MB;

Pode ter um certo impacto na estabilidade da rede, mas a equipe de desenvolvimento do Ethereum decidiu testá-lo primeiro para evitar a necessidade de hard forks subsequentes para expandir o bloco blob.

Blob usa KZGcommit Hash como Hash para verificação de dados, semelhante ao Merkle;

Depois que o nó sincronizar o BlobTransaction na cadeia, a parte do Blob expirará e será excluída após um período de tempo, e o tempo de armazenamento é de três semanas.

O papel do Blob - melhorar o TPS do Ethereum enquanto reduz os custos

Atualmente, o volume total de dados de todo o Ethereum é de apenas cerca de 1 TB, e o Blob pode trazer 2,5-5 TB de volume de dados adicionais para o Ethereum todos os anos, o que excede diretamente o próprio livro-razão várias vezes;

Para nós, o download de 1 MB a 2 MB de dados blob por bloco não causará sobrecarga de largura de banda, e o espaço de armazenamento aumentará apenas a quantidade fixa de dados blob de cerca de 200 a 400 GB por mês, o que não afetará a descentralização de todo o Nó Ethereum, mas a expansão em torno do Rollup é bastante aprimorada;

E o nó em si não precisa armazenar todos os dados do blob, porque o blob é na verdade um pacote de dados temporário, então, na verdade, o nó só precisa baixar uma quantidade fixa de dados por três semanas.

O papel de EIP-4844 - abrindo o primeiro capítulo da narrativa de Danksharding

Alta expansão: Atualmente, o EIP-4844 pode inicialmente expandir a capacidade L2. A versão completa do Danksharding pode expandir a quantidade de dados Blob no EIP-4844 de 1 MB para 2 MB para 16 MB para 32 MB, o que garante descentralização e segurança. Alta expansão;

Taxas baixas: de acordo com os analistas da Bernstein, o Proto-dank-sharding pode reduzir as taxas da rede da camada 2 para 10 a 100 vezes o nível atual;

Os dados reais:

A rede de teste Opside implantou 4844 e a observação atual pode reduzir o custo de rollup em 50%;

A solução técnica DA da EigenLayer não revela muito para avaliar seus dados;

Estritamente falando, Celestia tem pouco a ver com Ethereum, e seu custo DA não pode ser avaliado agora, dependendo de suas soluções técnicas específicas;

A solução da Ethstorage é fazer upload de seu certificado de armazenamento Layer2, e seu custo DA pode ser reduzido para 5% do original;

A Topia espera reduzir os custos de 100 a 1.000 vezes, porque o Danksharding da rede principal também precisa levar em consideração a segurança e a compatibilidade com a transmissão da rede P2P da Camada 1.

Solução DA: Danksharding (uma solução de sharding para expansão do Ethereum) atualmente pode causar problemas como carga excessiva de nós (acima de 16mb) e disponibilidade insuficiente de dados (período de validade de 30 dias). Solução:

DataAvailability Sampling - reduz a carga do nó

Corte os dados no Blob em fragmentos de dados e deixe os nós mudarem de baixar os dados do Blob para verificar aleatoriamente os fragmentos de dados do Blob, de modo que os fragmentos de dados do Blob sejam espalhados em cada nó do Ethereum, mas os dados completos do Blob sejam armazenados em todo o ledger Ethereum In Fang, a premissa é que os nós precisam ser suficientes e descentralizados;

O DAS usa duas tecnologias: codificação de eliminação (ErasureCoding) e compromisso polinomial KZG (KZGCommitment);

Proposer-Bundler Separation (PBS) - resolve o problema da divisão de trabalho do nó, permitindo que os nós com configuração de alto desempenho baixem todos os dados para codificação e distribuição e que os nós com configuração de baixo desempenho sejam responsáveis pela verificação pontual.

Os nós com configurações de alto desempenho podem se tornar construtores. Os construtores só precisam baixar os dados blob para codificação e criar blocos e, em seguida, transmitir para outros nós para verificações pontuais. Para os construtores, como o volume de dados de sincronização e os requisitos de largura de banda são altos, será relativamente centralizado;

Um nó com configuração de baixo desempenho pode se tornar um proponente (Proposer). O proponente só precisa verificar a validade dos dados e criar e transmitir o cabeçalho do bloco (BlockHeader). No entanto, para o proponente (Proposer), a quantidade de dados síncronos e os requisitos de largura de banda são relativamente altos. Baixos, portanto, será descentralizado.

Lista anti-censura (crList) - resolve o problema de que os empacotadores podem deliberadamente ignorar certas transações e inserir transações que desejam obter MEV devido ao seu excessivo poder de revisão.

Antes que o construtor (Builder) empacote as transações do bloco, o proponente (Proposer) primeiro publicará uma lista resistente a revisão (crList), que contém todas as transações no mempool;

O construtor (Builder) só pode optar por empacotar e classificar as transações em crList, o que significa que o construtor não pode inserir sua própria transação privada para obter MEV, nem pode rejeitar deliberadamente uma transação (a menos que o Gaslimit esteja cheio);

Após o empacotamento, o Builder transmite a versão final do Hash da lista de transações para o Proponente, e o Proponente seleciona uma das listas de transações para gerar um cabeçalho de bloco (BlockHeader) e transmiti-lo;

Quando o nó sincroniza os dados, ele obterá o cabeçalho do bloco do proponente (Proposer) e, em seguida, obterá o corpo do bloco do empacotador (Builder), para garantir que o corpo do bloco seja a versão final selecionada.

PBS de slot duplo - resolve o problema de que empacotadores centralizados estão se tornando cada vez mais centralizados ao adquirir MEV

Use o modo de lance para determinar o bloco:

O construtor (Builder) cria o cabeçalho do bloco da lista de transações após obter a crList e os lances;

O proponente (Proponente) seleciona o cabeçalho do bloco e o construtor (Builder) que finalmente lance com sucesso, e o proponente recebe incondicionalmente a taxa de lance vencedor (independentemente de um bloco válido ser gerado);

O comitê de verificação (Comitês) confirma o cabeçalho do bloco vencedor;

O Construtor divulga o corpo do bloco vencedor;

O comitê de verificação (Comitês) confirma o corpo do bloco vencedor e realiza uma votação de verificação (se o bloco for aprovado, o bloco é produzido e, se o embalador deliberadamente não der o corpo do bloco, considera-se que o bloco não existir).

significado:

Em primeiro lugar, o construtor (Builder) tem mais poder para empacotar transações, mas o crList mencionado acima, em primeiro lugar, limita a possibilidade de inserir transações temporariamente e, em segundo lugar, se o construtor (Builder) quiser lucrar alterando a ordem das transações, é é necessário pagar um grande custo de licitação no início para garantir que ele possa obter a qualificação da cabeça do bloco, então o lucro do MEV obtido será ainda mais reduzido e, em geral, terá um impacto nos meios e no valor real de obtenção MEV;

No entanto, no estágio inicial, apenas um pequeno número de pessoas pode se tornar empacotador (considerando questões de desempenho do nó), enquanto a maioria das pessoas se torna apenas proponentes, o que pode levar a uma maior centralização. pequeno Sob certas circunstâncias, alguns mineradores experientes com recursos MEV terão maior probabilidade de licitar com sucesso, o que afetará ainda mais o efeito real da solução MEV;

Isso tem implicações para algumas soluções MEV que usam leilões MEV.

significado:

O EIP4844 é na verdade uma versão super simplificada do Danksharding: ele fornece a mesma interface de aplicativo do Danksharding, incluindo um novo opcode chamado DataHash e um novo objeto de dados chamado BinaryLarge Objects, que é Blob;

proto-danksharding é uma proposta de "suporte" (isto é, formato de transação e regras de verificação) para implementar a especificação Danksharding completa: no entanto, nenhum sharding foi implementado ainda e todos os verificadores e usuários ainda precisam verificar diretamente a disponibilidade de dados completos ;

Por que você escolhe proto-danksharding em vez de EIP4488 para reduzir diretamente a taxa de camada2 a longo prazo, porque apenas um pequeno ajuste é necessário ao atualizar para um fragmento completo no futuro:

A principal diferença prática entre o EIP4488 e o proto-danksharding é que o EIP-4488 tenta minimizar as alterações que o Ethereum precisa fazer hoje, enquanto o proto-danksharding faz mais alterações no Ethereum hoje para atualizar para o Ethereum no futuro. necessário para fragmentação de versão completa;

Embora a implementação de sharding completo (com amostragem de disponibilidade de dados, etc.) seja uma tarefa complexa e ainda haja um trabalho complexo a ser feito após a implementação do proto-danksharding, essas complexidades serão controladas na camada de consenso. Depois que o proto-danksharding é implantado, a equipe do cliente da camada executiva, os desenvolvedores de rollup e os usuários não precisam fazer nenhum trabalho adicional ao fazer a transição para o sharding completo.

Para obter a fragmentação completa, é necessário concluir a implementação real de PBS, prova delegada e amostragem de disponibilidade de dados, mas essas modificações serão concentradas na camada CL e os desenvolvedores não precisam reajustar: atualmente 4844 implementa um novo tipo de transação , que é semelhante a O formato da transação, a lógica de validação cruzada consensual e a lógica da camada de execução necessária na fragmentação completa são exatamente as mesmas, e também é derivado um preço de gás independente autoajustável para blobs. o futuro, PBS e certificados de delegação precisam ser concluídos e a implementação real da amostragem de disponibilidade de dados, mas essas modificações são apenas na camada CL e não requerem modificações pela camada EL ou desenvolvedores cumulativos, o que é conveniente para desenvolvedores.

Seguido por SELFDESTRUCTremoval, EIP-6780 foi finalmente determinado como a solução mais adequada, mas na reunião de desenvolvedores no dia 26, Tim propôs adicionar outro opcode SETCODE a esta proposta para permitir que as contas programáticas ainda sejam atualizadas

SELFDESTRUCTremoval EIP-6780：X

fundo:

Em 21 de março, Vitalik propôs que o SELFDESTRUCT faz mais mal do que bem à ecologia Ethereum. A principal razão é que é o único que pode alterar um número infinito de objetos de estado em um único bloco, resultando em alterações no código do contrato e pode ser modificado sem o consentimento da conta. O código de operação do saldo da conta tem um grande perigo oculto para a segurança do Ethereum;

A única maneira de remover um contrato na cadeia é SELFDESTRUCT. Se você chamar a função de autodestruição no contrato, poderá autodestruir o contrato. O Ethereum armazenado no contrato será enviado para o endereço designado. O código restante e as variáveis de armazenamento serão removidos na máquina de estado. Na verdade, a ação de destruição de contratos parece boa em teoria, mas na verdade é muito perigosa. Embora a função de autodestruição possa ajudar os desenvolvedores a excluir o contrato inteligente e transferir o saldo do contrato para o endereço especificado em caso de emergência, esse recurso também é usado por criminosos, tornando-o um meio de ataque.

Na reunião de desenvolvedores do núcleo em 13 de abril de 23, quatro propostas sobre SELFDESTRUCT foram apresentadas para participar da discussão, ou seja, 6780, 4758, 6046 e 6190, e o EIP6780 de acompanhamento foi determinado como a proposta final.

Introdução: selfdestruct é o botão de emergência do contrato inteligente, que destrói o contrato e transfere o ETH restante para a conta designada.

EIP6780: Desabilitar SELFDESTRUCT a menos que estejam na mesma transação no contrato.

ATUALIZAÇÃO: Em 26 de maio, a tim propôs que além de remover o SELFDESTRUCT, adicionasse outro opcode - SETCODE, para permitir que as contas programáticas ainda fossem atualizadas. (Ou seja, a função de atualização é adicionada e a propriedade no contrato inteligente é atualizada por meio de atualização/upgrade.) Aqui, as vantagens do EIP4758 são absorvidas, o que permite que o dapp tenha espaço para atualização.

Motivo: a manipulação do código SELFDESTRUCT originalmente exigia grandes alterações no estado da conta, como a exclusão de todos os códigos e armazenamento. Isso cria dificuldades para usar as árvores Verkle no futuro: cada conta será armazenada em muitas chaves de conta diferentes que não serão explicitamente conectadas à conta root.

ALTERADO: Este EIP implementa uma alteração que remove SELFDESTRUCT, com as duas exceções a seguir

Os aplicativos que são usados apenas para sacar fundos do SELFDESTRUCT ainda funcionarão;

O AUTODESTRUTO utilizado na mesma transação no contrato também não precisa ser alterado.

Significado: Melhorar a segurança

Anteriormente, havia um contrato na rede principal que usava SELFDESTRUCT para restringir quem pode iniciar transações por meio do contrato;

Para evitar que os usuários continuem depositando fundos e negociando em um cofre após SELFDESTRUCT, este cofre pode fazer com que alguém roube tokens no cofre durante o uso repetido.

As três propostas abaixo são propostas relacionadas ao SELFDESTRUCT que foram excluídas posteriormente. 6780 foi oficialmente selecionado na reunião de desenvolvedores do núcleo em 28 de abril de 23, e as três propostas restantes foram abandonadas porque a equipe de desenvolvimento do Ethereum eventualmente queria excluir completamente o opcode SELFDESTRUCT, e as três propostas seguintes são mais alteradas por meio de substituição.

EIP-4758 (OBSOLETO): Desative SELFDESTRUCT alterando SELFDESTRUCT para SENDALL, que restaura todos os fundos para o chamador (envia todo o ether da conta para o chamador), mas não exclui nenhum código ou armazenamento.

Motivo: o mesmo que acima, a manipulação anterior de códigos SELFDESTRUCT exigia grandes alterações no estado da conta, como excluir todos os códigos e armazenamento. Isso cria dificuldades para usar as árvores Verkle no futuro: cada conta será armazenada em muitas chaves de conta diferentes que não serão explicitamente conectadas à conta root.

Mudar:

Opcode SELFDESTRUCT renomeado para SENDALL, agora apenas move todo o ETH na conta para o chamador, o esquema não quebra mais o código e o armazenamento ou altera os nonces;

Todos os reembolsos relacionados SELFDESTRUCT foram excluídos

significado:

A funcionalidade original é preservada em relação ao EIP-6780, pois alguns aplicativos ainda/precisam utilizar o código SELFDESTRUCT.

EIP-6046 (reprovado): Substitua SELFDESTRUCT por DEACTIVATE. Altere SELFDESTRUCT para não excluir a chave de armazenamento e use um valor especial no nonce da conta para indicar a desativação

Razão: Igual ao anterior, com as árvores Verkle, as contas serão organizadas de forma diferente: as propriedades da conta (incluindo armazenamento) terão chaves separadas, mas será impossível percorrer e encontrar todas as chaves usadas. A manipulação de códigos SELFDESTRUCT anteriormente exigia grandes alterações no estado da conta, tornando muito difícil continuar usando SELFDESTRUCT em árvores Verkle.

Mudar:

Altere as regras introduzidas pelo EIP-2681 para que os incrementos de nonce regulares sejam limitados por 2^64-2 em vez de 2^64-1;

AUTODESTRUIÇÃO é alterado para:

Não exclua nenhuma chave de armazenamento e deixe a conta no lugar;

Transfira o saldo da conta para o destino e defina o saldo da conta como 0.

Defina o nonce da conta como 2^64-1.

Nenhum reembolso desde EIP-3529;

A regra relevante SELFDESTRUCT de EIP-2929 permanece inalterada.

significado:

Esta proposta tem mais flexibilidade do que outros comportamentos que excluem diretamente SELFDESTRUCT.

EIP-6190 (obsoleto): Altere SELFDESTRUCT, compatível com Verkle, para que cause apenas um número limitado de alterações de estado

Razão: Igual ao anterior, com as árvores Verkle, as contas serão organizadas de forma diferente: as propriedades da conta (incluindo armazenamento) terão chaves separadas, mas será impossível percorrer e encontrar todas as chaves usadas. A manipulação de códigos SELFDESTRUCT anteriormente exigia grandes alterações no estado da conta, tornando muito difícil continuar usando SELFDESTRUCT em árvores Verkle.

Alteração: Ao invés de destruir o contrato ao final da transação, acontece o seguinte ao final da transação que o chamou:

O código do contrato é definido como 0x1 e o número aleatório é definido como 2^64-1.

O 0º slot do contrato é definido para o endereço que será publicado quando o contrato usar o opcode CREATE (keccak256(contractAddress, nonce)). O número aleatório é sempre 2^64-1.

Se o contrato se autodestrói após a chamada ser encaminhada por um ou mais contratos de alias, defina o 0º slot de armazenamento do contrato de alias para o endereço calculado na etapa 2;

O saldo do contrato será todo transferido para o endereço no topo da pilha;

O topo da pilha é estourado.

significado:

Projetado para permitir que SELFDESTRUCT subseqüentemente forme árvores Verkle com alterações mínimas;

O custo do gás aumentou com a aplicação do EIP-2929.

Depois, há o EIP1153, que economiza gás e abre caminho para futuros projetos de armazenamento

EIP1153X

Resumo: opcodes de armazenamento transitórios, adicione opcodes para manipular o estado que se comporta da mesma forma que os armazenamentos, mas descarta após cada transação.

razão:

A execução de uma transação no Ethereum pode gerar vários quadros de execução aninhados, cada quadro criado por uma instrução CALL (ou similar). Os contratos podem ser reinseridos na mesma transação, caso em que mais de um quadro pertence a um contrato.

Atualmente, essas estruturas podem se comunicar de duas maneiras: entrada/saída por meio de instruções CALL e por meio de atualizações de armazenamento. A comunicação via I/O não é segura se houver uma estrutura intermediária pertencente a outro contrato não confiável.

Tomando o bloqueio de reentrância como exemplo, ele não pode contar com quadros intermediários para transmitir o estado do bloqueio: SLOAD de comunicação SSTORE por meio de armazenamento é caro e o armazenamento transitório é uma solução dedicada e eficiente em termos de gás para o problema de comunicação entre quadros.

Alterado: Dois novos opcodes foram adicionados ao EVM, TLOAD (0xb3) e TSTORE (0xb4).

O armazenamento temporário é privado do contrato que o possui e, como o armazenamento persistente, apenas a estrutura do contrato proprietário pode acessar seu armazenamento efêmero. Ao acessar o armazenamento, todos os quadros acessam o mesmo armazenamento efêmero da mesma forma que o armazenamento persistente, mas de maneira diferente da memória.

Possíveis casos de uso:

trava de reentrância;

Endereços CREATE2 computáveis na cadeia: os parâmetros do construtor são lidos do contrato de fábrica, em vez de serem passados como parte do hash do código de inicialização;

Aprovação EIP-20 de transação única, por exemplo, #temporaryApprove(addressspender, valor uint256);

Contrato de taxa de transferência: pague uma taxa ao contrato de token para desbloquear transferências durante as transações;

Modo "Till": Permite ao usuário realizar todas as operações como parte do callback, e verifica se o "till" está balanceado ao final;

Metadados de chamada de proxy: passe metadados adicionais para implementar contratos sem usar dados de chamada, como os valores de parâmetros imutáveis do construtor de proxy.

significado:

Economize gás e tenha regras de cobrança de gás mais simples;

Resolver o problema de comunicação entre quadros;

não altera a semântica das operações existentes;

Não há necessidade de limpar o slot de armazenamento após o uso;

Projetos de armazenamento futuros (como árvores Verkle) não precisam considerar a questão de estornos para armazenamento instantâneo.

Depois, há 4788, que pode reduzir a suposição de confiança do pool de promessas

EIP4788：X

Resumo: Raízes do bloco Beacon no EVM.

Atualização: Na reunião de desenvolvedores em 15.06.23, os desenvolvedores propuseram fazer alterações no código para melhorar a experiência do staker, este EIP divulgará a raiz do bloco da cadeia de beacon, que contém as informações do estado da cadeia interna do EVM, para confiança dos desenvolvedores do DApp. acesso minimizado.

Alterado: Envie as raízes de hash de cada bloco de cadeia de beacon no cabeçalho de carga útil de execução correspondente, armazene essas raízes em um contrato no estado de execução e adicione um novo opcode para ler esse contrato.

Significado: Esta é uma proposta de modificação de código, que propõe modificar a Máquina Virtual Ethereum (EVM) para que ela possa divulgar os dados da raiz do estado da camada de contrato (CL) na camada de execução (EL), que pode fazer diferentes protocolos e aplicações na rede Ethereum A comunicação entre os programas é mais eficiente e segura. Permite designs mais confiáveis para pools de estaqueamento, pontes e protocolos de reestaqueamento.

Finalmente, há o 5656, que fornece um novo opcode de cópia de memória eficiente, mas está atualmente em estado de ser temporariamente incluído em uma atualização devido à sua largura de banda de teste

EIP5656X

Introdução: MCOPY-instrução de cópia de memória.

ATUALIZAÇÃO: Em 23.06.23, a equipe de desenvolvimento afirmou que inicialmente estava dividida sobre o MCOPY porque, embora resolvesse o problema de segurança, eles estavam preocupados com a largura de banda de implementação + teste necessária para adicioná-lo à atualização, mas finalmente concordaram em incluir o EIP , No entanto, se o desenvolvedor encontrar problemas de capacidade no teste ou no lado do cliente, ele será considerado para remoção. Como tal, o MCOPY está em estado de ser temporariamente incluído na atualização de Cancún.

Alterado: forneceu uma instrução EVM eficiente para copiar regiões de memória.

Significado: A cópia de memória é uma operação fundamental, mas há um custo para implementá-la no EVM.

Com a disponibilidade da instrução MCOPY, as palavras e frases do código podem ser copiadas com mais precisão, o que melhorará o desempenho da cópia de memória em cerca de 10,5%, o que é muito útil para várias operações computacionais intensivas;

Também seria útil para os compiladores gerar bytecodes menores e mais eficientes;

Ele pode economizar uma certa quantia de custo de gás para pré-compilação de identidade, mas não pode realmente promover a realização dessa parte.

Lista de candidatos EIP

Em 15 de junho de 23, a reunião de consenso do desenvolvedor discutiu quais EIPs centrados em CL incluir no Deneb, entre os quais EIP6988, EIP7044 e EIP7045 foram propostos para serem adicionados.

EIP6988：X

Resumo: Impede que validadores cortados sejam eleitos como proponentes de blocos.

Significado: O aumento das penalidades por nós violados beneficiará a TVP.

EIP7044：X

Resumo: Garantir que as saídas assinadas do validador sejam permanentemente válidas.

Significado: Pode melhorar a experiência do staker até certo ponto.

EIP7045：X

Resumo: estenda o intervalo de inclusão do slot de atestado de uma janela contínua de uma época para duas épocas.

Significado: Aumente a segurança da rede.

Excluir a análise do EIP

Na 160ª reunião Ethereum ACDE em 29 de abril de 23, EVMMAX e EOF foram confirmados para serem removidos desta atualização, e alterações relacionadas ao EOF podem ser introduzidas em atualizações diárias subsequentes

EVMMAXEIPs：

Resumo: EVMMAX visa trazer maior flexibilidade para operações aritméticas e esquemas de assinatura no Ethereum. Atualmente, existem duas propostas EVMMAX, uma com EOF e outra sem EOF.

EIP6601: Extensões Aritméticas Modulares EVM (EVMMAX)

Mudança: É uma iteração do EIP5843, a diferença do EIP5843 é:

6601 introduz um novo tipo de seção EOF que armazena o módulo, o parâmetro Montgomery pré-computado, o número de valores que serão usados (o módulo configurável em tempo de execução ainda é suportado);

6601 usa um espaço de memória separado para valores EVMMAX, com novos opcodes de carga/armazenamento para mover valores entre a memória EVM<->EVMMAX;

O 6601 suporta operações em módulos de até 4096 bits (limite provisório mencionado no EIP).

Significado: EIP-5843 introduz adição, subtração e multiplicação modulares eficientes para a Máquina Virtual Ethereum, e o EIP-6601 se baseia nisso introduzindo uma seção de configuração, um espaço de memória separado e novos opcodes para operações aritméticas modulares Oferece melhor organização e flexibilidade enquanto oferece suporte a módulos maiores e melhora o desempenho do EVM.

Como um contrato EVM, permitindo operações aritméticas de curva elíptica em várias curvas, incluindo BLS12-381;

MULMOD reduz o custo do gás de operar em valores de até 256 bits em 90-95% em comparação com os opcodes ADDMOD existentes;

Permite que a pré-compilação modexp seja implementada como contratos EVM;

Reduza significativamente o custo da verificação ZKP em funções hash algébricas (como MiMC/Poseidon) e EVM.

EIP6690:

Alteração: EIP-6990 é uma proposta adaptada de EIP-6601 para introduzir operações aritméticas modulares otimizadas para o EVM sem depender de EOF. Enquanto o EIP-6601 requer EIP-4750 e EIP-3670 como dependências, o EIP-6990 fornece uma solução mais autônoma. Ele fornece uma abordagem mais simplificada removendo a dependência do EOF.

Significado: Ele mantém a funcionalidade principal do EIP-6601 para realizar operações aritméticas modulares otimizadas em módulos ímpares de até 4096 bits. Essa simplificação permite implementação e adoção mais eficientes, ao mesmo tempo em que oferece os benefícios associados ao EIP-6601.

Mudanças EOF:

Introdução: EOF é uma atualização do EVM, que introduz novos padrões de contrato e alguns novos opcodes.O tradicional bytecode EVM (bytecode) é uma sequência não estruturada de bytecode de instruções. EOF introduz o conceito de contêiner, que implementa bytecode estruturado. O contêiner consiste em um cabeçalho e várias seções para estruturar o bytecode. Após a atualização, o EVM poderá executar o controle de versão e executar vários conjuntos de regras de contrato ao mesmo tempo.

EIP663:

Resumo: Instruções ilimitadas de SWAP e DUP

Significado: Introduzindo duas novas instruções: SWAPN e DUPN, que diferem de SWAP e DUP aumentando a profundidade da pilha de 16 elementos para 256 elementos

EIP3540:

Introdução:

Antigamente, o bytecode EVM implantado na cadeia não tinha uma estrutura pré-definida, e o código só era verificado antes de ser executado no cliente. Isso não é apenas um custo indireto, mas também impede os desenvolvedores de introduzir novas funções .Ou depreciar a funcionalidade antiga.

Este EIP introduz um contêiner que pode ser estendido e controlado por versão para o EVM, e declara o formato do contrato EOF. Com base nisso, o código pode ser verificado quando o contrato EOF é implantado, ou seja, validação em tempo de criação, o que significa que pode impedir a implantação de contratos não razoáveis que estejam em conformidade com o formato EOF. Essa alteração implementa o controle de versão EOF, que ajudará a desabilitar instruções EVM existentes ou introduzir funções de grande escala (como abstração de conta) no futuro.

significado:

O controle de versão é favorável à introdução ou descontinuação de novas funções no futuro (como a introdução de abstração de conta);

A separação do código do contrato e dos dados é benéfica para a verificação L2 (op), reduzindo o custo do gás dos validadores L2. Ao mesmo tempo, a separação do código do contrato e dos dados também é mais conveniente para ferramentas de análise de dados na cadeia.

EIP3670:

Introdução: Com base no EIP-3540, o objetivo é garantir que o código do contrato EOF esteja de acordo com o formato e seja válido. Para contratos que não estejam em conformidade com o formato, sua implantação será impedida e o Legacybytecode não será afetado.

Significado: com base no contêiner introduzido por 3540, o EIP-3670 garante que o código no contrato EOF seja válido ou impeça sua implantação. Isso significa que opcodes indefinidos não podem ser implantados em contratos EOF, o que tem o benefício adicional de reduzir o número de versões EOF que precisam ser adicionadas.

EIP4200:

Introdução:

Os primeiros opcodes específicos de EOF são introduzidos: RJUMP, RJUMPI e RJUMPV, que codificam destinos como valores imediatos assinados. Os compiladores podem usar esses novos opcodes JUMP para otimizar o custo do gás de implantação e execução do JUMP porque eles eliminam o tempo de execução necessário para fazer a análise de salto para os opcodes JUMP e JUMPI existentes. Este EIP é um complemento ao dynamicjump.

Em comparação com a operação JUMP tradicional, a diferença é que operações como RJUMP não especificam uma posição de deslocamento específica, mas especificam uma posição de deslocamento relativa (de saltos dinâmicos -> saltos estáticos), porque os saltos estáticos geralmente são suficientes.

Significado: otimizar a rede e reduzir custos.

EIP4750:

Leve a função de 4200 um passo adiante: introduzindo dois novos opcodes de CALLF e RETF, uma solução alternativa é realizada para a situação que não pode ser substituída por RJUMP, RJUMPI e RJUMPV, de modo que JUMPDEST não seja mais necessário no contrato EOF, ou seja, portanto, dynamicjump está desabilitado.

Significado: Otimize o código dividindo o código em várias partes.

EIP5450:

Antecedentes: O pano de fundo ainda é que o contrato Ethereum não é verificado quando é implantado, e apenas uma série de verificações é realizada quando está em execução, se a pilha transborda (o limite superior é 1024), se o gás é suficiente e breve.

Conteúdo: Adicionada outra verificação de validade para contratos EOF, desta vez na pilha. Este EIP evita situações em que as implantações de contrato EOF podem levar a estouros/subfluxos de pilha. Dessa forma, os clientes podem reduzir o número de verificações de validade que fazem durante a execução dos contratos EOF.

Significado: Uma grande melhoria é reduzir ao máximo essas verificações que ocorrem durante a execução, e mais verificações ocorrem quando o contrato é implantado.

Após a atualização da reunião de desenvolvedores em 26 de maio, a alteração do tipo de transação de SSZ para RLP relacionado ao EIP4844 significou que os dois SSZEIPs em Cancun não eram mais necessários, então os EIPs6475 e 6493 foram transferidos de Cancun para atualização

EIP6475X

Introdução: Proposta complementar ao EIP4844. Proto-danksharding apresenta um novo tipo de transação que usa a codificação SSZ em vez da codificação RLP usada por outros tipos de transação.

ATUALIZAÇÃO: Durante o 161º Ethereum Execution Layer Core Developers Meeting, as discussões sobre o formato de serialização SSZ para EIP4844 revelaram que inicialmente os desenvolvedores tendiam a introduzir iterações iniciais do formato SSZ para EL por meio de transações blob e, eventualmente, os desenvolvedores planejam trazer todos os tipos de transação foi atualizado de RLP para SSZ, mas os desenvolvedores estão pensando em remover o SSZ do EIP-4844, devido ao seu caminho pouco claro e certamente não sendo capazes de implementá-lo na atualização de Cancún. Após muitas discussões, os desenvolvedores concordaram em remover o SSZ da implementação EL do EIP-4844, mas ainda não removeram o EIP6475. Após a atualização de 26 de maio, a mudança SSZ->RLP significará que os dois SSZEIPs em Cancun não são mais necessários: assim, os EIPs 6475 e 6493 serão removidos de Cancun para atualizações.

EIP6493X

Introdução: Esquema de assinatura de transação SSZ. Este EIP define um esquema de assinatura para transações codificadas de Serialização Simples (SSZ) e abordará como os nós devem lidar com tipos de transação blob formatados no formato SSZ em CL, mas codificados de forma diferente em EL. Este EIP faz parte de uma atualização do formato de serialização Ethereum para consistência entre camadas;

Antecedentes: SSZchanges

Introdução: SimpleSerialiZe é o método de serialização usado na cadeia de beacons.

SSZchanges também inclui três outras propostas de apoio, desta vez apenas 6465 foi introduzida.

EIP6465: Raiz de retirada SSZ, que define o processo de migração de compromissos existentes de Merkle-PatriciaTrie (MPT) para retiradas de Serialização Simples (SSZ);

EIP6404/ EIP6466:

Ambos definem um processo para migrar compromissos existentes de Merkle-PatriciaTrie (MPT) para Simple Serialization (SSZ).

EIP-6404— Raiz da transação SSZ

EIP-6466— Base de Recebimento SSZ

Tim Beiko sugeriu na reunião principal de desenvolvedores em 26 de maio que futuras conversas sobre a expansão do escopo de Cancun sejam limitadas aos cinco EIPs a seguir: EIP5920, 5656, 7069, 4788 e 2537, e que propostas subsequentes serão geradas dentro desse escopo. EIP5656 e EIP4788 subsequentes foram confirmados como propostas formais de atualização e 5920, 7069 e 2537 foram removidos. e trabalho de segurança. Removido da atualização.

EIP5920：X

Introdução: opcode de pagamento. Introduz o novo opcode PAY para transferências Ethereum, que envia Ether para um endereço sem chamar nenhuma de suas funções.

Motivo: Atualmente, enviar ether para um endereço exige que o usuário chame uma função nesse endereço, o que apresenta vários problemas:

Primeiro, ele abre um vetor para ataques de reentrância, já que o receptor pode ligar de volta para o remetente;

Em segundo lugar, ele abre um vetor DoS, portanto, a função pai deve estar ciente de que o receptor pode ficar sem gás ou retornar a chamada;

Por fim, o opcode CALL é desnecessariamente caro para transferências de éter simples, pois requer expansão de memória e pilha, carregamento de dados completos do receptor, incluindo código e memória e, finalmente, precisa realizar uma chamada, possivelmente fazendo outra operação não intencional.

Mudar:

Um novo opcode foi introduzido: (PAY)PAY_OPCODE, onde:

Retire dois valores da pilha: addrthenval.

Transferir wei do endereço de execução val para o endereço addr. Se addr for endereço zero, valwei será programado a partir do endereço de execução.

Armadilhas potenciais: Os contratos existentes serão usados independentemente do saldo real de sua carteira, pois já é possível enviar ether para um endereço sem chamá-lo.

Significado: economizar gás.

ATUALIZAÇÃO: Em 09/06/23, PAY foi removido da atualização devido a preocupações sobre possíveis efeitos colaterais que poderiam existir na forma como o ETH é transferido e o raciocínio, teste e trabalho de segurança necessários para aprovar a proposta.

EIP7069X

Introdução: Instrução CALL modificada

Alteração: Introduzidas três novas instruções de chamada, CALL2, DELEGATECALL2 e STATICCALL2, que têm o efeito de simplificar a semântica. Visa remover a observabilidade do gás da nova diretiva e abrir a porta para uma nova classe de contratos que não são afetados pela reprecificação.

fundo:

63/64ª regra: limitar a profundidade da chamada e garantir que o chamador tenha gás restante para fazer alterações de estado após o retorno do chamado;

Antes da introdução das regras 63/64, o gás disponível para o chamador precisava ser calculado com certa precisão. O Solidity tem uma regra complexa que tenta estimar o custo do lado do chamador de executar a própria chamada para definir um valor de gás razoável.

A regra 63/64 é atualmente introduzida:

Inspeção de profundidade de chamada removida;

Certifique-se de reservar pelo menos 5000 gases antes de executar o comportamento chamado;

Certifique-se de que pelo menos 2300 gás esteja disponível para o comportamento chamado.

Regras de subsídio: como o conhecido subsídio 2300, quando um contrato chama outro contrato, o contrato chamado receberá 2300gas para realizar operações muito limitadas (suficiente para fazer um pequeno cálculo e gerar um log, mas não o suficiente para preencher um slot de armazenamento ), uma vez que estabelece uma quantidade fixa de gás, desde que o preço do gás possa ser ajustado, as pessoas não têm como determinar que tipo de cálculo esses gases podem suportar.

Significado: abrir caminho para a introdução do EOF no futuro e facilitar a execução de grandes contratos.

Remover a opcionalidade do gás: o novo comando não permite especificar o limite do gás, mas se baseia na "regra 63/64" (principalmente referente à reprecificação do gás usada para um grande número de operações IO no EIP-150, o que aumenta o consumo de gás de operações específicas) para Limitação de gás, essa importante melhoria é para simplificar as regras em torno do "subsídio", independente se o valor é enviado ou não, o chamador não precisa fazer cálculos sobre o gás;

Com a introdução da nova proposta, os usuários sempre podem contornar o erro Outof Gas enviando mais gás na transação (sujeito ao limite de gás do bloco, é claro).

Alguns contratos que enviavam apenas uma quantidade limitada de gás para suas chamadas foram quebrados pelo novo mecanismo de custeio ao aumentar anteriormente os custos de armazenamento (por exemplo, EIP-1884 aumentou o gás para determinados opcodes). Anteriormente, alguns contratos tinham um limite de gás que limitava permanentemente a quantidade de gás que eles podiam gastar, mesmo que eles enviassem para suas sub-chamadas, não daria certo, por mais gás extra que eles enviassem, porque a chamada limitaria o quantidade enviada.

Prepare o caminho para a introdução do EOF: uma vez que o EVM Object Format (EOF) é introduzido, as antigas instruções de chamada podem ser rejeitadas no contrato EOF, garantindo que sejam amplamente imunes às mudanças no preço do gás. Como essas operações são necessárias para remover a observabilidade do gás, a EOF as exigirá no lugar das instruções existentes;

Mais códigos de retorno de status de conveniência: Foram introduzidas funções de conveniência que retornam códigos de status mais detalhados: sucesso (0), reversão (1), falha (2) e são expansíveis no futuro.

EIP2537：X

Resumo: Uma pré-compilação da manipulação da curva BLS12-381.

ALTERADO: Adicionadas operações na curva BLS12-381 como pré-compilações para o conjunto necessário para executar operações com eficiência, como verificação de assinatura BLS e verificação SNARKs.

Significado: Ethereum pode criar provas criptográficas mais seguras e permitir uma melhor interoperabilidade com a cadeia de beacons.

PR3175 foi mencionado, mas nunca pré-selecionado, sem maiores discussões

PR3175：X

Resumo: Esta proposta impediria que validadores penalizados propusessem blocos quando retirados da fila. Se mais de 50% dos validadores forem penalizados por comportamento malicioso, esses validadores ainda poderão propor bloqueios enquanto são removidos à força da rede. Alterar essa lógica é uma alteração relativamente pequena da camada CL que fornece proteção contra "modos de falha alta", dizem os desenvolvedores.

De acordo com o 108º Ethereum Core Developers Consensus Meeting do dia 4 de maio, o PR3175 está em processo de formatação como EIP, e será alterado para EIP-6987, ou seja, por questões de segurança, para evitar que nós de verificação cortados sejam selecionados é o proponente do bloco.

futuro

Com base nas informações acima, chegamos às seguintes conclusões:

1. Os principais objetivos da atualização de Cancun são, em ordem de prioridade, expansão, segurança, economia de gás e interoperabilidade:

Não há dúvida de que a expansão é a primeira prioridade (4844);

Segurança e economia de gás são a segunda prioridade (6780, 1153, 5656 e 7045), levando em consideração uma certa experiência do desenvolvedor;

A terceira é a interoperabilidade, como otimizar a conexão, comunicação e interoperabilidade entre dapps (4788, 7044 e 6988);

Dados esperados: Testnet 4844 pode reduzir o custo de opsiderollup em 50%; as soluções técnicas de EigenLayer e Celestia não divulgaram muito e seus dados não podem ser avaliados; Ethstorage estima que o custo de DA cairá para 5% do original ; Espera-se que o Topia reduza o custo em 100 ~ 1000 vezes.

2. Os próximos 2 a 5 anos, quando Cancun for atualizado para Danksharding, é o período de ouro de desenvolvimento para projetos de camada DA

O limite superior de segurança da Camada 2 depende da camada DA que ela adota. O Proto-Danksharding beneficiará protocolos de armazenamento, protocolos modulares e redes de expansão de armazenamento L1 por meio de armazenamento de dados de estado mais barato.

Primeiro, Danksharding retorna à essência da máquina de estado Ethereum. V God mencionou que o propósito do protocolo de consenso Ethereum não é garantir o armazenamento permanente de todos os dados históricos. Em vez disso, a intenção é fornecer um quadro de avisos em tempo real altamente seguro e deixar espaço para outros protocolos descentralizados para armazenamento de longo prazo (o objetivo do protocolo de consenso Ethereum não é garantir o armazenamento de todos os dados históricos para sempre. Em vez disso, o objetivo é fornecer um quadro de avisos em tempo real altamente seguro e deixar espaço para outros protocolos descentralizados fazerem armazenamento de longo prazo. );

Em segundo lugar, o Danksharding reduz o custo do DA, mas o tempo real de pouso e os problemas de disponibilidade de dados também precisam ser resolvidos.

Redução de custo DA: antes dessa atualização, era necessário chamar calldata para liberar dados do rollup para a cadeia principal do Ethereum, e a taxa de gás para chamar esse código era muito cara, que era o maior gasto na camada 2. EIP4844 introduz blobs de dados como rollups O espaço de dados adicional exclusivo reduzirá muito os custos de armazenamento, reduzindo assim os custos de DA.

O tempo real de pouso é longo e o TPS que pode ser melhorado e o gás que pode ser reduzido ainda é limitado, por isso é bom para o desenvolvimento contínuo de projetos de camada DA no futuro:

No artigo de fragmentação de dados iablesecurity da polynya sobre danksharding, ele mostra que levará de 2 a 5 anos para ser implementado;

Mesmo que aterrisse, o TPS pode aumentar e o nível de gás que pode reduzir ainda é limitado:

EIP4844 atualmente suporta 6 blobs, e o problema de expansão futura só pode ser resolvido por Danksharding;

O espaço atual do bloco Ethereum é de cerca de 200 KB. Após o Danksharding, o tamanho planejado na especificação é de 32 megabytes, o que representa uma melhoria de cerca de 100 vezes. Atualmente, o TPS do Ethereum é de cerca de 15 e, em um estado idealizado, será de cerca de 1500 após ser aumentado em 100 vezes, o que não é uma grande melhoria em magnitude.

Portanto, longo tempo de implementação + mudanças reais limitadas beneficiarão os projetos da camada de DA. Alguns projetos de DA, como Celestia e Eigenda, ainda podem competir com Danksharding por meio de custos mais baratos e TPS mais rápido. Novos projetos de DA, como ETHstoragetopia, também podem preencher a lacuna do mercado anterior.

Questões técnicas, como armazenamento de dados e problemas de disponibilidade de dados, também precisam ser abordadas:

Existem dois custos principais de DA, um é o custo da largura de banda da rede, o outro é o custo do armazenamento e o 4844 em si não resolve o problema de armazenamento e o problema da largura de banda da cadeia de blocos

O blob será armazenado na camada de consenso do Ethereum por cerca de 3 semanas e depois excluído. Se você deseja armazenar registros históricos completos e disponibilizar todos os dados, as soluções atuais incluem: o próprio dapp armazena dados relacionados a si mesmo e a rede do portal Ethereum (atualmente em desenvolvimento) em desenvolvimento) ou protocolos de terceiros, como exploradores de bloco, dados históricos em BitTorrent ou armazenamento espontâneo por usuários individuais.

Portanto, o Proto-Danksharding beneficiará protocolos de armazenamento, protocolos modulares e redes de expansão de armazenamento L1:

A demanda por chamar dados históricos levará a um novo canal de desenvolvimento para protocolos de armazenamento descentralizados ou protocolos de indexação de terceiros;

Os acordos modulares subsequentes podem executar transações através de Rollup de alta velocidade, a camada de liquidação segura é responsável pela liquidação e a camada de disponibilidade de dados de baixo custo e grande capacidade é responsável pela garantia;

É bom para rede de expansão de armazenamento L1, como Ethstorage, que pode fornecer uma solução de segundo nível para armazenamento programável a um custo de armazenamento mais baixo.

3. A atualização de Cancun é boa para diversidade L2, L3, RAAS e disponibilidade de dados e outras faixas

Análise de pista L2:

Top Layer 2, cinco projetos como ArbitrumOrbit, OPStack, Polygon2.0, FractalScaling (em StarkWare) e HyperChain (em zkSync) serão beneficiados. A redução da taxa de armazenamento trazida pelo blob melhorará muito a série anterior de problemas de custo e escalabilidade que limitaram o desenvolvimento da camada 2 e aumentará muito a taxa de transferência de dados. Após resolver o problema de custo, a camada principal 2 terá a oportunidade de continuar a implantar recursos específicos funções de alto nível Ecologia L3 simultânea multicadeia personalizada;

A lacuna nos custos operacionais entre a Camada 2 de segundo nível e a Camada 2 principal será reduzida, dando a alguns pequenos projetos mais oportunidades de desenvolvimento, como Aztec, Metis, Boba, ZKspace, layer2.finance, etc.;

Embora as reais necessidades dos projetos modulares de blockchain ainda não tenham sido verificadas, diversas linguagens de programação ainda são possíveis, como Starkware's Cario, linguagens da série Move, linguagens das séries C, c++, C# e Go suportadas pelo Wasm, que podem introduzir mais Muitos web2 desenvolvedores.

Raas análise da faixa:

A vantagem do próprio Raas reside em seu alto grau de customização, requisitos customizados > puro custo e eficiência, portanto a redução de custos é uma grande vantagem do Rollup customizado.

Mas o problema da pista RAAS é que pode ser OverHype, e até a própria pista RAAS tem dúvidas. Enfrentando a competição dos 5 melhores layer2s e o surgimento de vários novos DAs, temos que questionar se os novos projetos podem formar uma trilha.

Em primeiro lugar, a vantagem da implantação da cadeia de aplicativos head layer2 está na integridade da estrutura de rede e na segurança da ecologia intercadeia, e a vantagem do RAAS está em sua personalização e liberdade;

No entanto, as barreiras técnicas RAAS das séries OP e ZK não são fortes no momento e ainda estão no estágio testnet no curto prazo, e não há interação real do produto. Considerando o progresso real do RAAS, formulários técnicos e as vantagens ecológicas de layer3 no futuro, a demanda real por RAAS é duvidosa.

Série OP: Embora a atualização básica +4844 da pilha OP tenha trazido algumas pequenas melhorias em custo e eficiência, a atração trazida pelas melhorias não é forte;

Série ZK: Atualmente, muitos projetos líderes seguem a rota ZKEVM e prestam mais atenção à compatibilidade com Ethereum, portanto, o design do circuito sacrificará certa eficiência e não é tão direcionado quanto a série OP. No entanto, a maioria dos ZKRAAS atualmente no mercado ainda usa projetos líderes (como o ZkSync) para bifurcar a cadeia, e as barreiras ainda não são fortes.

Portanto, no curto prazo, OPRAAS ainda tem algum espaço para desenvolvimento antes da camada 3. No longo prazo, ZKRAAS e camada 3 podem ser a tendência futura.

O ZKRAAS tem uma desvantagem de custo maior após 4844 e consome muito mais poder de computação do que o OP. Embora o custo de upload para L1 seja menor que o do OP, isso é apenas uma gota no balde em comparação com o custo do processo de prova, enquanto OP A vantagem é que ele pode construir rapidamente uma ecologia em um curto período de tempo, e ainda há espaço para desenvolvimento antes que a camada 3 chegue;

Para aplicativos DeFi convencionais e mercados NFT, a transformação do rollup não é um requisito rígido, apenas aplicativos de pagamento ou jogos que exigem alta eficiência têm uma demanda mais forte por rollup. No futuro, os projetos defi podem estar em l2, os projetos sociais podem estar em l3 ou off-chain e, finalmente, os principais dados e relacionamentos são colocados em l2. Os projetos de jogos precisam ir para l3 ou rollup, mas considerando que a maioria dos atuais os jogos em cadeia são essencialmente fundos, e a incapacidade dos tokens de circular externamente trouxeram gargalos de desenvolvimento, juntamente com o surgimento de jogos em toda a cadeia, o apelo ecológico do l3 em si é muito maior do que o rollup.

4. A atualização de Cancun melhora a experiência do desenvolvedor e do usuário

A segunda proposta importante da atualização de Cancun, SELFDESTRUCTremoval, irá melhorar ainda mais a segurança do Ethereum.Ao mesmo tempo, para o problema de atualização processual da conta que pode existir após a exclusão, um novo código de operação SETCODE está preparado para melhorar esta situação;

A terceira proposta EIP1153 atualizada por Cancun adiciona códigos de operação de armazenamento transitórios, que podem, em primeiro lugar, economizar gás, em segundo lugar resolver o problema de comunicação entre quadros e, finalmente, abrir caminho para o futuro design de armazenamento, como a árvore Verkle não precisará considerar o reembolso de questão de armazenamento transiente;

EIP5656, a quarta proposta da atualização de Cancun, apresenta a instrução de cópia de memória MCOPY, que pode copiar palavras e frases de código com mais precisão, o que melhorará o desempenho da cópia de memória em cerca de 10%;

A quinta proposta para a atualização de Cancun é o EIP4788, que pode tornar a comunicação entre diferentes protocolos e aplicativos na rede Ethereum mais eficiente e segura, além de permitir designs mais confiáveis para pools de staking, protocolos de ponte e reestaking;

A última atualização de Cancun (15 de junho de 23) propõe adicionar atualizações EIP centradas em CL: EIP6988, EIP7044 e EIP7045, que melhoram a segurança e a usabilidade do Ethereum em detalhes, como melhorar a experiência do penhorador e melhorar a segurança da rede, etc.

Entre as propostas excluídas, a transição SSZ->RLP fez com que dois SSZEIPs (EIP6475 e EIP6493) fossem removidos da atualização de Cancun; propostas relacionadas a EOF foram removidas da atualização de Cancun novamente após serem removidas da atualização de Xangai e são atualmente consideradas possível Será implementado diretamente nas atualizações diárias posteriores; EVMMAX também é removido de Cancun para atualizações junto com EOF porque é um subconjunto de EIP relacionado à implementação de EOF; considerando os possíveis efeitos colaterais que podem existir na forma de transferência de ETH, e a necessidade de passar a proposta O raciocínio, teste e trabalho de segurança, EIP5920 é removido da atualização.

5. Relacionamento com zkml e abstração de conta

Pouco efeito no zkml

ZKML é a combinação de Zero Knowledge Proof (ZeroKnowledge) e Machine Learning (Machine Learning); a combinação de blockchain e modelo ML resolve os problemas de proteção de privacidade e verificabilidade do aprendizado de máquina:

Proteção de privacidade: a confidencialidade dos dados de entrada, como o uso de uma grande quantidade de informações pessoais como dados para alimentar máquinas para treinamento, a confidencialidade das informações pessoais é um requisito importante; ou parâmetros de modelo, como a principal competitividade do projeto, também precisam ser criptografados para manter as barreiras da concorrência. Quando existem problemas de confiança como esses, os modelos de ML serão impedidos de obter dados e aplicativos em maior escala.

Verificabilidade: A tecnologia de prova de conhecimento zero tem uma ampla gama de aplicações e o ZKP permite que os usuários saibam a exatidão das informações sem verificação. E como o modelo de aprendizado de máquina requer muitos cálculos, o modelo ML pode gerar provas por meio do ZK-SNARK, reduzindo o tamanho da prova e aliviando a demanda de poder de computação do ML.

Os requisitos de armazenamento do ZKML têm pouco a ver com o DA: é necessária uma estrutura de armazenamento separada, como Espaço e Tempo, e sua tecnologia principal é o novo protocolo de segurança "SQL Proof". Ou conecte dados on-chain e off-chain de uma maneira simples Formate SQL e carregue os resultados diretamente em contratos inteligentes;

ZK-SNARKs é a principal forma de ZK em ZKML, que pode se adaptar aos requisitos de poder computacional de ML na cadeia. Com o desenvolvimento da criptografia, provas SNARK especialmente recursivas beneficiarão a implementação de ZKML na cadeia:

ZK-SNARKs são caracterizados por alta compacidade. O uso de ZK-SNARKs permite que o provador gere uma prova curta, e o verificador não precisa interagir e apenas precisa realizar uma pequena quantidade de cálculo para verificar sua validade. Isso requer apenas um provador A natureza da interação com os verificadores torna os ZK-SNARKs eficientes e práticos em aplicações práticas e é mais adequado para os requisitos de poder de computação on-chain do ML.

Atualmente, é impossível treinar na cadeia e apenas os resultados dos cálculos fora da cadeia podem ser armazenados na cadeia:

O problema atual de ML é mais devido aos requisitos de poder de computação insatisfeitos e baixo desempenho causado por limitações de algoritmo (não pode ser calculado em paralelo). Os ZK-SNARKs suportam apenas a pequena prova de escala de conhecimento zero ML e pequena quantidade de cálculo, ou seja, a limitação do poder de computação é um fator chave que afeta o desenvolvimento de aplicativos blockchain ZKML, e a cadeia só pode armazenar os resultados de off -cálculos em cadeia.

Boa abstração de conta

Em primeiro lugar, a atualização de Cancun pode reduzir o custo da prova do ZKrollup até certo ponto:

A taxa de transação atual do zkSync depende de 3 aspectos:

O custo fixo do recurso consumido pelo verificador para gerar o certificado SNARK e verificá-lo é relativamente alto;

A taxa de gás quando o verificador envia a prova SNARK para a rede principal Ethereum, esta parte da taxa aumentará de acordo devido ao congestionamento da rede principal;

A taxa de serviço paga pelo usuário ao verificador, incluindo confirmação de transação, transmissão de mensagem, etc.

Portanto, se o 4844 for introduzido, o problema do aumento das taxas de gás causado pelo congestionamento da rede principal será aliviado e o custo das provas ZKP pode ser reduzido até certo ponto. A tendência de desenvolvimento da série ZK não deve ser subestimada.

Em segundo lugar, a abstração de conta transforma transações tradicionais de tx em operações de usuário e, em seguida, empacota operações de usuário em blocos com ECDSA, que ocupa mais armazenamento na cadeia do que antes, portanto, os requisitos de armazenamento são maiores;

Então, a abstração da conta e o ZKrollup podem se complementar:

Atualmente, o problema da abstração da conta é que o GasFee é caro. Como há muitas etapas e contratos inteligentes envolvidos, há muitos dados, o que torna o GasFee caro. A vantagem do ZKRollup é que ele pode reduzir os dados;

A abstração da conta dificulta a garantia da segurança: como o AA envolve vários contratos, a segurança é um problema. No entanto, depois que o L2 for gradualmente formado no futuro, a camada de consenso não será mais alterada, os contratos inteligentes terão mais usos e a segurança de abstração de conta também aumentará. Isso pode ser garantido e, com a verificação confiável do ZKrollup, a segurança será aprimorada ainda mais.

Por fim, considerando a ascensão da tecnologia de IA, ela pode ajudar a aumentar a segurança dos contratos on-chain e otimizar transações on-chain ou etapas de atividade:

IA e segurança: a tecnologia de IA pode ser usada para aprimorar a segurança e a proteção da privacidade das transações on-chain. Por exemplo, a plataforma de segurança Web3 SeQure usa IA para detectar e prevenir ataques maliciosos, fraudes e vazamento de dados, e fornece monitoramento em tempo real e mecanismos de alarme para garantir a segurança e a estabilidade das transações na cadeia;

Otimização de IA e atividades na cadeia: as atividades na cadeia de blocos incluem transações, execução de contratos e armazenamento de dados. Por meio dos recursos inteligentes de análise e previsão da IA, as atividades na cadeia podem ser melhor otimizadas e a eficiência e o desempenho geral melhorados. A IA pode ajudar a identificar padrões de transação, detectar atividades incomuns e fornecer recomendações em tempo real para otimizar a alocação de recursos para redes blockchain por meio de análise de dados e treinamento de modelos.

Portanto, a atualização de Cancun beneficiará gradualmente o desenvolvimento futuro da abstração de contas, desde a expansão do espaço de armazenamento até a complementaridade com o ZKrollup e, em seguida, a combinação com a tecnologia AI.

6. Olhando para o roteiro da Ethereum, o que vem a seguir

Atualmente, o Layer2 não tem desempenho semelhante ao Solana (em termos de latência e taxa de transferência), nem tem desempenho de fragmentação como Near, nem tem desempenho de execução paralela como Sui e Aptos. A atualização de Cancun melhorou a liderança do Ethereum como um líder;

Após a atualização de Cancun, estima-se que vários tempos de desenvolvimento importantes serão totalmente danksharding (2 a 5 anos), pouso MEV e PBS (1 a 3 anos), abstração de conta (1 a 2 anos), ZK tudo (3 a 3 anos). 6 anos) ), EOF e experiência de desenvolvedor (quantas vezes você já viu a extensão?).

O flagelo

Objetivo: Concentrar-se na resolução de problemas de MEV.

Solução: Minimizar o MEV na camada de aplicação através de "Proposer-Builder Separation (PBS)" Neste momento, os blobs podem ser otimizados, e serviços de pré-confirmação ou proteção de preempção podem ser introduzidos.

PBS é a separação de criadores e classificadores de blocos. O sorter é responsável apenas pela triagem, independentemente da cadeia, e o criador do bloco não se preocupa com a transação, seleciona diretamente o pacote feito pelo classificador e o coloca na cadeia. Esse processo vai tornar todo o processo mais justo e amenizar o problema do MEV, que é a ideia de externalizar o MEV.

O grau de conclusão do PBS ainda é muito baixo no momento, e o mais maduro é a cooperação com soluções MEV externas - mevboost de flashbots.

A versão avançada do "Enshrined Proposer-Builder Separation (ePBS)" tem um menor grau de conclusão e um ciclo mais longo, estimando-se que não seja implementada a curto prazo. Além disso, existem versões progressivas do PEPC e Optimistic Relaying, que aumenta a flexibilidade e adaptabilidade da estrutura PBS

TheVerge

Objetivo: usar a árvore Verkel para substituir o Merkle, introduzir uma solução de minimização de confiança, permitir que os nós leves obtenham a mesma segurança que os nós completos e tornar a verificação de bloco o mais simples e portátil possível.

Ao mesmo tempo, a ZKização de L1 é claramente adicionada ao roteiro da Verge. ZK será a tendência geral de expansão e aceleração futuras;

Solução: Introduzir zk-SNARKs para substituir o antigo sistema de provas, incluindo light clients baseados em SNARK; SNARKs com mudanças de estado de consenso; EnshrinedRollups.

As árvores Verkle são uma alternativa mais eficiente às árvores Merkle específicas do estado que não precisam fornecer um caminho de cada nó irmão (nós que compartilham o mesmo pai) para o nó escolhido, mas apenas o próprio caminho como prova Em parte, as provas Verkle são 3 vezes mais eficientes que as provas de Merkle.

EnshrinedRollup refere-se a um Rollup que possui algum tipo de integração de consenso em L1. A vantagem é que ele herda o consenso de L1 e não precisa de tokens de governança para realizar atualizações de rollup. Ao mesmo tempo, realizando cálculos fora da cadeia e apenas publicando os resultados para o blockchain, pode aumentar o número de transações, mas a dificuldade técnica de implementação é relativamente grande. A combinação desses rollups no futuro será capaz de atender a maioria das necessidades do ecossistema blockchain nas próximas décadas.

A depuração

ThePurge refere-se ao objetivo de simplificar o protocolo reduzindo os requisitos de armazenamento para participar da validação da rede. Isso é obtido principalmente por meio da hibernação e do gerenciamento do histórico e do estado. A dormência de dados históricos (EIP-4444) permite que os clientes removam dados históricos com mais de um ano e parem de fornecer serviços no nível P2P.

estado dormente. Quando se trata de lidar com o crescimento do estado, existem dois objetivos principais: apatridia fraca, que se refere ao objetivo de apenas usar o estado para construir blocos, mas não verificá-lo; o estado que está sendo acessado. A hibernação de estado deve reduzir os nós de estado que precisam armazenar em um total de 20 a 50 GB.

No quinto estágio do Purge, o EIP4444 é explicitamente escrito no Roadmap. O EIP-4444 requer que o cliente limpe os dados com mais de um ano. Ao mesmo tempo, existem algumas tarefas de otimização do EVM neste estágio, como simplificar o mecanismo de GAS e pré-compilação EVM, etc.;

TheSplurge

No sexto estágio final do Splurge, o EIP4337 também foi mencionado. Como uma proposta de layout de longo prazo para ecologia de carteira, a abstração de contas melhorará ainda mais a facilidade de uso de carteiras no futuro, incluindo o uso de stablecoins para pagar por gás e carteiras de recuperação social , etc.;