Release 3.4.0 #874
Merged
Release 3.4.0 #874
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
## Description The PR updates the `near-workspaces-rs` dependency.
…tracts (#861) Bumps [browserify-sign](https://github.com/crypto-browserify/browserify-sign) from 4.2.1 to 4.2.2. <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/browserify/browserify-sign/blob/main/CHANGELOG.md">browserify-sign's changelog</a>.</em></p> <blockquote> <h2><a href="https://github.com/browserify/browserify-sign/compare/v4.2.1...v4.2.2">v4.2.2</a> - 2023-10-25</h2> <h3>Fixed</h3> <ul> <li>[Tests] log when openssl doesn't support cipher <a href="https://redirect.github.com/browserify/browserify-sign/issues/37"><code>[#37](https://github.com/crypto-browserify/browserify-sign/issues/37)</code></a></li> </ul> <h3>Commits</h3> <ul> <li>Only apps should have lockfiles <a href="https://github.com/browserify/browserify-sign/commit/09a89959393b3c89fedd4f7f3bafa4fec44371d7"><code>09a8995</code></a></li> <li>[eslint] switch to eslint <a href="https://github.com/browserify/browserify-sign/commit/83fe46374b819e959d56d2c0b931308f7451a664"><code>83fe463</code></a></li> <li>[meta] add <code>npmignore</code> and <code>auto-changelog</code> <a href="https://github.com/browserify/browserify-sign/commit/44181838e7dcc4d5d0c568f74312ea28f0bcdfd5"><code>4418183</code></a></li> <li>[meta] fix package.json indentation <a href="https://github.com/browserify/browserify-sign/commit/9ac5a5eaaac8a11eb70ec2febd13745c8764ae02"><code>9ac5a5e</code></a></li> <li>[Tests] migrate from travis to github actions <a href="https://github.com/browserify/browserify-sign/commit/d845d855def38e2085d5a21e447a48300f99fa60"><code>d845d85</code></a></li> <li>[Fix] <code>sign</code>: throw on unsupported padding scheme <a href="https://github.com/browserify/browserify-sign/commit/8767739a4516289568bcce9fed8a3b7e23478de9"><code>8767739</code></a></li> <li>[Fix] properly check the upper bound for DSA signatures <a href="https://github.com/browserify/browserify-sign/commit/85994cd6348b50f2fd1b73c54e20881416f44a30"><code>85994cd</code></a></li> <li>[Tests] handle openSSL not supporting a scheme <a href="https://github.com/browserify/browserify-sign/commit/f5f17c27f9824de40b5ce8ebd8502111203fd6af"><code>f5f17c2</code></a></li> <li>[Deps] update <code>bn.js</code>, <code>browserify-rsa</code>, <code>elliptic</code>, <code>parse-asn1</code>, <code>readable-stream</code>, <code>safe-buffer</code> <a href="https://github.com/browserify/browserify-sign/commit/a67d0eb4ffceabb366b69da69ce9a223e9d5e96b"><code>a67d0eb</code></a></li> <li>[Dev Deps] update <code>nyc</code>, <code>standard</code>, <code>tape</code> <a href="https://github.com/browserify/browserify-sign/commit/cc5350b96702fcba930e0662cf763844fd2f59bf"><code>cc5350b</code></a></li> <li>[Tests] always run coverage; downgrade <code>nyc</code> <a href="https://github.com/browserify/browserify-sign/commit/75ce1d5c49a6591dd13422016c07f8f9cae13371"><code>75ce1d5</code></a></li> <li>[meta] add <code>safe-publish-latest</code> <a href="https://github.com/browserify/browserify-sign/commit/dcf49ce85a1a66a6fb31689508d916d7894286a9"><code>dcf49ce</code></a></li> <li>[Tests] add <code>npm run posttest</code> <a href="https://github.com/browserify/browserify-sign/commit/75dd8fd6ce56eb37b12e30807e5f913867b21733"><code>75dd8fd</code></a></li> <li>[Dev Deps] update <code>tape</code> <a href="https://github.com/browserify/browserify-sign/commit/3aec0386dc8dfba8698be756ec770df863867c84"><code>3aec038</code></a></li> <li>[Tests] skip unsupported schemes <a href="https://github.com/browserify/browserify-sign/commit/703c83ea72db2f45714fe749c6f04b05243ca9a8"><code>703c83e</code></a></li> <li>[Tests] node < 6 lacks array <code>includes</code> <a href="https://github.com/browserify/browserify-sign/commit/3aa43cfbc1fdde8481bcdd3bff581574159b869a"><code>3aa43cf</code></a></li> <li>[Dev Deps] fix eslint range <a href="https://github.com/browserify/browserify-sign/commit/98d4e0d7ff18871b0ca07415f758a610ccf8ebbe"><code>98d4e0d</code></a></li> </ul> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/browserify/browserify-sign/commit/4af5a90bf8acd9e76e5671dc0497f6ba71968a2c"><code>4af5a90</code></a> v4.2.2</li> <li><a href="https://github.com/browserify/browserify-sign/commit/3aec0386dc8dfba8698be756ec770df863867c84"><code>3aec038</code></a> [Dev Deps] update <code>tape</code></li> <li><a href="https://github.com/browserify/browserify-sign/commit/85994cd6348b50f2fd1b73c54e20881416f44a30"><code>85994cd</code></a> [Fix] properly check the upper bound for DSA signatures</li> <li><a href="https://github.com/browserify/browserify-sign/commit/9ac5a5eaaac8a11eb70ec2febd13745c8764ae02"><code>9ac5a5e</code></a> [meta] fix package.json indentation</li> <li><a href="https://github.com/browserify/browserify-sign/commit/dcf49ce85a1a66a6fb31689508d916d7894286a9"><code>dcf49ce</code></a> [meta] add <code>safe-publish-latest</code></li> <li><a href="https://github.com/browserify/browserify-sign/commit/44181838e7dcc4d5d0c568f74312ea28f0bcdfd5"><code>4418183</code></a> [meta] add <code>npmignore</code> and <code>auto-changelog</code></li> <li><a href="https://github.com/browserify/browserify-sign/commit/8767739a4516289568bcce9fed8a3b7e23478de9"><code>8767739</code></a> [Fix] <code>sign</code>: throw on unsupported padding scheme</li> <li><a href="https://github.com/browserify/browserify-sign/commit/5f6fb1755917851a40249db7d834da4265ed5950"><code>5f6fb17</code></a> [Tests] log when openssl doesn't support cipher</li> <li><a href="https://github.com/browserify/browserify-sign/commit/f5f17c27f9824de40b5ce8ebd8502111203fd6af"><code>f5f17c2</code></a> [Tests] handle openSSL not supporting a scheme</li> <li><a href="https://github.com/browserify/browserify-sign/commit/d845d855def38e2085d5a21e447a48300f99fa60"><code>d845d85</code></a> [Tests] migrate from travis to github actions</li> <li>Additional commits viewable in <a href="https://github.com/crypto-browserify/browserify-sign/compare/v4.2.1...v4.2.2">compare view</a></li> </ul> </details> <details> <summary>Maintainer changes</summary> <p>This version was pushed to npm by <a href="https://www.npmjs.com/~ljharb">ljharb</a>, a new releaser for browserify-sign since your current version.</p> </details> <br /> [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- <details> <summary>Dependabot commands and options</summary> <br /> You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot show <dependency name> ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) You can disable automated security fix PRs for this repo from the [Security Alerts page](https://github.com/aurora-is-near/aurora-engine/network/alerts). </details> Signed-off-by: dependabot[bot] <[email protected]> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
## Description The Near runtime has a random value available to smart contracts via a cost function. Aurora exposes that random value to EVM smart contracts in two ways: (1) via a custom precompile, and (2) via [EVM opcode 0x44](https://www.evm.codes/#44?fork=shanghai) since it was changed from `DIFFICULTY` to `PREVRANDAO` after the merge. Therefore it is important for the standalone engine to be able to correctly provide the same random value as would be present on-chain. In this PR I fix the standalone engine to be able to correctly reproduce the Near runtime random value based on the implementation present in nearcore. There will also be a follow-up PR to `borealis-engine-lib` to make use of this change in the Borealis Engine there. The random value is computed as `sha256(block_random_value || action_hash)` where the `block_random_value` comes from the protocol-level VRF (this was the value which previously we were using directly) and the `action_hash` is derived from the (`FunctionCall`) `Action` that is being executed in the Near runtime. To have the `action_hash` available to the standalone engine I am adding a new field to `TransactionMessage` which stores this value. In the tests the `action_hash` field is populated in a reasonable way, but not exactly as it would be in nearcore because there is no actual `Action` (we skip straight to the Wasm execution). However, in the follow-up PR in `borealis-engine-lib` the field will be populated from the Near data. Once this change is made, it will fix a bug in Borealis Engine where it was not correctly reproducing the execution of contracts involving randomness. ## Performance / NEAR gas cost considerations N/A : change is to standalone engine only. ## Testing The test for the random precompile has been updated to reflect this change. A test related to tracing is also changed to no longer depend on the randomness precompile because the test did not rely on the specifics of which precompile was used and now using randomness in the tests has extra setup steps.
## 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.
## Description If `input` is empty a panic occurs. This PR sets `flag` to the default value in that case. ## Performance / NEAR gas cost considerations ## Testing Fuzzing. ## How should this be reviewed Ensure that `flag` assuming the default value if `input` is empty is the intended behavior. ## Additional information
## Description The initial XCC implementation was meant to allow the contracts deployed to the sub-accounts created by the Engine as part of the XCC flow to be upgradable. However, that upgrade code did not work as intended. The problem is that Near enforces [only an account itself](https://github.com/near/nearcore/blob/83fe943e4e270db87a89535037d2b3a8909a2c6d/runtime/runtime/src/actions.rs#L852) can use the `DeployContract` action after the account has been created (if the account is being created during that receipt then `DeployContract` is allowed to be part of the batch). But the initial implementation attempted to push the `DeployContract` action directly, causing an `ActorNoPermission` error. The correct way to implement an upgrade mechanism is to have the deployed contract contain a method which accepts new code then creates a receipt to itself with the `DeployContract` action. This PR changes the XCC Router contract to include such a method. Unfortunately since V1 XCC Routers did not have any upgrade method, and they have no access keys associated with them, they can never be upgraded. After releasing the V2 Router contract with upgradability we may encourage existing XCC users (for example the fast bridge) to migrate to a new XCC account. ## Performance / NEAR gas cost considerations N/A ## Testing A new integration test for upgrading XCC contracts is included in this PR.
## Description Since #750 has been merged, the ERC-20 connector is able to unwrap wrapped Near tokens into Near native tokens. This logic was duplicated by the XCC router, but in this PR we remove the logic from XCC and use the bridge's unwrapping instead. This has a nice side-effect of saving us 20 Tgas from the XCC overhead. ## Performance / NEAR gas cost considerations No impact on regular transactions, 20 Tgas improvement to XCC transactions. ## Testing Existing tests. Specifically this relies heavily on the upgrade test introduced in #866
## 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
…869) ## Description Explorers like Blockscout rely on EVM logs to index certain events such as ERC-20 token transfers/minting/burning. When NEP-141 tokens are bridged to Aurora via `ft_on_transfer` there are ERC-20 token events that should be produced and indexed by explorers. This PR changes how `ft_on_transfer` calls are handled to expose the EVM logs generated to the standalone engine, which in turn will make them available to the Refiner and thus also to block explorers. There will be a follow-up PR in `borealis-engine-lib` which uses the `SubmitResult` to include logs in the transactions corresponding to `ft_on_transfer`. ## Performance / NEAR gas cost considerations N/A no significant changes to contract code ## Testing Existing tests. (A new test will be added to `borealis-engine-lib` when we do integration there)
## Description Remove the unused bully feature which didn't see fruition.
## Description The PR adds a new option to pass init arguments in JSON format. ## Performance / NEAR gas cost considerations There are no changes in performance or gas cost. ## Testing A corresponding unit test has been added. ## Additional information The controller contract needs the change to allow passing generic JSON object as initialise arguments.
mrLSD
approved these changes
Nov 28, 2023
birchmd
approved these changes
Nov 28, 2023
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] <[email protected]> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Michael Birch <[email protected]> Co-authored-by: Guido Vranken <[email protected]> Co-authored-by: Joshua J. Bouw <[email protected]>
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.
[3.4.0] 2023-11-28
Additions
newtransaction by [@aleksuss]. (#871)SubmitResultwas made available forft_on_transfertransactions in the standalone engine by [@birchmd]. (#869)Changes
near-workspacesto 0.9 by [@aleksuss]. (#862)Fixes
ExitToNearprecompile by [@guidovranken]. (#865)ft_transfercould occur before thenear_withdrawby [@birchmd]. (#864)