Originalmente, “a Fusão” referia-se ao evento mais importante na história do protocolo Ethereum desde o seu lançamento: a transição tão aguardada e conquistada com dificuldade do sistema de prova de trabalho para o sistema de prova de participação. Hoje, o Ethereum tem operado de forma estável com o sistema de prova de participação há quase exatamente dois anos, e este sistema de prova de participação tem se mostrado notavelmente eficaz em estabilidade, desempenho e evitando riscos de centralizaçãoNo entanto, ainda existem áreas importantes nas quais a prova de participação precisa melhorar.

Meu diagrama de roteiro de 2023 separou isso em categorias: melhorando recursos técnicos como estabilidade, desempenho e acessibilidade para validadores menores, e mudanças econômicas para abordar riscos de centralização. O primeiro passou a assumir o comando de “the Merge”, e o último tornou-se parte de “the Scourge”.

A Fusão, edição do roteiro de 2023.

Esta postagem focará na parte “Merge”: o que ainda pode ser melhorado no design técnico de prova de participação, e quais são alguns caminhos para chegar lá?

Esta não é uma lista exaustiva de coisas que poderiam ser feitas para comprovar a participação; em vez disso, é uma lista de ideias que estão sendo ativamente consideradas.

A Fusão: objetivos-chave

• Finalidade de slot único
• Confirmação e finalização da transação o mais rápido possível, mantendo a descentralização
• Melhorar a viabilidade do staking para stakers individuais
• Melhorar robustez
• Melhorar a capacidade do Ethereum de resistir e se recuperar de ataques de 51% (incluindo reversão de finalidade, bloqueio de finalidade e censura)

Neste capítulo

• Finalidade de slot único e democratização do staking
• Eleição de líder secreto único
• Confirmações de transações mais rápidas
• Outras áreas de pesquisa

Finalidade de slot único e democratização do staking

Qual problema estamos resolvendo?

Hoje, leva 2-3 épocas (~15 min) para finalizar um bloco, e são necessários 32 ETH para ser um validador. Isso foi originalmente um compromisso destinado a @VitalikButerin/parametrizando-casper-o-tradeoff-entre descentralização, finalidade e tempo de overhead, equilíbrio entre três objetivos:

• Maximizar o número de validadores que podem participar do staking (isso implica diretamente na minimização do ETH mínimo necessário para o staking)
• Minimizando o tempo de finalização
• Minimizando os custos de executar um nó, neste caso o custo de baixar, verificar e retransmitir todas as assinaturas dos outros validadores

Os três objetivos estão em conflito: para que a finalidade econômica seja possível (ou seja, um atacante precisaria queimar uma grande quantidade de ETH para reverter um bloco finalizado), você precisa que cada validador assine duas mensagens sempre que a finalidade ocorre. E se você tiver muitos validadores, ou você precisa de muito tempo para processar todas as assinaturas, ou você precisa de nós muito poderosos para processar todas as assinaturas ao mesmo tempo.

Note que tudo isso é condicional a um objetivo chave do Ethereum: garantir que mesmo os ataques bem-sucedidos tenham um alto custo para o atacante. Isso é o que se entende pelo termo 'finalidade econômica'. Se não tivéssemos esse objetivo, poderíamos resolver esse problema selecionando aleatoriamente um comitê para finalizar cada slot. Blockchains que não tentam alcançar a finalidade econômica, como Algorand, frequentemente fazer exatamente isso. Mas o problema com essa abordagem é que se um atacante controlar 51% dos validadores, então eles podem realizar um ataque (revertendo um bloco finalizado, ou censurando, ou atrasando a finalização) a um custo muito baixo: apenas a parte de seus nós que estão no comitê poderia ser detectada como participando do ataque e penalizada, seja porslashingoufork suave coordenado socialmenteIsso significa que um atacante poderia atacar repetidamente a cadeia muitas vezes, perdendo apenas uma pequena parte de sua participação em cada ataque. Portanto, se quisermos uma finalidade econômica, uma abordagem ingênua baseada em comitês não funciona, e parece à primeira vista que precisamos do conjunto completo de validadores para participar.

Idealmente, queremos preservar a finalidade econômica, ao mesmo tempo que melhoramos o status quo em duas áreas:

1. Finalizar blocos em um slot (idealmente, manter ou até reduzir o comprimento atual de 12s), em vez de 15 minutos
2. Permitir que os validadores apostem com 1 ETH (em vez de 32 ETH)

O primeiro objetivo é justificado por dois objetivos, ambos dos quais podem ser vistos como "trazer as propriedades do Ethereum em linha com as das cadeias L1 focadas em desempenho (mais centralizadas)".

Primeiro, garante que todos os usuários do Ethereum realmente se beneficiem do maior nível de garantias de segurança alcançado por meio do mecanismo de finalidade. Hoje, a maioria dos usuários não o faz, porque não estão dispostos a esperar 15 minutos; com finalidade de slot único, os usuários verão suas transações finalizadas quase assim que forem confirmadas. Em segundo lugar, simplifica o protocolo e a infraestrutura circundante se os usuários e aplicativos não precisarem se preocupar com a possibilidade de a cadeia reverter, exceto no caso relativamente raro de umvazamento de inatividade.

O segundo objetivo é justificado pelo desejo de apoiar os apostadores individuais. Enquete após enquete mostram repetidamente que o principal fator que impede mais pessoas de apostar individualmente é o mínimo de 32 ETH. Reduzir o mínimo para 1 ETH resolveria esse problema, a ponto de outras preocupações se tornarem o fator dominante que limita as apostas individuais.

Existe um desafio: os objetivos de finalidade mais rápida e de stake mais democratizado entram em conflito com o objetivo de minimizar as despesas gerais. E, de fato, este fato é a razão inteira pela qual não começamos com uma finalidade de slot único a princípio. No entanto, pesquisas mais recentes apresentam alguns possíveis caminhos ao redor do problema.

O que é isso e como funciona?

A finalidade de um único slot envolve o uso de um algoritmo de consenso que finaliza blocos em um único slot. Isso por si só não é um objetivo difícil: muitos algoritmos, como consenso Tendermint, já faz isso com propriedades ótimas. Uma propriedade desejada única para o Ethereum, que o Tendermint não suporta, é vazamentos de inatividade, que permitem que a cadeia continue funcionando e eventualmente se recupere mesmo quando mais de 1/3 dos validadores ficam offline. Felizmente, esse desejo já foi atendido: existem já propostasque modificam o consenso estilo Tendermint para acomodar vazamentos de inatividade.

Uma proposta líder de finalidade de slot único

A parte mais difícil do problema é descobrir como fazer com que a finalidade de um único slot funcione com um número muito alto de validadores, sem resultar em uma sobrecarga extremamente alta para os operadores de nós. Para isso, existem algumas soluções principais:

• Opção 1: Força bruta - trabalhar duro na implementação de melhores protocolos de agregação de assinaturas, potencialmente usando ZK-SNARKs, o que nos permitiria processar assinaturas de milhões de validadores em cada slot.

Horn, um dos designs propostos para um protocolo de agregação melhor.

• Opção 2: Comitês de Órbita - um novo mecanismo que permite que um comitê de tamanho médio selecionado aleatoriamente seja responsável por finalizar a cadeia, mas de uma forma que preserve as propriedades de custo de ataque que estamos procurando.

  Uma maneira de pensar sobre o Orbit SSF é que ele abre um espaço de opções de compromisso ao longo de um espectro de x=0 (comitês ao estilo Algorand, sem finalidade econômica) a x=1 (status quo Ethereum), abrindo pontos no meio onde o Ethereum ainda tem finalidade econômica suficiente para ser extremamente seguro, mas ao mesmo tempo obtemos os benefícios de eficiência de precisar apenas de uma amostra aleatória de validadores de tamanho médio para participar de cada slot.

Orbit aproveita a heterogeneidade preexistente nos tamanhos de depósito do validador para obter o máximo de finalidade econômica possível, ainda dando aos pequenos validadores um papel proporcional. Além disso, Orbit usa uma rotação lenta do comitê para garantir uma alta sobreposição entre os quóruns adjacentes, garantindo que sua finalidade econômica ainda se aplique nos limites de troca de comitê.

• Opção 3: stake em dois níveis - um mecanismo onde existem duas classes de stakers, uma com requisitos de depósito mais altos e outra com requisitos de depósito mais baixos. Apenas o nível de depósito mais alto estaria diretamente envolvido em fornecer a finalidade econômica. Existem várias propostas (por exemplo, veja a postagem de aposta no Rainbow staking) para exatamente quais direitos e responsabilidades o nível de depósito mais baixo possui. Ideias comuns incluem:
  • o direito de delegar participação a um staker de nível superior
  • uma amostra aleatória de validadores de baixo nível atestando, e sendo necessária para finalizar, cada bloco
  • o direito de gerarlistas de inclusão

Quais são alguns links para pesquisas existentes?

• Caminhos em direção à finalidade de um único slot (2022): @vbuterin/single_slot_finality"">https://notes.ethereum.org/@vbuterin/single_slot_finality
• Uma proposta concreta para um protocolo de finalidade de slot único para Ethereum (2023): https://eprint.iacr.org/2023/280
• Orbit SSF: https://ethresear.ch/t/orbit-ssf-solo-staking-friendly-validator-set-management-for-ssf/19928
• Análise adicional sobre os mecanismos estilo Orbit: https://ethresear.ch/t/vorbit-ssf-with-circular-and-spiral-finality-validator-selection-and-distribution/20464
• Horn, protocolo de agregação de assinaturas (2022): https://ethresear.ch/t/horn-collecting-signatures-for-faster-finality/14219
• Fusão de assinaturas para consenso em grande escala (2023): https://ethresear.ch/t/signature-merging-for-large-scale-consensus/17386?u=asn
• Protocolo de agregação de assinaturas proposto por Khovratovich et al:@7dpNYqjKQGeYC7wMlPxHtQ/BykM3ggu0#/"">https://hackmd.io/@7dpNYqjKQGeYC7wMlPxHtQ/BykM3ggu0#/
• Agregação de assinatura baseada em STARK (2022): @vbuterin/stark_aggregation"">https://hackmd.io/@vbuterin/stark_aggregation
• Staking em arco-íris: https://ethresear.ch/t/unbundling-staking-towards-rainbow-staking/18683

O que resta fazer e quais são os tradeoffs?

Existem quatro caminhos principais possíveis a seguir (e também podemos seguir caminhos híbridos):

1. Manter o status quo
2. Força bruta SSF
3. Orbit SSF
4. SSF com staking em dois níveis

(1) significa não fazer nenhum trabalho e deixar o staking como está, mas deixa a experiência de segurança do Ethereum e as propriedades de centralização do staking piores do que poderiam ser.

(2) força bruta o problema com alta tecnologia. Fazer isso acontecer requer a agregação de um número muito grande de assinaturas (1 milhão +) em um período muito curto de tempo (5-10s). Uma maneira de pensar nesse enfoque é que envolveminimizando a complexidade sistêmica ao adotar totalmente a complexidade encapsulada.

(3) evita o “alto tecnologia”, e resolve o problema com um repensar inteligente em torno das suposições do protocolo: relaxamos o requisito de “finalidade econômica” para que exijamos que os ataques sejam caros, mas tudo bem com o custo do ataque sendo talvez 10x menos do que hoje (ex. custo de ataque de $2.5 bilhões em vez de $25 bilhões). É uma visão comum que o Ethereum hoje tem muito mais finalidade econômica do que precisa, e seus principais riscos de segurança estão em outro lugar, e assim, isso é, sem dúvida, um sacrifício aceitável a ser feito.

O principal trabalho a ser feito é verificar se o mecanismo Orbit é seguro e possui as propriedades que desejamos e, em seguida, formalizá-lo e implementá-lo completamente. Além disso, EIP-7251 (aumento do saldo efetivo máximo)permite a consolidação voluntária do saldo do validador que reduz imediatamente um pouco a sobrecarga de verificação da cadeia, e atua como uma etapa inicial eficaz para um lançamento do Orbit.

(4) evita a reelaboração inteligente e de alta tecnologia, mas cria um sistema de participação em duas camadas que ainda tem riscos de centralização. Os riscos dependem fortemente dos direitos específicos que a camada inferior de participação recebe. Por exemplo:

• Se um staker de baixo nível precisar delegar seus direitos de atestação a um staker de alto nível, então a delegação poderia centralizar e assim acabaríamos com dois níveis altamente centralizados de staking.
• Se for necessário uma amostra aleatória do nível inferior para aprovar cada bloco, então um atacante poderia gastar uma quantidade muito pequena de ETH para bloquear a finalidade.
• Se os stakers de nível inferior só podem fazer listas de inclusão, então a camada de atestado pode permanecer centralizada, momento em que um ataque de 51% à camada de atestado pode censurar as próprias listas de inclusão.

Diversas estratégias podem ser combinadas, por exemplo:

(1 + 2): use técnicas de força bruta para reduzir o tamanho mínimo de depósito sem fazer finalidade de slot único. A quantidade de agregação necessária é 64x menor do que no caso puro (3), então o problema se torna mais fácil.

(1 + 3): adicione Orbit sem fazer finalidade de slot único

(2 + 3): faça Orbit SSF com parâmetros conservadores (por exemplo, comitê de validadores de 128k em vez de 8k ou 32k) e use técnicas de força bruta para tornar isso ultraeficiente.

(1 + 4): adicione staking arco-íris sem fazer finalidade de slot único

Como ele interage com outras partes do roteiro?

Além de seus outros benefícios, a finalidade de slot único reduz o risco de certos tipos de ataques MEV multi-bloco. Além disso, os designs de separação de atestador-proponente e outros pipelines de produção de blocos em protocolo precisariam ser projetados de forma diferente em um mundo de finalidade de slot único.

Estratégias de força bruta têm a fraqueza de que tornam mais difícil reduzir os tempos de slot.

Eleição única de líder secreto

Qual problema estamos resolvendo?

Hoje, qual validador vai propor o próximo bloco é conhecido antecipadamente. Isso cria uma vulnerabilidade de segurança: um atacante pode observar a rede, identificar quais validadores correspondem a quais endereços IP e atacar cada validador exatamente quando estão prestes a propor um bloco.

O que é isso e como funciona?

A melhor maneira de corrigir o problema de DoS é esconder as informações sobre qual validador irá produzir o próximo bloco, pelo menos até o momento em que o bloco é realmente produzido. Note que isso é fácil se removermos o requisito 'único'.uma soluçãoé permitir que qualquer pessoa crie o próximo bloco, mas exige orevelação do randaoser inferior a 2256 / N. Em média, apenas um validador seria capaz de atender a esse requisito - mas às vezes haveria dois ou mais e às vezes haveria zero. Combinar o requisito de 'sigilo' com o requisito 'único' tem sido há muito o grande problema.

Protocolos de eleição de líder secreto único resolvem isso usando algumas técnicas criptográficas para criar um ID de validador "cego" para cada validador e, em seguida, dando a muitos proponentes a oportunidade de embaralhar e reembaralhar o grupo de IDs cegos (isso é semelhante a como umMixnetfunciona). Durante cada slot, um ID cego aleatório é selecionado. Apenas o proprietário desse ID cego é capaz de gerar uma prova válida para propor o bloco, mas ninguém mais sabe a qual validador esse ID cego corresponde.

Protocolo SSLE Whisk

Quais são alguns links para pesquisas existentes?

• Artigo de Dan Boneh (2020): https://eprint.iacr.org/2020/025.pdf
• Batedeira (proposta concreta para Ethereum, 2022):https://ethresear.ch/t/whisk-a-practical-shuffle-based-ssle-protocolo-for-Ethereum/11763
• Tag de eleição de líder secreto única em ethresear.ch:https://ethresear.ch/tag/single-secret-leader-election
• SSLE simplificado usando assinaturas de anel: https://ethresear.ch/t/simplified-ssle/12315

O que resta a fazer e quais são os tradeoffs?

Realisticamente, o que resta é encontrar e implementar um protocolo que seja suficientemente simples para que nos sintamos confortáveis em implementá-lo na mainnet. Valorizamos muito o Ethereum como um protocolo razoavelmente simples, e não queremos que a complexidade aumente ainda mais. As implementações SSLE que vimos adicionam centenas de linhas de código de especificação e introduzem novas suposições em criptografia complicada. Descobrir uma implementação SSLE eficiente o suficiente para resistir a quantidades também é um problema em aberto.

Pode acontecer que a complexidade adicional introduzida pelo SSLE só diminua o suficiente quando tomarmos a decisão e introduzirmos a maquinaria para realizar provas de conhecimento zero de uso geral no protocolo Ethereum na L1 por outras razões (por exemplo, árvores de estado, ZK-EVM).

Uma opção alternativa é simplesmente não se preocupar com o SSLE e usar mitigadores fora do protocolo (por exemplo, na camada p2p) para resolver os problemas de DoS.

Como isso interage com outras partes do roteiro?

Se adicionarmos um mecanismo de separação de atestador-proponente (APS), por exemplo. tickets de execução, em seguida, os blocos de execução (ou seja, blocos contendo transações Ethereum) não precisarão de SSLE, porque poderíamos contar com construtores de blocos especializados. No entanto, ainda nos beneficiaríamos do SSLE para blocos de consenso (ou seja, blocos contendo mensagens de protocolo como atestações, talvez partes de listas de inclusão, etc).

