The deep dive into statelessness ~Intmax2 algorithm was published~

In this article, we introduce the concept of the Stateless zkRollup of INTMAX.

This update successfully transitions the zkRollup into a fully stateless and client-side dependent system, reclaiming many aspects left behind by the stateful Ethereum L1/L2. It achieves extreme scalability and privacy, full democratization of block generation, and interoperability. This could signify the onset of truly convenient decentralized payments.

The core of this Stateless Layer is built upon an algorithm called Intmax2, which can be considered as an improvement of zkRollup.

The paper link: https://eprint.iacr.org/2023/1082.pdf

This powerful algorithm introduces several features that were unthinkable in zkRollups:

• Block producers remain unaware of the contents of each transaction or its validity.
• The cost of data availability is 4~6 bytes per transaction, and a large number of token transfers can be made in one transaction without additional DA (Data Availability) costs.
• An invalid transaction can become valid later through deposits.
• Both data storage and ZKP computations get to O(1) on user-side.
• Subscription payments are available.

Why do these properties emerge? We will explain this through the evolution from client-side balance computation to the new Intmax2 algorithm. (This is not exactly how Intmax2 was conceived and developed, but it is the easiest way to explain Intmax2 here.)

So, what exactly is client-side balance computation? Here is a simple example.

Imagine only the following two items are written on the blockchain:

1. Alice mined 100 coins.
2. Alice sent 20 coins to Bob.

Even if the node doesn’t calculate anyone’s balance, everyone can compute it client-side and arrive at the same conclusion: Alice has 80 coins. As long as there’s consensus on the finality of the Layer 1 blockchain, everyone will reach the same conclusion. Therefore, this can be said to have the same security as Layer 1, akin to Layer 2. Balances like Ether, ERC20, and Bitcoin can be calculated client-side without nodes having to do the computation.

However, since the node doesn’t verify whether the transaction to be posted is valid, it can end up posting incorrect transactions. In the above example, what would happen if a transaction is posted in 2) where Alice sends 120 coins? Alice must not only post the transaction to Bob and pass the proof of that transaction to Bob, but also prove that she had a sufficient balance. Let’s call this set of two proofs — proof that the transaction is on the blockchain, plus proof that there was a sufficient balance for that transaction — a proof-set.

So, what does this proof of having a sufficient balance entail? It’s proof of a deposit from someone else, a proof which was sent from the previous sender. The balance proof in that proof-set is the proof-set that the sender before the sender sent. In other words, the receiver verifies the previous proof to check the proof, and so on, recursively. This process can be quite lengthy if done manually. Such client-side balance computation is primarily used off-chain on Bitcoin, with RGB being a typical example.

Now, isn’t there a way to verify this instantly instead of verifying it recursively indefinitely? Let’s employ a ZKP that can recursively repeat infinitely.

Cyclic recursive ZKP repeats the verification of another ZKP proof in a ZKP circuit indefinitely. Interestingly, if you prove what the previous ZKP has verified, you can inductively verify the validity of all previous ZKPs. This is the mechanism that Mina protocol uses to verify blockchains.

Obviously, this can be used to verify client-side balance computation. In other words, each time a proof-set becomes a cyclic recursive ZKP, the next person only needs to verify that ZKP, input it into their circuit, and create a new ZKP. There’s no need to verify it recursively many times.

Let’s combine this mechanism with the previously existing mechanism of Intmax1. To put it simply, the mechanism of Intmax1 allows sending a lot of tokens with almost no DA cost. The block producer distributes the balance’s Merkle Proof, and it can be used for Exit in a manner that has been discussed since Plasma, eliminating the need to place transaction data in calldata or blob. You can consolidate a large number of token transfers into a single transaction of 5 bytes.

What if we utilize this distributed proof for the first proof in the proof-set, which is proof that the transaction is recorded? The data storage and ZKP computation, typically performed by validators in the regular zkRollup do, are now decentralized to the user side in O(1)!

Protocol Level Subscription Payments

Unlike all other L1s and L2s, our protocol enables trustless subscription payments, like monthly payments. This is one of our achievements, which had been extremely difficult before the advent of ZKP & stateless architecture.

Detail: https://ethresear.ch/t/a-subscription-protocol-with-a-constant-and-minimal-cost-for-nodes

How to deposit money from other L2s and how to avoid client-side zkp

Intmax1/Intmax2 enables the compression of DA costs, which involve a large number of token transfers, into approximately 4 to 6 bytes within a single transaction. However, most users do not typically consolidate multiple transactions at once. To effectively reduce the cost of each payment consistently regardless of conditions, it is highly advantageous to introduce one-way payment channels.

The users open dedicated payment channels to intermediaries in the INTMAX Network. These intermediaries then aggregate all the individual payments to different recipients from the users and handle them as a single bulk transfer. The proof of this delegated payment, as a condition of HTLC (Hashed Time Lock Contract), allows for the update of each payment channel. As a result, the 4 to 6-byte DA cost is divided among a large number of users, such as 1000, reducing it to a completely negligible level.

It is important to note that the balance in a user’s one-way payment channel decreases over time, and there is no risk of broadcasting old states and suffering losses. This eliminates the need for nodes and watch-towers from the user side while intermediaries need to be online. As long as payment proofs on Intmax2 remain verifiable, users can open payment channels on various Layer 2 solutions, enabling extremely low-cost transfers to INTMAX addresses from diverse L2 environments.

These L2 Interoperability and Channel aspects were intentionally left out of the Intmax2 paper, but it allows for interoperability and further extreme cost-cutting, making it a necessary component for the actual productization of Intmax2.

Advantages of Rich Statefulness and Statelessness

As is widely recognized, rich statefulness is essential for public smart contracts and is the soil for producing a rich ecosystem on Ethereum. Many Layer 2s inherit these benefits. INTMAX’s Stateless Layer is designed to reclaim the aspects — extreme scalability, privacy, and L2 interoperability — that rich statefulness has sacrificed as a consequence.