Title: Validium-like scaling solution for non-financial applications

# Title: Validium-like scaling solution for non-financial applications *This post is a continuation of **[The state of scaling solutions for non-financial applications](https://ethresear.ch/t/the-state-of-scaling-solutions-for-non-financial-applications/14336).*** *We'll refer to this scaling solution as a **validium** for simplicity, but some characteristics don’t exactly match the definition of a validium (it can be also framed as e.g. "bundler"*). ## TL;DR - We propose a validium dedicated to certain kinds of non-financial and privacy apps. - Certain kinds of non-financial apps could avoid centralization caused by MEV by running on a separate non-financialized platform. - To be decentralized and scalable, the validium **takes advantage of the fact that certain kinds of apps don’t require transaction ordering, and have a loose data availability requirement.** - This validium supports the following types of apps - Decentralized social media (e.g. Farcaster, Lens Protocol) - Publishing (e.g. Mirror) - Anonymous signaling (Heyanon) - This validium does NOT support the following type of apps - DeFi - Voting ## Motivation We believe that it is important to have a light-client-friendly infrastructure not only for financial apps but also for non-financial apps. Given the difference in assumptions/security requirements between financial and non-financial apps, we propose a validium-like system that can potentially provide higher scalability and decentralization than existing validiums, for certain kinds of non-financial apps. ## Validium for signature/zkps verifications Let’s consider a validium that only verifies signatures and zero-knowledge proofs. Importantly, this validium doesn’t involve any asset transfers. ### **The state** The state can consist of verified data accompanied by the verification method (e.g. ECDSA, Groth16 circuit identifier, etc). It could be managed by a Merkle tree or a Verkle tree. Moreover, by using a Verkle tree or Merkle tree with SNAKRSs, the user verification complexity could be _tuned_: one can imagine in a social media app, **instead of asking for an inclusion/verification proof for each post in the current feed, it is more efficient to request a single proof that validates 30 posts that will be shown in the feed.** ## Sequencer decentralization Taking advantage of the fact that the double-spending problem doesn’t exist for apps that this validium expects, **we can allow any sequencer to submit any valid data at any moment in time.** In regular validiums, such total anarchy is extremely inefficient because the sequencers cannot know the would-be state at the time their batches get processed. In other words, batching transactions on top of the correct `prev_state_root` will be hard, since other sequencers could update the `prev_state_root` at any moment. **Although in this validium which only verifies proofs and doesn't order them, we can separate the variable `prev_state_root` per sequencer. The idea behind this is: we can take advantage of the fact that transactions aren’t related to each other.** In other words, we don’t need to have a consensus on **when** proofs get into the state. ## **The validium smart contract** The validium smart contract (the smart contract that sequencers submit proofs to), will verify the proofs and store the sequencer state roots. This decouples each sequencer’s state updates, allowing anyone to submit any valid data at any moment in time. Sequencers should provide a validity proof (i.e SNARK) that proves - the validity of the Verkle tree update. - the validity of each leaf (i.e. validity of a signature) ## Light clients Lights clients verify data, by checking 1. the state root of Ethereum 2. the inclusion of the sequencer root in the Ethereum state root 3. the inclusion of the data in the sequencer root 1 . is possbile with the [light-client sync protocol](https://github.com/ethereum/consensus-specs/blob/dev/specs/altair/light-client/light-client.md) , and 2., 3. are possbile using Merkle or Verkle proofs. ## Data availability The question of data available persists for this validium as well, so applying DAS or similar methods is ideal. However, since there are no _funds_ in this validium, the consequence of unavailable data is less severe for most situations, compared to financial validiums. Even in a case where data never gets published or gets lost, end users can submit signatures again (to a different sequencer if necessary). Furthermore, for redundancy users can share the data they intend to publish to multiple sequencers, and only send the verification request to a single sequencer. ## **Possibly higher censorship resistance than Ethereum due to the non-existence of MEV or a similar centralization vector** Centralization vector regarding sequencers exists for this validium design, but it is presumably less severe than MEV in Ethereum. However, since this validium relies on Ethereum for verifying state roots, it's subject to e.g. censorship in Ethereum. Therefore, a transition to a standalone chain while preserving light-client friendliness might be necessary. Which could eventually have a property of a constant-size blockchain akin to [Mina Protocol](https://minaprotocol.com/). ## Status of the design We are actively assessing, modifying, and prototyping this design. Please leave a comment if you spot critical issues, know an existing similar solution, or have any questions.