Eu estava olhando para o modelo de transação transparente da Dusk e, inicialmente, passei por cima de algo que soava quase bom demais para ser verdade: o nonce.
Moonlight é o modelo de transações baseado em contas da Dusk. Cada conta tem uma chave pública, um saldo e um nonce, sendo que o nonce atua como um contador das transações enviadas a partir daquela conta.
Esse pequeno contador tem uma função maior do que parece à primeira vista.
O whitepaper conecta explicitamente o nonce à proteção contra replay. Uma transação não é apenas autorizada porque a assinatura é válida; a sequência de transações da conta também precisa fazer sentido.
Esta é uma daquelas peças da infraestrutura de blockchain que os usuários quase nunca notam quando funciona corretamente.
Você assina uma transação, a rede a processa, seu saldo muda e você segue em frente.
Mas sem mecanismos que impeçam que uma transação válida e antiga seja aceita novamente, a mesma autorização poderia potencialmente se transformar em um problema de segurança completamente diferente.
O que acho interessante sobre a Dusk é que Moonlight e Phoenix resolvem os mesmos requisitos fundamentais de transação por meio de modelos bem diferentes.
Moonlight expõe publicamente o estado da conta, os saldos e os metadados da transação. Phoenix leva a verificação de saldo e a proteção contra double-spend para dentro de provas ZK e nullifiers. Ainda assim, ambos precisam estabelecer propriedade, impedir malleabilidade e parar double spending.
Então a decisão de design real não é simplesmente pública vs. privada.
É quanto da transição de estado a rede consegue verificar diretamente versus quanto precisa ser provado criptograficamente.
Isso torna o humilde nonce mais interessante do que parece.
A transação visível é apenas a superfície. Por baixo dela há um conjunto de regras garantindo que a mesma autorização não possa simplesmente ser repetida.
Quantos “recursos” de blockchain são, na verdade, suposições invisíveis de segurança que os usuários só percebem quando falham?
@Dusk $DUSK #dusk
Moonlight é o modelo de transações baseado em contas da Dusk. Cada conta tem uma chave pública, um saldo e um nonce, sendo que o nonce atua como um contador das transações enviadas a partir daquela conta.
Esse pequeno contador tem uma função maior do que parece à primeira vista.
O whitepaper conecta explicitamente o nonce à proteção contra replay. Uma transação não é apenas autorizada porque a assinatura é válida; a sequência de transações da conta também precisa fazer sentido.
Esta é uma daquelas peças da infraestrutura de blockchain que os usuários quase nunca notam quando funciona corretamente.
Você assina uma transação, a rede a processa, seu saldo muda e você segue em frente.
Mas sem mecanismos que impeçam que uma transação válida e antiga seja aceita novamente, a mesma autorização poderia potencialmente se transformar em um problema de segurança completamente diferente.
O que acho interessante sobre a Dusk é que Moonlight e Phoenix resolvem os mesmos requisitos fundamentais de transação por meio de modelos bem diferentes.
Moonlight expõe publicamente o estado da conta, os saldos e os metadados da transação. Phoenix leva a verificação de saldo e a proteção contra double-spend para dentro de provas ZK e nullifiers. Ainda assim, ambos precisam estabelecer propriedade, impedir malleabilidade e parar double spending.
Então a decisão de design real não é simplesmente pública vs. privada.
É quanto da transição de estado a rede consegue verificar diretamente versus quanto precisa ser provado criptograficamente.
Isso torna o humilde nonce mais interessante do que parece.
A transação visível é apenas a superfície. Por baixo dela há um conjunto de regras garantindo que a mesma autorização não possa simplesmente ser repetida.
Quantos “recursos” de blockchain são, na verdade, suposições invisíveis de segurança que os usuários só percebem quando falham?
@Dusk $DUSK #dusk