Row 9100

Row ID: 9100 | Dataset Entry | Axioma AXP Content Repository

Content Data

This page contains data entry 9100 from the Axioma AXP content repository. The structured data below represents the complete record for this entry.

After reading this page from [Ethereum.org](https://ethereum.org/en/developers/docs/mev/#mev-in-ethereum-proof-of-stake), I have some questions and thought you could help me understand it better. I put my own understanding but please tell me if I'm wrong or what I'm missing.

Thanks!

**1. What's the difference between PBS (Proposer-Builder Separation) and MEV-Boost?**

**PBS:**

* PBS design is still in discussion. * PBS would be implemented at the protocol level, meaning it will be built in Ethereum consensus protocol and would change the way blocks are built and proposed for every Validator. * PBS design doesn't rely on third-party **Relayers**

**MEV-Boost (from Flashbots):**

* Use the same idea of PBS: separating block **Builders** and block **Proposers** * is a client that Validators can install in order to access a some kind of "auctions market" for MEV-optimized blocks. * The Validator becomes a **Proposer**. By calling the **Relayer** (via MEV-Boost API), this **Proposer** selects the most profitable block, among blocks built by **Builders**. Those **Builders** want their block to be included because they want to extract MEV, so offer high gas fees (some kind of "profit sharing" between the **Proposer** and the **Builder**). * This is somewhat centralized because the **Relayer** is a third-party (unlike in true built-in PBS). But still better than nothing because without MEV-Boost, there would be less competition and more centralization risk (**Searchers** would be frontrunned by **Proposers** ; **Searchers** / **Builders** would make private arrangements with the biggest Validators/Pools).

Am I right or did I miss something?

**2. Are Searchers and Builders actually the same actors?**

* The **Searchers** are the actors that look for MEV opportunities ; * **Builders** are the actors that actually build the blocks and bid for its inclusion (via a **Relayer** in the case of MEV-Boost) ; * But I suppose **Searchers** build blocks themseleves (just because they can and I don't know why they would delegate this to someone else).

Am I right?

**3. With MEV-Boost, what does prevent the Proposer to frontrun the Searchers?**

FieldValue
text After reading this page from [Ethereum.org](https://ethereum.org/en/developers/docs/mev/#mev-in-ethereum-proof-of-stake), I have some questions and thought you could help me understand it better. I put my own understanding but please tell me if I'm wrong or what I'm missing. Thanks! **1. What's the difference between PBS (Proposer-Builder Separation) and MEV-Boost?** **PBS:** * PBS design is still in discussion. * PBS would be implemented at the protocol level, meaning it will be built in Et…
label r/ethereum
dataType post
communityName r/ethereum
datetime 2024-05-20
username_encoded Z0FBQUFBQm5Lakw0R0ZtZHRFUzU4cHQtNnBhVC0wOTdzSW9MUnRCTDlkQ1Rzc1hSTkdSTWJjemJET0pVanFDVU05V0NzXzRJcWVlVlRFRUs3cEk3enFtNmR3QjFtblNZcGc9PQ==
url_encoded Z0FBQUFBQm5Lak9JLVZpMmY1TjNEMUlvQzIyNG1oQ2J0VFBINE1ra3hjSHUyUzVodDZTYkFCVkVHNk1vVFVtTzZzQVFvc2tYWjRkcEpQV0xVNkd2ZXpBcmxyN2FIdXJuem9YdDl2bzB5cFVHbUtONUR6N3ZCc29YY3I0eUNmYklubFlmRTV1TmxjaEIwUzQ3Rk9jMGpIZEtxVmRKS2pvLWlNSndjNFpoLWR1LU5FanpHZi1FSjhFWnFsV3ZqRjZUaEhuemFKazdGWHZt

Raw Record

{
  "text": "After reading this page from [Ethereum.org](https://ethereum.org/en/developers/docs/mev/#mev-in-ethereum-proof-of-stake), I have some questions and thought you could help me understand it better. I put my own understanding but please tell me if I'm wrong or what I'm missing.\n\nThanks!\n\n**1. What's the difference between PBS (Proposer-Builder Separation) and MEV-Boost?**\n\n**PBS:**\n\n* PBS design is still in discussion.\n* PBS would be implemented at the protocol level, meaning it will be built in Ethereum consensus protocol and would change the way blocks are built and proposed for every Validator.\n* PBS design doesn't rely on third-party **Relayers**\n\n**MEV-Boost (from Flashbots):**\n\n* Use the same idea of PBS: separating block **Builders** and block **Proposers**\n* is a client that Validators can install in order to access a some kind of \"auctions market\" for MEV-optimized blocks.\n* The Validator becomes a **Proposer**. By calling the **Relayer** (via MEV-Boost API), this **Proposer** selects the most profitable block, among blocks built by **Builders**. Those **Builders** want their block to be included because they want to extract MEV, so offer high gas fees (some kind of \"profit sharing\" between the **Proposer** and the **Builder**).\n* This is somewhat centralized because the **Relayer** is a third-party (unlike in true built-in PBS). But still better than nothing because without MEV-Boost, there would be less competition and more centralization risk (**Searchers** would be frontrunned by **Proposers** ; **Searchers** / **Builders** would make private arrangements with the biggest Validators/Pools).\n\nAm I right or did I miss something?\n\n**2. Are Searchers and Builders actually the same actors?**\n\n* The **Searchers** are the actors that look for MEV opportunities ;\n* **Builders** are the actors that actually build the blocks and bid for its inclusion (via a **Relayer** in the case of MEV-Boost) ;\n* But I suppose **Searchers** build blocks themseleves (just because they can and I don't know why they would delegate this to someone else).\n\nAm I right?\n\n  \n**3. With MEV-Boost, what does prevent the Proposer to frontrun the Searchers?**\n\n",
  "label": "r/ethereum",
  "dataType": "post",
  "communityName": "r/ethereum",
  "datetime": "2024-05-20",
  "username_encoded": "Z0FBQUFBQm5Lakw0R0ZtZHRFUzU4cHQtNnBhVC0wOTdzSW9MUnRCTDlkQ1Rzc1hSTkdSTWJjemJET0pVanFDVU05V0NzXzRJcWVlVlRFRUs3cEk3enFtNmR3QjFtblNZcGc9PQ==",
  "url_encoded": "Z0FBQUFBQm5Lak9JLVZpMmY1TjNEMUlvQzIyNG1oQ2J0VFBINE1ra3hjSHUyUzVodDZTYkFCVkVHNk1vVFVtTzZzQVFvc2tYWjRkcEpQV0xVNkd2ZXpBcmxyN2FIdXJuem9YdDl2bzB5cFVHbUtONUR6N3ZCc29YY3I0eUNmYklubFlmRTV1TmxjaEIwUzQ3Rk9jMGpIZEtxVmRKS2pvLWlNSndjNFpoLWR1LU5FanpHZi1FSjhFWnFsV3ZqRjZUaEhuemFKazdGWHZt"
}

Entry Information