솔로 최고 셰어가 블록이 아닌 이유: eCash RTT

eCash의 Real-Time Targeting, 이른바 Heartbeat는 각 블록 이후 약 2분 동안 요구되는 채굴 타깃을 올렸다가 공개 난이도까지 감쇠시키는 합의 규칙이다. 익스플로러에 표시된 난이도를 넘은 셰어는 그 감쇠 이후에 도착해야만 유효한 블록이 된다. XEC의 솔로 채굴자가 기록적인 셰어를 보고도 아무것도 얻지 못하는 가장 흔한 이유가 바로 이것이다.

핵심 요점

• eCash는 안정적인 주기에서 각 블록 이후 약 115초 동안 공개된 것보다 높은 난이도를 요구한다.
• 요구치는 천문학적으로 높게 시작해 경과 시간의 5제곱으로 떨어진다. 표준 난이도보다 더 쉬워지는 일은 결코 없다.
• 익스플로러는 각 블록의 난이도를 채굴된 그대로, 즉 하한값으로 보여준다. 실시간 요구치를 알려주는 공개 피드는 존재하지 않는다.
• 운영 중인 노드의 자체 로그에 대해 공식 수식을 15회 측정에 걸쳐 재현했다: 최대 편차 0.002%.
• 오늘날 솔로 채굴자가 맞닥뜨리는 가파른 초기 램프는 전적으로 2025년 11월 15일 업그레이드 때문에 생겼다. 그 업그레이드가 1블록 필터 창을 추가했다.

왜 내 셰어가 네트워크 난이도를 넘었는데 블록을 찾지 못했나?

한 채굴자가 정확하고 지극히 타당한 불만을 보내왔다. 그는 공개 네트워크 난이도 약 73.6억에 맞서 약 80억 난이도의 셰어로 eCash 블록을 풀었다. 몇 시간 뒤 그의 채굴기가 훨씬 나은 셰어 — 약 118.7억 — 를 기록했지만 아무 일도 일어나지 않았다. 그는 그 이후 체인의 모든 블록을 확인했다. 공개 난이도는 밤새 71억에서 74억 사이에 머물렀다. Bitcoin의 규칙이라면 그 셰어는 블록이었다.

그는 숫자에 대해서는 옳았고 규칙에 대해서는 틀렸다. eCash에서 익스플로러가 공개하는 난이도는 당신이 제출하는 순간에 넘어야 할 난이도가 아니다. 그것은 바닥이다.

그의 118.7억 셰어는 직전 블록으로부터 약 100초 뒤에 도착했다 — 아직 램프 안이었다. 그 순간 네트워크는 148.5억을 요구했고, 셰어는 필요한 양의 약 80% 가치였다. 15초 뒤 램프가 끝나고 요구치는 73.3억으로 떨어졌으며, 똑같은 그 셰어라면 이겼을 것이다. 그에게 부족했던 것은 해시레이트가 아니었다. 15초였다.

eCash의 Real-Time Targeting이란 무엇인가?

Real-Time Targeting은 2024년 11월 15일 Heartbeat 업그레이드와 함께 활성화되었다. 이것이 해결하는 문제는 소수파 SHA-256 체인 특유의 것이다.

eCash는 Bitcoin 및 Bitcoin Cash와 알고리즘을 공유하므로 해시레이트가 수익성을 좇아 그 사이를 오간다. eCash 난이도가 떨어지면 외부 해시레이트가 밀려들어 여러 블록을 연달아 채굴한다 — 터보 블록이다. 표준 난이도 알고리즘은 난이도를 올려 반응하고, 방문했던 해시레이트는 떠나며, 체인은 높은 난이도와 얼마 안 되는 해시레이트만 남아 몇 시간씩 이어질 수 있는 블록 공백을 만든다. 입금이 막힌다. 컨펌은 예측 불가능해진다.

Heartbeat는 그 순환의 전반부를 공략한다. 직전 블록 이후 너무 빨리 채굴된 블록을 무효로 만들어 버스트 채굴의 보상을 없애고, 그 결과 기반 알고리즘이 애초에 과보정하지 않게 한다. 이 설계는 Tom Harding의 Real-Time Block Rate Targeting 연구에서 영감을 받았다.

이 메커니즘은 Avalanche 덕분에만 작동한다. 실시간 타깃팅은 블록이 언제 도착했는지에 대한 각 노드 자신의 측정에 의존하는데, 이는 본질적으로 주관적이다. Avalanche의 사후 합의가 그 주관적인 시각들을 단일한 네트워크 결정으로 조율하며, 블록 헤더나 나카모토 합의에는 손대지 않는다.

eCash의 실시간 타깃은 어떻게 계산되나?

이 규칙은 유효성 규칙이 아니라 파킹 정책으로 Bitcoin ABC에 구현되어 있다. 해당 소스는 src/policy/block/rtt.cpp에 있고, 핵심 수식은 파일 자체의 주석에 적혀 있다:

target(t) = target(prev_block) * RTT_CONSTANT_FACTOR * t^(RTT_K - 1)

RTT_CONSTANT_FACTOR = RTT_K * gamma(1 + 1/RTT_K)^RTT_K / T^(RTT_K - 1)

RTT_K는 6이므로 타깃은 경과 시간의 5제곱으로 스케일한다. T는 해당 필터 창의 목표 간격이다. 경과 시간은 헤더에 기록된 타임스탬프가 아니라, 노드가 직전 각 블록 헤더를 수신한 시점부터 측정된다.

수식은 다섯 개 창에 대해 동시에 평가되며, 가장 엄격한 결과가 이긴다:

창 길이는 소수이며, 연속된 항목 사이에서 하나씩 건너뛴다. 소스 코드가 그 이유를 설명한다: 여러 필터를 연결할 때 생기는 공명 주파수를 피하려는 최선의 시도다. 17블록에서 멈추는 것은 그 이상의 창이 필터의 선택도를 의미 있게 바꾸지 않기 때문이다.

채굴자에게 중요한 성질은 두 가지다. 모든 창 중 가장 낮은 타깃이 적용되므로 가장 까다로운 제약이 지배한다. 그리고 결과에는 상한이 있다: 실시간 타깃이 표준 타깃보다 높아지는 — 즉 쉬워지는 — 일은 결코 없다. 난이도는 위로만 밀어올려질 뿐, 결코 내려가지 않는다.

gamma(1 + 1/6) = 0.9277193336으로부터 상수를 재구성하면 공개된 다섯 계수 전부가 유효숫자 열 자리까지 재현된다.

직전 블록 직후 eCash 블록은 얼마나 더 어려운가?

이것은 다른 어디에도 없는 표로, 안정적인 10분 주기에서 공식 수식으로 계산했다. 배수는 익스플로러가 공개할 난이도에 적용된다.

직전 블록 1초 뒤에 발견된 블록이라면 공개 난이도의 약 200억 배가 필요하다. 10초 시점에는 20만 배다. 곡선은 잔인할 만큼 가파르다가 그냥 멈춘다: 약 115초 뒤 요구치는 공개 난이도와 정확히 같아지고 거기 머문다.

최근 블록들이 10분보다 빨리 도착했다면 모든 창이 더 짧은 경과 시간에서 시작하고, 램프는 더 높게 시작하면서 더 오래 지속된다. 이는 부작용이 아니다. 터보 블록 억제 메커니즘이 제 일을 하는 것이다.

이 수식이 실제 노드의 동작과 일치하나?

우리가 검증했다. 아래는 어느 블록 이후 2분 30초 동안 우리 eCash 노드 중 하나가 기록한 값과, 같은 로그에 보이는 블록 도착 시각만으로 공개 수식이 예측하는 값을 나란히 놓은 것이다.

기록된 열다섯 번의 측정 전체에서 최대 편차는 **0.002%**였다. 공개된 수식은 노드가 하는 일의 근사가 아니다 — 그것이 바로 노드가 하는 일이다.

짚어둘 만한 세부가 하나 있다. 처음 99초 동안 구속 조건은 1블록 창이었다. 109초가 되어서야 2블록 창이 넘겨받았고, 그로부터 40초 뒤 표준 난이도가 바닥을 정했다.

2025년 11월 15일에 무엇이 바뀌었나?

그 업그레이드 이전에는 2블록에서 시작하는 네 개의 창이 있었다. 2025년 11월 15일 업그레이드가 150초 간격을 가진 1블록 창을 추가했다.

두 구성을 안정적인 10분 주기로 수식에 통과시키면 인상적인 결과가 나온다:

정상 주기에서 네 창 구성은 램프를 전혀 만들지 않았다. 블록이 이미 너무 빨리 도착하고 있을 때만 작동했는데, 그것이 원래의 좁은 목적이었다. 그 외에는 건강한 체인에서 오늘날 솔로 채굴자가 부딪히는 가파른 초기 램프는 전적으로 2025년 11월에 추가된 1블록 창 때문이다.

그 날짜 이전에 eCash를 솔로 채굴했고 이런 일을 겪은 적이 없다면, 이유가 바로 이것이다.

왜 내 풀이 보여주는 난이도가 익스플로러와 맞지 않나?

eCash에서는 서로 다른 숫자이고, 채굴 소프트웨어가 그렇게 말하고 있기 때문이다.

Bitcoin ABC의 eCash 솔로 채굴 소프트웨어는 매 getblocktemplate 호출에서 rtt.nexttarget을 읽어 난이도로 변환하고, eCash에 한해 그 값을 자신이 보고하고 기록하는 네트워크 난이도로 사용한다. 다른 모든 SHA-256 체인은 대신 블록 헤더의 난이도 비트를 쓴다.

이 하나의 분기가 모든 eCash 풀 운영자가 보는 동작을 설명한다: 블록이 도착한 뒤 보고되는 네트워크 난이도는 천문학적으로 높다가, 약 2분 동안 10초마다 한 자릿수씩 떨어지고, 그다음 익스플로러가 결국 공개할 값에서 평평해진다.

노드 운영자에게는 두 번째 선택지가 있다: 블록 템플릿에 모두 들어 있는 rtt.prevheadertime, rtt.prevbits, rtt.nodetime으로부터 타깃을 로컬에서 계산하는 것이다. 두 경로 모두 eCash 채굴 페이지에 문서화되어 있다.

실시간 타깃을 위반한 블록은 어떻게 되나?

거부되는 것이 아니라 파킹된다. 노드는 policy-bad-rtt라는 정책 위반으로 표시해 옆으로 치워두고, 그다음 Avalanche 폴링이 네트워크의 나머지가 동의하는지 결정한다. 노드가 소수파라면 자신의 입장을 뒤집는다. 그동안 블록 헤더는 손대지 않은 채로 남고, 나카모토 합의는 변경되지 않는다.

eCash 노드에서 getchaintips를 실행하면 이런 블록들이 활성 체인과 나란히 status: parked로 표시된다. 우리 노드 중 하나에서 이 호출은 블록 높이 940,265에서 960,666에 걸친 262개의 파킹된 브랜치 팁을 반환했다 — 약 20,400블록이므로, 그 구간 블록의 약 1.3%가 적어도 한 번은 파킹되었다는 뜻이다.

이 수치는 실시간 타깃 위반의 상한이지 그 건수가 아니다. eCash는 여러 이유로 블록을 파킹하고, Avalanche는 일반적인 포크 경쟁의 패배 쪽도 파킹한다. 하지만 같은 높이의 경쟁 블록이 드문 체인에서 1퍼센트를 넘는 파킹 팁 비율은, 메커니즘이 놀고 있는 것이 아니라 활성화되어 일하고 있음을 알려준다.

이것이 Bitcoin, Bitcoin Cash, 또는 다른 SHA-256 체인에도 적용되나?

아니다. SHA-256 체인 가운데 이 동작은 eCash 고유인데, 주관적인 타이밍을 조율하기 위해 Avalanche 계층에 의존하기 때문이다.

Bitcoin과 Bitcoin Cash에서는 네트워크 난이도를 넘은 셰어가 블록이다, 그걸로 끝이다. 여러 체인을 채굴하면서 최고 셰어 수치를 서로 비교하고 있다면, 타이밍이 계산에 들어가는 것은 eCash 열뿐이다. 우리의 솔로 채굴 확률 분석과 네트워크 레이더는 둘 다 공개 난이도를 쓰는데, 장기 확률의 근거로는 그것이 옳다. 램프는 시간이 지나면 평균으로 씻겨나가기 때문이다.

솔로 채굴자에게 데드존은 얼마나 큰가?

램프가 끝나기 전에 떨어진 셰어는 아무리 좋아도 낭비된다. 안정적인 주기에서:

난이도를 간신히 넘기는 셰어에게는 각 블록 간격의 약 5분의 1이 쓸 수 없는 구간이다. 더 강한 셰어는 램프를 더 일찍 통과하며, 정말 거대한 셰어가 거의 낭비되지 않는 이유가 그것이다.

이것은 당신이 대응할 수 있는 어떤 방식으로도 기대 수익을 바꾸지 않는다. 이미 체인의 실제 블록 생산에 반영되어 있고, 따라서 난이도 자체에 반영되어 있다. 채굴기 설정에서 여기에 영향을 주는 것은 아무것도 없다.

솔로 채굴자는 실제로 무엇을 해야 하나?

대부분의 사람에게 솔직한 답은 아무것도 하지 않는 것이다 — 다만 자기 숫자는 제대로 읽어야 한다.

• 채굴기의 최고 난이도 표시는 해시를 찾은 그 순간, 풀이 응답하기 전에 로컬에서 계산된다. 그 셰어가 유효할 수 있었는지와 무관하게 값을 기록한다. 또한 이는 전체 기간 수치라서 블록을 찾아도 초기화되지 않는다.
• eCash에서 공개 난이도를 넘는 역대 최고 셰어는 놓친 블록이나 도난당한 블록의 증거가 아니다. 블록이 존재하는지 확인하고 싶다면 온체인의 coinbase 트랜잭션을 보라. 비수탁형 풀에서는 해싱이 시작되기 전에 당신의 주소가 coinbase에 기록되므로, 진짜 블록은 당신 이름으로 보이고 누구도 옮길 수 없다.
• 얼마나 가까웠는지 궁금하다면 최고 셰어 해설 글이 그 수치를 읽는 법을 다루고, 확률 계산기가 해시레이트를 현실적인 기댓값으로 바꿔준다. eCash 풀 페이지에는 현재 난이도와 모든 지역 엔드포인트가 있고, 설정 생성기가 stratum 설정을 만들어주며, 블록과 워커의 실시간 데이터는 풀 대시보드에 있다.

솔로 채굴을 위해 자신의 eCash 노드를 운영한다면 중요한 설정 항목이 하나 있다. 노드가 실시간 타깃을 계산하려면 기록된 헤더 도착 시각이 17블록 분량 필요하다. 그것이 갖춰질 때까지는 너무 낮은 난이도로 템플릿을 만들어 블록이 파킹될 수 있다. persistrecentheaderstime=1을 설정하면 그 기준 시각들이 디스크에 저장되고 재시작 때 다시 로드되어 이 공백이 메워진다.

출처

• eCash 채굴 문서 — 블록 템플릿의 RTT 필드, 타깃 계산의 참조 구현, 공개된 필터 계수
• Heartbeat Upgrade: A Steady Pulse for eCash — 그 근거, 스위치 채굴 문제, Avalanche 사후 합의의 역할
• Bitcoin ABC 소스 코드 — src/policy/block/rtt.cpp. 수식, 창 상수, 파킹 정책이 담겨 있다
• eCash 솔로 채굴 소프트웨어 — eCash에서 실시간 타깃이 보고되는 네트워크 난이도가 되는 방식

이 글의 검증 수치는 2026년 8월 2일 가동 중인 eCash 노드의 로그에 대해 공개된 수식을 평가하고 결과를 값별로 비교하여 산출했다.