Encontrei o problema da AEGIS mais revelador fora da própria prova de conhecimento zero. Um valor ao lado não estava totalmente controlado.
No caminho de transação do Phoenix da Dusk Network, um usuário poderia se comprometer a um max_fee legítimo enquanto a execução ainda consumia campos de taxa que não estavam vinculados ao mesmo contexto de segurança. Parâmetros de gás hostis poderiam causar inflação de reembolso ou estouro. Um endereço de reembolso mutável poderia redirecionar o valor.
A prova era válida. A semântica da transação não estava totalmente conectada a ela.
Uma taxa não é metadado inofensivo quando o caminho de reembolso pode criar ou redirecionar valor.
Esse é um aviso útil para qualquer protocolo de privacidade. Provar perfeitamente uma afirmação não protege campos adjacentes que a execução confia depois. O sistema deve vincular a prova, a assinatura, o cálculo da taxa, o destino e o caminho de reembolso em uma única invariância.
A AEGIS adicionou multiplicação verificada para gas_limit vezes gas_price e exigiu que o resultado fosse igual ao max_fee comprovado. A Dusk aplicou essa verificação duas vezes: na admissão ao mempool e novamente dentro da execução da VM. Ela também vinculou o endereço furtivo de reembolso, de modo que adulterar isso invalidaria a transação.
A segunda verificação é o detalhe de que me importo. Um proponente malicioso de bloco não precisa respeitar as suposições de um mempool honesto. Se a invariância existir apenas na borda da rede, o consenso ainda pode executar uma transação que ignorou essa borda.
Agora eu passaria a observar o mesmo padrão de defesa em Dusk: rejeição barata antes da admissão, validação autoritativa na execução e testes de regressão que mutam cada campo em torno de uma prova.
A AEGIS fechou os caminhos críticos conhecidos. A questão maior é se outros contratos da Dusk contêm valores que são "checados" em uma camada e apenas confiados na próxima.
A criptografia pode provar exatamente o que ela é solicitada a provar. A segurança depende de a Dusk pedir a afirmação completa.
#dusk $DUSK @Dusk
No caminho de transação do Phoenix da Dusk Network, um usuário poderia se comprometer a um max_fee legítimo enquanto a execução ainda consumia campos de taxa que não estavam vinculados ao mesmo contexto de segurança. Parâmetros de gás hostis poderiam causar inflação de reembolso ou estouro. Um endereço de reembolso mutável poderia redirecionar o valor.
A prova era válida. A semântica da transação não estava totalmente conectada a ela.
Uma taxa não é metadado inofensivo quando o caminho de reembolso pode criar ou redirecionar valor.
Esse é um aviso útil para qualquer protocolo de privacidade. Provar perfeitamente uma afirmação não protege campos adjacentes que a execução confia depois. O sistema deve vincular a prova, a assinatura, o cálculo da taxa, o destino e o caminho de reembolso em uma única invariância.
A AEGIS adicionou multiplicação verificada para gas_limit vezes gas_price e exigiu que o resultado fosse igual ao max_fee comprovado. A Dusk aplicou essa verificação duas vezes: na admissão ao mempool e novamente dentro da execução da VM. Ela também vinculou o endereço furtivo de reembolso, de modo que adulterar isso invalidaria a transação.
A segunda verificação é o detalhe de que me importo. Um proponente malicioso de bloco não precisa respeitar as suposições de um mempool honesto. Se a invariância existir apenas na borda da rede, o consenso ainda pode executar uma transação que ignorou essa borda.
Agora eu passaria a observar o mesmo padrão de defesa em Dusk: rejeição barata antes da admissão, validação autoritativa na execução e testes de regressão que mutam cada campo em torno de uma prova.
A AEGIS fechou os caminhos críticos conhecidos. A questão maior é se outros contratos da Dusk contêm valores que são "checados" em uma camada e apenas confiados na próxima.
A criptografia pode provar exatamente o que ela é solicitada a provar. A segurança depende de a Dusk pedir a afirmação completa.
#dusk $DUSK @Dusk
