On the scalability issues of onboarding millions of LN mobile clients

The ongoing advancement of BIP 157 implementation in Core provides an opportunity to reflect on the future of light client protocols in Bitcoin and make better-informed decisions about infrastructure needed to support mobile clients at large scale. The current paradigm of Bitcoin's security model has always relied on running a full-node, which may shift with the adoption of Lightning Network (LN), where fast, affordable, confidential, censorship-resistant payment services may attract a lot of adoption without users running a full-node. Designing a mobile-first LN experience opens its own gap of challenges especially in terms of security and privacy.Light client protocols for LN exist (either BIP157 or Electrum are used), although their privacy and security guarantees with regards to implementation on the client-side may still be an object of concern. One of the bottlenecks is likely the number of full-nodes being willingly to dedicate resources to serve those clients. Even with cheaper, more efficient protocols like BIP 157, there may be a huge discrepancy between what is asked and what is offered. Assuming 10M light clients each of them consuming ~100MB/month for filters/headers, that means 1PB/month of traffic to the backbone network. Deploying 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. Unless your light client protocol is so ridiculously cheap to rely on niceness of a subset of node operators offering free resources, it won't scale. It doesn't mean servicing filters for free won't work for now, numbers of BIP157 clients is still pretty low, but what is worrying is wallet vendors building such chain access backend, hitting a bandwidth scalability wall few years from now instead of pursuing better solutions. The LN security model diverges hugely from basic on-chain transactions. Worst-case attack on-chain a malicious light client server showing a longest, invalid, PoW-signed chain to double-spend the user. On LN, the liveliness requirement means the entity owning your view of the chain can lie to you on whether your channel has been spent by a revoked commitment, the real tip of the blockchain or even dry-up block announcement to trigger unexpected behavior in the client logic. Therefore, you may want to introduce monetary compensation in exchange for servicing filters. Light client not dedicating resources to maintain the network but free-riding on it, you may use their micro-payment capabilities to price chain access resources. 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.