𝗧𝗼 𝗕𝗔𝗠 𝗼𝗿 𝗻𝗼𝘁 𝘁𝗼 𝗕𝗔𝗠 💥🤔 Seguendo il consiglio di @0xMert, il team ha scritto un blog che presenta ogni contro-argomento contro BAM. Consulta il link qui sotto. Immergiamoci in questo 🧵 ⬇️

"𝗕𝗔𝗠 𝗲̀ 𝘂𝗻 𝗾𝘂𝗮𝗱𝗿𝗼 𝗰𝗲𝗻𝘁𝗿𝗮𝗹𝗶𝘇𝗮𝘁𝗼 𝗰𝗼𝗻 𝘂𝗻𝗮 𝗺𝗼𝗻𝗼𝗽𝗼𝗹𝗶 𝗱𝗲𝗹 𝗯𝗹𝗼𝗰𝗸-𝗯𝘂𝗶𝗹𝗱𝗶𝗻𝗴." 𝘚𝘵𝘦𝘦𝘭𝘮𝘢𝘯: Questa critica sostiene che BAM introduce un unico sequencer che si occuperà di tutta la programmazione delle transazioni per Solana. Anche se l'infrastruttura è distribuita, le regole di programmazione provengono da un unico sistema, controllato da Jito. Gli stakeholder temono che questo minacci la naturale diversità dei programmatori di Solana, riducendola a uno che potrebbe comportarsi come un sequencer centralizzato, diventando un unico punto di fallimento e concentrando troppo potere in un solo programmatori e in un'unica parte. BAM è progettato affinché nessun singolo ente possa controllare l'ordinamento delle transazioni. Il sistema decentralizzerà la sua operazione e la governance della logica di programmazione attraverso: • 𝗼𝗽𝗲𝗻 𝗽𝗮𝗿𝘁𝗶𝗰𝗶𝗽𝗮𝘁𝗶𝗼𝗻: qualsiasi operatore idoneo può partecipare e gestire il proprio nodo BAM. • 𝗴𝗹𝗼𝗯𝗮𝗹 𝗰𝗼𝘃𝗲𝗿𝗮𝗴𝗲: i nodi BAM saranno distribuiti in una rete di operatori geograficamente diversificata. • 𝗼𝗽𝗲𝗻-𝘀𝗼𝘂𝗿𝗰𝗲, 𝘃𝗲𝗿𝗶𝗳𝗶𝗮𝗯𝗹𝗲 𝘀𝗰𝗵𝗲𝗱𝘂𝗹𝗶𝗻𝗴: tutto il codice BAM sarà open source e verificabile tramite attestazioni crittografiche. Sebbene sia vero che i nodi BAM siano attualmente gestiti esclusivamente da Jito, a partire dal Q1 '26 il codice sarà reso open source e operatori indipendenti saranno integrati.

“𝗔𝘀 𝗮 𝘃𝗮𝗹𝗶𝗱𝗮𝘁𝗼𝗿, 𝗕𝗔𝗠 𝘁𝗶𝗲𝘀 𝗺𝗲 𝘂𝗽 𝘁𝗼 𝗼𝗻𝗹𝘆 𝗼𝗻𝗲 𝘀𝗰𝗵𝗲𝗱𝘂𝗹𝗲𝗿” 𝘚𝘵𝘦𝘦𝘭𝘮𝘢𝘯: Questa critica afferma che, optando per BAM, un validatore rinuncia effettivamente al controllo sull'ordinamento delle transazioni a favore di un unico pianificatore. Invece di poter eseguire o adottare diversi pianificatori, sperimentare le proprie strategie o passare tra design concorrenti, sono vincolati a un solo sistema. Per abilitare i Mercati di Capitale Internet, Solana ha bisogno di regole di ordinamento deterministiche e trasparenti. La frammentazione danneggia gli utenti. BAM rende questo possibile con la costruzione di blocchi standardizzati e verificabili richieste dalle app ad alte prestazioni. I fatti sono: • BAM è strettamente su base volontaria. • I validatori possono tornare ai client Agave, Jito-Solana o Firedancer • Possono disconnettersi da BAM in qualsiasi momento I plugin BAM offrono una piattaforma per l'ottimizzazione e l'innovazione degli sviluppatori che beneficia tutti di Solana.

