Resharding V3 - added future possibilities #569
Conversation
neps/nep-0568.md
Outdated
| ``` | ||
| * Dynamic Resharding - In this proposal, resharding is scheduled in advance and hardcoded within the neard binary. In the future, we aim to enable the chain to dynamically trigger and execute resharding autonomously, allowing it to adjust capacity automatically based on demand. | ||
| * Shard Merging - In this proposal the only allowed resharding operation is shard splitting. In the future, we aim to enable shard merging, allowing underutilized shards to be combined with neighboring shards. This would allow the chain to free up resources and reallocate them where they are most needed. | ||
| * Instant Resharding - In this proposal, the new shard layout is setup for the next next epoch and it takes a full epoch from the time resharding is scheduled until it takes effect. In the future we aim to make resharding instantneous, that is the time from the decision to perform resharding to the chain switching to the new layout should be minimal. |
There was a problem hiding this comment.
The instant resharding section is slightly misleading.
While reading In the future we aim to make resharding instantneous I thought "resharding operation is already instantaneous" from the point of view of the chain users. It's more about the time of detecting, planning and executing a resharding which is not instantaneous.
It's also unfortunate that we say "instant" in the name and then "time from the decision to perform resharding .. should be minimal", in the sense that minimal is not the same level of coolness as instantaneous :)
Not sure how improve this section. Perhaps we should avoid calling it "Instant Resharding" and switch to something more generic like "Faster chain load rebalancing"?
There was a problem hiding this comment.
updated, have a look please :)
Filling in the future possibilities section - and looking for more ideas :)