Ethereum Cat Herders PEEPanEIP, 27 Feb 2023

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: PEEPanEIP #101: Builder API (Shapella) with Gajinder Singh

Description

Topics covered
-------------------------
0:52 - Guest introduction
1:29 - Capella Builder API
1:52 - A sidecar to Ethereum Execution
2:28 - A top-level overflow
4:07 - APIs available
5:00 - Changes in Capella
5:02 - buildBlindedBlock & publishedBlindedBlock
7:00 - Builder vs Execution now
8:07 - Builder vs Execution Capella
8:37 - Builder vs Execution Free the validator
9:32 - Proof of Payment
11:32 - Zhejiang testnet
12:04 - Upgrade & testing considerations
15:38 - Why Builder API?
18:00 - How does the builder ensure that withdrawals are included?
19:22 - Testing: Match withdrawal use builder
22:00 - Testing: Fall back on local execution
24:40 - Future of Builder API
27:17 - A message to the Ethereum community

Resources:
-----------------
Slides - https://docs.google.com/presentation/d/1PWmM5cPL2WPYrcOoxg6Zd-dnZEYPAyq5W4CV4QytVkw/edit?usp=sharing

PEEPanEIP - https://www.youtube.com/playlist?list=PL4cwHXAawZxqu0PKKyMzG_3BJV_xZTi1F

Non-EIP - https://www.youtube.com/playlist?list=PL4cwHXAawZxpby7LszzOnyuAyQl8WLLvh

Questions for Guests - https://docs.google.com/forms/d/e/1FAIpQLSdsmujnH_ncIlSEJ23s9jzXAKwfpTGNeJqjREWPloBbkJVQTA/viewform

Check out upcoming EIPs in Peep an EIP series at https://github.com/ethereum-cat-herders/PM/projects/2

Follow at Twitter
Gajinder Singh @Gajpower | Pooja Ranjan @poojaranjan19

Client Diversity Survey - http://tiny.cc/ECHsurvey

Contact Ethereum Cat Herders
---------------------------------------------------
Discord: https://discord.io/ethereumcatherders
Twitter: https://twitter.com/EthCatHerders
Medium: https://medium.com/ethereum-cat-herders
Website: https://www.ethereumcatherders.com/

A

A

Piece of information that can help you understand, ethereum protocol, if you heard about pillar API and want to learn about its importance in Capella, upgrade on consensus, layer client continue listening.

A

Welcome to p penny I'm Pooja ranjan with the first episode after completedness Century on this ethereum educational series. Today we are going to talk about ethereum Builder API, to learn more about what it is and what role does it play in helping withdrawal with capella a great we are joined by kajender Singh? Welcome there.

B

A

For people who aren't aware uh kajinder Singh is an ethereum client developer recently joined the EIP editing team as well. He has joined us on Peep and eat a couple of times before to talk about lodestar and ethereum Js.

A

If you want to learn about these clients and others check out our know, your client series on p penny well, as per today's topic, Builder API. The term was mentioned in almost every CL meeting right before the March and I'm curious to learn more about it. So without further Ado, let's peep in.

B

Hey guys, we are here to talk about uh Builder, apis and kapila, as you would be more familiar with the more popular name, I mean with Boost and, as you know, that Mev boost is used to build highly profitable blocks on ethereum blockchain, some Arbitrage opportunities that are out there and they submit private bundles, which are not visible to everyone. And if a validator includes those private bundles, the payout to the validator is quite high. So the way this works is that Mev boost is a sidecar to ethereum local execution client.

B

So our validator bill request to build block on local execution client as well as on a builder, and it will then basically select one of the blocks and then it will basically propose it and include it in the blockchain and as a result, the validator should get a good payout.

B

So if you look at the top level flow, what really happens is that a validator needs to register itself to the to the Mev boost relay and maybe boost Builders, which is like a Marketplace. So there are people who are basically submitting these private bundles and they are sort of bidding that okay. This is the price they would. They would be happy to pay for that bundle. And what really happens is that value data also registers themselves to the me to the builders, and so so.

B

The flow starts with registration of the Builder registration of the validator to the Builder, and when the time for proposal comes a builder, will a validator will ask for a payload header which, which the Builder will reply and provide and that payload header will not have any transactions in it, because the entire purpose of uh Mev boost is me of of Mev boo.

B

Slash Builder is to hide the transactions until they don't need to be hidden anymore, which is basically when the validator has actually signed the payload, which is generally called a blinded, payload blinded block, and then that block is signed and submitted. Then Builder actually constructs a full block and publishes to the network, as well as provide the full payload to the client, which can also construct and publish.

B

So, on a high level, these are the apis that are out there.

B

So one is to request uh one is to register yourself, then the second one is to get a payload header which has transactions root instead of transactions, because again uh the transactions should be hidden till the block has been signed and submitted to the Builder and the third and the so that is where the third API comes in, where you construct a blinded payload, which has transaction root instead of transactions, and you give it to the Builder and basically, you get a full payload and the last one is just to keep polling this.

B

What is the status of the Builder? Because, obviously you wouldn't want to interact with a builder which is down and sort of risk, losing your proposal.

B

So, as we discussed, there are two two major parts of how the biller API works.

B

One is build blinded block and then so second is publish Blended block in the bill, binded block so Valley when the validator calls to build a blinded block, then, as we discussed before, Builder, will reply with an execution payload header which has transactions root and it has some bid value and when you submit a blinded block which has transactions root, then the Builder will reply you with an execution payload that has full transactions, which you can again construct to kind of use, to construct the full block and publish it.

B

So what is new in Capella right? So everything else is totally the same, but additionally, now with transactions, you you also get withdrawals root, which are basically withdrawals.

B

uh Root of the withdrawals in the block, and actually this withdrawals root is not really required in the sense that the withdrawals in a block are very, very deterministic, and even if the Builder does not provide you with withdrawals root, you already know what withdrawal route should be, and so basically this is how you check whether when the Builder has given a withdrawals route, you can match it with what you locally expect it to be and again moving to the second step.

B

When you actually submit that blinded block to the builder, then it gives you full execution payload, which has transactions as well as withdrawals, so everything else, Remains the Same, all the apis are the same. What really changes are these extra parameters that you get in the data and that is submit.

B

So what really is the new thing that will happen in kapila? Is that what is the more interesting thing that that will happen is now is that even execution will start giving you uh giving you the block value, but right now, what really happens is that Builder gives you bid value like along with the execution payload header, but when you call local execution and get a payload from it to include it in the Pro to include it in The Proposal, you only get transactions. You don't really get any block value that is out there.

B

So you can't really compare that. Okay, you know what to choose a validator. Basically can't really make a selection out there most of the times. What you really do is that you put a main bit value on your local Mev relay, which basically filters out uh filters out uh the the blocks which don't pay you that much.

B

But right now, with capella, what really happens is What will. What will really happen is that a new version of get payload is being introduced on the execution, clients and those clients which support this get payload V2. They will all all. They will also give you block value with it, and you can directly compare it up. Validator can directly compare it with the builder bit value and basically select whatever is more profitable to it.

B

So do it in late load star, you just need to provide an extra Arc which is minus minus Builder or selection, Max profit, and it will basically couple onwards. It will start making the selection base based on what is paying more, and this is also important not only for profitability, but also for censorship, because a lot of the Builders out there, they are censored and they basically will not include some particular kind of transactions, but execution clients don't have that restriction and they tend to include all the transactions that are in their mempool.

B

So what really will happen is that if your local execution client will Build a Better Block because of the transactions that the Builder is trying to exclude, then basically, you are also defeating censorship, with this particular upgrade.

B

So what else is desirable from the Builder I mean.

C

B

Gives you transactions it gives it it gives you transactions rooted, gives you withdrawal routes and obviously it will give you the full payload as well. But when you are, you are trying to build a block, a blinded block or from the Builder by getting the header. You also want a proof of the payment, because, right now everything is on that. So there is very high cost level on the builders that you are using that whatever bit that they are they are, they have included in their response.

B

That is a bit that you would get and there is some level of trust out there, because proposals are very few. Like you know, up valid data is getting carrying to make four proposals, so each proposal is very valuable and you would want that. uh Basically, you, you don't really have to trust that much and you can verify so earlier. People would be able to verify it verify in in so when an execution client is making a block, uh you will basically provide it a free recipient to which all the fees will will go.

B

But when a builder really uh gives you payout, it gives you payout in form of a transaction.

B

So it is not that stiff State forward, and you would basically expect that there is some proof of payment, because if there are no transactions at the time when you have to make a decision- and this is before you actually sign the block- and you don't have any transactions at the time, so it's pretty important that Builders will start include, should start including proof of payment proof of the bid value into their blocks, which can be cryptographically verified on the beacon or on the validator client.

B

If we look at the ground Readiness for the withdrawal builder for the capillabita Builder, basically I I feel that we have reached to the point where we are ready. For example, Mev boost is being tested on ggang test net, and here is a block that was proposed by a lot so again on ggang net and test net, which was an MAV boost block using the same Builder flow that we talked about.

B

So what are the considerations that we have for this particular flow? Be Builder as an Eco as a component in the ethereum ecosystem is a third party component. uh So what we really want to do is that we want to test not only a good flow. We are happy flow where everything works, but we want to test whether test the flows. Wave Builder doesn't work and uh ethereum blockchain carries on so what? What is this? What this particular feature is called.

B

Second breaker and most of the clients have this, and what really happens is that if, for example, the blocks uh from the Builder are more formed in some way, uh so the clients on the network can see. Okay, you know the proposals on the networks are failing and they basically switch off the Builder and they propose using only their execution. Clients till the network is Network. Health is backup, so most of the clients have this, and this is also being extensively tested.

B

Another thing that requires consideration is that, if, for example, Builder gives you a bad block which are able to test locally before you sign it, uh so you should be able to fall back on the execution client block, and this again is a feature which most of their clients will be having, but again it it is to be extensively tested and obviously the third thing is to uh optimize to basically aggressively verify. The withdrawals wrote that the Builder is setting sending.

B

You is the expected withdrawals to that that your local client will say it should be, because withdrawals are very, very deterministic. There is no, if and but over there, there's no chance to have a different withdrawals at up at any particular block. So this should be aggressively verified before even considering or build a block.

B

So again, regress testing is going on. They have been withdrawal devnets on gtang network and their Shadow folks, main net Shadow folks, and for which kudos to EF devops and all the client teams, and now the hype tests have come out which basically test whether the all these conditions were how the client is doing in all these conditions, whether there is a circuit breaker that is happening or is there a fallback on the local execution or all they matching withdrawals route with the expected roles or not because happy flow is one thing.

B

We have to make sure that the ethereum blockchain Carries On, even if the builders are not ready and if and if they give us small font blocks.

A

Right, thank you so much um and the presentation was really beautiful. I love the Builder flow of sharing the functioning of protocol. I know our podcast listener may have a hard time following it on audio, only mode but I'll, make sure to add the presentation, link and a video for reference so yeah. Thank you. So much for that. Well, I have a few questions for you. um uh Some some of the questions are on High level on a builder API.

A

So let's start with why Builder API so building block, um as we understand, is a key component of blockchain. In my mind, avoiding trust assumptions is the best way forward to provide a highest security to the network, um but we know the Builder API requires a higher trust assumption than it was proposed in PBS, and yet we focused on building this API. Do you have any thoughts on? Why choose Builder API.

B

I mean I believe we would everyone in the ethereum ecosystem would recommend you not to choose Builder right. Not to choose me we boost, because obviously, that part of the component again as I have said is you place, is a third party component.

B

If you consider, in terms of the remical system and what really, what what really are the first body components, are your consensus, layer and the execution layer, and uh so so again, when, basically, you have now asked a third party to provide you a block and they will say: okay, they will do an X payout on it, and so there are two things where the uh where you are placing your trust in them.

