비탈릭 부테린: zk-SNARKs 기술을 사용하여 개인 정보를 보호하는 방법?

저자: Vitalik Buterin

원문 제목: 《Some ways to use ZK-SNARKs for privacy》

편집: 탈중앙화 금융 커뮤니티

ZK-SNARK는 강력한 암호화 도구로, 블록체인 및 블록체인 외부에서 구축된 애플리케이션에서 점점 더 중요한 부분이 되고 있습니다. 그러나 그것들은 복잡하며, 그것들이 어떻게 작동하는지, 그리고 우리가 그것을 어떻게 사용하는지에 대한 관점에서 복잡합니다.

이 글은 ZK-SNARK가 기존 애플리케이션에 어떻게 적응하는지, 그것들이 무엇을 할 수 있는지, 할 수 없는지에 대한 예시와 ZK-SNARK가 특정 애플리케이션에 적합한지 판단하기 위한 일반적인 지침을 다룰 것입니다.

이 글은 특히 ZK-SNARK의 개인 정보 보호에 대한 응용에 초점을 맞춥니다.

ZK-SNARK는 무엇을 할 수 있나요?

공공 입력 x, 개인 입력 w, 그리고 입력에 대해 어떤 검증을 수행하는 (공공) 함수 f (x,w)→{True,False}가 있다고 가정해 보겠습니다. ZK-SNARK를 사용하면, 특정 f와 x에 대해 f (x,w)=True인 w를 알고 있다는 것을 증명할 수 있으며, 이 과정에서 w가 무엇인지 드러내지 않습니다. 또한, 검증자는 증명을 더 빠르게 검증할 수 있으며, 이는 그들이 직접 f (x,w)를 계산하는 것보다 훨씬 빠릅니다.

이것은 ZK-SNARK에 두 가지 속성을 부여합니다: 개인 정보 보호와 확장성. 위에서 언급한 바와 같이, 이 글에서는 개인 정보 보호에 초점을 맞춘 예시를 다룰 것입니다.

자격 증명

당신이 이더리움 지갑을 가지고 있고, 이 지갑이 인류 증명(proof-of-humanity)에 등록되어 있다는 것을 증명하고 싶다고 가정해 보겠습니다. 그러나 등록된 사람이 누구인지 드러내고 싶지 않습니다. 우리는 이 함수를 수학적으로 설명할 수 있습니다:

• 개인 입력 (w): 당신의 주소 A, 당신의 주소 개인 키 k
• 공공 입력 (x): 모든 검증된 인류 증명 프로필 {H1…Hn}의 주소 집합
• 검증 함수 f (x,w)
• w를 (A，σ) 쌍으로 해석하고, x는 유효한 프로필 목록 {H1…Hn}
• A가 {H1…Hn} 중 하나의 주소인지 검증
• privtoaddr (k) = A인지 검증
• 두 검증이 모두 통과하면 True를 반환하고, 하나라도 실패하면 False를 반환

증명자는 그들의 주소 A와 관련된 키 k를 생성하고, w=(A,k)를 f의 개인 입력으로 제공합니다. 그들은 체인에서 공공 입력을 가져오며, 현재 검증된 인류 증명 프로필 집합 {H1…Hn}을 얻습니다. 그들은 ZK-SNARK 증명 알고리즘을 실행하며, 이 알고리즘은 (입력이 올바르다고 가정할 때) 증명을 생성합니다. 증명자는 증명을 검증자에게 보내고, 그들이 검증 프로필 목록을 얻은 블록 높이를 제공합니다.

검증자는 또한 체인을 읽고, 증명자가 지정한 높이의 목록 {H1…Hn}을 가져와 증명을 확인합니다. 검증이 통과하면, 검증자는 증명자가 어떤 검증된 인류 증명 파일을 가지고 있다고 믿게 됩니다.

