Apoiar a aposta descentralizada através de mais incentivos anticorrelação – Prova de Participação

Nota de conteúdo: pesquisa preliminar. Adoraria ver tentativas de replicação independentes.

Código: https://github.com/ethereum/research/tree/master/correlation_análise

Uma tática para incentivar uma melhor descentralização num protocolo é penalizar correlações. Ou seja, se um ator se comportar mal (inclusive acidentalmente), a penalidade que ele receberá será maior quanto mais outros atores (medido pelo ETH total) se comportarem mal ao mesmo tempo que ele. A teoria é que se você for um único grande ator, quaisquer erros que você cometa teriam maior probabilidade de serem replicados em todas as “identidades” que você controla, mesmo se você dividir suas moedas entre muitas contas nominalmente separadas.

Esta técnica já é empregada na mecânica de redução de Ethereum (e possivelmente de vazamento de inatividade). No entanto, os incentivos extremos que surgem apenas numa situação de ataque altamente excepcional que pode nunca surgir na prática talvez não sejam suficientes para incentivar a descentralização.

Esta postagem propõe estender um tipo semelhante de incentivo anticorrelação para falhas mais “mundanas”, como a falta de um atestadoque quase todos os validadores fazem pelo menos ocasionalmente. A teoria é que os grandes stakers, incluindo indivíduos ricos e pools de staking, irão executar muitos validadores na mesma ligação à Internet ou mesmo no mesmo computador físico, e isto causará falhas correlacionadas desproporcionais. Tais apostadores poderia sempre fazem uma configuração física independente para cada nó, mas se acabarem fazendo isso, isso significaria que eliminamos completamente as economias de escala no piqueteamento.

Verificação de integridade: os erros cometidos por diferentes validadores no mesmo “cluster” são realmente mais propensos a se correlacionarem entre si?

Podemos verificar isso combinando dois conjuntos de dados: (i) dados de atestado de algumas épocas recentes mostrando quais validadores deveriam ter atestado e quais validadores realmente atestaram, durante cada slot, e (ii) mapeamento de dados de IDs de validador para conhecidos publicamente agrupamentos que contêm muitos validadores (por exemplo, “Lido”, “Coinbase”, “Vitalik Buterin”). Você pode encontrar um lixão do primeiro aqui, aqui e aqui, e do último aqui.

Em seguida, executamos um script que calcula o número total de co-falhas: instâncias de dois validadores no mesmo cluster sendo atribuídos para atestar durante o mesmo slot e falhando nesse slot.

Também calculamos co-falhas esperadas: o número de co-falhas que “deveriam ter acontecido” se as falhas fossem totalmente resultado do acaso.

Por exemplo, suponha que existam dez validadores com um cluster de tamanho 4 e os outros independentes, e três validadores falhem: dois dentro desse cluster e um fora dele.

Há uma co-falha aqui: o segundo e o quarto validadores dentro do primeiro cluster. Se todos os quatro validadores nesses clusters tivessem falhado, haveria seis co-falhas, uma para cada seis pares possíveis.

Mas quantos co-fracassos “deveriam ter havido”? Esta é uma questão filosófica complicada. Algumas maneiras de responder:

• Para cada falha, suponha que o número de co-falhas seja igual à taxa de falha nos outros validadores naquele slot vezes o número de validadores naquele cluster e reduza pela metade para compensar a contagem dupla. Para o exemplo acima, isso dá \frac{2}{3}.
• Calcule a taxa de falha global, eleve ao quadrado e multiplique por \frac{n * (n-1)}{2} para cada cluster. Isso dá (\frac{3}{10})^2 * 6 = 0,54.
• Redistribua aleatoriamente as falhas de cada validador em todo o seu histórico.

Cada método não é perfeito. Os dois primeiros métodos não levam em consideração clusters diferentes com configurações de qualidade diferentes. Enquanto isso, o último método não leva em conta as correlações decorrentes de diferentes slots com diferentes dificuldades inerentes: por exemplo, o slot 8103681 tem um número muito grande de atestados que não são incluídos em um único slot, possivelmente porque o bloco foi publicado com atraso incomum.

Veja “10216 ssfumbles” nesta saída python.

Acabei implementando três abordagens: as duas primeiras abordagens acima e uma abordagem mais sofisticada onde comparo “co-falhas reais” com “co-falhas falsas”: falhas em que cada membro do cluster é substituído por um validador (pseudo-)aleatório que tem uma taxa de falha semelhante.

Eu também separo explicitamente se atrapalha e sente falta. Eu defino esses termos da seguinte forma:

• Atrapalhar: quando um validador perde um atestado durante a época atual, mas é atestado corretamente durante a época anterior
• Perder: quando um validador perde um atestado durante a época atual e também perde durante a época anterior

O objetivo é separar os dois fenômenos muito diferentes de (i) problemas de rede durante a operação normal e (ii) ficar off-line ou apresentar falhas de longo prazo.

Também faço esta análise simultaneamente para dois conjuntos de dados: prazo máximo e prazo de slot único. O primeiro conjunto de dados trata um validador como tendo falhado em uma época apenas se um atestado nunca tiver sido incluído. O segundo conjunto de dados trata um validador como tendo falhado se o atestado não for incluído dentro de um único slot.

Aqui estão meus resultados para os dois primeiros métodos de cálculo de co-falhas esperadas. SSfumbles e SSmisses aqui referem-se a fumbles e erros usando o conjunto de dados de slot único.

Para o primeiro método, o Actual linha é diferente, porque um conjunto de dados mais restrito é usado para eficiência:

As colunas “esperados” e “clusters falsos” mostram quantas co-falhas dentro dos clusters “deveriam ter havido”, se os clusters não estivessem correlacionados, com base nas técnicas descritas acima. As colunas “reais” mostram quantas co-falhas realmente ocorreram. De maneira uniforme, vemos fortes evidências de “falhas correlacionadas em excesso” dentro dos clusters: dois validadores no mesmo cluster têm uma probabilidade significativamente maior de perder atestados ao mesmo tempo do que dois validadores em clusters diferentes.

Como podemos aplicar isso às regras de penalidade?

Proponho um espantalho simples: em cada slot, deixe p será o número atual de slots perdidos dividido pela média dos últimos 32 slots. Aquilo é, p(i) = \frac{erros(i)}{\sum_{j=i-32}^{i-1}\ erros(j)}. Limite: p\leftarrow min(p, 4). As penalidades para atestados desse slot devem ser proporcionais p. Aquilo é, a penalidade por não atestar em um slot deve ser proporcional a quantos validadores falham naquele slot em comparação com outros slots recentes.

Este mecanismo tem uma boa propriedade de não ser facilmente atacado: não há um caso em que falhar diminui suas penalidades, e manipular a média o suficiente para ter um impacto exige que você mesmo cometa um grande número de falhas.

Agora, vamos tentar realmente executá-lo. Aqui estão as penalidades totais para clusters grandes, clusters médios, clusters pequenos e todos os validadores (incluindo não clusterizados) para quatro esquemas de penalidades:

• basic: Penalize um ponto por falha (ou seja, semelhante ao status quo)
• basic_ss: o mesmo, mas exigindo inclusão de slot único para não contar como falha
• excess: penalizar p pontos com p calculado como acima
• excess_ss: penalizar p pontos com p calculado como acima, exigindo a inclusão de um único slot para não contar como uma falha

Aqui está o resultado:

                   basic          basic_ss       excess         excess_ss    
big                0.69           2.06           2.73           7.96           
medium             0.61           3.00           2.42           11.54         
small              0.98           2.41           3.81           8.77           
all                0.90           2.44           3.54           9.30

Com os esquemas “básicos”, o grande tem uma vantagem de aproximadamente 1,4x sobre o pequeno (~1,2x no conjunto de dados de slot único). Com os esquemas de “excesso”, isso cai para ~1,3x (~1,1x no conjunto de dados de slot único). Com várias outras iterações disso, usando conjuntos de dados ligeiramente diferentes, o esquema de penalidades por excesso reduz uniformemente a vantagem do “grande” sobre “o pequeno”.

O que está acontecendo?

O número de falhas por slot é pequeno: geralmente fica na casa das dezenas. Isso é muito menor do que qualquer “grande apostador”. Na verdade, é menor que o número de validadores que um grande staker teria ativo em um único slot (ou seja, 1/32 do seu estoque total). Se um grande staker executar muitos nós no mesmo computador físico ou conexão à Internet, qualquer falha afetará plausivelmente todos os seus validadores.

O que isso significa é: quando um validador grande apresenta uma falha na inclusão de atestado, ele sozinho move a taxa de falha do slot atual, o que, por sua vez, aumenta sua penalidade. Validadores pequenos não fazem isso.

Em princípio, um grande apostador pode contornar esse esquema de penalidades colocando cada validador em uma conexão de Internet separada. Mas isto sacrifica a vantagem das economias de escala que um grande interveniente tem ao poder reutilizar a mesma infra-estrutura física.

Tópicos para análise posterior

• Encontre outras estratégias para confirmar o tamanho desse efeito onde os validadores no mesmo cluster têm probabilidade incomum de ter falhas de atestado ao mesmo tempo
• Tente encontrar o esquema de recompensa/penalidade ideal (mas ainda simples, para não se ajustar demais e não ser explorável) para minimizar a vantagem do grande validador médio sobre os pequenos validadores.
• Tente provar propriedades de segurança sobre esta classe de esquemas de incentivos, idealmente identifique uma “região de espaço de design” dentro da qual os riscos de ataques estranhos (por exemplo, ficar off-line estrategicamente em horários específicos para manipular a média) são caros demais para valer a pena
• Agrupar por geografia. Isto poderia determinar se este mecanismo também cria ou não um incentivo à descentralização geográfica.
• Cluster por software cliente (execução e beacon). Isto poderia determinar se este mecanismo também cria ou não um incentivo à utilização de clientes minoritários.

Mini-FAQ

P: Mas isso não levaria apenas a staking pools descentralizando arquitetonicamente sua infraestrutura sem se descentralizarem politicamente, e não é com este último que nos importamos mais neste momento?

UM: Se o fizerem, isso aumentará o custo de suas operações, tornando o staking solo relativamente mais competitivo. O objetivo não é forçar sozinho a aposta individual, o objetivo é tornar a parte económica dos incentivos mais equilibrada. A descentralização política parece muito difícil ou impossível de incentivar no protocolo; para isso, penso que teremos apenas de contar com a pressão social, lançamentos aéreos do tipo starknet, etc. Mas se os incentivos económicos puderem ser ajustados para favorecer a descentralização arquitectónica, isso facilitará o lançamento de projectos politicamente descentralizados (que não podem evitar ser arquitectonicamente descentralizados).

P: Isso não prejudicaria mais os “stakers de médio porte” (indivíduos ricos que não são grandes exchanges/pools) e os encorajaria a migrar para pools?

UM: Na tabela acima, a seção “pequena” refere-se a stakers com 10-300 validadores, ou seja. 320-9600 ETH. Isso inclui a maioria das pessoas ricas. E como podemos ver, esses stakers sofrem penalidades significativamente mais elevadas do que os pools atuais, e a simulação mostra como o esquema de recompensa ajustado proposto equalizaria as coisas precisamente entre esses validadores e os realmente grandes. Matematicamente falando, alguém com 100 slots de validador teria apenas 3 por slot, portanto não afetaria muito o fator de penalidade de uma rodada; apenas validadores que vão muito acima disso seriam.

P: Pós-MAXEB, os grandes stakeholders não conseguirão contornar isso consolidando todos os seus ETH em um validador?

UM: A fórmula de penalidade proporcional contaria o valor total de ETH, não o número de IDs de validador, portanto, 4.000 ETH apostados que agissem da mesma maneira seriam tratados da mesma forma se fossem divididos entre 1 validador ou 2 ou 125.

P: Adicionar ainda mais incentivos para estar online não criará mais pressão para otimizar e, portanto, centralizar, independentemente dos detalhes?

UM:Os parâmetros podem ser definidos para que, em média, o tamanho do incentivo para estar online seja o mesmo que é hoje.