Je me suis penché sur la manière dont la preuve d’attestation concise (Succinct Attestation) résout effectivement une itération, et quelque chose concernant le chemin d’échec continuait de me trotter dans la tête.
L’histoire évidente : un comité valide un bloc, l’entérine, c’est fait. Mais le protocole de Dusk ne se contente pas de suivre « valide » : il suit les attestations, et une attestation échouée (un quorum convenant qu’un bloc n’est *pas* valide) est un résultat à part entière, pas un simple détail.
Voici ce que je n’avais pas envisagé : rejeter est structurellement plus facile 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 atteindre une attestation échouée, les membres du comité n’ont qu’à obtenir une supermajorité d’accord sur le fait que *quelque chose* ne va pas — données mal formées, un proposeur défaillant, un dépassement de délai. C’est un contrôle beaucoup moins profond.
Ainsi, mécaniquement, un mauvais bloc peut franchir plus vite son seuil de quorum qu’un bon bloc n’arrive à achever la validation — pas parce que le réseau favorise les blocs invalides, mais parce que le rejet ne requiert pas de reconstruire la correction, seulement de constater son absence. Ce n’est pas un défaut. C’est même pour cela que les itérations existent : échouer vite, confier l’emplacement au prochain provisionneur, et garder un temps de bloc prévisible.
Je travaille encore sur ce que signifie cette asymétrie une fois que la taille des comités évolue avec la répartition du capital. Le rejet plus rapide devient-il une surface d’attaque, ou simplement une résilience voulue par conception ?
@Dusk #dusk $DUSK
L’histoire évidente : un comité valide un bloc, l’entérine, c’est fait. Mais le protocole de Dusk ne se contente pas de suivre « valide » : il suit les attestations, et une attestation échouée (un quorum convenant qu’un bloc n’est *pas* valide) est un résultat à part entière, pas un simple détail.
Voici ce que je n’avais pas envisagé : rejeter est structurellement plus facile 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 atteindre une attestation échouée, les membres du comité n’ont qu’à obtenir une supermajorité d’accord sur le fait que *quelque chose* ne va pas — données mal formées, un proposeur défaillant, un dépassement de délai. C’est un contrôle beaucoup moins profond.
Ainsi, mécaniquement, un mauvais bloc peut franchir plus vite son seuil de quorum qu’un bon bloc n’arrive à achever la validation — pas parce que le réseau favorise les blocs invalides, mais parce que le rejet ne requiert pas de reconstruire la correction, seulement de constater son absence. Ce n’est pas un défaut. C’est même pour cela que les itérations existent : échouer vite, confier l’emplacement au prochain provisionneur, et garder un temps de bloc prévisible.
Je travaille encore sur ce que signifie cette asymétrie une fois que la taille des comités évolue avec la répartition du capital. Le rejet plus rapide devient-il une surface d’attaque, ou simplement une résilience voulue par conception ?
@Dusk #dusk $DUSK
