-
Notifications
You must be signed in to change notification settings - Fork 54
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
fix(finalizer): Handle 1:many withdrawal:calldata #953
Conversation
The previous change to the finalizer incorrectly assumed that there would be a 1:1 relationship between a txn and a withdrawal or proof. This is incorrect on Polygon, where 2 txns are needed to finalize a single withdrawal. This change seems like a manageable way of establishing a 1:many relationship between withdrawal/proof logging and the necessary transaction(s), without imposing any changes on the underlying chain adapters. Ultimately it would be nice to backport this into the adapters themselves, but that's invasive and it's not worth prioritising now.
nb. I am testing this locally and will attempt to front-run the production finalizer so I can capture the withdrawals and verify this works as I hope. |
src/finalizer/index.ts
Outdated
finalizationsToBatch.push(...txns); | ||
// Append calldata. If multiple calls are needed per withdrawal (i.e. Polygon), | ||
// require that the 2nd batch is appended to the first. | ||
txns.forEach((txn, i) => withdrawals[i % withdrawals.length].calldata.push(txn)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what if a future network uses more than 2 calls?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As long as they are returned as batches that are multiples of withdrawals
, i.e. batch 1, batch 2, batch 3, in the same order, then it should be OK.
ATM it seems unlikely that we'd require more than 2 transactions for a single withdrawal, and the fact that we currently need 2 seems to be exclusively a quirk of Polygon. Ultimately I'd like to go back into each of the adapters so that they enforce the 1:many relationship between withdrawal and multicall transactions, but I don't think that's a priority at the moment.
FWIW, I've been front-running the production finalizer successfully for the past ~24 hours, and it's working as expected.
Multiple layers of naming make this a bit messy.
I've run this continuously over the weekend. Aside from a small redis issue (unrelated to this change), the change has worked 100% as intended). Will submit as soon as CI passes. |
The previous change to the finalizer incorrectly assumed that there would be a 1:1 relationship between a txn and a withdrawal or proof. This is incorrect on Polygon, where 2 txns are needed to finalize a single withdrawal.
This change seems like a manageable way of establishing a 1:many relationship between withdrawal/proof logging and the necessary transaction(s), without imposing any changes on the underlying chain adapters. Ultimately it would be nice to backport this into the adapters themselves, but that's invasive and it's not worth prioritising now.