Confirmações de transações mais rápidas

Qual problema estamos resolvendo?

Existe valor no Ethereumtempo de confirmação da transação diminuindo ainda mais, de 12 segundos para, por exemplo, 4 segundos. Fazer isso melhoraria significativamente a experiência do usuário tanto da L1 quanto das rollups baseadas, tornando os protocolos defi mais eficientes. Também facilitaria a descentralização das L2s, pois permitiria que uma grande variedade de aplicativos L2 funcionasse em rollups baseados, reduzindo a demanda por L2s para construir sua própria sequência descentralizada baseada em comitê.

O que é isso e como funciona?

Existem amplamente duas famílias de técnicas aqui:

1. Reduzir os tempos de slot, para baixo para eg. 8 segundosou 4 segundos. Isso não precisa necessariamente significar finalidade de 4 segundos: a finalidade inerentemente requer três rodadas de comunicação e, portanto, podemos fazer com que cada rodada de comunicação seja um bloco separado, que após 4 segundos receba pelo menos uma confirmação preliminar.
2. Permitir que os proponentes publiquem pré-confirmações ao longo de um slot. No extremo, um proponente poderia incluir transações que eles veem em seu bloco em tempo real e imediatamente publicar uma mensagem de pré-confirmação para cada transação ("Minha primeira transação é 0×1234…", "Minha segunda transação é 0×5678…"). O caso de um proponente publicar duas confirmações conflitantes pode ser tratado de duas maneiras: (i) punindo o proponente, ou (ii) usando atestadores para votar em qual veio primeiro.

Quais são alguns links para pesquisas existentes?

• Com base nas pré-confirmações: https://ethresear.ch/t/based-preconfirmations/17353
• Compromissos de proponente aplicados pelo protocolo (PEPC): https://ethresear.ch/t/unbundling-pbs-towards-protocol-enforced-proposer-commitments-pepc/13879
• Períodos escalonados em cadeias paralelas (uma ideia da era de 2018 para alcançar baixa latência): https://ethresear.ch/t/staggered-periods/1793

O que resta a fazer e quais são os tradeoffs?

Está longe de ser claro o quão prático é reduzir os tempos de slot. Mesmo hoje, os validadores em muitas regiões do mundo têm dificuldade em incluir testemunhos rapidamente. Tentar tempos de slot de 4 segundos corre o risco de centralizar o conjunto de validadores e tornar impraticável ser um validador fora de algumas geografias privilegiadas devido à latência. Especificamente, a mudança para tempos de slot de 4 segundos exigiria reduzir o limite de latência de rede (“delta”) para dois segundos.

A abordagem de pré-confirmação do proponente tem a fraqueza de que pode melhorar significativamente os tempos de inclusão em casos médios, mas não em casos extremos: se o proponente atual estiver funcionando bem, sua transação será pré-confirmada em 0,5 segundos em vez de ser incluída (em média) em 6 segundos, mas se o proponente atual estiver offline ou não estiver funcionando bem, ainda seria necessário esperar até 12 segundos para que o próximo slot comece e forneça um novo proponente.

Além disso, há a questão em aberto de como as pré-confirmações serão incentivadas. Os proponentes têm um incentivo para maximizar sua opção o máximo possível. Se os atestadores concordarem com a pontualidade das pré-confirmações, os remetentes de transações poderiam fazer uma parte da taxa condicional a uma pré-confirmação imediata, mas isso colocaria uma carga extra sobre os atestadores, e potencialmente tornaria mais difícil para os atestadores continuarem funcionando como um “dumb pipe” neutro.

Por outro lado, se não tentarmos isso e mantivermos os tempos de finalização em 12 segundos (ou mais), o ecossistema dará maior peso aos mecanismos de pré-confirmação feitos pelos layer 2s, e a interação entre camadas 2 levará mais tempo.

Como isso interage com outras partes do roteiro?

As pré-confirmações baseadas no proponente dependem realisticamente de um mecanismo de separação de atestadores-proponentes (APS), por exemplo. bilhetes de execução. Caso contrário, a pressão para fornecer pré-confirmações em tempo real pode ser muito centralizadora para validadores regulares.

Exatamente quão curtos os tempos de slot podem ser também depende da estrutura do slot, que depende muito das versões de APS, listas de inclusão, etc que acabamos implementando. Existem estruturas de slot que contêm menos rodadas e, portanto, são mais amigáveis para tempos de slot curtos, mas elas fazem compensações em outros lugares.

