Difference between revisions of "SIP5-Sharding"
| (2 intermediate revisions by the same user not shown) | |||
| Line 7: | Line 7: | ||
The documentation for these changes are in [https://docs.google.com/document/d/17cljhZnAiQTL9yzhZ_INxKx131LUzNs2paP2kCCgljo/edit#heading=h.uosl2b838wbg Book of Snowblossom - Braid] | The documentation for these changes are in [https://docs.google.com/document/d/17cljhZnAiQTL9yzhZ_INxKx131LUzNs2paP2kCCgljo/edit#heading=h.uosl2b838wbg Book of Snowblossom - Braid] | ||
| + | |||
| + | == Voting == | ||
| + | |||
| + | * Passes when 1000 blocks pass containing 25% voting and >50% agreement | ||
| + | * Pools will represent their miners. | ||
| + | * Set in your miner or pool configuration file either | ||
| + | ** <code>vote_yes=5</code> | ||
| + | ** <code>vote_no=5</code> | ||
== Status == | == Status == | ||
| Line 26: | Line 34: | ||
The version 2.0 block syncing uses some new operations that only exist in 2.0 so nodes can only do a full block download from 2.0 nodes. On the plus side, with the new peer information the 2.0 nodes will automatically find each other. So as long as there are a few 2.0 nodes, it will be fine. And the on disk database is compatible so upgrading a node is simply running the new version. | The version 2.0 block syncing uses some new operations that only exist in 2.0 so nodes can only do a full block download from 2.0 nodes. On the plus side, with the new peer information the 2.0 nodes will automatically find each other. So as long as there are a few 2.0 nodes, it will be fine. And the on disk database is compatible so upgrading a node is simply running the new version. | ||
| + | |||
| + | When updating the node and running it for the first time, there is an inplace block summary re-index. This is a one time update and might take as much as an hour. | ||
== Timeline == | == Timeline == | ||
| Line 35: | Line 45: | ||
By the block height that we define, all nodes will need to be updated to snowblossom 2.0 or later to validate blocks. The block header format will switch to version 2 at that point and only version blocks will be valid. | By the block height that we define, all nodes will need to be updated to snowblossom 2.0 or later to validate blocks. The block header format will switch to version 2 at that point and only version blocks will be valid. | ||
| − | Even after shards are triggered, is based on block size average (so is not expected to by any time soon) without an configuration changes each node will just follow all shards so | + | Even after shards are triggered, is based on block size average (so is not expected to by any time soon) without an configuration changes each node will just follow all shards so no changes are required. |
Latest revision as of 17:46, 4 January 2024
Contents
Overview
This proposal is to bring in the changes in the shardo branch. This change includes the following:
- Adding a sharded L1 scaling solution
- Revamp of P2P block synchronization
- Updating version number to 2.0
The documentation for these changes are in Book of Snowblossom - Braid
Voting
- Passes when 1000 blocks pass containing 25% voting and >50% agreement
- Pools will represent their miners.
- Set in your miner or pool configuration file either
vote_yes=5vote_no=5
Status
These changes have been in testnet and various smaller scale networks for months. It seems to be very stable.
- Testnet - https://test-b.snowblossom.org/ https://test-b.snowblossom.org/static/shard-visual.html
- Shardtest - https://snow-testshard.1209k.com/ https://snow-testshard.1209k.com/static/shard-visual.html
Both of those networks upgraded from a single shard to multiple shards based on load as expected.
Things Not Complete
After the update, then after enough load to trigger shard creation then clients may need to connect to multiple nodes to get a full view of the network. This code is not yet complete.
Also, there are some improvements that need to be made to the explorer to show reasonable summary of all the shard status.
Risks
The version 2.0 block syncing uses some new operations that only exist in 2.0 so nodes can only do a full block download from 2.0 nodes. On the plus side, with the new peer information the 2.0 nodes will automatically find each other. So as long as there are a few 2.0 nodes, it will be fine. And the on disk database is compatible so upgrading a node is simply running the new version.
When updating the node and running it for the first time, there is an inplace block summary re-index. This is a one time update and might take as much as an hour.
Timeline
If approved, the activation height will be set to be about 90 days from the acceptance vote to allow for updates.
Node Operator Required Actions
By the block height that we define, all nodes will need to be updated to snowblossom 2.0 or later to validate blocks. The block header format will switch to version 2 at that point and only version blocks will be valid.
Even after shards are triggered, is based on block size average (so is not expected to by any time soon) without an configuration changes each node will just follow all shards so no changes are required.
