Usage of transfer history fetch

[alaibe]

Problem

Calculate the usage of full transfer history fetch

If acceptable for mobile, the on demand strategy can removed

[rasom]

fetching tx history for one of my accounts (which has 550+ tx per etherscan (that excludes incoming ERC20 transfers in most of cases) and something around 50 incoming ERC20) takes 65-85MB of data and more than 7k requests

what is a bit suspicious (although I don't know in details how that works) is that each time I run it i get a different number of eth_TransactionReceipt and eth_FullTransactionByBlockAndIndex (maybe @IvanBelyakoff knows whether that's expected)

[IvanBelyakoff]

@rasom How different are they? Are you using rpcstats.CountCall for that? Did you remove the data from DB each time? Because we don't detele the data if account is removed.

The only thing that comes to my mind irrespective of how this is tested and measured is that every time it is measured new blocks have been generated and history checked intervals are different which may result in slight variations of calls to find the blocks that have ETH transfers. For ERC20 I think that the difference can be even smaller if there is.

[rasom]

@IvanBelyakoff

How different are they?

so I logged three runs so far, I have 367/221, 422/282, 306/247 for eth_TransactionReceipt/eth_FullTransactionByBlockAndIndex

Are you using rpcstats.CountCall for that?

yes

Did you remove the data from DB each time?

I do remove entire multiacc (status account, not wallet account) and from data usage point of view it looks like the database is also removed (or not used after account recovery via phrase), otherwise it would be hard to explain 65-85MB of traffic.

history checked intervals are different which may result in slight variations of calls to find the blocks that have ETH transfers

Yes I'm aware of it, that's why I wrote specifically about calls which counts shouldn't vary per my understanding.

[rasom]

I also just noticed that for that run which had 306/247 there were only 264 eth_BlockByNumber which is likely not enough to scan entire history of that wallet account (500+ transfer and most of them in different blocks), so it looks like that scanning stalls on mobile at some point. I have to figure out what causes this and then rerun tests.

[rasom]

sooo, it stops loading historical data after the first "check recent blocks" request like

t=2023-08-08T14:03:54+0000 lvl=info msg="wallet historical downloader for erc20 transfers start" chainID=1 address=0x2f88d65f3cB52605a54A833ae118fb1363aCccd2 from=17,8 70,678 to=17,870,678 t=2023-08-08T14:03:54+0000 lvl=info msg="iterative downloader" address=0x2..................2 from=17,870,678 to=17,870,678 size=500,000 t=2023-08-08T14:03:54+0000 lvl=info msg="wallet historical downloader for erc20 transfers finished" chainID=1 address=0x2f88d65f3cB52605a54A833ae118fb1363aCccd2 from=1 7,870,678 to=17,870,678 time="378.692µs" headers=0

[IvanBelyakoff]

Yes I'm aware of it, that's why I wrote specifically about calls which counts shouldn't vary per my understanding

Yes, you are right, missed it.

sooo, it stops loading historical data after the first "check recent blocks" request like

But there is only one block to check (to == from). Are you sure this is not just because it was checked. There are 2 concurrent commands going on - checking for history and checking the newest block. From what I see, this is a newest block checked

[IvanBelyakoff]

I also just noticed that for that run which had 306/247 there were only 264 eth_BlockByNumber which is likely not enough to scan entire history of that wallet account (500+ transfer and most of them in different blocks), so it looks like that scanning stalls on mobile at some point. I have to figure out what causes this and then rerun tests.

Roman sorry to hear that. I just realized I never got back this code to write some tests for the new sequential strategy. So that could possibly be a bug if it does not load all the transfers occasionally. I might need to write some tests, especially since you found out that it possibly does not load all the transfers

[rasom]

@IvanBelyakoff I'm still not 100% that this is not due to the way how API is used on mobile side

Do you have some document or maybe you can describe what is the order of calls in order to fetch that entire history? Like I just call wallet_checkRecentHistory, or I start with wallet_start, the do wallet_checkRecentHistory and wait, or what exactly should be done?

[IvanBelyakoff]

You don't have control over it for this strategy. Once you add the account, downloader should fetch all the history (well, for now it is not true, it will fetch to the block when the first eth transfer happened, and stop even for ERC20 - currently by design, to save calls). Once new transfers loaded

• new-transfer event is sent and UI should react and fetch the transfers based on filters set or just all in chunks.. some "getTransferByAddress" should do it - just fetches from db.

Why don't you measure this using desktop app or some test sample?

On Tue, Aug 8, 2023, 16:55 Roman Volosovskyi @.***> wrote:

@IvanBelyakoff https://github.com/IvanBelyakoff I'm still not 100% that this is not due to the way how API is used on mobile side

Do you have some document or maybe you can describe what is the order of calls in order to fetch that entire history? Like I just call wallet-checkRecentHistory, or I start with wallet_start, the do wallet-checkRecentHistory and wait, or what exactly should be done?

— Reply to this email directly, view it on GitHub https://github.com/status-im/status-go/issues/3833#issuecomment-1669780446, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADXHGVJIZ2NOEC24XT4A6TTXUJHOHANCNFSM6AAAAAA27PFRPU . You are receiving this because you were mentioned.Message ID: @.***>

[rasom]

@IvanBelyakoff so to clarify

1. I was told that on desktop we do fetch entire history right away (that to be the difference with an old version)
2. I was told to check whether this will be suitable for mobile

Why don't you measure this using desktop app or some test sample?

Because I'm more comfortable with mobile version atm and it shouldn't matter. Why is it better to test it on desktop?

You don't have control over it for this strategy.

What I see is that entire history is not loaded and it took 25 minutes to get to block 5,885,783 (on WIFI). That required 14k+ requests. At the moment I'm a bit puzzled because this algorithm neither actively tries to save RPC calls (because 14k+) nor loads entire history. So what's the point here? Or there were some recent changes and I have to update local version of status-go where it works differently?

t=2023-08-09T07:29:00+0000 lvl=info msg="logging initialised" logSettings="{\"Enabled\":true,\"MobileSystem\":false,\"Level\":\"INFO\",\"File\":\"\\/storage\\/emulated\\/0\\/Android\\/data\\/im.status.ethereum.debug\\/files\\/Download\\/geth.log\"}"

t=2023-08-09T07:54:47+0000 lvl=info msg="eth historical downloader finished successfully" chain=1 address=0x2...2 from=5,885,783 to=5,985,783 total blocks=13 time=2.666043385s

[rasom]

@IvanBelyakoff do you still call wallet_checkRecentHistory on desktop?

[rasom]

So what I do:

1. restore an existing account via phrase with WalletConfig.LoadAllTransfers = true to enable that sequential strategy
2. call "wallet_getRecentHistory"
3. on "recent-history-ready" call "wallet_getTransfersByAddress"

What I get:

1. some part of history is fetched right away. It takes 3 to 20+ minutes depending on how lucky I am, and it takes 60-120MB of traffic, 7k to 15k eth_ requests
2. it stops somewhere around block 5,885,760

   t=2023-08-10T17:06:28+0000 lvl=info msg="wallet historical downloader for erc20 transfers finished" chainID=1 address=0x2f88d65f3cB52605a54A833ae118fb1363aCccd2 from=5,885,760 to=5,985,760 time=460.406875ms headers=7

3. On restart it never catches up with older blocks

This is definitely not optimal for a mobile network. Arguably it will be costly in terms of RPC calls eventually, but that depends on number of users we will have.

@IvanBelyakoff would be nice if you could confirm that what I do on the client side is actually expected to be done this way.

[rasom]

And as a note: we had to execute significantly less RPC requests in order to get to the same 5,885,760 block in the older version of the app, it is something around 6k agains 13k (for those specific runs). At least it looks so per RPC usage screen.

old:

new:

[rasom]

hm maybe it is just some issue with wallet_getTransfersByAddress, seems that transfers are loaded but I don't get them from wallet_getTransfersByAddress

upd.: yep I can confirm that it was rather pagination issue and mobile app would stop loading older transactions to the client side, likely there were some changes on backend related to this

[IvanBelyakoff]

Hey @rasom I was trying to reach out a couple of days ago via Status app, but you probably never received my message, and I could not find you on Discord that day, then it slipped my mind sorry.

@IvanBelyakoff do you still call wallet_checkRecentHistory on desktop?

I've checked the code and believe we still do. At least I don't see that something wrong happening if you do that

2. it stops somewhere around block 5,885,760

I believe this is the beginning of ETH history for the account

3. On restart it never catches up with older blocks

