Plasma is Back! What is the “true L2” that Intmax will achieve?

One of the highlights of EDCON2024, held in Yoyogi in July 2024, was the Plasma community side event called ” PLASMACON “, hosted by Intmax.

Some readers may feel nostalgic when they hear the name Plasma . This is because this technology was announced seven years ago in August 2017 as a solution to Ethereum’s scalability issues. Nowadays, scaling solutions refer to “L2” that employs rollup technologies such as ZK-Rollups and Optimistic Rollups, but in 2017, it was the dawn of the era when the term L2 did not even exist, and Plasma was the research topic that the Ethereum community, led by Vitalic, focused on. However, as described below, it declined due to certain technical issues, and the scalability issues were passed on to the L2 trend that came afterwards, and have continued to this day.

Why has the Plasma community, which once lost momentum, returned to the forefront of L2 after seven years? How is it different from traditional L2? And what are the core values ​​of Intmax , led by Japanese founder Reona Hioki ? In this article written based on the interview by Kenta (CEO of Bunzz), we will trace the history of scaling solutions based on an interview with Reona Hioki, and provide an easy-to-understand explanation of Intmax’s technology, which is the culmination of Plasma and ZK technology.

Source: Intmax official X
Source: Intmax official X

Interview by Kenta (CEO of Bunzz)

■CEO / Kenta Akutsu Profile 
In 2019, he won the Computer Software Association Award and a second prize at the Blockchain Hackathon 2019 hosted by the Ministry of Economy, Trade and Industry. In August of the same year, he founded LasTrust Co., Ltd. as a web3 startup. In 2021, he sold his first product, CloudCerts, to a listed company. In 2022, he founded Bunzz pte ltd. He launched Bunzz as his second product. He mainly oversees new business development in the blockchain field and provides value in the driven field.

[Presentation history]
"FIN/SUM BB 2020" sponsored by the Financial Services Agency and the Nihon Keizai Shimbun,
"Scheme D" sponsored by the Ministry of Education, Culture, Sports, Science and Technology (pitch actor certified by the Ministry of Education, Culture, Sports, Science and Technology)

[Awards]
Winner of B Dash Crypto 2022 Web3 Pitch Championship
Nominated as "92 companies selected by VCs and CVCs" in Nikkei BP's "Startups"
Bronze winner of "Unicorn Pitches Japan" Winner
of "World Communication Competition 2021" Winner of
the judging committee award of "ASPIC IoT / AI / Cloud Award 2020"
sponsored by the Ministry of Internal Affairs and Communications Winner of "Blockchain Hackathon 2019" sponsored by the Ministry of Economy, Trade and Industry
Winner of "World Communication Competition 2021".
 

Has L2 (Layer 2) solved the fundamental scalability problem?

As you know, Ethereum has a limit to its ability to process a large number of transactions and smart contracts. The more data recorded on the chain, the more congested the network becomes, the longer it takes for transactions to be confirmed, and the higher the gas fees become. It is possible to increase throughput and improve processing power, but on the other hand, this reduces the accuracy of verification and sacrifices security. Reducing the number of nodes that record transactions can shorten the verification time, but this comes at the expense of decentralization. The scalability issue can be said to be one aspect of this so-called “blockchain trilemma.” All L1s, not just Ethereum, are facing the fatal contradiction that “the more widespread it becomes, the more inconvenient it becomes.”

What is the key to the solution? The current goal of L2 can be summed up in one sentence: “How to avoid writing data to L1.” And, “Where can we securely store the data that is not written to L1?”

  1. Transaction details of each user
  2. Token sending and receiving history
  3. Smart contract execution results

In addition to transaction details such as the above, temporary status information for each transaction called “state” (such as changes in account balances and changes in the internal state of smart contracts) was written to L1, but the L2 approach is to record these instead in L2 and write only the final result to L1. Since the state is in L2, it is also called a “stateful chain.” However, Mr. Heki and the Plasma community have strong doubts about this.

