> ## Documentation Index
> Fetch the complete documentation index at: https://docs.optimism.io/llms.txt
> Use this file to discover all available pages before exploring further.

# 강제 트랜잭션

> sequencer 다운타임 동안의 강제 트랜잭션 흐름에 대해 알아봅니다.

## 강제 트랜잭션 흐름

이 가이드에서는 sequencer 다운타임 동안 강제 트랜잭션(forced transaction)의 세부 사항을 설명합니다.

OP Stack에서 강제 트랜잭션은 sequencer 다운타임 중에도 트랜잭션 포함을 보장하는 메커니즘 역할을 합니다.
사용자는 언제든지 트랜잭션을 강제로 포함시킬 수 있으며, 이를 통해 출금을 시작할 수도 있습니다.
강제 트랜잭션은 L1에 직접 제출되는 일반적인 [입금(디파짓) 트랜잭션](https://docs.optimism.io/ko/op-stack/bridging/deposit-flow.md)입니다. 이 페이지는 검열 저항성 측면에서의 역할과 sequencer 다운타임 동안의 포함 시점에 초점을 맞추며, 기반이 되는 메커니즘은 [입금 흐름](https://docs.optimism.io/ko/op-stack/bridging/deposit-flow.md) 설명 문서에서 다룹니다.
다만 체인 도출(derivation) 파이프라인과 sequencer 동작에 관해 이해해야 할 중요한 세부 사항이 있습니다.

## 핵심 개념

* **시퀀싱 윈도우(Sequencing Window)**: 네이티브 L2 트랜잭션과 입금 트랜잭션을 포함한 L2 트랜잭션을 포함시키기 위한 12시간의 롤링 윈도우입니다.
* **최대 시간 편차(Max Time Drift)**: L2 체인을 기준으로 입금 트랜잭션을 포함시키는 데 걸리는 최대 지연 시간으로, 30분입니다.
* **Sequencer 다운타임**: sequencer가 오프라인이거나 블록을 생성하지 않는 기간입니다.
* **강제 트랜잭션**: 사용자가 L1 체인에 직접 제출할 수 있는 트랜잭션으로, sequencer의 개입 없이 L2 체인에 포함되는 것이 보장됩니다.
  이 메커니즘은 sequencer 다운타임 동안 매우 중요합니다.

## 정상 운영

정상적인 상황에서는 다음과 같습니다.

1. 입금 트랜잭션은 30분 이내에 포함됩니다.
2. sequencer는 정기적으로 트랜잭션을 처리하고 블록을 생성합니다.

## 강제 트랜잭션 메커니즘

1. **L1에 제출:**
   사용자는 L1 Ethereum의 `OptimismPortal` 컨트랙트로 트랜잭션을 직접 보낼 수 있습니다. 이는 sequencer를 우회하므로 트랜잭션이 L1에 기록되는 것이 보장됩니다.

2. **L2에 포함:**
   L1에 제출된 트랜잭션은 자동으로 L2 체인에 포함됩니다. 포함 시점은 sequencer 다운타임 기간에 따라 달라집니다.

   * **짧은 다운타임(\< 30분):**
     약 `~ 30 minutes`의 짧은 다운타임 동안에는, sequencer가 해당 윈도우 내에 운영을 재개하면 트랜잭션이 여전히 일반적인 30분 최대 시간 편차 내에 포함될 수 있습니다.

   * **장기 다운타임(30분\~12시간):**
     sequencer 다운타임이 30분에서 12시간 사이로 지속되는 경우:

     * 입금 트랜잭션: 사용자는 L1의 [`OptimismPortal`](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/src/L1/OptimismPortal2.sol#L684) 컨트랙트에 강제 트랜잭션을 직접 제출할 수 있습니다. 그러나 이러한 트랜잭션은 sequencer가 재개되거나 12시간 시퀀싱 윈도우가 만료된 후에만 L2 체인에 포함됩니다.
       이 기능에 대한 자세한 내용은 [Sequencer 우회하기](https://docs.optimism.io/ko/op-stack/protocol/outages.md#bypassing-the-sequencer) 섹션을 참조하십시오.
     * L2 체인 상태: L2 체인의 상태는 다음 중 하나가 발생할 때까지 불확실한 상태로 유지됩니다.
       sequencer가 운영을 재개하고 대기 중인 트랜잭션을 처리하거나,
       12시간 시퀀싱 윈도우가 만료되는 경우(만료 후에는 node가 강제 포함된 입금 트랜잭션만 반영하여 결정론적으로 블록을 생성하기 시작합니다).

   * **Sequencer 따라잡기 단계:**
     sequencer가 30분 이상 12시간 미만 동안 오프라인 상태였다면, 재시작 시 **빠른 따라잡기(quick catch-up)** 단계에 들어갑니다.
     이 단계에서는 다음과 같이 동작합니다.
     * sequencer는 블록마다 L1 origin을 앞으로 이동시키면서 **입금 전용 블록**(deposit-only block)을 생성합니다.
     * 이 과정은 L1 origin이 sequencer drift 윈도우 안으로 돌아올 때까지 계속됩니다.
     * 일반적으로 L2 블록은 L1 origin 대비 **6:1 비율**로 생성됩니다(L2 블록당 12초 대 L1 블록당 2초). 그러나 따라잡기 단계에서는 이 비율이 **1:1로 전환**되어, 각 L2 블록이 새로운 L1 origin에 대응합니다.

   * **장시간 다운타임(> 12시간):**
     12시간이 지나면 node는 강제 포함된 트랜잭션만 반영하여 결정론적으로 블록을 생성하기 시작합니다. 일반 L2 트랜잭션은 sequencer가 다시 온라인 상태가 되어 L1 상태의 최근 12시간 이내로 들어올 만큼 충분한 블록을 처리할 때까지 연기됩니다.

## 강제 트랜잭션의 이점

* **검열 완화:** 강제 트랜잭션은 대체 메커니즘 역할을 하므로, sequencer가 트랜잭션을 검열하려 하더라도 사용자는 트랜잭션이 처리되도록 보장할 수 있습니다.
* **네트워크 복원력:** 네트워크가 계속 작동하므로 sequencer 다운타임 동안에도 중요한 트랜잭션을 진행할 수 있습니다.
* **사용자 자율성:** 사용자는 트랜잭션 포함을 전적으로 sequencer에 의존하지 않으므로, 추가적인 신뢰성과 안정성을 확보할 수 있습니다.

## 중요 고려 사항

* 입금을 통한 강제 트랜잭션(입금 금액은 필요하지 않음)은 작업이 적시에 실행되도록 보장하여, sequencer 다운타임 동안 DEX 가격 괴리와 같은 위험을 완화합니다.
* 시퀀싱 윈도우로 인해 작업은 최대 12시간 동안 추정(speculative) 상태로 유지됩니다.
* 12시간 윈도우는 운영 안정성과 잠재적인 L2 재구성(reorganization) 최소화 사이의 균형점입니다.

## 예시 시나리오

30분이 지난 후, 시퀀싱 윈도우가 만료되기 전에 입금이 시작된 경우:

1. 입금은 시퀀싱 윈도우가 만료될 때(최대 \~11시간 후) 유효해집니다.
2. L1에서 데이터를 읽는 node는 시퀀싱 윈도우가 만료된 후 해당 입금을 포함한 블록을 생성합니다.
3. 최종 L2 체인은 입금이 시작된 L1 블록에 가까운 온체인 타임스탬프를 가진 블록에 해당 입금을 포함합니다.

> [!NOTE]
>
> 시퀀싱 윈도우는 L1 블록이 처음 알려진 시점부터의 12시간 롤링 지연입니다.
> 이 설계는 L2 체인 재구성을 일으키지 않고 sequencer가 다시 온라인 상태로
> 돌아올 수 있는 유예 기간을 제공합니다.

## 결론

OP Stack 체인의 강제 트랜잭션 메커니즘은 [sequencer 다운타임](https://docs.optimism.io/ko/op-stack/protocol/outages.md#sequencer-downtime-outages)을 처리하는 견고한 방법을 제공하여, 중요한 트랜잭션이 적시에 포함되도록 보장합니다.
12시간 sequencer 윈도우는 다운타임 동안 어느 정도의 불확실성을 초래하지만, 시스템은 최종적인 일관성과 트랜잭션 포함을 보장하도록 설계되었습니다.