#dusk $DUSK @Dusk J’ai relu hier soir la documentation technique de Dusk, et je me suis retrouvé à prêter davantage attention aux parties qu’on a tendance à ignorer quand tout le monde parle de confidentialité et d’applications financières.
Un point m’a particulièrement frappé : la manière dont le protocole aborde l’efficacité.
L’Attestation succincte (SA) de Dusk s’appuie sur la preuve d’enjeu (proof-of-stake) plutôt que sur la preuve de travail (proof-of-work). Ainsi, la sécurité du réseau ne dépend pas de l’exécution continue d’énigmes computationnelles. Les provisionneurs sont sélectionnés via une sélection déterministe (sortition) fondée sur leur enjeu, tandis que la finalité en rotation est conçue pour réduire les tours de consensus inutiles.
Cela m’a amené à me demander : quelle part de l’efficacité du réseau provient du design du consensus lui-même, et quelle part dépend du travail réel exécuté en chaîne ?
Ensuite, j’ai examiné Piecrust, la machine virtuelle de Dusk basée sur le WASM. L’idée est assez simple : les smart contracts s’exécutent dans un environnement léger et modulaire, avec Rust et WebAssembly pour favoriser la portabilité et une exécution contrôlée.
Mais cela a soulevé une autre question. À mesure que les contrats deviennent plus complexes et que les opérations cryptographiques deviennent plus lourdes, à quel moment apparaît la limite de performance pratique ?
Je m’interroge aussi sur la décentralisation. Si l’enjeu détermine la participation au consensus, comment le système se comporte-t-il si l’enjeu se concentre entre un plus petit nombre de provisionneurs ?
Je n’ai pas trouvé assez de détails dans ces sections seules pour répondre à cela avec suffisamment de confiance.
Alors je me demande : que pensent les développeurs et les observateurs de long terme des compromis les plus importants encore non résolus dans l’architecture du consensus et de la VM de Dusk ?
@Dusk_Foundation $DUSK #dusk
Un point m’a particulièrement frappé : la manière dont le protocole aborde l’efficacité.
L’Attestation succincte (SA) de Dusk s’appuie sur la preuve d’enjeu (proof-of-stake) plutôt que sur la preuve de travail (proof-of-work). Ainsi, la sécurité du réseau ne dépend pas de l’exécution continue d’énigmes computationnelles. Les provisionneurs sont sélectionnés via une sélection déterministe (sortition) fondée sur leur enjeu, tandis que la finalité en rotation est conçue pour réduire les tours de consensus inutiles.
Cela m’a amené à me demander : quelle part de l’efficacité du réseau provient du design du consensus lui-même, et quelle part dépend du travail réel exécuté en chaîne ?
Ensuite, j’ai examiné Piecrust, la machine virtuelle de Dusk basée sur le WASM. L’idée est assez simple : les smart contracts s’exécutent dans un environnement léger et modulaire, avec Rust et WebAssembly pour favoriser la portabilité et une exécution contrôlée.
Mais cela a soulevé une autre question. À mesure que les contrats deviennent plus complexes et que les opérations cryptographiques deviennent plus lourdes, à quel moment apparaît la limite de performance pratique ?
Je m’interroge aussi sur la décentralisation. Si l’enjeu détermine la participation au consensus, comment le système se comporte-t-il si l’enjeu se concentre entre un plus petit nombre de provisionneurs ?
Je n’ai pas trouvé assez de détails dans ces sections seules pour répondre à cela avec suffisamment de confiance.
Alors je me demande : que pensent les développeurs et les observateurs de long terme des compromis les plus importants encore non résolus dans l’architecture du consensus et de la VM de Dusk ?
@Dusk_Foundation $DUSK #dusk