Jour 3/5 ~ Déballage des confirmations ~ Comment les chaînes modélisent la finalité, et pourquoi votre application doit penser de manière probabiliste ~ Hier, nous avons exploré comment la "confirmation" dépend de la chaîne. Aujourd'hui, déballons comment ces chaînes modélisent réellement la finalité, et pourquoi votre application doit aller au-delà d'une vue binaire de "confirmé vs non confirmé". La plupart des chaînes n'offrent pas une réponse claire et unique. Au lieu de cela, vous travaillez avec un spectre : 1. finalité déterministe : les chaînes utilisant un consensus de type BFT (par exemple, cosms, certains alt-DAs), le règlement L1 (par exemple, ethereu après finalité) et la plupart des PoS offrent des garanties solides - une fois finalisée, une transaction ne peut pas être annulée. 2. finalité probabiliste : les chaînes pow (comme bitcoin) et l'"pré-finalité" d'ethereum offrent des garanties statistiques. Une tx enterrée à 12 blocs de profondeur est peu susceptible d'être réorganisée - mais pas impossible. Plus c'est profond, plus c'est sûr. 3. signaux faibles : confirmations de séquenceur, inclusion dans le mempool, relais de constructeurs - ils sont rapides, mais comportent des risques. Ces signaux sont utiles, mais doivent être traités avec précaution. Les applications traitent souvent ces sources de manière égale : → "attendre X blocs" → "faire confiance au séquenceur" → "vérifier l'inclusion" Mais cette abstraction se brise dès que vous passez à l'interopérabilité. Une application cross-chain pourrait s'étendre : ~ Une chaîne BFT à finalité rapide ~ Un rollup optimiste avec des fenêtres de fraude de 7 jours ~ Un L1 avec finalité probabiliste ~ Une chaîne avec des garanties uniquement de séquenceur La logique de votre application ne peut pas coder en dur une règle unique pour tous....