During the re-staking boom at the beginning of this year, the name Zircuit first appeared in everyone's vision. This ZK L2 endorsed by Dragonfly and Pantera has become the final destination of many LRT tokens, and its TVL has risen rapidly after its launch. However, apart from the benefits and points, most people's impression of Zircuit remains on "another L2".

Recently, after an in-depth exchange with Martin, co-founder of Zircuit, I began to be full of expectations for the future of this new L2. In the context of L2 "aligning with Ethereum", Zircuit firmly chose pragmatism, not only "playing with flowers" on the sorter, but also finding a new way out for the troubled L2.

"Orthodoxy" is no longer suitable for L2

Every crypto practitioner is a super supporter of distributed ledgers, pursuing absolute openness and immutability, until the theft happens to them.

If you have ever experienced a hacker attack and watched the protocol assets being looted, you must have thought: "It would be great if the transaction could be rolled back." Of course, this is a "politically correct" issue that is not allowed to happen in the crypto field, both from a technical and ideological perspective. In the world of distributed ledgers, consensus is God. Once consensus is formed, it has absolute authority, and individual justice must be sacrificed in the face of collective fairness.

Interestingly, this industry seems to pay too much attention to the process of consensus building, so that this ideology extends to less "particular" corners.

For the Ethereum ecosystem, Layer2 is such a corner. As a solution to improve the scalability of Ethereum, L2 has been regarded as part of the future Ethereum body from day one, and has been handcuffed to the requirement of "Ethereum Alignment". For a long time, everyone has been discussing how L2 can achieve EVM compatibility, how Rollup can transition from OP to ZK, etc. Even Vitalik, as a core figure of Ethereum, has turned his opinions and remarks into "imperial edicts" under this "aligned" ideology.

But technological progress is not subject to personal will. With the emergence of Celestia, modular narratives have provided new ideas and directions for the evolution of the crypto technology stack, and have also brought a serious impact on Ethereum's "orthodoxy" thinking. Modular technologies and concepts such as RaaS, modular DA, and sovereign Rollup directly challenge the existence of "Ethereum-aligned" L2 such as Arbitrum, zkSync, and Scroll. What ideology should Rollup uphold and what should it look like? It seems to have more autonomy.

But autonomy does not mean growth. On the contrary, if you cannot provide differentiated value, you are competing with Ethereum for a living. As of now, most L2s have not yet developed their own differentiated value. The so-called differentiated value is not "my Gas is lower than Ethereum", because all L2s or other L1s can also say this, nor is it "I am an L2 focused on meme/DeFi", because the current vertical competition in the crypto industry has no moat, such as Base and Solana can have "meme season".

So where is the real differentiated value? After knowing and communicating with the Zircuit team, I think this value will be mainly reflected in ideology and specifically manifested through the sorter's technology stack.

For example, in the ideology of the Ethereum mainnet, "censored transactions" are not allowed to happen because it directly threatens the consensus of the entire network, but a sovereign L2 can, not only because of its technical feasibility, but also because it is not restricted by the mainnet ideology. As long as you migrate your assets to this L2, it means that you recognize its specific operating rules. In this case, "on-chain review" becomes an event allowed by consensus, and for groups with this special need, this L2 has differentiated value.

Zircuit's "On-chain Police"

Want to freeze assets that are about to be transferred after being hacked? Ethereum may not work, but Zircuit can do it for you. By adding an oracle model to the sorter, Zircuit's sorter can identify or predict malicious transactions in the network in advance, such as hacker attacks, and prevent these transactions from happening in time, thereby ensuring the safety of users' funds. The Zircuit team calls it "SLS", which stands for Sequencer Level Security.

This may sound a bit mysterious, but the biggest advantage of L2 lies precisely in the sorter, which has been criticized for centralization. Because there is no need to consider the design of the consensus mechanism, L2 can do a lot of work on the sorter, so that it can gain more "politically incorrect superpowers".

Before explaining the transaction review principle of the Zircuit sorter, let's review the current common operation of L2. Generally speaking, when transactions appear on L2, such as asset transfers between accounts, deployment and calling contracts, etc., they will be handled by a Rollup node consisting of a sorter, an execution engine, and a batch processor.

The sorter instructs the execution engine which transactions should be included in the next block, the batch processor packages L2 transactions and uploads them to L1 so that users can obtain data availability, and the execution engine batches transactions and generates new L2 states. Of course, there will be a difference in proof time between OP and ZK Rollup here, which will not be repeated in this article.

So the operation process of ordinary L2 is: generate transactions, sorter processes and generates L2 blocks, verifies blocks (optimistic fraud proof or zero-knowledge proof), and uploads L1 settlement (as shown below).

Compared with ordinary sorters, Zircuit's sorter adds a transaction oracle, which is different from price oracles such as ChainLink and is used to monitor and predict malicious transactions on L2. The oracle monitors the memory pool of the L2 network, identifies or predicts malicious transactions, and sends transactions identified as malicious intent to the "quarantine".

Transactions entering the quarantine area will no longer be included in the next block. If a hacker attacks a lending agreement or obtains wallet authorization through a phishing website and wants to transfer assets, the Zircuit sorter will isolate the transaction after identifying it, thereby ensuring the safety of user funds.

So the operation process of Zircuit is: generate transactions, sorter identifies and isolates malicious transactions, sorter processes and generates L2 blocks, verifies blocks (optimistic fraud proof or zero-knowledge proof), and uploads L1 settlement.

Specific to the sorter, Zircuit is based on Geth implementation, and the construction of blocks is divided into two steps: quasi-queue (Queue) and pending queue (Pending Queue). When a transaction is generated, it will be included in the quasi-queue regardless of whether it can be packaged into a block in the end. At this stage, the validator of ZK Rollup will generate ZK proofs for the transaction, and Zircuit will further review the transaction on this basis, put transactions without problems into the pending queue, and send transactions with malicious intent into the isolation area, and the transactions in the pending queue will eventually be packaged and uploaded to L1.

In this way, Zircuit embeds a security system at the consensus level equivalent to the L1 public chain, while preventing hard forks and block rollbacks.

Who has the final say?

Since it is a mechanism innovation at the consensus layer, "who has the final say" and "how to have the final say" must be the most important issues. The sorter is the "God" of L2. When his various superpowers are unlocked, they must be constrained by openness and transparency at the mechanism level. So how does Zircuit's sorter decide that a transaction may have malicious intent?

The AI model seems to provide a good solution at this time. The training principle of the Zircuit transaction oracle is mainly to use the transaction attached to the end of the block (that is, the final state of the longest chain) as data for simulation. This tracking data will contain information about all smart contract storage slots on the chain, as well as smart contract to smart contract calls made during the execution of this transaction. On this basis, the team will also add some off-chain metadata history, such as whether the account sender (Account Sender) has been active before, whether it is a newly funded account, etc. Through this "on-chain + off-chain" approach, the team has collected historical data of more than 4.5 billion transactions on 22 EVM chains, and provided this information to the machine learning model for training.

So to a certain extent, Zircuit's oracle can know what kind of on-chain consumer you are, and help you block suspicious transactions when necessary. For example, after data training, the oracle knows that your specific wallet address has never transferred more than 10% of the total assets in 7 years. Then when this address suddenly initiates several consecutive fund transfers or transfers all assets out, the oracle may put these transactions into quarantine. Of course, the Zircuit oracle will not interfere with most pure transfers. This kind of on-chain monitoring is mainly used to prevent protocol attacks.

But in addition to training the prediction model by itself, the main way the Zircuit team solves the problem is to create model integration. There are already many teams in the market whose core business is to provide intelligent active on-chain monitoring models. Zircuit maintains a close partnership with them and will continue to integrate with all accessible transaction prediction models or detection tools on the market.

This also gives the market many potential business opportunities. For example, you can focus on training an oracle for a specific protocol, and it doesn’t even need to be an AI model. When communicating with Zircuit co-founder Martin, he gave me an example: Old DeFi such as Compound has a long history of traffic (Traffic History). Based on these historical data, you can analyze which transactions usually go to Compound, what kind of Gas conditions they usually use, etc. You will find that 99% of the traffic records actually have very similar characteristics. Therefore, you can do traffic anomaly detection based on this data. If a transaction exceeds the 95% interval anomaly value, there is reason to intercept it.

In short, the Zircuit team hopes that the security research community will put forward their own ideas on how to review transactions and security issues. Martin told me: "I would be very happy if the community could use transaction data from Zircuit or other EVM blockchains to train their own models." The Zircuit team is very happy to give them access to the data they need, and once a good oracle product is found, it can be immediately implemented in Zircuit's existing model integration.

At the sorter level, the final execution logic of multi-oracle coordination will be: the sorter asks all currently available oracles. If each oracle believes that the transaction is fine, the sorter will directly include it in the block; if one or more oracles believe that the transaction is problematic, the sorter will decide whether to put it in the quarantine zone based on simple and transparent logic such as majority principle and performance rating.

Of course, it is absolutely not enough to rely on the model and oracle alone. It is foreseeable that in addition to some basic security standards, each application on Zircuit may have customized security requirements, such as "transaction amount is not less than/no more than" and "number of transactions in a single day must not exceed". Zircuit has developed a set of declarative language APIs specifically for this potential demand to help applications define some invariants that transactions cannot violate during execution.

In addition, Zircuit also provides multiple "appeal channels" for transactions placed in the quarantine zone. If a transaction meets specific requirements, it can leave the quarantine zone and be re-included in the block. At present, these "appeal channels" mainly include:

1. Time criterion, such as a transaction has reached the specified isolation time.

2. Alternative criterion, such as users do not want to wait and can cancel the transaction directly.

3. Failure criterion, such as a transaction has failed and therefore can no longer harm any address.

4. Economic criterion, such as users can pledge collateral equal to the funds involved in the transaction to offset the loss of funds predicted by the oracle.

5. Management criterion, the community unanimously decides that the transaction is benign.

Interestingly, under this set of modular block production logic, Zircuit's Prover technology has also been improved. Zircuit also adopts a modular approach to the prover, which the team calls Parallelized Prover. Each proof of Zircuit has its own specific role, such as one is used to prove that the transaction is executed correctly, another is used to prove that the related Keccak operation is executed correctly, and then the third proof is used to prove the aggregation of the operations performed by the first two proofs, etc., in this way to achieve higher efficiency and lower operating costs.

Can "SL+" become a new narrative for L2?

In the view of Martin and the Zircuit team, the potential of SLS is not only on-chain monitoring, it also opens up a new world of contract programming for developers.

The essence of blockchain security auditing is still based on the existing block status to ensure that the logic of smart contracts will not produce new unexpected states in the future. But sequencer-level security allows developers to take additional measures to ensure that these unexpected states will never occur. The Zircuit team calls it "Invariant Coding". Simply put, it is to tell the oracle through declarative language that certain rules should never be violated, such as the funds transferred out of the protocol treasury should never exceed 50% of the total amount, and put a transaction into isolation when it violates this invariant.

Alternatively, developers can use declarative languages to solve the ownership and transfer issues of calling functions in smart contracts. One of the great benefits of doing so is that it eliminates the engineering of encoding some invariants in smart contracts and obtains a smaller smart contract bytecode to reduce the mainnet deployment cost of the contract.

But I think that the SLS or "SL+" model may be a bigger narrative for L2.

In a recent article about the EF Foundation, I mentioned that L2 has become too homogenized due to its over-emphasis on "Ethereum alignment", and the emergence of Zircuit undoubtedly provides new ideas for the diversification of L2. In Martin's view, L2 should not consider the issue of "political correctness". His philosophy is: "As long as the people around you know what you are going to do, then you can do whatever you want." Under this logic, L2 is like an application with a consent clause. Users can choose to agree and start using it, or they can choose to refuse and leave. For L2, this means that it will no longer be bound by ideology, and can make a variety of "customized superpowers" through the sorter and sink into their respective segmented scenarios.

Today's market environment is increasingly fierce under the technical background of "one piece of chain". Solana has capital consensus, Base has Coinbase as its sponsor, and TON has Telegram's traffic entrance. In comparison, what do L2s have left? Perhaps the answer lies in the sorter, the "block-producing God".

欢迎加入律动 BlockBeats 官方社群：

Telegram 订阅群：https://t.me/theblockbeats

Telegram 交流群：https://t.me/BlockBeats_App

Twitter 官方账号：https://twitter.com/BlockBeatsAsia