If you are a DeFi enthusiast or a blockchain developer, you must have heard about MEV, PBS, and sandwich attacks many times. Have you ever wondered what the principle is behind this "dark forest"?
To fully understand the current PBS ecosystem (proposer-builder separation) and its underlying concept, we can approach it from the perspective of a transaction initiated by a user. In other words, we can explore what exactly happens during the process from the moment a user initiates a transaction on a dapp (decentralized application) to its complete establishment on the consensus layer.
To facilitate understanding, I have broken down these stages into several steps.
Transaction
As demonstrated in the diagram above, it illustrates the essential information needed for minting an NFT contract. The most critical piece of information is the "data" field. In the diagram provided, "0x1249c58b" represents the function selector of the "mint()" function. However, if we replace the data with "0x", it indicates a regular transfer transaction. By analyzing the data and value fields, we can clearly determine the user's intention and purpose behind this particular transaction.
Mempool
When users use public nodes to remotely call services (such as MetaMask, which by default uses Infura's Ethereum node service), their transactions are added to the mempool. The mempool is a buffer in the node where transactions are received and included in a block. Its purpose is to help the node examine different types of transactions and verify the validity and legality of their outputs and signatures, ensuring the security and stability of the blockchain network.
The transactions in the mempool are unique to each node, but the information they hold is public across the entire blockchain network. This means that if a person can set up multiple nodes on cloud services in various locations, they can obtain a significant amount of mempool data. The misuse of this data can be detrimental to regular users, as bots can profit from anticipating users' transaction intentions in advance. This process is referred to as MEV (Maximal Extractable Value). It is important to prevent such practices in order to maintain a fair and secure blockchain network.
Searcher
Also known as an Ethereum bot operator, the entities we currently understand as arbitrageurs and NFT minting-bots can be classified as searchers. After Flashbots open-sourced their auction components, searchers can combine their own transactions or transactions from the mempool in a bundled package and specify a particular block builder to include these bundled transactions in a block. This helps them avoid having their transactions sniffed out in the public mempool.
Flashbots has created a new channel for transmitting transaction information that allows certain users to communicate directly with block builders. In the example below, I used the Flashbots relay to transmit the details of the minting process directly to a block builder, which helped me avoid the scenario where my minting information could be compromised beforehand.
async function main() {
const flashbotsProvider = await FlashbotsBundleProvider.create(provider, Wallet.createRandom(), FLASHBOTS_ENDPOINT)
provider.on('block', async (blockNumber) => {
console.log(blockNumber)
const block = await provider.getBlock("latest");
const bundleSubmitResponse = await flashbotsProvider.sendBundle(
[
{
transaction: {
chainId: CHAIN_ID,
type: 2,
value: ETHER/100n*3n,
//value: BigNumber.from(10).pow(16).mul(3),
data: "0x1249c58b",
maxFeePerGas: GWEI * 15n,
maxPriorityFeePerGas: GWEI * 5n,
to: "0x20EE855E43A7af19E407E39E5110c2C1Ee41F64D"
},
signer: wallet
}
], blockNumber + 1
)
// By exiting this function (via return) when the type is detected as a "RelayResponseError", TypeScript recognizes bundleSubmitResponse must be a success type object (FlashbotsTransactionResponse) after the if block.
if ('error' in bundleSubmitResponse) {
console.warn(bundleSubmitResponse.error.message)
return
}
console.log(await bundleSubmitResponse.simulate())
})
}
Searchers are required to pay a fee in order to make their bundled packages more appealing. This can be accomplished by increasing gas fees or by transferring Ether directly to the builder's address. By offering higher incentives, searchers can motivate block builders to include their bundled transactions in the blocks.
Through bundled packages, searchers can change the order of transactions within a limited range. This mechanism also reduces the likelihood of properly ordered transactions being front-run. Attack strategies in the MEV (Maximal Extractable Value) field are formed by combining external transactions with self-generated contract invocation transactions. These strategies include front-running, back-running, sandwich attacks, JIT (Just-in-Time) bots, time bandit attacks, and uncle block bandit attacks, among others.
Front-running: It involves profiting by preempting and replicating the transaction strategy of competitors. For example, front-running in the context of NFT minting involves outbidding regular users by offering higher gas fees to mint NFTs, thus grabbing a larger share of the minting opportunities.
Back-running: It entails competing for the subsequent positions of a specific transaction to gain profits. For instance, bots monitor the creation of new token pairs on Uniswap and create a large number of buy transactions once the pool is deployed. The strategy aims to be the first to purchase the tokens. Similarly, bots can monitor the activation of NFT contracts' mint() transactions by project owners to become the first to mint the NFTs. Most existing NFT minting bots on the market follow this principle and architecture.
Sandwich attack: When a user intends to exchange token A on a decentralized exchange, robots can create two transactions and sandwich the victim's transaction between them using bundled packages. The bot's first transaction buys token A, the victim's transaction subsequently drives up the price of token A, and the third transaction sells the same amount of token A, thus generating profits. The profit depends on the slippage setting of the victim's exchange.
JIT attack (Just-in-Time): This pattern appears in token pools within Uniswap v3. Due to the concentrated liquidity function of v3, users can set up a small interval for a specific LP position. When a user intends to conduct a large token trade on v3, the JIT bot immediately initiates a transaction to add liquidity and another transaction to remove liquidity, effectively sandwiching the user's transaction in between. This allows the robot to profit from the liquidity income generated by the transaction. This pattern requires the JIT robot to calculate the positional changes before and after the trades to ensure the user's transaction falls within the designed liquidity range.
I won't go into detailed attack techniques and steps in this article. You can visit https://www.mev.wiki/attack-examples for more information if you are interested.
Not all searchers are doing arbitration, and we can also utilize these mechanisms for positive purposes.
Safe Transfer: Some hackers may exploit stolen wallets containing NFTs for phishing attempts. Usually, the wallet lacks sufficient ETH to cover the gas fees for transfers. When the victim intends to transfer ETH for the purpose of transfer, the hacker uses a script to siphon off the gas fees. We can use Flashbots to retrieve the NFTs from the compromised wallet before the hacker takes away the gas fees you transfer. By creating a transaction to transfer ETH into the compromised wallet and another transaction to transfer out from the victim wallet, bundling these two transactions together, and sending them to a block builder, we ensure that the consecutive transactions are included in the same block. This prevents the hacker from preventing you from transferring the stolen NFTs.
When a searcher completes the construction of a bundled package, they can send the bundle to their designated block builder.
Block Builders
In November 2022, Flashbots made their block building architecture open-source, shedding light on the internal workings of block builders. A complete block building client is made up of two distinct nodes: a Geth execution layer node responsible for handling block building specifications and a modified Prysm consensus layer node developed by the Flashbots team.
In order for searchers to send their bundled packages to the designated builder, block builders need to expose an RPC endpoint. The builder module is comprised of two parts: the miner (Geth) module and the builder (Prysm) module. The miner module utilizes algorithmic programs to select bundles that meet its criteria and transactions from the mempool, and includes them in the blocks that are created. Meanwhile, the builder module maintains constant communication with relays and the miner module, generating block data that includes the block hash, recipient address, and additional information (often including the builder's name). Furthermore, a transaction is set up to transfer the entire block's rewards to the recipient address of the validating node.
Relays
Block builders require a trusted third party to deliver the blocks they create to validators without leakage. Similarly, validators need a trusted relay layer to ensure the legitimacy of the blocks. Different relays have their own characteristics and features. A validator can utilize MEV-Boost to connect to multiple relays and gain the maximum block selection power.
From the above architecture, we can see that relays also need to run consensus layer nodes and execution layer nodes to receive and send block information. Externally, relays have two APIs, one for connecting with block builders and another for connecting with MEV-Boost. This architecture allows for maximum reduction in communication and trust costs between proposers and builders while ensuring that block information is not leaked.
Proposers
After the Ethereum merge, a new consensus layer is added to the network. The proposer's architecture consists of four clients: execution layer nodes, consensus layer nodes, validators (with 32 ETH), and MEV-Boost.
This is also the underlying architecture for most Ethereum staking providers. The PBS architecture actually separates the block-building capability from the proposers, so that proposers only need to propose blocks from MEV-Boost and add them to the beacon chain. Similarly, MEV-Boost can connect to multiple relay layers, maximizing the interests of proposers. Ultimately, the rewards generated by searchers and blocks are paid to the proposers, who are the Ethereum staking providers, through this entire architecture.
When a user starts a transaction, it is added to the public mempool. For a regular transaction, it will eventually become part of a block created by a block builder after a certain waiting period. However, if the transaction is targeted by a searcher, it will enter the block as part of a bundle after being added to the mempool. It then goes through the relay layer and is ultimately signed and broadcast to the network by the block proposer. Users also have the option to avoid the public mempool by using a private node of a block builder.
Linking all of these processes together forms a transaction supply chain, which is at the heart of the MEV ecosystem. Understanding this supply chain is crucial for anyone interested in DeFi or blockchain development.
Image References:
About Chainbase
Chainbase is an all-in-one data infrastructure for Web3 that allows you to index, transform, and use on-chain data at scale. By leveraging enriched on-chain data and streaming computing technologies across one data infrastructure, Chainbase automates the indexing and querying of blockchain data, enabling developers to accomplish more with less effort.
Want to learn more about Chainbase?
Visit our website chainbase.com Sign up for a free account, and Check out our documentation.
Website｜Blog｜Twitter｜Discord｜Link3
