--- title: "Separazione tra proponente e costruttore (PBS)" description: "La PBS separa costruzione del blocco e proposta nel consenso. Spiega il mercato MEV-Boost di Ethereum, la differenza dalla PBS integrata e i rischi di relay, censura, concentrazione e slot mancati." image: "https://wiki.fcontext.com/og.png" --- > Documentation Index > Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt > Use this file to discover all available pages before exploring further. # Separazione tra proponente e costruttore (PBS) > Solo a fini educativi; non è consulenza d'investimento né operativa per validatori. La PBS non elimina i rischi di MEV, censura, slot mancati, relay, concentrazione dei costruttori o progettazione del protocollo. ## Risposta diretta La separazione tra proponente e costruttore (PBS) divide due compiti della produzione dei blocchi. Un **costruttore** sceglie e ordina le transazioni e crea un payload di esecuzione; il **proponente** scelto dal consenso per lo slot seleziona un impegno sul payload, firma la proposta e diffonde o fa pubblicare il blocco completo. Il proponente resta un validatore con obblighi di consenso. Il costruttore è un ruolo di mercato distinto e oggi non deve essere il validatore dello slot. Su Ethereum occorre distinguere il sistema attuale dalle modifiche proposte. **MEV-Boost è PBS fuori protocollo:** un middleware del validatore interroga relay che mediano un'asta fra costruttori e proponenti. La **PBS integrata (ePBS)** inserirebbe scambio ed esecuzione nelle regole di consenso. Alla data di verifica Ethereum la descrive come ricerca senza specifica definitiva ed EIP-7732 resta una bozza. La PBS consente ai validatori di accedere a valore competitivo senza gestire ciascuno sistemi sofisticati di ricerca MEV e costruzione. Può ridurre un vantaggio centralizzante tra proponenti, ma non elimina MEV. Sposta la costruzione specializzata in un mercato e introduce questioni di fiducia nei relay, concentrazione di costruttori e flusso ordini, censura, tempistiche e disponibilità del payload. ## Come funziona 1. **I costruttori costruiscono e offrono.** Ricevono transazioni pubbliche e spesso flusso privato o bundle di searcher, simulano blocchi, ordinano transazioni, producono un payload valido e allegano un'offerta per il proponente. 2. **I relay mediano il mercato attuale.** In MEV-Boost il relay riceve il payload completo, lo controlla secondo la propria politica e mostra intestazione firmata e offerta senza rivelare subito il corpo. MEV-Boost può interrogare più relay e confrontare risposte utilizzabili. 3. **Il proponente sceglie un impegno.** Può confrontare offerte esterne e payload locale e applicare una soglia minima. Accettando l'offerta firma un blocco beacon oscurato vincolato all'intestazione scelta e non può poi sostituire le transazioni. 4. **Il payload viene rivelato e validato.** Ricevuto il blocco oscurato firmato, il relay restituisce o pubblica il payload completo. I client di consenso ed esecuzione validano il blocco. Un payload tardivo, assente o invalido può impedire la pubblicazione e far perdere lo slot. 5. **Pagamento e consenso restano distinti.** L'offerta è il pagamento promesso sul livello di esecuzione al destinatario commissioni configurato. Ricompense e penalità di consenso seguono altre regole. Scegliere un costruttore non gli trasferisce finalità o fork choice. La Builder API standardizza registrazione dei validatori, recupero delle intestazioni e invio del blocco oscurato firmato. Una API non garantisce fiducia: ammissione, validazione, dati e guasti del relay dipendono da implementazione e distribuzione. ## Esempio Supponiamo che il client locale crei un payload da `0.03 ETH` e le offerte utilizzabili siano `0.05 ETH`, `0.08 ETH` e `0.07 ETH`. Ignorando latenza e guasti, l'offerta maggiore dà un incremento lordo di `0.05 ETH`: **Incremento lordo = offerta del costruttore - valore del payload locale = 0.08 ETH - 0.03 ETH = 0.05 ETH** Il proponente sceglie l'intestazione da `0.08 ETH` e firma senza vedere l'elenco completo. Il relay fornisce o pubblica il payload impegnato. Se valido e puntuale, la rete lo elabora e il destinatario riceve il pagamento. Il proponente mantiene il ruolo di consenso; il costruttore non decide se il blocco diventa canonico o finale. Il confronto non garantisce reddito netto. Contano latenza, mancata rivelazione, software, verifica del pagamento e probabilità e costo dello slot mancato. Se nessuna offerta soddisfa in tempo la politica, un client configurato correttamente può usare il payload locale. ## Rischi - **Fiducia e disponibilità dei relay:** I relay MEV-Boost mediano lo scambio, vedono i payload, applicano politiche e sono sul percorso critico. La diversità riduce la dipendenza, ma non garantisce ogni relay. - **Concentrazione di costruttori e ordini:** Migliori flussi privati, latenza, capitale o simulazione possono far vincere più blocchi. Un'asta non garantisce costruzione decentralizzata o inclusione neutrale. - **Censura e privacy:** Costruttori o relay possono omettere transazioni e vedere flussi privati. Le liste di inclusione proposte sono un altro progetto; la PBS attuale non impone ogni transazione valida. - **Tempi, ritenzione e slot mancati:** Un'offerta alta vale solo con payload valido e puntuale. Ritenzione, guasti, ritardi o configurazioni errate possono ridurre ricompense o perdere lo slot. - **Ipotesi mutevoli:** Proposte ePBS come EIP-7732 cambiano pagamenti, rivelazione, validazione e fork choice. Essendo bozze, vale la specifica del fork distribuito, non la roadmap come garanzia attuale. ## Fraintendimenti comuni ### Mito 1: La PBS elimina MEV La PBS separa chi costruisce da chi propone. I costruttori competono ancora per MEV; il progetto mira a ridurne l'effetto centralizzante sui validatori e distribuire valore con le offerte. ### Mito 2: Il costruttore propone o finalizza il blocco Il costruttore crea il payload. Il proponente firma, gli altri validatori attestano e le regole di fork choice e finalità decidono la catena canonica. ### Mito 3: MEV-Boost è già PBS trustless imposta dal protocollo MEV-Boost è middleware esterno con relay. Approssima PBS senza cambiare il consenso, quindi le sue ipotesi differiscono da un futuro progetto integrato. ### Mito 4: L'offerta visualizzata più alta è sempre migliore Il valore è solo un input. Validità, consegna, comportamento del relay, fallback locale, destinatario commissioni e rischio di perdere lo slot incidono sul risultato. ## Argomenti correlati - [Resistenza alla censura](/it/crypto/censorship-resistance/) - [Regola di fork choice](/it/crypto/fork-choice-rule/) - [MEV](/it/crypto/mev/) - [Validatore](/it/crypto/validator/) - [Finalità](/it/crypto/finality/) ## Fonti - [Separazione proponente-costruttore](https://ethereum.org/roadmap/pbs/) - Ethereum.org (consultato: 2026-08-21) - [Valore massimo estraibile (MEV)](https://ethereum.org/developers/docs/mev/) - Ethereum.org (consultato: 2026-08-21) - [Builder API](https://ethereum.github.io/builder-specs/) - Ethereum Builder Specifications (consultato: 2026-08-21) - [MEV-Boost](https://github.com/flashbots/mev-boost) - Flashbots (consultato: 2026-08-21) - [EIP-7732: PBS integrata](https://eips.ethereum.org/EIPS/eip-7732) - Ethereum Improvement Proposals (consultato: 2026-08-21) Source: https://wiki.fcontext.com/it/crypto/proposer-builder-separation/index.mdx