Detailed Explanation of Lens Protocol Extension Solution Momoka: Mode of Operation, Basic Composition and Features
Original compilation: Peng SUN, Foresight News
Original compilation: Peng SUN, Foresight News
On April 27th, the Web3 social graph protocol Lens Protocol launched the internal beta version of the Optimistic L3 extension solution Momoka (formerly known as Bonsai), which is available for Lens developers. What Momoka needs to solve is still the contradiction between the storage and expansion limitations of the blockchain and the large-scale adoption of Web3 social networking. The solution tries to increase the throughput of the network and reduce costs without sacrificing user sovereignty. Momoka is characterized by not compressing transactions to L1, but sending and storing them on the data availability layer.
1. Expansion beyond block space: data availability layer
As a Web3 social graph protocol, Lens Protocol supports users to own and control their digital identities and social images, and also supports the casting of any user-generated content (text, music or video) into NFT, allowing creators to make money through NFT. As of today, while still in beta, Lens users have created and collected more than 3.4 million NFTs, earning an average profit of about $500,000. Since the tokenization of content into NFT needs to pay a certain fee cost for the security and transaction guarantee provided by the blockchain, but for content creators, it is important to determine whether a specific content is suitable for tokenization. Content may not require this level of security and assurance.
Data availability layers (Data availability layers) are used to avoid storing data on the chain, and reduce costs by pointing on-chain resources to existing data availability locations (storage), which is a way to expand ownership-related information on the chain such as NFT convenient way. Likewise, while content on Lens may include actual on-chain transactions, the content data itself is linked to where the data is available, such as Arweave.
Another solution, Bundlr, realizes the scalability of Arweave, provides data availability guarantee, can use the wallet supported by EVM to save DA logic, and quickly publish data to Arweave. The DA layer can be used to store Lens native operations, such as posting, commenting, mirroring (Mirrors), likes, etc.
However, storing data on-chain is expensive, and the EVM can only process a limited number of transactions per block based on a block's configured maximum gas limit. Polygon PoS is a shared block space with a block time of 2 seconds. As such, some latency is unavoidable, while the maximum gas limit per block makes scaling challenging for high-demand social media operations. However, Polygon PoS is still an excellent solution for securing blockchain-based Lens artifacts such as personal data and user network ownership. In fact, a lot of user-generated content tokenization can be minted on a zkEVM rollup while using the Ethereum network as the final layer.
Typically, high-demand social experiences peak at 25,000 TPS. While Lens Protocol may not need this level of capacity today, scalability is still a key consideration, allowing Lens to provide a social layer for Web3 and support any social networking use case. With Momoka, the scalability of Lens is no longer limited by the block space.
At Lens, we believe that the social infrastructure stack for Web3 should be granular and purpose-built, depending on the type of web artifact. For high-value artifacts like user profiles, higher security is valuable. For more casual web artifacts such as comments, a lighter DA infrastructure layer may be a viable solution.
2. Lens native ultra-large-scale solution
Momoka is an Optimistic L3 scaling solution that processes Polygon transactions off-chain to achieve hyperscale and reduce transaction costs. While it's important to use the blockchain to give users ownership and control, Momoka adds a new solution to the social network that enables Lens to offer even greater scalability. Instead of compressing transactions into L1 similar to L2 solutions, Momoka sends transactions to the data availability layer to optimize costs and achieve the higher scalability required by social media networks, regardless of block space or blocks Time configuration constraints.
Momoka is an open-source software that anyone can run as a node in real time to verify Lens data availability content publications (Publications) and related operations by operating trustless transaction submitters and validators. Ideally, running a unique validator is sufficient for finality. The long-term goal is to expand Momoka into a complete network protocol infrastructure. A content publication can be submitted and verified by multiple Momoka nodes to improve the effectiveness of content publication.
Momoka is built in such a way that it does not rely on a connectivity layer such as the Lens API; node operators can run nodes completely independently, which means that even if the Lens API or any third-party access point to the Lens Protocol ceases to exist, you can always prove the authenticity of the content effectiveness. Momoka also supports indexing - meaning that with Momoka, node operators can stream and index Lens data without requiring any third parties to maintain and scale Lens permissionless data infrastructure.
Starting today, to run a Momoka node and contribute to the Lens ecosystem, go toGitHubStart verifying Lens data availability transactions.
3. How Momoka works
Lens Protocol is currently deployed on the EVM-based Polygon network, and all operations such as posting, commenting, mirroring, following, and favorites are transactions that are constructed, signed, and sent to be stored on the EVM. Unlike the EVM process, Momoka builds transactions, requires signatures from wallets (which will communicate state on-chain), but does not send and broadcast the actual transaction on-chain.
Instead, transaction signatures and typed data are used to create DA metadata as transactions. Then, the transaction is passed to the DA layer, which contains information such as the block number and block hash when the transaction was created, the typed data of the signature, the transaction signature, and other key details. The structure of this data is fully verifiable with only one archive node.
The EVM functions as a large state machine. The EVM's JSON-RPC approach allows simulating transactions using eth_call, which can determine the outcome of a transaction (with certain constraints) without actually sending it. You can specify a block number to run simulated transactions and use signed typed data transactions with typed data. This can be done with every withSig method on the Lens Protocol smart contract. With just one Polygon node, anyone can verify that the data in the DA layer is accurate, valid at that point in time, and in compliance with the Lens Protocol smart contract rules.
Momoka allows the Lens ecosystem to scale to higher TPS (which is currently not possible with 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 not new to application developers. Using Momoka is optional; people who prefer Momoka can continue to store all information on Polygon. However, if the 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 that a particular operation has been executed on-chain according to the Lens Protocol smart contract rules (or any other smart contract rules), while storing the transaction itself in the data availability layer for verification.
Momoka involves performing the same signing operations as on the EVM chain, but without actually sending the transaction on the chain and spending the gas required to execute the transaction in the EVM state. Instead, a data availability transaction is created according to the Momoka rules and exported to the DA layer with proofs and required information. The solution enables anyone to cross-check data, providing guaranteed proof that the action must have been performed by a user with the ability to create and submit a transaction signature. The trading itself is demonstrated through simulation. This approach allows Lens to scale anytime, anywhere, depending on the use case and content type, while maintaining the ownership and trust provided by the blockchain.
Since the data is stored on a decentralized layer, there is no centralized entity controlling 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 to anyone. Decentralization ensures that user data submissions cannot be tampered with.
4. The components of the Momoka network
Submitters
The submitter is responsible for validating and constructing DA metadata and submitting to Arweave. After the DA submits the proof of generation, the data will be uploaded to Arweave through Bundlr, and an immediate response can be obtained. Committers must provide proof that anyone can dispute. Validator software listens for DA content publications sent from whitelisted submitter addresses and verifies their validity.
To maintain trust, committers are held accountable for their actions and face potential penalties for misbehavior verified by the network protocol. Initially, the committer whitelist will consist of a single address operated by the Lens core team. As the method is proven, the system will be expanded to allow anyone to be a committer, with rewards for good behavior and penalties for bad behavior. If there is no loss for the committers, they could flood the system with invalid commits, overwhelming the validators and causing delays.
During the testing phase, the Lens team will be responsible for correcting any bugs, with plans to offer bug bounties for bugs after testing is complete.
Verifiers¶
The validator's task is to monitor the submitter's DA content publications and confirm their validity. They must follow certain criteria when evaluating upcoming content publications, with the main goal being to ensure that submitters are genuine. Anyone can use open source software to run validators with a few commands. Validators utilize LevelDB to store results quickly. The code is able to use a forked archive node with Foundry's anvil for local machine execution. However, for best speed, an archive node is currently recommended. All that is required to run a validator is an archive node.
Timestamps
You might worry that the committer might be tricking you about which block it made the commit on, which is where Bundlr timestamp proofs come into play. Additionally, each signature has an expiration date that corresponds to the timestamp of the mined block, and the signature is invalid if sent. Bundlr enables you to request timestamp proofs, returning the current timestamp at the time of storage, allowing anyone to verify their timestamp. This is the source of truth for determining the appropriate block number to use; we should use the block number closest to the Bundlr generation timestamp. Note that delays are unavoidable due to node software, so if it picks a block number, and it's verified, it's acceptable if it's one block number behind.
5. Backward Compatibility
no signature required
A great user experience is critical for Lens users. DA content publications work with a dispatcher that can post, mirror, or comment on behalf of users. If enabled, it will pass status checks. Lens Protocol contract logic dictates that a transaction is valid if the scheduler signs it on behalf of the user. Users who don't want to trust the scheduler can still sign typed data with their wallet and submit it via the committer. This process is similar to the current process, but transactions are sent to Momoka committers instead of Polygon nodes.
no gas
DA operations do not require Gas and can be used for free. The client still needs to upload the contentURI to a resolvable location. Committers pay via Bundlr to store DA metadata on Arweave, which is much cheaper (1000x lower cost) than executable EVM transactions.
collect
Collectible user-generated content as NFTs has been a vital 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 creators. This means that any content can be monetized as long as there is an idea. We look forward to integrators rolling out lazy casting on Polygon as a feature and on Momoka.
6. Momoka browser
To make it easier to find any transactions made with Momoka, Lens built the Momoka Explorer (momoka.lens.xyz) to track and find Momoka transactions, and monitor the throughput speed of Momoka. You can find all the details of the transaction and all relevant data. Momoka Explorer also allows verification of transactions via its own nodes.
7. Momoka Roadmap
The Momoka beta is live now. Anyone can use Momoka node validators to attest and verify transactions. Currently, transactions supported by Momoka include posting content publications, comments, and mirrors. Soon, Momoka will support publishing data availability comments to on-chain content publications and vice versa.
In the future, Momoka transactions can be carried out as a network protocol, which means that multiple nodes must verify the transaction to ensure its validity, and nodes can dispute each other's verification. Network protocols can also be accompanied by incentives and slashing mechanisms to maintain the validity of the protocol.
Since Momoka is open source software, anyone can contribute and help improve it. The team will continue to improve the source code and add features as they learn more about how Momoka works at very large scale.
Momoka is designed as a network of nodes that can be used as a general data scaling solution and can be used by other use cases outside of social networking.
