DigiByte: 셰어가 블록이 되지 못한 이유
DigiByte 셰어가 네트워크 난이도를 넘었는데 아무것도 얻지 못했습니다. MultiShield는 SHA-256 목표값을 몇 초마다 움직입니다. 풀의 실제 로그로 검증했습니다.
DigiByte의 MultiShield는 다섯 알고리즘 중 어디에서든 블록이 도착할 때마다 SHA-256 채굴 목표값을 다시 계산합니다. 평균적으로 15초마다입니다. 익스플로러, 대시보드, 채굴 리포트에서 보는 네트워크 난이도는 이미 낡아 버린 스냅샷입니다. 그 값을 넘은 셰어가 유효한 블록이 되려면, 풀에 도착한 바로 그 초에 유효한 목표값을 넘어야 합니다. DigiByte 솔로 채굴자가 기록적인 셰어를 보고도 아무것도 얻지 못하는 가장 흔한 이유가 바로 이것입니다.
핵심 요약
- DigiByte에서 SHA-256 목표값은 다섯 알고리즘 중 어디에서든 블록이 도착할 때마다 다시 계산됩니다. SHA-256 블록을 찾았을 때만이 아닙니다.
- 90분 구간에서 SHA-256 블록 난이도는 4.18억에서 11.2억까지 움직였습니다. 2.7배의 폭입니다.
- 단 2분 구간에서 유효 목표값은 7.48억에서 13.1억으로 75% 올랐습니다.
- 셰어의 가치는 그것이 도착한 초의 목표값으로 정해집니다. 같은 셰어가 어느 순간에는 못 미치고, 1〜2분 뒤에는 이길 수도 있습니다.
- 이것이 블록을 잃었다는 뜻은 아닙니다. 유효 목표값보다 낮은 셰어는 블록으로 전송되지 않으므로, 고아로 만들거나 거부하거나 숨길 것이 아무것도 없습니다.
제 셰어가 네트워크 난이도를 넘었는데 왜 블록을 찾지 못했을까?
한 DigiByte 솔로 채굴자가 꼼꼼하고 잘 조사된 보고를 보내왔습니다. 그분의 채굴기는 난이도 약 9.97억의 셰어를 냈습니다. 약 1시간 뒤에 생성된 채굴 리포트에는 네트워크 난이도가 5.31억으로 표시되어, 셰어가 목표값의 거의 두 배인 셈이었습니다. 그런데도 블록은 나타나지 않았습니다. 그분은 풀의 API를 확인해 셰어가 수신되고 수락되었음을 확인했고, 거부나 오래된 셰어 기록이 전혀 없다는 것도 확인했습니다. 볼 수 있는 모든 숫자로 보면 블록이 되었어야 했습니다.
그분이 본 숫자는 진짜였습니다. 다만 봐야 할 숫자가 아니었을 뿐입니다.
저희는 풀의 로그에서 그 셰어를 추적했습니다. 셰어는 2026년 10월 4일 06:26:31에서 06:27:31 UTC 사이에 도착했습니다. 그 1분 동안 네트워크가 요구한 것은 5.31억이 아니었습니다. 요구한 것은 11.3억〜12.1억이었습니다. 셰어는 필요한 값의 82.7%〜88.1%에 도달했습니다.
5.31억이라는 수치는 급등이 지나간 1시간 뒤의 난이도였습니다. 그리고 06:28:37부터, 즉 셰어가 도착한 지 1〜2분 뒤에 목표값은 9.97억 아래로 내려갔습니다. 같은 셰어가 1〜2분 늦게 도착했다면 블록이 되었을 것입니다.
DigiByte의 난이도는 왜 이렇게 크게 움직일까?
DigiByte는 블록 생산을 다섯 개의 독립적인 채굴 알고리즘으로 나눕니다. SHA-256, Scrypt, Skein, Qubit, Odocrypt입니다. 각각이 대략 다섯 블록 중 하나를 채굴하고, 각각 고유한 난이도를 가집니다. 체인 전체는 15초에 한 블록을 목표로 하므로 SHA-256 레인은 평균 75초에 한 블록이 됩니다.
각 레인의 난이도는 DigiByte가 2014년에 도입한 DigiShield의 멀티 알고리즘 확장인 MultiShield가 관리합니다. Bitcoin이 2,016블록마다 한 번 재조정하는 반면, MultiShield는 매 블록마다 난이도를 다시 계산합니다.
채굴자들이 허를 찔리는 부분은, MultiShield가 매 블록마다 그 블록을 찾은 레인만이 아니라 모든 레인을 다시 계산한다는 점입니다. DigiByte의 합의 코드는 난이도 파라미터 위의 주석에서 이를 분명히 밝힙니다. 다른 알고리즘이 블록을 풀면 어떤 알고리즘의 난이도가 내려갈 수 있다는 것입니다. 따라서 SHA-256 목표값은 SHA-256 블록과 블록 사이에서도 가만히 있지 않습니다. Scrypt, Skein, Qubit, Odocrypt에서 찾은 블록도 모두 목표값을 움직이며, 그 결과 목표값은 약 15초마다 바뀝니다. 전체 알고리즘은 합의 코드에서 직접 읽어 낸 DigiByte 해설에서 다룹니다.
그 1분 동안 목표값은 실제로 어떻게 움직였을까?
새 블록이 도착할 때마다 풀은 새 채굴 작업을 만들고 그 작업이 충족해야 할 목표값을 기록합니다. 다음은 그 셰어 전후로 풀의 로그가 기록한 정확한 값입니다.
| 시각 (UTC) | 유효한 SHA-256 목표값 |
|---|---|
| 06:24:07 | 748,086,882 |
| 06:24:35 | 919,283,054 |
| 06:25:36 | 1,128,075,706 |
| 06:25:48 | 1,078,654,901 |
| 06:26:02 | 1,312,633,757 |
| 06:26:10 | 1,262,143,768 |
| 06:26:18 | 1,205,245,749 |
| 06:26:55 | 1,130,849,418 |
| 06:27:31 | 1,087,355,545 |
| 06:28:30 | 1,039,941,926 |
| 06:28:37 | 989,362,566 |
| 06:28:49 | 942,584,060 |
셰어는 06:26:31에서 06:27:31 사이에 도착했고, 그때 목표값은 1,205,245,749였다가 이어서 1,130,849,418이었습니다. 996,739,624의 셰어는 요구값의 82.7%〜88.1%에 도달했습니다. 목표값이 처음으로 셰어 아래로 내려간 것은 06:28:37입니다.
이 물결을 만든 원인은, 같은 구간에서 체인이 실제로 생성한 SHA-256 블록을 더해 보면 분명해집니다.
| 블록 | 채굴 시각 (UTC) | 난이도 |
|---|---|---|
| 24,323,739 | 06:24:11 | 748,086,882 |
| 24,323,740 | 06:24:35 | 919,283,054 |
| 24,323,742 | 06:25:50 | 1,078,654,901 |
| 24,323,752 | 06:30:14 | 857,977,528 |
99초 동안 SHA-256 블록이 세 개 도착했습니다. 75초에 하나라는 예상 속도에 비해 33초에 하나입니다. SHA-256 레인은 다른 네 레인보다 크게 앞서 있었고, MultiShield는 이에 대응해 난이도를 끌어올려 최고 13.1억에 이르렀습니다. 그 후 4분 24초 동안 SHA-256 블록은 하나도 도착하지 않았습니다. 다른 알고리즘에서 블록이 도착함에 따라 목표값은 한 계단씩 내려갔습니다. 셰어가 도착한 것은 정점 직후, 목표값이 아직 거기서 내려오던 중이었습니다.
기록된 값은 추정치가 아니라 네트워크의 실제 요구값입니다. 위의 네 SHA-256 블록은 모두 풀이 직전에 기록한 목표값과 정확히 같은 값으로, 일의 자리까지 일치하게 채굴되었습니다. 네 블록 모두 어떤 DigiByte 익스플로러에서도 공개적으로 검증할 수 있습니다.
리포트의 난이도는 왜 목표값과 일치하지 않았을까?
리포트가 기록한 것이 1시간 뒤의 순간이었고, DigiByte에서 1시간은 긴 시간이기 때문입니다.
익스플로러, 풀 대시보드, 채굴 리포트, 수익성 계산기 등 어디에서 보는 난이도 값이든, 그것은 읽은 순간의 값입니다. Bitcoin에서는 그 값이 2주 동안 유지됩니다. DigiByte에서는 다섯 알고리즘 중 하나가 블록을 찾을 때마다 SHA-256 목표값이 다시 계산되므로, 07:34에 잡은 값은 06:27에 무엇이 요구되었는지에 대해 거의 아무것도 말해 주지 않습니다.
이 셰어 전후 90분 동안 체인의 SHA-256 블록 난이도는 약 4.18억에서 11.2억까지, 2.7배의 폭을 보였습니다. 9.97억의 셰어는 그 범위의 아래쪽이라면 넉넉히 블록이 되었고, 위쪽이라면 넉넉히 못 미쳤습니다.
함정이 하나 더 있습니다. 익스플로러는 채굴된 시점의 각 블록 난이도, 즉 승자에게 적용된 값을 공개합니다. 블록과 블록 사이 몇 초 동안 유효했던 목표값에 대한 공개 기록은 존재하지 않습니다. 위 로그에서 가장 높은 목표값인 13.1억은 어떤 익스플로러에도 나타나지 않습니다. 그 값이 유효했던 동안 SHA-256 블록이 하나도 채굴되지 않았기 때문입니다. 그런데도 아깝게 놓치는 일은 바로 그런 순간에 일어납니다.
목표값은 왜 MultiShield의 8% 한계를 넘어 튈 수 있을까?
저희 DigiByte 해설은 MultiShield가 재조정을 제한해, 난이도가 한 단계에 최대 16%까지 내려가지만 오르는 것은 최대 8%라고 설명합니다. 그런데 이 구간에서는 빠른 SHA-256 블록 세 개 이후 매번 목표값이 20% 넘게, 즉 22.9%, 22.7%, 21.7% 올랐습니다.
이 두 사실은 모순되지 않습니다. MultiShield가 레인을 서로 다른 두 가지 방식으로 움직이기 때문입니다. 8%와 16%의 한계는 레인 자체의 평균화된 재조정을 묶어 둡니다. 여기에 더해 알고리즘별 4% 조정이 있어, 레인이 다른 네 레인보다 뒤처져 있는지 앞서 있는지에 따라 레인을 움직입니다.
이 구간에서는 두 번째 메커니즘이 뚜렷한 톱니 모양을 만들었습니다. 다른 알고리즘에서 블록이 나올 때마다 SHA-256 목표값은 약 4〜5% 내려갔습니다. 그리고 레인이 이미 앞서 있을 때 도착한 SHA-256 블록은 매번 목표값을 다시 가파르게 밀어 올렸습니다. 이를 염두에 두고 위 목표값 로그를 다시 읽으면 패턴은 오해의 여지가 없습니다. SHA-256 블록 뒤마다 세 번의 큰 계단으로 오르고, 그다음 긴 계단을 따라 내려갑니다.
eCash의 Real-Time Targeting과는 무엇이 다를까?
증상은 같습니다. 셰어가 공표된 난이도를 넘어도 아무것도 얻지 못합니다. 하지만 메커니즘은 다릅니다.
| eCash (RTT) | DigiByte (MultiShield) | |
|---|---|---|
| 움직이는 것 | 한 블록 간격 안에서의 요구값 | 블록 사이의 목표값 |
| 무엇에 따라 | 직전 블록 이후 경과 시간 | 다섯 알고리즘 중 어느 것이 각 블록을 찾느냐 |
| 모양 | 각 블록 뒤 급등, 약 115초에 걸쳐 감쇠 | 빠른 SHA-256 블록 뒤 상승, 다른 블록 뒤 하락 |
| 미리 예측 가능한가 | 예, 경과 시간으로 | 아니요, 다른 레인에 달려 있음 |
eCash에서는 셰어의 운명이 직전 블록이 얼마나 전에 도착했느냐로 정해집니다. 이 내용은 eCash RTT: 솔로 셰어가 블록이 되지 못한 이유에서 자세히 다뤘습니다. DigiByte에서는 어떤 알고리즘에서든 가장 최근 블록 이후 SHA-256 목표값이 어디에 있었느냐로 정해집니다. 둘 다 채굴자 입장에서는 영락없이 블록을 놓친 것처럼 보이는, 아깝게 놓친 셰어를 만들어 냅니다.
Bitcoin이나 다른 SHA-256 체인에서도 일어날까?
이런 형태로는 일어나지 않습니다. 대부분의 SHA-256 체인에서는 목표값이 블록 간격 내내 고정되어 있다가, 그 체인이 다음 블록을 찾을 때만 바뀝니다.
| 체인 | 난이도 조정 | 블록 사이의 목표값 |
|---|---|---|
| Bitcoin | 2,016블록마다 | 일정 |
| Bitcoin Cash | ASERT, 매 블록 | 일정 |
| eCash | ASERT와 RTT | 각 블록 뒤 상승 후 감쇠 |
| DigiByte | MultiShield, 매 블록, 모든 알고리즘 | 어느 알고리즘의 블록이든 매번 움직임 |
Bitcoin과 Bitcoin Cash에서는 조회한 난이도가 곧 넘어야 했던 값입니다. DigiByte에서는 여러분의 셰어를 결정한 목표값이 몇 초 동안만 존재했고 어디에도 공개되지 않았습니다.
블록은 손실되었거나, 고아가 되었거나, 숨겨졌을까?
아닙니다. 애초에 블록이 존재하지 않았기 때문입니다.
풀은 셰어가 해당 작업의 네트워크 목표값에 도달할 때마다 블록 해결 이벤트를 기록합니다. 이 셰어에 대해서는 그런 이벤트가 한 번도 없었습니다. 풀은 셰어를 유효 목표값과 비교해 미달로 판단하고 일반 셰어로 수락했습니다. 블록은 조립되지 않았고, submitblock 호출도 없었으며, 네트워크로는 아무것도 보내지지 않았습니다. 고아로 만들거나, 거부하거나, 잃을 것이 아무것도 없었습니다.
비수탁형 풀에서는 이를 외부에서 확인할 수 있습니다. 채굴자의 지급 주소는 해싱이 시작되기 전에 블록 템플릿의 코인베이스 트랜잭션에 기록되므로, 실제 블록은 모두 채굴자 자신의 이름으로 영구히 온체인에 나타납니다. 블록이 되지 못한 셰어는 그런 흔적을 남기지 않습니다. 그리고 실제 블록이 존재했다면 그것을 숨길 수는 없었을 것입니다.
DigiByte 솔로 채굴자는 실제로 무엇을 해야 할까?
거의 아무것도 할 필요가 없습니다. 다만 숫자는 올바르게 읽으세요.
- 모든 난이도 값을 스냅샷으로 여기세요. 대시보드나 리포트에서 난이도를 넘는 베스트 셰어가 보여도, 그것은 블록을 놓쳤다는 증거가 아닙니다. 셰어가 도착했을 때 목표값이 더 높았다는 증거입니다.
- 채굴기가 표시하는 베스트 셰어는 로컬에서 계산됩니다. 채굴기는 해시를 찾은 순간, 풀이 응답하기 전에 그 난이도를 기록하며, 대개 초기화되지 않는 역대 최고값을 보관합니다. 그것은 하드웨어에 좋은 순간이 있었음을 알려 줄 뿐, 그 순간이 승리였는지는 알려 주지 않습니다.
- 셰어 난이도 관리는 vardiff에 맡기세요. DigiByte는 매 블록마다 재조정하므로, 어느 한 시간에 맞는 고정 셰어 난이도가 다음 한 시간에는 틀릴 수 있습니다. 설정은 DigiByte 설정 가이드에서 다룹니다.
- 지연을 낮게 유지하세요. 15초 블록 체인에서는 가까운 서버일수록 새 작업이 나타난 뒤 채굴기가 그 작업에 착수하기까지의 간격이 짧아집니다.
- 카운터가 아니라 코인베이스를 확인하세요. 블록을 찾았는지 알려면 온체인 코인베이스 트랜잭션에서 자신의 주소를 찾아보세요.
이 중 어느 것도 장기적인 확률을 바꾸지는 않습니다. 변동은 시간이 지나면 상쇄되므로, 평균 난이도에 기반한 확률, 예를 들어 저희 솔로 확률 계산기가 쓰는 확률이 여전히 기대치의 올바른 기준입니다. 변동이 결정하는 것은 어떤 아깝게 놓친 셰어가 블록이 되느냐뿐입니다.
출처
- DigiByte Core 합의 파라미터 — 난이도가 매 블록마다 모든 알고리즘에 대해 갱신된다는 주석과, MultiShield 상수
nMaxAdjustUpV4 = 8,nMaxAdjustDownV4 = 16,nLocalTargetAdjustment = 4 - DigiByte Core —
pow.cpp, MultiShield 난이도 조정(GetNextWorkRequiredV4) - 채굴자를 위한 DigiByte(DGB) 해설 — 합의 코드에서 직접 읽어 낸 MultiShield의 전체 프로필
- Measuring expected block timing for Difficulty Adjustment — MultiShield와 매 블록 재조정에 관한 Josiah Spackman의 글
이 글의 목표값은 2026년 10월 4일 풀의 로그에서 가져온 것으로, 새 채굴 작업이 만들어질 때마다 기록된 값입니다. 구간 안에서 채굴된 네 SHA-256 블록, 24,323,739, 24,323,740, 24,323,742, 24,323,752는 모두 각각의 직전에 풀이 기록한 목표값과 정확히 일치하며, 이는 기록된 값이 네트워크의 실제 요구값임을 뒷받침합니다. 인용한 블록 난이도는 모두 어떤 DigiByte 익스플로러에서도 공개적으로 검증할 수 있습니다.
자주 묻는 질문
제 DigiByte 셰어가 네트워크 난이도를 넘었는데 왜 블록을 찾지 못했나요?
여러분이 본 네트워크 난이도가 스냅샷이었기 때문입니다. DigiByte의 MultiShield는 다섯 알고리즘 중 어디에서든 블록이 도착할 때마다 SHA-256 목표값을 다시 계산하며, 대략 15초마다입니다. 셰어가 블록이 되려면 풀에 도착한 바로 그 초에 유효한 목표값을 넘어야 하고, 그 목표값은 나중에 읽은 값보다 훨씬 높을 수 있습니다.
DigiByte 난이도는 매 블록마다 바뀌나요?
네. MultiShield는 매 블록마다 다시 계산하며, 블록을 찾은 알고리즘뿐 아니라 다섯 알고리즘 모두의 난이도를 갱신합니다. DigiByte 자체 소스 코드에는 다른 알고리즘이 블록을 찾으면 어떤 알고리즘의 난이도가 내려갈 수 있다고 적혀 있습니다. 실제로 SHA-256 목표값은 약 15초마다 바뀝니다.
DigiByte의 SHA-256 난이도는 짧은 시간에 얼마나 움직일 수 있나요?
아주 크게 움직입니다. 2026년 10월 4일의 90분 구간에서 SHA-256 블록 난이도는 약 4.18억에서 11.2억까지, 2.7배의 폭을 보였습니다. 단 2분 구간에서 유효 목표값은 7.48억에서 13.1억으로 75퍼센트 올랐습니다. 셰어의 가치는 그것이 도착한 초에 달려 있습니다.
제 대시보드의 난이도가 넘어야 했던 난이도와 다른 이유는 무엇인가요?
대시보드, 익스플로러, 채굴 리포트는 읽은 시점의 난이도를 보여 주는데, DigiByte에서는 그 값이 몇 초 만에 낡습니다. 게다가 익스플로러는 채굴된 시점의 각 블록 난이도만 공개할 뿐, 블록과 블록 사이 몇 초 동안 유효했던 목표값은 절대 공개하지 않습니다. 아깝게 놓치는 일은 바로 그 사이에 일어납니다.
이것은 eCash의 Real-Time Targeting과 같은 건가요?
증상은 같지만 메커니즘은 다릅니다. eCash의 RTT는 각 블록 이후 요구값을 끌어올렸다가 경과 시간에 따라 약 115초에 걸쳐 낮춥니다. DigiByte의 MultiShield는 다섯 알고리즘 중 어디에서든 블록이 나올 때마다 SHA-256 목표값을 움직이며, 그 방향은 SHA-256 레인이 다른 레인보다 앞서 있는지 뒤처져 있는지에 따라 정해집니다.
제 DigiByte 블록이 손실되거나, 고아가 되거나, 풀에 의해 숨겨졌을 수 있나요?
셰어가 유효 목표값보다 낮았다면 그럴 수 없습니다. 애초에 블록이 만들어지지 않았기 때문입니다. 목표값에 못 미친 셰어는 일반 셰어로 수락되고 네트워크로는 전혀 보내지지 않습니다. 비수탁형 풀에서는 해싱 전에 이미 지급 주소가 코인베이스에 들어가 있으므로, 실제 블록은 모두 여러분 이름으로 온체인에 보입니다.
DigiByte 난이도가 급등할 때 셰어가 도착하면 손해를 보나요?
여러분이 손쓸 수 있는 방식의 손해는 없습니다. 난이도 변동은 이미 체인의 실제 블록 생산에 반영되어 있어 시간이 지나면 상쇄됩니다. 변동이 결정하는 것은 어떤 아깝게 놓친 셰어가 블록이 되느냐뿐입니다. 장기적인 확률은 여전히 평균 난이도와 여러분의 해시레이트를 따릅니다.
난이도 급등 때문에 DigiByte 블록을 놓치지 않으려면 어떻게 해야 하나요?
목표값의 타이밍은 맞출 수 없으므로 급등을 피하는 설정은 없습니다. 도움이 되는 것은 자신의 수치를 올바르게 읽고, 셰어 난이도 관리를 풀의 vardiff에 맡기고, 15초 블록 체인에서 지연을 낮게 유지하도록 가까운 서버에 연결하는 것입니다. 블록을 확인하려면 온체인 코인베이스 트랜잭션에서 자신의 주소를 찾아보세요.