블록체인에서의 프로그래밍 가능한 프라이버시: 오프체인 컴퓨팅과 온체인 검증
퍼블릭 블록체인은 프라이버시를 희생하여 투명성과 무결성을 제공합니다. 모든 트랜잭션과 컨트랙트 상태가 모든 참여자에게 노출됩니다. 이러한 개방성은 MEV (채굴자 추출 가능 가치) 공격, 카피 트레이딩, 민감한 비즈니스 로직 유출과 같은 문제를 야기합니다. 프로그래밍 가능한 프라이버시는 데이터 자체를 노출하지 않고 개인 데이터에 대한 계산을 허용함으로써 이러한 문제를 해결하는 것을 목표로 합니다. 두 가지 새로운 암호학 패러다임이 이를 가능하게 하고 있습니다: **완전 동형 암호화 가상 머신 (FHE-VM)**과 영지식 (ZK) 코프로세서입니다. 이러한 접근 방식은 오프체인 또는 암호화된 계산과 온체인 검증을 가능하게 하여, 신뢰가 필요 없는 정확성을 유지하면서 기밀성을 보존합니다. 이 보고서에서는 FHE-VM과 ZK 코프로세서 아키텍처를 심층적으로 분석하고, 그들의 장단점을 비교 하며, 금융, 신원, 의료, 데이터 마켓, 탈중앙화 머신러닝 전반에 걸친 사용 사례를 탐구합니다.
완전 동형 암호화 가상 머신 (FHE-VM)
**완전 동형 암호화 (FHE)**는 암호화된 데이터를 복호화하지 않고도 임의의 계산을 수행할 수 있게 합니다. FHE 가상 머신은 이 기능을 블록체인 스마트 컨트랙트에 통합하여 암호화된 컨트랙트 상태 및 로직을 가능하게 합니다. FHE가 활성화된 블록체인 (EVM 호환 설계의 경우 종종 fhEVM이라고 불림)에서는 모든 입력, 컨트랙트 저장소, 출력이 실행 내내 암호화된 상태로 유지됩니다. 이는 검증자들이 민감한 값을 전혀 알지 못한 채 트랜잭션을 처리하고 상태를 업데이트할 수 있음을 의미하며, 데이터 기밀성을 갖춘 온체인 실행을 달성합니다.
FHE-VM의 아키텍처 및 설계
일반적인 FHE-VM은 표준 스마트 컨트랙트 런타임 (이더리움 가상 머신 등)을 확장하여 암호화된 데이터 유형 및 연산에 대한 네이티브 지원을 추가합니다. 예를 들어, Zama의 FHEVM은 암호화된 정수 (euint8, euint32 등), 암호화된 불리언 (ebool), 심지어 암호화된 배열을 일급 유형 으로 도입합니다. Solidity와 같은 스마트 컨트랙트 언어는 라이브러리나 새로운 옵코드를 통해 증강되어 개발자들이 암호문에 대해 직접 산술 (add, mul 등), 논리 연산, 비교를 수행할 수 있게 합니다. 내부적으로 이러한 연산은 FHE 프리미티브 (예: TFHE 라이브러리 사용)를 호출하여 암호화된 비트를 조작하고 암호화된 결과를 생성합니다.
암호화된 상태 저장소가 지원되어 컨트랙트 변수가 블록체인 상태에서 암호화된 채로 유지됩니다. 실행 흐름은 일반적으로 다음과 같습니다:
- 클라이언트 측 암호화: 사용자는 트랜잭션을 보내기 전에 공개 FHE 키를 사용하여 로컬에서 입력을 암호화합니다. 암호화 키는 공개 (암호화 및 평가용)이며, 복호화 키는 비밀로 유지됩니다. 일부 설계에서는 각 사용자가 자신의 키를 관리하고, 다른 설계에서는 단일 전역 FHE 키가 사용됩니다 (아래에서 논의).
- 온체인 동형 계산: 채굴자/검증자는 암호화된 옵코드로 컨트랙트를 실행합니다. 그들은 암호문에 대해 동일한 결정론적 동형 연산을 수행하므로, 암호화된 새로운 상태에 대한 합의에 도달할 수 있습니다. 결정적으로, 검증자들은 평문 데이터를 절대 보지 못합니다. 그들은 단지 "알 수 없는" 암호문만 보지만 여전히 일관되게 처리할 수 있습니다.
- 복호화 (선택 사항): 결과를 공개하거나 오프체인에서 사용해야 하는 경우, 개인 키를 가진 승인된 당사자가 출력 암호문을 복호화할 수 있습니다. 그렇지 않으면 결과는 암호화된 상태로 유지되며 추가 트랜잭션의 입력으로 사용될 수 있습니다 (영구적인 암호화 상태에 대한 연속적인 계산 허용).
주요 설계 고려 사항은 키 관리입니다. 한 가지 접근 방식은 사용자별 키로, 각 사용자가 자신의 비밀 키를 보유하고 자신과 관련된 출력만 복호화할 수 있습니다. 이는 프라이버시를 극대화하지만 (다른 누구도 당신의 데이터를 복호화할 수 없음), 동형 연산은 복잡한 다중 키 프로토콜 없이는 다른 키로 암호화된 데이터를 혼합할 수 없습니다. Zama의 FHEVM에서 사용하는 또 다른 접근 방식은 전역 FHE 키입니다: 단일 공개 키가 모든 컨트랙트 데이터를 암호화하고, 분산된 검증자 집합이 임계값 복호화 키의 지분을 보유합니다. 공개 암호화 및 평가 키는 온체인에 게시되므로 누구나 네트워크에 데이터를 암호화할 수 있습니다. 개인 키는 검증자들 사이에 분할되어 임계값 체계 하에 필요할 경우 공동으로 복호화할 수 있습니다. 검증자 공모로 인한 프라이버시 침해를 방지하기 위해, Zama는 부분 복호화를 안전하게 만들기 위한 "노이즈 플러딩"을 포함한 임계값 FHE 프로토콜 (그들의 Noah’s Ark 연구 기반)을 사용합니다. 충분한 정족수의 검증자가 협력해야만 평문을 복구할 수 있습니다 (예: 읽기 요청 처리). 그러나 정상적인 작동에서는 어떤 단일 노드도 평문을 보지 못하며, 데이터는 항상 온체인에서 암호화된 상태로 유지됩니다.
접근 제어는 또 다른 중요한 구성 요소입니다. FHE-VM 구현에는 누가 (만약 있다면) 복호화를 트리거하거나 특정 암호화된 필드에 접근할 수 있는지 관리하기 위한 세분화된 제어가 포함됩니다. 예를 들어, Cypher의 fhEVM은 암호문에 대한 접근 제어 목록 (ACL)을 지원하여 개발자가 어떤 주소나 컨트랙트가 특정 데 이터와 상호 작용하거나 재암호화할 수 있는지 지정할 수 있게 합니다. 일부 프레임워크는 재암호화를 지원합니다: 평문을 노출하지 않고 한 사용자의 키에서 다른 사용자의 키로 암호화된 값을 전송하는 기능입니다. 이는 데이터 마켓플레이스와 같은 곳에서 유용합니다. 데이터 소유자는 자신의 키로 데이터셋을 암호화하고, 구매 시 구매자의 키로 재암호화할 수 있습니다. 이 모든 것이 공개적으로 복호화되지 않고 온체인에서 이루어집니다.
정확성 및 프라이버시 보장
모든 데이터가 암호화되어 있다면, 어떻게 컨트랙트 로직의 정확성을 강제할 수 있을까요? 체인이 값을 "볼" 수 없다면 어떻게 유효하지 않은 연산을 막을 수 있을까요? FHE 자체는 정확성 증명을 제공하지 않습니다. 검증자들은 동형 단계를 수행할 수 있지만, 복호화 없이는 사용자의 암호화된 입력이 유효했는지 또는 조건부 분기를 취해야 하는지 등을 본질적으로 알 수 없습니다. **영지식 증명 (ZKP)**은 이 격차를 해결하기 위해 FHE를 보완할 수 있습니다. FHE-VM에서는 일반적으로 사용자가 필요할 때마다 특정 평문 조건에 대한 ZK 증명을 제공해야 합니다. 예를 들어, Zama의 설계는 각 암호화된 입력과 함께 _평문 지식의 영지식 증명 (ZKPoK)_을 사용합니다. 이는 사용자가 자신의 암호문에 해당하는 평문을 알고 있으며, 그것이 예상 기준을 충족함을 평문 자체를 드러내지 않고 증명합 니다. 이러한 **"인증된 암호문"**은 악의적인 사용자가 잘못된 형식의 암호화나 범위를 벗어난 값을 제출하는 것을 방지합니다. 마찬가지로, 결정이 필요한 연산 (예: 계정 잔액 ≥ 인출 금액 확인)의 경우, 사용자는 암호화된 연산이 실행되기 전에 평문에 대해 이 조건이 참임을 증명하는 ZK 증명을 제공할 수 있습니다. 이런 방식으로, 체인은 값을 복호화하거나 보지 않지만, 암호화된 트랜잭션이 규칙을 따른다는 확신을 얻습니다.
FHE 롤업의 또 다른 접근 방식은 ZKP를 사용한 오프체인 검증입니다. Fhenix (FHE를 사용하는 L2 롤업)는 _임계값 서비스 네트워크_라는 별도의 네트워크 구성 요소가 암호화된 결과를 복호화하거나 검증할 수 있는 옵티미스틱 모델을 선택했으며, 잘못된 계산은 사기 증명으로 이의를 제기할 수 있습니다. 일반적으로 FHE + ZK 또는 사기 증명을 결합하면 암호화된 실행이 신뢰가 필요 없게 유지됩니다. 검증자들은 승인된 경우에만 공동으로 복호화하거나, 각 암호화된 상태 전환이 평문을 볼 필요 없이 유효했음을 증명하는 증명을 검증합니다.
성능 고려 사항: FHE 연산은 계산적으로 매우 무겁습니다 – 일반 산술보다 수십 배 느립니다. 예를 들어, 이더리움에서 간단한 64비트 덧셈은 약 3 가스가 소요되지만, Zama의 FHEVM에서 암호화된 64비트 정수 (euint64)에 대한 덧셈은 약 188,000 가스가 듭니다. 심지어 8비트 덧셈도 약 94k 가스가 소요될 수 있습니다. 이 엄청난 오버헤드는 기존 노드에 대한 간단한 구현이 비현실적으로 느리고 비용이 많이 든다는 것을 의미합니다. FHE-VM 프로젝트는 최적화된 암호화 라이브러리 (예: Zama의 이진 게이트 부트스트래핑을 위한 TFHE-rs 라이브러리)와 성능을 위한 맞춤형 EVM 수정을 통해 이 문제를 해결합니다. 예를 들어, Cypher의 수정된 Geth 클라이언트는 새로운 옵코드를 추가하고 C++/어셈블리에서 동형 명령어 실행을 최적화하여 오버헤드를 최소화합니다. 그럼에도 불구하고, 사용 가능한 처리량을 달성하려면 가속화가 필요합니다. 진행 중인 작업에는 FHE 계산 속도를 높이기 위한 GPU, FPGA, 심지어 특수 광자 칩 사용이 포함됩니다. Zama는 2024년 이후 FHE 성능이 100배 향상되었으며 GPU/FPGA 가속을 통해 수천 TPS를 목표로 하고 있다고 보고합니다. 전용 FHE 코프로세서 서버 (예: Optalysys의 LightLocker Node)는 검증자 노드에 연결하여 암호화된 연산을 하드웨어로 오프로드하여 노드당 초당 100개 이상의 암호화된 ERC-20 전송을 지원할 수 있습니다. 하드웨어와 알고리즘이 개선됨에 따라 FHE와 일반 계산 간의 격차는 좁혀져, 개인 컨트랙트가 더 실용적인 속도에 접근할 수 있게 될 것입니다.
호환성: FHE-VM 설계의 핵심 목표는 기존 개발 워크플로우와의 호환성을 유지하는 것입니다. Cypher와 Zama의 fhEVM 구현은 개발자가 최소한의 변경으로 Solidity에서 컨트랙트를 작성할 수 있게 합니다 – 라이브러리를 사용하여 암호화된 유형과 연산을 선언합니다. 나머지 이더리움 툴체인 (Remix, Hardhat 등)은 기본 수정이 대부분 클라이언트/노드 수준에 있기 때문에 여전히 사용할 수 있습니다. 이는 진입 장벽을 낮춥니다: 개발자는 기밀 스마트 컨트랙트를 작성하기 위해 암호학 전문가가 될 필요가 없습니다. 예를 들어, 두 숫자의 간단한 덧셈은 euint32 c = a + b;로 작성할 수 있으며, FHEVM이 내부적으로 암호화 관련 세부 사항을 처리합니다. 컨트랙트는 일반 컨트랙트와 상호 운용될 수도 있습니다. 예를 들어, 암호화된 컨트랙트가 원하는 경우 표준 컨트랙트에 복호화된 결과를 출력하여 하나의 생태계에서 개인 부분과 공용 부분을 혼합할 수 있습니다.
현재 FHE-VM 프로젝트: 여러 프로젝트가 이 분야를 개척하고 있습니다. Zama (파리에 본사를 둔 FHE 스타트업)는 핵심 FHEVM 개념과 라이브러리 (TFHE-rs 및 fhevm-solidity 라이브러리)를 개발했습니다. 그들은 자체 체인을 출시할 계획은 없지만, 다른 사람들에게 인프라를 제공하는 것을 목표로 합니다. Inco는 Zama의 FHEVM을 통합하여 모듈식 기밀 체인을 만든 L1 블록체인 (Cosmos SDK와 Evmos 기반)입니다. 그들의 테스트넷 (Gentry 및 Paillier)은 암호화된 ERC-20 전송 및 기타 개인 DeFi 프리미티브를 선보입니다. Fhenix는 프라이버시를 위해 FHE를 사용하는 이더리움 레이어-2 옵티미스틱 롤업입니다. 모든 블록에 대해 FHE와 ZK를 함께 수행하는 데 드는 막대한 비용 때문에 ZK 롤업 대신 옵티미스틱 (사기 증명) 접근 방식을 결정했습니다. Fhenix는 동일한 TFHE-rs 라이브러리 (일부 수정 포함)를 사용하며, 탈중앙화된 방식으로 복호화를 처리하기 위한 임계값 서비스 네트워크를 도입합니다. **Fhenix (현재 리브랜딩됨)**와 같은 독립적인 팀과 MPC + FHE 하이브리드를 탐색하는 스타트업도 있습니다. 또한, **Cypher (Z1 Labs 제작)**는 AI와 프라이버시에 초점을 맞춘 레이어-3 네트워크를 구축하고 있으며, 비밀 저장소 및 연합 학습 지원과 같은 기능을 갖춘 fhEVM을 사용합니다. 생태계는 초기 단계이지만 상당한 자금 지원을 받아 빠르게 성장하고 있습니다. 예를 들어, Zama는 FHE 기술 발전을 위해 2025년까지 1억 3천만 달러 이상을 모금하여 "유니콘"이 되었습니다.
요약하자면, FHE-VM은 온체인에서 암호화된 데이터에 대한 모든 로직을 실행함으로써 프라이버시 보존 스마트 컨트랙트를 가능하게 합니다. 이 패러다임은 최대의 기밀성을 보장합니다 – 민감한 정보는 트랜잭션이나 상태에서 절대 노출되지 않음 – 동시에 무결성을 위해 기존 블록체인 합의를 활용합니다. 단점은 검증자에 대한 계산 부담 증가와 키 관리 및 증명 통합의 복잡성입니다. 다음으로, 계산을 완전히 오프체인으로 오프로드하고 체인은 검증에만 사용하는 대안적인 패러다임인 영지식 코프로세서를 탐구합니다.
영지식 코프로세서 (ZK 코프로세서)
ZK 코프로세서는 비용이 많이 드는 계산을 오프체인에서 수행하고, 그 정확성에 대한 간결한 영지식 증명을 온체인에서 검증하는 새로운 블록체인 아키텍처 패턴입니다. 이를 통해 스마트 컨트랙트는 신뢰 불필요성을 희생하지 않고 온체인 실행이 허용하는 것보다 훨씬 더 큰 계산 능력과 데이터를 활용할 수 있습니다. _코프로세서_라는 용어는 CPU를 위해 전문적인 작업을 처리하는 하드웨어 코프로세서 (수학 코프로세서나 GPU 등)에 비유하여 사용됩니다. 여기서 블록체인의 "CPU" (EVM과 같은 네이티브 VM)는 특정 작업을 암호학적 코프로세서 역할을 하는 영지식 증명 시스템에 위임합니다. ZK 코프로세서는 결과와 함께 결과가 올바르게 계산되었음을 증명하는 증명을 반환하며, 온체인 컨트랙트는 이를 검증하고 사용할 수 있습니다.
아키텍처 및 워크플로우
일반적인 설정에서, dApp 개발자는 애플리케이션 로직 중 온체인 실행에 너무 비싸거나 복잡한 부분 (예: 과거 데이터에 대한 대규모 계산, 무거운 알고리즘, ML 모델 추론 등)을 식별합니다. 그들은 해당 부분을 실행의 영지식 증명을 생성할 수 있는 오프체인 프로그램 (고급 언어 또는 회로 DSL로)으로 구현합니다. 온체인 구성 요소는 증명을 확인하고 결과를 시스템의 나머지 부분에서 사용할 수 있도록 하는 검증자 스마트 컨트랙트입니다. 흐름은 다음과 같이 요약할 수 있습니다:
- 요청 – 온체인 컨트랙트가 특정 계산을 오프체인에서 수행하도록 요청을 트리거합니다. 이는 사용자 트랜잭션에 의해 시작되거나 한 컨트랙트가 ZK 코프로세서의 인터페이스를 호출하여 시작될 수 있습니다. 예를 들어, DeFi 컨트랙트는 _“proveInterestRate(currentState)”_를 호출하거나 사용자는 _“queryHistoricalData(query)”_를 호출할 수 있습니다.
- 오프체인 실행 및 증명 – 오프체인 서비스 (설계에 따라 탈중앙화된 증명자 네트워크 또는 신뢰할 수 있는 서비스일 수 있음)가 요청을 받습니다. 필요한 데이터 (온체인 상태, 오프체인 입력 등)를 수집하고 특 수 ZK 가상 머신 (ZKVM) 또는 회로에서 계산을 실행합니다. 실행 중에 증명 추적이 생성됩니다. 마지막으로, 서비스는 _“입력 X에 대해 함수 F를 계산하면 출력 Y가 나온다”_는 것을 증명하는 간결한 증명 (예: SNARK 또는 STARK)을 생성하고, 선택적으로 데이터 무결성을 증명합니다 (자세한 내용은 아래 참조).
- 온체인 검증 – 증명과 결과는 블록체인으로 반환됩니다 (종종 콜백 함수를 통해). 검증자 컨트랙트는 효율적인 암호학적 검증 (페어링 검사 등)을 사용하여 증명의 유효성을 확인합니다. 유효하다면, 컨트랙트는 이제 출력 Y를 올바른 것으로 신뢰할 수 있습니다. 결과는 상태에 저장되거나, 이벤트로 발생하거나, 추가 컨트랙트 로직에 입력될 수 있습니다. 증명이 유효하지 않거나 일정 시간 내에 제공되지 않으면 요청은 실패한 것으로 간주될 수 있습니다 (그리고 잠재적으로 일부 폴백 또는 타임아웃 로직이 트리거됨).
그림 1: ZK 코프로세서의 아키텍처 (RISC Zero Bonsai 예시). 오프체인에서 프로그램은 스마트 컨트랙트 호출의 입력을 받아 ZKVM에서 실행됩니다. 실행 증명은 릴레이 컨트랙트를 통해 온체인으로 반환되며, 이는 검증된 결과와 함께 콜백을 호출합니다.
결정적으로, 검증에 대한 온체인 가스 비용은 오프체인 계산이 얼마나 복잡했는지에 관계없이 일정하거나 매우 느리게 증가합니다. 간결한 증명을 검증하는 데는 수십만 가스 (이더리움 블록의 일부) 정도가 들 수 있지만, 그 증명은 오프체인에서 수행된 수백만 개의 계산 단계를 나타낼 수 있습니다. 한 개발자가 말했듯이, “디지털 서명 하나를 증명하고 싶나요? 약 15달러입니다. 백만 개의 서명을 증명하고 싶나요? 그것도 약 15달러입니다.”. 이 확장성은 큰 이점입니다: dApp은 블록체인을 막지 않고 복잡한 기능 (빅데이터 분석, 정교한 금융 모델 등)을 제공할 수 있습니다.
ZK 코프로세서 시스템의 주요 구성 요소는 다음과 같습니다:
-
증명 생성 환경: 이는 범용 ZKVM (임의의 프로그램을 실행할 수 있음) 또는 특정 계산에 맞춰진 맞춤형 회로일 수 있습니다. 접근 방식은 다양합니다:
- 일부 프로젝트는 지원되는 각 쿼리 또는 기능에 대해 수작업으로 만든 회로를 사용합니다 (해당 기능에 대한 효율성 극대화).
- 다른 프로젝트는 개발자가 오프체인 로직을 작성하는 데 사용하는 도메인 특화 언어 (DSL) 또는 임베디드 DSL을 제공하며, 이는 회로로 컴파일됩니다 (사용 용이성과 성능의 균형).
- 가장 유연한 접근 방식은 zkVM입니다: 프로그램이 표준 언어 (Rust, C 등)로 작성되고 자동으로 증명될 수 있는 가상 머신 (종종 RISC 아키텍처 기반)입니다. 이는 성능을 희생하는 대신 (회로에서 CPU를 시뮬레이션하면 오버헤드가 추가됨) _최대의 개발자 경험_을 제공합니다.
-
데이터 접근 및 무결성: 독특한 과제는 오프체인 계산에 올바른 데이터를 제공하는 것인데, 특히 해당 데이터가 블록체인 (과거 블록, 컨트랙트 상태 등)에 있는 경우입니다. 순진한 해결책은 증명자가 아카이브 노드에서 읽고 그것을 _신뢰_하게 하는 것이지만, 이는 신뢰 가정을 도입합니다. 대신 ZK 코프로세서는 일반적으로 머클 증명이나 상태 커밋먼트에 연결하여 사용된 온체인 데이터가 실제로 진짜였음을 증명합니다. 예를 들어, 쿼리 프로그램은 블록 번호와 저장소 슬롯 또는 트랜잭션의 머클 증명을 가져올 수 있으며, 회로는 알려진 블록 헤더 해시에 대해 해당 증명을 검증합니다. 세 가지 패턴이 존재합니다:
- 인라인 데이터: 필요한 데이터를 온체인에 (검증자의 입력으로) 넣어 직접 확인할 수 있게 합니다. 이는 대용량 데이터에 대해 매우 비용이 많이 들고 전체적인 목적을 훼손합니다.
- 오라클 신뢰: 오라클 서비스가 증명에 데이터를 제공하고 보증하게 합니다. 이는 더 간단하지만 제3자에 대한 신뢰를 다시 도입합니다.
- ZK를 통한 데이터 포함 증명: 체인 기록에 데이터가 포함되었음을 증명하는 것을 영지식 회로 자체에 통합합니다. 이는 각 이더리움 블록 헤더가 전체 이전 상태 (상태 루트를 통해)와 트랜잭션 기록에 커밋한다는 사실을 활용합니다. 회로 내에서 데이터의 머클 패트리샤 증명을 검증함으로써, 출력 증명은 컨트랙트에게 _“이 계산은 블록 N의 진짜 블록체인 데이터를 사용했다”_는 것을 추가적인 신뢰 없이 보증합니다.
세 번째 접근 방식이 가장 신뢰가 필요 없으며 Axiom 및 Xpansion과 같은 고급 ZK 코프로세서에서 사용됩니다 (증명 비용은 증가하지만 보안상 선호됨). 예를 들어, Axiom의 시스템은 이더리움의 블록 구조, 상태 트라이, 트랜잭션 트라이를 회로 내에 모델링하여 “계정
X는 블록N에서 잔액Y를 가졌다” 또는 _“특정 속성을 가진 트랜잭션이 블록 N에서 발생했다”_와 같은 진술을 증명할 수 있습니다. 이는 최근의 신뢰할 수 있는 블록 해시가 주어지면, 외부 당사자를 신뢰하지 않고 도 과거 데이터의 포함을 재귀적으로 증명할 수 있다는 사실을 활용합니다. -
검증자 컨트랙트: 이 온체인 컨트랙트는 증명을 수락하거나 거부하는 검증 키와 로직을 포함합니다. Groth16 또는 PLONK와 같은 SNARK의 경우, 검증자는 몇 가지 타원 곡선 페어링을 수행할 수 있습니다. STARK의 경우, 일부 해시 계산을 수행할 수 있습니다. 집계 및 재귀와 같은 성능 최적화는 온체인 부하를 최소화할 수 있습니다. 예를 들어, RISC Zero의 Bonsai는 STARK-to-SNARK 래퍼를 사용합니다: 속도를 위해 오프체인에서 STARK 기반 VM을 실행한 다음, STARK의 유효성을 증명하는 작은 SNARK 증명을 생성합니다. 이는 증명 크기를 수백 킬로바이트에서 수백 바이트로 줄여 온체인 검증을 실현 가능하고 저렴하게 만듭니다. Solidity 검증자는 SNARK만 확인하면 됩니다 (이는 상수 시간 연산임).
배포 측면에서, ZK 코프로세서는 레이어-2와 유사한 네트워크 또는 순수 오프체인 서비스로 기능할 수 있습니다. Axiom과 같은 일부는 이더리움에 특화된 서비스로 시작하여 (Paradigm의 지원을 받아) 개발자가 Axiom의 증명자 네트워크에 쿼리를 제출하고 온체인에서 증명을 받습니다. Axiom의 슬로건은 이더리움 컨트랙트에 _“모든 온체인 데이터에 대한 신뢰 없는 접근과 그에 대한 임의의 표현력 있는 계산”_을 제공하는 것이었습니다. 이는 답변이 신뢰 대신 ZKP에 의해 검증되는 쿼리 오라클 역할을 효과적으로 수행합니다. RISC Zero의 Bonsai와 같은 다른 것들은 더 개방적인 플랫폼을 제공합니다: 모든 개발자는 프로그램 (RISC-V 호환 ZKVM으로 컴파일됨)을 업로드하고 릴레이 컨트랙트를 통해 Bonsai의 증 명 서비스를 사용할 수 있습니다. 그림 1에 설명된 릴레이 패턴은 요청과 응답을 중재하는 컨트랙트를 포함합니다: dApp 컨트랙트는 릴레이를 호출하여 증명을 요청하고, 오프체인 서비스는 이를 수신하여 (예: 이벤트 또는 직접 호출을 통해) 증명을 계산한 다음, 릴레이는 결과와 증명과 함께 dApp 컨트랙트의 콜백 함수를 호출합니다. 이 비동기 모델은 증명에 복잡성에 따라 수 초에서 수 분이 걸릴 수 있기 때문에 필요합니다. 이는 지연 시간 (그리고 증명자가 응답할 것이라는 활성 가정)을 도입하는 반면, FHE-VM 계산은 블록 내에서 동기적으로 발생합니다. 이 비동기 워크플로우를 처리하도록 애플리케이션을 설계하는 것 (아마도 오라클 응답과 유사하게)은 ZK 코프로세서를 사용하는 것의 일부입니다.
주목할 만한 ZK 코프로세서 프로젝트
-
Axiom: Axiom은 이더리움에 맞춰진 ZK 코프로세서로, 원래 과거 온체인 데이터 쿼리를 증명하는 데 중점을 두었습니다. Halo2 증명 프레임워크 (Plonk 계열 SNARK)를 사용하여 이더리움의 암호학적 구조를 통합한 증명을 생성합니다. Axiom의 시스템에서 개발자는 _“블록 N에서 컨트랙트 X의 상태는 무엇이었는가?”_와 같은 것을 쿼리하거나 특정 범위의 모든 트랜잭션에 대한 계산을 수행할 수 있습니다. 내부적으로 Axiom의 회로는 이더리움의 상태/트라이 로직을 구현해야 했으며, 재귀를 지원하기 위해 회로 내에서 타원 곡선 연산과 SNARK 검증까지 수행했습니다. Trail of Bits는 감사에서 Axiom의 Halo2 회로가 전체 블록과 상태를 모델링하는 복잡성을 언급했습니다. 감사 후, Axiom은 기술을 OpenVM으로 일반화하여 동일한 Halo2 기반 인프라로 임의의 Rust 코드를 증명할 수 있게 했습니다. (이는 도메인 특화 회로에서 더 일반적인 ZKVM 접근 방식으로 이동하는 추세를 반영합니다.) Axiom 팀은 이더리움이 네이티브로 할 수 없는 ZK 쿼리를 시연하여, 암호학적 무결성을 갖춘 모든 과거 데이터에 대한 _상태 비저장 접근_을 가능하게 했습니다. 그들은 또한 보안을 강조하여, 제약 조건이 부족한 회로 버그를 찾아 수정하고 건전성을 보장했습니다. Axiom의 초기 제품은 피봇 중에 중단되었지만, 그들의 접근 방식은 ZK 코프로세서의 랜드마크로 남아 있습니다.
-
RISC Zero Bonsai: RISC Zero는 RISC-V 아키텍처 기반의 ZKVM입니다. 그들의 zkVM은 임의의 프로그램 (Rust, C++ 및 RISC-V로 컴파일된 기타 언어로 작성됨)을 실행하고 실행의 STARK 증명을 생성할 수 있습니다. Bonsai는 이 증명을 온디맨드로 제공하는 RISC Zero의 클라우드 서비스로, 스마트 컨트랙트의 코프로세서 역할을 합니다. 이를 사용하려면 개발자는 프로그램 (예: 복잡한 수학을 수행하거나 오프체인 API 응답을 검증하는 함수)을 작성하고, Bonsai 서비스에 업로드하고, 해당 검증자 컨트랙트를 배포합니다. 컨트랙트가 해당 계산을 필요로 할 때, Bonsai 릴레이를 호출하여 증명 생성을 트리거하고 콜백을 통해 결과를 반환합니다. 시연된 한 가지 예시 애플리케이션은 오프체인 거버넌스 계산이었습니다: RISC Zero는 DAO가 Bonsai를 사용하여 투표를 집계하고 복잡한 투표 지표를 오프체인에서 계산한 다음, 온체인 거버너 컨트랙트가 최소한의 가스 비용으로 결과를 신뢰할 수 있도록 증명을 게시하는 것을 보여주었습니다. RISC Zero의 기술은 개발자가 익숙한 프로그래밍 패러다임을 사용할 수 있다는 점을 강조합니다. 예를 들어, 무언가를 계산하는 Rust 함수를 작성하면, 회로 생성의 무거운 작업은 zkVM이 처리합니다. 그러나 증명이 클 수 있으므로, 앞서 언급했듯이 온체인 검증을 위해 SNARK 압축을 구현했습니다. 2023년 8월, 그들은 이더리움의 Sepolia 테스트넷에서 RISC Zero 증명을 성공적으로 검증했으며, 증명당 약 30만 가스가 소요되었습니다. 이는 이더리움 dApp이 확장 및 프라이버시 솔루션으로 Bonsai를 오늘날 사용할 수 있는 문을 엽니다. (Bonsai는 아직 알파 버전이며, 프로덕션 준비가 되지 않았고, 세레모니 없는 임시 SNARK 설정을 사용합니다.)
-
기타: 수많은 다른 플레이어와 연구 이니셔티브가 있습니다. Expansion/Xpansion (블로그에서 언급됨)은 임베디드 DSL 접근 방식을 사용하여 개발자가 특수 언어로 온체인 데이터에 대한 쿼리를 작성할 수 있으며, 내부적으로 증명 생성을 처리합니다. StarkWare의 Cairo와 Polygon의 zkEVM은 더 일반적인 ZK 롤업 VM이지만, 그들의 기술은 L1 컨트랙트 내에서 증명을 검증함으로써 코프로세서와 유사한 용도로 재사용될 수 있습니다. 우리는 또한 ZKML (ZK 머신러닝) 도메인의 프로젝트를 볼 수 있는데, 이는 ML 모델 추론이나 훈련 결과를 온체인에서 검증하는 코프로세서 역할을 효과적으로 수행합니다. 예를 들어, zkML 설정은 입력이나 온체인 계산을 드러내지 않고 _“개인 입력에 대한 신경망 추론이 분류 X를 생성했다”_는 것을 증명할 수 있습니다. 이는 AI에 적용된 코프로세서 개념의 특별한 경우입니다.
신뢰 가정: ZK 코프로세서는 암호학적 증명의 건전성에 의존합니다. 증명 시스템이 안전하다면 (그리고 신뢰할 수 있는 설정이 정직하게 수행되었다면), 수락된 증명은 계산이 올바랐음을 보장합니다. 증명자에 대한 추가적인 신뢰는 필요하지 않습니다 – 악의적인 증명자조차도 검증자에게 거짓 진술을 확신시킬 수 없습니다. 그러나 활성 가정이 있습니다: 누군가는 실제로 오프체인 계산을 수행하고 증명을 생성해야 합니다. 실제로는 이는 탈중앙화된 네트워크 (인센티브나 수수료로 작업을 수행) 또는 단일 서비스 운영자일 수 있습니다. 아무도 증명을 제공하지 않으면 온체인 요청은 해결되지 않은 채로 남을 수 있습니다. 또 다른 미묘한 신뢰 측면은 블록체인에 없는 오프체인 입력에 대한 데이터 가용성입니다. 계산이 일부 개인 또는 외부 데이터에 의존하는 경우, 데이터 커밋먼트나 오라클 서명과 같은 추가 조치가 사용되지 않는 한 검증자는 해당 데이터가 정직하게 제공되었는지 알 수 없습니다. 그러나 순수하게 온체인 데이터 계산의 경우, 설명된 메커니즘은 체인 자체와 동등한 신뢰 불필요성을 보장합니다 (Axiom은 그들의 증명이 과거 쿼리에 대해 "이더리움과 암호학적으로 동등한 보안"을 제공한다고 주장했습니다).
프라이버시: 영지식 증명은 본질적으로 프라이버시를 지원합니다. 증명자는 입력에 대한 진술을 증명하면서 입력을 숨길 수 있습니다. 코프로세서 맥락에서, 이는 증명이 컨트랙트가 개인 데이터에서 파생된 결과를 사용할 수 있게 함을 의미합니다. 예를 들어, 증명은 실제 신용 점수나 원시 데이터를 드러내지 않고 _“사용자의 신용 점수 > 700이므로 대출 승인”_을 보여줄 수 있습니다. Axiom의 사용 사례는 공개적으로 알려진 데이터 (블록체인 기록)에 대한 것이었으므로 프라이버시가 초점은 아니었습니다. 그러나 RISC Zero의 zkVM은 사용자가 제공한 비밀 데이터에 대한 주장을 증명하는 데 사용될 수 있습니다: 데이터는 오프체인에 머물고 필요한 결과만 온체인으로 이동합니다. FHE와 달리 ZK 증명은 일반적으로 상태의 지속적인 기밀성을 제공하지 않는다는 점은 주목할 가치가 있습니다. 이는 일회성 증명입니다. 워크플로우가 트랜잭션 간에 비밀 상태를 유지해야 하는 경우, 컨트랙트가 상태에 대한 _커밋먼트_를 저장하고 각 증명이 비밀을 숨긴 채 이전 커밋먼트에서 새로운 커밋먼트로의 유효한 상태 전환을 보여주도록 구축할 수 있습니다. 이것이 본질적으로 개인 트랜잭션을 위한 zk-롤업 (Aztec이나 Zcash와 같은)이 작동하는 방식입니다. 따라서 ZK 코프로세서는 완전히 개인적인 상태 기계를 용이하게 할 수 있지만, 구현은 간단하지 않습니다. 종종 입력이나 출력 (또는 둘 다)이 필요에 따라 비공개일 수 있는 _일회성 계산_에 사용됩니다.
개발자 경험: ZK 코프로세서를 사용하려면 일반적으로 새로운 도구를 배워야 합니다. 맞춤형 회로를 작성하는 것 (위의 옵션 (1))은 매우 복잡하며 일반적으로 좁은 목적을 위해서만 수행됩니다. DSL이나 zkVM과 같은 상위 수준 옵션은 삶을 더 쉽게 만들지만 여전히 오버헤드를 추가합니다: 개발자는 오프체인 코드 를 작성하고 배포하며 상호 작용을 관리해야 합니다. 암호화가 대부분 내부적으로 처리되고 개발자가 일반적인 스마트 컨트랙트 코드를 작성하는 FHE-VM과 대조적으로, 여기서는 개발자가 로직을 분할하고 오프체인 부분을 위해 다른 언어 (Rust 등)로 작성해야 할 수 있습니다. 그러나 Noir, Leo, Circom DSL이나 RISC Zero의 접근 방식과 같은 이니셔티브는 접근성을 빠르게 향상시키고 있습니다. 예를 들어, RISC Zero는 템플릿과 Foundry 통합을 제공하여 개발자가 로컬에서 오프체인 코드를 시뮬레이션하고 (정확성을 위해) Bonsai 콜백을 통해 솔리디티 테스트에 원활하게 연결할 수 있도록 합니다. 시간이 지남에 따라, 로직의 일부가 ZK 증명을 통해 실행되는지 또는 온체인에서 실행되는지를 추상화하는 개발 프레임워크를 기대할 수 있습니다. 컴파일러나 툴링이 비용에 따라 결정할 수 있습니다.
FHE-VM 대 ZK 코프로세서: 비교
FHE-VM과 ZK 코프로세서는 모두 _“온체인 보증을 통한 개인 데이터 계산”_의 한 형태를 가능하게 하지만, 아키텍처에서 근본적으로 다릅니다. 아래 표는 주요 차이점을 요약합니다:
| 측면 | FHE-VM (암호화된 온체인 실행) | ZK 코프로세서 (오프체인 증명) |
|---|---|---|
| 계산이 일어나는 곳 | 직접 온체인 (모든 노드가 암호문에 대해 동형 연산을 실행). | 오프체인 (증명자 또는 네트워크가 프로그램을 실행, 온체인에서는 증명만 검증). |
| 데이터 기밀성 | 완전 암호화: 데이터는 온체인에서 항상 암호화된 상태로 유지, 검증자는 평문을 절대 보지 못함. 복호화 키 소유자만 출력을 복호화할 수 있음. | 영지식: 증명자의 개인 입력은 온체인에서 절대 공개되지 않음, 증명은 공개 출력에 있는 것 외에는 비밀을 드러내지 않음. 그러나 온체인 상태에 영향을 미쳐야 하는 계산에 사용된 모든 데이터는 출력이나 커밋먼트에 인코딩되어야 함. 비밀은 기본적으로 오프체인에 유지됨. |
| 신뢰 모델 | 합의 실행 및 암호학에 대한 신뢰: 대다수의 검증자가 프로토콜을 따르면 암호화된 실행은 결정론적이고 정확함. 계산 정확성을 위해 외부 신뢰가 필요 없음 (모든 노드가 재계산). 프라이버시를 위해 FHE 체계 보안 (일반적으로 격자 어려움에 기반)을 신뢰해야 함. 일부 설계에서는 충분한 수의 검증자가 공모하여 임계값 키를 오용할 수 없다는 신뢰도 필요함. | 증명 시스템 보안 (SNARK/STARK의 건전성)에 대한 신뢰. 증명이 검증되면 결과는 암호학적 확실성으로 정확함. 오프체인 증명자는 수학을 속일 수 없음. 증명자가 실제로 작업을 수행할 것이라는 활성 가정이 있음. 신뢰할 수 있는 설정 (예: SNARK SRS)을 사용하는 경우, 정직하게 생성되었거나 투명/설정 없는 시스템을 사용해야 함을 신뢰해야 함. |
| 온체인 비용 및 확장성 | 트랜잭션당 높은 비용: 동형 연산은 계산적으로 매우 비싸고, 모든 노드가 이를 수행해야 함. 가스 비용이 높음 (예: 단일 8비트 덧셈에 10만+ 가스). 복잡한 컨트랙트는 모든 검증자가 한 블록 내에서 계산할 수 있는 것에 의해 제한됨. 특수 하드웨어를 사용하지 않는 한 처리량은 일반 스마트 컨트랙트보다 훨씬 낮음. 확장성은 더 빠른 암호학과 하드웨어 가속으로 개선되지만, 근본적으로 각 연산은 체인 작업량을 증가시킴. | 낮은 검증 비용: 간결한 증명을 검증하는 것은 효율적이고 크기가 일정하므로 온체인 가스는 적당함 (어떤 크기의 계산이든 수십만 가스). 이는 복잡성을 온체인 리소스 제한과 분리함 – 대규모 계산은 추가적인 온체인 비용이 없음. 따라서 온체인 부하 측면에서 _확장성_이 있음. 오프체인에서는 증명 시간이 상당할 수 있으며 (거대한 작업의 경우 몇 분 이상) 강력한 기계가 필요할 수 있지만, 이는 블록체인을 직접적으로 느리게 하지 않음. 증명이 제시간에 생성될 수 있는 한 (잠재적인 병렬 증명자 네트워크) 전체 처리량은 높을 수 있음. |
| 지연 시간 | 계산이 실행 중에 발생하므로 결과는 동일한 트랜잭션/블록에서 즉시 사용 가능. 추가적인 왕복이 없음 – 동기식 작동. 그러나 FHE 연산이 느리면 블록 처리 시간이 길어져 블록체인 지연 시간이 증가할 수 있음. | 본질적으로 비동기식. 일반적으로 요청하는 트랜잭션 하나와 나중에 증명/결과를 제공하는 트랜잭션 (또는 콜백)이 필요함. 이는 지연을 도입함 (증명 복잡성 및 증명 하드웨어에 따라 수 초에서 수 시간까지 가능). 단일 트랜잭션의 즉각적인 최종성에는 적합하지 않음 – 비동기 작업 모델에 더 가까움. |
| 프라이버시 보장 | 강력함: 모든 것 (입력, 출력, 중간 상태)이 온체인에서 암호화된 상태로 유지될 수 있음. 여러 트랜잭션이 절대 공개하지 않고 업데이트하는 장기적인 암호화된 상태를 가질 수 있음. 승인된 복호화 작업 (만약 있다면)만이 출력을 공개하며, 이는 키/ACL을 통해 제어될 수 있음. 그러나 가스 사용량이나 이벤트 로그와 같은 사이드 채널 고려 사항은 패턴이 유출되지 않도록 관리해야 함 (fhEVM 설계는 데이터-무관 실행과 연산에 대한 상수 가스를 통해 유출을 피하려 노력함). | 선택적: 증명은 공개 출력에 있거나 검증에 필요한 것 (예: 초기 상태에 대한 커밋먼트)을 공개함. 설계자는 의도된 결과만 공개되고 다른 모든 입력은 영지식으로 숨겨지도록 보장할 수 있음. 그러나 FHE와 달리 블록체인은 일반적으로 숨겨진 상태를 저장하지 않음 – 프라이버시는 데이터를 완전히 오프체인에 유지함으로써 달성됨. 영구적인 개인 상태가 필요한 경우, 컨트랙트는 이에 대한 암호학적 커밋먼트를 저장할 수 있음 (따라서 상태 업데이트는 매번 새로운 커밋먼트를 공개함). 프라이버시는 무엇을 증명하기로 선택하는지에 따라 제한됨, 예를 들어 정확한 값을 공개하지 않고 임계값이 충족되었음을 증명할 유연성이 있음. |
| 무결성 강제 | 설계상 모든 검증자는 다음 상태를 동형적으로 재계산하므로, 악의적인 행위자가 잘못된 암호문 결과를 제공하면 다른 사람들은 불일치를 감지함 – 모든 사람이 동일한 결과를 얻지 않는 한 합의는 실패함. 따라서 무결성은 중복 실행에 의해 강제됨 (일반 블록체인과 같지만 암호화된 데이터에 대해). 검증자가 평문 조건을 직접 확인할 수 없기 때문에 비즈니스 규칙 (예: 사용자가 제약 조건을 위반할 수 없음)을 강제하기 위해 추가적인 ZK 증명이 종종 사용됨. | 무결성은 ZK 증명을 확인하는 검증자 컨트랙트에 의해 강제됨. 증명이 검증되는 한, 결과는 오프체인 프로그램의 유효한 실행과 일치함이 보장됨. 정확성을 위해 정직한 다수 가정이 필요 없음 – 단일 정직한 검증자 (컨트랙트 코드 자체)만으로도 충분함. 온체인 컨트랙트는 잘못된 증명이나 누락된 증명을 단순히 거부할 것임 (유효하지 않은 서명을 거부하는 것과 유사). 한 가지 고려 사항: 증명자가 중단하거나 지연하면 컨트랙트는 폴백 로직이 필요할 수 있지만 (또는 사용자가 나중에 다시 시도해야 할 수 있음), 잘못된 결과를 수락하지는 않음. |
| 개발자 경험 | 장점: 익숙한 스마트 컨트랙트 언어 (Solidity 등)를 확장하여 대체로 사용할 수 있음. 기밀성은 플랫폼에서 처리됨 – 개발자는 주로 무엇을 암호화하고 누가 키를 보유할지에 대해 걱정함. 암호화된 컨트랙트와 일반 컨트랙트의 구성이 가능하여 DeFi의 구성 가능성을 유지함 (암호화된 변수만 추가). 단점: FHE 제한 사항을 이해해야 함 – 예: 특별한 처리 없이 비밀 데이터에 대한 직접적인 조건부 점프 불가, 제한된 회로 깊이 (TFHE의 부트스트래핑은 시간 비용으로 임의 길이의 계산을 허용). 키 없이는 런타임 값을 쉽게 검사할 수 없으므로 암호화된 로직 디버깅이 까다로울 수 있음. 또한 키 관리 및 권한 부여는 컨트랙트 설계에 복잡성을 더함. | 장점: 오프체인 부분에 잠재적으로 모든 프로그래밍 언어를 사용할 수 있음 (특히 zkVM 사용 시). 오프체인 프로그램에서 기존 코드/라이브러리 활용 가능 (ZK 호환성에 대한 주의 사항 있음). 일반 ZKVM을 사용하는 경우 개발자가 맞춤형 암호학 을 필요로 하지 않음 – 일반 코드를 작성하고 증명을 얻음. 또한 무거운 계산은 온체인에서 절대 실행되지 않을 라이브러리 (예: 머신러닝 코드)를 사용할 수 있음. 단점: 개발자는 오프체인 인프라를 조정하거나 증명 서비스를 사용해야 함. 비동기 워크플로우를 처리하고 온체인 로직과 통합하는 데 더 많은 설계 작업이 필요함 (예: 보류 중인 상태 저장, 콜백 대기). 효율적인 회로나 zkVM 코드를 작성하려면 새로운 제약 조건을 배워야 할 수 있음 (예: 부동 소수점 없음, 고정 소수점 또는 특수 프리미티브 사용, 증명 시간을 폭발시키는 무거운 분기 피하기, 제약 조건 수 최적화). 또한 증명 실패, 타임아웃 등을 처리해야 하는 부담이 있으며, 이는 일반 솔리디티에서는 걱정할 필요가 없음. 도구 생태계는 성장하고 있지만, 많은 사람들에게는 새로운 패러다임임. |
두 접근 방식 모두 활발하게 개선되고 있으며, 심지어 융합되는 모습도 보입니다: 언급했듯이, ZKPs는 특정 검사를 위해 FHE-VM 내부에서 사용되며, 반대로 일부 연구자들은 ZK에서 증명자 입력을 비공개로 유지하기 위해 FHE를 사용하는 것을 제안합니다 (따라서 클라우드 증명자가 당신의 비밀 데이터를 보지 못함). 미래 시스템이 이들을 결합할 것이라고 상상할 수 있습니다. 예를 들어, 오프체인에서 FHE를 수행한 다음 그 정확성을 체인에 증명하거나, 온체인에서 FHE를 사용하지만 라이트 클라이언트에게 암호화된 연산이 올바르게 수행되었음을 ZK 증명하는 것입니다. 각 기술에는 강점이 있습니다: FHE-VM은 무거운 계산 비용을 감수하고 _지속적인 프라이버시와 실시간 상호 작용_을 제공하는 반면, ZK 코프로세서는 지연 시간과 복잡성을 감수하고 _확 장성과 유연성_을 제공합니다.
사용 사례 및 시사점
프로그래밍 가능한 프라이버시의 등장은 산업 전반에 걸쳐 수많은 새로운 블록체인 애플리케이션을 열어줍니다. 아래에서는 FHE-VM과 ZK 코프로세서 (또는 하이브리드)가 프라이버시 보존 스마트 컨트랙트와 안전한 데이터 경제를 가능하게 함으로써 다양한 영역을 어떻게 강화할 수 있는지 탐구합니다.
기밀 DeFi 및 금융
탈중앙화 금융에서 프라이버시는 프론트러닝을 완화하고, 거래 전략을 보호하며, 필요한 경우 투명성을 희생하지 않고 규정을 준수할 수 있습니다. 기밀 DeFi는 사용자가 자신의 포지션을 세상에 공개하지 않고 프로토콜과 상호 작용할 수 있게 합니다.
-
비공개 트랜잭션 및 숨겨진 잔액: FHE를 사용하여 블록체인 L1에서 기밀 토큰 전송 (암호화된 ERC-20 잔액 및 트랜잭션) 또는 보호된 풀을 구현할 수 있습니다. 관찰자는 당신이 보유하거나 전송한 토큰의 양을 볼 수 없으므로, 보유량에 기반한 표적 공격의 위험을 제거합니다. ZK 증명은 잔액이 동기화되고 이중 지불이 발생하지 않도록 보장할 수 있습니다 (Zcash와 유사하지만 스마트 컨트랙트 플랫폼에서). 한 예로 풀의 예비금과 거래가 온체인에서 암 호화되는 **기밀 AMM (자동화된 시장 조성자)**이 있습니다. 차익 거래자나 프론트러너는 거래가 정산될 때까지 가격 슬리피지를 관찰할 수 없으므로 풀을 악용할 수 없어 MEV를 줄입니다. 일부 지연 후 또는 접근 제어 메커니즘을 통해서만 일부 데이터가 감사 목적으로 공개될 수 있습니다.
-
MEV 저항성 경매 및 거래: 채굴자와 봇은 거래 투명성을 악용하여 거래를 프론트러닝합니다. 암호화를 사용하면 주문이 암호문으로 제출되는 암호화된 멤풀 또는 배치 경매를 가질 수 있습니다. 경매가 종료된 후에만 거래가 복호화됩니다. 때로는 _공정한 주문 흐름_이라고 불리는 이 개념은 임계값 복호화 (여러 검증자가 공동으로 배치를 복호화) 또는 개별 입찰을 공개하지 않고 ZK를 통해 경매 결과를 증명함으로써 달성할 수 있습니다. 예를 들어, ZK 코프로세서는 오프체인에서 봉인된 입찰 배치를 받아 경매 청산 가격을 계산하고, 그 가격과 승자만 증명과 함께 출력할 수 있습니다. 이는 패배한 입찰의 공정성과 프라이버시를 보존합니다.
-
기밀 대출 및 파생상품: DeFi 대출에서 사용자는 대출 규모나 담보를 공개하고 싶지 않을 수 있습니다 (이는 시장 심리에 영향을 미치거나 악용을 유발할 수 있음). FHE-VM은 각 대출의 세부 정보가 암호화된 암호화된 대출 장부를 유지할 수 있습니다. 스마트 컨트랙트 로직은 암호화된 건전성 요소에 대해 작동하여 청산 조건과 같은 규칙을 계속 강제할 수 있습니다. 대출의 담보 비율이 임계값 아래로 떨어지면, 컨트랙트는 (ZK 증명의 도움으로) 정확한 값을 노출하지 않고 청산을 위해 플래그를 지정할 수 있습니다. 평문으로 예/아니오 플래그만 생성할 수 있습니다. 마찬가지로, 비밀 파생상품이나 옵션 포지션은 온체인에서 관리될 수 있으며, 집계된 위험 지표만 공개될 수 있습니다. 이는 카피 트레이딩을 방지하고 독점 전략을 보호하여 더 많은 기관 참여를 장려할 수 있습니다.
-
규제 준수 프라이버시: 모든 금융 상황이 완전한 익명성을 원하는 것은 아닙니다. 때로는 규제를 위해 _선택적 공개_가 필요합니다. 이러한 도구를 사용하면 규제된 프라이버시를 달성할 수 있습니다: 예를 들어, 거래는 대중에게 비공개이지만, 규제된 거래소는 특정 속성에 대한 증명을 복호화하거나 받을 수 있습니다. ZK를 통해 _“이 거래는 블랙리스트에 오른 주소를 포함하지 않았으며 양 당사자는 KYC 인증을 받았다”_는 것을 체인에 신원을 공개하지 않고 증명할 수 있습니다. 이 균형은 자금 세탁 방지 (AML) 규칙을 만족시키면서 다른 모든 사람에게는 사용자 신원과 포지션을 기밀로 유지할 수 있습니다. FHE는 온체인 준법 감시인 컨트랙트가 암호화된 트랜잭션에서 위험 신호를 스캔할 수 있게 할 수 있습니다 (예를 들어, 법원 명령 하에서만 접근 가능한 복호화 키 사용).
디지털 신원 및 개인 데이터
신원 시스템은 온체인 프라이버시 기술로부터 상당한 이점을 얻을 수 있습니다. 현재, 개인 자격 증명이나 속성을 공개 원장에 올리는 것은 프라이버시 법과 사용자 거부감 때문에 비현실적입니다. FHE와 ZK를 사용하면 자기 주권 신원을 프라이버시를 보존하는 방식으로 실현할 수 있습니다:
-
영지식 자격 증명: ZK 증명 (일부 신원 프로젝트에서 이미 일반적임)을 사용하여 사용자는 “나는 18세 이상이다”, “유효한 운전 면허증을 가지고 있다”, 또는 _“연 소득이 5만 달러 이상이다 (신용 평가용)”_와 같은 진술을 다른 개인 정보를 공개하지 않고 증명할 수 있습니다. ZK 코프로세서는 오프체인에서 더 복잡한 검사를 처리함으로써 이를 향상시킬 수 있습니다. 예를 들어, Axiom과 유사한 방식으로 개인 신용 데이터베이스를 쿼리하여 사용자의 신용 점수가 임계값 이상임을 증명하고, 블록체인에는 예/아니오만 출력할 수 있습니다.
-
DeFi에서의 기밀 KYC: 법적으로 사용자가 KYC 인증을 받았는지 확인해야 하는 DeFi 프로토콜을 상상해 보세요. FHE-VM을 사용하면 사용자의 자격 증명이 온체인에 암호화되어 저장될 수 있으며 (또는 DID를 통해 참조됨), 스마트 컨트랙트는 FHE 계산을 수행하여 KYC 정보가 요구 사항을 충족하는지 확인할 수 있습니다. 예를 들어, 컨트랙트는 암호화된 사용자 프로필의 _이름_과 _SSN_이 제재 대상 사용자 목록 (역시 암호화됨)과 일치하는지, 또는 사용자의 국가가 제한되지 않았는지 동형적으로 확인할 수 있습니다. 컨트랙트는 암호화된 "통과/실패"만 얻게 되며, 이는 네트워크 검증자에 의해 불리언 플래그로 임계값 복호화될 수 있습니다. 사용자가 허용되었는지 여부만 공개되어 개인 식별 정보 (PII)의 기밀성을 보존하고 GDPR 원칙과 일치합니다. 이 선택적 공개는 규정 준수와 프라이버시를 보장합니다.
-
속성 기반 접근 및 선택적 공개: 사용자는 검증 가능한 자격 증명 (나이, 시민권, 기술 등)을 암호화된 속성으로 보유할 수 있습니다. 그들은 특정 dApp이 모든 것을 공개하지 않고 그들에 대한 계산을 실행하도록 승인할 수 있습니다. 예를 들어, 탈중앙화 채용 dApp은 (FHE를 사용하여) 암호화된 이력서에 대한 검색을 수행하여 후보자를 필터링할 수 있습니다. 예를 들어, 경력 연수를 세거나, 자격증을 확인하고, 일치하는 경우에만 오프체인에서 후보자에게 연락합니다. 후보자의 개인 정보는 그들이 공개하기로 선택하지 않는 한 암호화된 상태로 유지됩니다. ZK 증명은 또한 사용자가 실제 값을 공개하지 않고 속성의 조합 (예: 21세 이상 그리고 특정 우편 번호 내)을 소유하고 있음을 선택적으로 증명할 수 있게 합니다.
-
다자간 신원 확인: 때로는 사용자의 신원이 여러 당사자에 의해 심사되어야 합니다 (예: A 회사의 배경 조사, B 회사의 신용 조사). 동형 및 ZK 도구를 사용하면 각 검증자가 암호화된 점수나 승인을 기여할 수 있으며, 스마트 컨트랙트는 이를 최종 결정으로 집계하여 개별 기여를 노출하지 않고 처리할 수 있습니다. 예를 들어, 세 개의 기관이 암호화된 "통과/실패" 비트를 제공하고, 컨트랙트는 세 개 모두 통과인 경우 승인을 출력합니다. 사용자나 의존 당사자는 최종 결과만 볼 뿐, 특정 기관이 실패했는지는 알 수 없어 각 기관에서의 사용자 기록 프라이버시를 보존합니다. 이는 예를 들어, 하나의 실패한 검사가 특정 문제를 드러내는 것과 관련된 편견과 낙인을 줄일 수 있습니다.