Lens v2 (aka Bonsai) improves scalability and lowers costs by broadcasting tx data to Arweave/Bundlr instead of Polygon. "Data Submitters" accept signed txs from users and submit them to Arweave/Bundlr. "Data Verifiers" then simulate those txs against Lens contracts on Polygon to verify they would've succeeded if they were actually submitted to the chain.

Benefits:

1. The initial idea to outsource data availability and censorship resistance to an existing BFT network is well-intentioned, but Polygon and the EVM are too expensive and slow. Arweave / Bundlr is much more affordable and has lower latency. This is a smart choice.
2. V2 does not break UX because users sign the same tx they would submit to Polygon. That's a major win.
3. V2 enables on-chain composability (ex: posts can be on-chain ERC721s in EVM) but it's optional, not the default, which is much more practical.
4. Data reads can be completely independent of the Lens API, since the data verifier is open source and connects directly to Arweave/Bundlr. This is a major improvement.

Things I would change:

1. Permissionless submission: every client should be able to run a submitter. The main roadblock is spam from malicious submitters. However, submitters cover the Arweave/Bundlr tx costs, and data verifiers can choose to index data only from trusted clients (this requires some form of app signatures--more on that later). Plus bloom filters can be implemented to make checks for whitelisted clients very efficient and reduce the impact of DDOS attacks
2. Bundled txs >>> individual txs: user interactions should be bundled by clients, then compressed (using gzip or zstd) and submitted to Arweave / Bundlr. This would reduce costs even further.
3. DA agnostic: Lens v2 enshrines Arweave/Bundlr as the DA layer of choice at the protocol level. In my view, the protocol should be DA agnostic and support arbitrary DA layers (IPFS/Arweave/Celestia). This decision should be left in the hands of client devs and the community but with initial first-class support for reputable DA protocols.
4. App signatures: data verifiers have no trustworthy way of proving that a tx comes from a trusted client. This makes it difficult to filter out spam and malicious txs. A basic app signature scheme should be implemented so verifiers can reliably filter for trusted clients.
5. Flexible and granular dispatcher scheme: users should be able to set multiple dispatchers AND have control over which actions dispatchers can perform on their behalf. A simple active / owner scheme with permissions mapping would work well and be easy to implement.
6. Bloom filters: if anyone can submit a tx, clients will need a primitive to help filter for trusted clients and txs. Bloom filters can help here by enabling efficient searches of tx bundles for certain app ids and events. This is very important to prevent DDOS from spam submitters; clients can just skip a bundle if there are no whitelisted app ids in the bundle.