Background

Currently, HTTP/gRPC has an interface /wallet/listwitnesses for querying the number of witness votes in the previous epoch. During the maintenance period, the node calculates the votes of all witnesses and selects the first 27 witnesses as SRs for the next epoch block production. There are the following problems:

1. This interface returns the JSON-format voting results of the previous epoch, which is unchanged in the current epoch, and lacks an interface for real-time query of the number of votes in the current epoch;

2. This interface sorts by the address of the witness instead of the number of votes. Users cannot view the overall ranking and need to sort manually; witnesses cannot easily view their ranking in the previous epoch;

We plan to modify the results of /wallet/listwitnesses, namely return results sorted in descending vote order of the witness; and paln to add a new interface to query all real-time witnesses, also sort them in descending order by the number of votes.

Rationale

Why should this feature exist?

• For ordinary users, they can easily view the historical ranking and real-time ranking of each witness through the API to vote for themselves;

• For witnesses who want to become Super Represent (SR), they urgently need to know their real-time votes and rankings in the current epoch so as to attract votes and enter the top 27; for SRs who have entered the top 27 in the previous epoch, they urgently need to understand their leading advantage over the 28th witness and provide an early warning mechanism to remind them to increase votes and avoid losing.

What are the use-cases?

• Developers, SRs & SR candidates need this feature urgently.

Specification

1. For the existing interface /wallet/listwitnesses for querying the voting results of the previous epoch, the current proto is:

rpc ListWitnesses (EmptyMessage) returns (WitnessList) {...}

Since no parameters can be taken in EmptyMessage, the list of witnesses returned by getWitnessList function is sorted in reverse order by vote count by default; if the vote counts are the same, they are sorted in lexicographical order by witness address.

2. A new interface /wallet/listrealtimewitness is added, which supports HTTP/gRPC and is used to query the real-time vote count of all witnesses in the current epoch. The results are sorted in reverse order by the vote count. If the vote count is the same, they are sorted in lexicographical order of the witness address. In order to avoid too large query results, pagination query is introduced:

rpc ListRealtimeWitness (PaginatedMessage) returns (WitnessList) {
};

In the database, WitnessStore stores the cumulative number of votes cast by users for all witnesses after the last epoch, excluding the votes cast in this epoch; the incremental votes cast in this epoch are stored in VotesStore. The incremental votes may actually be positive or negative, and generally the amount of data is small. By adding up the data of WitnessStore and VotesStore, real-time witness voting data can be calculated.

The above two changes should support both fullnode and solidity related interfaces.

Test Specification

Test conditions include:

1. Is the interface /wallet/listwitnesses in reverse order of votes?
2. Is the interface /wallet/listrealtimewitness in reverse order of votes?
3. Does the real-time interface support dynamic updates after a vote transaction?
4. Is the paging conditions of the real-time interface reasonable and the handling of boundary conditions?
5. Does walletsolidity API also support related real-time queries?
6. Does the QPS of the real-time interface meet the requirements?

Scope Of Impact

This involves changes to the api.proto file, affecting related interfaces including HTTP and gRPC.

Implementation

Do you have ideas regarding the implementation of this feature?
Y

Are you willing to implement this feature?
Y