День 3/5 ~ Підтвердження розпакування ~ Як ланцюжки моделюють завершеність, і чому ваш додаток повинен мислити імовірнісно ~ Вчора ми досліджували, як "підтвердження" залежить від ланцюжка. Сьогодні давайте розберемося, як ці ланцюжки насправді моделюють остаточність, і чому ваш додаток повинен вийти за рамки бінарного представлення «підтверджено проти ні» Більшість мереж не пропонують єдиної чіткої відповіді. Замість цього ви працюєте зі спектром: 1. Детермінована кінцевість: ланцюжки, що використовують консенсус у стилі BFT (наприклад, cosms, деякі alt-DA), розрахунки L1 (наприклад, Ethereu після фіналізації) і більшість PoS пропонують жорсткі гарантії - після завершення транзакція не може бути скасована. 2. Імовірнісна кінцевість: Pow Chains (наприклад, Bitcoin) і «Pre-finality» Ethereum пропонують статистичні гарантії. Тх, закопаний на глибину 12 кварталів, навряд чи вдасться реорганізувати - але не неможливо. Чим глибше, тим безпечніше. 3. М'які сигнали: Підтвердження секвенсора, включення Mempool, реле будівельника - вони швидкі, але несуть ризик. Ці сигнали корисні, але до них потрібно ставитися обережно. Додатки часто однаково ставляться до цих джерел: → "чекати X блоків" → "довіряйте секвенсеру" → "перевірка на включення" Але ця абстракція руйнується, як тільки ви переходите на взаємодію. Багатоланцюговий додаток може охоплювати: ~ Швидкий ланцюжок BFT ~ Оптимістичний злет із 7-денними вікнами шахрайства ~ L1 з імовірнісною кінцевістю ~ Ланцюжок з гарантіями тільки секвенсера Логіка вашого додатка не може жорстко закодувати універсальне правило. вам потрібно запитати: «Наскільки ймовірним є повернення цього tx? А хто це забезпечує? ==> Остаточність не є бінарною, а компроміс між швидкістю та безпекою не є лінійним. (Мультипідписи, наприклад, не набирають швидкості та довіри.) → вам потрібна програмована впевненість з урахуванням ланцюга == спосіб виразити, що означає "підтверджено" в кожному контексті