Dynamic Sharding
This section describes the process of dynamic sharding in more detail. To learn more about Venom's network architecture, please have a look at Shardchains.
A common practice in database management is the process of splitting and distributing a database into smaller pieces, known as "shards." Doing so improves efficiency as the database can be distributed across several machines, allowing parallel operations.
Sharding is a scalability solution for decentralized networks allowing the parallel processing of transactions. This is made possible because each shard is organized by its own validator set, allowing validators to simultaneously validate multiple transactions.
Venom's Shardchains are smaller pieces of a blockchain that are solely responsible for a subset of accounts based on a defined range. In the Venom blockchain, the execution of smart contracts is split into smaller threads, called "shards." The shards are then processed in parallel by different validator groups.
Split event
If the number of transactions on a Shardchain causes it to become overloaded, a split event is triggered. The overloaded Shardchain is then divided into two shardchains.
Before a split event occurs, it is announced several blocks in advance. This happens in the headers of the corresponding Shardchain block first. After this, it is announced in the Masterchain block referring to this specific Shardchain block.
The split event is then triggered under the requirement that the Shardchain's blocks are at 90% capacity (or higher) for 100 seconds (which translates into 50 blocks presently).
The announcement ensures that preparations can be made for the planned split. This includes selecting a subset of validators responsible for a defined range of accounts on the new shardchains.
Once the split happens, it is committed into the Shardchain block so that it gets propagated to the Masterchain block. This will result in an update of the network's shard configuration.
The Masterchain block is released approximately one second after the validator group produces the blocks for a Shardchain. Once the block is included in the Masterchain, it is considered to be finalized and immutable.
Merge event
Sibling Shardchains are continuously monitored for their block sizes. In the event that the sum does not exceed 60% of the maximal block size for 100 seconds, a block with a "want merge" flag is produced by validators. The flag tells validators assigned to the Shardchains to merge into one Shardchain.
A "merge commit" flag is then produced, followed by validators stopping to produce blocks in the separate Shardchains. The new state of the merged Shardchain is produced by combining the blocks and transactions from both sibling chains.
The merge event helps the Venom network adjust the number of Shardchains based on the current load. This process helps to reduce computational costs for maintaining Shardchains and increases efficiency in the network.
