descrever em abstrato a execução de dois modelos de transação estruturalmente diferentes em uma única camada de liquidação é uma coisa. fazer com que eles não possam se contradizer é um problema completamente diferente, e a DuskDS resolve isso por meio de um componente específico da arquitetura: o Transfer Contract.
Phoenix e Moonlight não são sistemas independentes executados em paralelo, na esperança de permanecerem consistentes por coincidência. toda movimentação de valor, seja uma nota UTXO protegida no Phoenix ou um saldo de conta público no Moonlight, passa, em última instância, pelo Transfer Contract, que é a autoridade efetiva sobre o estado global na DuskDS. é o único responsável por garantir que o gasto de uma nota protegida e a atualização de um saldo público nunca produzam um total inconsistente, nunca criem valor do nada e nunca permitam que os dois modelos se afastem um do outro com o tempo.
na prática, isso significa que Phoenix e Moonlight não são dois livros-razão separados que por acaso compartilham uma blockchain; são duas representações diferentes, regidas por uma única fonte de verdade compartilhada. o modelo de privacidade muda de acordo com o tipo de transação usado, mas a contabilidade subjacente não pode se contradizer dependendo de qual lado do sistema você está observando.
essa é a parte do projeto que precisa ser impecável para que toda a abordagem de modelo duplo, mencionada há alguns dias, realmente se sustente no uso real. se houvesse alguma inconsistência na forma como o Transfer Contract reconcilia os dois modelos, isso não seria um pequeno bug: seria um ponto em que, teoricamente, valor poderia ser criado ou perdido simplesmente ao passar de uma representação protegida para uma transparente do mesmo ativo.
então, centralizar essa reconciliação em um único contrato é um projeto mais seguro por haver exatamente um lugar para auditar e verificar a correção, ou concentrar tanta responsabilidade em um único contrato apenas concentra o risco, em vez de realmente reduzi-lo?
#dusk @Dusk $DUSK
Phoenix e Moonlight não são sistemas independentes executados em paralelo, na esperança de permanecerem consistentes por coincidência. toda movimentação de valor, seja uma nota UTXO protegida no Phoenix ou um saldo de conta público no Moonlight, passa, em última instância, pelo Transfer Contract, que é a autoridade efetiva sobre o estado global na DuskDS. é o único responsável por garantir que o gasto de uma nota protegida e a atualização de um saldo público nunca produzam um total inconsistente, nunca criem valor do nada e nunca permitam que os dois modelos se afastem um do outro com o tempo.
na prática, isso significa que Phoenix e Moonlight não são dois livros-razão separados que por acaso compartilham uma blockchain; são duas representações diferentes, regidas por uma única fonte de verdade compartilhada. o modelo de privacidade muda de acordo com o tipo de transação usado, mas a contabilidade subjacente não pode se contradizer dependendo de qual lado do sistema você está observando.
essa é a parte do projeto que precisa ser impecável para que toda a abordagem de modelo duplo, mencionada há alguns dias, realmente se sustente no uso real. se houvesse alguma inconsistência na forma como o Transfer Contract reconcilia os dois modelos, isso não seria um pequeno bug: seria um ponto em que, teoricamente, valor poderia ser criado ou perdido simplesmente ao passar de uma representação protegida para uma transparente do mesmo ativo.
então, centralizar essa reconciliação em um único contrato é um projeto mais seguro por haver exatamente um lugar para auditar e verificar a correção, ou concentrar tanta responsabilidade em um único contrato apenas concentra o risco, em vez de realmente reduzi-lo?
#dusk @Dusk $DUSK