Un petit changement dans Rusk dit beaucoup de la façon dont Dusk gère la vérification cryptographique lors des mises à jour de protocole.
Un résultat mis en cache n’est désormais plus lié uniquement à la preuve et à ses entrées. Dusk associe aussi ce résultat aux règles de vérification qui étaient en vigueur au moment où le contrôle a été effectué.
Cela compte car des données de preuve identiques ne signifient pas toujours un contexte de vérification identique. Une mise à jour de protocole peut modifier le vérificateur ou la politique d’exécution sans changer les octets de la preuve eux-mêmes.
Pour le réseau Dusk, cela devient particulièrement pertinent puisqu’il met en place une confidentialité programmable pour les marchés réglementés, où les preuves cryptographiques doivent rester fiables au fil des mises à jour de protocole.
Ce que je ne sais pas encore, c’est si Dusk a isolé ces règles spécifiques à la version avec assez de rigueur pour qu’un résultat mis en cache ne puisse jamais dépasser la sémantique qui le rendait valide.
Les détails à surveiller sont notamment le contexte de politique d’exécution inclus dans les clés de cache, les changements de vérificateur comme l’activation de PLONK V3, et ce qui se passe lorsque de futures mises à jour changent à nouveau le comportement de vérification.
Faire correspondre des octets de preuve est une preuve utile que deux vérifications se ressemblent. C’est toutefois une preuve plus faible que le même résultat mis en cache soit sûr à réutiliser.
Je me soucierais davantage de savoir si le contexte du vérificateur actif correspond encore que du volume de travail de vérification que Dusk arrive à mettre en cache.
Le point plus profond est que la vérification déterministe dépend de plus que du fait de fixer l’entrée. Les règles utilisées pour interpréter cette entrée doivent elles aussi être figées.
La question est de savoir si Dusk peut continuer à optimiser la vérification sans laisser les anciennes sémantiques de protocole traverser une frontière de mise à jour via le cache.
Je surveille comment les futurs changements de vérificateur se reflètent dans ce contexte de politique d’exécution.
#dusk $DUSK @Dusk
Un résultat mis en cache n’est désormais plus lié uniquement à la preuve et à ses entrées. Dusk associe aussi ce résultat aux règles de vérification qui étaient en vigueur au moment où le contrôle a été effectué.
Cela compte car des données de preuve identiques ne signifient pas toujours un contexte de vérification identique. Une mise à jour de protocole peut modifier le vérificateur ou la politique d’exécution sans changer les octets de la preuve eux-mêmes.
Pour le réseau Dusk, cela devient particulièrement pertinent puisqu’il met en place une confidentialité programmable pour les marchés réglementés, où les preuves cryptographiques doivent rester fiables au fil des mises à jour de protocole.
Ce que je ne sais pas encore, c’est si Dusk a isolé ces règles spécifiques à la version avec assez de rigueur pour qu’un résultat mis en cache ne puisse jamais dépasser la sémantique qui le rendait valide.
Les détails à surveiller sont notamment le contexte de politique d’exécution inclus dans les clés de cache, les changements de vérificateur comme l’activation de PLONK V3, et ce qui se passe lorsque de futures mises à jour changent à nouveau le comportement de vérification.
Faire correspondre des octets de preuve est une preuve utile que deux vérifications se ressemblent. C’est toutefois une preuve plus faible que le même résultat mis en cache soit sûr à réutiliser.
Je me soucierais davantage de savoir si le contexte du vérificateur actif correspond encore que du volume de travail de vérification que Dusk arrive à mettre en cache.
Le point plus profond est que la vérification déterministe dépend de plus que du fait de fixer l’entrée. Les règles utilisées pour interpréter cette entrée doivent elles aussi être figées.
La question est de savoir si Dusk peut continuer à optimiser la vérification sans laisser les anciennes sémantiques de protocole traverser une frontière de mise à jour via le cache.
Je surveille comment les futurs changements de vérificateur se reflètent dans ce contexte de politique d’exécution.
#dusk $DUSK @Dusk
