#dusk $DUSK @Dusk
J’ai commencé à compter les routes indépendantes vers DuskEVM et, eh bien, la liste s’est réduite très vite. La documentation DUSK oriente les utilisateurs vers un seul RPC, un seul explorateur, un seul flux de pont (Web Wallet) et le séquenceur au singulier.
DuskDS peut toujours régler des lots via un consensus décentralisé. Mais si un séquenceur ordonne les transactions, un point de terminaison par défaut reçoit les soumissions et une interface officielle indique aux utilisateurs quand les retraits de pont sont prêts, alors il existe une couche de coordination au-dessus du consensus. Elle ne réécrit peut-être pas l’état final. Elle peut quand même retarder, filtrer ou disparaître.
Cela compte pour DUSK, car la demande de gaz et la liquidité de pont dépendent du fait que les utilisateurs atteignent l’exécution, et non du fait que des provisionneurs continuent de finaliser en dessous. La conception répartit le règlement ; en pratique, le chemin peut concentrer l’accès via l’infrastructure officielle. Ce n’est pas la même chose.
La plupart des gens confondent règlement vérifié et accès neutre. Ce n’est pas équivalent. Le même test devrait couvrir des clusters pairs, des émetteurs de la preuve d’identité Citadel et la règle de rechargement 90/10 : les dix provisionneurs hébergés ensemble ne constituent pas dix domaines d’échec indépendants.
Ma discrète inquiétude porte sur les données manquantes. Je n’arrive pas à trouver des parts de trafic RPC publiques, le nombre médian de pairs, des détails de basculement du séquenceur ou des seuils de contrôle du pont. Tant que DUSK ne les expose pas, la décentralisation décrit la couche de règlement avec plus de confiance que le parcours complet de l’utilisateur.
J’ai commencé à compter les routes indépendantes vers DuskEVM et, eh bien, la liste s’est réduite très vite. La documentation DUSK oriente les utilisateurs vers un seul RPC, un seul explorateur, un seul flux de pont (Web Wallet) et le séquenceur au singulier.
DuskDS peut toujours régler des lots via un consensus décentralisé. Mais si un séquenceur ordonne les transactions, un point de terminaison par défaut reçoit les soumissions et une interface officielle indique aux utilisateurs quand les retraits de pont sont prêts, alors il existe une couche de coordination au-dessus du consensus. Elle ne réécrit peut-être pas l’état final. Elle peut quand même retarder, filtrer ou disparaître.
Cela compte pour DUSK, car la demande de gaz et la liquidité de pont dépendent du fait que les utilisateurs atteignent l’exécution, et non du fait que des provisionneurs continuent de finaliser en dessous. La conception répartit le règlement ; en pratique, le chemin peut concentrer l’accès via l’infrastructure officielle. Ce n’est pas la même chose.
La plupart des gens confondent règlement vérifié et accès neutre. Ce n’est pas équivalent. Le même test devrait couvrir des clusters pairs, des émetteurs de la preuve d’identité Citadel et la règle de rechargement 90/10 : les dix provisionneurs hébergés ensemble ne constituent pas dix domaines d’échec indépendants.
Ma discrète inquiétude porte sur les données manquantes. Je n’arrive pas à trouver des parts de trafic RPC publiques, le nombre médian de pairs, des détails de basculement du séquenceur ou des seuils de contrôle du pont. Tant que DUSK ne les expose pas, la décentralisation décrit la couche de règlement avec plus de confiance que le parcours complet de l’utilisateur.