모든 길은 MPC로 통할까요? 개인 정보 보호 인프라의 최종 게임 살펴보기

저자: EQ Labs 출처: 이퀼리브리엄 번역: 굿오바, 골든파이낸스

프라이버시 시리즈 1편에서는 프라이버시의 의미, 블록체인 네트워크에서 프라이버시가 웹2.0 프라이버시와 어떻게 다른지, 블록체인에서 프라이버시를 달성하기 어려운 이유를 소개했습니다. ', 프라이버시의 의미, 블록체인 네트워크에서의 프라이버시가 웹2.0 프라이버시와 어떻게 다른지, 블록체인에서 프라이버시를 달성하기 어려운 이유에 대해 소개했습니다.

이 글의 요점은 이상적인 최종 상태가 단일 장애 지점 없이 공유된 개인 상태를 처리할 수 있는 프로그래밍 가능한 프라이버시 인프라를 갖추는 것이라면 모든 길은 MPC로 이어진다는 것입니다. 또한 MPC의 성숙도와 신뢰 가정을 살펴보고, 대안을 강조하며, 장단점을 비교합니다. 그리고 업계 개요를 제공합니다.

과거에서 벗어나 미래를 포용하기

블록체인의 기존 개인정보 보호 인프라는 개인 결제나 투표와 같은 매우 특정한 사용 사례를 처리하도록 설계되었습니다. 이는 현재 블록체인의 용도(거래, 송금, 투기)를 주로 반영하는 다소 편협한 관점입니다. 톰 월포의 말처럼 암호화폐는 페르미 역설에 시달리고 있습니다.

개인정보 보호는 개인의 자유를 증진하는 것 외에도 현재의 투기적 메타데이터를 넘어 블록체인 설계 공간을 확장하기 위한 전제 조건으로 간주됩니다. 많은 애플리케이션이 제대로 작동하려면 일부 비공개 상태 및/또는 숨겨진 로직이 필요합니다.

• 숨겨진 상태: 대부분의 금융 사용 사례에서 는 다른 사용자에게 (최소한) 비밀로 유지되어야 하며, 많은 멀티플레이어 게임은 숨겨진 상태(예: 포커 테이블의 모든 사람이 서로의 카드를 볼 수 있는 경우)가 없으면 훨씬 덜 흥미롭습니다.

• 숨겨진 로직: 매칭 엔진, 온체인 트레이딩 전략 등 일부 로직을 숨기면서도 다른 사용자가 앱을 사용할 수 있도록 해야 하는 사용 사례도 있습니다.

경험적 분석(웹2와 웹3에서)에 따르면 대부분의 사용자는 개인정보 보호를 위해 추가 비용을 지불하거나 추가 세션을 건너뛸 의향이 없으며, 개인정보 보호 자체가 판매 포인트가 아니라는 데 동의합니다. 그러나 프라이버시는 블록체인 위에 새롭고 (희망적으로) 더 의미 있는 사용 사례가 존재할 수 있게 해주며, 페르미의 역설에서 벗어날 수 있게 해줍니다.

개인정보 보호 강화 기술(PET)과 최신 암호화 솔루션 ("프로그래머블 암호화")은 이 비전을 실현하기 위한 기본 구성 요소입니다("프로그래머블 암호화"). 사용 가능한 다양한 솔루션과 그 장단점에 대한 자세한 내용은 부록을 참조하세요).

우리의 견해에 영향을 미치는 세 가지 가정

블록체인 개인정보 보호 인프라의 발전 방식에 대한 우리의 견해를 결정하는 세 가지 주요 가정:

1. 암호화가 애플리케이션 개발자로부터 추상화될 것이다: 대부분의 애플리케이션 개발자는 프라이버시를 처리하는 데 필요한 암호화를 원하지 않거나 어떻게 처리해야 할지 모릅니다. 이들이 자체 암호화를 구현하고 퍼블릭 체인 위에 프라이빗 앱 전용 체인(예: Zcash 또는 나마다)이나 프라이빗 앱(예: 토네이도 캐시)을 구축하기를 기대하는 것은 무리한 요구입니다. 이는 너무 복잡하고 오버헤드가 너무 많으며 현재 대부분의 개발자(특정 프라이버시 보장이 필요한 애플리케이션을 구축할 수 없는)의 설계 공간을 제한합니다. 따라서 암호화 구성 요소 관리의 복잡성은 애플리케이션 개발자로부터 추상화되어야 한다고 생각합니다. 여기서 두 가지 접근 방식은 프로그래밍 가능한 프라이버시 인프라(공유 프라이빗 L1/L2) 또는 비밀 계산의 아웃소싱을 허용하는 "서비스로서의 비밀"입니다.