If that is indeed the beginning of ETH history, then it wont proceed loading older blocks on restart even for ERC20. We know this is strictly speaking wrong, but on some chains there are 100+ million blocks and with this strategy it is very consuming as for requests to check all that history even in chunks of multiple thousands requests per call (getLogs), and considering that there are several chains, in this sense we do save some calls for now, because in more cases there wont be any ERC20 transfers than will. I've discussed that with @alaibe and @John-44 a while ago and we decided we just stop there for the time being.

So what I do:

1. restore an existing account via phrase with WalletConfig.LoadAllTransfers = true to enable that sequential strategy
2. call "wallet_getRecentHistory"
3. on "recent-history-ready" call "wallet_getTransfersByAddress"

Though I think we don't call getTransfersByAddress now, but we use filtering in activity.go to display transfers, I think the right call we use is getMultiTransactions but for this purpose of measuring, it does not matter. getMultiTransactions will give you even smaller number of transfers of some of them are part of single transactions.

And as a note: we had to execute significantly less RPC requests in order to get to the same 5,885,760 block in the older version of the app, it is something around 6k agains 13k (for those specific runs). At least it looks so per RPC usage screen.

old:

new:

As for the test results, I see that for some reason NonceAt is missing in the old strategy, and there are some calls like FullTransactionByBlockAndNumber which fixes an issue with wrong block hash fetched from header (if I remember correctly) and GetBaseFeeFromBlock - I have no idea now what we use it for, actually, that together make 2 requests more, but I just think that those calls might have not been included in the old strategy and are used for a reason, sothe numbers after the fixes could be more even between new and old.

Do you know why you don't have "NonceAt" call in the list? I remember it should be called to check for transfers within block range

[IvanBelyakoff]

Hey @rasom I was trying to reach out a couple of days ago via Status app, but you probably never received my message, and I could not find you on Discord that day, then it slipped my mind sorry.

@IvanBelyakoff do you still call wallet_checkRecentHistory on desktop?

I've checked the code and believe we still do. At least I don't see that something wrong happening if you do that

2. it stops somewhere around block 5,885,760

I believe this is the beginning of ETH history for the account

3. On restart it never catches up with older blocks

If that is indeed the beginning of ETH history, then it wont proceed loading older blocks on restart even for ERC20. We know this is strictly speaking wrong, but on some chains there are 100+ million blocks and with this strategy it is very consuming as for requests to check all that history even in chunks of multiple thousands requests per call (getLogs), and considering that there are several chains, in this sense we do save some calls for now, because in more cases there wont be any ERC20 transfers than will. I've discussed that with @alaibe and @John-44 a while ago and we decided we just stop there for the time being.

So what I do:

1. restore an existing account via phrase with WalletConfig.LoadAllTransfers = true to enable that sequential strategy
2. call "wallet_getRecentHistory"
3. on "recent-history-ready" call "wallet_getTransfersByAddress"

Though I think we don't call getTransfersByAddress now, but we use filtering in activity.go to display transfers, I think the right call we use is getMultiTransactions but for this purpose of measuring, it does not matter. getMultiTransactions will give you even smaller number of transfers of some of them are part of single transactions.

And as a note: we had to execute significantly less RPC requests in order to get to the same 5,885,760 block in the older version of the app, it is something around 6k agains 13k (for those specific runs). At least it looks so per RPC usage screen.

As for the test results, I see that for some reason NonceAt is missing in the old strategy, and there are some calls like FullTransactionByBlockAndNumber which fixes an issue with wrong block hash fetched from header (if I remember correctly) and GetBaseFeeFromBlock - I have no idea now what we use it for, actually, that together make 2 requests more, but I just think that those calls might have not been included in the old strategy and are used for a reason, sothe numbers after the fixes could be more even between new and old.

Do you know why you don't have "NonceAt" call in the list? I remember it should be called to check for transfers within block range

[rasom]

@IvanBelyakoff

Do you know why you don't have "NonceAt" call in the list? I remember it should be called to check for transfers within block range

on that screen it is eth_getTransactionCount

[rasom]

https://notes.status.im/TSPntaw0SCeV44Z4ENM1sQ?view

[John-44]

https://notes.status.im/TSPntaw0SCeV44Z4ENM1sQ?view

@rasom Thanks for the notes!

@alaibe @rasom @IvanBelyakoff I think the one thing that we DON'T want to do is implement any difference in behaviour when a user is using cellular data. These days, in many locations cellular data is fast and plentiful. Also in many locations wifi is slow. So saying that "cellular data = slow and expensive data", and "wifi data = fast and plentiful data" is incorrect. Yes it is sometimes true, but equally a lot of the time it's not true.

In the future we will be introducing to Status Desktop a bandwidth test on app startup, and we will use the results from this test to configure the various node services for the duration of that session. I haden't considered doing the same on mobile, and it's probably not needed on mobile, but if we really want to make decisions based on a user's available bandwidth the only way to do this in a sufficiently reliable fashion is to actually periodically run a test to check the user's bandwidth.

So we shouldn't do either possible actions 1 or 2 in the screenshot from the notes below:

We need to think of possible solutions that don't factor if a user is connected to wifi or cellular into the decision. Also Status Desktop users can have low bandwidth as well! So the ideal solution works for both Status Desktop and Status Mobile users e.g. we should try do avoid doing anything Mobile specific here.

[rasom]

@John-44 thanks

as I mentioned in the note, the way how we can handle this for transfers history is to have a limit of around 5k RPC requests (arbitrary and it will never be very precise, also the way how we detect that threshold might differ), and stop fetching when that limit is reached. We can also add a timeframe... or just go with an old argo which made an attempt to make as few as possible RPC requests to fetch at least 20 latest transfers (if those exist). But that's technical details.

The point is that we can't guarantee that loading of entire history will go smoothly for all accounts. Thus not all accounts will get a complete history right away and we can't completely get rid of some kind of "on demand strategy". The objective of this issue was to figure out whether we can just ditch it ("on demand strategy").

[alaibe]

@rasom it looks like we cannot just ditch it. But can we hope with all the improvement suggested in the notes to have only one algorightm?

[rasom]

@alaibe, do you mean one instead of "sequential" and "on demand"

