이더리움 거래가 대기하는 이유: 논스 순서와 교체·취소 시도

이더리움 거래에 서명한 뒤 지갑은 실행 클라이언트나 거래 중계 서비스에 거래를 보낼 수 있습니다. 거래를 받은 노드는 이를 다른 노드에 전달할 수 있고, 블록 제안자가 나중에 블록에 포함할 수 있습니다. 그전까지 거래는 정식 체인의 상태를 바꾸지 않습니다. 지갑이나 블록 탐색기에 “대기 중”이라고 표시되면 대개 해당 서비스가 거래를 알고 있지만 아직 블록 안에서 확인하지 못했다는 뜻입니다. 네트워크 전체가 공유하는 단일 대기열을 가리키는 말은 아닙니다. Ethereum.org의 거래 안내는 서명, 전파, 블록 포함으로 이어지는 과정을 설명합니다.

거래가 기다리는 이유는 한 가지가 아닙니다. 수수료 상한이 블록 조건에 맞지 않을 수 있고, 같은 계정에서 먼저 보낸 거래가 아직 해결되지 않았을 수도 있습니다. 확인 중인 노드가 거래를 받지 못했거나, 지갑이 오래되었거나 특정 제공자의 정보만 보여줄 수도 있습니다. 원인마다 확인할 내용이 다릅니다. 수수료를 높여도 네트워크를 잘못 선택한 문제가 해결되지는 않습니다. 첫 거래의 상태를 확인하지 않고 같은 결제를 다시 보내면 두 번 지불하게 될 수 있습니다.

“대기”, “확정”, “최종성 확보”, “실패”는 같은 상태가 아닙니다. 거래 해시는 영수증이 생기기 전에 보일 수 있습니다. 영수증은 거래가 블록에 포함된 후 확인할 수 있습니다. 이후 이더리움 블록은 합의 과정의 상태를 거칩니다. 지갑과 탐색기는 이 단어들을 서로 다르게 사용할 수 있으므로, 화면의 짧은 상태 문구만 믿기보다 거래 해시와 블록, 영수증, 현재 체인 상태를 살펴보세요.

일반적인 이더리움 외부 소유 계정(EOA)에는 거래 순서를 정하는 논스가 있습니다. 논스는 수수료나 시간 기록, 고유한 거래 해시가 아니라 계정별 카운터입니다. 체인은 계정 상태에서 다음으로 예상하는 논스와 일치하는 거래를 받아들입니다. 같은 계정은 동일한 논스를 가진 거래 두 개를 정식 체인에서 모두 실행할 수 없습니다. Ethereum.org의 계정 문서는 논스를 계정 거래 카운터이자 재전송 공격을 막는 수단으로 설명합니다.

다음으로 사용 가능한 계정 논스가 41이라고 가정해보겠습니다. 그 계정이 보내는 다음 유효 거래에는 논스 41을 사용하고, 해당 거래가 포함되어 처리된 뒤 다음 거래에는 42를 사용합니다. 논스는 받는 사람 주소가 아니라 보내는 계정에 붙습니다. 계정마다 별도의 순번이 있으므로 서로 다른 두 계정이 동시에 논스 41 거래를 갖는 것은 가능합니다.

현재 온체인 논스보다 큰 논스로 거래에 서명할 수는 있지만, 실행할 때 순서를 건너뛸 수는 없습니다. 빠진 앞선 논스가 먼저 소비되어야 합니다. 계정이 이미 소비한 논스를 다시 사용하는 거래는 오래된 거래이므로 새 거래처럼 실행될 수 없습니다. 이 순서 규칙은 여러 노드를 거쳐 다른 시점에 전파된 거래도 계정별로 순서대로 처리되도록 합니다.

논스 규칙은 이더리움 실행 계층의 일반적인 EOA 거래에 적용됩니다. 모든 지갑 추상화, 롤업 시퀀서, 다른 체인의 동작을 한꺼번에 설명하는 규칙은 아닙니다. 스마트 계정 시스템은 별도의 작업 순서와 논스 규칙을 추가할 수 있으며, 뒤에서 다룹니다.

이더리움에는 모든 지갑, 노드, 블록 탐색기, 블록 제안자가 똑같이 보는 하나의 동기화된 대기실이 없습니다. 각 실행 클라이언트는 자신이 받은 거래 중 자체 한도와 정책에 따라 유효하다고 판단한 거래를 로컬 거래 풀에 보관합니다. 한 노드에 있는 거래가 다른 노드에는 없을 수 있습니다. Geth의 txpool RPC 문서는 해당 클라이언트의 로컬 pending과 queued 묶음을 보여주며, 같은 발신 계정과 논스에 거래 후보가 여러 개 존재할 수 있다고 설명합니다.

Geth에서 pending은 보통 현재 계정 상태에서 논스 순서대로 처리할 수 있는 거래를, queued는 논스 공백이 메워지기를 기다리는 더 뒤의 거래를 뜻합니다. 이 용어는 클라이언트 인터페이스의 구분이지, 이더리움 합의 규칙이 모든 소프트웨어에 동일한 상태 이름을 강제한다는 뜻은 아닙니다. 어떤 지갑은 미확인 거래 목록 전체를 “pending”이라고 하고, 어떤 탐색기는 자체 데이터 제공자가 관찰한 거래만 표시할 수 있습니다.

예를 들어 한 노드가 논스 41 거래와 논스 43 거래를 알고 있어도, 43을 42보다 먼저 실행할 수는 없습니다. 그 노드는 42가 도착하거나 계정 상태가 다른 방식으로 바뀔 때까지 43을 대기열에 둘 수 있습니다. 반면 43을 받지 못한 다른 노드에는 그 거래가 보이지 않습니다. 두 탐색기가 거래를 “대기 중” 또는 “찾을 수 없음”으로 다르게 보여도, 어느 화면 하나만으로 모든 검증자가 무엇을 받았는지 증명되지는 않습니다.

일부 클라이언트는 같은 발신자와 논스에 대해 미확인 거래 후보를 둘 이상 보관합니다. 이들은 순서대로 모두 적용될 거래가 아니라 동일한 순번을 차지하려는 대안입니다. 풀 용량, 거래 보관 시간, 교체 조건은 구현체의 정책이고 소프트웨어 버전에 따라 바뀔 수 있습니다. 예를 들어 Geth의 거래 풀 설정에는 해당 클라이언트에서 쓰는 가격 인상 기준이 있습니다. 이 값을 모든 이더리움 거래에 적용되는 수수료 규칙으로 보면 안 됩니다. 설정 범위는 Geth 명령줄 참고 문서에서 확인할 수 있습니다.

계정의 다음 온체인 논스가 41이라고 가정해보겠습니다. 논스 41로 거래 A를 전파하고, 이어서 논스 42로 거래 B를 보냈습니다. A가 해결되지 않으면 B가 먼저 적용될 수 없습니다. B는 로컬 대기열에 머물거나 지갑에서만 대기 중으로 보이거나, 아직 받지 못한 탐색기에는 아예 나타나지 않을 수 있습니다. 중요한 것은 지갑이 두 거래를 어떤 순서로 만들거나 보여줬는지가 아니라 논스 순서입니다.

A가 나중에 포함되면 계정 논스가 42로 진행되고, B는 자체 유효성, 수수료 조건, 거래 풀 정책을 충족할 때 실행될 수 있습니다. 논스 41의 A가 다른 유효 거래로 교체되면, 그 교체 거래가 포함되는 경우 같은 순번을 차지합니다. 계정의 다른 거래가 이미 논스 41을 소비했다면 기존 41 후보는 오래된 거래가 되어 나중에 실행할 수 없습니다.

따라서 더 높은 논스로 새 거래를 보내는 것은 멈춘 거래를 일반적으로 풀어주는 방법이 아닙니다. 빠진 순번 뒤에 거래를 하나 더 보탤 뿐입니다. 이미 뒤의 거래인 B를 취소해도 A가 해결되는 것은 아닙니다. 가장 먼저 해결되지 않은 계정 논스부터 찾고, 바꾸기 전에 그 상태를 확인해야 합니다.

논스 공백은 잠시 생겼다가 사라질 수도 있고 오래 남을 수도 있습니다. 앞선 거래가 지금 확인하는 노드까지 전파되지 않았거나, 수수료 조건이 현재 상황에서 매력적이지 않거나, 특정 노드 풀에서 제거되었을 수 있습니다. 다른 기기에서 만든 거래를 지갑이 예약 상태로 보여줄 수도 있습니다. 화면만으로는 어느 경우인지 알 수 없습니다. 계정의 확정 논스, 거래 해시, 신뢰할 수 있는 둘 이상의 조회 결과를 함께 비교하세요.

논스 순서와 수수료 조건은 별개의 제약입니다. 다음 순번에 맞는 거래여도 블록에 포함될 조건을 충족하지 못하면 기다릴 수 있습니다. 반대로 뒤의 논스 거래가 더 큰 팁을 제시해도 앞서 실행될 수는 없습니다. 논스 42 거래의 수수료를 올려도 논스 41 거래가 사라지지는 않습니다.

일반적인 EIP-1559 거래에서는 최대 수수료가 포함될 블록의 기본 수수료를 감당할 수 있어야 하고, 우선 수수료는 블록 제안자의 선택에 영향을 줄 수 있습니다. 거래가 기다리는 동안 기본 수수료와 블록 공간은 달라질 수 있습니다. 최대 수수료는 상한이며, 상한을 높였다고 특정 시점의 포함이 보장되는 것은 아닙니다. 이더리움 가스비 안내는 각 항목과 유효 수수료 계산을 설명합니다.

노드나 지갑은 자체 전파·교체 기준을 추가로 적용할 수 있습니다. 이 정책은 특정 서비스가 어떤 거래를 받아들이거나 전달할지를 정하는 것이며, 모두가 합의해야 하는 규칙은 아닙니다. 예를 들어 Geth는 자체 거래 풀에서 대기 거래를 교체하는 데 사용할 가격 인상 기준을 설정할 수 있습니다. 다른 클라이언트, 제공자, 지갑, 소프트웨어 버전은 다르게 동작할 수 있습니다. 기억에 의존한 수수료 비율이나 정해진 대기 시간을 네트워크 전체의 보장으로 생각하지 마세요.

낮은 논스가 해결되지 않아 기다린다면 먼저 그 순번을 가진 거래를 찾으세요. 현재 기본 수수료를 감당하지 못해 기다리는 것으로 보인다면 거래 수수료 필드를 이해한 다음 바꾸세요. 수수료 계산에는 앞서 연결한 가스비 안내가 적합하고, 이 글은 그와 별개인 계정 순서 문제에 집중합니다.

지갑의 “속도 올리기”는 보통 같은 계정과 논스를 쓰되 수수료 설정을 조정한 새 거래를 만듭니다. 같은 논스의 두 후보는 서로 충돌합니다. 계정은 그 순번을 가진 거래 하나만 실행할 수 있기 때문입니다. 교체 거래가 관련 거래 풀에서 받아들여지고 블록에 포함되면 그 거래가 해당 논스 순번을 차지할 수 있으며, 원래 거래는 정식 체인에서 함께 실행될 수 없습니다. MetaMask의 대기 거래 안내는 해당 제품의 속도 올리기 흐름이 더 높은 수수료와 같은 논스를 사용해 다시 제출한다고 설명합니다.

교체 거래는 원래 목적지와 동작을 유지하면서 수수료 필드만 바꿀 수도 있지만, 화면을 직접 확인하지 않은 채 그렇게 된다고 가정하지 마세요. 지갑 구현에 따라 다른 입력을 보여주거나 기능 이름이 다를 수 있습니다. 서명하기 전에 발신 계정, 논스, 받는 주소, 금액, 컨트랙트 데이터를 확인하세요. 거래의 동작 자체가 달라진다면 단순한 수수료 조정이 아닙니다.

교체 거래가 모든 곳에서 받아들여지거나 빠르게 포함되는 것은 아닙니다. 원래 거래가 이미 포함되었을 수 있고, 노드가 자체 정책에 따라 교체를 거부할 수 있습니다. 교체 거래의 조건도 블록 제안자에게 여전히 매력적이지 않을 수 있고, 확인 중인 노드까지 전파되지 않을 수도 있습니다. 원래 거래가 확정되었다면 이미 소비된 논스로 새 거래를 보내 이를 되돌릴 수 없으며, 보통 오래된 논스로 거부됩니다.

여기서 “교체”는 같은 계정과 논스를 가진 경쟁 거래를 뜻합니다. Bitcoin의 RBF나 CPFP 절차를 이더리움에 가져와 적용하지 마세요. Bitcoin은 다른 거래 구조를 사용하며, 그 수수료 조정 방식은 이더리움 계정의 처리 방법이 아닙니다.

서명한 이더리움 거래를 전파한 뒤 모든 노드에서 회수하는 프로토콜 차원의 실행 취소 명령은 없습니다. 일부 지갑은 거래가 아직 미확인일 때 취소 기능을 제공합니다. 이 기능은 보통 같은 계정에서 같은 논스를 쓰는 다른 거래를 전파하려고 시도합니다. 흔한 지갑 방식 중 하나는 자기 주소로 보내는 금액 0의 거래를 만드는 것입니다. 취소 후보가 원래 거래보다 먼저 받아들여져 블록에 포함되면 해당 논스를 소비하므로, 원래 후보는 나중에 실행될 수 없습니다. 정확한 생성 방식과 사용 가능 여부는 지갑에 따라 다릅니다.

원래 거래와 취소 후보는 서로 경쟁합니다. 원래 거래가 먼저 포함되면 그 뒤에 보낸 취소는 이미 발생한 효과를 되돌리지 못합니다. 어느 후보도 받아들여지거나 포함되지 않으면 논스가 계속 해결되지 않을 수 있습니다. 지갑의 버튼을 눌렀거나 성공 알림을 받았다고 취소 후보가 이겼다고 단정할 수 없습니다. 새 거래 해시와 정식 체인의 상태를 확인하세요. MetaMask 안내도 아직 대기 중인 거래에 대한 취소 시도라고 범위를 한정하고, 확정된 거래는 취소할 수 없다고 설명합니다.

취소 거래에 서명하기 전에 대상 거래와 같은 계정·논스를 사용하는지 확인하고 지갑이 보여주는 모든 필드를 살펴보세요. 포함되면 네트워크 수수료를 새로 내야 할 수 있습니다. 취소 후보도 기다리거나 관련 거래 풀의 정책에 따라 원래 거래를 대체하지 못할 수 있습니다. 지갑이 “취소됨”이라고 표시하더라도 프로토콜에서 이미 처리된 거래를 되돌렸다는 뜻은 아닙니다. 어떤 거래가 해당 논스를 소비했는지 확인한 뒤 결과를 판단하세요.

거래가 이미 실행되어 토큰 승인, 컨트랙트 호출, 자산 전송이 끝났다면 나중의 거래를 취소해 그 상태 변경을 되돌릴 수 없습니다. 일부 컨트랙트 동작에는 별도의 후속 기능이 있을 수 있지만, 가능 여부와 결과는 컨트랙트에 따라 다릅니다. 화면에 취소라고 쓰여 있다는 이유만으로 익숙하지 않은 거래에 서명하지 마세요.

블록에 포함된 거래에는 블록 정보와 영수증이 있습니다. 실행에 성공하면 의도한 상태 변경이 적용될 수 있습니다. EVM 실행이 되돌려졌다면 그 실행에서 발생한 상태 변경은 롤백되지만, 거래의 계정 논스는 소비되며 가스비가 들 수 있습니다. 지갑의 알림만 보고 성공 여부를 추측하지 말고 거래 영수증과 실행 상태를 확인하세요. 포함과 실행 결과의 차이는 Ethereum.org의 거래 안내와 가스비 안내에서 확인할 수 있습니다.

