reth
reth copied to clipboard
paradigmxyz
Support old receipt type (state root before byzantium)
This is more a discussion and dont forget it task.
Receipt before Byzantium contained state root and didn't have status, how exactly do we want to support that? calculating state root is expensive and it is best done while execution is on the way, we could just ignore it and put empty/zero value or maybe somehow hardcode it?
Part of code that checks receipt root (without stateroot within receipt this is skipped before byzantium): https://github.com/paradigmxyz/reth/blob/e6ca4c56c6a314e5553656e5b62be3bca6801b85/crates/executor/src/executor.rs#L261-L268
Geth checks the root of every block, one of the reasons why geth archive is not usable, for Erigon idk.
@carver just saw your note on Reddit (thx for the comment, big fan from the early web3 python days...), should we remove that reference to Trin from the blog? apologies if it felt inaccurate.
What should we do here to better support Trin / what are you missing?
This issue is stale because it has been open for 21 days with no activity.
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
This issue was closed because it has been inactive for 7 days since being marked as stale.
Any update on this issue / estimated timeline until Reth might be able to support pre-byzantium receipts?
Any update on this issue / estimated timeline until Reth might be able to support pre-byzantium receipts?
Do you need this for an application? Would be good to know what the requirements are exactly
The use case would be to re-calculate valid receipt roots for pre-byzantium blocks, which requires the state_root field. However, in Trin / the Portal Network, we're moving towards using era1 files for pre-byzantium blocks, rather than requesting the data from a client, so this is no longer needed from our side
Hi. We would like this feature too. I think I could be able to implement it after looking how Geth handles it. Just to be sure, this step from geth is related, right?
Hi. We would like this feature too. I think I could be able to implement it after looking how Geth handles it. Just to be sure, this step from geth is related, right?
yes, although fair warning, it's definitely a nontrivial change, and I'm still not convinced we should support this. What's the use case for pre byzantium receipts?
yes, although fair warning, it's definitely a nontrivial change, and I'm still not convinced we should support this. What's the use case for pre byzantium receipts?
In our flat files decoder here we need to have encoding that supports pre-byzantinum transactions. We did some workaround in order for it to work, however, it would be nice if Reth handled it.
Thinking about it now, just handling this functionality in enconde_inner in Reth should be enough, right?
yes, although fair warning, it's definitely a nontrivial change, and I'm still not convinced we should support this. What's the use case for pre byzantium receipts?
In our flat files decoder here we need to have encoding that supports pre-byzantinum transactions. We did some workaround in order for it to work, however, it would be nice if Reth handled it.
Thinking about it now, just handling this functionality in
enconde_innerin Reth should be enough, right?
Yeah, I would even be open to supporting a separate pre-byzantium receipt type (which would derive rlp encodable / decodable) if necessary
Yeah, I would even be open to supporting a separate pre-byzantium receipt type (which would derive rlp encodable / decodable) if necessary
Neat. I will work on it. Any recommendations for this task besides the contribution guidelines?