Release v2.9.2 #786
Merged
Release v2.9.2 #786
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
joshuajbouw
requested review from
aleksuss,
RomanHodulak and
vimpunk
as code owners
aleksuss
approved these changes
Jun 22, 2023
## Description The AccountId validation is missing on parsing a JSON input, and this leads to the possibility of calling `ft_transfer()` with an invalid `receiver_id`. here is an [example](https://explorer.near.org/transactions/HKLVudra9nYdtuFBncFipSveZ5d6D1TbHGfAnM4S2rWg) that we received. This pull request removes the default implementation of the `serde::Deserialize` and implements a custom one.
…or all crates (#767) ## Description [Near Workspaces](https://crates.io/crates/workspaces) still uses `borsh` version 0.9. Therefore we need the `borsh-compat` feature on all our crates that use `borsh` if we want to use them in Workspaces-based tests. This PR makes this change. This is a non-functional change (impacts only a dependency version and only if a feature is specified), therefore has no impact on tests or performance.
Adds Shanghai hardfork support by integrating updated aurora-sputnikvm. N/A Testing has been added to sputnikvm's test suite. All engine tests are passing. The majority of changes are in sputnikvm which have already been reviewed. N/A --------- Co-authored-by: Oleksandr Anyshchenko <[email protected]>
## Description The PR improves some comment docs in the eth-connector module and applies tiny refactoring. ## Performance / NEAR gas cost considerations No changes. ## Testing <!-- Please describe the tests that you ran to verify your changes. --> ## How should this be reviewed <!-- Include any recommendations of areas to be careful of to ensure that the reviewers use extra attention. --> ## Additional information <!-- Include any additional information which you think should be in this PR, such as prior arts, future extensions, unresolved problems, or a TODO list which should be followed up. -->
<!-- Thanks for submitting a pull request! Here are some helpful tips: * Always create branches on and target the `develop` branch. * Run all the tests locally and ensure that they are passing. * Run `make format` to ensure that the code is formatted. * Run `make check` to ensure that all checks passed successfully. * Small commits and contributions that attempt one single goal is preferable. * If the idea changes or adds anything functional which will affect users, an AIP discussion is required first on the Aurora forum: https://forum.aurora.dev/discussions/AIPs%20(Aurora%20Improvement%20Proposals). * Avoid breaking the public API (namely in engine/src/lib.rs) unless required. * If your PR is a WIP, ensure that you enable "draft" mode. * Your first PRs won't use the CI automatically unless a maintainer starts. If this is not your first PR, please do NOT abuse the CI resources. Checklist: - [ ] I have performed a self-review of my code - [ ] I have documented my code, particularly in the hard-to-understand areas - [ ] I have made corresponding changes to the documentation - [ ] I have added tests to prove my fix or new feature is effective and works - [ ] Any dependent changes have been merged - [ ] The PR is targeting the `develop` branch and not `master` - [ ] I have pre-squashed my commits into a single commit and rebased. --> ## Description The PR is alternative version of #769. ## Performance / NEAR gas cost considerations <!-- Performance regressions are not ideal, though we welcome performance improvements. Any PR must be completely mindful of any gas cost increases. The CI will fail if the gas costs change at all. Do update these tests to accommodate for the new gas changes. It is good to explain this change, if necessary. --> ## Testing <!-- Please describe the tests that you ran to verify your changes. --> ## How should this be reviewed <!-- Include any recommendations of areas to be careful of to ensure that the reviewers use extra attention. --> ## Additional information <!-- Include any additional information which you think should be in this PR, such as prior arts, future extensions, unresolved problems, or a TODO list which should be followed up. -->
## Description hskang9 is no longer part of the company, so removing him as one of the listed code owners. For now, I'll take ownership over tests libraries and in the future, may pass on ownership to another.
## Description We need to specially handle the case where the exponent is zero because the main code does not do this correctly. Note: EVM treats 0^0 as equal to 1. ## Testing New test for this case.
<!-- Thanks for submitting a pull request! Here are some helpful tips: * Always create branches on and target the `develop` branch. * Run all the tests locally and ensure that they are passing. * Run `make format` to ensure that the code is formatted. * Run `make check` to ensure that all checks passed successfully. * Small commits and contributions that attempt one single goal is preferable. * If the idea changes or adds anything functional which will affect users, an AIP discussion is required first on the Aurora forum: https://forum.aurora.dev/discussions/AIPs%20(Aurora%20Improvement%20Proposals). * Avoid breaking the public API (namely in engine/src/lib.rs) unless required. * If your PR is a WIP, ensure that you enable "draft" mode. * Your first PRs won't use the CI automatically unless a maintainer starts. If this is not your first PR, please do NOT abuse the CI resources. Checklist: - [ ] I have performed a self-review of my code - [ ] I have documented my code, particularly in the hard-to-understand areas - [ ] I have made corresponding changes to the documentation - [ ] I have added tests to prove my fix or new feature is effective and works - [ ] Any dependent changes have been merged - [ ] The PR is targeting the `develop` branch and not `master` - [ ] I have pre-squashed my commits into a single commit and rebased. --> ## Description The goal of the PR is to allow to use input parameters of the engine without importing the `aurora-engine` itself. ## Performance / NEAR gas cost considerations There are no changes because it's refactoring only. ## Testing Some tests were moved only. ## How should this be reviewed Pay attention that parameters correctly have been placed in corresponding modules. ## Additional information <!-- Include any additional information which you think should be in this PR, such as prior arts, future extensions, unresolved problems, or a TODO list which should be followed up. -->
## Description The goal of the PR is to speed up passing CI flow. Also, it adds an additional job for testing the `bech_modexp` flow.
<!-- Thanks for submitting a pull request! Here are some helpful tips: * Always create branches on and target the `develop` branch. * Run all the tests locally and ensure that they are passing. * Run `make format` to ensure that the code is formatted. * Run `make check` to ensure that all checks passed successfully. * Small commits and contributions that attempt one single goal is preferable. * If the idea changes or adds anything functional which will affect users, an AIP discussion is required first on the Aurora forum: https://forum.aurora.dev/discussions/AIPs%20(Aurora%20Improvement%20Proposals). * Avoid breaking the public API (namely in engine/src/lib.rs) unless required. * If your PR is a WIP, ensure that you enable "draft" mode. * Your first PRs won't use the CI automatically unless a maintainer starts. If this is not your first PR, please do NOT abuse the CI resources. Checklist: - [ ] I have performed a self-review of my code - [ ] I have documented my code, particularly in the hard-to-understand areas - [ ] I have made corresponding changes to the documentation - [ ] I have added tests to prove my fix or new feature is effective and works - [ ] Any dependent changes have been merged - [ ] The PR is targeting the `develop` branch and not `master` - [ ] I have pre-squashed my commits into a single commit and rebased. --> ## Description <!-- Provide a general summary of your changes. A clear overview along with an in-depth explanation is beneficial. If this PR closes any issues, be sure to add "closes #<number>" somewhere. --> ## Performance / NEAR gas cost considerations <!-- Performance regressions are not ideal, though we welcome performance improvements. Any PR must be completely mindful of any gas cost increases. The CI will fail if the gas costs change at all. Do update these tests to accommodate for the new gas changes. It is good to explain this change, if necessary. --> ## Testing <!-- Please describe the tests that you ran to verify your changes. --> ## How should this be reviewed <!-- Include any recommendations of areas to be careful of to ensure that the reviewers use extra attention. --> ## Additional information <!-- Include any additional information which you think should be in this PR, such as prior arts, future extensions, unresolved problems, or a TODO list which should be followed up. -->
## Description Switch to using the `ibig` implementation for modexp. Its performance is better than current Aurora implementation in some (but not all) cases, and it is more battle-tested in terms of correctness.
## Description Release notes for 2.9.2. I am doing this first to develop intentionally, to prevent back porting later.
birchmd
force-pushed
the
release/joshuajbouw/2.9.2
branch
from
1d16bce
to
30926b1
Compare
mrLSD
approved these changes
Jun 22, 2023
aleksuss
approved these changes
Jun 22, 2023
## Description Adding links was missed in the changelog for 2.9.2 release, adding in those now.
vimpunk
approved these changes
Jun 23, 2023
mrLSD
approved these changes
Nov 27, 2023
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.
2.9.2 2023-06-22
Fixes