Na semana passada enviei um pacote pelos correios e saiu errado um item. Depois que entrei em contato com o suporte, o atendente explicou: o status do envio de logística não é algo do tipo “enviou” vs. “não enviou” — existe um meio-termo. Entre eles, ainda há “enviado”, “em transporte” e “entregue/assinado”. Em cada fase, dá para interceptar, fazer recall e reaver? As regras são totalmente diferentes. Desliguei o telefone e, de repente, pensei: a “confirmação” na cadeia de blocos também segue essa lógica — não é simplesmente “confirmou” ou “não confirmou”.
Por aqui, no Dusk, os status do bloco são divididos em quatro níveis. Um bloco recém-saído, se a primeira rodada de votação já passar direto, chama-se “attested” (já verificado/confirmado); se antes houve uma rodada em que a votação falhou e só agora passou, chama-se “accepted” (já aceito) — e este ainda pode ser substituído por um bloco de uma rodada mais baixa. Mais adiante, no caminho: um bloco “attested” passa a “confirmed” (já confirmado) assim que blocos posteriores se conectam a ele. Já um bloco “accepted” precisa esperar uma quantidade específica de blocos posteriores sustentando-o para então poder evoluir para “confirmed”. Por fim, o bloco “confirmed” só consegue subir para “final” (estado final) se o seu “bloco pai” também estiver em estado final; uma vez atingido esse estado, ele se torna completamente irreversível.
Esse desenho em camadas resolve a questão de “quão rápido dá para ficar tranquilo” — nem todos os blocos precisam esperar o nível mais alto para serem usados. Em cenários leves, é possível assumir o “attested” para começar a agir; em cenários de alto valor/ativos pesados, precisa esperar até o “final” para só então ficar completamente tranquilo. Diferentes níveis de tolerância ao risco correspondem a diferentes limiares de confirmação, e essa flexibilidade é bem prática.
Mas o custo é a complexidade — para usuários comuns, fica difícil identificar diretamente em que nível exatamente chegou aquela transação. Hoje, essa parte depende principalmente das exibições feitas pelo software dos nós e pela camada de carteira; se a experiência é boa ou não, ainda depende de como isso será implementado na prática.
$DUSK
#dusk @Dusk
Por aqui, no Dusk, os status do bloco são divididos em quatro níveis. Um bloco recém-saído, se a primeira rodada de votação já passar direto, chama-se “attested” (já verificado/confirmado); se antes houve uma rodada em que a votação falhou e só agora passou, chama-se “accepted” (já aceito) — e este ainda pode ser substituído por um bloco de uma rodada mais baixa. Mais adiante, no caminho: um bloco “attested” passa a “confirmed” (já confirmado) assim que blocos posteriores se conectam a ele. Já um bloco “accepted” precisa esperar uma quantidade específica de blocos posteriores sustentando-o para então poder evoluir para “confirmed”. Por fim, o bloco “confirmed” só consegue subir para “final” (estado final) se o seu “bloco pai” também estiver em estado final; uma vez atingido esse estado, ele se torna completamente irreversível.
Esse desenho em camadas resolve a questão de “quão rápido dá para ficar tranquilo” — nem todos os blocos precisam esperar o nível mais alto para serem usados. Em cenários leves, é possível assumir o “attested” para começar a agir; em cenários de alto valor/ativos pesados, precisa esperar até o “final” para só então ficar completamente tranquilo. Diferentes níveis de tolerância ao risco correspondem a diferentes limiares de confirmação, e essa flexibilidade é bem prática.
Mas o custo é a complexidade — para usuários comuns, fica difícil identificar diretamente em que nível exatamente chegou aquela transação. Hoje, essa parte depende principalmente das exibições feitas pelo software dos nós e pela camada de carteira; se a experiência é boa ou não, ainda depende de como isso será implementado na prática.
$DUSK
#dusk @Dusk