Democracia de staking, confirmação mais rápida de transações, resistência a ataques quânticos... Qual é o futuro do Ethereum?
Escrito por: Vitalik Buterin
Compilado por: Alex Liu, Foresight News
Agradecimentos especiais a Justin Drake, Hsiao-wei Wang, @antonttc, Anders Elowsson e Francesco pelos comentários e avaliações.
Inicialmente, “the Merge” referia-se ao evento mais importante na história do protocolo Ethereum desde o seu lançamento: a tão esperada e duramente conquistada transição da Prova de Trabalho (PoW) para a Prova de Participação (PoS). Hoje, Ethereum tem sido um sistema de prova de aposta estável e funcional por quase dois anos completos, e esse sistema de prova de aposta teve um desempenho extremamente bom em termos de estabilidade, desempenho e prevenção de riscos de centralização. No entanto, ainda existem algumas áreas importantes onde a prova de participação precisa de melhorias.
O meu roteiro para 2023 divide-o em várias partes: melhorias nas características técnicas, como estabilidade, desempenho e acessibilidade para pequenos validadores, bem como mudanças económicas que abordam os riscos da centralização. O primeiro assumiu o título de “a Fusão” e o último passou a fazer parte do “Flagelo”.
Este artigo se concentrará na parte “Mesclar”: Onde mais o design técnico da Prova de Participação pode ser melhorado e quais são as formas de atingir esse objetivo?
Esta não é uma lista exaustiva de coisas que a prova de aposta pode fazer, mas sim uma lista de ideias que estão sendo ativamente consideradas;
Finalidade de slot único e democratização de apostas
Que problema estamos tentando resolver?
Hoje, leva de 2 a 3 épocas (cerca de 15 minutos) para completar um bloco e requer 32 ETH para se tornar um staker. Este foi originalmente um compromisso para equilibrar três objetivos:
Maximizar o número de validadores que podem participar do staking (isso significa diretamente minimizar o ETH mínimo necessário para o staking)
Minimize o tempo de finalização
Minimize a sobrecarga de execução de um nó, neste caso o custo de download, verificação e retransmissão de todas as outras assinaturas do validador
Esses três objetivos estão em conflito entre si: para tornar possível a finalidade econômica (ou seja: um invasor precisaria queimar muito ETH para reverter um bloco finalizado), você precisa que cada validador assine ambas as mensagens sempre que a finalização ocorrer. Portanto, se você tiver muitos validadores, precisará de muito tempo para processar todas as assinaturas ou precisará de nós muito poderosos para processar todas as assinaturas ao mesmo tempo.
Esses três objetivos estão em conflito entre si: para tornar possível a finalidade econômica (ou seja: um invasor precisaria queimar muito ETH para adulterar os blocos finalizados), você precisa que cada validador assine ambas as mensagens sempre que ocorrer a finalização. Portanto, se você tiver muitos validadores, precisará de muito tempo para processar todas as assinaturas ou precisará de nós muito poderosos para processar todas as assinaturas ao mesmo tempo.
Observe que tudo isso está condicionado a um objetivo principal do Ethereum: garantir que mesmo ataques bem-sucedidos imponham altos custos ao invasor. Isto é o que significa o termo “finalidade económica”. Se não tivermos esse objetivo, então podemos resolver esse problema selecionando aleatoriamente uma comissão para finalizar cada bloco. As cadeias que não tentam alcançar a finalidade económica, como a Algorand, muitas vezes fazem exatamente isso. Mas o problema com essa abordagem é que se um invasor controlar 51% dos validadores, ele poderá realizar o ataque (recuperar blocos finalizados, censura ou atrasar a finalização) a um custo muito baixo: basta controlar seus nós em alguns nós. Dentro do comitê, alguém pode ser detectado por participar de um ataque e punido, seja por meio de corte ou de um soft fork socialmente coordenado. Isso significa que um invasor pode atacar repetidamente a cadeia várias vezes, perdendo apenas uma pequena parte de sua aposta durante cada ataque. Portanto, se quisermos a finalidade económica, uma abordagem simples baseada em comités não funcionará e, à primeira vista, precisamos da plena participação do validador.
Idealmente, gostaríamos de manter a finalidade económica e, ao mesmo tempo, melhorar o status quo em duas áreas:
Complete pedaços em um único slot (idealmente, mantenha ou até mesmo reduza a duração atual de 12 segundos) em vez de 15 minutos
Permitir que os validadores façam stake com 1 ETH (abaixo dos 32 ETH)
O primeiro objetivo tem dois objetivos, ambos os quais podem ser vistos como “alinhar as propriedades do Ethereum com as das cadeias L1 (mais centralizadas) focadas no desempenho”.
Em primeiro lugar, garante que todos os utilizadores do Ethereum beneficiam realmente do nível mais elevado de garantias de segurança alcançado através do mecanismo de finalidade. Hoje, a maioria dos usuários não faz isso porque não está disposta a esperar 15 minutos com a finalização em um único slot; os usuários veem sua transação concluída quase assim que a transação é confirmada; Em segundo lugar, simplifica o protocolo e a infra-estrutura envolvente, caso os utilizadores e aplicações não tenham de se preocupar com a possibilidade de reversão da cadeia (excepto no caso relativamente raro de uma fuga de inactividade).
O segundo objetivo se deve ao desejo de apoiar os apostadores individuais. Pesquisa após pesquisa mostra repetidamente que a principal coisa que impede mais pessoas de apostar sozinhas é o mínimo de 32 ETH. Reduzir o mínimo para 1 ETH resolverá este problema e outras questões se tornarão o fator dominante que limita o staking individual.
Há um desafio: os objetivos de uma finalização mais rápida e de uma fixação mais democratizada entram em conflito com o objetivo de minimizar as despesas gerais. Na verdade, esse é o motivo pelo qual não começamos com finalidade de slot único. No entanto, pesquisas recentes sugerem algumas maneiras possíveis de resolver esse problema.
O que é e como funciona?
A finalidade de slot único envolve o uso de um algoritmo de consenso para finalizar blocos em um slot. Este não é um objetivo difícil em si: muitos algoritmos, como o consenso Tendermint, já fazem isso. Uma propriedade necessária exclusiva do Ethereum que o Tendermint não suporta é o vazamento de inatividade, que permite que a cadeia continue funcionando e eventualmente se recupere mesmo se mais de 1/3 dos validadores ficarem offline. Felizmente, isso foi resolvido: já existem propostas para modificar o consenso no estilo Tendermint para acomodar vazamentos de inatividade.
Proposta líder de finalidade de slot único
A parte mais difícil do problema é descobrir como fazer com que a finalidade de slot único funcione com contagens de validadores muito altas, sem incorrer em sobrecarga extremamente alta do operador do nó. Existem algumas soluções líderes para isso:
Opção 1: Força bruta – trabalhar para um melhor protocolo de agregação de assinaturas, possivelmente usando ZK-SNARK, o que nos permitiria essencialmente processar assinaturas de milhões de validadores por slot.
Horn, um dos projetos propostos para melhores protocolos de agregação
Opção 2: Comitês orbitais — Um novo mecanismo que permite que comitês de médio porte selecionados aleatoriamente sejam responsáveis pela finalização da cadeia, mas de uma forma que preserve as propriedades de custo de ataque que procuramos.
Uma maneira de pensar sobre o Orbit SSF é que ele abre um espaço de compromisso entre duas opções, variando de x=0 (comitê estilo Algorand, sem finalidade econômica) a x=1 (status quo do Ethereum), com algo no meio “Ethereum ainda tem finalidade econômica suficiente para ser muito seguro, mas ao mesmo tempo precisamos apenas de uma amostra aleatória de validadores de tamanho moderado para participar de cada slot para obter vantagens de eficiência.”
A Orbit aproveita a heterogeneidade pré-existente nos tamanhos dos depósitos dos validadores para obter o máximo de finalidade econômica possível, ao mesmo tempo em que atribui uma função aos pequenos validadores. Além disso, a Orbit utiliza uma rotação lenta de comissões para garantir um elevado grau de sobreposição entre quóruns adjacentes, garantindo assim que a sua finalidade económica permanece dentro dos limites da mudança de comissões.
Opção 3: Staking de dois níveis – Um mecanismo onde existem duas classes de stakers, uma com requisitos de depósito mais elevados e outra com requisitos de depósito mais baixos. Apenas níveis de depósitos mais elevados estão diretamente envolvidos no fornecimento de finalidade económica. Existem várias sugestões sobre quais são exatamente os direitos e responsabilidades dos níveis de depósito mais baixos (ver, por exemplo, o posto de staking do Rainbow). As ideias comuns incluem:
O direito de delegar o staking a um staker de nível superior
Alguns stakers aleatórios de baixo nível são obrigados a certificar e finalizar cada bloco
O direito de gerar listas de inclusão
Quais são as conexões com a pesquisa existente?
Caminhos para a finalidade de slot único (2022): https://notes.ethereum.org/@vbuterin/single_slot_finality Caminhos para a finalidade de slot único (2022)
Uma proposta concreta para um protocolo de finalidade de slot único para Ethereum (2023): https://eprint.iacr.org/2023/280 Finalidade de slot único Ethereum
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 Análise adicional sobre mecanismos estilo Orbit
Horn, protocolo de agregação de assinatura (2022): https://ethresear.ch/t/horn-collecting-signatures-for-faster-finality/14219 Horn, protocolo de agregação de assinatura (2022)
Fusão de assinaturas para consenso em grande escala (2023): https://ethresear.ch/t/signature-merging-for-large-scale-consensus/17386?u=asn Fusão de assinaturas para consenso em grande escala (2023)
Protocolo de agregação de assinatura proposto por Khovratovich et al: https://hackmd.io/@7dpNYqjKQGeYC7wMlPxHtQ/BykM3ggu0#/ Protocolo de agregação de assinatura proposto por Khovratovich et al
Agregação de assinaturas baseada em STARK (2022): https://hackmd.io/@vbuterin/stark_gregation Agregação de assinaturas baseada em STARK (2022)
Estaqueamento de arco-íris: https://ethresear.ch/t/unbundling-staking-towards-rainbow-stake/18683 Estaqueamento de arco-íris
O que mais precisa ser feito, que compensações precisam ser feitas?
Existem quatro caminhos principais possíveis para escolher (também podemos seguir um caminho híbrido):
manter o status quo
SSF violenta
Órbita SSF
SSF com dois níveis de piquetagem
(1) significa não fazer nenhum trabalho e deixá-lo como está, mas isso pioraria a experiência de segurança do Ethereum e as propriedades de centralização do staking.
(2) Usar tecnologia avançada para resolver problemas de forma violenta. Para conseguir isso, um grande número de assinaturas (mais de 1 milhão) precisa ser agregado em um tempo muito curto (5 a 10 segundos). Uma maneira de pensar sobre essa abordagem é que ela envolve a minimização da complexidade do sistema, abraçando totalmente a complexidade do encapsulamento.
(3) Evitar "técnicas avançadas" e resolver problemas repensando de forma inteligente as suposições do protocolo: flexibilizámos o requisito de "finalidade económica" para continuarmos a tornar os ataques dispendiosos, mas aceitamos que o custo dos ataques pode ser 10 vezes inferior ao custo actual do ataque (por exemplo, o ataque custou 2,5 mil milhões de dólares em vez de 25 mil milhões de dólares). É geralmente aceite que o Ethereum tem hoje muito mais finalidade económica do que o necessário, e os principais riscos de segurança residem noutro lado, pelo que este é sem dúvida um sacrifício aceitável.
A principal tarefa é verificar se o mecanismo Orbit é seguro e possui as propriedades que desejamos, e então formalizá-lo e implementá-lo totalmente. Além disso, o EIP-7251 (Aumentar o Saldo Máximo Válido) permite a consolidação voluntária do saldo do validador, o que reduz imediatamente a sobrecarga de verificação da cadeia até certo ponto e serve efetivamente como a fase inicial da implementação do Orbit.
(4) Evita a reflexão inteligente e a tecnologia avançada, mas cria um sistema de apostas em dois níveis que ainda corre o risco de centralização. O risco depende em grande parte dos direitos específicos adquiridos em níveis de participação mais baixos. Por exemplo:
Se os stakeholders de nível inferior precisarem delegar os seus direitos de atestado aos stakeholders de nível superior, então a delegação pode ser centralizada, de modo que acabamos com duas camadas de piquetagem altamente centralizadas.
Se uma amostra aleatória de camadas inferiores for necessária para aprovar cada bloco, um invasor poderá gastar uma quantidade muito pequena de ETH para evitar a finalidade.
A camada de prova poderia permanecer centralizada se os intervenientes de nível inferior pudessem apenas gerar listas de inclusão, altura em que um ataque de 51% à camada de prova poderia censurar as listas de inclusão por si só.
Várias estratégias podem ser combinadas, como:
1 + 2): Adicionar Orbit sem finalização de slot único
(1 + 3): Use técnicas de força bruta para reduzir o tamanho mínimo do depósito sem finalização de slot único. A quantidade de polimerização necessária é 64 vezes menor que no caso puro (3), então o problema fica mais fácil.
(2 + 3): Use parâmetros conservadores (por exemplo, comitê validador de 128k em vez de 8k ou 32k) para Orbit SSF e use tecnologia para torná-lo supereficiente.
(1 + 4): Adicionar piquetagem arco-íris sem finalização de slot único
Como ele interage com outras partes do roteiro?
Entre outros benefícios, a finalidade de slot único reduz o risco de certos tipos de ataques MEV multibloco. Além disso, em um mundo de finalidade de slot único, o projeto de separação provador-proponente e outros pipelines de produção de blocos no protocolo exigem um projeto diferente.
O ponto fraco das estratégias de força bruta é que elas tornam mais difícil a redução do slot time.
Eleição de líder secreto único
Que problema estamos tentando resolver?
Hoje, já se sabe com antecedência qual validador irá propor o próximo bloco. Isto cria uma falha de segurança: um invasor pode monitorar a rede, identificar quais validadores correspondem a quais endereços IP e realizar um ataque DoS em cada validador quando o validador estiver prestes a propor um bloqueio.
O que é e como funciona?
A melhor maneira de resolver o problema DoS é ocultar a informação sobre qual validador irá gerar o próximo bloco, pelo menos até que o bloco seja realmente gerado. Observe que isso é fácil se removermos o requisito "único": uma solução é deixar qualquer um criar o próximo bloco, mas exigir que o randao Reveal seja menor que 2 (256) / N. Em média, apenas um validador atende a esse requisito – mas às vezes há dois ou mais, e às vezes há zero. Combinar requisitos de “confidencialidade” com requisitos de “unidade” sempre foi um problema difícil.
O protocolo de eleição de líder secreto único resolve esse problema usando algumas técnicas criptográficas para criar um ID de validador "cego" para cada validador e, em seguida, fornecendo a muitos proponentes a oportunidade de embaralhar o pool de ID cego (semelhante ao método do mixnet). Durante cada slot, um ID cego aleatório é selecionado. Somente o dono do blinded ID pode gerar uma prova válida para propor o bloqueio, mas ninguém mais sabe a qual validador o blinded ID corresponde.
Quais são as conexões com a pesquisa existente?
Artigo de Dan Boneh (2020): https://eprint.iacr.org/2020/025.pdf Artigo de Dan Boneh (2020)
Whisk (proposta concreta para Ethereum, 2022): https://ethresear.ch/t/whisk-a-practical-shuffle-based-ssle-protocol-for-ethereum/11763 Whisk (proposta concreta para Ethereum, 2022)
Etiqueta única de eleição de líder secreto em ethresear.ch: https://ethresear.ch/tag/single-secret-leader-election Etiqueta única de eleição de líder secreto em ethresear.ch
SSLE simplificado usando assinaturas em anel: https://ethresear.ch/t/simplified-ssle/12315 SSLE simplificado usando assinaturas em anel
O que mais precisa ser feito, que compensações precisam ser feitas?
Na verdade, tudo o que resta é encontrar e implementar um protocolo que seja simples o suficiente para que possamos implementá-lo facilmente na rede principal. Valorizamos muito o Ethereum como um protocolo bastante simples e não queremos que a complexidade aumente ainda mais. As implementações SSLE que vimos adicionaram centenas de linhas de código canônico e introduziram novas suposições em criptografia complexa. Encontrar implementações SSLE resistentes a quantum suficientemente eficientes também é um problema em aberto.
O que pode ser o caso é que, uma vez que tomemos a iniciativa e introduzamos mecanismos para provas universais de conhecimento zero no protocolo Ethereum em L1 (por exemplo, árvores de estado, ZK-EVM) por outras razões, a complexidade adicional introduzida pelo SSLE diminuirá. suficiente.
Outra opção é não considerar o SSLE e usar mitigações fora do protocolo (por exemplo, na camada p2p) para resolver problemas de DoS.
Como ele interage com outras partes do roteiro?
Se somarmos o mecanismo de separação provador-proponente (APS), por exemplo. tickets de execução, então a execução de blocos (ou seja, blocos contendo transações Ethereum) não exigirá SSLE, pois podemos contar com construtores de blocos especializados. No entanto, ainda nos beneficiaríamos dos blocos de consenso do SSLE (ou seja, blocos contendo mensagens de protocolo, como atestados, talvez fragmentos contendo listas, etc.).
Confirmação de transação mais rápida
Que problema estamos tentando resolver?
Há valor em reduções adicionais nos tempos de confirmação de transação do Ethereum, de 12 segundos para, por exemplo, 4 segundos. Isso melhorará a experiência do usuário de L1 e Rollups baseados, ao mesmo tempo que tornará o protocolo defi mais eficiente. Também facilitará a descentralização do L2, pois permitirá que uma grande classe de aplicativos L2 funcionem em Rollups Baseados, reduzindo assim a necessidade de L2 construir seu próprio pedido descentralizado baseado em comitê.
O que é e como funciona?
Reduza o tempo do slot, como 8 segundos ou 4 segundos. Isso não significa necessariamente 4 segundos para finalização: a finalização requer essencialmente três rodadas de comunicação, então poderíamos transformar cada rodada de comunicação em um bloco separado, que seria pelo menos provisoriamente confirmado após 4 segundos.
Permitir que os proponentes emitam pré-confirmações durante o processo de slot. Em um caso extremo, um proponente poderia adicionar transações que vê em tempo real ao seu próprio bloco e publicar imediatamente uma mensagem de pré-confirmação para cada transação ("Minha primeira transação foi 0x1234...", "Minha segunda transação é 0×5678 ..."). A situação em que um proponente emite duas confirmações conflitantes pode ser tratada de duas maneiras: (i) cortando o proponente, ou (ii) usando um provador para votar na confirmação anterior.
Quais são as conexões com a pesquisa existente?
Pré-confirmações baseadas: https://ethresear.ch/t/based-preconfirmations/17353
Compromissos do proponente impostos pelo protocolo (PEPC): https://ethresear.ch/t/unbundling-pbs-towards-protocol-enforced-proposer-commitments-pepc/13879 Compromissos do proponente impostos pelo protocolo (PEPC)
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 Períodos escalonados em cadeias paralelas (uma ideia da era de 2018 para alcançar baixa latência)
O que mais precisa ser feito, que compensações precisam ser feitas?
Não está claro se a redução do tempo de slot é prática. Ainda hoje, os interessados em muitas partes do mundo lutam para obter provas com rapidez suficiente. Tentar um intervalo de 4 segundos acarreta o risco de centralização do validador e torna impraticável tornar-se um validador fora de algumas regiões desenvolvidas devido à latência. Especificamente, mudar para intervalos de tempo de 4 segundos requer a redução do limite de latência da rede ("delta") para dois segundos.
A desvantagem do método de pré-confirmação do proponente é que ele melhora muito o tempo de inclusão no caso médio, mas não no pior caso: se o proponente atual estiver funcionando bem, a transação será pré-confirmada em 0,5 segundos em vez de 6 segundos estão incluídos (em média), mas se o proponente atual estiver offline ou não tiver um bom desempenho, você ainda terá que esperar 12 segundos completos antes que o próximo slot seja iniciado e um novo proponente seja atendido.
Além disso, como incentivar a pré-confirmação também é uma questão em aberto. Os proponentes têm um incentivo para maximizar as suas opções durante o maior tempo possível. Se o certificador assinar uma pré-confirmação para pontualidade, então o remetente da transação poderá condicionar uma parte da taxa à pré-confirmação imediata, mas isso representaria um fardo adicional para o certificador e potencialmente tornaria mais difícil para o certificador continuar operando como "tubo mudo" neutro.
Por outro lado, se não tentarmos fazer isso e mantermos o tempo de finalização em 12 segundos (ou mais), o ecossistema dará mais ênfase ao mecanismo de pré-confirmação da L2 e as interações entre L2 levarão mais tempo.
Como ele interage com outras partes do roteiro?
A pré-confirmação baseada no proponente, na verdade, depende de um mecanismo de separação provador-proponente (APS), como tíquetes de execução. Caso contrário, a pressão sobre os validadores regulares para fornecerem pré-confirmações em tempo real poderá ser demasiado concentrada.
O quão curto pode ser o tempo do slot também depende da estrutura do slot, que depende muito da versão APS que implementamos, da lista de inclusão, etc. Algumas estruturas de slots contêm menos rodadas e, portanto, são mais amigáveis para slots curtos, mas têm compensações em outros lugares.
Outras áreas de pesquisa
51% de recuperação de ataque
Freqüentemente, presume-se que no caso de um ataque de 51% (incluindo ataques que não podem ser comprovados criptograficamente, como a censura), a comunidade se unirá para implementar um soft fork minoritário para garantir que os mocinhos ganhem e os bandidos obtenham inatividade vazou ou foi cortada. No entanto, esta dependência excessiva da dimensão social é indiscutivelmente pouco saudável. Podemos tentar reduzir a dependência da camada social, automatizando tanto quanto possível o processo de recuperação.
A automação total não é possível porque, se fosse, seria considerado um algoritmo de consenso tolerante a falhas> 50%, e já conhecemos as limitações (muito estritas) matematicamente prováveis de tais algoritmos. Mas podemos conseguir uma automação parcial: por exemplo, o cliente pode recusar automaticamente a aceitação da cadeia finalizada ou mesmo da cabeça selecionada pelo fork se o cliente tiver visto uma transação longa o suficiente. Um objetivo fundamental é garantir que os bandidos no ataque possam, pelo menos, não vencer de forma rápida e limpa.
Aumentar o limite de quórum
Hoje, se os detentores de 67% do capital apoiarem, o bloco estará finalizado. Alguns acham que isso é muito radical. Em toda a história do Ethereum, ocorreu apenas uma falha definitiva (muito breve). Se esta percentagem aumentar, por exemplo para 80%, então o número de fases de não finalidade adicionadas será relativamente baixo, mas o Ethereum ganhará propriedades de segurança: em particular, muitas das situações mais controversas levarão a uma suspensão temporária da finalidade. Isso parece muito mais saudável do que a vitória imediata do "lado errado", seja quando o lado errado é um invasor ou tem um cliente com bugs.
Isto também responde à pergunta "Qual é o significado de um proponente separado?" Hoje, a maioria dos stakers aposta através de pools de mineração e parece improvável que um único staker receba 51% do ETH apostado. No entanto, se trabalharmos arduamente, parece exequível conseguir que os stakeholders individuais alcancem um quórum para bloquear uma minoria, especialmente se o quórum for de 80% (portanto, é necessário um quórum de apenas 21% para bloquear uma minoria). Enquanto os stakers individuais discordarem de um ataque de 51% (seja por reversão ou revisão de finalidade), tal ataque não alcançará uma "vitória limpa" e os stakers individuais terão um incentivo para ajudar a organizar um soft fork minoritário.
Observe que há uma interação entre o limite de quorum e o mecanismo Orbit: se acabarmos usando o Orbit, então o que exatamente significa “21% dos stakers” será uma questão mais complexa e dependerá em parte da distribuição dos validadores.
resistência quântica
A Metaculus acredita atualmente que, embora com amplas barras de erro, os computadores quânticos podem começar a quebrar a criptografia em algum momento na década de 2030:
Especialistas em computação quântica, como Scott Aaronson, também começaram recentemente a levar mais a sério a possibilidade de os computadores quânticos funcionarem de forma eficaz a médio prazo. Isso tem implicações para todo o roteiro do Ethereum: significa que cada parte do protocolo Ethereum que atualmente depende de curvas elípticas precisará de algum substituto baseado em hash ou outro resistente a quantum. Em particular, isto significa que não podemos assumir que alguma vez poderemos confiar nas propriedades superiores da agregação BLS para lidar com assinaturas de grandes conjuntos de validadores. Isto justifica o conservadorismo das suposições em torno do desempenho do projeto de prova de participação e é uma razão para ser mais proativo no desenvolvimento de alternativas resistentes ao quantum.