2. 많은 사용 사례(아마도 생각보다 많을 것)에서 공유 비공개 상태가 필요합니다. 앞서 언급한 것처럼, 많은 애플리케이션이 제대로 작동하려면 일부 숨겨진 상태 및/또는 로직이 필요합니다. 공유 비공개 상태는 여러 당사자가 동일한 비공개 상태에서 계산하는 하위 집합입니다. 중앙화된 당사자가 이 작업을 대신 처리해 줄 것을 믿고 맡길 수도 있지만, 이상적으로는 단일 장애 지점을 피하기 위해 신뢰를 최소화하는 방식으로 이 작업을 수행하는 것이 좋습니다. 영지식 증명(ZKP)만으로는 이를 달성할 수 없으며, 신뢰할 수 있는 실행 환경(TEE), 완전 동형 암호화(FHE), 다자간 컴퓨팅(MPC)과 같은 다른 도구를 활용해야 합니다.

3. 마스킹 세트가 클수록 프라이버시 극대화: 대부분의 정보는 마스킹 세트에 들어오고 나갈 때 손상되므로 이를 최소화해야 합니다. 동일한 블록체인에 여러 개의 비공개 앱을 구축하면 동일한 차단 세트 내에서 사용자와 트랜잭션 수를 늘려 개인 정보 보호 기능을 강화할 수 있습니다.

개인정보 보호 인프라의 끝

위의 가정을 고려할 때, 블록체인 개인정보 보호 인프라의 궁극적인 목표는 무엇일까요? 모든 애플리케이션에 적용할 수 있는 단일화된 접근 방식이 있을까요? 모든 앱을 통합할 수 있는 개인정보 보호 강화 기술이 있을까요?

정확히는 아닙니다. 이들 모두는 서로 다른 장단점을 가지고 있으며, 다양한 방식으로 조합되는 것을 보았습니다. 전반적으로 11가지 접근 방식을 확인했습니다.

현재 블록체인에서 개인정보 보호 인프라를 구축하는 데 가장 많이 사용되는 두 가지 접근 방식은 ZKP 또는 FHE를 활용하는 것입니다. 하지만 두 가지 모두 근본적인 결함이 있습니다.

• 클라이언트 증명이 있는 ZK 기반 프라이버시 프로토콜은 강력한 프라이버시를 보장하지만, 여러 당사자가 동일한 프라이빗 상태에서 계산하는 것을 허용하지 않습니다. 따라서 개발자가 구축할 수 있는 애플리케이션 유형에 대한 표현력이 제한됩니다.

• FHE는 암호화된 데이터와 공유 개인 상태에 대한 연산을 지원하지만, 누가 상태를 '소유'하는지, 즉 누가 암호 해독 키를 소유하는지에 대한 의문을 제기합니다. 이는 프라이버시 보장의 강도를 제한하고, 오늘 사적인 것이 내일도 여전히 사적인 것이라고 믿을 수 있는 정도를 제한합니다.

이상적인 최종 상태가 단일 장애 지점 없이 공유 개인 상태를 처리할 수 있는 프로그래밍 가능한 개인 정보 인프라를 보유하는 것이라면, 두 경로 모두 MPC로 이어집니다:

두 접근 방식은 결국 수렴하게 되지만 MPC는 서로 다른 용도로 사용됩니다.

• ZKP 네트워크: MPC는 공유된 개인 상태의 계산을 가능하게 하여 표현력을 추가합니다.

• FHE 네트워크: MPC는 암호 해독 키를 단일 제3자가 아닌 MPC 위원회에 배포하여 보안을 강화하고 개인 정보 보호를 강화합니다.

