Mempool(멤풀)이란?
Mempool(멤풀)은 일반적으로 블록체인 네트워크에서 아직 블록에 포함되지 않은 유효한 거래들이 노드에서 대기하는 영역 또는 거래 집합을 설명할 때 사용하는 개념입니다.
이용자가 가상자산을 전송하고 거래가 네트워크에 전달됐다고 해서 반드시 즉시 블록에 포함되는 것은 아닙니다.
네트워크의 노드는 전달받은 거래가 기본적인 규칙을 충족하는지 확인한 뒤 아직 블록에 포함되지 않은 거래를 자신의 Mempool에 보관할 수 있습니다.
초보자는 Mempool을 “블록에 들어가기 전에 거래가 잠시 기다릴 수 있는 대기 공간”이라고 이해하면 쉽습니다. 다만 모든 블록체인이 동일한 Mempool 구조를 사용하는 것은 아닙니다.
가족 웹툰으로 먼저 알아보기
아빠는 코인을 보냈는데 Block Explorer에서 계속 Pending으로 표시되자 거래가 멈춘 것인지 걱정합니다. 큰딸의 설명을 들으며 아직 블록에 포함되지 않은 거래가 Mempool에서 대기할 수 있다는 점을 알아보고, 엄마와 나나는 네트워크 혼잡과 수수료, 거래 상태를 확인해야 하는 이유를 함께 살펴봅니다.
웹툰 핵심 설명
53-1. Mempool이 뭐야?
아직 블록에 포함되지 않은 거래들이 노드에서 대기할 수 있는 영역 또는 거래 집합을 설명하는 개념입니다.
53-2. 코인을 보내면 바로 블록에 들어가는 게 아니야?
거래가 네트워크에 전달된 뒤 검증과 선택 과정을 거쳐 블록에 포함될 수 있으므로 일정 시간 대기할 수 있습니다.
53-3. Pending 거래가 Mempool에서 기다릴 수 있어.
거래가 아직 블록에 포함되지 않았다면 네트워크 구조에 따라 노드의 Mempool에서 대기하고 있을 수 있습니다.
53-4. 네트워크가 붐비면 대기 거래가 많아질 수 있어.
처리하려는 거래가 많으면 제한된 블록 공간을 두고 여러 거래가 경쟁하면서 대기 시간이 길어질 수 있습니다.
53-5. 수수료 조건도 거래 선택에 영향을 줄 수 있어.
일부 네트워크에서는 검증자나 블록 생성자가 어떤 거래를 먼저 포함할지 결정할 때 수수료 조건 등이 영향을 줄 수 있습니다.
53-6. Pending이라고 같은 거래를 바로 다시 보내면 안 돼.
기존 거래가 여전히 처리될 가능성이 있으므로 먼저 Transaction Hash와 현재 거래 상태를 확인해야 합니다.
52화 Confirmation과 Mempool은 어떻게 연결될까?
앞서 배운 Confirmation은 거래가 블록에 포함된 뒤 확인 상태가 이어지는 과정을 이해할 때 사용하는 개념입니다.
Mempool은 그보다 앞선 단계와 관련됩니다.
초보자는 거래 생성 → 네트워크 전달 → Mempool 대기 → 블록 포함 → Confirmation이라는 기본 흐름으로 연결하면 이해하기 쉽습니다.
다만 실제 거래 처리 과정과 용어는 블록체인마다 다를 수 있습니다.
51화 Transaction Hash는 Mempool에서도 있을까?
거래가 생성되어 네트워크에 전달된 뒤 아직 블록에 포함되지 않은 상태에서도 Transaction Hash / TXID를 이용해 거래를 식별할 수 있는 경우가 있습니다.
따라서 TXID가 존재한다고 해당 거래가 이미 블록에 포함됐다고 생각해서는 안 됩니다.
Block Explorer에서 Transaction Hash를 검색해 현재 거래가 Pending인지 실제 블록에 포함됐는지 확인하는 것이 중요합니다.
Mempool은 블록체인에 기록된 공간일까?
Mempool 자체를 이미 확정된 블록체인의 한 부분이라고 생각해서는 안 됩니다.
Mempool에 있는 거래는 아직 블록에 포함되지 않은 대기 거래일 수 있습니다.
거래가 블록 생성 과정에서 선택되고 블록에 포함된 뒤에야 해당 블록의 거래 기록으로 체인에 들어가게 됩니다.
Mempool은 하나의 중앙 서버에 있을까?
일반적으로 탈중앙화 블록체인의 Mempool을 하나의 중앙 서버에 존재하는 공용 대기실처럼 이해해서는 안 됩니다.
각 노드는 자신이 받은 거래와 운영 규칙 등에 따라 자체적인 대기 거래 집합을 관리할 수 있습니다.
따라서 모든 노드가 언제나 완전히 동일한 Mempool 내용을 가지고 있다고 단정할 수는 없습니다.
노드마다 Mempool이 다를 수 있을까?
그럴 수 있습니다.
거래가 네트워크를 통해 전달되는 시간이나 각 노드의 정책, 메모리 제한과 거래 처리 규칙 등이 다를 수 있기 때문입니다.
어떤 거래가 한 노드에는 전달됐지만 다른 노드에는 아직 전달되지 않았거나 특정 조건에 따라 보관 여부가 달라질 수도 있습니다.
거래는 어떻게 Mempool에 들어갈까?
이용자가 지갑에서 거래를 만들고 트랜잭션 서명을 완료하면 해당 거래가 블록체인 네트워크로 전달될 수 있습니다.
노드는 거래가 네트워크의 기본 규칙을 충족하는지 확인하고 유효한 대기 거래로 받아들일 수 있습니다.
이후 거래는 블록에 포함되기 전까지 Mempool에서 기다릴 수 있습니다.
Mempool에 들어가면 거래가 성공한 걸까?
아닙니다.
Mempool에서 거래가 대기하고 있다는 것은 아직 블록에 포함되어 최종적인 실행 결과가 확정된 상태와는 다릅니다.
거래가 블록에 포함된 뒤에도 스마트 컨트랙트 실행 결과 등에 따라 성공 또는 실패 상태가 결정될 수 있습니다.
왜 거래가 바로 블록에 들어가지 않을까?
블록에는 일정한 처리 용량이나 자원 제한이 있을 수 있습니다.
한꺼번에 많은 거래가 네트워크에 제출되면 모든 거래를 동시에 하나의 블록에 포함할 수 없기 때문에 일부 거래가 다음 블록을 기다릴 수 있습니다.
이 과정에서 네트워크 혼잡과 거래 수수료 조건 등이 대기 시간에 영향을 줄 수 있습니다.
Mempool이 붐빈다는 것은 무슨 뜻일까?
네트워크가 처리할 수 있는 속도보다 많은 거래가 제출되면 블록에 포함되기를 기다리는 거래가 늘어날 수 있습니다.
이러한 상황을 일반적으로 Mempool이 혼잡하다고 표현할 수 있습니다.
혼잡이 심하면 일부 거래가 평소보다 오랫동안 Pending 상태로 남을 수 있습니다.
Mempool이 붐비면 가스비도 올라갈까?
네트워크에 따라 거래들이 제한된 블록 공간을 두고 경쟁하면서 더 높은 수수료를 제시하는 상황이 발생할 수 있습니다.
이 때문에 혼잡한 시기에는 가스비 또는 네트워크 수수료가 높아지는 현상이 나타날 수 있습니다.
하지만 수수료 결정 방식은 블록체인마다 다르므로 Mempool 거래 수만으로 모든 네트워크의 비용을 동일하게 설명해서는 안 됩니다.
수수료가 높으면 무조건 먼저 처리될까?
그렇게 단정할 수 없습니다.
일부 네트워크에서는 거래 수수료가 블록에 포함되는 우선순위에 영향을 줄 수 있지만 블록 생성 상황과 거래 구조, 네트워크 규칙 등 다른 요소도 영향을 줄 수 있습니다.
따라서 높은 수수료가 특정 시간 안의 거래 처리를 절대적으로 보장한다고 생각해서는 안 됩니다.
수수료가 너무 낮으면 거래가 오래 기다릴 수도 있을까?
네트워크 구조와 상황에 따라 그럴 수 있습니다.
혼잡한 상황에서 다른 거래보다 상대적으로 낮은 수수료 조건을 가진 거래는 블록에 포함되기까지 더 오래 기다릴 수 있습니다.
하지만 정확한 처리 우선순위와 대기 시간은 해당 블록체인의 실제 수수료 구조를 확인해야 합니다.
Mempool에서 거래가 사라질 수도 있을까?
거래가 블록에 포함되면 더 이상 대기 거래로 남아 있을 필요가 없습니다.
반면 오랫동안 블록에 포함되지 않은 거래가 노드의 정책이나 메모리 관리 등의 이유로 Mempool에서 제거될 가능성도 있습니다.
이 경우 모든 네트워크와 지갑에서 동일한 방식으로 처리된다고 단정해서는 안 되며 실제 거래 상태를 확인해야 합니다.
Mempool에서 사라지면 자산이 전송된 걸까?
반드시 그렇지는 않습니다.
Mempool에서 거래가 보이지 않는 이유는 블록에 포함됐기 때문일 수도 있고 노드가 대기 거래를 더 이상 보관하지 않기 때문일 수도 있습니다.
따라서 단순히 Mempool 표시만 보지 말고 Transaction Hash를 이용해 실제 블록 포함 여부와 거래 상태를 확인해야 합니다.
Mempool과 Nonce는 어떤 관계일까?
일부 블록체인에서는 계정에서 생성되는 거래의 순서와 중복 실행을 관리하기 위해 Nonce라는 값을 사용합니다.
앞선 거래가 Pending 상태로 남아 있으면 이후 거래의 처리에 영향을 줄 수 있는 구조도 있습니다.
Nonce는 다음 54화에서 별도의 핵심 주제로 자세히 알아봅니다.
Mempool과 Block Height는 어떤 관계일까?
Mempool의 거래는 아직 특정 블록에 포함되지 않은 대기 거래일 수 있습니다.
거래가 블록에 포함되면 어느 블록에 기록됐는지를 Block Height 등의 정보와 함께 확인할 수 있습니다.
Block Height는 55화에서 자세히 알아봅니다.
Mempool의 주요 주의점
- Pending 오해: 거래가 대기 중이라는 이유만으로 실패했다고 판단할 수 있습니다.
- 반복 전송: 기존 거래가 처리될 수 있는데 같은 전송을 다시 실행할 수 있습니다.
- 수수료 오해: 높은 수수료가 무조건 즉시 처리를 보장한다고 생각할 수 있습니다.
- 중앙 대기실 오해: 모든 노드가 완전히 같은 하나의 Mempool을 공유한다고 생각할 수 있습니다.
- 블록 포함 오해: Mempool에 있다는 사실을 이미 블록에 기록된 것으로 착각할 수 있습니다.
- 거래 소멸 오해: 탐색기에서 표시가 달라졌다는 이유만으로 거래나 자산이 사라졌다고 판단할 수 있습니다.
Mempool을 확인할 때 체크할 것
- 네트워크: 거래가 어느 블록체인에서 실행됐는지 확인합니다.
- Transaction Hash: 정확한 TXID를 확인합니다.
- 거래 상태: 현재 Pending인지 블록에 포함됐는지 확인합니다.
- 수수료: 해당 거래에 설정된 네트워크 비용 조건을 확인합니다.
- 네트워크 혼잡: 현재 대기 거래가 많은 상황인지 확인합니다.
- 블록 포함: 거래가 실제 어느 블록에 포함됐는지 확인합니다.
- Confirmation: 블록에 포함됐다면 Confirmation 상태를 확인합니다.
Pending 거래가 오래 걸릴 때 무엇부터 확인할까?
Mempool에서 거래가 예상보다 오래 대기한다면 같은 거래를 다시 보내기보다 Transaction Hash → 현재 거래 상태 → 수수료 조건 → 네트워크 혼잡 → 앞선 Pending 거래 여부 순서로 확인하는 것이 좋습니다.
거래가 단순히 블록에 포함되기를 기다리는 것인지, 다른 거래와 순서가 연결되어 있는지에 따라 원인이 달라질 수 있습니다.
먼저 Block Explorer에서 기존 거래가 실제로 어떤 상태인지 확인하는 것이 중요합니다.
Pending이 오래 지속되면 거래가 실패한 걸까?
반드시 그렇지는 않습니다.
Pending은 거래가 아직 블록에 포함되지 않았거나 네트워크에서 처리를 기다리는 상태를 나타낼 수 있습니다.
네트워크 혼잡과 수수료 조건 등에 따라 대기 시간이 길어질 수 있으므로 Pending이라는 표시만으로 거래 실패를 판단해서는 안 됩니다.
거래가 Mempool에 있으면 자산은 이미 빠져나간 걸까?
지갑 화면에서는 Pending 거래를 반영해 사용 가능한 잔액이 줄어든 것처럼 표시할 수 있습니다.
하지만 아직 블록에 포함되지 않은 거래와 최종적으로 처리된 거래는 구분해야 합니다.
실제 온체인 상태는 Transaction Hash / TXID를 이용해 확인하는 것이 좋습니다.
Pending 거래를 기다리는 동안 같은 자산을 다시 보낼 수 있을까?
지갑과 블록체인의 계정 구조에 따라 후속 거래를 만들 수 있는 경우가 있습니다.
하지만 앞선 거래가 아직 처리되지 않은 상태라면 이후 거래의 처리 순서에도 영향을 줄 수 있습니다.
특히 계정 기반 블록체인에서는 거래 순서를 관리하는 값이 사용될 수 있으며 다음 54화에서 배우는 Nonce가 이 과정과 연결됩니다.
앞의 거래가 Pending이면 뒤의 거래도 기다릴 수 있을까?
일부 블록체인에서는 그럴 수 있습니다.
계정에서 생성한 거래가 순서대로 처리되어야 하는 구조에서는 앞선 순서의 거래가 Pending 상태로 남아 있으면 이후 거래도 바로 처리되지 못할 수 있습니다.
따라서 여러 거래가 동시에 멈춘 것처럼 보인다면 각각의 거래만 따로 보기보다 거래 순서와 Nonce도 함께 확인해야 할 수 있습니다.
Nonce는 왜 Mempool에서 중요할까?
일부 계정 기반 블록체인에서는 Nonce를 이용해 해당 계정에서 발생하는 거래의 순서를 관리하고 동일한 거래가 반복 실행되는 것을 방지할 수 있습니다.
예를 들어 더 낮은 Nonce를 가진 거래가 아직 처리되지 않았다면 그다음 순서의 거래가 기다리는 상황이 발생할 수 있습니다.
Nonce는 다음 54화에서 거래 순서와 중복 방지 원리를 중심으로 자세히 알아봅니다.
같은 Nonce의 거래가 여러 개 존재할 수도 있을까?
네트워크와 지갑의 기능에 따라 기존 Pending 거래를 조정하는 과정에서 같은 Nonce와 다른 수수료 조건을 가진 거래가 네트워크에 전달되는 상황이 있을 수 있습니다.
이 경우 모든 거래가 각각 독립적으로 최종 실행되는 것으로 생각해서는 안 됩니다.
구체적인 처리 방식은 블록체인과 지갑에 따라 다르므로 임의로 거래 값을 수정하기보다 사용하는 지갑의 공식 안내를 확인하는 것이 중요합니다.
Pending 거래의 수수료를 높일 수 있을까?
일부 네트워크와 지갑에서는 아직 처리되지 않은 거래를 더 높은 수수료 조건의 거래로 대체하는 기능을 제공할 수 있습니다.
지갑 화면에서는 Speed Up 같은 기능으로 표시될 수도 있습니다.
하지만 모든 블록체인과 지갑에서 동일한 기능을 제공하는 것은 아니며 실제로 새로운 거래가 어떤 방식으로 만들어지는지 확인해야 합니다.
Speed Up을 누르면 기존 거래와 새 거래가 둘 다 실행될까?
구현 방식에 따라 기존 Pending 거래를 대체하기 위한 새로운 거래가 생성될 수 있습니다.
이때 거래 순서와 Nonce 등의 규칙에 따라 어떤 거래가 최종적으로 처리되는지가 결정될 수 있습니다.
따라서 Speed Up을 단순히 기존 거래의 버튼 하나를 빠르게 만드는 기능으로만 생각하지 말고 실제 지갑의 처리 방식을 확인하는 것이 좋습니다.
Pending 거래를 취소할 수도 있을까?
일부 블록체인과 지갑에서는 아직 처리되지 않은 거래를 사실상 대체하는 방식으로 취소 기능을 제공할 수 있습니다.
예를 들어 동일한 거래 순서 정보를 사용하는 다른 거래를 제출하는 방식이 활용될 수 있습니다.
하지만 Cancel 버튼을 누른다고 이미 블록에 포함된 거래가 되돌아가는 것은 아닙니다. 지원 여부와 실제 동작 방식은 지갑과 네트워크마다 다릅니다.
Cancel 거래에도 수수료가 필요할 수 있을까?
취소가 새로운 온체인 거래를 제출하는 방식으로 이루어진다면 네트워크 비용이 필요할 수 있습니다.
따라서 거래를 취소한다는 이유로 기존 가스비가 자동으로 모두 반환되거나 아무 비용도 발생하지 않는다고 생각해서는 안 됩니다.
실행 전 지갑에 표시되는 예상 비용과 거래 내용을 확인해야 합니다.
거래를 취소하려는 순간 기존 거래가 먼저 처리되면?
Pending 거래는 언제 블록에 포함될지 정확하게 보장하기 어려운 경우가 있습니다.
이 때문에 대체 또는 취소 거래를 준비하는 동안 기존 거래가 먼저 처리될 가능성도 고려해야 합니다.
거래 상태가 빠르게 변할 수 있으므로 실제 실행 직전에 Block Explorer와 지갑에서 최신 상태를 다시 확인하는 것이 중요합니다.
Mempool에서 거래가 제거되면 자동으로 실패 표시가 날까?
반드시 동일한 방식으로 표시되는 것은 아닙니다.
노드가 오랫동안 처리되지 않은 거래를 더 이상 보관하지 않더라도 지갑이나 Block Explorer가 이를 표시하는 방식은 다를 수 있습니다.
따라서 한 화면에서 거래가 사라졌다는 사실만으로 최종 상태를 단정하지 말고 다른 온체인 정보와 지갑 상태를 함께 확인해야 합니다.
거래가 Mempool에서 제거되면 Confirmation도 생길까?
블록에 포함되지 않은 채 단순히 대기 거래 집합에서 제거됐다면 블록에 포함된 거래처럼 Confirmation이 누적되는 것으로 생각해서는 안 됩니다.
Confirmation은 거래가 실제 블록에 포함된 이후의 확인 과정과 관련됩니다.
따라서 Mempool에서 사라짐 = 블록 포함이라고 판단해서는 안 됩니다.
거래가 다시 네트워크에 전달될 수도 있을까?
지갑이나 노드의 동작 방식에 따라 아직 유효한 거래가 다시 네트워크에 전달되는 상황이 있을 수 있습니다.
구체적인 재전파 방식과 거래 유지 정책은 네트워크와 소프트웨어마다 다를 수 있습니다.
따라서 오래된 Pending 거래를 직접 처리하려 한다면 사용하는 지갑과 블록체인의 공식 안내를 먼저 확인하는 것이 좋습니다.
Mempool 데이터는 실시간으로 완전히 정확할까?
Mempool은 각 노드가 관리할 수 있는 대기 거래 집합이므로 모든 서비스가 정확히 같은 순간에 같은 데이터를 보여준다고 단정할 수 없습니다.
Block Explorer나 분석 서비스가 보여주는 Mempool 정보도 해당 서비스가 관찰한 네트워크 상태를 기반으로 할 수 있습니다.
따라서 서비스마다 대기 거래 수나 예상 처리 정보가 조금 다르게 표시될 수 있습니다.
Mempool 크기가 크면 무조건 네트워크가 고장 난 걸까?
아닙니다.
처리 대기 거래가 많다는 것은 현재 네트워크의 블록 처리 용량보다 많은 거래가 제출되고 있는 상황과 관련될 수 있습니다.
하지만 이것만으로 네트워크 자체가 고장 났다고 판단할 수는 없습니다.
블록이 정상적으로 생성되고 있는지와 거래 처리 상황 등을 함께 확인해야 합니다.
Mempool이 비어 있으면 모든 거래가 끝난 걸까?
그렇게 단정할 수도 없습니다.
노드마다 Mempool 내용이 다를 수 있고 서비스가 표시하는 데이터 범위에도 차이가 있을 수 있습니다.
특정 거래를 확인하려는 목적이라면 전체 Mempool 숫자보다 해당 Transaction Hash의 실제 상태를 확인하는 것이 더 중요합니다.
Mempool과 블록 생성자는 어떤 관계일까?
블록 생성자는 네트워크 규칙에 따라 블록에 포함할 거래를 선택할 수 있습니다.
Proof of Work 계열에서는 채굴자가, Proof of Stake 계열에서는 네트워크 구조에 따라 검증자나 블록 제안자가 이러한 역할에 참여할 수 있습니다.
이후 57화 Proof of Work, 58화 Proof of Stake, 59화 Validator에서 이 구조를 차례대로 자세히 알아봅니다.
Mempool을 확인한 뒤 체크할 것
- TXID: 확인하려는 거래의 정확한 Transaction Hash가 맞는지 확인합니다.
- Pending 상태: 거래가 아직 블록에 포함되지 않았는지 확인합니다.
- 수수료 조건: 현재 네트워크 상황과 거래의 수수료 조건을 확인합니다.
- 앞선 거래: 같은 계정에서 더 앞선 Pending 거래가 있는지 확인합니다.
- Nonce: 지원되는 네트워크에서는 거래 순서와 관련된 Nonce를 확인합니다.
- 대체 거래: Speed Up이나 Cancel을 사용했다면 어떤 거래가 최종 처리됐는지 확인합니다.
- 블록 포함: 거래가 블록에 들어갔다면 해당 블록 정보를 확인합니다.
- Confirmation: 블록 포함 이후에는 확인 상태를 살펴봅니다.
Mempool에서 가장 중요한 습관
Mempool에서 가장 중요한 것은 “Pending이 오래되면 거래가 실패했으니 다시 보내면 된다”고 생각하지 않는 것입니다.
기존 거래가 여전히 유효한 상태로 처리될 수 있고, 계정의 거래 순서나 Nonce 때문에 이후 거래까지 영향을 받을 수 있습니다.
따라서 TXID 확인 → Pending 상태 확인 → 수수료·네트워크 혼잡 확인 → 앞선 거래와 Nonce 확인 → 블록 포함 확인 → Confirmation 확인 순서로 살펴보는 습관이 중요합니다.
FAQ
Q. Mempool은 무엇인가요?
Mempool은 일반적으로 아직 블록에 포함되지 않은 유효한 거래들이 노드에서 대기하는 영역 또는 거래 집합을 설명할 때 사용하는 개념입니다. 초보자는 거래가 블록에 들어가기 전에 잠시 기다릴 수 있는 대기 공간으로 이해하면 쉽습니다.
Q. 거래가 Mempool에 있으면 이미 전송이 완료된 건가요?
아닙니다. Mempool에서 대기하고 있다는 것은 아직 블록에 포함되지 않은 상태일 수 있습니다. 실제 거래 상태는 Transaction Hash / TXID를 이용해 확인하는 것이 좋습니다.
Q. Mempool과 Pending은 같은 뜻인가요?
완전히 같은 용어는 아니지만 서로 밀접하게 연결됩니다. Pending은 거래가 아직 처리 중임을 나타내는 상태로 사용될 수 있고, 해당 거래가 네트워크 구조에 따라 Mempool에서 블록 포함을 기다리고 있을 수 있습니다.
Q. 모든 노드가 하나의 Mempool을 공유하나요?
그렇게 생각해서는 안 됩니다. 각 노드는 자신이 전달받은 거래와 운영 정책 등에 따라 자체적인 대기 거래 집합을 관리할 수 있으므로 모든 노드의 Mempool이 항상 완전히 같다고 단정할 수 없습니다.
Q. Mempool이 혼잡하면 거래가 늦어질 수 있나요?
그럴 수 있습니다. 처리하려는 거래가 많아 제한된 블록 공간을 두고 경쟁하면 일부 거래가 블록에 포함되기까지 더 오래 기다릴 수 있습니다.
Q. 수수료를 많이 내면 무조건 바로 처리되나요?
아닙니다. 일부 네트워크에서는 수수료 조건이 거래 선택 우선순위에 영향을 줄 수 있지만 높은 수수료가 특정 시간 안의 처리를 절대적으로 보장하는 것은 아닙니다.
Q. Pending 거래가 오래되면 같은 거래를 다시 보내도 되나요?
바로 반복 전송하는 것은 주의해야 합니다. 기존 거래가 여전히 처리될 수 있으며 별도의 거래를 다시 만들면 의도하지 않은 추가 전송이나 네트워크 비용이 발생할 수 있습니다. 먼저 Block Explorer에서 기존 거래 상태를 확인하는 것이 중요합니다.
Q. Mempool에서 거래가 사라지면 Confirmation이 생긴 건가요?
반드시 그렇지는 않습니다. 거래가 블록에 포함돼 대기 상태에서 빠졌을 수도 있지만 노드 정책 등에 따라 대기 거래가 제거된 경우도 있을 수 있습니다. 실제 블록 포함 여부와 Confirmation 상태를 확인해야 합니다.
Mempool을 쉽게 기억하는 방법
“블록에 아직 들어가지 않은 거래가 노드에서 기다릴 수 있는 대기 거래 영역”이라고 기억하면 됩니다.
지금까지 배운 거래 흐름을 연결하면 다음처럼 이해할 수 있습니다.
거래 생성 → 트랜잭션 서명 → 네트워크 전달 → Mempool 대기 → 블록 포함 → Confirmation
다만 Mempool은 하나의 중앙 대기실이 아니며 노드마다 보유한 대기 거래가 다를 수 있습니다.
또한 Pending 상태가 오래된다고 거래 실패를 의미하는 것은 아니므로 같은 거래를 바로 반복하지 않는 것이 중요합니다.
핵심 정리
Mempool(멤풀)은 일반적으로 아직 블록에 포함되지 않은 유효한 거래들이 노드에서 대기하는 영역 또는 거래 집합을 설명할 때 사용하는 개념입니다.
이용자가 거래를 생성하고 네트워크에 전달하면 노드가 해당 거래를 확인한 뒤 블록에 포함되기 전까지 Mempool에 보관할 수 있습니다.
네트워크에 처리 대기 거래가 많으면 Mempool이 혼잡해질 수 있으며 네트워크 구조에 따라 수수료 조건 등이 거래의 블록 포함 순서에 영향을 줄 수 있습니다.
하지만 Mempool에 있다는 사실은 거래가 이미 성공했다는 뜻이 아니며, Mempool에서 사라졌다는 사실만으로 거래가 블록에 포함됐다고 단정해서도 안 됩니다.
따라서 Transaction Hash → Pending 상태 → 수수료 조건 → 네트워크 혼잡 → 거래 순서 → 블록 포함 → Confirmation 순서로 확인하는 것이 중요합니다.
다음 54화에서는 Pending 거래의 순서와 중복 방지를 이해할 때 중요한 Nonce(논스)를 자세히 알아봅니다.
참고 자료
Mempool의 구조와 거래 전파, 대기 거래 관리, 수수료 우선순위 및 거래 대체 방식은 블록체인 네트워크와 노드 소프트웨어에 따라 다를 수 있습니다. 실제 Pending 거래를 확인하거나 조정할 때는 해당 블록체인과 사용하는 지갑의 최신 공식 안내를 우선 확인하는 것이 좋습니다.
Disclaimer
본 콘텐츠는 Mempool, Pending 거래, Transaction Hash 및 블록체인 거래 처리 과정에 대한 일반적인 정보 제공과 이용자 보호를 목적으로 하며 특정 가상자산, 지갑, 네트워크, 거래소 또는 투자 참여를 권유하지 않습니다. 블록체인 거래에는 네트워크 혼잡, 거래 지연 또는 실패, 수수료 변동, 잘못된 거래 재전송, 주소·네트워크 오류 및 원금 손실을 포함한 다양한 위험이 존재할 수 있습니다. Pending 거래의 Speed Up, Cancel 또는 대체 거래 기능은 네트워크와 지갑마다 작동 방식이 다를 수 있으므로 실제 이용 전 해당 서비스의 최신 공식 안내와 거래 상태를 직접 확인하시기 바랍니다.