Panne franche vs panne byzantine

Panne franche (panne par arrêt, crash / fail-stop)

Définition : le composant (nœud, processus, matériel) cesse définitivement de fonctionner ; il n'émet plus rien mais ne produit jamais de résultat incorrect.
Caractéristiques :
Silencieuse : le composant ne répond plus, mais ne « ment » pas et ne corrompt pas les données.
Détectabilité : garantie dans le modèle fail-stop (l'arrêt est signalé/observable). Attention : dans un modèle purement asynchrone, un simple crash est indiscernable d'une lenteur — c'est le sens du résultat d'impossibilité FLP ; on s'appuie alors sur des détecteurs de défaillance imparfaits et des timeouts.
Définitive : pas de reprise de l'activité (sinon on parle de crash-recovery).
Exemples : serveur qui plante et ne redémarre pas ; disque dur en panne mécanique ; processus tué sans corrompre son état.
Classe de faute : faute par omission (cas extrême : omission permanente).
Seuil de tolérance typique : consensus possible avec 
𝑛
≥
2
𝑓
+
1
n≥2f+1 (voire 
𝑓
<
𝑛
f<n en synchrone avec canaux fiables).

Panne byzantine (panne arbitraire, Byzantine fault)

Définition : le composant défaille de manière arbitraire, éventuellement malveillante : il peut émettre des valeurs fausses, incohérentes ou contradictoires selon le destinataire.
Caractéristiques :
Arbitraire : tout comportement est possible (mensonge, duplication, réordonnancement, silence sélectif, collusion entre fautifs).
Non détectable localement : un nœud byzantin peut se comporter correctement vis-à-vis de certains pairs ; seule une décision collective (protocole de consensus, signatures, preuves) permet de le neutraliser.
Dangerosité : corruption active de l'état global (propagation de fausses informations, equivocation, sabotage).
Exemples : nœud qui envoie deux versions différentes d'une même transaction à deux pairs (double dépense, equivocation) ; capteur défectueux transmettant des valeurs aberrantes mais plausibles ; nœud compromis par un attaquant. (La Sybil attack est un problème distinct : falsification d'identités multiples, souvent combiné à un comportement byzantin, mais ce n'est pas un modèle de faute.)
Classe de faute : faute arbitraire (englobe omission, temporisation et valeur erronée).
Seuil de tolérance typique : 
𝑛
≥
3
𝑓
+
1
n≥3f+1 en asynchrone/partiellement synchrone sans signatures (PBFT, Tendermint) ; 
𝑓
<
𝑛
/
2
f<n/2 atteignable en synchrone avec signatures authentifiées.

Comparaison

Critère Panne franche Panne byzantine

Comportement Arrêt, silence Arbitraire, mensonges, incohérences
Détectabilité Directe (timeout, heartbeat), sous hypothèse de synchronie Indirecte, via consensus/cryptographie
Impact Perte de disponibilité Perte d'intégrité et de cohérence
Tolérance Réplication, failover, 
𝑛
≥
2
𝑓
+
1
n≥2f+1 Consensus byzantin (PBFT, HotStuff, Tendermint), 
𝑛
≥
3
𝑓
+
1
n≥3f+1
Coût Faible (peu de messages, pas de crypto) Élevé (rounds supplémentaires, signatures)
Exemple système RAID, cluster avec load balancer Blockchains, avionique (vote entre calculateurs)

Relation d'inclusion : la panne franche est un cas particulier de la panne byzantine ; tout protocole tolérant 
𝑓
f fautes byzantines tolère 
𝑓
f crashes, l'inverse est faux.

Implications d'ingénierie

Pannes franches : détecteurs de défaillance (heartbeat), réplication passive/active, bascule automatique, consensus type Paxos/Raft. Suffisant quand tous les composants sont sous contrôle d'une même autorité de confiance.
Pannes byzantines : signatures numériques, réplication machine d'états byzantine, vote majoritaire sur les valeurs, diversification des implémentations (pour éviter la faute corrélée). Indispensable dès qu'il y a des acteurs mutuellement méfiants, du code non maîtrisé ou un environnement adverse.
Cas Bitcoin : la sûreté probabiliste requiert que l'adversaire contrôle strictement moins de 50 % de la puissance de calcul (et non du nombre de nœuds) ; des attaques rentables existent dès ~25–33 % (selfish mining).

Références
Lamport, L., Shostak, R., Pease, M. (1982). The Byzantine Generals Problem, ACM TOPLAS — fondation du modèle byzantin.
Fischer, Lynch, Paterson (1985). Impossibility of Distributed Consensus with One Faulty Process — indiscernabilité crash/lenteur en asynchrone.
Castro, M., Liskov, B. (1999). Practical Byzantine Fault Tolerance, OSDI — borne 
𝑛
≥
3
𝑓
+
1
n≥3f+1.
Tanenbaum, A. S., Van Steen, M. Distributed Systems: Principles and Paradigms — taxonomie des modèles de faute.