Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Release v2.9.1 #758

Merged
merged 12 commits into from
May 15, 2023
Merged

Release v2.9.1 #758

merged 12 commits into from
May 15, 2023

Conversation

joshuajbouw
Copy link
Contributor

2.9.1 2023-05-11

Changes

Fixes

@joshuajbouw joshuajbouw changed the title Release/joshuajbouw/2.9.1 Release 2.9.1 May 11, 2023
@joshuajbouw
Copy link
Contributor Author

Pending commit drops.

@joshuajbouw joshuajbouw marked this pull request as draft May 11, 2023 13:06
lempire123 and others added 8 commits May 11, 2023 15:11
The engine initialisation function `new() `is not limited in the number
of times it may be called by the owner.

Recommendations:

Only allow `new() `to be called once at deployment.

---------

Co-authored-by: Oleksandr Anyshchenko <[email protected]>
There is an issue in `deploy_upgrade()` that the upgrade index is not
cleared after each call.

Therefore, `deploy_upgrade() `will pass the check `io.block_height() <=
index + state.upgrade_delay_blocks` since
`index` remains unchanged from previous calls.
Several instances of lack of array bounds checks were identified in the
`engine-standalone-storage` and `engine-standalone-tracing` crates.

**Recommendations**

Implement checks to ensure values used when slicing arrays or
referencing items from arrays are within array bound- aries.

Use safer alternatives, such as `.get(n..m)` or `.get_mut(n..m) `when
accessing array elements.
<!--
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 updates near's crates from crates.io rather than our forks. The
dependencies are used in the tests. Also, the PR bumps the version of
the nightly rust compiler.

## Performance / NEAR gas cost considerations

A tiny gas costs regression occurs probably because of updating some
dependency.

## 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 updates the transitive dependency `sha3` to 0.10.8, which fixes
the regression in gas costs (in the tests) regarding this
[fix](RustCrypto/hashes#472).

## Performance / NEAR gas cost considerations

A tiny gas costs improvement.

## 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

This PR replaces the `modexp` implementation with a more efficient one.
This addresses a performance issue that has been raised to us.

## Performance / NEAR gas cost considerations

The PR is all about performance. New benchmarks are added for `modexp`.
We also see the gas cost go down for `repro_Emufid2` because that
transaction uses the `modexp` precompile.

## Testing

New code includes unit tests. We also have the existing `modexp` tests.

## How should this be reviewed

The code here is a little hard to read because it is implementing very
low-level algorithms. Reviewers are welcome to read the papers
referenced in the README to help get the overall idea of what is going
on in the code. The correctness of this code has also been validated by
comparing many cases against the results of other Rust libraries (`ibig`
and `num-bigint`).
When using panicking macros such as `unreachable!()` and `panic!(),` its
best to pass a string detailing the reason for the error. Another
options is to handle error conditions and returned `Err` values by
propagating them with `?` operator and handling them further up the
execution chain.
This PR is a modified version of #726 

Normally I would not make a whole separate PR, but I ended up starting
this work from scratch off of `develop` because I could not understand
why the gas costs in `repro` were increased so much in the old PR. I
have since figured out that it was some change in `Cargo.lock` that was
causing the problem, but by that point I already had all this code
finished in a separate branch so I thought it would be easier to make a
separate PR at that point.

Key differences from #726 :

1. The `repro` tests pass without any changes to the gas values (i.e.
this implementation does not create a significant gas increase). This is
mostly due to leaving `Cargo.lock` untouched, but there are a few other
improvements as well (see below).
2. Automatically migrate the state if the V1 state is found. This change
means that after the first transaction, the fallback deserialization
logic will not be executed and hence reading the state will be as
efficient as it always was (as exemplified by the `repro` gas costs
remaining unchanged).
3. Use `Cow` in `BorshableEngineState` so that `From<&EngineState> for
BorshableEngineState` does not need to clone the owner account id.
4. Ensure removing the `bridge_prover_id` field from `NewCallArgs` is
done in a backwards compatible way. This is not a performance
improvement, but it is still a critical change. We must ensure that
changes to the format of top-level contract functions are always
backwards compatible otherwise the Borealis Engine and Borealis Refiner
will not be able to parse old transactions (it will fail to deserialize
the arguments).
@birchmd birchmd force-pushed the release/joshuajbouw/2.9.1 branch from 2fec77d to 4691a0e Compare May 11, 2023 13:19
@joshuajbouw joshuajbouw changed the title Release 2.9.1 Release v2.9.1 May 11, 2023
birchmd and others added 2 commits May 12, 2023 14:46
## Description

There was a small bug in the new modexp implementation where sometimes
factoring an even modulus into and odd number times a power of two left
a leading zero on the odd number. This threw off some of the other parts
of the algorithm, leading to incorrect results. This PR fixes the issue
and adds test cases for it.
No changes to the contract, but should help CI.
@joshuajbouw joshuajbouw marked this pull request as ready for review May 15, 2023 12:41
@joshuajbouw joshuajbouw requested a review from vimpunk May 15, 2023 12:41
@joshuajbouw joshuajbouw merged commit 733b1a2 into master May 15, 2023
@joshuajbouw joshuajbouw deleted the release/joshuajbouw/2.9.1 branch May 15, 2023 12:53
joshuajbouw added a commit that referenced this pull request Jun 22, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants