이더리움 계정 논스 완벽 정리: 순서·재전송 방지·RPC 조회법

이더리움 트랜잭션 두 건을 빠르게 보냈는데 두 번째 거래가 꼼짝하지 않았던 적이 있나요? 이때 조용히 대기열을 통제하는 규칙이 계정 논스(Account Nonce)예요. 논스는 작은 정수 하나지만, 한 계정이 보낸 거래의 순서를 엄격하게 정합니다. 평소 지갑이 감춰 주는 블록체인 기초지만 거래가 멈추거나 개발자가 여러 요청을 동시에 보낼 때 존재감이 드러나요.

여기서 다루는 것은 프로토콜의 계정 논스입니다. 일부 암호학적 서명에서 쓰는 임의 논스나 비트코인 채굴 논스와는 달라요. 지갑에서 멤풀(Mempool), 블록으로 이어지는 흐름을 살핀 뒤 RPC 조회와 문제 해결 원칙까지 연결해 보겠습니다.

이더리움 계정 논스란 무엇인가요?

일반적인 외부 소유 계정(Externally Owned Account, EOA)의 논스는 이더리움 상태에 저장되는 카운터예요. 그 계정이 보내는 트랜잭션에는 논스가 들어가고, 다음으로 유효한 거래는 현재 계정 값과 같은 논스를 사용합니다. 거래가 실행되면 상태의 논스가 앞으로 이동해요.

빵집 번호표를 떠올려 보세요. 42번을 처리해야 43번 차례가 옵니다. 여러 주문을 미리 적어 둘 수는 있지만 42번이 빠졌다고 43번부터 유효해지는 것은 아니에요. 이더리움은 이 순서를 보내는 계정마다 독립적으로 적용합니다.

Ethereum.org 계정 문서에 따르면 한 계정에서 같은 논스를 가진 거래는 하나만 실행될 수 있어요. 여기서 두 가지 성질이 나옵니다.

• 순서 보장: 한 발신자의 거래가 임의 순서로 실행되지 않아요.
• 재전송 공격 방지: 이미 소비한 논스의 서명 거래는 같은 체인 상태에서 다시 실행될 수 없어요.

논스는 전 세계 공통 거래 번호가 아닙니다. 앨리스의 논스 12와 밥의 논스 12는 서로 관계가 없어요. 각 계정이 자기 카운터를 갖습니다.

논스 순서는 어떻게 작동하나요?

어떤 계정의 다음 유효 논스가 7이라고 가정해 볼게요.

여기서 나중에는 유효함과 지금 실행 가능함을 구분해야 합니다. Geth는 실행 가능한 대기 거래와 논스 공백 때문에 줄을 선 거래를 나눠 관리해요. Geth txpool 문서는 한 계정의 같은 논스에 수수료 조건 등이 다른 여러 거래가 풀에 존재할 수도 있다고 설명합니다. 하지만 정식 체인 상태에서 그 논스를 소비하는 거래는 하나뿐이에요.

노드마다 로컬 멤풀이 있고, 이더리움 전체가 공유하는 단 하나의 대기실이 있는 것은 아닙니다. 따라서 두 RPC 제공자가 잠시 서로 다른 후보를 볼 수 있어요. 무엇이 체인에 들어갈지는 합의가 정하고, 포함되기 전 무엇을 저장하고 전파할지는 각 노드의 풀 정책이 정합니다.

논스는 왜 재전송 공격을 막나요?

서명은 권한을 증명하지만, 그 명령이 새로운지는 말해 주지 못합니다. 한 번 쓴 순서 값이 없다면 누군가 과거의 서명된 송금 거래를 다시 방송해 실행을 요구할 수 있어요.

계정 논스는 한 번만 쓰는 물품 보관표와 비슷합니다. 서명은 논스를 포함한 트랜잭션 필드에 묶여 있어요. 논스 7이 소비된 뒤에는 같은 발신자의 논스 7 거래가 계정이 요구하는 다음 값과 맞지 않습니다. 똑같은 서명 바이트를 다시 방송해도 카운터가 되돌아가지 않아요.

계정 단위 보호와 체인 단위 재전송 방지는 구분해야 합니다. 이더리움 서명의 체인 ID는 한 체인용 거래가 다른 호환 체인에서 재사용되는 일을 막는 데 도움을 줘요. 계정 논스와 체인 ID는 관련 있지만 서로 다른 재전송 문제를 해결합니다.

논스 공백·대체 거래·막힌 대기열

논스 순서를 알면 지갑에서 자주 보는 세 가지 현상을 설명할 수 있어요.

