2 possible solutions to avoid (cryptokitties) network congestion

Hi guys,
i've thinked two possibles solution to process peaks in ethereum network avoiding delays;

solution 1: ensure heterogeneous transactions inside blocks

when more processes runs on a single cpu they must share cpu time; in the same way when a lot of transactions (a peak) are pending on a single smart contract miners should makes blocks taking into account that the whole network must continue working.
To achieve this goal the network should ensure that transactions inside block must cover all smart contracts waiting for pending transactions, avoiding that a single smart contract cover almost all miners computational power (rejecting blocks that not follow this rule).



solution 2: dynamic difficulty

I expose this idea using a simple use case with imaginary values:

t0: network is working without delays while serving at most 1k transactions per second (difficulty=x)

t1: clients starts sending an high number of transactions, e.g. 10k transactions per second

t2: network detect the high number of requests and enter "quick hash" mode; in this modality

1. difficulty is decreased proportionally to the number of exceeding requests (eg difficulty=x/10)
   
2. every 5 minutes one block must be hashed using difficulty=x
   
3. transactions will be confirmed only after a block is hashed using difficulty=x
   
4. no transactions will be accepted while there is a pending transaction from the same address
   
5. mining fee will be proportionally to the decreased difficulty
   

t3: network start serving 10k transactions per second without delays

t4: network detect that all exceeding requests has been served and exit from "quick hash" mode

every block (from the eventually adoption of this modified protocol) must contain in the header the number of exceeding transaction (eventually 0)detected from the network; the history of numbers of requests per minute must be manteined in a certified source (or another blockchain)



I hope this may help you