J’ai creusé comment la Succinct Attestation résout réellement une itération, et un détail du chemin d’échec n’arrêtait pas de me trotter dans la tête.
L’histoire évidente : un comité valide un bloc, l’entérine, et c’est fini. Mais le protocole de Dusk ne se contente pas de suivre « valide » — il suit des Attestations, et une Attestation échouée (un quorum qui s’accorde sur le fait qu’un bloc n’est *pas* valide) est un résultat de premier ordre, pas une simple conséquence.
Voilà ce que je n’avais pas pris en compte : rejeter est structurellement plus simple qu’accepter. Pour entériner un bloc valide, le comité doit effectivement vérifier les transitions d’état, les signatures, l’ensemble du candidat. Pour aboutir à une Attestation échouée, les membres du comité n’ont qu’à obtenir une supermajorité d’accord sur le fait que *quelque chose* cloche — des données mal formées, un mauvais proposeur, un dépassement de délai. C’est une vérification bien moins profonde.
Donc, mécaniquement, un mauvais bloc peut franchir plus vite son seuil de quorum qu’un bon bloc n’atteint sa validation — non pas parce que le réseau favorise les blocs invalides, mais parce que le rejet ne nécessite pas de reconstruire la correction, seulement de constater son absence. Ce n’est pas un défaut. C’est même précisément pour cela que les itérations existent : échouer rapidement, confier la place au prochain pourvoyeur, et garder un temps de bloc prévisible.
Je continue cependant à réfléchir à ce que signifie cette asymétrie quand la taille des comités évolue avec la répartition des enjeux. Le rejet plus rapide devient-il une surface d’attaque, ou bien une résilience conçue ?
@Dusk_Foundation #dusk $DUSK
L’histoire évidente : un comité valide un bloc, l’entérine, et c’est fini. Mais le protocole de Dusk ne se contente pas de suivre « valide » — il suit des Attestations, et une Attestation échouée (un quorum qui s’accorde sur le fait qu’un bloc n’est *pas* valide) est un résultat de premier ordre, pas une simple conséquence.
Voilà ce que je n’avais pas pris en compte : rejeter est structurellement plus simple qu’accepter. Pour entériner un bloc valide, le comité doit effectivement vérifier les transitions d’état, les signatures, l’ensemble du candidat. Pour aboutir à une Attestation échouée, les membres du comité n’ont qu’à obtenir une supermajorité d’accord sur le fait que *quelque chose* cloche — des données mal formées, un mauvais proposeur, un dépassement de délai. C’est une vérification bien moins profonde.
Donc, mécaniquement, un mauvais bloc peut franchir plus vite son seuil de quorum qu’un bon bloc n’atteint sa validation — non pas parce que le réseau favorise les blocs invalides, mais parce que le rejet ne nécessite pas de reconstruire la correction, seulement de constater son absence. Ce n’est pas un défaut. C’est même précisément pour cela que les itérations existent : échouer rapidement, confier la place au prochain pourvoyeur, et garder un temps de bloc prévisible.
Je continue cependant à réfléchir à ce que signifie cette asymétrie quand la taille des comités évolue avec la répartition des enjeux. Le rejet plus rapide devient-il une surface d’attaque, ou bien une résilience conçue ?
@Dusk_Foundation #dusk $DUSK