> ## 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.

# 플래시블록 FAQ

> 플래시블록에 대한 자주 묻는 질문입니다. 블록 빌딩, WebSocket 데이터, RPC 사용, 노드 설정 등에 대해 답변합니다.

<Info>
  플래시블록의 작동 방식에 대한 종합적인 소개는 [플래시블록 개요](/base-chain/flashblocks/overview)를 참조하세요.
</Info>

## 블록 빌딩

<AccordionGroup>
  <Accordion title="플래시블록은 선택 사항인가요?">
    모든 Base 블록은 플래시블록 빌더에 의해 구축되므로 **플래시블록은 항상 활성화**되어 있습니다. 그러나 앱은 사전 확인에 의존하지 않고 플래시블록 통합 없이 표준 RPC를 계속 사용하도록 선택할 수 있습니다.
  </Accordion>

  <Accordion title="플래시블록과 2초 블록의 트랜잭션 포함에 차이가 있나요?">
    중요한 차이는 없습니다 — 둘 다 수수료로 트랜잭션을 정렬합니다. 주요 차이점은 타이밍입니다: 플래시블록은 2초 간격이 아닌 200ms마다 발생합니다.

    자세한 내용은 [블록 빌딩](/base-chain/network-information/block-building#flashblocks)을 참조하세요.
  </Accordion>

  <Accordion title="시퀀서가 플래시블록 게시를 중단할 수 있나요?">
    극단적인 상황에서 실행이 안전하지 않게 되지 않는 한 시퀀서는 플래시블록 게시를 중단하지 않습니다. 이 경우 사전 확인이 네트워크 전체에서 비활성화되고 확인이 표준 2초 블록으로 폴백됩니다. 시퀀서는 정상적으로 계속 운영됩니다.
  </Accordion>

  <Accordion title="트랜잭션이 포함되는 데 문제가 있는 이유는 무엇인가요?">
    큰 가스 한도(\~187.5M 블록 한도의 1/10인 \~18.75M 가스 이상)를 가진 트랜잭션은 포함 시간이 더 길 수 있습니다. 빌더가 누적 방식으로 가스를 할당하기 때문입니다 — 각 플래시블록 `j`는 총 블록 가스 한도의 최대 `j/10`을 사용할 수 있습니다. 큰 트랜잭션은 충분한 누적 용량이 생기면 포함될 수 있습니다.

    전체 분석은 [가스 및 트랜잭션 크기](/base-chain/flashblocks/app-integration#gas-&-transaction-sizing)를 참조하세요.
  </Accordion>

  <Accordion title="내 트랜잭션이 첫 번째 플래시블록에 있도록 보장할 수 있나요?">
    특정 블록을 보장할 수 없는 것처럼 트랜잭션이 어느 플래시블록에 들어갈지 보장할 방법이 없습니다. 빠른 포함 가능성을 높이려면:

    * 더 높은 우선순위 수수료 설정
    * 플래시블록 1에 적합하도록 가스 한도를 \~18.75M (블록 한도의 1/10) 미만으로 유지
  </Accordion>

  <Accordion title="트랜잭션이 수수료 순서대로 나타나지 않는 이유는 무엇인가요?">
    플래시블록 빌더는 빌드 중에 지속적으로 새 트랜잭션을 수락하는 **동적 멤풀**을 사용합니다. 이 설계는 엄격한 수수료 순서보다 **낮은 포함 지연**을 우선시합니다.

    **이것이 의미하는 바:**

    * 트랜잭션은 포함을 위해 선택되는 *시점*의 수수료로 정렬됩니다
    * 높은 수수료 트랜잭션이 낮은 수수료 트랜잭션이 현재 플래시블록에 이미 커밋된 후에 도착하면, 높은 수수료 트랜잭션은 그 뒤나 다음 플래시블록에 나타납니다
    * 이는 예상된 동작으로, 버그가 아닙니다 — 빌더는 이미 커밋된 트랜잭션을 "재정렬"하지 않습니다

    **이 트레이드오프의 이유**

    "스냅샷" 멤풀(각 블록 시작 시 트랜잭션 풀을 동결하는 방식)은 엄격한 수수료 순서를 보장하지만 포함 지연을 증가시킵니다. 동적 접근 방식은 200ms 플래시블록 창 내에서 예상되는 우선순위 가스 경매(PGA) 순서를 가끔 "깨뜨리는" 비용으로 트랜잭션을 더 빨리 포함시킵니다.

    **트레이더 및 봇:** 엄격한 수수료 기반 순서가 사용 사례에 중요한 경우, 200ms 플래시블록 창 내에서 수수료만큼 도착 타이밍이 중요하다는 점을 인식하세요.
  </Accordion>

  <Accordion title="플래시블록 리오그는 얼마나 자주 발생하나요?">
    Base는 플래시블록 리오그 비율 \< 0.1%를 목표로 합니다. 리오그는 드물지만 앱은 중요한 작업을 위한 폴백 로직을 구현해야 합니다.

    현재 지표는 [base.org/stats](https://base.org/stats)에서 확인하세요.
  </Accordion>

  <Accordion title="플래시블록이 리오그되면 어떤 의미인가요?">
    리오그는 플래시블록이 사전 확인으로 스트리밍되었지만 최종 블록에 포함되지 않았음을 의미합니다. 이는 꼬리 플래시블록 리오그를 방지하는 rollup-boost의 아키텍처 개선으로 인해 드뭅니다. 앱은 이 가능성을 우아하게 처리해야 하지만 발생 빈도는 최소화되어 있습니다.
  </Accordion>
</AccordionGroup>

***

## WebSocket

<AccordionGroup>
  <Accordion title="플래시블록 WebSocket 스트림에 직접 연결할 수 있나요?">
    **아니요.** 원시 플래시블록 WebSocket(`wss://mainnet.flashblocks.base.org/ws`)은 인프라 간 노드 데이터 동기화를 위해 예약되어 있습니다. 애플리케이션은 직접 연결해서는 안 됩니다.

    대신 RPC 노드 또는 노드 제공업체(예: QuickNode, Alchemy, Infura, dRPC)를 통해 플래시블록 데이터를 조회하세요:

    * **RPC API**: `pending` 태그가 있는 표준 JSON-RPC 메서드
    * **WebSocket 구독**: 노드 제공업체의 WebSocket 엔드포인트를 통한 `eth_subscribe` 사용

    구현 세부 사항은 [앱 통합](/base-chain/flashblocks/app-integration)을 참조하세요.
  </Accordion>

  <Accordion title="플래시블록 인덱스가 11개(0-10)인 이유는 무엇인가요?">
    인덱스 0은 시스템 트랜잭션만 포함하며 가스 한도를 사용하지 않습니다. 인덱스 1-10은 txpool에서 대기 중인 트랜잭션을 가져오는 실제 플래시블록입니다.
  </Accordion>

  <Accordion title="플래시블록이 10개 미만인 경우가 있는 이유는 무엇인가요?">
    이는 예상된 동작입니다. 이전 블록을 빌드하는 데 더 오래 걸리면 시스템은 다음 블록에 할당되는 시간을 줄여 보상하므로 플래시블록 수가 줄어듭니다.
  </Accordion>

  <Accordion title="플래시블록 인덱스가 10을 초과할 수 있나요? 버그인가요?">
    **아니요, 버그가 아닙니다.** 10, 11 이상의 인덱스를 보는 것은 예상된 동작입니다.

    표준 계산 — 2초 블록 시간 ÷ 플래시블록당 200ms — 은 정확히 10개의 플래시블록(인덱스 0-9)을 제공합니다. 그러나 실제로 하나의 전체 L2 블록에서 다음 블록으로의 전환이 항상 200ms 타이머와 완벽하게 동기화되지는 않습니다. 두 가지 상황이 추가 인덱스를 발생시킬 수 있습니다:

    1. **시퀀서 지연:** 시퀀서가 전체 블록을 최종화하고 봉인하는 데 2000ms보다 약간 더 오래 걸리면 플래시블록 스트림은 스트림을 활성 상태로 유지하기 위해 현재 블록에 대한 증분 업데이트를 계속 방출합니다.
    2. **타이밍 드리프트:** 내부 200ms 클럭이 L2 블록의 표준 시작 시간에 비해 드리프트되거나 일찍 시작되면 2초 창 내에 추가 업데이트가 맞을 수 있습니다.

    **구현에 대한 의미:**

    * `9` 또는 `10`을 최종 인덱스로 하드코딩하지 마세요 — 주어진 블록의 마지막 플래시블록은 인덱스만으로는 예측할 수 없습니다.
    * 대신 `payloadId`를 확인하세요. 블록이 완료되었다는 가장 신뢰할 수 있는 신호는 `payloadId`가 변경되거나 표준 RPC를 통해 전체 블록이 확인될 때입니다. 동일한 `payloadId`를 공유하는 모든 플래시블록은 인덱스가 얼마나 높은지에 관계없이 동일한 블록에 속합니다.
    * 시퀀서가 다음 블록으로 진행하면 `payloadId`가 재설정되고 `index`가 `0`으로 돌아갑니다.
  </Accordion>

  <Accordion title="트랜잭션 데이터의 인코딩 형식은 무엇인가요?">
    [`diff.transactions`](/base-chain/api-reference/flashblocks-api/flashblocks-api-overview#diff-object) 배열의 트랜잭션 데이터는 RLP(Recursive Length Prefix) 인코딩입니다.
  </Accordion>

  <Accordion title="WebSocket에서 속도 제한이 걸리는 이유는 무엇인가요?">
    공개 WebSocket에는 최대 연결 제한이 있습니다. 프로덕션 사용의 경우 권장 사항:

    1. 자체 [플래시블록 인식 RPC 노드](/base-chain/node-operators/run-a-base-node#enable-flashblocks) 실행
    2. 플래시블록 지원이 있는 서드파티 노드 제공업체 사용
  </Accordion>
</AccordionGroup>

***

## RPC

<AccordionGroup>
  <Accordion title="mainnet-preconf.base.org 사용 시 속도 제한이 걸리는 이유는 무엇인가요?">
    공개 엔드포인트에는 명시적인 속도 제한이 있습니다. 프로덕션 사용의 경우:

    * 플래시블록 지원이 있는 서드파티 노드 제공업체 사용 (Alchemy, Infura, QuickNode, dRPC)
    * 자체 [플래시블록 인식 RPC 노드](/base-chain/node-operators/run-a-base-node#enable-flashblocks) 실행
  </Accordion>

  <Accordion title="eth_call 'pending'이 팁보다 몇 블록 뒤의 블록 번호를 보고하는 이유는 무엇인가요?">
    이는 예상된 동작입니다. 플래시블록 인식 노드는 경쟁 조건을 방지하기 위해 최대 5개의 과거 블록 분량의 플래시블록 상태를 저장합니다. `eth_call "pending"`이 호출될 때 해당 과거 베이스 위에서 동작하므로 호출 컨텍스트에서 볼 수 있는 블록 번호(예: `block.number`)가 N-5로 보일 수 있습니다.

    `eth_call "pending"`이 실행될 때 전체 블록 컨텍스트 — `block.number`, `block.timestamp`, `block.basefee`, 그리고 모든 기타 블록 속성 — 가 현재 체인 팁이 아닌 해당 과거 베이스 블록(잠재적으로 N-5)에 해당합니다. **호출 결과는 정확합니다** — 수신된 모든 플래시블록 상태가 그 위에 적용되어 있지만 블록 컨텍스트 속성에 의존하는 컨트랙트는 해당 값이 몇 블록 뒤일 수 있음을 인식해야 합니다.

    P2P 지연이 WebSocket 스트림 지연보다 크게 높지 않은 지리적 지역에서 노드를 운영하는 경우 `MAX_PENDING_BLOCKS_DEPTH` 설정 값을 낮춰 이 차이를 줄일 수 있습니다. 이는 노드가 저장하는 최대 과거 블록 분량의 플래시블록 수를 제어하므로 낮은 값은 P2P 지연 급증에 대한 허용 범위를 줄이는 대신 블록 컨텍스트를 팁에 더 가깝게 만듭니다.
  </Accordion>

  <Accordion title="어떤 RPC 메서드가 플래시블록을 지원하나요?">
    다음 메서드가 플래시블록 지원됩니다:

    | 메서드                         | 사용법                     |
    | --------------------------- | ----------------------- |
    | `eth_getBlockByNumber`      | `pending` 태그 사용         |
    | `eth_getBalance`            | `pending` 태그 사용         |
    | `eth_getTransactionReceipt` | 사전 확인된 영수증 반환           |
    | `eth_getTransactionByHash`  | `pending` 태그 사용         |
    | `eth_getTransactionCount`   | `pending` 태그 사용         |
    | `eth_call`                  | `pending` 태그 사용         |
    | `eth_simulateV1`            | `pending` 태그 사용         |
    | `eth_estimateGas`           | `pending` 태그 사용         |
    | `eth_getLogs`               | `toBlock`에 `pending` 사용 |
    | `eth_subscribe`             | 실시간으로 플래시블록 데이터 스트리밍    |
    | `base_transactionStatus`    | 트랜잭션이 멤풀에 있는지 확인 (베타)   |

    전체 메서드 세부 사항 및 예시는 [플래시블록 API 참조](/base-chain/api-reference/flashblocks-api/flashblocks-api-overview)를 참조하세요.
  </Accordion>
</AccordionGroup>

***

## 노드 설정

<AccordionGroup>
  <Accordion title="플래시블록 인식 RPC 노드를 어떻게 설정하나요?">
    [Base 노드 저장소](https://github.com/base/node/tree/main/reth)의 Reth 바이너리를 사용하세요. 전체 설정 지침은 [플래시블록 활성화 가이드](/base-chain/node-operators/run-a-base-node#enable-flashblocks)를 참조하세요.
  </Accordion>
</AccordionGroup>