B

One is that, obviously they will pay you out, because right now, no payments proofs are included and second, they have included all the transactions that are there and there is no such strip that is going on. So basically what it really means that you are also trusting that okay, these guys are giving you a block which carries uh the full value.

B

So there are two two places where you are really placing the trust, everything else you are able to verify, because when you have transactions root, you can be basically verify that the rest of the state that is being generated is all good. But again you don't have any uh view into the transactions before you actually sign and submit it to the Builder. So you are therefore placing a lot of trust into the builders for doing the right thing, and that is something where, uh where changes are are.

C

B

Being proposed, one is again for for the builders to include payment proofs, and the second thing is: there are some transaction lists that could be provided to the Builder to include those transactions and make sure that no censorship can happen at the Builder level.

A

Thank you. um We know when Builder API was introduced. It was introduced as a temporary solution to like high fixed cost of efficient validator, with a higher trust assumption. Now, with this capella upgrade, we have added further improvements to help out with the withdrawal. I see a question here in chat James. If you would like to ask the question here related to withdrawal.

C

Yeah, how does the Builder ensure that withdrawals are included.

B

So if you look at the response that the Builder Builder gives you so when you ask when the proposal time starts- and you ask Builder to give you a header which is basically an execution payload header, uh so it has to give you a properly formatted execution, payload header and for the capillar hard Fork. You will expect it not only to give transactions root, but also the withdrawals root and as withdrawals that are there that are to be packed in the block.

B

So they are 100 deterministic, and so you can easily verify whether the withdrawals root match with the expected withdrawals root. So you can locally calculate that and sort of match. It.

A

Thank you. We were talking about uh specs testing earlier, um like the changes that has been introduced with the capillary upgrade. We all know. Specs testing goes without saying for ethereum and for every minor changes we want to do double triple checks, be sure about it. We know that Mev boost is already on jizong test net. um Could you maybe talk a little bit more about the um match? Withdrawals boot feature? uh Is it already on hive or any other internet.

B

Yeah, so all the clients so um doesn't matter whether you use Builder or execution.

B

So when a new block comes in, it is very deterministic what withdrawals will get packed into it and it is sort of part of the consensus and so the next. So if you meet a block and other crank, other clients are trying to import that block. They will very they. They have to check, and it is part of the spec that the expected withdrawal should match.

B

So you locally calculate what the withdrawal should be and basically, then you have to match and similarly for the builders, since you don't know what the withdrawals are, but you can match with the withdrawals root and obviously, when you get the full payload, you will construct it and again it has to match that. Okay, this. These are the withdrawals that match with this withdrawal root, and these are the transactions that match with this.

B

These are the transactions that match with this transaction root, uh so there there are, uh they have spec tests that are out there. That will basically feed you blocks and they will basically make sure that you catch the error. If there is any discrepancy in the withdrawal route, also, the state uh State also has a flag which is directly dependent upon uh what withdrawals are packed into that block. So there is next.

B

So there is a flag to determine what is the next eligible validator for for the withdrawal, and so there is some State matching that is also going on, so not only it happens in the at the Block Level, but also at the state level. uh There is some match that is going on and if the clients are not in agreement, obviously the consensus will break, and so we started when all the testing started.

B

We saw some of these things and then obviously we, our clients team, went back and fixed all those issues, and then we have got these pack test when we have got uh uh tests that are happening on jjang network. We have the shadow forks and now we also have the hype test which basically tests the same thing.

A

So um talking about this hype test, we got to know that the Builder API circuit, breaker testing- is also going on that does it also cover the fallback on a local execution.

B

Yes, it covers the fallback on the left, local execution, because when the circuit breaks, then basically local execution has to pick it up right. So it does cover that that thing, but even without the circuit breaker getting triggered, for example, a client which is uh a validator which is basically making a proposals, for example, load star. It will start two flows. It will start a flow with a builder as well as it will.

B

It will start up build block flow with the local execution, and if the Builder is failing because, for example, it gave it didn't give withdrawals root or it gave a malformed withdrawals truth, then the local execution block will be picked up and I think these are the tests which are out there right now.

