---
title: "유저 오퍼레이션 수수료 추정 및 청구 방식"
description: "번들러가 어떻게 인센티브를 받는지, 번들러가 유저 오퍼레이션 가스비를 어떻게 추정하는지, 그리고 발신자가 Arbitrum과 Optimism에서 유저 오퍼레이션 수수료를 어떻게 추정하는지 알아보세요."
---

# 유저 오퍼레이션 수수료 추정 및 청구 방식

ERC-4337 가스 추정에 관한 시리즈에서 [ERC-4337 가스 추정 작동 방식](https://www.alchemy.com/blog/erc-4337-gas-estimation)을 시작으로, “User Operation Flow”의 2단계인 `eth\_estimateUserOperationGas`과 그 복잡성, 즉 [가스 토큰 전송 문제](https://www.alchemy.com/blog/dummy-signatures-and-gas-token-transfers)와 [L2 가스 추정](https://www.alchemy.com/blog/l2-gas-and-signature-aggregators)의 어려움에 대해 다뤘습니다. 이번 포스트에서는 플로우의 3단계에 초점을 맞춰, 가스 수수료가 어떻게 추정되고 청구되는지 자세히 설명합니다.

이 글에서는 EIP-1559를 지원하는 체인을 다룬다고 가정합니다. user operation의 수수료 필드를 이해하려면 [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559)에 대한 배경 지식이 필요합니다.

User operation은 EIP-1559 트랜잭션과 동일한 수수료 필드를 가집니다:

- `maxFeePerGas`: 사용자가 지불하기로 입찰하는 최대 총액 \(base fee \+ priority fee\)
- `maxPriorityFeePerGas`: 사용자가 입찰하는 최대 priority fee, 즉 “팁”

Entry point는 다음 공식을 사용해 이 두 필드로부터 [결과 가스 가격을 계산합니다](https://github.com/eth-infinitism/account-abstraction/blob/033b4be2a606defd5cd5226bdde3afcea21db5fa/contracts/core/EntryPoint.sol#L600):

보시다시피 `maxFeePerGas`은 가스 가격에 대한 절대적인 상한선 역할을 하며, `maxPriorityFeePerGas`는 블록의 base fee 위에 더해지는 팁 역할을 합니다.

## Bundle 트랜잭션

[Bundler가 bundle 트랜잭션을 entry point로 보낼 때](https://www.alchemy.com/overviews/what-is-a-bundler)에도 EIP-1559 동작에 따라 도출되는 가스 가격이 적용됩니다. Bundler는 `maxFeePerGas`와 `maxPriorityFeePerGas`를 설정합니다. 최종 가스 가격은 이 값들과 트랜잭션이 포함되는 블록의 base fee로부터 계산됩니다.

Bundler는 하나의 가스 가격으로 트랜잭션을 제출하지만, 실제 보상은 bundle 내 각 user operation이 설정한, 잠재적으로 다른 가스 가격으로 이뤄집니다. user operation의 가스 가격이 더 높으면 bundler는 이익을 보고, 그렇지 않으면 해당 user operation에서 손실을 입습니다. `maxPriorityFeePerGas`은 단순히 bundler에게 주는 팁이 아니라, bundler가 block builder에게 지불해야 했던 팁을 \(bundler 자신이 builder가 아닌 이상\) 보전하는 데도 도움을 줍니다.

### Bundler는 어떻게 재정적으로 인센티브를 받나요?

Bundling은 bundler 안전성을 보장하기 위해 필요한 복잡한 시뮬레이션 때문에 비용이 많이 드는 작업일 수 있습니다. Bundler가 이런 연산 비용을 회수하고, user operation을 위한 건전한 시장을 활성화하기 위해\(이는 포함까지 걸리는 시간을 줄여 UX를 개선합니다\), bundler에게 초과 수익 형태의 재정적 인센티브가 필요합니다.

이 수익은 여러 형태를 취할 수 있습니다: priority fee, MEV, 그리고 오프체인 거래입니다.

#### 1. Priority fee

Bundler는 sender에게 자신이 트랜잭션에 지불한 priority fee보다 더 높은 priority fee를 operation에 포함시키도록 요구할 수 있습니다. 혼잡도가 높은 시기에 bundling될 확률을 높이고 싶은 sender는 priority fee 입찰을 높일 수 있습니다.

#### 2. MEV 수익

Bundler는 bundle 내 순서 지정 권한을 가지고 있으므로 mempool에 있는 operation에서 MEV를 추출할 수 있습니다. 이 이익을 취하기 위해 operation을 back-run하거나 sandwich하는 것이 자유롭습니다.

#### 3. 오프체인

Bundler는 \(MEV 보호 같은 기능을 갖춘\) 프라이빗 mempool을 운영하며 user operation sender와 오프체인 거래를 할 수 있습니다. 이 경우 수수료는 어떤 오프체인 메커니즘을 통해 강제됩니다.

건전한 네트워크를 위해서는 대부분의 user operation에 대해 \(1\)이 필수적인 옵션이라고 주장할 수 있습니다.

모든 유형의 user operation에서 양의 MEV를 추출할 수 있는 것은 아닙니다. 이 인센티브에만 의존한다면 bundler는 대부분의 user operation을 처리하지 않을 것입니다. 오프체인 거래는 중앙화를 초래하며 많은 사용자가 이 방식을 피하고 싶어할 것입니다. 결국 남는 것은 Priority Fee입니다.

Alchemy의 Rundler는 현재 bundling에 필요한 동적 priority fee를 정의합니다. 이 수수료는 현재 추정된 네트워크 수수료를 기반으로 합니다. user operation이 추정된 네트워크 수수료에 bundler를 위한 소액의 오버헤드 팁을 더한 것보다 낮게 입찰하면 bundling되지 않고 mempool에 남게 됩니다.

<CalloutBlock>

💡 P2P 네트워크가 등장하면 이는 트랜잭션 시장과 더 비슷한 형태가 될 것입니다. Sender는 이전에 채굴된 user operation을 분석해 최소 가격을 가늠할 수 있습니다. Bundler는 현재 mempool 내용을 바탕으로 사용자에게 힌트를 제공할 수 있습니다. MEV searcher 역시 연관 MEV가 높은 user operation을 mempool에서 골라, 가스비를 적게\(또는 전혀\) 지불하지 않거나 심지어 searcher가 [그 대가를 지불하도록](https://github.com/blunt-instruments/MevWallet) 요구할 수도 있습니다. 이러한 MEV 시장은 [Orderflow Auction](https://frontier.tech/the-orderflow-auction-design-space) \(OFA\)을 통해 촉진될 수 있습니다.

</CalloutBlock>

## Bundler는 가스 수수료를 어떻게 추정하나요?

[Bundling](https://www.alchemy.com/overviews/what-is-account-abstraction)에 앞서, bundler는 bundle 시장을 통해 bundle 트랜잭션의 포함을 보장하기 위해 제출할 수수료를 스스로 추정해야 합니다. 일반적으로 bundler는 다음 블록에 포함되도록 빌드하며, 포함을 보장하기 위해 적절한 가격을 입찰합니다.

Base fee를 추정하기 위해 bundler는 네트워크에 현재 블록의 base fee를 조회할 수 있습니다. 일반적으로 최소 25%\(다음 2개 블록에서 수수료가 증가할 수 있는 최대치\)의 오버헤드를 추가하는 것이 트랜잭션이 멈추지 않도록 하는 데 바람직합니다.

Priority fee를 추정하기 위해 bundler는 `eth\_maxPriorityFeePerGas`을 사용할 수 있습니다. Base fee와 마찬가지로, 트랜잭션이 채택되도록 하기 위해 여기에 일정 비율의 오버헤드를 추가하는 것이 바람직합니다.

이렇게 수수료를 추정한 후, bundler는 mempool을 조회해 \(bundler의 소액 “팁”을 포함하여\) 포함되기에 충분한 수수료를 입찰한 user operation을 필터링할 수 있습니다.

<CalloutBlock>

💡 이 섹션은 bundle 시장을 활용해 bundle을 제출하는 Bundler를 설명합니다. Bundler는 자신의 user operation bundle이 front-run되어 온체인에서 revert되고 bundler 자신이 가스비를 부담하게 되는 상황을 막기 위해 bundle 시장\(예: [Flashbots](https://www.alchemy.com/dapps/flashbots)\)을 사용해야 합니다.

Bundler가 block builder의 일부라면 상황은 달라집니다.

</CalloutBlock>

### Sender는 user operation 수수료를 어떻게 추정해야 하나요?

클라이언트 측에서 sender는 bundling에 필요한 수수료를 추정해야 합니다. 너무 낮게 추정하면 user operation이 mempool에 갇힐 수 있습니다. 너무 높게 추정하면, 특히 priority fee의 경우, 포함을 위해 과다 지불하게 될 수 있습니다.

**P2P 네트워크 이전의 Rundler와 상호작용할 때는 다음 접근 방식을 권장합니다:**

1. Base fee를 추정합니다. 가격이 불리하게 움직여도 채굴되도록 감당할 수 있는 오버헤드를 추가하세요. 최소 25%를 권장합니다.
1. `eth\_maxPriorityFeePerGas`를 사용해 priority fee를 추정합니다. 감당할 수 있는 오버헤드를 추가하세요. 최소 10%를 권장합니다.
1. 네트워크에 따른 bundler “팁” 오버헤드를 priority fee에 추가합니다.
1. Priority fee를 base fee에 더해 `maxFeePerGas`을 구합니다. `maxPriorityFeePerGas`은 2단계에서 추정한 수수료입니다.

### Arbitrum 수수료 추정

Arbitrum 시퀀서는 priority fee를 무시하며 `eth\_maxPriorityFeePerGas `는 항상 0을 반환합니다. Bundler를 보상하기 위해 우리는 bundler가 추정한 최대 base fee의 고정 비율에 해당하는 priority fee를 요구합니다. 현재 5%를 부과합니다.

### Optimism 수수료 추정

Optimism에는 이전 포스트인 [L2 가스 추정](https://www.alchemy.com/blog/l2-gas-and-signature-aggregators)에서 설명한 것처럼 수수료 추정에 영향을 미치는 엣지 케이스가 있습니다.

Optimism에서는 `maxPriorityFeePerGas = l1\_gas / l2\_base\_fee`을 설정합니다. 하지만 일반적인 Optimism 트랜잭션에서 priority fee는 L2 가스 구성요소에만 적용되기 때문에 L2 base fee보다 몇 자릿수 더 높을 수 있습니다. 따라서 우리는 bundle의 priority fee가 추정된 base fee의 고정 비율이 되도록 요구합니다. 현재 5%를 부과합니다.

<CalloutBlock>

💡 Alchemy의 [bundler 수수료 로직](https://www.alchemy.com/docs/reference/bundler-api-quickstart)에 대한 자세한 내용은 문서에서 확인할 수 있습니다.

</CalloutBlock>

## P2P mempool

P2P mempool이 가동되면 user operation 수수료에 대한 별도의 시장이 형성될 것입니다. 이는 user operation의 수수료 추정을 상당히 단순화할 수 있습니다. 위에서 설명한 것처럼 priority fee에 대해 정적인 계산을 수행하는 대신, 사용자는 수수료 이력을 이용해 입찰을 추정할 수 있습니다. 단일 bundler가 user operation을 선택하기 위해 사용하는 기준은 더 이상 중요하지 않으며, _어떤_ bundler가 그 user operation을 bundling할 만큼 가치 있다고 보는지만 중요해집니다.

Rundler는 이전에 bundling된 operation을 기반으로 입찰을 추정하기 위해 사용자가 조회할 수 있는, `eth\_feeHistory`와 유사한 `rundler\_userOperationFeeHistory` 메서드\(또는 이와 비슷한, 표준화될 수도 있는 무언가\)를 지원할 예정입니다.

🦀

## 계속 읽기

ERC-4337 가스 추정에 관한 이 기술 시리즈의 처음 세 편의 글을 놓치셨다면, ERC-4337 가스 추정이 어떻게 작동하는지, 그리고 user operation에 대한 정확한 가스 추정을 제공하기 위해 어떤 복잡성을 극복했는지 알아보세요.

- [How ERC-4337 Gas Estimation Works](https://www.alchemy.com/blog/erc-4337-gas-estimation)
- [Dummy Signatures and Gas Token Transfers](https://www.alchemy.com/blog/dummy-signatures-and-gas-token-transfers)
- [L2 Gas and Signature Aggregators](https://www.alchemy.com/blog/l2-gas-and-signature-aggregators)
