Proposer-Builder Separation (PBS) to koncepcja architektoniczna dla Ethereum, która polega na rozdzieleniu dwóch zadań wykonywanych dotychczas przez jednego uczestnika sieci — budowy zawartości bloku oraz jego zgłoszenia (zaproponowania) sieci. W obecnym modelu walidator, który zostaje wylosowany do stworzenia bloku w danym slocie, sam decyduje, jakie transakcje się w nim znajdą. PBS proponuje rozdzielenie tej roli między wyspecjalizowanych „builderów”, którzy konstruują bloki, i „proposerów”, którzy jedynie wybierają i zgłaszają najbardziej opłacalną propozycję.
Definicja i idea PBS
W modelu PBS builderzy tworzą kompletne bloki transakcji i przedstawiają je proposerowi wraz z deklarowaną opłatą. Proposer nie widzi zawartości bloku przed jego wyborem — ocenia, która oferta jest najbardziej opłacalna, i wybiera ją, otrzymując w zamian ustaloną płatność od buildera. Taki podział ma sens, bo budowanie maksymalnie dochodowego bloku wymaga specjalizowanego oprogramowania i wiedzy, której nie musi mieć każdy walidator.
Jak działa PBS — kluczowe rozróżnienia
PBS jako koncepcja protokołowa
PBS w czystej, wbudowanej w protokół formie wciąż znajduje się w fazie badawczej — nie istnieje jeszcze finalna specyfikacja tego mechanizmu na poziomie konsensusu Ethereum.
Rozwiązanie tymczasowe: Builder API
Zanim PBS zostanie wdrożony w samym protokole, funkcjonuje rozwiązanie pośrednie zwane Builder API — interfejs pozwalający klientom warstwy konsensusu korzystać z bloków przygotowanych przez zewnętrzne podmioty. Jest ono opisywane jako tymczasowe i wymaga wyższego poziomu zaufania niż docelowy PBS, ale ma tę zaletę, że nie wymaga zmian w samej warstwie bazowej.
Implementacja praktyczna: MEV-Boost
Najbardziej rozpowszechnioną, działającą już implementacją tego podejścia jest oprogramowanie pośredniczące instalowane dobrowolnie przez walidatorów, działające jako dodatkowy komponent (sidecar) klienta konsensusu. Zbiera ono propozycje bloków od wielu builderów za pośrednictwem sieci przekaźników (relayów) i wskazuje walidatorowi najbardziej dochodową ofertę.
Docelowy kierunek: enshrined PBS
Długofalowym celem badań jest tzw. enshrined PBS, czyli wbudowanie roli buildera bezpośrednio w protokół. Do struktury bloku konsensusu dodawany byłby wpis reprezentujący ofertę buildera, a specjalny komitet walidatorów potwierdzałby terminowe ujawnienie zawartości bloku i dostępność powiązanych danych. Celem jest wymiana korzyści między proposerem i builderem bez zaufanego pośrednika.
Praktyczne znaczenie dla użytkownika i sieci
PBS ma istotny wpływ na ekonomię wartości wydobywanej z porządkowania transakcji (MEV, maximal extractable value). Bez rozdzielenia ról maksymalizacja tej wartości wymaga zaawansowanego know-how, co sprzyja dużym operatorom i tworzy presję centralizacyjną, zniechęcającą do prowadzenia niezależnych węzłów przez mniejszych uczestników. Dzięki PBS nagroda z tytułu MEV trafia do proposera niezależnie od tego, czy jest on dużym operatorem czy pojedynczym walidatorem prowadzącym węzeł we własnym domu — bo budowę bloku wykonuje wyspecjalizowany podmiot zewnętrzny.
PBS ma również znaczenie dla odporności sieci na cenzurę. Rozdzielenie ról utrudnia builderom systematyczne wykluczanie określonych transakcji z bloków, a proposer może pełnić funkcję swoistego strażnika, wymuszającego włączenie pewnych transakcji niezależnie od decyzji buildera. PBS jest też traktowany jako warunek wstępny dla dalszego skalowania Ethereum, bo przyszłe mechanizmy zwiększające przepustowość danych będą wymagać, by builderzy radzili sobie z obliczeniami na dużych ilościach danych w krótkim czasie.
Czym PBS nie jest
PBS jako mechanizm wbudowany w protokół to nie to samo co Builder API — to ostatnie jest opisywane jako rozwiązanie przejściowe z wyższymi wymaganiami dotyczącymi zaufania. PBS to również nie to samo co popularne oprogramowanie pośredniczące działające jako sidecar walidatora — to konkretna, pozaprotokołowa implementacja jednego podejścia do PBS. Warto pamiętać, że PBS nie jest jeszcze wdrożony w samym protokole Ethereum — brakuje sfinalizowanej specyfikacji, a otwarte pytania badawcze dotyczą m.in. optymalnej konstrukcji list wymuszonego włączenia transakcji.
Ograniczenia i ryzyka
PBS wprost akceptuje, że budowanie bloków może z czasem ulegać centralizacji wśród niewielkiej liczby podmiotów — i próbuje ograniczyć skutki tej centralizacji do warstwy budowy bloku, izolując ją od walidacji i dystrybucji nagród. W modelu pośredniczącym proposer często polega na relayu, który przekazuje mu jedynie „zaślepiony” nagłówek bloku, a pełną treść odsłania dopiero po podpisaniu zobowiązania — co wiąże się z ryzykiem kary za podpisanie dwóch sprzecznych wersji bloku. Docelowy, w pełni wbudowany PBS wymaga hard forka i wciąż podlega recenzji technicznej.
Podsumowanie
Proposer-Builder Separation to jedna z centralnych koncepcji w planach rozwoju Ethereum, mająca rozdzielić budowę bloku od jego zatwierdzenia przez proposera, aby ograniczyć presję centralizacyjną związaną z ekstrakcją wartości z porządku transakcji. Dziś funkcjonuje głównie w formie pozaprotokołowych implementacji, natomiast w pełni wbudowana w protokół wersja PBS pozostaje przedmiotem aktywnych badań i nie powinna być traktowana jako gotowy, wdrożony standard.
