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
