The problem to solve
Peercoin has a block interval of 10 min, which means that on average there are 6 * 24 * 365 = 52560 blocks minted per year.
At best, this means that at most 52560 people a year can be block minters.
This is an issue because fewer than 100 people control 55% of peercoins (http://bitinfocharts.com), so there are many small holders out there for whom it will be hard to mint any block at all.
This is bound to get worse if Peercoin adoption increases, as there will be even more people competing to mint. If Peercoin is ever used by 500,000 people, assuming an optimal, uniform distribution of peercoins among its users, then it will take about 10 years on average to mint a block, which introduces a lot of variability.
This is in itself an incentive to develop minting pools, which carries a risk of centralization.
This is somewhat mitigated by the fact that Peercoin is designed to give a 1% interest to any holder, big or small. E.g.: you would get a 10% reward if you minted using 10 year-old coins. However small holders are more likely to forego it, if they spend their coin-age (by spending some of their coins) before they are able to mint any block with it.
So if only big holders get a 1% interest while small holders get nothing, it means that only small holders bear the cost of the inflation of the money supply. This could deter people from adopting Peercoin, and fuel the criticism that Peercoin was made to reward early adopters.
My proposal
It would require some protocol changes.
All these issues come from the fact that there is only one user who can mint any given block. So my proposal revolves around allowing multiple users to join stakes and mint a block together.
The core idea
The idea is to use multiple inputs as coinstake kernels, and instead of comparing the hashes they generate individually to the PoS target, we compare the score they get together. Assuming a scheme where inputs must score above a given target to mint a block, we could use the sum of individual scores as the total score.
You might notice that you can reach any difficulty target by simply adding more inputs. I’m not sure this is an issue, as whatever coin-age is used will be destroyed.
Still, to err on the side of caution, we could restrict the use of multi-input kernels to inputs that have good scores per unit of PPC. E.g.: if the latest solo-miners use on average 10 PPC to reach a target of 100, and you only have 1 PPC, you can use a multi-input kernel if your 1 PPC scores at least 10.
How to prevent the centralization of minting power?
Let’s consider the following architecture: users send partial coinstake transactions to the pool server, the server aggregates them into one single coinstake transaction, puts it with regular transactions into a block, signs the block and broadcasts it.
Users could control what the server is minting if each partial coinstake transaction includes:
[ul][li]The hash of the last known block (the one the pool has to mine on top of). This is to prevent the pool from minting on forks.[/li]
[li]The hash of one or a few transactions that must be included in the Merkle tree of the block. This is to prevent DOS attacks.[/li][/ul]
If the contents of the block don’t match, the block is considered invalid. This should ensure that the pool has only limited control over what it mints.
Additionally, partial coinstake transactions should reference the public key of the minting pool, so that only this pool can publish blocks on behalf of its members. Otherwise it could get messy if other people try to double mint with the publicly disclosed partial coinstake transactions.
I hope I didn’t make any glaring mistake there 
Feedback is welcome.