Isto facilitará a vida dos implementadores de tecnologia, bem como dos construtores de infraestrutura de suporte, como clientes leves.
Escrito por: Vitalik Buterin, ethresearch
Compilado por: Songxue, Golden Finance
A principal diferença entre o Ethereum e a maioria dos outros sistemas de prova de aposta (finalidade) é que o Ethereum tenta suportar um grande número de objetos validadores: atualmente temos 895.000 objetos validadores, e a simples análise da lei de Zipf mostra que isso corresponde a dezenas de objetos validadores. milhares de objetos validadores são indivíduos/entidades únicos. O objetivo disto é apoiar a descentralização e até mesmo permitir que indivíduos comuns participem na aposta sem exigir que cada pessoa desista da sua agência e dê o controlo a um de um punhado de grupos de aposta.
No entanto, esta abordagem exige 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 elevada. Suportar esta carga requer sacrifícios técnicos significativos:
- Isso requer um mecanismo complexo de propagação de prova envolvendo a divisão da prova em várias sub-redes, exigindo hiperotimização das operações de assinatura BLS para verificar essas assinaturas, etc.
- Não temos uma alternativa clara que seja suficientemente eficiente para ser resistente ao quantum.
- Correções de seleção bifurcada, como mesclagem de visualizações, tornam-se mais complexas porque assinaturas individuais não podem ser extraídas.
- SNARKing assinaturas é difícil devido ao seu grande número. O Helios precisa operar com uma assinatura adicional dedicada, chamada assinatura do comitê de sincronização.
- Aumenta o intervalo de tempo mínimo seguro, exigindo três intervalos de subtempo em um intervalo de tempo em vez de dois.
O sistema de agregação de assinaturas pode parecer razoável à primeira vista, mas na verdade cria uma complexidade sistêmica que permeia todos os aspectos.
Além do mais, nem sequer cumpre o seu propósito. O requisito mínimo para piquetagem ainda é de 32 ETH, o que está fora do alcance de muitos. Apenas a partir de uma análise lógica, no longo prazo, parece inviável para um sistema onde todos se inscrevem para realmente fornecer staking para pessoas comuns: se Ethereum tem 500 milhões de usuários, e 10% deles fazem promessas, então isso significa que existem 100 milhões assinaturas por slot. Em termos da teoria da informação, os cortes de processamento neste design requerem pelo menos 12,5 MB de espaço livre de dados por slot, aproximadamente tanto quanto o objetivo de daksharding completo (!!!). Talvez seja factível, mas exigir que o piqueteamento em si dependa da amostragem de disponibilidade de dados traria um grande ganho de complexidade - mesmo que isso represente apenas cerca de 0,6% da piquetagem da população mundial, e isso nem sequer começa a entrar nos problemas computacionais de verificação tantas assinaturas.
Portanto, em vez de confiar nos criptógrafos para criar uma bala mágica (ou uma armadura mágica) que torne possível ter um número cada vez maior de assinaturas em cada intervalo de tempo, sugiro que façamos uma mudança filosófica: desistir de tais expectativas no primeiro lugar . Isso expandiria muito o espaço de design de PoS e permitiria muita simplificação técnica, tornando-o mais seguro, permitindo que Helios fizesse SNARK diretamente no consenso Ethereum e criando esquemas de assinatura chatos e de longa data, como Winternitz. resolver o problema da resistência quântica.
Por que não “apenas usar comitê”?
Muitos blockchains não-Ethereum que enfrentam exatamente esse problema usam uma abordagem de segurança baseada em comitês. Em cada intervalo de tempo, eles selecionam aleatoriamente N validadores (por exemplo, N é aproximadamente igual a 1000), e esses validadores são responsáveis por completar esse intervalo de tempo. Vale a pena lembrar por que esta abordagem é insuficiente: falta-lhe responsabilidade.
Para entender por quê, imagine um ataque de 51%. Este poderia ser um ataque de reversão final ou um ataque de censura. Para lançar um ataque, o ator económico que controla a maior parte da participação ainda precisa de concordar em realizar o ataque, ou seja, executar o software que participa no ataque, juntamente com todos os validadores que são eleitos para o comité. A matemática da amostragem aleatória garante isso. No entanto, a penalidade que suportam por tal ataque é pequena porque a maioria dos validadores que concordam com o ataque acabam não sendo vistos porque não foram eleitos para o comitê.
Atualmente, Ethereum vai ao extremo oposto. No caso de um ataque de 51%, a maioria de todo o conjunto de validadores de ataque terá sua aposta reduzida. O custo atual do ataque é de aproximadamente 9 milhões de ETH (aproximadamente US$ 20 bilhões), e isso pressupõe que a sincronização da rede seja interrompida de uma maneira que maximize o benefício do invasor.
Penso que é um custo elevado, e é um custo demasiado elevado, e podemos fazer alguns sacrifícios nesta questão. Mesmo que o custo do ataque seja de 1 a 2 milhões de ETH, é completamente suficiente. Além disso, o principal risco de centralização que existe atualmente para o Ethereum reside num lugar completamente diferente: se o montante mínimo de aposta for reduzido para perto de zero, a diferença na força dos pools de aposta em grande escala não será grande.
É por isso que defendo uma solução modesta: fazer alguns sacrifícios na responsabilidade do validador, mas ainda manter a quantidade total de ETH cortável bastante alta e, em troca, isso nos dá um conjunto de validadores menor, com a maior parte dos benefícios.
Como seriam 8.192 assinaturas por intervalo de tempo no SSF?
Assumindo um protocolo tradicional de consenso de duas rodadas (semelhante ao usado pelo Tendermint, e inevitavelmente usado pela SSF), cada validador participante requer duas assinaturas por intervalo de tempo. Precisamos contornar essa realidade. Vejo três maneiras principais de fazer isso.
Método 1: Aposte tudo no pool de promessas descentralizadas
Python tem um ditado muito importante:
Deve haver uma - de preferência apenas uma - maneira óbvia de fazer isso.
Em relação à questão da equalização de staking, o Ethereum atualmente viola esta regra porque implementamos simultaneamente duas estratégias diferentes para atingir esse objetivo: (i) staking individual em pequena escala e (ii) usando pool de staking descentralizado de tecnologia de validação distribuída (DVT). Pelas razões acima expostas, (i) apenas um subconjunto de participantes individuais pode ser apoiado; sempre haverá muitas pessoas cujo depósito mínimo é muito grande. No entanto, a Ethereum está pagando um custo técnico muito alto para apoiar (i).
Uma solução possível é abandonar (i) e apostar tudo em (ii). Podemos aumentar o valor mínimo de aposta para 4.096 ETH e definir um limite total de 4.096 validadores (aproximadamente 16,7 milhões de ETH). Espera-se que pequenos participantes se juntem ao pool DVT: fornecendo fundos ou tornando-se operadores de nós. Para evitar abusos por parte dos invasores, a função do operador do nó precisa ser limitada de alguma forma pela reputação, e os pools competirão entre si, oferecendo diferentes opções nesse sentido. O financiamento não terá permissão.
Podemos tornar a aposta colectiva neste modelo mais “clemente”, limitando as sanções, por exemplo. a 1/8 do penhor total fornecido. Isto reduzirá a confiança nos operadores dos nós, embora valha a pena abordar com cautela devido aos problemas descritos aqui.
Método 2: promessa de dois níveis
Criamos dois níveis de stakers: um nível “pesado”, exigindo 4.096 ETH, para participar da finalização, e um nível “leve”, que não tem requisitos mínimos de staking (também sem atrasos em depósitos e saques, e sem risco de redução), que adiciona outra camada de segurança. Para que um bloco seja final, tanto a camada pesada precisa finalizá-lo quanto a camada leve precisa de >= 50% de validadores leves online para atestar isso.
Esta heterogeneidade é benéfica para a resistência à censura e ao ataque, uma vez que tanto as camadas pesadas como as leves precisam de ser corrompidas para que um ataque seja bem sucedido. Se uma camada estiver corrompida e outra não, a cadeia irá parar; se uma camada pesada estiver corrompida, ela poderá ser punida.
Outro benefício dessa abordagem é que a camada leve pode incluir ETH, que também é usado como garantia no aplicativo. A principal desvantagem é que torna a aposta menos igual ao estabelecer uma divisão entre pequenos e grandes apostadores.
Método 3: participação alternada (ou seja, comitê, mas responsável)
A abordagem que adotamos é semelhante ao design do supercomitê proposto aqui: para cada intervalo de tempo, selecionamos 4.096 validadores atualmente ativos e ajustamos cuidadosamente esse conjunto durante cada intervalo de tempo para garantir que permaneçamos seguros.
No entanto, fizemos algumas escolhas de parâmetros diferentes para obter o “benefício máximo” dentro desta estrutura. Em particular, permitimos que os validadores participem com saldos arbitrariamente elevados, e se um validador possuir mais do que uma certa quantia M de ETH (que deve ser flutuante), então eles participam do comitê a cada época. Se o verificador tiver N <M ETH，那么他们有 N/M 在任何给定时间段内进入委员会的概率。
Uma alavanca interessante que temos aqui é dissociar o “peso” para fins de incentivo do “peso” para fins de consenso: a recompensa para cada validador dentro do comitê deve ser a mesma (pelo menos para validadores com ≤M ETH), para manter a recompensa média proporcional. Ainda podemos realizar uma contagem consensual dos validadores no comitê usando ETH como peso. Isso garante que a quebra da finalidade exija uma quantidade de ETH igual a mais de um terço da quantidade total de ETH no comitê.
A análise da lei de Zipf calculará a 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 saldo, e o saldo total desses validadores será o mesmo.
Portanto, o comitê terá uma quantidade igual de ETH participando de todos os níveis de equilíbrio, exceto níveis acima da barreira M (os validadores estão sempre no comitê).
Portanto, temos nível Log2(M) para cada K validadores no nível acima, e K+K/2+…=2K validadores de nível acima. Portanto, K=4096/Log2(M)+2.
O maior validador terá M*k ETH. Podemos trabalhar de trás para frente: se o maior validador tiver 2^18=262144 ETH, isso significa (aproximadamente) M = 1024 ek = 256.
O valor total de ETH prometido é:
Todos os direitos e interesses dos 512 principais validadores (2^18*1+2^17*2+……+2^10*2^8=2359296)
Além de apostas menores de amostragem aleatória (2^8*(2^9+2^8+2^7…) é aproximadamente igual a 2^8*2^10=2^18)
Ganhamos um total de 2621440 ETH, ou seja, o custo do ataque foi de aproximadamente 900 mil ETH.
A principal desvantagem desta abordagem é que ela introduz um pouco mais de complexidade no protocolo para selecionar validadores aleatoriamente de uma forma que nos permite ainda alcançar a segurança do consenso quando o comitê muda.
A sua principal vantagem é que mantém uma forma reconhecível de aposta independente, mantém um sistema único e ainda permite que o montante mínimo de aposta seja reduzido para níveis muito baixos (por exemplo, 1 ETH).
Resumir
Se determinarmos isso por trás do protocolo SSF, queremos ficar com 8.192 assinaturas, o que facilitará a vida dos implementadores técnicos, bem como dos construtores de infraestrutura de suporte, como clientes leves. Torna-se mais fácil para qualquer pessoa administrar um cliente de consenso, e usuários, entusiastas de staking e outros podem trabalhar imediatamente com base nessa suposição. A carga futura do protocolo Ethereum não é mais desconhecida: ele poderia ser melhorado no futuro através de hard forks, mas somente se os desenvolvedores estiverem convencidos de que a tecnologia melhorou o suficiente para ser capaz de lidar com mais assinaturas por intervalo de tempo com a mesma facilidade.
O resto será decidir qual das três abordagens acima queremos adotar, ou talvez uma abordagem totalmente diferente. Será uma questão sobre quais os compromissos com os quais nos sentimos confortáveis, especialmente como resolvemos os problemas envolvidos, como o staking de liquidez, que provavelmente pode ser resolvido separadamente das questões técnicas que estão a tornar-se mais fáceis agora.
