One of the most exciting TON usecases, is the opportunity to c | TON technical overview

One of the most exciting TON usecases, is the opportunity to create a token working on external messages. How it is supposed to work?
There are users with their balances and there are gas providers, people who are willing to pay transfer fees in grams in exchange for a commission in tokens. Users send an external message transfer, choose a gas provider with the best price and pay a commission to him.
That way, the user should not bother that in order to send his "shiny tokens" he needs to first top up his account by grams and make sure that the balance is greater than a certain limit. He may not even know that the token works on TON. Got a public key? Tokens can be sent to it (without any preliminary preparation). Are there enough tokens on the account of the corresponding key? You can immediately send them without worrying about buying grams.
This is a killer-feature, which, coupled with a huge user base, would instantly transfer to TON points of brand loyalty, airline miles, tokenize in-game resources, etc.
Unfortunately, it seems that low gas-credit and growth of the cost of working with dictionaries as the dictionary grows, kills this idea.
In this repository, https://github.com/EmelyanenkoK/TON_tokens is the result of a couple of weeks of reflection and several days of work on that kind of token. Yesterday and today I spent some time on optimization (thanks @akifoq for help), but I did not achieve stunning results.
If the balance sheet is empty, all checks which should be done before accept_message fit within the limit of 10k gas credit, but when number of users grows to a thousand, the first attempt to find the sender balance in the dictionary overflows. It should be noted that the cost of searching in the dictionary grows logarithmically with the size of the dictionary, so that problem can, in principle, be mitigated.
For instance, increase of gas credit to 50k already allows to work with 100k users. Another way is a substantial (for example 20x) discount for non-changing reading from dictionaries.
Finally, the possibility of optimizing the token code is probably not exhausted yet.
P.S. I will be glad to see pool requests with optimizations, you can test the correct work of the token using the script test_external.fif, also you can test the operation of the token with a large balance dictionary using script test_external_highload.fif