From theory to practice, understand Lens Protocol's Layer3 expansion solution Momoka in one article

Written by: Lens Protocol

Compiled by: Peng SUN, Foresight News

On April 27, the Web3 social graph protocol Lens Protocol launched the beta version of its Optimistic L3 scaling solution, Momoka (formerly known as Bonsai), which is now available for Lens developers. Momoka aims to address the limitations of blockchain storage and scalability and the contradiction between these limitations and the large-scale adoption of Web3 social networks. The solution seeks to increase network throughput and reduce costs without sacrificing user sovereignty. Momoka's feature is that it does not compress transactions to L1 but instead sends and stores them on a data availability layer.

1. Scaling Beyond Block Space: Data Availability Layer

As a Web3 social graph protocol, Lens Protocol allows users to own and control their digital identities and social graphs, and it also supports minting any user-generated content (text, music, or video) as NFTs, enabling creators to monetize through NFTs. As of today, although still in the testing phase, Lens users have created and collected over 3.4 million NFTs, with average earnings of about $500,000. While tokenizing content into NFTs incurs certain transaction costs for the security and transaction guarantees provided by the blockchain, it is crucial for content creators to determine whether a specific piece of content is suitable for tokenization, as some content may not require this level of security and assurance.

Data availability layers are used to avoid storing data on-chain, reducing costs by pointing on-chain resources to existing data availability locations (storage), which is a convenient way to scale on-chain ownership information related to NFTs. Similarly, while content on Lens may include actual on-chain transactions, the content data itself is linked to data availability locations, such as Arweave.

Another solution, Bundlr, implements the scalability of Arweave, providing data availability guarantees and allowing the use of EVM-compatible wallets to store DA logic and quickly publish data to Arweave. The DA layer can be used to store native Lens operations, such as posting, commenting, mirroring, liking, and more.

However, storing data on-chain is expensive, and EVM can only handle a limited number of transactions within each block based on the maximum gas limit configured for a block. Polygon PoS has a block time of 2 seconds in a shared block space. Therefore, some delays are inevitable, and the maximum gas limit per block makes scaling high-demand social media operations challenging. Nevertheless, Polygon PoS remains a good solution for protecting blockchain-based Lens artifacts (such as profiles and user network ownership). In fact, much of the user-generated content tokenization can be minted on zkEVM rollups while using the Ethereum network as the final layer.

Generally speaking, high-demand social experiences peak at 25,000 TPS. While Lens Protocol may not require this level of capacity today, scalability remains a key consideration, enabling Lens to provide a social layer for Web3 and support any social network use case. With Momoka, Lens's scalability is no longer limited by block space.

At Lens, we believe that the social infrastructure stack of Web3 should be refined and purpose-built, depending on the type of network artifacts. For high-value artifacts like user profiles, higher security is valuable. For more casual network artifacts like comments, a lighter DA infrastructure layer may be a viable solution.

2. Lens Native Hyper-Scale Solution

Momoka is an Optimistic L3 scaling solution that processes Polygon transactions off-chain to achieve hyper-scaling and reduce transaction costs. While it is important to provide users with ownership and control through blockchain, Momoka adds a new solution for social networks, enabling Lens to offer greater scalability. Momoka does not compress transactions into L1 like L2 solutions; instead, it sends transactions to the data availability layer to optimize costs and achieve the higher scalability required for social media networks without considering the limitations of block space or block time configurations.

Momoka is open-source software, and anyone can run a node in real-time, verifying Lens data availability content publications and related operations through a trustless transaction submitter and validator. Ideally, running a single validator is sufficient for determinism. The long-term goal is to expand Momoka into a complete network protocol infrastructure, where a content publication can be submitted and validated by multiple Momoka nodes to enhance the effectiveness of content publications.

The way Momoka is built does not rely on connection layers like the Lens API; node operators can run nodes completely independently, meaning that even if the Lens API or any third-party access points to Lens Protocol cease to exist, you can always prove the validity of the content. Momoka also supports indexing—this means that through Momoka, node operators can stream and index Lens data without any third party retaining and expanding Lens's permissionless data infrastructure.

Starting today, anyone wishing to run a Momoka node and contribute to the Lens ecosystem can go to GitHub to start verifying Lens data availability transactions.

3. How Momoka Works

Lens Protocol is currently deployed on the EVM-based Polygon network, where all operations such as posting, commenting, mirroring, following, and favoriting are constructed, signed, and sent as transactions stored on the EVM. Unlike the EVM process, Momoka builds transactions that require signatures from wallets (which will pass state on-chain), but does not send and broadcast the actual transactions on-chain.

Instead, transaction signatures and typed data are used to create DA metadata as transactions. Then, the transaction is sent to the DA layer, which includes information such as the block number and block hash at the time of creating the transaction, the signed typed data, transaction signatures, and other key details. The structure of this data only requires one archival node for complete verification.

The EVM functions as a large state machine. The JSON-RPC methods of the EVM allow simulating transactions using eth_call, which can determine the outcome of a transaction (with certain limitations) without needing to send it actually. You can specify a block number to run a simulated transaction and use the signed typed data transaction with typed data. This can be accomplished through every withSig method on the Lens Protocol smart contract. With just one Polygon node, anyone can verify that the data on the DA layer is accurate, valid at that point in time, and complies with the rules of the Lens Protocol smart contract.

