New post on
EthResear.ch!
Builders' Defection and Incentive Compatibility
By:
-
@nuconstruct
๐
ethresear.ch/t/25400
Highlights:
- PBS creates an imperfect-commitment problem: builders observe all bids and full payloads, and nothing cryptographically forces them to honor the auction outcome rather than replicate/profit from bundles.
- In a repeated-game model, honesty is incentive-compatible only if the one-shot defection gain (ฮ) is smaller than the expected discounted loss from being caught: ฮ โค p * (ฮด/(1โฮด)) * ฯ_h; low detection probability p or low patience ฮด makes defection rational.
- Empirically (libmev panel, Sep 2024โAug 2025), replication-style defection is likely hard to detect on-chain, implying low p (plausibly 0.01โ0.1), under which incentive compatibility fails for every major non-TEE builder unless the builder is extremely forward-looking.
- The potential economic scale is large: the paper estimates roughly $26M/year of counterfactual defection surplus available to non-TEE builders in the panel, and ~$49M total exposure when including BuilderNetโs TEE-neutralized share.
- Therefore commitment must be restored architecturally, not reputationally: prevent builders from learning usable bid/payload details (e.g., TEEs like BuilderNet, commitment-based settlement designs, or cryptographic approaches such as threshold-encrypted mempools / commit-reveal / ZK), while noting ePBS (EIP-7732) and FOCIL (EIP-7805) donโt address this replication/confidentiality channel.
ELI5:
Ethereum blocks are often built by a โbuilderโ who gets to see everyoneโs secret trading plans (bids + transaction bundles) before deciding what goes in the next block. Even if the builder runs an auction and promises to include the winning bundle, it can secretly copy the best bundle for itself and keep the profit. The paper asks: can we rely on the builderโs reputation (fear of losing future business) to stop this? The answer is usually no, because copying is hard to detect and the one-time profit can be big. So the fix should be technical: design the system so the builder canโt reuse what it sees (using TEEs or cryptography), instead of hoping it behaves.