The deneb spec has introduced a new block generation endpoint for validators.
Spec: https://github.com/ethereum/beacon-APIs/pull/339
Previously there were separate endpoints for returning blinded vs unblinded blocks. This new endpoint combines these two endpoints into one single endpoint.
Per Michael Sproul at lighthouse, here is some additional information about what this endpoint needs to do.
There are a bunch of conditions already implemented that determine when to use a builder block vs a local block, including:
Is a builder available?
Is the chain healthy enough to use a builder?
Did both the builder and the local EL return a payload successfully?
Which payload has the higher value?
Is the –always-prefer-builder-payloads flag set?The entry point for this logic is here: https://github.com/sigp/lighthouse/blob/dfcb3363c757671eb19d5f8e519b4b94ac74677a/beacon_node/execution_layer/src/lib.rs#L661-L669
The beacon node must return an unblinded block if it obtains the execution payload from its paired execution node. It must only return a blinded block if it obtains the execution payload header from an MEV relay.
This paragraph of the spec is indirectly calling out part of our current behaviour which we need to stop doing in the new paradigm, which is: if the user has requested a blinded payload on v1/v2, we will give them a blinded version of the locally produced block. This is sub-optimal in the case where the caller might want to "unblind" the block using another node/relay, and they can't! Because the full block is known only to the beacon node that produced it (see https://github.com/sigp/lighthouse/issues/4040 for more info). The v3 API fixes that, by saying we should never return blinded versions of local payloads (fair enough).
The hard part will be updating the get_payload method to use the new way of doing things, where it gets to choose between blinded/unblinded, rather than being told to use one or the other by the caller. It might be hard to make a method that's abstract enough to be used for v1/v2 and v3
If it is too hard, then splitting out as much common logic as possible and having two different get_payload_v1_v2 and get_payload_v3 methods would be acceptable
A majority of my weeks work was focused on this endpoint. My progress can be tracked via this PR: https://github.com/sigp/lighthouse/pull/4594
I've made some big progress on my tracing task for libp2p. The maintainers of the repo have approved my current changes to the ping protocl and now I'm tasked with adding subsequent changes to all the other supported libp2p protocols
As a quick reminder, we are adding tracing to rust-libp2p to enable a richer more contexualized logging experience. This should make it easier for developers to build and debug issues when using the rust-libp2p library
PR: https://github.com/libp2p/rust-libp2p/pull/4282
Lightouse binary size is around 110Mb. Almost half of that is simply genesis.ssz files for the different networks that lighthouse supports.
By using snappy compression we can reduce binary size by roughly 25Mbs! See issue here: https://github.com/sigp/lighthouse/issues/4564
I did some benchmark testing and compressing/uncompressing these genesis files takes roughly 25 milliseconds. Based on these benchmarks the team decided that we could go ahead and compress these genesiss files, and uncompress them at startup without affecting start up times for users
It would make our HTTP API slightly more ergonomic to use via curl if it didn't error when the Content-Type header is omitted.
This seems to be acceptable according to the HTTP spec:
https://stackoverflow.com/questions/15860742/is-content-type-mandatory-in-http-post-request
I think using application/json as the default for most endpoints is OK, as that's usually what one is munging around on the CLI. If the user is sending binary they should be savvy enough to set the header (we could maybe log a warning if the error message doesn't already make it clear enough that Lighthouse attempted to parse JSON data).
The built in warp json filter warp::body::json defaults to Content-Type application/json if a Content-Type isn't provided. If a Content-Type is provided and it is not application/json the request will fail.
I ran several tests on my own, and was unable to recreate a failed endpoint request when Content-Type was omitted. I was however able to recreate a failed endpoint request when Content-Type was included but wasn't application/json.
In out test suite note that builder.json() appends Content-Type application/json to the header by default.
I created a new function post_generic_json_without_content_type_header which creates a post request with serialized json in the body without including Content-Type application/json in the header.
Locally I replaced all post requests in our test suite to NOT include the Content-Type header and all the tests passed. In this PR I only updated a single test to send a POST request without the Content-Type header.
I plan on also spinning up the client locally and making some curl requests myself to make sure I haven't missed anything.
See PR here:
-
Any changes
Be notified of any changes
-
Mention me
Be notified of mention me
-
Unsubscribe
Subscribe