-
Notifications
You must be signed in to change notification settings - Fork 81
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Fix(xcc): Ensure near_withdraw comes after ft_transfer (#864)
## Description The XCC feature was designed to allow users to spend their own wNEAR ERC-20 tokens on Aurora in Near native interaction as if it were the base token. This works by bridging the wNEAR from Aurora out to the user's XCC account, then unwrapping it. The Rainbow bridge team noticed an issue where it is possible for the `wrap.near:withdraw_near` promise to resolve before the `wrap.near:ft_transfer` promise. This causes the XCC flow to fail if the user's XCC account does not carry a wNEAR balance because we attempt to withdraw tokens we don't yet have. This PR aims to solve that issue. To see why this fix works, we need to know why the issue happens in the first place. The problem is the XCC flow used to use the `call` entry point to trigger the exit to Near function on the wNEAR ERC-20 token. That function invokes the exit to Near precompile which creates a promise to transfer the corresponding NEP-141 token from `aurora` to the destination account. However, that promise is not returned from `call` because instead it must return the EVM `SubmitResult` (the normal use-case for `call` is simply to invoke the EVM). By not returning the `ft_transfer` promise, it is disconnected from the subsequent execution graph and therefore Near does not make any guarantees about when it will resolve relative to other promises the execution will create. Under normal (non-congested) conditions, the `ft_transfer` does resolve first because there is one block before the `wrap.near:withdraw_near` call is created (since after `aurora:call` comes `xcc_router:unwrap_and_refund_storage` which then makes the withdraw call). However, if the shard containing `wrap.near` is congested then the `ft_transfer` call can delayed by one block and then need to execute in the same block as `near_withdraw`, resulting in a 50% chance of failure. Therefore, to fix the issue we must make sure the promise from the exit precompile is given as the return value of the call in the XCC flow to make sure it stays connected with the rest of the execution graph. Doing this will ensure `wrap.near:ft_transfer` resolves before `xcc_router:unwrap_and_refund_storage` is allowed to execute. To that end, in this PR I introduce a new private function called `withdraw_wnear_to_router`. The only purpose of this function is to make the call to the exit precompile while capturing its promise and then return that promise. With that context, this change should be pretty easy to follow. The new function is defined in `contract_methods::xcc`, and that logic is applied in both `lib.rs` and the standalone engine. ## Performance / NEAR gas cost considerations All costs should remain unchanged. The same work is done, just in a different method to allow the promise return. ## Testing The bug described above only occurs under congested conditions, so I do not know how to write a good test for it in near-workspaces. I am relying on the existing XCC tests to at least be sure this change does not break the feature.
- Loading branch information
Showing
8 changed files
with
234 additions
and
28 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.