-
Notifications
You must be signed in to change notification settings - Fork 217
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
Upcoming mev-boost release: v1.4.0 #377
Comments
The remaining PRs have been completed and merged. Major improvements:
Minor, but noteworthy:
Next steps:
|
Prepared release candidate 1: mev-boost v1.4.0-rc1
|
Help output with cli args:
|
Found an issue in requesting gzip encoded responses. Fix: #382 ( |
Turns out, Go http requests add Also merged #380 with minor cleanup
|
Tested (Also tested on Goerli) |
This release will be out within a week or so. The reason for being slow to roll out include (a) ongoing discussions about whether to include #297, (b) wanting to add this release to this week's CL call, and (c) me being on vacation until Thursday. |
Merged two more notable PRs: And a few minor PRs. See v1.4.0-rc4...v1.4.0-rc5 Prepared v1.4.0-rc5 last expected release candidate
|
Should we remove the strict json decoding from the getPayload call to accomodate future consensus changes in a backwards-compatible manner? And add this to the current release? For instance the upcoming Capella and EIP-4844 changes will modify certain payloads, which would guarantee to break in the current mev-boost version because of the strict JSON payload decoding (disallowing unknown fields). See also #392 for more details about the specific changes. |
We may also want to revert #299 now, since it would incorrectly alert to have received a different block hash once the new payload fields are live. |
is it not better to keep the strict {en,de}coding and instead just support versioned types? -- we have to address this problem in e.g. the beacon APIs so we can just do something similar here |
The strict en/decoding is only used in a single place (decoding the getPayload request body from the beacon node), where it doesn't actually serve a purpose, since the full payload is already read before (therefore it wouldn't protect from resource exhaustion). I think it'd be better to remove the constraint in the decoding, which has no downsides but leaves more options open for the future. Fwiw, i've heard various opinions from CL devs about adding a new API version in the builder specs for each payload change vs adding it in a backwards compatible way. |
Wouldn't there still be a problem? The |
Yeah @jtraglia that is correct. I think we can leave the json as is for now, and it will be a mandatory mev-boost upgrade along with EL+CL anyway. Cutting a new, possibly final, release candidate now. |
Created a new release candidate based on current main. Feature freeze. v1.4.0-rc6
Next steps:
|
ETA for publishing this release is tomorrow - Wednesday Nov. 9, 2022. |
I have some error messages:
Args:
|
Also:
|
Thanks @nalepae 🙏
|
Ran |
A number of improvements have accumulated since the last release (v1.3.2 on September 22, 2022), and it's time to think about the next release v1.4.0!
These are the already merged changes since the last release:
Would love to hear any comments, concerns, thoughts!
The process would be:
The text was updated successfully, but these errors were encountered: