Título original: “Manter 8192 assinaturas por slot pós-SSF: como e porquê”
Artigo original de Vitalik Buterin, ETH research
Compilação original: Luccy, BlockBeats
*Nota do editor: SSF (Single Slot Finality) significa Single Slot Finality, que fornece uma maneira de reduzir significativamente a latência do Ethereum. No Mecanismo de Consenso de Blockchain, finalidade significa que uma transação ou Bloco se torna irrevogável, garantindo que não possa ser adulterada ou revertida. Alcançar a finalidade é essencial para a confiança e segurança dos sistemas de Descentralização, pois elimina o risco de gastos duplos e outras atividades maliciosas. *
*O SSF sugere que, no Mecanismo de Consenso Blockchain, um único intervalo de tempo ou unidade de tempo pode ser considerado “final”. Ao contrário do EthereumConsensus original, ele permite que todos os validadores participem do reconhecimento ou assinatura de slots, reduzindo o tempo de confirmação da transação e melhorando a experiência geral do usuário. *
A pesquisa ETH de Vitalik “devolve” explora por que é necessário que os validadores participantes tenham duas assinaturas por slot após o SSF, ou seja, para alcançar 8192 assinaturas, e apresenta 3 hipóteses sobre como atingir esse objetivo, ou seja, staking completo, staking de duas camadas e participação rotativa, analisa como lidar com o número de assinaturas por slot de forma mais eficiente, mantendo a segurança do protocolo, e discute suas vantagens e desvantagens e o impacto no protocolo e nos usuários. BlockBeats compilou o texto original da seguinte forma:
Uma grande diferença entre o Ethereum e a maioria dos outros sistemas PoS (com finalidade) é que o Ethereum se esforça para suportar um número muito grande de validadores: atualmente temos 895.000 validadores, o que a análise da lei da Zipf mostra ser equivalente a dezenas de milhares de indivíduos ou entidades independentes. O objetivo é apoiar a Descentralização, permitindo que pessoas comuns participem da estaca sem exigir que todos abram mão de sua capacidade de agir e entreguem o controle a um dos poucos grupos de estaca.
No entanto, essa abordagem requer que a cadeia Ethereum processe um grande número de assinaturas por slot (cerca de 28.000 hoje; 1.790.000 após SSF), o que é uma carga muito alta. Para suportar esta carga, é necessário fazer alguns sacrifícios técnicos:
- Requer um mecanismo complexo de propagação de provas onde as provas são divididas em várias sub-redes, operações de assinatura BLS super-otimizadas para verificar essas assinaturas e assim por diante.
- Atualmente, não temos uma alternativa clara e eficiente à resistência quântica.
- Correções de seleção de bifurcação, como mesclagem de visualização, são tornadas mais complicadas pela incapacidade de extrair assinaturas individuais.
- O processamento SNARK é difícil para tantas assinaturas. Helios precisa ser executado em uma assinatura extra especializada, chamada de assinatura de comitê síncrono.
- Requer três sub-slots dentro de um slot em vez de dois, o que aumenta o tempo mínimo seguro do slot.
Um sistema de agregação de assinaturas pode parecer razoável à primeira vista, mas na realidade cria uma complexidade sistémica que permeia todo o sistema.
Além disso, nem sequer atingiu os seus objetivos. O requisito mínimo para a aposta ainda é de 32 ETH, o que está fora do alcance de muitas pessoas. Do ponto de vista da análise lógica, o objetivo de um sistema que permita que todos assinem todos os slots a longo prazo não parece viável para realmente fornecer staking para pessoas comuns: se o Ethereum tem 500 milhões de usuários, 10% dos quais participam do staking, isso significa 100 milhões de assinaturas por slot. Do ponto de vista da teoria da informação, o processamento de penalidades neste projeto requer pelo menos 12,5 MB de espaço livre de dados por slot, aproximadamente equivalente ao objetivo de fragmentação total. Pode ser possível, mas exigir que a própria estaca dependa da amostragem de disponibilidade de dados é um grande ganho de complexidade. E mesmo assim, apenas cerca de 0,6% da população global participa do staking, e isso ainda não começou a envolver o problema computacional de verificar tantas assinaturas.
Então, em vez de confiar na criptografia para criar balas mágicas (ou à prova de balas mágicas) para alcançar um número cada vez maior de assinaturas por slot, sugiro uma mudança filosófica: primeiro abandone essas expectativas. Isso expandiria muito o espaço de design do PoS e permitiria uma grande simplificação técnica, tornando-o mais seguro, permitindo que Helios SNARKs diretamente no Consenso Ethereum, e resolveria o problema da resistência quântica tornando viável até mesmo um esquema de assinatura desinteressante, mas de longa data, como o Winternitz.
Por que não “Usar apenas comitês”?
Muitos não-EthereumBlockchain que enfrentam esse problema exato adotam uma abordagem baseada em comitê para a segurança. Durante cada slot, eles selecionam aleatoriamente N validadores (por exemplo, N ≈ 1000) que são responsáveis por confirmar o slot. Vale a pena recordar por que razão esta abordagem não é suficiente, uma vez que não prevê a responsabilização.
Para entender o porquê, digamos que 51% dos ataques ocorreram. Pode ser um ataque de reversão terminal ou um ataque de censura. Para realizar o ataque, você ainda precisa que o ator econômico controle a maioria da estaca para concordar com o ataque, ou seja, executar o software envolvido no ataque e participar do ataque com todos os validadores que são eleitos para o comitê. A amostragem matematicamente aleatória garante isso. No entanto, as penalidades que receberam por isso foram mínimas, já que a maioria dos validadores que concordaram com o ataque não foram eleitos para o comitê e, portanto, não foram vistos.
Atualmente, o Ethereum faz exatamente o oposto. Se ocorrer um ataque de 51%, a maioria de toda a coleção do validador de ataque terá seu depósito cortado. O custo atual do ataque é de cerca de 9 milhões de ETH (cerca de US$ 20 bilhões), e supõe-se que a interrupção da sincronização da rede seja realizada da maneira mais favorável para o invasor.
Acho que é um custo alto, mas é um preço muito alto a pagar, e podemos fazer alguns sacrifícios nesta questão. Mesmo um custo de ataque de 1-2 milhões de ETH é perfeitamente suficiente. Além disso, o principal risco de centralização que existe atualmente no Ethereum se reflete em um lugar completamente diferente: se o valor mínimo de depósito for reduzido para perto de zero, o poder dos pools de staking em grande escala não será muito reduzido.
É por isso que estou defendendo uma solução intermediária: fazer alguns sacrifícios nas responsabilidades do validador, mas ainda manter uma alta quantidade total de ETH cortante e, em troca, podemos desfrutar da maioria dos benefícios de um conjunto menor de validadores.
O que acontece se houver 8192 assinaturas por slot no SSF?
Assumindo um protocolo de consenso tradicional de duas rodadas (como o protocolo usado pela Tendermint e o protocolo que o SSF inevitavelmente usa), cada validador participante precisa de duas assinaturas por slot. Temos de abordar esta realidade, e vejo que existem três formas principais de resolver este problema.
Método 1: Adotar totalmente os pools de staking de descentralização
O Python Zen contém uma frase muito crucial:
Deve haver uma - e de preferência apenas uma - maneira óbvia de fazê-lo. ）
O Ethereum está atualmente violando essa regra quando se trata de tornar o staking igual, pois estamos implementando simultaneamente duas estratégias diferentes para atingir esse objetivo: (i) staking independente em pequena escala e (ii) pools de staking de descentralização usando tecnologia de validador distribuído (DVT). Pelas razões acima, (i) apenas alguns stakers individuais podem ser suportados, e sempre haverá muitas pessoas cujo valor mínimo de depósito é muito grande. No entanto, o Ethereum está pagando um custo de carga técnica muito alto para suportar (i).
Uma solução possível é desistir (i) e ir com tudo (ii). Podemos aumentar o valor mínimo do depósito para 4096 ETH e definir o limite total do validador para 4096 (cerca de 16,7 milhões de ETH). Espera-se que os stakers de pequena escala se juntem ao pool de TVP: fornecendo capital ou tornando-se Operadores de Nós. Para evitar abusos por parte de atacantes, a função de Operador de Nó precisa ser limitada pelo limite de prestígio de alguma forma, e os pools competirão oferecendo diferentes opções nesse sentido. A provisão de capital será sem permissão.
Podemos tornar a aposta neste modelo mais “tolerante” estabelecendo um limite de penalização (por exemplo, 1/8 do depósito total fornecido). Isso permitirá menos confiança nos operadores de nós, embora valha a pena tratar com cautela devido aos problemas delineados.
Método 2: Duas camadas de estaca
Criamos duas camadas de stakers: uma camada “pesada” que requer 4096 ETH para participar da confirmação do estado final, e uma camada “leve” sem requisitos mínimos (sem atrasos de depósito e retirada, sem vulnerabilidades de corte), adicionando uma segunda camada de segurança. Para que um estado final de bloco seja confirmado, é necessária uma confirmação de estado final de camada pesada e pelo menos 50% da camada leve de provas de validação de luz on-line.
Essa heterogeneidade é benéfica para a censura e a resistência ao ataque, pois tanto as camadas pesadas quanto as leves precisam ser corrompidas para que um ataque seja bem-sucedido. Se uma camada estiver corrompida e a outra não, a cadeia irá parar, e se a camada pesada estiver corrompida, ela pode ser punida.
Outro benefício disso é que a camada light pode conter ETH que também é usada como garantia no aplicativo. A principal desvantagem é que a aposta se torna menos igualitária ao estabelecer uma divisão entre as partes interessadas de pequena e grande escala.
Método 3: Participação rotativa (ou seja, comité, mas responsabilização)
Adotamos uma abordagem semelhante ao design do supercomitê proposto aqui: para cada slot, selecionamos 4096 validadores atualmente ativos e ajustamos cuidadosamente o conjunto em cada slot para que ainda tenhamos segurança.
No entanto, fizemos algumas escolhas de parâmetros diferentes dentro deste quadro, a fim de obter “valor para o dinheiro” nele. Em particular, permitimos que os validadores participem com saldos arbitrariamente altos e, se os validadores tiverem mais de uma certa quantidade de ETH (que teria que ser flutuante), eles participam de comitês em cada slot. Se um validador tem N<M ETH, então ele tem uma probabilidade de N/M em qualquer slot para participar do comitê.
Aqui temos uma alavanca interessante para dissociar o “peso” no propósito do incentivo do “peso” no propósito do Consenso: a recompensa para cada validador no comitê deve ser a mesma (pelo menos para validadores que usam ≤M ETH) para manter a recompensa média proporcional ao saldo, mas ainda podemos calcular os pesos do validador de Consenso no comitê ponderando ETH. Isso garante que a quantidade de ETH necessária para quebrar a finalidade seja igual a mais de 1/3 do ETH total no comitê.
Uma análise aproximada da lei de Zipf calcula essa quantidade de ETH da seguinte forma:
- Em cada nível quadrático do saldo total, o número de validadores é inversamente proporcional a esse nível de equilíbrio, e o saldo total desses validadores será o mesmo.
- Como resultado, o comitê terá uma quantidade igual de ETH de cada nível de equilíbrio participante, exceto aqueles que excederem a barreira M, onde os validadores estão sempre no comitê.
Nota: Para mostrar os dados calculados com mais clareza, os próximos passos serão capturas de tela
A principal desvantagem desta abordagem é um ligeiro aumento na complexidade de selecionar aleatoriamente validadores no protocolo para que possamos obter segurança de consenso em caso de mudanças no comitê.
A principal vantagem é que ele mantém a participação independente em uma forma reconhecível, mantém um sistema de classe única e até permite que o valor mínimo do depósito seja reduzido para um nível muito baixo (por exemplo, 1 ETH).
Conclusão
Se decidirmos ficar com 8192 assinaturas após o protocolo SSF, isso tornará o trabalho muito mais fácil para implementadores de tecnologia e construtores de infraestrutura lateral, como clientes leves. Os clientes de consenso podem ser executados mais facilmente por qualquer pessoa, e os usuários, entusiastas de staking e outros podem trabalhar imediatamente nessa suposição. A carga futura do protocolo Ethereum não é mais desconhecida: o futuro pode ser impulsionado por um hard fork, mas apenas se os desenvolvedores estiverem confiantes de que a tecnologia melhorou o suficiente para lidar com mais assinaturas por slot no mesmo nível de facilidade.
O resto do trabalho será decidir qual dos três métodos queremos adotar, ou talvez uma abordagem completamente diferente. Será uma questão de quais compensações estamos confortáveis, especificamente como lidamos com questões relacionadas, como o staking líquido, que pode ser resolvido separadamente dos problemas técnicos que agora são muito mais fáceis.
Link para o artigo original
