Je considère Dusk comme un test de risque d’infrastructure, et pas simplement comme une autre couche 1. Ce qui compte pour moi, c’est de savoir si la confidentialité, le règlement et le jalonnement peuvent fonctionner avec des limites solides autour de l’autorité. L’architecture actuelle de Dusk combine le règlement DuskDS avec l’exécution DuskEVM et DuskVM, ce qui rend le système plus intéressant qu’un simple récit axé sur la vitesse. J’observe si un usage réel peut justifier ses économies de jetons à long terme, car des émissions seules ne constituent pas une demande organique. Je m’intéresse aussi à la distribution des validateurs, à la rétention des développeurs, à l’activité récurrente des portefeuilles, à la croissance des frais et à la quantité de capital qui reste bloquée plutôt que celle qui circule effectivement dans les applications. La question la plus importante pour moi est opérationnelle : la confidentialité et les flux financiers programmables peuvent-ils réduire l’exposition sans créer de nouvelles hypothèses de confiance au sujet des ponts, des clés et des autorisations ? J’ai appris que la plupart des défaillances sérieuses ne commencent pas par des blocs lents. Elles commencent par un excès d’autorité. Pour moi, la meilleure infrastructure n’est pas le registre qui traite tout le plus vite. C’est celui qui est capable de rejeter les comportements dangereux avant une défaillance prévisible.
@Dusk #dusk $DUSK