$FOGO per una ragione che non ha nulla a che fare con i numeri della classifica, e tutto a che fare con come la catena esercita silenziosamente pressione sui costruttori per crescere nella loro architettura, perché quando costruisci su un L1 basato su SVM non stai solo scegliendo un ambiente più veloce, stai scegliendo un modello di esecuzione che premia un buon design dello stato ed espone un cattivo design dello stato senza pietà.
Fogo sembra essere modellato attorno all'idea che la velocità non dovrebbe essere un'affermazione cosmetica, perché se i blocchi sono veramente veloci e il runtime può elaborare lavoro indipendente contemporaneamente, allora l'applicazione diventa il vero collo di bottiglia, e quel cambiamento è dove la storia SVM diventa interessante, poiché il runtime sta essenzialmente ponendo a ogni sviluppatore la stessa domanda nel momento in cui arrivano utenti reali, cioè se le loro transazioni sono realmente indipendenti o se hanno accidentalmente progettato un blocco condiviso che tutti devono toccare.
L'esecuzione parallela sembra semplice quando viene spiegata come transazioni che vengono eseguite insieme, ma il dettaglio pratico che cambia tutto è che funziona solo quando due transazioni non si contendono lo stesso stato, e su SVM lo stato non è un blob invisibile che la catena interpreta come vuole, lo stato è esplicito e concreto, e ogni transazione deve dichiarare cosa leggerà e cosa scriverà, il che significa che la catena può pianificare il lavoro con fiducia quando quelle dichiarazioni non si sovrappongono, e significa anche che la catena non può salvarti dal tuo stesso layout quando costringi tutto a sovrapporsi.
Questa è la parte che la maggior parte dei commenti superficiali ignora, perché le persone parlano come se le prestazioni vivessero a livello di catena, ma su Fogo, nel momento in cui inizi a modellare un'applicazione, le prestazioni diventano qualcosa che progetti nel modo in cui gli account e i dati sono separati, ed è per questo che due app sulla stessa catena possono sentirsi completamente diverse sotto stress, con una che rimane fluida mentre l'altra rimane inspiegabilmente bloccata, anche se entrambe si trovano nello stesso ambiente di esecuzione veloce.
Ho notato che quando i costruttori provengono da abitudini di esecuzione sequenziale, portano un istinto che sembra sicuro ma diventa costoso su SVM, che è l'istinto di mantenere un oggetto di stato centrale che ogni azione aggiorna, perché rende il ragionamento sul sistema pulito, rende l'analisi facile e fa sentire il codice come se avesse una singola fonte di verità, ma su una catena SVM quel design stesso diventa un freno silenzioso, perché ogni azione dell'utente sta ora cercando di scrivere nello stesso posto, quindi anche se il runtime è pronto per eseguire in parallelo, la tua applicazione ha creato una singola corsia in cui tutto deve entrare.
Ciò che cambia su @Fogo Official è che il layout dello stato smette di essere solo stoccaggio e inizia a essere politica di concorrenza, poiché ogni account scrivibile diventa una sorta di lucchetto, e quando metti troppo dietro un solo lucchetto non rallenti solo un piccolo componente, crolli il parallelismo per l'intero flusso, e la catena non ha bisogno di essere congestionata per farti sentire, perché il tuo stesso design del contratto genera la congestione costringendo utenti non correlati a collidere sullo stesso set di scritture.
Il modo più utile per pensarci è trattare ogni pezzo scrivibile di stato come una decisione su chi è autorizzato a procedere contemporaneamente, e l'obiettivo di design diventa ridurre le collisioni non necessarie, il che non significa rimuovere completamente lo stato condiviso, poiché alcuni stati condivisi sono essenziali, ma significa essere disciplinati riguardo a ciò che deve essere condiviso e ciò che era solo condiviso per comodità, poiché la comodità è dove l'esecuzione parallela muore silenziosamente.
Su Fogo, i modelli che mantengono le applicazioni rapide sono raramente complicati, ma sono rigorosi, perché richiedono a uno sviluppatore di separare aggressivamente lo stato dell'utente, di isolare lo stato specifico del mercato invece di spingere tutto attraverso un unico oggetto di protocollo globale, e di smettere di scrivere in account condivisi che sono per lo più lì per il monitoraggio e la visibilità, poiché quelle metriche derivate possono esistere senza diventare parte del percorso di scrittura critico per ogni transazione.
Quando guardo ai design paralleli di successo, tendono a trattare le azioni degli utenti come per lo più locali, dove un utente tocca il proprio stato e una fetta ristretta di stato condiviso che è realmente necessaria, e la fetta condivisa è strutturata in un modo che non costringe utenti non correlati a contendere, ed è per questo che la separazione per utente non è solo un trucco di organizzazione elegante, è una strategia di throughput, e la separazione per mercato non è solo una scelta architettonica pulita, è la differenza tra un mercato attivo che trascina tutto verso il basso e più mercati che fluiscono indipendentemente.
La trappola nascosta è che gli sviluppatori scrivono spesso stato condiviso perché vogliono una verità globale istantanea, come totali di commissioni globali, contatori di volume globali, tracker di attività globali, classifiche globali o metriche di protocollo globali, e il problema non è che quelle metriche siano cattive, il problema è che quando le aggiorni nella stessa transazione di ogni azione dell'utente, inietti una scrittura condivisa in ogni percorso, quindi ogni percorso ora confligge, e all'improvviso hai costruito un'applicazione sequenziale all'interno di un runtime parallelo, e non importa quanto sia veloce Fogo, perché il tuo stesso design costringe la catena a trattare il lavoro indipendente come lavoro dipendente.
Ciò che cambia nell'esecuzione parallela, in un senso molto pratico, è che i costruttori sono spinti a separare lo stato di correttezza dallo stato di report, e sono spinti ad aggiornare lo stato di report su un ritmo diverso, o a scriverlo in segmenti shardati, o a derivarlo da sentieri di eventi, perché una volta che smetti di forzare ogni transazione a scrivere lo stesso account di report, il runtime può finalmente pianificare lavoro reale in parallelo, e l'applicazione inizia a sentirsi come se appartenesse a una catena SVM invece di semplicemente funzionare su una.
Questo diventa ancora più visibile nelle applicazioni di stile trading, dove la postura di Fogo rende la discussione più concreta, poiché il trading concentra l'attività, e la concentrazione crea contesa, e la contesa è il nemico dell'esecuzione parallela, quindi se un sistema di trading è progettato attorno a uno stato centrale di orderbook che deve essere mutato per ogni interazione, la catena serializzerà quelle interazioni non importa quanto siano veloci i blocchi, e l'esperienza dell'utente degraderà esattamente quando conta di più, ed è per questo che i costruttori sono costretti a design più difficili ma migliori, dove i componenti più caldi sono minimizzati, dove lo stato è partizionato, dove i percorsi di regolamento sono ristretti e dove le parti che non devono essere mutate in ogni azione sono rimosse dal percorso critico.
La stessa logica si presenta nelle applicazioni in tempo reale che le persone presumono saranno facili su una catena veloce, come i sistemi interattivi che si aggiornano frequentemente, perché l'approccio ingenuo è mantenere un singolo stato mondiale e mutarlo costantemente, ma su @Fogo Official questo diventa un punto di collisione garantito, poiché ogni partecipante sta cercando di toccare lo stesso oggetto scrivibile, quindi l'approccio migliore è isolare lo stato per partecipante, localizzare le zone condivise invece di globalizzarle, e trattare gli aggregati globali come qualcosa che viene aggiornato in modo più controllato, perché nel momento in cui smetti di far sì che ogni azione scriva allo stesso oggetto condiviso, il runtime può iniziare a eseguire molte azioni insieme, e questo è dove la velocità percepita diventa reale.
Nella logica in stile alta frequenza, che è dove le catene a bassa latenza vengono spesso giudicate severamente, l'esecuzione parallela rende impossibili da nascondere i difetti di design, perché quando molti attori inviano azioni rapidamente, qualsiasi stato scrivibile condiviso diventa un campo di battaglia, e invece di costruire un sistema dove molti flussi progrediscono in modo indipendente, costruisci un sistema dove tutti corrono per la stessa serratura, e il risultato non è solo un'app più lenta, è una dinamica di mercato diversa, perché l'ordinamento è dominato dalla contesa piuttosto che dalla strategia, ed è per questo che i migliori design tendono a isolare le scritture, ridurre la mutazione condivisa e trattare i componenti contestati come ristretti e deliberati piuttosto che ampi e accidentali.
Le applicazioni pesanti di dati mostrano lo stesso schema in modo più silenzioso, perché la maggior parte dei consumatori di dati ha solo bisogno di leggere, e le letture non sono il problema, ma quando i flussi dei consumatori iniziano a scrivere dati condivisi per comodità, come timbrare valori in account globali o aggiornare cache condivise, avvelenano il parallelismo senza un reale guadagno, e l'approccio migliore è lasciare che i consumatori leggano i dati condivisi e scrivano solo le proprie decisioni, perché una volta che mantieni le scritture condivise confinate a flussi di aggiornamento dedicati, proteggi la concorrenza per tutti gli altri.
Il compromesso che Fogo chiede implicitamente agli sviluppatori di accettare è che l'architettura amichevole per il parallelo non è gratuita, perché una volta che shard lo stato e separi gli account, stai gestendo più componenti, stai ragionando su più bordi, e stai costruendo sistemi dove la concorrenza è reale piuttosto che teorica, il che significa che i test devono essere più rigorosi, i percorsi di aggiornamento devono essere più attenti e l'osservabilità deve essere migliore, ma la ricompensa è che l'applicazione può scalare nel modo in cui un runtime SVM è progettato per supportare, dove azioni indipendenti procedono veramente insieme invece di aspettare dietro un collo di bottiglia globale.
L'errore che distrugge la maggior parte del vantaggio parallelo non è un errore avanzato, è un errore semplice, che consiste nel creare un unico account scrivibile condiviso che ogni transazione tocca, e su una catena come Fogo quell'errore è particolarmente costoso, poiché più veloce diventa la catena, più è evidente che il tuo stesso design è il limitatore, e quella visibilità non è un fallimento della catena, è la catena che rivela cos'è realmente l'architettura.
Fogo in questo contesto rende la conversazione tra costruttori più onesta, perché non basta dire che la catena è veloce, il modello della catena costringe uno sviluppatore a dimostrare di meritare quella velocità, e la prova sta nel modo in cui lo stato è plasmato, partizionato e accessibile, ed è per questo che l'esecuzione parallela non è un dettaglio di marketing, è una disciplina che cambia il modo in cui le applicazioni vengono costruite, ed è anche per questo che un L1 basato su SVM come Fogo non è semplicemente più veloce, è più esigente, poiché chiede agli sviluppatori di progettare tenendo a mente i conflitti, di trattare lo stato come una superficie di concorrenza e di costruire sistemi che rispettano l'idea che le prestazioni riguardano tanto il layout quanto il runtime.
