J'ai prêté attention à un petit détail architectural dans Dusk qui en dit plus qu'il n'y paraît : le Transfer Contract agit comme le point d'entrée unique pour le DUSK public et le DUSK shielded, au lieu de faire fonctionner deux systèmes séparés qui se parlent de temps en temps. Chaque transfert, public ou shielded, ainsi que chaque conversion entre les deux, passe par la même logique du contrat. C'est un choix de conception délibéré, pas un hasard. L'intérêt est subtil. Les systèmes fragmentés ont tendance à créer des cas limites où les garanties de confidentialité ou la comptabilité des soldes peuvent discrètement diverger. Un point d'entrée unique réduit la surface d'attaque et rend l'audit de la logique plus maniable, du moins en théorie. Ce que je ne sais pas encore, c'est comment cela résiste à une charge réelle, ou si l'unification du chemin introduit ses propres goulets d'étranglement à mesure que l'usage augmente. Je préférerais voir cela testé par un volume réel de transactions plutôt que par la seule documentation. La question est de savoir si la conception reste propre à mesure que davantage de types de contrats viennent s'y greffer. J'observe ses performances une fois que le débit réel arrive.
@Dusk #dusk $DUSK