Dag 3/5 ~ Uppackning Bekräftelser ~ Hur kedjor modellerar slutgiltighet och varför din app behöver tänka probabilistiskt ~ Igår utforskade vi hur "bekräftelse" beror på kedjan. I dag ska vi gå igenom hur dessa kedjor faktiskt modellerar slutgiltighet och varför din app måste gå bortom en binär vy av "bekräftad eller inte" De flesta kedjor erbjuder inte ett enda rent svar. I stället arbetar du med ett spektrum: 1. Deterministisk slutgiltighet: kedjor som använder BFT-konsensus (t.ex. kosmos, vissa alt-DAs), L1-avveckling (t.ex. ethereu efter finality) och de flesta PoS erbjuder hårda garantier - när en transaktion väl är slutförd kan den inte återställas. 2. Probabilistisk slutgiltighet: Pow-kedjor (som Bitcoin) och Ethereum "pre-finality" erbjuder statistiska garantier. En tx begravd 12 kvarter djup är osannolikt att omorganiseras - men inte omöjligt. Ju djupare, desto säkrare. 3. Mjuka signaler: Sequencer-bekräftelser, mempool-inkludering, byggarreläer - de är snabba, men medför risk. Dessa signaler är användbara, men måste behandlas försiktigt. Appar behandlar ofta dessa källor lika: → "vänta X block" → "lita på sequencern" → "kontrollera om det finns med" Men den abstraktionen bryts så fort du går interop. En app över kedjan kan sträcka sig över: ~ En BFT-kedja med snabb slutgiltighet ~ En optimistisk rollup med 7-dagars bedrägerifönster ~ En L1 med sannolikhetsbaserad slutgiltighet ~ En kedja med garantier endast för sequencer Din applogik kan inte hårdkoda en regel som passar alla. du måste fråga: "Hur troligt är det att denna tx kommer att återställas? Och vem ser till att det följs?" ==> slutgiltighet är inte binärt och avvägningen mellan hastighet och säkerhet är inte linjär. (Multisigs, till exempel, får inte fart eller förtroende.) → vad du behöver är programmerbart, kedjemedvetet förtroende == ett sätt att uttrycka vad "bekräftad" betyder i varje sammanhang