O pequeno ícone "confirmado" na carteira parece nada demais; só depois de ler a documentação final do Dusk é que percebi que, por trás desse aviso aparentemente insignificante, estão embutidos quatro níveis de confiabilidade totalmente diferentes.
Primeiro, um novo bloco passa pela fase de "aceito"; nesse ponto, se na mesma rodada surgirem blocos candidatos mais antigos, ele pode ser substituído a qualquer momento. Sobrevivendo a isso e subindo para o nível "comprovado", você escapa desse destino de ser deslocado; depois disso, vem o "bloqueado", que é sustentado pelo acúmulo de blocos subsequentes; e, no nível de "resolução completa", é preciso esperar que o bloco pai também conclua todo o processo.
O ponto-chave é que não existe uma resposta única para quantos blocos posteriores são necessários para ir do estágio de recém-nascido até a resolução completa. Esse número se relaciona com quantas tentativas fracassadas o bloco passou quando nasceu — quanto mais acidentado for o nascimento, mais confirmação será necessária depois para compensar aquela incerteza inata. E, mesmo quando o rótulo é o mesmo, "confirmado", o valor real pode variar drasticamente.
Seguindo essa lógica para outros módulos, percebi que essa mesma filosofia de camadas aparece em outros lugares também. O contrato central que roteia transações de diferentes tipos as separa em canais de validação correspondentes com base em suas propriedades; depois de cada uma concluir seu próprio fluxo, elas são registradas de forma unificada no livro-razão da cadeia. Transferências visíveis, transferências criptografadas, transações baseadas em conta e baseadas em títulos — tudo precisa ser materializado de maneira consistente.
Agora, ao mudar o foco para o cenário de matching, fica ainda mais interessante: para cada negociação ser reconhecida pelo mercado, é preciso deixar na cadeia evidências verificáveis e reavaliáveis. A finalidade em níveis fornece às aplicações uma régua graduada de julgamento: quando é possível prometer publicamente, e quando só dá para registrar contabilmente de forma provisória. Os nós é que decidem e calibram isso.
O custo é que essa complexidade não é visível para usuários comuns. Em caso de bifurcação extrema da rede, em quem recai essa diferença de informação e como isso realmente afeta tudo — ainda precisa ser observado.
#dusk @Dusk $DUSK
Primeiro, um novo bloco passa pela fase de "aceito"; nesse ponto, se na mesma rodada surgirem blocos candidatos mais antigos, ele pode ser substituído a qualquer momento. Sobrevivendo a isso e subindo para o nível "comprovado", você escapa desse destino de ser deslocado; depois disso, vem o "bloqueado", que é sustentado pelo acúmulo de blocos subsequentes; e, no nível de "resolução completa", é preciso esperar que o bloco pai também conclua todo o processo.
O ponto-chave é que não existe uma resposta única para quantos blocos posteriores são necessários para ir do estágio de recém-nascido até a resolução completa. Esse número se relaciona com quantas tentativas fracassadas o bloco passou quando nasceu — quanto mais acidentado for o nascimento, mais confirmação será necessária depois para compensar aquela incerteza inata. E, mesmo quando o rótulo é o mesmo, "confirmado", o valor real pode variar drasticamente.
Seguindo essa lógica para outros módulos, percebi que essa mesma filosofia de camadas aparece em outros lugares também. O contrato central que roteia transações de diferentes tipos as separa em canais de validação correspondentes com base em suas propriedades; depois de cada uma concluir seu próprio fluxo, elas são registradas de forma unificada no livro-razão da cadeia. Transferências visíveis, transferências criptografadas, transações baseadas em conta e baseadas em títulos — tudo precisa ser materializado de maneira consistente.
Agora, ao mudar o foco para o cenário de matching, fica ainda mais interessante: para cada negociação ser reconhecida pelo mercado, é preciso deixar na cadeia evidências verificáveis e reavaliáveis. A finalidade em níveis fornece às aplicações uma régua graduada de julgamento: quando é possível prometer publicamente, e quando só dá para registrar contabilmente de forma provisória. Os nós é que decidem e calibram isso.
O custo é que essa complexidade não é visível para usuários comuns. Em caso de bifurcação extrema da rede, em quem recai essa diferença de informação e como isso realmente afeta tudo — ainda precisa ser observado.
#dusk @Dusk $DUSK