J’ai failli abandonner en rafraîchissant mon solde deux fois avant de comprendre exactement ce que j’attendais.
Le crépuscule ne traite pas une transaction « pontée » comme un seul et unique instant. Une transaction est d’abord incluse dans un bloc L2 par le séquenceur, puis le batcher publie ces données sur DuskDS, et ce n’est qu’une fois que les engagements d’état et les preuves de faute l’y ont ancrée que le transfert est réellement réglé.
Voici le point qui a changé ma lecture : la plupart des rollups EVM vous obligent à patienter pendant une fenêtre de contestation d’environ sept jours avant qu’un retrait ne soit véritablement final, parce qu’il faut laisser du temps à quelqu’un pour contester un état erroné. DuskEVM règle directement vers DuskDS, sans fenêtre de faute de sept jours. Ainsi, l’écart entre inclusion et règlement n’est pas de plusieurs jours : c’est quelque chose que vous pourriez presque ignorer d’un clin d’œil. C’est un véritable choix de conception, pas juste de la tuyauterie.
Ce qui, presque, le rend pire d’une certaine façon. Si le délai était long, on s’attendrait à devoir attendre et à s’organiser en conséquence. Comme c’est rapide, il est facile de confondre « inclus » avec « final » et de ne jamais remarquer qu’il y avait deux réclamations distinctes qui étaient faites.
J’aime le fait que le protocole continue de garder ces réclamations séparées, même quand l’intervalle entre elles est suffisamment court pour être ignoré.
Alors, réduire la fenêtre de faute à quelque chose de quasi instantané est-il une réelle amélioration de résilience par rapport au modèle standard de rollup, ou bien le fait de supprimer l’attente prolongée fait simplement disparaître le signal qui incitait les gens à faire preuve de prudence ?
#dusk @Dusk $DUSK $PENGU $TUT
Le crépuscule ne traite pas une transaction « pontée » comme un seul et unique instant. Une transaction est d’abord incluse dans un bloc L2 par le séquenceur, puis le batcher publie ces données sur DuskDS, et ce n’est qu’une fois que les engagements d’état et les preuves de faute l’y ont ancrée que le transfert est réellement réglé.
Voici le point qui a changé ma lecture : la plupart des rollups EVM vous obligent à patienter pendant une fenêtre de contestation d’environ sept jours avant qu’un retrait ne soit véritablement final, parce qu’il faut laisser du temps à quelqu’un pour contester un état erroné. DuskEVM règle directement vers DuskDS, sans fenêtre de faute de sept jours. Ainsi, l’écart entre inclusion et règlement n’est pas de plusieurs jours : c’est quelque chose que vous pourriez presque ignorer d’un clin d’œil. C’est un véritable choix de conception, pas juste de la tuyauterie.
Ce qui, presque, le rend pire d’une certaine façon. Si le délai était long, on s’attendrait à devoir attendre et à s’organiser en conséquence. Comme c’est rapide, il est facile de confondre « inclus » avec « final » et de ne jamais remarquer qu’il y avait deux réclamations distinctes qui étaient faites.
J’aime le fait que le protocole continue de garder ces réclamations séparées, même quand l’intervalle entre elles est suffisamment court pour être ignoré.
Alors, réduire la fenêtre de faute à quelque chose de quasi instantané est-il une réelle amélioration de résilience par rapport au modèle standard de rollup, ou bien le fait de supprimer l’attente prolongée fait simplement disparaître le signal qui incitait les gens à faire preuve de prudence ?
#dusk @Dusk $DUSK $PENGU $TUT
