FHE와 기밀 스마트컨트랙트
도입
FHE는 암호화된 데이터 위에서 계산하는 모델이다. ZK가 "이 명제가 참이다"를 증명하는 데 강하다면, FHE는 "값을 복호화하지 않고 계산한다"에 가깝다. Stablecoin 제품에서는 encrypted balance, private amount, private limit check, confidential settlement 같은 아이디어로 연결된다.
하지만 FHE를 쓰면 모든 privacy 문제가 해결되는 것은 아니다. encrypted input, ciphertext handle, access control, decryption authority, KMS, coprocessor 같은 새로운 trust boundary가 생긴다. 이 강의는 production 구현보다 먼저 어떤 상태를 숨기고 어떤 상태를 공개해야 하는지 설계하는 데 집중한다.
학습 목표
- FHE가 암호화된 상태 계산을 제공하는 모델을 설명한다.
- 성능, 키 관리, 개발 경험 제약을 고려한다.
개념 설명
핵심 개념
- FHE가 암호화된 상태 계산을 제공하는 모델을 설명한다.
- 성능, 키 관리, 개발 경험 제약을 고려한다.
검증 지점
- 숨길 데이터와 공개할 데이터가 분리되는가
- 체인별 ownership 모델을 오해하지 않는가
- FHE 계산 모델을 설명했다.
실습 산출물
- FHE와 기밀 스마트컨트랙트 이해 점검
- FHE와 기밀 스마트컨트랙트 적용 과제
- 감사 가능성이 유지되는가
Zama fhEVM 문서 기준으로 encrypted input은 ciphertext와 proof가 함께 제출된다. smart contract는 einput handle과 inputProof를 받아 encrypted type으로 변환한 뒤 연산한다.
| 구성 요소 | 역할 | stablecoin 질문 |
|---|---|---|
| encrypted input | 사용자가 ciphertext로 제출한 값 | 결제 금액, limit, balance 중 무엇을 숨기는가 |
| input proof | encrypted input의 유효성 확인 | 사용자가 plaintext를 알고 있음을 어떻게 보장하는가 |
| encrypted type | contract가 다루는 암호화된 값 | 일반 Solidity 분기와 어떤 점이 다른가 |
| ACL/host contract | ciphertext handle 접근 제어 | 누가 balance를 재암호화하거나 볼 수 있는가 |
| KMS/gateway/coprocessor | decryption과 computation 인프라 | 어떤 offchain trust assumption을 받아들이는가 |
FHE stablecoin 설계는 세 층을 나눠야 한다.
| 층 | 숨길 수 있는 것 | 공개해야 하는 것 |
|---|---|---|
| 사용자 결제 | amount, balance, spending limit | transaction existence, proof result, receipt |
| issuer/compliance | 필요한 범위의 decrypt/disclose | supply, freeze policy, disclosure log |
| merchant/ledger | payer의 전체 잔고는 숨김 | payment success, settled amount, dispute evidence |
코드로 확인하기
FHE 기반 설계에서는 값이 암호화된 채 계산된다. 그래서 코드는 "비밀 값으로 무엇을 계산하는가"와 "언제 누구에게 reveal하는가"를 분리해야 한다.
컨트랙트암호화 잔고의 전송 조건
function confidentialTransfer( address to, euint64 encryptedAmount, bytes calldata proof) external { if (!acl.canSpend(msg.sender, encryptedAmount, proof)) { revert ConfidentialPolicyRejected(); } encryptedBalance[msg.sender] = FHE.sub(encryptedBalance[msg.sender], encryptedAmount); encryptedBalance[to] = FHE.add(encryptedBalance[to], encryptedAmount); emit ConfidentialTransfer(msg.sender, to);}예시에서 event는 amount를 노출하지 않는다. 대신 policy proof와 encrypted state가 일관적인지를 검증해야 한다.
운영reveal 권한을 별도 승인 흐름으로 관리
type RevealRequest = { account: string; field: "balance" | "transfer_amount"; reason: "audit" | "dispute" | "regulatory_request"; approvers: string[];};function canReveal(request: RevealRequest) { const enoughApprovers = request.approvers.length >= 2; const allowedReason = request.reason === "audit" || request.reason === "dispute"; return enoughApprovers && allowedReason;}FHE를 썼다고 운영상 공개가 사라지는 것은 아니다. 누가 어떤 사유로 reveal할 수 있는지 정책 코드가 있어야 한다.
강의 포인트
| 관점 | 확인할 질문 | 증거로 남길 것 |
|---|---|---|
| encrypted state | 어떤 field를 암호화하고 어떤 event를 공개할 것인가 | public/private state table |
| computation | encrypted type 연산이 제품 요구를 충족하는가 | operation feasibility memo |
| decryption | 누가 어떤 상황에서 복호화할 수 있는가 | decryption authority matrix |
| infra trust | KMS, gateway, coprocessor 장애를 어떻게 다룰 것인가 | trust boundary diagram |
| UX | encrypted proof/input 생성 실패와 latency를 어떻게 안내할 것인가 | user state copy |
실무 예시
비공개 결제 한도 검증 기능을 만든다고 가정한다. 사용자의 실제 누적 지출액은 공개하지 않지만, "이번 결제 후에도 daily limit 이하"라는 결과는 contract가 확인해야 한다.
| 단계 | 공개 여부 | 설명 |
|---|---|---|
| encrypted amount 제출 | private | 사용자는 amount를 ciphertext로 제출 |
| proof 검증 | public result | ciphertext가 유효한 입력임을 확인 |
| limit 계산 | private computation | encrypted spent + encrypted amount 계산 |
| allow/deny 결과 | public enough | 결제 가능 여부는 알아야 함 |
| audit disclosure | controlled | 분쟁이나 규제 요청 시 제한 복호화 |
흔한 오해와 실패 시나리오
| 오해 | 실제로 확인할 것 |
|---|---|
| FHE를 쓰면 모든 값이 완전히 비공개라고 본다. | transaction timing, participant, receipt, access pattern metadata는 남을 수 있다. |
| encrypted type을 일반 Solidity 값처럼 다룬다. | 분기, 비교, overflow, error handling semantics가 다르다. |
| decryption authority를 나중에 정한다. | 누가 언제 무엇을 복호화할 수 있는지가 제품 신뢰의 핵심이다. |
| KMS와 coprocessor를 단순 infra로 본다. | 이들은 privacy와 availability의 trust boundary다. |
| merchant reconciliation을 잊는다. | merchant는 private amount를 모르더라도 정산 가능한 receipt를 받아야 한다. |
실습 과제
- FHE와 기밀 스마트컨트랙트 이해 점검: encrypted state, public event, decryption authority, KMS dependency를 표로 정리한다.
- trust boundary 작성: user, contract, KMS, gateway, coprocessor, issuer, auditor가 각각 무엇을 신뢰해야 하는지 그린다.
- 비공개 한도 검증 설계: encrypted daily spend와 encrypted amount를 이용한 allow/deny 흐름을 설계한다.
- 제품 적용 한계 작성: gas/latency, SDK maturity, key rotation, emergency access, ledger reconciliation 한계를 적는다.
완료 기준
- FHE 계산 모델을 설명했다.
- 키 관리 질문을 정리했다.
- 제품 적용 한계를 적었다.
근거 자료
- FHE 기밀 스마트컨트랙트: 06-프라이버시-ZK-FHE/02-FHE-기밀-스마트컨트랙트.md
- ZK FHE 프라이버시 문서: 90-출처/원문-노트/ZK-FHE-프라이버시-문서.md
- Zama fhEVM Encrypted Inputs: https://docs.zama.ai/fhevm/smart-contract/inputs