TIP-772: SRs produce blocks strictly in descending order of votes at the beginning of epoch

[317787106]

tip: 772
title: SRs produce blocks strictly in descending order of votes at the beginning of epoch
author: 317787106@qq.com
discussions-to: https://github.com/tronprotocol/tips/issues/xxx
status: Draft
type: Standards Track 
category: Core
created: 2025-06-20

Simple Summary

At present, in the first round of block production cycle of each epoch, TRON produces blocks in descending order of the number of votes of super representatives(SRs), but it does not start from the SR with the highest number of votes, which has a certain degree of uncertainty. This also leads to SRs with higher voting rankings receiving fewer block production rewards, affecting fairness.

In order to solve this problem, this tip proposes an optimized block production sorting scheme: in each epoch, the block production order of SRs is strictly executed in a cycle according to the voting ranking. This scheme not only optimizes the developer experience, but also adheres to the core principle of "the more votes, the higher the block production income" on the basis of fairness, so as to improve the rationality of the reward mechanism.

Motivation

Related concept definitions

• epoch: refers to the interval between two maintenance periods, during which the network performs block generation and voting.
• slot (also called relative slot): The theoretical block number in the current epoch, starting from 0 and increasing. slots are strictly advanced at fixed time intervals. Each slot may correspond to a block, or there may be "block miss" (that is, no block is generated in this slot).
• absolute_slot: The integer value obtained by subtracting the genesis block timestamp from the current timestamp and dividing it by the block interval.

Current block order description

Currently, the order of blocks within an epoch is not completely determined by the ranking of the number of votes of the super representatives (SRs) in the previous epoch (in reverse order). The specific rules for selecting block producers (SRs) are as follows:

• First block: subtract 2 from the absolute_slot corresponding to the current time, and then calculate it modulo the total number of active SRs (27). That is, index = (absolute_slot - 2) % 27
• Subsequent blocks: calculate by taking the absolute_slot modulo 27: index = absolute_slot % 27

Therefore, in the case of no block missing, two SRs are skipped between the SR of the first block and the SR of the second block, that is, two slots of the maintenance period. Starting from the second block, the order of blocks is restored to linear increase.

Example of actual block generation order

Take a certain epoch of the main network as an example:

• First block: the height is 72779676, the block time is 2025-06-04 00:00:09 (UTC), the block SR is TJBtdYunmQkeK5KninwgcjuK1RPDhyUWBZ, and the SR voting ranking is 11th.
• Second block: the height is 72779677, the block time is 2025-06-04 00:00:12 (UTC), the block SR is TMafrJCuNoYq3mg9dDThfg7c9VP6enZN6j, and the SR voting ranking is 14th.
• Subsequent blocks: The block SR rankings are 15 → 16 → … → 27 → 1 → 2 …, forming a rotation cycle.

Distribution analysis of the first block SR

Assume that the current epoch is the n+1 th epoch and it is in the first slot of the current epoch. The maintenance period is MAINTENANCE_TIME_INTERVAL = 6 * 3600 = 21600 seconds, and the block interval is 3 seconds. The absolute_slot calculation formula at this time is: absolute_slot = n * (21600 / 3) + 3 = 7200n + 3. The block SR index number of the first block is: index = (7200n + 3 - 2) % 27 = (7200n + 1) % 27 = 9*(800n%3) +1. That is, it can only take values ​​of 1, 10, and 19, corresponding to the SRs ranked 2nd, 11th, and 20th in the voting. Therefore, the probability that the block SR of the first block of each epoch falls into the above three rankings is 1/3.

Further calculations show that SRs ranked 3rd, 4th, 12th, 13th, 21st, and 22nd have the worst chances of producing blocks, with only a 1/3 probability of producing one more block than other SRs, while other SRs have a 2/3 probability of obtaining more block production opportunities.

Problems

The current block generation mechanism has the following two problems:

1. The order of block generation SR is difficult to predict: The block generation rules are complicated, which increases the user's understanding cost and affects the experience.

2. The voting ranking does not match the block generation reward: some SRs with lower votes may get more block generation opportunities in an epoch, resulting in a mismatch between reward distribution and voting weight.

Specification

In order to solve the problem of inconsistency between the current block production order and the SR voting ranking, we propose the following improvement plan:

1. Add a new field to record the timestamp corresponding to the first slot of each epoch

Add a new field FIRST_SLOT_TIME in DynamicStore to record the time corresponding to the first slot of each epoch. It is only written during the maintenance period, which is the current block_time plus (MAINTENANCE_SKIP_SLOTS + 1) * BLOCK_PRODUCED_INTERVAL.

2. Special treatment of the first block after the genesis block

Since it is impossible to accurately determine which node sets block.needSyncCheck = false for the first block after the genesis block, we allow the block to be produced by any SR without mandatory constraints.

3. Block generation rules for the first slot of each epoch

The first slot of each epoch must be generated by the SR ranked first in the vote (i.e. the SR with the most votes). If a block is missing in the slot, the right to generate blocks will be deferred to the next SR, and so on, until an SR successfully generates blocks.

