Layer 2s are not the end... The best place to begin understanding why is, unsurprisingly, [Vitalik's blog](https://vitalik.ca/general/2022/09/17/layer_3.html). Most importantly, "sophisticated" approaches to L3s > are not just stacking the same thing on top of itself, they're assigning the second layer and the third layer **different purposes**. Vitalik summarizes the three visions of what "L3s" are for: 1. L2 is for scaling, L3 is for customized functionality, for example privacy. 2. L2 is for general-purpose scaling, L3 is for customized scaling. 3. L2 is for trustless scaling (rollups), L3 is for weakly-trusted scaling (validiums). He also makes the fascinating point that L3s can be done in a potentially simpler (and similarly gas-cost efficient way) through leveraging ERC 4337 aggregate verfification and recursive SNARKs or STARKs, as is alrady happening with SHARP, a recursive proof system developed by StarkWare. You can read the details yourself, but the high level difference is: >instead of the middle layer being a complicated full EVM system, the middle layer is a simplified and highly specialized object, and so it is more likely to be secure, it is more likely to be built at all without needing yet another specialized token, and it is more likely to be governance-minimized and not change over time [...] I suspect more sophisticated (and simpler) constructions will start to have a bigger role to play as the layer 2 scaling ecosystem matures. In general, Vitalik's blog is a treasure trove of insights and [this post ranking different kinds of rollups] is also critical to understanding the evolving landscape and the range of solutions being offered by different people. ## Further Resources [AppChains are coming](https://www.youtube.com/watch?v=Zw_tWvg7Ph4) (Eli Ben-Sasson's talk from the same conference provides the context for this, and is described in [[Infra Resources]] in more detail). The AppChain talk highlights how some of the drawbacks of "AppChains" as they have been implemented so far (in Cosmos, for instance) can be largely solved with Validity Rollups like Starknet. The difference between Validity Rollups and Cosmos zones or Avalanche subnets is instructive here. Validators on an app chain in Cosmos can still collude and thereby degrade the security properties of that specific chain, whereas Validity Rollups make sure that each app chain inherits the underlying security of the layer 1, because the results of any computation are always povably correct. There are also good economic reasons to favour this validity rollup over zones/subnet approach: validators in their own zone have no incentive to contribute back to/participate in the base chain (there isn't one). Note: there are different schools of thought on this (as with everything in economics), and Ethan from Cosmos would likely point out that [this kind of localisation is a feature, not a bug](https://twitter.com/buchmanster/status/1330600020173860866). Given that App Chains are coming in many different forms across ecosystems, it's important that we understand some of the more cutting edge cryptographic work on this, for which we turn to [Gideon Kaempfer](https://www.youtube.com/watch?v=5VBP6-6A7eA), in order to understand not just the roots of prover-verifier cryptographic systems, but how they might be built **recursively**. "Recursive" meeans that we can prove the verification of a proof. Which is interesting, because we can prove a bunch of things, and the prove the verification of all those proofs simultaneously, so you do all sorts of things, prove the outputs to be valid, and then prove that validity across all the different verifications in a single proof. ![[recursion.png]]