Hioki: “I think that the current (stateful) L2 is gradually losing its meaning as a scaling solution. What I mean is that L2 does not fundamentally solve the bottleneck of ‘data retention.’ For example, what Rollup does is to temporarily store transaction data in L1, and after about a month, store the data on only about 15 L2 nodes. This method does not put pressure on the block space of L1, but since the number of nodes is small and not distributed, if a node is attacked and transaction data is lost, there is a risk that users’ assets will also be lost.”

Source: zkSync documentation. Life Cycle of a transaction on zkSync

The reason why user assets are lost when a transaction under the management of an L2 node is lost is because the final result written in L1 cannot be proven. This problem is called the “Data Availability Problem (DA problem).”

What is the DA problem?

Scaling solutions make heavy use of a cryptographic technique called hashing to consolidate multiple transaction data. In simple terms, applying a hash function to transactions A and B results in a unique and lightweight value called hash value (C), and the correctness of transaction data A and B can be proven by writing only (C) to the chain, which ultimately reduces the burden on the chain (two or more transactions can be hashed together).

The problem is that if any transactions are lost, (C) cannot be restored.

Source: Provided by Intmax

In other words, even if only the final result is extracted and written to the chain, the transaction data to restore it still needs to be stored somewhere other than L1 (all of the bottom row HA to HP in the diagram above).

Although L2 stores data in nodes, its decentralization is fragile, and it can be said that the problems that occurred in L1 have simply been transferred to L2, so isn’t this a one-sided scaling solution? This is the common opinion of researchers in the Ethereum community, including Mr. Hioki. In fact, the Rollup-based L2 itself was aware of this problem, and initially referred to its chain as “L1.5.”

For these reasons, the DA problem was a deep-rooted problem that stood in the way of L2 scaling. The technical challenges that led to the temporary decline of Plasma were also largely due to this DA problem.

The Plasma Community’s Technical Achievement: Stateless Chain

In other words, to fundamentally solve the scalability problem, it is necessary not to write the state to L2, and to store the transaction data that supports the final result written in L1 in a “decentralized” location outside of L2. This is a difficult problem that is almost like a cryptographic feat, but groundbreaking technology has been developed in the past few years.

Hioki: “The technical breakthrough that eliminated the need to reconstruct transactions was the invention of recursive ZKPs and the Plonky2 framework, which can handle recursive ZKPs at high speed.”

We will go into more detail later, but these technologies have made it possible to securely verify and store transaction data and states off-chain, thus resolving the DA problem and creating the scalable chains that the Ethereum community has long awaited. These are called “stateless chains” because they do not have state on the chain.

(Below is a comparison of the characteristics of the Intmax deck with Rollup chains and the Lightning Network.)

Source: Provided by Intmax

What Intmax, a stateless chain, has achieved

Now that we have looked back at the history of L2, let’s take a look at how Intmax has used recursive ZKP technology and what it has achieved.

Hioki: The problem with L2 scaling is that all transaction data must be stored in order to record Merkle Proofs (hashed transactions) on the chain, but Intmax’s idea is that if we give Merkle Proofs to users, there is no need to store them on the chain. In this chain, when a user issues a transaction, they are guaranteed to receive a transaction receipt called a ZKP proof (this also includes Merkle Proofs, which are hashed versions of other users’ transactions).

Source: Discover INTMAX’s Stateless zkRollup Protocol
Source: Discover INTMAX’s Stateless zkRollup Protocol

In the diagram above, only the root is recorded on the chain, and the hash and transaction are stored by the user along with the ZKP proof in the form of UTXO. In Rollup, storing hashes and transactions on the chain was a problem, but by handing them over to the user, it has succeeded in significantly reducing the burden on the chain. Even the expression “significantly” may be an understatement. The amount of data written to the chain by the root is only 32 bytes, and it is possible to aggregate an almost unlimited amount of transactions on the chain, with scalability that overwhelms conventional L2.

