TIP-391: Optimize fetch block process

[Vikingzzu]

tip: 391
title: Optimize fetch block process
author: vikingzzu@163.com
discussions-to: https://github.com/tronprotocol/TIPs/issues/391
status: Final
type: Standards Track
category: Networking
created: 2022-03-21

Simple Summary

Optimize fetch block process between nodes

Abstract

During the process of broadcasting a block, sometimes timeouts occur between nodes fetching blocks, nodes will wait until it times out and then go through a P2P sync to fetch the block, the P2P block fetching process will send SyncBlockChainMessage, ChainInventoryMessage, FetchInvDataMessage, BlockMessage to get the block, this process is more time consuming, such a strategy is very inefficient, we should choose a new node to fetch the block, such a solution only needs to send a FetchInvDataMessage to fetch the latest block in the broadcast process, which will save a lot of time.

Motivation

Network fluctuations between nodes can cause block fetch timeouts, use a new strategy to prevent such scenarios from occurring.

Rationale

As a decentralized service, network fluctuations between nodes occur frequently, and network fluctuations can lead to very inefficient block acquisition between nodes, which can lead to a very inefficient service if such scenarios occur frequently, we should use a new strategy to prevent such scenarios from occurring.

Implementation

Add a new class to save fetch block info,

public class FetchBlockService{
  private PeerConnection peer;
  private Sha256Hash hash;
  private long fetchBlockTimeout;
  public void fetchBlock(Sha256Hash sha256Hash, PeerConnection peer){}
  private void reSendFetchTimeOutBlock(){}
  public void blockFetchSuccess(Sha256Hash sha256Hash){}
}

During the process of broadcasting a block, message service calls method fetchBlock of the FetchBlockService to record the current sha256Hash info and peer info.

After fetchBlockTimeout time, FetchBlockService calls method reSendFetchTimeOutBlock to check if it got the block information of sha256Hash, if not then we find a new connection to fetch the block.

When block service receive the block information of sha256Hash, block service calls method blockFetchSuccess of the FetchBlockService to remove the sha256Hash info and peer info, then the block will not be reacquired.

[ethan1844]

Close this issue as it is implemented by GreatVoyage-v4.5.0.
Check TIP detail at TIP-391
Check implementation PR at tronprotocol/java-tron#4326