Conversation going deep into bundler competition, value leakage, and decentralization of relay systems. EIP-4337’s public mempool and fitting with intent-based systems being strongly debated, spotlighting complex interaction between user-aligned and validator-aligned relays.
As Ethereum continues to grow, such community-driven discussions are crucial for refining protocols, since they adhere to the spirit of decentralization while managing transactions efficiently.
Read the full conversation:
Alex | FastLane Labs
“I was under the impression that users would sign UserOps that would go into a public 4337 mempool that all bundlers could see.
is that not the case?
I actually was the one who was against widespread adoption of sendTransactionConditional on Polygon. In the PIP thread on the Polygon boards, you can read my explanation of how it would have DDoS’d validators and lowered their revenue.
I think the team settled on a limited implementation, and my team is working on a relay for it.
But we’re not going to build it so that validators who opt in will earn a lower yield than validators who don’t. That’d be silly.
(because none of them would opt in)”
Yoav Weiss | Ethereum Foundation
“Hey @thogard, looks like I missed a spicy discussion here. Adding my 2 cents on some messages here. It was a long discussion, so a lot to cover:
> So what’s stopping different bundlers from sending the same operation to builders?
How is that different from builder/searcher markets, such as Flashbots? Multiple searchers could send the same transaction to the builder. He flashbots relay guarantees non-revert so it can only include one transaction from a set of mutually exclusive ones. It picks the highest paying one. It requires simulation, which is much more computationally expensive than sendRawTransactionConditional. The latter shifts the simulation work to the sender (the bundler in the 4337 case) and reduces the builder’s work to just checking a limited number of storage slots. The builder no longer has to guarantee non-revert, just that this small list of slots hasn’t changed. Isn’t that strictly better than a simulation-based relay in terms of the amount of computational work?
> So the bundler who can extract the most will be able to bid the most. This alignment is incompatible with intents.
How is the alignment different from builders and normal transactions? The builder that can extract the most from the transactions will be able to bid the most, and will end up getting picked by the validator.
I don’t think it’s incompatible with intents, it just requires designing the intents system with this in mind. Unless you centralize intents, you have to make competitive bids to validators. You can bypass this problem by making intent solvers permissioned but as long as censorship resistance is one of the goals, it wouldn’t be the best choice. (and why would users use the blockchain if it’s not)
> https://forum.polygon.technology/t/pip-15-adding-support-for-eip-4337-bundled-transactions/12679/2
That is indeed a problem we considered. While it’s less work than a simulation-based system, there’s still work and we need to prevent repeated invalidations as in the case of an auction. There are different ways to mitigate it:
One way is a reputation system where each sender starts with 0 reputation (so it can only use a small number of slots/accounts and is rate-limited), and the reputation increases with every inclusion and decreases with every invalidation. It’s not part of the sendRawTransactionConditional doc because it’s up to each validator/builder to implement its own protection method.
Another is what Arbitrum did when they added sendRawTransactionConditional support to Arbitrum One. IIRC they check if the slots had the same values 1 second ago, not just at the time of submission. This kills the incentive to abuse it for offchain auctions. The players are better off sending transactions the old way, so at least they have a chance. A player that uses sendRawTransactionConditional will always be behind those who don’t. And for account abstraction it doesn’t cause a problem since validation relies on slots controlled by the user rather than something that is being auctioned. As far as I know, it hasn’t been abused by auctioneers on Arbitrum so far, and I believe there’s quite a bit of fee auctioning on that network.
Additional protections have been discussed by other rollups. The protection is outside the scope of the sendRawTransactionConditional specs since it doesn’t need to be uniform for an honest bundler to be able to use this method.
Wouldn’t Arbitrum’s method mitigate the problem you described in that post?
> A builder that extracts less value makes a block that offers less value to the proposer (validator).
Isn’t that how PBS systems should work?
As 4337 traction increases, builders will also be bundlers. A builder+bundler will be strictly more profitable than a builder without a bundler. The builder+bundler listens to both the transactions mempool and the UserOps mempool. It builds the most profitable block, using both transactions and UserOps (in one of more bundles it includes in the block). For ease of integration, it can just run one of the bundlers developed by the community (probably partnering with the bundler dev to produce more MEV-oriented bundles), and use sendRawTransactionConditional as the integration interface between the two processes. The bundler builds the most profitable bundles, and the builder includes it if it pays more than other transactions taking the same block space. The conditions specified by the bundler make it easy to place the bundle in the right spot in the block to ensure non-revert which would otherwise make the block less profitable.
Similarly to the mev-geth guarantee, the builder+bundler never earns less than it would earn as just a builder. If it doesn’t receive a bundle that pays more for the blockspace than other transactions, it simply won’t include the bundle.
> The trick is figuring out whether or not the 4337 alt mempool will still reject those ops.
The canonical 4337 mempool will. Bundlers should reject anything that can be used to DoS or grief them. The rules are not arbitrary – they are designed to protect the bundler. They’re intentionally not enforced on-chain since they protect bundlers rather than contracts. It’s perfectly legit to deploy accounts that violate the rules, they just won’t be served by the canonical mempool and won’t benefit from its censorship resistance.
If you come up with a different set of rules that still protect the bundler, you can set an alt mempool and use the same EntryPoint. The 4337 p2p specs even allow you to do it on the same p2p network, and only bundlers that agree to your alt rules will accept and propagate UserOps that require them. And since you’re using the same EntryPoint you can combine UserOps from your alt mempool and from the canonical one in the same bundle, producing the most profitable bundle from both.
Just keep in mind that DoS and griefing mitigation is not as easy as it seems. E.g. if you allow any of the banned opcodes during validation and you don’t make the system permissioned in some way, then it becomes trivial to grief the bundler by failing validations on-chain after passing simulation off-chain. I gave a glimpse of it in this post.
> Permissioning the bundler role at the smart contract level allows us to invert the flow of value without sacrificing decentralization.
How do you keep the system decentralized if bundlers are permissioned? If all the current bundlers decide to censor my UserOp and I can’t spin up my own bundler, is there a way for me to force them to include me?
Censorship resistance is a core focus of 4337. It’s much easier to build an AA system (and an intents system) if you remove that requirement, but we believe that this is what the blockchain should stand for. It’s also possible to build intents on 4337 without sacrificing censorship resistance, but it takes more effort. I’ll try to post something about that soon.”
Alex | FastLane Labs
“I think this might help with the understanding of MEV relays, because you’re certainly not the first person here to make this mistake.
Validator-aligned relays:
– Searchers pick user transactions out of the *public mempool*
– Value accrues to the Validator
– Validators / builders opt in to these
User-aligned relays:
– Searchers have *private* transactions from Users – this is called *private* orderflow.
– Value accrues back to the user.
– This is enforced by making Builders sign off-chain deals / partnerships – they are trusted parties here.
If more than one searcher knows about the User transaction then the User transaction is no longer private. The relay being used is no longer a User-aligned one because the builder or the validator will replace that bundle with one that they receive on a validator-aligned relay.
4337 mempool is public. It is a huge misunderstanding of the MEV supply chain to think that you can get the outcome of a User-aligned relay from an operation that is public… User-aligned relays only work with *private* orderflow.
Our thesis is that rather than leaking value to validators or relying on multiple, centralized relays run by middle parties that increase latency and decrease value return, we’ll just handle all of it with a trustless, decentralized smart contract. This also let’s us add multiple other neat features, such as multi-party flashloans.
And if users are comfortable getting execution that has the maximal amount of value extracted by bundlers then they can instead choose to use the 4337 public mempool via an entrypoint with a permissionless bundler. It appears that our system can still make use of the 4337 mempool, which allows for some robust guarantees. What we’ll recommend to most DApps is to set a block number limit, so that if two or three blocks pass without the operation being included by the intended bundler then it’ll open up to permissionless bundling.
I do think there’s importance in having a permissionless bundling spec. Like the public mempool, i think it’s a good fallback. Please don’t let the fact that my solution won’t be fully in-spec imply that the 4337 spec isn’t valuable, it is.”
Yoav Weiss | Ethereum Foundation
“> I personally find that verifying bundlers on chain using arbitrary smart contract logic is objectively more decentralized and trustless than any other system…
How is censorship resistance guaranteed that way? Can the smart contract logic prevent the permissioned bundlers from not accepting my valid UserOps?
> but the key here is that if the dApp *wants* to centralize the bundling to just one party then they can.
That’s fine. You can do that with 4337, e.g. by wrapping EntryPoint, or by performing a tx.origin check in the account itself. You just can’t do it in the canonical mempool because bundlers have no reason to accept and propagate a UserOp that they can’t bundle.
> Long term, I don’t think the role of bundler, paymaster, or even smart wallet provider will be sustainable. All of those can be trustlessly and permissionlessly abstracted, handled, and simplified (to reduce on chain gas cost) by external systems such as SUAVE. The replacement of middle parties with trustless smart contract logic that retains maximal user value is, imo, inevitable.
I’m not sure I understand this one. The role of the bundler is that of a builder, and in the long run there won’t be separate bundlers, just builder+bundler. And paymasters are just contracts with on-chain logic. E.g. a TokenPaymaster that accepts payment in ERC20 and pays for your gas. What middle parties exist in the system, once the p2p mempool is up?
> tldr; if your model involves 3+ middle parties, all of whom need extra-protocol relays to make $ to operate, then it might be worth rethinking the model.
Are we talking about the 4337 model? IMHO the model involves 0 middle parties. Just a fully decentralized permissionless p2p layer that builders+bundlers pick UserOps from. They do it for profit so they’re incentivized to participate.
> I think this might help with the understanding of MEV relays, because you’re certainly not the first person here to make this mistake.
I’m well aware of the two types. We just favor the first one in 4337, because it allows censorship resistance. With the second type, there’s no reason for users to assume that they won’t be censored, delayed, etc.
If you’re trying to build a censorship resistant system and it has “trusted parties” as the 2nd one’s description does, it might be worth rethinking the model 🙂
> 4337 mempool is public. It is a huge misunderstanding of the MEV supply chain to think that you can get the outcome of a User-aligned relay from an operation that is public… User-aligned relays only work with *private* orderflow.
Yes, it’s public in order to keep censorship resistance and prevents Robinhood-style attacks on the user. When using a private orderflow, do I have a reason to assume that the “user-aligned” relay doesn’t pull a Robinhood, delays my transactions and frontruns me?
But ultimately it’s just different philosophies. Mine is that trusted parties reduce the benefits that the blockchain gives us, so I prefer public. If I understand correctly, yours is that trusted parties get the user a better deal, you just have to trust them. Users trusted Robinhood, and it was worth it until it wasn’t.”
Alex | FastLane Labs
“The 4337 model in a vacuum is a decentralized permissionless p2p layer. It just has a lot of value leakage. My point is that to prevent that value leakage, I’d rather use a smart contract than the alternative, which is multiple centralized relays with multiple profit-seeking actors.”
Yoav Weiss | Ethereum Foundation
“How does this smart contract guarantee that I don’t get censored or delayed/frontrun?”
Alex | FastLane Labs
“This is a good question and I think the best answer depends on an understanding of SUAVE.”
Yoav Weiss | Ethereum Foundation
“> And if users are comfortable getting guaranteed-worst execution then they can instead choose to use the 4337 spec.
Or they can use an intents system on top of 4337, but choose one that doesn’t require trusted parties. Consider the Uniswap X model for example. IIUC, it doesn’t require trust and it doesn’t give you the guaranteed-worst. Your swap gets fulfilled when it pays enough for *someone* to execute it.
> What we’ll recommend to most DApps is to set a block number limit, so that if two or three blocks pass without the operation being included by the intended bundler then it’ll open up to permissionless bundling.
That’s a valid approach, and is already built into 4337. See validUntil/validAfter in the EIP. The account can return a validity time (which you can encode in the UserOp). No need to use a banned opcode for that. If that’s your plan, you may be able to do it without an alt mempool since the canonical mempool allows validity time ranges.”
Alex | FastLane Labs
“I think my original point was that intents and the permissionless bundling of 4337 are incompatible. An intent is an effort to capture the maximal desired outcome – IE “give me the most USDC for 1 eth”, not the worst-but-acceptable outcome. Any intent protocol that says otherwise is mislabeling itself imo.
I think validUntil / validAfter is for a slightly different purpose that what I’m envisioning.
But I will definitely keep that in mind and use it.”
Yoav Weiss | Ethereum Foundation
“Value leakage is indeed something we’d like to avoid as much as possible, as long as we don’t sacrifice things like censorship resistance. I’d be comfortable with a contract controlled network of centralized relays (each relay is centralized but the network isn’t, unless relays are permissionless). It’s what we did with GSN. But then there are two requirements to keep it decentralized: 1. The relay can’t manipulate the user’s intention without getting its stake slashed. 2. Relays are permissionless, so if all the relays refuse to serve me, I can spin up my own.”
Alex | FastLane Labs
“Right but a relay to what? Each bundler has its own relay, and the dapp frontend connects to just one of them?
That’s obviously not decentralized.
There’s a fundamental issue here – if more than one bundler knows about the operation then value will leak to the validator, because if more than one bundler is trying to bundle the tx then it’s the validator who determines which one of them actually bundles it.
This isn’t conjecture – we’re already seeing value leakage from bundler-on-bundler competition on polygon pos.”
Yoav Weiss | Ethereum Foundation
“I agree with that. You can’t run intents directly over the public mempool, except for time-based use cases like Uniswap X. It’s possible to build a decentralized intents system on the 4337 EntryPoint but it won’t use the canonical mempool. It requires a different design, on which I’ll publish something (hopefully soon).”
Alex | FastLane Labs
“Well if we can run our system over the 4337 mempool – which it sounds like we can – then we got you covered 🙂”
Yoav Weiss | Ethereum Foundation
“I think it can do what you described above. You can create a UserOp that does one thing (possibly incompatible with the mempool) until a certain time, and after that time it becomes compatible with the mempool and can be included. Not the intended use of validUntil, but can be used that way.”
Source: The Telegram 4337 Mafia group
Get In Touch:
Website | Twitter | Discord | Github | Telegram
Powered by Etherspot
BUIDLer React Component | TransactionKit | Pillar Wallet | AirdropMe