#dusk $DUSK
Os números 2/3 e 1/2 continuaram aparecendo em partes diferentes da documentação do consenso, e eu continuei tratando-os como o mesmo limite, com notações diferentes. Não são. São duas regras de quórum diferentes para dois resultados diferentes.
Limite de aprovação do bloco: ≥2/3 dos créditos do comitê precisam votar como Válido. Isso é uma supermaioria. Para um comitê de 64 créditos, isso significa que pelo menos 43 créditos precisam concordar que o bloco está correto para que ele seja aceito.
Limite de rejeição do bloco: >1/2 dos créditos do comitê — estritamente mais da metade, mais um — precisam votar como Inválido, NoCandidate ou NoQuorum. Isso é uma maioria simples. Para 64 créditos, isso significa pelo menos 33.
Mesmo comitê. Bar diferente. Chegar à aprovação é mais difícil do que disparar uma falha.
Então por que o limite de rejeição também não exige 2/3.
A assimetria é intencional. A justificativa de design é que aprovar um bloco requer alta confiança — você não quer que um bloco seja aceito a menos que uma maioria forte concorde que ele está correto. Mas encerrar uma iteração com falha não carrega o mesmo risco. Se o gerador do bloco ficou offline ou enviou algo inválido, você quer que a rede avance rapidamente em vez de esperar por um limite mais alto para confirmar a falha. Um limite menor de rejeição faz com que a rede falhe mais rápido e tente novamente mais cedo.
Eu acho a assimetria de limites ainda mais interessante do ponto de vista de segurança do que de velocidade. O limite de aprovação mais difícil torna significativamente mais caro para um atacante obter um bloco malicioso aceito do que é para validadores honestos rejeitarem um bloco ruim.
O que eu não vi explicado é como a ponderação do comitê interage com esses limites — se um único provedor possuindo 20 dos 64 créditos pode, de fato, bloquear a aprovação ou acelerar a rejeição por conta própria, ou se a distribuição de créditos pelo comitê torna esse tipo de concentração praticamente impossível. @Dusk
$DUSK #dusk
Os números 2/3 e 1/2 continuaram aparecendo em partes diferentes da documentação do consenso, e eu continuei tratando-os como o mesmo limite, com notações diferentes. Não são. São duas regras de quórum diferentes para dois resultados diferentes.
Limite de aprovação do bloco: ≥2/3 dos créditos do comitê precisam votar como Válido. Isso é uma supermaioria. Para um comitê de 64 créditos, isso significa que pelo menos 43 créditos precisam concordar que o bloco está correto para que ele seja aceito.
Limite de rejeição do bloco: >1/2 dos créditos do comitê — estritamente mais da metade, mais um — precisam votar como Inválido, NoCandidate ou NoQuorum. Isso é uma maioria simples. Para 64 créditos, isso significa pelo menos 33.
Mesmo comitê. Bar diferente. Chegar à aprovação é mais difícil do que disparar uma falha.
Então por que o limite de rejeição também não exige 2/3.
A assimetria é intencional. A justificativa de design é que aprovar um bloco requer alta confiança — você não quer que um bloco seja aceito a menos que uma maioria forte concorde que ele está correto. Mas encerrar uma iteração com falha não carrega o mesmo risco. Se o gerador do bloco ficou offline ou enviou algo inválido, você quer que a rede avance rapidamente em vez de esperar por um limite mais alto para confirmar a falha. Um limite menor de rejeição faz com que a rede falhe mais rápido e tente novamente mais cedo.
Eu acho a assimetria de limites ainda mais interessante do ponto de vista de segurança do que de velocidade. O limite de aprovação mais difícil torna significativamente mais caro para um atacante obter um bloco malicioso aceito do que é para validadores honestos rejeitarem um bloco ruim.
O que eu não vi explicado é como a ponderação do comitê interage com esses limites — se um único provedor possuindo 20 dos 64 créditos pode, de fato, bloquear a aprovação ou acelerar a rejeição por conta própria, ou se a distribuição de créditos pelo comitê torna esse tipo de concentração praticamente impossível. @Dusk
$DUSK #dusk
