지캐시 Orchard 위조 취약점 — AI가 찾아낸 4년짜리 ZK 회로 결함 심층 분석

TL;DR — 2026년 5월, 보안 연구자 Taylor Hornby가 Anthropic의 Opus 4.8을 보조 도구로 활용해 Zcash의 최신 shielded pool인 Orchard 회로에서 약 4년간 잠복해 온 위조(counterfeiting) 취약점을 발견했다. 원인은 under-constrained 회로 — elliptic curve multiplication 검증에 필요한 제약이 빠져 있어, 수학적으로 틀린 false witness로도 검증을 통과시켜 무제한·탐지 불가능한 counterfeit ZEC를 만들 수 있었다. 발견 닷새 만에 소프트포크와 NU6.2 하드포크로 수정됐다. 이 글은 공식적으로 확인된 사실과 공개 자료로는 확정할 수 없는 영역을 엄격히 구분해 정리한다.

1. 사건 개요 — 무엇이 발견됐나

2026년 5월 29일, 보안 엔지니어 Taylor Hornby는 Zcash의 최신 shielded pool인 Orchard 회로에서 critical counterfeiting vulnerability를 발견했다. Shielded Labs 공식 설명에 따르면, 이 취약점은 Orchard 안에서 무제한·탐지 불가능한 counterfeit ZEC를 생성할 수 있는 수준이었다.

Hornby는 2026년 4월부터 Shielded Labs의 의뢰로 Zcash 프로토콜 보안 연구를 진행했고, Anthropic의 Opus 4.8 모델이 2026년 5월 28일 공개된 직후 이를 활용해 Orchard 회로를 집중 검토했다. 공식 설명은 Hornby가 2026년 5월 29일 취약점을 발견해 Zcash Open Development Lab(ZODL)에 즉시 비공개 제보했다고 밝힌다.

취약점은 Orchard가 활성화된 2022년 5월부터 2026년 6월 1일 긴급 수정이 배포될 때까지 존재했다. 즉 약 4년간 존재했지만, Shielded Labs는 여러 정황상 사전 악용 가능성은 낮다고 평가했다. 다만 이것은 "증명"이 아니라 "평가"다. 출처: Shielded Labs 공식 설명.

공개 이후 시장은 민감하게 반응했다. 블루밍비트는 ZEC가 24시간 전 대비 31.4% 하락해 409.64달러를 기록했다고 보도했고, CoinDesk는 약 38% 급락으로 보도했다. Bitquery는 여러 시장 보도를 종합해 하루 30~50% 하락으로 표현했다. 출처: 블루밍비트, CoinDesk, Bitquery.

고가권·스냅샷 출처

급락 저점 출처

실측 앵커: 6/4 고점 624, 6/5 저점 309·스냅샷 409, 6/8 ≈ 월간 −30% 437, 6/9 448~478. 6/3·6/6·6/7은 추세 보간값.

Fig 1. ZEC/USD 일주일 등락 (2026-06-03 ~ 06-09) — 윗선은 스냅샷·고가권 출처(블루밍비트·news.bitcoin), 아랫선은 급락 저점 출처(BitMEX·DigitalCoinPrice). 급락 전까지 겹치다가 6/5 저점에서 출처별로 갈린 뒤 반등하며 수렴.

발견부터 수정까지 전체 사건의 흐름은 다음과 같다.

2022-05
Orchard 활성화
최신 shielded pool인 Orchard가 메인넷에 적용 — 이 시점부터 취약점이 존재.
2026-05-28
Opus 4.8 출시
Anthropic이 Opus 4.8 모델 공개. Hornby는 직후 이를 Orchard 회로 집중 검토에 활용.
2026-05-29
Hornby 발견 → ZODL 제보
Taylor Hornby가 critical counterfeiting 취약점 발견, Zcash Open Development Lab에 즉시 비공개 제보.
2026-06-01
긴급 fix 배포
수정 패치 배포. 취약점은 이 시점까지 약 4년간 존재했다.
2026-06-02
소프트포크 — 블록 3,363,426
임시 소프트포크 활성화로 Orchard actions를 비활성화.
2026-06-03
NU6.2 하드포크 — 블록 3,364,600
NU6.2 하드포크 활성화로 수정된 회로와 함께 Orchard 재활성화.

왼쪽 띠 색이 국면을 구분한다 — 취약점 잠복(rose) → AI 도구(amber) → 발견·제보(강조) → 긴급 수정(emerald).

