privacy enhancements

[brenzi]

light clients bear the potential to enhance privacy over using public rpc endpoints.

The most trivial example is hat all your accounts and contacts are leaked to the rpc endpoint because apps/js and other wallet UI's fetch all balances and account status. This links all accounts to a person, even if pseudonymous

light clients also leak what storage keys they query. Of course, UI's could do masking and query many more keys than they are actually interested in.

My question here is if it wouldn't make more sense to build in privacy features into smoldot because all UI's depending on it would benefit directly

Caveats:

• it doesn't make sense to query random storage keys becasue it would be too easy to filter out invalid keys where no storage value is set. therefore, the masking must be context-aware and probably cache some state (like a subset of foreign accounts)

[tomaka]

I think you have said yourself why this feature can't easily be built into smoldot.
It's also not easy to get right in general. For example, JSON-RPC clients will probably query the balance of user's account at every block. If you query random other accounts, it's still easy to find out which account is being queried at every block and which are being queried only once or or a few times.

Aside from this, there are a few other ways to improve this:

• Use the mixnet that's being integrated into Substrate (Mixnet integration paritytech/polkadot-sdk#1345), but I've been told that the latency would be awful
• Make light clients connect to each other and proxy requests through each other, so you'd never know whether the request comes from the light client itself or from another random light client that uses it as a proxy. Kind of a poor man's mixnet. Obviously not a fool-proof method, but a mitigation.
• Rotate peer frequently.

[brenzi]

• peer rotation may make things worse, because you'll spread links between accounts even more widely
• sending extrinsics is yet another concern, I'm worried already about pure queries, so the mixnet pallet won't help

mixing storage queries:

• light client p2p mixing may be a nice way forward if we use tor or nym for networking, mixing every single storage key query

masking storage queries:

• admittedly, the lowest level where this can be meaningfully implemented is where storage metadata is known. that excludes smoldot AFAIU