Continuu să văd oameni spunând că o tranzacție pe Fogo este „confirmată”, iar apoi, la scurt timp, altcineva arată un portofel sau un explorator care încă o arată ca fiind în așteptare. Vreau să fie binar, dar lanțurile rapide nu colaborează cu adevărat. Îți oferă o imagine în mișcare, iar diferite instrumente îngheață cadre diferite. Cheia este că „confirmarea” nu este un singur lucru. În sistemele de tip Solana, mulți oameni folosesc niveluri de angajament—procesat, confirmat, finalizat—care reflectă o încredere crescândă despre care istorie va rămâne rețeaua. Documentația lui Anza o prezintă clar: procesat înseamnă că un nod a primit un bloc conținând tranzacția ta, confirmat adaugă cerința ca 66%+ din miză să fi votat pentru acel bloc, iar finalizat înseamnă în general că 31+ blocuri confirmate au fost construite deasupra. Litepaper-ul Fogo descrie aceeași formă: un bloc este considerat confirmat odată ce 66%+ din miză a votat pe majoritatea fork-ului, și finalizat odată ce atinge blocarea maximă, reprezentată în mod obișnuit ca 31+ blocuri confirmate construite deasupra. Odată ce accept acea scară, întrebarea „de ce diferă confirmările?” devine mai puțin misterioasă. În primul rând, există sincronizare. Mesajele se mișcă cu întârziere, iar litepaper-ul este direct că diferite părți ale rețelei află despre actualizările de stare la momente diferite; dezacordul temporar este normal, nu un caz ciudat. Fogo încearcă să micșoreze acea diferență cu o abordare bazată pe zone, unde validatorii dintr-o zonă activă operează în apropiere fizică și zona poate roti în timp pentru a evita să pună toate consensul într-o singură jurisdicție. Chiar și așa, cele mai multe portofele și servere RPC sunt observatori în altă parte, așa că vor fi puțin întârziate. Acea întârziere este de obicei mică. În al doilea rând, aplicațiile aleg ceea ce numesc „suficient de bun”. Pentru o transferare casuală, „procesat” sau „confirmat” ar putea fi bine. Pentru ceva ce nu poate tolera revertirea, aștepți pentru „finalizat.” Documentele RPC ale Solana recomandă chiar angajamente mai mici pentru a raporta progresul și angajamente mai mari pentru a reduce riscul de rollback, ceea ce îți spune că aceste niveluri sunt menite să fie alese. Acest subiect a devenit mai fierbinte în ultima vreme pentru că mai multă activitate pe lanț este sensibilă la latență—oamenii vor ca bucla de feedback să se simtă imediată, nu ca un sistem de decontare care își ia timpul. În cele din urmă, instalațiile pot adăuga confuzie. Unele metode RPC verifică doar cache-ul recent al statutului unui nod, cu excepția cazului în care le spui să caute în istoricul tranzacțiilor, așa că „nu pot să-l găsesc” poate însemna uneori „cauți la adâncimea greșită.” Exploratoarele pot arăta un număr de confirmări numerice în timp ce portofelele comprimă totul într-o singură etichetă, iar acea nepotrivire poate părea dezacord. Și în fundal, alegerea fork-ului își face în continuare treaba: un bloc poate fi văzut, apoi deprioritizat, ceea ce este exact motivul pentru care „procesat” există ca un stat de încredere mai mică. Ceea ce mă surprinde este cât de des confuzia provine din amestecarea nivelurilor. Dacă trimiți cu o presupunere de angajament și apoi întrebi cu alta, poți fabrica o discrepanță. Când tratez confirmarea ca o scară mobilă—segnal rapid întâi, garanție mai puternică puțin mai târziu—numerele diferite încep să se simtă informative în loc de alarmante.
@Fogo Official #Fogo #fogo $FOGO
