A página de revisão diz “finality”, mas nos registros só há “proposal”. Quando isso acontece, o primeiro passo não é tratar “finalidade” como conclusão; é buscar as evidências ao contrário: esse bloco foi apenas proposto com participação de membros do comitê? Se a resposta for “sim”, ele ainda está na primeira camada e não pode substituir as validações e aprovações que vêm depois.

A segunda camada é a validation. O material exige uma validação independente do bloco candidato e das transações; o foco não é se há uma palavra bonita de status na página, mas se o objeto validado realmente abrange o bloco e as transações nele contidas. Se houver apenas registros de proposta, sem base de validação independente, a cadeia de evidências ainda fica interrompida no meio.

A terceira camada é a ratification, isto é, se as condições de aprovação foram atingidas. Quando as condições são atingidas, o bloco passa a ter finalidade final e determinística; no contexto normal de operação, o usuário não deve entendê-la como algo que ainda depende de reagrupamento orientado ao usuário. Essa ordem é importante: proposal é “alguém propôs”; validation é “alguém verificou de forma independente”; ratification é “condições atendidas e aprovação concluída”.

Portanto, ao avaliar o status de consenso de @Dusk , você pode usar três perguntas em vez de um slogan: quem é o proponente? o que a validação cobre? as condições de aprovação foram atendidas? $DUSK é um token nativo da rede, mas não pode ser usado para responder a questões de evidência de finalidade. #dusk

Ao verificar, também é preciso registrar “qual camada está faltando”, e não apenas “não passou”. Essa forma de escrever devolve as palavras de status a um caminho de evidências rastreável e também impede que uma explicação de finalidade no funcionamento normal seja interpretada erroneamente como um compromisso para todos os cenários anômalos.

Não trate as três palavras em inglês como três diferenciais independentes. O que realmente precisa ficar registrado é se, do proposal até a validation, o objeto é contínuo e se, da validation até a ratification, as condições estão claras. Só quando essa cadeia se fecha, a finality se torna um resultado verificável, e não apenas uma decoração na interface.