B

What Hive is testing is that, okay, whether the circuit is circuit breakers, are coming in to play and if they are coming into play, whether the local executive education client is taking over or not, but even without the circuit breaker coming into play. The local execution client can basically take over and say that, okay, if a bad block is being being given to you and if you can sort of detect it pre-signing it because sometimes even a state in the block can be malformed, which you can't really figure out.

B

Unless you execute the transactions and since you don't have the transactions before signing, it is not possible to evaluate that. So unless that is the condition that is out there, you will be able to figure out whether you are getting a good uh block or a malform block. And if that has that is the case, then basically the validator should pick from the local execution and most of the clients, including lot star. We have uh those test cases running in our CIS uh and uh so I I.

B

Don't really think that you know I think this is well covered with the current uh testing that is going on.

A

Awesome that is always helpful to know all right. um I have a question about the future of Builder API so as we know uh that it was added as a temporary solution before the March right before the merge, uh and we know that um PBS at that time couldn't have been added because that required some modification to the beacon chain. Now that robust incentive group rig a division of ethereum research is working in the direction of getting more information on PBS and having it in a better place.

A

Do you think PBS will replace Builder API in future, upgrade.

B

I mean, as of now it doesn't look likely, but because what really is happening is that what all these Builders they have, they have come up as some sort of a marketplace where people submit private bundles right and then they are validators which are hooking up to that. So there is some Network effect that is going on over there.

B

Whether the new system will be able to overcome that Network effect and how actually the logistics of people submitting their private vendors, because obviously nobody wants somebody else to front run their orders when they are trying to extract.

C

B

Out there on the blockchains, so that is something that I'm not sure of how it will work, and if there is I mean there is no clear solution onto that, and so it is more a problem of of the ux in terms of the user flow rather than technical challenges. Maybe some of cryptography in terms of zero knowledge, proofs can come over there and sort of help up help this entire process and make sure that people can submit private bundles and they don't really have to go to some propriety marketplaces to do that.

B

So that would be awesome.

A

Right I mean I, don't see, PBS proposal, better separation to be ready right away. I do not even see that coming up with the Cancun upgrade or Cancun app upgrade um yeah. This could be maybe more in a long term. Yeah all right for people interested in learning more about proposal, Builder separation or PBS check out episode, 93 on PBS, with Barnaby manath on T penny.

A

All right, it's time to wrap up. Is there anything that you would like to add or share with the etm community.

B

So what I would like to share is that uh please go to clientoveristry.com and look at the clients that are out there and pick up a minority, client combination and run it and me are blogging from the Lord Star team. I would definitely bet for load star and, as you can see, load star is also couple already in terms of all the features and in terms of Builder flow as well. So please don't hesitate and try it out on testnet, and if you like it, then on mainnet go for it.

A

Absolutely and to add on here, ethereum Cate address are currently running a survey on client diversity in which we have um options for you to share what you're expecting for from your client, both on execution layer and on consensus layer. So if you haven't taken the survey, consider taking out time and respond to the survey to let your client provider know what is your expectation and also do not forget to Kudos them with whatever feature you are enjoying, the link will be available in the description, so yeah check it out.

A

Gajinder Singh. We appreciate you taking our time to talk us about the psycha to ethereum chain. I. Hope to see you again on show with a different topic.

B

Thanks, we are always pleasure to be here according.

A

To the ethereum Builder API specs repository the winter API is an interface for consensus, layer, clients to Source block builds by external entities. The operational functioning does not affect users or validators directly, however, understanding the workflow increases the transparency and the Trust on the robust ethereum blockchain. How do you like today's non-vip episode? What topic you would like us to cover? Next?

A

Let us know in the comment below, if you want to learn about latest ethereum research topic subscribe to ekeedom Caterers YouTube today reach us at this call to follow the amazing world of ethereum catering, we'll be back with another interesting ethereum topic, so stay tuned and keep sharing your love with ethereum Caterers cheers.

A