NEP-508: Resharding v2 #508
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
Create NEP template for resharding
|
Your Render PR Server URL is https://nomicon-pr-508.onrender.com. Follow its progress at https://dashboard.render.com/static/srv-ck4uivei9prc73dshdpg. |
Updating draft
Update Status and DiscussionsTo
Additional changes
wacban
reviewed
Sep 20, 2023
Updating based on @wacban 's feedback
wacban
approved these changes
Sep 22, 2023
fix lint errors
walnut-the-cat
commented
Oct 31, 2023
frol
added
WG-protocol
|
Hi @walnut-the-cat – thank you for starting this proposal. As the moderator, I labeled this PR as "Needs author revision" because we assume you are still working on it since you left "wip" in the description. Please ping the @near/nep-moderators once you are ready for us to review it. We will review it again in early January, unless we hear from you sooner. We typically close NEPs that are inactive for more than two months, so please let us know if you need more time. |
2 tasks
github-merge-queue bot
pushed a commit
to near/nearcore
that referenced
this pull request
Dec 6, 2023
# Feature to stabilize This PR stabilizes the Resharding V2 protocol feature. It introduces a new implementation for resharding and a new shard layout for the production networks - mainnet and testnet. The resharding process from the current shard layout to the new shard layout will be triggered automatically an epoch before the switch to the new protocol version. # Context - near/NEPs#508 - #8992 # Testing and QA This feature was extensively tested in unit tests, integration tests, nayduck tests, mocknet, testnet and mainnet. # Checklist - [ ] nayduck - https://nayduck.near.org/#/run/3308 - [x] Update CHANGELOG.md to include this protocol feature in the `Unreleased` section.
mfornet
reviewed
Dec 6, 2023
mfornet
reviewed
Dec 6, 2023
mfornet
reviewed
Dec 6, 2023
Co-authored-by: Marcelo Fornet <[email protected]>
|
The NEP is scheduled for Protocol working group review at 4:30 PM UTC, Friday, December 15 |
|
|
||
| ### Flat Storage | ||
|
|
||
| The old implementation of resharding relied on iterating over the full trie state of the parent shard in order to build the state for the children shards. This implementation was suitable at the time but since then the state has grown considerably and this implementation is now too slow to fit within a single epoch. The new implementation relies on iterating through the flat storage in order to build the children shards quicker. Based on benchmarks, splitting the largest shard by using flat storage can take around 15 min without throttling and around 3 hours with throttling to maintain the block production rate. |
There was a problem hiding this comment.
Unrelated to this proposal, but do I understand correctly that once we have in-memory trie, the old approach would actually work again?
There was a problem hiding this comment.
Hmm good question. One requirement that we have for storage is to give us access to a frozen view of the chain at a pre-defined block. This is why we need the flat store snapshots. I'm not sure if such snapshottting would be feasible with mem-trie. It's definitely worth exploring as a number of fundamental assumptions will change.
There was a problem hiding this comment.
Although theoretically it does seem plausible given we have a large enough GC period for mem-trie and we maintain "historic" state for the GC period.
There was a problem hiding this comment.
One requirement that we have for storage is to give us access to a frozen view of the chain at a pre-defined block. This is why we need the flat store snapshots. I'm not sure if such snapshottting would be feasible with mem-trie
My understanding is that in-memory trie just moves trie to be held in memory and does not change its persistence assumptions, so yes you can read the state at some predefined block (assuming it has not been garbage collected).
There was a problem hiding this comment.
In-memory trie loads from flat storage and indeed does not change any persistence assumptions. If there is flat storage available at some block (such as via a flat state snapshot) then memtries can be loaded that corresponds to that flat state. It's possible to then iterate through the memtrie to reconstruct a resharded on-disk trie or flat state. That being said, this does not sound so much like "the old approach works again", but rather that memtries can be used as an optimization to the (pretty isolated) step of reconstructing a trie from flat state -- which is the solution we're adopting in this proposal. We would be doing the same thing, except that memtrie construction from flat state is a bit more efficient than direct trie reconstruction of flat state (for reasons of doing less wasted work and doing less disk I/O).
The pros would be that this is more efficient (perhaps 2x-4x more would be my ballpark guess), the cons is that this requires more memory and, well, we don't have the code for dumping memtrie into on-disk trie. It sounds easy, but they are different data structures and in practice we have to carefully deal with refcount keeping which will not be trivial.
|
|
||
| ### Garbage collection | ||
|
|
||
| In epoch T+2 once resharding is completed, we can delete the trie state and the flat state related to the parent shard. In practice, this is handled as part of the garbage collection code. While garbage collecting the last block of epoch T+1, we go ahead and clear all the data associated with the parent shard from the trie cache, flat storage, and RocksDB state associated with trie state and flat storage. |
There was a problem hiding this comment.
Does this mean that the storage increase would last for 5 epochs (or however long the garbage collection period is configured to be)
There was a problem hiding this comment.
Yes, that's correct, we maintain the state of the parent shard for the period of GC. Note that right after resharding, we keep deleting state from the State (Trie data) column of the parent shard with GC normally while new state is being added to the State column of the child shards upto the GC period. This means the storage increase compared to a non-resharding case would amortized be the size of the current state as of the time of resharding and not all the historic data.
added storage overhead numbers
|
As the moderator (on behalf of @ori-near), I would like to thank @walnut-the-cat, @robin-near, and @Longarithm for completing the technical review. Based on your comments above, it seems like this proposal is ready for the working group members for review. Also, what is Marcin's GH handle? I can't find it 😄 |
|
As a working group member, I lean towards approving this proposal. A robust mechanism for increasing the number of shards is important to continue scaling Near protocol and this proposal delivers such a mechanism. One important caveat is the comment above about how this proposal may interact with the bridge. I think it is important for the bridge team to coordinate with the engineers implementing this proposal to ensure a smooth integration with the bridge. |
|
As a working group member, I lean towards approving this proposal. Splitting shard 3 into 2 shards both tests the current resharding approach and also alleviates the pressure on the state size of shard 3. |
|
As the moderator, I would like to thank @walnut-the-cat for submitting this Protocol NEP, and for the @near/wg-protocol work group members for your review. Based on the voting indications above, it seems like this proposal is close to a decision. We are therefore scheduling the sixth Protocol Work group call this week, where this NEP can enter the final voting stage. Anyone can discuss the technical details by adding your comments to this discussion. And join the call to learn about the final decision and how to get more involved. Meeting Info |
ori-near
added
S-voting/final-comment-period
|
As a working group member, I lean towards approving this proposal. |
|
As an SME, I lean towards approving this proposal. Sharding is crucial for the scalability of the chain, and splitting shard 3 is a great stepping stone towards a robust solution for horizontal scalability. Although the resharding problem is inherently very complex and there's an inherent risk of making such a complex change, the team implementing the proposal has thoroughly discussed various high-level solutions, and they have a concrete plan for each foreseeable corner case. They also have a comprehensive testing plan including unit tests, integration tests, and mocknet tests; the latter two being more comprehensive than what we did during the 1 -> 4 resharding. Furthermore, although resharding has interactions with other efforts such as state sync and stateless validation, I see no red flags that would suggest that this NEP might block these other systems from making progress in the future. Therefore I think this is a good proposal. |
|
As an SME, I approve this proposal and consider it ready for voting. Benefits
Concerns
|
|
As a working group member, I lean towards approving this proposal. Pro:
Concerns:
|
|
@mm-near Thanks for sharing your thoughts!
That is a concern for me as well. The NEAT investigation is still ongoing and I have some hope that we'll be able to address the main issues and even have enough margin for resharding. If that doesn't turn out to be true, I very much like your suggestion and it's definitely something that we will consider.
Yes, the archival nodes are expected to finish resharding within an epoch. I performed a test where I hardcoded resharding to happen on my personal node, regardless of the rest of the network. The resharding, with default config, completed within 3h00m on mainnet and 5h30m on testnet. The time was almost the same for a rpc and a legacy archival node. More detailed results are here if you are interested. I also shared the typical times in the refreshed resharding doc. The storage overhead on archival nodes is primarily due to the divergance between the flat state snapshot and the primary database, it's not due to extra storage needed for the children shards. This is something that can be optimized and we have two ideas on how to do it, see below. We didn't have time to implement it due to deadline but if there is any indication that optimization is needed we can go back and improve it.
We tested that get_tx works as expected after resharding for a transaction that happened before the resharding. Is that what you were referring to or is there some other case where it can break? near/nearcore#10296 |
|
Thank you to everyone who attended the sixth Protocol Work Group call today! The work group members reviewed the NEP and reached the following consensus: Status: Approved 👍 @birchmd:NEP-508: Resharding v2 #508 (comment) Meeting Recording: @wacban, Thank you for authoring this NEP! Next Steps: |
Sarah-NEAR
added
S-approved
frol
approved these changes
Jan 22, 2024
zwong91
added a commit
to utnet-org/utility-readonly
that referenced
this pull request
Mar 12, 2024
* build fuzzers on Big machines (#10252)
See eg. the likely-OOM at
https://github.com/near/nearcore/actions/runs/6890897651/job/18744849948
* test: add tests for SnapshotHostInfo broadcast behavior (#10204)
Add a few tests which test that `SnapshotHostInfo` is properly broadcast
between peers.
`SnapshotHostInfo` lets other peers know that a certain peer has a state
snapshot at a specific point in time, which is later used for state
sync. Nodes publish this information periodically and it should be
broadcast to all nodes in the network.
Fixes: #10172
* allow warnings for fuzzer building (#10253)
Fuzzer building runs on rustc nightly, which can have a different set of
warnings than rustc stable. Rather than introduce a new compilation step
for all the PRs, just compile fuzzers without caring about warnings.
Fixes a recent fuzzer building issue, probably caused by a nightly
upgrade:
https://github.com/near/nearcore/actions/runs/6929988512/job/18848791016
* fix: use header_head to determine validators for forwarding transactions (#10256)
Functions `find_chunk_producer_for_forwarding()`,
`find_validator_for_forwarding()` are not used much, one calls another,
and they both call `chain.head()`.
That seems unnecessary. Refactored to call `get_chunk_producer()`
directly, and not worry about 3 layers of functions using different
types of heads.
See https://github.com/near/nearcore/pull/10251 for context
* drop buildkite pipeline (#10227)
We have now fully migrated off buildkite, so let’s remove the old
pipeline from the repository :)
* configurable tx routing horizon (#10251)
Community reports that sometimes it takes minutes for a transaction to
be recorded on chain.
My guess is that it takes that much time to record a transaction on
chain, because it gets forwarded to nodes which either:
* fail to produce their chunks
* don't have time to process incoming tx RPCs before producing their
chunks
* the node producing a tx is out of sync and the set of validators is
already too late
All of these can be fixed by multicasting transactions further into the
future.
This PR is the simplest attempt to send transactions further into the
future.
Tested: Had a testnet node and submitted a tx that was supposed to be
forwarded to chunk producers of the next 100 blocks. In practice it gets
forwarded to 5 validators. Sending a message to a validator takes about
100µs for a trivial tx.
* refactor: more work removing `num_shards()` (#10255)
Building on top of https://github.com/near/nearcore/pull/10249, further
reduces use of `num_shards()` in chain.rs.
Also removes some "premature" optimisations that I don't think would
necessarily help in production and just add complexity to the code.
* fix(config): disable epoch sync, enable state sync (#10260)
* Simplifies `state_sync_enabled` and `enable_multiline_logging`.
* Adjusts {min,max}_block_production_delay config options when
generating configs for testnet and mainnet.
* Simplifies config initialization logic.
* Deletes betanet and stakewars
* bump openssl (#10262)
Fixes https://rustsec.org/advisories/RUSTSEC-2023-0072, reported by the
cargo-audit CI job
* add a Justfile for reproducing CI locally, use it for CI (#10235)
* feat: support partial mandates in chunk validator assignment (#10241)
Adds support for partial mandates in chunk validator assignment.
Currently only full mandates are considered. Assume `stake_per_mandate =
5`, then:
- Valdiator `V1` with stake 12 holds 2 full mandates corresponding to a
stake of 10. The remaining stake of 2 does not participate in
validation.
- Validator `V2` with stake 4 holds 0 full mandates and does not
participate in validation at all.
With support for partial mandates `V1` gets a partial mandate with
weight 2 and `V2` gets a partial mandate of 4. So partial mandates allow
to increase the number of validators and allows them to commit their
entire stake to validation.
### Probability of shard corruption
In [these
simulations](https://near.zulipchat.com/#narrow/stream/407237-pagoda.2Fcore.2Fstateless-validation/topic/chunk.20validator.20assignment.20simulation.20with.20partial.20seats),
the probability of shard corruption decreases as partial seats are
included. In general, the effect of including partial seats depends on
the distribution of (malicious) stake across validators and the stake
required per mandate.
### `ValidatorMandatesAssignment`
This type is introduced to more clearly document the result of sampling
chunk validators and to avoid passing around a raw
`Vec<HashMap<ValidatorId, _>>`.
### Shuffling of shard ids
[This
thread](https://github.com/mooori/sim-validator-assignment/pull/12#discussion_r1389895314)
points out a bias towards small shard ids and brings up shard id
shuffling as a way to fix it. For now shard ids are not shuffled in this
PR, since I think it would make the diff harder to review. I would
suggest to introduce shard id shuffling in a separate PR. This should
not pose a risk as chunk validator assignment is not enabled in
production.
* [Snyk] Upgrade @types/react-dom from 18.2.14 to 18.2.15 (#10270)
<p>This PR was automatically created by Snyk using the credentials of a
real user.</p><br /><h3>Snyk has created this PR to upgrade
@types/react-dom from 18.2.14 to 18.2.15.</h3>
:information_source: Keep your dependencies up-to-date. This makes it
easier to fix existing vulnerabilities and to more quickly identify and
fix newly disclosed vulnerabilities when they affect your project.
<hr/>
- The recommended version is **1 version** ahead of your current
version.
- The recommended version was released **22 days ago**, on 2023-11-07.
<details>
<summary><b>Release notes</b></summary>
<br/>
<details>
<summary>Package name: <b>@types/react-dom</b></summary>
<ul>
<li>
<b>18.2.15</b> - 2023-11-07
</li>
<li>
<b>18.2.14</b> - 2023-10-18
</li>
</ul>
from <a
href="https://snyk.io/redirect/github/DefinitelyTyped/DefinitelyTyped/releases">@types/react-dom
GitHub release notes</a>
</details>
</details>
<hr/>
**Note:** *You are seeing this because you or someone else with access
to this repository has authorized Snyk to open upgrade PRs.*
For more information: <img
src="https://api.segment.io/v1/pixel/track?data=eyJ3cml0ZUtleSI6InJyWmxZcEdHY2RyTHZsb0lYd0dUcVg4WkFRTnNCOUEwIiwiYW5vbnltb3VzSWQiOiI5MDM2MzdmYS0yNGU2LTRiZjktYjY1NC1hYzYzNzFiMDY5MDEiLCJldmVudCI6IlBSIHZpZXdlZCIsInByb3BlcnRpZXMiOnsicHJJZCI6IjkwMzYzN2ZhLTI0ZTYtNGJmOS1iNjU0LWFjNjM3MWIwNjkwMSJ9fQ=="
width="0" height="0"/>
🧐 [View latest project
report](https://app.snyk.io/org/ecp88/project/98480bdc-d80b-4fd1-89d7-c4c56a706763?utm_source=github&utm_medium=referral&page=upgrade-pr)
🛠 [Adjust upgrade PR
settings](https://app.snyk.io/org/ecp88/project/98480bdc-d80b-4fd1-89d7-c4c56a706763/settings/integration?utm_source=github&utm_medium=referral&page=upgrade-pr)
🔕 [Ignore this dependency or unsubscribe from future upgrade
PRs](https://app.snyk.io/org/ecp88/project/98480bdc-d80b-4fd1-89d7-c4c56a706763/settings/integration?pkg=@types/react-dom&utm_source=github&utm_medium=referral&page=upgrade-pr#auto-dep-upgrades)
<!---
(snyk:metadata:{"prId":"903637fa-24e6-4bf9-b654-ac6371b06901","prPublicId":"903637fa-24e6-4bf9-b654-ac6371b06901","dependencies":[{"name":"@types/react-dom","from":"18.2.14","to":"18.2.15"}],"packageManager":"npm","type":"auto","projectUrl":"https://app.snyk.io/org/ecp88/project/98480bdc-d80b-4fd1-89d7-c4c56a706763?utm_source=github&utm_medium=referral&page=upgrade-pr","projectPublicId":"98480bdc-d80b-4fd1-89d7-c4c56a706763","env":"prod","prType":"upgrade","vulns":[],"issuesToFix":[],"upgrade":[],"upgradeInfo":{"versionsDiff":1,"publishedDate":"2023-11-07T20:33:53.244Z"},"templateVariants":[],"hasFixes":false,"isMajorUpgrade":false,"isBreakingChange":false,"priorityScoreList":[]})
--->
Co-authored-by: snyk-bot <[email protected]>
* feat: use the < operator instead of cmp method to improve readability (#10268)
The following code is currently used for comparing `boundary_account`
and `account_id`:
```rust
if boundary_account.cmp(account_id) == Greater {
...
}
```
IMO it's a bit confusing - it isn't immediately obvious whether this
means `boundary_account` > `account_id` or `account_id` >
`boundary_account`. I misread this line and because of that I made a
mistake in #10240.
Let's change it to something that is easier to read:
```rust
if account_id < boundary_account {
...
}
```
* feat: add database analyse-gas-usage command (#10240)
Add a command which allows to analyse gas usage on some part of the
blockchain.
The command goes over the specified blocks and gathers information about
how much
gas was used by each block, shard and account.
Then it displays an analysis of all the data.
The analysis contains:
* Total gas used
* Gas used on each shard
* Top 10 accounts by gas usage
* The optimal account by which a shard could be split into two halves
with similar gas usage
Help page:
```bash
$ ./neard database analyse-gas-usage --help
Analyse gas usage in a chosen sequnce of blocks
Usage: neard database analyse-gas-usage [OPTIONS]
Options:
--last-blocks <LAST_BLOCKS>
Analyse the last N blocks in the blockchain
--from-block-height <FROM_BLOCK_HEIGHT>
Analyse blocks from the given block height, inclusive
--to-block-height <TO_BLOCK_HEIGHT>
Analyse blocks up to the given block height, inclusive
-h, --help
Print help
```
Example usage:
```bash
# Analyse gas usage in the last 1000 blocks
cargo run --bin neard -- database analyse-gas-usage --last-blocks 1000
# Analyse gas usage in blocks with heights between 200 and 300 (inclusive)
./neard database analyse-gas-usage --from-block-height 200 --to-block-height 300
```
* refactor: replace all remaining uses of `num_shards()` with `shard_ids()` (#10271)
Closes https://github.com/near/nearcore/issues/10237
* Update resharding.md (#10264)
A pretty heavy handed rewrite of the resharding documentation. I'm open
to some heavy handed suggestions ;)
I'm not sure what's the best trade off between duplicating some content
from the NEPs here and keeping in minimal with just links.
There is some new content here, mainly the rollout section, I would love
to hear some thoughts about this in particular from @gmilescu and
@posvyatokum.
* introduce hack for fuzzers building (#10276)
This introduces a hack in our fork of cargo-bolero, needed for proper
fuzzer building. The reason is still the same as the patch previously
applied: the current bolero way of auto-detecting fuzzers is suboptimal.
All these patches should be able to go away with some work on
cargo-bolero, but we have other priorities, and this hack seems to make
the tarball builds work locally at least.
With this, we run with two patches:
-
https://github.com/Ekleog-NEAR/bolero/commit/877f19959e708f288e2e3c814768743f86f69c80,
which is a bit hacky but might deserve being included upstream were it
not for backward compatibility reasons
-
https://github.com/Ekleog-NEAR/bolero/commit/56da8e6d1d018519a30b36d85d3a53fe35a42eaf,
which is a real, bad hack, but seems to be enough to stop having to care
about it for now, until we can go back to it and fix the underlying
issue that fuzzer listing is currently not well-implemented. Its
consequence is, any fuzzer in the `neard` crate will not actually run on
our fuzzing infrastructure. We’ll have to fix it at some point.
* refactor: move runtime tests into a separate file (#10274)
This PR moves NightshadeRuntime tests module into a separate file
without changing anything else.
See https://github.com/near/nearcore/issues/10275 for more context.
In case having tests as a separate file is a good idea for the following
reasons:
- these are mostly integration-style tests with heavy setup (see
`TestEnv`) and quite a lot of code, so to me it seems like it deserves
to be in a separate file
- the code is already in `mod.rs` file, so we don't need to create a
separate directory structure.
* [ChunkValidation] Remove the feature flag protocol_feature_chunk_validation. (#10257)
We discussed as a team earlier that we don't need these feature flags.
Removing it to simplify further development of chunk validation.
* Chore: Removed unused imports/exports (#10288)
* crypto: simplify split usage [trivial] (#10285)
* [Snyk] Upgrade @types/react from 18.2.25 to 18.2.37 (#10284)
<p>This PR was automatically created by Snyk using the credentials of a
real user.</p><br /><h3>Snyk has created this PR to upgrade @types/react
from 18.2.25 to 18.2.37.</h3>
:information_source: Keep your dependencies up-to-date. This makes it
easier to fix existing vulnerabilities and to more quickly identify and
fix newly disclosed vulnerabilities when they affect your project.
<hr/>
- The recommended version is **12 versions** ahead of your current
version.
- The recommended version was released **25 days ago**, on 2023-11-07.
<details>
<summary><b>Release notes</b></summary>
<br/>
<details>
<summary>Package name: <b>@types/react</b></summary>
<ul>
<li>
<b>18.2.37</b> - 2023-11-07
</li>
<li>
<b>18.2.36</b> - 2023-11-06
</li>
<li>
<b>18.2.35</b> - 2023-11-05
</li>
<li>
<b>18.2.34</b> - 2023-11-01
</li>
<li>
<b>18.2.33</b> - 2023-10-26
</li>
<li>
<b>18.2.32</b> - 2023-10-25
</li>
<li>
<b>18.2.31</b> - 2023-10-20
</li>
<li>
<b>18.2.30</b> - 2023-10-19
</li>
<li>
<b>18.2.29</b> - 2023-10-18
</li>
<li>
<b>18.2.28</b> - 2023-10-10
</li>
<li>
<b>18.2.27</b> - 2023-10-09
</li>
<li>
<b>18.2.26</b> - 2023-10-09
</li>
<li>
<b>18.2.25</b> - 2023-10-04
</li>
</ul>
from <a
href="https://snyk.io/redirect/github/DefinitelyTyped/DefinitelyTyped/releases">@types/react
GitHub release notes</a>
</details>
</details>
<hr/>
**Note:** *You are seeing this because you or someone else with access
to this repository has authorized Snyk to open upgrade PRs.*
For more information: <img
src="https://api.segment.io/v1/pixel/track?data=eyJ3cml0ZUtleSI6InJyWmxZcEdHY2RyTHZsb0lYd0dUcVg4WkFRTnNCOUEwIiwiYW5vbnltb3VzSWQiOiJkYjA5OTM4YS0zZGY5LTRkMTYtYTM5MS00MDkyMzVkNTllMDUiLCJldmVudCI6IlBSIHZpZXdlZCIsInByb3BlcnRpZXMiOnsicHJJZCI6ImRiMDk5MzhhLTNkZjktNGQxNi1hMzkxLTQwOTIzNWQ1OWUwNSJ9fQ=="
width="0" height="0"/>
🧐 [View latest project
report](https://app.snyk.io/org/ecp88/project/98480bdc-d80b-4fd1-89d7-c4c56a706763?utm_source=github&utm_medium=referral&page=upgrade-pr)
🛠 [Adjust upgrade PR
settings](https://app.snyk.io/org/ecp88/project/98480bdc-d80b-4fd1-89d7-c4c56a706763/settings/integration?utm_source=github&utm_medium=referral&page=upgrade-pr)
🔕 [Ignore this dependency or unsubscribe from future upgrade
PRs](https://app.snyk.io/org/ecp88/project/98480bdc-d80b-4fd1-89d7-c4c56a706763/settings/integration?pkg=@types/react&utm_source=github&utm_medium=referral&page=upgrade-pr#auto-dep-upgrades)
<!---
(snyk:metadata:{"prId":"db09938a-3df9-4d16-a391-409235d59e05","prPublicId":"db09938a-3df9-4d16-a391-409235d59e05","dependencies":[{"name":"@types/react","from":"18.2.25","to":"18.2.37"}],"packageManager":"npm","type":"auto","projectUrl":"https://app.snyk.io/org/ecp88/project/98480bdc-d80b-4fd1-89d7-c4c56a706763?utm_source=github&utm_medium=referral&page=upgrade-pr","projectPublicId":"98480bdc-d80b-4fd1-89d7-c4c56a706763","env":"prod","prType":"upgrade","vulns":[],"issuesToFix":[],"upgrade":[],"upgradeInfo":{"versionsDiff":12,"publishedDate":"2023-11-07T20:31:32.792Z"},"templateVariants":[],"hasFixes":false,"isMajorUpgrade":false,"isBreakingChange":false,"priorityScoreList":[]})
--->
Co-authored-by: snyk-bot <[email protected]>
* [Snyk] Security upgrade react-query from 3.39.3 to 4.0.0 (#10282)
<p>This PR was automatically created by Snyk using the credentials of a
real user.</p><br /><h3>Snyk has created this PR to fix one or more
vulnerable packages in the `npm` dependencies of this project.</h3>
#### Changes included in this PR
- Changes to the following files to upgrade the vulnerable dependencies
to a fixed version:
- tools/debug-ui/package.json
- tools/debug-ui/package-lock.json
#### Vulnerabilities that will be fixed
##### With an upgrade:
Severity | Priority Score (*) | Issue | Breaking Change | Exploit
Maturity
:-------------------------:|-------------------------|:-------------------------|:-------------------------|:-------------------------
 | **661/1000** <br/> **Why?** Recently disclosed, Has a
fix available, CVSS 7.5 | Missing Release of Resource after Effective
Lifetime
<br/>[SNYK-JS-INFLIGHT-6095116](https://snyk.io/vuln/SNYK-JS-INFLIGHT-6095116)
| Yes | No Known Exploit
(*) Note that the real score may have changed since the PR was raised.
<details>
<summary><b>Commit messages</b></summary>
</br>
<details>
<summary>Package name: <b>react-query</b></summary>
The new version differs by 1 commits.</br>
<ul>
<li><a
href="https://snyk.io/redirect/github/TanStack/query/commit/357ec041a6fcc4a550f3df02c12ecc7bcdefbc05">357ec04</a>
v4 release (#3842)</li>
</ul>
<a
href="https://snyk.io/redirect/github/TanStack/query/compare/ef684205cb4890db904db5b387513fb9042e0bb6...357ec041a6fcc4a550f3df02c12ecc7bcdefbc05">See
the full diff</a>
</details>
</details>
Check the changes in this PR to ensure they won't cause issues with your
project.
------------
**Note:** *You are seeing this because you or someone else with access
to this repository has authorized Snyk to open fix PRs.*
For more information: <img
src="https://api.segment.io/v1/pixel/track?data=eyJ3cml0ZUtleSI6InJyWmxZcEdHY2RyTHZsb0lYd0dUcVg4WkFRTnNCOUEwIiwiYW5vbnltb3VzSWQiOiIyMzRmMTE2Yi0wYWFjLTRkOTMtYWRlZi0zMjNhMDgyMTQ2MzAiLCJldmVudCI6IlBSIHZpZXdlZCIsInByb3BlcnRpZXMiOnsicHJJZCI6IjIzNGYxMTZiLTBhYWMtNGQ5My1hZGVmLTMyM2EwODIxNDYzMCJ9fQ=="
width="0" height="0"/>
🧐 [View latest project
report](https://app.snyk.io/org/ecp88/project/98480bdc-d80b-4fd1-89d7-c4c56a706763?utm_source=github&utm_medium=referral&page=fix-pr)
🛠 [Adjust project
settings](https://app.snyk.io/org/ecp88/project/98480bdc-d80b-4fd1-89d7-c4c56a706763?utm_source=github&utm_medium=referral&page=fix-pr/settings)
📚 [Read more about Snyk's upgrade and patch
logic](https://support.snyk.io/hc/en-us/articles/360003891078-Snyk-patches-to-fix-vulnerabilities)
[//]: #
(snyk:metadata:{"prId":"234f116b-0aac-4d93-adef-323a08214630","prPublicId":"234f116b-0aac-4d93-adef-323a08214630","dependencies":[{"name":"react-query","from":"3.39.3","to":"4.0.0"}],"packageManager":"npm","projectPublicId":"98480bdc-d80b-4fd1-89d7-c4c56a706763","projectUrl":"https://app.snyk.io/org/ecp88/project/98480bdc-d80b-4fd1-89d7-c4c56a706763?utm_source=github&utm_medium=referral&page=fix-pr","type":"auto","patch":[],"vulns":["SNYK-JS-INFLIGHT-6095116"],"upgrade":["SNYK-JS-INFLIGHT-6095116"],"isBreakingChange":true,"env":"prod","prType":"fix","templateVariants":["updated-fix-title","priorityScore"],"priorityScoreList":[661],"remediationStrategy":"vuln"})
---
**Learn how to fix vulnerabilities with free interactive lessons:**
🦉 [Learn about vulnerability in an interactive lesson of Snyk
Learn.](https://learn.snyk.io/?loc=fix-pr)
Co-authored-by: snyk-bot <[email protected]>
* build(deps-dev): bump @adobe/css-tools from 4.3.1 to 4.3.2 in /tools/debug-ui (#10272)
Bumps [@adobe/css-tools](https://github.com/adobe/css-tools) from 4.3.1
to 4.3.2.
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a
href="https://github.com/adobe/css-tools/blob/main/History.md"><code>@adobe/css-tools</code>'s
changelog</a>.</em></p>
<blockquote>
<h1>4.3.2 / 2023-11-28</h1>
<ul>
<li>Fix redos vulnerability with specific crafted css string -
CVE-2023-48631</li>
<li>Fix Problem parsing with :is() and nested :nth-child() <a
href="https://redirect.github.com/adobe/css-tools/issues/211">#211</a></li>
</ul>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li>See full diff in <a
href="https://github.com/adobe/css-tools/commits">compare view</a></li>
</ul>
</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/near/nearcore/network/alerts).
</details>
Signed-off-by: dependabot[bot] <[email protected]>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
* Update resharding.md (#10281)
Added some metrics from tests in mainnet and testnet.
ref data mainnet https://nearinc.grafana.net/goto/aFBwfLHSg?orgId=1
ref data testnet https://nearinc.grafana.net/goto/XgBUBYNSg?orgId=1
* fix: Document HeaderSync (#10280)
Made no functional changes except:
* Replaced a tuple with a struct
* Introduced a function `made_enough_progress()` to make the code much
simpler to understand.
* Renamed a ban reason
* fix: format tcp connection error using `Display` (#10286)
Reported by @wacban.
Debug printing results in multiline strings, which are hard to
interpret. It also breaks tooling one might want to use to analyze logs.
Example:
```
2023-12-01T10:22:08.186809Z INFO network: failed to connect to ed25519:[email protected]:54063 result=Err(tcp::Stream::connect()
Caused by:
deadline has elapsed)
```
I believe this is coming from the default `Debug` impl for
`anyhow::Error`. Using `Display` impl should fix it as it concatenates
the context via `:` instead.
---------
Co-authored-by: nikurt <[email protected]>
* refactor: remove some more usage of `num_shards()` (#10291)
See https://github.com/near/nearcore/issues/10237.
* feat: limit the number of shards ids in SnapshotHostInfo (#10294)
`SnapshotHostInfo` contains a list of shard ids for which a peer has a
snapshot.
Under normal circumstances this list is pretty small - the maximum size
would be the total number of shards.
But a malicious peer could craft a `SnapshotHostInfo` message with very
large number of shards - millions of shard ids. This could cause
problems on the receiver node, so there has to be limit on the number of
shard ids in a message.
Let's limit the number of shard ids in a single message to
`MAX_SHARDS_PER_SNAPSHOT_HOST_INFO = 512`.
It's a constant that describes how many shards a single peer can have
snapshots for.
A peer doesn't keep more state snapshots than the number of tracked
shards, so this limit is reasonable. 512 shards ought to be enough for
anyone.
In an ideal world we could check the current number of shards and reject
messages that contain more shard ids than the current number, but sadly
this can't be implemented. The problem is that the receiving node might
be behind the rest of the blockchain, and the latest information just
isn't available, so it can't check what the current number of shards is.
We could reject messages in such situations, but this would lead to loss
of information.
Limiting the number of shard ids to a constant number is an okay
alternative.
* feat(resharding): dynamic config (#10290)
make the resharding config dynamic
* Remove rust-version.workspace = true from published crates (#10292)
This comes at the request of dev-hub, where dependencies downstream have
been having issues with our aggressive rust-version policy. Supporting
only the latest rust-version is not enough for them.
As a consequence, we’re removing rust-version here. This sounds like a
more semantically reasonable use for rust-version anyway: a crate
without rust-version set should be assumed to work with the latest
stable version anyway, and maybe more without guarantees… which is
exactly our guarantees.
Also update the themis tool to make sure we don’t make this mistake
again.
* [resharding] Add pytest for checking RPC calls after resharding (#10296)
This PR adds a basic pytest to check if the RPC calls to tx endpoint
work after a resharding event.
Note that this test currently works under the assumption that the node
is tracking all shards and future improvements to the tests where we may
need to redirect the request to a node tracking the specific shard we
are interested in, would come later.
Resolving https://github.com/near/nearcore/issues/5047
* build fuzzers on ubuntu-20.04 (#10299)
Currently, our clusterfuzz runners do not have the glibc version
required to run builds made on ubuntu-22.04.
Building fuzzers on ubuntu-20.04 should fix the issue (that is only
apparent in fuzzer logs); hopefully once we upgrade our clusterfuzz
runners we’ll be able to bump to a newer ubuntu LTS.
* refactor: Rename BodySync to BlockSync for consistency (#10293)
And a bit of documentation for header sync.
And a bit of documentation of block sync.
And a bit of refactoring of block sync.
And a tiny refactoring related to state sync.
And a lot of TODOs.
* fix(resharding): fix dynamic config (#10297)
Fixing the dynamic config since #10290 was accidentaly merged
prematurely before it was fully tested and fixed.
Tested on localnet for now, will then test on mocknet and only then
merge.
* refactor: don't use `Fn` when `FnOnce` will suffice (#10301)
This function calls the closure just once so no need to take a more
restrictive closure.
* enable resharding v2 (#10303)
# Feature to stabilize
This PR stabilizes the Resharding V2 protocol feature. It introduces a
new implementation for resharding and a new shard layout for the
production networks - mainnet and testnet. The resharding process from
the current shard layout to the new shard layout will be triggered
automatically an epoch before the switch to the new protocol version.
# Context
- https://github.com/near/NEPs/pull/508
- https://github.com/near/nearcore/issues/8992
# Testing and QA
This feature was extensively tested in unit tests, integration tests,
nayduck tests, mocknet, testnet and mainnet.
# Checklist
- [ ] nayduck - https://nayduck.near.org/#/run/3308
- [x] Update CHANGELOG.md to include this protocol feature in the
`Unreleased` section.
* Reintroduce configurable cache size for the FlatState column (#10304)
One way to reduce flat state read latency during the NEAT incident was
to increase the cache size 3x.
As the config parameter was helpful during the incident, re-introduce
this config parameter.
Additionally make caches for State and FlatState configurable
separately.
* refactor: same treatment for `get_shard_uids()` as for `shard_ids()` (#10305)
- renames `get_shard_uids()` to `shard_uids()`
- `shard_uids()` return an iterator instead of a vector.
* refactor(state-sync): Request sync block in client actor before starting state sync (#10175)
We only use this logic for state sync when the nodes starts with old
blocks.
If the nodes has been running during the epoch change, it is supposed to
have the block so it does not need it at state sync during catchup.
* refactor: group runtime apply_transactions block/chunk-related arguments (#10279)
This PR groups block- and chunk-related
`RuntimeAdapter::apply_transactions` arguments into a separate structs.
It also replaces usage `update_shard::BlockContext` with
`ApplyTransactionsBlockContext` as well as a bit of refactoring around
`ShardUpdateReason` to only require data which is actually used.
Implements the first idea from
https://github.com/near/nearcore/issues/10261.
* fix: State Sync Header Request no longer crashes a node (#10313)
* feat: add a time limit for processing transactions in produce_chunk (#10310)
To produce a chunk the node fetches transactions from the transaction
pool and adds them to the chunk. Adding a transaction to the chunk can
be computationally expensive - the transaction is converted to receipt,
which burns gas. Because of that the number of transactions has to be
limited. The node will fetch transactions until some kind of limit is
reached, and then decide that the chunk is ready and publish it.
Currently we have a limit of gas that can be used for preparing
transactions, but there is a big problem with it - it doesn't take into
account discarding invalid transactions from the pool. Processing an
invalid transaction doesn't burn gas, so the node could spend a lot of
time discarding invalid transactions without ever reaching the limit.
This would make chunk production very slow and the others might decide
to just skip the chunk instead of waiting for it.
Let's add another limit to `prepare_transactions`: a time limit. When
producing a chunk the node will be allowed to add new transactions to
the chunk for up to X milliseconds. This will ensure that a chunk is
produced quickly, even when there are many invalid transactions.
Choosing a good value for the limit is difficult, so a new config option
is added to allow changing it on the fly:
`produce_chunk_add_transactions_time_limit`.
The default value for the time limit is 200ms. The reasoning for
choosing this value is as follows:
* Assuming that we want to produce ~1 block per second, 200ms is the
largest value that would support that. If my understanding of the flow
is correct, a 200ms chunk production would look like this:
* Chunk producer produces a chunk (200ms)
* Chunk producer publishes the chunk (50ms (?))
* Validator receives the chunk
* Validator validates the transactions, redoing chunk producer's work
(200ms)
* Validator runs receipts (500ms)
This gives us a 1s time to produce a block.
* Looking at the metrics from mainnet, the P99 time to produce a chunk
is ~60ms (and maximum is similar). 200ms is more than three times that,
so it shouldn't break anything on the chain:
https://nearinc.grafana.net/d/cd668436-f19a-4f3d-b4a5-a35ebd3701b0/chunk-production-stats?from=now-12h&to=now&refresh=1h&orgId=1
* During the minting of NEAT, the P99 time to produce a chunk jumped to
~860ms. This is unacceptable, as this will cause the chain to produce
less than one block per second. This limit would prevent that.
https://nearinc.grafana.net/d/cd668436-f19a-4f3d-b4a5-a35ebd3701b0/chunk-production-stats?from=1701298800000&to=1701342000000&orgId=1
For a more detailed discussion, see the comments in
https://github.com/near/nearcore/issues/10278
Fixes: #10278
* fix(resharding): fix tests (#10314)
This should fix a bunch of the nayduck tests.
https://nayduck.near.org/#/run/3318
* feat(chunk-validator-assignment): shuffle shard ids (#10298)
Introduces a shuffling of shard ids when assigning chunk validators to
shards. Without that shuffling it is predictable which shards receive
fewer (partial) mandates when they cannot be distributed evenly across
shards. See this
[comment](https://github.com/mooori/sim-validator-assignment/pull/12#discussion_r1389895314)
which also brings up the idea of shard id shuffling.
### Separate shuffles for full and partial mandate assignment
If there was only one shuffling for both full and partial mandates, then
the shard(s) that get a full mandate less may also get a partial mandate
less. Separate shufflings counter that and ideally (depending on
randomness) stake is distributed more evenly as shards that receive a
full mandate less may still get the maximum amount of partial mandates.
### Related issue
#10014
* docs(resharding) - described how to dynamically update the config (#10315)
* feat: stateless validation jobs in test mode (#10248)
This is a next step for #9982.
Here I introduce jobs which will perform stateless validation of newly
received chunk by executing txs and receipts.
Later they should be executed against state witness, but for now I just
set a foundation by running these jobs against state data in DB. All
passing tests verify that old and new jobs generate the same result.
The final switch will happen when stateful jobs will be replaced with
stateless ones.
### Details
This doesn't introduce any load on stable version. On nightly version
there will be `num_shards` extra jobs which will check that stateless
validation results are consistent with stateful execution. But as we use
nightly only for testing, it shouldn't mean much overhead.
I add more fields to `ShardContext` structure to simplify code. Some of
them are needed to break early if there is resharding, and the logic is
the same for both kinds of jobs.
`StorageDataSource::DbTrieOnly` is introduced to read data only from
trie in stateless jobs. This is annoying but still needed if there are a
lot of missing chunks and flat storage head moved above the block at
which previous chunk was created. When state witness will be
implemented, `Recorded` will be used instead.
## Testing
* Failure to update current_chunk_extra on the way leads to >20 tests
failing in process_blocks, with errors like `assertion `left == right`
failed: For stateless validation, chunk extras for block
CMV88CBcnKoxa7eTnkG64psLoJzpW9JeAhFrZBVv6zDc and shard s3.v2 do not
match...`
* If I update current_chunk_extra only once,
`tests::client::resharding::test_latest_protocol_missing_chunks_high_missing_prob`
fails which was specifically introduced for that. Actually this helped
to realize that `validate_chunk_with_chunk_extra` is still needed but I
will introduce it later.
* Nayduck: ~https://nayduck.near.org/#/run/3293 - +10 nightly tests
failing, will take a look~ https://nayduck.near.org/#/run/3300
---------
Co-authored-by: Longarithm <[email protected]>
* [Snyk] Upgrade @types/node from 16.18.3 to 16.18.62 (#10312)
<p>This PR was automatically created by Snyk using the credentials of a
real user.</p><br /><h3>Snyk has created this PR to upgrade @types/node
from 16.18.3 to 16.18.62.</h3>
:information_source: Keep your dependencies up-to-date. This makes it
easier to fix existing vulnerabilities and to more quickly identify and
fix newly disclosed vulnerabilities when they affect your project.
<hr/>
- The recommended version is **59 versions** ahead of your current
version.
- The recommended version was released **22 days ago**, on 2023-11-18.
<details>
<summary><b>Release notes</b></summary>
<br/>
<details>
<summary>Package name: <b>@types/node</b></summary>
<ul>
<li>
<b>16.18.62</b> - 2023-11-18
</li>
<li>
<b>16.18.61</b> - 2023-11-07
</li>
<li>
<b>16.18.60</b> - 2023-10-31
</li>
<li>
<b>16.18.59</b> - 2023-10-18
</li>
<li>
<b>16.18.58</b> - 2023-10-06
</li>
<li>
<b>16.18.57</b> - 2023-10-02
</li>
<li>
<b>16.18.56</b> - 2023-10-02
</li>
<li>
<b>16.18.55</b> - 2023-09-29
</li>
<li>
<b>16.18.54</b> - 2023-09-23
</li>
<li>
<b>16.18.53</b> - 2023-09-20
</li>
<li>
<b>16.18.52</b> - 2023-09-16
</li>
<li>
<b>16.18.51</b> - 2023-09-15
</li>
<li>
<b>16.18.50</b> - 2023-09-08
</li>
<li>
<b>16.18.49</b> - 2023-09-08
</li>
<li>
<b>16.18.48</b> - 2023-09-02
</li>
<li>
<b>16.18.47</b> - 2023-09-01
</li>
<li>
<b>16.18.46</b> - 2023-08-24
</li>
<li>
<b>16.18.45</b> - 2023-08-24
</li>
<li>
<b>16.18.44</b> - 2023-08-23
</li>
<li>
<b>16.18.43</b> - 2023-08-22
</li>
<li>
<b>16.18.42</b> - 2023-08-22
</li>
<li>
<b>16.18.41</b> - 2023-08-17
</li>
<li>
<b>16.18.40</b> - 2023-08-08
</li>
<li>
<b>16.18.39</b> - 2023-07-21
</li>
<li>
<b>16.18.38</b> - 2023-06-30
</li>
<li>
<b>16.18.37</b> - 2023-06-26
</li>
<li>
<b>16.18.36</b> - 2023-06-13
</li>
<li>
<b>16.18.35</b> - 2023-06-10
</li>
<li>
<b>16.18.34</b> - 2023-05-26
</li>
<li>
<b>16.18.33</b> - 2023-05-25
</li>
<li>
<b>16.18.32</b> - 2023-05-21
</li>
<li>
<b>16.18.31</b> - 2023-05-16
</li>
<li>
<b>16.18.30</b> - 2023-05-13
</li>
<li>
<b>16.18.29</b> - 2023-05-11
</li>
<li>
<b>16.18.28</b> - 2023-05-10
</li>
<li>
<b>16.18.27</b> - 2023-05-08
</li>
<li>
<b>16.18.26</b> - 2023-05-05
</li>
<li>
<b>16.18.25</b> - 2023-04-25
</li>
<li>
<b>16.18.24</b> - 2023-04-19
</li>
<li>
<b>16.18.23</b> - 2023-03-30
</li>
<li>
<b>16.18.22</b> - 2023-03-28
</li>
<li>
<b>16.18.21</b> - 2023-03-25
</li>
<li>
<b>16.18.20</b> - 2023-03-24
</li>
<li>
<b>16.18.19</b> - 2023-03-23
</li>
<li>
<b>16.18.18</b> - 2023-03-20
</li>
<li>
<b>16.18.17</b> - 2023-03-20
</li>
<li>
<b>16.18.16</b> - 2023-03-14
</li>
<li>
<b>16.18.15</b> - 2023-03-13
</li>
<li>
<b>16.18.14</b> - 2023-03-02
</li>
<li>
<b>16.18.13</b> - 2023-02-26
</li>
<li>
<b>16.18.12</b> - 2023-02-04
</li>
<li>
<b>16.18.11</b> - 2022-12-26
</li>
<li>
<b>16.18.10</b> - 2022-12-16
</li>
<li>
<b>16.18.9</b> - 2022-12-13
</li>
<li>
<b>16.18.8</b> - 2022-12-10
</li>
<li>
<b>16.18.7</b> - 2022-12-08
</li>
<li>
<b>16.18.6</b> - 2022-12-05
</li>
<li>
<b>16.18.5</b> - 2022-12-05
</li>
<li>
<b>16.18.4</b> - 2022-11-30
</li>
<li>
<b>16.18.3</b> - 2022-10-30
</li>
</ul>
from <a
href="https://snyk.io/redirect/github/DefinitelyTyped/DefinitelyTyped/releases">@types/node
GitHub release notes</a>
</details>
</details>
<hr/>
**Note:** *You are seeing this because you or someone else with access
to this repository has authorized Snyk to open upgrade PRs.*
For more information: <img
src="https://api.segment.io/v1/pixel/track?data=eyJ3cml0ZUtleSI6InJyWmxZcEdHY2RyTHZsb0lYd0dUcVg4WkFRTnNCOUEwIiwiYW5vbnltb3VzSWQiOiI0NTA4MzY5Mi1lOWNjLTQyMjYtOWRkMi01NDFhODBhNTYzYTgiLCJldmVudCI6IlBSIHZpZXdlZCIsInByb3BlcnRpZXMiOnsicHJJZCI6IjQ1MDgzNjkyLWU5Y2MtNDIyNi05ZGQyLTU0MWE4MGE1NjNhOCJ9fQ=="
width="0" height="0"/>
🧐 [View latest project
report](https://app.snyk.io/org/ecp88/project/98480bdc-d80b-4fd1-89d7-c4c56a706763?utm_source=github&utm_medium=referral&page=upgrade-pr)
🛠 [Adjust upgrade PR
settings](https://app.snyk.io/org/ecp88/project/98480bdc-d80b-4fd1-89d7-c4c56a706763/settings/integration?utm_source=github&utm_medium=referral&page=upgrade-pr)
🔕 [Ignore this dependency or unsubscribe from future upgrade
PRs](https://app.snyk.io/org/ecp88/project/98480bdc-d80b-4fd1-89d7-c4c56a706763/settings/integration?pkg=@types/node&utm_source=github&utm_medium=referral&page=upgrade-pr#auto-dep-upgrades)
<!---
(snyk:metadata:{"prId":"45083692-e9cc-4226-9dd2-541a80a563a8","prPublicId":"45083692-e9cc-4226-9dd2-541a80a563a8","dependencies":[{"name":"@types/node","from":"16.18.3","to":"16.18.62"}],"packageManager":"npm","type":"auto","projectUrl":"https://app.snyk.io/org/ecp88/project/98480bdc-d80b-4fd1-89d7-c4c56a706763?utm_source=github&utm_medium=referral&page=upgrade-pr","projectPublicId":"98480bdc-d80b-4fd1-89d7-c4c56a706763","env":"prod","prType":"upgrade","vulns":[],"issuesToFix":[],"upgrade":[],"upgradeInfo":{"versionsDiff":59,"publishedDate":"2023-11-18T20:08:25.418Z"},"templateVariants":[],"hasFixes":false,"isMajorUpgrade":false,"isBreakingChange":false,"priorityScoreList":[]})
--->
Co-authored-by: snyk-bot <[email protected]>
* test(resharding) - test for getting the shard layout info by rpc (#10320)
We need a way for near ecosystem developers to query the current shard
layout. The EXPERIMENTAL_protocol_config allows that although with some
extra steps. It should be good enough until we have time to implement a
dedicated endpoint just for the shard layout. In this PR I extended the
resharding nayduck test to check that the mentioned rpc endpoint works
as expected and that changes in the shard layout are reflected in the
rpc.
* fix: remove flakiness in the test try_map_result_stops_on_error (#10318)
`try_map_result` is a function which takes a list of tasks and runs them
on multiple threads producing task outputs until the first error occurs.
The test `try_map_result_stops_on_error` asks to execute an infinite
list of tasks, but the 100th task throws an error, so the function
should stop after executing ~100 tasks.
The test checked that the function produces outputs for the first 10
tasks, but this isn't always true. The first 10 tasks could end up on a
thread that is preempted and the tasks aren't executed before the error
is hit on the 100th task. Because of this the test is flaky.
I assumed that the first 10 tasks would be executed first, but this was
wrong, we can't assume anything here. Let's remove all checks that could
be broken by race conditions, no matter how unlikely. This makes the
test weaker, but at least it won't be flaky.
* make crates publish-able for other branches than master (#10322)
* Fix sync_ban.py (#10323)
The log message tracked by this test was changed.
* [Snyk] Upgrade @types/react-dom from 18.2.15 to 18.2.16 (#10324)
<p>This PR was automatically created by Snyk using the credentials of a
real user.</p><br /><h3>Snyk has created this PR to upgrade
@types/react-dom from 18.2.15 to 18.2.16.</h3>
:information_source: Keep your dependencies up-to-date. This makes it
easier to fix existing vulnerabilities and to more quickly identify and
fix newly disclosed vulnerabilities when they affect your project.
<hr/>
- The recommended version is **1 version** ahead of your current
version.
- The recommended version was released **22 days ago**, on 2023-11-21.
<details>
<summary><b>Release notes</b></summary>
<br/>
<details>
<summary>Package name: <b>@types/react-dom</b></summary>
<ul>
<li>
<b>18.2.16</b> - 2023-11-21
</li>
<li>
<b>18.2.15</b> - 2023-11-07
</li>
</ul>
from <a
href="https://snyk.io/redirect/github/DefinitelyTyped/DefinitelyTyped/releases">@types/react-dom
GitHub release notes</a>
</details>
</details>
<hr/>
**Note:** *You are seeing this because you or someone else with access
to this repository has authorized Snyk to open upgrade PRs.*
For more information: <img
src="https://api.segment.io/v1/pixel/track?data=eyJ3cml0ZUtleSI6InJyWmxZcEdHY2RyTHZsb0lYd0dUcVg4WkFRTnNCOUEwIiwiYW5vbnltb3VzSWQiOiIyNjJjMzRiNi1iYjljLTQ2YjYtYmQzMy04NDdkZDU2ZjRiNDciLCJldmVudCI6IlBSIHZpZXdlZCIsInByb3BlcnRpZXMiOnsicHJJZCI6IjI2MmMzNGI2LWJiOWMtNDZiNi1iZDMzLTg0N2RkNTZmNGI0NyJ9fQ=="
width="0" height="0"/>
🧐 [View latest project
report](https://app.snyk.io/org/ecp88/project/98480bdc-d80b-4fd1-89d7-c4c56a706763?utm_source=github&utm_medium=referral&page=upgrade-pr)
🛠 [Adjust upgrade PR
settings](https://app.snyk.io/org/ecp88/project/98480bdc-d80b-4fd1-89d7-c4c56a706763/settings/integration?utm_source=github&utm_medium=referral&page=upgrade-pr)
🔕 [Ignore this dependency or unsubscribe from future upgrade
PRs](https://app.snyk.io/org/ecp88/project/98480bdc-d80b-4fd1-89d7-c4c56a706763/settings/integration?pkg=@types/react-dom&utm_source=github&utm_medium=referral&page=upgrade-pr#auto-dep-upgrades)
<!---
(snyk:metadata:{"prId":"262c34b6-bb9c-46b6-bd33-847dd56f4b47","prPublicId":"262c34b6-bb9c-46b6-bd33-847dd56f4b47","dependencies":[{"name":"@types/react-dom","from":"18.2.15","to":"18.2.16"}],"packageManager":"npm","type":"auto","projectUrl":"https://app.snyk.io/org/ecp88/project/98480bdc-d80b-4fd1-89d7-c4c56a706763?utm_source=github&utm_medium=referral&page=upgrade-pr","projectPublicId":"98480bdc-d80b-4fd1-89d7-c4c56a706763","env":"prod","prType":"upgrade","vulns":[],"issuesToFix":[],"upgrade":[],"upgradeInfo":{"versionsDiff":1,"publishedDate":"2023-11-21T01:34:32.698Z"},"templateVariants":[],"hasFixes":false,"isMajorUpgrade":false,"isBreakingChange":false,"priorityScoreList":[]})
--->
Co-authored-by: snyk-bot <[email protected]>
* [Snyk] Upgrade @types/node from 16.18.62 to 16.18.63 (#10326)
<p>This PR was automatically created by Snyk using the credentials of a
real user.</p><br /><h3>Snyk has created this PR to upgrade @types/node
from 16.18.62 to 16.18.63.</h3>
:information_source: Keep your dependencies up-to-date. This makes it
easier to fix existing vulnerabilities and to more quickly identify and
fix newly disclosed vulnerabilities when they affect your project.
<hr/>
- The recommended version is **1 version** ahead of your current
version.
- The recommended version was released **22 days ago**, on 2023-11-21.
<details>
<summary><b>Release notes</b></summary>
<br/>
<details>
<summary>Package name: <b>@types/node</b></summary>
<ul>
<li>
<b>16.18.63</b> - 2023-11-21
</li>
<li>
<b>16.18.62</b> - 2023-11-18
</li>
</ul>
from <a
href="https://snyk.io/redirect/github/DefinitelyTyped/DefinitelyTyped/releases">@types/node
GitHub release notes</a>
</details>
</details>
<hr/>
**Note:** *You are seeing this because you or someone else with access
to this repository has authorized Snyk to open upgrade PRs.*
For more information: <img
src="https://api.segment.io/v1/pixel/track?data=eyJ3cml0ZUtleSI6InJyWmxZcEdHY2RyTHZsb0lYd0dUcVg4WkFRTnNCOUEwIiwiYW5vbnltb3VzSWQiOiI0NmJkMTg5Yy02MDg5LTRlNTQtOTZmMC0yOTFlNzZlY2ZkMzkiLCJldmVudCI6IlBSIHZpZXdlZCIsInByb3BlcnRpZXMiOnsicHJJZCI6IjQ2YmQxODljLTYwODktNGU1NC05NmYwLTI5MWU3NmVjZmQzOSJ9fQ=="
width="0" height="0"/>
🧐 [View latest project
report](https://app.snyk.io/org/ecp88/project/98480bdc-d80b-4fd1-89d7-c4c56a706763?utm_source=github&utm_medium=referral&page=upgrade-pr)
🛠 [Adjust upgrade PR
settings](https://app.snyk.io/org/ecp88/project/98480bdc-d80b-4fd1-89d7-c4c56a706763/settings/integration?utm_source=github&utm_medium=referral&page=upgrade-pr)
🔕 [Ignore this dependency or unsubscribe from future upgrade
PRs](https://app.snyk.io/org/ecp88/project/98480bdc-d80b-4fd1-89d7-c4c56a706763/settings/integration?pkg=@types/node&utm_source=github&utm_medium=referral&page=upgrade-pr#auto-dep-upgrades)
<!---
(snyk:metadata:{"prId":"46bd189c-6089-4e54-96f0-291e76ecfd39","prPublicId":"46bd189c-6089-4e54-96f0-291e76ecfd39","dependencies":[{"name":"@types/node","from":"16.18.62","to":"16.18.63"}],"packageManager":"npm","type":"auto","projectUrl":"https://app.snyk.io/org/ecp88/project/98480bdc-d80b-4fd1-89d7-c4c56a706763?utm_source=github&utm_medium=referral&page=upgrade-pr","projectPublicId":"98480bdc-d80b-4fd1-89d7-c4c56a706763","env":"prod","prType":"upgrade","vulns":[],"issuesToFix":[],"upgrade":[],"upgradeInfo":{"versionsDiff":1,"publishedDate":"2023-11-21T01:32:12.982Z"},"templateVariants":[],"hasFixes":false,"isMajorUpgrade":false,"isBreakingChange":false,"priorityScoreList":[]})
--->
Co-authored-by: snyk-bot <[email protected]>
Co-authored-by: nikurt <[email protected]>
* refactor: various cleanups and fixes in `chain.rs` (#10327)
get_state_response_part():
- remove the contiguous shard_ids assumption. Instead of checking the
shard id against the number of chunks, look up the list of shard ids
instead.
- since the epoch id is remains the same for the current and the prev
block, the set of shard ids should also remain the same so we only need
to do the check once.
- remove some unnecessary clones
- finally rename some variables to make them shorter. Mainly remove the
`sync_` prefix. I am not sure how much value this prefix is adding and
the shorter variables are still conveying the same amount of
information.
compute_state_response_header():
- Similar to above, remove the contiguous shard_ids assumption.
- Remove some unnecessary clones and dereferences
save_receipt_id_to_shard_id_for_block():
- there is a potential bug in the function where if encounter an error
in middle of iteration, we do not roll back the changes. Hence, pre
compute the list of hashmaps before saving receipts.
- Take a list of shard ids instead of num_shards to remove the
contiguous shard ids assumption
* Remove a scary warning from GCS State Sync (#10329)
* [Snyk] Upgrade @types/react-dom from 18.2.16 to 18.2.17 (#10332)
<p>This PR was automatically created by Snyk using the credentials of a
real user.</p><br /><h3>Snyk has created this PR to upgrade
@types/react-dom from 18.2.16 to 18.2.17.</h3>
:information_source: Keep your dependencies up-to-date. This makes it
easier to fix existing vulnerabilities and to more quickly identify and
fix newly disclosed vulnerabilities when they affect your project.
<hr/>
- The recommended version is **1 version** ahead of your current
version.
- The recommended version was released **22 days ago**, on 2023-11-22.
<details>
<summary><b>Release notes</b></summary>
<br/>
<details>
<summary>Package name: <b>@types/react-dom</b></summary>
<ul>
<li>
<b>18.2.17</b> - 2023-11-22
</li>
<li>
<b>18.2.16</b> - 2023-11-21
</li>
</ul>
from <a
href="https://snyk.io/redirect/github/DefinitelyTyped/DefinitelyTyped/releases">@types/react-dom
GitHub release notes</a>
</details>
</details>
<hr/>
**Note:** *You are seeing this because you or someone else with access
to this repository has authorized Snyk to open upgrade PRs.*
For more information: <img
src="https://api.segment.io/v1/pixel/track?data=eyJ3cml0ZUtleSI6InJyWmxZcEdHY2RyTHZsb0lYd0dUcVg4WkFRTnNCOUEwIiwiYW5vbnltb3VzSWQiOiI3MTZkNzFlYS01ZDExLTRjYTAtYjA1NS05YzMzZjdlMDVlODUiLCJldmVudCI6IlBSIHZpZXdlZCIsInByb3BlcnRpZXMiOnsicHJJZCI6IjcxNmQ3MWVhLTVkMTEtNGNhMC1iMDU1LTljMzNmN2UwNWU4NSJ9fQ=="
width="0" height="0"/>
🧐 [View latest project
report](https://app.snyk.io/org/ecp88/project/98480bdc-d80b-4fd1-89d7-c4c56a706763?utm_source=github&utm_medium=referral&page=upgrade-pr)
🛠 [Adjust upgrade PR
settings](https://app.snyk.io/org/ecp88/project/98480bdc-d80b-4fd1-89d7-c4c56a706763/settings/integration?utm_source=github&utm_medium=referral&page=upgrade-pr)
🔕 [Ignore this dependency or unsubscribe from future upgrade
PRs](https://app.snyk.io/org/ecp88/project/98480bdc-d80b-4fd1-89d7-c4c56a706763/settings/integration?pkg=@types/react-dom&utm_source=github&utm_medium=referral&page=upgrade-pr#auto-dep-upgrades)
<!---
(snyk:metadata:{"prId":"716d71ea-5d11-4ca0-b055-9c33f7e05e85","prPublicId":"716d71ea-5d11-4ca0-b055-9c33f7e05e85","dependencies":[{"name":"@types/react-dom","from":"18.2.16","to":"18.2.17"}],"packageManager":"npm","type":"auto","projectUrl":"https://app.snyk.io/org/ecp88/project/98480bdc-d80b-4fd1-89d7-c4c56a706763?utm_source=github&utm_medium=referral&page=upgrade-pr","projectPublicId":"98480bdc-d80b-4fd1-89d7-c4c56a706763","env":"prod","prType":"upgrade","vulns":[],"issuesToFix":[],"upgrade":[],"upgradeInfo":{"versionsDiff":1,"publishedDate":"2023-11-22T00:59:09.852Z"},"templateVariants":[],"hasFixes":false,"isMajorUpgrade":false,"isBreakingChange":false,"priorityScoreList":[]})
--->
Co-authored-by: snyk-bot <[email protected]>
* [Snyk] Upgrade react-router-dom from 6.19.0 to 6.20.0 (#10331)
<p>This PR was automatically created by Snyk using the credentials of a
real user.</p><br /><h3>Snyk has created this PR to upgrade
react-router-dom from 6.19.0 to 6.20.0.</h3>
:information_source: Keep your dependencies up-to-date. This makes it
easier to fix existing vulnerabilities and to more quickly identify and
fix newly disclosed vulnerabilities when they affect your project.
<hr/>
- The recommended version is **2 versions** ahead of your current
version.
- The recommended version was released **21 days ago**, on 2023-11-22.
<details>
<summary><b>Release notes</b></summary>
<br/>
<details>
<summary>Package name: <b>react-router-dom</b></summary>
<ul>
<li>
<b>6.20.0</b> - <a
href="https://snyk.io/redirect/github/remix-run/react-router/releases/tag/react-router-native%406.20.0">2023-11-22</a></br><p>[email protected]</p>
</li>
<li>
<b>6.20.0-pre.0</b> - 2023-11-21
</li>
<li>
<b>6.19.0</b> - 2023-11-16
</li>
</ul>
from <a
href="https://snyk.io/redirect/github/remix-run/react-router/releases">react-router-dom
GitHub release notes</a>
</details>
</details>
<details>
<summary><b>Commit messages</b></summary>
</br>
<details>
<summary>Package name: <b>react-router-dom</b></summary>
<ul>
<li><a
href="https://snyk.io/redirect/github/remix-run/react-router/commit/3cc38eac4753702a9a8a1fe239e2138d63ac6cc5">3cc38ea</a>
chore: Update version for release (#11050)</li>
<li><a
href="https://snyk.io/redirect/github/remix-run/react-router/commit/77862f95f71397d92b8b583a16674c56efccc55f">77862f9</a>
Exit prerelease mode</li>
<li><a
href="https://snyk.io/redirect/github/remix-run/react-router/commit/1621319ffa353bf33f33064d7611859df16286ee">1621319</a>
Update Release Notes TOC</li>
<li><a
href="https://snyk.io/redirect/github/remix-run/react-router/commit/f1f8ed0acffb3d6c2860c362fc2b376dbf87df24">f1f8ed0</a>
Update release notes</li>
<li><a
href="https://snyk.io/redirect/github/remix-run/react-router/commit/1e026b6f1ac34a774b4f77e5e3696251e8f79940">1e026b6</a>
chore: Update version for release (pre) (#11047)</li>
<li><a
href="https://snyk.io/redirect/github/remix-run/react-router/commit/4a08d64c368c07816e753632345a13b8da050111">4a08d64</a>
Enter prerelease mode</li>
<li><a
href="https://snyk.io/redirect/github/remix-run/react-router/commit/c0b4e12d12c5abdf5f7723e71959c4eb5e9effd9">c0b4e12</a>
Merge branch 'main' into release-next</li>
<li><a
href="https://snyk.io/redirect/github/remix-run/react-router/commit/58d421fc4c592661a68dea59edc507fc4668ba5d">58d421f</a>
Fix other code paths for resolveTo from a splat route (#11045)</li>
<li><a
href="https://snyk.io/redirect/github/remix-run/react-router/commit/5f530a775cd266940f725894277b6ea7bc55b5d0">5f530a7</a>
Do not revalidate unmounted fetchers when v7_persistFetcher is enabled
(#11044)</li>
<li><a
href="https://snyk.io/redirect/github/remix-run/react-router/commit/f320378b5145f59bb266a35a7655b563f712daef">f320378</a>
Add additional test case for #10983</li>
<li><a
href="https://snyk.io/redirect/github/remix-run/react-router/commit/a48c43c8118bbf75b23b3ee748648bb3ee4d688e">a48c43c</a>
feat: export `PathParam` type (#10719)</li>
<li><a
href="https://snyk.io/redirect/github/remix-run/react-router/commit/1d56e55d3f95730f99617dff23cf153f82394921">1d56e55</a>
Remove tag links from headings in CHANGELOG.md</li>
<li><a
href="https://snyk.io/redirect/github/remix-run/react-router/commit/3b1a7364c730209b4baed9454c7f6c17c55e3ba8">3b1a736</a>
Fix flaky test</li>
<li><a
href="https://snyk.io/redirect/github/remix-run/react-router/commit/406a1ddecd399ede2a517d7cae5f3ee63d02ed91">406a1dd</a>
Merge branch 'release-next' into dev</li>
<li><a
href="https://snyk.io/redirect/github/remix-run/react-router/commit/6a5939b07c06c9dacd82705645dbbbe46de90e5e">6a5939b</a>
Merge branch 'release-next'</li>
</ul>
<a
href="https://snyk.io/redirect/github/remix-run/react-router/compare/dcf0c2a85aac3a78059a287ea478ff12adcb6a2d...3cc38eac4753702a9a8a1fe239e2138d63ac6cc5">Compare</a>
</details>
</details>
<hr/>
**Note:** *You are seeing this because you or someone else with access
to this repository has authorized Snyk to open upgrade PRs.*
For more information: <img
src="https://api.segment.io/v1/pixel/track?data=eyJ3cml0ZUtleSI6InJyWmxZcEdHY2RyTHZsb0lYd0dUcVg4WkFRTnNCOUEwIiwiYW5vbnltb3VzSWQiOiIyZmI3YjkxYi0zN2NiLTQzYzgtOWNkYS02ODAzNTFmYzMwNmQiLCJldmVudCI6IlBSIHZpZXdlZCIsInByb3BlcnRpZXMiOnsicHJJZCI6IjJmYjdiOTFiLTM3Y2ItNDNjOC05Y2RhLTY4MDM1MWZjMzA2ZCJ9fQ=="
width="0" height="0"/>
🧐 [View latest project
report](https://app.snyk.io/org/ecp88/project/98480bdc-d80b-4fd1-89d7-c4c56a706763?utm_source=github&utm_medium=referral&page=upgrade-pr)
🛠 [Adjust upgrade PR
settings](https://app.snyk.io/org/ecp88/project/98480bdc-d80b-4fd1-89d7-c4c56a706763/settings/integration?utm_source=github&utm_medium=referral&page=upgrade-pr)
🔕 [Ignore this dependency or unsubscribe from future upgrade
PRs](https://app.snyk.io/org/ecp88/project/98480bdc-d80b-4fd1-89d7-c4c56a706763/settings/integration?pkg=react-router-dom&utm_source=github&utm_medium=referral&page=upgrade-pr#auto-dep-upgrades)
<!---
(snyk:metadata:{"prId":"2fb7b91b-37cb-43c8-9cda-680351fc306d","prPublicId":"2fb7b91b-37cb-43c8-9cda-680351fc306d","dependencies":[{"name":"react-router-dom","from":"6.19.0","to":"6.20.0"}],"packageManager":"npm","type":"auto","projectUrl":"https://app.snyk.io/org/ecp88/project/98480bdc-d80b-4fd1-89d7-c4c56a706763?utm_source=github&utm_medium=referral&page=upgrade-pr","projectPublicId":"98480bdc-d80b-4fd1-89d7-c4c56a706763","env":"prod","prType":"upgrade","vulns":[],"issuesToFix":[],"upgrade":[],"upgradeInfo":{"versionsDiff":2,"publishedDate":"2023-11-22T16:56:32.720Z"},"templateVariants":[],"hasFixes":false,"isMajorUpgrade":false,"isBreakingChange":false,"priorityScoreList":[]})
--->
Co-authored-by: snyk-bot <[email protected]>
Co-authored-by: nikurt <[email protected]>
* feat(resharding): making resharding interruptible (#10328)
Currently ctrl-c doesn't fully stop neard while it's in the middle of
resharding.
Adding StateSplitHandle that allows for stopping resharding in the
`build_state_for_split_shards` method.
to be tested in mocknet soon
* bump shared crates version to 0.18, as released on the 1.36.1 branch (#10336)
* better wording for workflow option (#10337)
* fix: remove potential flakiness from a snapshot_hosts test (#10317)
The test `snapshot_hosts::invalid_signature_not_broadcast` sends out a
message containing three instances of `SnapshotHostInfo`, one of which
has an invalid signature, and then verifies that this message is
rejected.
There is a subtelty here that I didn't take into account when I wrote
this test. When the `PeerManager` receives a message with multiple
`SnapshotHostInfos`, it can accept the valid instances, even in the case
where there are other invalid instances in the message. Because of this
the test could fail - `PeerManager` could accept `ok_info_a` or
`ok_info_b` and then the final assert would fail. Whether it accepts
them or not depends on the timing, as the instances are processed on
multiple threads and the processing stops at the first invalid instance.
Because of that the test could be flaky.
Let's fix it by filtering out `ok_info_a` and `ok_info_b` in the final
check. This way even if the `PeerManager` accepts them, it won't break
the test. The code is the same as in
`snapshot_hosts::too_many_shards_not_broadcast()`.
* Implement simple state witness distribution, chunk validation, and chunk approval distribution skeletons. (#10287)
This is a pretty rough PR, but I'm making an attempt to concretely
implement the flow from distributing the state witness to sending the
chunk endorsement. The following is left out: (1) production of the
state witness; (2) actual validation logic; (3) receiving the chunk
endorsement. However, the skeleton of the flow is there, including
multithreading of the validation logic.
Very open to comments.
* nit: remove unnecessary `?` and `return`s in chain.rs (#10340)
* init project
* Wallet Contract placeholder (#10269)
## Context
NEP: https://github.com/near/NEPs/issues/518
Tracking issue: https://github.com/near/nearcore/issues/10018.
### Goal
We want the NEAR Protocol's ecosystem to be closer with Ethereum by
integrating Web3 wallet support.
To accomplish that, some changes on the protocol level are needed with
an emphasis on user experience continuity.
Following the design, the main change on the protocol level would be to
have ETH-style addresses managed by a new `Wallet Contract` integrated
into the protocol. For seamless onboarding of EVM users, the contract
will be free of charge.
### Previous work
This PR is built on top of two PRs:
* https://github.com/near/nearcore/pull/10020: no-op PR, laying
groundwork for further changes.
* https://github.com/near/nearcore/pull/10224: empty contract as a
placeholder, literally deployed to new ETH accounts.
## Summary
This PR adds `near-wallet-contract` crate (based on
`runtime/near-test-contracts`) that exposes `Wallet Contract` WASM code
to the runtime.
It stops deploying a copy of the `Wallet Contract` to each newly created
ETH-implicit account.
Instead, it uses an in-memory cached contract code on
`execute_function_call` action from such account.
### Changes
- Add `wallet-contract` crate (separated from the workspace) with
placeholder `Wallet Contract` implementation.
- Add `near-wallet-contract` crate (part of the workspace) that
generates (through `build.rs`) and exposes the `Wallet Contract` WASM
code.
- Do not literally deploy `Wallet Contract` when creating ETH-implicit
account. Just store reference to the `Wallet Contract`.
- Treat ETH-implicit accounts specially when retrieving contract code
from an account (in such case returns in-memory cached `Wallet Contract`
code).
- Add tests calling `Wallet Contract` where a transfer from an
ETH-implicit account is possible depending on the public key passed with
`rlp_transa…
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.
NEP Status (Updated by NEP Moderators)
Status: Approved
Meeting Recording:
https://bit.ly/483Wo6X
SME reviews:
Protocol Work Group voting indications (❔ | 👍 | 👎 ):