Fig 2. Orchard 취약점 전체 타임라인 — 2022-05 활성화부터 약 4년간 잠복하다, 발견(2026-05-29) 닷새 만에 소프트포크 + NU6.2 하드포크로 마무리됐다.

2. 핵심 취약점 — 공식적으로 확인된 범위

공식적으로 확인된 기술 설명은 다음 한 문장으로 요약된다. Orchard 회로의 어떤 요소가 under-constrained였고, 그 결과 elliptic curve multiplication에 임의의 false input을 넣어도 multiplication check가 통과할 수 있었다. 출처: Shielded Labs 공식 설명.

직관적 비유 — '도장 5개' 검문소 — 입국 심사에서 도장 5개를 모두 확인해야 하는데, 검문 규칙에서 1개 확인을 빠뜨리면 바로 그 도장만 위조한 사람이 그대로 통과한다. ZK 회로의 빠진 제약도 똑같다. 검증자는 회로에 적혀 있는 검사만 수행하므로, 적혀 있지 않은 관계(여기서는 elliptic curve multiplication의 일부 조건)는 위조해도 걸리지 않는다.

위조 입력

EC multiplication을 만족하지 않는 false witness

↓

정상 회로

모든 제약을 검사

↓

모든 제약 통과?

곱셈 제약에서 걸림

↓

✓ 거부 — 위조 차단

under-constrained 회로

곱셈 검증 제약 일부 누락

↓

남은 제약만 통과?

누락된 제약은 검사 안 함

↓

✗ 통과 — 위조 ZEC 생성

차이는 ‘공식이 틀려서'가 아니라 ‘검사해야 할 관계가 회로에 적혀 있지 않아서' 생긴다.

Fig 3. 같은 위조 입력, 두 회로의 다른 결과 — 정상 회로는 곱셈 제약에서 위조를 거부하지만, 제약이 일부 누락된 under-constrained 회로는 같은 입력을 통과시킨다.

이 설명에서 중요한 단어는 under-constrained다. ZK 회로는 "증명자가 제시한 witness가 특정 다항식 제약을 만족한다"는 사실을 검증한다. 만약 필요한 제약이 빠져 있으면, 증명자는 실제 수학적 의미와 맞지 않는 값을 넣어도 검증을 통과시킬 수 있다. 이 일반 원리는 halo2나 Circom 등 ZK 회로 감사에서 가장 흔한 고위험 패턴 중 하나로 설명된다.

다만 현재 공개 자료만으로는 "정확히 어떤 파일의 어떤 두 줄이 빠졌는지", "어떤 witness가 어떤 방식으로 조작됐는지", "패치 diff가 어떤 형태였는지"를 검증할 수 없다. 따라서 아래 코드 블록은 실제 Zcash exploit 코드가 아니라 under-constrained EC multiplication이 어떻게 soundness failure로 이어질 수 있는지 보여주는 개념 코드다.

3. ZK 회로 기본 모델 — 왜 "빠진 제약"이 위험한가

halo2 스타일 회로에서 증명자는 advice column에 비밀 witness를 채우고, 회로는 selector가 켜진 행에서 특정 다항식이 0이 되도록 강제한다. 검증자는 witness 자체를 보지 않고, 해당 제약들이 만족됐는지만 확인한다.

// 교육용 개념 코드 — 실제 Orchard 코드 아님.
// selector가 켜진 행에서 out = a * b 를 강제하는 단순 게이트.
meta.create_gate("mul example", |meta| {
    let s   = meta.query_selector(q_mul);
    let a   = meta.query_advice(col_a, Rotation::cur());
    let b   = meta.query_advice(col_b, Rotation::cur());
    let out = meta.query_advice(col_out, Rotation::cur());
 
    // s * (a * b - out) == 0
    vec![s * (a * b - out)]
});

위 예시에서 out = a * b라는 제약이 빠지면, 증명자는 out에 임의의 값을 넣을 수 있다. 즉 검증자는 "곱셈 결과"라고 믿지만 실제로는 곱셈 결과가 아닌 값이 들어갈 수 있다. 이것이 under-constrained 회로의 기본 위험이다.

회로는 selector가 켜진 행에서 다항식 제약이 0이 되도록 강제한다. 곱셈 게이트는 다음을 강제한다.

s\cdot(a\cdot b - \mathit{out}) = 0

회로 전체는 제약 집합으로 볼 수 있고, 검증자는 모든 제약이 0이 되는지만 확인한다.

\mathcal{C} = \{\, p_k(\mathbf{w}) = 0 \,\}_{k=1}^{m}

만약 $a\cdot b - \mathit{out} = 0$ 제약이 빠지면, 아래를 만족하는 witness가 존재한다. 즉 곱셈 결과가 아닌 값도 검증을 통과한다.

\exists\, \mathbf{w}:\quad \mathit{out} \neq a\cdot b \;\wedge\; \forall k\; p_k(\mathbf{w}) = 0

1비밀 witness

증명자만 아는 비밀 입력값

→

2advice column 채움

witness를 회로의 advice 열에 배치

→

3제약 평가

selector ON 행에서 다항식 제약 계산

↓

모든 제약 = 0 ?

✓ 검증 통과

✗ 검증 실패

검증자는 witness를 직접 보지 않고, 제약이 0이 되는지만 확인한다.

제약이 빠지면(under-constrained) 실제로 틀린 값도 통과할 수 있다.

Fig 4. ZK 회로 검증 흐름 — 증명자는 advice column에 witness를 채우고, 회로는 selector가 켜진 행에서 다항식 제약을 평가한다. 검증자는 witness를 직접 보지 않고 제약 충족 여부만 확인한다.

4. Orchard와 value balance — 위조가 왜 공급 문제로 이어지는가

Zcash의 shielded transaction은 금액을 공개하지 않으면서도 전체 가치가 보존되는지 검증해야 한다. 일반적으로 이는 value commitment와 value balance를 통해 처리된다. 금액은 숨기되, 입력 commitment와 출력 commitment의 합 관계가 맞는지 검증하는 방식이다.

정상 불변식(개념):
  Σ value_in  ==  Σ value_out  + public_value_balance
 
목표:
  금액은 숨기되, 전체 합은 보존되도록 강제한다.

Shielded Labs의 설명은 이 버그가 "Orchard 내부에서 무제한 위조 ZEC를 만들 수 있었다"고 밝힌다. 이는 회로가 어떤 invalid state transition 또는 invalid witness를 정상 증명처럼 받아들였고, 결과적으로 가치 보존 불변식이 깨질 수 있었다는 의미다. 다만 공개 자료만으로는 실제 exploit이 value commitment의 어느 부분을 어떻게 위조했는지까지는 확정할 수 없다. 출처: Shielded Labs 공식 설명.

Bitquery는 이 문제를 "하나의 shielded note를 반복적으로 소비해 가치를 복제할 수 있는 missing constraint"로 설명한다. 이는 이해를 돕는 외부 분석이며, 공식 글의 "unlimited undetectable counterfeit ZEC" 설명과 방향은 같지만, 세부 exploit 구조는 공식적으로 검증된 원문과 구분해야 한다. 출처: Bitquery.

shielded transaction은 금액을 숨기면서도 다음 가치 보존 불변식을 강제해야 한다.

\sum_{i} v^{\text{in}}_{i} = \sum_{j} v^{\text{out}}_{j} + v_{\text{balance}}

금액 $v$ 는 Pedersen 형태의 value commitment로 숨겨진다. 여기서 $\mathcal{V},\mathcal{R}$ 는 독립적인 생성원이고 $r$ 은 blinding factor다.

\mathrm{cv} = [v]\,\mathcal{V} + [r]\,\mathcal{R}

commitment의 동형(homomorphic) 성질 덕분에 입력·출력 commitment의 차이로 전체 합을 검증할 수 있다.

\sum_i \mathrm{cv}^{\text{in}}_i - \sum_j \mathrm{cv}^{\text{out}}_j = \Big[\textstyle\sum_i v^{\text{in}}_i - \sum_j v^{\text{out}}_j\Big]\mathcal{V} + [\,r_{\Sigma}\,]\,\mathcal{R}

회로가 $v$ 와 $\mathrm{cv}$ 의 관계를 충분히 제약하지 못하면(under-constrained), 아래처럼 순증가분이 양수여도 검증이 통과할 수 있다. 이 $\Delta v$ 가 곧 위조량이다.

\Delta v = \sum_i v^{\text{in}}_i - \sum_j v^{\text{out}}_j > 0

정상 (제약 충족)

Σ value_in = Σ value_out + public_balance

↓

✓ 공급 보존

취약 (제약 누락 · 개념 모델)

하나의 shielded note

↓

소비

중복 소비

↓

가치 복제 (Σ in ≠ Σ out)

↓

✗ counterfeit ZEC

Bitquery는 이를 ‘하나의 note를 반복 소비해 가치를 복제하는 missing constraint'로 설명한다 — 공식 설명의 ‘무제한 위조'와 방향은 같되, 세부 구조는 공식 원문과 구분해야 한다.

Fig 5. 가치 보존 불변식과 위조 발생 — 정상 회로는 입력·출력 가치의 합을 강제하지만, 제약이 누락되면 하나의 note를 중복 소비해 가치를 복제할 수 있다(개념 모델).

5. Elliptic curve multiplication — 확인된 사실과 개념 모델

공식 글은 문제가 elliptic curve multiplication check와 관련됐다고 밝힌다. 즉 어떤 곡선 점과 스칼라의 곱셈 관계가 회로 안에서 충분히 강제되지 않았고, 그 틈을 통해 false input이 통과했다는 수준까지는 확인된다. 출처: Shielded Labs 공식 설명.

halo2 Book은 elliptic curve addition gadget에서 incomplete addition과 complete addition을 구분해 설명한다. incomplete addition은 특정 조건(예: 두 점의 x좌표가 같은 경우 등)에서 바로 사용할 수 없기 때문에, 회로가 어떤 케이스를 다루는지에 따라 추가 제약 또는 complete addition gadget이 필요하다. 출처: halo2 Book — Incomplete and complete addition.

짧은 Weierstrass 곡선의 일반 덧셈 개념:
 
P = (x1, y1), Q = (x2, y2)
λ = (y2 - y1) / (x2 - x1)
R = P + Q = (x3, y3)
 
이 공식은 x1 == x2 같은 예외 케이스에서 그대로 쓰기 어렵다.

따라서 기존 글의 "x2 - x1 != 0 제약이 빠졌다"는 표현은 가능한 설명 모델로는 유용하지만, 현재 공개 자료만으로는 "실제 Orchard 버그의 정확한 원인"이라고 단정하면 안 된다. 더 안전한 표현은 "elliptic curve multiplication 내부의 어떤 제약이 부족해 false input이 통과했다"이다.

짧은 Weierstrass 곡선에서 서로 다른 두 점 $P=(x_1,y_1)$ , $Q=(x_2,y_2)$ 의 합 $R=P+Q=(x_3,y_3)$ 는 다음과 같다.

\begin{aligned} \lambda &= \frac{y_2 - y_1}{x_2 - x_1} \\ x_3 &= \lambda^2 - x_1 - x_2 \\ y_3 &= \lambda\,(x_1 - x_3) - y_1 \end{aligned}

halo2는 분모를 직접 쓰지 않고 위 관계를 다항식 제약으로 바꾼다(incomplete addition).

\begin{aligned} (x_3 + x_2 + x_1)(x_2 - x_1)^2 - (y_2 - y_1)^2 &= 0 \\ (y_3 + y_1)(x_2 - x_1) - (y_2 - y_1)(x_1 - x_3) &= 0 \end{aligned}

이 공식은 $x_1 \neq x_2$ 를 가정한다. 만약 $x_1 = x_2$ 이면 $\lambda$ 의 분모가 0이 되어 정의되지 않으므로, incomplete addition은 임의 입력에 대해 안전하지 않다.

x_1 = x_2 \;\Rightarrow\; x_2 - x_1 = 0 \;\Rightarrow\; \lambda\ \text{undefined}

스칼라 곱 $[k]P$ 는 비트 분해로 계산되며, 각 단계의 점 연산이 모두 올바르게 제약돼야 한다.

[k]P = \sum_{t=0}^{n-1} k_t\,[\,2^{t}\,]P, \qquad k=\sum_{t=0}^{n-1} k_t 2^{t},\; k_t\in\{0,1\}

EC 점 덧셈 P + Q

↓

예외 케이스? (x₁ = x₂)

일반 케이스

↓

incomplete addition 사용 가능

예외 케이스

↓

추가 제약 또는 complete addition 필요

제약 부족 시

↓

false input 통과 — soundness failure

halo2 Book도 incomplete addition이 임의 입력에 안전하지 않음을 명시한다. 공식 자체가 아니라 ‘어떤 입력 영역에서 쓰는지'를 회로가 강제해야 한다.

Fig 6. EC 점 덧셈의 예외 케이스와 제약 필요성 — incomplete addition 공식은 x₁ = x₂ 같은 예외 입력에서 안전하지 않아, 회로가 그 케이스를 추가로 제약하지 않으면 false input이 통과할 수 있다.

6. 개념 코드 — under-constrained EC 연산이 어떻게 생길 수 있는가

아래 코드는 실제 Orchard 코드가 아니라, "EC addition/multiplication에서 예외 케이스 또는 보조 witness가 충분히 제약되지 않으면 어떤 형태의 문제가 생길 수 있는가"를 설명하기 위한 교육용 의사코드다.

// 교육용 개념 코드 — 실제 Zcash/Orchard 소스 아님.
// 목표: incomplete addition에서 예외 케이스를 충분히 막지 않으면
// witness가 자유도를 얻을 수 있다는 점을 보여준다.
 
meta.create_gate("ec_add_incomplete_concept", |meta| {
    let q = meta.query_selector(q_add);
 
    let xp = meta.query_advice(xp, Rotation::cur());
    let yp = meta.query_advice(yp, Rotation::cur());
    let xq = meta.query_advice(xq, Rotation::cur());
    let yq = meta.query_advice(yq, Rotation::cur());
    let xr = meta.query_advice(xr, Rotation::cur());
    let yr = meta.query_advice(yr, Rotation::cur());
 
    // halo2 Book의 incomplete addition 형태를 단순화한 제약.
    // 실제 halo2 Book은 분모를 직접 쓰지 않고 다항식 형태로 바꿔 제약한다.
    let c1 = (xr.clone() + xq.clone() + xp.clone())
        * (xp.clone() - xq.clone()) * (xp.clone() - xq.clone())
        - (yp.clone() - yq.clone()) * (yp.clone() - yq.clone());
 
    let c2 = (yr.clone() + yq.clone()) * (xp.clone() - xq.clone())
        - (yp.clone() - yq.clone()) * (xq.clone() - xr.clone());
 
    // incomplete addition은 임의 입력에 안전하지 않다.
    // 따라서 실제 회로는 어떤 케이스에서 이 게이트를 켜는지,
    // 예외 케이스를 별도 처리하는지까지 함께 검증해야 한다.
    vec![q.clone() * c1, q * c2]
});

위 코드에서 핵심은 "공식이 틀렸다"가 아니라 "공식을 어떤 입력 영역에서 쓰는지까지 회로가 강제해야 한다"는 점이다. halo2 Book도 incomplete addition constraint가 임의 입력에 사용할 수 없음을 명시하고, complete addition에서는 여러 예외 케이스를 추가 제약으로 다룬다. 출처: halo2 Book.

7. exploit 개념 — 무엇이 확인됐고 무엇이 미확인인가

확인된 사실은 Hornby가 Opus 4.8의 도움을 받아 완전한 exploit을 작성했고, 로컬 regtest 환경에서 테스트했을 때 무제한·탐지 불가능한 counterfeit ZEC를 생성했다는 점이다. Shielded Labs는 같은 도구를 mainnet에서 실행했다면 mainnet 지갑에도 무제한 counterfeit ZEC가 생성됐을 것이라고 설명했다. 출처: Shielded Labs 공식 설명.

다만 exploit 코드 자체와 정확한 witness 조작 방식은 공개 자료에서 확인할 수 없다. 따라서 아래 의사코드는 실제 exploit이 아니라 "검증자는 valid proof로 받아들이지만 실제 의미론은 깨지는" under-constrained 회로 공격의 일반 구조를 보여주는 모델이다.

// 교육용 의사코드 — 실제 exploit 아님.
// 실제 Orchard 취약 코드/PoC는 공개 자료만으로 재구성할 수 없다.
 
fn counterfeit_concept() {
    // 1. 정상 입력처럼 보이는 shielded action을 만든다.
    let spend = make_valid_looking_spend();
 
    // 2. 회로가 충분히 제약하지 않는 witness 영역을 조작한다.
    let malicious_witness = craft_false_ec_multiplication_witness();
 
    // 3. 검증자는 제약식만 확인하므로, 빠진 제약이 있으면 proof가 통과할 수 있다.
    let proof = prove_with(malicious_witness);
 
    // 4. 의미론적으로는 가치 보존이 깨졌지만, 취약 회로 기준 검증은 통과한다.
    assert!(verify(proof));
}

이 exploit의 위험성은 Zcash의 프라이버시 특성과 결합될 때 커진다. Orchard 내부 금액은 암호화되어 있기 때문에, 위조된 노트가 Orchard 안에만 남아 있으면 외부 분석으로는 존재 여부를 확인할 수 없다.

1정상처럼 보이는 action

유효해 보이는 shielded action을 구성

→

2witness 영역 조작

회로가 충분히 제약하지 않는 부분을 변경

→

3false proof 생성

false EC multiplication witness로 proof 작성

↓

취약 회로 검증

빠진 제약 때문에 통과

↓

✗ 무제한 · 탐지 불가 counterfeit ZEC

검증은 통과하지만 가치 보존은 깨진다

실제 Orchard exploit 코드·witness 조작 방식은 공개 자료로 재구성할 수 없다 — 위 흐름은 under-constrained 공격의 일반 구조를 보여주는 모델이다.

Fig 7. exploit의 일반 구조 (개념 모델) — 정상처럼 보이는 action을 만들고, 제약이 부족한 witness 영역을 조작해 proof를 생성하면, 취약 회로는 빠진 제약 때문에 이를 통과시킨다.

8. 실제 악용 여부 — "없었다"가 아니라 "증거가 없다"

Shielded Labs는 과거 악용 가능성이 낮다고 평가했다. 이유는 이 취약점이 세계 최고 수준의 암호학자와 감사자들의 수년간 검토를 피해왔고, Hornby가 매우 의도적인 AI 보조 감사로 찾아냈으며, 발견 직후 ZODL과 생태계가 빠르게 대응했기 때문이다.

하지만 Shielded Labs는 동시에 "사용자가 우리의 평가에 의존해서는 안 된다"고도 밝혔다. Orchard의 프라이버시와 버그 특성상, 과거에 exploit이 있었는지 여부를 암호학만으로 확정할 수 없기 때문이다. 출처: Shielded Labs 공식 설명.

Bitquery는 체인 데이터를 분석해 대규모 탈취의 흔적은 없다고 봤다. 전체 공급은 발행 스케줄과 맞고, shielded pool이 급격히 비워지지 않았으며, Opus 4.8 공개 이후 Orchard 비활성화 전까지의 흐름도 비정상적이지 않았다는 설명이다.

그러나 Bitquery 역시 "작거나 아직 현금화되지 않은 위조"는 배제할 수 없다고 명시했다. 특히 fake note가 Orchard 안에 머물러 있다면 분석으로 발견할 수 없고, 소규모 현금화는 정상적인 일일 변동성에 묻힐 수 있다는 것이다. 출처: Bitquery.

과거 mainnet에서 실제 악용?

↓

regtest 환경에서 exploit 작동

확인됨

대규모 탈취 · 공급 이상 흔적

없음 (Bitquery)

단, 소규모·미현금화 위조는 배제 불가

Orchard 내부 잔류 위조 여부

확정 불가

프라이버시 특성상 cryptography만으로 증명 불가

‘없었다'가 아니라 ‘공개적으로 관측 가능한 증거가 없다'에 가깝다 — 두 문장은 다르다.

Fig 8. 실제 악용 여부 — 확인된 것과 미확인된 것. regtest에서 exploit이 작동함은 확인됐고 대규모 탈취 흔적은 없지만, Orchard 내부에 잔류한 위조 여부는 프라이버시 특성상 확정할 수 없다.

9. 대응 — 소프트포크와 NU6.2 하드포크

공식 글은 ZODL이 생태계 전반의 emergency response를 조율했고, 2026년 6월 2일 수정이 완료됐다고 설명한다. 취약점 자체는 2026년 6월 1일 긴급 fix 배포 전까지 존재했다. 출처: Shielded Labs 공식 설명.

Crypto Briefing은 더 구체적으로, 2026년 6월 2일 메인넷 블록 3,363,426에서 임시 소프트포크가 활성화되어 Orchard actions를 비활성화했고, 2026년 6월 3일 블록 3,364,600에서 NU6.2 하드포크가 활성화되어 수정된 회로로 Orchard가 재활성화됐다고 보도했다. 출처: Crypto Briefing.

Crypto Briefing은 Zcash Foundation 입장을 인용해, 이 과정에서 exploit evidence, unauthorized value creation, privacy impact가 없었다고 보도했다. 단, 이 보도는 Shielded Labs의 "암호학적으로 과거 악용 부재를 확정할 수 없다"는 설명과 함께 읽어야 한다. 두 문장은 충돌한다기보다, 하나는 "관측된 증거 없음"이고 다른 하나는 "원리적으로 완전 증명 불가"에 가깝다. 출처: Crypto Briefing, Shielded Labs 공식 설명.

10. 공급 무결성 회복 방안 — 새 shielded pool과 turnstile accounting

Shielded Labs는 사용자가 "우리의 평가"를 믿도록 두는 대신, 누구나 Zcash supply integrity를 검증할 수 있게 하는 네트워크 업그레이드를 검토 중이라고 밝혔다. 제안의 핵심은 새 shielded pool을 배포하고, Orchard pool에서 나오는 모든 코인에 turnstile accounting을 강제하는 것이다. 출처: Shielded Labs 공식 설명.

개념:
  Orchard pool → 새 shielded pool
 
검증 아이디어:
  Orchard에서 빠져나오는 총량을 공개적으로 추적한다.
  정당하게 들어온 총량보다 더 많이 빠져나오면,
  과거 위조분이 존재했을 가능성이 드러난다.

Bitquery는 turnstile을 "shielded side에서 transparent address 또는 다른 pool로 이동하는 공개 crossing"으로 설명한다. fake coin이 pool 안에 머무르면 보이지 않지만, 그것을 현금화하거나 다른 pool로 이동하려면 공개적으로 관측 가능한 경계를 지나야 한다는 분석이다. 출처: Bitquery.

Crypto Briefing은 Zcash Foundation 입장을 인용해 Zcash의 turnstile mechanism이 Sprout, Sapling, Orchard, transparent, lockbox pool 간 value를 추적해 total supply integrity를 확인한다고 보도했다. 다만 Shielded Labs가 새 shielded pool 및 Orchard 대상 turnstile accounting 업그레이드를 별도로 제안했다는 점은, 현 체계만으로 사용자 신뢰를 충분히 회복하기 어렵다는 현실을 보여준다. 출처: Crypto Briefing, Shielded Labs 공식 설명.

Orchard pool

위조 가능했던 구역

turnstile accounting 강제

→

새 shielded pool

공개적으로 관측 가능한 경계

빠져나온 총량 > 정당한 유입 총량?

예

↓

과거 위조분 존재 가능성 노출

아니오

↓

공급 무결성 검증 가능

fake coin이 pool 안에 머무르면 보이지 않지만, 현금화하거나 다른 pool로 옮기려면 공개 경계를 지나야 한다 — 사후 검증 가능한 accounting boundary.

Fig 9. 새 shielded pool + turnstile accounting 회복 방안 — Orchard에서 빠져나오는 총량을 공개적으로 추적해, 정당한 유입보다 더 많이 빠져나오면 과거 위조 가능성이 드러나게 한다.

11. 2018년 Sprout 취약점과의 비교

Zcash는 2018년에도 counterfeiting vulnerability를 겪었다. Electric Coin Company는 2019년 공개 글에서, 2018년 3월 Ariel Gabizon이 Sprout에 쓰인 BCTV14 기반 zk-SNARK 구성의 soundness flaw를 발견했고, 2018년 10월 28일 Sapling 업그레이드로 이를 수정했다고 밝혔다.

당시 취약점도 counterfeiting에 특화됐고, 사용자 privacy에는 영향을 주지 않았다고 설명됐다. 또한 ECC는 Sprout pool 모니터링과 체인 분석에서 counterfeiting evidence를 찾지 못했다고 밝혔다. 출처: Electric Coin Company (2019).

Orchard 사건과 Sprout 사건의 공통점은 "ZK 시스템의 soundness failure가 공급 무결성 문제로 이어질 수 있다"는 점이다. 차이점은 Sprout 문제는 proving system/parameter setup 계열의 flaw였고, Orchard 문제는 공개 설명 기준으로 Orchard circuit 내부의 under-constrained elliptic curve multiplication 문제라는 점이다. 출처: Electric Coin Company (2019), Shielded Labs 공식 설명.

2018 · Sprout

원인

BCTV14 기반 zk-SNARK — proving system / parameter flaw

↓

수정

Sapling 업그레이드로 수정 (2018-10-28)

2026 · Orchard

원인

회로 내부 under-constrained EC multiplication

↓

수정

소프트포크 + NU6.2 하드포크로 수정 (2026-06)

공통 — ZK soundness failure → 공급 무결성 위협 · privacy에는 영향 없음

Fig 10. 2018 Sprout vs 2026 Orchard — 둘 다 ZK soundness failure가 공급 무결성을 위협했지만, Sprout는 proving system/parameter 계열, Orchard는 회로 내부 under-constrained EC multiplication이라는 차이가 있다.

12. AI 감사의 의미

Shielded Labs는 Hornby가 최신 AI-assisted security auditing techniques와 전통적 보안 연구를 함께 사용했다고 설명한다. 특히 Opus 4.8 출시 직후 이를 Orchard 회로 집중 검토에 활용했고, 하루 뒤 취약점을 발견했다고 밝혔다.

이 사건의 의미는 "AI가 단독으로 수학적 증명을 완성했다"가 아니다. 더 정확히는 "전문 보안 연구자가 AI를 보조 도구로 사용해, 사람이 장기간 놓친 ZK 회로 취약점을 찾아냈다"는 것이다. 따라서 "AI가 모든 취약점을 찾는다"가 아니라 AI 보조 레드팀/회로 감사가 ZK·암호 인프라의 표준 방어 절차가 될 가능성이 커졌다고 정리하는 편이 정확하다.

Shielded Labs는 향후 Orchard circuit formal verification 프로젝트를 시작하고, Head of Security 및 Cryptographer 채용도 진행한다고 밝혔다. 이는 AI 보조 감사와 형식 검증(formal verification)을 함께 강화하겠다는 방향으로 해석할 수 있다. 출처: Shielded Labs 공식 설명.

13. 최종 정리 — 안전한 표현

확정적으로 쓸 수 있는 문장: "Zcash Orchard 회로에는 under-constrained element가 있었고, 이로 인해 elliptic curve multiplication check에 false input을 넣어도 통과할 수 있었다. Taylor Hornby는 Opus 4.8 도움으로 이를 발견했고, 로컬 regtest에서 무제한·탐지 불가능한 counterfeit ZEC 생성 exploit을 검증했다." 출처: Shielded Labs 공식 설명.

조심해서 써야 하는 문장: "정확히 어떤 두 줄이 문제였다", "x2 - x1 != 0 제약이 빠졌다", "value commitment의 특정 항이 조작됐다" 같은 표현은 현재 공개 자료만으로 확정할 수 없다. 이런 설명은 반드시 개념적 재구성 또는 가능한 기술 모델이라고 표시해야 한다. 출처: Shielded Labs 공식 설명, halo2 Book.

시장·공급 측면에서 안전한 문장: "대규모 탈취나 공개적으로 관측 가능한 공급 이상 징후는 확인되지 않았지만, Orchard 내부에 머문 위조분의 존재 여부는 암호학적으로 확정할 수 없다." 출처: Shielded Labs 공식 설명, Bitquery, Crypto Briefing.

14. 시사점

ZK 회로에서 가장 위험한 버그는 "틀린 수식"보다 "빠진 수식"인 경우가 많다. 검증자는 명시된 제약만 확인하므로, 설계자가 빠뜨린 관계는 증명 시스템 바깥으로 사라진다. Orchard 사건은 이 원리를 실제 대규모 프라이버시 코인에서 다시 보여준 사례다.

프라이버시는 사용자를 보호하지만, 사고 후 포렌식의 한계도 만든다. Orchard 내부 위조가 실제로 있었는지 cryptography만으로 증명할 수 없다는 점은, 프라이버시 시스템이 설계 단계에서 사후 검증 가능한 경계(accounting boundary) 를 반드시 포함해야 함을 보여준다.

AI 보조 감사는 공격자와 방어자 모두에게 같은 도구가 된다. 이번에는 white-hat이 먼저 찾았지만, 앞으로는 ZK 회로·스마트컨트랙트·지갑·브릿지·거래소 인프라 모두에서 AI 기반 취약점 탐색이 기본 threat model에 포함되어야 한다.

참고 자료

Shielded Labs — The Orchard counterfeiting vulnerability and next steps (공식 설명).
Bitquery — Was Zcash counterfeited? The Orchard bug (온체인 분석).
Crypto Briefing — Zcash Orchard bug emergency upgrade.
CoinDesk — Zcash plummets ~30% as developer reveals a major bug.
Electric Coin Company (2019) — Zcash counterfeiting vulnerability successfully remediated (2018 Sprout).
The halo2 Book — Incomplete and complete addition.

지캐시 Orchard 위조 취약점 — AI가 찾아낸 4년짜리 ZK 회로 결함 심층 분석

댓글