Å BAM eller ikke BAM 💥🤔 Etter å ha fulgt @0xMert sitt råd, skrev teamet en blogg hvor de stålmannet alle motargumenter mot BAM. Se lenken nedenfor. La oss dykke ned i det 🧵 ⬇️

"BAM er en sentralisert sekvenser med monopol på blokkbygging." Steelman: Denne kritikken hevder at BAM introduserer en enkelt sekvenser som skal håndtere all transaksjonsplanlegging for Solana. Selv om infrastrukturen er distribuert, stammer planleggingsreglene fra ett system, som kontrolleres av Jito. Interessenter frykter at dette undergraver Solanas naturlige mangfold av planleggere til en som kan oppføre seg som en sentralisert sekvenser, bli et enkelt feilpunkt og konsentrere for mye innflytelse i én planlegger og én part. BAM er designet slik at ingen enkelt enhet kan kontrollere transaksjonsrekkefølgen. Systemet vil desentralisere sin drift og styring av planleggingslogikk gjennom: • åpen deltakelse: enhver kvalifisert operatør kan delta og drive sin egen BAM-node. • global dekning: BAM-noder vil bli distribuert over et geografisk variert nettverk av operatører. • åpen kildekode, verifiserbar planlegging: all BAM-kode vil være åpen kildekode og kan revideres via kryptografiske attesteringer. Selv om det er sant at BAM-noder for øyeblikket kun drives av Jito, vil kodebasen fra og med første kvartal 2026 være åpen kildekode og uavhengige operatører vil bli ombordkommet.

"Som validator binder BAM meg til bare én planlegger" Steelman: Denne kritikken sier at ved å velge BAM, overgir en validator effektivt kontrollen over transaksjonsrekkefølgen til én enkelt planlegger. I stedet for å kunne kjøre eller ta i bruk ulike planleggere, eksperimentere med egne strategier, eller bytte mellom konkurrerende design, er de bundet til ett system. For å muliggjøre internettkapitalmarkeder trenger Solana deterministiske og transparente bestillingsregler. Fragmentering skader brukerne. BAM gjør dette mulig med standardisert, verifiserbar blokkbygging som kreves av høyytelsesapper. Fakta er: • BAM er strengt opt-in. • Validatorer kan falle tilbake på Agave-, Jito-Solana- eller Firedancer-klienter • De kan koble fra BAM når som helst BAM Plugins tilbyr en plattform for optimalisering og utviklerinnovasjon som gagner hele Solana.

"BAM monopoliserer Solana-ordreflyt." Steelman: Interessenter hevder at det å samle offentlige transaksjoner i en enkelt rørledning skaper et sentralt flaskehalspunkt som all ordreflyt passerer gjennom, og gir fordeler til den som kontrollerer den. Selv om BAM er nøytral i starten, kontrollerer den ordreflyten, noe som kan styrke dens konkurranseposisjon og hindre andre løsninger i å få gjennomslag. BAM samler inn transaksjoner ved bruk av standard Solana TPU-mekanismen. Det er ingen forskjell mellom «BAM-transaksjoner» og offentlige. Validatorer mottar samme offentlige flyt, bare planlagt gjennom et verifiserbart lag. Validatorer kan gå tilbake til sin native TPU umiddelbart uten svitsjekostnader, og holde orderflyten offentlig i stedet for fragmentert i private kanaler.

"BAM introduserer ekstra forsinkelse vs. validatorens native TPU." Steelman: Interessenter hevder at en av Solanas ytelsesfordeler kommer fra transaksjoner som flyter direkte til lederens TPU med minimale hopp. Ethvert mellomliggende rutinglag, selv et raskt ett, risikerer å legge til latens, jitter og nye feilpunkter under belastning, og kan svekke IBRL-oppdraget sammenlignet med native TPU-planlegging. BAM sikrer minimal forsinkelse via et globalt fotavtrykk på 100+ noder og strategisk samlokalisering, og holder rundtur-tiden under 5 ms. Vår TEE-stabel er sterkt tilpasset trådpinning og CPU-isolasjon, og oppnår ytelsesparitet med Agave. Med den kommende overgangen til DoubleZero forventer vi å overgå bare metal-ytelsesbenchmarkene.

