Um depósito DUSK finalizado é automaticamente seguro para creditar.
A finalização não terminou o trabalho
Eu assumi que, quando um depósito Moonlight atingisse a finalização, uma exchange poderia gravar com segurança o crédito do cliente e seguir adiante.
Os documentos da Dusk separam duas coisas.
O scanner lê o histórico finalizado do Moonlight, mas a custódia precisa fazer o crédito e seu checkpoint de bloco avançarem juntos. Cada crédito usa o ID de transação da Dusk como sua chave única, e `next_block` só avança depois que o crédito é durável.
Agora veja um exemplo construído: o scanner termina um intervalo finalizado até o bloco 12.000. Ele grava um depósito de 5 DUSK para Alice e então cai antes de `next_block` avançar.
Quando ele reinicia, ele escaneia esse intervalo de novo.
O depósito ainda está finalizado. O segundo scan ainda é seguro. O ID de transação impede que o mesmo depósito vire um segundo crédito.
Mas inverta a ordem.
Se `next_block` tivesse avançado antes do crédito ser durável, uma queda poderia fazer o scanner acreditar que o intervalo foi concluído sem que o depósito do cliente jamais fosse registrado. Os documentos da Dusk alertam explicitamente contra essa ordem.
Assim, a finalização responde uma pergunta: "Esse movimento em DUSK está liquidado?"
A custódia responde outra: "Registramos esse movimento liquidado exatamente uma vez?"
Ambas precisam estar corretas para o saldo da exchange ficar certo.
Quanto de um “depósito seguro” vem da finalização da Dusk, e quanto vem da engrenagem contábil que faz um evento finalizado sobreviver a falhas sem ser perdido ou creditado duas vezes?
@Dusk #dusk $DUSK
A finalização não terminou o trabalho
Eu assumi que, quando um depósito Moonlight atingisse a finalização, uma exchange poderia gravar com segurança o crédito do cliente e seguir adiante.
Os documentos da Dusk separam duas coisas.
O scanner lê o histórico finalizado do Moonlight, mas a custódia precisa fazer o crédito e seu checkpoint de bloco avançarem juntos. Cada crédito usa o ID de transação da Dusk como sua chave única, e `next_block` só avança depois que o crédito é durável.
Agora veja um exemplo construído: o scanner termina um intervalo finalizado até o bloco 12.000. Ele grava um depósito de 5 DUSK para Alice e então cai antes de `next_block` avançar.
Quando ele reinicia, ele escaneia esse intervalo de novo.
O depósito ainda está finalizado. O segundo scan ainda é seguro. O ID de transação impede que o mesmo depósito vire um segundo crédito.
Mas inverta a ordem.
Se `next_block` tivesse avançado antes do crédito ser durável, uma queda poderia fazer o scanner acreditar que o intervalo foi concluído sem que o depósito do cliente jamais fosse registrado. Os documentos da Dusk alertam explicitamente contra essa ordem.
Assim, a finalização responde uma pergunta: "Esse movimento em DUSK está liquidado?"
A custódia responde outra: "Registramos esse movimento liquidado exatamente uma vez?"
Ambas precisam estar corretas para o saldo da exchange ficar certo.
Quanto de um “depósito seguro” vem da finalização da Dusk, e quanto vem da engrenagem contábil que faz um evento finalizado sobreviver a falhas sem ser perdido ou creditado duas vezes?
@Dusk #dusk $DUSK