Den 3/5 ~ Potvrzení o rozbalení ~ Jak řetězce modelují konečnost a proč vaše aplikace potřebuje myslet pravděpodobnostně ~ Včera jsme zkoumali, jak "potvrzení" závisí na řetězci. Dnes si pojďme rozbalit, jak tyto řetězce ve skutečnosti modelují konečnost a proč se vaše aplikace musí posunout za binární pohled na "potvrzeno vs. ne" Většina řetězců nenabízí jedinou jasnou odpověď. Místo toho pracujete se spektrem: 1. Deterministická konečnost: řetězce využívající konsensus ve stylu BFT (např. cosms, některé alt-DA), vypořádání L1 (např. ethereu po finalitě) a většina PoS nabízí tvrdé záruky - jakmile je transakce dokončena, nelze ji vrátit zpět. 2. pravděpodobnostní konečnost: Pow chainy (jako Bitcoin) a Ethereum "Pre-finality" nabízejí statistické záruky. Je nepravděpodobné, že by tx pohřbený 12 bloků hluboko byl znovu vybudován - ale ne nemožný. čím hlubší, tím bezpečnější. 3. Měkké signály: Potvrzování sekvencerů, začlenění Mempoolu, Builder relay - jsou rychlé, ale nesou riziko. Tyto signály jsou užitečné, ale je třeba s nimi zacházet opatrně. Aplikace často zacházejí s těmito zdroji stejně: → "počkejte X bloků" → "důvěřujte sekvenceru" → "Zkontrolovat zařazení" Ale tato abstrakce se rozbije, jakmile vstoupíte do interoperabilního vysílání. Cross-chain aplikace může zahrnovat: ~ Řetězec BFT s rychlou finalitou ~ Optimistický souhrn se 7denními podvodnými okny ~ L1 s pravděpodobnostní konečností ~ Řetězec se zárukami pouze pro sekvencer Logika vaší aplikace nemůže pevně zakódovat univerzální pravidlo. Musíte se zeptat: "Jak pravděpodobné je, že se toto tx vrátí? A kdo to vynucuje?" ==> konečnost není binární a kompromis mezi rychlostí a bezpečností není lineární. (Například multisigy nezískávají rychlost ani důvěru.) → to, co potřebujete, je programovatelná, řetězcová jistota == způsob, jak vyjádřit, co znamená "potvrzeno" v každém kontextu