This is a good start. I do however think that we shouldn't trust the rest of response given that just part of it is provably correct. You can imagine attacks where an RPC sends correct base fees, but wildly high priority fees to trick Helios users into sending transactions with a high priority fee. They could then auction that artificially valuable transaction off to a miner using something like flashbots.

We should however be able to implement this method without needing any trust at all. Since Helios has pastExecutionPayloads, we can already get the base fees that we need. We also have the transaction list as a member of each ExecutionPayload, which we can use to decode the priority fees paid out in that block. With that list of priority fees, and a bit of math to figure out percentiles, we should be able to return a response with zero trust in the rpc.

Does this strategy make sense?

Hey guys,

Tried my best but unfortunately computing the reward parameters ourselves has quite some overhead (can push on another branch if needed, just let me know). As can be seen with reth, some client actually don't give an answer for this parameter.

I tried though, and unfortunately amount of request quickly starts going out of hand. Indeed, you need the gas_used parameter per transaction to accumulate it until you reach the gas_used percentile, at which point you can return the gas paid for that specific transaction. Ultimately, what that means is that you need to get the receipt for every transaction in each block queried as there is no other way to get the gas used (practical way at least, not planning to track opcode raised for that endpoint 😬 ) ...

If there was a way to prove that the content was correct without querying it ourselves (wink wink zero-knowledge proof), it would make getting that list possible. Maybe we can follow reth for now and re-assess later on?

Hey @sfyll, merging into a fee_history branch in the a16z/helios repo so we can resolve these formatting and api key issues locally :)