Regra de confirmação para Ethereum PoS – Consenso

Esta postagem está aberta para discussão sobre. a seguinte regra de confirmação rápida para prova de aposta Ethereum:

Este trabalho foi realizado em conjunto com Francesco D’Amato @fradamt, Roberto Saltini @saltiniroberto, Luca Zanolini @luca_zanolini e Chenyi Zhang.

Regra de confirmação

Suposições:

• A partir do slot atual, os votos emitidos pelos validadores honestos em um slot são recebidos por todos os validadores até o final desse slot, ou seja, a rede é síncrona com a latência < 8 seconds.
• Esta proposta de mudança no protocolo Ethereum:
  • Se j é o bloco de ponto de verificação justificado mais alto e a época atual é eentão permita uma ramificação com bloco folha b se o último posto de controle justificado no pós-estado de b é ou jou de uma época \ge e-2

Notação:

• n é o slot atual e e é a época atual.
• b está a um quarteirão da época atual e.
• Há S Votos FFG da época e em apoio de c.
• W_f é o peso dos validadores que ainda não votaram na época ee W_t é o peso total de todos os validadores.
• O adversário controla \beta < \frac{1}{3}^{\textrm{rd}} fração do conjunto de validadores.
• O adversário está disposto a suportar um corte de \alfa (\leq\beta) fração do conjunto de validadores.

Uma breve descrição da regra (consulte confirm-rule-draft.pdf (396,2 KB) ou postagem do blog para obter explicação):

• p_{b}^n = \frac{\textrm{suporte honesto ao bloco } b}{\textrm{peso honesto total}} de validadores em comitês de b\textrm{.parent.slot} + 1 até n.
• \textrm{isLMDConfirmado}(b, n) é definido como p_{b’}^n > \frac{1}{2(1-\beta)} para todos b’ na cadeia de b.
• \textrm{está confirmado}(b,n) se:
  • o último posto de controle justificado no pós-estado de b é da época e-1e
  • \textrm{isLMDConfirmado}(b,n)e
  • (S – \textrm{min}(S, \alpha W_t, \beta (W_t – W_f))) + (1-\beta)W_f \ge \frac{2}{3}W_t.

Se \textrm{está confirmado}(b,n)então b é dito ser confirmado e permanecerá na cadeia canônica.

Desde p_b^n não pode ser observado, definimos uma prática indicador de segurança q_b^n para determinar se p_b^n está na faixa apropriada:

• q_{b}^n = \frac{\textrm{suporte para bloco } b}{\textrm{peso total}} dos comitês no slot b\textrm{.parent.slot} + 1 até o slot n
• q_{b’}^n > \frac{1}{2} \left(1+\frac{\textrm{proponente aumenta o peso}}{\textrm{peso total honesto}}\right) + \beta para todos b’ na cadeia de b implica \textrm{isLMDConfirmado}(b, n)

Desempenho

Em condições ideais, a regra confirmaria um bloqueio imediatamente após o término do seu slot.
Sob condições típicas da rede principal, esperamos que a regra confirme a maioria dos bloqueios dentro de 3 a 4 slots (menos de 1 minuto).

Observamos os seguintes valores para q (gráfico gerado usando este protótipo):

A vaga atual é 6337565e o último bloco confirmado está no slot 6337564.

Trabalho Anterior

Altere para “peso total do slot(b’.parent)+1 para n”

Eu encontrei uma maneira muito fácil de atrasar o tempo de confirmação para sempre.

Primeiro, descrevo a maneira de atrasar o tempo de confirmação de um slot para uma época.

Na função isLMDconfirmed especificado nas especificações, a confirmação de um bloco requer que seus últimos 32 ancestrais também sejam confirmados por LMD.

Porém, o adversário pode atrasar a liberação de um bloco para impedir sua confirmação. Em particular, se um bloco for liberado em 2/3 do slot, quase nenhum atestado o suporta. Isso faz com que o bloqueio não possa ser confirmado. Portanto, os próximos 32 blocos com o bloco atrasado como ancestral não podem ser confirmados.

Como resultado, a estratégia para atrasar o tempo de confirmação para sempre é atrasar um bloco durante cada época.

Se quase nenhum atestado suporta o bloco, o bloco não pode ser reorganizado trivialmente pelo próximo proponente usando o recurso de reorganização tardia do bloco?

A resposta é sim, eu acho. Porém, o proponente do bloco pode liberar o bloco entre 4s a 4,5s após o início do slot, para que ele não seja reorganizado e também não seja confirmado.

Se você liberar um bloco no segundo 4s a 4,5s, a probabilidade desse bloco ser reorganizado é muito alta. Sem fazer qualquer análise sobre isso, eu diria que é tão alta quanto a participação de mercado do prisma e do farol, já que ambos suportam reorganizações honestas.

Acho que o tempo de lançamento não é uma questão vital.

Acredito que se o proponente do bloco liberar seu bloco logo antes dos validadores liberarem seus atestados (por exemplo, em 3,9 segundos), há uma probabilidade de uma condição em que pelo menos 20% e no máximo 50% dos validadores recebam o bloco antes de atestar. Acredito que esse tempo de lançamento pode ser medido.

Mesmo a determinação precisa do tempo de lançamento pode ser um desafio, um adversário que detenha uma participação de 20% poderia atestar o seu bloqueio atrasado para evitar que seja reorganizado por validadores honestos.

Portanto, considero altamente provável que tal cenário possa ocorrer.

Isso causa apenas uma pequena lentidão na regra de confirmação. Se o bloco permanecer na cadeia canônica, ele continuará acumulando peso e eventualmente será confirmado, independentemente do peso que acumulou em seu próprio slot: à medida que mais slots e mais votos se acumulam, esse peso original se torna cada vez menos importante. Se, em vez disso, não permanecer na cadeia canônica (ou seja, for reorgado), então se tornará irrelevante para a regra de confirmação.

Acabamos de lançar aqui um artigo apresentando uma versão atualizada do algoritmo de regra de confirmação descrito neste post.

Algum cliente de consenso já apoia esta regra de confirmação? (Vejo que o Prysm tem um PR aberto).

Em Berlim, @dankrad mencionou esse trabalho para mim e ficou surpreso ao saber que os rollups geralmente não o utilizam, por exemplo, para confirmar depósitos. A razão pode ser que esta especificação ainda não foi implementada.

Só vim aqui para dizer: nós (Gnosis) adoraríamos atualizar nossa ponte para usar essa regra de confirmação rápida. Parece que os clientes CL estão realmente enviando-o – assim que pelo menos 3 o lançarem, iremos ativá-lo em nossa ponte e reduzir o tempo de aproximadamente 10-20 minutos para <20 segundos.

Legal!

Como a Gnosis lidará com o cenário improvável quando um bloco confirmado pelo FCR for reorganizado? Pelos seus slides EEZ, acho que a Gnosis Chain também será reorganizada?

Além disso, para quem perdeu, este é o site do FCR: https://fastconfirm.it (anteriormente não publicado neste tópico).