New Ethereum talks, every Monday. The week's conference uploads by event, in your inbox.

Loading player…

Bootstrapping a block builder by Sean Anderson | Devcon SEA

DevconThu, Oct 9, 2025, 12:00 AM

Speaker

The sessions aims to be a practical overview of how to go from zero to having a running and reasonably competitive builder (profits may vary). It aims to answer the following questions: - What software to run? How can this be customized? - What would need to go into writing a builder from the ground up? - How does one acquire orderflow? What is the relative value of various sources of orderflow? - What infrastructure is required? How much does it cost? Speaker(s): Sean Anderson Skill level: Intermediate Track: Cryptoeconomics Keywords: PBS, MEV, builder, blocks Follow us: https://twitter.com/efdevcon, https://twitter.com/ethereum, https://warpcast.com/devcon Learn more about devcon: https://www.devcon.org/ Learn more about ethereum: https://ethereum.org/ Visit the https://archive.devcon.org/ to gain access to the entire library of Devcon talks with the ease of filtering, playlists, personalized suggestions, decentralized access on Swarm, IPFS and more. Devcon is the Ethereum conference for developers, researchers, thinkers, and makers. Devcon SEA was held in Bangkok, Thailand on Nov 12 - Nov 15, 2024. Devcon is organized and presented by the Ethereum Foundation. To find out more, please visit https://ethereum.foundation/

Transcript

