성배 해독: 체인 상의 동형 암호화 기술이 마주한 과제와 해결책
저자: Jeffrey Hu, Arnav Pagidyala
핵심 관점
· 전형동형암호(FHE)는 "암호학의 성배"로 불리지만, 현재는 성능, 개발 경험, 보안 측면에서 적용이 제한되고 있다.
· 위 그림과 같이 진정으로 기밀성과 보안을 갖춘 공유 상태 시스템을 구축하기 위해서는 FHE를 제로지식 증명(ZKP) 및 다자간 계산(MPC)과 결합해야 한다.
· FHE는 빠르게 발전하고 있으며, 새로운 컴파일러, 라이브러리, 하드웨어 등의 개발과 인텔, 구글, DARPA 등 Web2 기업들의 R&D가 FHE 발전을 크게 촉진하고 있다.
· FHE와 주변 생태계가 성숙함에 따라 우리는 "검증 가능한 FHE(Verifiable FHE)"가 표준이 될 것으로 예상한다. 탈중앙화 애플리케이션(DApp)/롤업은 계산과 검증을 FHE 협력 프로세서에 아웃소싱할 수 있다.
· 체인 상 FHE의 근본적인 한계는 "누가 복호화 키를 소유하는가?"이다. 임계값 복호화(threshold decryption)와 MPC는 이러한 제약에 대한 해결책을 제공하지만, 일반적으로 성능과 보안 간의 트레이드오프 문제가 존재한다.
서론
블록체인의 투명성은 양날의 검이다. 개방성과 가시성이 매력적이지만, 기업들이 블록체인 기술을 채택하는 데 있어 우려 요인이 되기도 한다.
체인 상 프라이버시는 지난 10년간 암호화 분야에서 가장 도전적인 문제 중 하나였다. ZKP 기반 시스템을 구축하려는 많은 팀들이 노력하고 있지만, 이들은 암호화된 공유 상태를 지원하지 못한다. 이러한 솔루션들이 일련의 ZKP 함수이기 때문에 현재 상태에 임의의 로직을 적용할 수 없기 때문이다. 즉, 프라이빗 유니스왑(Uniswap)과 같은 암호화된 공유 상태 애플리케이션을 단순히 ZKP만으로 구축할 수 없다는 의미다.
그러나 최근의 기술적 돌파구는 ZKP와 전형동형암호(FHE)를 결합하면 완전히 범용적이고 암호화된 탈중앙화 금융(DeFi)을 실현할 수 있음을 보여준다. 어떻게 가능할까? FHE는 암호화된 데이터 상에서 임의의 연산을 수행할 수 있는 신생 암호학 분야다. 위 그림에서 보듯, ZKP는 사용자 입력과 연산의 무결성을 증명할 수 있고, FHE는 연산 자체를 처리할 수 있다.
FHE는 "암호학의 성배"라 불리지만, 본고에서는 이 분야와 다양한 도전 과제 및 가능한 해결책에 대해 객관적인 분석을 시도할 것이다. 이 기술 보고서는 다음과 같은 체인 상 FHE 주제들을 다룬다:
1. FHE 방식, 라이브러리 및 컴파일러 (FHE Schemes, Libraries and Compilers)
2. 안전한 임계값 복호화 (Secure Threshold Decryption)
3. 사용자 입력과 연산 당사자의 제로지식 증명 (ZKPs for User Inputs + Computing Party)
4. 프로그래머블하고 확장 가능한 데이터 가용성(DA) 계층 (Programmable, Scalable DA Layer)
5. FHE 하드웨어 (FHE Hardware)
전형동형암호(FHE) 방식, 라이브러리 및 컴파일러
도전: 신생 FHE 방식, 라이브러리 및 컴파일러
체인 상 FHE의 기본 병목 현상은 개발 도구와 인프라의 부족에 있다. ZKP나 MPC와 달리 FHE는 2009년 이후 짧은 기간 동안 발전해 왔으므로 성숙도가 낮다.
FHE 개발 환경의 주요 제약 사항은 다음과 같다:
· 백엔드 암호학에 깊이 관여하지 않고도 코딩할 수 있는 쉬운 프런트엔드 언어 부족
· 파라미터 선택, BGV/BFV SIMD 최적화 및 병렬 최적화 등 모든 복잡한 작업을 처리할 수 있는 기능 완전한 FHE 컴파일러 부족
· 기존 FHE 방식(특히 TFHE)은 일반 계산보다 약 1000배 느림
FHE 통합의 복잡성을 이해하기 위해 개발자가 겪어야 할 절차를 살펴보자:
FHE를 애플리케이션에 통합하는 첫 번째 단계는 FHE 방식을 선택하는 것이다. 다음 표는 주요 방식을 설명한다:
위 표에서 보듯, 부울 회로(FHEW 및 TFHE)는 부트스트래핑 속도가 가장 빠르며 복잡한 파라미터 선택을 피할 수 있고 임의/범용 계산에 사용할 수 있지만 상대적으로 느리다. 반면 BGV/BFV는 고정밀 산술 계산에서 더 효율적이므로 일반 DeFi 애플리케이션에 적합하지만, 개발자는 회로 깊이를 미리 알고 있어야 하며 이를 통해 방식의 모든 파라미터를 설정해야 한다. 다른 한편으로 CKKS는 동형 곱셈을 지원하며 정밀도 오차를 허용하므로 머신러닝과 같은 비정밀 용례에 적합하다.
개발자로서 FHE 방식 선택은 매우 신중해야 하며, 이 선택은 모든 다른 설계 결정과 미래의 성능에 영향을 준다. 또한 모듈러스 크기 선택 및 다항식 차수의 역할과 같은 FHE 방식을 올바르게 설정하는 데 중요한 몇 가지 핵심 파라미터가 있다.
다음은 라이브러리에 대해 살펴보자. 다음 표는 현재 널리 사용되는 주요 FHE 라이브러리의 기능과 능력을 보여준다:
그러나 이러한 라이브러리는 다양한 FHE 방식과 컴파일러와 서로 다른 관계를 맺고 있다:
FHE 방식을 선택한 후 개발자는 파라미터를 설정해야 한다. 올바른 파라미터 선택은 FHE 방식의 성능에 큰 영향을 미친다. 어려운 점은 추상 대수, 재선형화 및 모듈러스 전환과 같은 FHE 특정 연산, 그리고 산술 또는 이진 회로에 대한 이해가 필요하다는 점이다. 마지막으로, 파라미터를 효과적으로 선택하기 위해서는 개념적으로 그것들이 FHE 방식에 어떤 영향을 미치는지 이해해야 한다.
이 시점에서 개발자는 다음과 같은 질문을 할 수 있다:
내 평문(plaintext) 공간은 얼마나 커야 하는가? 허용 가능한 암호문(ciphertext) 크기는 얼마인가? 어디서 병렬 계산을 할 수 있는가? 등등...
또한 FHE는 임의의 계산을 지원할 수 있지만, 개발자는 FHE 프로그램을 작성할 때 사고방식을 바꿔야 한다. 예를 들어 변수에 기반한 분기를(if-else) 코드에 작성할 수 없다. 프로그램은 변수를 일반 데이터처럼 직접 비교할 수 없기 때문이다. 대신 개발자는 모든 분기 조건을 포함할 수 있는某种 연산으로 코드를 분기에서 변경해야 한다. 마찬가지로 이는 개발자가 코드에 루프를 작성하는 것도 막는다.
간단히 말해, FHE에 익숙하지 않은 개발자에게는 자신의 애플리케이션에 FHE를 통합하는 것이 거의 불가능하다. FHE가 제시하는 복잡성을 추상화하기 위해 상당한 개발 도구와 인프라가 필요하다.
해결책:
1. Web3 특화 FHE 컴파일러
구글과 마이크로소프트와 같은 기업들이 이미 FHE 컴파일러를 개발했지만, 이들은 다음과 같은 문제점을 지닌다:
· 성능을 설계 목표로 하지 않아 회로 직접 작성에 비해 1000배의 "오버헤드" 발생
· CKKS(즉 ML)에 최적화되어 있어 DeFi에 필요한 BFV/BGV에는 덜 유리함
· Web3용으로 구축되지 않아 ZKP 방식, 프로그래머블 블록체인 등과의 호환성 미지원
Sunscreen FHE 컴파일러가 등장하기까지 그러했다. Sunscreen은 Web3 원생 컴파일러로, 하드웨어 가속기가 없더라도 산술 연산(예: DeFi)에서 일부 최고의 성능을 제공한다. 앞서 언급했듯이 파라미터 선택은 FHE 방식을 구현하는 가장 어려운 부분일 수 있다. Sunscreen은 파라미터 선택을 자동화할 뿐 아니라 데이터 인코딩, 키 선택, 재선형화 및 모듈러스 전환 실행, 회로 설정, SIMD 연산 구현까지 모두 수행한다.
기술이 계속 발전함에 따라 Sunscreen 컴파일러뿐 아니라 다른 팀들도 고급 언어를 지원하는 추가 최적화를 위한 자체 컴파일러를 개발하길 기대한다.
2. 새로운 FHE 라이브러리
연구자들이 끊임없이 새로운 효과적인 방식을 탐색하고 있지만, FHE 라이브러리는 더 많은 개발자가 FHE를 통합할 수 있도록 도와줄 수 있다.
FHE 스마트 계약을 예로 들어보자. 다양한 FHE 라이브러리 중에서 선택하는 것은 어려울 수 있지만, 체인 상 FHE를 논할 때는 Web3에서 지배적인 몇 가지 프로그래밍 언어만 있기 때문에 선택이 더 쉬워진다.
예를 들어 Zama의 fhEVM은 오픈소스 라이브러리 TFHE-rs를 일반 EVM에 통합하여 동형 연산을 사전컴파일된 계약으로 공개한다. 이는 개발자가 컴파일 도구를 수정하지 않고도 계약 내에서 암호화된 데이터를 사용할 수 있게 해준다.
다른 특정 시나리오의 경우 다른 인프라도 필요할 수 있다. 예를 들어 C++로 작성된 TFHE 라이브러리는 Rust 버전만큼 잘 관리되지 않는다. TFHE-rs는 C/C++ 내보내기를 지원할 수 있지만, C++ 개발자가 더 나은 호환성과 성능을 원한다면 자신만의 TFHE 라이브러리 버전을 작성해야 한다.
마지막으로, 시장에서 FHE 인프라 부족의 핵심 이유 중 하나는 FHE-RAM을 효과적으로 구축할 방법이 부족하기 때문이다. 가능한 해결 방향 중 하나는 일부 오퍼코드가 없는 FHE-EVM 연구다.
안전한 임계값 복호화(Secure Threshold Decryption)
도전: 불안전하거나 중심화된 임계값 복호화
모든 기밀 공유 상태 시스템은 암호화 및 복호화 키를 기반으로 한다. 어느 한 당사자를 신뢰할 수 없으므로 복호화 키는 네트워크 참여자들 사이에서 다자간 계산(MPC)을 통해 분할된다.
체인 상 전형동형암호(FHE)에서 가장 도전적인 측면 중 하나는 안전하고 고성능의 임계값 복호화 프로토콜을 구축하는 것이다. 주요 병목 현상은 두 가지다:
(1) FHE 기반 계산은 상당한 "오버헤드"를 유발하므로 고성능 노드가 필요하며, 이는 본질적으로 검증자 집합의 잠재적 규모를 줄인다.
(2) 복호화 프로토콜에 참여하는 노드 수가 증가함에 따라 지연도 증가한다.
적어도 지금까지 FHE 프로토콜은 검증자 다수의 정직성(honesty majority)에 의존하지만, 앞서 언급했듯이 체인 상 FHE는 작은 검증자 집합을 의미하므로 공모 및 악의적 행동 가능성은 더욱 높아진다.
임계값 노드가 공모하여 악행을 저지르면 어떻게 될까? 이들은 프로토콜을 우회하여 기본적으로 사용자가 체인 상에 입력한 모든 데이터를 포함해 아무거나 복호화할 수 있다. 게다가 현재 시스템에서는 복호화 프로토콜이 감지되지 않은 채 발생할 수 있다는 점(즉 "무음 공격")에 더욱 주의해야 한다.
해결책: 개선된 임계값 복호화 또는 동적 MPC
임계값 복호화의 단점을 해결하기 위한 몇 가지 방법이 있다.
(1) n/2 임계값 활성화: 공모를 더 어렵게 만든다.
(2) 하드웨어 보안 모듈(HSM) 내에서 임계값 복호화 프로토콜 실행
(3) 신뢰 실행 환경(TEE) 기반 임계값 복호화 네트워크 사용: 탈중앙화 체인에서 인증을 제어하고 동적 키 관리를 허용
임계값 복호화를 활용하는 대신 MPC를 사용하는 것이 더 가능성이 높다. 체인 상 FHE에서 사용할 수 있는 MPC 프로토콜의 획기적인 사례로는 Odsy의 새로운 2PC-MPC가 있는데, 이것은 공모하지 않으며 대규모로 탈중앙화된 최초의 MPC 알고리즘이다.
또 다른 접근법은 데이터를 사용자의 공개키로만 암호화하는 것이다. 검증자가 동형 연산을 처리하고, 필요 시 사용자 본인이 결과를 복호화할 수 있다. 이 방법은 특정 사용 사례에만 적용되지만, 임계값 가정을 완전히 피할 수 있다.
요약하자면, 체인 상 FHE는 다음과 같은 특징을 갖춘 효율적인 MPC 구현이 필요하다:
(1) 악의적인 행위자가 존재하더라도 작동 가능
(2) 최소한의 지연 유발
(3) 무허가/유연한 노드 가입 허용
사용자 입력 및 연산 당사자의 제로지식 증명(ZKP)
도전: 사용자 입력과 연산의 검증 가능성
Web2 세계에서는 계산 작업을 요청할 때 기업이 약속한 대로 백엔드에서 작업을 실행한다고 완전히 신뢰한다. Web3에서는 이 모델이 완전히 뒤집힌다. 이제는 기업의 명성에 의존하거나 그들이 성실히 행동한다고 단순히 믿는 대신, 신뢰하지 않는 환경에서 운영되며, 사용자는 누구도 신뢰할 필요가 없다.
전형동형암호(FHE)는 암호화된 데이터를 처리할 수 있지만, 사용자 입력이나 연산의 정확성은 검증할 수 없다. 검증 능력이 없다면 FHE는 블록체인 맥락에서 거의 쓸모없다.
해결책: 사용자 입력 및 연산 당사자의 ZKP
FHE는 누구나 암호화된 데이터에 대해 임의의 계산을 수행할 수 있게 하지만, ZKP는 기저 정보를 노출하지 않고도 어떤 사실이 참임을 증명할 수 있게 한다. 그렇다면 이 둘은 어떻게 관련될까?
FHE와 ZKP는 세 가지 핵심 방식으로 결합된다:
1. 사용자는 입력 암호문이 올바른 형식임을 증명해야 한다. 즉 암호문이 암호화 방식의 요구사항을 충족하며 임의의 데이터 문자열이 아니라는 것을 의미한다.
2. 사용자는 입력 평문이 주어진 애플리케이션의 조건을 충족함을 증명해야 한다. 예를 들어 계정 잔액이 송금 금액보다 크다.
3. 검증 노드(즉 연산 당사자)는 FHE 연산을 올바르게 실행했음을 증명해야 한다. 이를 "검증 가능한 FHE(Verifiable FHE)"라고 하며 롤업에 필요한 ZKP에 비유할 수 있다.
ZKP의 활용을 더 깊이 탐색하기 위해:
1. 암호문의 ZKP
FHE는 격자 기반(lattice-based) 암호학에 기반한다. 즉 암호 원시 요소의 구성은 격자(lattice)를 포함하며, 이 격자들은 포스트양자(post-quantum) 보안이다. 반면 SNARKs, STARKs, Bulletproofs와 같은 인기 있는 ZKP는 격자 기반 암호학에 의존하지 않는다.
사용자의 FHE 암호문 형식이 올바름을 증명하기 위해, 우리는 그것이 고리(rings)의 원소(entries)로 구성된 행렬-벡터 방정식을 충족하며, 그 원소들의 수치가 작다는 것을 보여야 한다. 본질적으로 격자 기반 관계(lattice-based relations) 처리에 특화되고 체인 상 검증 비용 효율이 높은 증명 시스템이 필요하며, 이는 아직 열린 연구 분야다.
2. 평문 입력의 ZKP
형식이 올바른 암호문을 증명하는 것 외에도, 사용자는 입력 평문이 애플리케이션 요구사항을 충족함을 증명해야 한다. 다행히도 이전 단계와 달리, 우리는 사용자 입력의 유효성을 증명하기 위해 일반적인 SNARKs를 활용할 수 있으므로 개발자는 기존의 ZKP 방식, 라이브러리 및 인프라를 활용할 수 있다.
그러나 도전 과제는 이 두 증명 시스템을 "연결"해야 한다는 점이다. 연결한다는 것은 사용자가 두 증명 시스템에 동일한 입력을 사용했음을 보장해야 한다는 의미다. 그렇지 않으면 악의적인 사용자가 프로토콜을 속일 수 있다. 여기서 다시 강조하지만, 이것은 극도로 어려운 암호학적 업적이며 초기 연구의 열린 분야다.
Sunscreen은 이를 위한 기반을 마련했는데, 그들의 ZKP 컴파일러는 SDLP와 가장 쉽게 연결되기 때문에 Bulletproofs를 지원한다. FHE와 ZKP 컴파일러를 "연결"하는 연구도 지속적으로 진행 중이다.
Mind Network는 ZKP 통합을 선도하며, 안전한 계산을 위해 FHE를 활용하면서 동시에 제로트러스트 입력과 출력을 보장하고 있다.
3. 올바른 연산의 ZKP
기존 하드웨어에서 실행되는 FHE는 극도로 비효율적이고 비용이 많이 든다. 우리가 이전에 본 확장성 삼각난제의 동적 표현처럼, 노드 리소스 요구량이 높은 네트워크는 충분한 탈중앙화 수준으로 확장할 수 없다. 가능한 해결책 중 하나는 "검증 가능한 FHE(Verifiable FHE)"라는 프로세스로, 연산 당사자(검증자)가 거래의 성실한 실행을 증명하기 위해 ZKP를 제출한다.
검증 가능한 FHE의 초기 프로토타입은 SherLOCKED라는 프로젝트를 통해 보여줄 수 있다. 본질적으로 FHE 연산은 Risc ZERO의 Bonsai zkVM에 로드되며, 이 VM은 체인 외부에서 암호화된 데이터 상의 연산을 처리하고 ZKP와 함께 결과를 반환하며 체인 상 상태를 업데이트한다.
최근 FHE 협력 프로세서를 활용한 사례로 Aztec의 체인 상 경매 데모를 들 수 있다. 우리가 이전에 논의했듯이, 기존 FHE 체인은 전체 상태를 임계값 키로 암호화하므로 시스템의 강도는 임계값 위원회(threshold committee)에만 의존한다. 반면 Aztec에서는 사용자가 자신의 데이터를 소유하므로 임계값 보안 가정의 제약을 받지 않는다.
마지막으로, 개발자가 어디서 먼저 FHE 애플리케이션을 구축할 수 있는지 이해하는 것이 중요하다. 개발자는 FHE 지원 L1, FHE 롤업에서 애플리케이션을 구축하거나, 어떤 EVM 체인에서도 구축하고 FHE 협력 프로세서를 활용할 수 있다. 각 설계는 자체적인 트레이드오프를 가지지만, 우리는 Fhenix가 개척한 설계가 잘 된 FHE 롤업이나 FHE 협력 프로세서를 선호한다. 이들은 이더리움으로부터 보안 등의 다른 이점을 물려받기 때문이다.
최근까지 FHE 암호화 데이터 상에서 사기 증명(fraud proof)을 구현하는 것은 복잡했지만, 최근 Fhenix.io 팀은 Arbitrum Nitro 스택과 FHE 로직을 WebAssembly로 컴파일하여 사기 증명을 어떻게 구현할 수 있는지를 보여주었다.
FHE의 데이터 가용성(DA) 계층
도전: 맞춤화 및 처리량 부족
Web2에서는 "스토리지"가 상품화되었지만 Web3에서는 그렇지 않다. 전형동형암호(FHE)는 10,000배 이상의 데이터 팽창을 유지한다는 점을 고려하면, 방대한 FHE 암호문을 어디에 저장할지 결정해야 한다. 주어진 DA 계층의 각 노드 운영자가 모든 FHE 체인의 데이터를 다운로드하고 저장해야 한다면, 기관 운영자만이 수요를 따라갈 수 있어 중심화 위험이 증가한다.
처리량 측면에서 Celestia의 최고 속도는 6.7MB/s인데, FHEML 형태를 실행하려면 초당 수 GB의 대역폭이 필요하다. 1k(x)가 최근 공유한 데이터에 따르면, 설계 결정이 처리량을 제한하기 때문에(의도적으로), 기존 DA 계층은 FHE를 지원할 수 없다.
해결책: 수평 확장 + 맞춤화
우리는 수평 확장을 지원할 수 있는 DA 계층이 필요하다. 기존 DA 아키텍처는 모든 데이터를 네트워크의 각 노드에 전파하므로 확장성의 주요 제한 요인이 된다. 반대로 더 많은 DA 노드가 시스템에 들어올수록 수평 확장은 각 노드가 저장하는 데이터 양을 줄이며, 더 많은 블록 공간이 사용 가능해짐에 따라 성능과 비용이 개선된다.
또한 FHE 관련 대량 데이터의 크기를 고려할 때, 개발자에게 더 높은 수준의 소거 부호화(erasure coding) 임계값 맞춤화를 제공하는 것이 의미 있다. 즉, 개발자는 DA 시스템에 대해 어느 정도의 보장을 원하는가? 지분 기반 가중치인지, 탈중앙화 기반 가중치인지.
EigenDA의 아키텍처는 FHE의 DA 계층 가능성의 기반이 될 수 있다. 수평 확장성, 구조적 비용 절감, DA와 컨센서스의 분리 등은 FHE를 지원할 수 있는 확장성 수준을 위한 길을 열어준다.
마지막으로, 더 높은 차원의 아이디어는 암호문이 특정 인코딩 방식을 따르므로 최적화된 저장 슬롯을 구축하는 것이 될 수 있다. 최적화된 저장 슬롯은 저장 공간을 효율적으로 사용하고 더 빠른 검색을 도울 수 있다.
전형동형암호(FHE) 하드웨어
도전: 낮은 성능의 전형동형암호(FHE) 하드웨어
체인 상 전형동형암호(FHE) 애플리케이션의 보급에서 주요 문제는 계산 오버헤드로 인한 상당한 지연이며, 이는 어떤 표준 처리 하드웨어에서도 FHE를 실행하는 것을 비실용적으로 만든다. 이 제한은 프로세서가 거대한 데이터량을 처리해야 하기 때문에 메모리와의 상호작용이 많기 때문이며, 메모리 상호작용 외에도 복잡한 다항식 계산과 시간이 많이 소요되는 암호문 유지 작업도 상당한 오버헤드를 발생시킨다.
FHE 가속기의 현황을 깊이 이해하기 위해 구체적인 설계를 밝혀야 한다: 애플리케이션 특화 FHE 가속기 vs 범용 FHE 가속기.
FHE의 계산 복잡성과 하드웨어 설계의 핵심은 주어진 애플리케이션이 필요로 하는 곱셈 수(즉 "동형 연산의 깊이")와 항상 관련된다. 특정 애플리케이션의 경우 깊이는 알려져 있으므로 시스템 파라미터와 관련 계산은 고정된다. 따라서 애플리케이션 특화 하드웨어 설계는 더 쉽고 일반적으로 범용 가속기 설계보다 더 나은 성능을 최적화할 수 있다. 일반적으로 FHE가 임의의 곱셈 수를 지원해야 하는 경우, 동형 연산 중 누적되는 노이즈를 제거하기 위해 부트스트래핑 기술을 도입해야 한다. 부트스트래핑 기술은 비용이 많이 들며 칩 메모리, 메
TechFlow 공식 커뮤니티에 오신 것을 환영합니다
Telegram 구독 그룹:https://t.me/TechFlowDaily
트위터 공식 계정:https://x.com/TechFlowPost
트위터 영어 계정:https://x.com/BlockFlow_News
