Dzień 3/5 ~ Rozpakowywanie potwierdzeń ~ Jak łańcuchy modelują finalność i dlaczego Twoja aplikacja musi myśleć probabilistycznie ~ Wczoraj zbadaliśmy, jak "potwierdzenie" zależy od łańcucha. Dziś rozpakujemy, jak te łańcuchy faktycznie modelują finalność i dlaczego Twoja aplikacja musi wyjść poza binarny pogląd na "potwierdzone vs niepotwierdzone". Większość łańcuchów nie oferuje jednej, czystej odpowiedzi. Zamiast tego pracujesz z spektrum: 1. finalność deterministyczna: łańcuchy korzystające z konsensusu w stylu BFT (np. cosms, niektóre alt-DA), rozliczenie L1 (np. ethereum po finalności) i większość PoS oferują twarde gwarancje - po sfinalizowaniu transakcja nie może być cofnięta. 2. finalność probabilistyczna: łańcuchy pow (jak bitcoin) i ethereum "pre-finalność" oferują statystyczne gwarancje. Transakcja zakopana 12 bloków głęboko jest mało prawdopodobna do reorganizacji - ale nie niemożliwa. Im głębiej, tym bezpieczniej. 3. miękkie sygnały: potwierdzenia sekwencera, włączenie do mempoola, relay budowniczych - są szybkie, ale niosą ryzyko. Te sygnały są użyteczne, ale muszą być traktowane ostrożnie. Aplikacje często traktują te źródła równo: → "czekaj X bloków" → "ufaj sekwencerowi" → "sprawdź włączenie" Ale ta abstrakcja łamie się, gdy przechodzisz do interoperacyjności. Aplikacja międzyłańcuchowa może obejmować: ~ Łańcuch BFT z szybką finalnością ~ Optymistyczny rollup z 7-dniowymi oknami oszustw ~ L1 z finalnością probabilistyczną ~ Łańcuch z gwarancjami tylko sekwencera Logika Twojej aplikacji nie może twardo kodować zasady "jeden rozmiar dla wszystkich". Musisz zapytać: "Jak prawdopodobne jest, że ta transakcja zostanie cofnięta? I kto to egzekwuje?" ==> finalność nie jest binarna, a kompromis między szybkością a bezpieczeństwem nie jest liniowy. (multisigi, na przykład, nie zyskują na szybkości ani zaufaniu.) → to, czego potrzebujesz, to programowalna, świadoma łańcucha pewność == sposób wyrażenia, co oznacza "potwierdzone" w każdym kontekście.