“제거됨” 또는 “찾을 수 없음”은 특정 지갑, 탐색기, RPC 제공자, 로컬 거래 풀이 보고하는 상태인 경우가 많습니다. 그 문구만으로 프로토콜이 거래를 취소했거나 해당 논스가 비었다고 증명되지는 않습니다. 다른 노드에는 거래가 남아 있을 수 있고, 지갑이 서명된 거래를 다시 전파할 수도 있습니다. 반대로 확인한 화면들에서 거래가 보이지 않더라도 계정의 확정 논스가 그대로일 수 있습니다.

거래 해시를 찾을 수 없다면 같은 체인과 거래를 만든 계정을 선택했는지 확인하세요. 계정의 최신 온체인 논스와 거래 논스를 비교하고, 해당 발신 계정의 최근 거래를 살펴보세요. nonce too low 응답은 현재 조회 중인 엔드포인트 관점에서 해당 논스가 이미 소비되었을 수 있다는 단서이지, 같은 요청을 계속 반복하라는 뜻이 아닙니다. 어떤 거래가 논스를 사용했는지, 해당 블록이 여전히 정식 체인인지 확인하세요.

포함된 거래도 체인이 안정화되기 전의 짧은 재구성 영향을 받을 수 있습니다. 지갑과 탐색기는 관측 상태가 바뀌면 표시를 고칠 수 있습니다. 중요한 전송이라면 받는 서비스의 확인 기준을 따르고, 필요한 경우 더 강한 합의 최종성을 확인하세요. “한 블록에서 보였다”는 말과 “어떤 상황에서도 되돌릴 수 없다”는 말은 같지 않습니다.

먼저 올바른 체인과 발신 계정, 거래 해시를 확인하세요. 해당 네트워크의 신뢰할 수 있는 탐색기에서 해시를 조회해 영수증 유무, 논스, 실행 성공 여부, 발신 계정의 이후 거래를 살펴보세요. 거래 확인을 위해 시드 문구를 공개하거나 입력할 필요는 없습니다. 공개 주소와 거래 해시만으로도 공개 체인의 정보를 조회할 수 있습니다.

해시가 보이지 않으면 계정의 최신 확정 논스와 지갑이 보여주는 논스를 비교하세요. 개발자나 노드 운영자는 latest와 pending 블록 태그를 사용해 eth_getTransactionCount를 조회할 수 있습니다. Ethereum.org의 JSON-RPC 참고 문서는 latest가 최신 블록 상태를, pending이 대기 상태를 가리킨다고 정의합니다. pending 값도 해당 RPC 엔드포인트의 관측 결과입니다. 제공자 두 곳에 질의하면 값이 다를 수 있습니다. 대부분의 사용자는 명령을 실행하지 않아도 지갑의 계정 활동과 신뢰할 만한 탐색기에서 같은 첫 단서를 얻을 수 있습니다.

아직 소비되지 않은 가장 낮은 논스부터 살펴보세요. 원래 거래가 여전히 보이고 지갑에서 교체를 지원한다면, 새로 서명하기 전에 교체 거래의 필드와 수수료 설정을 확인하세요. 원래 거래가 보이지 않으면 거래가 네트워크에서 사라졌다고 가정하지 말고, 지갑이나 RPC 제공자에게 재전파와 교체를 어떻게 처리하는지 알아보세요. 논스가 이미 소비되었다면 먼저 그 거래를 확인한 뒤 다음 행동을 정하세요. 높은 논스로 새 거래를 계속 보내면 최초의 공백을 해결하지 않은 채 대기열만 늘어날 수 있습니다.

이 글은 일반적인 이더리움 외부 소유 계정 거래를 다룹니다. 계정 추상화 시스템은 번들러를 통해 UserOperation을 제출할 수 있고, 스마트 계정은 하나의 단순 카운터를 넘어서는 논스 키와 순번을 쓸 수 있습니다. EIP-4337은 해당 작업에 쓰이는 논스 구조를 정의하므로, 계정 추상화를 사용하는 지갑은 이 글의 EOA 예시와 다르게 동작할 수 있습니다. 목적지 네트워크, 주소, 전송 상태는 암호화폐 전송 체크리스트에서 이어서 확인하세요.