#dusk $DUSK @Dusk
No sistema financeiro tradicional, para impedir que a mesma instrução seja processada repetidas vezes, recorre-se a um mecanismo bem simples — um número de série, ou o número do cheque. Cada instrução tem um identificador único; o sistema só reconhece o primeiro envio. Envios repetidos depois disso são simplesmente recusados. É um mecanismo meio “rústico”, mas durante décadas a infraestrutura financeira dependeu exatamente desse método “naive”, evitando a maior parte dos desastres causados por cobranças ou liquidações duplicadas.
No modelo de contas Moonlight do Dusk, é feito a mesma coisa: cada conta mantém um nonce (um contador). Cada transação precisa ter um nonce exatamente 1 a mais que o nonce atual. Depois do envio, o nonce é incrementado. Assim, mesmo que a mesma transação assinada seja retransmitida e reenviada repetidas vezes pela rede, ela só será aceita na primeira vez; as tentativas seguintes são rejeitadas diretamente. Parece um design básico demais — básico a ponto de muita gente talvez nem ter notado que ele existe. Mas justamente esse tipo de mecanismo fundamental é o que determina se uma blockchain pode ser confiável para processar instruções de liquidação com dinheiro real para instituições.
Ao longo dos anos nessa área, vi mais de uma vez casos em que sistemas antigos, ao tratarem mal instruções repetidas, fizeram com que a mesma transferência fosse debitada mais de uma vez, exigindo depois longos processos de reconciliação e reembolso. Em finanças tradicionais, essas falhas costumam ser classificadas como “incidentes operacionais”, raramente viram notícia. Porém, para as instituições e clientes envolvidos, lidar com isso não é nada trivial. Se uma blockchain for sequer capaz de atender instruções de liquidação de instituições, e não tiver implementado com solidez esse mecanismo mais básico de proteção contra replay, então de nada adianta empilhar depois mais e mais provas de conhecimento zero — a instituição não se importa com quão avançada é sua criptografia; a primeira pergunta é: “Meu dinheiro será debitado duas vezes?”
Dá até para conversar sobre esse design, mas ele não é “sexy” e não tem nada que valha um print e um post. Ainda assim, é justamente a solidez desses mecanismos simples que eu considero como ponto de partida para julgar se o “alicerce” de uma cadeia é firme — não o ponto final.
Na sua opinião, ao avaliar se uma blockchain é confiável, vale começar por esses mecanismos básicos “naive”, ou você deve primeiro ver quão muitas tecnologias novas e chamativas ela tem?
No sistema financeiro tradicional, para impedir que a mesma instrução seja processada repetidas vezes, recorre-se a um mecanismo bem simples — um número de série, ou o número do cheque. Cada instrução tem um identificador único; o sistema só reconhece o primeiro envio. Envios repetidos depois disso são simplesmente recusados. É um mecanismo meio “rústico”, mas durante décadas a infraestrutura financeira dependeu exatamente desse método “naive”, evitando a maior parte dos desastres causados por cobranças ou liquidações duplicadas.
No modelo de contas Moonlight do Dusk, é feito a mesma coisa: cada conta mantém um nonce (um contador). Cada transação precisa ter um nonce exatamente 1 a mais que o nonce atual. Depois do envio, o nonce é incrementado. Assim, mesmo que a mesma transação assinada seja retransmitida e reenviada repetidas vezes pela rede, ela só será aceita na primeira vez; as tentativas seguintes são rejeitadas diretamente. Parece um design básico demais — básico a ponto de muita gente talvez nem ter notado que ele existe. Mas justamente esse tipo de mecanismo fundamental é o que determina se uma blockchain pode ser confiável para processar instruções de liquidação com dinheiro real para instituições.
Ao longo dos anos nessa área, vi mais de uma vez casos em que sistemas antigos, ao tratarem mal instruções repetidas, fizeram com que a mesma transferência fosse debitada mais de uma vez, exigindo depois longos processos de reconciliação e reembolso. Em finanças tradicionais, essas falhas costumam ser classificadas como “incidentes operacionais”, raramente viram notícia. Porém, para as instituições e clientes envolvidos, lidar com isso não é nada trivial. Se uma blockchain for sequer capaz de atender instruções de liquidação de instituições, e não tiver implementado com solidez esse mecanismo mais básico de proteção contra replay, então de nada adianta empilhar depois mais e mais provas de conhecimento zero — a instituição não se importa com quão avançada é sua criptografia; a primeira pergunta é: “Meu dinheiro será debitado duas vezes?”
Dá até para conversar sobre esse design, mas ele não é “sexy” e não tem nada que valha um print e um post. Ainda assim, é justamente a solidez desses mecanismos simples que eu considero como ponto de partida para julgar se o “alicerce” de uma cadeia é firme — não o ponto final.
Na sua opinião, ao avaliar se uma blockchain é confiável, vale começar por esses mecanismos básicos “naive”, ou você deve primeiro ver quão muitas tecnologias novas e chamativas ela tem?
A. 从基础机制看起,地基不稳一切白搭
100%
B. 看新技术,基础机制大家都差不多
0%
C. 两者都看,但基础机制该是一票否决项
0%
2 Votos • Votação encerrada