-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feat: ExEx op-proposer #8174
Comments
We are thinking through an approach and our current design for the ExEx to act as the proposer & submit withdrawal proofs every There still exists a risk where reading/writing to the db could fail. Since withdraws depend on proofs being submitted, it might be valuable to have a fallback for edge cases where the historical proof is recomputed in memory by unwinding the db. We could also rely on an fallback endpoint that could fetch the historical proof (geth client for example). Ideally there is a mechanism that can guarantee that historical proofs are able to be fetched in edge cases resulting from transaction failure. Let me know if you have any thoughts on this. |
This issue is stale because it has been open for 21 days with no activity. |
This issue is stale because it has been open for 21 days with no activity. |
This issue was closed because it has been inactive for 7 days since being marked as stale. |
Describe the feature
The
eth_getProof
endpoint currently lacks support for storage proofs at historical blocks. Theop-proposer
must retrieve proofs from historical blocks for theL2ToL1MessagePasser
account in order to submit WithdrawalProofs and facilitate withdrawals from L2 -> L1 for the OP stack.Instead of unwinding the state to the specified block and calculating the storage proof, we can implement the
op-proposer
logic as an ExEx, getting a storage proof everyn
blocks or at some specified interval. The ExEx would then create a transaction that would post the proof to theL2OutputOracle
on L1.We can get started working on this now.
Additional context
No response
The text was updated successfully, but these errors were encountered: