Giorno 3/5 ~ Conferme di Scompattamento ~ Come le catene modellano la finalità e perché la tua app deve pensare in modo probabilistico ~ Ieri abbiamo esplorato come la "conferma" dipenda dalla catena. Oggi, scomponiamo come queste catene modellano effettivamente la finalità e perché la tua app deve andare oltre una visione binaria di "confermata vs non confermata". La maggior parte delle catene non offre una risposta unica e chiara. Invece, stai lavorando con uno spettro: 1. finalità deterministica: catene che utilizzano il consenso in stile BFT (ad es. cosms, alcuni alt-DA), liquidazione L1 (ad es. ethereu dopo la finalità) e la maggior parte di PoS offrono garanzie solide - una volta finalizzata, una transazione non può essere annullata. 2. finalità probabilistica: catene pow (come bitcoin) ed ethereum "pre-finalità" offrono garanzie statistiche. Una tx sepolta 12 blocchi in profondità è improbabile che venga riorganizzata - ma non impossibile. Più è profonda, più è sicura. 3. segnali soft: conferme sequencer, inclusione nel mempool, relay dei costruttori - sono veloci, ma comportano rischi. Questi segnali sono utili, ma devono essere trattati con cautela. Le app spesso trattano queste fonti in modo uguale: → “aspetta X blocchi” → “fidati del sequencer” → “controlla l'inclusione” Ma quell'astrazione si rompe non appena vai in interoperabilità. Un'app cross-chain potrebbe estendersi su: ~ Una catena BFT a finalità rapida ~ Un rollup ottimista con finestre di frode di 7 giorni ~ Un L1 con finalità probabilistica ~ Una catena con garanzie solo sequencer La logica della tua app non può codificare una regola universale. Devi chiederti: “Quanto è probabile che questa tx venga annullata? E chi lo fa rispettare?” ==> la finalità non è binaria e il compromesso tra velocità e sicurezza non è lineare. (i multisig, ad esempio, non guadagnano in velocità o fiducia.) → ciò di cui hai bisogno è una fiducia programmabile e consapevole della catena == un modo per esprimere cosa significa "confermata" in ciascun contesto.