#dusk $DUSK
Les détails techniques de cette machine virtuelle Dusk, c’est aussi quelque chose qui devient de plus en plus incompréhensible à mesure qu’on creuse.
Au début, je me demandais surtout où se trouvaient ces états de position et d’autorisations dans le contrat. Après avoir fouillé longtemps, j’ai fini par comprendre : il met toute la chaîne d’état du contrat dans un bloc de mémoire contigu, puis, à chaque modification, il réécrit l’ensemble du bloc de mémoire. Ce n’est absolument pas la même approche que l’EVM que nous connaissons : chez nous, on modifie où il faut ; là-bas, c’est comme pour un document, on ne change que cette ligne. Eux, même si on ne modifie qu’un seul nombre, toute la page de mémoire doit être reconstruite et réécrite.
Déjà, ça consomme énormément de ressources. En plus, ils ont ajouté une conception à double “carnet”. L’un est publié pour que le régulateur voie, l’autre, pour la confidentialité, tourne dans le XSC. Pour une transaction : on modifie une fois l’état public, puis on régénère une fois l’état privé, et les deux copies en mémoire doivent toutes les deux être réécrites. Et du côté de Hedger, il faut aussi relancer une fois une preuve à divulgation nulle de connaissance ; les nœuds doivent ensuite recalculer aussi. Au final, ce n’est pas un coût qui s’additionne en 1+1 : c’est un coût qui se multiplie.
Pour les titres tokenisés — positions, listes blanches, règles de verrouillage — les états, de toute façon, ne font qu’augmenter, jamais l’inverse. Donc même pour déployer un contrat XSC un peu complexe, même si on ne change qu’un solde, il faut réécrire intégralement toute la page mémoire.
Quelqu’un dira sûrement : “Et alors ? Les états tournent au niveau supérieur ; en dessous, DuskDS ne stocke que des preuves.”
À première vue, c’est logique, mais en y réfléchissant, ce n’est pas juste. Les nœuds d’archivage ne stockent pas des instantanés d’historiques de mémoire ? Alors, pour des audits à l’avenir, qu’est-ce qu’on va vérifier ? Vérifier du vide ? Si on les stocke, qu’est-ce que ça change par rapport aux nœuds complets ? Autrement dit, le problème de l’accumulation toujours plus massive des états n’est fait que d’être déplacé de la couche d’exécution vers la couche d’archivage. Là-dessus, l’officiel tourne en rond, et il n’y a aucune réponse claire et positive.
Pour l’instant, je m’intéresse surtout au cas réel : comment les contrats de titres de NPEX sont mis en chaîne. Si, dans les six mois, le volume d’état d’un seul contrat devient 10 fois plus grand que pour un ERC20 ordinaire, ou si les nœuds d’archivage commencent à stocker secrètement des instantanés mémoire, alors cette conception met clairement des mines pour la RWA : je ne toucherai pas à ça.
Ah, et encore un piège : la preuve concise de DuskDS peut attester que le registre de confidentialité en lui-même est correct, mais peut-elle attester que, pour chaque instantané mémoire, l’historique est resté cohérent et n’a jamais été modifié ? Si elle ne peut pas, alors la piste d’audit des titres tokenisés s’interrompt directement entre la couche de confidentialité et la couche d’archivage.
@Dusk
Les détails techniques de cette machine virtuelle Dusk, c’est aussi quelque chose qui devient de plus en plus incompréhensible à mesure qu’on creuse.
Au début, je me demandais surtout où se trouvaient ces états de position et d’autorisations dans le contrat. Après avoir fouillé longtemps, j’ai fini par comprendre : il met toute la chaîne d’état du contrat dans un bloc de mémoire contigu, puis, à chaque modification, il réécrit l’ensemble du bloc de mémoire. Ce n’est absolument pas la même approche que l’EVM que nous connaissons : chez nous, on modifie où il faut ; là-bas, c’est comme pour un document, on ne change que cette ligne. Eux, même si on ne modifie qu’un seul nombre, toute la page de mémoire doit être reconstruite et réécrite.
Déjà, ça consomme énormément de ressources. En plus, ils ont ajouté une conception à double “carnet”. L’un est publié pour que le régulateur voie, l’autre, pour la confidentialité, tourne dans le XSC. Pour une transaction : on modifie une fois l’état public, puis on régénère une fois l’état privé, et les deux copies en mémoire doivent toutes les deux être réécrites. Et du côté de Hedger, il faut aussi relancer une fois une preuve à divulgation nulle de connaissance ; les nœuds doivent ensuite recalculer aussi. Au final, ce n’est pas un coût qui s’additionne en 1+1 : c’est un coût qui se multiplie.
Pour les titres tokenisés — positions, listes blanches, règles de verrouillage — les états, de toute façon, ne font qu’augmenter, jamais l’inverse. Donc même pour déployer un contrat XSC un peu complexe, même si on ne change qu’un solde, il faut réécrire intégralement toute la page mémoire.
Quelqu’un dira sûrement : “Et alors ? Les états tournent au niveau supérieur ; en dessous, DuskDS ne stocke que des preuves.”
À première vue, c’est logique, mais en y réfléchissant, ce n’est pas juste. Les nœuds d’archivage ne stockent pas des instantanés d’historiques de mémoire ? Alors, pour des audits à l’avenir, qu’est-ce qu’on va vérifier ? Vérifier du vide ? Si on les stocke, qu’est-ce que ça change par rapport aux nœuds complets ? Autrement dit, le problème de l’accumulation toujours plus massive des états n’est fait que d’être déplacé de la couche d’exécution vers la couche d’archivage. Là-dessus, l’officiel tourne en rond, et il n’y a aucune réponse claire et positive.
Pour l’instant, je m’intéresse surtout au cas réel : comment les contrats de titres de NPEX sont mis en chaîne. Si, dans les six mois, le volume d’état d’un seul contrat devient 10 fois plus grand que pour un ERC20 ordinaire, ou si les nœuds d’archivage commencent à stocker secrètement des instantanés mémoire, alors cette conception met clairement des mines pour la RWA : je ne toucherai pas à ça.
Ah, et encore un piège : la preuve concise de DuskDS peut attester que le registre de confidentialité en lui-même est correct, mais peut-elle attester que, pour chaque instantané mémoire, l’historique est resté cohérent et n’a jamais été modifié ? Si elle ne peut pas, alors la piste d’audit des titres tokenisés s’interrompt directement entre la couche de confidentialité et la couche d’archivage.
@Dusk