It is somewhat common that XCC requires tokens to be bridged from the user's Aurora address to their XCC account on Near. Naturally, this bridging needs to happen before the XCC promise resolves so that the tokens are available for it to use. However, due to the async nature of Near we could not guarantee that the bridging would happen before the XCC call.
In this PR we change how the Engine produces promises so that they are sequential instead of concurrent (i.e. all the promises produced by the EVM are connected by the then combinator, in the order they were produced during the EVM execution). This means a contract which calls the exit precompile and then later calls XCC will have the promises happen in that same order, as the developer intended.
Description
This PR is addressing a usability issue with XCC brought up by @karim-en .
It is somewhat common that XCC requires tokens to be bridged from the user's Aurora address to their XCC account on Near. Naturally, this bridging needs to happen before the XCC promise resolves so that the tokens are available for it to use. However, due to the async nature of Near we could not guarantee that the bridging would happen before the XCC call.
In this PR we change how the Engine produces promises so that they are sequential instead of concurrent (i.e. all the promises produced by the EVM are connected by the
thencombinator, in the order they were produced during the EVM execution). This means a contract which calls the exit precompile and then later calls XCC will have the promises happen in that same order, as the developer intended.Performance / NEAR gas cost considerations
N/A
Testing
Existing XCC tests