더 복잡한 예시를 논의하기 전에, 위의 예시를 완전히 이해할 때까지 살펴보는 것을 강력히 권장합니다.

자격 증명을 더 효율적으로 만들기

위의 증명 시스템의 단점은 검증자가 전체 프로필 집합 {H1…Hn}을 알아야 하며, 이 프로필 집합을 ZK-SNARK 메커니즘에 "입력"하는 데 O(n) 시간이 걸린다는 것입니다.

우리는 모든 프로필을 포함하는 체인상의 Merkle 루트를 공공 입력으로 사용하여 이 문제를 해결할 수 있습니다 (이것은 단순히 상태 루트일 수 있습니다). 우리는 또 다른 개인 입력, Merkle 증명 M을 추가하여 증명자의 계정 A가 트리의 관련 부분에 있다는 것을 증명합니다.

ZK를 사용한 자격 증명을 위한 Merkle 증명의 매우 새롭고 더 효율적인 대안은 Caulk입니다. 앞으로 이러한 일부 사용 사례는 Caulk와 유사한 솔루션으로 이전될 수 있습니다.

ZK-SNARK와 화폐

Zcash와 Tornado.cash와 같은 프로젝트는 우리가 개인 정보를 보호하는 화폐를 가질 수 있게 해줍니다. 이제, 당신은 위의 "ZK 인류 증명"을 사용할 수 있다고 생각할 수 있지만, 그것은 인류 증명 프로필에 대한 접근을 증명하는 것이 아니라 화폐에 대한 접근을 증명하는 것입니다. 이제 우리는 개인 정보 보호와 이중 지불 문제를 동시에 해결해야 합니다. 즉, 우리는 화폐를 두 번 사용해서는 안 됩니다.

우리는 이렇게 해결합니다. 화폐를 가진 모든 사람은 개인 비밀 "s"를 가지고 있습니다. 그들은 로컬에서 "leaf" L=hash (s,1)을 계산하고, 이것은 체인에 게시되어 상태의 일부가 되며, N=hash (s,2)로 불리는 nullifier가 됩니다. 상태는 Merkle 트리에 저장됩니다.

화폐를 사용하려면, 발신자는 ZK-SNARK를 수행해야 하며, 여기서:

• 공공 입력은 nullifier N, 현재 또는 최근의 Merkle 루트 R, 그리고 새로운 leaf L'을 포함합니다 (목적은 수신자가 비밀 s'를 가지고 있으며 발신자에게 L' =hash (s',1)을 전달하는 것입니다)
• 개인 입력은 비밀 s, leaf L, 그리고 Merkle 분기 M을 포함합니다
• 검증 기능은 다음을 확인합니다:
• M이 R을 루트로 하는 트리의 leaf인 유효한 Merkle 분기인지 증명합니다
• hash (s,1)=L
• hash (s,2)=N

거래는 nullifier N과 새로운 leaf L'을 포함합니다. 우리는 실제로 L'에 대한 어떤 것도 증명하지 않지만, 거래가 진행되는 동안 제3자가 거래를 수정하지 못하도록 "혼합"합니다.

거래를 검증하기 위해, 체인은 ZK-SNARK를 확인하고, 추가로 N이 이전의 지출 거래에서 사용되었는지 확인합니다. 거래가 성공하면, N은 사용된 nullifier 집합에 추가되어 더 이상 사용될 수 없습니다. L'은 Merkle 트리에 추가됩니다.

이렇게 우리는 zk-SNARK를 사용하여 두 값을 연결합니다: L (화폐가 생성될 때 체인에 나타나는)과 N (화폐가 소비될 때 체인에 나타나는), 그리고 어떤 L이 어떤 N과 연결되어 있는지를 드러내지 않습니다. 두 값을 생성하는 비밀 s를 알고 있어야만 L과 N 사이의 관계를 발견할 수 있습니다. 생성된 각 화폐는 한 번만 사용될 수 있습니다 (각 L에 대해 유효한 N은 하나만 존재하므로), 그러나 특정 시간 내에 사용되는 화폐는 숨겨져 있습니다.

