Dag 3/5 ~ Utpakkingsbekreftelser ~ Hvordan kjeder modellerer endelighet, og hvorfor appen din må tenke probabilistisk ~ I går utforsket vi hvordan "bekreftelse" avhenger av kjeden. La oss i dag pakke ut hvordan disse kjedene faktisk modellerer endelighet, og hvorfor appen din må gå utover en binær visning av «bekreftet vs ikke» De fleste kjeder gir ikke et eneste rent svar. I stedet jobber du med et spektrum: 1. Deterministisk finalitet: kjeder som bruker konsensus i BFT-stil (f.eks. cosms, noen alt-DA-er), L1-oppgjør (f.eks. ethereu etter endelighet) og de fleste PoS tilbyr harde garantier - når den er fullført, kan ikke en transaksjon tilbakestilles. 2. Sannsynlighetsmessig endelighet: Pow-kjeder (som Bitcoin) og Ethereum "pre-finality" tilbyr statistiske garantier. En tx begravd 12 kvartaler dypt vil neppe bli omorganisert - men ikke umulig. jo dypere, jo tryggere. 3. Myke signaler: Sequencer-bekreftelser, mempool-inkludering, byggerreléer - de er raske, men medfører risiko. Disse signalene er nyttige, men må behandles nøye. Apper behandler ofte disse kildene likt: → "vent X blokker" → "stol på sequenceren" → "sjekk for inkludering" Men den abstraksjonen brytes så snart du går interop. En app på tvers av kjeder kan strekke seg over følgende: ~ En BFT-kjede med rask avslutning ~ En optimistisk opprulling med 7-dagers svindelvinduer ~ En L1 med probabilistisk finalitet ~ Et kjede med kun sequencer-garantier Applogikken din kan ikke hardkode en regel som passer alle. du må spørre: "Hvor sannsynlig er det at denne tx går tilbake? Og hvem håndhever det?» ==> endelighet er ikke binær, og avveiningen mellom hastighet og sikkerhet er ikke lineær. (Multisigs, for eksempel, får ikke fart eller tillit.) → det du trenger er programmerbar, kjedebevisst tillit == en måte å uttrykke hva "bekreftet" betyr i hver sammenheng