"BAM gir færre belønninger sammenlignet med andre klienter» Steelman: Validatorer har uttrykt bekymring for at BAMs planleggingslogikk kan redusere tips og totale belønninger sammenlignet med andre blokkbygger- eller planleggingsmuligheter. I tillegg er ikke plugin-gebyrmarkedene ennå aktive, noe som gjør oppside teoretisk mens nedsiden virker umiddelbar. Vi prioriterer langsiktig profittmaksimering. BAMs belønninger er allerede sammenlignbare med Jito-Agave. Tidligere ulikheter ble drevet av midlertidige, utvinningsplanleggere andre steder som nå blir avviklet. Fremtidig avkastning vil drives av plugins og ACE, som frigjør bærekraftige betalingsstrømmer fra netto ny økonomisk aktivitet i stedet for kortsiktige spill.

"Som validator må jeg gi stakerne mine høyest mulig avkastning." Steelman: Stakere velger ofte validatorer utelukkende basert på belønninger. Selv en liten nedgang i tips eller variasjon i inntekter over én epoke kan føre til at delegerte andeler flyter andre steder. Validatorer frykter at tidlig innføring av BAM kan sette dem i en konkurranseulempe hvis jevnaldrende utsetter adopsjonen. Vi forstår at validatorer må maksimere utbyttet for seg selv og sine stakere, men må også vurdere andreordens effekter av sine handlinger. Kortsiktig yield hacking (sandwiching, slot-lagging) forringer den totale utførelseskvaliteten og driver bort likviditet. Den eneste bærekraftige veien til høyere avkastning er dypere onchain-aktivitet, som bare kan muliggjøres gjennom bedre applikasjoner, dypere likviditet og strammere spreads.

"Applikasjonskontrollert utførelse (ACE) er ikke viktig." Steelman: Interessenter hevder at Solana-applikasjoner allerede fungerer godt under Priority Fee and Tips-inkluderingsmekanismene. Å introdusere ACE kan øke kompleksiteten og skape ujevne utførelsesgarantier mellom avanserte apper og mindre utviklere. De frykter at det å la applikasjoner definere rekkefølgelogikk kan føre til at BAM gir visse aktører fortrinn. Sofistikerte apper trenger garantier som kanselleringsprioritet eller likvidasjonsprioritet for å fungere trygt. Hyperliquid gjør 10-15 ganger volumet av Solana-kriminelle, nettopp på grunn av sitt tillatelsesbaserte validatorsett som håndhever streng rekkefølge. Uten ACE vil disse appene migrere til tilpassede L1 eller L2 for å få disse garantiene.

"FIFO-ordningen er den mest rettferdige transaksjonsordningslogikken" Steelman: Interessenter hevder at enkel FIFO (først inn, først ut) bestilling er den mest rettferdige og mest nøytrale måten å planlegge transaksjoner på Solana. Det speiler tidsprioritet fra tradisjonelle markeder, er lett for brukere å forstå ("hvis min behandling kommer først, utføres den først"), og unngår "pay-to-win"-dynamikken til de fleste blokkjedene. Selv om FIFO fremstår som mest rettferdig ved å behandle transaksjoner i den rekkefølgen de mottas, oppmuntrer det brukerne til å spamme nettverket for å sikre en gunstig posisjon, noe som fører til kø og pengebrennende latensløp. Dette bryter sammen når nettverksetterspørselen er høy, noe som forårsaker uforutsigbare forsinkelser for alle brukere etter hvert som køene blir lengre. FIFOs one-size-fits-all-tilnærming klarer ikke å møte behovene til apper som krever spesifikk transaksjonsrekkefølge for å fungere optimalt.

"Er ikke BAMs Trusted Execution Environments (TEEs) sårbare for angrep?" Steelman: TEE-er har en historie med sidekanal-sårbarheter, fastvarefeil og forsyningskjederisikoer. Interessenter argumenterer for at avhengighet av TEE-er for blokkplanlegging kan føre til korrelerte feilmoduser: hvis en maskinvareutnyttelse påvirker SEV-SNP, kan BAM som nettverk bli kompromittert. De hevder også at TEE-er gir tilliten til maskinvareleverandører og datasenterleverandører. BAM kjører på AMD SEV-SNP med kryptografiske attestasjoner i sikre, kompatible datasentre (ISO 27001/SOC 2). Selv ved et verste tilfelle maskinvarekompromittering forblir validatornøkler sikre, og kjedens historikk kan ikke skrives om, kun bestillingspersonvernet på den spesifikke noden påvirkes. Validatorer verifiserer den "målte TCB" og kan avvise dårlig firmware via attestering.

@0xmert Fremtiden for blokkbygging beveger seg fra fragmentert planlegging til et transparent, verifiserbart marked. BAM er løsningen. Milliarder må BAM! 💥