There was some recent talk on Nano subreddit by /u/BuyNanoNotBitcoin which I would like to explore here.
So, DAG structure of the Nano ledger theoretically allows to implement "shard nodes" - nodes which vote on (and keep the ledger of) transactions involving wallets from some subset of addresses. Implementation of such nodes would turn Nano ledger into some kind of distributed storage and would allow to scale almost infinitely.
Basic suggestion: allow shard nodes.
"Shard node" by definition is a node which is vouched for by "Master node". It is allowed to vote on transactions instead of master node. If multiple shard nodes (or shard nodes and master node) vote on the same transaction, only one of the votes are considered (it is a byzantine behavior, similar to node voting twice). Master node can revoke shard node permissions at any time.
I think it requires only small changes to the protocol?
Now, what can we do with these shard nodes? Say, 100 redditors decide to gang up and create a distributed node, best in existence. They choose some master node (there is as much trust in the whole thing as in the master node, want to point this). Some users delegate to the master node, master node gives permissions to the every shard.
Now, every shard picks some subset of address space (they can even adjust it dynamically later). They also choose the subsets in such a way that every address is held by multiple shards (2-3 is enough).
When the transaction comes, only shards which have the sender address in their subset even look on it. Of these shards, one knows it needs to vote (it is first in some order which is obtained from the hash of the transaction). Shards also periodically ping each other to see if anyone went down - in which case, they arbitrage to the master node, and it judges it by proof of authority.
After the transaction is settled, the shards inform other shards of relevant pending blocks - i.e., if transaction is from A to B, then all shards which handle B need to be informed about pending block.
Possible byzantine behavior by shards is easily detected by master node: if some shard decides to vote on things it is not supposed to, and this vote ever gets rebroadcast to the honest shard, it provides the proof of such behavior to the master node. If some shard refuses to vote on things it is supposed to consistently, it also can be detected (albeit, a bit harder).
It is important to organize shard cluster in such a way that network bandwidth is not a bottleneck. I think shards need to be peers of each others if their subsets intersect, and outgoing connections should be distributed randomly in the cluster.