"𝗕𝗔𝗠 𝗺𝗼𝗻𝗼𝗽𝗼𝗹𝗶𝘇𝗲𝘀 𝗦𝗼𝗹𝗮𝗻𝗮 𝗼𝗿𝗱𝗲𝗿𝗳𝗹𝗼𝘄." 𝘚𝘵𝘦𝘦𝘭𝘮𝘢𝘯: Gli stakeholder sostengono che aggregare le transazioni pubbliche in un'unica pipeline crea un collo di bottiglia centrale attraverso il quale passa tutto l'orderflow e offre vantaggi a chiunque lo controlli. Anche se inizialmente neutrale, BAM controlla l'order flow, il che può rafforzare la sua posizione competitiva e impedire ad altre soluzioni di guadagnare terreno. BAM raccoglie le transazioni utilizzando il meccanismo standard TPU di Solana. Non c'è distinzione tra "transazioni BAM" e quelle pubbliche. I validatori ricevono lo stesso flusso pubblico, solo programmato attraverso uno strato verificabile. I validatori possono tornare al loro TPU nativo istantaneamente senza costi di switching, mantenendo l'orderflow pubblico piuttosto che frammentato in canali privati.

“𝗕𝗔𝗠 𝗶𝗻𝘁𝗿𝗼𝗱𝘂𝗰𝗲𝘀 𝗲𝘅𝘁𝗿𝗮 𝗹𝗮𝘁𝗲𝗻𝗰𝘆 𝘃𝘀. 𝘃𝗮𝗹𝗶𝗱𝗮𝘁𝗼𝗿’𝘀 𝗻𝗮𝘁𝗶𝘃𝗲 𝗧𝗣𝗨.” 𝘚𝘵𝘦𝘦𝘭𝘮𝘢𝘯: Gli stakeholder sostengono che uno dei vantaggi prestazionali di Solana deriva dal fatto che le transazioni fluiscono direttamente verso il TPU del leader con minimi passaggi. Qualsiasi strato di instradamento intermedio, anche se veloce, rischia di aggiungere latenza, jitter e nuovi punti di guasto sotto carico, e potrebbe indebolire la missione IBRL rispetto alla programmazione nativa del TPU. BAM garantisce una latenza minima grazie a una rete globale di oltre 100 nodi e a una co-locazione strategica, mantenendo i tempi di andata e ritorno sotto i 5 ms. Il nostro stack TEE è altamente ottimizzato utilizzando il pinning dei thread e l'isolamento della CPU, raggiungendo parità di prestazioni con Agave. Con la prossima migrazione a DoubleZero, ci aspettiamo di superare i benchmark delle prestazioni bare metal.

“𝗕𝗔𝗠 𝗽𝗿𝗼𝗱𝘂𝗰𝗲𝘀 𝗹𝗲𝘀𝘀 𝗿𝗲𝘄𝗮𝗿𝗱𝘀 𝘃𝘀. 𝗼𝘁𝗵𝗲𝗿 𝗰𝗹𝗶𝗲𝗻𝘁𝘀” 𝘚𝘵𝘦𝘦𝘭𝘮𝘢𝘯: I validatori hanno espresso preoccupazioni sul fatto che la logica di programmazione di BAM potrebbe ridurre le mance e i premi complessivi rispetto ad altri costruttori di blocchi o opportunità di programmazione. Inoltre, i mercati delle commissioni dei Plugin non sono ancora attivi, rendendo il potenziale teorico mentre il rischio appare immediato. Diamo priorità alla massimizzazione del profitto a lungo termine. I premi di BAM sono già comparabili a quelli di Jito-Agave. Le disparità passate erano guidate da programmatori temporanei ed estrattivi altrove che stanno venendo deprecati. I futuri rendimenti saranno guidati dai Plugin e da ACE, sbloccando flussi di commissioni sostenibili da nuove attività economiche piuttosto che da giochi a breve termine.

“𝗖𝗼𝗺𝗲 𝗮 𝘂𝗻 𝘃𝗮𝗹𝗶𝗱𝗮𝘁𝗼𝗿𝗲, 𝗱𝗲𝘃𝗼 𝗱𝗮𝗿𝗲 𝗮𝗶 𝗺𝗶 𝘀𝘁𝗮𝗸𝗲𝗿 𝗶𝗹 𝗺𝗮𝗴𝗴𝗶𝗼𝗿 𝗿𝗲𝗻𝗱𝗶𝗺𝗲𝗻𝘁𝗼.” 𝘚𝘵𝘦𝘦𝘭𝘮𝘢𝘯: I staker spesso scelgono i validatori esclusivamente in base ai premi. Anche una piccola diminuzione delle mance o una variazione nei guadagni durante un'epoca possono far fluire lo stake delegato altrove. I validatori temono che adottare BAM precocemente possa metterli in una posizione di svantaggio competitivo se i colleghi ritardano l'adozione. Comprendiamo che i validatori devono massimizzare il rendimento per se stessi e per i loro staker, ma devono anche considerare gli effetti di secondo ordine delle loro azioni. L'hacking del rendimento a breve termine (sandwiching, slot-lagging) degrada la qualità complessiva dell'esecuzione e allontana la liquidità. L'unico percorso sostenibile verso un rendimento più elevato è un'attività onchain più profonda, che può essere abilitata solo da migliori applicazioni, liquidità più profonda e spread più ristretti.

