Data Availability, Sequencer, Finality

도입

L2 결제에서 가장 위험한 문장은 "transaction이 보였으니 완료"다. wallet이나 explorer에 transaction이 나타난 상태, sequencer가 transaction을 받아들인 상태, L2 state가 확정된 상태, L1에 batch/proof가 게시된 상태, bridge나 CCTP가 최종 처리된 상태는 모두 다르다. 결제 제품은 이 차이를 가격, 금액, 환불 가능성, merchant delivery 정책으로 바꿔야 한다.

이 강의에서는 DA, sequencer, finality를 따로 외우지 않는다. checkout이 언제 Paid가 되고, settlement ledger가 언제 닫히고, stuck 상태가 언제 support ticket으로 넘어가는지 결정하는 기준으로 읽는다.

학습 목표

• data availability가 독립 검증과 자금 회수에 왜 필요한지 설명한다.
• sequencer confirmation과 L1/bridge finality를 분리해 confirmation policy를 만든다.
• 금액과 위험에 따라 soft confirmation, final confirmation, manual review 조건을 다르게 둔다.
• stuck 상태를 예외가 아니라 제품 상태로 설계한다.

개념 설명

1. DA는 "데이터를 다시 구할 수 있는가"보다 먼저 "검증할 수 있는가"를 묻는다

Ethereum.org는 data availability를 block 검증에 필요한 데이터가 실제로 network participants에게 제공된다는 확신으로 설명한다. rollup에서는 실행은 L2에서 일어나도, 그 실행을 검증하거나 dispute하려면 transaction data가 필요하다.

DA가 약하면 단순히 "explorer 조회가 불편하다"가 아니다. 사용자가 자금 소유를 증명하거나 invalid state에 대응하는 능력이 약해질 수 있다. 그래서 DA는 product risk sheet에서 별도 항목으로 둔다.

2. Sequencer는 빠른 UX와 censorship risk를 동시에 만든다

sequencer는 L2 transaction ordering과 빠른 confirmation UX를 제공한다. 중앙화된 sequencer가 많은 L2에서 사용자는 빠른 체감 속도를 얻지만, 장애와 censorship 지점을 함께 갖는다.

중요한 점은 sequencer accepted가 final settlement가 아니라는 것이다. merchant가 즉시 상품을 제공해도 되는지, refund queue를 닫아도 되는지, treasury ledger를 확정해도 되는지는 별도 기준이 필요하다.

3. Finality는 결제 목적별로 다르게 잡는다

같은 Paid라도 내부적으로는 PaidSoft, PaidFinal, Settled, BridgeFinal처럼 나누어 관리할 수 있다. UI에는 간단히 보여주되 ledger와 risk engine에는 단계가 남아야 한다.

4. Confirmation policy는 금액과 되돌릴 수 없음으로 정한다

정책은 chain별로 달라질 수 있다. "모든 L2는 12 confirmations" 같은 고정 규칙보다, L2 risk intake sheet의 DA, sequencer, proof, bridge 상태를 읽고 기준을 정하는 방식이 낫다.

5. Stuck 상태는 실패가 아니라 설계 대상이다

Delayed와 ManualReview가 없는 결제 상태머신은 운영에서 깨진다. 정상 지연, provider 장애, reorg, CCTP attestation 지연, bridge message 실패를 모두 "실패"로 처리하면 사용자 안내와 회계가 뒤섞인다.

코드로 확인하기

위 신뢰 모델을 코드와 운영 규칙으로 확인한다. 메시지 상태, 최종성, 재시도, 관측 지점이 어디서 분리되는지 보는 것이 목적이다.

백엔드Confirmation policy matrix — 금액·체인별 N블록 정책

금액이 크면 confirmation을 늘리고, 체인이 DA 약하면 더 보수적으로. policy를 코드 한 곳에 박는다.

01type ChainConfirmationPolicy = {02  chainId: number;03  softConfirmBlocks: number;     // 사용자에게 "결제 진행 중" 표시 가능04  finalConfirmBlocks: number;    // ledger 에서 settled 처리05  largeAmountUsd: number;        // 이 금액 이상이면 더 보수적인 정책06  largeAmountFinalBlocks: number;07};0809export const CONFIRMATION_POLICY: Record<number, ChainConfirmationPolicy> = {10  1: {     // Ethereum mainnet11    chainId: 1, softConfirmBlocks: 1, finalConfirmBlocks: 32, // ~ Casper finality12    largeAmountUsd: 100_000, largeAmountFinalBlocks: 6413  },14  8453: {  // Base15    chainId: 8453, softConfirmBlocks: 2, finalConfirmBlocks: 200,16    largeAmountUsd: 50_000, largeAmountFinalBlocks: 50017  },18  42161: { // Arbitrum One19    chainId: 42161, softConfirmBlocks: 1, finalConfirmBlocks: 100,20    largeAmountUsd: 100_000, largeAmountFinalBlocks: 30021  }22};2324export function blocksRequired(chainId: number, amountUsd: number, kind: "soft" | "final") {25  const p = CONFIRMATION_POLICY[chainId];26  if (!p) throw new Error(`no policy for chain ${chainId}`);27  if (kind === "soft") return p.softConfirmBlocks;28  return amountUsd >= p.largeAmountUsd ? p.largeAmountFinalBlocks : p.finalConfirmBlocks;29}

인덱서Confirmation 카운터 + reorg watcher

블록 N개 후 finalized 처리. block hash가 바뀌면 (reorg) status를 되돌린다.

01export async function tickConfirmations(chainId: number) {02  const head = await client.getBlock({ blockTag: "latest" });0304  const pending = await prisma.payment.findMany({05    where: { chainId, status: { in: ["SoftPaid", "Submitted"] } }06  });0708  for (const p of pending) {09    const blockAtSubmit = await client.getBlock({ blockNumber: p.submittedAtBlock });10    if (blockAtSubmit.hash !== p.submittedAtBlockHash) {11      // reorg 발생 — 상태를 되돌린다12      await prisma.payment.update({13        where: { id: p.id },14        data: { status: "Retryable", reorgedAt: new Date() }15      });16      continue;17    }18    const confirmations = Number(head.number - p.submittedAtBlock);19    const finalBlocks = blocksRequired(chainId, p.amountUsd, "final");20    if (confirmations >= finalBlocks) {21      await prisma.payment.update({ where: { id: p.id }, data: { status: "FinalPaid", finalizedAt: new Date() } });22    }23  }24}

운영Sequencer outage 시 결제·환불·인출 분리 대응

모든 기능을 동시에 막지 않는다. 신규 결제는 차단, refund는 큐에, withdrawal은 L1 escape를 안내.

01type SequencerOutageAction = {02  newCheckout: "disable" | "enable";03  refund: "queue" | "execute";04  treasuryWithdrawal: "block-l2-route" | "force-l1-escape" | "wait";05  userBanner: string;06};0708export const OUTAGE_RESPONSE: SequencerOutageAction = {09  newCheckout: "disable",10  refund: "queue",11  treasuryWithdrawal: "force-l1-escape",12  userBanner: "이 체인의 시퀀서가 응답하지 않습니다. 신규 결제는 일시 중단되었고, 환불은 복구 후 자동 처리됩니다."13};

강의 포인트

실무 예시

Confirmation policy matrix

운영Sequencer down runbook

흔한 오해와 실패 시나리오

실습 과제

1. 백엔드Confirmation policy matrix 작성: low-value API payment, normal checkout, high-value merchant settlement, treasury withdrawal에 대해 wallet displayed, sequencer accepted, L2 finalized, L1 posted, bridge final 중 어떤 기준을 쓸지 정한다.
2. 운영Sequencer down runbook 작성: sequencer 장애 시 checkout 접수, relayer retry, refund queue, status page, support macro를 어떤 순서로 처리할지 runbook으로 작성한다.
3. 클라이언트[OPS] Stuck state UX 설계: 정상 지연, provider 장애, 재시도 가능, 수동 검토, 환불 필요 상태를 구분해 사용자 표시 문구와 운영자 증거 링크를 설계한다.

완료 기준

1. DA, retrievability, blob availability, archive access를 구분했다.
2. 금액과 업무 유형별 confirmation policy를 작성했다.
3. sequencer outage 때 닫을 기능과 유지할 기능을 정했다.
4. stuck 상태를 포함한 payment state machine을 만들었다.

근거 자료

• Data Availability Sequencer Finality: 03-크로스체인-L2/03-Data-Availability-Sequencer-Finality.md
• Ethereum.org Data Availability: https://ethereum.org/developers/docs/data-availability/
• Ethereum.org Optimistic Rollups: https://ethereum.org/developers/docs/scaling/optimistic-rollups/
• L2BEAT Scaling Risk Overview: https://l2beat.com/scaling/risk