Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Post-Merge MEV Breakout Room #423

Closed
timbeiko opened this issue Nov 19, 2021 · 5 comments
Closed

Post-Merge MEV Breakout Room #423

timbeiko opened this issue Nov 19, 2021 · 5 comments

Comments

@timbeiko
Copy link
Collaborator

timbeiko commented Nov 19, 2021

Meeting Info

Agenda

@benjaminion
Copy link

Could a recording be made available, please. I (and some others) have a clash at that time, but would like to be able to catch up.

@timbeiko
Copy link
Collaborator Author

Recording for the call here: https://youtu.be/ivcI_plFu1o

@timbeiko
Copy link
Collaborator Author

Youtube comment with some questions:

Interesting video. Have a few questions.

  1. Is it possible to identify which builders / relays were responsible for constructing and relaying the payload and record this information in the chain? If that would be possible, then validators would be able monitor and weed out any bad actors automatically.
  2. Would there be a mechanism in place where builders can advertise constructed payloads to validators, and validators can decide to engage with new builders on the fly without requiring configuration change on the client side. This would create something like a market place where best builders will be the most profitable.
  3. Now 100% of the tips and rewards are deposited in the fee recipient address. So what about extending the mechanism by allowing builders and relays to add an instruction in their payload to deposit a certain amount or percentage of the tips and rewards into their respective recipient addresses. E.g. 99% is deposited to the fee recipient address, 0.5% in the builder recipient address and 0.5% in the relay recipient address. I realize that requires a new EIP. Appreciate any thoughts if something like that would make sense.

Thank you

@thegostep
Copy link

thegostep commented Dec 14, 2021

  1. Is it possible to identify which builders / relays were responsible for constructing and relaying the payload and record this information in the chain? If that would be possible, then validators would be able monitor and weed out any bad actors automatically.

Yes! Relays must sign the payloads which means MEV-boost can monitor their performance.

  1. Would there be a mechanism in place where builders can advertise constructed payloads to validators, and validators can decide to engage with new builders on the fly without requiring configuration change on the client side. This would create something like a market place where best builders will be the most profitable.

Yes, relays are in charge of aggregating from multiple builders and making sure the payloads provided are valid. Validators may be able to outsource selection of relays to some third party list if they don't want to get them individually.

  1. Now 100% of the tips and rewards are deposited in the fee recipient address. So what about extending the mechanism by allowing builders and relays to add an instruction in their payload to deposit a certain amount or percentage of the tips and rewards into their respective recipient addresses. E.g. 99% is deposited to the fee recipient address, 0.5% in the builder recipient address and 0.5% in the relay recipient address. I realize that requires a new EIP. Appreciate any thoughts if something like that would make sense.

You can do this without an EIP if the builder sets their own address as the fee recipient and inserts a transaction at the end of the block which pays the relay and the validator. The relay would then only forward blocks which pay them a sufficient amount.

@ronaldjmaas
Copy link

Thank you for your clear answer. I can imagine that best and most cost effective builders / relays will likely become the most popular. Looking forward to see how this is going to unfold.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants
@timbeiko @thegostep @benjaminion @ronaldjmaas and others