[Music] hello okay so bootstrapping a block Builder well over the past few months we've been looking into how do you actually join the block Builder Market I think the last talk did a good job setting up up how difficult it actually is um so we're attempting to the impossible I guess on some level this is a picture of relay scan which many of you may have already seen I think it illustrates the problem with the current centralization of the market pretty well you can see on the right hand side here there's two builders that are really dominating the market producing about 95% of blocks um and that's obviously a huge calization Vector for ethereum um the block builder at the end of the day acts as uh an Arbiter of inclusion to the chain the proposer Outsourcing its ability to pick which transactions to include and the inverse of this power is that a block Builder gets to decide which transactions to exclude so it has power over censorship of the chain as well so let's look at the Builder profitability tab here as you can see it looks like 600 eth per week is being made by each of these block Builders you might think you know this is pretty good business to get into um but this isn't entirely illustrative like it's not entirely comprehensive this number is derived from the balance changes on a builder's address after uh it builds a block it doesn't include any information that's offchain so like we saw in the last St uh there's a lot of competition for actually getting the transactions that you can then extract met from and then include in a block on chain so payments for these types of things are probably being made offchain um and the purpose of that is one just privacy for the transaction flow provider and two back running or front running protection um so the or at least like exclusion of front running rights something like that um so it's these numbers are actually a lot more opaque than this we don't know exactly how far off this is it could be something like a factor of 10 um we don't really know all right so where's the competition because in spite of this you would still probably expect there to be more builder competition you can see two years ago relay scan looked a lot different there's something like nine different block builders that each had more than 6% of blocks being built and no block Builder had more than 177% of blocks being built over the years more than 40 block Builders have ceased operations um so why have they been failing I think you could chalk it up to competition on some level um just there simply being out out competed on a in a zero some market so let's hone in onto like what is the role of the Builder to try to figure out like why are they failing why are they shutting down um here I want to make a distinction between a Searcher and a builder where the Searcher is the very specialized party that's actually extracting the Mev um the Builder's more of an aggregator of the uh Searchers output and then the party that's participating in the bids to actually get blocks on chain um so that's the part the interaction with the relay there um some Builders choose to collapse the Center two blocks the Searcher and Builder um it could be more efficient to run both of these processes in process there's no like communication overhead there um the downside though would be if you have that type of setup you may not be able to get other Searchers to work with you and the Builder since it's an aggregator it has a high incentive to um get bundles from as many Searchers as possible in order to get them most competitive block um and over here if we look at the order order flow provider this is another party that like may or may not be distinct from the Searcher a Searcher may have with it its own unique order flow um if it's doing sex Dex Arbitrage the Searcher itself might be an orderflow provider um but at the end of the day the the flow of money here it sort of moves away from the Builder on both ends the Searcher is paying for the rights for transactions on some level the tra the Builder can be like a proxy for this it could be like a broker for this um and the money being paid here is going to an orderflow provider something like a wallet something like an RPC um and on the other end the any excess bid that a search is sending to a builder has to be aggregated and used in order to be competitive in the block building auction so in the limit the money is moving away from the Builder on both ends so the margins are compressed as there's more competition between Builders um so you can start to see how it could become a very tough Market to participate in so specifically what is the Builder doing why should it exist in this interaction one thing is it's it is the expert in actually getting a block on chain so it has a broad like a breath of knowledge as far as what transactions are available um it has the ability to um make certain guarantees for certain transactions that they can get in in a timely matter this might be important for sexx Arbitrage for example a builder can also provide privacy guarantees so it can provide privacy to an orderflow Prov provider which would be good for not front running potentially it can be provide privacy to Searchers as well so that they're Mev strategies aren't leaked and it can also provide other sets of guarantees so for a Mev Searcher it might be a specific position within a block which enables some strategy uh can guarantee atomicity of bundles of transactions so they like execute and sequence on train on chain and then also so giving a guarantee that if there's contentious State like your transaction will execute like it won't revert um so these are all valuable things that a builder can provide um if we go back to this diagram we if we start to think about the Privacy component here of a builder we need to look at the private transaction flow so orderflow provider to Builder and eventually the searcher the Searcher needs to have access to these transactions in order to um extract me from them so it needs to see the private transactions but we don't want leakage um so how do we add privacy guarantees or some some conditions of privacy to this well one way to do it is if there's public order flow auctions you can add obfuscation to transactions so this is what flash Bots meev share does Mev blocker does um they allow like a more permissionless auction for order flow but uh there's some degree of appliation for transactions so Searchers can on some level extract Mev but not like perfectly perhaps another major way to do this is via like offchain agreements probably legal contracts so that would that would be like the orderflow provider and the Builder and the orderflow provider and the Searcher enter into legal agreements to say like these transactions have to be private these are the conditions if not and the need for these types of legal contracts is a big centralizing force uh because this requires like administrative overhead for the Builder it requires some degree of reputation in the space you have to be a public uh figure on some level and a lot of actors in this ecosystem prefer anonymity especially Searchers um so that's another big Buri to entry okay and so this is actually the paper that was in the last talk um and I think it does a good job illustrating how critical the order flow is to this whole um the success of the Builder and some of the key takeways included the diversity of order flow is very key it correlates to the success of the Builder and I think hand in hand with that is the exclusivity of of a specific Builder's order flow and it makes intuitive sense because if two Builders have access to the same set of transaction you're probably just competing on computation on latency but if one Builder has the most important transaction in the set all of a sudden he just has perhaps an in insurmountable Advantage so this is the key thing to focus on I think as far as bootstrapping a builder and how do you do it well you could just try to win these orderflow auctions they are very competitive if you're you have a separation between a seon builder then you need to work with a Searcher as a builder to get like a specialist to like work with you to win this it would be better if they worked just with you um that might be easier said than done another interesting approach this is sort of what Titan has done over the past year is to focus on like feature richness so making features in your Builder that are conducive to a Searchers searching and that might attract them to use your Builder and they might bring with them maybe order flow that they possess um so a specific feature would be if you send the Titan Builder a transaction that runs out of gas they'll just front the the payment for the gas for you so long as the builders balance increases at the end of the transaction um and then subsidization you could view this also like a feature on some level like it's a feature very directly in that the Searcher ends up having to tip less because you're just paying for the searcher's inclusion but also if a Searcher is running some sort of strategy where they need maybe like a 10% chance that their block ends up on chain you might have to subsidize in order for them to have that probability and then yeah major component is just business development so this is like actually making the relationships with orderflow providers with Searchers um the things that go into this include like building an ecosystem represent or reputation and making legal agreements contracts being a public presence all right and can we get rid of these off chain contracts because these are like really highly centralizing I think it's reasonable to think of tees as a potential replacement for a legal contract because if what you really want is just to keep the execution of the transactions private or the execution of the Builder over private transactions um tees can let you do that and they can let you do it with a pretty minimal performance impact they're not bulletproof though and because of this like if it's really like high value transactions it might still require a legal agreement in conjunction with the te so this this isn't necessarily a catch-all solution something that would hopefully be more of a catch all is like a pure cryptography solution um something like threshold encryption or fully homomorphic enry encryption but both of these add a lot more of a performance overhead especially presently but maybe in the future that can be reduced to where the performance tradeoff versus the trustless isn't quite as great um so let's look at specifically the Builder software because actually working with this is a barrier to entry in itself there are some open- Source options that are good the ruer Mev RS um what you can do is you can extend these you can start with these to like help you hit the ground running um at some point you might need like more optimization maybe optimization you don't want to share because you're trying to like bootstrap your Builder you want every Edge you can get especially if you're trying to overcome these other network effects like orderflow um so that might lead you to trying to start a builder from the ground up that would also help you build some expertise in in your Builder all then infrastructure this is another barrier to entry a lot of the game for a builder is minimizing latency uh you want to minimize latency because if you're able to include a transaction that's produced later then that broadens your set of transaction for potential inclusion in your block like maybe the most valuable transaction in a slot comes like just before the end um and you can include it no one else can that would be an advantage you want to minimize latency from transaction origination to your Builder and you also want to minimize it from your Builder to the relay the way to minimize transaction uh origin latency there's a few ways but you could use use like an optimized me pool there's some third party services that do this you could build your own sort of infrastructure for this where you have Sentry nodes around the network and maybe they're directly connected to each other and just like sending transactions back and forth you could also potentially collocate at an orderflow provider that would be like how to minimize it maximally um but on the other end you probably want to collocate with a relay um because that's an easy way to minimize the latency from the Builder to the relay obviously um and relays might be geographically distributed to serve different proposers around the world um like with lower latency so you might also want to collocate your Builder with a single relay but at each instance of a relay so generally this leads to you probably want a very flexible uh devops infrastructure setup you probably want to use something like kubernetes because um at some point you might want to horizontally scale as well so if you want like multiple clusters around the world horizontally scaled it gets pretty complex and the cost runs out pretty quick because you're dealing with full nodes for a lot of this and full nodes are expensive to on all right and then projecting the role of the Builder into the future this is another challenge in trying to start a builder is it's not really just a a stagnant Target you're aiming at it's a moving Target so you'll probably want to incorporate what do things like base sequencing pre-confirmation epbs like how do these impact um how your your Builder will develop in the future like maybe if you can get ahead on one of these things that would give you a bit of an edge to try to enter the market um it's interesting pre confirmations are actually similar to the guarantees you would get now from a builder as far as like oh like I want to be I want this traction like not to revert but they happen earlier in the slot and they can happen uh with the risk of the Builder losing collateral otherwise so there's kind of like some overlap with a pre-confirmation and like a builder's current role and yeah so right now we're building blocks on heski it's a lot easier there lower competition thankfully um our intent is to try to make a builder that's competitive and from there work on trying to push the boundary of how to decentralize it how to make it more transparent how to make it more permissionless um this feels like a more natural approach to us as opposed to starting with a theoretical solution and trying to make it performant um probably because we're a team of Engineers um yeah that's it thank you thanks Sean I hope that inspires a few people here to try something out if I could just have you in the middle we're going to take some of these questions but please feel free to keep submitting them first one what prevents a builder relayer or proposal from themselves front running a searches bundle Builder relay all right so the Builder wouldn't front run the Searcher bundle because they would have some sort of agreement and this is where like either the aisc comes in or maybe a legal agreement or just trust um that like the Searcher will continue to send the Builder bundles unless you know they build a front run them but from the relays perspective the relay is like a trusted intermediary where they they'll see the bundles and they serve the purpose of actually blinding the payload and cashing it before sending it to the proposer and the idea there is that the proposer is going to be like the most distributed Anonymous actor here so they have they would have the easiest uh way to I guess just steal the Mev and you know just wait for the next proposal in like six months they don't really care but the relay has to have some degree of reputation because it's acting like every slot so yeah all right so next question question does Builder benefit from being closer to popular public RPC servers such as latency benefit oh yeah I think definitely it's tough to say like we don't have like empirical evidence to this yet but you want to minimize that type of latency if possible if that's where you're getting order flows from but also latency to the proposer or to the relay um and which of those Dimensions is more valuable to optimize for I'm not sure if might be better to do it near your orderflow provider because you don't know which relay is going to have the block that wins the auction for example okay next one do RPC providers like Alchemy or infura sell a transaction for order flow should we take precaution against this um yeah they might I don't have personal insight into this but yeah they might should you take personal action I mean you could try to put pressure on these rpcs to say like oh if you're selling this like I should get a rebate like if my transaction is going to I should get some money back for that I think that's like The Natural end state of the market um it's just not quite there yet okay what do you think of execution auctions and how they might change the function of the build oh I think execution auctions are really cool one thing it does is it kind of generalizes the interaction between the Builder and the proposer all of a sudden the Builder doesn't have to like go directly through the proposer to broadcast a block it's like you buy the block beforehand a builder would and then you have the rights to like do your best job building um so in some ways it simplifies it it's sort of like it could be viewed as making the building set more permissionless but you obviously have these other Berry stes still so maybe not quite okay uh what if a proposer such as node provider is launching his block Builder without a relay is it bad a node provider with his own block Builder without a relay I I think it depends if the proposer if this is like a big set of proposers using a single Builder that would be bad if it's a single proposer with their own builder that doesn't seems so bad it seems the same as like you're using a local block Builder but the best version of that if every proposer had their own highly optimized block Builder you'd still have this really decentralized block production uh Network so you'd still have the same like censorship property as we have today okay uh next one I'll allow you to choose which one of the Tre as the last question okay yeah um public on CH okay is the link between Searcher and Builder's public on chain for instance which Builders which Builder a famous Searcher like Jared from sub uses oh okay I think they actually touched on that in the last talk um and they were able to see that recently Beaver build is getting more flow from Jared so there is way to track it on some level but we haven't dug into this too much sounds like the last team did okay thank you very much Sean for your session please another seven

Automatic transcript — names and jargon may be misspelled.