이것은 이해해야 할 중요한 원리이기도 합니다. 아래에서 설명할 많은 메커니즘은 이 원리를 기반으로 하고 있으며, 목적은 다르지만 말입니다.

임의 잔액의 화폐

위의 경우는 임의 잔액의 화폐로 쉽게 확장될 수 있습니다. 우리는 "화폐"의 개념을 유지하지만, 각 화폐는 (개인) 잔액이 첨부됩니다. 이를 달성하는 간단한 방법은 각 화폐가 체인에 저장되는 것이며, 단순히 leaf L뿐만 아니라 암호화된 잔액도 포함됩니다.

각 거래는 두 개의 화폐를 소모하고 두 개의 새로운 화폐를 생성하며, 두 쌍 (leaf, 암호화된 잔액)을 상태에 추가합니다. ZK-SNARK는 또한 입력 잔액의 합이 출력 잔액의 합과 같고, 두 출력의 잔액이 모두 비음수가 되도록 확인합니다.

ZK 반거부 서비스

흥미로운 반거부 서비스 도구입니다. 당신이 체인상의 신원을 가지고 있다고 가정해 보겠습니다. 이는 쉽게 생성할 수 없습니다; 이는 인류 증명 프로필일 수도 있고, 32개의 ETH 검증자일 수도 있으며, 단순히 비영(非零) ETH 잔액을 가진 계정일 수도 있습니다. 우리는 메시지 발신자가 프로필을 가지고 있다는 증명과 함께 메시지를 수락함으로써 DoS에 더 강한 점대점 네트워크를 만들 수 있습니다. 각 프로필은 매시간 최대 1000개의 메시지를 보낼 수 있으며, 발신자가 부정행위를 할 경우 발신자의 프로필은 목록에서 삭제됩니다. 그러나 우리는 개인 정보를 어떻게 보호할 수 있을까요?

먼저 설정을 살펴보겠습니다. k를 사용자의 개인 키로 설정합니다; A=privtoaddr (k)는 해당 주소입니다. 유효한 주소 목록은 공개되어 있습니다 (예: 체인상의 등록부). 지금까지는 인류 증명 예시와 유사합니다: 당신은 주소의 개인 키를 소유하고 있다는 것을 증명해야 하지만, 어떤 주소인지 드러내지 않아야 합니다. 그러나 여기서는 단순히 당신이 목록에 있다는 것을 증명하고 싶지 않습니다. 우리는 당신이 목록에 있다는 것을 증명할 수 있지만, 너무 많은 증명을 하지 못하도록 방지하는 프로토콜이 필요합니다.

우리는 시간을 여러 기간으로 나눌 것입니다: 각 기간은 3.6초 지속됩니다 (따라서 매시간 1000개의 기간이 있습니다). 우리의 목표는 각 사용자가 각 기간에 단 한 개의 메시지만 보낼 수 있도록 하는 것입니다; 만약 사용자가 같은 기간에 두 개의 메시지를 보낸다면, 그들은 포착될 것입니다. 사용자가 가끔 폭발적인 메시지를 보낼 수 있도록 허용하기 위해, 그들은 최근의 기간을 사용할 수 있습니다. 따라서 어떤 사용자가 500개의 미사용 기간을 가지고 있다면, 그들은 이 기간을 사용하여 한 번에 500개의 메시지를 보낼 수 있습니다.

프로토콜

우리는 nullifier를 사용하는 간단한 버전부터 시작합니다. 사용자는 N=hash (k,e)인 nullifier를 생성하며, 여기서 k는 그들의 키이고, e는 기간 번호입니다. 그리고 이를 메시지 m과 함께 게시합니다. ZK-SNARK는 다시 hash (m)을 혼합하며, 이 과정에서 m에 대한 어떤 것도 검증하지 않으므로 증명이 단일 메시지에 바인딩됩니다. 만약 사용자가 동일한 nullifier를 사용하여 두 개의 증명을 두 개의 다른 메시지에 바인딩한다면, 그들은 포착될 수 있습니다.

이제 우리는 더 복잡한 버전으로 넘어갑니다. 이 경우, 다음 프로토콜은 그들의 개인 키를 노출시키며, 단순히 누군가가 동일한 기간을 두 번 사용했는지를 증명하는 것이 아닙니다. 우리의 핵심 기술은 "두 점이 선을 이룬다"는 기술에 의존합니다: 만약 당신이 선 위에 한 점을 표시하면, 당신은 적은 것을 표시하지만, 만약 당신이 선 위에 두 점을 표시하면, 당신은 전체 선을 표시하게 됩니다.

각 기간 e에 대해, 우리는 직선 Le (x)=hash (k,e)∗x+k을 가져옵니다. 직선의 기울기는 hash (k,e)이며, y 절편은 k입니다; 두 값 모두 대중에게 알려져 있지 않습니다. 메시지 m에 대한 증명을 만들기 위해, 발신자는 y=Le (hash (m))= hash (k,e)∗hash (m)+k를 제공하며, y의 계산이 올바르다는 ZK-SNARK 증명을 제공합니다.

요약하자면, ZK-SNARK는 다음과 같습니다:

공공 입력:

• {A1…An}, 유효한 계정 목록
• M, 증명이 검증되고 있는 메시지
• E, 증명의 기간 번호
• Y, 선 함수의 평가

개인 입력:

• K, 당신의 개인 키

검증 기능:

• privtoaddr (k)가 {A1…An}에 있는지 확인
• y=hash (k,e)∗hash (m)+k인지 확인

하지만 누군가가 기간을 두 번 사용한다면 어떻게 될까요? 이는 그들이 두 개의 값 m1과 m2 및 해당 증명 값 y1=hash (k,e)∗hash (m1)+k와 y2=hash (k,e)∗hash (m2)+k를 공개했다는 것을 의미합니다. 우리는 이 두 점을 사용하여 직선을 복원할 수 있으며, 따라서 y 축 절편 (이는 개인 키입니다):

따라서 누군가가 기간을 재사용하면, 그들은 개인 키를 유출하게 되어 모든 사람이 볼 수 있게 됩니다. 상황에 따라, 이는 자금이 도난당할 수 있음을 의미하거나, 단순히 개인 키를 방송하고 스마트 계약에 포함되게 하여 해당 주소가 목록에서 삭제될 수 있습니다.

블록체인 점대점 네트워크, 채팅 애플리케이션 등 시스템에 적합한 실행 가능한 체인 외 익명 반거부 서비스 시스템은 작업 증명이 필요하지 않습니다. RLN 프로젝트는 현재 이 아이디어를 구축하고 있으며, 약간의 수정이 이루어졌습니다 (즉, 그들은 nullifier와 두 점 선 기술을 동시에 사용하여, nullifier를 사용하면 기간의 이중 사용 문제를 더 쉽게 포착할 수 있습니다).

ZK의 부정적 평판

우리가 0chan을 구축하고 싶다고 가정해 보겠습니다. 이는 4chan과 같은 완전 익명의 네트워크 포럼을 제공하지만 (당신은 심지어 영구적인 이름도 없습니다), 더 높은 품질의 콘텐츠를 장려하기 위한 평판 시스템이 있습니다. 이는 일부 감사 DAO가 시스템 규칙을 위반하는 게시물을 표시하고 삼진 아웃 메커니즘을 구축할 수 있는 시스템이 될 수 있습니다.

