Voltei ontem à documentação do Dusk e, no fim, fiquei mais interessado nas questões de design do que nas afirmações técnicas.

A primeira coisa que me chamou atenção foi a divisão entre Moonlight e Phoenix. Moonlight é baseado em conta, com chave pública, nonce e saldo, enquanto Phoenix usa UTXOs como “notas” dentro de uma árvore de Merkle. Os campos de transação do Moonlight incluem from, to, value, nonce, deposit, data, gas_limit, gas_price e signature, com o gás máximo calculado como gas_limit × gas_price.

Phoenix fica interessante. Ele usa a curva Jubjub, com chaves públicas (A,B), chaves secretas (a,b) e uma chave de visualização (a,B). A estrutura da nota inclui type, com, enc, npk, R e encsender. A chave de nota de uso único é derivada como npk = H(rA)G + B, enquanto a chave de gasto é nsk = H(aR) + b.

Ainda estou tentando entender a fronteira de confiança em torno da geração de provas ZK e da varredura delegada. A documentação diz que terceiros podem gerar provas ou fazer scan usando chaves de visualização sem obter autoridade de gasto, mas onde estão os pontos de falha?

E com nullifiers, raízes de Merkle recentes e o gás tratado dentro da prova, como isso se comporta sob condições adversas de rede? Quais partes são descentralizadas e quais suposições os usuários devem questionar?

#dusk $DUSK @Dusk