2026년 Zcash 채굴 보안: Orchard 수정 및 위험 가이드

12026년 Z캐시 채굴: 시스템부터 시작하기

Z캐시는 Equihash 채굴자들이 보호하는 작업 증명 네트워크로 남아 있습니다. 특수 ASIC 하드웨어가 해싱 작업을 수행하고, 풀이 지분(share)을 집계하며, 풀 노드가 블록을 검증하고, 지갑이 지급을 받습니다. 따라서 수익성 있는 작업은 해시레이트 이상의 요소에 달려 있습니다. 전기, 가동 시간, 풀 신뢰성, 지갑 보안, 소프트웨어 호환성, 네트워크 난이도, ZEC의 시장 가치 모두 동일한 운영 체인에 속합니다.

이것이 중요한 이유는 2026년 Orchard 사건이 ASIC을 손상시키거나 Equihash 칩이 작업을 계산하는 방식을 변경하지 않았기 때문입니다. 이는 쉴드 트랜잭션 회로의 결함을 드러냈습니다. 그러나 이 대응은 채굴자들에게 영향을 미쳤습니다. 노드 및 풀 운영자는 소프트웨어 업그레이드를 조율해야 했고, 노후화된 인프라는 거부된 블록을 생성할 위험이 있었으며, 시장 신뢰는 채굴된 보상의 가치에 영향을 미쳤습니다.

2Z캐시 채굴 위험 스택

채굴자들은 종종 기계 사양에 집중합니다. 비교하기 쉽기 때문입니다. 이는 필요하지만 불완전합니다. 더 나은 평가는 위험을 계층별로 분리하고 각 계층에 소유자, 모니터링 신호 및 대응 계획을 부여합니다.

3Orchard에 무슨 일이 일어났는가?

2026년 5월 29일, 보안 연구원 Taylor Hornby는 Shielded Labs의 의뢰로 AI 지원 보안 감사 중 Orchard Action 회로에서 건전성 취약점을 보고했습니다. Orchard는 Zcash의 쉴드 프로토콜로, 사용자가 송신자, 수신자 또는 금액을 공개하지 않고도 비공개 트랜잭션이 규칙을 준수함을 증명할 수 있게 합니다.

결함은 Equihash 채굴 하드웨어가 아닌 회로 구현에 있었습니다. 간단히 말해, 스칼라 곱셈 가젯 내에서 관계가 누락되어 악의적인 증명자가 유효하지 않은 숨겨진 잔액 변경에 대해 겉보기에 유효한 증명을 생성할 수 있었습니다. 따라서 성공적인 익스플로잇은 Orchard 풀 내에서 무단 가치 생성을 허용했을 수 있습니다.

4네트워크는 어떻게 대응했는가?

대응은 두 가지 조율된 단계로 이루어졌습니다. 첫째, 개발자들이 수정된 회로를 완성하고 검토하는 동안 비상 소프트 포크가 Orchard 작업을 일시적으로 비활성화했습니다. 이 완화 조치는 6월 2일 블록 높이 3,363,426에서 메인넷에 활성화되었습니다. 이 임시 기간 동안 Sapling 및 투명 트랜잭션은 계속 작동했습니다.

둘째, NU6.2는 6월 3일 메인넷 블록 높이 3,364,600에서 활성화되었습니다. 이는 수정된 회로와 새로운 검증 키를 사용하여 Orchard를 복원했으며, 동시에 정식 증명 길이를 강제했습니다. 업그레이드를 지원하는 공식 릴리스는 zcashd 6.20.0 및 Zebra 5.0.0 또는 이후 호환 버전이었습니다.

이러한 대응은 유용한 채굴 교훈을 제공합니다. 합의 변경은 일반적인 앱 업데이트가 아닙니다. 긴급 활성화를 놓친 풀이나 노드는 업그레이드된 네트워크가 거부하는 작업을 생성하거나, 연결이 끊기거나, 높은 고아 블록률을 경험할 수 있습니다. 해당 인프라에 연결된 채굴자는 해시레이트를 계속 표시하면서도 예상보다 적게 벌 수 있습니다.

5Orchard 이벤트가 ZEC 채굴자에게 미치는 의미

ASIC을 제3자 풀에 연결하는 채굴자에게 가장 중요한 질문은 풀이 업그레이드되었고 승인된 체인에 남아 있었는지 여부입니다. 채굴기 자체는 모든 프로토콜 규칙을 검증하지 않습니다. 채굴기는 풀에 지분을 제출하고, 풀의 노드는 후보 블록을 구축하거나 검증합니다. 이것은 풀 소프트웨어 규율을 채굴자의 상대방 위험의 일부로 만듭니다.

자신의 풀 노드나 풀을 운영하는 운영자는 더 큰 책임을 집니다. 그들은 공식 릴리스를 모니터링하고, 바이너리 및 릴리스 노트를 확인하고, 업그레이드를 준비하고, 구성 백업을 보존하고, 업그레이드 후 피어 수, 체인 높이, 블록 템플릿 및 지급 처리를 확인해야 합니다. 비상 업그레이드 중에는 일상적인 유지 보수 기간을 기다리는 것이 너무 늦을 수 있습니다.

지갑 사용자도 주소 및 소프트웨어 지원과 채굴 작업의 차이를 구분해야 합니다. 네트워크 업그레이드를 제대로 따르지 못하는 지급 지갑은 풀이 올바르게 지불했음에도 불구하고 보상 접근을 지연시킬 수 있습니다. 현재 지원되는 지갑 소프트웨어를 사용하고, 복구 자료를 오프라인으로 보호하며, 주요 지갑 또는 프로토콜 변경 후 소액 지급을 테스트하십시오.

6실용적인 보안 체크리스트

7고정 약속 없이 수익성 계산

Zcash 수익은 네트워크 난이도, 블록 발행, 풀 운, 수수료, 가동 시간 및 ZEC 가격에 따라 변합니다. 따라서 수익성 추정치는 보장이 아닌 스냅샷으로 취급되어야 합니다. 비정상적으로 유리한 하루를 연간으로 환산하거나 현재 네트워크 조건이 변함없이 유지될 것이라고 가정하지 마십시오.

일일 전기 비용 = kW 단위 전력 × 24 × 전기 요금. 순 영업 현금 흐름은 총 채굴 수익에서 전기, 풀 수수료, 호스팅, 냉각, 유지 보수, 가동 중단 및 모든 전환 비용을 뺀 것입니다. 하드웨어 감가상각 및 세금도 전체 투자 모델에 포함되어야 합니다.

적어도 세 가지 시나리오를 실행하십시오. 기본 사례, 낮은 ZEC 가격과 높은 난이도를 가정한 하방 사례, 그리고 낮은 가동 시간이나 일시적인 풀 문제를 가정한 중단 사례. 프로토콜 보안 이벤트는 ASIC이 계속 해싱 작업을 수행하더라도 유동성, 가격, 소프트웨어 가용성 및 지급에 영향을 미칠 수 있으므로 마지막 시나리오에 속합니다.

8더 나은 실행/중단 프레임워크

• 진행 하방 시나리오에서도 전기가 경쟁력을 유지하고, 냉각 및 회로 용량이 검증되었으며, 풀이 신뢰할 수 있는 업그레이드 기록을 가지고 있을 때.
• 노출 감소 대부분의 예상 마진이 단일 ZEC 가격 가정, 단일 풀, 단일 지급 지갑 또는 중단 없는 가동 시간에 의존할 때.
• 확장 일시 중지 활성 네트워크 사고 중에 노드 또는 풀 호환성이 불분명하거나, 승인된 지분 및 지급을 조정할 수 없을 때.
• 종료 또는 재배포 현실적인 조건에서 지속적인 운영 마진이 더 이상 전기, 유지 보수 및 하드웨어 감가상각을 감당하지 못할 때.

핵심 원칙은 간단합니다. 채굴 계획은 한 가지 유형 이상의 실패에서 살아남아야 합니다. 효율적인 하드웨어는 도움이 되지만, 규율 있는 소프트웨어 업데이트, 안전한 지급 관리, 풀 중복성, 보수적인 경제학이 운영의 탄력성을 결정합니다.

9자주 묻는 질문