평판 시스템은 긍정적 또는 부정적 평판을 지원할 수 있습니다; 그러나 부정적 평판을 지원하려면 추가 인프라가 필요하며, 사용자가 증명에서 모든 평판 정보를 고려해야 합니다. 비록 그것이 부정적일지라도 말입니다. 우리는 이 더 어려운 사용 사례에 초점을 맞출 것이며, 이는 Unirep Social이 구현하고 있는 사용 사례와 유사합니다.

링크 게시물: 기초 지식

누구나 체인에 해당 게시물을 포함하는 메시지와 ZK-SNARK를 게시하여 게시물을 게시할 수 있습니다. 이를 통해 (i) 당신이 계정을 생성할 수 있는 권한을 부여하는 희소한 외부 신원을 소유하고 있음을 증명하거나, (ii) 당신이 특정 게시물을 게시한 적이 있음을 증명할 수 있습니다. 구체적으로, ZK-SNARK는 다음과 같습니다:

• 공공 입력
• nullifier N
• 최근의 블록체인 상태 루트 R
• 게시물 내용 (증명에 "혼합"되어 게시물에 바인딩되지만, 우리는 어떤 계산도 수행하지 않습니다)

개인 입력:

• 당신의 개인 키 k
• 외부 신원 (주소 A) 또는 이전 게시물에서 사용된 nullifier Nprev
• A 또는 Nprev가 체인에 포함되어 있음을 증명하는 Merkle 증명 M
• 당신이 이전에 이 계정을 사용하여 게시한 i번째 게시물

검증 기능:

• M이 R을 루트로 하는 트리의 leaf인 유효한 Merkle 분기인지 확인 (A 또는 Nprev에 따라)
• N=enc (i,k)인지 확인, 여기서 enc는 암호화 함수입니다 (예: AES)
• 만약 i=0이라면, A=privtoaddr (k)인지 확인, 그렇지 않으면 Nprev=enc (i−1,k)인지 확인

증명을 검증하는 것 외에도, 체인은 두 가지 측면을 확인합니다 (i) R이 실제로 최근의 상태 루트인지, (ii) nullifier N이 아직 사용되지 않았는지. 지금까지는 앞서 소개한 개인 정보 보호 화폐와 유사하지만, 우리는 새로운 계정을 "주조"하는 과정을 추가했으며, 당신의 계정을 다른 키로 "전송"하는 능력을 제거했습니다 ------ 반대로, 모든 nullifier는 원래 키를 사용하여 생성됩니다.

우리는 여기서 enc를 사용하여 nullifier를 가역적으로 만들고, hash를 사용하지 않습니다: 만약 당신이 k를 가지고 있다면, 당신은 체인상의 특정 nullifier를 해독할 수 있으며, 결과가 유효한 인덱스가 아니라 무작위 쓰레기가 아니라면 (예: 우리는 단순히 dec (N)<264를 확인할 수 있습니다), 당신은 nullifier가 k를 사용하여 생성되었음을 알 수 있습니다.

평판 추가

이 계획에서 평판은 체인상에 있으며, 명시적입니다: 일부 스마트 계약은 addReputation이라는 메서드를 가지고 있으며, 이는 (i) 게시물과 함께 게시된 nullifier와 (ii) 추가하거나 감소시킬 평판 단위 수를 입력으로 받습니다.

우리는 각 게시물이 저장하는 체인상의 데이터를 확장합니다: 우리는 {N,h¯,u¯}를 저장하며, 단순히 nullifier N만 저장하는 것이 아닙니다. 여기서:

• h¯=hash (h,r)이며, 여기서 h는 증명에서 참조된 상태 루트의 블록 높이입니다
• u¯=hash (u,r)이며, 여기서 u는 계정의 평판 점수입니다 (새 계정은 0입니다)

여기서 R은 단순히 임의의 값이며, 이를 추가하는 것은 h와 u가 강제로 검색되는 것을 방지하기 위한 것입니다 (암호학적 용어로, R을 추가하면 해시가 숨겨진 약속이 됩니다).