As far as I can say the algorithm is identical in both cases (I mean the way how we find transfers in the range of blocks, @IvanBelyakoff please correct me if I'm wrong), the difference is what range is checked and when.

[IvanBelyakoff]

As far as I can say the algorithm is identical in both cases (I mean the way how we find transfers in the range of blocks, @IvanBelyakoff please correct me if I'm wrong), the difference is what range is checked and when.

@rasom you are correct.

@alaibe Do you mean the actions that @rasom suggested - combine new transfers fetching with new balance history and history fetching with hitory balance?

Or anything else in terms of when/what range we check - like do some 5K requests then on demand? I just think that the activity for Desktop that we have developed will often have some banner in this case like "not all history is fetched, data may not be accurate" if we don't fetch all the history data. I don't think that was the goal, though I understand the limitations we have

[rasom]

@IvanBelyakoff

I just think that the activity for Desktop that we have developed will often have some banner in this case like "not all history is fetched, data may not be accurate"

Just as a reminder: majority of account will not have history which will actually require around 5k requests, thus it is very unlikely that it will be seen often. Watch-only accounts is a different thing, but I'm not sure that we have to replace block explorers for those.

[IvanBelyakoff]

@rasom on one hand I do agree with you. On the other, currently we have a "workaround" that we don't check ERC20 further back than the block with first ETH transfer. This is done because we must use some reasonable block range for getLogs call - sometimes this is a limitation of providers like POKT and Infura, but also I think if we take too big ranges, it is split into subranges on each iteration recursively and calls getLogs for that subrange and this can be quite resource hungry - both CPU and mem intensive and cause reaching requests limit per second in hystrix (though we could increase it, but I don't know if that is a good idea) and at provider as well. So we will need to check that with relatively small chunks - several thousand blocks a time and less - if we want to keep searching. AFAIK this workaround is somewhat temporary solution, because some chains have a hundred of millions blocks, so it is very long to check before we can say that all history is loaded. So now when we say that all history is checked, technically, this is not true. And in fact we should notify the users

[rasom]

@IvanBelyakoff

split into subranges on each iteration recursively and calls getLogs for that subrange in old "on demand" startegy we would

1. try to find the range with at least 20 outgoing transfers
2. fetch all ETH transfers in that range
3. Check all logs by making as little as possible getLogs calls (considering we know the limit)

So I mean, I don't really think that there is a point in making getLogs calls recursively, we need to determine the range and just go with it.

As per that 5k limit we can also try to estimate a range for each we will keep it under 5k or whatever we will choose. It will never be very precise, but still having ~50-100 transactions fetched in most cases should be more than enough.

[IvanBelyakoff]

@IvanBelyakoff

split into subranges on each iteration recursively and calls getLogs for that subrange in old "on demand" startegy we would

1. try to find the range with at least 20 outgoing transfers
2. fetch all ETH transfers in that range
3. Check all logs by making as little as possible getLogs calls (considering we know the limit)

So I mean, I don't really think that there is a point in making getLogs calls recursively, we need to determine the range and just go with it.

As per that 5k limit we can also try to estimate a range for each we will keep it under 5k or whatever we will choose. It will never be very precise, but still having ~50-100 transactions fetched in most cases should be more than enough.

you are talking about 20 ETH transfers right in p.1? I am talking about a situation, where we have already found the first ever block for ETH transfers (nonce is 0, balance is 0). So before that block we can't determine the range you are talking about. But there can still be incoming ERC20 transfers. Do I understand it correctly or I miss something?

[rasom]

@IvanBelyakoff oh ok, so the simplest thing we can do for this case:

1. At that point we know which tokens were used by that account
2. We can check whether those had zero balance before the block with the first ETH transfer
3. If we find that some of them are not zero we can do binary search for those specific tokens (by balance, as those are going to be only incoming txs it should be straightforward)

Then we can do getLogs for specific blocks, or well just get those blocks without getLogs. It likely will take less requests than getting smaller chunks of getLogs.

upd. if I recall correctly, we have to execute a single RPC request to get balances of all ERC20 tokens (that can be our own list of top something tokens + those which were found during history fetching) and that in most cases will be almost as good as all those getLogs (at least for verifying that there were no transfers)

[rasom]

So that's what I get now while fetching full history on that same account, apparently nothing changed here because previously balance history requests were not counted

;; => {:total 13596,
;;     :methods
;;     ([:eth_BalanceAt 5277]
;;      [:eth_NonceAt 4323]
;;      [:eth_GetBaseFeeFromBlock 805]
;;      [:eth_TransactionReceipt 676]
;;      [:eth_HeaderByNumber 573]
;;      [:eth_BlockByNumber 556]
;;      [:eth_FullTransactionByBlockNumberAndIndex 526]
;;      [:eth_FilterLogs 342]
;;      [:eth_CallContract 235]
;;      [:eth_BlockByHash 120]
;;      [:eth_TransactionByHash 120]
;;      [:eth_CodeAt 36]
;;      [:eth_BlockNumber 3]
;;      [:eth_CallContext 2]
;;      [:eth_getBlockByNumber 1]
;;      [:eth_getBalance 1])}

that's the old screen

So unless we run old version of balance history with addition of that counting it is hard to say what's the difference, it just wasn't included.

[rasom]

That's one hour of idle load with only one network

;; => {:total 1883,
;;     :methods
;;     ([:eth_FilterLogs 556]
;;      [:eth_CallContract 453]
;;      [:eth_HeaderByNumber 282]
;;      [:eth_BalanceAt 278]
;;      [:eth_NonceAt 278]
;;      [:eth_CodeAt 18]
;;      [:eth_BlockNumber 18])}

[rasom]

some notes https://notes.status.im/ViAdJMklTj-R9uhTIxtVYQ

[rasom]

The biggest concern atm is idle load needed for watching for new transfers.

Currently per iteration we execute next requests M * (eth_getHeader + N * (eth_getBalance + eth_getNonce + 3*eth_getLogs)), where M=number of chains, N=number of accounts watched

For, let's say, 3 networks (which is default at the moment) and 3 accounts it would require 48 requests per iteration. We have 13s interval atm, so it requires ~320k requests per day to work.

There are multiple things we can do to optimise this, like

1. Increase interval
2. Avoid transfers scanning for wallet accounts which have never been used
3. Investigate possibility of batch balance and nonce checks with read-only contract
4. Merge eth_getLogs requests when possible
5. Avoid making separate eth_getLogs for outgoing erc20 when possible

The end Gould of those changes is:

1. Stop making requests at all for accounts which are not expected to have any wallet activity
2. For the majority of those which are active execute M * (eth_callContract + 2*eth_getLogs) requests per iteration
3. For the rest which are active and has used approve method of erc20 M * (eth_callContract + 3*eth_getLogs)

That means, in the last of those three cases, if we would have 3 networks it would require 12 requests per iteration and do not grow with the number of accounts.

[rasom]

latest stats

1h, 1 network, 6 accounts (restored from mnemonic)

eth_CallContract_0x08A8fDBddc160A7d5b957256b903dCAb1aE512C5 90 <- ethscan contract mainnet
eth_CallContract_0xBB85398092B83A016935a17Fc857507b7851a071 90 <- ethscan contract arbitrum
eth_CallContract_0x9e5076DF494FC949aBc4461F4E57592B81517D81 90 <- ethscan contract optimism 
eth_CallContract_0xA8d270048a086F5807A8dc0a9ae0e96280C41e3A 60 <- directory
eth_CallContract_0x040EA8bFE441597849A9456182fa46D38B75BC05 30 <- balance checker (tx detection)
eth_CodeAt                                                  18 <- to be identified
eth_BlockNumber                                             18 <- fetchLatestBlockNumberCommand (to be removed)
eth_FilterLogs                                              18 <- checking incoming erc20/721/1155 (tx detection)
eth_BalanceAt                                               12 <- checking nonce (tx detection) (can be removed)
eth_NonceAt                                                 6  <- checking nonce (tx detection)
eth_CallContract_0x110101156e8F0743948B2A61aFcf3994A8Fb172e 5  <- stickers 

total                                                       437
total tx detection:                                         66

[rasom]

many hours on desktop, the point is to figure out what's used, not to calculate exact number of calls

  eth_CallContract_0x08A8fDBddc160A7d5b957256b903dCAb1aE512C5: 1079, //ethscan
  eth_CallContract_0x9e5076DF494FC949aBc4461F4E57592B81517D81: 1079, //ethscan optimism
  eth_CallContract_0xBB85398092B83A016935a17Fc857507b7851a071: 1079, //ethscan arbitrum
  eth_CallContract_0x55bD303eA3D50FC982A8a5b43972d7f38D129bbF: 982, //tx detection optimism + arbitrum
  eth_CallContract_0xA8d270048a086F5807A8dc0a9ae0e96280C41e3A: 980, // directory
  eth_CodeAt: 887, // likely ethscan
  eth_CallContract_0x040EA8bFE441597849A9456182fa46D38B75BC05: 491, //tx detection mainnet
  eth_FilterLogs: 411, // tx detection
  eth_BlockNumber: 297, // fetchLatestBlockNumberCommand and tx detection
  eth_HeaderByNumber: 297, // tx detection?
  eth_BalanceAt: 42, // tx detection
  eth_CallContract_0x0577215622f43a39F4Bc9640806DFea9b10D2A36: 21, //stickers
  eth_NonceAt: 21, //tx detection
  eth_CallContract_0x00000000000C2E074eC69A0dFb2997BA6C7d2e1e: 3, //resolver
  eth_CallContract_0x0000000000000000000000000000000000000000: 2, //mystery :D
  eth_CallContract_0x110101156e8F0743948B2A61aFcf3994A8Fb172e: 2, // sticker pack
  eth_CallContract_0x4976fb03C32e5B8cfe2b6cCB31c09Ba78EBaBa41: 1 //ens

[rasom]

same account as here after importing seed phrase https://github.com/status-im/status-go/issues/3833#issuecomment-1673627059

3 networks, tested on latest desktop

The number of requests is big which is definitely not very good, but the biggest problem is that UI doesn't really show anything for 5-8 minutes

total: 14634
{
  eth_BalanceAt: 5612,
  eth_NonceAt: 4527,
  eth_FilterLogs: 1176,
  eth_TransactionReceipt: 757,
  eth_BlockByNumber: 723,
  eth_HeaderByNumber: 716,
  eth_FullTransactionByBlockNumberAndIndex: 713,
  eth_TransactionByHash: 107,
  eth_CodeAt: 78,
  eth_CallContract_0x0577215622f43a39F4Bc9640806DFea9b10D2A36: 21,
  eth_CallContract_0x39755357759cE0d7f32dC8dC45414CCa409AE24e: 21,
  eth_CallContract_0x110101156e8F0743948B2A61aFcf3994A8Fb172e: 17,
  eth_CallContract_0x8fd3121013A07C57f0D69646E86E7a4880b467b7: 8,
  eth_CallContract_0xA8d270048a086F5807A8dc0a9ae0e96280C41e3A: 8,
  eth_CallContract_0xBB85398092B83A016935a17Fc857507b7851a071: 6,
  eth_CallContract_0x9e5076DF494FC949aBc4461F4E57592B81517D81: 5,
  eth_CallContract_0x040EA8bFE441597849A9456182fa46D38B75BC05: 4,
  eth_CallContract_0x08A8fDBddc160A7d5b957256b903dCAb1aE512C5: 4,
  eth_CallContract_0x212D95FcCdF0366343350f486bda1ceAfC0C2d63: 4,
  eth_CallContract_0x519475b31653E46D20cD09F9FdcF3B12BDAcB4f5: 4,
  eth_CallContract_0x54764eF12d29b249fDC7FC3caDc039955A396A8e: 4,
  eth_CallContract_0x55bD303eA3D50FC982A8a5b43972d7f38D129bbF: 4,
  eth_CallContract_0x9ab165D795019b6d8B3e971DdA91071421305e5a: 4,
  eth_CallContract_0x9dCe7C9767863110E4fA01410A35b5471AecE64e: 4,
  eth_CallContract_0xC12D1c73eE7DC3615BA4e37E4ABFdbDDFA38907E: 4,
  eth_CallContract_0xab95E915c123fdEd5BDfB6325e35ef5515F1EA69: 4,
  eth_CallContract_0x00000000000C2E074eC69A0dFb2997BA6C7d2e1e: 3,
  eth_CallContract_0x0000000000000000000000000000000000000000: 2,
  eth_CallContract_0x599485Dc0f3D8b308B973B2Db5Cd44baE46D31c4: 2,
  eth_CallContract_0x785CfC135cd5E26f55a791D177C3cbDFB16F9fEA: 2,
  eth_CallContract_0x85C5c26DC2aF5546341Fc1988B9d178148b4838B: 2,
  eth_CallContract_0xCBc6a023eb975a1e2630223a7959988948E664f3: 2,
  eth_CallContract_0x0391D2021f89DC339F60Fff84546EA23E337750f: 1,
  eth_CallContract_0x081131434f93063751813C619Ecca9C4dC7862a3: 1,
  eth_CallContract_0x08389495D7456E1951ddF7c3a1314A4bfb646d8B: 1,
  eth_CallContract_0x090D4613473dEE047c3f2706764f49E0821D256e: 1,
  eth_CallContract_0x0AbdAce70D3790235af448C88547603b945604ea: 1,
  eth_CallContract_0x0D8775F648430679A709E98d2b0Cb6250d2887EF: 1,
  eth_CallContract_0x0b38210ea11411557c13457D4dA7dC6ea731B88a: 1,
  eth_CallContract_0x111111111117dC0aa78b770fA6A738034120C302: 1,
  eth_CallContract_0x1494CA1F11D487c2bBe4543E90080AeBa4BA3C2b: 1,
  eth_CallContract_0x18aAA7115705e8be94bfFEBDE57Af9BFc265B998: 1,
  eth_CallContract_0x1A4b46696b2bB4794Eb3D4c26f1c55F9170fa4C5: 1,
  eth_CallContract_0x1F573D6Fb3F13d689FF844B4cE37794d79a7FF1C: 1,
  eth_CallContract_0x1a7e4e63778B4f12a199C062f3eFdD288afCBce8: 1,
  eth_CallContract_0x1aBaEA1f7C830bD89Acc67eC4af516284b1bC33c: 1,
  eth_CallContract_0x2565ae0385659badCada1031DB704442E1b69982: 1,
  eth_CallContract_0x27054b13b1B798B345b591a4d22e6562d47eA75a: 1,
  eth_CallContract_0x27702a26126e0B3702af63Ee09aC4d1A084EF628: 1,
  eth_CallContract_0x321C2fE4446C7c963dc41Dd58879AF648838f98D: 1,
  eth_CallContract_0x32353A6C91143bfd6C7d363B546e62a9A2489A20: 1,
  eth_CallContract_0x3294395e62F4eB6aF3f1Fcf89f5602D90Fb3Ef69: 1,
  eth_CallContract_0x3472A5A71965499acd81997a54BBA8D852C6E53d: 1,
  eth_CallContract_0x3506424F91fD33084466F402d5D97f05F8e3b4AF: 1,
  eth_CallContract_0x3597bfD533a99c9aa083587B074434E61Eb0A258: 1,
  eth_CallContract_0x3A880652F47bFaa771908C07Dd8673A787dAEd3A: 1,
  eth_CallContract_0x3Ab6Ed69Ef663bd986Ee59205CCaD8A20F98b4c2: 1,
  eth_CallContract_0x3D658390460295FB963f54dC0899cfb1c30776Df: 1,
  eth_CallContract_0x41e5560054824eA6B0732E656E3Ad64E20e94E45: 1,
  eth_CallContract_0x42bBFa2e77757C645eeaAd1655E0911a7553Efbc: 1,
  eth_CallContract_0x467719aD09025FcC6cF6F8311755809d45a5E5f3: 1,
  eth_CallContract_0x491604c0FDF08347Dd1fa4Ee062a822A5DD06B5D: 1,
  eth_CallContract_0x4976fb03C32e5B8cfe2b6cCB31c09Ba78EBaBa41: 1,
  eth_CallContract_0x4F9254C83EB525f9FCf346490bbb3ed28a81C667: 1,
  eth_CallContract_0x4Fabb145d64652a948d72533023f6E7A623C7C53: 1,
  eth_CallContract_0x4d224452801ACEd8B2F0aebE155379bb5D594381: 1,
  eth_CallContract_0x4e3FBD56CD56c3e72c1403e103b45Db9da5B9D2B: 1,
  eth_CallContract_0x5283D291DBCF85356A21bA090E6db59121208b44: 1,
  eth_CallContract_0x5732046A883704404F284Ce41FfADd5b007FD668: 1,
  eth_CallContract_0x626E8036dEB333b408Be468F951bdB42433cBF18: 1,
  eth_CallContract_0x64D91f12Ece7362F91A6f8E7940Cd55F05060b92: 1,
  eth_CallContract_0x6B0b3a982b4634aC68dD83a4DBF02311cE324181: 1,
  eth_CallContract_0x6B175474E89094C44Da98b954EedeAC495271d0F: 1,
  eth_CallContract_0x761D38e5ddf6ccf6Cf7c55759d5210750B5D60F3: 1,
  eth_CallContract_0x799ebfABE77a6E34311eeEe9825190B9ECe32824: 1,
  eth_CallContract_0x7B9c5E2D10Fdcc18b972CB6caB4E60f277a8e332: 1,
  eth_CallContract_0x7Fc66500c84A76Ad7e9c93437bFc5Ac33E2DDaE9: 1,
  eth_CallContract_0x7a250d5630B4cF539739dF2C5dAcb4c659F2488D: 1,
  eth_CallContract_0x80C62FE4487E1351b47Ba49809EBD60ED085bf52: 1,
  eth_CallContract_0x818E6FECD516Ecc3849DAf6845e3EC868087B755: 1,
  eth_CallContract_0x8290333ceF9e6D528dD5618Fb97a76f268f3EDD4: 1,
  eth_CallContract_0x845576c64f9754CF09d87e45B720E82F3EeF522C: 1,
  eth_CallContract_0x84cA8bc7997272c7CfB4D0Cd3D55cd942B3c9419: 1,
  eth_CallContract_0x8A2279d4A90B6fe1C4B30fa660cC9f926797bAA2: 1,
  eth_CallContract_0x91Af0fBB28ABA7E31403Cb457106Ce79397FD4E6: 1,
  eth_CallContract_0x92D6C1e31e14520e676a687F0a93788B716BEff5: 1,
  eth_CallContract_0x961C8c0B1aaD0c0b10a51FeF6a867E3091BCef17: 1,
  eth_CallContract_0xA0b73E1Ff0B80914AB6fe0444E65848C4C34450b: 1,
  eth_CallContract_0xA2120b9e674d3fC3875f415A7DF52e382F141225: 1,
  eth_CallContract_0xA9B1Eb5908CfC3cdf91F9B8B3a74108598009096: 1,
  eth_CallContract_0xAC51066d7bEC65Dc4589368da368b212745d63E8: 1,
  eth_CallContract_0xADE00C28244d5CE17D72E40330B1c318cD12B7c3: 1,
  eth_CallContract_0xAE12C5930881c53715B369ceC7606B70d8EB229f: 1,
  eth_CallContract_0xB50721BCf8d664c30412Cfbc6cf7a15145234ad1: 1,
  eth_CallContract_0xB98d4C97425d9908E66E53A6fDf673ACcA0BE986: 1,
  eth_CallContract_0xBA11D00c5f74255f56a5E366F4F77f5A186d7f55: 1,
  eth_CallContract_0xBA50933C268F567BDC86E1aC131BE072C6B0b71a: 1,
  eth_CallContract_0xBB0E17EF65F82Ab018d8EDd776e8DD940327B28b: 1,
  eth_CallContract_0xBBc2AE13b23d715c30720F079fcd9B4a74093505: 1,
  eth_CallContract_0xBe9895146f7AF43049ca1c1AE358B0541Ea49704: 1,
  eth_CallContract_0xC18360217D8F7Ab5e7c516566761Ea12Ce7F9D72: 1,
  eth_CallContract_0xD417144312DbF50465b1C641d016962017Ef6240: 1,
  eth_CallContract_0xD533a949740bb3306d119CC777fa900bA034cd52: 1,
  eth_CallContract_0xDDB3422497E61e13543BeA06989C0789117555c5: 1,
  eth_CallContract_0xDf801468a808a32656D2eD2D2d80B72A129739f4: 1,
  eth_CallContract_0xEF68e7C694F40c8202821eDF525dE3782458639f: 1,
  eth_CallContract_0xEd04915c23f00A313a544955524EB7DBD823143d: 1,
  eth_CallContract_0xF17e65822b568B3903685a7c9F496CF7656Cc6C2: 1,
  eth_CallContract_0xF629cBd94d3791C9250152BD8dfBDF380E2a3B9c: 1,
  eth_CallContract_0xa117000000f279D81A1D3cc75430fAA017FA5A2e: 1,
  eth_CallContract_0xa1faa113cbE53436Df28FF0aEe54275c13B40975: 1,
  eth_CallContract_0xba100000625a3754423978a60c9317c58a424e3D: 1,
  eth_CallContract_0xc00e94Cb662C3520282E6f5717214004A7f26888: 1,
  eth_CallContract_0xd9Fcd98c322942075A5C3860693e9f4f03AAE07b: 1,
  eth_CallContract_0xdBdb4d16EdA451D0503b854CF79D55697F90c8DF: 1,
  eth_CallContract_0xe6fd75ff38Adca4B97FBCD938c86b98772431867: 1,
  eth_CallContract_0xfB7B4564402E5500dB5bB6d63Ae671302777C75a: 1,
  eth_CallContract_0xfF20817765cB7f73d4bde2e66e067E58D11095C2: 1
}

[rasom]

idle load, ~1.5h, 1 acc, 3 networks

total: 232 (around 3700 requests daily)
{
  eth_FilterLogs: 81,
  eth_CallContract_0x040EA8bFE441597849A9456182fa46D38B75BC05: 46,
  eth_CallContract_0x54764eF12d29b249fDC7FC3caDc039955A396A8e: 46,
  eth_CallContract_0x55bD303eA3D50FC982A8a5b43972d7f38D129bbF: 46,
  eth_NonceAt: 6,
  eth_CallContract_0x110101156e8F0743948B2A61aFcf3994A8Fb172e: 5, <- stickers
  eth_CallContract_0xA8d270048a086F5807A8dc0a9ae0e96280C41e3A: 2. <- directory
}

[rasom]

boot requests: 1 acc, 3 networks, history is loaded before login

total: 62
{
  eth_CallContract_0x0577215622f43a39F4Bc9640806DFea9b10D2A36: 21,
  eth_FilterLogs: 9,
  eth_NonceAt: 8,
  eth_BalanceAt: 6,
  eth_CallContract_0x00000000000C2E074eC69A0dFb2997BA6C7d2e1e: 3,
  eth_HeaderByNumber: 3,
  eth_CallContract_0x0000000000000000000000000000000000000000: 2,
  eth_CallContract_0x110101156e8F0743948B2A61aFcf3994A8Fb172e: 2,
  eth_CallContract_0xA8d270048a086F5807A8dc0a9ae0e96280C41e3A: 2,
  eth_CodeAt: 2,
  eth_CallContract_0x040EA8bFE441597849A9456182fa46D38B75BC05: 1,
  eth_CallContract_0x4976fb03C32e5B8cfe2b6cCB31c09Ba78EBaBa41: 1,
  eth_CallContract_0x54764eF12d29b249fDC7FC3caDc039955A396A8e: 1,
  eth_CallContract_0x55bD303eA3D50FC982A8a5b43972d7f38D129bbF: 1
}

[rasom]

history loading

Total   14993 of 15113

eth_BalanceAt   5639
eth_NonceAt 4573
eth_FilterLogs  1281
eth_TransactionReceipt  813
eth_BlockByNumber   779
eth_HeaderByNumber  746
eth_FullTransactionByBlockNumberAndIndex    743
eth_TransactionByHash   107
eth_CodeAt  93
eth_CallContract_0x39755357759cE0d7f32dC8dC45414CCa409AE24e 21
eth_CallContract_0x0577215622f43a39F4Bc9640806DFea9b10D2A36 14
eth_CallContract_0x8fd3121013A07C57f0D69646E86E7a4880b467b7 8
eth_CallContract_0xBB85398092B83A016935a17Fc857507b7851a071 6
eth_CallContract_0x040EA8bFE441597849A9456182fa46D38B75BC05 5
eth_CallContract_0x110101156e8F0743948B2A61aFcf3994A8Fb172e 5
eth_CallContract_0x54764eF12d29b249fDC7FC3caDc039955A396A8e 5
eth_CallContract_0x55bD303eA3D50FC982A8a5b43972d7f38D129bbF 5
eth_CallContract_0x9e5076DF494FC949aBc4461F4E57592B81517D81 5
eth_CallContract_0x08A8fDBddc160A7d5b957256b903dCAb1aE512C5 4
eth_CallContract_0x212D95FcCdF0366343350f486bda1ceAfC0C2d63 4
eth_CallContract_0x519475b31653E46D20cD09F9FdcF3B12BDAcB4f5 4
eth_CallContract_0x9ab165D795019b6d8B3e971DdA91071421305e5a 4
eth_CallContract_0x9dCe7C9767863110E4fA01410A35b5471AecE64e 4
eth_CallContract_0xC12D1c73eE7DC3615BA4e37E4ABFdbDDFA38907E 4
eth_CallContract_0xab95E915c123fdEd5BDfB6325e35ef5515F1EA69 4
eth_CallContract_0x0000000000000000000000000000000000000000 2
eth_CallContract_0x00000000000C2E074eC69A0dFb2997BA6C7d2e1e 2
eth_CallContract_0x599485Dc0f3D8b308B973B2Db5Cd44baE46D31c4 2
eth_CallContract_0x785CfC135cd5E26f55a791D177C3cbDFB16F9fEA 2
eth_CallContract_0x85C5c26DC2aF5546341Fc1988B9d178148b4838B 2
eth_CallContract_0xA8d270048a086F5807A8dc0a9ae0e96280C41e3A 2
eth_CallContract_0xCBc6a023eb975a1e2630223a7959988948E664f3 2
eth_CallContract_0x0391D2021f89DC339F60Fff84546EA23E337750f 1
eth_CallContract_0x081131434f93063751813C619Ecca9C4dC7862a3 1
eth_CallContract_0x08389495D7456E1951ddF7c3a1314A4bfb646d8B 1
eth_CallContract_0x090D4613473dEE047c3f2706764f49E0821D256e 1
eth_CallContract_0x0AbdAce70D3790235af448C88547603b945604ea 1
eth_CallContract_0x0D8775F648430679A709E98d2b0Cb6250d2887EF 1
eth_CallContract_0x0b38210ea11411557c13457D4dA7dC6ea731B88a 1
eth_CallContract_0x111111111117dC0aa78b770fA6A738034120C302 1
eth_CallContract_0x1494CA1F11D487c2bBe4543E90080AeBa4BA3C2b 1
eth_CallContract_0x15D4c048F83bd7e37d49eA4C83a07267Ec4203dA 1
eth_CallContract_0x18aAA7115705e8be94bfFEBDE57Af9BFc265B998 1
eth_CallContract_0x1A4b46696b2bB4794Eb3D4c26f1c55F9170fa4C5 1
eth_CallContract_0x1F573D6Fb3F13d689FF844B4cE37794d79a7FF1C 1
eth_CallContract_0x1a7e4e63778B4f12a199C062f3eFdD288afCBce8 1
eth_CallContract_0x1aBaEA1f7C830bD89Acc67eC4af516284b1bC33c 1
eth_CallContract_0x2565ae0385659badCada1031DB704442E1b69982 1
eth_CallContract_0x27054b13b1B798B345b591a4d22e6562d47eA75a 1
eth_CallContract_0x27702a26126e0B3702af63Ee09aC4d1A084EF628 1
eth_CallContract_0x321C2fE4446C7c963dc41Dd58879AF648838f98D 1
eth_CallContract_0x32353A6C91143bfd6C7d363B546e62a9A2489A20 1
eth_CallContract_0x3294395e62F4eB6aF3f1Fcf89f5602D90Fb3Ef69 1
eth_CallContract_0x3432B6A60D23Ca0dFCa7761B7ab56459D9C964D0 1
eth_CallContract_0x3472A5A71965499acd81997a54BBA8D852C6E53d 1
eth_CallContract_0x3506424F91fD33084466F402d5D97f05F8e3b4AF 1
eth_CallContract_0x3597bfD533a99c9aa083587B074434E61Eb0A258 1
eth_CallContract_0x3A880652F47bFaa771908C07Dd8673A787dAEd3A 1
eth_CallContract_0x3Ab6Ed69Ef663bd986Ee59205CCaD8A20F98b4c2 1
eth_CallContract_0x3D658390460295FB963f54dC0899cfb1c30776Df 1
eth_CallContract_0x3F382DbD960E3a9bbCeaE22651E88158d2791550 1
eth_CallContract_0x41545f8b9472D758bB669ed8EaEEEcD7a9C4Ec29 1
eth_CallContract_0x41e5560054824eA6B0732E656E3Ad64E20e94E45 1
eth_CallContract_0x42bBFa2e77757C645eeaAd1655E0911a7553Efbc 1
eth_CallContract_0x467719aD09025FcC6cF6F8311755809d45a5E5f3 1
eth_CallContract_0x491604c0FDF08347Dd1fa4Ee062a822A5DD06B5D 1
eth_CallContract_0x4E15361FD6b4BB609Fa63C81A2be19d873717870 1
eth_CallContract_0x4F9254C83EB525f9FCf346490bbb3ed28a81C667 1
eth_CallContract_0x4Fabb145d64652a948d72533023f6E7A623C7C53 1
eth_CallContract_0x4d224452801ACEd8B2F0aebE155379bb5D594381 1
eth_CallContract_0x4e3FBD56CD56c3e72c1403e103b45Db9da5B9D2B 1
eth_CallContract_0x5283D291DBCF85356A21bA090E6db59121208b44 1
eth_CallContract_0x5732046A883704404F284Ce41FfADd5b007FD668 1
eth_CallContract_0x5fAa989Af96Af85384b8a938c2EdE4A7378D9875 1
eth_CallContract_0x626E8036dEB333b408Be468F951bdB42433cBF18 1
eth_CallContract_0x64D91f12Ece7362F91A6f8E7940Cd55F05060b92 1
eth_CallContract_0x6810e776880C02933D47DB1b9fc05908e5386b96 1
eth_CallContract_0x6B0b3a982b4634aC68dD83a4DBF02311cE324181 1
eth_CallContract_0x6B175474E89094C44Da98b954EedeAC495271d0F 1
eth_CallContract_0x761D38e5ddf6ccf6Cf7c55759d5210750B5D60F3 1
eth_CallContract_0x77FbA179C79De5B7653F68b5039Af940AdA60ce0 1
eth_CallContract_0x799ebfABE77a6E34311eeEe9825190B9ECe32824 1
eth_CallContract_0x7B9c5E2D10Fdcc18b972CB6caB4E60f277a8e332 1
eth_CallContract_0x7DD9c5Cba05E151C895FDe1CF355C9A1D5DA6429 1
eth_CallContract_0x7Fc66500c84A76Ad7e9c93437bFc5Ac33E2DDaE9 1
eth_CallContract_0x7a250d5630B4cF539739dF2C5dAcb4c659F2488D 1
eth_CallContract_0x80C62FE4487E1351b47Ba49809EBD60ED085bf52 1
eth_CallContract_0x818E6FECD516Ecc3849DAf6845e3EC868087B755 1
eth_CallContract_0x8290333ceF9e6D528dD5618Fb97a76f268f3EDD4 1
eth_CallContract_0x845576c64f9754CF09d87e45B720E82F3EeF522C 1
eth_CallContract_0x84cA8bc7997272c7CfB4D0Cd3D55cd942B3c9419 1
eth_CallContract_0x853d955aCEf822Db058eb8505911ED77F175b99e 1
eth_CallContract_0x8A2279d4A90B6fe1C4B30fa660cC9f926797bAA2 1
eth_CallContract_0x8c15Ef5b4B21951d50E53E4fbdA8298FFAD25057 1
eth_CallContract_0x91Af0fBB28ABA7E31403Cb457106Ce79397FD4E6 1
eth_CallContract_0x92D6C1e31e14520e676a687F0a93788B716BEff5 1
eth_CallContract_0x961C8c0B1aaD0c0b10a51FeF6a867E3091BCef17 1
eth_CallContract_0xA0b73E1Ff0B80914AB6fe0444E65848C4C34450b 1
eth_CallContract_0xA2120b9e674d3fC3875f415A7DF52e382F141225 1
eth_CallContract_0xA9B1Eb5908CfC3cdf91F9B8B3a74108598009096 1
eth_CallContract_0xAC51066d7bEC65Dc4589368da368b212745d63E8 1
eth_CallContract_0xADE00C28244d5CE17D72E40330B1c318cD12B7c3 1
eth_CallContract_0xAE12C5930881c53715B369ceC7606B70d8EB229f 1
eth_CallContract_0xB50721BCf8d664c30412Cfbc6cf7a15145234ad1 1
eth_CallContract_0xB98d4C97425d9908E66E53A6fDf673ACcA0BE986 1
eth_CallContract_0xBA11D00c5f74255f56a5E366F4F77f5A186d7f55 1
eth_CallContract_0xBA50933C268F567BDC86E1aC131BE072C6B0b71a 1
eth_CallContract_0xBB0E17EF65F82Ab018d8EDd776e8DD940327B28b 1
eth_CallContract_0xBBc2AE13b23d715c30720F079fcd9B4a74093505 1
eth_CallContract_0xBe9895146f7AF43049ca1c1AE358B0541Ea49704 1
eth_CallContract_0xC18360217D8F7Ab5e7c516566761Ea12Ce7F9D72 1
eth_CallContract_0xD417144312DbF50465b1C641d016962017Ef6240 1
eth_CallContract_0xD533a949740bb3306d119CC777fa900bA034cd52 1
eth_CallContract_0xDDB3422497E61e13543BeA06989C0789117555c5 1
eth_CallContract_0xDf801468a808a32656D2eD2D2d80B72A129739f4 1
eth_CallContract_0xEF68e7C694F40c8202821eDF525dE3782458639f 1
eth_CallContract_0xEd04915c23f00A313a544955524EB7DBD823143d 1
eth_CallContract_0xF17e65822b568B3903685a7c9F496CF7656Cc6C2 1
eth_CallContract_0xF629cBd94d3791C9250152BD8dfBDF380E2a3B9c 1
eth_CallContract_0xa0246c9032bC3A600820415aE600c6388619A14D 1
eth_CallContract_0xa117000000f279D81A1D3cc75430fAA017FA5A2e 1
eth_CallContract_0xa1faa113cbE53436Df28FF0aEe54275c13B40975 1
eth_CallContract_0xaea46A60368A7bD060eec7DF8CBa43b7EF41Ad85 1
eth_CallContract_0xba100000625a3754423978a60c9317c58a424e3D 1
eth_CallContract_0xc00e94Cb662C3520282E6f5717214004A7f26888 1
eth_CallContract_0xc770EEfAd204B5180dF6a14Ee197D99d808ee52d 1
eth_CallContract_0xc944E90C64B2c07662A292be6244BDf05Cda44a7 1
eth_CallContract_0xccC8cb5229B0ac8069C51fd58367Fd1e622aFD97 1
eth_CallContract_0xd9Fcd98c322942075A5C3860693e9f4f03AAE07b 1
eth_CallContract_0xdBdb4d16EdA451D0503b854CF79D55697F90c8DF 1
eth_CallContract_0xdab396cCF3d84Cf2D07C4454e10C8A6F5b008D2b 1
eth_CallContract_0xe6fd75ff38Adca4B97FBCD938c86b98772431867 1
eth_CallContract_0xef3A930e1FfFFAcd2fc13434aC81bD278B0ecC8d 1
eth_CallContract_0xfB7B4564402E5500dB5bB6d63Ae671302777C75a 1
eth_CallContract_0xfF20817765cB7f73d4bde2e66e067E58D11095C2 1

[rasom]

changed DefaultNodeBlockChunkSize from 100000 to 10000000, same account. Looks weird

Total   3055 of 3166

eth_BalanceAt   1421
eth_NonceAt 912
eth_FilterLogs  236
eth_TransactionReceipt  93
eth_BlockByNumber   91
eth_HeaderByNumber  68
eth_FullTransactionByBlockNumberAndIndex    65
eth_TransactionByHash   36
eth_CallContract_0x0577215622f43a39F4Bc9640806DFea9b10D2A36 21
eth_CallContract_0x110101156e8F0743948B2A61aFcf3994A8Fb172e 17
eth_CodeAt  14
eth_CallContract_0x39755357759cE0d7f32dC8dC45414CCa409AE24e 9
eth_CallContract_0x89d24A6b4CcB1B6fAA2625fE562bDD9a23260359 9
eth_CallContract_0x4DC3643DbC642b72C158E7F3d2ff232df61cb6CE 7
eth_CallContract_0xBBbbCA6A901c926F240b89EacB641d8Aec7AEafD 7
eth_CallContract_0xBB85398092B83A016935a17Fc857507b7851a071 6
eth_CallContract_0x08A8fDBddc160A7d5b957256b903dCAb1aE512C5 5
eth_CallContract_0x9e5076DF494FC949aBc4461F4E57592B81517D81 5
eth_CallContract_0x0000000000000000000000000000000000000000 4
eth_CallContract_0x519475b31653E46D20cD09F9FdcF3B12BDAcB4f5 4
eth_CallContract_0x9ab165D795019b6d8B3e971DdA91071421305e5a 4
eth_CallContract_0xab95E915c123fdEd5BDfB6325e35ef5515F1EA69 4
eth_CallContract_0x00000000000C2E074eC69A0dFb2997BA6C7d2e1e 2
eth_CallContract_0x040EA8bFE441597849A9456182fa46D38B75BC05 2
eth_CallContract_0x54764eF12d29b249fDC7FC3caDc039955A396A8e 2
eth_CallContract_0x55bD303eA3D50FC982A8a5b43972d7f38D129bbF 2
eth_CallContract_0x785CfC135cd5E26f55a791D177C3cbDFB16F9fEA 2
eth_CallContract_0x85C5c26DC2aF5546341Fc1988B9d178148b4838B 2
eth_CallContract_0xA8d270048a086F5807A8dc0a9ae0e96280C41e3A 2
eth_CallContract_0x818E6FECD516Ecc3849DAf6845e3EC868087B755 1
eth_CallContract_0xCBc6a023eb975a1e2630223a7959988948E664f3 1
eth_CallContract_0xEF68e7C694F40c8202821eDF525dE3782458639f 1

[rasom]

DefaultNodeBlockChunkSize=1000000

Total   28659 of 28900

eth_FilterLogs  10308
eth_BalanceAt   8147
eth_NonceAt 7350
eth_TransactionReceipt  604
eth_BlockByNumber   575
eth_HeaderByNumber  540
eth_FullTransactionByBlockNumberAndIndex    537
eth_TransactionByHash   107
eth_CallContract_0xBB85398092B83A016935a17Fc857507b7851a071 56
eth_CallContract_0x9e5076DF494FC949aBc4461F4E57592B81517D81 55
eth_CallContract_0x08A8fDBddc160A7d5b957256b903dCAb1aE512C5 54
eth_CodeAt  47
eth_CallContract_0x040EA8bFE441597849A9456182fa46D38B75BC05 39
eth_CallContract_0x54764eF12d29b249fDC7FC3caDc039955A396A8e 39
eth_CallContract_0x55bD303eA3D50FC982A8a5b43972d7f38D129bbF 39
eth_CallContract_0x110101156e8F0743948B2A61aFcf3994A8Fb172e 22
eth_CallContract_0x0577215622f43a39F4Bc9640806DFea9b10D2A36 21
eth_CallContract_0x39755357759cE0d7f32dC8dC45414CCa409AE24e 21
eth_CallContract_0x8fd3121013A07C57f0D69646E86E7a4880b467b7 8
eth_CallContract_0x212D95FcCdF0366343350f486bda1ceAfC0C2d63 4
eth_CallContract_0x519475b31653E46D20cD09F9FdcF3B12BDAcB4f5 4
eth_CallContract_0x9ab165D795019b6d8B3e971DdA91071421305e5a 4
eth_CallContract_0x9dCe7C9767863110E4fA01410A35b5471AecE64e 4
eth_CallContract_0xA8d270048a086F5807A8dc0a9ae0e96280C41e3A 4
eth_CallContract_0xC12D1c73eE7DC3615BA4e37E4ABFdbDDFA38907E 4
eth_CallContract_0xab95E915c123fdEd5BDfB6325e35ef5515F1EA69 4
eth_CallContract_0x0000000000000000000000000000000000000000 2
eth_CallContract_0x00000000000C2E074eC69A0dFb2997BA6C7d2e1e 2
eth_CallContract_0x599485Dc0f3D8b308B973B2Db5Cd44baE46D31c4 2
eth_CallContract_0x785CfC135cd5E26f55a791D177C3cbDFB16F9fEA 2
eth_CallContract_0x85C5c26DC2aF5546341Fc1988B9d178148b4838B 2
eth_CallContract_0xCBc6a023eb975a1e2630223a7959988948E664f3 2
eth_CallContract_0x0391D2021f89DC339F60Fff84546EA23E337750f 1
eth_CallContract_0x090D4613473dEE047c3f2706764f49E0821D256e 1
eth_CallContract_0x0D8775F648430679A709E98d2b0Cb6250d2887EF 1
eth_CallContract_0x0b38210ea11411557c13457D4dA7dC6ea731B88a 1
eth_CallContract_0x111111111117dC0aa78b770fA6A738034120C302 1
eth_CallContract_0x18aAA7115705e8be94bfFEBDE57Af9BFc265B998 1
eth_CallContract_0x1A4b46696b2bB4794Eb3D4c26f1c55F9170fa4C5 1
eth_CallContract_0x1F573D6Fb3F13d689FF844B4cE37794d79a7FF1C 1
eth_CallContract_0x1a7e4e63778B4f12a199C062f3eFdD288afCBce8 1
eth_CallContract_0x2565ae0385659badCada1031DB704442E1b69982 1
eth_CallContract_0x27054b13b1B798B345b591a4d22e6562d47eA75a 1
eth_CallContract_0x27702a26126e0B3702af63Ee09aC4d1A084EF628 1
eth_CallContract_0x32353A6C91143bfd6C7d363B546e62a9A2489A20 1
eth_CallContract_0x3472A5A71965499acd81997a54BBA8D852C6E53d 1
eth_CallContract_0x42bBFa2e77757C645eeaAd1655E0911a7553Efbc 1
eth_CallContract_0x467719aD09025FcC6cF6F8311755809d45a5E5f3 1
eth_CallContract_0x4Fabb145d64652a948d72533023f6E7A623C7C53 1
eth_CallContract_0x4d224452801ACEd8B2F0aebE155379bb5D594381 1
eth_CallContract_0x5283D291DBCF85356A21bA090E6db59121208b44 1
eth_CallContract_0x5732046A883704404F284Ce41FfADd5b007FD668 1
eth_CallContract_0x626E8036dEB333b408Be468F951bdB42433cBF18 1
eth_CallContract_0x64D91f12Ece7362F91A6f8E7940Cd55F05060b92 1
eth_CallContract_0x6B0b3a982b4634aC68dD83a4DBF02311cE324181 1
eth_CallContract_0x799ebfABE77a6E34311eeEe9825190B9ECe32824 1
eth_CallContract_0x7B9c5E2D10Fdcc18b972CB6caB4E60f277a8e332 1
eth_CallContract_0x7Fc66500c84A76Ad7e9c93437bFc5Ac33E2DDaE9 1
eth_CallContract_0x7a250d5630B4cF539739dF2C5dAcb4c659F2488D 1
eth_CallContract_0x818E6FECD516Ecc3849DAf6845e3EC868087B755 1
eth_CallContract_0x8290333ceF9e6D528dD5618Fb97a76f268f3EDD4 1
eth_CallContract_0x845576c64f9754CF09d87e45B720E82F3EeF522C 1
eth_CallContract_0x91Af0fBB28ABA7E31403Cb457106Ce79397FD4E6 1
eth_CallContract_0xA2120b9e674d3fC3875f415A7DF52e382F141225 1
eth_CallContract_0xA9B1Eb5908CfC3cdf91F9B8B3a74108598009096 1
eth_CallContract_0xAC51066d7bEC65Dc4589368da368b212745d63E8 1
eth_CallContract_0xADE00C28244d5CE17D72E40330B1c318cD12B7c3 1
eth_CallContract_0xAE12C5930881c53715B369ceC7606B70d8EB229f 1
eth_CallContract_0xB50721BCf8d664c30412Cfbc6cf7a15145234ad1 1
eth_CallContract_0xB98d4C97425d9908E66E53A6fDf673ACcA0BE986 1
eth_CallContract_0xBA11D00c5f74255f56a5E366F4F77f5A186d7f55 1
eth_CallContract_0xBA50933C268F567BDC86E1aC131BE072C6B0b71a 1
eth_CallContract_0xBB0E17EF65F82Ab018d8EDd776e8DD940327B28b 1
eth_CallContract_0xBe9895146f7AF43049ca1c1AE358B0541Ea49704 1
eth_CallContract_0xEF68e7C694F40c8202821eDF525dE3782458639f 1
eth_CallContract_0xEd04915c23f00A313a544955524EB7DBD823143d 1
eth_CallContract_0xF17e65822b568B3903685a7c9F496CF7656Cc6C2 1
eth_CallContract_0xa117000000f279D81A1D3cc75430fAA017FA5A2e 1
eth_CallContract_0xa1faa113cbE53436Df28FF0aEe54275c13B40975 1
eth_CallContract_0xba100000625a3754423978a60c9317c58a424e3D 1
eth_CallContract_0xdBdb4d16EdA451D0503b854CF79D55697F90c8DF 1
eth_CallContract_0xfF20817765cB7f73d4bde2e66e067E58D11095C2 1

[rasom]

Total   13993 of 14112

eth_BalanceAt   7297
eth_NonceAt 4347
eth_TransactionReceipt  581
eth_BlockByNumber   552
eth_HeaderByNumber  517
eth_FullTransactionByBlockNumberAndIndex    514
eth_CodeAt  46
eth_CallContract_0x0577215622f43a39F4Bc9640806DFea9b10D2A36 21
eth_CallContract_0x110101156e8F0743948B2A61aFcf3994A8Fb172e 17
eth_CallContract_0x1F573D6Fb3F13d689FF844B4cE37794d79a7FF1C 7
eth_CallContract_0x040EA8bFE441597849A9456182fa46D38B75BC05 5
eth_CallContract_0x54764eF12d29b249fDC7FC3caDc039955A396A8e 5
eth_CallContract_0x55bD303eA3D50FC982A8a5b43972d7f38D129bbF 5
eth_CallContract_0x9e5076DF494FC949aBc4461F4E57592B81517D81 5
eth_CallContract_0xBB85398092B83A016935a17Fc857507b7851a071 5
eth_FilterLogs  5
eth_CallContract_0x08A8fDBddc160A7d5b957256b903dCAb1aE512C5 4
eth_TransactionByHash   4
eth_CallContract_0x0000000000000000000000000000000000000000 2
eth_CallContract_0x00000000000C2E074eC69A0dFb2997BA6C7d2e1e 2
eth_CallContract_0x59E7Bee6374A3f6ecB33180ecE978fd4f2B7Cea2 2
eth_CallContract_0x8fd3121013A07C57f0D69646E86E7a4880b467b7 2
eth_CallContract_0xA8d270048a086F5807A8dc0a9ae0e96280C41e3A 2
eth_CallContract_0x0391D2021f89DC339F60Fff84546EA23E337750f 1
eth_CallContract_0x0D8775F648430679A709E98d2b0Cb6250d2887EF 1
eth_CallContract_0x0b38210ea11411557c13457D4dA7dC6ea731B88a 1
eth_CallContract_0x111111111117dC0aa78b770fA6A738034120C302 1
eth_CallContract_0x18aAA7115705e8be94bfFEBDE57Af9BFc265B998 1
eth_CallContract_0x1A4b46696b2bB4794Eb3D4c26f1c55F9170fa4C5 1
eth_CallContract_0x1a7e4e63778B4f12a199C062f3eFdD288afCBce8 1
eth_CallContract_0x2565ae0385659badCada1031DB704442E1b69982 1
eth_CallContract_0x27054b13b1B798B345b591a4d22e6562d47eA75a 1
eth_CallContract_0x27702a26126e0B3702af63Ee09aC4d1A084EF628 1
eth_CallContract_0x32353A6C91143bfd6C7d363B546e62a9A2489A20 1
eth_CallContract_0x3294395e62F4eB6aF3f1Fcf89f5602D90Fb3Ef69 1
eth_CallContract_0x3472A5A71965499acd81997a54BBA8D852C6E53d 1
eth_CallContract_0x42bBFa2e77757C645eeaAd1655E0911a7553Efbc 1
eth_CallContract_0x467719aD09025FcC6cF6F8311755809d45a5E5f3 1
eth_CallContract_0x4Fabb145d64652a948d72533023f6E7A623C7C53 1
eth_CallContract_0x4d224452801ACEd8B2F0aebE155379bb5D594381 1
eth_CallContract_0x5283D291DBCF85356A21bA090E6db59121208b44 1
eth_CallContract_0x5732046A883704404F284Ce41FfADd5b007FD668 1
eth_CallContract_0x599485Dc0f3D8b308B973B2Db5Cd44baE46D31c4 1
eth_CallContract_0x626E8036dEB333b408Be468F951bdB42433cBF18 1
eth_CallContract_0x64D91f12Ece7362F91A6f8E7940Cd55F05060b92 1
eth_CallContract_0x6B0b3a982b4634aC68dD83a4DBF02311cE324181 1
eth_CallContract_0x799ebfABE77a6E34311eeEe9825190B9ECe32824 1
eth_CallContract_0x7Fc66500c84A76Ad7e9c93437bFc5Ac33E2DDaE9 1
eth_CallContract_0x8290333ceF9e6D528dD5618Fb97a76f268f3EDD4 1
eth_CallContract_0x845576c64f9754CF09d87e45B720E82F3EeF522C 1
eth_CallContract_0x91Af0fBB28ABA7E31403Cb457106Ce79397FD4E6 1
eth_CallContract_0xA2120b9e674d3fC3875f415A7DF52e382F141225 1
eth_CallContract_0xA9B1Eb5908CfC3cdf91F9B8B3a74108598009096 1
eth_CallContract_0xAC51066d7bEC65Dc4589368da368b212745d63E8 1
eth_CallContract_0xADE00C28244d5CE17D72E40330B1c318cD12B7c3 1
eth_CallContract_0xAE12C5930881c53715B369ceC7606B70d8EB229f 1
eth_CallContract_0xB50721BCf8d664c30412Cfbc6cf7a15145234ad1 1
eth_CallContract_0xB98d4C97425d9908E66E53A6fDf673ACcA0BE986 1
eth_CallContract_0xBA11D00c5f74255f56a5E366F4F77f5A186d7f55 1
eth_CallContract_0xBA50933C268F567BDC86E1aC131BE072C6B0b71a 1
eth_CallContract_0xBB0E17EF65F82Ab018d8EDd776e8DD940327B28b 1
eth_CallContract_0xBe9895146f7AF43049ca1c1AE358B0541Ea49704 1
eth_CallContract_0xEd04915c23f00A313a544955524EB7DBD823143d 1
eth_CallContract_0xF17e65822b568B3903685a7c9F496CF7656Cc6C2 1
eth_CallContract_0xa117000000f279D81A1D3cc75430fAA017FA5A2e 1
eth_CallContract_0xa1faa113cbE53436Df28FF0aEe54275c13B40975 1
eth_CallContract_0xba100000625a3754423978a60c9317c58a424e3D 1
eth_CallContract_0xdBdb4d16EdA451D0503b854CF79D55697F90c8DF 1
eth_CallContract_0xfF20817765cB7f73d4bde2e66e067E58D11095C2 1

no logs

[saledjenic]

On demand strategy was removed, obsolete issue.