PBS post - HackMD

--- tags: pbs --- # PBS post _Incomplete post, probably outdated, provided for reference. See [Notes on PBS](https://barnabe.substack.com/p/pbs) for a more relevant view._ Users of blockchains realise the value of their economic needs by transacting on-chain, interacting with smart contracts which operate organisations, marketplaces and more. Settling this activity requires blockspace, a unique good manufactured and sold within decentralised systems. Meanwhile, blockspace markets proliferate in- and out-of-protocol, organising access to this resource. In this post, we attempt a survey of the various ways agents in these markets organise themselves. Economic value flows from the users to the protocol, and we let ourselves go with the flow. Along the way, we'll observe where the flow lands, who captures it and where we might have power to reconfigure it. ## General model A user comes to the blockchain market with a transaction. They expect some outcome $\omega$ to happen, which is realised whenever the transaction is executed after any pre-state $s$ in some set $S_\omega$. The outcome may be parameterised by time, e.g., if the users has (wall-clock, or blocktime) time preferences, or by the amount they receive in an exchange, e.g., because of slippage. In other words, the user maps the realisation of an outcome $\omega$ to some economic value $v(\omega)$, which is realised whenever the transaction is executed after some pre-state included in $S_\omega$. The realisation of outcome $\omega$ may in turn create more value to some other agent, including the user themselves. We call this value $\bar{v}(\omega)$. If a user makes a trade, arbitrage opportunities may be available in the post-state, for which any user would be willing to expend up to $\bar{v}(\omega)$ to capture. Critically, a user only has limited control over which of all possible outcomes may be realised. With encrypted transactions, even the block producer has limited control over inducing some outcome $\omega$ which may be more profitable for themselves, but more on this later in the post. For now, let's consider some case studies.  ### An hypothesis Isn't it strange that we'd have $v(\omega)$ and $\bar{v}(\omega)$? Why would a user leave money on the table? What makes a user unable to capture the extra value they create, and what makes it possible for a user to receive their minimum expected value more often than they should? Contract theory seems to imply that since the user has the power to make or not the transaction, they should have all the negotiating power they need to force whatever party into giving them up to $\bar{v}(\omega)$ back. Market failures are often found in market asymmetries. In this case, we may consider two kinds: - *Information asymmetry:* The user may not be able to compute $\bar{v}(\omega)$. In the case of arbitrage, they may not have the knowledge to perform ex ante exact routing or to make an equalising trade to capture the ex post arbitrage. - *Control asymmetry:* Ultimately, neither the user nor the potential capturer may fully control the mechanism which selects $\omega$, e.g., in an ordering consensus such as receive-time ordering, or when the user is not willing to pay the prevailing market rate for blockspace and their trade executes later. ### An example Suppose two users want to make a trade. Alice wants to trade 1 ETH for 1000 DAI. Bob wants to trade 1000 DAI for 1 ETH. Clearly Alice and Bob might not know of one another's existence. If they did, they should just exchange the tokens between one another, peer-to-peer. The famous CoWincidence of Wants ;) (more on that later!) If Alice trades first, let's say on a vanilla $xy=k$ AMM where the current price is 1000 ETH/DAI, i.e., the pool reserves $X_{ETH}$ and $Y_{DAI}$ are such that $Y/X = 1000$. By selling her $\Delta x = 1 \text{ ETH}$, Alice receives $\Delta y = \frac{Y \cdot \gamma \Delta x}{X + \gamma \Delta x}$ where $1-\gamma$ is the LP fee, i.e., Alice does not receive exactly 1000 DAI. Alice might have an intrinsic reason to use the AMM to do her trade, for instance she needs DAI to pay her rent at the end of the month and the AMM has the lowest cost for the trade, so much so that she is willing to expend up to $v(X, Y)$ DAI to use the AMM, where $\omega = (X, Y)$ denotes that Alice's trade executed at the AMM state $(X, Y)$. If Alice was to receive less than $\Delta y$ DAI, let's say $\Delta y - \epsilon$, due to the AMM being in a different state $(X', Y')$, then her value would be $v(X', Y') = v(X, Y) - \epsilon$. Suppose there is a second exchange, a CEX, where the ETH/DAI pair trades, with much higher reserves, at the $p =$ 1000 ETH/DAI price. Then the arbitrageur wants to buy $\Delta x'$ units of ETH from the AMM and sell the ETH on the CEX against some DAI. It turns out that the optimal quantity of ETH to buy for them is $\Delta x' = X - \sqrt{\frac{k}{p \, \gamma}}$, which they buy against $\Delta y'$ DAI and resell for $\Delta y''$ DAI on the CEX. They eventually receive $\bar{v}(X, Y) = \Delta y'' - \Delta y'$. If Alice and Bob's trades were first executed on the AMM, Alice first and then Bob, then the arbitrageur would have received value $\bar{v}(X', Y')$, where $(X', Y')$ is the state of the AMM after Alice's trade was executed, and thus the state of the AMM for Bob's trade. Bob would not have received 1 ETH exactly had he sold 1000 DAI to the AMM, since Alice changed the state in the meantime. Obviously we have here that $\bar{v}(X', Y') < \bar{v}(X, Y)$, since Bob's trade would have put the AMM state closer to the exchange price. Overall, the total value served in this example is $v(X, Y) + v(X', Y') + \bar{v}(X', Y')$, namely, Alice's value, plus Bob's, plus the arbitrageur's. ## Proposer-Builder Separation (PBS) The talk of the town revolves around Proposer-Builder Separation, an attempt to entrench existing dynamics where parts of the block construction are outsourced to third-parties. In the PoW world, searchers via Flashbots submit bundles to miner-block producers (BP). These bundles, sometimes a large set of them, are included at the top of the block, with the BP filling the block suffix from their mempool transactions. Searchers sell the bundle data by forwarding parts of their own profits to the BP, who runs an internal auction to determine which bundles to include. In the PoS world, direct lines of communication may not exist between solo stakers and searchers. While searchers trust mining pools to not steal the bundle data from them, the same trust relationship may not be established between solo stakers and searchers. While [some constructions](https://twitter.com/barnabemonnot/status/1559647136886710273) now exist, the currently available [mev-boost](https://boost.flashbots.net/) builder client relies on *blind signing* the full block. A builder submits a full block payload to a relay, along with a bid. The relay forwards the bids to proposers. The current proposer selects one bid, for which they sign the corresponding block header, binding them to propose the block payload held by the relay. In other words, at the time of signing, the proposer does not know the contents of the block, and is unable to add to the block later on. mev-boost-based PBS has a trusted relay in the design. The endgame is to move to [in-protocol PBS](https://youtu.be/jQjBNbEv9Mg), where the protocol organises a market between proposers and builders. This has manifold implications on the centralisation of the builder market, user experience and censorship-resistance properties of Ethereum. Much has been written about each topic, and here we attempts to provide a holistic view of PBS in the context of other suggested solutions. Simply, using the formalism introduced above, we have: $$\omega^* = \text{arg} \max_{\omega \in \Omega} \sum \bar{v}(\omega)$$ In other words, the builder would select the block contents (represented by some outcome $\omega^*$) maximising the sum of externalities accruing by the inclusion of some set of transactions. The first obvious claim to make here is that there is no reason for $\omega^* = \omega^{SW}$, where $\omega^{SW}$ is the outcome maximising user social welfare, i.e., $$\omega^{SW} = \text{arg} \max_{\omega \in \Omega} \sum v(\omega)$$