Optimization some blockchain sync function #21
Conversation
|
Kudos, SonarCloud Quality Gate passed!
|
| @@ -4004,7 +4005,7 @@ bool verify_network_block(std::vector<std::string> &block_verifiers_database_has | |||
| // check if the blocks reserve bytes hash matches any of the network data nodes | |||
| VERIFY_DATA_HASH(BLOCK_VERIFIERS_TOTAL_AMOUNT,block_verifiers_database_hashes,block_verifier_count); | |||
|
|
|||
| if (block_verifier_count >= BLOCK_VERIFIERS_VALID_AMOUNT) | |||
| if (block_verifier_count >= BLOCK_VERIFIERS_VALID_AMOUNT||(hashesStatus==1&&block_verifier_count>=1)) | |||
There was a problem hiding this comment.
Hi @snakewaypasser
I dont fully understand this
This part is where we need 27+ block verifiers to say "yes the current block you received from some random xcashd (does not have to be in xcash dpops) is the same block we have
But then this code you add, where hashesStatus is 1 and at least 1 block verifier added it. It does not make sense to me because wont this bypass the 27+ DBFT check if just 1 block verifier says yes?
I looked where hashesStatus is set to 1 and its only when passRootRequest>=2
passRootRequest>=2 is run if at least 2 root (DPOPS seed) nodes return a hash response
So to me this would mean if at least 2 root nodes return any response (not necessarily the correct hash) then say yes and add the block to your local chain?
| } | ||
| if(passRootRequest==0){ | ||
| MGINFO_RED("At least need include one root node sign it"); | ||
| if(OPEN_SAFE_VALIDATE==1){ |
There was a problem hiding this comment.
I dont fully understand what OPEN_SAFE_VALIDATE does
It looks to me like your saying "check the response quickly on all nodes, if its a root node see if it responded. If 0 root nodes responded then cancel going any further with verifying this block"?
The seed nodes dont have to be online for the chain to continue so I dont understand this code either?
There was a problem hiding this comment.
If 27+ requests are executed, some requests actually will time out. If the root node is stable, the connection timeout(60s) caused by other node problems can be reduced. Sometimes we will download block data from some random nodes that are different from the root node. Some bad data lead to must download the blockchain reset data.If keep the data consistent with the root node can avoid this.
There was a problem hiding this comment.
Hi @snakewaypasser if you can just explain the messages I have on the code it would be helpful, either in the community chat or here on github
Description
Optimization some blockchain sync function
Fixes 1:Send a large number of requests synchronously.
The get_network_block_database_hash will send many NODE_TO_BLOCK_VERIFIERS_GET_RESERVE_BYTES_DATABASE_HASH function.
By judging whether the root node participates in verification, a large number of unnecessary requests can be reduced, and the speed can be increased by 5 ~10 times.And reduce timeout time to 20 second because every request may block 60 second when some node have problem.With optimization,the request with NODE_TO_BLOCK_VERIFIERS_GET_RESERVE_BYTES_DATABASE_HASH function will be reduced from 30 to 3 when root node is stable.
And also can reduce sync "Your block height is not synced correctly, waiting for the next round to begin" problem from xcashd sync too late.
Fixes 2:Safe hash validate.
The random_network_data_node may connect to a problem node.When add block function also from this node may lead some node got bad hash.If the random node call NODE_TO_NETWORK_DATA_NODES_GET_CURRENT_BLOCK_VERIFIERS_LIST_MESSAGE return some bad ip witch all link to his server.Can pass network verification add bad data to blockchain when node and random_network_data_node all target it.
(Can edit cryptonote_config.h make OPEN_SAFE_VALIDATE to 1 active this validate)