Originalmente, “a Merge” referia-se ao evento mais importante na história do protocolo Ethereum desde o seu lançamento: a transição tão esperada e conquistada com dificuldade do sistema de prova de trabalho para prova de participação. Hoje, o Ethereum tem sido um sistema de prova de participação em funcionamento estável há quase exatamente dois anos, e esta prova de participação tem-se revelado notavelmente eficaz emestabilidade, desempenho e evitando riscos de centralização. No entanto, ainda existem algumas áreas importantes nas quais a prova de aposta precisa de melhorias.

O meu diagrama de roteiro a partir de 2023 separou isto em categorias: melhorar as características técnicas, como estabilidade, desempenho e acessibilidade para validadores menores, e mudanças económicas para abordar os riscos de centralização. O primeiro passou a assumir a liderança para "a Fusão", e o último tornou-se parte de "o Flagelo".

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

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

Esta não é uma lista exaustiva de coisas que poderiam ser feitas para o comprovante de 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, preservando ao mesmo tempo a descentralização
• Melhorar a viabilidade do staking para stakers individuais
• Melhorar robustez
• Melhorar a capacidade do Ethereum de resistir e recuperar-se de ataques de 51% (incluindo reversão de finalidade, bloqueio de finalidade e censura)

Neste capítulo

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

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

Que problema estamos a resolver?

Hoje, são necessárias 2-3 épocas (~15 min) para finalizar um bloco, e são necessários 32 ETH para ser um validador. Este era originalmente um compromisso destinado a@VitalikButerin/parametrizing-casper-the-decentralization-finality-time-overhead-tradeoff-3f2011672735">balance between three goals:

• Maximizar o número de validadores que podem participar no staking (isto implica diretamente a minimização da quantidade mínima de Éter necessária para fazer staking)
• Minimizar o tempo de finalização
• Minimizar os custos de execução de 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 (significando: 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 acontecer. E assim, se você tiver muitos validadores, ou você precisa de muito tempo para processar todas as assinaturas deles, ou você precisa de nós muito robustos para processar todas as assinaturas ao mesmo tempo.

Note que tudo isto é condicional a um objetivo chave do Ethereum: garantir que mesmo os ataques bem-sucedidos tenham um alto custo para o atacante. Isto é o que se entende pelo termo 'finalidade econômica'. Se não tivéssemos este objetivo, então poderíamos resolver este problema selecionando aleatoriamente um comitê para finalizar cada slot. Cadeias que não tentam alcançar finalidade econômica, como a Algorand, frequentemente fazer exatamente isso. Mas o problema com esta 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ê poderiam ser detectados como participando no ataque e penalizados, quer através punirougarfo suave coordenado socialmente. Isto significa que um atacante poderia atacar repetidamente a cadeia muitas vezes, perdendo apenas uma pequena parte da sua participação durante 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 simultaneamente o status quo em duas áreas:

1. Finalize blocos num slot (idealmente, manter ou até reduzir o comprimento atual de 12s), em vez de 15 min
2. Permitir que os validadores apostem com 1 Éter (reduzido de 32 Éter)

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 (mais centralizadas) focadas no desempenho".

Primeiro, garante que todos os utilizadores do Ethereum beneficiem realmente do maior nível de garantias de segurança alcançado através do mecanismo de finalidade. Hoje, a maioria dos utilizadores não o faz, porque não estão dispostos a esperar 15 minutos; com finalidade de um único slot, os utilizadores verão as suas transações finalizadas quase tão logo sejam confirmadas. Em segundo lugar, simplifica o protocolo e a infraestrutura circundante se os utilizadores e aplicações não tiverem que se preocupar com a possibilidade de a cadeia reverter, exceto no caso relativamente raro de umfuga de inatividade.

O segundo objetivo é justificado por um desejo de apoiar apostadores individuais. Pesquisa após pesquisa mostra repetidamente que o principal fator que impede mais pessoas de apostar individualmente é o mínimo de 32 Éter. Reduzir o mínimo para 1 Éter resolveria este problema, ao ponto de outras preocupações se tornarem o fator dominante que limita a aposta individual.

Existe um desafio: os objetivos de maior rapidez na finalidade e de uma participação mais democratizada entram em conflito com o objetivo de minimizar os custos gerais. E de facto, este facto é a razão inteira pela qual não começámos com uma finalidade de um único slot desde o início. No entanto, investigações mais recentes apresentam alguns possíveis caminhos em torno do problema.

O que é e como funciona?

A finalidade de um único slot envolve o uso de um algoritmo de consenso que finaliza blocos num único slot. Isso, por si só, não é um objetivo difícil: muitos algoritmos, como consenso Tendermint, já fazemos isso com propriedades ótimas. Uma propriedade desejada única ao Ethereum, que o Tendermint não suporta, évazamentos de inatividade, que permitem que a cadeia continue a funcionar 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 do estilo Tendermint para acomodar vazamentos de inatividade.

Uma proposta de finalidade de slot único líder

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 levar a uma sobrecarga extremamente alta do operador do nó. Para isso, existem algumas soluções principais:

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

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

• 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 forma de pensar sobre Orbit SSF é que ele abre um espaço de opções de compromisso ao longo de um espectro de x=0 (comitês no 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 tamanho médio de validadores para participar em cada slot.

A Orbit aproveita a heterogeneidade pré-existente nos tamanhos de depósito de validadores para obter o máximo de finalidade econômica possível, continuando a dar aos pequenos validadores um papel proporcional. Além disso, a Orbit usa rotação lenta de comitês para garantir alta sobreposição entre quóruns adjacentes, assegurando que sua finalidade econômica ainda se aplique nos limites de troca de comitês.

• Opção 3: staking em dois níveis - um mecanismo onde existem duas classes de stakers, um com requisitos de depósito mais elevados e outro com requisitos de depósito mais baixos. Apenas a classe de depósito mais elevado estaria diretamente envolvida na garantia da finalidade econômica. Existem várias propostas (por exemplo, ver a postagem de stake do Rainbow) para saber exatamente quais são os direitos e responsabilidades do nível de depósito mais baixo. Ideias comuns incluem:
  • o direito de delegar a participação a um apostador de nível superior
  • uma amostra aleatória de validadores de nível inferior a atestar, e ser necessário 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 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 larga 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 assinaturas baseada em STARK (2022): @vbuterin/stark_aggregation"">https://hackmd.io/@vbuterin/stark_aggregation
• Rainbow staking: https://ethresear.ch/t/unbundling-staking-towards-rainbow-staking/18683

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

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

1. Manter o status quo
2. SSF de força bruta
3. Orbit SSF
4. SSF com estaca 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. Para que isto aconteça, é necessário agregar um número muito grande de assinaturas (1 milhão +) num período de tempo muito curto (5-10s). Uma forma de pensar neste método é que envolveminimizando a complexidade sistémica ao aceitar totalmente a complexidade encapsulada.

(3) evita o “alto tecnológico” 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 estamos bem com o custo do ataque sendo talvez 10x menor do que hoje (por exemplo, custo de ataque de $2.5 bilhões em vez de $25 bilhões). É uma visão comum que o Ethereum hoje tem uma finalidade econômica muito maior do que precisa, e seus principais riscos de segurança estão em outro lugar, e portanto, isso é, em teoria, um sacrifício aceitável a ser feito.

O trabalho principal a fazer é verificar se o mecanismo Orbit é seguro e tem as propriedades que desejamos e depois formalizá-lo totalmente e implementá-lo. Além disso, EIP-7251 (aumentar o saldo efetivo máximo)permite a consolidação voluntária do saldo dos validadores que reduz imediatamente um pouco a sobrecarga de verificação da cadeia e atua como uma fase inicial eficaz para o lançamento da Orbit.

(4) evita o repensar inteligente e a alta tecnologia, mas cria um sistema de staking de dois níveis que ainda tem riscos de centralização. Os riscos dependem muito dos direitos específicos que o nível inferior de staking obtém. Por exemplo:

• Se um staker de baixo nível precisa delegar seus direitos de atestar 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 quantia muito pequena de Éter para bloquear a finalidade.
• Se os stakers de nível inferior só podem criar listas de inclusão, então a camada de atestação pode permanecer centralizada, momento em que um ataque de 51% à camada de atestação pode censurar as próprias listas de inclusão.

Várias estratégias podem ser combinadas, por exemplo:

(1 + 2): Use técnicas de força bruta para reduzir o tamanho do depósito mínimo sem fazer a finalidade de um único slot. 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): adicionar Órbita 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): adicionar staking de arco-íris sem realizar a finalidade de slot único

Como interage com outras partes do roteiro?

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

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

Eleição de líder secreto único

Que problema estamos a resolver?

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 DoS quando estão prestes a propor um bloco.

O que é isto e como funciona?

A melhor maneira de corrigir o problema de DoS é ocultar as informações sobre qual validador produzirá o próximo bloco, pelo menos até o momento em que o bloco for realmente produzido. Observe que isso é fácil se removermos o requisito "único": uma soluçãoé permitir que qualquer pessoa crie o próximo bloco, mas exigir orevelação randaoser inferior a 2256 / N. Em média, apenas um validador seria capaz de cumprir este requisito - mas às vezes haveria dois ou mais e às vezes não haveria nenhum. Combinar o requisito de "sigilo" com o requisito de "único" tem sido há muito tempo o problema difícil.

Os 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 pool de IDs cegos (isso é semelhante a como ummixnetDurante cada slot, é selecionado um ID cego aleatório. 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.

Whisk protocolo SSLE

Quais são alguns links para pesquisas existentes?

• Artigo de Dan Boneh (2020): https://eprint.iacr.org/2020/025.pdf
• Whisk (proposta concreta para Ethereum, 2022): https://ethresear.ch/t/whisk-um-protocolo-ssle-baseado-em-embaralhamento-pratico-para-ethereum/11763
• Única tag de eleição de líder secreto em ethresear.ch: https://ethresear.ch/tag/single-secret-leader-election
• SSLE simplificado usando assinaturas em anel: https://ethresear.ch/t/simplified-ssle/12315

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

Realisticamente, o que resta é encontrar e implementar um protocolo que seja suficientemente simples para que estejamos confortáveis em implementá-lo na rede principal. Nós valorizamos muito o Ethereum sendo 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 suficientemente eficiente e resistente ao quantum também é um problema em aberto.

Pode acontecer que a complexidade adicional introduzida pela SSLE só diminua o suficiente quando tomarmos a decisão e introduzirmos a máquina para realizar provas de conhecimento zero de uso geral no protocolo Ethereum em 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 interage com outras partes do roteiro?

Se adicionarmos um mecanismo de separação de atestador-proponente (APS), por exemplo.bilhetes 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 confiar em construtores de blocos especializados. No entanto, ainda beneficiaríamos de SSLE para blocos de consenso (ou seja, blocos contendo mensagens de protocolo como testemunhos, talvez partes de listas de inclusão, etc).

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

Que problema estamos a resolver?

Há valor no protocolo Ethereum’s tempo de confirmação da transação a diminuir ainda mais, de 12 segundos para, por exemplo, 4 segundos. Fazer isso melhoraria significativamente a experiência do usuário tanto da L1 como dos rollups baseados, tornando os protocolos defi mais eficientes. Também tornaria mais fácil para os L2s se descentralizarem, pois permitiria que uma grande classe de aplicações L2 funcionasse em rollups baseados, reduzindo a demanda para que os L2s construam seu próprio sequenciamento descentralizado baseado em comitê.

O que é isto e como funciona?

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

1. Reduzir os tempos de slot, até por exemplo. 8 segundosou 4 segundos. Isso não necessariamente tem que significar finalidade de 4 segundos: a finalidade inherentemente requer três rodadas de comunicação, então podemos fazer com que cada rodada de comunicação seja um bloco separado, o que, após 4 segundos, obteria 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 veem no seu bloco em tempo real e publicar imediatamente uma mensagem de pré-confirmação para cada transação ("A minha primeira transação é 0×1234…", "A minha segunda transação é 0×5678…"). O caso de um proponente publicar duas confirmações conflitantes pode ser tratado de duas maneiras: (i) penalizando o proponente, ou (ii) usando atestadores para votar em qual veio primeiro.

Quais são alguns links para pesquisas existentes?

• Pré-confirmações com base em: https://ethresear.ch/t/based-preconfirmations/17353
• Compromissos de proponentes reforçados por protocolo (PEPC): https://ethresear.ch/t/unbundling-pbs-towards-protocolo-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 compromissos?

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 obter atestações incluídas suficientemente 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 da latência da rede ("delta") para dois segundos.

A abordagem do proponente de pré-confirmação tem a fraqueza de que pode melhorar muito os tempos de inclusão no caso médio, mas não no pior caso: se o proponente atual estiver bem funcional, 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 terá que esperar até 12 segundos completos 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 a sua opcionalidade o maior tempo possível. Se os atestados aprovarem a pontualidade das pré-confirmações, os remetentes das transações poderiam condicionar uma parte da taxa a uma pré-confirmação imediata, mas isso colocaria um fardo extra sobre os atestados e potencialmente tornaria mais difícil para os atestados continuarem funcionando como um "tubo mudo" neutro.

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

Como interage com outras partes do roteiro?

As pré-confirmações baseadas em proponentes 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 demasiado centralizadora para os 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 por implementar. Existem estruturas de slot que contêm menos rondas e são, portanto, mais amigáveis para tempos de slot curtos, mas fazem concessões em outros lugares.

Outras áreas de pesquisa

recuperação de ataque de 51%

Há frequentemente 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 suave de minoriaque garante que os bons vençam e os maus sejam vazados por inatividade ou cortados. No entanto, este grau de dependência excessiva da camada social é, sem dúvida, insalubre. 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 possível, isso contaria como um algoritmo de consenso tolerante a falhas >50%, e já conhecemos o (muito restritivo) limitações matematicamente comprováveis desses tipos de algoritmosMas podemos alcançar automação parcial: por exemplo, um cliente poderia recusar automaticamente aceitar uma cadeia como finalizada, ou mesmo como cabeça da escolha do garfo, se censurar transações que o cliente tenha visto por tempo suficiente. Um objetivo chave seria garantir que os vilões em um ataque pelo menos não possam obter uma vitória rápida e limpa.

Aumentar o limiar 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 esta percentagem for aumentada, por exemplo. para 80%, então o número adicional de períodos de não-finalidade será relativamente baixo, mas o Ethereum ganharia propriedades de segurança: em particular, muitas situações mais controversas resultarão na interrupção temporária da finalidade. Esta parece uma situação muito mais saudável do que "o lado errado" obter uma vitória instantânea, tanto quando o lado errado é um atacante, e quando é um cliente que tem um bug.

Isto também responde à pergunta “qual é o objetivo dos validadores solo”? Hoje, a maioria dos validadores já está a validar através de pools, e parece muito improvável que os validadores solo cheguem a 51% do ETH em jogo. No entanto, conseguir que os validadores solo cheguem a uma minoria bloqueadora de quórum, especialmente se o quórum for de 80% (assim, uma minoria bloqueadora de quórum só precisaria de 21%), parece potencialmente alcançável se trabalharmos arduamente nisso. Desde que os validadores solo não colaborarem com um ataque de 51% (seja de reversão de finalidade ou censura), tal ataque não teria uma “vitória limpa”, e os validadores solo seriam motivados a ajudar a organizar um fork suave de minoria.

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

Resistência quântica

Metaculus atualmente acredita, embora com barras de erro amplas, é provável que os computadores quânticos comecem a quebrar a criptografia algures 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 a sério. Isso tem consequências em todo o roteiro do Ethereum: isso significa que cada parte do protocolo Ethereum que atualmente depende de curvas elípticas precisará ter algum tipo de substituição resistente a hash ou de outra forma quântica. Isso significa especialmente que não podemos assumir que seremos capazes de contar comas excelentes propriedades da agregação BLSprocessar assinaturas de um grande conjunto de validadores para sempre. Isso justifica o conservadorismo nas suposições em torno do desempenho dos designs de prova de participação, e também é uma razão para ser mais proativo no desenvolvimento de alternativas resistentes à computação 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, contacte o Gate Learnequipe e eles vão lidar com isso prontamente.
2. Aviso de responsabilidade: As opiniões expressas neste artigo são exclusivamente as do autor e não constituem qualquer conselho de investimento.
3. As traduções do artigo para outros idiomas são feitas pela equipe do Gate Learn. A menos que mencionado, copiar, distribuir ou plagiar os artigos traduzidos é proibido.