You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
0 commit comments