4. Calculation rules for block producers of subsequent slots.

For subsequent slots, the selection of the block SR is carried out according to the following rules:

• Calculate the difference Δslot between the current slot and the slot corresponding to the last produced block (actually exists already);

• Get the current slot = (latest_block_header_timestamp - FIRST_SLOT_TIME) /BLOCK_PRODUCED_INTERVAL + Δslot;

• Get the index of the block SR index = slot % active_witness_size.

5. Fix the mixed use of slot and Δslot

Some functions in the current code confuse slot with Δslot. We will sort out and correct these functions to ensure consistent calculation logic and accurate semantics.

Rationale

If the SR corresponding to the last slot of last epoch doesn’t miss blocks, FIRST_SLOT_TIME is the start time of maintenance period + (MAINTENANCE_SKIP_SLOTS + 1) * BLOCK_PRODUCED_INTERVAL. If this SR miss block, it can't enter the maintenance period until the next slot produces blocks (block_time). At this time, FIRST_SLOT_TIME is be postponed, so it is defined as block_time + (MAINTENANCE_SKIP_SLOTS + 1) * BLOCK_PRODUCED_INTERVAL to adapt to this change.

The first block after the genesis block is not produced strictly according to the SR voting ranking. The genesis block is specified by the configuration file, not produced by any SR. When the network starts from the genesis block (number 0), If and only if one node is allowed to set block.needSyncCheck = false to start and wait for the initial block production process. This node is not forced to be the SR with the most votes, so the first slot (block number 1) is not necessarily produced by the SR with the most votes, and it is impossible to ensure that the order of block production strictly corresponds to the ranking. After this block (number 1) is produced, the maintenance period will immediately begin, and the block production of subsequent epochs (starting from block number 2) will be strictly executed according to the voting ranking order of the SR.

Backwards Compatibility

Since this solution introduces a new block generation order logic that is incompatible with the existing block generation mechanism, a new network parameter needs to be added to switch between the old and new rules. At the same time, an on-chain proposal must be initiated through the community governance process to officially enable the change.

[barbatos2011]

This is a great proposal — it ensures that SRs’ reward order aligns with their vote ranking, which also makes it easier to explore further optimizations related to SR block production order.

[lxcmyf]

@317787106
I have a few concerns, high vote SR ranking higher means they:

• More likely to be selected as the first few blocks of the new round, prioritized for trading, theoretically making more money (such as transaction fees).

• Causing newly added SRs to always block at the end, making it easy for them to be unable to block due to "jumping blocks".

• May lead to an increased tendency towards centralization: the higher the number of votes, the more blocks it represents, and the more it can maintain its voting advantage, forming the Matthew effect.

[waynercheung]

@317787106 Hi, regarding Tron's DPoS, the focus might be more on fairness among witnesses. For example, the top 27 SR nodes produce blocks and receive block production rewards, while the top 127 witnesses receive incentive rewards.
For the top 27 SRs, producing blocks in turn provides a near-equitable opportunity and reward distribution. Could this TIP affect that fairness?

Additionally, modifying the block production order logic carries significant impact and requires thorough testing to avoid introducing bugs.

[King31T]

Good proposal，It can make the blocks production fair. Fairness is important to SRs, It can incentivize SRs to secure more votes for achieving higher rankings.

[lvs0075]

Good proposal，It can make the blocks production fair. Fairness is important to SRs, It can incentivize SRs to secure more votes for achieving higher rankings.

If the idea is to incentivise SRs to get more votes, why not use the weight of the vote share to calculate the SR's chances of spawning blocks?

[317787106]

@lvs0075 The main goal is to make the block production rules more transparent and simpler, not a messy one, while maintaining as much fairness as possible. For example, the first slot is 11th and the second slot is 14th. So why? it's complex and incomprehensible.

[lvs0075]

@lvs0075 The main goal is to make the block production rules more transparent and simpler, not a messy one, while maintaining as much fairness as possible. For example, the first slot is 11th and the second slot is 14th. So why? it's complex and incomprehensible.

I think the rules are definitely clear and transparent now and are predictable algorithms; how is that fair? Wouldn't it be fairer to weight them according to the number of votes? Ether's consensus is also complex, why don't they use the simple way!

[King31T]

Good proposal，It can make the blocks production fair. Fairness is important to SRs, It can incentivize SRs to secure more votes for achieving higher rankings.

If the idea is to incentivise SRs to get more votes, why not use the weight of the vote share to calculate the SR's chances of spawning blocks?

If the probability of block production strictly follows the voting ratio, it would soon lead to block production rights being monopolized by the top 3 or even the top 1 SR (Super Representative), which would undermine the meaning of decentralization. The voting ratio can be reflected through TRON's voting rewards, the fairness mentioned here means that an SR with more votes can produce one more block than an SR with fewer votes, because the number of block production slots in each epoch is not an integer multiple of 27.

[317787106]

@lvs0075 I don't think it's clear now. And can you explain the issue why the first slot is 11th and the second slot is 14th? Maybe it's a bug.