"L'esecuzione controllata dalle applicazioni (ACE) non è importante." 𝘚𝘵𝘦𝘦𝘭𝘮𝘢𝘯: Gli stakeholder sostengono che le applicazioni Solana funzionano già bene sotto i meccanismi di inclusione delle commissioni prioritarie e delle mance. Introdurre ACE potrebbe aumentare la complessità e creare garanzie di esecuzione disuguali tra app sofisticate e sviluppatori più piccoli. Temono che consentire alle applicazioni di definire la logica di ordinamento potrebbe portare a un privilegio di BAM per alcuni attori. Le app sofisticate necessitano di garanzie come la priorità di cancellazione o la priorità di liquidazione per funzionare in sicurezza. Hyperliquid gestisce un volume 10-15 volte superiore a quello dei perps di Solana specificamente a causa del suo set di validatori autorizzati che impone un ordinamento rigoroso. Senza ACE, queste app migreranno verso L1 o L2 personalizzati per ottenere quelle garanzie.

“𝗙𝗜𝗙𝗢 𝗼𝗿𝗱𝗲𝗿𝗶𝗻𝗴 𝗶𝘀 𝘁𝗵𝗲 𝗳𝗮𝗶𝗿𝗲𝘀𝘁 𝘁𝗿𝗮𝗻𝘀𝗮𝗰𝘁𝗶𝗼𝗻 𝗼𝗿𝗱𝗲𝗿𝗶𝗻𝗴 𝗹𝗼𝗴𝗶𝗰” 𝘚𝘵𝘦𝘦𝘭𝘮𝘢𝘯: Gli stakeholder sostengono che un semplice ordinamento FIFO (first-in, first-out) sia il modo più equo e neutrale per programmare le transazioni su Solana. Rispecchia la priorità temporale dei mercati tradizionali, è facile da comprendere per gli utenti (“se la mia tx arriva prima, viene eseguita prima”) e evita le dinamiche “pay-to-win” della maggior parte delle blockchain. Sebbene il FIFO appaia il più equo elaborando le transazioni nell'ordine in cui vengono ricevute, incoraggia gli utenti a spammare la rete per assicurarsi una posizione favorevole, portando a congestione e gare di latenza che bruciano denaro. Questo si rompe quando la domanda di rete è alta, causando ritardi imprevedibili per tutti gli utenti man mano che le code si allungano. L'approccio one-size-fits-all del FIFO non riesce a soddisfare le esigenze delle app che richiedono un ordinamento specifico delle transazioni per funzionare in modo ottimale.

"𝗔𝗿𝗲𝗻'𝘁 𝗕𝗔𝗠'𝘀 𝗧𝗿𝘂𝘀𝘁𝗲𝗱 𝗘𝘅𝗲𝗰𝘂𝘁𝗶𝗼𝗻 𝗘𝗻𝘃𝗶𝗿𝗼𝗻𝗺𝗲𝗻𝘁𝘀 (𝗧𝗘𝗘𝘀) 𝘃𝘂𝗹𝗻𝗲𝗿𝗮𝗯𝗹𝗲 𝘁𝗼 𝗮𝘁𝘁𝗮𝗰𝗸𝘀?" 𝘚𝘵𝘦𝘦𝘭𝘮𝘢𝘯: I TEEs hanno una storia di vulnerabilità da canali laterali, bug del firmware e rischi della catena di fornitura. Gli stakeholder sostengono che fare affidamento sui TEEs per la pianificazione dei blocchi potrebbe introdurre modalità di guasto correlate: se un exploit hardware colpisce SEV-SNP, BAM come rete potrebbe essere compromessa. Sostengono anche che i TEEs spostano la fiducia sui fornitori di hardware e sui fornitori di data center. BAM funziona su AMD SEV-SNP con attestazioni crittografiche in data center sicuri e conformi (ISO 27001/SOC 2). Anche in caso di compromissione hardware nel peggiore dei casi, le chiavi dei validatori rimangono sicure e la storia della catena non può essere riscritta, solo la privacy dell'ordinamento su quel nodo specifico è influenzata. I validatori verificano il "TCB misurato" e possono rifiutare firmware difettosi tramite attestazione.

@0xmert Il futuro della costruzione di blocchi sta passando da una programmazione frammentata a un mercato trasparente e verificabile. BAM è la soluzione. Milioni devono BAM! 💥