Päivä 3/5 ~ Pakkauksen purkaminen Vahvistukset ~ Miten ketjut mallintavat lopullisuutta ja miksi sovelluksesi on ajateltava todennäköisyyksillä ~ Eilen tutkimme, miten "vahvistus" riippuu ketjusta. Tänään selvitetään, miten nämä ketjut todella mallintavat lopullisuutta ja miksi sovelluksesi on siirryttävä binäärinäkymästä "vahvistettu vs. ei" Useimmat ketjut eivät tarjoa yhtä selkeää vastausta. Sen sijaan työskentelet spektrin kanssa: 1. Deterministinen lopullisuus: ketjut, jotka käyttävät BFT-tyylistä konsensusta (esim. cosms, jotkut alt-DA:t), L1-selvitys (esim. ethereu lopullisuuden jälkeen) ja useimmat PoS:t tarjoavat kovia takuita - kun transaktio on valmis, sitä ei voi palauttaa. 2. Todennäköisyysperusteinen lopullisuus: POW-ketjut (kuten Bitcoin) ja Ethereum "Pre-finality" tarjoavat tilastollisia takuita. 12 korttelin syvyyteen haudattua tx:ää tuskin järjestetä uudelleen - mutta ei mahdotonta. mitä syvemmälle, sitä turvallisempaa. 3. Pehmeät signaalit: Sekvensserivahvistukset, mempool-inkluusio, rakentajareleet - ne ovat nopeita, mutta niihin liittyy riskejä. Nämä signaalit ovat hyödyllisiä, mutta niihin on suhtauduttava huolellisesti. Sovellukset kohtelevat usein näitä lähteitä tasapuolisesti: → "odota X lohkoa" → "Luota sekvensseriin" → "tarkista sisällyttäminen" Mutta tämä abstraktio katkeaa heti, kun siirryt interoperaatioon. Ketjujen välinen sovellus voi kattaa seuraavat: ~ Nopea BFT-ketju ~ Optimistinen rollup, jossa on 7 päivän petosikkunat ~ L1, jolla on todennäköisyyspohjainen lopullisuus ~ Ketju, jossa on vain sekvensser-takuut Sovelluslogiikka ei voi koodata yhden koon sääntöä. Sinun on kysyttävä: "Kuinka todennäköistä on, että tämä TX palautuu? Ja kuka valvoo sitä?" ==> Lopullisuus ei ole binäärinen, eikä nopeuden ja turvallisuuden välinen kompromissi ole lineaarinen. (Esimerkiksi multisigit eivät saa nopeutta tai luottamusta.) → tarvitset ohjelmoitavaa, ketjutietoista luottamusta == tapaa ilmaista, mitä "vahvistettu" tarkoittaa kussakin kontekstissa