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

# 트랜잭션 문제 해결

> Base의 트랜잭션 문제를 진단하고 해결하기 위한 가이드입니다. 트랜잭션 미포함, 거부, 실패 상황별 해결 방법을 안내합니다.

## 트랜잭션이 포함되지 않는 경우

트랜잭션이 예상보다 오래 대기 중인 경우 다음을 확인하세요:

### 최대 수수료가 너무 낮음

`maxFeePerGas`가 현재 기본 수수료보다 낮으면 기본 수수료가 지정된 수준으로 떨어질 때까지 트랜잭션은 대기 상태로 유지됩니다.

**해결책**: `maxFeePerGas`는 기본 수수료와 우선순위 수수료 모두를 포함해야 합니다. 기본 수수료는 각 블록마다 변경될 수 있으므로, 트랜잭션이 대기 중인 동안 기본 수수료가 상승하더라도 유효하게 유지될 만큼 충분히 높게 `maxFeePerGas`를 설정하세요. 일반적인 접근 방식은 다음과 같습니다:

```
maxFeePerGas = baseFee * 2 + maxPriorityFeePerGas
```

이 공식([ethers.js](https://github.com/ethers-io/ethers.js/blob/98c49d091eb84a9146dfba8476f18e4c3e3d1d31/src.ts/providers/abstract-provider.ts#L945-L950)에서 사용)은 트랜잭션이 실행 불가능해지기 전에 기본 수수료가 두 배로 늘어날 수 있는 여유를 제공합니다. 최대 수수료가 아닌 포함 시점의 실제 기본 수수료만 지불합니다.

<Note>
  Base는 [최소 기본 수수료](/base-chain/network-information/network-fees#minimum-base-fee)를 가지고 있습니다. 이 값보다 낮은 `maxFeePerGas`를 가진 트랜잭션은 기본 수수료가 최솟값 아래로 떨어질 수 없으므로 포함되지 않습니다.
</Note>

### 우선순위 수수료가 너무 낮음

높은 수요 기간에 트랜잭션은 우선순위 수수료를 통해 블록 공간을 경쟁합니다. 우선순위 수수료가 다른 트랜잭션에 비해 너무 낮으면 지연될 수 있습니다.

**해결책**: 대부분의 사용자는 단순히 혼잡이 가라앉기를 기다립니다. 시간이 중요한 트랜잭션의 경우 `eth_maxPriorityFeePerGas`를 사용하여 최근 트랜잭션 중 충분히 많은 수를 능가할 수 있는 우선순위 수수료 추정값을 얻으세요.

<Note>
  [DA 스로틀링](https://docs.optimism.io/chain-operators/guides/configuration/batcher#batcher-sequencer-throttling)이 현재 적용 중인 경우, 스로틀링을 고려한 우선순위 수수료 추정을 계산하는 RPC 엔드포인트가 없습니다. DA 스로틀링 중에는 높은 우선순위 수수료를 가진 트랜잭션조차도 시퀀서가 L1 데이터 가용성 처리량을 관리하기 위해 L2 트랜잭션을 제한하므로 지연될 수 있습니다.
</Note>

### 논스 갭

논스 N의 대기 중인 트랜잭션이 있으면 논스 N+1 이상의 모든 트랜잭션은 수수료에 관계없이 뒤에 줄을 서게 됩니다.

**해결책**: 대기 중인 트랜잭션이 포함될 때까지 기다리거나, 동일한 논스와 더 높은 수수료(최소 10% 높은 `maxPriorityFeePerGas` 및 `maxFeePerGas`)로 새 트랜잭션을 제출하여 대체하세요.

### 논스가 너무 낮음

이미 사용된 논스로 트랜잭션을 제출하면 거부됩니다.

**해결책**: `pending` 태그와 함께 `eth_getTransactionCount`를 사용하여 현재 논스를 조회하여 다음 사용 가능한 논스를 얻으세요.

## 트랜잭션 거부

### 가스 한도가 최대값을 초과함

Base는 트랜잭션당 가스 최대값인 **25,000,000 가스**를 [적용합니다](/base-chain/network-information/block-building#per-transaction-gas-maximum). 더 높은 가스 한도를 지정하는 트랜잭션은 포함 전에 멤풀에서 거부됩니다.

**오류**: `exceeds maximum per-transaction gas limit`

**해결책**: 가스 한도를 25,000,000 이하로 줄이세요. 트랜잭션이 실제로 더 많은 가스가 필요한 경우 여러 트랜잭션으로 나눠야 합니다.

## 트랜잭션이 포함되었지만 실패한 경우

트랜잭션이 블록에 포함되었지만 실패 상태를 보이는 경우:

### 가스 부족

트랜잭션이 실행 중에 가스가 소진되었습니다.

**해결책**: 가스 한도를 늘리세요. `eth_estimateGas`를 사용하여 가스 추정값을 얻은 다음 변동성을 고려하여 버퍼(예: 20%)를 추가하세요.

### 컨트랙트에 의해 되돌림

컨트랙트 실행 중에 되돌림 조건이 발생했습니다.

**해결책**: [Basescan](https://basescan.org)에서 트랜잭션을 확인하여 되돌림 이유를 확인하세요. 일반적인 원인으로는 실패한 require 문, 산술 오류 또는 유효하지 않은 상태 전환이 있습니다.

## 느린 확인

### 확인 시간 이해

Base는 2초마다 블록을 생성하지만 [플래시블록](/base-chain/flashblocks/app-integration)은 200ms마다 사전 확인을 제공합니다.

| 확인 수준       | 시간      | 설명                 |
| ----------- | ------- | ------------------ |
| 플래시블록 사전 확인 | \~200ms | 사전 확인에 트랜잭션 포함     |
| L2 블록 포함    | \~2s    | 봉인된 L2 블록에 트랜잭션 포함 |
| L1 배치 포함    | \~2m    | 이더리움에 트랜잭션 게시      |
| L1 최종성      | \~20m   | 이더리움 배치 최종 확정      |

자세한 내용은 [트랜잭션 최종성](/base-chain/network-information/transaction-finality)을 참조하세요.

### 더 빠른 확인을 위한 플래시블록 사용

가장 빠른 확인을 받으려면 플래시블록 인식 RPC 엔드포인트를 사용하세요:

| 네트워크    | Flashblocks RPC                    |
| ------- | ---------------------------------- |
| 메인넷     | `https://mainnet-preconf.base.org` |
| Sepolia | `https://sepolia-preconf.base.org` |

이 엔드포인트는 전체 L2 블록을 기다리지 않고 트랜잭션이 플래시블록에 포함되는 즉시 트랜잭션 영수증을 반환합니다.

## 디버깅 도구

* **[Basescan](https://basescan.org)**: 트랜잭션 상태, 로그 및 되돌림 이유 확인
* **[Tenderly](https://tenderly.co)**: 트랜잭션 시뮬레이션 및 디버그
* **`eth_call`**: 트랜잭션을 제출하지 않고 컨트랙트 호출 테스트
* **`eth_estimateGas`**: 제출 전 가스 사용량 추정

## 도움 받기

아직 문제가 해결되지 않는다면 [Base Discord](https://base.org/discord)의 `#developer-chat` 채널에서 문의하세요.