Ziua 3/5 ~ Confirmări de despachetare ~ Cum modelează lanțurile finalitatea și de ce aplicația trebuie să gândească probabilistic ~ Ieri, am explorat modul în care "confirmarea" depinde de lanț. Astăzi, să analizăm modul în care aceste lanțuri modelează de fapt finalitatea și de ce aplicația ta trebuie să treacă dincolo de o vizualizare binară de "confirmat vs nu" Majoritatea lanțurilor nu oferă un singur răspuns curat. În schimb, lucrați cu un spectru: 1. Finalitate deterministă: lanțuri care folosesc consens în stil BFT (de exemplu, cosm, unele alt-DA), decontare L1 (de exemplu, ethereu după finalitate) și majoritatea PoS oferă garanții dure - odată finalizată, o tranzacție nu poate fi anulată. 2. Finalitate probabilistică: Lanțurile POW (cum ar fi Bitcoin) și Ethereum "pre-finalitate" oferă garanții statistice. Un tx îngropat la 12 blocuri adâncime este puțin probabil să fie reorganizat - dar nu imposibil. cu cât mai adânc, cu atât mai sigur. 3. Semnale ușoare: Confirmările secvențiatorului, includerea mempool, releele constructorului - sunt rapide, dar prezintă riscuri. Aceste semnale sunt utile, dar trebuie tratate cu atenție. Aplicațiile tratează adesea aceste surse în mod egal: → "așteptați X blocuri" → "Ai încredere în secvențiator" → "verifică includerea" Dar acea abstracție se rupe de îndată ce intri în interoperabilitate. O aplicație între lanțuri se poate întinde: ~ Un lanț BFT cu finalitate rapidă ~ Un rollup optimist cu ferestre de fraudă de 7 zile ~ Un L1 cu finalitate probabilistică ~ Un lanț cu garanții exclusiv pentru secvențiere Logica aplicației nu poate codifica o regulă unică. trebuie să întrebați: "Cât de probabil este ca acest tx să revină la revenire? Și cine impune asta?" ==> finalitatea nu este binară și compromisul dintre viteză și securitate nu este liniar. (MultiSIG-urile, de exemplu, nu câștigă viteză sau încredere.) → ceea ce aveți nevoie este încredere programabilă, conștientă de lanț == o modalitate de a exprima ce înseamnă "confirmat" în fiecare context