게시물이 루트 R을 사용하고 {N,h¯,u¯}를 저장한다고 가정해 보겠습니다. 증명에서, 이전 게시물에 연결되며, 데이터 {Nprev,h¯prev,u¯prev}를 저장합니다. 게시물의 증명은 또한 hprev와 h 사이에 게시된 모든 평판 항목을 탐색해야 합니다. 각 nullifier N에 대해, 검증 기능은 사용자의 키 k를 사용하여 N을 해독하며, 해독 결과가 유효한 인덱스를 출력하면 평판 업데이트를 적용합니다. 모든 평판 업데이트의 총합이 δ라면, 최종 증명은 u=uprev+δ가 됩니다.

우리가 "삼진 아웃" 규칙을 원한다면, ZK-SNARK는 또한 u>−3을 확인합니다. 우리가 "게시물의 rep≥100"라는 규칙을 원한다면, 해당 게시물은 특별한 "높은 평판 게시물" 식별을 받을 수 있습니다.

계획의 확장성을 높이기 위해, 우리는 이를 두 가지 유형의 메시지로 나눌 수 있습니다: 게시물과 RCA. 게시물은 체인 외부에 있을 것이지만, 이는 지난 주에 생성된 RCA를 가리켜야 합니다. RCA는 체인상에 있으며, RCA는 해당 게시자가 이전 RCA 이후의 모든 평판 업데이트를 탐색합니다. 이러한 방식으로, 체인상의 부하가 매주 각 게시물에 대한 거래 한 건과 각 평판 메시지에 대한 거래 한 건으로 줄어듭니다.

중앙화된 주체에 대한 책임

때때로, 당신은 어떤 중앙화된 "운영자"가 있는 계획을 구축해야 할 필요가 있습니다. 그 뒤에 있는 이유는 여러 가지가 있을 수 있습니다: 때로는 확장성을 위해, 때로는 개인 정보 보호를 위해 (특히 운영자가 보유한 데이터의 개인 정보 보호를 위해).

예를 들어, MACI는 투표자가 체인에 그들의 투표를 제출하고 중앙화된 운영자가 보유한 키에 암호화하도록 요구하는 강제 저항 투표 시스템을 구현합니다. 운영자는 체인상의 모든 투표를 해독하고, 이를 집계하며 최종 결과를 보여주고, ZK-SNARK를 사용하여 그들이 한 모든 것이 올바르다는 것을 증명합니다. 이러한 추가 복잡성은 강력한 개인 정보 보호를 보장하는 데 매우 필요합니다 (강제 저항이라고 불립니다): 사용자는 다른 사람에게 그들이 어떻게 투표했는지를 증명할 수 없습니다, 심지어 그렇게 하고 싶더라도 말입니다.

블록체인과 ZK-SNARK 덕분에 우리는 운영자에 대한 신뢰도를 매우 낮은 수준으로 유지할 수 있습니다. 악의적인 운영자는 여전히 강제 저항을 깨뜨릴 수 있지만, 투표가 블록체인에 게시되기 때문에 운영자는 투표를 검열하여 부정행위를 할 수 없으며, 운영자는 ZK-SNARK를 제공해야 하므로 결과를 잘못 계산하여 부정행위를 할 수 없습니다.

ZK-SNARK와 MPC 결합

ZK-SNARK의 더 고급 사용은 계산에서 증명을 포함하는 것으로, 입력이 두 당사자 또는 다수의 당사자 간에 분배되며, 우리는 어떤 당사자도 다른 당사자의 입력을 배우지 않기를 원합니다. 두 당사자의 경우, 당신은 암호화 회로를 통해 개인 정보 요구를 충족할 수 있으며, N 당사자의 경우 더 복잡한 다자 계산 프로토콜을 사용하여 개인 정보 요구를 충족할 수 있습니다. ZK-SNARK는 이러한 프로토콜과 결합하여 검증 가능한 다자 계산을 수행할 수 있습니다.