높은 논스 거래가 대기열에 들어갔어요

논스 21이 빠진 상태에서 22와 23을 방송하면 뒤의 거래가 먼저 갈 수 없습니다. 발신자는 유효한 논스 21 거래를 포함시키거나, 기존 논스 21 후보를 대체하거나, 로컬 풀 상태가 바뀐 뒤 순서를 신중하게 다시 구성해야 해요.

두 거래가 같은 논스를 사용해요

두 거래는 순서대로 실행할 작업이 아니라 서로 경쟁하는 대안입니다. 지갑의 '속도 높이기(Speed up)'와 '취소(Cancel)'는 보통 같은 논스를 쓰되 연결된 노드의 교체 정책을 충족하려는 수수료 조건으로 새 거래를 만듭니다. 취소는 서명 거래를 지우는 기능이 아니에요. 다른 같은-논스 거래를 먼저 포함시키려는 경쟁입니다.

논스가 너무 낮다는 오류가 나요

노드는 보통 정식 상태나 대기 상태가 제출한 값보다 이미 앞섰다고 판단한 거예요. 재시도하기 전에 계정, 체인, 확정 상태, 대기 상태가 맞는지 비교하세요. RPC가 받아 줄 때까지 무작정 논스를 올리면 의도하지 않은 송금이나 컨트랙트 호출을 만들 수 있습니다.

JSON-RPC로 논스를 읽는 법

이더리움 표준 메서드는 eth_getTransactionCount입니다. 이름은 거래 수를 뜻하는 것처럼 보이지만 현재 Execution API 명세는 결과를 계정 논스로 정의해요. Pectra와 EIP-7702 이후에는 단순히 '보낸 거래 개수'와 같다고 볼 수 없다는 경고도 있습니다.

{
  "jsonrpc": "2.0",
  "method": "eth_getTransactionCount",
  "params": ["0xYourAddress", "pending"],
  "id": 1
}

결과는 16진수 부호 없는 정수예요. 예를 들어 0x2a는 10진수 42입니다.

블록 매개변수에 따라 질문이 달라져요.

• latest: 그 노드가 관찰한 최신 정식 블록의 논스를 묻습니다.
• pending: 노드의 로컬 풀로 만든 샘플 대기 블록 기준의 논스를 묻습니다.
• 특정 블록 번호 또는 해시: 제공자가 지원한다면 그 시점의 과거 상태를 묻습니다.

다음 거래를 만들 때 개발자는 흔히 pending을 참고해요. 하지만 이것은 동시성 잠금이 아닙니다. 두 작업자가 어느 쪽도 방송하기 전에 같은 값을 읽을 수 있어요. 운영 환경에서는 계정별로 거래 생성을 직렬화하고, 논스를 원자적으로 예약하며, 서명한 페이로드를 기록하고, 영수증을 대조하고, 드롭된 거래를 정해진 절차로 복구하는 논스 매니저가 필요합니다.

Pectra 이후 개발자가 알아야 할 변화

예전에는 EOA 논스를 '보낸 트랜잭션 수'라고 간단히 설명해도 대체로 맞았습니다. 이제 이 표현은 안전하지 않아요. EIP-7702 권한 처리 과정에서 권한 계정의 논스가 증가할 수 있어서 공식 API도 반환값을 단순 전송 횟수가 아닌 계정 논스라고 명확히 부릅니다.

실무 원칙은 간단해요. 필요한 프로토콜 상태를 직접 조회하고 관리하세요. 블록 탐색기 행을 세어 다음 논스를 재구성하면 안 됩니다. 탐색기는 드롭된 거래를 빼거나, 내부 호출을 다르게 분류하거나, 계정 논스 변화와 일대일로 대응하지 않는 활동을 보여 줄 수 있어요.

프로토콜 경계에서는 최종 확정된 EIP-2681이 계정 논스의 한도를 정하고, 2^64 - 1 이상인 논스의 트랜잭션을 무효로 만듭니다. 일반 사용자가 이 한도에 가까워질 일은 없어요. 클라이언트와 증명 형식에 명확한 경계를 준다는 점이 중요합니다.

안전한 구현 체크리스트

지갑 사용자라면 다음을 확인하세요.

• 논스를 비교하기 전에 발신 주소와 네트워크가 맞는지 확인해요.
• 가장 최근 거래보다 가장 낮은 미해결 논스를 먼저 찾습니다.
• 잘 모르는 원시 필드를 직접 고치지 말고 지갑의 공식 대체 절차를 써요.
• 대체 거래에 서명하기 직전 온체인 상태를 다시 확인합니다.

개발자라면 다음 원칙이 필요해요.

• 발신 계정마다 하나의 조정된 논스 할당기를 유지합니다.
• pending을 전체 네트워크의 약속이 아니라 한 노드의 관찰로 취급해요.
• 트랜잭션 해시·논스·서명 원문·의도한 작업을 함께 저장합니다.
• 재시작하거나 RPC 제공자를 바꾼 뒤 영수증과 정식 계정 상태를 대조해요.
• 한 작업이 다른 작업을 의도적으로 대체하는 경우가 아니면 논스를 재사용하지 않습니다.

결과를 진단할 때 트랜잭션 영수증은 포함된 거래의 성공 여부를 알려 주고, 이더리움 콜데이터는 어떤 컨트랙트 작업을 승인했는지 파악하게 해 줍니다. 논스는 다른 질문, 즉 '이 발신자의 명령이 순서상 어디에 있었나?'에 답해요.

리스크와 한계

논스를 수동으로 다루는 일은 비용이 들고 되돌릴 수 없는 결과를 낳을 수 있습니다. 같은 논스의 대체 거래가 원치 않은 작업을 실행할 수 있어요. 높은 논스의 송금이 잊고 있던 사이 나중에 실행 가능해질 수도 있습니다. RPC 제공자의 관찰 차이 때문에 드롭된 거래가 살아 있는 것처럼, 살아 있는 후보가 사라진 것처럼 보일 수 있어요. 스마트 계정은 전통적인 EOA 단일 카운터보다 복잡한 논스 체계를 정의할 수도 있습니다.

논스를 '고쳐 주겠다'며 시드 문구나 개인 키를 요구하는 사람에게 절대 알려 주지 마세요. 정상적인 고객 지원에는 키의 소유권이 필요하지 않습니다. 맞춤형 전송 인프라는 테스트넷에서 먼저 검증하고, 실제 자산을 움직일 때는 잃어도 되는 소액으로 시험하며, 최신 지갑과 클라이언트 공식 문서를 확인하세요.

자주 묻는 질문

모든 이더리움 트랜잭션의 논스는 고유한가요?

특정 발신자의 실행 기록 안에서 고유합니다. 서로 다른 계정은 같은 숫자를 쓸 수 있어요. 같은 발신자·논스 조합의 여러 후보가 대기 풀에 존재할 수도 있지만 정식 상태에서 소비하는 거래는 하나뿐입니다.

논스 12가 논스 11보다 먼저 실행될 수 있나요?

일반적인 같은 EOA에서는 안 됩니다. 노드가 논스 12를 대기열에 보관할 수는 있지만, 계정 상태가 논스 11을 거쳐 앞으로 이동하기 전에는 실행할 수 없어요.

eth_getTransactionCount는 정확한 전송 횟수인가요?

아니요. 이 메서드는 계정 논스를 반환합니다. 이름은 역사적으로 남은 것이며 Pectra 이후 EIP-7702 동작 때문에 단순 거래 수로 해석하면 안 돼요.

애플리케이션은 항상 pending을 써야 하나요?

무조건은 아닙니다. 로컬 대기 거래를 반영하는 데 도움이 되지만 한 노드의 풀을 볼 뿐이고, 여러 호출자가 같은 논스를 고르는 것도 막지 못해요. 조정된 논스 관리와 사후 대조가 필요합니다.

이더리움 논스와 비트코인 채굴 논스는 같은가요?

다릅니다. 이더리움 계정 논스는 발신자 거래의 순서를 정해요. 작업증명 채굴 논스는 난이도 조건에 맞는 블록 해시를 찾으려고 바꾸는 값입니다.

기억할 핵심 모델

이더리움 계정 논스는 발신자별 대기 순번이자 한 번만 쓰는 재전송 방지 장치입니다. 다음 값은 실행할 수 있고, 미래 값은 기다리며, 소비한 값은 다시 실행할 수 없고, 같은 논스 거래끼리는 대안으로 경쟁해요. 이 모델만 알아도 지갑을 블랙박스로 보지 않고 'queued', 'nonce too low', 대체 거래 현상을 대부분 설명할 수 있습니다.

이 글은 교육 목적이며 투자 조언이 아닙니다. 온체인 작업은 되돌릴 수 없고 수수료와 지갑 동작은 바뀔 수 있으며 실수하면 영구 손실이 생길 수 있어요. 최신 공식 문서를 확인하고, 익숙하지 않은 과정은 잃어도 되는 금액으로 시험하며, 스스로 조사하세요(DYOR).