Continuous Learning_Startup & Investment

AI가 괴물이 될 거다 라는 모두의 공포감 속에서 영지식 증명(ZK)을 활용한 어떤 AI 연산의 검산 내지 신뢰성을 검증할 수 있는 도구로서 ZKML에 대해 관심을 가지고 기말고사가 끝나고 시간이 날 때마다 조금씩 살펴봤다. 특히 지난 번 샘 알트만의 방한 때 OpenAI 엔지니어와 5분 정도 대화를 나눌 기회가 있었는데 OpenAI도 내부적으로 ZKML 연구를 하고 있다고 한다.

샘 알트만의 월드코인이 ZKML을 최소한 마케팅 용어로나마 표방하고 있으니 당연할 지도 모른다. 하지만 ZKML의 실무적 도입에 대해서는 아직까지 시기상조라는 생각이 들었고 계속 리서치가 필요하다는 의견을 갖게 되었다(나는 문과에서 전과한 수학과 학부생이니까 계속 공부할 기회가 있을 것이다. 사실 지난 주말에는 또 한국통계학회에서 진행하는 수리통계 석사생 대상 강의를 듣고 이게 뭐지 한 걸 보면 난 호기심 부자가 맞다.)

ZKML 라이브러리로는 EZKL이 가장 유명한데 나의 질문 공세에 매우 빠르면서도 친절하게 대답해주어 감명 받았고 정말 고마운 마음이다. Halo2를 사용하는 EZKL 라이브러리의 목적은 인공지능 모델의 출력이 특정 입력에 대해 정확하게 계산되었음을 증명하는 것이고, 일반적으로 블록체인에서 주장하는 “상호 무신뢰 상태에서의 신뢰 부여” 에 부합하는 유즈케이스라고 생각했다.

일반적으로 머신러닝에서 숨기고자 하는 것은 모델의 가중치와 파라미터이므로 모델의 전체 정보를 포함하는 ONNX 파일은 숨겨져야 한다.

내가 파악한 EZKL의 구동 원리는 대략적으로 다음과 같다:

1. 모델 생성: 증명자(prover)는 머신러닝 모델을 생성하고, 이 모델의 가중치와 파라미터를 알게 된다.

2. 해시 생성: 증명자는 이 가중치와 파라미터를 해시 함수에 입력하여 결과 해시 값을 얻고 해시 함수는 원래의 정보를 완전히 복구할 수 없도록 변환하는 일방향 함수이므로 주어진 해시 값만으로는 원래의 가중치와 파라미터를 알아낼 수 없다.

3. 프리 커밋: 증명자는 이 해시 값을 사전 커밋값으로 사용하고 커밋값은 후에 검증 과정에서 사용되며, 증명자는 이 해시 값을 검증자에게 보낸다.

4. 증명 생성: 증명자는 이 모델을 사용하여 작업을 수행하고, 그 결과에 대한 증명을 생성한다. 이 증명에는 해시 값을 사용하여 생성한 모델 파라미터의 해시 값이 포함된다.

5. 증명 검증: 검증자(verifier)는 증명자로부터 받은 증명을 검증한다. 검증자는 증명 내의 해시 값과 증명자로부터 사전에 받은 해시 값이 일치하는지 확인한다. 두 해시 값이 일치한다면, 검증자는 증명자가 작업을 수행할 때 약속한 모델의 가중치와 파라미터를 사용했다고 확신할 수 있다.

이 과정을 통해, 증명자는 실제 가중치와 파라미터를 공개하지 않고도, 이들이 정상적으로 사용되었다는 것을 검증자에게 증명할 수 있는 것이 목표다. 그래서 이는 ONNX 파일 자체를 공개하지 않고도 모델의 신뢰성을 검증하는 방법으로 사용될 수 있다고 한다.

하지만, 허점이 하나 있다. ONNX 파일이라는 모델 형식을 사용하여, EZKL 라이브러리가 신뢰할 수 있는 검증 키(verifying key)와 증명 키(proving key)를 생성한다는 것이다. ONNX 파일은 모델의 구조뿐만 아니라 가중치와 같은 모델의 파라미터를 포함하고 있으므로, ONNX 파일을 소유하고 있는 개체가 해당 모델의 기밀 정보를 접근하고 조작할 수 있다는 의미이다. 그렇다고 투명성을 위해 ONNX 파일을 공개하자니 이건 기업 기밀 유출 내지 과도한 정보 공개이다.

그렇기 때문에, 검증 키와 증명 키를 생성하는 과정에서 ONNX 파일을 보유하고 있는 생성자를 믿어야 하는 문제가 생기게 된다. 따라서 genesis setup에서는 모델 개발자에게 trust를 현실적으로 부여해야 한다는 이야기다. 모델의 개발자가 그 파일을 적절하게 보호하고, 파일이 정확한 파라미터와 함께 올바르게 생성되었다는 것을 보장할 수 있어야 함을 의미하는데 이는 암호학이 궁극적으로 달성하고자 하는 “완전한 무신뢰 상태” 목표 달성에 실패한다.

물론, 이러한 문제를 해결하기 위한 가능한 방법은 다자간 계산(MPC)을 이용해 ONNX 파일을 공동으로 생성하는 것이지만, 이는 현실적으로는 복잡한 프로토콜을 요구하며, 아직까지는 엔터프라이즈 환경에서 실용적이지 않다.

따라서 이러한 문제들은 EZKL 라이브러리가 single-point of failure가 존재하는 현재 아키텍처 상 기업 수준의 생산 환경에서 현재 구조 하에서 실질적으로 적용될 수 있는지에 대한 의문을 가지게 된다. (물론 zk-SNARKs 환경에서 부동소수점 계산이 제대로 되지 않아 tolerance를 일부 상쇄해줘야 한다는 단점도 있지만 이는 차치하도록 하자)

하지만 온디바이스 ML에 대해서는 유용하게 사용될 수도 있겠다. 만약 애플이 구동하는 어떤 온디바이스 신용평가 ML 모델이 있다고 한다면 애플이 가지고 있는 모델과 아이폰에서 구동하는 ML 모델은 동일할 것이므로 아이폰과 애플 사이에는 ML 모델은 public으로 두고 아이폰에서 제공하는 데이터는 private으로 두어 최종적으로 애플에 ML 모델을 돌린 결과값인 신용평가 정보(이 아이폰 사용자는 신용 등급이 A등급입니다)를 제출하고 그 모델을 맞게 돌렸다고 하는, 즉 중간에서 위변조가 이루어지지 않았다는 proof를 함께 제출하면 애플은 사용자의 민감 정보를 수집하지 않고도 모델의 결과값을 신뢰할 수 있을 것이다.

그리고 한 가지 더.. 실질적으로 ZK의 구동은 서버에서 proof를 생성하고 클라이언트에서 wasm으로 bind된 verify 바이너리를 call하여 증명의 참 거짓 여부를 알게 될 것이다. verify 바이너리의 checksum만 봐도 내가 사용하는 라이브러리의 신뢰성을 부여할 수 있다. 다시 말해, 특수하게 신뢰공증을 제공해야 할 경우를 제외하고는 굳이 블록체인에 검증 연산을 실행할 필요가 보이지는 않는다.

Sigurd

48 views06:28