Feat: Exit and XCC promises are sequential #868
Merged
Conversation
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
aleksuss
approved these changes
Nov 20, 2023
mrLSD
approved these changes
Nov 20, 2023
aleksuss
pushed a commit
that referenced
this pull request
Nov 28, 2023
## Description This PR is addressing a [usability issue with XCC](aurora-is-near/aurora-contracts-sdk#13 (comment)) 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 `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. ## Performance / NEAR gas cost considerations N/A ## Testing Existing XCC tests
Merged
aleksuss
added a commit
that referenced
this pull request
Nov 28, 2023
## [3.4.0] 2023-11-28 ### Additions - Added a possibility to pass initialize arguments in json format to the `new` transaction by [@aleksuss]. ([#871]) - The `SubmitResult` was made available for `ft_on_transfer` transactions in the standalone engine by [@birchmd]. ([#869]) - The order of producing the exit precompile and XCC promises has been changed to sequential by [@birchmd]. ([#868]) ### Changes - Removed the code hidden behind the feature that isn't used anymore by [@joshuajbouw]. ([#870]) - The logic of unwrapping wNEAR has been changed to the Bridge's native by [@birchmd]. ([#867]) - Bumped the `near-workspaces` to 0.9 by [@aleksuss]. ([#862]) ### Fixes - Add a method for upgrading XCC router contract by [@birchmd]. ([#866]) - Fixed a potential panic in the `ExitToNear` precompile by [@guidovranken]. ([#865]) - Fixed a behaviour when the `ft_transfer` could occur before the `near_withdraw` by [@birchmd]. ([#864]) - Fixed correctness of reproducing the NEAR runtime random value in the standalone engine by [@birchmd]. ([#863]) [#862]: #862 [#863]: #863 [#864]: #864 [#865]: #865 [#866]: #866 [#867]: #867 [#868]: #868 [#869]: #869 [#870]: #870 [#871]: #871 --------- Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Michael Birch <michael.birch@aurora.dev> Co-authored-by: Guido Vranken <guidovranken@users.noreply.github.com> Co-authored-by: Joshua J. Bouw <joshua@aurora.dev>
aleksuss
added a commit
that referenced
this pull request
Nov 28, 2023
## [3.4.0] 2023-11-28 ### Additions - Added a possibility to pass initialize arguments in json format to the `new` transaction by [@aleksuss]. ([#871]) - The `SubmitResult` was made available for `ft_on_transfer` transactions in the standalone engine by [@birchmd]. ([#869]) - The order of producing the exit precompile and XCC promises has been changed to sequential by [@birchmd]. ([#868]) ### Changes - Removed the code hidden behind the feature that isn't used anymore by [@joshuajbouw]. ([#870]) - The logic of unwrapping wNEAR has been changed to the Bridge's native by [@birchmd]. ([#867]) - Bumped the `near-workspaces` to 0.9 by [@aleksuss]. ([#862]) ### Fixes - Add a method for upgrading XCC router contract by [@birchmd]. ([#866]) - Fixed a potential panic in the `ExitToNear` precompile by [@guidovranken]. ([#865]) - Fixed a behaviour when the `ft_transfer` could occur before the `near_withdraw` by [@birchmd]. ([#864]) - Fixed correctness of reproducing the NEAR runtime random value in the standalone engine by [@birchmd]. ([#863]) [#862]: #862 [#863]: #863 [#864]: #864 [#865]: #865 [#866]: #866 [#867]: #867 [#868]: #868 [#869]: #869 [#870]: #870 [#871]: #871 --------- Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Michael Birch <michael.birch@aurora.dev> Co-authored-by: Guido Vranken <guidovranken@users.noreply.github.com> Co-authored-by: Joshua J. Bouw <joshua@aurora.dev>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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