𝗧𝗼 𝗕𝗔𝗠 𝗼𝗿 𝗻𝗼𝘁 𝘁𝗼 𝗕𝗔𝗠 💥🤔 Biorąc pod uwagę radę @0xMert, zespół napisał bloga, w którym przedstawia wszystkie kontrargumenty przeciwko BAM. Odwołaj się do linku poniżej. Zanurzmy się w to 🧵 ⬇️

"𝗕𝗔𝗠 𝗶𝘀 𝗮 𝗰𝗲𝗻𝘁𝗿𝗮𝗹𝗶𝘇𝗲𝗱 𝘀𝗲𝗾𝘂𝗲𝗻𝗰𝗲𝗿 𝘄𝗶𝘁𝗵 𝗮 𝗯𝗹𝗼𝗰𝗸-𝗯𝘂𝗶𝗹𝗱𝗶𝗻𝗴 𝗺𝗼𝗻𝗼𝗽𝗼𝗹𝘆." 𝘚𝘵𝘦𝘦𝘭𝘮𝘢𝘯: Ta krytyka argumentuje, że BAM wprowadza jednego sekwencera, który będzie odpowiedzialny za harmonogramowanie wszystkich transakcji dla Solany. Nawet jeśli infrastruktura jest rozproszona, zasady harmonogramowania pochodzą z jednego systemu, który jest kontrolowany przez Jito. Interesariusze obawiają się, że to podważa naturalną różnorodność harmonizatorów Solany, przekształcając ją w jeden, który może działać jak scentralizowany sekwencer, stając się pojedynczym punktem awarii i koncentrując zbyt dużą władzę w jednym harmonizatorze i jednej stronie. BAM jest zaprojektowane tak, aby żadna pojedyncza jednostka nie mogła kontrolować kolejności transakcji. System zdywersyfikuje swoją operację i zarządzanie logiką harmonogramowania poprzez: • 𝗼𝗽𝗲𝗻 𝗽𝗮𝗿𝘁𝗶𝗰𝗶𝗽𝗮𝘁𝗶𝗼𝗻: każdy uprawniony operator może uczestniczyć i uruchomić własny węzeł BAM. • 𝗴𝗹𝗼𝗯𝗮𝗹 𝗰𝗼𝘃𝗲𝗿𝗮𝗴𝗲: węzły BAM będą wdrażane w geograficznie zróżnicowanej sieci operatorów. • 𝗼𝗽𝗲𝗻-𝘀𝗼𝘂𝗿𝗰𝗲, 𝘃𝗲𝗿𝗶𝗳𝗶𝗮𝗯𝗹𝗲 𝘀𝗰𝗵𝗲𝗱𝘂𝗹𝗶𝗻𝗴: cały kod BAM będzie otwartym źródłem i audytowalny za pomocą kryptograficznych poświadczeń. Chociaż prawdą jest, że węzły BAM są obecnie wyłącznie zarządzane przez Jito, począwszy od Q1 '26, baza kodu zostanie udostępniona jako otwarte źródło, a niezależni operatorzy zostaną włączeni.

„𝗔𝘀 𝗮 𝘃𝗮𝗹𝗶𝗱𝗮𝘁𝗼𝗿, 𝗕𝗔𝗠 𝘁𝗶𝗲𝘀 𝗺𝗲 𝘂𝗽 𝘁𝗼 𝗼𝗻𝗹𝘆 𝗼𝗻𝗲 𝘀𝗰𝗵𝗲𝗱𝘂𝗹𝗲𝗿” 𝘚𝘵𝘦𝘦𝘭𝘮𝘢𝘯: Ta krytyka mówi, że decydując się na BAM, walidator de facto zrzeka się kontroli nad porządkiem transakcji na rzecz jednego harmonogramu. Zamiast móc korzystać z różnych harmonogramów, eksperymentować z własnymi strategiami lub przełączać się między konkurencyjnymi rozwiązaniami, są związani z jednym systemem. Aby umożliwić rynki kapitałowe w Internecie, Solana potrzebuje deterministycznych i przejrzystych zasad porządkowania. Fragmentacja szkodzi użytkownikom. BAM to umożliwia dzięki ustandaryzowanemu, weryfikowalnemu budowaniu bloków, które jest wymagane przez aplikacje o wysokiej wydajności. Fakty są następujące: • BAM jest ściśle opcjonalne. • Walidatorzy mogą wrócić do klientów Agave, Jito-Solana lub Firedancer • Mogą w każdej chwili odłączyć się od BAM Wtyczki BAM oferują platformę do optymalizacji i innowacji dla deweloperów, co przynosi korzyści całej Solanie.

