Când piețele explodează, partea dificilă a unui schimb nu este să faci clic pe „schimb.” Este să știi rapid ce este de fapt adevărat după aceea. Tranzacționarea pe lanț se simte utilizabilă doar în piețele rapide când confirmările sosesc rapid și consistent, astfel încât poți acționa pe baza lor fără a ghici. Acea „momentul finalizat” contează mai mult decât debitul maxim, deoarece următoarea ta decizie depinde de dacă actualizarea stării anterioare a aterizat cu adevărat.
O fitil atinge, schimbi într-o acoperire, iar interfața arată „trimis.” În următoarea secundă nu știi dacă soldul tău s-a schimbat, dacă tranzacția ta va fi inclusă sau dacă ar trebui să încerci din nou. Oamenii panică-clic, retrimit sau acoperă de două ori pe o altă platformă. Costul nu este doar taxe; este expunerea accidentală creată de incertitudine.
Fogo este construit pentru a reduce fereastra de incertitudine tratând distanța de rețea și variația evaluatorilor ca principalii dușmani ai confirmării. Principala sa alegere de design este „consensul multi-local” bazat pe zone: validatorii sunt grupați în zone geografice, iar doar o zonă este activă pentru consens la un moment dat, astfel încât cvorumul care trebuie să fie de acord este fizic aproape și poate comunica cu o latență mult mai mică. Protocolul descrie selectarea și rotirea zonelor (inclusiv o idee de rotație „urmărește soarele”), astfel încât cvorumul activ să se poată mișca în timp în loc să fie blocat într-o singură geografie.
A doua alegere este aplicarea performanței. Fogo standardizează pe un client validator de înaltă performanță bazat pe Firedancer (cu un hibrid interimar menționat în documente), având ca scop reducerea latenței de fundal - cele mai lente excepții care domină întârzierile percepute de utilizator sub sarcină. Când piața este haotică, nu simți „nodul mediu.” Simți cea mai lentă cale care trebuie totuși așteptată.
Pentru a face acest lucru concret, este util să descriem cum este reprezentată „adevărul”. Ca în sistemele de tip Solana, starea Fogo este un set de conturi: soldurile tokenurilor trăiesc în conturi de tokenuri, iar un schimb actualizează mai multe conturi simultan (contul tău de tokenuri de intrare scade, contul tău de tokenuri de ieșire crește, iar conturile pool-ului se schimbă). Schimbul este atomic, ceea ce înseamnă că fie se întâmplă totul, fie nimic din el—deci „adevărul după schimb” este pur și simplu noua stare a contului.
Calea de la acțiunea utilizatorului la confirmare este directă. Semnezi o tranzacție, o trimiți în rețea, iar liderul actual o prelucrează, verifică semnătura, execută schimbul împotriva stării contului actual și înregistrează rezultatul în registru. Alți validatori votează pe acea istorie. În acest model, „confirmat” înseamnă că o supermajoritate a stării a votat pentru lanțul care conține schimbul tău; „finalizat” vine mai târziu, după ce blocajele de vot s-au acumulat la maximum (de obicei rezumat ca necesitând multe confirmări pe deasupra, precum „31+”).
De ce contează asta în timpul vârfurilor? Pentru că vârfurile se referă cu adevărat la timp. Prețul se mișcă mai repede decât oamenii pot raționa, iar acțiunile de tranzacționare se leagă între ele. Dacă confirmarea este lentă sau inconsistentă, nu poți face în siguranță pasul doi: nu știi dacă să desfaci, dacă marja ta este acoperită sau dacă ar trebui să anulezi comanda de urmărire pe care tocmai ai plasat-o. Confirmarea rapidă transformă următoarea ta acțiune dintr-o presupunere într-un răspuns.
Poziția actuală a Fogo reflectă această prioritate. Documentele descriu testnet-ul care vizează blocuri de 40 de milisecunde cu rotație frecventă a liderilor și schimbări de zonă, iar documentația mainnet arată o configurație de rețea activă cu parametrii RPC publici și o configurație de zonă activă.
Schimbi în stablecoins în timpul unei scăderi bruște, apoi plasezi imediat o comandă limită pentru a reintra mai jos. Dacă schimbul se confirmă rapid, dimensiunea comenzii tale folosește soldul tău real; dacă nu, îți dimensionezi pe o miraj.
Părerea mea personală este că majoritatea dezbaterilor despre „viteză” ratează stratul emoțional: oamenii nu se supără să aștepte când sistemul este onest în privința asta, dar urăsc să acționeze pe o stare care se schimbă ulterior. Calitatea confirmării este locul în care UX-ul pe lanț fie câștigă încredere, fie o pierde, în special odată ce automatizezi tranzacțiile. Dacă Fogo poate face confirmările predictibile sub stres, nu se va simți ca un lanț mai rapid; se va simți ca unul mai calm.
Dacă ai putea obține o confirmare rapidă și de încredere în timpul unui fitil pe Fogo, ai folosi mai mult schimburi pe lanț, da sau nu?