논의가 보다 미묘한 견해로 나아가고 있지만, 이러한 다양한 접근 방식의 이면에 있는 보안 보장은 아직 충분히 탐구되지 않은 상태입니다. 우리의 신뢰 가정이 MPC의 가정으로 귀결된다는 점을 감안할 때, 다음과 같은 세 가지 핵심 질문이 필요합니다.

1. 블록체인에서 MPC 프로토콜이 제공할 수 있는 프라이버시 보장은 얼마나 강력한가?

2. 기술이 충분히 성숙했나요? 충분하지 않다면 병목 현상은 무엇인가요?

3. 보증의 강도와 이로 인해 발생하는 오버헤드를 고려할 때 다른 접근 방식에 비해 합당한가요?

이 질문에 좀 더 자세히 답해 보겠습니다.

MPC로 위험 및 취약성 분석

솔루션에서 FHE를 사용할 때마다 항상 "누가 암호 해독 키를 가지고 있는가?"라는 질문을 던져야 합니다. " . 대답이 "네트워크"라면, 후속 질문은 "네트워크를 구성하는 실제 엔티티는 무엇인가?"입니다. . 후자의 질문은 어떤 형태로든 MPC에 의존하는 모든 사용 사례와 관련이 있습니다.

출처:Zama의 ETH CC 강연

MPC의 주요 위험은 충분한 참여자가 악의적으로 공모하여 데이터를 해독하거나 계산을 도용하는 담합입니다. 담합은 오프체인에서 합의할 수 있으며, 악의적인 당사자가 명백한 행동(갈취, 허공에서 토큰을 발행하는 등)을 취할 때만 드러납니다. 말할 필요도 없이, 이는 시스템이 제공할 수 있는 프라이버시 보장에 중대한 영향을 미칩니다. 담합의 위험은 다음에 따라 달라집니다.

• 프로토콜이 얼마나 많은 악의적인 당사자를 견딜 수 있는가?

• 네트워크를 구성하는 당사자들은 어떤 사람들인가요? 얼마나 신뢰할 수 있나요?

• 네트워크에 참여하는 다양한 당사자의 수와 분포 - 공통적인 공격 벡터가 있나요?

• 네트워크 라이선스가 필요 없는가, 아니면 라이선스가 필요한가(금전적 이익 대 평판/법적 근거)?

• 악의적인 행위에 대한 처벌은 어떻게 되나요? 담합 게임은 이론적으로 최적의 결과인가요?

1. 블록체인에서 MPC 프로토콜이 제공할 수 있는 프라이버시 보장은 얼마나 강력하나요?

TLDR: 우리가 원하는 만큼 강력하지는 않지만, 중앙화된 제3자에 의존하는 것보다는 강력합니다.

복호화에 필요한 임계값은 선택한 MPC 체계에 따라 달라지며, 이는 활동성("보장된 출력 전달")과 보안 간의 절충점입니다. N/N 방식은 매우 안전하지만, 한 노드가 오프라인 상태가 되면 곧바로 충돌이 발생합니다. 반면에 N/2 또는 N/3 방식은 더 견고하지만 담합의 위험이 더 높습니다.

균형을 맞춰야 하는 두 가지 조건은 다음과 같습니다.

1. 비밀 정보가 절대 손상되지 않습니다(예: 암호 해독 키).

2. 비밀 정보는 절대 사라지지 않습니다(참가자의 1/3이 갑자기 탈퇴하더라도).

선택된 옵션은 구현에 따라 다릅니다. 예를 들어, Zama는 N/3을 목표로 하고 있으며, Arcium은 현재 N/N 방식을 구현하고 있지만 추후 더 높은 활동 보장(그리고 더 큰 신뢰 가정)을 가진 방식을 지원할 예정입니다.

이 절충안은 하이브리드 솔루션을 선택하는 것입니다.

• 높은 신뢰 위원회를 사용하여 예를 들어 N/3 임계값으로 키를 처리할 수 있습니다.

• 계산 위원회는 예를 들어 N-1 임계값(또는 사용자가 선택할 수 있는 서로 다른 특성을 가진 여러 계산 위원회)으로 순환됩니다.

이론적으로는 매력적이지만, 계산 위원회가 높은 신뢰 위원회와 상호작용하는 방식과 같은 추가적인 복잡성을 야기하기도 합니다.

보안성을 강화하는 또 다른 방법은 신뢰할 수 있는 하드웨어 내에서 MPC를 실행하여 키 공유가 안전한 영역에 보관되도록 하는 것입니다. 이렇게 하면 프로토콜 정의 이외의 다른 용도로 키 공유를 추출하거나 사용하는 것이 훨씬 더 어려워집니다. 적어도 Zama와 Arcium은 TEE 각도를 탐구하고 있습니다.

더 미묘한 위험에는 예를 들어 MPC 클러스터의 모든 회사가 10년에서 15년 이상 선임 엔지니어를 고용하고 있는 사회 공학 같은 에지 케이스가 포함됩니다.

2. 기술이 충분히 성숙했나요? 그렇지 않다면 병목 현상은 무엇인가요?

성능 관점에서 볼 때 MPC의 핵심 과제는 통신 오버헤드입니다. 이는 계산의 복잡성과 네트워크의 노드 수에 따라 증가합니다(더 많은 양방향 통신이 필요함). 블록체인 사용 사례의 경우 이는 두 가지 실질적인 의미를 갖습니다.

1. 소규모 연산자 집합: 통신 오버헤드를 관리하기 위해 현재 대부분의 기존 프로토콜은 소규모 연산자 집합으로 제한되어 있습니다. 예를 들어, Zama의 암호 해독 네트워크는 현재 최대 4개의 노드만 허용합니다(16개까지 확장할 계획이지만). Zama가 복호화 네트워크(TKMS)에 대해 발표한 초기 벤치마크에 따르면, 4개의 노드로만 구성된 클러스터에서도 복호화에 0.5~1초가 소요됩니다(전체 e2e 프로세스는 훨씬 더 오래 걸립니다). 또 다른 예로 3명의 당사자(정직한 당사자가 2/3라고 가정)가 있는 Worldcoin의 홍채 데이터베이스를 위한 Taceo의 MPC 구현을 들 수 있습니다.

   출처:Zama의 ETH CC 발표

2. 

3. 라이선스된 오퍼레이터 세트: 대부분의 경우 오퍼레이터 세트는 라이센스가 부여됩니다. 이는 경제적 또는 암호학적 보안보다는 평판과 법적 계약에 의존한다는 의미입니다. 라이선스가 없는 오퍼레이터 세트의 가장 큰 문제점은 사람들이 체인에서 담합을 하고 있는지 알 방법이 없다는 것입니다. 또한, 노드가 네트워크에 동적으로 들어오고 나갈 수 있도록 주기적인 부트스트랩 또는 키 공유의 재분배가 필요합니다. 무허가 운영자 세트가 궁극적인 목표이며 임계값 MPC(예: 자마)를 활성화하기 위해 지분 증명 메커니즘을 확장하는 연구가 진행 중이지만, 현재로서는 허가된 경로가 가장 좋은 방법인 것으로 보입니다.

대안

전체 개인정보 보호 포트폴리오는 다음을 포함합니다:

• 개인정보 보호 계산 위임을 위한 FHE

• FHE 계산이 올바르게 수행되었는지 확인하기 위한 ZKP

• : 왼쪽;">임계값 암호 해독을 위한 MPC

• 보안 강화를 위해 각 MPC 노드가 TEE 내부에서 실행

복잡하고, 미개척 극단을 많이 도입하며, 오버헤드가 많고 앞으로 수년 동안은 실질적으로 실현되지 않을 수도 있습니다. 또 다른 위험은 사람들이 여러 가지 복잡한 개념을 겹겹이 쌓아 올려 잘못된 보안 의식을 갖게 될 수 있다는 것입니다. 더 많은 복잡성과 신뢰 가정을 추가할수록 전체 솔루션의 보안을 추론하기가 더 어려워집니다.

이만한 가치가 있을까요? 그만한 가치가 있을 수도 있지만, 개인정보 보호가 약간만 약해져도 계산 효율성이 크게 향상될 수 있는 다른 접근 방식도 살펴볼 가치가 있습니다. Seismic의 Lyron이 지적한 것처럼, 프라이버시를 위한 과도한 엔지니어링보다는 원하는 수준의 프라이버시와 허용 가능한 트레이드오프에 대한 기준을 충족하는 가장 간단한 솔루션에 집중해야 합니다.

