Ce se rupe de obicei prima sub încărcare nu este capacitatea de procesare, ci sincronizarea. Când o rețea devine aglomerată, blocurile nu se umplu doar, ci devin mai greu de prezis. Tranzacțiile sosesc, comisioanele cresc, validatoarele reordonează, iar drumul de la trimiterea unei tranzacții la a o vedea executată devine incert. Am văzut strategii care par precise în testare eșuând în producție pur și simplu pentru că ordinea de execuție s-a schimbat cu o fracțiune de secundă. O lichidare lipsește pentru că aterizează cu o poziție mai târziu decât se aștepta. Un arbitraj în mai multe etape finalizează prima etapă, dar a doua etapă vede o stare ușor diferită pentru că o altă tranzacție a intervenit între timp. Acestea nu sunt eșecuri dramatice. Sunt mici schimbări în ordonare care schimbă liniștit rezultatele.
În interiorul Fogo, diferența apare în modul în care este gestionată acea ordonare. Sistemul face o alegere deliberată în jurul programării deterministe. Tranzacțiile nu sunt constant reordonate pe baza unor mici diferențe de taxe odată ce intră într-o fereastră de programare. Ele sunt plasate în felii definite de timp și ordonate într-un mod previzibil în cadrul acelor feliuțe. Sub trafic greu, acea alegere devine vizibilă. În loc să observi constructorul de blocuri ajustând continuu pozițiile în răspuns la presiunea taxelor, vezi o structură mai fixă. Dacă o tranzacție intră într-o limită de programare dată la timp, poziția sa relativă este stabilă. Dacă sosește prea târziu, nu concurează în interiorul acelei limite prin licitarea mai mare. Se mută la următoarea.
Am realizat o strategie de tranzacții multiple pe parcursul unor blocuri consecutive în timpul unui test de congestie. Pe multe sisteme, chiar și atunci când proiectezi tranzacții pentru a se executa secvențial, există întotdeauna riscul ca o tranzacție neînrudită să se strecoare între ele, deoarece ordonarea rămâne fluidă până în ultimul moment. Pe Fogo, acea fluiditate este redusă. Odată ce tranzacțiile sunt în interiorul aceleași felii de programare, există mult mai puțin reordonare în mijlocul ferestrei. Secvența fie se execută conform modelului în acea limită, fie se mută curat la următoarea. Nepredictibilitatea care apare de obicei sub stres este înlocuită de o coadă mai clară.
Aceasta produce un tip diferit de limitare. Pe cele mai multe lanțuri cu variație mare, dacă observi că urmează să pierzi o poziție, poți încerca să-ți crești taxa și să avansezi în același bloc. Rezultatul este incert, dar opțiunea există. Pe Fogo, acea opțiune este constrânsă. Schedulerul prioritizează ordonarea previzibilă în detrimentul re-prețuirii în ultimul moment. Odată ce o limită de programare este definită eficient, creșterea taxei tale nu garantează că vei sări înainte în cadrul acelei feliute. Dacă ratezi fereastra, aștepți. Sistemul reduce variația temporară, dar reduce și abilitatea de a reacționa în interiorul acelei feronțe temporale.
Stratul de propagare susține această structură. Validatorii se coordonează în jurul intervalelor de timp definite, iar propagarea tranzacțiilor este ajustată pentru a converge în limitele latenței înainte de finalizare. Designul nu urmărește să maximizeze flexibilitatea în compunerea blocurilor în ultimul moment posibil. Scopul este de a asigura că ceea ce văd validatorii se aliniază rapid și constant. Când traficul crește, sistemul protejează acele garanții temporale în loc să se extindă pentru a absorbi mai multe reordonări oportuniste. Rezultatul este că, sub stres, vezi o coadă ordonată mai degrabă decât o re-prețuire haotică.
Am testat un arbitraj sensibil la latență care depindea de mici intervale de timp între două piețe legate. Pe sisteme mai elastice, există momente când o actualizare de stare este vizibilă, în timp ce alta întârzie puțin. Acea fereastră poate crea oportunitate. Pe Fogo, acele feronțuri sunt mai înguste, deoarece tranzițiile de stare se propagă și se finalizează în intervale de timp mai strânse. Validatorii observă schimbările în aliniere mai apropiată. Logica de arbitraj s-a executat corect, dar avantajul a scăzut deoarece sistemul a redus ambiguitatea de care depindea strategia. Nimic nu a funcționat greșit. Mediu a oferit pur și simplu mai puțină asimetrie temporală de exploatat.
Coordonarea validatorului în acest model implică cerințe reale. Pentru a menține programarea deterministă și latența limitată, validatorii au nevoie de performanțe și conectivitate fiabile. În timpul unui test de stres cu o întârziere minoră de propagare între noduri geografic îndepărtate, sistemul a preferat să întârzie finalizarea puțin mai degrabă decât să permită vederi divergente ale tranzacțiilor să treacă și să se reconcilieze mai târziu. Consistența a fost păstrată, dar cu costul unor așteptări mai stricte de infrastructură. Designul tolerează mai puțină variație în performanța validatorilor, deoarece garanțiile temporale depind de aceasta.
O condiție de limitare a făcut compromisurile clare. Un grup de tranzacții care vizează același contract a sosit aproape de marginea unei feronțe de programare. Unele au intrat în feliuta curentă. Altele, doar puțin mai târziu, s-au mutat la următoarea. Pe un sistem condus de taxe, acele tranzacții întârziate ar fi încercat să liciteze mai mult și să forțeze o reordonare parțială în cadrul aceluiași bloc. Pe Fogo, separarea a rămas clară. Schedulerul nu a redeschis limita pentru a acomoda licitatii mai mari. Pentru o aplicație care se bazează pe secvențiere stabilă, această predictibilitate a fost benefică. Pentru un trader care încearcă să se introducă înaintea concurenților în ultimul moment, oportunitatea nu a existat.
Determinismul execuției se extinde prin finalizare. Deoarece ordonarea este strâns legată de limitele programării, finalizarea se comportă ca o continuare a acelei structuri, mai degrabă decât o a doua etapă de filtrare probabilistică. În timpul vârfurilor de încărcare, nu am observat micro-reorganizări oportuniste folosite pentru a captura taxe mai mari prin alterarea ordinii tranzacțiilor. Mecanicile sistemului reduc stimulentele și spațiul pentru acel comportament. Timpul rămâne controlat, iar ordonarea rămâne aliniată între validatorii.
Implicările depind de ceea ce construiești sau rulezi. Dacă aplicația ta necesită execuție multi-pas coordonată strâns, unde intercalarea neașteptată ar putea distruge presupunerile, rigiditatea Fogo simplifică mediu. Poți estima timpul de includere cu o incertitudine mai mică. Ești mai puțin expus la reordonări bruște provocate de presiunea taxelor. Dacă, totuși, strategia ta depinde de exploatarea ambiguității ordonării, re-prețuirea dinamică sau neconcordanțele temporale scurte între participanți, mediu oferă mai puțină flexibilitate. Aceleași mecanisme care reduc variația reduc, de asemenea, manevrarea strategică.
Există o fricțiune onestă în acest design. Programarea deterministă cu latență limitată necesită performanțe disciplinate din partea validatorilor și ridică costurile infrastructurii. Instrumentele construite în jurul escaladării elastice a taxelor trebuie să se adapteze la un sistem în care licitarea târzie are un impact limitat în cadrul unei limite de programare. Unele strategii își pierd avantajul nu pentru că sunt defectuoase, ci pentru că mediu nu mai produce inconsistențe temporale de care se bazau.
Ce se prăbușește de obicei sub încărcare este predictibilitatea timpului de execuție. Pe Fogo, acea predictibilitate se menține în mare măsură. Compromisul este că abilitatea de a remodela timpul în ultimul moment devine constrânsă structural.