#dusk $DUSK @Dusk
A documentação de transações do Moonlight tem uma seção que a maioria das pessoas trata como boilerplate — a lista completa de propriedades de segurança que o whitepaper nomeia formalmente. São quatro, e a última é mais interessante do que parece.
Propriedades de segurança do Moonlight: não falsificabilidade (protegida por assinaturas digitais), prevenção de gastos duplos (a rede verifica os saldos antes de aceitar), não-maleabilidade (a assinatura cobre o hash de todos os campos da transação, então qualquer modificação a invalida) e prevenção de ataques de replay (protegida pelo nonce).
Vale pensar no que o nonce realmente faz aqui.
Um ataque de replay é quando alguém pega uma transação válida e assinada e a reenvi a. A assinatura é genuína — foi você quem assinou — mas você não autorizou esse envio específico. Sem um mecanismo de prevenção de replay, uma transação válida enviada uma vez poderia ser retransmitida indefinidamente por qualquer pessoa que a capturasse.
O nonce resolve isso. Cada conta do Moonlight tem um nonce atual — um contador que incrementa a cada transação aceita. Quando você envia uma transação, o campo nonce deve ser exatamente current_nonce + 1. A rede rejeita qualquer coisa em que essa verificação falhe. Depois de aceita, o nonce da conta incrementa, então a mesma transação não pode ser reenviada.
Não estou dizendo que isso seja incomum. Toda cadeia séria baseada em contas usa nonces para exatamente esse propósito. O Ethereum faz do mesmo jeito.
Não estou dizendo que seja trivial, porém. O nonce está fazendo uma tarefa separada da assinatura — a assinatura prova autorização, o nonce prova que essa instância específica de transação é nova. Você precisa de ambos, e eles cobrem vetores de ataque diferentes.
O que eu ainda não entendi é se os nonces do Moonlight são globais da conta ou por contrato — se chamar um contrato e enviar uma transferência direta da mesma conta compartilham um único contador de nonce, ou se cada tipo de interação tem sua própria sequência. @Dusk
$DUSK #dusk
A documentação de transações do Moonlight tem uma seção que a maioria das pessoas trata como boilerplate — a lista completa de propriedades de segurança que o whitepaper nomeia formalmente. São quatro, e a última é mais interessante do que parece.
Propriedades de segurança do Moonlight: não falsificabilidade (protegida por assinaturas digitais), prevenção de gastos duplos (a rede verifica os saldos antes de aceitar), não-maleabilidade (a assinatura cobre o hash de todos os campos da transação, então qualquer modificação a invalida) e prevenção de ataques de replay (protegida pelo nonce).
Vale pensar no que o nonce realmente faz aqui.
Um ataque de replay é quando alguém pega uma transação válida e assinada e a reenvi a. A assinatura é genuína — foi você quem assinou — mas você não autorizou esse envio específico. Sem um mecanismo de prevenção de replay, uma transação válida enviada uma vez poderia ser retransmitida indefinidamente por qualquer pessoa que a capturasse.
O nonce resolve isso. Cada conta do Moonlight tem um nonce atual — um contador que incrementa a cada transação aceita. Quando você envia uma transação, o campo nonce deve ser exatamente current_nonce + 1. A rede rejeita qualquer coisa em que essa verificação falhe. Depois de aceita, o nonce da conta incrementa, então a mesma transação não pode ser reenviada.
Não estou dizendo que isso seja incomum. Toda cadeia séria baseada em contas usa nonces para exatamente esse propósito. O Ethereum faz do mesmo jeito.
Não estou dizendo que seja trivial, porém. O nonce está fazendo uma tarefa separada da assinatura — a assinatura prova autorização, o nonce prova que essa instância específica de transação é nova. Você precisa de ambos, e eles cobrem vetores de ataque diferentes.
O que eu ainda não entendi é se os nonces do Moonlight são globais da conta ou por contrato — se chamar um contrato e enviar uma transferência direta da mesma conta compartilham um único contador de nonce, ou se cada tipo de interação tem sua própria sequência. @Dusk
$DUSK #dusk
