> ## Documentation Index
> Fetch the complete documentation index at: https://daehan-base.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# 플래시블록 개요

> Base의 플래시블록 시퀀서 아키텍처, 블록 빌딩 알고리즘, 통합 옵션에 대해 설명합니다. 200ms 사전 확인으로 트랜잭션 지연을 크게 줄이는 방법을 안내합니다.

## 플래시블록이란?

플래시블록은 Base에 **200ms** 단위의 증분 상태 업데이트를 도입하여 사용자가 체감하는 지연을 크게 줄입니다.

[Flashbots](https://www.flashbots.net/)와의 협업으로 구축된 이 메커니즘은 표준 2초 블록 간격 내에서 서브 블록을 스트리밍하여 즉각적인 시퀀서 사전 확인을 제공합니다. 이를 통해 전체 블록이 나머지 네트워크에 전파되기 훨씬 전에 애플리케이션이 상태 변경을 반영할 수 있습니다.

<Note>
  플래시블록은 Base에서 항상 활성화되어 있습니다. 모든 블록은 플래시블록 빌더에 의해 구축됩니다. 앱은 사전 확인을 사용할지, 아니면 표준 2초 블록 최종성을 기다릴지 선택할 수 있습니다.
</Note>

### 핵심 개념

| 용어        | 정의                                   |
| --------- | ------------------------------------ |
| **플래시블록** | 전체 블록 트랜잭션의 일부를 포함하는 200ms 서브 블록     |
| **사전 확인** | 전체 블록이 봉인되기 전에 트랜잭션이 포함될 것이라는 초고속 신호 |
| **전체 블록** | 완전한 2초 블록을 형성하는 10개의 플래시블록 시리즈       |

각 블록에는 **10개의 플래시블록**(인덱스 1-10)이 포함되며, 각각 200ms마다 도착합니다. 인덱스 0은 존재하지만 시스템 트랜잭션만 포함합니다. 가스 예산 작동 방식은 [가스 및 트랜잭션 크기](/base-chain/flashblocks/app-integration#gas-&-transaction-sizing)를 참조하세요.

## 아키텍처

시퀀서 시스템 및 플래시블록 인프라 구성 요소(rollup-boost, op-rbuilder, websocket-proxy, base)에 대한 자세한 내용은 [아키텍처](/base-chain/flashblocks/architecture) 페이지를 참조하세요.

## 트랜잭션 라이프사이클

Base로 트랜잭션을 전송하면 다음과 같은 과정이 발생합니다:

### 1. 제출

```
사용자 → DNS (mainnet.base.org) → 로드 밸런서 → Proxyd → 멤풀
```

트랜잭션이 프라이빗 멤풀에 도달하고 대기 중으로 txpool에 삽입됩니다.

### 2. 배포

멤풀은 실행 레이어(op-reth, op-rbuilder)와 P2P 연결을 유지하여 모든 대기 중인 트랜잭션이 블록 빌딩을 위해 동기화되도록 합니다.

### 3. 블록 빌딩

각 200ms 블록 빌딩 루프 동안 op-rbuilder는 다음을 기반으로 트랜잭션을 선택합니다:

1. **트랜잭션 수수료** — 트랜잭션은 수수료 순으로 정렬됩니다(높은 것 먼저)
2. **가스 한도 및 남은 용량** — 각 플래시블록 `j`는 총 블록 가스 한도의 최대 `j/10`을 사용할 수 있습니다

<Note>
  **동적 멤풀:** 빌더는 빌드 중에 지속적으로 새 트랜잭션을 수락하는 동적 멤풀을 사용합니다. 이는 포함 지연을 최소화하지만 나중에 도착한 높은 수수료 트랜잭션이 동일한 플래시블록 내의 이미 커밋된 낮은 수수료 트랜잭션 이후에 나타날 수 있음을 의미합니다. 이는 예상된 동작으로, 버그가 아닙니다—트랜잭션은 *선택 시점*의 수수료로 정렬됩니다.
</Note>

### 4. 블록 빌딩 알고리즘

빌더는 각 2초 블록에 대해 다음 과정을 따릅니다:

```
각 플래시블록 j (0 ~ 10):
    1. 다음 200ms 창까지 대기
    2. 사용 가능한 가스 계산: (j / 10) × 총_블록_가스_한도
    3. 수수료 기준으로 대기 트랜잭션 정렬 (내림차순)
    4. 사용 가능한 가스에 맞는 상위 트랜잭션 선택
    5. 트랜잭션 실행 및 상태 업데이트
    6. websocket-proxy로 플래시블록 스트리밍
```

<Note>
  **인덱스 0**은 시스템 트랜잭션만 포함하며 가스 한도를 사용하지 않습니다. **인덱스 1-10**은 txpool에서 대기 중인 트랜잭션을 가져오는 실제 플래시블록입니다.
</Note>

### 5. 사전 확인 전달

트랜잭션이 플래시블록에 포함되면 websocket-proxy로 스트리밍되고, RPC 노드가 이를 수신합니다. 플래시블록 인식 RPC 메서드(예: `eth_getTransactionReceipt`)를 호출하면 노드가 캐시에서 사전 확인된 데이터를 검색합니다.

<Info>
  전체 인프라 스트림 스키마는 [플래시블록 API 개요](/base-chain/api-reference/flashblocks-api/flashblocks-api-overview) 참조 문서를 확인하세요: [플래시블록](/base-chain/api-reference/flashblocks-api/flashblocks-api-overview#flashblock-object), [Diff](/base-chain/api-reference/flashblocks-api/flashblocks-api-overview#diff-object), [메타데이터](/base-chain/api-reference/flashblocks-api/flashblocks-api-overview#metadata-object), [영수증](/base-chain/api-reference/flashblocks-api/flashblocks-api-overview#receipt-object).
</Info>

## 추가 자료

* [FAQ](/base-chain/flashblocks/faq) — 플래시블록에 대한 일반적인 질문
* [블록 빌딩](/base-chain/network-information/block-building) — 상세한 블록 순서화 설정
* [플래시블록 심층 분석](https://blog.base.dev/flashblocks-deep-dive) — 구현 세부 사항이 담긴 엔지니어링 블로그 게시물