"𝗕𝗔𝗠 𝗺𝗼𝗻𝗼𝗽𝗼𝗹𝗶𝘇𝗲𝘀 𝗦𝗼𝗹𝗮𝗻𝗮 𝗼𝗿𝗱𝗲𝗿𝗳𝗹𝗼𝘄." 𝘚𝘵𝘦𝘦𝘭𝘮𝘢𝘯: Interesariusze twierdzą, że agregowanie publicznych transakcji w jedną rurociąg tworzy centralny wąskie gardło, przez które przechodzi cały przepływ zamówień i daje przewagę temu, kto to kontroluje. Nawet jeśli początkowo jest neutralne, BAM kontroluje przepływ zamówień, co może wzmocnić jego pozycję konkurencyjną i uniemożliwić innym rozwiązaniom zdobycie popularności. BAM zbiera transakcje za pomocą standardowego mechanizmu TPU Solana. Nie ma rozróżnienia między "transakcjami BAM" a publicznymi. Walidatorzy otrzymują ten sam publiczny przepływ, tylko zaplanowany przez weryfikowalną warstwę. Walidatorzy mogą natychmiast wrócić do swojego rodzimym TPU bez żadnych kosztów przełączenia, utrzymując przepływ zamówień publicznym, a nie rozdzielonym na prywatne kanały.

“𝗕𝗔𝗠 𝗶𝗻𝘁𝗿𝗼𝗱𝘂𝗰𝗲𝘀 𝗲𝘅𝘁𝗿𝗮 𝗹𝗮𝘁𝗲𝗻𝗰𝘆 𝘃𝘀. 𝘃𝗮𝗹𝗶𝗱𝗮𝘁𝗼𝗿’𝘀 𝗻𝗮𝘁𝗶𝘃𝗲 𝗧𝗣𝗨.” 𝘚𝘵𝘦𝘦𝘭𝘮𝘢𝘯: Interesariusze twierdzą, że jednym z atutów wydajności Solany jest to, że transakcje płyną bezpośrednio do TPU lidera z minimalną liczbą skoków. Każda pośrednia warstwa routingu, nawet szybka, niesie ryzyko dodania opóźnienia, jittera i nowych punktów awarii pod obciążeniem, co może osłabić misję IBRL w porównaniu do natywnego harmonogramowania TPU. BAM zapewnia minimalne opóźnienie dzięki globalnej sieci ponad 100 węzłów i strategicznej współlokalizacji, utrzymując czasy podróży w obie strony poniżej 5 ms. Nasz stos TEE jest wysoko dostosowany przy użyciu przypinania wątków i izolacji CPU, osiągając parytet wydajności z Agave. Wraz z nadchodzącą migracją do DoubleZero, spodziewamy się przewyższyć standardy wydajności sprzętu.

„𝗕𝗔𝗠 𝗽𝗿𝗼𝗱𝘂𝗰𝗲𝘀 𝗹𝗲𝘀𝘀 𝗿𝗲𝘄𝗮𝗿𝗱𝘀 𝘃𝘀. 𝗼𝘁𝗵𝗲𝗿 𝗰𝗹𝗶𝗲𝗻𝘁𝘀” 𝘚𝘵𝘦𝘦𝘭𝘮𝘢𝘯: Walidatorzy wyrazili obawy, że logika harmonogramu BAM może zmniejszyć napiwki i ogólne nagrody w porównaniu do innych budowniczych bloków lub możliwości harmonogramowania. Dodatkowo, rynki opłat za wtyczki nie są jeszcze aktywne, co sprawia, że potencjalne zyski są teoretyczne, podczas gdy straty wydają się natychmiastowe. Priorytetem jest maksymalizacja zysku w długim okresie. Nagrody BAM są już porównywalne z Jito-Agave. Przeszłe różnice były spowodowane tymczasowymi, ekstrakcyjnymi harmonogramami w innych miejscach, które są wycofywane. Przyszły zysk będzie napędzany przez wtyczki i ACE, odblokowując zrównoważone strumienie opłat z nowej działalności gospodarczej, a nie krótkoterminowych gier.

„Jako walidator muszę zapewnić moim stakerom najwyższy zysk.” 𝘚𝘵𝘦𝘦𝘭𝘮𝘢𝘯: Stakerzy często wybierają walidatorów wyłącznie na podstawie nagród. Nawet niewielki spadek napiwków lub zmienność zarobków w jednym epoku może spowodować, że delegowane stawki popłyną gdzie indziej. Walidatorzy obawiają się, że wczesne przyjęcie BAM może postawić ich w niekorzystnej sytuacji konkurencyjnej, jeśli ich rówieśnicy opóźnią przyjęcie. Rozumiemy, że walidatorzy muszą maksymalizować zyski dla siebie i swoich stakerów, ale muszą również brać pod uwagę drugorzędne skutki swoich działań. Krótkoterminowe hakowanie zysków (sandwiching, slot-lagging) pogarsza ogólną jakość wykonania i odsuwa płynność. Jedyną zrównoważoną drogą do wyższych zysków jest głębsza aktywność on-chain, co może być możliwe tylko dzięki lepszym aplikacjom, głębszej płynności i węższym spreadom.

