On the scalability issues of onboarding millions of LN mobile clients

The ongoing advancement of BIP 157 implementation in Core presents an opportunity to reflect on the future of light client protocols. Trust-minimization of Bitcoin security model has always relied on running a full-node, but LN may shift this paradigm by attracting adoption without users running a full-node. Designing a mobile-first LN experience presents challenges regarding building a scalable, secure, and private chain access backend for millions of LN clients. Light client protocols for LN exist, but their privacy and security guarantees with regards to implementation on the client-side may still be an object of concern. Assuming 10M light clients each of them consuming ~100MB/month for filters/headers, that means you're asking 1PB/month of traffic to the backbone network. If you assume 10K public nodes, like today, assuming all of them opt-in to signal BIP 157, that's an increase of 100GB/month for each. Widening full-node adoption, specially in term of geographic distribution means as much as we can to bound its operational cost. Deployment of more efficient tx-relay protocol like Erlay will free up some resources, but it maybe wiser to dedicate them to increase health and security of the backbone network like deploying more outbound connections.Therefore, monetary compensation may be introduced in exchange for servicing filters. This proposition may suit within the watchtower paradigm, where another entity is delegated some part of protocol execution, alleviating client onliness requirement. It needs further analysis, but how your funds may be compromised by a watchtower are likely to be the same scenario that how a chain validation provider can compromise you. It maybe argued that distinction client-vs-peer doesn't hold because you may start as a client and start synchronizing the chain, relaying blocks, etc. AFAIK, there is no such hybrid implementation and that's not what you want to run in a mobile.