Je remarque un point intéressant en réfléchissant au rôle de Zilch sur @Dusk : cela ressemble à une forme de « traduction » entre deux langages différents — d’un côté, le langage des valeurs protégées de type UTXO anonyme, et de l’autre, le langage de l’état des contrats de type account-based, dont la plupart de la logique des smart contracts a besoin pour fonctionner.
Phoenix fonctionne de façon proche d’un modèle UTXO privé : la valeur existe sous forme de notes indépendantes, et chaque note prouve sa validité sans avoir besoin de connaître l’état global. Mais la plupart des logiques de contrat, y compris sur la Rusk VM, ont souvent besoin d’un modèle d’état plus continu — où une variable peut être lue, modifiée, puis enregistrée dans un ordre traçable. C’est l’écart d’architecture entre deux modèles de données différents, qui ne se limite pas à une question de confidentialité.
Si c’est le cas, le rôle de Zilch ne consiste pas seulement à « cacher l’information aux personnes extérieures », mais aussi à servir de passerelle pour traduire une valeur sous forme de note discrète en entrée que le modèle d’état du contrat peut consommer — un problème de compatibilité des données, pas uniquement de sécurité. PLONK prouve ensuite que cette traduction suit les règles, sans divulguer le contenu de la note d’origine.
Autocritique : il s’agit d’une inférence fondée sur une compréhension générale des différences entre les modèles UTXO et account-based ; elle n’est donc pas forcément une représentation exacte des détails techniques réels de Dusk — il faudrait une documentation plus approfondie pour le confirmer.
J’attends de voir si $DUSK publie une documentation technique plus détaillée sur la façon dont Zilch convertit entre ces deux modèles de données, pour vérifier que c’est bien le problème de compatibilité UTXO-account tel que je l’imagine.
#dusk $BTC $ETH
Phoenix fonctionne de façon proche d’un modèle UTXO privé : la valeur existe sous forme de notes indépendantes, et chaque note prouve sa validité sans avoir besoin de connaître l’état global. Mais la plupart des logiques de contrat, y compris sur la Rusk VM, ont souvent besoin d’un modèle d’état plus continu — où une variable peut être lue, modifiée, puis enregistrée dans un ordre traçable. C’est l’écart d’architecture entre deux modèles de données différents, qui ne se limite pas à une question de confidentialité.
Si c’est le cas, le rôle de Zilch ne consiste pas seulement à « cacher l’information aux personnes extérieures », mais aussi à servir de passerelle pour traduire une valeur sous forme de note discrète en entrée que le modèle d’état du contrat peut consommer — un problème de compatibilité des données, pas uniquement de sécurité. PLONK prouve ensuite que cette traduction suit les règles, sans divulguer le contenu de la note d’origine.
Autocritique : il s’agit d’une inférence fondée sur une compréhension générale des différences entre les modèles UTXO et account-based ; elle n’est donc pas forcément une représentation exacte des détails techniques réels de Dusk — il faudrait une documentation plus approfondie pour le confirmer.
J’attends de voir si $DUSK publie une documentation technique plus détaillée sur la façon dont Zilch convertit entre ces deux modèles de données, pour vérifier que c’est bien le problème de compatibilité UTXO-account tel que je l’imagine.
#dusk $BTC $ETH