"𝗔𝗽𝗽𝗹𝗶𝗰𝗮𝘁𝗶𝗼𝗻-𝗖𝗼𝗻𝘁𝗿𝗼𝗹𝗹𝗲𝗱 𝗘𝘅𝗲𝗰𝘂𝘁𝗶𝗼𝗻 (𝗔𝗖𝗘) 𝗻𝗼𝘁 𝗶𝘀 𝗻𝗼𝘁 𝗶𝗺𝗽𝗼𝗿𝘁𝗮𝗻𝘁." 𝘚𝘵𝘦𝘦𝘭𝘮𝘢𝘯: Interesariusze twierdzą, że aplikacje Solana już dobrze działają w ramach mechanizmów uwzględniania opłat priorytetowych i napiwków. Wprowadzenie ACE może zwiększyć złożoność i stworzyć nierówne gwarancje wykonania między zaawansowanymi aplikacjami a mniejszymi deweloperami. Obawiają się, że pozwolenie aplikacjom na definiowanie logiki porządkowej może prowadzić do faworyzowania niektórych aktorów przez BAM. Zaawansowane aplikacje potrzebują gwarancji takich jak priorytet anulowania lub priorytet likwidacji, aby działać bezpiecznie. Hyperliquid realizuje 10-15 razy większy wolumen niż Solana perps, głównie z powodu swojego dozwolonego zestawu walidatorów, który egzekwuje ścisłe porządkowanie. Bez ACE te aplikacje przeniosą się do niestandardowych L1 lub L2, aby uzyskać te gwarancje.

“𝗙𝗜𝗙𝗢 𝗼𝗿𝗱𝗲𝗿𝗶𝗻𝗴 𝗶𝘀 𝘁𝗵𝗲 𝗳𝗮𝗶𝗿𝗲𝘀𝘁 𝘁𝗿𝗮𝗻𝘀𝗮𝗰𝘁𝗶𝗼𝗻 𝗼𝗿𝗱𝗲𝗿𝗶𝗻𝗴 𝗹𝗼𝗴𝗶𝗰” 𝘚𝘵𝘦𝘦𝘭𝘮𝘢𝘯: Interesariusze twierdzą, że proste zamówienie FIFO (pierwsze przyszło, pierwsze wyszło) jest najsprawiedliwszym i najbardziej neutralnym sposobem planowania transakcji na Solanie. Odbija to priorytet czasowy z tradycyjnych rynków, jest łatwe do zrozumienia dla użytkowników („jeśli moja transakcja przychodzi pierwsza, wykonuje się pierwsza”) i unika dynamiki „płać, aby wygrać” większości blockchainów. Chociaż FIFO wydaje się najsprawiedliwsze, przetwarzając transakcje w kolejności ich przybycia, zachęca użytkowników do spamowania sieci, aby zabezpieczyć korzystną pozycję, co prowadzi do zatorów i wyścigów o opóźnienia, które kosztują pieniądze. To się załamuje, gdy popyt w sieci jest wysoki, powodując nieprzewidywalne opóźnienia dla wszystkich użytkowników, gdy kolejki się wydłużają. Podejście FIFO „jeden rozmiar dla wszystkich” nie spełnia potrzeb aplikacji, które wymagają specyficznego porządku transakcji, aby działać optymalnie.

"𝗔𝗿𝗲𝗻'𝘁 𝗕𝗔𝗠'𝘀 𝗧𝗿𝘂𝘀𝘁𝗲𝗱 𝗘𝘅𝗲𝗰𝘂𝘁𝗶𝗼𝗻 𝗘𝗻𝘃𝗶𝗿𝗼𝗻𝗺𝗲𝗻𝘁𝘀 (𝗧𝗘𝗘𝘀) 𝘃𝘂𝗹𝗻𝗲𝗿𝗮𝗯𝗹𝗲 𝘁𝗼 𝗮𝘁𝘁𝗮𝗰𝗸𝘀?" 𝘚𝘵𝘦𝘦𝘭𝘮𝘢𝘯: TEEs mają historię podatności na ataki boczne, błędy oprogramowania i ryzyka związane z łańcuchem dostaw. Interesariusze twierdzą, że poleganie na TEEs w harmonogramie bloków może wprowadzić skorelowane tryby awarii: jeśli exploit sprzętowy wpłynie na SEV-SNP, BAM jako sieć może zostać skompromitowane. Twierdzą również, że TEEs przenoszą zaufanie na dostawców sprzętu i dostawców centrów danych. BAM działa na AMD SEV-SNP z kryptograficznymi poświadczeniami w bezpiecznych, zgodnych centrach danych (ISO 27001/SOC 2). Nawet w przypadku najgorszego kompromisu sprzętowego, klucze walidatora pozostają bezpieczne, a historia łańcucha nie może być przepisana, tylko prywatność porządkowania na tym konkretnym węźle jest dotknięta. Walidatorzy weryfikują "mierzone TCB" i mogą odrzucić złe oprogramowanie za pomocą poświadczenia.

@0xmert Przyszłość budowania bloków przechodzi od fragmentarycznego harmonogramowania do przejrzystego, weryfikowalnego rynku. BAM jest rozwiązaniem. Miliony muszą BAM! 💥