feat: unlimited pending sign txs whitelist#31
Conversation
| #[cfg_attr(not(target_arch = "wasm32"), derive(Debug))] | ||
| pub struct Account { | ||
| pub account_id: AccountId, | ||
| pub btc_pending_sign_ids: HashSet<String>, |
There was a problem hiding this comment.
What is the max allowed size of the btc_pending_sign_ids? I think we still have some limits due to the gas limitation.
There was a problem hiding this comment.
I think the design will be more flexible if we put this value into the multi_txs_white_list map.
There was a problem hiding this comment.
By doing this we can remove the max_pending_sign_txs from the config.
|
|
||
| pub fn internal_get_account(&self, account_id: &AccountId) -> Option<&Account> { | ||
| self.data().accounts.get(account_id).map(Into::into) | ||
| pub fn internal_get_account(&self, account_id: &AccountId) -> Option<Account> { |
There was a problem hiding this comment.
I just decided to implement a lazy account migration. If we request mut, we upgrade the account to the new version. If it’s view, we convert it locally. Because of this approach, we can’t return a reference, since a conversion happens.
As an alternative, we could implement a separate migration function and migrate accounts in batches. But I kind of like the lazy approach more.
3 participants
OmniBridge acts as the sender for all withdraw transactions. Previously, an account could only have one pending-sign transaction at a time — it had to wait for MPC signing to complete before creating another. This became a bottleneck for
OmniBridge, which needs to submit new withdrawals in parallel while existing ones are still being signed.