Regra de confirmação para Ethereum POS – Consenso

Este post foi aberto para discussão. A seguinte regra de confirmação rápida para a prova de participação 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 expressos por 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 mudança proposta para o protocolo Ethereum:
  • Se j é o bloco de ponto de verificação mais alto justificado, e a época atual é eentão deixe um ramo com bloco de folhas b Se o último ponto de verificação justificado no pós-estado de b é também jou de uma época \ ge E-2

Notação:

• n é o slot atual e e é a época atual.
• b é a uma quadra da época atual e.
• Há S Votos de FFG da época e em apoio a c.
• W_F é o peso dos validadores ainda para votar em época ee W_t é o peso total de todos os validadores.
• Os controles adversários \ 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 Confirmation-rule-draft.pdf (396,2 kb) ou post para explicação):

• p_ {b}^n = \ frac {\ textrm {Suporte honesto para bloco} b} {\ textrm {total honesto peso}} de validadores em comitês de b \ textrm {.parent.slot} + 1 até n.
• \ textrm {islmdConfirmed} (b, n) é definido como p_ {b ‘}^n> \ frac {1} {2 (1- \ beta)} para todos b ‘ na cadeia de b.
• \ textrm {isconfirmed} (b, n) se:
  • o último ponto de verificação justificado no pós-estado de b é da época e-1e
  • \ textrm {islmdConfirmed} (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 {isconfirmed} (b, n)então b Diz -se que é confirmado e permanecerá na cadeia canônica.

Desde p_b^n não pode ser observado, definimos um prático Indicador de segurança Q_B^n Para determinar se p_b^n está no intervalo apropriado:

• q_ {b}^n = \ frac {\ textrm {suporte para bloco} b} {\ textrm {total peso}} de comitês em slot b \ textrm {.parent.slot} + 1 até o slot n
• q_ {b ‘}^n> \ frac {1} {2} \ esquerda (1+ \ frac {\ textrm {proposer Boost Weight}} {\ textrm {Total Honest Weight}} \ Right) + \ beta para todos b ‘ na cadeia de b implica \ textrm {islmdConfirmed} (b, n)

Desempenho

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

Observamos os seguintes valores para q (Lote gerado usando este protótipo):

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

Trabalho anterior

Por favor, mude para “Peso total do slot (B’.parent) +1 para n”

Eu encontrei uma maneira muito fácil de adiar 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 em especificações, a confirmação de um bloco exige que seus últimos 32 ancestrais também sejam confirmados por LMD.

No entanto, o adversário pode atrasar a liberação de um bloco para evitar sua confirmação. Em particular, se um bloco for lançado no 2/3 do slot, quase nenhum atestado o apoia. Isso leva o bloco não pode ser confirmado. Portanto, os próximos 32 blocos com o bloco atrasado, pois o ancestral não pode ser confirmado.

Como resultado, a estratégia para adiar o tempo de confirmação para sempre é atrasar um bloco durante todas as épocas.

Se quase nenhum atestado suportar o bloco, o bloco não pode ser reorganizado trivialmente pelo próximo proponente usando o recurso de reorg de bloqueio final?

A resposta é sim, eu acho. No entanto, o proponente do bloco pode liberar o bloco entre 4s e 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ê lançar um bloco nos segundos 4s a 4.5s, a probabilidade de esse bloco ser reorgido é muito alto. Sem fazer nenhuma análise, eu diria que a participação de mercado da Prysm e do Farol como os dois apoiam reorgs honestos.

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

Acredito que, se o propositor de blocos lançar seu bloco pouco antes dos validadores liberarem seus atestados (por exemplo, 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. Eu acredito que esse tempo de lançamento pode ser medido.

Mesmo a determinação precisa do tempo de liberação pode ser um desafio, um adversário que detém uma participação de 20% pode atestar seu bloqueio atrasado para impedir que ele seja reorganizado por validadores honestos.

Portanto, acho altamente provável que esse cenário possa ocorrer.

Isso causa apenas uma pequena desaceleração da 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, é reorgada), ela se torna irrelevante para a regra de confirmação.

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

Algum clientes de consenso já apoiam essa regra de confirmação? (Vejo que o Prysm tem um PR aberto).

Em Berlim, @Dankrad mencionou este trabalho para mim e ficou surpreso ao saber que os rollups geralmente não o usam, por exemplo, para confirmar depósitos. O motivo é que esta especificação ainda não foi implementada.