이는 더 고급 평판 시스템을 가능하게 하며, 여러 참여자가 그들의 개인 입력에 대해 공동 계산을 수행할 수 있습니다. 현재 이를 효과적으로 구현하기 위한 수학적 계산은 상대적으로 초기 단계에 있습니다.

우리는 무엇을 개인적으로 설정할 수 없나요?

ZK-SNARK는 사용자가 개인 상태를 소유하는 시스템을 만드는 데 매우 효과적입니다. 그러나 ZK-SNARK는 아무도 모르는 개인 상태를 유지할 수 없습니다. 정보의 일부를 증명하려면, 증명자는 해당 정보를 명시적으로 알아야 합니다.

Uniswap은 개인화하기 어려운 예입니다. Uniswap에서는 논리적으로 중심이 되는 "무언가"가 있으며, 이는 누구에게도 속하지 않는 시장 조성자 계정입니다. Uniswap의 모든 거래는 시장 조성자 계정과 거래하는 것입니다. 당신은 시장 조성자 계정의 상태를 숨길 수 없습니다, 왜냐하면 그렇게 하려면 누군가가 이 상태를 증명하기 위해 명시적으로 보유해야 하며, 각 거래는 그들의 적극적인 참여가 필요하기 때문입니다.

당신은 ZK-SNARK의 암호화 회로를 사용하여 중앙화된 작업의 안전하고 개인적인 Uniswap을 만들 수 있지만, 그렇게 하는 이점이 이를 실행하는 데 필요한 비용을 상쇄할 수 있을지는 아무도 모릅니다. 이는 실제로 어떤 진정한 이점을 가져오지 않을 수도 있습니다: 계약은 사용자에게 자산의 가격이 무엇인지 말할 수 있어야 하며, 블록 단위의 가격 변화는 사용자에게 거래 활동이 무엇인지 알려줄 수 있습니다.

블록체인은 상태 정보를 글로벌화할 수 있으며, ZK-SNARK는 상태 정보를 개인화할 수 있지만, 우리는 상태 정보를 글로벌화하면서 개인화할 수 있는 좋은 방법이 없습니다.

원리 결합

위의 소절에서 우리는 본질적으로 강력하고 유용한 도구의 몇 가지 예를 보았지만, 이들은 다른 애플리케이션의 구성 요소로도 사용될 수 있습니다. 예를 들어, nullifier는 화폐에 중요하며, 현재 다른 사용 사례에서도 반복적으로 나타나고 있습니다.

부정적 평판 부분에서 사용된 "강제 링크" 기술은 적용 범위가 매우 넓습니다. 이는 시간이 지남에 따라 복잡한 방식으로 변화하는 사용자 "프로필"이 있는 많은 애플리케이션에 매우 효과적이며, 사용자가 시스템 규칙을 준수하도록 강제하면서 개인 정보를 보호하고자 할 때 유용합니다. 사용자는 내부 "상태"를 나타내기 위해 전체 개인 Merkle 트리를 사용할 수도 있습니다. 이 글에서 제안된 "약속 풀" 도구는 ZK-SNARK를 사용하여 구축할 수 있습니다. 특정 애플리케이션이 완전히 체인상에 존재할 수 없고 중앙화된 운영자가 필요하다면, 동일한 기술을 사용하여 운영자의 정직성을 유지할 수 있습니다.

ZK-SNARK는 책임과 개인 정보 보호의 이점을 결합한 매우 강력한 도구입니다. 동시에 그것들은 실제로 한계가 있지만, 특정 경우에는 영리한 애플리케이션 설계가 이러한 제한을 우회할 수 있습니다. 나는 더 많은 애플리케이션이 ZK-SNARK를 사용하고, 궁극적으로 향후 몇 년 내에 ZK-SNARK와 다른 형태의 암호화를 결합한 애플리케이션을 구축하는 것을 보고 싶습니다.