1. 일반 계산에 직접 MPC 사용

ZK와 FHE가 궁극적으로 MPC의 신뢰 가정에 의존한다면, 계산에 직접 MPC를 사용하지 않는 이유는 무엇일까요? 이는 정당한 질문이며 Arcium, SodaLabs(Coti v2에서 사용), Taceo, Nillion과 같은 팀에서 시도하고 있는 작업입니다. MPC는 다양한 형태로 제공되지만, 여기서는 세 가지 주요 접근 방식 중 복호화를 위해 MPC를 사용하는 FHE 기반 프로토콜보다는 비밀 공유와 글리치 회로(GC)에 기반한 프로토콜을 언급하고자 합니다.

분산 서명이나 보다 안전한 지갑과 같은 간단한 연산에는 MPC가 사용되었지만, 보다 일반적인 연산에 MPC를 사용할 때 가장 큰 문제는 통신 오버헤드(연산 복잡성과 관련 노드 수에 따라 증가)입니다.

전처리(즉, 프로토콜에서 가장 비용이 많이 드는 부분)를 오프라인에서 미리 수행하는 등 오버헤드를 줄이는 방법이 있으며, 이는 Arcium과 SodaLabs에서 연구 중입니다. 그런 다음 계산은 오프라인 단계에서 생성된 데이터의 일부를 소비하는 온라인 단계에서 수행됩니다. 이렇게 하면 전반적인 통신 오버헤드가 크게 줄어듭니다.

다음 표는 SodaLabs의 초기 벤치마크로, gcEVM에서 다양한 연산 코드를 1,000회 수행하는 데 걸리는 시간(마이크로초 단위)을 보여줍니다. 이는 올바른 방향으로 나아가는 단계이지만, 효율성을 개선하고 연산자 집합을 몇 노드 이상으로 확장하기 위해 아직 해야 할 일이 많이 남아있습니다.

출처: SodaLabs

ZK 기반 접근 방식의 장점은 공유된 개인 상태에서 계산해야 하는 사용 사례에만 MPC를 사용한다는 것입니다. fHE는 MPC와 더 직접적으로 경쟁하며 하드웨어 가속에 크게 의존합니다.

2. 신뢰할 수 있는 실행 환경

최근 TEE에 대한 관심이 다시 높아지고 있는데, 단독으로(TEE 기반 프라이빗 블록체인 또는 코프로세서) 또는 ZK 기반 솔루션과 같은 다른 PET와 조합하여(ZK) 사용하기도 합니다. ZK 기반 솔루션) 또는 다른 PET(예: ZK 기반 솔루션)와 결합하여(공유 프라이빗 상태 계산에만 TEE 사용) 사용합니다.

TEE는 어떤 면에서 더 성숙하고 성능 오버헤드가 적지만, 단점이 없는 것은 아닙니다. 첫째, TEE는 신뢰 가정(1/N)이 다르며 소프트웨어 기반이 아닌 하드웨어 기반 솔루션을 제공합니다. SGX의 과거 취약성에 대한 비판이 자주 들리지만, TEE ≠ 인텔 SGX는 하드웨어 제공업체에 대한 신뢰가 필요하며, 이는 대부분의 사람들이 감당할 수 없는 고가의 비용이라는 점에 주목할 필요가 있습니다. 물리적 공격의 위험에 대한 한 가지 해결책은 미션 크리티컬한 작업을 위해 우주에서 TEE를 실행하는 것일 수 있습니다.

전반적으로 TEE는 단기적인 프라이버시만 필요한 증명이나 사용 사례(임계값 암호 해독, 다크 원장 등)에 더 적합한 것으로 보입니다. 영구적이거나 장기적인 개인 정보 보호의 경우 보안이 덜 매력적으로 보입니다.

3. 프라이빗 DAC 및 신뢰할 수 있는 제3자에 의존하여 개인정보를 보호하는 기타 접근 방식

