tip: 289
title: Block Broadcast Optimization
author: [email protected]
discussions to: https://github.com/tronprotocol/TIPs/issues/289
status: Final
category: Core
created: 2021-07-12
This TIP is to optimize block broadcasting.
The current block processing and broadcasting logic is like this: Verify block → Process block → Broadcast block. The time consumption is mainly in the block processing. Therefore, once this broadcast logic is used, the block delay will be longer. The log below shows that the block delay is close to 2 seconds.
Worse, for example, if the processing of the block takes 1 second, the next SR and the previous SR exceed 2 hops, it will directly lead to a block miss. This article details the optimization of the block broadcasting.
In order to speed up the block broadcast, let the block be broadcast on the whole network in a short time and improve the block miss rate, it is necessary to optimize the block broadcasting.
Modify the processing and broadcast block logic: Verify block → Broadcast block → Process block. As long as the network is unblocked, the block will be broadcasted on the whole network soon, and the block will not be lost.
Reasons for the feasibility of the scheme:
- If there is no witness of cheating, it is completely feasible to broadcast first and then execute.
- If a witness cheats, the result is only one more performance consumption of block execution. Blocks that fail to execute will not be chained, which will not have much impact on the entire system.
The main need to modify the place:
- Processing broadcast block: verify the block, including signature and witness valid verification, broadcast directly after the verification is passed, and then process the block.
- TCP connection: the block verification fails and the connection is disconnected; the block processing fails and the connection cannot be disconnected (currently the connection will be disconnected as long as the processing fails), otherwise a bad block may cause the entire network to be disconnected.