Difference between revisions of "SIP5-Sharding"

From Snowblossom Wiki
Jump to: navigation, search
Line 34: 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 ==

Revision as of 05:51, 7 February 2022

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=5
    • vote_no=5

Status

These changes have been in testnet and various smaller scale networks for months. It seems to be very stable.

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 not changes are required.