How is a block generated on MultiVAC?

Image for post
Image for post

Do you want to know when will the genesis block be generated and how will the continuous blocks be born? Let’s figure it out together.

Step 1: The main thread receives the block header, notifies each shard, and initiates consensus

For details on where the main thread receives the block header, see step 6 and step 7b.

This step is the internal communication of the node.
The main thread transfers the block header to each shard’s thread.
Each shard’s thread checks whether the block header belongs to its shard.
If yes, send the block header to consensus and abci
If no, send the block header to abci
The consensus logic decides whether to participate in the next round of consensus through the block header.

The corresponding data types are the block header and block. Calling the API in the node does not require a special message type.

abci interface:
func OnNewMessage(msg wire.Message)

consensus interface
func OnNewMessage(msg wire.Message)

Step 2: Consensus uses abci to generate new blocks

This step is the internal communication of the node, and the consensus logic directly calls the abci API to generate a new block.

abci interface:
In the first version, there was only one synchronous interface, ProposeBlock(). If abci does not have enough transactions, an empty block is returned.
In the improved version, change to the asynchronous interface, AsyncProposeBlock() with timeout, abci tries to get the transaction as many as possible, use ProposeBlockImmediately() to generate a block immediately when timeout.
Note: The interface of the improved version may change

Note that the blocks generated by abci do not contain consensus-related information which is added and checked by consensus logic.

Step 3: Potential leader broadcasts unconsensus blocks to nodes in the same shard

This step is the communication between the various consensus logics of the network within a shard. Message definition:

type LeaderProposalMessage struct {    ShardIndex         ShardIndex    Round              int    Timestamp          time.Time    ValidatorPublicKey []byte    Signature          []byte    Seed               []byte    Block              *MsgBlock}

It is completely determined by consensus logic, and each group can modify it according to its own needs.

Step 4a: Consensus uses abci to verify the block

This step is the internal communication of the node, and the consensus logic directly calls the abci API to verify the new block

abci’s API is
VerifyBlock(block *wire.MsgBlock) error

Note: abci only verifies transactions and ledgers. The data related to the consensus in the block cannot be verified, and the consensus logic needs to be verified by itself.

Step 4b: GC and BA

This step is the communication between the various consensus logics of the network within a shard. The specific message is determined by consensus logic.

Step 5: The consensus logic sends the block to this shard abci

This step is the internal communication of the node. The consensus logic directly calls abci’s API to notify abci of a new block that has reached consensus.

The API of abci is:
AcceptBlock(block *wire.MsgBlock) error

Note: When the data broadcast on the whole network is changed from block to block header, this is the only channel for abci to obtain the block of this shard.

Step 6: The consensus logic sends the block header to the main thread to notify the entire network

After the consensus logic is completed, the consensus logic holds the blocks and voting information. The consensus logic is responsible for sending the block header and voting information to the main thread and forwarding it to the entire network.

This step is the node internal communication. The main thread provides an interface, and the consensus logic calls the interface to send block headers and votes to the main thread.

Step 7a: The main thread transfers the block header to other shards

Same as step 1.

Step 7b: The main thread sends the block header to other nodes in the entire network

This step is the communication between the main threads of all nodes in the entire network.

In the first version, this step sends the entire block to other nodes in the entire network.
In the improved version, this step only sends the block header to other nodes in the entire network.

For specific message types, see wire.BlockHeader and wire.MsgBlock.

ABOUT MULTIVAC:

MultiVAC is a high-throughput flexible blockchain platform based all-dimensional sharding. It’s a next-generation public blockchain platform built for integration with large-scale decentralized applications (dApps). MultiVAC is developing the first solution in the world characterized by speediness, efficiency, and all-dimensional sharding to expand its capacity in computation, transmission, and storage. It realizes the maximum throughput while maintaining decentralization and without sacrificing security.

Website: https://www.mtv.ac

Onepager: https://www.mtv.ac/assets/file/MultiVAC_OnePager.pdf

Technical Whitepaper: https://www.mtv.ac/assets/file/MultiVAC_Tech_Whitepaper.pdf

Technical Yellowpaper: https://www.mtv.ac/assets/file/MultiVAC_Sharding_Yellowpaper.pdf

Technical Purplepaper: https://www.mtv.ac/assets/file/MultiVAC_Programming_Purplepaper.pdf

Telegram Group 2020: https://t.me/MultiVAC2020

Telegram Channel: https://t.me/MultiVACMTV

Twitter: https://twitter.com/MultiVAC_Global

A High-Throughput and Flexible Blockchain Platform Based on Trusted Sharding Computing

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store