Guia para iniciantes
Gate Post
Transmissões ao vivo
Conversar
Eventos futuros
Notícias
Blog da Gate
Início
Recomendar
Quente
Visão
Publicar

O passado, presente e futuro das atualizações de Cancun

金色财经_vip

Vida passada

**Por que a atualização de Cancún é necessária? **

  • A visão do Ethereum é tornar-se mais escalável e 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:
  • No momento, o TPS e o desempenho são baixos, a taxa de gás é alta e o congestionamento é sério. Ao mesmo tempo, o espaço em disco necessário para executar um cliente Ethereum também está crescendo rapidamente. No fundo, o trabalho de garantir o segurança e descentralização do Ethereum O impacto do algoritmo de consenso de volume 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 beacons 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.
  • O espaço atual 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, dividido pelo tempo de bloqueio de 12 segundos, o limite superior de TPS do 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 bloco No espaço, a segurança é garantida por meio de provas de fraude e provas de validade, e é por isso que a camada DA determina o limite superior de segurança, que também é o conteúdo principal da atualização de Cancun.
  • 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. No curto prazo, o Ethereum só pode construir uma estrutura multicamada com Rollup como núcleo, então Cancun atualiza para resolver TPS, gás As taxas e a experiência do desenvolvedor são essenciais para o roteiro da Ethereum.

**Como o roteiro do Ethereum é planejado? **

As últimas atualizações importantes e seus objetivos

  • 2020ano12mês1* Beacon chain é lançado oficialmente, abrindo caminho para atualização de POS*
  • 2021**8meses5** Atualização de Londres, EIP1559 muda o modelo econômico da Ethereum;
  • 2022ano9mês15* Atualização de Paris (O Merge), completou a troca de POW POS;*
  • 2023ano4mês12* Atualizado em Xangai, resolveu o problema de retirada de penhor;*
  • 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 é focar no roteiro Ethereum O Surto .
  • Alvo: Alcance mais de 100.000 TPS no Rollup.
  • Existem 2 esquemas, 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 sharding popular.Um entendimento simples de sharding é 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. Atualmente, é difícil concluir uma sincronização de dados de nó de rede em grande escala. não pode resolver a situação do MEV, mas também pode exigir um grande número de remendos para compensar vários problemas que possam surgir, que não podem ser realizados a curto prazo.
  • Danksharding é um novo design de sharding proposto para Ethereum, Sua ideia central é Produção de bloco centralizada + Verificação descentralizada + **Resistência à censura,**Isso também está relacionado à disponibilidade de dados mencionada abaixo Amostragem (DAS), Bloqueie a Separação entre Produtores e Empacotadores (PBS) e Lista de Resistência à Censura (Crlist). O maior significado da ideia central de Danksharding está em transformar o Ethereum L1 em um acordo unificado (liquidação) e disponibilidade de dados (disponibilidade de dados) Disponibilidade）层。

*O esquema de sharding é dividido em 2 etapas, atualmente é dividido em Proto- sharding e Full-Rollup. ***

  • Portanto- danksharding**:**
  • introduzir: Ajude na redução da taxa de L2 e aumente a taxa de transferência introduzindo blobs , ao mesmo tempo como uma solução de pré-sharding para preparar o caminho para o sharding completo. Espera-se que após o proto-danksharding, a implementação do danksharing leve de 2 a 5 anos.
  • 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 esses pacotes de dados ao Ethereum pode permitir que todos os dados de rollup sejam armazenados em blob, o que alivia a carga na corrente principal.A pressão de armazenamento também pode reduzir o custo de rollup.
  • Rollup completo
  • Introdução: Rollup é totalmente expandido, com foco na utilização da disponibilidade de dados.
  • contente:
  • Projeto P2P de DAS: alguns trabalhos e pesquisas envolvendo problemas de conexão de rede de sharding 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;
  • Eficiente DA self-healing: capaz de reconstruir eficientemente todos os dados nas piores condições de rede (por exemplo, ataque de validador malicioso ou tempo de inatividade de longo prazo de nós de bloco grande).

Reunião de Desenvolvedores do Núcleo Ethereum

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 no atualize ou não e, após o teste final, revise-o novamente e decida se deseja incluí-lo na atualização real com base na discussão.
  • As conferências são divididas em 2 categorias, que são a reunião da camada de consenso e a reunião da camada executiva, que são realizadas alternadamente a cada duas semanas:
  • ** Reunião da camada de consenso (Todos Core Developers Consensus - ACDC), com foco na camada de consenso Ethereum (proof of stake, beacon chain, etc.);**
  • Reunião de nível executivo ( Todos Solução Core Developers - ACDE**), que foca na camada de execução do Ethereum (EVM, **Gás schedule, etc.).
  • Existem 3 tipos de mantenedores do núcleo Ethereum, principalmente organizações oficiais ou fóruns voluntários discutindo 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;
  • Ethereum Mágicos: Um "fórum" que deseja discussões sobre EIP e outros tópicos técnicos.

Cronograma das reuniões relacionadas ao escalonamento de Cancún

*De acordo com o conteúdo da discussão, esta atualização de Cancún pode ser dividida em 5 etapas. ***

Fase 1 - Apresentando temas de atualização

Apresentar novas tarefasproto-danksharding***,EOF e "selfdestruct" * Opcode, discussão superficial do conteúdo da atualização de Shanghai*

  • 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 são preliminares Na minha opinião, a atualização de Xangai pode ser dividida em várias pequenas atualizações, como permitir retiradas de ETH prometidas primeiro e, em seguida, atualizar EIP 4844, mas outro grupo de desenvolvedores acha que faz mais sentido implementar uma atualização maior em uma única etapa.

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

No final de 2022**, a conferência Ethereum gira principalmente em torno de ***EOF e EIP 4844 Discussão, continuando a promover EIP 4844 A cerimônia de configuração pré-credível necessária para a cerimônia ***—KZG, os desenvolvedores estarão em *******23 **** Ano **** 1 **** mês confirmado oficialmente qual atualização **** 4844 **** aparecerá em ***

  • 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 2 de dezembro de 22, Trent, chefe do ecossistema Ethereum Van Epps atualizou o EIP 4844 Progresso na implementação da cerimônia de configuração confiável necessária para gerar um Código de segurança usado em 4844. furgão Epps espera que a cerimônia seja uma das maiores de todos os tempos no espaço criptográfico, coletando de 8.000 a 10.000 contribuições, e o período de contribuição pública para a 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. A possibilidade de entrar em Cancun é muito pequena, em relação ao código de autodestruição, existem desenvolvedores que defendem o avanço do EIP na época 4758, mas desabilitar este opcode diretamente irá quebrar alguns aplicativos, e o desenvolvedor acredita que este EIP deve ser pesado novamente por um tempo antes de criar um caso extremo para proteger este tipo de contrato;
  • Na reunião de desenvolvedores do núcleo em 9 de dezembro de 22, foi promovida a implementação da cerimônia KZG sobre a atualização de Cancun e o atual EIP 4844 A cerimônia de configuração confiável necessária está pronta;
  • Na reunião da camada de consenso em 16 e 22 de dezembro, sobre EIP 4844, 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 a disponibilidade de dados além de um certo ponto após a remoção de dados e outra quando um bloco Novos códigos de erro serão introduzidos para alertar nós quando faltam informações sobre blobs em
  • Durante a reunião do núcleo de desenvolvimento em 5 de janeiro de 23, os desenvolvedores chegaram a um consenso para remover as modificações de código relacionadas à implementação do EOF da atualização de Xangai, Beiko neste momento sugeriu decidir após duas semanas se o EOF deveria ser incluído em Cancun está sendo atualizado;

Fase III - Discussão preliminar do escopo da proposta

