Sequencer Level Security (SLS)
Overview
Zircuit will protect users at the sequencer level by monitoring the mempool for malicious transactions and preventing their inclusion into a block. In comparison to typical security efforts that focus on the application and smart contract levels, Zircuit’s revolutionary approach goes directly to the underlying sequencer level.
This approach is called "Sequencer Level Security" (SLS) and adds an extra layer of security to the Zircuit network. This novel approach means that our sequencer scrutinizes transactions for potential malicious intent before they are finalized on layer 2. By enabling early detection and quarantine of suspicious transactions, the SLS protocol enhances the security of smart contracts and the layer 2 without necessitating the contentious measures of hard forks or block reversion.
Detailed Description
Zircuit adds another layer of security at the sequencer level. The sequencer is a privileged node that collects users’ transactions, similar to Ethereum, and also orders them based on predefined rules.
The figure above presents an overview of the protocol. It contains three main components: (1) Malice Detection, (2) Quarantine-Release Criterion, and (3) Transaction Execution.
Upon arrival at the SLS sequencer, transactions from the mempool are initially routed to Malice Detection module. In our talks, we refer to this module as the “oracle.” It identifies whether a transaction is benign or potentially malicious. Benign transactions are promptly queued for block inclusion, adhering to standard sequencing protocols. Conversely, transactions flagged as malicious are diverted to the Quarantine-Release Criterion module, which acts as an intermediary holding area. Here, they undergo a rigorous verification process against specific release criteria. Transactions that meet these criteria are then forwarded to the Transaction Execution module. The Transaction Execution module executes the transactions against the blockchain state at the forthcoming L2 block. Successfully executed transactions are cycled back to the SLS sequencer for inclusion in the forthcoming L2 block.
Malice Detection
Malice Detection is done via the following steps:
Choosing Transactions by the Sequencer: The sequencer selects a list of transactions for potential inclusion in the upcoming block. This step is the same as other standard sequencing protocols. This includes both transactions from the mempool, and deposit transactions that have origin on L1.
Parallel Simulation on the Tip of the Chain: Each transaction is independently simulated using the current state at the tip of the blockchain. This step allows for parallel processing of transactions. The outcomes of these simulations provide essential data for future dependency analysis and malice detection: (1) Simulation results of each transaction (2) The blockchain states read and written by each transaction.
Transaction Dependency Analysis: We perform the analysis on the state read and written by each transaction and identify the dependencies between all transactions. Informally, one transaction is dependent on another if executing one may change the outcome of executing the other.
Parallel Detection for Independent Transactions and Sequential Detection for Dependent Transactions: For any transaction that is not dependent (a.k.a. independent) on any other prior transaction, the sequencer can perform parallel detection on their simulation results. Other dependent transactions are queued for sequential simulation and detection within the block context.
Transaction Inclusion: The sequencer finalizes the block by including all transactions identified as benign. Dependent transactions that could not be fully analyzed due to time constraints or complexity are deferred to the next cycle. The same detection process will be applied in the next round when these transactions are considered again for inclusion.
The algorithms used by the sequencer to identify malicious include program analysis, machine learning, and rule-based methods.
Quarantine-Release Criterion
While in quarantine, the transaction does not get executed and cannot be included in the blocks. The sequencer maintains the information about when the transaction has been placed in the quarantine. The transaction will either be dropped from the mempool once it meets one of the retirement criteria or be released from the quarantine if it meets one of the release criteria.
The exact retirement criteria and release criteria can be defined by the sequencer.
Mempool Retirement Criteria:
Nonce criterion. This criterion is met if the transaction can no longer be included in a block because the nonce is no longer valid.
Time criterion and memory constraints. This criterion is met if the transaction clutters the mempool that the node maintains. Such a transaction can be resubmitted to the network and re-enter the mempool (in the quarantined state).
The current implementation of Zircuit ensures that transactions in quarantine are being checked periodically on the retirement criteria by the sequencer. The following list of quarantine-release criteria are viable from the security standpoint.
Release Criteria:
Time criterion. The time criterion represents the reaction time that the sequencer offers to the users to react to a malicious transaction. If the transaction has been quarantined for longer than required, it can be released and considered for block inclusion. The exact amount of time required for the transaction to stay in the quarantine is a configuration parameter.
Failure criterion. If a transaction fails due to changes in the chain’s state, it can be safely included in the block since it will result in a revert. Reverted transactions do not alter the blockchain state.
Administrative criterion. It is expected that the detection of malice will occasionally produce false positives. Under such circumstances, the sequencer operational team, comprising security experts, can administratively override decisions to release transactions.
We refer to the Sequencer-Level Security paper for other possible release criteria.
At the launch time, the Zircuit sequencer uses only the Time criterion set to a very long period of time (in the order of years). During this period, the sequencer waits for a privileged party to trigger the release criteria.
Transaction Execution
Upon releasing from the quarantine, the sequencer can consider including the transaction when forming the next block. This is subject to the regular sequencing Rules. For a transaction that was resubmitted due to being originally underpriced for the current chain state, the transaction should not be quarantined again. The SLS protocol has to use the account address, and the transaction data (the function selector and call data), and value, to establish whether a new incoming transaction is a duplicate of a transaction that has been already released from the quarantine.
Requirements for Builders
The SLS protocol is implemented in Zircuit natively. Therefore, every smart contract deployed on Zircuit is by default included and protected by the SLS. However, SLS is a best-effort service powered by AI, so it can make mistakes. The developers are therefore encouraged to follow best engineering practices and scrutinize the security of their code. The sequencer-level security protocol should be considered an added secondary security measure.
SLS requires pricing information for detecting malice and protecting assets. Tokens natively deployed on Zircuit should be listed on CoinGecko. The technology will automatically recognize such price feeds and tokens. Tokens that are deployed on other networks and bridged to Zircuit are advised to contact the Zircuit team via Discord to ensure rapid inclusion in the oracle’s pricing system.
Learn More
Technical details can be found in our pre-print:
You can also learn more by watching some of our talks on the topic:
Last updated