중개자 프라이버시는 다른 사용자의 접근으로부터 개인정보를 제공할 수 있지만 개인정보 보장은 전적으로 제3자에 대한 신뢰(단일 장애 지점)에서 파생됩니다. 프라이버시 보장은 전적으로 제3자에 대한 신뢰(단일 실패 지점)에서 비롯됩니다. "웹2 프라이버시"(다른 사용자로부터의 프라이버시)와 유사하지만 추가 보장(암호화 또는 경제성)을 통해 강화할 수 있으며 인증이 올바르게 수행될 수 있습니다.

개인 데이터 가용성 위원회(DAC)가 한 예로, DAC 회원은 체인에 데이터를 저장하고 사용자는 데이터를 올바르게 저장하고 상태 전환 업데이트를 수행한다고 신뢰합니다. 또 다른 형태는 톰 월포가 제안한 공인 시퀀서입니다.

이 접근 방식은 프라이버시 보장 측면에서 상당한 장단점이 있지만, 비용과 성능 측면에서 (적어도 현재로서는) 저가치 고성능 애플리케이션을 위한 유일한 대안이 될 수 있습니다. 예를 들어, 렌즈 프로토콜은 프라이빗 메시지 스트리밍에 프라이빗 DAC를 사용할 계획입니다. 온체인 소셜과 같은 사용 사례의 경우, (다른 대안의 비용과 오버헤드를 고려할 때) 프라이버시와 비용/성능 간의 절충이 현재로서는 합리적일 수 있습니다.

4. 스텔스 주소 지정

스텔스 주소 지정은 각 트랜잭션에 새 주소를 만드는 것과 유사한 개인정보 보호를 제공하지만, 백엔드에서 프로세스가 자동화되며 사용자에게 공개적으로 제공되지 않습니다. 자세한 내용은 Vitalik의 개요 또는 다양한 접근 방식에 대해 자세히 설명하는 이 문서를 참조하세요. 스텔스 주소는 비교적 간단한 솔루션을 제공하지만, 일반적인 계산이 아닌 거래(결제 및 이체)에만 프라이버시 보장을 추가할 수 있다는 단점이 있습니다. 이 점이 위에서 언급한 다른 세 가지 솔루션과 차별화됩니다.

또한 스텔스 주소가 제공하는 프라이버시 보장은 다른 대안만큼 강력하지 않습니다. 특히 수신 및 발신 이체 금액이 비슷한 범위가 아닌 경우(예: 10,000달러를 받았지만 하루 평균 10~100달러를 거래에 사용한 경우) 간단한 클러스터 분석으로 익명성이 깨질 수 있습니다. 스텔스 주소의 또 다른 과제는 키를 업그레이드하는 것인데, 현재 각 지갑마다 별도의 업그레이드가 필요합니다(키스토어 통합이 도움이 될 수 있습니다). 사용자 경험 측면에서도 스텔스 주소 프로토콜은 계정에 수수료 토큰(예: 이더리움)이 없는 경우 계정 추상화자 또는 지불자가 수수료를 지불해야 합니다.

우리 주장의 위험

빠른 개발 속도와 다양한 기술 솔루션에 대한 일반적인 불확실성을 고려할 때 MPC가 궁극적인 해결책이 될 것이라는 우리의 주장에는 여러 가지 위험 요소가 있습니다. 어떤 형태의 MPC가 필요하지 않을 수 있는 주된 이유는 다음과 같습니다.

1. 개인 상태 공유가 생각만큼 중요하지 않음: 이 경우 ZK 기반 인프라가 더 유리할 수 있습니다. ZK 기반 인프라는 FHE보다 더 강력한 프라이버시 보장과 낮은 오버헤드를 제공하기 때문에 이 경우에 더 유리할 가능성이 높습니다. 이미 프라이빗 결제 프로토콜 Payy와 같이 격리된 사용 사례에서 ZK 기반 시스템이 잘 작동하는 사용 사례가 있습니다.