Momoka allows the Lens ecosystem to scale to higher TPS (which is currently unachievable on EVM chains) and provides a cost-effective and low-latency solution. This can be achieved without compromising the core value of user ownership and control over their profiles and social graphs. At the same time, the indexing process is familiar to application developers. Using Momoka is optional; those who prefer Momoka can continue to store all information on Polygon. However, if a content publication does not require the functionality of a trustless execution layer, there is no need to use EVM state.

Momoka enables node operators to verify whether specific operations have been executed on-chain according to the rules of the Lens Protocol smart contract (or verified according to any other smart contract rules), while storing the transactions themselves in the data availability layer for verification.

Momoka involves executing the same signing operations as on the EVM chain, but without actually sending transactions on-chain and incurring the gas costs required to execute transactions under EVM state. Instead, a data availability transaction is created according to Momoka rules and exported to the DA layer, accompanied by proofs and required information. This solution allows anyone to cross-check the data, providing guaranteed evidence that the operation must have been executed by a user capable of creating and submitting transaction signatures. The transaction itself is demonstrated through simulation. This approach allows Lens to scale anytime and anywhere based on use cases and content types while maintaining the ownership and trust provided by the blockchain.

Since the data is stored on a decentralized layer, no centralized entity controls the content. Users retain ownership of their content publications, and if any part of the Lens ecosystem fails, the data remains verifiable, accessible, and available for anyone to use. Decentralization ensures that users' data submissions cannot be tampered with.

4. Components of the Momoka Network

Submitters

Submitters are responsible for verifying and constructing DA metadata and submitting it to Arweave. After generating proof for DA submissions, data is uploaded to Arweave via Bundlr, receiving immediate feedback. Submitters must provide proof that anyone can contest. Validator software listens for DA content publications sent from whitelisted submitter addresses and verifies their validity.

To maintain trust, submitters are accountable for their actions and face potential penalties for misconduct verified by the network protocol. Initially, the submitter whitelist will include a single address operated by the Lens core team. As this method proves effective, the system will be expanded to allow anyone to become a submitter, rewarding good behavior and penalizing misconduct. If submitters face no losses, they might flood the system with invalid submissions, overwhelming validators and causing delays.

During the testing phase, the Lens team will be responsible for correcting any errors and plans to offer bug bounties for issues after testing concludes.

Verifiers

Verifiers are tasked with monitoring submitters' DA content publications and confirming their validity. They must follow specific standards when evaluating upcoming content publications, with the primary goal of ensuring that submitters are genuine. Anyone can run a verifier using open-source software with some commands. Verifiers utilize LevelDB for fast storage of results. The code can use forked archival nodes with Foundry's anvil for local machine execution. However, for optimal speed, using an archival node is currently recommended. Running a verifier requires just one archival node.

Timestamps

You might be concerned that submitters could deceive you about which block they submitted to, which is where Bundlr's timestamp proof comes into play. Additionally, each signature has a deadline corresponding to the timestamp of the mined block, and if sent, the signature becomes invalid. Bundlr allows you to request timestamp proof, returning the current timestamp upon storage, enabling anyone to verify its timestamp. This is the true source for determining the appropriate block number to use; we should use the block number closest to the timestamp generated by Bundlr. It is important to note that delays are inevitable due to node software, so if it selects a block number and is verified, it is acceptable if it falls behind by one block number.

5. Backward Compatibility Without Signatures

An excellent user experience is crucial for Lens users. DA content publications work with dispatchers that can post, mirror, or comment on behalf of users. If enabled, it will check the state. The logic of the Lens Protocol contract stipulates that if the dispatcher signs on behalf of the user, the transaction is valid. Users who do not want to trust the dispatcher can still sign typed data with their wallets and submit through the submitter. This process is similar to the current flow, but the transaction is sent to the Momoka submitter instead of the Polygon node.

No Gas

DA operations do not require gas and can be used for free. Clients still need to upload the contentURI to a resolvable location. Submitters pay for storing DA metadata on Arweave through Bundlr, which is significantly cheaper than the cost of executing EVM transactions (up to 1000 times lower).

Collecting

Collecting user-generated content as NFTs has always been a crucial monetization layer in the Lens protocol. While Momoka transactions are not on-chain transactions, in cases where creators set these parameters to enable tokenization, creators or content consumers can "lazy mint" content on behalf of the creators. This means that any content can be monetized as long as there is an idea. We look forward to integrators implementing lazy minting on Polygon as a feature and launching it on Momoka.

6. Momoka Explorer

To make it easier to find any transactions made using Momoka, Lens has built the Momoka Explorer (momoka.lens.xyz) to track and locate Momoka transactions and monitor Momoka's throughput. You can find all the details of the transactions and all related data. The Momoka Explorer also allows verification of transactions through your own node.

7. Momoka Roadmap

The Momoka beta version is now live. Anyone can use the Momoka node validator to prove and verify transactions. Currently, the transactions supported by Momoka include publishing content publications, commenting, and mirroring. Soon, Momoka will support publishing data availability comments to on-chain content publications and vice versa.

In the future, Momoka transactions can operate as a network protocol, meaning multiple nodes must validate transactions to ensure their validity, and nodes can contest each other's validations. The network protocol can also be accompanied by incentive and penalty mechanisms to maintain the protocol's effectiveness.

As Momoka is open-source software, anyone can contribute and help improve it. As more is learned about how Momoka works at hyper-scale, the team will continuously improve the source code and add features.

Momoka is designed as a node network that can serve as a general data scaling solution and can be used for other use cases beyond social networks.