feat: Add a list of the richest addresses

[msbrogli]

No description provided.

[obiyankenobi]

There are 3 main decisions about the behavior of the richest addresses page we have to consider:

1. Will it update on real time? If a new tx changes the list, will it update automatically?

2. Do we have a limited number of addresses on the list (like this - top 100 addresses)? Or should we have pagination and allow the user to go through all addresses (like this)?

3. Only for HTR or should we also have the richest addresses for each token?

In my opinion:

1. No real time updates. It's very unlikely it will happen and I don't think the user has any expectations of this;

2. Have a limited number of addresses. As we're still a new crypto, I'd suggest either 10 or 20 richest addresses.

3. Only HTR, at least the first version. If we later want to have for each token also, I believe we need to have a better separation on the full node about what indexes are mandatory (like TipsIndex) and which ones are optional (eg: WalletIndex). I don't think most people will want to have support for this kind of index.

[pedroferreira1]

I agree about numbers 1, 2 and 3. No real time updates, only a limited number of addresses (I would go with 20) and only HTR for now. Each token owner can create their richest addresses of their tokens if they want.

[msbrogli]

1. I think we can quickly keep a list of the K richest addresses for a given token because we already have the transactions grouped by address, more precisely O(1) on time. It would also consume O(K) of memory to keep the list in memory. If K=100, it shouldn't be a problem.

2. I agree that we must keep only the first K richest. Maybe we can set K=100, and have at most 5 pages of 20 addresses each.

3. We can add this richest addresses list in the token detail's API. But I agree that we should do it in another issue. It would also increase memory requirements.

In fact, I prefer to keep the list updated on the fly because it is quick and would not consume much memory. Also, running an algorithm that loops through all transactions to update the richest list is O(number of transactions) and gets slower over time.

What do you think?

[obiyankenobi]

@msbrogli I'm still not sure about your idea for the first item. I was asking more regarding the behavior for the end user, not the implementation itself.

As for implementation (on the fullnode), I prefer to keep the list updated as new txs arrive. When the user makes the request, it'll be ready. That's also what you said, right?

[msbrogli]

@obiyankenobi Oh! I think I got it now. You're talking whether we should update the statistics on real time on the client, right? I agree that it is not important.

Exactly. Keep a list updated as new txs arrive.