> ## Documentation Index
> Fetch the complete documentation index at: https://docs.optimism.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Batcher 비용 조정하기

> 배치 제출 안전 한도를 깨뜨리지 않으면서 OP Stack 체인이 L1에 데이터를 게시하는 데 드는 비용을 줄이고, 지출한 비용을 회수합니다.

이 가이드는 L1 데이터 게시가 온체인 운영 비용 중 가장 큰 비중을 차지하는 체인 운영자를 대상으로 비용 순환
전체를 한 번에 안내합니다. batcher가 지출하는 비용, 그 지출을 제어하는 설정, 그리고 사용자로부터 비용을
회수하는 수수료 파라미터를 다룹니다. 이 과정에는 `op-batcher`, 체인의 `SystemConfig` 수수료 파라미터,
그리고 스로틀링(throttling)을 위한 sequencer의 실행 클라이언트가 관련됩니다.

## 이 가이드가 필요한 경우

다음에 해당한다면 이 가이드를 사용하십시오.

* OP Stack 체인을 운영하고 있습니다. 즉, `op-batcher` 배포를 제어하고 있으며, 파라미터 변경이 필요할 때
  [SystemConfig 소유자](https://docs.optimism.io/ko/op-stack/protocol/privileged-roles.md)에게 연락할 수 있습니다.
* batcher 장애나 동기화 문제가 아니라 경제적인 목표가 있습니다(L1 게시 비용이 너무 높아 보이거나,
  사용자 수수료로 비용을 충당하지 못하는 경우).

batcher를 처음 구축하는 경우에는 먼저
[batcher 설정 튜토리얼](https://docs.optimism.io/ko/chain-operators/tutorials/create-l2-rollup/op-batcher-setup.md)을 따르십시오.
수수료를 변경하는 것이 아니라 수수료의 작동 방식을 이해하고 싶다면
[트랜잭션 수수료](https://docs.optimism.io/ko/op-stack/transactions/fees.md)를 읽으십시오. 대체 데이터 가용성(data availability, DA)
레이어를 검토하고 있다면 [Alt-DA 모드 가이드](https://docs.optimism.io/ko/chain-operators/guides/features/alt-da-mode-guide.md)를
참고하십시오. 이 가이드는 Ethereum DA(calldata 및 blob)만 다룹니다.

## 시작하기 전에

다음이 준비되어 있어야 합니다.

* 체인의 배치를 게시하고 있는 실행 중인 `op-batcher`, 그리고 플래그나 환경 변수를 변경하고 재시작할 수
  있는 권한.
* 변경 효과를 측정할 수 있도록 배치 제출자의 L1 지출 기록에 대한 접근(L1 익스플로러에서의 해당 주소).
* 쿼리할 수 있는 곳에 수집되는 batcher 메트릭.
  [체인 모니터링 옵션](https://docs.optimism.io/ko/chain-operators/tools/chain-monitoring.md)을 참고하십시오.
* 5단계를 위해 SystemConfig 소유자로서의 트랜잭션 권한(수수료 스칼라는 L1에서 설정됩니다).

## 1단계: 수수료 흐름 파악하기

중요한 수수료 흐름은 두 가지이며, 각각 다른 설정으로 조정됩니다. 하나는 데이터를 게시하기 위해 **운영자가**
L1에 지불하는 수수료(batcher 설정)이고, 다른 하나는 **사용자가** 운영자에게 지불하는 수수료(SystemConfig
수수료 파라미터)입니다. [트랜잭션 수수료](https://docs.optimism.io/ko/op-stack/transactions/fees.md)를 읽고 다음 내용을 파악하십시오.

* 사용자 수수료의 세 가지 구성 요소(실행 gas 수수료, L1 데이터 수수료, 운영자 수수료)와,
  [L1 데이터 수수료](https://docs.optimism.io/ko/op-stack/transactions/fees.md#l1-data-fee)가 batcher 지출을 회수하기 위해
  존재하는 구성 요소라는 점입니다.
* L1 데이터 수수료의 가격을 결정하는 스칼라(`basefeeScalar` 및 `blobBaseFeeScalar`)입니다.
  이 값들은 5단계에서 설정합니다.

그다음 [트랜잭션 수수료 101](https://docs.optimism.io/ko/chain-operators/guides/management/transaction-fees-101.md)을 훑어보고,
운영자가 조정할 수 있는 수수료 파라미터와 체인의 트래픽 패턴에 맞는 예시 시나리오를 파악하십시오.

## 2단계: sequencing window 예산 균형 맞추기

비용 조정은 게시 비용과 배치 제출 속도 사이의 절충이며, sequencing window는 이 절충에 엄격한 상한을
둡니다. 배치를 빨리 제출할수록 사용자의 트랜잭션은 더 빨리 Ethereum 최종성(finality) 보장을 받습니다.
게시하기 전에 오래 누적할수록 상한까지는 바이트당 비용이 저렴해집니다. batcher 구성 가이드의
[batcher 정책 섹션](https://docs.optimism.io/ko/chain-operators/guides/configuration/batcher.md#batcher-policy)을 읽고 다음 내용을
파악하십시오.

* 체인의 **sequencing window**는 표준 체인에서 3,600 L1 블록(12시간)이며, 배치는 항상 이 범위 안에서
  L1에 도달해야 한다는 점입니다. sequencing window를 위반하면
  [12시간 reorg](https://docs.optimism.io/ko/op-stack/protocol/outages.md#inclusion-rules)가 발생합니다.
* 배치 제출 목표를 **1,800 L1 블록(6시간) 이하**로 설정해야 하는 표준 요구 사항과, 운영자가 그보다 낮게
  혼잡 대비 여유분을 두는 이유입니다.
* 제출 간격이 길면 [safe head](https://specs.optimism.io/glossary.html?utm_source=op-docs\&utm_medium=docs#safe-l2-head)가
  최대 그 간격만큼 정체되며, 이로 인해 Ethereum 최종성을 기다리는 거래소와 bridge가 지연된다는 점입니다.

3단계와 4단계의 모든 선택은 배치 제출을 sequencing window 안에 유지해야 합니다. 체인 사용자가 Ethereum
최종성을 얼마나 오래 기다릴 수 있는지 지금 결정하십시오. 12시간이라는 엄격한 상한이 아니라 그 값이
실제 예산입니다.

## 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
가격이 인상되었습니다.

| 다음과 같은 경우 ... | 선택 ... | 이유 ... |
| - | - | - |
| 합리적인 기본값을 원함(대부분의 체인, 처리량과 관계없이) | `blobs` | blob base fee는 대부분의 시간을 최저치 또는 그 근처에서 보내며, 이때는 blob이 일부만 채워진 채 전송되더라도 blob 바이트가 calldata보다 훨씬 저렴합니다. |
| blob 수수료 급등을 자동으로 처리하고 싶음 | `auto` | batcher가 두 시장의 현재 바이트당 비용을 추정해 더 저렴한 쪽을 선택하며, 스로틀링이 활성화된 동안에는 blob을 유지합니다. |
| blob 수수료 급등이 지속되고 있고 유형을 고정하고 싶음 | `calldata` | blob 수요가 급증할 때는 calldata가 잠시 유리할 수 있습니다. 이는 예외로 취급하고, 급등이 지나가면 다시 전환하십시오(또는 `auto`로 이동하십시오). |

현재 어느 시장이 더 저렴한지 확인하려면, 두 값을 모두 보여주는 gas 트래커에서 현재 blob base fee와 L1 base
fee를 비교하거나, `auto`가 채널별로 비교하도록 하십시오. 전환을 실행하려면
[배치 데이터를 blob으로 게시하기](https://docs.optimism.io/ko/chain-operators/guides/features/blobs.md)를 따르십시오. 이 문서는
[blob으로 전환하기](https://docs.optimism.io/ko/chain-operators/guides/features/blobs.md#switch-to-using-blobs),
[calldata로 다시 전환하기](https://docs.optimism.io/ko/chain-operators/guides/features/blobs.md#switch-back-to-using-calldata),
[auto 모드](https://docs.optimism.io/ko/chain-operators/guides/features/blobs.md#use-auto-da-mode-in-your-batcher)를 다룹니다.
DA 유형을 전환하면 올바른 스칼라 값도 달라지므로, 같은 변경 기간에 5단계도 함께 계획하십시오.

## 4단계: 채널 크기 조정하기

DA 유형이 정해지면, 가장 큰 비용 조절 수단은 batcher가 게시하기 전에 데이터를 얼마나 오래 누적하는지,
그리고 blob을 사용하는 경우 트랜잭션당 몇 개의 blob을 담는지입니다.

* `--max-channel-duration` (`OP_BATCHER_MAX_CHANNEL_DURATION`), L1 블록 단위입니다. 기본값은
  `0`(기간 추적 비활성화)입니다.
  [채널 기간 권장 사항](https://docs.optimism.io/ko/chain-operators/guides/configuration/batcher.md#set-your--op_batcher_max_channel_duration)을
  읽고, 권장 상한인 1,500 블록(5시간), 이를 초과하지 말아야 하는 이유, 그리고 채널이 가득 차면 이 설정과
  관계없이 조기에 게시된다는 점을 파악하십시오.
* `--target-num-frames` (`OP_BATCHER_TARGET_NUM_FRAMES`), 목표로 하는 frame 수(따라서 blob
  트랜잭션당 blob 수)입니다. 기본값은 `1`입니다.
  [다중 blob 권장 사항](https://docs.optimism.io/ko/chain-operators/guides/configuration/batcher.md#configure-your-batcher-to-use-multiple-blobs)을
  읽고, 다중 blob 구성에 필요한 관련 트랜잭션 매니저 설정과 blob 혼잡 관련 주의 사항을 파악하십시오.
* `--batch-type=1` (`OP_BATCHER_BATCH_TYPE`)은 배치 오버헤드를 줄여주는 span batch를 활성화합니다.
  기본값은 `0`(singular)입니다. [span batch 활성화하기](https://docs.optimism.io/ko/chain-operators/guides/features/enable-span-batches.md)를
  따르십시오. 이 문서에는 먼저 Delta 업그레이드가 활성화되었는지 확인하는 절차가 포함되어 있습니다.

연결 논리는 다음과 같습니다.

| 다음과 같은 경우 ... | 선택 ... | 이유 ... |
| - | - | - |
| 처리량이 낮고 사용자가 몇 시간의 safe head 지연을 감수할 수 있음 | 긴 채널 기간(최대 1,500 블록), 단일 blob | 트래픽이 적은 체인이 비용을 지불한 만큼 채울 수 있는 유일한 방법은 더 오래 누적하는 것입니다. |
| 처리량이 낮지만 bridge/거래소에 최신 safe 블록이 필요함 | 더 짧은 채널 기간, 더 높은 바이트당 비용 감수 | safe head는 최대 채널 기간만큼 정체됩니다. 지연 시간은 저렴한 게시의 대가입니다. |
| 중간/높은 처리량 | 기간이 끝나기 전에 blob이 채워지도록 `--target-num-frames`를 조정한 `blobs` | 빈 blob 공간에 대한 비용 지불을 멈추고, 더 적은 L1 트랜잭션으로 같은 데이터를 전송합니다. |
| 모든 처리량 | Span batch (`--batch-type=1`) | Delta가 활성화된 체인에서 안전성 비용 없이 배치당 오버헤드가 줄어듭니다. |

구체적인 blob 수를 구하려면, 체인이 채널 기간 동안 생성하는 압축된 배치 데이터를 추정하고 blob 용량
(\~130 KB)으로 나누십시오. 7단계의 활용률 메트릭으로 이 추정치를 확인하거나 수정할 수 있습니다.

## 5단계: 수수료 스칼라로 지출 회수하기

저렴하게 게시하는 것은 순환의 절반일 뿐입니다. 사용자가 지불하는 L1 데이터 수수료는 실제로 지출하는 비용을
따라가야 합니다.
[트랜잭션 수수료 101의 L1 수수료 섹션](https://docs.optimism.io/ko/chain-operators/guides/management/transaction-fees-101.md#tune-the-l1-fee)을
따라 SystemConfig에서 `basefeeScalar`와 `blobBaseFeeScalar`를 조회하고 설정하며, 각 조정의 방향을
파악하십시오. 스칼라가 입력되는 공식과 OP Mainnet이 사용하는 값은
[수수료 파라미터 참조](https://docs.optimism.io/ko/chain-operators/reference/fee-parameters.md#fee-formulas)를 참고하십시오.
측정한 batcher 지출에 맞춰 스칼라 크기를 정해, 지출에 목표 마진을 더한 만큼 회수하도록 하십시오.

3단계에서 DA 유형을 전환했다면, 같은 유지 관리 기간에 새 스칼라를 설정하십시오. calldata 사용 중에 blob에
맞는 스칼라를 사용하면(또는 그 반대의 경우) 수정될 때까지 모든 사용자 트랜잭션의 가격이 잘못 책정됩니다.

## 6단계: 스로틀링 방침 결정하기

스로틀링은 트래픽 급증이 DA 예산을 초과하는 것을 막는 batcher의 방어 수단입니다. 아직 게시되지 않은 데이터의
백로그가 임계값을 넘어서면, batcher는 (`miner_setMaxDASize` RPC를 통해) sequencer의 실행 클라이언트에
DA 사용량이 많은 트랜잭션과 블록을 제한하도록 지시합니다. 스로틀링은 **기본적으로 활성화되어** 있으므로,
이 단계는 무언가를 켜는 것이 아니라 기본값이 비용 방침에 맞는지 확인하는 것입니다.
[batcher sequencer 스로틀링 섹션](https://docs.optimism.io/ko/chain-operators/guides/configuration/batcher.md#batcher-sequencer-throttling)을
읽고 다음 내용을 파악하십시오.

* sequencer의 실행 클라이언트가 `miner` RPC 네임스페이스를 노출해야 한다는 요구 사항과, 다중 node 구성에서
  sequencer를 따라가야 한다는 주의 사항입니다.
* 스로틀링이 작동하기 시작하는 백로그 임계값과 최대 강도에 도달하는 기본 백로그 임계값
  (`--throttle.unsafe-da-bytes-lower/upper-threshold`), 그리고 기본 컨트롤러가 `quadratic`이라는 점
  (`--throttle.controller-type`, 옵션은 `step`, `linear`, `quadratic`, `pid`)입니다.

이 가이드가 추가하는 결정은 다음과 같습니다. 트래픽 급증 시 백로그가 무제한으로 증가하고, 그 백로그를 L1이
그때 부과하는 가격으로 게시해야 하는 비용 노출을 감수할 것이 아니라면 스로틀링을 켜 둔 상태로 유지하십시오.
그래도 이 절충을 받아들이려면 `--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](https://docs.optimism.io/ko/chain-operators/guides/management/fee-vaults.md)에 들어오는 L1 수수료 수익을 비교하십시오.
  수익이 지출보다 목표 마진 이상으로 많다면 건전한 결과입니다. 그렇지 않다면 5단계를 다시 검토하십시오.

## 다음 단계

* [Batcher 구성 참조](https://docs.optimism.io/ko/chain-operators/reference/batcher-configuration.md):
  전체 플래그 및 환경 변수 목록입니다. 2026-07-16 기준 `op-batcher/v1.10.0`에 수동으로 고정되어 있으므로,
  실행 중인 릴리스의 `op-batcher --help`로 값을 확인하십시오.
* [op-batcher 스로틀링 심층 분석](https://github.com/ethereum-optimism/optimism/blob/develop/op-batcher/throttling.md):
  네 가지 스로틀링 컨트롤러, 런타임 관리 RPC, 실험적 PID 컨트롤러의 조정 프로필을 심층적으로 다루는
  유일한 문서입니다. `develop` 브랜치의 저장소 내 문서이며, 2026-07-16 기준입니다.
* [op-batcher readme](https://github.com/ethereum-optimism/optimism/blob/develop/op-batcher/readme.md):
  구성 이상의 batcher 아키텍처와 운영 세부 사항을 다룹니다. `develop` 브랜치의 저장소 내 문서이며,
  2026-07-16 기준입니다.
* [derivation 명세의 frame 형식](https://specs.optimism.io/protocol/derivation.html?utm_source=op-docs\&utm_medium=docs#frame-format):
  채널과 frame의 규범적 정의로, 채널에 실제로 무엇이 포함되는지 추론해야 할 때 참고합니다.