I have also started on my implementation of ERC20. Have not tested anything yet, but the general idea is to try to have a holder contract being able to hold arbitrary number of tokens, instead of having one holder contract per (token, owner) pair. I might also do data analysis on what is current number of these pairs.
Code is here, but tests will come later: https://github.com/ledgerwatch/eth_state/tree/master/erc20
FYI, the linked contract is the .eth registrar, which hands out new domains under .eth; ENS itself is here, and its source is here). (deployed LLL version here). The same mitigation would apply, although it could be difficult to eliminate all possible storage of data on behalf of others when it comes to name issuance etc.
Another example of this issue is the DNSSEC Oracle, which allows anyone to submit a proof of existence of a DNS record.
I have written tests for token minting and transfer, and they pass. I did not test one holder having multiple tokens yet, but will add it in couple of days. Working with CREATE2 without extra tooling is a bit painful, of course. Here is the working token contract: https://github.com/ledgerwatch/eth_state/tree/master/erc20
@antoineherzog you wanted to see this
It looks very good 
i can see how we can improve the smart actor contract now to delegate any transfer authorization from the ERC20 contract to the smart actor contract by calling a isTransferAuthorized method. Then we could add very cool feature such as: improving the security of an account by switching from 1 sig to multisig or implementing a shamir secret procedure for private key recovery 
I am publishing an article about that tomrorow.
More data on ERC20 tokens (at block 6856437, which was 9th of December 2018).
From my previous data, containing 71k+ ERC20 token contracts, I filtered out non-contracts, self-destructed contracts, those which do not have working balanceOf() method, and those that are not storing token balances in a straightforward way as Solidity mapping, and those that do not have any holders. 59986 contract left from such filtering.
(token, holder) pairs: 55’494’243
Tokens: 59’986
Unique holders: 18’628’814
Top 40 tokens by number of holders:
1,LivePeer_Token,2598037
2,TronToken,1063737
3,VIUToken,956329
4,XENON_Token,747466
5,OmiseGo_Token,649854
6,VinToken,478881
7,Streamr_Token,434733
8,BeautyChain_Token,364840
9,EOS_DSToken,330606
10,UCashToken,318759
11,GSENetwork_Token,305723
12,BinanceToken,301538
13,GSG_Coin,285302
14,MST_Token,244130
15,SoPay_Token,229642
16,BitClave_Token,220350
17,OCoin,216915
18,StatusToken,196825
19,BOBsRepairToken,195309
20,DecenturionToken,193224
21,BeautyChain_Token?,192536
22,BitcoinEOS_Token,184420
23,DataToken,184352
24,PentaNetwork_Token,178805
25,EMO_Token,173647
26,DRC_Token,170303
27,EthLend_Token,163939
28,AVINOCToken,163272
29,IFoods_Token,155379
30,ForAgricultureCoin,152910
31,NePay_Token,152626
32,OrmeusCoin,149907
33,BrahmaOS_Token,146113
34,StorjToken,144979
35,HashPowerToken,143476
36,ThreeDBToken,141585
37,FTI_Token,141400
38,DACC_Token,140218
39,XMAX_Token,139284
40,ExTradeCash_Token,133536
Top 25 holder by number of tokens:
1,EtherDelta_2,6711
2,IDEX_1,1340
3,3463934897d356b8659cbdfe15209e3bc3229105,1116
4,ea3a8bd1a99e16160832d6b473ce06c1058dff7e,1091
5,Freewallet,788
6,5bd5d826e4275a2180e8c5fa3c80a66ca461a375,772
7,0000000000000000000000000000000000000000,715
8,57a3e7088651b237cd363d7025554a63d47fc21f,675
9,3a2e3849945aae6b87e0ef4d13940049681e0b36,666
10,873dc5af4b3845ac90daa78383909f25efe295ac,658
11,30c8d95fb80c874dc285284147d4b4a4faeb05a9,643
12,81cd2b96a2a7625fe76f5f8c5e3032843268cc82,633
13,6204c634f06fa6a45e1f0e2a89c752f8450cdfad,629
14,Bittrex_1,627
15,f488efa00caf5bab853c7334688a5bf57db0eb7f,609
16,345f4e88905cfa1605b5f56167af7d0caa59ae74,601
17,cdae6e5d38605a4f428f2ed7c811a579d213bb97,601
18,edfc8b4d5e243e9e797b1292a6e0c4ec600dac26,595
19,3f5ce5fbfe3e9af3971dd833d26ba9b5c936f0be,589
20,51ec49876fd0f9e4bf72998fb24cd82e05802fbb,585
21,a12431d0b9db640034b0cdfceef9cce161e62be4,577
22,8460b752d49de926c8c623b4a836eb7bd402930c,562
23,TokenStore,562
24,23ef66867765adfaa9dbc518c76b42865710a114,560
25,ba95b4a5b130c4c1d27dc9e8adcf7f087cdb4c52,555
FYI 
imho the root of the problem is that non-mining full nodes in ETH are not paid anything. That is why people are not able to buy enough storage and compute.
There are hundreds of millions of dollars per year paid to miners.
imho, one needs to figure out a way to pay a portion of this money to full nodes, and then each of them will be able to handle 1000 times more storage. The current ETH storage is tiny by enterprise means.
If ETH 2.0 is going to have 100 chains, these chains can not be stored altruistically. Therefore, the problem of paying nodes for storage needs to be solved anyway. If this problem is solved, storage rent will simply not be needed in my view.
You are partially right. Partially, because it is not just storing the state that matters, but also downloading it in a “trustless” way when you join the network. This problem of downloading needs to be addressed regardless whether we want to reduce the state growth or not, and I might have something to show on this front in a few months (with my new Morus database that I am developing in collaboration with Ethermint).
If someone figures out how to pay full node, that would be great! I do not see that anyone has done it yet, therefore it is not wise to just abandon the State Rent work. Although I am pretty neutral on whether it has to be introduced or not, I will continue working on it. If we keep giving things up as soon as someone brings up an alternative (but does not actually implements the alternative), nothing non-trivial will be done.
Ok - here is one interesting idea to pay to a full node by introducing the “PoW fuel” abstraction explained below:
Introduce fuel costs for EVM read calls. Basically a node that responds to a JSON read call will require PoW from the client, proportional to the gas spent in the read call. Currently read calls are free, what is proposed that you charge for them as for write calls.
Let the node post the gathered “fuel” from time to time to a bounty smart contract on the main net to get ETH printed in return.
Thats it. The nodes will respond to read calls, gather “fuel” and from time to time go exchange this fuel for real ETH.
Clients would not need to do the PoW themselves, they could pre-pay to third party providers. In additional, to be on the greenish side, one can consider using VDF functions(?) instead of PoW.
In this case how would you prevent double spending of the PoW? Especially if you want to batch PoW submission, there needs to be an efficient way to validate whether the PoW had been submitted before.
There’s also a fair exchange problem. A user has a piece of PoW and the full node has the solution to their query, but they must be able to perform the exchange without one having the ability to cheat the other.
Finally, what’s to stop mining of PoW in the system to extract value without actually filling queries?
Harry - totally - these are the hard questions that need to be addressed … )
I think if someone mines the PoW just to make value it is not a big problem since it just becomes another crypto currency in a certain sense. One can map PoW to ETH and pay people in ETH, or you one have a “fuel” crypto currency (ERC-20 token) so people asking nodes for read calls for would pay nodes using this token. If someone else mines the token by directly exchanging PoW for the token it will be totally fine.
I think the PoW should include the node ID / public key in some way so others can not claim it.
There “comb inability” property is the hardest one. One should be able to somehow combine many “small” PoW into one succinct PoW proof. May be one can use STARKs for that.
Another possibility it may be use g^2 group squaring algorithm similar to VDF - people could keep up squaring a group element, so each call could correspond go further squaring …