2. 성능 트레이드오프는 프라이버시 보장의 이점에 비해 가치가 없습니다: 라이센서가 2~3개인 MPC 네트워크의 신뢰 가정이 중앙화된 단일 참여자와 크게 다르지 않다고 주장할 수 있습니다. 참여자와 크게 다르지 않으며, 비용/오버헤드의 상당한 증가는 그만한 가치가 없다고 주장할 수 있습니다. 많은 애플리케이션, 특히 가치가 낮고 비용에 민감한 애플리케이션(예: 소셜 또는 게임)의 경우 이는 사실일 수 있습니다. 그러나 법적 문제나 높은 조정 마찰로 인해 협업이 현재 매우 비싸거나 불가능한 고부가가치 사용 사례도 많이 있습니다. 후자가 바로 MPC 및 FHE 기반 솔루션이 빛을 발할 수 있는 곳입니다.

3. 특화가 보편적 설계보다 우선: 새로운 체인을 구축하고 사용자 및 개발자 커뮤니티를 부트스트랩하는 것은 매우 어렵습니다. 그 결과, 보편적인 프라이버시 인프라(L1/L2)는 견인력을 확보하는 데 어려움을 겪을 수 있습니다. 또 다른 문제는 전문화와 관련된 것으로, 단일 프로토콜 설계로 모든 트레이드오프 영역을 커버하기는 어렵습니다. 이러한 환경에서는 기존 생태계(서비스로서의 기밀성) 또는 특수한 사용 사례(예: 결제)에 대한 프라이버시를 제공하는 솔루션이 우세할 것입니다. 그러나 애플리케이션 개발자가 암호화를 추상화하지 않고 직접 구현해야 하는 복잡성 때문에 후자에 대해서는 회의적인 시각을 가지고 있습니다.

4. 규제는 개인정보 보호 솔루션의 실험을 계속 방해하고 있으며, 이는 개인정보 보호 인프라 및 일부 개인정보 보호 기능을 갖춘 앱을 구축하는 모든 사람에게 위험 요소로 작용합니다. 비금융 사용 사례는 규제 위험이 덜하지만, 라이선스가 필요하지 않은 개인정보 보호 인프라 위에 구축된 것을 제어하기는 어렵습니다(불가능). 규제 문제를 해결하기 전에 기술 문제를 먼저 해결해야 할 가능성이 높습니다.

5. MPC 및 FHE 기반 솔루션의 오버헤드는 대부분의 사용 사례에서 여전히 너무 높습니다. MPC는 대부분 통신 오버헤드로 인해 어려움을 겪는 반면, FHE 팀은 성능 향상을 위해 하드웨어 가속에 크게 의존하고 있습니다. 하지만 ZK 측의 전용 하드웨어 개발을 추정해 보면, 프로덕션에 사용할 수 있는 FHE 하드웨어가 나오기까지는 대부분의 사람들이 생각하는 것보다 훨씬 더 오랜 시간이 걸릴 것입니다. FHE 하드웨어 가속을 연구하는 팀으로는 Optalysys, fhela, Niobium 등이 있습니다.

개요

결국 체인의 강도는 가장 약한 링크에 따라 달라집니다. 프로그래밍 가능한 프라이버시 인프라의 경우, 단일 장애 지점 없이 공유된 개인 상태를 처리할 수 있기를 원한다면 신뢰 보장은 MPC 보장으로 귀결됩니다.

이 글은 MPC에 대해 비판적으로 들리지만, 그렇지 않으며 MPC는 현재 중앙화된 제3자에 대한 의존도를 크게 개선한 것입니다. 가장 큰 문제는 업계 전반에 잘못된 신뢰감이 퍼져 있어 문제가 가려지고 있다는 점이라고 생각합니다. 그 대신 문제를 정면으로 마주하고 잠재적 위험을 평가하는 데 집중해야 합니다.

그러나 모든 문제를 동일한 도구로 해결할 필요는 없습니다. MPC가 궁극적인 목표라고 생각하지만, MPC 기반 솔루션의 오버헤드가 여전히 높은 한 다른 접근 방식도 실행 가능한 옵션입니다. 해결하고자 하는 문제의 특정 요구사항/특성에 가장 적합한 접근 방식이 무엇인지, 그리고 어떤 절충점을 감수할 수 있는지 항상 고려하는 것이 좋습니다.

세상에서 가장 좋은 망치를 가지고 있다고 해도 모든 것이 반드시 못을 박는 것은 아닙니다.