Skip to main content

Documentation Index

Fetch the complete documentation index at: https://daehan-base.mintlify.app/llms.txt

Use this file to discover all available pages before exploring further.

플래시블록의 작동 방식에 대한 종합적인 소개는 플래시블록 개요를 참조하세요.

​
블록 빌딩

모든 Base 블록은 플래시블록 빌더에 의해 구축되므로 플래시블록은 항상 활성화되어 있습니다. 그러나 앱은 사전 확인에 의존하지 않고 플래시블록 통합 없이 표준 RPC를 계속 사용하도록 선택할 수 있습니다.
중요한 차이는 없습니다 — 둘 다 수수료로 트랜잭션을 정렬합니다. 주요 차이점은 타이밍입니다: 플래시블록은 2초 간격이 아닌 200ms마다 발생합니다.자세한 내용은 블록 빌딩을 참조하세요.
극단적인 상황에서 실행이 안전하지 않게 되지 않는 한 시퀀서는 플래시블록 게시를 중단하지 않습니다. 이 경우 사전 확인이 네트워크 전체에서 비활성화되고 확인이 표준 2초 블록으로 폴백됩니다. 시퀀서는 정상적으로 계속 운영됩니다.
큰 가스 한도(~187.5M 블록 한도의 1/10인 ~18.75M 가스 이상)를 가진 트랜잭션은 포함 시간이 더 길 수 있습니다. 빌더가 누적 방식으로 가스를 할당하기 때문입니다 — 각 플래시블록 j는 총 블록 가스 한도의 최대 j/10을 사용할 수 있습니다. 큰 트랜잭션은 충분한 누적 용량이 생기면 포함될 수 있습니다.전체 분석은 가스 및 트랜잭션 크기를 참조하세요.
특정 블록을 보장할 수 없는 것처럼 트랜잭션이 어느 플래시블록에 들어갈지 보장할 방법이 없습니다. 빠른 포함 가능성을 높이려면:
  • 더 높은 우선순위 수수료 설정
  • 플래시블록 1에 적합하도록 가스 한도를 ~18.75M (블록 한도의 1/10) 미만으로 유지
플래시블록 빌더는 빌드 중에 지속적으로 새 트랜잭션을 수락하는 동적 멤풀을 사용합니다. 이 설계는 엄격한 수수료 순서보다 낮은 포함 지연을 우선시합니다.이것이 의미하는 바:
  • 트랜잭션은 포함을 위해 선택되는 시점의 수수료로 정렬됩니다
  • 높은 수수료 트랜잭션이 낮은 수수료 트랜잭션이 현재 플래시블록에 이미 커밋된 후에 도착하면, 높은 수수료 트랜잭션은 그 뒤나 다음 플래시블록에 나타납니다
  • 이는 예상된 동작으로, 버그가 아닙니다 — 빌더는 이미 커밋된 트랜잭션을 “재정렬”하지 않습니다
이 트레이드오프의 이유“스냅샷” 멤풀(각 블록 시작 시 트랜잭션 풀을 동결하는 방식)은 엄격한 수수료 순서를 보장하지만 포함 지연을 증가시킵니다. 동적 접근 방식은 200ms 플래시블록 창 내에서 예상되는 우선순위 가스 경매(PGA) 순서를 가끔 “깨뜨리는” 비용으로 트랜잭션을 더 빨리 포함시킵니다.트레이더 및 봇: 엄격한 수수료 기반 순서가 사용 사례에 중요한 경우, 200ms 플래시블록 창 내에서 수수료만큼 도착 타이밍이 중요하다는 점을 인식하세요.
Base는 플래시블록 리오그 비율 < 0.1%를 목표로 합니다. 리오그는 드물지만 앱은 중요한 작업을 위한 폴백 로직을 구현해야 합니다.현재 지표는 base.org/stats에서 확인하세요.
리오그는 플래시블록이 사전 확인으로 스트리밍되었지만 최종 블록에 포함되지 않았음을 의미합니다. 이는 꼬리 플래시블록 리오그를 방지하는 rollup-boost의 아키텍처 개선으로 인해 드뭅니다. 앱은 이 가능성을 우아하게 처리해야 하지만 발생 빈도는 최소화되어 있습니다.

​
WebSocket

아니요. 원시 플래시블록 WebSocket(wss://mainnet.flashblocks.base.org/ws)은 인프라 간 노드 데이터 동기화를 위해 예약되어 있습니다. 애플리케이션은 직접 연결해서는 안 됩니다.대신 RPC 노드 또는 노드 제공업체(예: QuickNode, Alchemy, Infura, dRPC)를 통해 플래시블록 데이터를 조회하세요:
  • RPC API: pending 태그가 있는 표준 JSON-RPC 메서드
  • WebSocket 구독: 노드 제공업체의 WebSocket 엔드포인트를 통한 eth_subscribe 사용
구현 세부 사항은 앱 통합을 참조하세요.
인덱스 0은 시스템 트랜잭션만 포함하며 가스 한도를 사용하지 않습니다. 인덱스 1-10은 txpool에서 대기 중인 트랜잭션을 가져오는 실제 플래시블록입니다.
이는 예상된 동작입니다. 이전 블록을 빌드하는 데 더 오래 걸리면 시스템은 다음 블록에 할당되는 시간을 줄여 보상하므로 플래시블록 수가 줄어듭니다.
아니요, 버그가 아닙니다. 10, 11 이상의 인덱스를 보는 것은 예상된 동작입니다.표준 계산 — 2초 블록 시간 ÷ 플래시블록당 200ms — 은 정확히 10개의 플래시블록(인덱스 0-9)을 제공합니다. 그러나 실제로 하나의 전체 L2 블록에서 다음 블록으로의 전환이 항상 200ms 타이머와 완벽하게 동기화되지는 않습니다. 두 가지 상황이 추가 인덱스를 발생시킬 수 있습니다:
  1. 시퀀서 지연: 시퀀서가 전체 블록을 최종화하고 봉인하는 데 2000ms보다 약간 더 오래 걸리면 플래시블록 스트림은 스트림을 활성 상태로 유지하기 위해 현재 블록에 대한 증분 업데이트를 계속 방출합니다.
  2. 타이밍 드리프트: 내부 200ms 클럭이 L2 블록의 표준 시작 시간에 비해 드리프트되거나 일찍 시작되면 2초 창 내에 추가 업데이트가 맞을 수 있습니다.
구현에 대한 의미:
  • 9 또는 10을 최종 인덱스로 하드코딩하지 마세요 — 주어진 블록의 마지막 플래시블록은 인덱스만으로는 예측할 수 없습니다.
  • 대신 payloadId를 확인하세요. 블록이 완료되었다는 가장 신뢰할 수 있는 신호는 payloadId가 변경되거나 표준 RPC를 통해 전체 블록이 확인될 때입니다. 동일한 payloadId를 공유하는 모든 플래시블록은 인덱스가 얼마나 높은지에 관계없이 동일한 블록에 속합니다.
  • 시퀀서가 다음 블록으로 진행하면 payloadId가 재설정되고 index가 0으로 돌아갑니다.
diff.transactions 배열의 트랜잭션 데이터는 RLP(Recursive Length Prefix) 인코딩입니다.
공개 WebSocket에는 최대 연결 제한이 있습니다. 프로덕션 사용의 경우 권장 사항:
  1. 자체 플래시블록 인식 RPC 노드 실행
  2. 플래시블록 지원이 있는 서드파티 노드 제공업체 사용

​
RPC

공개 엔드포인트에는 명시적인 속도 제한이 있습니다. 프로덕션 사용의 경우:
이는 예상된 동작입니다. 플래시블록 인식 노드는 경쟁 조건을 방지하기 위해 최대 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 지연 급증에 대한 허용 범위를 줄이는 대신 블록 컨텍스트를 팁에 더 가깝게 만듭니다.
다음 메서드가 플래시블록 지원됩니다:
메서드사용법
eth_getBlockByNumberpending 태그 사용
eth_getBalancepending 태그 사용
eth_getTransactionReceipt사전 확인된 영수증 반환
eth_getTransactionByHashpending 태그 사용
eth_getTransactionCountpending 태그 사용
eth_callpending 태그 사용
eth_simulateV1pending 태그 사용
eth_estimateGaspending 태그 사용
eth_getLogstoBlock에 pending 사용
eth_subscribe실시간으로 플래시블록 데이터 스트리밍
base_transactionStatus트랜잭션이 멤풀에 있는지 확인 (베타)
전체 메서드 세부 사항 및 예시는 플래시블록 API 참조를 참조하세요.

​
노드 설정

Base 노드 저장소의 Reth 바이너리를 사용하세요. 전체 설정 지침은 플래시블록 활성화 가이드를 참조하세요.