Source: Discover INTMAX’s Stateless zkRollup Protocol

However, simply guaranteeing one transaction with one ZKP proof can only prove the correctness of one block. To make the entire history of the chain consistent, a “connection” is required that allows ZKP proofs to prove each other’s correctness. Recursive ZKP technology makes this possible. Please take another look at the diagram above. Before a user issues a transaction, they have the ZKP proof generated in the previous transaction. When a new transaction is issued, “a new ZKP proof is generated, including the previous ZKP proof.” In other words, the latest ZKP proof always contains the entire correct history. Its unique feature is that the latest proof alone can prove the correctness of the entire history of the chain.
(For a more detailed understanding, we recommend
this official video .)

Source: Discover INTMAX’s Stateless zkRollup Protocol

Intmax is a blockchain with a whole new feel

As mentioned above, the Intmax chain only records the final result called Root. It is also encrypted with a hash function, so it is just a string. In other words, “there is no concrete information even if you view the chain.” In a normal chain, you can view the balance and transaction history of accounts in wallets other than your own. This on-chain data makes analysis and copy trading possible, but since Intmax does not have it, you cannot build applications that use on-chain.

It doesn’t even have a block explorer like Etherscan, and it feels different from any chain we’ve ever come across.

Heki: “Having user data on-chain is a weakness for us. One of Intmax’s core values ​​is ‘ultimate privacy.’ From this perspective, being able to view wallet information on-chain is actually a disadvantage. Intmax, all transactions are calculated and stored off-chain. Since nothing happens on-chain, the system is set up so that no one can know anything that happens on the user’s behalf.”

While many users have grown accustomed to their transaction data being public, this does pose risks and real harm, as attackers can use on-chain data and wallets as a clue to develop their attack methods.

Intmax Use Cases

Because it is a privacy-focused chain, its use case is ideal for stable and ultra-low gas payments and asset storage. Even if Intmax scales to 1 billion users, the gas fee remains constant. Data is stored on each of the 1 billion devices, and the ZKP circuit that generates ZKP proofs is also attached to the user’s app. This is because transactions for 1 billion users are calculated in parallel on 1 billion devices. Since all transaction data is calculated and stored off-chain, it has the characteristic of being almost infinitely scalable.

On the other hand, it is not suitable as a chain for deploying DApps, and basically you cannot even deploy smart contracts on Intmax. If a third party develops an application using Intmax technology, it may be that they will extend the UI or link an external smart contract on a different chain and wrap Intmax.

Hioki: “I would like people who want to build practical payments and ensure compliant privacy to try it out.”

Source: Provided by Intmax

Deploy Solidity-written smart containers

Among the Plasma series, there is a chain called Plasma Free that supports EVM and can deploy DApps, and it has partnered with Intmax. If you are interested in developing applications on stateless chains, please check it out. Bunzz is also considering supporting Plasma Free as a development infrastructure for smartphones and plans to make it possible to easily deploy contracts on Plasma Free using only a GUI. In addition, Bunzz Audit is considering offering discounts on audit tickets to teams considering deploying DApps on Plasma Free. If you are interested, please contact us here.

Intmax Summary

What did you think? I hope you’ve been able to understand that Intmax is a new L2 that specializes in scalability and privacy. Bunzz requested an interview because of the Intmax team’s design philosophy, which focuses on privacy and security.

Although Rollup chains still have DA problems, that is why they have given birth to a variety of use cases. Assuming that stateless chains such as Intmax are not in conflict with each other but have different design philosophies, Heki said, “Finally, L2 was born” regarding Plasma chains, including his own chain. I’m looking forward to seeing them popularize chains at the forefront of the Ethereum ecosystem in the future. DApps and use cases are essential for chain-driven. Builders should definitely try out Intmax’s technology.

Share this article: