Taking advantage of Zircuit's $ZRC official TGE, let's talk about an interesting mechanism regarding the sequencer in this project.
Zircuit has its own L2, characterized by a solution called 'Sequencer Level Security (SLS)'.
We all know that currently, the input and output of L2 transactions are through the official sequencer of the project party. Of course, due to the existence of ZK/challenge proofs, we generally do not worry about the sequencer being malicious.
Overall, the sequencer is a neutral role, always executing each transaction with integrity.
So, even though the sequencer is neutral, can we strive to have it join the benevolent side?
Thus, Zircuit enabled this SLS mechanism, aimed at isolating 'malicious transactions'.
Generally, how does an L2 transaction go on-chain? It's a simple four-step process:
1. User initiates a transaction and broadcasts it
2. Transaction goes to the memory pool (mempool) waiting
3. The sequencer acts as a neutral party, helping to package it into the block
4. Transaction goes on-chain
However, based on the SLS mechanism, this step has changed to five steps:
1. User initiates a transaction and broadcasts it
2. Transaction goes to the memory pool (mempool) waiting
3. The sequencer acts as a benevolent party, using some tools to check if the transaction is malicious
4. If there is no malice, help package it into the block
5. Transaction goes on-chain
But what if there are suspected malicious transactions? Changes start from step four:
4. If suspected malicious, enter the isolation pool
5. Isolation pool review confirms no errors, sequencer continues to help package it
Or:
4. If suspected malicious, enter the isolation pool
5. Isolation pool review finds it indeed a malicious transaction, then refuses to package it on-chain
The SLS standard for checking malice may use some open-source libraries and have AI assist in the judgment.
In the future, there is hope to achieve some effects, for example: stolen assets may never be transferable or cross back to L1. This is still very meaningful for the current harsh dark forest chain environment.
Of course, since it involves checking transactions, there may inevitably be some collateral damage. However, I understand that by improving the isolation pool algorithm, it can minimize such issues as much as possible.
This is a double-edged sword; the blockchain emphasizes permissionless, which slightly contradicts SLS. From the perspective of normal users, such L2 is indeed a bit safer.
But overall, I feel that although there is a slight impact on permissionless, the improvement in security, especially in protecting inexperienced users, is still quite worthwhile.
Attached at the end: Original paper on Zircuit's SLS mechanism: https://arxiv.org/html/2405.01819v1