Magnetar 연구, 일반 코드 실행 증명과 13ms 검증

Microsoft Research는 2026년 10월 15일 Magnetar 연구 발표에서 Rust·Go·C 프로그램의 실행을 증명하고, 비교 대상인 기존 zkVM보다 증명 생성 처리량이 작업별 기하평균으로 10~39배 높았다고 밝혔다. 전용 암호 회로를 프로그램마다 새로 만드는 부담을 줄였다는 점에서 일반 코드에 검증 가능한 계산을 붙일 경로가 넓어졌다. 다만 발표된 성능은 연구팀의 실험 결과다.

검증 단계의 수치는 생성 속도와 별개다. 독립 기술 매체 SXZ의 논문 수치 재계산에 따르면, 연구진이 M4 Max MacBook Pro의 성능 코어 12개와 증명 가능한 120비트 보안 설정에서 측정한 약 600KiB의 Magnetar 증명은 11~13ms에 검증됐으며 최대 검증 시간은 13ms였다. 이는 이미 만들어진 증명의 확인 시간으로, 프로그램 실행이나 증명 생성에 걸린 전체 시간과는 다르다. 매체가 배수를 재계산했지만 경쟁 시스템을 독립적으로 다시 시험한 결과는 아니다.

영지식 증명 분야의 주간 소식지 ZK Insights의 10월 16일호는 Magnetar를 추천 논문으로 다루며 사전공개본이 10월 9일 등록되고 15일 개정됐다고 정리했다. 공개된 성과는 설계, 구현과 성능 평가에 관한 것이다. 일반 이용자를 위한 제품이나 클라우드 기능의 출시가 발표된 단계는 아니다.

Rust·Go·C 코드는 어떻게 증명 대상이 되나

Rust·Go·C 프로그램이 RV64I 실행 경로로 모여 Magnetar의 증명 대상이 되는 구조

Magnetar가 직접 다루는 것은 특정 언어의 문법이 아니라 RV64I 명령어로 변환된 프로그램의 실행이다. 개발자가 기존 도구로 코드를 컴파일하면 가상 프로세서가 명령을 수행하고, 증명자는 정해진 입력에서 주장한 출력으로 이어지는 실행에 대한 암호학적 증거를 만든다. 결과를 받는 쪽은 계산을 다시 전부 수행하는 대신 증명을 검사한다. 언어마다 별도 회로를 설계하는 방식보다 개발 과정의 중복을 줄일 수 있는 이유다.

이 구조의 실용성은 프로그램이 목표 명령어 집합에서 실제로 실행될 수 있는지에 달려 있다. 소스코드가 익숙한 언어로 작성됐다는 사실만으로 외부 서비스 호출, 운영체제 의존 기능, 모든 라이브러리가 곧바로 증명 환경으로 옮겨지는 것은 아니다. 실행에 들어갈 입력과 검증자가 받아들일 출력도 증명하려는 주장에 맞춰 정해야 한다. 일반 코드 지원은 컴파일 가능한 실행을 증명한다는 의미로 이해해야 한다.

논문이 든 구체적 예시는 Rust나 Go로 작성한 이더리움 가상머신 해석기를 대상 명령어로 컴파일하는 방법이다. 해석기가 스마트 계약의 동작을 처리하면 Magnetar는 그 해석기의 실행을 증명하는 경로를 제공한다. 이때 증명의 대상은 계약을 평가한 가상머신의 계산이다. 계약의 경제적 타당성이나 외부에서 주어진 데이터의 진실성은 실행 증명만으로 판정되지 않으며, 감사용 업무 규칙에도 같은 경계가 적용된다.

생성 처리량, 증명 크기, 검증 시간의 다른 의미

Magnetar의 약 600KiB 증명 크기를 Jolt와 SP1 Hypercube의 증명 크기와 비교한 구성

Magnetar의 성능을 읽을 때 먼저 나눠야 할 것은 증명을 만드는 쪽과 받아서 확인하는 쪽의 부담이다. 증명 생성 처리량은 주어진 연산 자원으로 얼마나 많은 프로그램 실행을 증명할 수 있는지를 나타낸다. 검증 시간은 완성된 증명을 받은 사람이 결과를 확인하는 데 드는 지연이다. 수신자가 많을수록 검증 비용은 중요해지지만, 빠른 검증이 생성자의 계산 비용이나 증명 파일의 전송 비용까지 없애 주지는 않는다.

연구진은 서로 다른 가상머신이 명령과 사이클을 세는 방식이 달라 응용 작업의 완료량으로 처리량을 비교했다. 이 비교에서 Magnetar의 우위는 SP1 Hypercube, Jolt-Dory, Jolt-Akita 중 어느 시스템을 기준으로 삼는지에 따라 달라진다. 더 긴 실행에서는 경쟁 시스템의 처리량도 변하므로 한 구간의 배수를 모든 프로그램과 실행 길이에 그대로 적용할 수 없다. 발표된 배수는 해당 장비와 작업에서 관찰된 증명 생성 결과다.

증명 파일의 크기는 별도 비용이다. Magnetar의 증명은 SP1 Hypercube의 압축 전 핵심 증명보다 작지만 Jolt 계열의 증명보다는 크다. 수신자가 결과를 가끔 확인한다면 짧은 검증 지연이 눈에 띄고, 같은 증명을 여러 곳에 보내거나 오랫동안 보관한다면 파일 크기가 누적 비용으로 바뀐다. 비교 대상의 증명 형식도 같지 않으므로 작은 수치 하나만으로 전체 시스템의 효율을 판정하기 어렵다.

증명자의 메모리 사용량 역시 실제 운영에 영향을 준다. 논문의 같은 실행 길이 비교에서는 Magnetar가 SP1 Hypercube보다 적은 메모리를 썼지만 Jolt 계열보다는 더 많이 썼다. 긴 작업은 한 번에 증명할지, 작은 구간으로 나눌지에 따라 필요한 메모리와 최종 증명의 구성 방식이 달라진다. 연구 성과가 빠른 검증을 보여 줬다는 사실과 대규모 업무 전체의 비용이 이미 확정됐다는 판단은 구분해야 한다.

표준 해시 기반 보안과 남은 구현 범위

Magnetar는 표준 해시 함수에 계산적 안전성의 토대를 둔다. 논문은 타원곡선이나 격자 문제, 증명에 특화된 대수적 해시, 비밀 매개변수를 만드는 신뢰 설정에 기대지 않는 구성을 설명한다. 이런 선택은 장기적으로 양자 컴퓨터의 영향을 고려하는 조직에 의미가 있다. 암호학적 가정이 다르면 증명 크기와 속도 수치도 서로 다른 조건에서 나온 결과가 된다는 점을 함께 봐야 한다.

비교 대상 가운데 Jolt-Dory는 타원곡선 기반 약속 방식을, Jolt-Akita는 격자 기반 약속 방식을 사용한다. 두 방식이 더 작은 증명을 낼 수 있는 대신 어떤 수학적 가정을 신뢰하는지는 Magnetar와 다르다. SP1 Hypercube 역시 표준 해시 함수에만 의존하는 비교 대상은 아니다. 보안 가정, 생성 처리량, 증명 크기는 같은 선택의 서로 다른 비용과 이익으로 읽는 편이 정확하다.

긴 계산을 여러 조각으로 나눠 재귀적으로 합치는 구상도 이번 연구의 중요한 부분이다. Magnetar의 검증 과정이 주로 해시 계산과 이진 체계 연산으로 이뤄져 그 검증 자체를 다시 증명하기에 적합하다는 논리다. 그러나 공개된 실험은 개별 실행 구간을 대상으로 하며, 논문은 구간별 증명을 재귀적으로 합치는 구현이 아직 이뤄지지 않았다고 적었다. 계속 움직이는 원장이나 아주 긴 프로그램에 적용할 때는 이 설계가 실제 구현과 측정으로 이어지는지가 관건이다.

또 하나의 구분은 실행의 정확성과 입력의 비밀 보호다. 논문은 가상머신 실행에 대한 간결한 증명과 영지식성을 별도 성질로 설명하며, 제시한 안전성 정리에서 비공개 입력이 증명으로부터 숨겨진다는 성질을 따로 입증하지 않는다. 정책 준수나 외주 계산의 정확성을 확인하려는 경우에는 실행 증명의 의미가 분명하다. 민감한 고객 데이터까지 감추어야 하는 경우에는 입력 공개 범위와 비밀 보호 성질을 추가로 정의해야 한다.

감사와 외부 계산 검증에 적용할 때의 선택 기준

Magnetar가 제시한 가치가 가장 뚜렷한 곳은 계산을 수행한 주체와 그 결과를 받아들이는 주체가 다른 업무다. 결과를 받는 사람이 전체 계산을 다시 실행하지 않아도 된다는 장점이 있기 때문이다. 다만 어떤 계산을 증명했는지 합의할 프로그램과 입력 형식이 먼저 있어야 하며, 컴파일 이후의 실행이 원래 업무 규칙을 정확히 표현하는지도 중요하다. 발표된 실험 수치는 다음 용도별 판단에서 서로 다른 자리에 놓인다.

정해진 규칙의 감사: 기존 언어로 관리하는 정책 검사나 집계 프로그램을 목표 환경에서 실행할 수 있다면 결과에 실행 증명을 붙일 수 있다. 반복 처리에는 생성 처리량이, 여러 감사자에게 결과를 내보낼 때는 검증 지연과 전송 크기가 함께 중요하다. 증명은 정해진 규칙을 계산했다는 사실을 다루므로 규칙의 적절성은 별도 문제로 남는다.
클라우드 계산 결과 확인: 외부 운영자가 실행한 계산의 결과와 증명을 이용자에게 전달하는 구조에서는 검증자가 전체 작업을 재실행하지 않는 이점이 생긴다. 반면 증명 파일이 계속 이동하거나 보관된다면 크기가 통신량과 저장 비용에 영향을 준다. 어느 쪽의 컴퓨팅 자원이 더 제한적인지에 따라 유리한 설계도 달라질 수 있다.
가상머신을 통한 계약 실행: 기존 계약을 처리하는 해석기를 일반 언어로 구현하고 그 실행을 증명하는 경로가 제시됐다. 이 경우 성능은 계약 자체의 복잡도뿐 아니라 해석기가 수행하는 명령의 수와 구간 구성에 따라 변한다. 작은 시험 작업의 처리량을 실제 서비스의 계약 전체 처리량으로 옮겨 적을 수는 없다.

다음에 필요한 데이터는 더 긴 실제 프로그램의 생성 시간과 메모리, 재귀 결합 뒤의 최종 증명 크기와 검증 지연이다. 현재 결과가 연구팀의 장비와 비교 설정에 한정된 만큼 공개 구현을 이용한 별도 재현도 운영 비용을 가늠하는 데 도움이 된다. 그런 데이터가 나오면 짧은 검증이라는 장점이 통신비와 생성비를 감수할 만큼 큰지 용도별로 더 분명해질 것이다.

함께 읽기: