BitVM 스타일 브리지용 TEE 검증 도구: 기존 방식을 통합
레이블 배포 문제
배경 설명: 저희는 BitVM급 브리지를 갖춘 비트코인(BTC) L2 서버인 Stax를 개발 중입니다. 모호성 검증 전용 보호 기능은 Signet에서 이미 제공되고 있습니다.
2026년 4월 23일 기준으로, 저희는 현재 3단계에 대한 고정 거짓말 방어 전략을 설계하고 있습니다. 설계 과정을 진행하면서 다음과 같은 틀에 도달했습니다.
— 면밀한 검토를 견뎌낸다면 — 온체인 메커니즘의 전체 유형(강제 공개 탭루트 리프, Σ-응답, 라벨)을 제거합니다.
유통 채널). §6에 있는 7가지 질문에 대해 암호학자의 검토를 거친 후에야 확정할 수 있습니다.
이 글에서는 문제점, 관점의 변화, 그리고 다른 사람의 의견을 구하고 싶은 7가지 질문을 요약했습니다. 전체 디자인 문서는 다음 링크에서 확인할 수 있습니다.
맨 끝에 링크가 있습니다.
- 표준 BitVM급 브리지 모델에서의 문제점
표준 BitVM 방식 출금 절차:
운영자는 인출 시점의 L2 상태를 주장하는 AssertTx를 게시하여 램포트 역상을 비트 단위로 공개합니다.
CSV 타이머.
감시탑은 CSV 기간 동안 DisprovalTx를 게시하여 보증금을 대폭 삭감할 수 있습니다. 여기에는 두 가지 공격 유형이 중요합니다.
(a) 모호성 — 운영자가 동일한 Lamport 위치에서 서로 충돌하는 비츠(Bits) 가진 두 개의 AssertTx를 게시합니다.
(b) 고정된 거짓 — 연산자는 주장된 상태가 정규 L2 기록과 일치하지 않는 AssertTx 하나를 게시합니다.
애매모호함은 간단하며 BitVM2/Citrea/Bitlayer가 현재 제공하는 기능입니다. 한 위치에서 서로 상충되는 두 가지 결과가 나타나면 하나의 결과가 나옵니다.
감시탑은 램포트의 두 가지 예상을 모두 보여주며, 이는 유대감을 크게 줄입니다.
Fixed-lie는 해결되지 않은 문제입니다. 배포된 BitVM급 브리지 중 어느 것도 이를 반증할 온체인 경로를 가지고 있지 않습니다. 일반적인 가정은 "만약"입니다.
운영자는 AssertTx를 하나만 게시하는데, 이는 거짓이며 오프체인 메커니즘(알림, 소셜)이 이를 처리합니다. 이 글은 이러한 오해를 바로잡기 위한 것입니다.
격차. 단순한 입금-시간 키 쌍 흐름은 다음과 같습니다.
s_i^b = SHA256(“op-secret” || withdrawal_id || i || b)
즉, 연산자는 자체적으로 람포트 역상을 생성합니다. 연산자는 모든 비트(Bit) 위치에서 두 역상을 모두 알고 있습니다. 따라서 연산자는
어떤 비트(Bit) 패턴이든 참이든 거짓이든 주장하는 AssertTx를 구성하면 스크립트 검증기가 이를 수락합니다. 온체인 메커니즘에는 이러한 기능이 없습니다.
정식 구성 비츠(Bits) 무엇이어야 하는지에 대한 독립적인 참조 자료입니다.
기존 문헌에서는 강제적인 연결 해제(예: Σ-프로토콜 방식의 챌린지-응답 연결 해제는 운영자를 공개 정규 와이어에 묶는다)에 대해 다루고 있습니다.
레이블 테이블)은 모두 정규 레이블이 연산자 외부의 어딘가에서 온다고 가정합니다. 일반적으로 권장되는 방법은 다자간 협업입니다.
DKG 인증 절차 또는 신뢰할 수 있는 설정. 분석 결과, 우리가 검토한 온체인 강제 인증 변형(공개 키 확장, 별도 인증) 중 어느 것도 효과가 없었습니다.
RevealTx(CSV 게이트 반대 이미지)는 외부 레이블 생성기 없이도 문제를 해결합니다. 이에 대한 내용은 문서에 기록되어 있습니다.
별도의 설계 문서입니다. forcing_mechanism_design.md의 §10.6을 참조하십시오.
그렇다면 문제는 다음과 같습니다. 공식 라벨은 어디에서 오는 것이며, 누가 그것을 볼 수 있을까요?
2. 라벨 생성기로서의 TEE에 대한 두 가지 관점
저희는 1인 팀으로서의 실행 가능성을 고려하여, 여러 업체가 참여하는 계약 대신 TEE(AWS Nitro Enclaves를 기본 플랫폼으로 사용)를 선택했습니다.
TEE에 커밋하는 경우 두 가지 API 설계가 가능합니다. API 선택에 따라 전체 온체인 흔적이 결정됩니다.
2.1 TEE-as-Garbler (우리가 처음 시작했던 틀)
TEE.generate_circuit(vk) → (commitment_C, label_table T = {(L_i^0, L_i^1)})
TEE.attest() → AttestedCommitment(C, code_hash, public_seed, …)
그러면 라벨은 어딘가로 흘러가야 합니다. 감시탑으로 말이죠. 그러면 감시탑은 거짓말을 감지했을 때 강제로 드러내는 주근 잎을 사용할 수 있습니다.
AssertTx. 여기서 어려운 하위 문제가 발생합니다. 운영자에게 레이블을 유출하지 않고 감시탑에 레이블을 배포하는 방법은 무엇일까요?
비허가형(Permissionless) 감시탑을 운영할 수 있으므로 누구나 라벨을 소지할 수 있습니다. 심지어 양말을 통해 운영자도 라벨을 소지할 수 있습니다.
꼭두각시 감시탑. 명확한 답은 없습니다.
TEE를 가블러로 사용하는 경우 다음 사항도 필요합니다: Taproot 트리의 강제 공개 리프, AssertTx witness의 Σ-응답 생성, 워치타워
분쟁 해결 코드는 나뭇잎, 신호 배관 및 라벨 유통 채널 자체에 사용됩니다. 이것이 대부분입니다.
강제 메커니즘 설계.md 마일스톤 B 및 C.
2.2 TEE를 검증 도구로 활용하기 (우리가 제안하는 프레임워크)
TEE.generate_keypair_for_withdrawal(withdrawal_id) -> Lamport 공개 키(47KB), 인증
TEE.release_preimages(withdrawal_id, claimed_state s, claimed_proof π)
→ { s_i^{bit_i(public_inputs(s))} } Groth16Verify(vk, ., π)가 유효한 경우
그렇지 않으면 "유효하지 않음" 오류가 발생합니다.
TEE는 가블러이자 검증기입니다. 연산자의 유일한 API는 "이 증명을 검증하고 공개 입력에 대한 역상을 제공해 주세요"입니다.
결정적으로:
TEE는 비트(Bit) 위치당 하나의 역상만 공개합니다. 이는 주장된 상태의 공개 입력의 비트(Bit) 값과 일치하는 역상입니다.
TEE는 어떤 위치에서도 다른 역상을 내보내지 않습니다.
TEE는 주장된 적이 없는 상태와 연결된 프리이미지를 절대 내보내지 않습니다.
고정 거짓 공격은 다음과 같이 요약됩니다. 경로 발생 과정 A: 운영자가 (거짓 상태, 가비지 증명)을 제출하고 TEE Groth16Verify를 호출합니다. → 무효 → 거부 → 운영자가 역상을 가지고 있지 않음 B: 운영자가 (진실 상태, 유효한 증명)을 제출하고 TEE가 참인 역상을 반환합니다. → AssertTx가 진실을 주장하고 거짓이 발생하지 않았음을 확인합니다. C: 운영자가 거짓 상태에 대한 Groth16 증명을 위조합니다. 결과적으로 Groth16 건전성 문제로 귀결됩니다. 이는 L2가 이미 신뢰하는 것과 동일한 가정입니다.
그 거짓말은 애초에 비트코인에 도달할 수 없습니다. 비트코인 체인상에 그 거짓말을 포착하고 강제로 삭제하는 방식으로 차단할 수 있는 요소가 전혀 없기 때문입니다.
2.3 이로 인해 온체인 구성 요소 TEE-as-Garbler, TEE-as-Verifier, 강제 공개 Taproot, 제거된 AssertTx Σ-응답, 제거된 Watchtower, 제거된 강제 공개 분쟁 해결사, 제거된 정규 레이블 배포 채널(미해결 문제), 제거된 Σ-프로토콜 변형을 위한 비콘 배관, 제거된 Equivocation Lamport는 변경되지 않음, 변경되지 않음, TEE 증명 인프라 필요, 브리지 계약의 registerGarblerAttestation 필요, 필요
TEE를 검증 도구로 사용하는 감시탑에는 다음만 필요합니다: TEE 증명 다이제스트 일치, AssertTx 감지, 모호성 감지(기존 기능).
또한, TEE 손상에 대한 명확한 시나리오를 위한 오프체인 경고 경로가 있습니다.
3. TEE를 검증 도구로 사용하는 경우 강제 공개 잎이 퇴화 기관이라고 생각하는 이유
원래 Σ-프로토콜 설계의 강제 공개 리프( phase3_tee_secrecy.md §3.1 참조)를 유지하더라도 TEE에서는
타협 없는 시나리오에서 감시탑은 여전히 그 돈을 쓸 수 없습니다. 리프 스크립트는 다음과 같습니다.
OP_SHA256 <expected_hash[i]> OP_EQUALVERIFY OP_TRUE
지출을 하려면 감시탑은 expected_hash[i]의 역상이 필요합니다. TEE 모델에서 역상은 TEE 내부적입니다. 감시탑
저는 그런 것들을 가져본 적이 없습니다. 리프는 TEE와 TEE가 프리이미지를 공개한 대상(운영자)을 제외한 어떤 당사자도 사용할 수 없습니다.
forcing_mechanism_design.md §10.6에 기록된 연기 사유와 동일한 결과이지만, 행위자는 다릅니다. 방어-인
잎을 유지하기 위한 깊이 논증은 역상을 가진 행위자가 두 시나리오 모두에서 동일한 행위자이기 때문에 성립하지 않습니다.
TEE에 응한 사람).
4. 신뢰 진술, 정직성
TEE-as-Verifier 가블러 트러스트를 사용하는 3단계의 Stax 브리지:
(a) 비트코인 정직한 다수, (b) 셀레스티아 DA(운영자 보류는 2026년 4월 22일부터 종료됨), © ≥1개의 정직한 감시탑
(d) 고정 거짓 방어를 위한 Groth16 건전성, (e) TEE 공급업체 인증 체인(AWS Nitro)
기본값; 다중 공급업체 교차 인증은 3.2c 단계로 연기됨).
가정 (e)는 BitVM2 N-of-N 방식보다 엄격하게 약합니다. 우리는 명시적인 조건 하에 솔로팀 메인넷 실행 가능성을 위해 이를 수용합니다.
메인넷 종료 후, 행사가 가능해지면 해당 장치를 폐기할 계획입니다.
5. 심층 방어 체계 (3항에 반박할 경우)
검토자가 "건설 단계에서의 고정된 거짓 정보"가 충분한 방어 수단이 아니라고 판단하는 경우, 차선책은 강제 공개된 정보를 유지하고 배포하는 것입니다.
검증된 사이드 채널(각 감시탑 키로 TEE 암호화, Celestia DA를 통해 게시)을 통해 감시탑에 정규 레이블을 전송합니다.
비용: 공개 키 약 85KB, AssertTx 증명에 포함된 Σ-응답(약 3-5KB), 선택형 검증 위치당 추가 Taproot 리프 1개(원하는 건전성을 위해 선택됨, c=64일 경우 거짓이 탐지되지 않을 확률이 약 1/264임), 전체 Σ-프로토콜 분쟁 해결 도구 + 레이블 배포
채널 구현과 감시탑 키 레지스트리가 포함됩니다.
우리는 이것이 깔끔하게 구성되지 않는다고 주장합니다. 왜냐하면 누구나 감시탑을 운영할 수 있다는 것은 누구나 라벨을 가질 수 있다는 것을 의미하고, 이는 다시 붕괴되기 때문입니다.
라벨을 소지한 가짜 계정을 통해 운영자에게 전달되었지만, 우리는 이 거부에 대해 이의를 제기하고 싶습니다.
6. 암호학자의 의견이 필요한 미해결 질문
이것들은 구현 착수 전 단계의 장애물입니다. 우리는 아직 인증 인프라를 제외한 3.2b 단계 코드 작업을 시작하지 않았습니다.
(어느 관점에서 보더라도 모두 옳습니다.)
Q1 — Groth16 건전성이 유일한 고정 거짓말 방어 수단인가요? TEE 하에서 고정 거짓말 방어를 "Groth16 건전성 + TEE"로 축소하는 것인가요?
메인넷 브리지에 "인증 무결성"이 허용될까요? 지캐시(Zcash) Sapling과 파일코인(Filecoin) 모두 프로덕션 환경에서 Groth16의 건전성 검증에 의존합니다.
수십억 달러 규모의 배포 사례가 있으며, 이러한 가정은 지속적인 검토에도 불구하고 타당성이 입증되었습니다. 우리는 새로운 것을 도입하려는 것이 아닙니다.
암호화 가정 — 우리는 이 가정이 온체인 비트코인이 아닌 온체인 외부에서 검증되는 브리지 컨텍스트에서 확인되기를 원합니다.
이더리움.
Q2 — 모호성 방지를 위한 TEE 상태 유지. TEE는 내부적으로 "이미 프리이미지를 릴리스했습니다"를 추적해야 할까요?
"인출 ID X, 비트(Bit) 패턴 P"에서 동일한 인출에 대해 두 번째 패턴을 제공하지 않는 것입니까? 그렇다면 이는 방지 조치입니다.
탐지보다는 모호함에 가깝고, 램포트가 남긴 모호함은 완전히 무시될 수 있다. 즉, 3단계를 "TEE"로 통합하는 것이다.
증명할 뿐, 그 이상도 이하도 아닙니다. 비용: TEE는 상태를 영구적으로 유지해야 합니다(Nitro KMS 또는 AMD SEV-SNP와 동등). 여러 항목 간의 경쟁 조건
TEE 인스턴스는 처리가 필요합니다(Q4 참조).
Q3 — TEE-운영자 채널 암호화. TEE가 역상을 반환할 때, 운영자와의 채널은 암호화되어야 합니다.
(그렇지 않으면 수동적인 도청자가 AssertTx를 게시할 수 있는 권한을 얻게 됩니다.) 표준 답변: 인클레이브 인증 TLS - 임시 키 쌍
인클레이브 내부에서 생성된 증명 문서는 TLS 공개 키를 코드 해시에 바인딩하고, 운영자는 해당 증명을 인증합니다.
증명 자료를 보내기 전에요. BitVM 환경에 특정한 미묘한 차이점(예: TEE 재시작 시 세션 재생)을 놓치고 있는 건 아닐까요?
TEE 업그레이드 중 키 로테이션, 어떤 세션이 어떤 프리이미지를 받았는지에 대해 거짓말을 하는 운영자?
4분기 — TEE 복제를 통한 Liveness. 단일 TEE는 브리지 Liveness 에 있어 단일 장애점(SPOF)이 됩니다. 여러 TEE 인스턴스(동일한 code_hash, 동일한 코드 해시)를 사용하면 활성 보장이 강화됩니다.
master_seed는 충돌하는 상태에 대한 프리이미지를 방출하지 않도록 조정 프로토콜이 필요합니다. "결정론적 마스터 시드"란 무엇일까요?
N개의 TEE에 걸쳐 인스턴스별 상태 로그와 "먼저 응답한 쪽이 우선"하는 안전한 방식이 될까요, 아니면 공격자가 악용할 수 있는 경쟁 조건이 발생할까요? 구체적으로 말하자면,
인스턴스 A는 시간 t에 상태 P에 대한 역상을 공개하고, 인스턴스 B는 A의 상태보다 t+ε 이전 시간 t+ε에 상태 P'(P' ≠ P)에 대한 역상을 공개합니다.
로그 복제본의 경우, 운영자가 특정 비트(Bit) 위치에서 두 부분 모두를 전달받은 것입니까?
5분기 — 활성 예치금이 있는 TEE 업그레이드. 새로운 가블러 바이너리(다른 code_hash)를 배포하는 경우, 기존에 커밋된 예치금은 그대로 유지됩니다.
(a) 기존 TEE 바이너리가 무기한으로 작동 가능한 상태로 유지되거나, (b) 마이그레이션 경로가 제공되지 않는 한 기존 공개 키는 그대로 유지됩니다.
(예: 협력적 환불 흐름 후 새 코드 해시로 재입금). TEE를 사용하는 교량 설계에서 표준 패턴은 무엇입니까? (a)
6~12개월 보증금 유지 기간에 적합한가요? (b)는 "소유자 주도 마이그레이션 기간"보다 더 깔끔한 메커니즘을 가지고 있나요?
Q6 — 출금 건별 인증 주기 vs 일괄 인증 주기. 온체인 인증 다이제스트에는 (코드 해시, 공개 시드,
output_hash). 만약 output_hash가 하나의 출금에 대한 공개 키 커밋먼트라면, 모든 출금에는 각각 고유한 온체인 다이제스트가 필요합니다.
등록 방식은 규모가 커질수록 비용이 많이 듭니다. 배치 단위 방식은 집계는 되지만 세부적인 정보가 손실됩니다. 에포크 단위 방식은 가장 저렴하지만 비용이 증가합니다.
어떤 인출이 어떤 증명에 해당하는지에 대한 질문입니다. 적절한 세분화 수준은 어느 정도이며, 오류 발생 시 대처 방법은 무엇일까요?
뭔가 잘못 생각하고 있는 건가요?
Q7 — 강제로 공개되는 나뭇잎이 유용할까요? 이 글의 3절에서는 감시탑이 라벨을 가지고 있다는 것은…
운영자가 소셜 미디어 계정을 통해 레이블을 보유합니다( 비허가형(Permissionless) 감시탑 집합에서). 강제적인 위협 모델을 구축할 수 있다면,
리빌 리프가 오프체인 알림 및 인증 취소로는 제공하지 못하는 상당한 수준의 심층 방어 기능을 제공한다는 점에 대해 듣고 싶습니다.
이는 우리를 제5조의 대안으로 몰아넣을 것입니다.
7. 우리가 요구하는 것
정식 감사는 아닙니다(그건 나중에 4단계 지출 항목에 포함됩니다). 지금 우리가 원하는 것은 다음과 같습니다.
질문 1에 대한 현실적인 점검 - 4절의 신뢰 진술은 진실된 것인가, 아니면 무언가를 얼버무리고 있는 것인가?
Q2에 대한 두 번째 의견 — TEE 상태 유지 기능이 모호성 탐지 기능을 진정으로 포함하는가, 아니면 TEE의 특수한 경우에만 포함되는가?
국가 부패/복구 정책이 다시 문을 열 것인가?
4분기/5분기에 AWS Nitro Enclave를 실제로 사용해 보신 분들, 설계 단계에서는 나타나지 않지만 실제 운영 환경에서 어떤 문제가 발생하는지 알려주시면 감사하겠습니다.
문서요?
만약 모든 답변이 "괜찮습니다"라는 만장일치로 나오면 약 1주일 안에 3.2b 단계를 시작합니다. 만약 답변 중 하나라도 질문이 나온다면,
취약점이 드러나면 §5에 따라 대체 방안을 실행하거나 아키텍처를 재설계합니다.
8. 링크
이 게시물에서 요약한 전체 설계 문서는 docs/phase3_tee_secrecy.md (~530줄)에서 확인할 수 있습니다.
관련 항목: docs/phase3_tee_design.md (TEE 플랫폼 선택, 위협 모델)
원래 문제 설명: docs/forcing_mechanism_design.md §10.6
Bridge는 Bitcoin Signet에서 실행됩니다(2026년 4월 22일부터 서비스 중). TESTNET.md에는 모호성 처리 및 DisprovalTx 흐름, Celestia가 기록되어 있습니다.
DA 엄격 모드 거부 및 각 거래에 대한 구체적인 시그넷 거래 해시를 포함한 정직한 예치/ 민트(Mint).
댓글과 DM 환영합니다. 기술적인 답변은 Ethresearch 스레드에 남겨주시고, 실질적인 피드백은 별도로 안내해 드리겠습니다.
출처를 명시하여 문서에 삽입하세요.
