---
title: "Séparation proposant-constructeur (PBS)"
description: "La PBS sépare la construction du bloc de sa proposition en consensus. Découvrez le marché MEV-Boost, sa différence avec la PBS intégrée et les risques de relais, censure, concentration et créneaux manqués."
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.
# Séparation proposant-constructeur (PBS)
> À visée éducative uniquement ; ceci ne constitue pas un conseil d'investissement ni d'exploitation de validateur. La PBS n'élimine pas les risques de MEV, censure, créneau manqué, relais, concentration des constructeurs ou conception du protocole.
## Réponse directe
La séparation proposant-constructeur (PBS) partage deux tâches de production. Un **constructeur** choisit et ordonne les transactions et crée une charge d'exécution ; le **proposant** désigné par le consensus pour le créneau choisit un engagement, signe la proposition et diffuse ou fait publier le bloc complet. Le proposant reste un validateur soumis aux obligations de consensus. Le constructeur est un rôle de marché distinct et, sur le marché externe actuel, ne doit pas être le validateur du créneau.
Sur Ethereum, il faut distinguer le système actuel des changements proposés. **MEV-Boost est une PBS hors protocole :** un middleware du validateur interroge des relais qui organisent l'enchère entre constructeurs et proposants. La **PBS intégrée (ePBS)** inscrirait l'échange et son exécution dans les règles de consensus. À la date de vérification, Ethereum la présente comme une recherche sans spécification finale et EIP-7732 reste un projet.
La PBS permet aux validateurs d'accéder à une valeur compétitive sans que chacun exploite une infrastructure sophistiquée de recherche MEV et de construction. Elle peut réduire un avantage centralisateur entre proposants, mais ne supprime pas la MEV. La construction spécialisée passe à un marché, avec des questions de confiance dans les relais, concentration des constructeurs et du flux d'ordres, censure, délais et disponibilité.
## Fonctionnement
1. **Les constructeurs bâtissent et enchérissent.** Ils reçoivent des transactions publiques et souvent des flux privés ou lots de chercheurs, simulent des blocs, ordonnent les transactions, créent une charge valide et joignent une enchère représentant le paiement offert.
2. **Les relais organisent le marché actuel.** Dans MEV-Boost, le relais reçoit la charge complète, la vérifie selon sa politique et présente un en-tête signé et une enchère sans révéler d'abord le corps des transactions. MEV-Boost peut interroger plusieurs relais et comparer les réponses utilisables.
3. **Le proposant choisit un engagement.** Il peut comparer les enchères externes à une charge locale et appliquer un minimum. S'il accepte, il signe un bloc balise aveuglé engagé sur l'en-tête choisi ; il ne peut ensuite remplacer les transactions.
4. **La charge est révélée et validée.** Après réception du bloc aveuglé signé, le relais renvoie ou publie la charge complète. Les clients de consensus et d'exécution valident le bloc. Une charge tardive, indisponible ou invalide peut empêcher la publication et faire manquer le créneau.
5. **Paiement et consensus restent distincts.** L'enchère est le paiement promis sur la couche d'exécution au destinataire des frais configuré. Récompenses et pénalités de consensus suivent d'autres règles. Choisir un constructeur ne lui transfère ni finalité ni fork choice.
La Builder API normalise l'inscription des validateurs, la récupération d'en-têtes et l'envoi d'un bloc aveuglé signé. Une API ne garantit pas la confiance : admission, validation, traitement des données et pannes du relais dépendent de l'implémentation et du déploiement.
## Exemple
Supposons que le client local crée une charge de `0.03 ETH`, tandis que les enchères utilisables valent `0.05 ETH`, `0.08 ETH` et `0.07 ETH`. Sans coûts de latence ni de panne, la meilleure offre procure un gain brut de `0.05 ETH` :
**Gain brut = enchère du constructeur - valeur de la charge locale = 0.08 ETH - 0.03 ETH = 0.05 ETH**
Le proposant choisit l'en-tête à `0.08 ETH` et signe sans voir la liste complète. Le relais fournit ou publie la charge engagée. Si le bloc est valide et ponctuel, le réseau le traite et le destinataire reçoit le paiement. Le proposant conserve son rôle de consensus ; le constructeur ne décide pas si le bloc devient canonique ou final.
Cette comparaison ne garantit pas un revenu net. Latence, échec de révélation, logiciel, vérification du paiement ainsi que probabilité et coût d'un créneau manqué comptent. Si aucune enchère ne satisfait la politique à temps, un client bien configuré peut employer la charge locale.
## Risques
- **Confiance et disponibilité des relais :** Les relais MEV-Boost organisent l'échange, voient les charges, appliquent des politiques et sont sur un chemin critique. Leur diversité réduit la dépendance, sans garantir chacun d'eux.
- **Concentration des constructeurs et des ordres :** Meilleurs flux privés, latence, capital ou simulation peuvent faire gagner davantage de blocs. Une enchère ne garantit ni construction décentralisée ni inclusion neutre.
- **Censure et confidentialité :** Constructeurs ou relais peuvent omettre des transactions et voir les flux privés. Les listes d'inclusion proposées sont un autre mécanisme ; la PBS actuelle n'impose pas toute transaction valide.
- **Délais, rétention et créneaux manqués :** Une forte enchère ne vaut que si la charge est valide et ponctuelle. Rétention, panne, retard réseau ou mauvaise configuration peuvent réduire les gains ou faire manquer le créneau.
- **Hypothèses changeantes :** Les projets ePBS comme EIP-7732 modifient paiement, révélation, validation et fork choice. Tant qu'ils restent au stade de projet, la spécification du fork déployé prévaut sur la feuille de route.
## Idées reçues
### Idée reçue 1 : La PBS élimine la MEV
La PBS sépare construction et proposition. Les constructeurs continuent de rechercher la MEV ; le mécanisme vise à réduire son effet centralisateur et à distribuer la valeur par enchères.
### Idée reçue 2 : Le constructeur propose ou finalise le bloc
Le constructeur crée la charge. Le proposant signe, les autres validateurs attestent, et les règles de fork choice et de finalité déterminent la chaîne canonique.
### Idée reçue 3 : MEV-Boost est déjà une PBS sans confiance imposée par le protocole
MEV-Boost est un middleware externe à relais. Il approche la PBS sans changer le consensus ; ses hypothèses diffèrent donc d'une future conception intégrée.
### Idée reçue 4 : L'enchère affichée la plus élevée est toujours optimale
Le montant n'est qu'un facteur. Validité, délai, conduite du relais, solution locale, destinataire des frais et risque de créneau manqué influencent le résultat.
## Sujets connexes
- [Résistance à la censure](/fr/crypto/censorship-resistance/)
- [Règle de choix de fork](/fr/crypto/fork-choice-rule/)
- [MEV](/fr/crypto/mev/)
- [Validateur](/fr/crypto/validator/)
- [Finalité](/fr/crypto/finality/)
## Sources
- [Séparation proposant-constructeur](https://ethereum.org/roadmap/pbs/) - Ethereum.org (consulté le : 2026-08-21)
- [Valeur maximale extractible (MEV)](https://ethereum.org/developers/docs/mev/) - Ethereum.org (consulté le : 2026-08-21)
- [Builder API](https://ethereum.github.io/builder-specs/) - Ethereum Builder Specifications (consulté le : 2026-08-21)
- [MEV-Boost](https://github.com/flashbots/mev-boost) - Flashbots (consulté le : 2026-08-21)
- [EIP-7732 : PBS intégrée](https://eips.ethereum.org/EIPS/eip-7732) - Ethereum Improvement Proposals (consulté le : 2026-08-21)
Source: https://wiki.fcontext.com/fr/crypto/proposer-builder-separation/index.mdx