Deprecate ShardLayout::v0

[Longarithm]

Description

ShardLayout::v0 is responsible for random assignment of accounts to shards. It is incompatible with current and future shard layouts because it makes it impossible to derive range of accounts from boundary accounts.
The first mainnet config was v0. However, there was only one shard, so random assignment wasn't used.
It could be nice to remove all occurrences of v0 from code, including all kinds of tests up to pytests.
But we need to be very careful to preserve compatibility with genesis.

There was assumption in some test that localnet accounts are located on different shards; but this can be handled with v1/v2 as well.

[eagr]

I could only deduce the work to be done from your description here as I’m brand new to NEAR.

---

remove all occurrences of v0 from code

By "deprecate", I suppose you mean to wipe it out instead of to show a deprecation warning about using V0, right?

And I guess some of the occurrences of V0 in the tests should be replaced by V2 (assuming V2 is preferred over V1 now, that right?).

preserve compatibility with genesis

Do you mean something like "new code should work on old data"?
If so, to be backward-compatible, I suppose we need to do some transformation if it’s v0, providing the related code is removed?
Could you expand on that? Not so sure about this.

[wacban]

@eagr

Let's first disambiguate:

• V0 is an old variant of that ShardLayout structure - this is a protocol structure so it likely needs to stay as is in order to preserve serialization and replayability.
• v0 is a method used to create shard layouts using the V0 structure. This method should be removed and replaced with calls to v2.
• I think mainnet genesis contains a V0 layout but it's constructed using deseralization when genesis is read so the v0 method shouldn't be needed.

I can also see that there is v0_single_shard -> perhaps a good first step for you would be to

• rename it to single_shard
• make it use v2 instead of v0
• run tests - I would hope they all pass but if not -> let's discuss

Then later you can find any reference to v0 and try tro replace those with v2.

• This has potential to break things like the implicit assumptions made by some tests that Longarithm mentioned.
• Feel free to debug but if it doesn't work it's ok to leave some as is or ping me and I'll help debugging.

Finally once all references to v0 are gone we can delete it altogether.

Feel free to pick and choose any of the subtasks here.

preserve compatibility with genesis

I think it should be sufficient to keep V0 as is.