Dag 3/5 ~ Bevestigingen Ontpakken ~ Hoe ketens finaliteit modelleren, en waarom jouw app probabilistisch moet denken ~ gisteren hebben we onderzocht hoe "bevestiging" afhankelijk is van de keten. Vandaag laten we zien hoe die ketens daadwerkelijk finaliteit modelleren, en waarom jouw app verder moet kijken dan een binaire visie van "bevestigd vs niet" De meeste ketens bieden geen enkel schoon antwoord. In plaats daarvan werk je met een spectrum: 1. deterministische finaliteit: ketens die BFT-stijl consensus gebruiken (bijv. cosms, sommige alt-DA's), L1-settlement (bijv. ethereu na finaliteit) en de meeste PoS bieden harde garanties - eenmaal gefinaliseerd, kan een transactie niet worden teruggedraaid. 2. probabilistische finaliteit: pow-ketens (zoals bitcoin) en ethereum "pre-finaliteit" bieden statistische garanties. Een tx die 12 blokken diep is begraven, is onwaarschijnlijk om te worden gereorganiseerd - maar niet onmogelijk. hoe dieper, hoe veiliger. 3. zachte signalen: sequencer-bevestigingen, mempool-inclusie, builder-relays - ze zijn snel, maar dragen risico. deze signalen zijn nuttig, maar moeten voorzichtig worden behandeld. apps behandelen deze bronnen vaak gelijk: → “wacht X blokken” → “vertrouw de sequencer” → “controleer op inclusie” Maar die abstractie breekt zodra je interoperabel gaat. Een cross-chain app kan zich uitstrekken over: ~ Een snel-finaliteit BFT-keten ~ Een optimistische rollup met 7-daagse fraudevensters ~ Een L1 met probabilistische finaliteit ~ Een keten met sequencer-alleen garanties de logica van jouw app kan geen one-size-fits-all regel hardcoderen. jij moet vragen: “Hoe waarschijnlijk is het dat deze tx terugdraait? En wie handhaaft dat?” ==> finaliteit is niet binair en de afweging tussen snelheid en veiligheid is niet lineair. (multisigs, bijvoorbeeld, winnen geen snelheid of vertrouwen.) → wat je nodig hebt is programmeerbare, keten-bewuste vertrouwen == een manier om uit te drukken wat "bevestigd" betekent in elke context.