Indeed, it will scale indefinitely.

05 Dec 2022, 07:31
Indeed, it will scale indefinitely. Theoretically at least, as practically restrictions such as computing power and consensus algorithm will eventually bottleneck the scalability, although the huge “plus” of the MultiVAC blockchain is the fact that everything was designed to render the computing power as light as possible, and so the bottleneck horizon has been made quite remote (kindly refer to my pinned #l8gendary tweets on the subject). Just to give you here a high-level explanation on the subject, MultiVAC is designed with an incremental shard splitting system, which automatically increases the number of shards when the blockchain senses that a shard becomes overloaded by its flow of transactions. The shard will then be split into two new shards, with each new shard managing half of the original accounts (commonly called “wallet addresses”). In other words, MultiVAC’s sharding splitting is “account address-based”, rather than being based on splitting in two the number of transactions in the original shard. To understand why the splitting is behaving in such a way, first you must understand how accounts are allocated to a shard. As one of the strength of the MultiVAC blockchain is the fact that shards don’t need continuous synchronisation which consumes a lot of computing power (asynchronous sharding), a protection must be put in place to prevent double spending, where the same transaction could be processed and validated blindly by two different shards simultaneously. The trick is quite clever and simple: accounts allocation to a shard are based on the account’s address. For instance, accounts starting with 01 will be allocated to a certain shard. Once the incremental shard splitting occurs, the two new shards will look one character further, and so one new shard will manage 010 accounts, while the other new shard will manage 011 accounts. While shard splitting doesn’t affect the in-shard consensus, the shard’s blocks, the block headers or the Merkle Trees, a couple of mechanisms are still triggered by the shard splitting system: The Light Nodes (nodes that submit new transactions but doesn’t perform any processing) follow the address-based mechanism and are allocated to the new shards accordingly The Miners Nodes (nodes that are running the consensus algorithm) are re-allocated to both shards using the blockchain’s main re-sharding mechanism (a mechanism in which miners are reallocated every few minutes to a new shard to avoid shard corruption) The Storage Nodes that were allocated to the original shard will keep serving the two new shards for a short period of time, to ensure a smooth transition. Once the blockchain has made sure that each new shard has secured enough storage nodes, the original storage nodes are allowed to stop serving one of the new shards, as those new shards are meant to grow, and so they would quickly overload the storage nodes that were serving the two shards I hope you will find this information helpful 😉