No final de 231EOF** mudou-se para Cancun para promoção depois de ser transferido da promoção de Xangai, desde então 2 meses principalmente giram em torno, exceto para EOF** e EIP Outras propostas além de 4844* foram discutidas e, ao mesmo tempo, ***EOF foi proposto para sair de Cancún. Este período de tempo foi gasto principalmente em delinear o escopo das propostas para a modernização de Cancún. ***

  • Na reunião de desenvolvedores do núcleo 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, a proposta preliminar para a atualização de Cancun foi: EIP 4788 (raiz do estado da cadeia de sinalizadores públicos), EIP 2537 (Execute com eficiência operações como verificação de assinatura BLS e verificação SNARKs), EIP-5920 (apresenta o novo opcode PAY) e EIP Uma implementação combinada de 6189 (para tornar SELFDESTRUCT compatível com árvores Verkle) e EIP-6190 (alterar a função SELFDESTRUCT para causar apenas um número limitado de mudanças de estado);
  • Na reunião de desenvolvedores principais em 16 e 23 de março, exceto para EOF e EIP 4844, foram consideradas as seguintes propostas para inclusão em Cancun: formato SSZ, exclusão SELFDESTRUCT, EIP 2537、EVMMAX、EIP
  1. Instruções ilimitadas de SWAP e DUP, introduzindo códigos PAY e raízes de beacon state no EVM;
  • Na reunião de desenvolvedores do núcleo em 30 de março de 23, a proposta EIP-6780 sobre desabilitar o SELFDESTRUCT foi apresentada pela primeira vez, que também é a proposta para desabilitar o SELFDESTRUCT que Cancun finalmente decidiu usar. Mas em relação à implementação do EOF, da Erigon (EL) Um desenvolvedor da equipe do cliente disse EOF 'Mudança demais' para competir com a proposta de melhoria do Ethereum EIP na próxima atualização de Cancún 4844, houve uma proposta para implementar EOF no hard fork logo após a atualização de Cancun;

Quarta etapa - determinar a direção clara da atualização da proposta e excluir propostas irrelevantes

Em 234mês, há uma direção clara para as propostas que devem ser cobertas pela atualização de Cancun, e os principais nós estão em 4 ********************************************** ************************************************** *********** EIP, e tim também tiveram uma discussão mais aprofundada sobre as propostas alternativas, em 4mês Na reunião de 27,EIP 6780、EIP 6475 eEIP 1153** está determinado a ser incluído em Cancun, e ao mesmo tempo *EOF e EVMMAX (com * ***EOF **relacionado à implementação EIP subconjunto) foi removido da atualização de Cancun, a atualização de EOF ajuda principalmente EVM executa o controle de versão e pode executar vários conjuntos de regras de contrato ao mesmo tempo, o que ajudará na expansão subsequente do Ethereum, mas considerando a viabilidade de toda a atualização, ** * EOFO upgrade pode ser levado adiante com o upgrade diário

  • 23****4mês12****, a atualização do Ethereum Shanghai foi concluída;
  • Durante a reunião de desenvolvimento central em 23.04.23, os desenvolvedores discutiram o EIP 4844 (para expor dados sobre a raiz do estado CL no EL), há pelo menos nove outros EIPs sendo considerados para a atualização, a saber EIP 4844**, AUTODESTRUIÇÃO REMOVER (EIP-6780, EIP 4758、EIP 6046、EIP 6190）、EIP 5920、EIP 1153、EIP 2537、EIP 4788、EVMMAX EIPs（EIP 6601 e EIP 6690), SS alterações（EIP 6475、EIP 6493、EIP 6465、EIP 6404 e EIP 6466 ）、EIP 5656 e****EIP 6193**;
  • Na reunião de desenvolvedores do núcleo em 27 de abril, 23, vários progressos e compensações foram focados. Primeiro, o EIP4844 continua a ser identificado para inclusão na atualização Cancun, com a adição dos seguintes EIPs: EIP 6780 (altera a funcionalidade do opcode SELFDESTRUCT), EIP 6475 (um novo tipo de serialização simples (SSZ) para representar valores opcionais), EIP 1153 (adicione um novo opcode para operar o status); em segundo lugar, o EIP que está sendo considerado, mas não oficialmente incluído na atualização, é o EIP 6913 (introdução da instrução SETCODE), EIP 6493 (Definir um esquema de assinatura para transações codificadas com SSZ), EIP 4788 (Expor a raiz do bloco da cadeia de beacon no cabeçalho do bloco EL), EIP 2537 (adiciona a curva BLS12-381 como pré-compilação) e EIP 5656 (apresenta novas instruções EVM para copiar regiões de memória); finalmente, EOF ** e ** EVMMAX** (** EOF ** dependente da implementação ** * EIP* subconjunto) foi removido da atualização de Cancún. **EOF A atualização foi transferida de Xangai na Ethereum Developers Conference no início de ****2023****1**** e foi posteriormente atualizada de * *** Do final de 1 até o início de 4 em 23****, aparecerá na atualização de Cancun por padrão, mas em ** 23** **EOF **foi removido novamente na reunião de desenvolvedores em 29, 4. **

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

235meses principalmente agiliza e melhora os detalhes da proposta final,SSZ-> As alterações do RLP significarão que os doisSSZs em Cancun não são mais necessários EIPs**, entãoEIPs 6475 e 6493 serão transferidos de Cancun para atualizações. Ao mesmo tempo, na reunião central do dia 26, Tim A Beiko recomenda que conversas futuras sobre a expansão do alcance de Cancun sejam limitadas aos seguintes cincoEIP:*EIP-5920 * ,5656,7069,4788 e ****2530 * ****. Os desenvolvedores agora determinaram a extensão total da atualização de Cancun. ***

*Reunião Ethereum Core Consensus em 5/5/23, discutindo o último EIP mencionado 4788, ao adicionar o EIP 6987 e EIP Discussão em 6475, essas duas propostas são sobre verificadores e transações SSZ, respectivamente;

  • Na 161ª reunião da camada executiva da Ethereum em 11 de maio de 23, Tim Beiko disse que o escopo da atualização de Cancun ainda pode ser modificado nas próximas semanas, mas sem um conselho explícito dos desenvolvedores, o escopo da atualização de Cancun permanecerá no estado "padrão", e a discussão sobre EIP-4844 mostra que o desenvolvimento O autor concordou em remover SSZ da implementação EL de EIP-4844, **mas ainda não afetou o progresso contínuo de ** 6475 **. **Além disso, os desenvolvedores também discutiram brevemente dois EIPs para consideração em Cancun, ou seja, EIP 6969（EIP
  1. e EIP 5656 (instruções EVM eficientes para copiar regiões de memória);
  • Os desenvolvimentos em 4844 foram brevemente discutidos na reunião de Consenso do Desenvolvedor em 18 de maio de 23, como permitir aplicativos de contrato inteligente em 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 finais de Cancun foram discutidas na 162ª reunião do Ethereum Core em 25 de maio de 2023. hora A Beiko recomenda que conversas futuras sobre a expansão do alcance de Cancun sejam limitadas aos cinco EIPs a seguir: EIP-5920**, 5656, 7069,* ** 4788* ** e ** 2530**. Os desenvolvedores confirmarão nas próximas semanas ** Dencun** (****Deneb
  • toda a gama de Cancún****);**
  • 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 EIP A especificação 4844 aumentou de um máximo de 4 blobs para 6 por bloco. Ao mesmo tempo, os desenvolvedores estão considerando o EIP 4788 incluído na atualização Cancun;
  • Na reunião principal de desenvolvedores em 13 de junho de 2023, os desenvolvedores confirmaram oficialmente o escopo da atualização, incluindo EIP 4844、EIP 1153、EIP 5656、EIP 6780、EIP 4788;
  • 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 para o seguinte Uma rede de teste EIP-4844 Devnet6 testará o aumento do número de blobs e tomará uma decisão final sobre o assunto dentro de duas semanas, enquanto o pesquisador da Ethereum Foundation Michael Neuder propôs remover o limite de 32 ETH para ajudar a reduzir o crescimento do conjunto de validadores ativos;
  • Na reunião de 22 de junho de 2023, a tim propôs mover o endereço pré-compilado de 4844 para 0xA, empacotá-los e mover o BLS para outro endereço, embora o pré-compilado via EIP 2537, mas não será considerado em Cancún;
  • Na reunião de consenso em 29 de junho de 2023, os desenvolvedores continuaram a discutir o número de blobs, limitando o blob de destino Aumentou de 2 para 3, aumentou o limite máximo de blob de 4 para 6 e 4844 rede de teste Devnet

7 está chegando em breve.

essa vida

  • O conteúdo principal é EIP 4844, 即Proto-Danksharding
  • O intervalo EIP final para esta atualização de Cancún é: EIP 4844**、EIP 1153、EIP 5656、EIP 6780、EIP 4788. Enquanto isso, na 111ª reunião Ethereum ACDC em 19 de junho, os desenvolvedores continuaram a discutir EIP 6988、** EIP 7044**、**EIP 7045 para inclusão em Deneb. Os desenvolvedores disseram que planejam fundir os três EIPs mencionados na especificação Deneb nas próximas semanas.

**Análise de ChaveEIP

EIP 4844

  • Introdução:
  • O nome da proposta EIP4844 é Proto-Danksharding, que é o pré-protocolo para a versão completa da expansão de sharding Danksharding.Todo o conjunto de soluções de sharding é realmente baseado em Rollup para expansão on-chain. **O objetivo do programa é expandir a ** 2 camada **Rollup——****Ajudando L2 a reduzir taxas e aumentar o rendimento , ao mesmo tempo em que abre caminho para a fragmentação completa (sharding). **
  • Na teleconferência de 23 de fevereiro, os desenvolvedores Ethereum farão EIP A atualização 4844 é chamada de Deneb, que é o nome de uma estrela de primeira magnitude na constelação de Cygnus, que é o EIP na versão relevante do GitHub no futuro A nomenclatura de 4844 será atualizada para Deneb; na reunião de 1º de junho de 23, haverá 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 se prepararam para atualizar o EIP O endereço pré-compilado de 4844. Atualmente, os principais desenvolvedores adicionaram 9 pré-compilações ao EVM e ativarão o EIP por 4844 e 4788 criam duas pré-compilações nos endereços "0xA" e "0xB", respectivamente. Na reunião de consenso de 29 de junho, o EIP está pronto para ser lançado Rede dedicada de teste de curto prazo do 4844 Devnet #7.
  • EIP-4844** apresenta um novo tipo de transação - Blob Transação。** *Perfil do Blob:
  • Blob, semelhante a um pacote de dados plug-in, apenas 128 no início O espaço de armazenamento da KB, no início da discussão da proposta, o alvo e limite do Blob era de 2/4, e foi ajustado para 3/6 na reunião de desenvolvedores do dia 9 de junho de 23. Ou seja, atualmente cada transação no Ethereum pode carregar até três transações Blob, ou seja, 384 KB, o destino de cada bloco A capacidade do blob é 6, ou seja, 768 KB, que pode transportar até 16 blobs, ou seja, 2 MB;
  • Pode ter um certo impacto na estabilidade da rede, mas a equipe de desenvolvimento do Ethereum ainda decidiu testar primeiro para evitar a necessidade de hard forks subsequentes para expandir o bloco blob.
  • Blob **em ** KZG commit Hash Como um ** Hash, usado para verificação de dados, a função é semelhante a ** Merkle ;
  • O nó sincroniza o Blob na cadeia Após a transação, 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.
  • Função Blob - melhorar o TPS do Ethereum, reduzindo 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, excedendo 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. Isso afetará a descentralização de todo Nó Ethereum, mas a expansão em torno do Rollup é bastante aprimorada;
  • Na verdade, 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** - para abrir o primeiro capítulo da narrativa de Danksharding**
  • **Expansão de alta capacidade: **Atualmente, o EIP-4844 pode inicialmente expandir a capacidade L2. A versão completa do Danksharding pode expandir o volume de dados Blob no EIP-4844 de 1 MB para 2 MB para 16 MB para 32 MB, garantindo descentralização e segurança Enquanto alcançar maior expansão;
  • **Taxas baixas: **Os analistas da Bernstein mostram que 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, o que pode reduzir o custo de rollup em 50% de acordo com as observações atuais;
  • 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 de DA pode ser reduzido para 5% do original;
  • A Topia espera reduzir o custo em 100~1000 vezes, porque o Danksharding da rede principal também precisa levar em consideração a segurança e a compatibilidade com a transmissão de rede P2P da Camada 1.
  • **DA****Solution: Danksharding (uma solução de sharding para a expansão do Ethereum) no momento, se a expansão continuar, a carga do nó pode ser muito grande (****16mb **** acima) e disponibilidade insuficiente de dados (validade de 30 dias). Solução: **
  • Amostragem de disponibilidade de dados (Dados Amostragem de Disponibilidade) - reduz a carga sobre os nós
  • Corte os dados no Blob em fragmentos de dados e deixe o nó mudar 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 são armazenados em todo o ledger do Ethereum, a premissa é que os nós precisam ser suficientes e descentralizados;
  • O DAS usa duas tecnologias: código de eliminação (Erasure Codificação) e Compromisso Polinomial KZG (KZG Compromisso);
  • Proposer-Packager Separation (PBS)——Resolvido o problema da divisão de trabalho dos nós, deixe os nós com configuração de alto desempenho serem responsáveis por baixar todos os dados para distribuição de codificação e deixe os nós com configuração de baixo desempenho serem responsáveis por verificação de verificação no local.
  • Um nó com configuração de alto desempenho pode se tornar um construtor. O construtor só precisa baixar os dados do blob para codificação e criar um bloco (Block) e, em seguida, transmiti-lo para outros nós para verificações pontuais. Para construtores, porque o volume de dados de sincronização e os requisitos de largura de banda são altos, por isso será relativamente centralizado;
  • Um nó com configuração de baixo desempenho pode se tornar um proponente (Proposer), e o proponente só precisa verificar a validade dos dados e criar e transmitir o cabeçalho do bloco (Block Header), mas para o proponente (Proponente), o volume de dados de sincronização e os requisitos de largura de banda são baixos, portanto, será descentralizado.
  • Lista anti-censura (crList) - resolve o problema de que os empacotadores podem deliberadamente ignorar certas transações e classificar e inserir aleatoriamente as 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 Gas limite está 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 o cabeçalho do bloco (Block Cabeçalho) e transmissão;
  • 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 ficando 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 (Committees) confirma o cabeçalho do bloco vencedor;
  • A Construtora 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 será produzido, se o embalador deliberadamente não der o corpo do bloco, será considerado que o bloco não existe).
  • 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, então ele precisa pagar muitos custos de licitação no início para garantir que 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 de 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. Ao mesmo tempo, o número de empacotadores em si é muito pequeno No caso de , alguns mineradores experientes com recursos de MEV terão maior probabilidade de licitar com sucesso, o que afetará mais o efeito da solução MEV real;
  • Tem algum impacto em algumas soluções MEV usando leilões MEV.
  • Significado:
  • EIP 4844 Na verdade, uma versão super simplificada Danksharding**: **Ele fornece a mesma interface de aplicativo que o Danksharding, incluindo um novo opcode chamado Data Hash; e um novo objeto de dados chamado Binary Objetos Grandes, ou seja, Blob;
  • proto-danksharding ** é usado para implementar a ** Danksharding ** especificação "suporte"** (** é o formato da transação e as regras de verificação****) * * Proposta: 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 a perspectiva de longo prazo escolhe proto-danksharding não EIP 4488 ** reduz diretamente a taxa de ** layer2 , porque apenas um pequeno ajuste é necessário ao atualizar para um shard completo no futuro:
  • EIP A principal diferença prática entre 4488 e proto-danksharding é que o EIP-4488 tenta minimizar as mudanças que o Ethereum precisa fazer hoje, enquanto o proto-danksharding faz mais mudanças no Ethereum hoje para atualizar para o Ethereum no futuro. necessário para fragmentação de versão completa;
  • Embora seja uma tarefa muito complexa alcançar a fragmentação completa (com amostragem de disponibilidade de dados, etc.), e ainda haja muito trabalho 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 de execução, os desenvolvedores de rollup e os usuários não precisam fazer nenhum trabalho adicional para fazer a transição para o sharding completo.
  • Para obter a fragmentação completa, é necessário concluir a implementação real de ** PBS, prova de delegação e amostragem de disponibilidade de dados, mas essas modificações serão concentradas no ** CL * * camada, não há necessidade de reajuste dos desenvolvedores **: 4844 atualmente implementa um novo tipo de transação, que é exatamente o mesmo que o formato da transação, a lógica de validação cruzada de consenso e a lógica da camada de execução necessária no shard completo e também derivado para blobs , precificação independente de gás auto-ajustável, a fim de alcançar fragmentação completa no futuro, é necessário concluir a implementação real de PBS, prova de delegação e amostragem de disponibilidade de dados, mas essas modificações são apenas na camada CL e não requer que os desenvolvedores de camada EL ou rollup modifiquem, o que é conveniente para o desenvolvimento por.

seguido deAUTODESTRUIÇÃO remoção***,EIP-6780 foi finalmente determinada como a solução mais adequada, mas o desenvolvedor em 26**** No reunião tim** propôs adicionar outro opcode a esta propostaSETCODE para permitir que as contas programáticas ainda sejam atualizadas***

AUTO-DESTRUIÇÃO remoção EIP-6780**:**X

  • fundo:
  • Em 21 de março, Vitalik propôs que SELFDESTRUCT faz mais mal do que bem à ecologia Ethereum. A principal razão é que é o único que pode mudar um número infinito de objetos de estado em um único bloco, resultando em mudanças nos códigos de contrato, e pode ser usado sem o consentimento da conta. pode modificar o código de operação do saldo da conta, que tem grandes perigos ocultos na segurança do Ethereum;**
  • A única maneira de remover um contrato on-chain é 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 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-se um meio de ataque. **
  • Na reunião de desenvolvedores do núcleo em 13 de abril, 23, quatro propostas sobre SELFDESTRUCT foram apresentadas para participar da discussão, ou seja, 6780, 4758, 6046 e 6190, e o EIP subsequente 6780 foi definido 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.
  • EIP 6780: Desabilita SELFDESTRUCT a menos que eles 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 está a absorção do EIP As vantagens do 4758, que podem dar espaço ao dapp para atualizar.

  • Motivo: A manipulação do código SELFDESTRUCT originalmente exigia grandes alterações no estado da conta, como excluir todos os códigos e armazenamento. Isso representa uma dificuldade para usar as árvores Verkle no futuro: cada conta será armazenada em muitas chaves de conta diferentes que não serão vinculadas explicitamente à conta root.
  • ALTERADO: Este EIP implementa alterações para remover SELFDESTRUCT, exceto nos dois casos a seguir
  • Os aplicativos que são usados apenas para SELFDESTRUCT para sacar fundos ainda funcionarão;
  • SELFDESTRUCT utilizado na mesma transação no contrato não precisa ser alterado.
  • Significado: Aumento da segurança
  • Anteriormente, havia um contrato na rede principal que usava SELFDESTRUCT para restringir quem pode iniciar transações por meio do contrato;
  • Impedir que os usuários continuem depositando fundos e negociando em um cofre após SELFDESTRUCT, então este cofre pode fazer com que alguém roube tokens no cofre durante o uso repetido.

As três propostas abaixo são as propostas sobre SELFDESTRUCT que foram posteriormente deletadas, em 23ano*****4 *** 6780 foi oficialmente selecionado na reunião de desenvolvedores do núcleo em **28, e as outras três propostas foram abandonadas. é que a equipe de desenvolvimento do Ethereum eventualmente deseja excluir completamente o opcode SELFDESTRUCT, e as três propostas a seguir são modificadas principalmente por 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 do código SELFDESTRUCT exigia alterações extensas no estado da conta, como excluir todos os códigos e armazenamento. Isso representa uma dificuldade para usar as árvores Verkle no futuro: cada conta será armazenada em muitas chaves de conta diferentes que não serão vinculadas explicitamente à conta raiz.
  • Mudar:
  • Opcode SELFDESTRUCT renomeado para SENDALL, agora apenas move todos os ETH na conta para o chamador, este esquema não destrói mais código e armazenamento, nem altera números aleatórios;
  • Todos os reembolsos relacionados ao SELFDESTRUCT foram excluídos
  • Significado:
  • Preservada a funcionalidade original em relação ao EIP-6780, pois alguns aplicativos ainda/precisam utilizar o código SELFDESTRUCT.
  • EIP-6046 (OBSOLETO): 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: O mesmo que acima, 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 o aumento de nonce regular seja limitado por 2^64-2 em vez de 2^64-1;
  • SELFDESTRUCT é alterado para:
  • Não exclua nenhuma chave de armazenamento e deixe a conta no lugar;
  • Transfira o saldo da conta para o alvo **, **defina o saldo da conta para 0.
  • Defina a conta nonce para 2^64-1.
  • Sem reembolso desde EIP-3529;
  • A regra relevante SELFDESTRUCT de EIP-2929 permanece inalterada.
  • Significado:
  • Esta proposta tem mais flexibilidade do que outra exclusão direta de SELFDESTRUCT.
  • EIP-6190 (DEPRECATED): Alterado SELFDESTRUCT, compatível com Verkle, para que cause apenas um número limitado de alterações de estado
  • Motivo: Igual ao anterior, com uma árvore 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.
  • ALTERADO: Em vez de destruir o contrato no final de uma transação, acontece o seguinte no 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 de armazenamento do contrato é definido para o contrato usando o opcode CREATE ( keccak256(contractAddress, nonce)) será emitido quando o endereço. 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á transferido integralmente 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 mudanças mínimas;
  • Custo do gás aumentado com EIP-2929 aplicado.

Seguido porEIP 1153***, economizandogás, abrindo caminho para o futuro design de armazenamento***

EIP 1153X

  • 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, esses quadros 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.
  • com reentrada lock como exemplo, ele não pode contar com quadros intermediários para comunicar o estado do bloqueio: comunicação SSTORE por meio de armazenamento SLOAD é 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, TLOAD ( 0xb3 ) e TSTORE ( 0xb4 ), foram adicionados ao EVM.
  • O armazenamento transitório é privado ao contrato que o possui, assim como o armazenamento persistente, apenas a estrutura do contrato proprietário pode acessar seu armazenamento temporário. 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:
  • reentrada trancar;
  • 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(endereço gastador, valor de 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 açõ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**, com gás regras de cobrança mais simples
  • ** Resolver o problema de comunicação entre quadros; **
  • ** Não altere a semântica das operações existentes; **
  • Não há necessidade de limpar o tanque de armazenamento após o uso;
  • ** Projetos de armazenamento futuros (como ** Verkle ** árvores) não precisam considerar reembolsos para armazenamento instantâneo. **

Seguido por 4788, pode reduzir a suposição de confiança no pool de promessas**

EIP 4788**:**X

  • Introdução: Raiz do bloco Beacon no EVM. *Atualização: Na reunião de desenvolvedores em 15 de junho de 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 informações do estado da cadeia interna do EVM, para desenvolvimento do DApp Confiança do autor minimiza o acesso.
  • ALTERADO: confirme 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 expor o estado da camada de contrato (CL) Os dados raiz na camada de execução (EL) podem tornar a comunicação entre diferentes protocolos e aplicativos na rede Ethereum mais eficiente e segura**. **Permite designs mais confiáveis para pools de estaqueamento, pontes e protocolos de reestaqueamento.

O último é5656***, que fornece um novo opcode de cópia de memória eficiente, mas está atualmente em um estado de inclusão temporária na atualização devido à sua largura de banda de teste** *

EIP 5656X

  • Introdução: MCOPY
  • Instrução de cópia de memória. Atualização: 09.06.23, a equipe de desenvolvimento afirmou que inicialmente estava dividida sobre o MCOPY porque, embora resolvesse o problema de segurança, eles ainda estavam preocupados em adicioná-lo à largura de banda de implementação+teste necessária para a atualização, mas finalmente concordaram em incluir o EIP , mas será considerado para remoção se o desenvolvedor encontrar problemas de capacidade no teste ou no lado do cliente. Portanto, MCOPY* está em estado de ser temporariamente incluído na atualização Cancun. **
  • Alterado: Forneceu uma instrução EVM eficiente para copiar regiões de memória.
  • Significado: a cópia de memória é uma operação básica, mas há um custo para implementá-la no EVM.
  • Com a disponibilidade da instrução MCOPY, palavras e frases de código podem ser copiadas com mais precisão, o que aumentará o desempenho da cópia de memória em cerca de 10,5%, o que é muito útil para várias operações de cálculo intensivo;
  • Também será útil para compiladores gerarem bytecodes menores e mais eficientes;
  • Pode economizar uma certa quantidade de custos de gás pré-compilados de identidade, mas não pode realmente promover a implementação desta parte.

Lista de finalistas****EIP

Em 236mês15**, a reunião de consenso do desenvolvedor discutida em *** Qual EIP** centrados em CL estão incluídos em Deneb, onde **** ** EIP 6988******、EIP 7044、******EIP 7045 *** *** é proposto para aderir. ***

EIP 6988**:**X

  • Resumo: Impedir que validadores cortados sejam eleitos como proponentes de blocos.
  • Significado: O aumento das penalidades por nós violados beneficiará a TVP.

EIP 7044**:**X

  • Resumo: Garantir que as saídas validadoras assinadas sejam permanentemente válidas.
  • Significado: pode melhorar a experiência dos participantes até certo ponto.

EIP 7045**:**X

  • Introdução: testamento O intervalo de inclusão de slots se estende de uma janela contínua de uma época a duas épocas.
  • Significado: Aumente a segurança da rede.

Excluir análise de EIP

No dia **** de 29*************** *********************************************** Em ** 160****ACDE reunião de Ethereum, EVMMAX e EOF **** está confirmado para ser removido desta atualização, alterações relacionadas a EOF podem ser introduzidas em atualizações diárias subsequentes

EVMMAX EIPs**:**

  • 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.
  • EIP 6601: Extensões Aritméticas Modulares EVM (EVMMAX)
  • Mudança: é EIP 5843 iterações, com EIP A diferença de 5843 é:
  • 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, EIP-6601 atualizações adicionais nesta base, introduzindo uma seção de configuração, um espaço de memória separado e novos opcodes, para operações aritméticas modulares fornecem uma 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 operações 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 um contrato EVM;
  • Reduz significativamente o custo de verificação ZKP em funções hash algébricas (por exemplo, MiMC/Poseidon) e EVM.
  • EIP 6690:
  • 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 independente. Ele fornece uma abordagem mais simplificada removendo a dependência do EOF.
  • Significado: Ele mantém a funcionalidade principal do EIP-6601, que pode executar 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, enquanto ainda fornece os benefícios associados ao benefício EIP-6601.

EOF mudanças**:**

  • Introdução: EOF é uma atualização para EVM, que introduz novos padrões de contrato e alguns novos opcodes. O tradicional EVM bytecode (bytecode) é uma sequência de instruções não estruturada (unstructured sequência de instruções) bytecode. 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.
  • EIP 663:
  • Resumo: Instruções irrestritas 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
  • EIP 3540:
  • Introdução:
  • Anteriormente, 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 novos recursos ou recursos antigos obsoletos.
  • Este EIP apresenta um contêiner que pode ser expandido e controlado por versão para EVM, e declara o formato do contrato EOF. Com base nisso, o código pode ser verificado ao implantar o contrato EOF, ou seja, criação A validação de tempo significa que os contratos que não estão em conformidade com o formato EOF podem ser impedidos de serem implantados. 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 depreciaçã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 o trabalho de análise de dados on-chain ferramentas.
  • EIP 3670:
  • Introdução: Com base no EIP-3540, o objetivo é garantir que o código do contrato EOF esteja em conformidade com o formato e seja válido, e a implantação de contratos que não estejam em conformidade com o formato será evitada sem afetar o Legado bytecode。
  • 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 que ele seja implantado. 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.
  • EIP 4200:
  • Introdução:
  • Introduziu os primeiros opcodes específicos de EOF: 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 ao implantar e executar o JUMP, uma vez que eliminam a necessidade dos opcodes JUMP e JUMPI existentes para executar o jumpdest O tempo de execução necessário para análise. Este EIP é para dinâmica A adição de salto.
  • Em comparação com as operações JUMP tradicionais, 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 (da dinâmica saltos -> saltos estáticos), porque muitas vezes saltos estáticos saltos são suficientes.
  • Significado: otimizar a rede e reduzir custos.
  • EIP 4750:
  • Leve a função de 4200 um passo adiante: introduzindo CALLF Os dois novos opcodes de e RETF implementam alternativas para situações que não podem ser substituídas por RJUMP, RJUMPI e RJUMPV, desta forma o JUMPDEST não é mais necessário no contrato EOF, portanto a dinâmica é proibida. pular.
  • Significado: otimize o código dividindo o código em várias partes.
  • EIP 5450:
  • 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 assim por diante.
  • Conteúdo: Adicionada outra verificação de validade para contratos EOF, desta vez na pilha. Este EIP evita situações em que a implantação do contrato EOF pode causar subfluxo ou estouro de pilha (pilha transbordamento/transbordamento). 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.

5mês26***************** ************************************************** ************************** 4844Alteração do tipo de transação relacionada deSSZ****** paraRLPsignifica que não há necessidade de duas a**** de Cancún SSZ EIPs****, entãoEIPs 6475 e 6493** foram transferidos de Cancun para atualização***

EIP 6475X

  • Introdução: EIP Proposta de acompanhamento para 4844. 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 Executive Layer Core Developers Meeting, houve uma discussão sobre o EIP A discussão sobre o formato de serialização SSZ para 4844 mostrou que inicialmente os desenvolvedores favoreceram a introdução de uma iteração inicial do formato SSZ para EL por meio de transações blob e, eventualmente, os desenvolvedores planejaram atualizar todos os tipos de transação de RLP para SSZ, mas devido ao seu caminho pouco claro e certamente não implementado na atualização de Cancun, os desenvolvedores estão avaliando a remoção do SSZ do EIP-4844. Após muita discussão, os desenvolvedores concordaram em remover SSZ da implementação EL de EIP-4844,** mas não há remoção de EIP6475****. **SSZ-> As mudanças no RLP significarão que os dois SSZs em Cancun não são mais necessários EIPs: ** Portanto EIPs 6475 e 6493 serão transferidos de Cancun para atualizações. **

EIP 6493X

  • 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: SSZ mudanças
  • Introdução: Simples SerialiZe, é o método de serialização usado na cadeia beacon. *SS As mudanças também incluem três outras propostas de apoio, desta vez apenas a 6465 foi introduzida.
  • EIP 6465: raiz de retirada SSZ, define Merkle-Patricia existente Migração de compromissos Trie (MPT) para retiradas de Serialização Simples (SSZ);
  • EIP 6404 / EIP 6466:
  • Ambos definem uma Merkle-Patricia existente As promessas Trie (MPT) estão em processo de migração para Simple Serialization (SSZ).
  • EIP-6404 — Raiz da transação SSZ
  • EIP-6466 — base de recebimento SSZ

Tim Beiko** sugeriu desenvolvimentos futuros em torno da expansão de Cancun em uma reunião de desenvolvedores principais em 5mês26*** As conversas são limitado aos cinco seguintesEIP:EIP 5920,5656,7069,4788 e 2537, neste âmbito serão geradas propostas de seguimento. AcompanhamentoEIP 5656*** eEIP 4788 foi confirmado como uma proposta de atualização oficial,5920,7069 e2537 removido ondeEIP 5920 é devido à preocupação do desenvolvedor com os possíveis efeitos colaterais da maneira de transferir ETH**, bem como o raciocínio inacabado, teste e trabalho de segurança, portanto, a partir da atualização remover. ***

EIP 5920**:**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, 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;
  • Finalmente, 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 outras coisas não intencionalmente.
  • Mudar:
  • Um novo opcode é introduzido: ( PAY) PAY_OPCODE onde:
  • Retire dois valores da pilha: addrthen val.
  • 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: salvar gás**. ** *Atualização: 09.06.23 PAY foi removido da atualização devido a preocupações sobre possíveis efeitos colaterais da forma como o ETH é transferido e o raciocínio, teste e trabalho de segurança necessários para aprovar a proposta.

EIP 7069X

  • Introdução: Instrução CALL modificada
  • ALTERADO: Introduzidas três novas instruções de chamada, CALL2, DELEGATECALL2 e STATICCALL2, que têm o efeito de simplificar a semântica. Visa retirar a observabilidade do gás da nova diretiva e abrir a porta a uma nova classe de contratos que não são afetados pela reprecificação.
  • fundo:
  • Regra 63/64: 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, era necessário um cálculo um pouco mais preciso do gás disponível do chamador. 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.
  • **Atualmente introduzindo **63/64 Regras:
  • Inspeção de profundidade de chamada excluída;
  • Certifique-se de reservar pelo menos 5000 gases antes de executar o comportamento chamado;
  • Certifique-se de que haja pelo menos 2300 gases disponíveis para o comportamento chamado.
  • Regras de subsídio: como o conhecido subsídio de 2300, quando um contrato chama outro contrato, o contrato chamado receberá 2300 o gás é usado para executar operações muito limitadas (o suficiente para fazer um pequeno cálculo e gerar um log, mas não o suficiente para preencher um slot de armazenamento) e, como define uma quantidade fixa de gás, não há como as pessoas determinarem isso como desde que o preço do gás possa ser ajustado Que tipo de cálculos o gás pode suportar?
  • Significado: ** Abre caminho para a introdução de ** EOF ** no futuro, e é mais conveniente para a operação de grandes contratos. **
  • Remoção da opcionalidade do gás: novas diretivas não permitem a especificação do gás limite, mas contam com a "regra 63/64" (principalmente referente à reprecificação do gás 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 limitar o gás. Esta importante melhoria simplifica o processo em torno da regra "Abono", independentemente de o valor ser enviado ou não, o chamador não precisa realizar cálculos relacionados ao gás;
  • Depois de introduzir a nova proposta, os usuários sempre podem superar Out enviando mais gás na transação (claro, sujeito ao limite de gás do bloco) de erro de gás.
  • Anteriormente, ao aumentar os custos de armazenamento (por exemplo, EIP-1884 aumentava o gás para determinados opcodes), alguns contratos que enviavam apenas uma quantidade limitada de gás para suas chamadas eram quebrados pelo novo mecanismo de custeio. 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 valor enviado.
  • Pavimente 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;
  • Códigos de retorno de status mais convenientes: Foram introduzidas funções de conveniência que retornam códigos de status mais detalhados: sucesso (0), restauração (1), falha (2) e pode ser estendido no futuro.

EIP 2537**:**X

  • Introdução: Pré-compilação da manipulação da curva BLS12-381.
  • Alterado: Adicionadas operações na curva BLS12-381 como pré-compiladas para o conjunto necessário para executar com eficiência a verificação de assinatura BLS e realizar operações de verificação de SNARKs, etc.
  • Significado: Ethereum pode criar provas criptográficas mais seguras e permitir uma melhor interoperabilidade com a cadeia de beacons**. **

PR 3175 *** Mencionado, mas não pré-selecionado, sem maiores discussões ***

PR 3175**:**X

  • Breve: Esta proposta impediria validadores penalizados de propor 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 em 4 de maio, PR 3175 está em processo de formatação como EIP e será alterado para EIP-6987, que é por questões de segurança para evitar que validadores cortados sejam eleitos como proponentes de blocos.

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 da capacidade, 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 opside 50% do custo de rollup; 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; Topia espera reduzir o custo por 100 ~ 1000 vezes.

2.** Atualização de Cancún No futuro 2~5 anos de Danksharding**, é o período dourado de desenvolvimento dos projetos de camada DA****

  • Camada O limite superior de segurança de 2 depende da camada DA adotada. O proto-Danksharding beneficiará o protocolo de armazenamento, o protocolo modular e a rede 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 altamente seguro em tempo real e deixar espaço para outros protocolos descentralizados para armazenamento de longo prazo (O propósito do protocolo de consenso Ethereum não é garantir armazenamento de todos os dados históricos para sempre. Ao contrário, o propósito é fornecer um quadro de avisos em tempo real altamente seguro e deixar espaço para outros protocolos descentralizados para fazer armazenamento de longo prazo. ）；
  • **Em segundo lugar, **Danksharding **reduz o custo de **DA **, mas o tempo real de pouso e os problemas de disponibilidade de dados também precisam ser resolvidos. **
  • Redução de custos DA**: **Antes desta atualização, era necessário chamar calldata para publicar dados de rollup para a cadeia principal Ethereum, e a taxa de gás para chamar este código era muito cara, que é camada O maior pagamento de 2, o EIP 4844 introduz o blob de dados como um espaço de dados adicional exclusivo para rollups, o que reduzirá bastante os custos de armazenamento, reduzindo assim os custos de DA.
  • O tempo real de pouso é longo, e o ** TPS ** aprimorado e o ** gás ** reduzido ainda são limitados, por isso é bom para ** DA * * projetos de camada em desenvolvimento contínuo subsequente:
  • disponível sobre danksharding em polynya No artigo de fragmentação de dados de segurança, é indicado que levará de 2 a 5 anos para ser implementado;
  • ** Mesmo se pousar, pode aumentar ** TPS ** e reduzir ** gás ** as magnitudes ainda são limitadas:**
  • EIP 4844 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. 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, muito tempo para pousar + Mudanças reais limitadas serão beneficiadas DA Projetos de camada, alguns como Celestia, ** Eigenda** ** ** Projeto DA ** ainda pode passar de custo mais barato e mais rápido ** TPS ** para concorrer com ** Danksharding ** no futuro*, ETHstorage Topia** e outros novos projetos DA também podem preencher a lacuna do mercado antes do lançamento. **
  • Questões técnicas, como problemas de armazenamento e disponibilidade de dados, também precisam ser abordadas:
  • Existem dois custos principais do 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 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, a rede de portal Ethereum (atualmente em desenvolvimento) ou protocolos de terceiros, como exploradores de blocos, dados históricos em BitTorrent ou armazenamento espontâneo por usuários individuais.
  • Portanto, o Proto-Danksharding beneficiará o protocolo de armazenamento, o protocolo modular e a rede de expansão de armazenamento L1:
  • A demanda por chamadas de dados históricos levará a um novo canal de desenvolvimento para protocolos de armazenamento descentralizado ou protocolos de indexação de terceiros;
  • 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;
  • Boa rede de expansão de armazenamento L1, como Eth armazenamento, que pode fornecer uma solução de segundo nível para armazenamento programável a um custo de armazenamento menor.

**3.**Benefícios do upgrade para Cancún L2diversidade, L3, RAAS e Disponibilidade de dados e outras faixas

  • Análise de faixa L2:
  • Head Layer2, como Arbitrum Órbita、OP Pilha, Polígono 2.0, Fractal 5 projetos, incluindo Scaling (em StarkWare) e HyperChain (em zkSync), serão beneficiados. A redução da taxa de armazenamento trazida pelo blob tornará a série anterior de camadas restritas 2 Os problemas de custo de desenvolvimento e escalabilidade foram bastante aprimorados e a taxa de transferência de dados foi bastante aprimorada. Depois de resolver o problema de custo, a camada principal 2 Haverá uma oportunidade de continuar a implantar uma ecologia L3 simultânea multicadeia altamente personalizada para funções específicas;
  • A lacuna nos custos operacionais entre o Layer2 de segundo nível e o Layer2 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 por Wasm, que podem apresentar mais desenvolvedores web2.
  • Análise da faixa Raas:
  • 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é mesmo há dúvidas sobre a própria pista RAAS. ** Diante da concorrência de ** 5 ** cabeças** layer2 **, o surgimento de vários novos ** DA **, novos projetos podem constituir uma Temos que colocar um ponto de interrogação na pista. **
  • Primeiro, a camada de cabeçalho 2 A vantagem da implantação da cadeia de aplicativos está na integridade da estrutura de rede e na segurança da ecologia entre as cadeias, e a vantagem do RAAS está em sua customizaçã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 de RAAS é duvidosa.
  • Departamento OP: Embora OP atualização do alicerce da pilha+ O lançamento do 4844 trouxe um pequeno aumento de custo e eficiência, mas o aumento não é muito atraente;
  • 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. Mas o ZK atualmente no mercado A maioria dos RAAS ainda usa projetos líderes (como o ZkSync) para bifurcar a cadeia, e as barreiras ainda não são fortes.
  • SO, curto prazo OP RAAS** **Ainda há espaço para desenvolvimento antes da chegada de ** layer3 **. A longo prazo, ** ZK RAAS ** e ** layer3 ** podem ser a tendência futura. ** *ZK O RAAS 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 de 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.**O upgrade de Cancun melhora a experiência do desenvolvedor e do usuário

  • Cancun atualiza a segunda proposta importante SELFDESTRUCT a remoção irá melhorar ainda mais a segurança do Ethereum. Ao mesmo tempo, para os possíveis problemas de atualização de conta programática após a exclusão, planejamos introduzir um novo código de operação SETCODE para melhorar esta situação;
  • Terceira Proposta EIP para Cancun Upgrade 1153 adiciona um código de operação de armazenamento transiente, que pode primeiro 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, que não precisará considerar o problema de reembolso de transientes armazenar;
  • Quarta proposta EIP para atualização de Cancun 5656 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%;
  • Quinta proposta para atualização de Cancun é EIP 4788 pode tornar a comunicação entre diferentes protocolos e aplicativos na rede Ethereum mais eficiente e segura, e também permitir projetos mais confiáveis para pools de promessas, protocolos de ponte e restaking;
  • Cancún atualiza as últimas (15 e 23 de junho) propostas de atualizações EIP centradas em CL: EIP 6988, EIP 7044、EIP 7045, que melhora a segurança e a usabilidade do Ethereum em detalhes, como melhorar a experiência dos contribuintes e melhorar a segurança da rede.
  • Entre as propostas excluídas, SSZ-> A transformação do RLP torna as duas SSZs EIP（EIP 6475 e EIP
  1. foi removido da atualização de Cancun; propostas relacionadas a EOF foram removidas da atualização de Cancun após serem removidas da atualização de Xangai, e atualmente considera-se que pode ser implementada diretamente na atualização diária posterior; EVMMAX é devido a alguns EIPs relacionado ao subconjunto de implementação de EOF, por isso também foi transferido de Cancun para atualização junto com EOF; considerando os possíveis efeitos colaterais que podem existir na forma de transferência de ETH, bem como o raciocínio, teste e trabalho de segurança necessários para aprovar a proposta , EIP 5920 removido da atualização.

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

Pouco efeito em zkml

  • ZKML é prova de conhecimento zero (Zero Conhecimento) e aprendizado de máquina (Machine Learning); a combinação de **blockchain e ML modelo 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 a máquina para treinamento, a confidencialidade das informações pessoais é um requisito importante; ou os parâmetros do modelo são a principal competitividade do projeto e a criptografia também é necessária para manter as barreiras da concorrência. Quando existem problemas de confiança como esses, os modelos de ML sã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 de ZKML ** têm pouco a ver com ** DA **: **Precisa de algo como Espaço A principal tecnologia dessa estrutura de armazenamento separada é o novo protocolo de segurança "à prova de SQL". Simplificando, é um data warehouse próximo ao blockchain, permitindo que os desenvolvedores se conectem on-chain e off-chain em um formato SQL simples. dados e carregue os resultados diretamente no contrato inteligente;
  • ZK-SNARKs **é a forma principal de ** ZK ** em ** ZKML ** e pode se adaptar ao cálculo on-chain de ** **ML ** ** Com o desenvolvimento da criptografia, especialmente o recursivo **SNARK a prova será benéfica ZKML Pousando 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. Este tipo de prova precisa apenas uma vez A natureza da interação entre o verificador e o verificador torna os ZK-SNARKs eficientes e práticos em aplicações práticas e é mais adequado para os requisitos de poder de computação do ML na cadeia.
  • 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 ao baixo desempenho causado por limitações de algoritmo (não pode ser calculado em paralelo). Provas de ZK de modelo grande requerem maior poder de computação, que não pode ser suportado na cadeia. O atual popular Os ZK-SNARKs suportam apenas a prova de conhecimento zero de ML com pequena escala 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 de 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 até certo ponto ZK rollup Comprovante de Taxa:
  • A taxa de transação atual do zkSync depende de 3 aspectos:
  • O custo dos recursos fixos consumidos pelo verificador para gerar as provas SNARK e verificá-las é 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. Embora não seja muito comparado ao custo de geração de provas, considerando que o ZK ainda está em seus estágios iniciais, a tendência de desenvolvimento futuro da série ZK não deve ser subestimada.
  • Em segundo lugar, a abstração da conta transforma as transações ** tx ** tradicionais em ** useroperation e, em seguida, ** useroperations use ECDSA * * Embalado em blocos, o armazenamento na cadeia ocupa mais do que antes, então os requisitos de armazenamento são maiores;
  • **A seguir, abstração da conta e ** ZK rollup podem se complementar:
  • O problema atual de captação de contas é o Gás A taxa é cara, porque há muitas etapas e contratos inteligentes envolvidos, portanto, há muitos dados, o que leva ao Gas A taxa é cara e ZK A vantagem do Rollup é que ele pode reduzir os dados;
  • Abstração de conta dificulta a garantia de segurança: Como AA envolve vários contratos, a segurança é um problema, mas após a formação gradual de L2 no futuro, a camada de consenso não será alterada, os contratos inteligentes terão mais usos e a segurança de captação de contas também pode ser garantida, com a ajuda de ZK A verificação confiável do rollup melhorará ainda mais a segurança.
  • **Finalmente, considerando o surgimento da tecnologia ** AI , ela pode ajudar a aumentar a segurança dos contratos on-chain e otimizar transações on-chain ou etapas de atividade:
  • AI e segurança: a tecnologia AI pode ser usada para aumentar 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;
  • IA e otimização de 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 modelo.
  • **Portanto, o upgrade de Cancun será desde a expansão do espaço de armazenamento, até a integração com o ** ZK A complementaridade do rollup ** e a combinação com a tecnologia ** AI ** beneficiarão gradualmente o desenvolvimento futuro da abstração de contas. **

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

  • **Atualmente, **Layer2 ** não tem desempenho (em termos de latência e throughput) semelhante a ** Solana **, nem como ** Próximo ** Tal desempenho de sharding e nenhum desempenho de execução paralela como ** Sui ** e ** Aptos **, a atualização de Cancun melhorou a posição de liderança do Ethereum como líder; **
  • Após a atualização de Cancun, vários tempos de desenvolvimento importantes são estimados Full-Danksharding** (2~5 anos), *MEV * e ** PBS pouso (1~3 anos), abstração de conta (1~2 anos), ***ZK * * *Tudo (3~6 anos), EOF e experiência de desenvolvedor (quantas vezes você já viu a extensão?). **

O Flagelo

  • Objetivo: Foco 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, blobs podem ser otimizados, e serviços de pré-confirmação ou proteções de preempção podem ser introduzidos.
  • PBS é a separação de produtores 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 os problemas do MEV, que é a ideia da externalização do MEV.
  • O grau de conclusão do PBS ainda é muito baixo, e os mais maduros estão Colaboração com soluções MEV externas - mevboost por flashbots.
  • Versão avançada de "Consagrada Proposer-Builder Separation (ePBS)" tem menor grau de conclusão e ciclo mais longo, e estima-se que não seja implementado no curto prazo. Além disso, existem versões progressivas de PEPC e Optimistic Retransmissão, que aumenta a flexibilidade e adaptabilidade da estrutura PBS

O Beira

  • Objetivo: Usar a árvore Verkel para substituir Merkle, introduzir uma solução de minimização de confiança, permitir que nós leves obtenham a mesma segurança que nós completos e tornar a verificação de bloco o mais simples e leve 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 prova, incluindo clientes leves baseados em SNARK; SNARKs para mudanças de estado de consenso; Consagrado Rollups。
  • 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 caminho em si como prova Parte do Verkle as provas são 3 vezes mais eficientes que as provas de Merkle.
  • Consagrado Rollup 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.

O purga

  • O Purge 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 servir no nível P2P.
  • Estado inativo. Quando se trata de crescimento do estado, existem dois objetivos principais: apatridia fraca, que se refere ao objetivo de apenas usar o estado para construir um bloco, mas não verificá-lo; o estado sendo acessado. A hibernação de estado deve reduzir o estado que um nó precisa armazenar em um total de 20 a 50 GB。
  • No quinto estágio Purge, EIP 4444 é explicitamente escrito no Roadmap, o EIP-4444 exige que o cliente limpe os dados com mais de 1 ano e ainda há algum trabalho de otimização do EVM neste estágio, como simplificar o mecanismo de pré-compilação do GAS e do EVM, etc.;

O Fazer alarde

  • Na sexta etapa final Splurge, EIP Também foi mencionado o 4337. 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 gasolina, carteiras de recuperação social, etc.;

Materiais de referência:

  • Atualização da reunião de desenvolvimento do núcleo Ethereum:
  • Ethereum Todos os principais desenvolvedores ligam para o número 148 Escrever
  • Ethereum Todos os principais desenvolvedores ligam para a redação nº 149
  • Ethereum Chamada de camada de consenso nº 99 Escrever
  • Ethereum Todos os principais desenvolvedores ligam para o número 150 Escrever
  • Ethereum Todos os desenvolvedores principais ligam para o número 151 Escrever
  • Ethereum Chamada de camada de consenso nº 100 Escrever
  • Ethereum Todos os principais desenvolvedores ution Call #152 Escrever
  • Ethereum Todos os principais desenvolvedores ution Call #153 Escrever
  • Ethereum Discussão no fórum Original Magicians:
  • Ethereum Todos os principais desenvolvedores ution Call #156 Escrever
  • Ethereum Todos os principais desenvolvedores ution Call #157 Escrever
  • Ethereum Todos os principais desenvolvedores ution Call #158 Escrever
  • Ethereum Todos os principais desenvolvedores ution Call #159 Escrever
  • Ethereum Todos os principais desenvolvedores ution Call #160 Escrever
  • Ethereum Chamada de consenso para todos os principais desenvolvedores nº 108 Escrever
  • Ethereum Todos os principais desenvolvedores ution Call #161 Escrever
  • Ethereum Chamada de consenso para todos os principais desenvolvedores nº 109 Escrever
  • Ethereum Todos os principais desenvolvedores ution Call #162 Escrever
  • Ethereum Chamada de consenso para todos os principais desenvolvedores nº 110 Escrever *Tim twittou sobre a atualização mais recente do Ethereum Cancun (09.06.23):
  • Ethereum All Core Developers Consensus Call #111 Escrever
  • Ethereum Chamada de consenso para todos os principais desenvolvedores nº 112 Escrever
  • Conteúdo relacionado à atualização do Ethereum:
  • Introdução ao código de autodestruição:
  • Explore a proposta EVMMAX e BLS12-381
  • Além do EIP-4844, o que mais a atualização do Cancun incluirá? Uma espiada na última chamada de consenso da Ethereum
  • Que novo conteúdo foi adicionado na atualização do Ethereum Shanghai?
  • tweets:
  • OK Empreendimentos: após a atualização do Ethereum Shanghai, Cancun atualiza potenciais oportunidades de investimento- Notícias de previsão
  • Além do EIP-4844 de alto perfil, que propostas incluirá a atualização de Cancun?
  • V God: função EVM que vale a pena considerar para exclusão
  • Proto-Danksharding Perguntas frequentes
  • Recomendado por V God丨Compreensão profunda do roteiro de sharding do Ethereum, ler este relatório é suficiente
  • Um artigo para entender o Danksharding, o novo plano de atualização do Ethereum
  • Decifre fatos interessantes e segredos ocultos no mais recente roteiro da Ethereum
  • Vitalik: Por que SELFDESTRUCT faz mais mal do que bem à ecologia do Ethereum
  • Visão Ethereum:
  • Blockworks Pesquisador Brrr: Como o Proto-Danksharding acelera o L1 do Ethereum Escalabilidade de acúmulo
  • A 111ª reunião do Ethereum ACDC: Discuta o escopo final da atualização do Deneb e três propostas, incluindo EIP-7044 *KOL Espiada de Stacy Muur na evolução das soluções de dimensionamento Ethereum: OP Stack、Arbitrário Órbita, Polígono 2.0
  • Comparação horizontal de três tipos de Rollups: Rollups clássicos (Optimistic/ZK Rollups）、Consagrado Rollups、Soberano Rollups
  • [AMA] Somos a EF Research (Pt. 8: 07 julho, 2022)::
  • 3 faixas populares que valem a pena repensar em 2023
  • Montenegro EDCON Reflexões sobre o final de 2023: uma análise das tendências de infraestrutura e aplicativos
  • Fantasia infinita da possibilidade de combinar AI e Web3
  • AI+Web3: Explorando a integração de inteligência artificial e blockchain
  • Comparando zk-rollup e op-rollup: analisando por que o zkSync atual do método de verificação A taxa de gás é alta
  • "Adicionando volumes a volumes": soluções de abstração de contas na era Rollup
  • Interpretação aprofundada do ZKML: princípios técnicos, cenários de aplicação, vantagens e desafios
  • ZKML: uma tecnologia de implantação de modelo que integra IA e blockchain para obter proteção de privacidade
  • disponível dados de segurança fragmentação
  • Diálogo com Qi, fundador da EthStorage Zhou | Disponibilidade de dados e armazenamento descentralizado
  • Leia a versão mais recente do roteiro de desenvolvimento do Ethereum em um artigo *Sobre o Espaço e Uma breve introdução ao Tempo
  • Proposta original:
  • EIP 4844:
  • EIP 6780:
  • EIP 1153:
  • EIP 5920:
  • EIP 5656:
  • EIP 7069:
  • EIP 4788:
  • EIP 2537:
  • EVMMAX EIPs:
  • EIP 6601:
  • EIP 6990:
  • EOF mudanças:
  • EIP 663:
  • EIP 3540:
  • EIP 3670:
  • EIP 4200:
  • EIP 4750:
  • EIP 5450:
  • EIP 6475:
  • EIP 6493:
  • RP 3175:
Ver original
O conteúdo serve apenas de referência e não constitui uma solicitação ou oferta. Não é prestado qualquer aconselhamento em matéria de investimento, fiscal ou jurídica. Consulte a Declaração de exoneração de responsabilidade para obter mais informações sobre os riscos.
  • Recompensa
  • Comentar
  • Partilhar
Comentar
0/400
Nenhum comentário
  • Pino
mapa do site
Negocie cripto em qualquer lugar e a qualquer hora
qrCode
Digitalizar para transferir a aplicação Gate.io
Novidades
Português (Portugal)
  • 简体中文
  • English
  • Tiếng Việt
  • 繁體中文
  • Español
  • Русский
  • Français (Afrique)
  • Português (Portugal)
  • ไทย
  • Indonesia
  • 日本語
  • بالعربية
  • Українська
  • Português (Brasil)
    • Sobre nósCarreirasParceirosContrato de utilizadorAviso de riscoPolítica de privacidadeCookie PolicyKit de mediaComprovativo de reservas de 100%LicenseSegurançaPrivilégios de utilizador GTGate ChainCalendárioAutoridadesCimeirasGate Ventures
    Comprar CriptoVender criptomoedasNegociar SpotNegociação de futurosTokens alavancadosStartupNFTGate PayGate LifeCartão de ofertaGate OTCGate CharityCartão GateLoja Gate
    Benefícios VIPFeedback do utilizadorAnúncioTarifasCentral de AjudaEnviar um pedidoSolicitação de listagemContrato inteligente seguroDesenvolvedoresVerificação de PesquisaAplicação de Mercador P2PAplicação Blue V P2PPrograma de afiliados
    Gate LearnCursos de CriptomoedasGlossário de CriptomoedasPreços de criptomoedasGrandes DadosDivisão ao Meio do Bitcoin
    Gate.io © 2013-2025.