I notice something noteworthy when thinking about Zilch’s role on @Dusk : it resembles a kind of “translation” between two different languages—namely, the UTXO-style language where protected values are anonymized, and the account-based contract-state language that most smart-contract logic needs in order to run.
Phoenix operates very similarly to a private UTXO model—value exists as independent notes, and each note proves its validity on its own without needing to know the global state. But most contract logic, even on the Rusk VM, typically requires a more continuous state model—where a variable can be read, changed, and recorded in a traceable sequence. This is the architectural gap between two different data models; it’s not only a privacy issue.
If that’s the case, Zilch’s role isn’t just to “hide information from outsiders,” but also to bridge the translation of a note-form value into an input that a contract-state model can consume—i.e., a data-compatibility problem, not just security. PLONK then proves that this translation process follows the rules, without revealing the contents of the original note.
Counterargument: this is a reasoning based on general understanding of the differences between UTXO and account-based models. It’s not certain that it accurately reflects the actual technical implementation details of Dusk—more in-depth documentation is needed to confirm.
I’m waiting to see whether $DUSK will publish more detailed technical documentation on how Zilch converts between these two data models, to verify whether this is truly the UTXO-to-account compatibility problem as I imagine.
#dusk $BTC $ETH
Phoenix operates very similarly to a private UTXO model—value exists as independent notes, and each note proves its validity on its own without needing to know the global state. But most contract logic, even on the Rusk VM, typically requires a more continuous state model—where a variable can be read, changed, and recorded in a traceable sequence. This is the architectural gap between two different data models; it’s not only a privacy issue.
If that’s the case, Zilch’s role isn’t just to “hide information from outsiders,” but also to bridge the translation of a note-form value into an input that a contract-state model can consume—i.e., a data-compatibility problem, not just security. PLONK then proves that this translation process follows the rules, without revealing the contents of the original note.
Counterargument: this is a reasoning based on general understanding of the differences between UTXO and account-based models. It’s not certain that it accurately reflects the actual technical implementation details of Dusk—more in-depth documentation is needed to confirm.
I’m waiting to see whether $DUSK will publish more detailed technical documentation on how Zilch converts between these two data models, to verify whether this is truly the UTXO-to-account compatibility problem as I imagine.
#dusk $BTC $ETH
