op-batcher, 체인의 SystemConfig 수수료 파라미터,
그리고 스로틀링(throttling)을 위한 sequencer의 실행 클라이언트가 관련됩니다.
이 가이드가 필요한 경우
다음에 해당한다면 이 가이드를 사용하십시오.- OP Stack 체인을 운영하고 있습니다. 즉,
op-batcher배포를 제어하고 있으며, 파라미터 변경이 필요할 때 SystemConfig 소유자에게 연락할 수 있습니다. - batcher 장애나 동기화 문제가 아니라 경제적인 목표가 있습니다(L1 게시 비용이 너무 높아 보이거나, 사용자 수수료로 비용을 충당하지 못하는 경우).
시작하기 전에
다음이 준비되어 있어야 합니다.- 체인의 배치를 게시하고 있는 실행 중인
op-batcher, 그리고 플래그나 환경 변수를 변경하고 재시작할 수 있는 권한. - 변경 효과를 측정할 수 있도록 배치 제출자의 L1 지출 기록에 대한 접근(L1 익스플로러에서의 해당 주소).
- 쿼리할 수 있는 곳에 수집되는 batcher 메트릭. 체인 모니터링 옵션을 참고하십시오.
- 5단계를 위해 SystemConfig 소유자로서의 트랜잭션 권한(수수료 스칼라는 L1에서 설정됩니다).
1단계: 수수료 흐름 파악하기
중요한 수수료 흐름은 두 가지이며, 각각 다른 설정으로 조정됩니다. 하나는 데이터를 게시하기 위해 운영자가 L1에 지불하는 수수료(batcher 설정)이고, 다른 하나는 사용자가 운영자에게 지불하는 수수료(SystemConfig 수수료 파라미터)입니다. 트랜잭션 수수료를 읽고 다음 내용을 파악하십시오.- 사용자 수수료의 세 가지 구성 요소(실행 gas 수수료, L1 데이터 수수료, 운영자 수수료)와, L1 데이터 수수료가 batcher 지출을 회수하기 위해 존재하는 구성 요소라는 점입니다.
- L1 데이터 수수료의 가격을 결정하는 스칼라(
basefeeScalar및blobBaseFeeScalar)입니다. 이 값들은 5단계에서 설정합니다.
2단계: sequencing window 예산 균형 맞추기
비용 조정은 게시 비용과 배치 제출 속도 사이의 절충이며, sequencing window는 이 절충에 엄격한 상한을 둡니다. 배치를 빨리 제출할수록 사용자의 트랜잭션은 더 빨리 Ethereum 최종성(finality) 보장을 받습니다. 게시하기 전에 오래 누적할수록 상한까지는 바이트당 비용이 저렴해집니다. batcher 구성 가이드의 batcher 정책 섹션을 읽고 다음 내용을 파악하십시오.- 체인의 sequencing window는 표준 체인에서 3,600 L1 블록(12시간)이며, 배치는 항상 이 범위 안에서 L1에 도달해야 한다는 점입니다. sequencing window를 위반하면 12시간 reorg가 발생합니다.
- 배치 제출 목표를 1,800 L1 블록(6시간) 이하로 설정해야 하는 표준 요구 사항과, 운영자가 그보다 낮게 혼잡 대비 여유분을 두는 이유입니다.
- 제출 간격이 길면 safe head가 최대 그 간격만큼 정체되며, 이로 인해 Ethereum 최종성을 기다리는 거래소와 bridge가 지연된다는 점입니다.
3단계: 데이터 가용성 유형 선택하기
batcher는 Ethereum에 calldata 또는 blob으로 데이터를 게시하며, 이는--data-availability-type
(OP_BATCHER_DATA_AVAILABILITY_TYPE)으로 제어됩니다. 유효한 값은 calldata(플래그의 기본값), blobs,
auto입니다. blob은 채우든 채우지 않든 약 130 KB의 사용 가능한 용량 단위로 통째로 구매해야 합니다.
실제로 이것이 calldata에 유리하게 작용하는 경우는 드뭅니다. 짧은 수요 급증 시기를 제외하면 blob base fee는
blob 도입 이후 최저치 또는 그 근처에 머물러 왔으므로, 일부만 채운 blob도 같은 바이트를 calldata로 게시하는
것보다 대개 저렴합니다. 게다가 L1의 Pectra 업그레이드(EIP-7623)로 데이터가 많은 트랜잭션의 calldata
가격이 인상되었습니다.
현재 어느 시장이 더 저렴한지 확인하려면, 두 값을 모두 보여주는 gas 트래커에서 현재 blob base fee와 L1 base
fee를 비교하거나,
auto가 채널별로 비교하도록 하십시오. 전환을 실행하려면
배치 데이터를 blob으로 게시하기를 따르십시오. 이 문서는
blob으로 전환하기,
calldata로 다시 전환하기,
auto 모드를 다룹니다.
DA 유형을 전환하면 올바른 스칼라 값도 달라지므로, 같은 변경 기간에 5단계도 함께 계획하십시오.
4단계: 채널 크기 조정하기
DA 유형이 정해지면, 가장 큰 비용 조절 수단은 batcher가 게시하기 전에 데이터를 얼마나 오래 누적하는지, 그리고 blob을 사용하는 경우 트랜잭션당 몇 개의 blob을 담는지입니다.--max-channel-duration(OP_BATCHER_MAX_CHANNEL_DURATION), L1 블록 단위입니다. 기본값은0(기간 추적 비활성화)입니다. 채널 기간 권장 사항을 읽고, 권장 상한인 1,500 블록(5시간), 이를 초과하지 말아야 하는 이유, 그리고 채널이 가득 차면 이 설정과 관계없이 조기에 게시된다는 점을 파악하십시오.--target-num-frames(OP_BATCHER_TARGET_NUM_FRAMES), 목표로 하는 frame 수(따라서 blob 트랜잭션당 blob 수)입니다. 기본값은1입니다. 다중 blob 권장 사항을 읽고, 다중 blob 구성에 필요한 관련 트랜잭션 매니저 설정과 blob 혼잡 관련 주의 사항을 파악하십시오.--batch-type=1(OP_BATCHER_BATCH_TYPE)은 배치 오버헤드를 줄여주는 span batch를 활성화합니다. 기본값은0(singular)입니다. span batch 활성화하기를 따르십시오. 이 문서에는 먼저 Delta 업그레이드가 활성화되었는지 확인하는 절차가 포함되어 있습니다.
구체적인 blob 수를 구하려면, 체인이 채널 기간 동안 생성하는 압축된 배치 데이터를 추정하고 blob 용량
(~130 KB)으로 나누십시오. 7단계의 활용률 메트릭으로 이 추정치를 확인하거나 수정할 수 있습니다.
5단계: 수수료 스칼라로 지출 회수하기
저렴하게 게시하는 것은 순환의 절반일 뿐입니다. 사용자가 지불하는 L1 데이터 수수료는 실제로 지출하는 비용을 따라가야 합니다. 트랜잭션 수수료 101의 L1 수수료 섹션을 따라 SystemConfig에서basefeeScalar와 blobBaseFeeScalar를 조회하고 설정하며, 각 조정의 방향을
파악하십시오. 스칼라가 입력되는 공식과 OP Mainnet이 사용하는 값은
수수료 파라미터 참조를 참고하십시오.
측정한 batcher 지출에 맞춰 스칼라 크기를 정해, 지출에 목표 마진을 더한 만큼 회수하도록 하십시오.
3단계에서 DA 유형을 전환했다면, 같은 유지 관리 기간에 새 스칼라를 설정하십시오. calldata 사용 중에 blob에
맞는 스칼라를 사용하면(또는 그 반대의 경우) 수정될 때까지 모든 사용자 트랜잭션의 가격이 잘못 책정됩니다.
6단계: 스로틀링 방침 결정하기
스로틀링은 트래픽 급증이 DA 예산을 초과하는 것을 막는 batcher의 방어 수단입니다. 아직 게시되지 않은 데이터의 백로그가 임계값을 넘어서면, batcher는 (miner_setMaxDASize RPC를 통해) sequencer의 실행 클라이언트에
DA 사용량이 많은 트랜잭션과 블록을 제한하도록 지시합니다. 스로틀링은 기본적으로 활성화되어 있으므로,
이 단계는 무언가를 켜는 것이 아니라 기본값이 비용 방침에 맞는지 확인하는 것입니다.
batcher sequencer 스로틀링 섹션을
읽고 다음 내용을 파악하십시오.
- sequencer의 실행 클라이언트가
minerRPC 네임스페이스를 노출해야 한다는 요구 사항과, 다중 node 구성에서 sequencer를 따라가야 한다는 주의 사항입니다. - 스로틀링이 작동하기 시작하는 백로그 임계값과 최대 강도에 도달하는 기본 백로그 임계값
(
--throttle.unsafe-da-bytes-lower/upper-threshold), 그리고 기본 컨트롤러가quadratic이라는 점 (--throttle.controller-type, 옵션은step,linear,quadratic,pid)입니다.
--throttle.unsafe-da-bytes-lower-threshold=0으로 설정하여 스로틀링을
비활성화하십시오. 컨트롤러 선택과 심층적인 조정은 다음 단계의 스로틀링 심층 분석 문서를 참고하십시오.
7단계: 결과 확인하기
변경 후 최소 몇 번의 전체 채널 주기가 지나도록 기다린 다음, 순환의 양쪽을 모두 확인하십시오. batcher는op_batcher_<procname> 네임스페이스로 Prometheus 메트릭을 내보냅니다(커스텀 프로세스 이름을 설정하지 않았다면
op_batcher_default_*).
- blob 활용률 (blob 전용):
blob_used_bytes히스토그램이 blob 용량(~130 KB) 근처에 있어야 합니다. blob이 지속적으로 일부 비어 있다면 처리량에 비해 채널 기간이나 frame 수가 너무 크다는 의미입니다. 4단계를 다시 검토하십시오. - 게시 주기: 배치 제출자 주소의 batcher 트랜잭션이 선택한 간격과 대략 일치하는 주기로 L1에 나타나야 하며, 2단계의 sequencing window 기한에 절대 가까워져서는 안 됩니다.
- 평상시 스로틀링: 정상 운영 중에는
throttle_intensity가0이고unsafe_da_bytes가 하한 임계값 아래에 있어야 합니다. 스로틀링이 일상적으로 작동한다면 체인의 정상 상태 처리량이 게시 예산을 초과하는 것입니다. 6단계의 임계값을 건드리기 전에 3단계와 4단계를 다시 검토하십시오. - 경제적 결산: 대표적인 기간에 걸쳐 배치 제출자의 L1 지출과 fee vault에 들어오는 L1 수수료 수익을 비교하십시오. 수익이 지출보다 목표 마진 이상으로 많다면 건전한 결과입니다. 그렇지 않다면 5단계를 다시 검토하십시오.
다음 단계
- Batcher 구성 참조:
전체 플래그 및 환경 변수 목록입니다. 2026-07-16 기준
op-batcher/v1.10.0에 수동으로 고정되어 있으므로, 실행 중인 릴리스의op-batcher --help로 값을 확인하십시오. - op-batcher 스로틀링 심층 분석:
네 가지 스로틀링 컨트롤러, 런타임 관리 RPC, 실험적 PID 컨트롤러의 조정 프로필을 심층적으로 다루는
유일한 문서입니다.
develop브랜치의 저장소 내 문서이며, 2026-07-16 기준입니다. - op-batcher readme:
구성 이상의 batcher 아키텍처와 운영 세부 사항을 다룹니다.
develop브랜치의 저장소 내 문서이며, 2026-07-16 기준입니다. - derivation 명세의 frame 형식: 채널과 frame의 규범적 정의로, 채널에 실제로 무엇이 포함되는지 추론해야 할 때 참고합니다.