Outras áreas de pesquisa

recuperação de ataque de 51%

Muitas vezes há a suposição de que se ocorrer um ataque de 51% (incluindo ataques que não são criptograficamente comprováveis, como censura), a comunidade se unirá para implementar umgarfo macio minoritárioque garante que os bons vençam e os maus sejam vazados por inatividade ou penalizados. No entanto, esse grau de super-reliance na camada social é, sem dúvida, prejudicial. Podemos tentar reduzir a dependência da camada social, tornando o processo de recuperação o mais automatizado possível.

A automação completa é impossível, porque se fosse, isso contaria como um algoritmo de consenso tolerante a falhas >50%, e já sabemos o (muito restritivo)limitações matematicamente comprováveis desses tipos de algoritmos. Mas podemos alcançar a automação parcial: por exemplo, um cliente pode automaticamente se recusar a aceitar uma cadeia como finalizada, ou até mesmo como o chefe da escolha do fork, se ela censurar transações que o cliente viu por tempo suficiente. Um objetivo fundamental seria garantir que os bandidos em um ataque, pelo menos, não consigam uma vitória limpa e rápida.

Aumentando o limite de quórum

Hoje, um bloco é finalizado se 67% dos stakers o apoiarem. Há um argumento de que isso é excessivamente agressivo. Houve apenas uma falha de finalidade (muito breve) em toda a história do Ethereum. Se esse percentual for aumentado, por exemplo, para 80%, então o número adicionado de períodos de não-finalização será relativamente baixo, mas o Ethereum ganharia propriedades de segurança: em particular, muitas situações mais contenciosas resultariam na paralisação temporária da finalidade. Isso parece uma situação muito mais saudável do que “o lado errado” obtendo uma vitória instantânea, tanto quando o lado errado é um atacante, quanto quando é um cliente que tem um bug.

Isso também responde à pergunta “qual é o ponto dos stakers solo”? Hoje, a maioria dos stakers já está participando de pools, e parece muito improvável que os stakers solo alcancem 51% do ETH apostado. No entanto, conseguir que os stakers solo alcancem uma minoria bloqueadora de quórum, especialmente se o quórum for de 80% (então uma minoria bloqueadora de quórum precisaria apenas de 21%), parece potencialmente alcançável se trabalharmos duro nisso. Desde que os stakers solo não participem de um ataque de 51% (seja revisão de finalidade ou censura), tal ataque não obteria uma “vitória limpa”, e os stakers solo seriam motivados a ajudar a organizar um hard fork minoritário.

Note que existem interações entre os limiares de quórum e o mecanismo de Órbita: se acabarmos usando Órbita, então o que exatamente significa "21% dos validadores" se tornará uma questão mais complicada, e dependerá em parte da distribuição dos validadores.

Resistência quântica

Metaculus atualmente acredita, embora com amplas barras de erro, é provável que os computadores quânticos comecem a quebrar criptografia em algum momento na década de 2030:

Especialistas em computação quântica, como Scott Aaronson, também começaram recentemente a considerar a possibilidade de os computadores quânticos realmente funcionarem a médio prazomuito mais seriamente. Isso tem consequências em todo o roadmap do Ethereum: significa que cada parte do protocolo Ethereum que atualmente depende de curvas elípticas precisará ter alguma substituição baseada em hash ou de outra forma resistente a quântica. Isso significa especialmente que não podemos assumir que seremos capazes de contar comas excelentes propriedades da agregação de BLSprocessar assinaturas de um grande conjunto de validadores para sempre. Isso justifica o conservadorismo nas suposições sobre o desempenho dos designs de prova de aposta, e também é uma causa para ser mais proativo no desenvolvimento de alternativas resistentes à quântica.

Aviso Legal：

1. Este artigo é reproduzido a partir de [ Vitalik Buterin], Todos os direitos autorais pertencem ao autor original [Vitalik Buterin]. Se houver objeções a esta reimpressão, entre em contato com o Gate Learnequipe e eles vão lidar com isso prontamente.
2. Isenção de Responsabilidade: As opiniões expressas neste artigo são exclusivamente do autor e não constituem qualquer conselho de investimento.
3. As traduções do artigo para outros idiomas são feitas pela equipe Gate Learn. Salvo indicação em contrário, copiar, distribuir ou plagiar os artigos traduzidos é proibido.