You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As mentioned in PR #342 , I also thought it was a bug that the blocknative relay was receiving getPayload requests for payloads we did not deliver.
But I came to a different conclusion upon seeing growing sentiment from the various block builders and relays to send blocks to each other. Could this behavior been seen as a redundancy feature?
More specifically: If a block gets sent to all relays, and the relay who serves the winning bid goes down in between serving the header and payload, asking the other relays for that block could add redundancy?
The text was updated successfully, but these errors were encountered:
That was some of the thinking behind the original implementation (as well as simplicity). But both mev-boost as well as the relays would log errors, users were confused, and there were additional concerns about privacy. Also the relay has to guarantee data availability for bids it sent to proposers. Semi-related - there is also work underway of retrying getPayload call.
For context, PR #342 has been included in the v1.3.2 release. Since then mev-boost only sends getPayload to the relays that served the specific bid.
As mentioned in PR #342 , I also thought it was a bug that the blocknative relay was receiving
getPayload
requests for payloads we did not deliver.But I came to a different conclusion upon seeing growing sentiment from the various block builders and relays to send blocks to each other. Could this behavior been seen as a redundancy feature?
More specifically: If a block gets sent to all relays, and the relay who serves the winning bid goes down in between serving the header and payload, asking the other relays for that block could add redundancy?
The text was updated successfully, but these errors were encountered: