Security Model
Background
Layer4 Network is an evolving project that is continuously advancing. During the Mainnet phase, the network's operations are characterized by a higher degree of centralization. This phase relies on a dedicated core contributor team, entrusted with ensuring optimal performance and robust security. It's important to highlight two fundamental aspects:
Fraudproofs in Progress: The ongoing development of fraudproofs is a focal point. Our efforts are concentrated on refining and enhancing this technology based on the latest advancements showcased on Testnet and the GitHub repository.
Data Availability and Layer4 DA: The current setup involves a permissioned node network for Layer4 DA, where the selection and approval of all nodes are overseen by the core team.
Our protocol's development roadmap comprises multiple phases with the overarching goal of elevating user experience and transitioning various protocol components into decentralized, trustless systems, along with streamlined architecture. The team's plan involves engaging in discussions with Layer4 Governance, ensuring community involvement in pivotal decision-making processes that shape the decentralization journey.
Security Model
System Components
Permission Management
Lib Address Manager
Within Layer4 Network, this element plays a crucial role in overseeing permissions and addresses linked to significant L1 smart contracts. The Lib Address Manager is equipped to reset addresses related to the following entities: Sequencer, Proposer, Mt-batcher, L1StandardBridge, L1Crossdomainmanager, SCC, CTC, Layer4 DA contracts, along with assorted TSS Stake-related addresses. It's important to note that the Lib Address Manager does not possess the capability to reset addresses associated with Layer4 DA or Fraud Proof.
Offchain Systems
Proposer Functionality
The proposer undertakes the responsibility of submitting novel state roots to the SCC (L1). State roots play a vital role in state validation and significantly influence withdrawal capabilities from the L1 Bridge.
In case of Proposer component compromise:
Authorized roles with SCC write permissions can perform "deleteStateBatch" actions (refer to SCC section).
The proprietor of the LibAddress Manager has the authority to reset the proposer's address.
It's noteworthy that due to the 7-day challenge period configured for withdrawals, prompt fixes within this timeframe can help mitigate the impact of a compromise.
Sequencer and Mt-Batcher Operations
The sequencer plays a pivotal role in forwarding a subset of rollup transaction data, including transaction counts, batches, and elements, to the CTC (L1). This is performed to enqueue data via L1, as elaborated further in the CTC section. Meanwhile, the mt-batcher is responsible for submitting all rollup transaction data to the DA solution. Rollup transaction data holds significant importance for L2 State Validation, involving components like the Fraud Proof component and Verifier Node component.
In case of Sequencer component compromise:
The owner of the CTC possesses the authority to rectify data discrepancies.
The proprietor of the LibAddress Manager can reset the Sequencer's address.
DTL Service Overview
The DTL Service stands as a critical system, supplying L1 data, L1 enqueued transactions, and DA data to various L2 systems (Replica Nodes, L2geth, verifier nodes). It serves as a pivotal relay service for accurate information. Notably, the current DTL does not relay messages accompanied by L1 signatures. This presents a risk, especially in the ongoing development of fraud proofs. This matter has been addressed in https://community.optimism.io/docs/developers/bedrock/, which is under evaluation for the upcoming upgrade.
In case of DTL Service component compromise:
The DTL Service functions offchain, transmitting data to other offchain systems.
Should the DTL Service face a breach, the data-receiving systems like Replica Nodes, Verifier Nodes, and L2geth can update their connections to an alternative backup DTL Service.
Rollup Smart Contracts
(SCC) StateCommitmentChain
The SCC stores the L2 state roots on L1. State roots are submitted using the appendStateBatch method, by the Proposer via the FraudProofRollup contract.
The SCC manages the length of time before user withdrawals are permitted on L1, also known as the 'Challenge Period', via the setFraudProofWindow method.
The state roots determine the ability for users to withdraw to L1, after waiting for the fraud proof window.
The SCC deleteStateBatch method can be called in an emergency where L2 and SCC state are no longer in sync, such as a 64+ block L1 reorganization, or a compromise of the Proposer component.
In the event of a compromise affecting the SCC:
The SCC address can be reset by the proprietor of the LibAddressManager (Layer4 Security Msig).
Should the component be restored within the setFraudProofWindow, which is currently set at 7 days, the potential for unauthorized L1 asset withdrawals is mitigated.
(CanonicalTransactionChain) CTC
Within the Layer4 Network, the CTC, or CanonicalTransactionChain, serves as a repository for a portion of rollup transaction data, unlike Layer4 DA, which stores the entirety of such data.
The CTC plays an essential role in enabling L1-->L2 transactions and is the sole avenue for queuing transactions to L2, distinct from Layer4 DA.
Management of L1 to L2 transactions, including deposit requests, rests with the CTC through the enqueue method. For instance, the journey of an ERC20 deposit involves L1StandardBridge._initiateERC20Deposit -> L1CrossDomainMessenger.sendMessage -> CanonicalTransactionChain.enqueue.
Some L2 transaction data is housed within the CTC, encompassing counts of elements, batches, and transactions. These counts serve as reference points for enqueuing transactions effectively.
Enqueued transactions routed through the CTC reach the DTL Service approximately after 30 seconds and await validation from 64 L1 block confirmations before being relayed to other L2 nodes.
In the event of a compromise affecting the CTC:
The Layer4 Security Msig, the owner of the LibAddressManager, possesses the authority to reset the CTC address.
The DTL Service retains the capability to reject CTC data or pause its own operations as a response.
Fraud Proof
FP.Rollup
The FP.Rollup module assumes responsibility for storing state batches to support the initiation of fraud proof challenges. Within our existing configuration, this data is consistently submitted by the Proposer utilizing the createAssertionWithStateBatch method, synchronized with the Proposer's state root submissions to the SCC.
It's important to note that there are certain areas of convergence with the SCC.appendStateBatch method, which is also triggered by Proposer submissions. These areas of convergence include:
The relationship to the same event, leading to limited gas cost duplication;
The FP.Rollup component solely storing the final block's state root, as opposed to SCC which retains state roots for all blocks;
The FP.Rollup including supplementary information like the L2 block height to facilitate fraud proof challenges.
Storing state information within both the SCC and FP.Rollup components offers an advantage, as the SCC can function independently even without the FP component in scenarios where fraud proof-type state validation methods are not employed.
The FP.Rollup's createAssertion method is designed to lay the groundwork for forthcoming fraud proof challenges and operates as a distinct channel from the Proposer's standard submissions via createAssertionWithStateBatch.
The FP.Rollup component encompasses an array of permissions and parameter controls, including operator whitelists for challengers and defenders, as well as management of stakes. It's important to note that these functions serve as provisional placeholders, given that fraud proof challenges have not been activated.
Although callable, the rollbackL2Chain method is not intended for utilization in the present Mainnet version. Even if invoked, executing a full rollback on L2 requires manual intervention by the core contributor team. A potential risk stems from deep reorganizations occurring on L1. To mitigate this, our L1 to L2 messaging effectively awaits confirmation from 64 L1 blocks.
Bridge
L1StandardBridge
The L1StandardBridge components are used to store deposited L1 tokens that are to be bridged to L2, and facilitate future withdrawals of such tokens on L1.
If the L1StandardBridge component is compromised:
The LibAddressManager owner (Layer4 Security Msig) can reset the address, however existing tokens held in the L1StandardBridge may become inaccessible.
L1CrossDomainMessenger
The L1CrossDomainMessenger component is used to send messages from L1 to L2. This is triggered through the sendMessage method of L1CrossDomainMessenger, and routed to the enqueue method in the CTC contract. After the verification is successful, the TransactionEnqueued event is thrown and caught by the DTL Service for relaying to other L2 nodes.
The L1CrossDomainMessenger component is used to facilitate L2 to L1 communication. This is initiated through the sendMessage method of L2CrossDomainMessenger which will be rolled up to L1. After the challenge period, a user can call the relayMessage method of the L1CrossDomainMessenger and the legitimacy of the message will be verified and executed.
The main fields of messages include: address_target which is the address of the contract to be interacted with, and bytes memory_message which includes the parameters for calling the contract. Additional L2 to L1 messages will include address_sender.
TSS
TSS nodes - which provide an additional check on state validity prior to batch submission - is currently a permissioned node network, with all nodes selected and approved by the core team. The future direction of TSS will be a major decision for the next significant upgrade of Layer4 Network, and will be evaluated among other mechanisms that aim to enhance confidence in State Validity.
If the TSS components are compromised, stateroots can not be submitted by the Proposer to the SCC, and the L2 chain may need to be paused depending on the duration of TSS downtime and the establishment of a new TSS group. Key TSS components are owned by a combination of Layer4 Engineering Msig and Layer4 Security Msig.
Last updated
