Here's this week's technical Q&A content:In MultiVAC, does miner need to save complete blockchain data.

24 May 2022, 12:59
Here's this week's technical Q&A content:In MultiVAC, does miner need to save complete blockchain data? If not, how does a miner validate transactions and produce blocks without complete data? Shawn: Miners do not need to save complete data. We have a very neat design that allows miners to validate transactions and generate new blocks without complete data. In MultiVAC, miners are required to keep track of All block headers; Roots of all shards’ main Merkle trees; Merkle Paths as required to perform updates to the Merkle Roots of all shards. At present, the above data does not exceed 100MB in total. Even with the continuous operation of MultiVAC, we estimate that the future data growth will not exceed 1GB/year. So the data stored by ordinary miner is very small. Only storage nodes are required to be aware of all blocks, comprising all historical transactions. However, they only maintain and update transaction outputs whose accounts are in the shard they are responsible for. For this reason, storage nodes of different shards will have different main Merkle Trees because storage nodes are only responsible for updating the state of transactions in their shard. Once the state is updated, the block hash changes and is propagated up to the Merkle root, resulting in each storage node having recorded the same transactions but updating only the transactions that it is responsible for serving up. Storage nodes may then optionally choose to prune the records of transactions that it is not responsible for. So how does the miner update the block? Recall that miners store not only all block headers but also the Merkle root from all shards and some Merkle paths from all shards as required for bookkeeping. When a miner is a block proposer, he is responsible for producing a block whose header contains two Merkle roots: the root of the attached block Merkle tree and the shard’s new main Merkle root upon addition of the block. Miners must update state changes from newly spent transactions when calculating the new main Merkle root. In addition, Merkle roots of blocks received from other shards must be appended to miners’ local versions of that shard’s Merkle root and Merkle paths in order to stay consistent with the other shards. Finally, the miner’s pending transaction pool consists of Merkle paths generated according to the current Merkle tree. After a new block is confirmed, these Merkle paths need to be updated in order for the system to stay consistent. These comprise a miner’s update tasks in MultiVAC. MultiVAC designs a process allowing miners to update their local state without knowledge of the whole Merkle tree. To do this, the miner requires the following information: The Merkle paths of all inputs spent in a miner’s newly generated block. All roots of block Merkle trees included in block headers received from other shards since the miner’s last update. The right-most Merkle path of each shard’s top main Merkle tree, that is, the Merkle path marking the locations where new blocks should be added in each shard. These provided by the shard’s storage node when the miner first joins the shard. You can find more details in Section 4.3 of the MultiVAC Yellowpaper: mtv.ac/assets/file/MultiVAC_Sharding_Yellowpaper.pdf