Mateusz Morusiewicz
Mateusz Morusiewicz
Great benchmark results! I'd consider checking if the JIT is not optimising away the benchmarked logic, it'd be really good to see the IL generated for the benchmarked contract
Good starting point would be https://github.com/ajsutton/merge-scripts/tree/main/localnet
Also relevant: https://github.com/flashbots/mev-boost/pull/187
I don't think it's quite there yet - it's still convoluted and hard to follow.
We could, but is it really what we should do? Exited validators will never propose blocks, so the best thing would to not have them registered. The [builder spec](https://ethereum.github.io/builder-specs/#/Builder/registerValidator) clearly...
Do we know which version of mev-boost is it?
Related issues: https://github.com/foundry-rs/foundry/issues/5435, https://github.com/foundry-rs/foundry/issues/5410, https://github.com/foundry-rs/foundry/issues/4440, https://github.com/foundry-rs/foundry/issues/3498
@michaelsproul This proposal fits the builder use case perfectly. > CL clients publish augmented payload attributes via the SSE stream, whenever they "discover" new payload attributes As I understand it...
I would also love to see this for builder submissions.
> If we assume that worst case, that this takes 1 second , how would 7 - 11 seconds be for the builder to prepare these transactions ? The problem...