Difference between revisions of "SIP5-Sharding"

From Snowblossom Wiki
Jump to: navigation, search
(Created page with "== Overview == This proposal is to bring in the changes in the [https://github.com/snowblossomcoin/snowblossom/tree/shardo shardo] branch. This change includes the following...")
 
Line 19: Line 19:
 
== Things Not Complete ==
 
== 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 ==
 
== 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.
  
 
== Timeline ==
 
== Timeline ==
Line 28: Line 32:
  
 
== Node Operator Required Actions ==
 
== 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.

Revision as of 05:36, 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

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.

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.