Autor original: LuozhuZhang
Compilado por: Leo, BlockBeats
Em 21 de julho deste ano, Buterin fez um discurso na Ethereum Community Conference (ETHCC) em Paris, dizendo que Ethereum pode atingir 100.000 TPS após completar 5 etapas principais. As 5 etapas são:
The Merge: refere-se à fusão da camada de execução Ethereum (mainnet atual) e da cadeia de beacon (nova camada POS).
The Surge: Refere-se à introdução de sharding no Ethereum.
The Verge: Apresentando a árvore Verkle, que acabará por melhorar a escalabilidade da ETH.
The Purge: Reduza o espaço no disco rígido exigido pelos validadores. Dados históricos e inadimplência são eliminados.
The Splurge: Um conjunto diversificado de atualizações “menores” que garantem que a rede funcione sem problemas após as primeiras 4 fases.
Em 5 de novembro, Buterin anunciou mais uma vez um novo e mais detalhado roteiro Ethereum no Twitter, otimizando o roteiro anterior. Então, quanta melhoria existe?
Twitter KOL LuozhuZhang postou um artigo listando as melhorias no roteiro Ethereum nos últimos anos e reunindo recursos relevantes para ajudar todos a entender melhor o roteiro Ethereum mais recente.
O roteiro do Ethereum foi atualizado. Podemos ver claramente a história da evolução do Ethereum no Twitter de Buterin. Acho que alguns dos recursos abaixo são cruciais para os leitores entenderem o roteiro atualizado do Ethereum.
Avanços no roteiro
Roteiro para 2020: visão geral de Buterin sobre “como poderá ser a ETH 2.0 nos próximos 5 a 10 anos e além”.
Buterin disse que nos últimos dois anos, a equipe Ethereum mudou do estágio de pesquisa "céu azul" para pesquisa e desenvolvimento específicos. A equipe tem uma melhor compreensão das funções e limitações da prova de aposta, do modelo de segurança de sharding, etc. Tecnologias como zk-snark, que antes pareciam difíceis de implementar, agora estão se tornando cada vez mais viáveis.
Além disso, manter a compatibilidade e garantir uma transição suave para Ethereum têm sido as principais direções nos últimos dois anos. Actualmente, a investigação relevante ainda continua e só haverá situações cada vez mais complexas do que esta actualização no futuro. Ao mesmo tempo, V God disse que muitas melhorias vão, na verdade, na direção de menor complexidade.
Naquela época, Ethereum havia começado a mudar de “fragmentação de execução” para “centrado em rollup”, conforme mostrado abaixo:
Dezembro de 2021, roteiro mais detalhado: O novo roteiro “mostra o status atual do desenvolvimento do protocolo Ethereum e a sequência do desenvolvimento futuro”.
Cinco fases são realizadas em paralelo, mas o trabalho principal é no PoS. Quando o PoS estiver concluído, podemos descobrir o que fazer a seguir e criar um novo roteiro!
Em 5 de novembro de 2022, o roteiro foi atualizado novamente:
A fusão
Retirada: Implemente validadores de retirada em toda a testnet do cliente até o final de 2022.
Melhoria da regra de escolha de garfo: (protocolo de consenso Goldfish - uma alternativa segura à regra de escolha de garfo PoS Ethereum LMD GHOST)
Finalidade de slot único: Atualmente, os blocos Ethereum requerem de 64 a 95 slots (cerca de 15 minutos) para concluir a finalização, que é o melhor tempo depois de pesar todos os aspectos - 15 minutos não é muito tempo, que tem tempos de confirmação semelhantes aos das exchanges existentes , permitindo que os usuários executem nós em computadores normais, mesmo com um grande número de validadores, devido a um tamanho de depósito de 32 ETH (em vez dos 1.500 ETH necessários para apostar antecipadamente). No entanto, ainda existe uma maneira mais ideal de reduzir o tempo de finalização para um único slot.
A onda
EIP-4844: Proto-danksharding (também conhecido como EIP-4844) é uma proposta que visa implementar a maior parte da lógica e do "andaime" que compõem a especificação completa do danksharding (por exemplo, formatos de transação, regras de validação), mas nenhum sharding foi realmente implementado ainda. Na implementação do protótipo do danksharding, todos os validadores e usuários ainda devem verificar diretamente a disponibilidade dos dados completos.
Rodas de treinamento do Rollup: Atualmente existem muitos projetos rollup (otimistas e ZK) em vários estágios de desenvolvimento. A modalidade comum desses projetos é a utilização de rodinhas temporárias: a tecnologia do projeto ainda é imatura. Para desenvolver a ecologia, eles optaram por iniciar esta modalidade antecipadamente em vez de confiar inteiramente na sua prova de fraude ou na prova ZK. , o rollup deverá ter um mapa de rota livre.
DAS: Proposta de Amostragem de Dados de Disponibilidade da Fase 1: Uma descrição mais detalhada de como construir uma proposta da Fase 1 baseada em uma abordagem “centrada na disponibilidade de dados”. O vetor de ShardDataHeader é adicionado principalmente à cadeia de beacon e cada fragmento corresponde a um vetor. ShardDataHeader é um pequeno banco de dados que representa uma grande quantidade de dados subjacentes (aproximadamente 0-512 kB de tamanho). Um bloco só é válido se os dados subjacentes apontados pelo ShardDataHeader estiverem disponíveis – ou seja, foram publicados na rede e qualquer pessoa pode baixá-los. No entanto, para manter sua escalabilidade, o cliente não tenta baixar os dados subjacentes completos de cada ShardDataHeader para verificar o bloco, mas em vez disso usa uma técnica indireta chamada "amostragem de dados de disponibilidade" para verificar se os dados estão disponíveis.
O flagelo
Ideia de alto nível
Lista de inclusão
PBS nativo (separação proponente/construtor): Aumenta a diversidade e a resistência à censura do Ethereum.
Queima de MEV: A ideia central é leiloar o “direito de construir blocos” na camada de consenso por meio de um leilão de queima dentro do protocolo. Assim que o licitante vencedor for selecionado, o bloco de execução proposto será confirmado para consumir pelo menos a mesma quantidade de ETH que seu lance. A ideia é que o licitante com lance mais alto fique naturalmente próximo do Valor Máximo Extraível (MEV) dentro do bloco, portanto a maior parte do MEV deve ser queimada diretamente.
A beira
Árvore Verkle: Evoluída da árvore Merkle, ela aproveita a natureza fracamente sem estado do Ethereum para tornar a verificação de blocos completamente sem estado. Verkle trie é usado como esquema de compromisso estatal devido ao seu pequeno tamanho de testemunha e alta eficiência de verificação. O custo do gás é alterado para o custo de acesso estatal (mais ou menos) refletindo o custo da testemunha.
SNARK para L1 EVM: Use a tecnologia ZK-SNARK para fazer provas criptográficas semelhantes à execução de transações Ethereum, seja para facilitar a verificação da própria cadeia Ethereum, ou para construir uma versão equivalente (próxima), mas mais escalável, do que Ethereum fornece zk -rolar.
Ethereum totalmente SNARKed: EVM, consenso, assinaturas, árvore, tudo isso
Eventualmente STARKed Ethereum
A depuração
EIP-4444 (expiração do histórico): Execução de dados históricos agrupados em clientes: Esta proposta força os clientes a parar de servir dados históricos antigos por P2P. Deixe claro que o cliente procura dados históricos de outras fontes, em vez de confiar em algum comportamento opcional do lado do cliente que pode levar à redução da qualidade.
Expiração do estado: O mecanismo de expiração do estado é proposto. A ideia central é que cada período de estado tenha uma árvore de estado (imagine: 1 período de estado é aproximadamente igual a 1 ano, quando um novo período de estado começa, é uma árvore de estado inicializada). Todas as atualizações de estado são gravadas nesta árvore, e os nós completos da rede só precisam armazenar as duas árvores mais próximas. Em média, eles armazenam apenas o estado lido ou escrito nos últimos 1,5 ciclos (aproximadamente 1,5 anos).
O alarde
Abstração de conta: A abstração de conta altera o Ethereum de ter dois tipos de contas (contas de propriedade externa e contas de contrato) para ter apenas um - contas de contrato. As contas contratuais podem iniciar transações e pagar taxas de transação, proporcionando maior flexibilidade para a experiência do usuário.
Otimização de EVM
VDF (Verifiable Delay Function): Um VDF é um tipo de função que leva um certo tempo, um "atraso", para produzir saída (mesmo se você adicionar muitos processadores), mas cuja saída pode ser verificada de forma fácil e rápida .
