본 글은 정보 제공을 목적으로 작성된 것으로, 투자, 법률, 자문 등 어떠한 분야에서도 책임을 지지 않습니다. 특정 자산에 대한 투자 권유의 의도가 없으며, 본문 내용만을 기반으로 투자 결정을 내리지 마시기 바랍니다.

오근탁 | CURG | ot6252@naver.com

[들어가며] 우리 팀이 Groth16을 파헤치는 이유

최근 블록체인 업계에서 뜨거운 키워드 중 하나는 영지식 증명(Zero-Knowledge Proof)이다.

비트코인의 탄생 이래 블록체인 업계는 항상 투명성과 프라이버시라는 상충하는 가치 사이에서 딜레마를 겪어 왔다. 투명성은 신뢰를 구축하지만 동시에 개인정보 유출을 동반한다.

투명성과 프라이버시라는 상충하는 가치를 해결할 대안으로 ZKP가 떠올랐고, 단순한 프라이버시 보호를 넘어 데이터의 압축을 통해 이더리움과 같은 메인넷의 확장성을 높이는 핵심 기술(ZK-Rollups)로도 사용되고 있다.

ZKP는 증명자가 자신이 알고 있는 정보의 구체적인 내용은 공개하지 않으면서 검증자에게 그 정보가 참이라는 사실을 입증하는 암호학적 방법론이다.

예를 들자면 내 지갑의 잔액이 100BTC가 넘는다는 것을 인증하고 싶지만, 지갑 주소는 노출하고 싶지 않은 경우, 내가 성인이라는 것은 인증하고 싶지만, 구체적인 나이는 공개하고 싶지 않은 경우가 있을 것이다.

아래 그림은 ZKP의 일반적인 개념을 보여준다. (대화형 방식)

이처럼 노출하고 싶지 않은 민감한 정보는 숨기면서 내가 증명하고자 하는 사실만을 증명하는 것이 ZKP의 주 목적이다. 그래서 처음 ZKP를 접하면, 자연스럽게 프라이버시 보호 기술이라고만 생각하기 쉽다.

다만, ZKP의 쓰임새는 그게 끝이 아니다. 프라이버시 보호뿐 아니라 방대한 연산 자체를 아주 짧은 증명으로 압축할 수 있다는 점에서도 큰 활용 가치를 가진다.

그래서 ZKP의 사용 목적은 불법 자금세탁으로 유명한 대표적인 믹서 서비스인 토네이도 캐시처럼 프라이버시 보호를 위해 ZK를 사용하는 것과 ZK-Rollups처럼 데이터 압축을 위해 ZK를 사용하는 두 축으로 나누어진다.

ZKP는 방대한 연산 과정을 아주 짧은 증명으로 요약할 수 있는데, 이를 활용하는 가장 대표적인 사례가 이더리움의 확장성 솔루션인 ZK-Rollups이다.

ZK-Rollups의 경우 L1이 기가바이트 단위의 L2 트랜잭션을 일일이 검증하는 대신, L2에서 트랜잭션 무결성을 입증하는 단 하나의 증명(~128바이트)만 제출한다.

중요한 것은 L2의 트랜잭션 데이터는 여전히 투명하게 공개되며 원한다면 L1이 직접 L2의 트랜잭션을 재실행하여 무결성을 검증할 수도 있다는 것이다.

이는 ZK-Rollups의 목적이 정보 은닉이 아닌 L1 부하 감소이기 때문이며 이처럼 프라이버시 보호만을 위해서 ZKP가 사용되는 것은 아님을 알 수 있다.

ZKP의 영향력은 날이 갈수록 높아지고 있다. 옵티미스틱 롤업의 대표 주자인 Optimism도 2026년 로드맵에 ZK 증명 시스템을 올렸고, Mantle과 Celo는 이미 ZK 증명으로 전환을 마쳤다. RWA 및 AI 등 주요 분야에서도 ZKP의 활용도가 급증하고 있다.

우리 팀이 참고한 비탈릭 부테린의 ZKP 가이드가 작성된 연도가 2016년이다. 이때부터 비탈릭은 ZKP의 중요성을 계속 강조해왔으며, 2023년 EDCON에서는 “zk-SNARK가 앞으로 10년간 블록체인만큼 중요해질 것”이라고 말하기도 했다. 실제로 이더리움 로드맵 중심에는 ZK가 있다.

기관 및 분석가들의 생각도 크게 다르지 않다. 메사리(Messari), 델파이 디지털(Delphi Digital)과 같은 주요 연구 기관들은 2026년을 ZKP가 투기에서 실질 유틸리티로 변화하는 전환점으로 정의하고 있다.

특히 델파이 디지털은 글로벌 중앙은행들의 정책 변화와 함께 블록체인 인프라가 규제 준수(Compliance)를 갖추기 위해 영지식 가상 머신(ZKVM)을 적극 도입할 것으로 내다봤다.

이처럼 업계 리더와 전문가들 모두 ZKP의 중요성에 대해 입을 모아 말하고 있는 가운데, 흥미롭게도 ZKP를 다룰 수 있는 인재는 극심한 부족 상태에 있다.

ZKP의 중요성과 인재 부족 때문에 많은 사람들이 ZKP를 공부하려 하지만 높은 수학 난이도에 막혀 포기하는 경우가 흔하다.

그뿐만 아니라 참고할 만한 양질의 학습 자료를 찾기 어려우며 국문으로 된 친절한 가이드는 거의 없다시피 하다.

그래서 우리 팀이 직접 Groth16의 국문 가이드를 작성하기로 마음먹었다.

0. Groth16(The C of ZKP): 왜 Groth16인가?

• Plonk, Halo2 등 새로운 ZKP 프로토콜이 나온 현재까지도 많이 쓰인다.
• 한번 제대로 익히면 다른 모든 ZK 시스템을 이해하는 기준점이 된다.
• “가장 완벽한 압축과 가장 빠른 검증을 보여주는 표준”

블록체인을 공부하는 사람이라면, ZKP 입문은 Groth16으로 하는 것이 좋다.

블록체인 업계에서 ZKP 붐이 시작한 발단은 2016년 Zcash의 런칭이다. 출시 초기의 Zcash는 BCTV14(Pinocchio 계열)를 사용했지만, 그 Zcash가 2018년 Sapling 업그레이드에서 Groth16을 채택하면서 업계 표준으로 자리 잡았다.

ZKP는 크게 zk-SNARKs와 zk-STARKs로 나뉘는데, Groth16은 가장 대표적인 zk-SNARK 프로토콜이다. 여기서 S(Succinct)는 증명의 크기가 아주 작고 검증 속도가 빠르다는 의미이며, ZK(Zero-Knowledge)는 민감한 정보는 노출하지 않고 참이라는 사실만을 증명한다는 뜻이다.

우리가 다룰 Groth16은 이러한 S와 ZK를 구현하기 위해 R1CS에서 QAP로 이어지는 워크플로우를 정립하였다.

Groth16 이후에 나온 zk-SNARK 프로토콜인 Plonk나 Halo2는 산술화 방식을 새롭게 설계했지만, 계산을 다항식으로 압축하고 짧은 증명으로 검증한다는 큰 틀은 같다.

따라서 Groth16을 이해하는 것으로 ZKP의 근본 원리를 파악할 수 있다.

표에 있는 재귀 증명(Recursive Proof)이 낯설 수 있는데, “증명을 증명하는 것” 을 뜻한다. 증명 A가 올바르게 검증된다는 사실을 증명하는 새로운 증명 B를 만드는 방식이다.

재귀 증명이 왜 필요할까? 증명이 100개 있다고 가정해 보자. 하나씩 검증하려면 100번을 확인해야 한다. 하지만 “이 100개의 증명이 모두 올바르다”는 사실을 증명 하나로 묶으면, 검증자는 마지막 증명 하나만 확인하면 된다. 마치 회사에서 결재 서류 100장을 팀장이 검토하고 나면, 사장은 팀장의 도장 하나만 확인하면 되는 것과 비슷하다. (저는 회사에 다녀본 적이 없습니다)

엄밀히 따지면 Groth16도 재귀 증명이 불가능하지는 않다. 다만 Groth16 증명을 검증하는 과정(뒤에서 다룰 페어링 연산)을 다시 회로 안에 집어넣으면 계산량이 엄청나게 불어난다. 이를 줄이려면 곡선 두 개가 맞물리는 특수한 구조까지 필요해서 아주 비효율적이다.

흥미로운 점은 Groth16 증명을 다른 ZKP 회로 안에서 검증하는 것은 말도 안 되게 비효율적이지만, 다른 증명을 Groth16 회로에서 검증해 Groth16 포장지로 감싸면 결과물이 아주 작아지고 검증도 저렴해진다는 것이다.

실제로 이런 용도로 아주 잘 쓰이고 있는데, 몇몇 zkVM은 먼저 STARK 방식으로 크고 무거운 증명을 만든 뒤, 마지막에 그 증명을 Groth16으로 한 번 더 감싸서 블록체인에 올린다. 여러 증명 방식 중 Groth16의 증명이 가장 작고 검증 비용도 가장 싸기 때문이다.

이제 본격적으로 Groth16의 작동 원리를 뜯어볼 시간이다. 본 가이드는 다음과 같은 순서로 진행된다.

Part 1. 산술화(Arithmetization): 간결함(Succinct)을 위해 논리를 수학적으로 압축하기

핵심 개념: 선형결합, 행렬, 다항식, 라그랑주 보간법

1. 연산(Computation)

2. 산술 회로(Arithmetic Circuit)

3. R1CS(Rank-1 Constraint System)

4. QAP(Quadratic Arithmetic Program)

Part 2. 증명 시스템(Proof System): 간결함에 영지식(ZK) 더하기

핵심 개념: 유한체, 타원곡선, 페어링, 이산로그 문제

5. 타원곡선과 신뢰 설정(Elliptic Curve & Trusted Setup)

6. 증명 생성 및 검증(Proof & Verification)

Groth16의 가장 큰 특징은 극강의 효율성이다. 그 어떤 복잡한 증명이라도 최종적으로는 단 3개의 점으로 압축된다.

Part1에서 현실의 논리를 어떻게 컴퓨터의 언어로 변환하는지 살펴보자.

Part 1. 산술화(Arithmetization): 간결함(Succinct)을 위해 논리를 수학적으로 압축하기

• 증명하고자 하는 논리를 컴퓨터가 검증할 수 있는 수식으로 변환한다
• 복잡한 수식을 게이트 단위로 쪼개고, 게이트를 다항식으로 압축해서 증명의 크기를 최소화한다
• 이 과정을 통해 수많은 연산을 단 하나의 식으로 검증할 수 있는 간결함(Succinct)의 토대를 만든다

1. 연산(Computation): 논리의 재정의

• “나는 y = x³ + x + 5를 만족하는 비밀 입력 x를 알고 있다.”

ZKP를 통해 이러한 주장이 참이라는 것을 증명하려면, 위 식을 컴퓨터가 이해할 수 있는 형태로 변환하는 것이 첫 단계다.

이는 곧 Flattening을 한다는 것을 의미한다.

1–1. 평탄화(Flattening): 복잡한 수식을 단순한 게이트로 쪼개기

우리가 증명하고자 하는 주장을 프로그램이 이해할 수 있게 모든 식을 하나의 연산만을 포함하는 형태로 변환한다.

ZKP 시스템에서는 한 번에 여러 연산이 섞인 식을 처리할 수 없기 때문이다.

이 ‘하나의 연산’이라는 것은 곱셈 또는 덧셈 연산 기호가 단 하나 존재하는 식을 말하는 것이며 식 하나하나를 게이트라고 한다.

모든 게이트는 A + B = C 또는 A × B = C처럼 덧셈 또는 곱셈의 형태를 띤다.

(이 단계에서는 이해를 위해 덧셈과 곱셈으로 구분하지만, R1CS 단계로 넘어가면 덧셈과 상수항도 하나의 곱셈식 안에서 함께 다뤄진다.)

위 이미지처럼 y = x³ + x + 5라는 최초의 식은 4개의 게이트로 쪼개진다.

1. v1 = x × x (1번 곱셈 게이트)
2. v2 = v1 × x (2번 곱셈 게이트)
3. v3 = v2 + x (3번 덧셈 게이트)
4. y = v3 + 5 (4번 덧셈 게이트)

이렇게 식을 잘게 쪼개는 평탄화 과정을 거쳐야 다음 단계로 넘어갈 수 있다.

2. 산술 회로(Arithmetic Circuit): 논리의 시각화

그리고 잘게 쪼개진 식들을 한눈에 볼 수 있도록 회로 형태로 연결해야 한다.

앞에서 구한 4개의 게이트(v1, v2, v3, y)는 서로 독립적인 것이 아니라, 앞 단계의 출력이 다음 단계의 입력으로 이어지는 구조를 가진다. 첫 번째 곱셈 게이트(G1)의 결과물 v1이 두 번째 곱셈 게이트(G2)의 입력값이 된다.

이렇게 꼬리에 꼬리를 무는 흐름을 선으로 이으면 회로도가 만들어진다. 복잡해 보이지만 입력값 x가 통로들을 거쳐 결과값 y에 도달하는 과정을 보기 좋게 시각화한 것뿐이다.

회로도를 그리는 이유는, 평탄화된 계산을 게이트 단위로 시각화해 각 연산이 어떤 제약으로 바뀌는지 명확히 보여주기 위해서다.

이 회로도를 바탕으로 각 게이트를 제약 조건으로 표현할 수 있다.

[용어 정리] 제약 조건(Constraint) = 게이트(Gate)?

같은 계산을 단계에 따라 서로 다른 관점에서 부르는 표현에 가깝다. 산술 회로 단계에서는 회로를 이루는 기본 연산 단위를 게이트라고 부르고, R1CS부터는 그 연산이 만족해야 하는 수학적 규칙을 제약 조건이라고 부른다.

예를 들어, 산술 회로 단계에서 A × B = C라는 식을 하나 만들면, 하나의 곱셈 게이트를 사용한 것이며 동시에 하나의 제약 조건이 생긴다고 볼 수 있다.

그래서 입문 단계에서는 게이트와 제약 조건을 비슷한 맥락에서 이해할 수 있지만, 둘을 완전히 같은 것으로 보면 안 된다.

또한 제약 조건과 제약식도 비슷한 뜻으로 함께 쓰일 때가 있다. 여기서 제약 조건은 “만족해야 하는 규칙”을 가리키고, 제약식은 그 규칙을 식으로 적은 표현이다. 두 용어는 비슷하게 쓰이기도 하지만, 관점이 조금 다르다.

덧셈과 상수항은 하나의 제약 조건 안에 함께 포함될 수 있지만, 곱셈은 보통 한 번 사용될 때마다 별도의 제약 조건이 필요하다. 그래서 ZKP 회로에서는 덧셈보다 곱셈이 훨씬 더 비싼 연산으로 취급된다.

따라서 회로 설계의 핵심은 단순히 게이트 수를 줄이는 것이 아니라, 더 정확히는 곱셈 게이트의 수를 최소화하는 데 있다. 실무에서도 가능한 많은 덧셈 연산과 상수항을 하나의 제약 조건 안에 압축해 넣고, 새로운 곱셈이 추가되는 것을 줄이는 방향으로 최적화를 수행한다.

이처럼 같은 계산도 회로 단계에서는 게이트로, R1CS부터는 제약 조건으로 표현되며, QAP 단계에서는 이러한 제약의 개수가 관련 다항식의 차수와 연결된다.

3. R1CS(Rank-1 Constraint System): 행렬로 통합

• 평탄화된 수많은 게이트를 계산하기 쉽도록 행렬의 형태로 정리하는 단계
• 수많은 제약 조건을 단 하나의 행렬 방정식(A · w) × (B · w) = (C · w)으로 압축하는 것이 목적

앞서 평탄화를 통해 y = x³ + x + 5를 4개의 게이트로 쪼갰다. 그런데 실제 ZKP 회로는 수백, 수천 개의 게이트로 이루어지기도 한다. 이 게이트들을 하나씩 검증하는 것은 매우 비효율적이다.

R1CS는 이 문제를 해결하기 위해 모든 게이트를 세 행렬 A, B, C와 witness vector w로 정리하고, 이를 하나의 방정식 (A·w) * (B·w) = (C·w)로 통합한다.

수많은 계산 내역을 하나의 거대한 장부(행렬)로 옮겨 적음으로써, 장부가 틀린 곳 없이 작성되었는지 단번에 확인하려는 것이 R1CS의 목적이다.

[용어 정리] Private Input, Public Input, Witness

ZKP에서는 증명에 필요한 값을 크게 비밀 입력(Private Input)과 공개 입력(Public Input)으로 나누어 생각할 수 있다.

비밀 입력(Private Input)은 증명자만 알고 있으며, 검증자에게 직접 공개하고 싶지 않은 값이다.
예) 실제 나이, 지갑 잔액, 개인 키

공개 입력(Public Input)은 검증자가 이미 알고 있거나, 검증 과정에서 기준으로 삼아야 하는 공개된 값이다.
예) 성인 기준 나이(만 19세), 대출 심사 기준, 컨트랙트 주소, 출력값 y

여기서 헷갈리기 쉬운 개념이 witness다. 입문 단계에서는 witness를 “증명자만 알고 있는 비밀값” 정도로 이해해도 되지만, 더 정확히는 회로를 성립시키는 데 필요한 값들의 묶음에 가깝다.

private Input ⊆ witness라고 볼 수 있으며, witness에는 비밀 입력뿐 아니라 그 값으로부터 계산된 중간값(intermediate values)과 출력값까지 함께 포함된다.

예를 들어 비밀 입력이 x고, 회로를 계산하는 과정에서 v1, v2, v3 같은 중간값이 만들어졌다면 witness에는 x뿐 아니라 출력값 y와 중간값 v1, v2, v3도 함께 들어간다.

그리고 x가 숨겨야 할 비밀 입력이라면, x로부터 계산된 중간값 v1, v2, v3 또한 검증자에게 그대로 노출되어서는 안 된다.

따라서 회로에 등장하는 값들을 하나씩 공개해 검증하는 대신, 이 값들이 전체 제약을 만족한다는 사실만 증명하는 방식이 필요하다.

3–1. Witness Vector: 회로에 등장하는 모든 값의 명단

이미지를 보면, 복잡한 표에 숫자 0과 1이 가득 채워져 있는 것을 볼 수 있다. 이 표는 산술 회로를 R1CS의 제약식 형태로 옮겨 가는 중간 과정을 보여준다.

R1CS에서 가장 먼저 해야 할 일은 회로에 등장하는 모든 값을 하나의 벡터, 하나의 목록으로 정리하는 것이다. 이를 witness vector w라고 한다.

앞서 회로에 등장한 변수들을 모아서 정리하면 다음과 같다.

w = [1, x, y, v1, v2, v3]

여기서 헷갈리기 쉬운 점이 하나 있다. 위 이미지는 witness vector 자체가 아니라, 각 제약식이 witness vector의 값들을 어떤 계수로 조합하는지를 보여주는 표다.

문헌마다 표현은 조금 다르지만, 이 글에서는 설명 편의를 위해 각 제약식에 사용되는 계수들의 묶음을 gate vector(계수 벡터)라고 부르겠다.

witness vector는 회로에 어떤 값들이 존재하는지를 한 줄로 정리한 목록이고, gate vector는 그 값들 중 어떤 항을 어떤 계수로 조합해 하나의 제약식을 만들지를 나타내는 계수 벡터다.

두 번째 이미지는 witness vector와 gate vector의 차이를 더 직관적으로 보여준다. 위쪽의 witness vector에는 실제 값들이 들어 있다. 예를 들어 x = 3이라면, 그로부터 계산된 v1, v2, v3와 출력 y까지 하나의 목록 안에 정리된다.

반면 아래쪽의 gate vector는 이 값들 중 어떤 항을 어떤 계수로 조합해 하나의 제약식을 만들지를 나타내는 계수 벡터다.

예를 들어 G4에 해당하는 제약식은 v3 + 5 = y이므로, 해당 gate vector에서는 상수항 1의 계수를 5로, v3의 계수를 1로 두고 나머지는 0으로 둔다.

그러면 이 gate vector와 witness vector를 내적했을 때 v3 + 5라는 선형결합이 만들어진다.

따라서 witness vector는 데이터의 명단이고, gate vector는 그 명단을 참조해 하나의 제약식을 만드는 규칙이다.

이제 witness vector를 다시 보면 맨 앞에 1이 추가되어 있다. R1CS의 제약식은 기본적으로 곱셈 형태를 기준으로 표현되기 때문에, 단순한 상수항도 5 × 1처럼 써야 한다. 그래서 witness vector의 맨 앞에는 기준점 역할을 하는 상수항 1이 항상 포함된다.

[용어 정리] Witness와 Witness Vector

witness는 회로를 성립시키는 데 필요한 값들의 묶음이고, witness vector는 그 값들을 R1CS 계산에 사용할 수 있도록 정해진 순서로 나열한 벡터다.

간단히 말해 witness가 “어떤 값들이 필요한가”를 가리키는 개념이라면, witness vector는 그 값들을 실제 계산에 맞게 한 줄로 정리한 표현이다.

3–2. 선형결합: 값들을 식으로 묶는 방식

지금까지 회로에 등장하는 값들을 정리해서 Witness vector로 만들었다. 이제 이 값들을 이용해 각 제약 조건을 식으로 표현해야 한다. 이때 사용되는 개념이 선형결합(linear combination)이다.

선형결합이란 witness vector에 들어 있는 값들에 각각 계수를 곱한 뒤 모두 더한 식을 말한다. 예를 들어 witness vector가 w = [1, x, y, v1, v2, v3]라고 하자.

이때 계수 벡터 [5, 0, 0, 0, 0, 1]은 다음 식을 뜻한다.

(5 × 1) + (0 × x) + (0 × y) + (0 × v1) + (0 × v2) + (1 × v3) = v3 + 5

표 안에 적힌 숫자들은 witness vector의 값들을 어떤 계수로 조합할지를 나타낸다.

R1CS에서는 각 제약식을 세 개의 선형결합으로 표현하고, 이들이 L(w) * R(w) = O(w)를 만족하도록 만든다.

여기서 L(w)는 왼쪽 입력, R(w)는 오른쪽 입력, O(w)는 출력에 해당한다. 예를 들어 v3 + 5 = y라는 제약식은 R1CS에서 곱셈 형태를 유지해야 하므로 (v3 + 5) × 1 = y로 바꿔 쓸 수 있다.

이때 v3 + 5, 1, y가 각각 하나의 선형결합이 된다.

중요한 점은 덧셈과 상수항이 별도의 새로운 곱셈 제약을 만드는 것이 아니라, 하나의 선형결합 안에 함께 들어간다는 것이다.

R1CS는 덧셈과 상수항을 왼쪽이나 오른쪽 선형결합 안에 흡수한 뒤, 이를 하나의 곱셈 제약으로 표현한다.

이처럼 R1CS는 각 제약식을 세 개의 선형결합으로 나눈 뒤, 이들이 L(w) × R(w) = O(w)를 만족하는지 확인하는 방식으로 회로 전체를 검사한다.

3–3. 행렬 A, B, C: 각 제약식을 행렬의 한 행으로 옮기기

R1CS에서는 각 제약식을 먼저 L(w) × R(w) = O(w) 형태의 세 개의 선형결합으로 표현한다. 다음 단계에서는 이 선형결합들을 행렬 형태로 정리해야 한다.

이를 위해 R1CS는 각 제약식을 행렬 A, B, C의 같은 행 번호에 옮겨 적는다.

행렬 A의 각 행은 왼쪽 입력 L(w)를, 행렬 B의 각 행은 오른쪽 입력 R(w)를, 행렬 C의 각 행은 출력 O(w)를 나타낸다. 이렇게 각 제약식을 한 행씩 기록하면 회로 전체를 세 개의 행렬로 정리할 수 있다.

예를 들어 G1에 대응하는 제약식 x × x = v1을 보면, 행렬 A와 B의 해당 행에서는 x 열에 1이 들어가고, 행렬 C에서는 v1 열에 1이 들어간다. 이는 왼쪽의 x와 오른쪽의 x를 곱해 결과 v1을 만든다는 뜻이다.

G4에 대응하는 제약식 v3 + 5 = y는 덧셈 형태이지만, R1CS에서는 이를 곱셈 형태로 바꿔 표현해야 한다. 따라서 이 식은 (v3 + 5) × 1 = y로 다시 쓸 수 있다. 여기서 왼쪽 선형결합은 v3 + 5이고, 오른쪽 선형결합은 1, 출력은 y가 된다.

따라서 행렬 A의 해당 행에서는 v3에 해당하는 열에 1이 들어가고, 상수항 1에 해당하는 열에는 5가 들어간다.

행렬 B에서는 상수항 1에 해당하는 열에 1이 들어가고, 행렬 C에서는 y에 해당하는 열에 1이 들어간다.

덧셈이 들어 있는 식도 선형결합과 상수항을 활용해 하나의 곱셈 제약식 안에서 표현할 수 있다.

3–4. 행렬 방정식: 최종 검증

앞에서 각 제약식을 세 개의 선형결합 L(w), R(w), O(w)로 표현했다면, 이를 행렬과 벡터의 곱 형태로 묶어 한 번에 계산할 수 있다.

R1CS의 최종 검증은 아래 방정식으로 이루어진다.

(A · w) × (B · w) = (C · w)

A · w는 행렬 A의 각 행과 witness vector w를 내적한 결과를 뜻한다. 행렬 A의 각 행은 하나의 왼쪽 선형결합을 나타내므로, A · w를 계산하면 각 제약식의 왼쪽 입력값이 한 번에 구해진다.

예를 들어 G4에 해당하는 A의 한 행이 [5, 0, 0, 0, 0, 1]이고 witness vector가 [1, 2, 15, 4, 8, 10]이라면, A · w = (5×1) + (1×10) = 15가 된다. 이는 왼쪽 선형결합인 v₃ + 5가 계산된다는 뜻이다.

마찬가지로 B · w는 각 제약식의 오른쪽 입력값을, C · w는 각 제약식의 출력값을 모아 놓은 벡터가 된다.

여기서 (A · w) × (B · w)는 두 벡터를 하나의 값으로 곱한다는 뜻이 아니라, 각 제약식에서 계산된 왼쪽 입력값과 오른쪽 입력값을 원소별로 곱한다는 뜻이다.

R1CS는 각 행이 나타내는 제약식이 모두 성립하는지를 한 번에 확인하는 방식이다.

이 식이 묻는 것은 단순하다. 증명자가 제출한 witness vector w를 규칙인 행렬 A, B, C에 대입했을 때, 모든 제약식이 올바르게 성립하는지를 확인하는 것이다.

증명자가 정직하게 비밀 입력 x를 넣어 v1, v2, v3를 계산했다면 각 행에서 이 등식은 성립한다. 반대로 잘못된 값을 집어넣었다면, 단 하나의 제약식이라도 규칙을 어기는 순간 해당 행에서 등식이 깨진다.

이처럼 R1CS는 회로 전체를 제약식마다 따로 검사하는 대신, witness vector가 모든 제약식을 동시에 만족하는지를 한 번에 확인하는 방식으로 계산의 무결성을 검증한다.

다만 현재 단계의 R1CS는 계산의 무결성을 행렬 형태로 정리했을 뿐, 아직 비밀 입력 자체를 숨기지는 못한다. witness vector w 안에는 비밀 입력과 중간 계산값, 그리고 출력값이 그대로 들어 있기 때문이다.

또 다른 문제도 있다. 회로의 게이트가 수천 개라면 이에 대응하는 행렬 역시 수천 개의 행을 갖게 된다. 여전히 너무 비효율적이므로, 다음 단계에서는 이 제약들을 다항식으로 옮겨 더 압축해야 한다. 이것이 QAP 단계의 핵심이다.

4. QAP(Quadratic Arithmetic Program): 다항식으로 압축

R1CS의 마지막 단계에서는 (A · w) × (B · w) = (C · w) 라는 식을 통해 witness vector w가 모든 제약식을 만족하는지를 확인했다.

R1CS에서는 회로의 각 연산이 하나의 제약식으로 바뀌고, 이 제약식들이 행렬 A, B, C에 한 행씩 기록되었다. 문제는 회로가 커져 게이트 수가 늘어날수록, 그에 대응하는 제약식도 계속 늘어난다는 점이다.

QAP는 이 많은 제약식을 다항식으로 옮겨, 회로 전체가 올바르게 계산되었는지를 한 번에 확인할 수 있는 형태로 바꾸는 단계다.

핵심은 각 제약식을 따로 보는 대신, 모든 제약식이 동시에 만족한다는 조건을 하나의 다항식 관계로 압축하는 데 있다.

회로 전체가 올바르게 계산되었다면 제약식들을 결합해 만든 하나의 다항식이 특정 다항식 Z(x)로 깔끔하게 나누어떨어져야 한다는 뜻이다. 모든 제약식이 맞으면 나머지가 0이 되고, 하나라도 틀리면 나머지가 남는다.

4–1. 라그랑주 보간법(Lagrange Interpolation)

몇 개의 점이 주어졌을 때, 그 점들을 정확히 지나는 하나의 다항식을 만드는 방법을 라그랑주 보간법이라 한다.

QAP에서 이 개념이 필요한 이유는, R1CS의 숫자 표를 그대로 두지 않고 다항식의 형태로 옮겨야 하기 때문이다.

지금까지는 제약식을 행렬 A, B, C에 숫자로 기록했다면, QAP에서는 각 행렬의 열(column)에 담긴 숫자들을 특정 점에서의 함수값처럼 보고, 그 점들을 지나는 다항식을 만드는 것이다.

위 그림은 설명을 위해 점 3개만 사용한 예시다. 실제 회로는 게이트가 4개이므로 각 열마다 점 4개를 지나는 다항식이 만들어진다.

이 과정을 통해 행렬에 담겨 있던 제약식 정보는 더 이상 단순한 숫자 표가 아니라, 하나의 다항식 관계로 다시 표현될 수 있다. 즉 라그랑주 보간법은 R1CS의 정보를 QAP의 언어인 다항식으로 번역해 주는 도구다.

예를 들어 어떤 열의 값이 세 점 x=1, x=2, x=3에서 각각 [1, 3, 2]라고 하자. 그러면 QAP에서는 이 값을 단순히 벡터 [1, 3, 2]로 두는 대신, (1,1), (2,3), (3,2)를 정확히 지나는 하나의 다항식을 만든다.

이후에는 이 다항식을 이용해, 특정 변수가 각 제약식에서 어떤 계수로 등장하는지를 하나의 식으로 다룰 수 있게 된다.

4-2. 행렬의 각 열을 다항식으로 바꾸기

QAP에서는 행렬 A, B, C의 각 행을 그대로 다항식으로 바꾸는 것이 아니라, 각 열(column)을 기준으로 다항식을 만든다.

그 이유는 witness vector의 각 원소가 하나의 변수에 대응하고, 각 열이 그 변수가 여러 제약식에서 어떤 계수로 등장하는지를 모아 놓은 정보이기 때문이다.

QAP는 각 열 벡터를 점값처럼 보고, 그 점들을 지나는 다항식으로 바꾼다. 이렇게 하면 행렬 A, B, C의 각 열마다 하나의 다항식이 생기며, 이를 각각 uᵢ(x), vᵢ(x), wᵢ(x)로 쓴다.

4-3. Witness와 결합해 전체 조건 만들기

다음으로는 witness의 값들과 이 다항식들을 결합해야 한다.

R1CS에서 A·w, B·w, C·w를 계산할 때 각 열에 대응하는 값에 witness의 값을 곱해 모두 더했던 것처럼, QAP에서도 각 열에 대응하는 다항식에 witness의 값을 곱해 모두 더한다.

R1CS에서 벡터로 하던 계산이 QAP에서는 다항식들의 선형결합으로 바뀌는 것이다.

이렇게 하면 왼쪽 입력, 오른쪽 입력, 출력에 대응하는 세 개의 다항식을 만들 수 있다. 이제는 각 제약식을 따로 보는 대신, 이 다항식들 사이의 관계를 한 번에 검사할 수 있다.

이를 식으로 쓰면 다음과 같다.

A(x) = Σ aᵢuᵢ(x)
B(x) = Σ aᵢvᵢ(x)
C(x) = Σ aᵢwᵢ(x)

여기서 aᵢ는 witness vector의 i번째 값이고, uᵢ(x), vᵢ(x), wᵢ(x)는 각각 행렬 A, B, C의 i번째 열에 대응하는 다항식이다.

4-4. Z(x)로 나누어떨어진다는 뜻

각 열을 다항식으로 바꾸고, 여기에 witness의 값을 곱해 모두 더하면 왼쪽 입력, 오른쪽 입력, 출력에 해당하는 세 개의 다항식을 만들 수 있다.

QAP의 핵심은 이 세 다항식이 R1CS의 제약식과 같은 관계를 유지하는지 확인하는 것이다.

QAP에서는 A(x) × B(x) = C(x)라는 관계가 각 제약식에 대응하는 점들에서 모두 성립해야 한다.

만약 모든 제약식이 올바르게 만족한다면, A(x) × B(x) — C(x)로 만든 P(x)는 그 모든 점에서 0이 된다.

P(x)는 모든 제약식 위치에서 0이 되므로, 그 점들을 모두 근으로 갖는 다항식 Z(x)를 인수로 가져야 한다.

따라서 P(x)는 Z(x)로 나누어떨어진다.

이를 식으로 쓰면 다음과 같다.

A(x)B(x) — C(x) = H(x)Z(x)

여기서 H(x)는 나누었을 때의 몫에 해당하는 다항식이다.

Z(x)는 각 제약식에 대응하는 점들에서 0이 되도록 만든 다항식이다.

예를 들어 제약식이 3개라면, Z(x)는 (x — 1)(x — 2)(x — 3)처럼 각 제약식의 지점에서 0이 되도록 만든다. (즉, 각 제약식의 지점을 근으로 갖는다.)

따라서 모든 제약식이 맞다면 P(x)는 Z(x)로 깔끔하게 나누어떨어져야 한다.

반대로 제약식 중 하나라도 틀리면 어떤 점에서는 P(x)가 0이 되지 못하고, 그 결과 Z(x)로 나누었을 때 나머지가 남는다.

즉 QAP는 “모든 제약식이 만족한다”라는 사실을 “특정 다항식으로 나누어떨어진다”라는 하나의 조건으로 압축해 표현한 것이다.

4–5. 슈왈츠-지펠 정리(Schwartz-Zippel Lemma)

그런데 P(x)가 정말로 Z(x)로 나누어떨어지는지 확인하려면, 원칙적으로는 여러 점에서 다항식 관계가 성립하는지를 모두 검사해야 할 것처럼 보인다. 하지만 이런 방식은 너무 비효율적이다.

이렇게 하면 제약식 수가 n개일 때 검사도 그에 비례해 늘어나므로 O(n)에 가까운 확인이 필요하다.

Groth16은 이 과정을 훨씬 짧게 검사할 수 있는 방향으로 바꾼다. 그것이 가능하도록 설명해 주는 것이 바로 슈왈츠-지펠 정리다.

이 정리는 서로 다른 두 다항식이 임의의 한 점에서 우연히 같은 값을 가질 확률은 매우 낮다는 사실을 말해 준다.

즉 두 다항식이 정말로 같다면 어느 점에서 평가해도 같은 값을 내겠지만, 서로 다른 다항식이라면 우연히 같은 값을 갖는 점의 수는 다항식의 차수 이하로 제한된다.

따라서 가능한 점의 후보가 충분히 많다면, 대부분의 점에서는 서로 다른 값을 낸다고 볼 수 있다.

모든 점을 하나하나 전부 확인하지 않더라도, 무작위로 한 점만 뽑아 비교하는 방식으로도 오류 없이 거의 안전하게 검사할 수 있다는 것이다.

이는 제약식 수에 비례하던 O(n) 검사를 상수 개의 비교인 O(1)에 가까운 검사로 압축하는 셈이다.

물론 이 방식이 100% 절대적인 검사는 아니다. 서로 다른 두 다항식도 우연히 같은 값을 갖는 점이 있을 수 있기 때문이다.

하지만 그 가능성은 매우 제한적이다. 더 정확히는, 차수가 d인 서로 다른 두 다항식을 후보 점이 |S|개인 집합에서 무작위로 비교할 때 우연히 같은 값을 낼 확률은 최대 d / |S|로 제한된다.

여기서 |S|는 무작위로 점을 고를 수 있는 후보의 개수이고, Groth16에서는 이런 계산이 주로 유한체(Field) 위에서 이루어진다.

즉 다항식의 차수보다 무작위로 고를 수 있는 점의 후보가 훨씬 많다면, 잘못된 다항식이 우연히 통과할 가능성은 극히 낮아진다.

4–6. 무작위 점을 숨겨야 한다

여기서 이런 의문이 생길 수 있다. “그렇다면 무작위 점 r 하나를 골라서, 그 점에서만 다항식을 비교하면 끝나는 거 아닌가?”

하지만 그 점이 그대로 공개되면 문제가 생긴다. 증명자가 미리 그 점을 알고 있다면, 전체 다항식 관계는 틀렸더라도 오직 그 한 점에서만 맞도록 값을 조작할 여지가 생기기 때문이다.

슈왈츠-지펠 정리가 “한 점만 비교해도 충분할 수 있다”라는 직관을 준다면, 그다음 문제는 그 점을 어떻게 숨긴 채 사용할 것인가이다.

무작위 한 점에서 평가하는 이 아이디어가 제대로 작동하려면 그 평가 지점은 증명자에게 알려지지 않아야 한다.

바로 여기서 Trusted Setup이 필요해진다. Trusted Setup은 이후의 증명과 검증에서 사용할 비밀 평가 지점에 관한 정보를 미리 준비하는 단계다.

[Insight] 증명자의 말을 어떻게 믿을까?

ZKP는 증명자가 어떤 특정한 값을 알고 있다는 사실, 혹은 어떤 계산이 올바르다는 사실을 증명하는 기술이다.

하지만 현실의 데이터를 다루는 순간 자연스럽게 이런 의문이 생긴다. “증명자가 들고 온 그 값이 애초에 진짜라는 것은 어떻게 믿을 수 있을까?”

이때 등장하는 개념이 커밋먼트(commitment)다. 커밋먼트는 값을 직접 공개하지 않으면서도, “나는 처음부터 이 값을 가지고 있었다”라는 사실을 묶어 두는 장치다.

쉽게 말해 값을 숨긴 채 봉인해 두었다가, 나중에 그 값이 바뀌지 않았음을 보여주는 방식이라고 생각하면 된다.

현실 세계의 데이터 인증에서는 이런 장치가 특히 중요하다.

예를 들어 어떤 나이 정보가 정부가 발급한 진짜 데이터인지, 어떤 잔액 정보가 거래소나 블록체인 상태와 연결된 실제 값인지를 보여주려면 그 값의 출처를 함께 확인할 수 있어야 한다.

즉 현실 데이터의 증명에서는 계산 결과뿐 아니라 데이터의 무결성도 함께 보장해야 한다.

해시 함수는 이러한 커밋먼트를 구현하는 대표적인 수단 중 하나다. 기관이 보증한 데이터의 해시값을 미리 고정해 두면, 증명자는 나중에 자신이 가진 값이 그 해시와 연결된 진짜 데이터임을 증명할 수 있다.

이더리움에서는 상태 루트(State Root)가 이런 역할을 한다.

다만 검증 기관의 직접적인 협조가 항상 필요한 것은 아니다.

예를 들어 정부나 거래소가 ZKP 시스템을 따로 도입하지 않았더라도, 사용자가 서버와 주고받은 HTTPS(TLS) 통신 기록 자체를 증명 대상으로 삼는 방법이 있다.

이것이 zkTLS의 핵심 아이디어다.

실제로 zkPass 같은 프로젝트들은 이러한 방식을 활용해, 기관의 직접 협조 없이도 특정 데이터가 진짜임을 증명하려 한다.

다만 모든 ZKP가 이런 커밋먼트를 필요로 하는 것은 아니다.

순수하게 수학적 관계를 증명할 때는 값의 출처보다 그 관계가 성립하는지가 핵심이기 때문이다.

예를 들어 “나는 y = x³ + x + 5를 만족하는 x를 알고 있다”라는 식의 증명에서는, x의 출처는 중요하지 않다. 오로지 그 값이 실제로 계산식을 만족시키는지만 중요하다.

반대로 현실의 데이터를 증명하려면, “무엇이 참인가”뿐 아니라 “그 데이터가 어디서 왔는가”까지 함께 다뤄야 한다.

ZK-Friendly Hash: 왜 SHA-256 대신 Poseidon을 쓸까

ZKP에서 해시를 사용하기로 했다면, 그때부터는 어떤 해시 함수를 선택하느냐가 회로의 비용과 증명 생성 속도를 크게 좌우한다.

게이트의 수를 최대한 줄이는 것이 ZKP 회로 설계의 핵심이기 때문에, 실제 프로젝트에서는 제약 조건 수를 줄이기 위해 ZKP 친화 해시 함수를 사용하는 경우가 많다.

SHA‑256은 데이터를 0과 1의 비트 단위로 쪼개 XOR, AND 같은 비트 연산을 수행한다. 비트코인의 PoW와 주소 생성 등 블록체인 전반에 쓰이는 표준이지만, ZK 회로에서는 문제가 된다.

ZK 회로는 유한체 기반의 산술 연산 체계를 사용하기 때문에, 비트 연산 기반인 SHA‑256을 쓰면 정수를 비트 단위로 하나씩 분해하는 매우 비효율적인 과정을 거쳐야 한다. 이 과정에서 수만 개의 게이트가 발생해 증명 생성 속도가 급격히 느려진다.

반면 Poseidon은 애초에 ZKP를 위해 설계된 해시 함수로, 유한체 위에서의 덧셈 및 곱셈만으로 정의된다. 유한체 위의 산술 연산에 잘 맞게 구성되어 있다.

그래서 별도의 비트 분해 과정 없이 회로에 넣을 수 있고, SHA-256보다 훨씬 적은 게이트 수로 같은 성능을 낼 수 있다.

실제로 SHA‑256 대비 제약 조건을 적게는 50분의 1에서, 많게는 200분의 1 수준까지 줄여주는 것으로 알려져 있다. 제약 조건 수가 적을수록 증명 생성 속도가 빨라지기 때문에, Groth16을 비롯한 ZKP 시스템에서는 SHA‑256 대신 Poseidon 같은 ZK‑Friendly 해시 함수를 쓰는 것이 일반적이다.

다만 Poseidon을 포함해 ZK-Friendly 해시들은 비교적 최근에 만들어졌고, 일부 보안성 논란이 존재한다.

이론적으로는 안전하다고 평가받지만 검증의 역사가 짧다. 이더리움 재단은 2024년부터 Poseidon 보안 분석 프로그램을 운영하고 있는데, 그 과정에서 후속 버전인 Poseidon2는 라운드를 늘려야 할 수 있다는 분석이 나오기도 했다. 그래서 SHA-256이나 SHA-3만큼 신뢰하기에는 아직 보수적인 시각이 남아 있다.

Part2: 증명 시스템(Proof System): 간결함에 ZK 더하기

• Part1에서 완성한 다항식은 간결하지만, witness에 담긴 값들이 그대로 드러나 있다
• 타원곡선의 성질을 이용해 witness를 직접 드러나지 않는 형태로 바꿔야 한다
• 이 과정을 통해 간결한 증명(SNARK)에 영지식(Zero-Knowledge)을 더해 zk-SNARK를 완성한다

Part1 산술화 단계에서는 증명하고 싶은 현실의 논리를 컴퓨터가 이해할 수 있는 수학의 언어로 바꾸고 하나의 다항식으로 압축하는 것을 다뤘다. 말하자면 zk-SNARK에서 S에 해당하는 간결함(Succinctness)의 토대를 만드는 것까지 한 것이다.

하지만 이 상태로는 아직 witness를 지킬 수 없다. Part1이 S를 구현하는 데 초점이 맞춰졌다면, Part2에서는 압축한 다항식을 직접 드러나지 않는 형태로 변환하는 과정을 다룬다.

구체적으로는 신뢰 설정과 타원곡선 페어링을 결합해, witness는 숨기면서 결과가 참이라는 사실만을 전달하는 영지식(Zero-Knowledge)을 구현하여 zk-SNARK를 완성하는 과정을 다룰 것이다.

[용어 정리] 군(Group), 환(Ring), 체(Field)

Groth16을 제대로 이해하려면 반드시 알아야 할 개념이 군(Group), 환(Ring), 체(Field)다.

군, 환, 체는 서로 완전히 별개의 개념이라기보다, 허용되는 연산 규칙이 점점 더 많아지는 대수적 구조로 이해하면 쉽다.

다만 Groth16에서 특히 중요한 것은 계산의 기반이 되는 체와 보안의 기반이 되는 군이다. 환은 그 사이를 연결해 주는 중간 구조로 이해하면 된다.

군은 하나의 연산을 다루는 가장 기본적인 구조이고, 환은 여기에 또 하나의 연산이 더해져 덧셈과 곱셈을 함께 다루며, 그 사이에 분배법칙이 성립하는 구조다.

체는 여기서 더 나아가, 0이 아닌 모든 원소에 대해 곱셈 역원이 존재해 나눗셈까지 가능한 구조다.

예를 들어 실수 집합 ℝ은 무한체이지만, 정수 집합 ℤ는 체가 아니다. 정수에서는 5 ÷ 2 = 2.5처럼 나눗셈 결과가 다시 정수 안에 머물지 않기 때문이다.

이 차이는 Groth16의 앞부분과 뒷부분을 이해할 때 특히 중요하다. 지금까지 Part 1에서 우리가 다뤘던 산술 회로, R1CS, QAP는 모두 유한체(Finite Field) 위의 계산이었다.

다항식과 계수, witness 값이 일정한 규칙 안에서 안정적으로 계산될 수 있었던 이유도 유한체가 체 구조를 이루기 때문이다.

Part 2에서도 유한체는 여전히 중요하다.

다만 Part 2에서는 유한체 위에 정의된 타원곡선의 점들이 아벨 군(Abelian Group)을 이루며, Groth16은 이 타원곡선 위의 점들을 군 원소로 사용해 계산 결과를 숨긴 채 증명과 검증을 수행한다.

즉 Part 1이 유한체 위에서 계산을 압축하는 과정이었다면, Part 2는 그 유한체 위에 정의된 타원곡선 군을 이용해 이를 안전하게 증명하는 단계다.

유한체에서는 모든 계산이 정해진 범위 안에서 순환한다. 예를 들어 𝔽7에서는 모든 계산을 mod 7로 하므로, 8은 1로, 10은 3으로 다시 돌아온다.

마치 시계가 12시를 넘으면 다시 1시로 돌아오는 것처럼, 정해진 범위를 넘으면 다시 처음으로 돌아온다고 생각하면 된다.

이때 항등원(identity)은 연산해도 값이 변하지 않게 만드는 원소다. 덧셈에서는 0이, 곱셈에서는 1이 항등원이다.

역원(inverse)은 어떤 원소와 연산했을 때 항등원을 만들어 주는 짝 원소다. 예를 들어 𝔽7에서 3의 덧셈 역원은 4다. 3 + 4 = 7 ≡ 0 (mod 7)이기 때문이다.

곱셈 역원도 존재한다. 𝔽7에서 3의 곱셈 역원은 5다. 3 × 5 = 15 ≡ 1 (mod 7)이기 때문이다. 따라서 유한체에서의 나눗셈은 실수처럼 소수로 표현되는 과정이 아니라, 곱셈 역원을 찾아 곱하는 방식으로 이해할 수 있다.

예를 들어 3으로 나눈다는 것은 3의 역원인 5를 곱하는 것과 같다.

반면 아벨 군(Abelian Group)은 군의 성질을 만족하면서, 연산의 순서를 바꿔도 결과가 같은 구조다. 예를 들어 두 점 P와 Q에 대해 P + Q = Q + P가 성립한다.

타원곡선에서는 점과 점을 더하는 연산이 이러한 아벨 군 구조를 이룬다.

Groth16은 계산 결과를 이런 군 원소의 형태로 표현함으로써, 값 자체는 감추면서도 검증할 수 있는 형태를 만든다.

그렇다면 왜 하필 군 중에서도 타원곡선 위의 아벨 군이 선택될까? 이제부터는 Groth16에서 타원곡선이 어떤 역할을 하는지 차례대로 살펴보자.

5. 타원곡선과 신뢰 설정(Elliptic Curve & Trusted Setup)

Part 1에서 우리는 유한체 위에서 산술 회로를 만들고, 이를 R1CS와 QAP를 거쳐 하나의 다항식 관계로 압축했다.

하지만 이 상태만으로는 witness가 그대로 드러나므로, 아직 영지식성은 확보되지 않는다.

이제 Part 2에서는 압축한 다항식 관계를 타원곡선 위의 군 원소로 표현해, witness는 감춘 채 계산이 올바르다는 사실만 검증할 수 있도록 만들어야 한다.

이 과정에서 핵심이 되는 것이 타원곡선과 신뢰 설정이다.

5–1. 왜 하필 타원곡선일까?

타원곡선은 고등학교 수학에서 보던 단순한 그래프라기보다, 암호학에서 특별한 성질을 가진 점들의 집합으로 이해하는 편이 좋다.

Groth16에서 중요한 것은 곡선의 모양 자체보다, 그 위의 점들을 일정한 규칙으로 다룰 수 있다는 사실이다.

우리가 실수 위에서 타원곡선을 그리면 하나의 매끈한 곡선처럼 보인다. 하지만 Groth16에서 실제로 사용하는 것은 이런 연속적인 곡선이 아니다.

앞에서 보았듯 Part 1의 계산은 모두 유한체 위에서 이루어졌고, 타원곡선 역시 그 유한체 위에서 정의된다.

유한체를 사용하는 가장 큰 이유는 보안이다. 실수 위에서는 값이 연속적으로 변하기 때문에, 결과를 보고 원래 값을 거슬러 추적하는 것이 쉽다. 반면 유한체 위에서는 모든 값이 mod p라는 울타리 안에 갇혀 있다. 값이 아무리 커지거나 음수가 되어도 다시 정해진 범위 안으로 돌아오기 때문에, 결과만 보고 원래 값을 추적하는 것이 사실상 불가능해진다. 이것이 뒤에서 볼 이산로그 문제의 기반이다.

또한 유한체에서는 0이 아닌 모든 값에 역원이 있어서 나눗셈이 항상 가능하다. 앞에서 본 라그랑주 보간처럼 나눗셈이 필요한 계산을 안심하고 할 수 있는 이유다. 덤으로 1/3 같은 무한소수(0.333…)는 컴퓨터 안에서 근삿값으로 저장되는데, 유한체를 사용하면 애초에 이러한 문제가 발생하지 않아서 컴퓨터로 오차 없이 정확하게 계산할 수 있다.

그래서 유한체 위의 타원곡선은 매끈한 선이 아니라, 좌표가 모두 정수인 점들이 정해진 범위 안에서 흩어져 있는 모습으로 보인다. 예를 들어 위 그림 속 점들은 오직 mod 47이라는 유한한 울타리 안에서만 정의된다.

그 결과 실수 평면에서 보던 연속적인 곡선과 달리, 유한체 위의 타원곡선은 불연속적인 점들의 집합처럼 보인다.

중요한 것은 이 점들이 단순히 흩어져 있기만 한 것이 아니라, 점과 점을 더하는 연산이 정의되어 있다는 사실이다. 그리고 그렇게 더한 결과도 다시 같은 점들의 집합 안에 머문다. 즉 타원곡선 위의 점들은 앞에서 봤던 군(Group)의 구조를 이룬다.

아직까지는 타원곡선을 고집할 이유가 없다. 왜냐하면 단순히 mod p 위에서 곱셈을 반복하는 군도 비슷한 성질을 갖기 때문이다. 그럼에도 타원곡선을 쓰는 이유는 크게 두 가지다.

타원곡선은 효율적이다. 타원곡선 위의 이산로그 문제는 일반적인 mod p 위의 문제보다 훨씬 풀기 어렵다. 그래서 256비트짜리 타원곡선이 약 3072비트짜리 RSA와 비슷한 수준의 보안을 낸다. 숫자가 작으면 증명도 작아지고 계산도 빨라진다. Groth16의 증명이 128바이트 남짓으로 작은 것도 이 덕분이다.

페어링을 쓸 수 있다. Groth16의 검증자는 숨겨진 값들 사이에 A × B = C 같은 곱셈 관계가 성립하는지 확인해야 한다. 그런데 일반적인 군에서는 값을 숨긴 채로 더하는 것까지는 할 수 있어도, 곱셈 관계를 확인할 방법이 없다. 이걸 가능하게 해주는 도구가 뒤에서 다룰 페어링이다. 그리고 암호학에서 쓸 만한 페어링은 사실상 타원곡선 위에서만 만들 수 있다. Groth16이 타원곡선을 쓸 수밖에 없는 결정적인 이유다.

타원곡선을 쓰기 때문에 Part 1에서 만든 다항식 관계를 그대로 드러내는 대신 그 결과를 타원곡선 위의 점들로 옮겨 숨길 수 있고, 그 숨긴 상태 그대로 빠르게 검증할 수 있게 된다.

5–2. 타원곡선 위의 점은 어떻게 더할까?

타원곡선 위의 점들은 보통 숫자처럼 더하는 것이 아니다. 대신 곡선 위의 두 점을 이용해 새로운 점을 만들어 내는 특별한 덧셈 규칙을 사용한다.

서로 다른 두 점 P와 Q가 있다고 하자. 이 두 점을 지나는 직선을 그으면, 그 직선은 타원곡선과 한 번 더 만나게 된다. 이렇게 얻은 세 번째 점을 그대로 쓰는 것이 아니라, x축에 대해 대칭시킨 점을 P + Q로 정의한다.

한마디로 두 점을 잇고, 곡선과 다시 만나는 점을 찾은 뒤, 그 점을 x축에 대해 대칭시키는 방식이다.

같은 점을 두 번 더할 때도 원리는 같다. 원래는 두 점을 지나는 직선을 그어야 하지만, 두 점이 완전히 같아지면 하나의 직선을 정하기 애매해진다.

그래서 P와 아주 가까운 다른 점을 하나 생각하고, 그 점을 점점 P에 가깝게 보낸다고 상상하는 것이다.

그 차이가 아주 미세해서 구분할 수 없을 정도로 가까워졌다고 상상하고 두 점을 잇는 직선을 그리면 결국 P에서의 접선으로 바뀐다.

따라서 P + P를 구할 때는 P에서의 접선을 그린 뒤, 곡선과 다시 만나는 점을 찾고, 마지막으로 x축 대칭을 취해 2P를 얻는다.

중요한 것은 이 연산의 결과가 다시 타원곡선 위의 점으로 돌아온다는 점이다. 점과 점을 더해도 결과가 다시 같은 점들의 집합 안에 머문다.

5–1에서 다룬 것처럼 유한체 위의 타원곡선은 mod p라는 울타리 안에서만 움직이므로, 점 덧셈의 결과도 결국 그 울타리 안으로 다시 돌아오게 된다.

이러한 타원곡선 위의 특이한 점 덧셈 성질이 타원곡선 암호의 원리가 되어 이산로그 문제로 이어진다.

5–3. 생성자 G와 반복 덧셈

점 덧셈 규칙을 알았으니, 그 연산을 여러 번 반복하면 어떤 일이 일어나는지 알아봐야 한다. 타원곡선 암호에서는 보통 곡선 위의 특정한 기준점 하나를 먼저 정해 두는데, 이 점을 생성자 G라고 부른다.

생성자 G는 특별한 시작점이다. 이 점에 점 덧셈을 반복하면 2G, 3G, 4G처럼 새로운 점들을 계속 만들어 낼 수 있다. 여기서 2G는 G를 두 번 더한 것이고, 3G는 G를 세 번 더한 것이다.

곱셈 기호처럼 보이지만, 실제로는 숫자와 점의 일반적인 곱셈이 아니라 같은 점을 여러 번 더한 반복 덧셈이라고 이해해야 한다.

중요한 것은 이 반복 덧셈이 계산하기는 쉽다는 점이다. 컴퓨터는 생성자 G와 횟수 n이 주어지면, nG라는 결과 점을 비교적 빠르게 구할 수 있다. 하지만 반대로 결과 점만 주어졌을 때, “이 점이 G를 몇 번 더한 것인지”를 거꾸로 알아내는 것은 매우 어렵다.

바로 이 비대칭성이 타원곡선 암호의 핵심이다. 정방향 계산은 쉽지만, 역방향 계산은 어렵다. Groth16 역시 이 성질을 이용해 계산에 필요한 값을 타원곡선 위의 점으로 표현하고, 값 자체는 숨긴 채 검증할 수 있도록 만든다.

5–4. 이산로그 문제: 역산의 어려움

생성자 G와 정수 n이 주어졌을 때 nG를 계산하는 것은 비교적 쉽다. 점 덧셈 규칙이 이미 정해져 있고, 이를 반복하거나 두 배씩 키워 가며 빠르게 계산할 수 있기 때문이다.

하지만 그 반대는 어렵다. 어떤 점 P가 주어졌을 때, 이것이 생성자 G를 몇 번 더한 결과인지, P = nG를 만족하는 n을 찾아내는 것은 매우 어렵다.

이 문제를 타원곡선 위의 이산로그 문제(Discrete Logarithm Problem, DLP)라고 한다. 이름은 어렵지만 뜻은 단순하다. 결과가 되는 점은 알고 있지만, 그 점이 생성자 G를 몇 번 더한 것인지 거꾸로 맞혀야 하는 문제라는 뜻이다.

예를 들어 누군가가 G를 여러 번 더해 어떤 점 P를 만들었다고 하자. 정방향 계산은 직접 더해 가면 되므로 비교적 빠르게 수행할 수 있다. 하지만 P만 보고 “이게 도대체 G를 몇 번 더한 결과인지”를 찾으려면, 가능한 경우를 하나씩 확인해 보는 것 말고는 뾰족한 방법이 없다.

양자컴퓨팅이라도 쓰지 않는 이상, 점의 개수가 매우 커질수록 이 역산은 사실상 불가능에 가까워진다.

이런 역산의 어려움 덕에 타원곡선 암호가 성립된다. 정직한 사용자는 비밀값 n과 생성자 G가 주어졌을 때 nG를 빠르게 계산할 수 있다. 반면 외부에서 결과 점만 본 사람은 원래의 n을 복원하기가 매우 어렵다.

Groth16을 비롯한 타원곡선 기반 암호는 모두 이 성질을 이용한다. 값을 타원곡선 위의 점으로 표현하면, 계산은 가능하지만 원래 값을 거꾸로 알아내기는 매우 어려워진다.

타원곡선은 단순히 계산을 위한 구조가 아니라, 값을 숨긴 채 다룰 수 있게 만드는 보안의 기반이 된다.

[Insight] 1000G는 정말 1000번 더해야 할까?

nG는 생성자 G를 n번 더한 반복 덧셈이라고 설명했다. 그렇다면 1000G를 구하려면 정말로 G를 1000번 더해야 할까? 겉보기에는 그렇게 보이지만, 실제로는 훨씬 빠르게 계산할 수 있다.

핵심은 같은 점을 두 번 더하는 계산을 반복해서 활용하는 것이다. 예를 들어 2G는 G를 두 번 더한 것이고, 4G는 2G를 다시 두 번 더한 것이다. 같은 방식으로 8G, 16G, 32G처럼 큰 값을 빠르게 만들 수 있다.

즉 nG는 단순한 반복 덧셈이 아니라, 숫자를 2의 거듭제곱들의 합으로 쪼개어 계산하는 방식에 가깝다. 이는 2진법으로 수를 표현하는 방식과도 비슷하다.

예를 들어 1000은 512 + 256 + 128 + 64 + 32 + 8로 쓸 수 있으므로, 1000G도 512G + 256G + 128G + 64G + 32G + 8G처럼 계산할 수 있다.

이 항들은 모두 G를 반복해서 두 배로 키우는 과정에서 얻을 수 있다. 그래서 1000번을 직접 더하는 대신, 몇 번의 두 배 계산과 몇 번의 점 덧셈만으로 같은 결과를 훨씬 빠르게 구할 수 있다.

이 성질은 암호학에서 매우 중요하다. 정직한 사용자는 비밀값 n과 생성자 G가 주어졌을 때 nG를 효율적으로 계산할 수 있어야 하기 때문이다.

타원곡선 암호는 정방향 계산은 빠르되 역방향은 어렵다는 이 비대칭성을 이용한다.

5–5. 신뢰 설정(Trusted Setup)

앞의 4–6에서 우리는 슈왈츠-지펠 정리를 이용한 한 점 검증이 성립하려면, 그 무작위 평가 지점이 증명자에게 알려져서는 안 된다는 사실을 보았다.

만약 증명자가 그 값을 미리 안다면, 원래는 성립하지 않는 다항식 관계라도 오직 그 한 점에서만 맞는 것처럼 식을 조작할 여지가 생기기 때문이다.

그렇다면 그 비밀 평가 지점을 실제 증명 시스템 안에서 어떻게 숨긴 채 사용할 수 있을까?

지금까지 Part 2 앞부분에서는 이 질문에 답하는 데 필요한 배경을 먼저 살펴보았다. 유한체 위에서 계산이 어떻게 이루어지는지, 타원곡선 위의 점들이 어떤 식으로 더해지는지, 그리고 왜 역산이 어려운지를 본 이유가 바로 여기에 있다.

이제는 그 성질들을 실제로 어떻게 활용하는지를 볼 차례다.

Groth16은 이 문제를 해결하기 위해, 비밀 평가 지점 τ를 직접 공개하지 않은 채 이후 계산에 활용할 수 있도록 미리 준비해 둔다.

이 값은 문헌에 따라 τ(tau) 혹은 s로 표기한다. 이 글에서는 τ라고 쓰겠다.

이 준비 단계가 바로 신뢰 설정(Trusted Setup)이다.

예를 들어 어떤 다항식 f(x)를 비밀값 τ에서 평가하려면, 결국 이후 증명과 검증에서는 τ 자체를 직접 공개하는 대신, τ를 드러내지 않고도 그와 관련된 계산을 할 수 있는 재료가 필요하다.

5–6. 비밀 평가 지점 τ를 어떻게 숨길까?

앞 절에서는 신뢰 설정의 목적이 비밀 평가 지점 τ를 직접 드러내지 않은 채, 이후 증명과 검증에 필요한 공통 재료를 미리 준비해 두는 데 있다는 점을 보았다.

신뢰 설정이 만드는 재료를 구체적으로 알아보자.

가장 단순한 예로, 어떤 다항식이 f(x) = a + bx + cx²라면 이를 비밀값 τ에서 평가한 값은 f(τ) = a + bτ + cτ²가 된다.

즉 다항식을 τ에서 평가하려면 결국 1, τ, τ² 같은 항이 필요하다. 그래서 신뢰 설정은 τ 자체를 숫자로 공개하는 대신, 그 값을 타원곡선 위의 점으로 바꾼 형태로 준비해 둔다.

5–3에서는 설명을 단순하게 하려고 생성자를 G라고 불렀지만, 수학 및 암호학 문헌에서는 군과 생성자를 구분해 적는 경우가 더 많다.

보통 G₁, G₂는 두 타원곡선 군 전체를 가리키고, 그 안의 생성자 점은 g₁, g₂처럼 소문자로 적는다.

다만 입문 설명에서는 생성자를 대문자 G로 쓰는 경우도 흔하다.

이후부터는 정확한 구분을 위해 표준적인 표기 관례를 따라 쓰겠다.

타원곡선은 보통 y² = x³ + ax + b 같은 방정식으로 정의되고, 그 방정식을 만족하는 점들 가운데 우리가 사용하는 특정 집합이 군 G₁, G₂가 된다.

대문자 G₁, G₂는 군 전체를 가리키고, 소문자 g₁, g₂는 그 군 안의 특정 점, 보통 생성자를 뜻한다.

그래서 g₁ ∈ G₁ g₂ ∈ G₂ 라고 표기하며, 이는 g₁이 G₁이라는 군에 속한 점이고, g₂는 G₂라는 군에 속한 점이라는 뜻이다.

그리고 신뢰 설정은 보통 다음과 같은 형태의 값들을 준비한다.

[g₁], [τg₁], [τ²g₁], …
[g₂], [τg₂], [τ²g₂], …

여기서 대괄호는 “이 값을 타원곡선 위의 점으로 바꿔 둔 형태”라고 이해하면 된다.

중요한 것은 τ를 숫자로 직접 주는 것이 아니라, τ를 타원곡선 위의 점으로 바꾼 값만 준다는 점이다. 이렇게 하면 이후 계산에는 사용할 수 있지만, 그 점만 보고 원래 숫자 τ를 거꾸로 알아내기는 매우 어렵다.

여기에는 앞서 본 타원곡선의 이산로그 문제가 쓰인다.

이렇게 해두면 증명자는 τ를 직접 모르더라도, 자신이 가진 계수 a, b, c를 이용해 [a·g₁] + [b·τg₁] + [c·τ²g₁]를 조합할 수 있다. 이는 [f(τ)·g₁]에 해당한다.

비밀값 τ는 끝까지 숨겨져 있지만, 마치 다항식을 τ에서 평가한 것과 같은 결과는 만들어 낼 수 있는 것이다.

5–7. 신뢰 설정은 무엇을 만들어 내는가?

하지만 Groth16의 신뢰 설정은 τ 하나만 준비하는 것으로 끝나지 않는다. 실제로는 τ만으로는 충분하지 않다.

Groth16은 증명자가 임의의 형태로 값을 섞지 못하게 하고, 공개 입력(public input)과 witness가 각자 정해진 방식으로 들어가도록 만들기 위해 몇 개의 비밀값을 추가로 사용한다.

보통 다음 기호들이 등장한다.

τ(Tau), α(Alpha), β(Beta), γ(Gamma), δ(Delta)

이 값들은 무작위 스칼라(random scalars)이자, 신뢰 설정 단계에서만 쓰이고 폐기되는 비밀값(비밀 파라미터)이다.

각 값의 역할을 아주 간단하게만 보면, τ는 비밀 평가 지점이고, α와 β는 증명자가 임의의 점을 꾸며 내지 못하게 하는 장치다. γ와 δ는 공개 입력과 witness가 서로 다른 방식으로 들어가도록 분리하고, 증명이 정해진 형태를 따르도록 만드는 데 쓰인다.

문헌에서는 증명자와 검증자가 함께 사용하는 이런 공통 재료 묶음을 SRS(Structured Reference String, 구조화된 참조 문자열)라고 부르기도 한다.

쉽게 말해 τ를 비롯한 비밀 파라미터들과 관련된 값들을 점의 형태로 정리해 둔 공통 재료다.

그리고 이 공통 재료로부터 proving key와 verification key가 만들어진다.

proving key는 증명자가 실제 증명을 만들 때 사용하는 재료다. 여기에는 τ에서 평가된 다항식 조각들과, α, β, δ 같은 값이 섞인 군 원소들이 들어 있다.

증명자는 witness를 알고 있으면 이 재료를 조합해, witness를 직접 드러내지 않는 매우 짧은 증명을 만들 수 있다.

verification key는 검증자가 그 증명을 빠르게 확인할 때 사용하는 재료다. 여기에는 proving key보다 훨씬 작은 수의 조각만 들어 있다.

검증자는 witness도 모르고 τ도 모르지만, verification key를 이용해 제출된 증명이 정말 올바른 계산 관계에서 나온 것인지 확인할 수 있다.

정리하면, 신뢰 설정은 단순히 비밀값 하나를 정해 두는 단계가 아니다. 비밀값 τ와 α, β, γ, δ 같은 추가 값들을 이용해, 증명자에게는 proving key를, 검증자에게는 verification key를 만들어 주는 단계다.

신뢰 설정은 그저 비밀값을 숨겨 두는 데서 끝나지 않고, 이후 증명이 반드시 올바른 구조를 따르도록 강제하는 규칙까지 함께 심어 두는 과정인 것이다.

그리고 이 키들 덕분에 이후에는 비밀값 자체를 드러내지 않고도 증명을 만들고 검증할 수 있게 된다.

5–8. toxic waste

신뢰 설정에서는 위조 방지를 위해 τ, α, β, γ, δ 같은 비밀값을 사용한다.

문제는 이 값들이 신뢰 설정 과정에서만 잠깐 쓰이고, 이후에도 누군가에게 남아 있으면 안 된다는 점이다.

신뢰 설정 단계가 완전히 끝난 뒤에도 남아 있으면 위험한 잔여 비밀값을 toxic waste라고 부른다. 이름 그대로 남아 있으면 위험한 독성 폐기물 같은 값이라고 이해하면 된다.

위험한 이유는 이 값들을 알고 있으면, 신뢰 설정이 만든 구조를 악용해 마치 올바른 witness를 가진 것처럼 가짜 증명을 만들어 낼 수 있기 때문이다. 검증자는 정상적인 증명이라고 믿고 통과시킬 수 있지만, 실제로는 올바른 계산에서 나온 증명이 아닐 수도 있다.

그래서 Trusted Setup에서 가장 중요한 조건은 이 toxic waste가 누구에게도 남지 않도록 하는 것이다. 이상적으로는 신뢰 설정이 끝난 뒤, 그 값들은 완전히 폐기되어야 한다. 증명자도, 검증자도, 기타 참여한 누구도 그것을 다시 알 수 없어야 한다.

이 때문에 실제 프로토콜에서는 한 사람이 모든 비밀값을 만드는 방식보다, 여러 참여자가 함께 신뢰 설정에 참여하는 MPC(Multi-Party Computation) 방식이 자주 사용된다.

방식은 단순하다. 각 참여자가 자기만 아는 무작위 비밀 조각을 하나씩 추가해 신뢰 설정을 갱신하고, 작업이 끝나면 자신의 비밀 조각을 폐기하는 것이다. 이렇게 여러 사람의 기여가 차례로 합쳐져 신뢰 설정이 완성된다.

핵심은 참여자 전원이 정직할 필요는 없다는 점이다. 참여자 중 단 한 사람만 자신의 비밀 조각을 제대로 폐기했다면, 최종 toxic waste 전체를 복원하는 것은 불가능하다.

이처럼 MPC는 모든 사람을 믿어야 하는 구조를 딱 한 사람만 믿을 수 있다면 안전한 구조로 바꿔준다.

실제 Groth16의 신뢰 설정은 두 단계로 나뉜다. 1단계(Powers of Tau)는 τ의 거듭제곱들을 준비하는 범용 단계로, 특정 회로와 무관하다. 그래서 MPC 방식으로 수많은 참여자가 함께하는 공개 행사를 한 번 크게 열어 두고, 여러 프로젝트가 이를 가져다 재사용한다. 반면 2단계는 특정 회로의 구조를 반영하기 때문에 회로마다 따로 진행해야 한다.

문제는 바로 이 2단계에서 생긴다. 일단 재사용이 불가능하다. 회로가 조금만 바뀌어도, 심지어 버그 하나를 고쳐도 2단계를 처음부터 다시 진행해야 한다.

2단계에서도 δ 같은 비밀값이 쓰이고, 이 값이 남아 있으면 가짜 증명을 만들 수 있다. 그런데 회로마다 매번 수많은 참여자를 모으기는 어려워서, 2단계는 1단계보다 훨씬 적은 인원으로 진행되는 경우가 많다. 1단계를 아무리 크게 열더라도 실질적으로 신뢰성은 2단계에 달려 있다.

다시 말해 신뢰 설정에서 말하는 “신뢰”란 toxic waste를 제대로 폐기한 사람이 1명이라도 있을 것이라 믿어야 한다는 뜻이다. MPC를 통해 위험을 최소화한 것은 사실이지만 불안한 요소가 남아 있다.

Groth16의 강력한 효율성은 결국 이런 낙관적인 가정 위에 서 있다.

6. 증명 생성 및 검증(Proof & Verification)

남은 것은 실제 증명 생성과 검증 과정뿐이다.

Groth16은 신뢰 설정에서 만들어진 proving key와 verification key를 이용해, 증명자는 witness를 직접 드러내지 않은 채 매우 짧은 증명을 만들고, 검증자는 그 짧은 증명만으로 계산이 올바른지 빠르게 확인할 수 있게 한다.

이 과정의 핵심에는 타원곡선 위의 점 조합과, 이를 한 번에 확인하게 해 주는 페어링(pairing)이 있다.

6–1. 증명자는 실제로 무엇을 만드는가?

신뢰 설정이 끝나면 증명자는 proving key를, 검증자는 verification key를 갖게 된다.

그렇다면, proving key를 손에 넣은 증명자는 실제로 무엇을 계산해 제출하는 걸까?

가장 바깥쪽 뼈대만 먼저 보면, 증명자는 QAP의 다항식들을 비밀 평가 지점 τ에서 평가한 뒤, 그 결과를 타원곡선 위의 군 원소로 조합한다.

QAP에서 A(x), B(x), C(x)는 witness 값 aᵢ를 계수로 하여 다항식들을 선형결합한 형태였다. 따라서 증명자는 이 계수 aᵢ를 이용해 다음과 같은 값을 만든다.

아래는 이해를 위해 α, β, γ, δ, r, s를 모두 뺀 뼈대 버전이다. 실제 식은 6–7에서 완성한다.

[A]₁ = Σ aᵢuᵢ(τ)
[B]₂ = Σ aᵢvᵢ(τ)
[C]₁ = Σ aᵢwᵢ(τ) + h(τ)t(τ)

여기서 아래 첨자 ₁과 ₂는 각 점이 어느 군에 속하는지를 나타낸다. Groth16에서는 보통 A와 C는 G₁에, B는 G₂에 놓인다.

aᵢ는 witness vector의 i번째 값이다. 앞에서 w = [1, x, y, v1, v2, v3]라고 썼던 것을, 일반화해서 [a₁, a₂, …, aₘ]처럼 적은 표기라고 이해하면 된다.

uᵢ(x), vᵢ(x), wᵢ(x)는 QAP에서 만든 다항식들이고, h(x)t(x)는 모든 제약식이 만족할 때 A(x)B(x) − C(x)에 붙는 나머지 없는 보정항이다.

QAP에서는 왼쪽과 오른쪽의 곱에서 출력을 뺀 값이 t(x)로 나누어떨어져야 하므로, 이를 식으로 쓰면 A(x)B(x) = C(x) + h(x)t(x)가 된다.

이는 R1CS에서 L(w) · R(w) = O(w) 형태로 표현하던 제약식을, QAP에서 하나의 다항식 관계로 옮겨 쓴 것이다.

Groth16에서는 다시 이 다항식 관계를 비밀 평가 지점 τ에서 계산한 뒤, 타원곡선 위의 군 원소 [A], [B], [C]로 표현한다.

[A]는 왼쪽 다항식 묶음, [B]는 오른쪽 다항식 묶음, [C]는 출력 다항식과 보정항까지 포함한 결과라고 생각하면 된다.

이처럼 값을 점의 형태로 바꾼 뒤에도 더하고 조합하는 관계가 유지되는 성질을 보통 준동형성(homomorphism)이라고 한다.

[A], [B], [C]는 단순히 아무 점 세 개를 만드는 것이 아니라, witness 계수 aᵢ와 QAP 다항식들을 비밀 평가 지점 τ에서 정확히 조합해 얻은 점들이다. 그래서 올바른 witness가 아니면 이 구조를 일관되게 만들 수 없다.

따라서 실제 proof는 단순한 [A], [B], [C]만의 값이 아니다. 신뢰 설정이 만든 구조와 witness를 함께 반영한 세 개의 타원곡선 점으로 이루어진다. 이것이 Groth16에서 “증명이 단 세 점으로 압축된다”라는 말의 핵심이다.

6–2. α(Alpha)와 β(Beta)의 역할

[A], [B], [C]는 witness와 QAP 다항식을 비밀 평가 지점 τ에서 조합해 만든 점들이다. 얼핏 보면 이 세 점만으로도 괜찮은 것처럼 보인다. 하지만 이 단계만으로는 아직 증명자가 임의의 점을 꾸며 낼 가능성을 완전히 배제할 수는 없다.

우연히 맞을 수도 있다는 뜻이 아니다. 검증식이 너무 단순하면, 증명자가 진짜 witness에서 출발하지 않았더라도 검증자가 확인하는 관계만 성립하도록 점들을 의도적으로 꾸며 낼 수 있다는 뜻이다.

그래서 검증자는 단순히 [A], [B], [C]가 어떤 관계를 만족하는지만 봐서는 안 된다. 이 점들이 정말 신뢰 설정이 허용한 구조 안에서 만들어졌는지도 함께 확인할 수 있어야 한다.

여기서 α와 β가 등장한다. 이 값들은 신뢰 설정 단계에서만 쓰이는 추가 비밀값으로, 증명자가 임의의 점을 만들어 제출하더라도 검증을 통과하지 못하도록 증명 구조에 안전장치를 거는 역할을 한다.

α와 β가 추가되면서 검증자는 단순히 “세 점이 어떤 식을 만족하는가”만 보는 것이 아니라, “이 점들이 정말 올바른 witness와 신뢰 설정 구조를 반영해 만들어졌는가”까지 함께 확인할 수 있게 된다.

그래서 Groth16은 증명이 아무리 짧고 간단하더라도, 그 짧은 증명이 반드시 올바른 구조를 따르도록 강제할 수 있다.

다음 단계에서는 남은 비밀 파라미터 γ와 δ가 왜 필요한지, 이들이 공개 입력과 나머지 witness를 어떻게 구분하는지를 살펴보자.

6–3. γ(Gamma)와 δ(Delta)의 역할

α와 β가 증명 구조에 1차적인 안전장치를 거는 역할을 한다면, γ와 δ는 그 구조를 더 정교하게 다듬는다. 특히 Groth16에서는 공개 입력과 witness가 서로 다른 방식으로 처리되어야 하므로, 이를 구분해 주는 장치가 필요하다.

공개 입력은 검증자가 알고 있어야 하는 값이다. 반면 witness에는 비밀 입력과 중간 계산값처럼 검증자에게 직접 드러나면 안 되는 값들이 들어 있다.

만약 이 둘이 같은 방식으로 뒤섞여 들어가면, 검증자는 무엇이 공개되어야 하는 값인지, 무엇이 숨겨져야 하는 값인지 구분할 수 없게 된다.

바로 여기서 γ와 δ가 등장한다. 이 값들은 신뢰 설정 단계에서 공개 입력과 나머지 witness가 서로 다른 통로를 타고 들어가도록 만든다.

γ는 검증자도 알아야 하는 공개 입력 쪽을, δ는 증명자 측의 비공개 계산 쪽을 분리하는 역할을 한다.

이 덕분에 검증자는 공개 입력에 해당하는 부분만 따로 확인할 수 있고, 증명자는 나머지 witness를 숨긴 채 필요한 계산을 수행할 수 있다.

γ와 δ는 단순히 기호 몇 개를 더 붙이는 것이 아니라, 공개되어야 할 값과 숨겨져야 할 값을 구조적으로 분리해 주는 역할을 한다.

특히 δ는 증명자가 신뢰 설정에서 허용한 형태를 벗어나 임의의 값을 섞어 넣지 못하게 막는 역할도 한다.

따라서 α와 β가 증명의 큰 골격을 묶는다면, γ와 δ는 그 안에서 공개 입력과 나머지 witness를 구분하고, 증명이 정해진 통로를 따르도록 만드는 세부 장치라고 볼 수 있다.

6–4. 검증자는 실제로 무엇을 확인하는가?

여기까지 오면 증명자가 무엇을 만드는지 어느 정도 드러난다.

증명자는 witness와 proving key를 이용해 올바른 계산 관계를 반영한 세 개의 점을 만든다.

이제 검증자가 해야 할 일은, 증명자가 제출한 점들이 정말로 같은 witness와 같은 QAP 관계에서 나왔는지, 그리고 신뢰 설정이 허용한 구조를 따르는지를 확인하는 것이다.

[A], [B], [C]는 각각 따로 그럴듯해 보이는지만 보면 안 되고, 이 셋이 하나의 일관된 계산 구조를 공유하는지가 중요하다.

하지만 검증자는 witness를 직접 알지 못한다. 비밀 평가 지점 τ도 모른다. 따라서 원래 다항식을 다시 계산해 보는 방식으로는 증명을 검사할 수 없다.

대신 verification key에 들어 있는 정보와 증명자가 제출한 세 점 사이에 특정한 페어링(pairing) 관계가 성립하는지를 확인하는 방식으로 검증을 수행한다.

검증의 목표는 “이 점들이 진짜 witness에서 나왔는가?”를 직접 복원하는 것이 아니라, “이 점들이 신뢰 설정이 정한 규칙과 QAP 관계를 동시에 만족하는가?”를 보는 것이다.

Groth16의 장점은 바로 여기서 나온다. 검증자는 복잡한 회로 전체를 다시 계산하지 않고도, 매우 짧은 증명과 verification key만으로 이 관계를 빠르게 확인할 수 있다.

[A], [B], [C]가 QAP에서 나온 곱셈 관계를 빠르고 확실하게 확인하는 것이 관건인데, 단순한 타원곡선 점 덧셈만으로는 이를 한 번에 검사하기 어렵다. 그래서 페어링이 필요해진다.

6–5. 페어링(Pairing)이란?

값을 타원곡선 위의 점으로 옮긴 이유는, 앞에서 본 이산로그 문제를 이용해 원래 값을 쉽게 거꾸로 알아낼 수 없게 만들기 위해서였다. 덕분에 증명에 필요한 값들은 숨길 수 있게 되었지만, 동시에 새로운 문제가 생긴다.

타원곡선 위의 점들은 기본적으로 점 덧셈만 가능한 군 구조를 이루기 때문에, 원래 계산의 곱셈 관계를 직접 다루기 어렵다. 그런데 Groth16은 결국 곱셈을 포함한 QAP 관계가 올바르게 성립하는지를 검증해야 한다.

이 한계를 넘기 위해 등장하는 것이 페어링(pairing)이다.

페어링은 두 타원곡선 점을 입력으로 받아, 그 둘의 관계를 다른 공간의 값 하나로 옮겨 주는 특별한 연산이다. 보통 이를 e(P, Q)처럼 쓴다.

여기서 P는 G₁의 점이고, Q는 G₂의 점이며, 결과는 Gₜ라는 또 다른 군의 원소가 된다.

예를 들어 검증자가 [A], [B]라는 두 타원곡선 점을 직접 비교한다고 해 보자. 점 자체만 봐서는 이 둘이 정말 같은 계산 구조를 반영하는지, 혹은 곱셈 관계를 올바르게 담고 있는지 한 번에 확인하기 어렵다.

그런데 페어링을 한 번 거치면, [A]와 [B] 사이의 관계가 Gₜ라는 다른 공간의 값 하나로 바뀐다. 그러면 검증자는 원래 점들을 직접 다루는 대신, 그 결과값끼리 비교해 관계가 맞는지를 확인할 수 있다.

페어링은 점 두 개를 단순히 다른 값 하나로 바꾸는 연산이 아니라, 원래 점들 안에 숨어 있던 관계를 꺼내어 검증할 수 있는 형태로 옮겨 주는 장치다.

단순하게 보면, 검증자는 다음과 비슷한 관계를 확인한다.

e([A], [B]) ?= e([C], [기준점])

물론 실제 Groth16의 검증식은 이것보다 더 복잡하다. α, β, γ, δ와 공개 입력이 함께 들어가므로, 단순히 [A], [B], [C]만 비교하는 것은 아니다.

이해를 위해 큰 구조만 보면, 왼쪽과 오른쪽에서 온 점들의 관계를 페어링으로 옮긴 뒤 두 결과가 서로 맞는지를 보는 방식이다.

Groth16에서 검증이 빠른 이유도 여기에 있다. 복잡한 회로 전체를 다시 계산하는 대신, 몇 번의 페어링 계산만으로 증명의 핵심 구조를 확인할 수 있기 때문이다.

하지만 아직 이것만으로는 충분하지 않다. 페어링이 왜 이런 일을 할 수 있는지 이해하려면, 그 안에 들어 있는 쌍선형성(bilinearity)이라는 성질을 봐야 한다.

6–6. 쌍선형성(Bilinearity)이란?

페어링이 강력한 이유는 쌍선형성(bilinearity)이라는 성질 때문이다.

핵심 수식은 다음과 같다.

e(aP, bQ) = e(P, Q)ᵃᵇ

여기서 a와 b는 점 앞에 붙는 스칼라값이다.

이 식이 말하는 바는 단순하다. 입력으로 들어간 두 점 P와 Q에 각각 스칼라 a와 b가 붙어 있으면, 페어링의 결과에서는 그 둘의 곱인 ab가 반영된다는 뜻이다.

점 자체에서는 a와 b를 직접 볼 수 없지만, 페어링을 거치면 a와 b가 만들어 내는 곱셈 관계를 바깥에서 비교할 수 있게 된다.

쌍선형성이라는 이름은, 이 성질이 양쪽 입력에 대해 각각 선형적으로 작동하기 때문에 붙는다. 이를 식으로 쓰면 다음과 같다.

e(P + P, Q) = e(P, Q) · e(P, Q)
e(P, Q + Q) = e(P, Q) · e(P, Q)

페어링은 G₁과 G₂ 안의 덧셈 구조를, 결과 공간 Gₜ안의 곱셈 구조로 옮겨 준다. 그래서 한쪽에 대해서도 선형이고, 다른 한쪽에 대해서도 선형이므로 bi-linear, 즉 쌍선형이라고 부른다.

예를 들어 P = aG₁, Q = bG₂라고 하자. 검증자는 점 P와 Q만 볼 뿐, 그 안에 숨어 있는 스칼라 a와 b를 직접 볼 수는 없다. 그런데 페어링을 적용하면

e(aG₁, bG₂) = e(G₁, G₂)ᵃᵇ

위 수식처럼 쓸 수 있다. 이 말은 곧, 점의 세계에서는 숨겨져 있던 a와 b의 곱 관계가 페어링 결과에서는 드러난다는 뜻이다.

Groth16에서 검증자가 궁금한 것은 결국 [A]와 [B]가 함께 만드는 곱셈 관계가 정말 [C]와 맞는지다. 하지만 타원곡선 위의 점들만 직접 다뤄서는 이 곱 구조를 보기 어렵다.

페어링과 쌍선형성을 이용하면, 점 안에 숨겨진 곱 관계를 밖으로 꺼내 비교할 수 있다.

실제 검증은 보통 한 개의 페어링만 보는 것이 아니라, 여러 페어링을 서로 비교하는 구조로 이루어진다.

실제 Groth16의 검증식은 다음과 같다.

e(A, B) = e(α, β) · e(L, γ) · e(C, δ)

또한, 모두 한쪽으로 넘겨 아래처럼 쓸 수도 있다.

e(−A, B) · e(α, β) · e(L, γ) · e(C, δ) = 1

여기서 L은 공개 입력으로 검증자가 직접 계산하는 값이다. 자세한 형태는 6–7에서 다룬다.

Groth16의 검증은 결국 여러 페어링들의 곱이 항등원이 되는지(곱이 1이 되는가) 혹은 같은 의미로 양쪽 페어링 관계가 서로 같은지를 확인하는 구조라고 이해하면 된다.

페어링은 점들을 다른 공간으로 옮기는 연산이고, 쌍선형성은 그 공간에서 숨겨진 스칼라들의 곱 관계를 비교할 수 있게 만드는 성질이다.

그래서 Groth16은 원래 회로 전체를 다시 계산하지 않고도, 몇 번의 페어링 계산만으로 증명의 핵심 관계를 빠르게 확인할 수 있다.

6–7. r과 s, 그리고 영지식성: 매번 증명(Proof)값이 달라지는 이유

신뢰 설정에서 τ, α, β, γ, δ를 준비했고, 증명자는 [A], [B], [C]를 만들며, 검증자는 페어링으로 그 관계를 확인한다. 그런데 이것만으로는 아직 완전한 영지식 증명이라고 할 수 없다.

만약 proof에 무작위성이 없으면, 같은 witness에 대해 항상 같은 proof가 나오기 때문이다.

[A], [B], [C]는 기본적으로 witness와 proving key가 정해지면 거의 자동으로 결정되는 값들이다.

따라서 여기에 추가 랜덤성이 없다면, 외부에서 여러 proof를 비교하거나 가능한 witness를 추측해 직접 proof를 만들어 보면서 원래 값을 짐작할 여지가 생긴다.

이를 막기 위해 Groth16은 proof를 만들 때마다 두 개의 무작위 스칼라 r과 s를 새로 뽑아 사용한다.

이 값들은 신뢰 설정에서만 한 번 쓰이고 버려지는 τ, α, β, γ, δ와는 다르다.

τ, α, β, γ, δ가 신뢰 설정 단계 전용 비밀 파라미터라면, r과 s는 증명자가 proof를 만들 때마다 새로 넣는 일회용 랜덤값이다.

증명을 구성하는 각 점은 대략 다음처럼 바뀐다.

[A]₁ = [α]₁ + Σ aᵢuᵢ(τ) + r[δ]₁
[B]₂ = [β]₂ + Σ aᵢvᵢ(τ) + s[δ]₂

그리고 [C]₁은 다음과 같이 완성된다.

[C]₁ = ( Σ(비공개 i) aᵢ(β·uᵢ(τ) + α·vᵢ(τ) + wᵢ(τ)) + h(τ)t(τ) ) / δ + s[A]₁ + r[B]₁ − rs[δ]₁

복잡해 보이지만 세 덩어리로 나눠 보면 단순하다.

• β·uᵢ + α·vᵢ + wᵢ: [A], [B], [C]가 모두 같은 witness에서 나왔다는 것을 묶어 주는 장치다. [A]에는 α, [B]에는 β가 들어가 있으므로 둘을 곱하면 이런 교차항이 생긴다. [C]가 이 항을 정확히 갖고 있어야 검증식이 맞아떨어진다.
• 비공개 값만 넣고 δ로 나눈다: 공개 입력 부분은 [C]에 넣지 않는다. 그 부분은 검증자가 직접 계산해 γ로 나눈 값 L로 따로 들어간다. 공개 값은 γ, 비공개 값은 δ라는 서로 다른 통로를 타는 것이다.
• s[A] + r[B] − rs[δ]: [A]와 [B]에 섞은 무작위 값 r, s를 상쇄하는 항이다. 이 항 덕분에 증명값은 매번 달라지지만 검증식은 그대로 성립한다.

여기서 L은 검증자가 공개 입력만으로 직접 계산하는 값이다.

L = Σ(공개 i) aᵢ(β·uᵢ(τ) + α·vᵢ(τ) + wᵢ(τ)) / γ

원래 witness가 같더라도 r과 s가 달라지면 최종 proof는 달라진다.

r과 s는 proof에 일종의 salt를 넣는 역할을 한다. 덕분에 공격자는 witness만 맞춰 본다고 해서 원래 proof와 같은 결과를 쉽게 재현할 수 없다.

결국 검증자는 계산이 맞다는 사실만 확인할 수 있고, 제출된 proof만 보고 witness를 추측하기는 훨씬 어려워진다.

정리하면, τ, α, β, γ, δ는 증명의 구조를 올바르게 고정하는 신뢰 설정 단계의 일회용 비밀 파라미터이고, r과 s는 그 구조 위에 무작위성을 덧씌워 진짜 영지식성을 완성하는 Groth16의 마지막 장치다.

6–8. 최종 검증식: 3개의 점만으로 신뢰할 수 있는 이유

증명자는 witness와 proving key를 이용해 세 개의 점 [A], [B], [C]를 만든다.

이 점들 안에는 QAP 관계, 신뢰 설정 구조, 공개 입력, 그리고 영지식성을 위한 랜덤화까지 함께 반영되어 있다.

검증자는 witness를 직접 알지 못한다. 비밀 평가 지점 τ도 모르고, 신뢰 설정에 쓰인 toxic waste도 모른다. 그런데도 verification key와 공개 입력, 그리고 제출된 세 개의 점만으로 proof가 올바른지 확인할 수 있다.

핵심은 이 점들을 각각 따로 보는 것이 아니라, 이들이 함께 특정한 페어링 관계를 만족하는지를 보는 것에 있다.

검증자가 실제로 확인하는 것은 다음 식이다.

e(A, B) = e(α, β) · e(L, γ) · e(C, δ)

왼쪽의 페어링은 증명자가 제출한 점들 사이의 관계를 나타내고, 오른쪽의 페어링들은 신뢰 설정 구조와 공개 입력, 그리고 출력 점 C가 올바른 방식으로 들어왔는지를 나타낸다.

이 식이 중요한 이유는, 증명자가 임의의 점 세 개를 꾸며 내서는 이 관계를 맞추기 어렵기 때문이다.

[A], [B], [C]는 같은 witness와 같은 QAP 관계, 같은 신뢰 설정 구조를 반영해 만들어져야만 전체 페어링 식이 성립한다.

결국 Groth16의 검증은 증명자가 사용한 값을 알아내는 과정이 아니다. 대신 그 값이 정말 회로를 만족했고, 그 사실이 신뢰 설정이 허용한 구조 안에서 짧게 압축되었는지를 확인하는 과정이다.

증명자가 했던 계산 전체를 다시 재현해 보지 않고도, 매우 짧은 proof와 몇 번의 페어링 계산만으로 이 관계를 확인할 수 있다는 점이 Groth16의 가장 강력한 장점이다.

7. 마치며

Groth16은 아무리 복잡한 계산이더라도 무조건 3개의 점으로 압축할 수 있다. 이 놀라운 강점 때문에 10년이 지난 현재까지도 쓰이는 프로토콜이다.

그만큼 내부 구조는 단순하지 않았다. 짧은 proof를 만들기까지 생각 이상으로 복잡한 과정을 거쳐야 했다.

먼저 현실의 논리를 산술 회로로 바꾸고, R1CS를 통해 행렬로 표현하고, QAP를 거쳐 하나의 다항식 관계로 압축한 뒤, 다시 그 관계를 타원곡선 위의 점으로 옮겨 검증할 수 있는 형태로 만들어야 했다.

의외로 Part 2의 큰 비중은 공격 가능성을 하나씩 제거하는 과정에 있었다.

증명자가 임의의 점을 꾸며 내지 못하도록 α, β를 넣고, 공개 입력과 witness를 구조적으로 분리하기 위해 γ, δ를 두며, 마지막에는 r과 s를 통해 proof에 무작위성을 더해 매번 proof 값이 달라지는 진짜 영지식 증명을 완성했다.

Groth16의 과정에서 계산을 압축하는 것도 당연히 중요하지만, 그 이상으로 압축된 결과가 위조되지 않고 정보도 새지 않도록 공격 가능성을 정교하게 차단하는 것이 중요했다.

당연하게도 뭐든지 트레이드오프는 존재하는 법, Groth16은 매우 짧은 proof와 빠른 검증을 제공하는 대신 신뢰 설정이 필요하다.

1단계(Powers of Tau)는 재사용할 수 있지만, 회로의 구조를 반영하는 2단계는 회로가 바뀔 때마다 다시 진행해야 한다.

그래서 Groth16은 다양한 회로를 계속 바꿔 가며 써야 하는 경우보다, 하나의 회로를 반복적으로 사용할 때 더 적합하다.

신뢰 설정은 효율적이지만 위험한 toxic waste를 동반한다. 아무리 MPC로 비밀 파라미터의 유출 가능성을 최소화할지라도, toxic waste가 남아 있으면 가짜 proof를 만들 수 있다는 점에서 이는 보안상 치명적인 약점이 된다.

그래서 Groth16 이후 ZKP들은 신뢰 설정에 주목하여 이를 변형시키거나 없애는 방향으로 많이 발전해 왔다. PLONK처럼 회로마다 하던 2단계를 없애고 하나의 범용 설정을 여러 회로가 같이 쓰는 방식이 대표적이다.

그럼에도 Groth16으로 ZKP를 입문할 가치는 크다. zk-SNARK의 핵심 아이디어가 Groth16에 가장 잘 담겨 있기 때문이다. 이 흐름을 끝까지 따라가고 이해한다면, 이후의 Plonk, Halo2, zkVM 같은 프로토콜이 무엇을 위해 무엇을 바꿨는지 선명하게 알 수 있을 것이다.

또한 타원곡선에 기반한 zk-SNARK는 양자 컴퓨팅이 실현될 경우, 쇼어 알고리즘에 의해 근간이 되는 이산로그 문제가 풀려버릴 수 있다. 반면 해시 함수에 기반한 zk-STARK는 양자 내성을 갖는다.

그래서 두 계열은 영지식 증명이라는 공통점은 있지만, 기반 원리와 장단점이 크게 다르며 서로 다른 계보로 발전해 왔다는 사실을 자연스럽게 이해할 수 있다.

참고문헌

더 깊게 알고 싶다면 RareSkills의 ZK 가이드를 읽는 것을 권장합니다.

• The RareSkills Book of Zero Knowledge | RareSkills
• Benchmarks of Hashing Algorithms in ZoKrates
• Elliptic Curve
• Zk-SNARKs: Under the Hood
• Quadratic Arithmetic Programs: from Zero to Hero

ZKP의 C언어, Groth16 톺아보기 was originally published in CURG on Medium, where people are continuing the conversation by highlighting and responding to this story.

본 글은 정보 제공을 목적으로 작성된 것으로, 투자, 법률, 자문 등 어떠한 분야에서도 책임을 지지 않습니다. 특정 자산에 대한 투자 권유의 의도가 없으며, 본문 내용만을 기반으로 투자 결정을 내리지 마시기 바랍니다.

1. 개요

DefiDash는 Sui에서 leverage와 deleverage를 한 번에 실행할 수 있게 만들기 시작한 프로젝트다.
핵심은 새로운 프로토콜을 만드는 게 아니라, 이미 있는 프로토콜을 한 흐름으로 묶는 것이었다.

현재 SDK는 아래 조합을 기준으로 동작한다.

• flash loan: Scallop
• swap: 7k
• lending: Suilend, Navi, Scallop

여기에 transaction builder, preview 계산, protocol 비교, 포지션 조회 기능을 붙였다.
프론트엔드에서는 단순한 액션만 보이지만, 실제로는 여러 Move call을 하나의 PTB로 조립하는 구조다.

2. Sui에서 Defi Saver가 필요한 이유

2.1 DeFi Saver란?

이 글에서 말하는 Defi Saver는 포지션 관리 레이어에 가깝다.
사용자가 원하는 건 개별 프로토콜 함수 호출이 아니라, “레버리지를 연다”, “포지션을 닫는다”, “어디가 더 나은지 본다” 같은 결과다.

그래서 SDK도 프로토콜 함수 단위가 아니라 액션 단위로 API를 잡았다.

const sdk = await DefiDashSDK.create(suiClient, keypair);

await sdk.buildLeverageTransaction(tx, {
  protocol: LendingProtocol.Suilend,
  depositAsset: "XBTC",
  depositValueUsd: 100,
  multiplier: 2.0,
});

2.2 Sui DeFi 생태계

Sui에는 필요한 기능이 이미 있었다.
문제는 기능이 없다는 게 아니라, 흐름이 끊겨 있다는 점이었다.

예를 들어 leverage 포지션 하나를 열 때도 다음 요소가 같이 필요하다.

• flash loan
• swap
• 담보 예치
• borrow
• flash loan 상환

이걸 각 프로토콜에서 따로 처리하면 프론트엔드가 너무 복잡해진다.
특히 XBTC, LBTC 같은 자산은 전략 자체는 단순한데, 실행 과정이 복잡해서 실제 사용성이 떨어진다.

그래서 DefiDash에서는 이 흐름을 SDK 안으로 넣고, 어느 프로토콜이 더 나은지까지 같이 계산하도록 했다.

const route = await sdk.findBestLeverageRoute({
  depositAsset: "XBTC",
  depositValueUsd: 100,
});

console.log(route.bestMaxMultiplier.protocol);
console.log(route.bestApy.protocol);

3. 결과물

• GitHub: defidash-sdk
• Demo: DefiDash Frontend

3.1 Leverage / Deleverage

leverage는 대략 아래 순서로 동작한다.

1. Scallop에서 USDC flash loan을 받는다.
2. oracle을 갱신한다.
3. 7k에서 담보 자산으로 swap한다.
4. 사용자가 가진 자산과 합쳐서 담보로 넣는다.
5. 다시 USDC를 빌린다.
6. flash loan을 갚는다.

코드로 보면 이런 형태다.

const [loanCoin, receipt] = flashLoanClient.borrowFlashLoan(
  tx,
  flashLoanUsdc,
  "usdc",
);

await protocol.refreshOracles(tx, [normalized, USDC_COIN_TYPE], userAddress);

const swappedAsset = await swapClient.swap(
  {
    quote: bestQuote,
    signer: userAddress,
    coinIn: loanCoin,
    tx,
  },
  100,
);

await protocol.deposit(tx, depositCoin, normalized, userAddress);

const borrowedUsdc = await protocol.borrow(
  tx,
  USDC_COIN_TYPE,
  borrowAmount.toString(),
  userAddress,
  true,
);

flashLoanClient.repayFlashLoan(tx, borrowedUsdc, receipt, "usdc");

deleverage는 반대 방향이다.
먼저 빚을 정리하고, 담보를 꺼내고, 필요한 만큼만 swap해서 flash loan을 갚는다.

const [loanCoin, receipt] = flashLoanClient.borrowFlashLoan(
  tx,
  estimate.flashLoanUsdc,
  "usdc",
);

await protocol.repay(tx, USDC_COIN_TYPE, loanCoin, userAddress);

const withdrawnCoin = await protocol.withdraw(
  tx,
  supplyCoinType,
  withdrawAmount.toString(),
  userAddress,
);

const swappedUsdc = await swapClient.swap(
  {
    quote: bestQuote2,
    signer: userAddress,
    coinIn: coinToSwap,
    tx,
  },
  DELEVERAGE_SLIPPAGE_BPS,
);

flashLoanClient.repayFlashLoan(tx, flashRepayCoins, receipt, "usdc");

3.2 SDK

처음에는 스크립트가 먼저였고, 그다음에 공통 로직을 SDK로 옮겼다.
지금 구조는 adapter가 프로토콜 차이를 흡수하고, 상위에서는 같은 흐름으로 leverage/deleverage를 빌드하는 방식이다.

const suilend = new SuilendAdapter();
await suilend.initialize(suiClient);
this.protocols.set(LendingProtocol.Suilend, suilend);

const navi = new NaviAdapter();
await navi.initialize(suiClient);
this.protocols.set(LendingProtocol.Navi, navi);

const scallop = new ScallopAdapter();
await scallop.initialize(suiClient);
this.protocols.set(LendingProtocol.Scallop, scallop);

프론트엔드에서는 이 차이를 몰라도 된다.
브라우저에서는 transaction builder로 쓰고, Node.js에서는 execute까지 포함해 사용할 수 있다.

3.3 각종 수치 계산

실행 기능만 있으면 실제로 쓰기 어렵다.
그래서 preview와 route 계산도 같이 넣었다.

preview에서는 flash loan 크기, debt 비중, liquidation price, APY, slippage 등을 계산한다.

const flashLoanUsd = initialEquityUsd * (multiplier - 1);
const flashLoanUsdc = BigInt(Math.ceil(flashLoanUsd * 1e6));

const totalPositionUsd = initialEquityUsd * multiplier;
const debtUsd = flashLoanUsd + flashLoanFeeUsd;
const ltvPercent = (debtUsd / totalPositionUsd) * 100;

liquidation 관련 값도 같이 계산한다.

const { liquidationPrice, priceDropBuffer } = calculateLiquidationMetrics(
  debtUsd,
  totalCollateralAmount,
  riskParams.liquidationThreshold,
  price,
);

route 계산은 최대 배율과 유지 비용을 분리해서 본다.
같은 자산이어도 “최대로 당길 수 있는 곳”과 “들고 가기 편한 곳”은 다를 수 있기 때문이다.

const minMaxMultiplier = Math.min(
  ...successfulRisk.map((r) => r.riskParams.maxMultiplier),
);

const safeMultiplier = Math.max(
  MIN_SAFE_MULTIPLIER,
  minMaxMultiplier - LEVERAGE_MULTIPLIER_BUFFER,
);

4. 개발 과정

개발은 SDK부터 시작하지 않았다.
먼저 swap과 leverage가 실제로 되는지 테스트 스크립트로 확인했다.
그 다음 Scallop flash loan을 붙였고, 그 뒤에 SUI gas coin 처리, oracle refresh, deleverage, protocol adapter 순으로 정리됐다.

진행 순서는 대략 이랬다.

• 7k swap과 leverage 테스트 작성
• Scallop flash loan 연동
• leverage 성공 케이스 확인
• close position / deleverage 구현
• Suilend, Navi, Scallop adapter 정리
• gas 최적화 추가
• preview, route 계산 추가
• 테스트와 문서 정리

처음에는 되는 코드를 만드는 게 목표였고, 그 다음에는 같은 코드를 반복하지 않도록 SDK 구조로 정리하는 쪽으로 바뀌었다.

5. 기술적 어려움

5.1 하나의 PTB로 묶기

가장 먼저 부딪힌 문제는 순서였다.
같은 호출이라도 PTB 안에서 어디에 놓느냐에 따라 성공 여부가 달라졌다.

대표적인 예가 oracle refresh다.
7k swap이 내부적으로 Pyth update command를 넣을 수 있어서, protocol refresh를 swap 뒤에 두면 충돌이 날 수 있었다.
그래서 refresh는 반드시 swap 전에 실행하도록 바꿨다.

const [loanCoin, receipt] = flashLoanClient.borrowFlashLoan(tx, flashLoanUsdc, "usdc");

await protocol.refreshOracles(tx, [normalized, USDC_COIN_TYPE], userAddress);

const swappedAsset = await swapClient.swap(
  { quote: bestQuote, signer: userAddress, coinIn: loanCoin, tx },
  100,
);

Scallop은 더 까다로웠다.
새 obligation을 만들면 바로 끝낼 수 없고, borrow까지 한 뒤에 닫아야 했다.
그래서 중간 상태를 adapter 안에 잠깐 들고 가는 로직이 필요했다.

if (
  obligations.length === 0 &&
  this.pendingObligation &&
  this.pendingObligationKey &&
  this.pendingHotPotato
) {
  const result = this.borrowFromObligation(
    tx,
    this.pendingObligation,
    this.pendingObligationKey,
    BigInt(amount),
    normalized,
  );

  this.returnObligation(tx, this.pendingObligation, this.pendingHotPotato);
  tx.transferObjects([this.pendingObligationKey], this.pendingUserAddress!);

  return result;
}

5.2 EVM과의 차이점

가장 큰 차이는 object 모델이었다.
EVM에서는 보통 balance와 allowance를 기준으로 생각하지만, Sui에서는 어떤 coin object를 쓸지 직접 정리해야 한다.

특히 SUI는 gas coin이기도 해서 따로 처리해야 했다.

if (isSui) {
  const [userDeposit] = tx.splitCoins(tx.gas, [tx.pure.u64(depositAmount)]);
  tx.mergeCoins(swappedAsset, [userDeposit]);
  depositCoin = swappedAsset;
} else {
  const primaryCoin = tx.object(allCoins[0].coinObjectId);
  const [userContribution] = tx.splitCoins(primaryCoin, [
    tx.pure.u64(depositAmount),
  ]);
  tx.mergeCoins(swappedAsset, [userContribution]);
  depositCoin = swappedAsset;
}

coin type 비교도 그대로 하면 자주 깨졌다.
주소 포맷이 다르게 들어오는 경우가 있어서 normalize가 필요했다.

export function normalizeCoinType(coinType: string): string {
  const parts = coinType.split("::");
  let pkg = parts[0].replace("0x", "");
  pkg = pkg.padStart(64, "0");
  return `0x${pkg}::${parts[1]}::${parts[2]}`;
}

또 하나는 package ID와 object ID 관리다.
EVM에서는 보통 proxy 주소 하나로 끝나는 경우가 많지만, Sui에서는 version, market, oracle, obligation 관련 object를 같이 맞춰야 한다.
SDK를 만들 때 이 부분이 생각보다 손이 많이 갔다.

5.3 SDK 지원 부족

공식 SDK가 있어도, 여러 프로토콜을 한 PTB로 묶는 수준까지는 바로 되지 않았다.

Suilend는 PTB 안에서 deposit과 borrow를 같이 처리할 때 oracle refresh를 따로 보정해야 했다.
이미 obligation에 들어 있는 coin type을 필터링하지 않으면 중복 refresh 문제도 생겼다.

const existingCoinTypes = new Set<string>();
(obligation?.deposits ?? []).forEach((d: any) =>
  existingCoinTypes.add(normalizeCoinType(d.coinType.name)),
);
(obligation?.borrows ?? []).forEach((b: any) =>
  existingCoinTypes.add(normalizeCoinType(b.coinType.name)),
);

const newCoinTypes = coinTypes.filter(
  (ct) => !existingCoinTypes.has(normalizeCoinType(ct)),
);

await this.client.refreshAll(
  tx,
  obligation,
  newCoinTypes.length > 0 ? newCoinTypes : undefined,
);

Scallop은 xOracle 갱신도 바로 맞지 않았다.
Scallop builder를 만들고, 그 내부 txBlock을 현재 Transaction으로 바꿔서 oracle update command를 주입했다.

const builder = await this.scallop.createScallopBuilder();
const scallopTx = builder.createTxBlock();
scallopTx.txBlock = tx;

await scallopTx.updateAssetPricesQuick(coinNames);

Navi도 필요한 자산만 refresh하는 것으로는 부족했고, 전체 feed refresh 쪽이 더 안정적이었다.

const feedsToUpdate =
  this.priceFeeds.length > 0
    ? this.priceFeeds
    : coinTypes.map((ct) => this.getPriceFeed(ct)).filter(Boolean);

if (feedsToUpdate.length > 0) {
  await updateOraclePricesPTB(tx as any, feedsToUpdate, {
    env: "prod",
  });
}

결론적으로 protocol SDK 위에 한 단계 더 얹은 orchestration layer가 필요했다.

6. 한계와 개선 방향

6.1 더 많은 플랫폼과 토큰 지원

현재 지원 범위는 넓지 않다.
lending는 Suilend, Navi, Scallop이고, 전략 자산도 SUI, XBTC, LBTC 중심이다.
debt asset도 사실상 USDC 기준으로 잡혀 있다.

이 범위로 leverage/deleverage 핵심 흐름은 검증했지만, 실제 제품으로 보려면 더 늘어나야 한다.
다만 프로토콜 수를 늘리는 것보다 먼저, 공통 로직과 protocol-specific path를 더 분명히 나눌 필요가 있다.

6.2 자동화 및 자산 이동

지금 상태의 DefiDash는 포지션을 열고 닫고 비교하는 도구에 가깝다.
다음 단계는 자동화다.

예를 들면 이런 쪽이다.

• health factor가 낮아지면 자동 deleverage
• 더 나은 protocol이 있으면 포지션 이동
• asset별로 route를 자동 선택

이 단계로 가면 단순 계산보다 실행 안정성이 더 중요해진다.
oracle freshness, gas cost, liquidity depth, object version까지 같이 봐야 한다.
현재 SDK는 그 기반을 만드는 단계까지는 왔다고 보고 있다.

7. 참고자료

• Sui PTB Documentation
• 7K Docs
• 7K Aggregator Integration
• 7K SDK
• Suilend SDK Guide
• Suilend SDK API Reference
• Scallop Developer Resources
• Scallop API Docs
• NAVI Technical Docs

DefiDash: Sui에서 DeFi Saver 만들기 was originally published in CURG on Medium, where people are continuing the conversation by highlighting and responding to this story.

CURG가 걸어온 길

CURG(Crypto United Research Group)는 2018년 5월 가톨릭대, 고려대, 서강대, 서울대, 성균관대, 이화여대, 중앙대, 한양대 등 서울권 대학교 학생들을 중심으로 만들어졌습니다.

여러 학문 분야를 망라하는 기술인 블록체인을 트렌디하고 심도 있게 꾸준히 연구하고 3T(Trendy | Thoughtful | Transdisciplinary) 한 자세로 블록체인 리서치를 이어왔습니다.

CURG의 비전

“기술 중심의 리서치 및 개발을 통해 생태계에 능동적으로 기여하자”

팀활동을 통해 함께 연구하며 오픈소스 개발, PoC프로덕트를 통해 생태계에 기여하고 학회원들 각각의 개인 역량 향상이 CURG가 추구하는 방향입니다.

정규 활동

13기 정규 활동은 3단계 프로세스로 나뉘어 진행됩니다.

리서치 기간

팀 활동 주제를 구체화하고, 필요한 기술의 백그라운드와 원리를 탐구합니다. BeaconKit,CometBFT, zkVM 등 기술을 분석하며, 학회원들과 공유할 기술의 인사이트를 발굴하고 탐색하는 시간입니다.

개발 기간

리서치를 바탕으로 실제 구현에 돌입하는 기간입니다. 이 기간동안 시스템 아키텍처 설계, 시퀀스 다이어그램 작성, 성능 벤치마크 측정 데이터등을 만들어내며, 실제 구현에 포커스 맞춘 활동을 진행하여 학회원들과 공유하게 됩니다.

정리 기간

그리고 마지막으로 활동 기간 동안의 리서치와 개발 내용을 아카이빙하고 기록하는 기간입니다. 미디엄 보고서 작성 및 최종 성과 발표준비를 통해 커뮤니티와 공유하고 나누는것을 목표로 합니다

12기 최종 결과물

클릭하시면 유투브를 통해 발표영상을 보실수 있습니다.

• Arbitrage Strategies (feat. BeaconKit, RethExEx)
• AI Agent랑 깐부되기 (feat. Memecoin)
• CometBFT Analyzer
• Automated Rebalancing Strategies for CLMM
• Data Refinement via Wallet Clustering
• Tornado Cash on zkVM

지원 자격

나이, 학력 무관하게 CURG 학회원들과 끈끈하게 의지하면서 블록체인 리서치와 빌딩에 몰입할 수 있는 사람을 모집합니다. 현재 대학생, 대학원생, 현직자등 매우 다양한 사람들이 학회원으로 있으니 주저하지 말고 지원해 주세요.

커그에 지원하면 좋으실 분들:

1. 블록체인 업계에 있는 현직자들과 네트워킹을 희망하는 사람.
2. 독특한 아이디어로 새로운 프로덕트를 만들어가는 것을 즐기는 사람.
3. 블록체인 씬에서 연구되는 최근 동향들을 파악하고 새로운 인사이트를 얻어가기를 원하는 사람.

한 학기가 아닌 총 1년 동안 활동하셔야 수료하실 수 있습니다. 1년 동안 활동이 가능하신 분만 지원 바랍니다. 매주 토요일 11시-1시 언주역 인근에서 진행됩니다.

지원 방법

• 서류 접수 | 25.09.13 ~ 25.09.24(수)
• 서류 합격자 발표 | 25.09.26(금)
• 온라인 면접 | 25.09.27 ~ 25.09.28 (토, 일)
• 최종 합격자 발표 | 25.09.30 (화)
• OT & 13기 시작 | 25.10.11 (토)

About CURG

• CURG 유투브
• CURG 미디엄: https://medium.com/curg
• CURG 트위터: https://twitter.com/curg_official

기타 문의 : curg.in.seoul@gmail.com 로 문의바랍니다.

CURG 13기 리크루팅 was originally published in CURG on Medium, where people are continuing the conversation by highlighting and responding to this story.

들어가며: 데이터 신뢰와 보안의 중요성

지난 4월, 대한민국은 최대 통신사 SK텔레콤의 서버 해킹으로 대규모 고객 데이터가 유출되는 사고를 겪었다. 이 사건으로 수 천만 이용자의 USIM 관련 민감 정보가 해커 손에 넘어갔고 회사 주가는 급락했으며, 기존 이용자들은 불안 속에 USIM 교체나 통신사 교체를 감행했다.

이처럼 디지털 시대에 데이터의 무결성과 보안이 흔들리면 막대한 피해와 불신이 뒤따른다. 문제는 이 같은 피해가 보통 단순한 경제적 손실을 넘어, 개인들의 민감정보 노출에 따른 2차피해 등 광범위한 영역으로 확장되고 심각성이 배가 된다는 것이다.

현재 우리는 인공지능(AI) 기술이 생활 곳곳에 스며든 AI 시대에 살고 있고 앞으로 그 추세는 더욱 가파르게 진행될 것이다. AI가 만들어내는 콘텐츠와 결정 역시 신뢰 문제를 안고 있다. 예를 들어, 2023년 5월에는 펜타곤 폭발 사진으로 조작된 딥페이크 이미지가 SNS에 퍼져 미국 증시가 일시 급락하는 일이 있었다. 또한 최근 고도화된 대형 언어 모델(LLM)들은 그럴듯한 문장을 생성하면서도 사실과 다른 “헛소리(Hallucination)” 답변을 늘어놓아 사용자를 현혹시키곤 한다.

실제로 OpenAI의 최신 GPT 모델들은 이전 버전보다 두 배 이상 높은 빈도로 사실과 다른 답변을 생성하고 있으며, “현 단계에선 어느 LLM의 출력도 신뢰하기 어렵다”는 평가가 나오고 있다. 딥페이크와 AI의 환각 문제(AI Hallucination)는 AI 시대에 정보의 진위와 신뢰를 크게 위협하는 요인으로 떠오르고 있다.

이런 현실 속에서 “어떻게 하면 우리가 AI의 결과를 믿을 수 있을까?”라는 질문이 중요해지고 있다. 즉, AI 시대에 신뢰할 수 있는 데이터와 검증 인프라를 구축하는 세상이 필연적으로 도래된 것이다. 이번 글에서는 이러한 현대적 흐름 속, AI로부터 파생된 사회적 문제를 라그랑주(Lagrange)라는 프로젝트를 통해 크립토 산업과 그 해결책의 연결점에서 살펴보고자 한다.

AI 신뢰 문제에 대한 zkML 해법: 라그랑주의 등장

라그랑주(Lagrange)는 블록체인 영지식 증명(ZKP, Zero-Knowledge Proof) 기술을 활용해 AI 결과의 무결성을 검증하는 접근을 선보이는 프로젝트다. 라그랑주 팀은 “zkML”이라 불리는 모델을 통해 AI 모델 추론 결과가 정확히 계산되었음을 증명하면서도, 그 과정에서 데이터나 모델의 민감한 세부사항은 공개하지 않도록 한다.

쉽게 말해, DeepProve라는 zkML 프레임워크를 이용하면 “AI가 어떤 판단을 내렸는지 암호학적으로 증명하되, 입력 데이터나 모델 내부는 드러나지 않는다”는 것이다. 이러한 영지식 머신러닝 검증은 의료, 금융 등의 민감 분야에서 프라이버시를 지키면서 AI 활용을 가능케 하는 열쇠가 된다.

특히 DeepProve는 AI 모델의 추론(inference) 단계에 초점을 맞추고 있다. 현재 대부분의 AI 시스템은 블랙박스처럼 동작하여, 사용자는 모델이 내놓은 결과를 그저 “믿고 따를” 수밖에 없는 상황이다.

반면 zkML을 적용하면 AI 모델이 내놓은 답이 주어진 입력에 대해 올바른 결과임을 검증자(Verifier)가 수학적으로 확인할 수 있다. 예를 들어 의료 영상 분석 AI가 “이 CT 이미지에 종양이 있다”는 진단을 내렸다면, DeepProve를 통해 의료진이나 보험사가 그 진단이 실제 해당 AI 모델로부터 나온 정당한 결과임을 증명받을 수 있다. 이 과정에서 환자의 원본 이미지나 AI 모델 파라미터는 노출되지 않으므로 프라이버시와 지적 자산 보호도 보장된다. 이렇듯 DeepProve는 AI의 신뢰성과 투명성을 극대화하는 솔루션으로 주목받고 있다.

라그랑주의 DeepProve 와 기술적 차별점

라그랑주의 DeepProve 기술이 주목받는 가장 큰 이유 중 하나는 그 탁월한 성능과 범용성이다. DeepProve는 다층 퍼셉트론(MLP)부터 합성곱 신경망(CNN)까지 다양한 신경망 구조를 지원하고, 영지식 증명을 위해 합계검증(sumcheck)과 GKR 프로토콜 같은 첨단 암호학 기법을 활용힌다.

그 결과, 기존 zkML 솔루션 대비 월등히 빠른 검증 속도를 달성했는데, 예컨대 4백만 개의 매개변수를 가진 대형 신경망에 대해 기존 대비 최대 158배 빠르게 증명을 생성하고 증명 검증 속도는 기존 대비 500배 이상 향상시켰다는 벤치마크 결과가 공개되었다. 한마디로 DeepProve는 현재까지 등장한 가장 빠른 zkML 엔진으로 복잡한 AI 모델의 추론도 실시간에 가깝게 검증할 수 있는 수준에 도달했다.

또한 라그랑주는 Lagrange Prover Network (LPN)라는 탈중앙화 증명 네트워크를 구축하여 이 연산을 효율화하고 있다. 복잡한 증명 생성 작업을 LPN의 노드들이 분산 처리함으로써, 개별 사용자는 가벼운 비용으로도 AI 검증 서비스를 이용할 수 있게 한다. 라그랑주 팀은 이러한 탈중앙 ZK 연산 인프라를 이더리움과 아이겐레이어의 리스테이킹(restaking) 생태계와 접목하여 확장성을 높였는데, 이미 Coinbase, Kraken, OKX 등 85개 이상의 주요 노드 운영자들이 참여한 네트워크에서 9백만 건 이상의 ZK proofs를 생성해내며 검증된 성능을 보여주고 있다. 이는 라그랑주 기술의 실전 배치 가능성을 입증하는 기록으로, 단순한 연구 단계에 머물지 않고 실제 블록체인 응용(예: 이더리움 레이어2의 롤업 증명)에도 활용되고 있음을 뜻힌다.

특히 올해 3월 라그랑주는 이더리움 레이어2 Matter Labs(zkSync 개발사)와 협약을 맺어, zkSync 네트워크의 외주 ZK 증명 작업의 최대 75%를 Lagrange 네트워크에서 처리하기로 했다. 이는 대형 롤업의 증명 연산을 탈중앙화한 첫 사례로, 블록체인 확장성 측면에서도 중대한 진전으로 평가받고 있다.

라그랑주 CEO인 이스마엘 히숀-레자이자데는 “모든 롤업은 결국 ZK 롤업이 될 것이며, 신뢰할 수 있는 탈중앙 증명은 미래 웹3 인프라의 핵심”이라고 강조하기도 했다. 이처럼 라그랑주의 기술력과 속도, 그리고 다양한 응용 분야에의 확장성이 라그랑주만의 차별화된 강점이라 할 수 있다.

든든한 지원군과 흥미로운 시작

라그랑주의 차별점은 여러 파트너십과 투자 유치를 통해서도 드러난다. 먼저 NVIDIA는 라그랑주의 잠재력을 높이 평가하여, 올해 라그랑주를 엔비디아 인셉션 프로그램 스타트업으로 최초 선정했다. AI와 ZK를 접목한 기업이 인셉션 프로그램에 들어간 것은 라그랑주가 처음으로, 이를 통해 라그랑주는 엔비디아의 기술 지원과 클라우드 인프라 크레딧 등을 제공받으며 DeepProve 개발을 가속화하고 있다. 라그랑주 CEO는 “AI와 ZK는 모두 거스를 수 없는 기술 대세이며 우리의 협업은 신뢰와 프라이버시, 확장성이라는 난제를 해결하는 데 기여할 것”이라고 밝혔다.

한편 분야별 전문 기업들과의 제휴도 활발하다. 0G Labs와는 탈중앙 AI 컴퓨팅 마켓플레이스에 DeepProve를 통합하여, 해당 AI 플랫폼의 모델 추론 결과를 검증 가능하게 만드는 협력을 진행 중이다. Ungate AI와는 의료 진단 분야의 파트너십을 맺어, 예를 들어 AI로 판독한 의료영상 진단에 대해 zkML 증명을 제공함으로써 환자 개인정보는 보호하면서 진단의 정확성을 담보하는 “Verified Care” 솔루션을 개발하고 있다. 또한 Inference Labs와의 전략적 제휴를 통해 탈중앙 AI 네트워크(예: Bittensor 기반)에 DeepProve를 결합, 분산 환경에서도 AI 모델을 검증 가능하게 배포하는 표준을 세우고 있다. Inference Labs 측은 “DeepProve는 탈중앙 AI 시스템의 신뢰 기준을 한 단계 끌어올리는 획기적 기술”이라며, 이번 협업이 “AI가 강력하기만 한 것이 아니라 검증 가능하고 투명한 방향으로 나아가는 미래”를 앞당길 것이라고 평가했다.

투자자 측면에서도 라그랑주는 탄탄한 지원을 받고 있다. 실리콘 밸리의 전설 피터 틸이 이끄는 Founders Fund가 2024년 라그랑주의 시드 라운드를 주도하여 1,320만 달러를 투자했고, 그 외에도 Archetype, 1kx, Maven 11, Fenbushi Capital, CMT Digital, Volt Capital 등 유수의 블록체인 투자사들이 초기부터 참여했다. 이들의 지원으로 라그랑주는 현재까지 총 1,700만 달러 이상의 자금을 유치하며 기술 개발과 네트워크 확장을 꾸준히 추진해왔다. 또한, 탈중앙 증명 네트워크 구축을 위한 LA 토큰 출시도 공식화되어 2025년 6월에는 라그랑주 재단을 통해 네이티브 토큰을 발행하고 프로토콜 참여자들에게 토큰을 에어드롭하는 계획이 발표되었다.

흥미로운 점은 초기 에어드롭 참가자들을 대상으로 “튜링 룰렛”이라 불리는 이벤트를 열어, AI와 인간을 구분하는 게임에 참가하도록 한 것이다. 튜링 룰렛은 사용자가 AI와의 대화를 통해 상대가 인간인지 AI인지를 맞히는 일종의 튜링 테스트로, AI 시대에 진위를 가리는 경험을 제공하면서 라그랑주의 지향점을 상징적으로 보여준 캠페인이었다. 지난 5월 11일 종료된 시즌3의 총 참여자수는 14만명, 게임·증명의 수는 375만회를 기록했다. 라그랑주는 이렇게 기술 개발뿐 아니라 커뮤니티 참여와 인식 제고 측면에서도 활발한 행보를 보이고 있다.

다양한 AI x 크립토 프로젝트의 등장과 라그랑주의 차별성

현재 AI 기술과 크립토 생태계의 결합은 다양한 방향으로 확장되고 있으며, 다양한 AI 프로젝트들은 각기 다른 과제를 해결하고 있다. 대표적으로는 다음과 같은 유형으로 분류된다:

이처럼 다양한 프로젝트가 AI 모델의 실행 인프라, 컴퓨팅 리소스 공유, 에이전트 구조, 사용자 신원 검증 등 각기 다른 기술 영역에 집중하고 있다. 이들 대부분은 AI의 실행 및 활용을 분산화하거나, 접근성과 보상 구조를 재설계하는 것에 초점을 맞추고 있다.

많은 AI 인프라 네트워크들 중 라그랑주(Lagrange)는 AI 데이터 검증 영역에 집중한다. 이처럼 AI 결과의 신뢰성 검증(inference-level integrity)에 초점을 맞춘 프로젝트인 라그랑주는 꽤나 성공적인 시작의 발판을 마련한 것으로 보인다. 성공적인 시작은 다른 AI 인프라 프로젝트들과 협력적으로 연결될 수 있는 중요한 퍼즐 조각이다.

한국에서 시작된 커뮤니티 기반의 확산

특히 주목할 점은 라그랑주가 기술적 차별성과 더불어 한국에서 매우 커뮤니티 친화적인 프로젝트로 출발했다는 점이다. 한국에서 ‘밋업메타’라는 새로운 에어드랍 시스템의 출발을 주도했고, 이는 “AI 프로젝트 중 한국에서 가장 눈에 띄는 성장세”라는 인상을 심어주었다. 실제로 밋업, 에어드랍, 앰배서더 프로그램 등에서 참여자 중심의 운영 전략이 빛을 발하며, 한국 커뮤니티의 활발한 참여를 이끌어냈다.

다만 앞으로 개선될 수 있는 방향도 존재한다. 예컨대,

• 앞으로의 실행가능한 현실적 로드맵 확립과 이행
• 기여자의 성장을 유도할 수 있는 지속적인 피드백 루프
• 기술적 진보와 커뮤니케이션의 균형 (예: zkML의 쉬운 설명 컨텐츠 제공)

이러한 점들을 보완해나간다면, 라그랑주는 단순히 “기술적으로 뛰어난 프로젝트”를 넘어 AI 신뢰 검증의 글로벌 인프라로 자리매김할 가능성을 충분히 지니고 있다.

결론: 신뢰 인프라로서의 라그랑주의 가능성

AI와 블록체인의 융합 분야는 이제 막 태동한 영역이지만, 그중에서도 라그랑주(Lagrange)는 신뢰성이라는 본질적인 가치를 짚어낸 프로젝트로 평가받고 있다. SKT 해킹 사고나 딥페이크 사태에서 보듯이, 디지털 시대의 혁신은 신뢰 없이는 위험으로 바뀔 수 있다. 라그랑주는 첨단 암호기술을 통해 AI의 신뢰 문제를 해결하는 선구자적 역할을 하고자 노력하며, 엔비디아를 비롯한 업계 리더들과 유수 투자자들의 지원으로 그 비전을 현실에 가까이 끌어오고 있다. 물론 앞으로 넘어야 할 과제들도 남아 있다. zkML 기술의 표준화와 대중적 활용이 더 진전되어야 하고 다양한 AI 모델과의 호환성 확보, 그리고 네트워크 효과를 통한 생태계 확장이 이루어져야 할 것이다.

그럼에도 불구하고, 현재 등장하는 여러 AI+크립토 프로젝트들 가운데 라그랑주는 “믿을 수 있는 AI”라는 분명한 문제의식과 솔루션으로 두각을 나타내고 있다. 미래에는 OpenAI 같은 거대 AI부터 작은 디앱(dApp)에 이르기까지, 라그랑주의 검증 레이어를 통해 결과의 신뢰를 담보하는 모습이 당연해질지도 모른다. AI 시대의 검증 인프라로서 라그랑주의 행보에 업계의 이목이 집중되는 이유가 여기에 있다. 라그랑주의 도전은 이제 시작 단계이지만, 그 미래 가능성은 많은 이들이 주목하고 있는 바다. 앞으로 라그랑주를 비롯한 AI 프로젝트들이 만들어갈 “증명 가능한 AI”의 생태계가 어떻게 전개될지 살펴보아야 할 것이다.

AI 시대의 신뢰 위기와 라그랑주 was originally published in CURG on Medium, where people are continuing the conversation by highlighting and responding to this story.

블록체인 연합 학회 CURG에서 학회원을 모집합니다. 지원하러 가기: 링크

CURG가 걸어온 길

CURG(Crypto United Research Group)는 2018년 5월 가톨릭대, 고려대, 서강대, 서울대, 성균관대, 이화여대, 중앙대, 한양대 등 서울권 대학교 학생들을 중심으로 만들어졌습니다.

여러 학문 분야를 망라하는 기술인 블록체인을 트렌디하고 심도 있게 꾸준히 연구하고 3T(Trendy | Thoughtful | Transdisciplinary) 한 자세로 블록체인 리서치를 이어왔습니다.

CURG의 비전

“기술 중심의 리서치 및 개발을 통해 생태계에 능동적으로 기여하자”

CURG는 열린 리서치 플랫폼으로써의 역할을 수행하고 있습니다. 또한 블록체인 인프라부터 토크노믹스, DAO, Dapp 등 다양한 영역에 걸친 연구가 이루어지고 있습니다.

팀활동을 통해 함께 연구하며 오픈소스 개발, PoC프로덕트를 통해 생태계에 기여하고 학회원들 각각의 개인 역량 향상이 CURG가 추구하는 방향입니다.

주요 활동

연사 초청 세션

CURG는 업계의 다양한 연사를 모셔 학회원들의 경험 확장과 네트워킹을 지원하고 있습니다. 학회 내부의 인사이트에서 멈추는 것이 아닌 실제 업계 최전선에서 고군분투 중인 창업자 및 CTO/엔지니어의 경험을 통해 시야를 확장할 수 있습니다.

팀활동

최근 블록체인 씬에서 등장하는 기술과 기술스택들을 사용해서 각각의 팀들이 결과물들을 만들어가는 시간입니다.

• Gnomix Team: Gno 체인에서 기존 툴이 제공하고 하지 못한 DX를 제공하기위해 Gno를 위한 Remix를 개발한 팀.
• Farcaster Mini App Team: Faracaster에서 크리스마스 트리 꾸미기를 개발하고 그 경험을 통해 Frame 개발툴에서 다양한 문제점을 찾아낸 팀.
• Safe Team: Safe Wallet의 Ecosystem과 그 원리를 심층 리서치한팀.
• AOT EVM Team: AOT컴파일러를 EVM에 적용한 라이브러리를 활용해 노드 런타임에서 활용할 수 있는 라이브러리를 개발한 팀.
• zkTLS Team: zkTLS를 활용한 트리 꾸미기를 만들고 다양한 zkTLS 관련 프로덕트를 리서치한 팀.

짧은 문장으로 소개할 수 없을 각 팀이 정말 다양한 활동을 진행했으며 지원자분들을 같이 함께했으면 합니다.

CUDY (성과 공유 발표회)

: 트위터 링크

지원 자격

나이, 학력 무관하게 크립토 윈터가 오더라도 흔들리지 않고 CURG 학회원들과 끈끈하게 의지하면서 블록체인 리서치와 빌딩에 몰입할 수 있는 사람을 모집합니다. 현재 대학생, 대학원생, 현직자등 매우 다양한 사람들이 학회원으로 있으니 주저하지 말고 지원해 주세요.

커그에 지원하면 좋으실 분들:

1. 블록체인 업계에 있는 현직자들과 네트워킹을 희망하는 사람.
2. 독특한 아이디어로 새로운 프로덕트를 만들어가는 것을 즐기는 사람.
3. 블록체인 씬에서 연구되는 최근 동향들을 파악하고 새로운 인사이트를 얻어가기를 원하는 사람.

12 기 학회 활동

CURG의 활동은 정규 활동과 팀 활동으로 구성됩니다.

팀 활동은 팀원들이 원하는 주제를 연구하고 발표하며, 이를 기반으로 PoC 프로덕트/심층 리서치/오픈소스 컨트리뷰션 활동을 만들어 갑니다.

정규 활동은 매주 토요일 11시-1시 강남역 인근에서 진행되며, 연사 초청 세션이 진행되고 팀활동에서 나온 결과물들을 학회원들과 공유하며 생각을 주고 받습니다.

한 학기가 아닌 총 1년 동안 활동하셔야 수료하실 수 있습니다. 1년 동안 활동이 가능하신 분만 지원 바랍니다.

지원 방법

• 지원방법 : 구글폼신청 — 링크
• 서류 접수 마감 : ~ 25.03.26 23:59
• 서류 합격자 발표 | 25.03.28
• 오프라인 면접 | 25.03.29 ~ 25.03.30 (토, 일)
• 최종 합격자 발표 | 25.03.31
• OT & 11기 시작 | 25.04.05 (토)

About CURG

• CURG 미디엄: https://medium.com/curg
• CURG 트위터: https://twitter.com/curg_official

기타 문의 : curg.in.seoul@gmail.com 로 문의바랍니다.

CURG 12기 리크루팅 was originally published in CURG on Medium, where people are continuing the conversation by highlighting and responding to this story.

A. Abstract

본 글에서는 Ahead-Of-Time (AOT) 컴파일러를 활용하여 EVM 바이트코드를 컴파일함으로써 이더리움 가상 머신(EVM)의 실행 성능을 향상시키는 방법을 소개합니다.

블록체인에 배포된 스마트 컨트랙트 코드는 변경되지 않음에도 불구하고 EVM 인터프리터를 통해 실행되어야 하며, 이는 본질적으로 낮은 성능을 초래합니다. 이에 따라 JavaScript나 Java와 같은 기존 인터프리터 기반 언어[1]들이 AOT/JIT [2] 컴파일 방식을 도입해 실행 성능을 높인 사례를 참고하여, EVM 바이트코드에 LLVM[3]을 사용해서 AOT 컴파일 방식을 적용하는 아이디어가 나오게 되었습니다.

그래서 이 아이디어를 기반으로 Paradigm은 EVM AOT 컴파일러를 EVM 실행 라이브러리 revm에 통합하여 revmc 라는 프로젝트를 만들게 되었습니다.

본 글에서는 revmc의 구조와 성능 분석을 다루고, 이를 활용해 개발된 라이브러리들의 기능들 소개하려고 합니다.

B. Related Work: revmc

본 글에서는 revmc concept과 example implementation 을 살펴보겠습니다.

B-1. Concept

revmc는 Paradigm이 개발한 EVM 성능 향상을 위한 라이브러리입니다. 이는 기존 revm에 자체 개발한 AOT [2] 컴파일러를 통합 개발한 것으로, LLVM IR을 생성하고 LLVM [3] 을 통해 각 플랫폼에 맞는 머신코드로 컴파일합니다. 이렇게 컴파일된 머신코드는 인터프리터 방식 대신 머신 코드를 직접 실행하여 지연 시간과 오버헤드를 크게 줄일 수 있습니다.

솔리디티 컴파일러(solc)는 스마트 컨트랙트를 컴파일하여 opcode 묶음을 생성하고, 이를 블록체인에 배포합니다. 컨트랙트가 실행될 때 EVM 인터프리터가 이 바이트 코드의 opcode들을 하나씩 실행하게 됩니다. 그러나 블록체인에 배포된 바이트 코드는 불변하기 때문에, 매번 인터프리터로 실행하는 것은 비효율적입니다.

따라서 revmc는 인터프리터 방식 대신 AOT 컴파일을 통해 만들어진 머신 코드로 을 수행합니다. 이 과정에서는 프론트엔드 단계를 통해 LLVM IR을 구성해야 합니다. 바이트코드는 분기점(예: JUMPDEST, JUMP opcode)을 기준으로 코드 블록을 나누고 이를 이용해 IR을 만듭니다. 그리고 플랫폼이 결정된 후에는 LLVM을 사용하여 백엔드 작업을 통해 머신 코드를 생성합니다. 최종적으로 EVM 바이트코드를 LLVM IR로 변환하고, LLVM을 통해 최종 머신 코드로 컴파일합니다.

정리하자면, 인터프리터가 opcode를 하나씩 실행하는 방식 대신 여러 개의 opcode를 묶어서 실행함으로써 비용을 크게 절감하고 실행 속도를 향상시킬 수 있습니다. jump opcode나 call, delegatecall과 같은 call opcode를 기준으로 코드 블록을 나누어 프론트엔드 과정에서 LLVM IR을 생성하고, 이를 LLVM을 통해 머신코드로 컴파일하여 클라이언트의 로컬 스토리지에 저장합니다. 이후 클라이언트가 컨트랙트를 실행할 때는 저장된 머신코드를 사용하여 더 낮은 비용으로 트랜잭션을 재실행할 수 있습니다.

B-2. Implementation

revmc를 사용하여 어떻게 evm에서 실행이 되는지 그 구현의 예시를 들며 설명해보겠습니다.

revmc를 사용해서 피보나치 컨트랙트를 머신코드로 실행하기 위한 코드 (github)

주석을 통해 함수에 대한 설명을 달아놓았습니다.

// 1. external context는 피보나치 컨트랙트에 해당하는 코드가 실행될때 
// get_funcation을 통해 native machine code를 반환합니다.
impl ExternalContext {
    fn new() -> Self {
        Self
    }
   ️⃣
    fn get_function(&self, bytecode_hash: B256) -> Option<EvmCompilerFn> {
        // Can use any mapping between bytecode hash and function.
        if bytecode_hash == FIBONACCI_HASH {
            return Some(EvmCompilerFn::new(fibonacci));
        }

        None
    }
}

// 2. register_hander에서 handler는 ExternalContext를 제네릭으로 가지고 있는 것을 
// 볼 수 있고 함수 구현을 보면 execute_frame에서 ExternalContext의 get_function을 타고
// call_with_interpreter_and_memory를 통해 미리 컴파일된 함수가 실행된다는 것을 볼 수 있습니다.
// This `+ 'static` bound is only necessary here because of an internal cfg feature.
fn register_handler<DB: Database + 'static>(handler: &mut EvmHandler<'_, ExternalContext, DB>) {
    let prev = handler.execution.execute_frame.clone();
    handler.execution.execute_frame = Arc::new(move |frame, memory, tables, context| {
        let interpreter = frame.interpreter_mut();
        let bytecode_hash = interpreter.contract.hash.unwrap_or_default();
        if let Some(f) = context.external.get_function(bytecode_hash) {
            Ok(unsafe { f.call_with_interpreter_and_memory(interpreter, memory, context) })
        } else {
            prev(frame, memory, tables, context)
        }
    });
}

// 3. build_evm 할때는 register_handler를 주입해주는 것을 볼수 있습니다. 
// 그러면 결과적으로 빌드된 evm에서는 execute_frame가 실행될때 
// 즉, transacation replay할때 로컬에 저장된 머신 코드를 가져와 실행하게 됩니다.
/// Build a [`revm::Evm`] with a custom handler that can call compiled functions.
pub fn build_evm<'a, DB: Database + 'static>(db: DB) -> revm::Evm<'a, ExternalContext, DB> {
    revm::Evm::builder()
        .with_db(db)
        .with_external_context(ExternalContext::new())
        .append_handler_register(register_handler)
        .build()
}

이 예시 구현을 나타낸 그림을 보면, evm에 피보나치 컨트랙트의 머신코드를 가지고 있는 external context를 사전에 주입해주고 bytecode hash(keccack256 of bytecode)가 fibonachi hash일때 지정해놓은 external context를 통해 로컬 스토리지에 있는 머신코드를 가져와서 실행하게 됩니다.

C. Measure: revmc Performance in ERC20 and Fibonacci Computation

해당 성능 측정은 E-1. 런타임 성능 향상 에서 언급된 revmc-worker를 이용해서 수행했습니다.

C-1. 피보나치 컨트랙트 밴치 마크 비교

benchmark code: github

패러다임 포스트에서 이미 피보나치 컨트랙트에 대해 실행속도를 측정하는 자료가 있습니다.

다만, 보다 다른 결과를 얻기 위해 피보나치 컨트랙트의 fib(n) 호출에서 n 값을 점진적으로 증가시키며 즉, contract call 횟수를 늘리면서 실행속도의 변화 추이를 알아보고자 측정했습니다. (피보나치 컨트랙트는 피보나치 컨트랙트를 재귀적으로 호출하는 컨트랙트입니다.)

C-2. ERC20 컨트랙트 밴치 마크 비교

benchmark code: github

대표적인 토큰 컨트랙트인 erc20에 대한 밴치마크입니다. 예상과 달리 그렇게 성능 개선이 크지 않다는 것을 알 수 있습니다.

C-3. Conclusion of Measure

앞서 측정된 결과를 분석하면, 피보나치 컨트랙트에서 볼 수 있듯이 contract call과 같이 분기하는 횟수가 많을수록 성능이 증가합니다. 반면 ERC20의 경우, contract call이 한 번만 일어나기 때문에 코드 블록이 단일로 이루어져 있어 성능이 기존과 큰 차이가 없습니다. 심지어 AOT 컴파일된 머신 코드를 불러와서 실행하는 것이 더 낮은 성능을 보일 때도 있습니다(예: Transfer 측정 시간 비교, 파일로드하는데 드는 비용이 발생합니다).

하지만 피보나치 컨트랙트처럼 콜 수가 많아질수록 성능 차이는 극적으로 커집니다. 극단적인 예시이긴 하지만, f(100000)의 결과를 보면 10만 번 이상의 contract call을 수행했을 때 성능이 무려 약 181배나 향상된다는 것을 확인할 수 있었습니다.

D. Our Contribution

저희 팀은 revmc를 기반으로 PoC로 노드 런타임에 컴파일을 지원하는 기능과 geth를 기반 클라이언트에서 ffi call을 통해 revm의 장점을 활용할 수 있는 라이브러리를 개발했습니다. 현재는 프로덕션에서도 활용될 수 있게 테스트와 개발을 계획하고 있습니다.

D-1. 노드 런타임 컴파일

: node runtime에 compile하도록 해서 JIT compiler 처럼 동작하도록 만든 라이브러리

revmc-worker (github)

예시 구현(C-2. Implementation)에서 볼 수 있듯이, 기존 방식에서는 EVM을 실행하기 전에 AOT(Ahead-Of-Time) 컴파일을 수행하여 이를 활용해 실행합니다. 그러나 이러한 방식에는 몇 가지 한계가 있습니다. 새로운 컨트랙트에 대해 머신 코드를 추가하고 싶을 때마다 revmc를 사용하는 클라이언트는 AOT 컴파일을 수동으로 수행해야 하며, 이후 구현체를 재컴파일해야 하는 문제가 발생합니다. 이로 인해 노드 런타임에서 머신 코드를 효율적으로 활용하기 어려운 구조적 한계가 있습니다. 특히, 노드 운영자(node operator)가 클라이언트를 중단하고 다시 실행해야 하는 상황은 현실적으로 운영 환경에서 매우 부담스러운 문제입니다.

이러한 문제를 해결하기 위해 노드 런타임에서 백그라운드로 AOT 컴파일을 수행하면서 블록 동기화 시간(sync time)에 미치는 영향을 최소화하도록 설계한 라이브러리를 개발하게 되었습니다. 이 라이브러리는 다음과 같은 기능을 지원합니다

• Concurrent AOT Compile 수행: 노드 운영자가 동시 실행 가능한 작업(task) 수를 설정할 수 있습니다.

• AOT 컴파일 threshold 설정: 특정 컨트랙트가 지정된 횟수 이상 호출된 경우에만 AOT 컴파일이 수행되도록 설정할 수 있습니다.

• LRU 캐시 도입: 실제 트랜잭션에서는 컨트랙트가 실행되고 다시 실행되는 경우가 많습니다. 기존 구현에서는 그때마다 파일로드를 하게되는데 이는 높은 비용을 요구하기 때문에 머신 코드를 캐싱하여 파일 로드 시간을 단축시킵니다.

이 라이브러리의 아키텍처는 다음과 같이 설계되었습니다.

먼저, revmc-worker는 Embedded Database를 사용하여 각 컨트랙트의 호출 횟수를 기록합니다. 클라이언트가 설정한 임계값(threshold)을 초과하면, 해당 컨트랙트를 컴파일 작업 큐(task queue)에 추가합니다. 작업이 모두 완료되면 생성된 머신 코드를 로컬 데이터베이스에 저장합니다.

이 과정을 통해 런타임 중에도 머신 코드를 로컬 스토리지에 동적으로 추가할 수 있으며, 실행 시 해당 머신 코드가 존재하면 이를 즉시 실행할 수 있습니다. 결과적으로 클라이언트를 재컴파일하거나 수동으로 파일을 추가해야 하는 기존의 번거로운 과정을 제거할 수 있습니다.

D-2. 호환성

: geth 기반 클라이언트에서 revm을 실행할 수 있도록 인터페이스를 만들어놓은 라이브러리

revmffi (github)

revmc와 revm은 상당히 나은 메모리 사용량과 실행속도를 가지고 있습니다. 하지만 그럼에도 불구하고 비교적 revm을 사용하는 reth는 execution client diversity에서 낮은 점유율을 가지고 있습니다. 이를 해결하기 위해서 geth 기반 클라이언트에서 ffi call을 통해 revm을 실행할 수 있도록 지원하는 라이브러리입니다.이 pr의description 에서 cadvisor로 geth의 call/create를 실행했을 때 해당 라이브러리를 통해 실행하는 것이 메모리 사용량 cpu 코어 사용량이 낮다는 결과를 볼 수 있습니다. 간단하게 테스트 한것이지만 revmffi 가 더 높은 성능을 가진것을 알 수 있었습니다.

E. Conclusion

revmc는 EVM의 인터프리터 방식에서 벗어나 AOT/JIT 컴파일을 통해 머신코드를 생성하여 컨트랙트를 실행합니다. 측정 결과에 따르면, 이 머신코드는 분기가 많을수록 더 높은 성능을 보여주지만, 분기가 없는 경우에는 오히려 성능이 저하될 수 있습니다. 그러나 DeFi나 복잡한 프로토콜에서는 contract call과 branch가 빈번하게 발생하므로, 실제 환경에서는 상당한 성능 향상을 기대할 수 있습니다.

현재 PBS 시장에서는 높은 transaction replay 속도가 필수적입니다. 특히 Bundling과 Searching 과정에서 더 빠른 실행 속도를 가진 노드가 시장에서 우위를 점할 수 있으며, 이를 위해 노드들은 revmc를 도입하여 실행 속도를 향상시킬 수 있습니다.

더불어 Prague upgrade와 Lido의 GasLimit 증가 움직임으로 인해 블록의 데이터 크기와 트랜잭션 수가 증가할 것으로 예상됩니다. 이러한 환경에서 빠른 transaction replay 능력은 PBS 시장에서의 경쟁력을 높이고, 더 적은 인프라 비용으로도 효율적인 block validation을 가능하게 할 것입니다.

F. Reference

aot/jit: https://ko.wikipedia.org/wiki/JIT_컴파일
llvm: https://ko.wikipedia.org/wiki/LLVM
revmc: https://www.paradigm.xyz/2024/04/revmc

E. Definition

EVM에 대한 기본적인 동작 구조는 아실 것이라고 생각되어 본 글에서는 다루지 않겠습니다.(학습링크)

[1] 인터프리터 언어 vs 컴파일 언어

[2] AOT/JIT

[3] LLVM

EVM + AOT Compiler: revmc was originally published in CURG on Medium, where people are continuing the conversation by highlighting and responding to this story.

본 글은 정보 제공을 목적으로 작성된 것으로, 투자, 법률, 자문 등 어떠한 분야에서도 책임을 지지 않습니다. 특정 자산에 대한 투자 권유의 의도가 없으며, 본문 내용만을 기반으로 투자 결정을 내리지 마시기 바랍니다.

본 글은 Safe{Wallet} 시리즈의 두 번째 글로, Safe{Wallet}의 배포 과정부터 상호작용에 대한 코드 중심의 기술적 분석을 다룬다. 이번 글을 통해 Safe가 단순한 멀티시그 지갑을 넘어, DeFi나 DAO와 같은 복잡한 온체인 시나리오에서도 활용될 수 있는지 살펴보고자 한다. 해당 글은 Smart Contract에 대한 기초 지식이 있는 개발자를 대상으로 작성되었다. 독자는 이 글을 통해 Safe Wallet의 배포 과정부터 상호작용까지 이해할 수 있을 것이라 기대된다.

1편 : [Safe 시리즈]#1 : 스마트 컨트랙트 지갑 Safe{Wallet} 살펴보기

2편 : [Safe 시리즈]#2 : Safe{Wallet}의 배포와 사용, 기술 분석으로 이해하기

안준하 | researcher of CURG | junha.ahn.dev@gmail.com
김상우 | researcher of CURG | 0xhold2018@gmail.com
최현겸 | researcher of CURG | sw.sdy613@gmail.com

목차

1. Deploy & Setup
2. Safe Tx란 무엇인가
3. Sign/Verify
4. execTransaction

1장. Deploy & Setup

Safe Wallet은 아래 그림과 같이 EIP-1167 Minimal Proxy 패턴을 통해 배포된다. 즉 유저가 Safe{Wallet} 에서 새로운 Safe Account를 만드는 것은 아래 Proxy Contract를 하나 더 배포하는 것과 같다.

참고로, 프록시 패턴을 통해 아래 장점을 얻을 수 있다.

• 가스비 절약: 모든 Safe Wallet이 동일한 로직을 공유하므로 로직 배포에 드는 가스비를 절약.
• 업그레이드 가능: 버그가 발견되거나 새로운 기능이 필요할 때 SafeSingleton 구현체를 교체할 수 있다.

• SafeProxyFactory.sol 과 SafeProxy.sol을 통해 확인 가능하다.
• 또한 Logic Contract는 Safe.sol을 확인하면 된다.
• safe-deployments 를 통해 현재 배포된 Singleton의 주소도 확인 가능하다.

SafeWallet은 배포 직후 Setup 함수를 호출하여 초기화를 진행한다.

Setup 함수는 다음과 같은 주요 작업을 수행한다:

function setup(
    address[] calldata _owners,
    uint256 _threshold,
    address to,
    bytes calldata data,
    address fallbackHandler,
    address paymentToken,
    uint256 payment,
    address payable paymentReceiver
) external {
		// 정족수와 Owner 리스트를 등록한다.
    setupOwners(_owners, _threshold);

    ...

    emit SafeSetup(msg.sender, _owners, _threshold, to, fallbackHandler);
}

참고로 Four practical Solidity patterns from Gnosis Safe 를 보면 알 수 있지만, Safe는 아래와 같이 Mapping을 통해 Owner를 관리한다.

mapping(address => address) internal owners;

Setup 단계에서 설정되는 threshold(정족수)와 owner 리스트는 Safe의 “Multisig” 기능을 구현한다.

• 이후 살펴볼 로직에서, Safe는 threshold 이상의 owner 승인이 있어야만 작동하도록 보장한다
• 즉 Safe Account가 자신의 자산을 이동하거나 외부 컨트랙트와 상호작용할 때는 최소 threshold만큼의 owner가 동의해야만 한다. (동의가 되지 않으면 실행 안 됨)

이제부터, 이렇게 설정된 Safe Account가 어떻게 트랜잭션을 생성하고 서명하는지 살펴볼 것이다.

2장. Safe Tx란 무엇인가

만약 Safe Account의 1 ETH를 0x987로 전송하는 ‘트랜잭션’을 만든다면 아래와 같을 것이다.

1. 1 ETH를 전송하는 safeTx를 만든다.
2. safeTx의signature를 만든다.
3. 위 그림과 같이 toAddress를 safeProxy으로 하고, calldata를 execTransaction(SafeTxObject, signature) 로 설정한 트랜잭션을 broadcast한다.
4. “Safe Singleton Contract”의 정해진 로직에 따라 signature를 확인하고 Owner의 것이라면 1 ETH를 이동한다.

참고로 execTransaction의 함수 시그니처는 위와 같다. 현재 이해가 안 가는 Parameter들은 생략해도 좋다.

참고로, data와 operation(call, delegatecall)을 보면 알 수 있듯, Safe는 1 ETH 전송과 같은 단순 Value Transfer만 실행할 수 있는 것이 아니라, 다른 컨트랙트를 call, delegatecall 하는 등도 가능하다. (erc20 approve, transfer 등) 이는 아래에서 자세히 살펴볼 예정이다.

• 특정 Safe execTransaction calldata를 decode해보면 위와 같은 값들을 확인할 수 있다. (일반 트랜잭션과 다를 게 없다! 가스비 관련 설정은 일단 넘어가자)

3장. Sign/Verify

Sign

블록체인 세상에서 디지털 서명(Signature)은 개인키(Private Key) 소유자가 특정 데이터(블록체인 세상에선 보통 트랜잭션)에 대해 암호학적 서명을 진행하여 생성한 bytes를 의미한다. 이 디지털 서명의 가장 중요한 특징은 암호학적 연산을 통해 해당 서명으로부터 공개키(Public Key)를 추출할 수 있다는 점이다. 즉 이를 통해 블록체인 네트워크의 참여자들은 해당 트랜잭션이 실제로 개인키 소유자에 의해 서명되었는지 검증할 수 있다.

SafeTx도 위와 같다. safeTx에 대해 safeWallet의 owner가 서명한 bytes가 바로 위 이미지 마지막 파라미터인 bytes memory signatures 인 것이다.

• 참고로, signature가 아니라 signatures이다. 즉 여러 개의 서명이 연속적으로 나열되어 있다. 즉 safeWallet에 등록된 여러 owner는 각각 하나의 서명을 생성하고, 실제로 가스비를 지불하고 트랜잭션을 실행할 주체가 모든 서명을 수집하여 한 번에 제출한다.
• 이때 우리는 해당 함수에 require(signatures.length >= threshold * 65, "signatures length is invalid") 와 같은 검증 로직이 존재할 것을 예상할 수 있다. 각 ECDSA 서명이 65바이트를 차지하므로, 전체 서명 데이터의 길이는 정족수(threshold) × 65바이트여야 하기 때문이다.
• 또한 서명의 유효성을 검증하기 위해 ecrecover 를 호출하여 각 서명으로부터 복구된 주소가 실제 owner 목록에 포함되어 있는지도 확인해야 한다.

블록체인에서 일반적으로 서명하는 대상과 마찬가지로, SafeTx에서 owner들이 서명하는 대상은 바로 safeTxHash이다. safeTxHash는 실행하고자 하는 Safe 트랜잭션의 모든 파라미터(to, value, data, operation, safeTxGas 등)를 직렬화한 후 keccak256으로 해시화한 32바이트 값이다.

이 직렬화 + 해싱 로직은 getTransactionHash 함수에 정의되어 있는데, 위 사진을 보면 알 수 있듯 트랜잭션의 모든 파라미터를 포함하여 해시화하고 있다. 이제, 직렬화 과정 일부를 살펴보자.

mstore(ptr, SAFE_TX_TYPEHASH)

mstore(add(ptr, 32), to)            // 받는 주소
mstore(add(ptr, 64), value)         // 이더량
mstore(add(ptr, 96), calldataHash)  // 호출 데이터의 해시
mstore(add(ptr, 128), operation)    // Call or DelegateCall
// ... 기타 gas 관련 파라미터들
mstore(add(ptr, 320), _nonce)       // 논스값
// EIP-712 최종 해싱
bytes32 safeTxHash = keccak256(abi.encodePacked(
    0x1901,                 // EIP-712 prefix (0x1901)
    domainSeparator(),      // EIP-712 도메인 해시    
    serialized_Tx_Struct    // 직렬화된 트랜잭션
));

각 파라미터는 위와 같이 정해진 규칙에 따라 순차적으로 배치된다. 그리고 마지막으로, EIP-712 표준에 따라 해시화되어 최종 safeTxHash가 된다. 그리고 각 owner가 ECDSA 서명을 하면 65바이트의 signature가 생성된다.

참고로 아래와 같은 domainHash가 사용된다.

// keccak256(
// "EIP712Domain(uint256 chainId,address verifyingContract)"
// );
bytes32 private constant DOMAIN_SEPARATOR_TYPEHASH = 0x47e79534a245952e8b16893a336b85a3d9ea9fa8c573f3d803afb92a79469218;

// keccak256(
// "SafeTx(address to,uint256 value,bytes data,uint8 operation,uint256 safeTxGas,uint256 baseGas,uint256 gasPrice,address gasToken,address refundReceiver,uint256 nonce)"
// );
bytes32 private constant SAFE_TX_TYPEHASH = 0xbb8310d486368db6bd6f849402fdd73ad53d316b5a4b2644ad6efe0f941286d8;

function domainSeparator() public view override returns (bytes32) {
    uint256 chainId;
    /* solhint-disable no-inline-assembly */
    /// @solidity memory-safe-assembly
    assembly {
        chainId := chainid()
    }
    /* solhint-enable no-inline-assembly */
    return keccak256(abi.encode(DOMAIN_SEPARATOR_TYPEHASH, chainId, this));
}

• Safe는 EIP-712 표준을 따르고 있다.
• domainSeparator에 chainId가 포함되어 있는 것을 볼 수 있다. 이는 크로스체인 재사용 공격을 방지하기 위함이다. 예를 들어 이더리움 메인넷에서 생성된 Safe Account 서명을 폴리곤 Account에 재사용하려고 하면, chainId가 다르기 때문에 검증에 실패하게 된다.
• SAFE_TX_TYPEHASH에서 볼 수 있듯이 모든 트랜잭션에는 nonce가 포함된다. 이는 트랜잭션 재사용 공격(replay attack)을 방지하는 핵심 메커니즘이다. nonce는 트랜잭션마다 순차적으로 증가하므로, 한번 실행된 트랜잭션의 서명을 다시 사용하려고 하면 nonce 불일치 탓에 검증에 실패하게 된다.

지금까지 살펴본 모든 로직을 JavaScript로는 다음과 같이 표현할 수 있다.

// Safe 트랜잭션 객체
const safeTx = {
    to: "0x...",
    value: "1000000000000000000", // 1 ETH
    data: "0x",
    operation: 0,
    // ... 기타 파라미터들
};

// safeTxHash 생성 (ethers.js 사용)
const safeTxHash = await safeContract.getTransactionHash(
    safeTx.to, safeTx.value, safeTx.data, safeTx.operation, /*...*/
);
// 개인키로 서명
const signature = await owner.signMessage(ethers.utils.arrayify(safeTxHash));

한번 정리하자면:

1. safeTxHash는 EIP-712 표준에 따라 트랜잭션 파라미터들을 직렬화한 후 해시화한 값이다
2. 각 owner는 이 safeTxHash에 대해 ECDSA 서명을 생성한다 (65바이트)
3. 모든 서명은 하나의 바이트 배열로 결합되어 최종적으로 컨트랙트에 제출된다
4. 컨트랙트 execTransaction 함수 내에서 제출된 서명의 개수가 충분한지 확인하고, 각 signature로부터 복구한 주소가 실제 owner 목록에 포함되어 있는지 검증한다.
5. 모든 검증이 완료되면 execTransaction 함수는 지정된 대상 주소로 함수 호출이나 이더 전송을 수행한다

다음 장에서는 어떻게 각 owner의 서명이 검증되는지 자세히 살펴본다.

Verify

먼저 execTransaction 함수의 서명 검증 관련 로직을 살펴보면

function execTransaction(to, value, data, operation ... signatures) {
    // ... 
    {
        bytes32 txHash = getTransactionHash(
            to, value, data, operation,
            safeTxGas, baseGas, gasPrice,
            gasToken, refundReceiver, nonce++
        );
        
        checkSignatures(txHash, signatures); 
    }
    // ... 실제 트랜잭션 실행 로직
}

execTransaction에서 checkSignatures 함수를 호출하는것을 확인 가능하다. 콜스택 가장 아래 checkNSignatures 함수가 존재하고, 해당 로직을 자세히 살펴보자.

function checkNSignatures(
    address executor,
    bytes32 dataHash,
    bytes memory signatures,
    uint256 requiredSignatures
) public view {
    // 서명 데이터의 길이가 충분한지 확인 (각 서명은 65바이트)
    require(signatures.length >= requiredSignatures * 65);
    
    address lastOwner = address(0);
    address currentOwner;
    
    for (uint256 i = 0; i < requiredSignatures; i++) {
        (v, r, s) = signatureSplit(signatures, i);
        if (v == 0) {
            // 컨트랙트 서명
            currentOwner = address(uint160(uint256(r)));
            checkContractSignature(currentOwner, dataHash, signatures, uint256(s));
        } else if (v > 30) {
            // eth_sign 방식
            currentOwner = ecrecover(keccak256(abi.encodePacked("\\x19Ethereum Signed Message:\\n32", dataHash)), uint8(v - 4), r, s);
        } else {
            // EOA 서명
            currentOwner = ecrecover(dataHash, uint8(v), r, s);
        }
        // 복구된 주소가 유효한지, 오름차순으로 정렬되었는지 확인
        require(currentOwner > lastOwner && owners[currentOwner] != address(0));
        lastOwner = currentOwner;
    }
}

• 참고로 signature 구현 세부사항(어떻게 패킹되는지 등)에 대해서는 Four practical Solidity patterns from Gnosis Safe 마지막 챕터에서 쉽게 확인 가능하다. (더 자세히는 signatures.md 를 참고)

위 로직을 보면 세 가지 서명 방식(EOA 서명, eth_sign, 컨트랙트 서명)을 지원하는 것을 확인할 수 있다.

• 특히 v=0인 경우는 EIP-1271 표준(스마트 컨트랙트가 서명을 검증할 수 있게 하는 표준)을 구현한 컨트랙트의 서명을 처리한다.
• 더 자세히는 owner 주소로 지정된 스마트 컨트랙트의 isValidSignature 함수를 호출하여 서명의 유효성을 확인한다.

또한 특이하게 mapping을 활용해 owner를 확인하는 것을 볼 수 있다(owners[currentOwner] != address(0))

• 배열로 owners를 구현하지 않은 것이 특이한데, 이 패턴의 장점은 O(1)의 시간복잡도로 owner 여부를 확인할 수 있다는 점이다. 자세한 디자인 패턴은 링크에서 확인 가능하다.

이러한 정족수 체크와 각각의 서명 검증을 모두 통과하면, execTransaction 함수는 지정된 대상 주소로 함수 호출이나 이더 전송을 수행하게 된다. 이 실행 과정은 아래에서 자세히 살펴보도록 하겠다.

4장. execTransaction

지금까지 알아본 내용을 쉽게 정리하면

1. Owner들이 SafeTx에 각각 서명
2. 누군가가 여러 서명을 모아서 execTransaction 함수 호출
3. 서명 검증 (checkSignatures 호출)
4. 실제 Safe Tx를 실행한다 (execTransaction의 남은 로직)

아래 코드는 매우 간단하게 execTransaction를 요약한것이다.

function execTransaction(...) public payable returns (bool success) {
    // 1. 트랜잭션 해시 생성
    bytes32 txHash;
    {
        txHash = getTransactionHash(
            to, value, data, operation,
            safeTxGas, baseGas, gasPrice,
            gasToken, refundReceiver, nonce
        );
        
        // 2. 서명 검증 (이전 챕터에서 살펴봄)
        checkSignatures(txHash, dataHash, signatures);
    }
    
    // 3. nonce 증가
    nonce++;
    
    // 4. 실제 트랜잭션 실행 (여기서 대상 컨트랙트 호출)
    success = execute(to, value, data, operation, safeTxGas);
    
    // 5. Gas 관련 처리 
}

execute 함수는 매우 단순하다 (요약버전)

function execute(
    address to,
    uint256 value,
    bytes memory data,
    Enum.Operation operation,
    uint256 txGas
) internal returns (bool success) {
    if (operation == Enum.Operation.Call)
				// ETH Transfer, ERC20 Transfer등은 Call로 실행하면 된다.
        success = call(txGas, to, value, data);
    else if (operation == Enum.Operation.DelegateCall)
        success = delegatecall(txGas, to, data);
}

이제 쉽게 어떻게 execTransaction이 동작하는지 이해 가능하다.

1. Owner들이 SafeTx에 각각 서명
2. 누군가가 서명들을 모아서 execTransaction 호출
3. 서명 검증 (checkSignatures 호출)
4. 실제 Safe Tx 실행 (execute 호출

하지만 아직 가스비 처리 관련된 내용을 살펴보지 않았다.

execTransaction의 파라미터를 보면 가스비 관련 파라미터들이 있다:

function execTransaction(
    // ... 기본 파라미터들 ...
    uint256 safeTxGas,
    uint256 baseGas,
    uint256 gasPrice,
    address gasToken,
    address refundReceiver
)

Safe의 가스비 처리 방식을 이해하기 위해서는, 먼저 Safe Tx의 실행 구조를 다시 한번 살펴볼 필요가 있다.

지금까지 각각의 Owner들이 서명하고, 이 서명들을 모아서 “누군가” execTransaction을 호출한다고 설명했다. 중요한 것은, 이 execTransaction을 실행하는 주체(executor)가 꼭 Owner일 필요는 없다는 것이다. Safe 컨트랙트의 코드를 자세히 살펴보면, execTransaction 함수나 checkSignatures 함수 어디에서도 트랜잭션을 실행하는 주체(msg.sender 또는 tx.origin)가 Owner인지 검증하지 않는다. 오직 중요한 것은 충분한 수의 '유효한 Owner 서명이 있느냐는 것이다.

이는 의도된 설계인데, 이를 통해 다음과 같은 시나리오가 가능해진다:

1. Owner A, B, C가 SafeTx에 서명한다
2. 이 서명들을 다른 누군가(예: Dapp, 릴레이 서비스)에게 전달한다
3. 릴레이 서비스는 이 서명들을 가지고, 자신의 EOA로 execTransaction을 호출한다
4. Safe는 서명을 검증하고 트랜잭션을 실행한다

이러한 구조가 왜 필요할까? 중요한 두 가지 use case를 소개한다

• 각 Owner가 개별적으로 onchain 트랜잭션을 발생시키지 않아도 된다. 즉 서명은 오프체인에서 수집하고, 한 번의 onchain 트랜잭션으로 처리
• Owner들은 서명만 하면 되고, 실제 가스비 처리는 다른 서비스가 대신할 수 있다 (위 예시처럼 모아진 서명을, 릴레이 서비스에 전송하는 등)

하나의 예시를 가져왔다. 위 이미지는 실제 폴리마켓에서의 상호작용(베팅 등)을 간략하게 요약한 것이다.

• 폴리마켓은 유저마다 하나의 Safe Wallet을 만들어서 할당시킨다.
• 이후 유저는 폴리마켓 Dapp과 Safe Wallet을 통해 상호작용한다.
• 그림과 같이 유저는 “Relayer Server”로 signatrue를 넘기고, Polymarket EOA가 대신 Safe Tx를 실행하는 것을 확인할 수 있다.

위와 같이 유저는 폴리마켓과 상호작용할 때 “트랜잭션”을 만드는 게 아니라, “서명”만 하는 것을 확인할 수 있다.

• 이렇게 만들어진 signature는 Polymarket Relayer 서버로 전달된다.

이러한 맥락에서 Safe Tx를 타인이 대신 실행해 주었을 때, 발생한 가스비에 대한 “환불(refund) 메커니즘”이 존재한다는 것을 추측할 수 있다. 이제 코드를 통해 알아보자. 위에서 설명한 가스 관련 파라미터 중 가장 중요한 파라미터는 gasPrice 다. Safe는 이 값에 따라 가스비 처리 방식이 크게 달라진다.

gasPrice가 0인 경우는 가장 일반적인 시나리오다. 예를 들면:

1. Alice, Bob, Charlie가 Safe의 Owner
2. Alice가 Safe 트랜잭션에 서명하고, Bob과 Charlie도 서명
3. Alice가 자신의 지갑으로 이 트랜잭션을 실행

이런 경우 Alice는 gasPrice = 0으로 설정한다. Safe는 가스비를 환불 관련 로직을 실행하지 않고, Alice가 트랜잭션 실행에 필요한 가스비를 직접 지불한다.

gasPrice가 0보다 큰 경우는 조금 더 특별한 시나리오다. 예를 들면:

1. Alice, Bob, Charlie가 Safe의 Owner
2. 모두가 Safe 트랜잭션에 서명
3. 하지만 이 서명들을 릴레이 서비스에 전달
4. 릴레이 서비스가 자신의 EOA로 트랜잭션을 실행

이런 경우 Owner 중 누구도 가스비를 지불하지 않는다. 대신 릴레이 서비스가 먼저 가스비를 지불하고, Safe가 이를 환불해 준다.이런 경우 Owner 중 누구도 가스비를 지불하지 않는다. 대신 릴레이 서비스가 먼저 가스비를 지불하고, Safe가 이를 환불해 준다.

function execTransaction() {
	... 
	
	execute();
	
	if (gasPrice > 0) {
	    handlePayment(gasUsed, baseGas, gasPrice, gasToken, refundReceiver);
	}
}

이제 handlePayment 함수를 살펴보자. 이 함수의 가장 흥미로운 특징은 가스비를 ETH가 아닌 다른 토큰으로도 지급할 수 있다는 점이다. 코드를 살펴보자:

function handlePayment(
    uint256 gasUsed,
    uint256 baseGas,
    uint256 gasPrice,
    address gasToken,
    address payable refundReceiver
) private returns (uint256 payment) {
    if (gasToken == address(0)) {
	    // ETH로 지급
	    payment = gasUsed.add(baseGas).mul(gasPrice < tx.gasprice ? gasPrice : tx.gasprice);
	    (bool success, ) = receiver.call{value: payment}("");
		} else {
	    // ERC20 토큰으로 지급
	    payment = gasUsed.add(baseGas).mul(gasPrice);
	    require(transferToken(gasToken, receiver, payment));
		}
}

코드를 보면 gasToken 파라미터를 통해 가스비를 환불할 토큰을 지정할 수 있다

• gasToken = address(0)인 경우 refundReceiver에게 ETH로 지급한다.
• gasToken이 다른 주소인 경우 해당 ERC20 토큰으로 지급한다

이런 구조가 어떻게 가능하고 왜 유용할까? 다음 시나리오를 생각해보자

1. Safe Wallet에 1000 DAI 보유 중
2. 릴레이 서비스는 ETH로 트랜잭션 실행에 필요한 가스비를 지불
3. Safe Walet은 이 가스비를 DAI로 환불해준다

이러한 방식이 왜 유용할까?

• 릴레이 서비스는 자신이 선호하는 토큰으로 환불받을 수 있다
• 심지어, Safe가 스테이블코인만 보유하고 있는 상황에서도 문제없다.
• DeFi 프로토콜과의 통합이 더 유연해진다

이러한 유연한 설계 덕분에 Safe는 단순한 멀티시그 지갑을 넘어, 더 복잡한 온체인 시나리오를 가능하게 한다.

매우 간단하게 ‘환불’에 대해서만 설명했지만, 실제로는 revert, gas_used 등을 고려하여 더 다양한 구현이 존재하니, 정확하고 자세하게 알고 싶다면 safe_tx_gas.md 문서를 참고하자

결론

Safe 컨트랙트의 아키텍처와 핵심 동작 방식을 살펴보았다. 간단히 요약하면:

Deploy&Setup

• EIP-1167 Minimal Proxy 패턴을 사용하여 가스비를 절약
• Setup 단계에서 Owner 리스트와 threshold(정족수)를 설정

Safe Transaction

1. Safe TX를 생성하고 필요한 Owner들의 서명을 수집
2. execTransaction을 통해 실행되며, 이때 서명 검증을 거침
3. 검증이 완료되면 실제 트랜잭션(ETH 전송, 컨트랙트 호출, 가스비 환불 등)이 실행

유용한 설계

• Owner가 아닌 제3자(릴레이)도 충분한 서명만 있다면 트랜잭션 실행 가능
• 가스비 환불 메커니즘을 통해 릴레이 서비스 활용 가능
• ETH뿐만 아니라 ERC20 토큰으로도 가스비 지급 가능

이러한 설계를 통해 Safe는 단순한 멀티시그 지갑을 넘어서, DeFi나 DAO와 같은 복잡한 온체인 시나리오에서도 활용될 수 있는 기반을 제공한다.

출처 :

• https://github.com/safe-global/safe-smart-account
• https://app.safe.global/welcome
• https://medium.com/@kyzooghost/four-practical-solidity-patterns-from-gnosis-safe-e8251f90a7ba

[Safe 시리즈]#2 : Safe{Wallet}의 배포와 사용, 기술 분석으로 이해하기 was originally published in CURG on Medium, where people are continuing the conversation by highlighting and responding to this story.

본 글은 정보 제공을 목적으로 작성된 것으로, 투자, 법률, 자문 등 어떠한 분야에서도 책임을 지지 않습니다. 특정 자산에 대한 투자 권유의 의도가 없으며, 본문 내용만을 기반으로 투자 결정을 내리지 마시기 바랍니다.

본 글은 Safe{Wallet} 시리즈의 첫 번째 글로, Safe{Wallet}의 배경과 사용 사례 그리고 개인과 기관의 커스터디를 개괄적으로 다룬다. 다음 편은 Safe{Wallet}의 배포 과정부터 상호작용에 대한 기술적 분석을 다룬다. 글이 서로 연관되어 있으므로, 차례대로 읽어보시는 것을 추천해 드린다.

1편 : [Safe 시리즈]#1 : 스마트 컨트랙트 지갑 Safe{Wallet} 살펴보기

2편 : [Safe 시리즈]#2 : Safe{Wallet}의 배포와 사용, 기술 분석으로 이해하기

안준하 | researcher of CURG | junha.ahn.dev@gmail.com
김상우 | researcher of CURG | 0xhold2018@gmail.com
최현겸 | researcher of CURG | sw.sdy613@gmail.com

목차

1. 배경 — EOA에서 Safe{Wallet}까지
2. Safe, 어디에서 사용되고 있는가?
3. 기관 커스터디
4. 개인 커스터디

1. 배경 — EOA에서 Safe{Wallet}까지

과거 지갑의 한계와 필요성

기존의 외부 소유 계정(EOA, Externally Owned Account)은 간단한 기능과 쉬운 접근성을 제공했으나 몇 가지 중요한 한계를 지녔다. 개인 키나 시드 문구를 분실하면 복구가 불가능해 자산에 대한 접근을 영구히 잃을 위험이 있었으며, 특정 조건에 따른 자동화 기능을 지원하지 못했다. 이는 조건부 결제나 자동 송금 같은 고급 기능의 부재로 이어졌고, 보안 문제를 증폭시키는 원인이 되었다.

2016년 The DAO 해킹 사건은 이러한 보안 문제를 극명히 보여준 사례였다. 이는 DAO, 마켓 메이커, 고액 자산가들에게 복구 메커니즘, 키 분산 관리, 출금 제한 등의 안전 장치를 요구하는 계기가 되었다. 동시에 자동화 시스템과 같은 Web2 수준의 고급 기능에 대한 필요성도 대두되었다.

Safe{Wallet}의 등장

2017년 초 Gnosis의 ICO로 시작된 Safe{Wallet}의 여정은 이러한 요구를 충족시키기 위한 노력으로 시작되었다. ICO 수익을 안전하게 보관할 방법이 필요했던 Gnosis는 Stefan George의 다중 서명 지갑 코드 개발로 이를 해결했다. 이 코드는 Gnosis multisig wallet으로 오픈 소스화되었고, 이후 발전하여 현재의 Safe{Wallet}로 자리 잡게 되었다.

현재 Safe는 약 660억 달러의 자산 규모로 이더리움 생태계 스마트 지갑의 선두를 지키고 있다. 거래 시 다중 서명을 요구하는 보안성 때문에 DAO와 기업, 고액 자산가들이 선호한다. 비수탁형 오픈소스 솔루션인 Safe{Wallet]은 트랜잭션 시뮬레이션, 사용자가 설정 가능한 보안, 소셜 복구 등의 부가적인 기능을 제공한다.

아래는 Safe{Wallet} 사용 영상이다. 지갑의 초기 설정과 배포 등 단계별로 어떻게 진행이 되는지 살펴보도록 하자.

• 각 단계에 대한 상세한 설명은 ‘[Safe 시리즈]#2 : Safe{Wallet}의 배포와 사용, 기술 분석으로 이해하기’ 에서 확인 가능하다.

Safe{Wallet} 계정 생성

Safe{Wallet} 계정을 생성하는 과정은 다음과 같다.

1. 지갑 연결: MetaMask나 WalletConnect를 사용해 개인 지갑을 Safe{Wallet}과 연결한다.
2. 계정 설정: 계정 이름을 지정하고, 배포할 네트워크를 선택한다.
3. 서명자 및 임계값 설정: 서명자 지갑을 설정하고, 트랜잭션 승인에 필요한 최소 서명 수를 지정한다.
4. 검토 및 배포: 설정 내용을 확인한 후 Safe 계정을 블록체인에 배포한다.

이제 Safe 계정을 생성했다면 어디에서 사용할 수 있는지, 그리고 어느 곳에서 Safe를 사용하는지 알아보자.

2. Safe, 어디에서 사용되고 있는가?

Safe의 사용 사례들을 살펴보기 이전에 Safe 계정과 Dapp들을 연결 시 사용하는 WalletConnect와 Safe 인프라 내의 Safe Apps를 사용할 경우를 살펴보도록 하자.

Wallet Connect

사용자가 Safe 계정과 Dapp을 연결할 때, WalletConnect를 통해 연결하여 상호작용을 할 수 있다. 사용자는 QR 코드를 스캔하거나 링크를 통해 지갑과 Dapp을 연결하며, Safe{Wallet} UIUX 내에서 WalletConnect를 이용해 쉽게 연결이 가능하다. 하지만 사용자가 여러 Dapp을 사용한다고 할 때, 각각의 Dapp에 접속하여 QR 코드 스캔이나 링크를 통해 수동 연결하는 과정을 반복해야 한다는 번거로움이 있다.

Safe Apps

하지만 각각의 Dapp 개발자들이 Safe Apps SDK를 통해 그들의 Dapp을 Safe{Wallet}에 통합을 한다면, 사용자가 Safe{Wallet} 인터페이스에서 Dapp과 직접 상호작용을 할 수 있도록 지원이 가능하다. Safe Apps SDK는 Dapp을 HTML iframe 구성 요소로 변환하여 Safe를 통해 접근 가능하게 만드는데, 개발자는 이 SDK를 통해 디자인 시스템, 재사용 가능한 구성 요소, Safe와의 통신을 지원하는 기능 등 다양한 도구를 활용해 Safe Apps를 쉽게 개발, 테스트, 통합할 수 있다.

즉, 여러 Dapp들을 사용할 때, Safe Apps에 통합된 Dapp들의 경우 각 Dapp에 따로 연결할 필요 없이 Safe UIUX 내에서 상호작용이 가능하다. 또한 이러한 앱과 상호작용은 Safe 트랜잭션을 실행하는 것과 동일한 방식으로 진행되며 만약 Safe 계정이 트랜잭션 실행에 여러 서명이 필요하다면, 동일한 요구 사항이 Safe Apps에도 적용된다.

Safe Apps를 통해 사용 가능한 Dapp은 현재 120가지 정도가 되는데 그 중에서 두 가지, Lido와 1inch를 살펴보도록 하자.

1. Lido : Lido는 이더리움과 여러 네트워크에서 유동성 스테이킹(liquid staking)을 제공하는 대표적인 프로토콜이며, 21년 3월부터 Safe (당시 Gnosis Safe) Apps에 추가되어 Safe의 인터페이스에서 바로 상호작용이 가능하게 되었다. Safe Apps를 통해 Safe 트랜잭션 실행으로 다중 서명 기능을 이용한 서명이 가능하다.

2. 1inch : 1inch는 다양한 탈중앙화 거래소(DEX)와 유동성 풀을 비교해 최적화된 거래를 제공하는 DEX 어그리게이터다. 1inch 역시 20년 7월부터 Safe (당시 Gnosis Safe) Apps에 추가되어 통합되었으며, Safe Apps를 통해 사용자는 Safe{Wallet} 환경 내에서 바로 1inch의 기능을 활용할 수 있다.

위 두 가지 사례는 Safe{Wallet} 내에서 Dapp과의 상호작용이 가능하게 통합된 경우로, 사용 편의성과 보안을 동시에 제공하며 Lido와 1inch의 사용자 경험을 한층 더 강화한다.

World App

앞의 경우와는 다르게 World app의 경우, Safe{Wallet} 내에서 Dapp과의 상호작용이 아닌 Safe의 계정 추상화 스택인 Safe{Core}를 기반으로 스마트 계약 지갑을 구현하는 차이점이 있다.

Worldcoin은 디지털 신원을 검증하고 이를 기반으로 암호화폐 생태계를 구축하기 위한 프로젝트로, 주로 생체 데이터를 활용한 고유 ID 검증과 이를 통한 암호화폐 배분 모델로 주목받고 있다.

World app은 Safe의 계정 추상화 스택인 Safe{Core}를 기반으로 스마트 계약 지갑을 구현했다. 따라서 World app에서 개인 증명 ID를 받은 사용자들은 Safe 기반 지갑 계정을 받아 온보딩하게 된다. 아래의 사진에서 확인할 수 있듯 World app에 가입 시 부여받은 World chain 주소를 Worldscan에서 확인 시, Event란에서 ‘SafeSetup’으로 Safe 계정이 배포된 것을 확인할 수 있다. 즉 현재까지 World app을 통해 600만이 넘는 Safe 계정이 배포되었으며, 이를 통해 Worldcoin은 사용자들에게 간단하고 안전한 금융 서비스와 디지털 신원 인증을 제공할 수 있다.

Polymarket

트럼프 베팅으로도 유명한 Polymarket도 World App과 동일하게, 내부적으로는 Safe를 사용하고 있다. 폴리마켓에 지갑을 연결하면 아래와 같은 Deposit USDC 페이지를 확인 가능하다. 해당 주소가 Safe 지갑이고, 해당 Safe 지갑에 USDC를 입금해야 폴리마켓의 다양한 기능(주로 베팅)을 이용 가능하다.

실제로 Polymarket을 이용한 경험이 있는 독자라면, 베팅을 하면서 트랜잭션 수수료(Polygon 체인이기에 POL을 지불)를 신경 쓰지 않았을 것이다. 예를 들어 위 주소로 POL을 입금하라는 안내 메세지는 어디에도 보이지 않는다.

Polymarket은 Safe를 활용하여 가스비 대납 기능을 통해 원활한 사용자 경험을 제공한다. (Multisig외에도 다양한 기능이 존재한다) 이는 Dapp이 서비스가 Safe의 다양한 기능을 활용하여 좋은 사용자 경험을 제공할 수 있는지를 보여주는 좋은 사례이다.

• 가스비 대납은 다음 편 ‘[Safe 시리즈]#2 : Safe{Wallet}의 배포와 사용, 기술 분석으로 이해하기’ 에서 자세한 확인 가능하다.

3. 기관 커스터디

암호화폐 시장이 성숙해짐에 따라 금융 기관, VC, 은행, DAO와 같은 다양한 기관이 이 시장에 적극적으로 참여하고 있다. 이러한 참여는 커스터디 솔루션에 대한 수요를 크게 증가시키고 있다.

기존 커스터디의 문제점

자산의 보안과 운영 유연성 간의 균형을 찾는 것이 가장 큰 고민이다. 막대한 금액이 얽혀 있는 거래에서 보안은 절대적인 필수 조건이다. 동시에, 신속한 투자 결정을 내리고, 효율적으로 자산을 관리하려면 높은 유연성을 확보해야 한다. 이 과정에서 기관이 직면하는 대표적인 문제는 다음과 같다

안전한 인프라의 부재

• 대규모 자산을 다룰 수 있는 온체인 관리 시스템은 대부분 개인 투자자 중심으로 설계되어 있어, 기관의 복잡한 요구를 충족하기엔 한계가 있다.

투명성과 규제 준수

• 글로벌 금융 시장에서 기관은 자산 운영의 투명성을 보장하면서도 각국의 규제 요건을 충족해야 한다. 이중 기준을 충족하는 커스터디 솔루션은 여전히 제한적이다.

권한 관리의 복잡성

• 수십억 달러의 자산이 얽힌 상황에서 의사결정을 내리는 과정은 여러 이해관계자를 포함한다. 이로 인해 발생하는 권한 관리와 서명 절차의 복잡성은 자산 운영의 걸림돌로 작용한다.

결과적으로, 이러한 문제를 해결하지 않고는 기관이 디지털 자산 시장에서 경쟁력을 확보하기 어려운 실정이다. Safe Wallet은 바로 이 점에서 대안으로 떠오르고 있다. Safe는 보안성과 유연성을 동시에 제공하는 솔루션으로, 기관의 복잡한 요구를 충족하며 시장에서 신뢰받는 선택지로 자리 잡고 있다.

Safe 활용 사례

Safe는 온체인 거래와 투자(1kx), 구독 및 카드 결제를 처리하는 자동화 솔루션(Gnosis Pay), 그리고 중앙화와 자체 보관 간 유연성을 제공하는 기관급 관리 솔루션(Cobo Argus), DeFirewall 등 다양한 방식으로 활용되고 있다.

DeFirewall : 안전 인프라 제공

트랜잭션에 잠재된 위험 요소를 감지하지 못하면, 단 한 번의 실수로도 막대한 자산 손실이 발생할 수 있다. 이런 문제를 해결하기 위해 등장한 것이 DeFirewall이다.

DeFirewall은 Safe Wallet과 Redefine의 협업으로 개발된 기술로, 기관 투자자들이 거래를 실행하기 전에 위험 요소를 분석하고 경고함으로써 자산 손실을 예방하도록 돕는다.

Defirewall 기술의 주요 특징과 활용 사례

거래 시뮬레이션

DeFirewall은 거래 실행 전 시뮬레이션을 통해 성공 가능성과 잠재적인 실패 요인을 상세히 분석한다. 예를 들어, 새로운 dApp과의 첫 상호작용에서 예상하지 못한 자산 이동이 발생할 수 있다. 이런 상황에서 DeFirewall은 거래를 실행하기 전에 사용자에게 위험을 경고하고, 이를 회피할 기회를 제공한다.

자동 위험 평가

트랜잭션을 스캔해 악의적인 코드나 의심스러운 동작을 탐지하고, 이를 블랙리스트 규정과 비교하여 평가한다. 한 기관이 새로운 스마트 컨트랙트를 사용하려 할 때, DeFirewall은 트랜잭션을 미리 검토해 해당 컨트랙트의 신뢰성을 판단할 수 있도록 돕는다. 이를 통해, 거래가 승인되기 전에 사용자는 충분한 정보를 얻을 수 있다.

잔액 변화 시각화

사용자는 거래 실행 후 잔액 변화를 명확히 확인할 수 있다. 특정 거래가 의도치 않게 과도한 자산 이동을 초래하는 경우, DeFirewall은 이를 시각적으로 표시해 즉각적인 대응이 가능하도록 한다. 한 DAO는 이 기능을 활용해 매월 수백 건의 트랜잭션에서 잔액 이상을 모니터링하고, 문제를 사전에 해결한 사례를 보고했다.

DeFirewall이 제공하는 신뢰와 투명성

위와 같이 DeFirewall은 dApp 및 스마트 컨트랙트와의 상호작용에서 발생할 수 있는 보안 문제를 사전에 방지한다. 이는 단순한 기술적 도구를 넘어, 기관 투자자들에게 온체인 활동에 대한 신뢰와 투명성을 제공한다. 예를 들어, Phalcon과 같은 기관은 DeFirewall을 통해 매월 10억 달러 이상의 자산을 안전하게 관리하며, 리스크를 최소화하고 있다. DeFirewall은 Safe Wallet의 생태계를 강화하며, 기관 투자자들에게 단순한 거래 도구가 아닌 안전한 온체인 자산 관리의 필수 요소로 자리 잡고 있다. Safe Wallet은 이러한 혁신적인 솔루션으로 온체인 거래의 새로운 기준을 제시하고 있다.

Cobo Argus : 권한관리 복잡성 해결

자산 관리 시장에서 중요한 과제 중 하나는 권한 관리의 유연성이다. 현재 중앙화 거래소의 경우, API Key를 통해 거래 권한과 출금 권한을 분리할 수 있어 펀드매니저에게 거래 기능만을 허용하는 방식으로 자산을 안전하게 운용할 수 있다. 그러나 DeFi 시장에서는 이러한 권한의 수직적 분리가 어려웠다. 기존의 Multisig 솔루션은 동등한 권한을 가진 키의 수평적 분산만을 제공하여, 실제 조직 운영에 필요한 권한의 계층화와 세분화된 접근 제어가 불가능했다.

이러한 문제를 해결하기 위해, 디지털 자산 관리 솔루션을 제공하는 회사인 Cobo에서 개발한 Cobo Argus는 Safe Wallet을 기반으로 한 스마트 컨트랙트 기반의 기관급 디지털 자산 관리 솔루션으로, DeFi 투자 전략을 자동화하고 보안을 강화하며 효율성을 극대화하기 위해 설계되었다. Cobo Argus의 사용자 권한은 역할 기반 접근 제어(Role-Based Access Control, RBAC)로 구성되며, 팀 내 사용자들이 각기 다른 권한과 책임을 가지도록 설정할 수 있다. 이를 통해 협업 효율성을 높이고 자산 관리의 보안을 강화한다.

Cobo의 고객사인 Phalcon Block은 Cobo Argus를 사용하여 체계적인 권한 구조를 구축했다. 특히 Aave 플랫폼에서의 자산 운용과 인출 작업을 안전하게 처리하기 위해 역할 기반 접근 제어(Role-Based Access Control, RBAC)를 효과적으로 활용하고 있다.

Phalcon Block의 관리자는 팀 내에서 최고 권한을 보유하며, 디파이에서 자산을 인출하거나 이동하기 위한 최종 승인 권한을 가진다. 예를 들어, Aave에서 긴급히 자산을 회수해야 하는 상황이 발생하면, 관리자가 이를 신속히 승인하여 자산을 안전한 지갑으로 이동시키는 역할을 수행한다. 전략 관리자는 투자 전략 설계와 실행에 중점을 두며, Yield Farming과 레버리지 조정 같은 반복 작업을 자동화해 자산 운용의 효율성을 높인다.

이러한 권한 체계의 효용성은 2023년 11월 5일 Aave의 긴급 상황에서 입증되었다. 당시 Aave는 화이트햇 해커로부터 심각한 취약점 보고를 받아 프로토콜을 일시 중지해야 했고, 이로 인해 사용자 자산이 동결될 위기에 처했다. Phalcon Block은 Cobo Argus의 권한 관리 시스템을 통해 신속하게 대응할 수 있었다. 리스크 관리자가 위험 신호를 감지하여 즉시 관리자에게 보고했고, 관리자는 신속한 승인을 통해 프로토콜 중지 전에 자산을 안전하게 이동시킬 수 있었다.

이처럼 Phalcon Block의 Cobo Argus 활용 사례는 DeFi 환경에서도 중앙화 거래소 수준의 세분화된 권한 관리가 가능함을 보여준다. 명확한 권한 체계와 신속한 의사결정 구조를 통해 자산 운용의 안정성과 효율성을 동시에 확보할 수 있게 되었다. 현재 Cobo Argus에 대한 기술적 분석은 진행하지 않아 중앙화된 솔루션인지 여부는 확인할 수 없으나, 해외 몇몇 팀들이 이러한 권한 관리 시스템을 순수하게 Smart Contract를 통해, 특히 Safe{Wallet}를 기반하여 구현하기 위한 개발을 진행하고 있다.

4. 개인 커스터디

비탈릭의 Safe Wallet 활용과 셀프 커스터디

비탈릭 부테린(Vitalik Buterin)은 이더리움의 공동 창립자로, 암호화폐 자산의 보안을 강화하기 위해 셀프 커스터디와 Safe Wallet을 적극적으로 활용하고 있다.

다중 서명을 활용한 보안 강화

비탈릭은 자산 보안을 위해 Safe Wallet의 다중 서명(multisig) 기능을 적극적으로 활용한다.

• 다중 서명(multisig) : 자산에 접근하려면 여러 신뢰할 수 있는 ‘Guardian’의 승인이 필요하다. 예를 들어, 비탈릭은 자신의 자산에 대해 3-of-5 Owner 서명 구조를 사용하여 5명 중 3명의 과반수 이상 승인이 있어야 거래가 실행되도록 설정한다.
• 분산 접근 방식: 세계 각지에 신뢰할 수 있는 Guardian를 배치함으로써 한 곳에서 발생하는 문제를 최소화한다(Preventing a single point of failure).이를 통해 물리적 손실과 지역적 리스크를 최소화한다. M-of-N 방식으로, 일부 키는 본인이 보유하되(복구를 막을 만큼 충분한 수는 아님), 나머지는 신뢰할 수 있는 다른 사람들이 보유하도록 설정하라고 한다. 이러한 다른 사람들이 누구인지, 심지어 서로에게도 밝히지 말라고 권장하고 있다.

Guardian 선정의 중요성

Reddit 게시글에서 비탈릭은 Guardian 선정에 대해 다음과 같은 기준을 강조했다:

• 신뢰도: 가족, 친구, 동료 등 충분히 신뢰할 수 있는 사람들을 선정
• 다양성: Guardian들이 서로 모르는 관계이거나, 서로 다른 지역과 배경에서 활동하도록 설정
• 책임감: Guardian과 역할과 절차를 명확히 정의하고 소통하며, 비상 상황에 대한 대비책을 마련

크립토 작업 환경과 셀프 커스터디

작업 환경의 중요성

크립토 활동을 하는 환경 자체도 중요하다는 것을 깨달았다. 온체인 작업은 가능한 한 전용 장비에서 실행하고, 다른 프로그램 실행을 최소화해야 한다. 또한, 커스터디 실행을 위한 철저한 계획이 필요하다. 비탈릭 역시 이러한 원칙을 강조하며, 셀프 커스터디를 위한 환경 설정과 습관의 중요성을 언급했다.

주요 전략

니모닉 백업 방식:

• 니모닉 플레이트를 금고에 보관하거나 다중 저장 방식을 활용

작업 환경:

• 작업 전용 맥(Mac) 환경에서 크립토 관련 작업을 수행하며, 외부 파일 실행을 제한

외부 위협 최소화:

• 전용 장비를 사용하고, 작업 중 불필요한 프로그램 실행을 자제하며, PDF나 exe 파일과 같은 잠재적 위험 요소를 철저히 검증

셀프 커스터디는 자산 관리의 핵심이다. 거래소들이 커스터디 강화를 위해 다양한 노력을 기울이고 있지만, 자산 보호의 최종 책임은 결국 개인에게 있다. Safe Wallet은 이러한 책임을 더 체계적이고 안전하게 관리를 돕는 좋은 툴이다.

하나의 Owner를 하드웨어 렛저로, 다른 Owner를 iOS 모바일 환경으로 설정하거나, Mac 환경에서 온체인 작업을 진행하는 것이 권장된다. 많은 크립토 관련 회사들이 Mac 환경을 표준으로 삼는 이유도 바로 여기에 있다. Safe Wallet은 여러 사용자나 디바이스를 통해 접근 권한을 분산시키는 구조를 가지고 있어, 자산 관리를 더욱 안전하고 효율적으로 수행할 수 있다.

결국 중요한 것은 책임감 있는 관리 습관이다. 자산을 스스로 지키고, 체계적으로 관리하며, 함께 안전한 크립토 생태계를 만들어 나가보자.

맺으며

이번 리서치에서는 Safe{Wallet}의 배경과 사용 사례, 그리고 기관과 개인의 커스터디와 관련된 내용을 다루었다. 다음 편에서는 Safe{Wallet}의 계정 배포 과정부터 상호작용까지의 기술적 분석을 심층적으로 탐구할 예정이다. Safe{Wallet}의 기술적 분석에 대해 더 자세히 알아보고자 한다면, 시리즈의 다음 편에서 자세히 알아 보자.

출처 :

• https://safe.global/blog/history-of-safe
• https://safe.global/blog/safe-wallet-top-10-safe-apps
• https://safe.mirror.xyz/rInLWZwD_sf7enjoFerj6FIzCYmVMGrrV8Nhg4THdwI
• https://blocksec.com/blog/as-an-lp-how-to-withdraw-funds-timely-before-protocol-pauses
• https://blocksec.com/phalcon
• https://x.com/cobo_global
• https://www.cobo.com/post/lp-withdraw-funds-before-protocol-pauses
• https://shop.ledger.com/products/ledger-nano-x/btc-orange
• https://x.com/VitalikButerin/status/1785562273433387320
• https://vitalik.eth.limo/general/2024/12/03/wallets.html

[Safe 시리즈]#1 : 스마트 컨트랙트 지갑 Safe{Wallet} 살펴보기 was originally published in CURG on Medium, where people are continuing the conversation by highlighting and responding to this story.

• Author: XRPL Korea & 박세준, 남민우
• Review: Jake Ku

본 글은 단순 정보 제공을 위해 작성 되었고 투자, 법률, 자문 등 어떤 부분에서도 책임을 지지 않습니다. 특정 자산에 대한 투자를 추천하는 것이 아님을 밝히며, 본문의 내용만을 바탕으로 투자에 대한 의사결정을 내리지 마십시오.

이 글은 기존에 업로드한 XRPL SERIES_01 XRPL AA Wallet Project에 이어지는 글입니다.

목차

1. INTRO
2. Account Abstraction Infra on XRPL EVM Sidechain
3. Account Abstraction Infra 주요 구성요소 소개
4. Account Abstraction Infra 주요 구성요소 개발
5. Bundler 서버 도입기
6. OUTRO

Abstract

이 프로젝트는 XRPL EVM Sidechain에서 계정 추상화(AA) 인프라 구현을 통해 블록체인 서비스 통합 시 발생하는 문제들을 해결하는 데 중점을 두고 있습니다. 특히, 높은 가스비, 이벤트 로깅 불가, 계약 배포 후 퍼블리싱 문제 등과 같은 이슈들을 해결하며, 사용자가 지갑 생성과 트랜잭션 처리를 간소화할 수 있도록 지원하는 것을 목표로 합니다.

이 글에서는 XRPL EVM Sidechain에서 AA 인프라를 배포할 때 고려해야 할 기술적 측면과 주요 이슈들을 다루며, 이를 통해 사용자 경험을 향상시키고 XRPL EVM Sidechain의 잠재력을 증명하고자 합니다. 궁극적으로 이 프로젝트는 블록체인 상호작용의 복잡성을 줄이고, 더 나은 사용자 경험을 제공하는 데 기여할 것입니다.

1. INTRO

XRPL은 넓은 사용자 기반을 보유하고 있음에도 불구하고, 실제 활용도가 낮다는 문제를 안고 있습니다. 복잡한 블록체인 서비스는 일반 사용자에게 진입 장벽이 되며, 이는 XRPL뿐만 아니라 DApp 개발자들도 해결해야 할 주요 과제로 여겨지고 있습니다. 이를 해결하기 위해, 최근 EVM 생태계에서는 pump.fun 같은 DApp들이 오프체인 처리 방식을 도입하여 사용자 경험(UX)을 개선하고 있습니다.

이러한 배경에서 XRPL EVM Sidechain의 등장은 매우 의미가 큽니다. 이 Sidechain은 EVM과의 호환성을 제공하면서도 높은 TPS와 낮은 수수료를 기반으로 한 최적의 블록체인 서비스 개발 환경을 제공합니다. 그러나 호환성만으로는 모든 문제를 해결할 수 없으며, 각 블록체인마다 클라이언트 환경의 차이가 존재합니다. 특히, 높은 가스비와 같은 이슈로 논란이 된 지갑 추상화(AA) 기능을 도입할 때는 신중한 접근이 필요합니다.

이제 XRPL EVM Sidechain에서 고도화된 블록체인 서비스를 구현할 때 주목해야 할 주요 포인트들을 살펴보겠습니다. 이 가이드는 개발자들이 XRPL의 광대한 사용자 기반을 효과적으로 활용하면서도, 안정적이고 효율적인 DApp을 구축하는 데 도움이 될 것입니다.

가장 중요한 첫 단계는 서명과 지갑 생성 과정을 간소화하는 것입니다. 이러한 접근은 새로운 사용자들의 진입 장벽을 낮추고, 기존 사용자들의 경험을 향상시키는 데 필수적인 역할을 할 것입니다.

ㅤ

2. Account Abstraction Infra on XRPL EVM Sidechain

이 프로젝트는 이더리움 생태계에서 발생하는 불편함을 해결하면서도, 하드포크 없이 계정 추상화(Account Abstraction, AA) 인프라를 구축하는 것을 목표로 하고 있습니다. 계정 추상화는 복잡한 블록체인 상호작용을 간소화하고, 사용자 경험(UX)을 크게 향상시킬 수 있는 중요한 기술입니다.

_

이번 프로젝트의 핵심 목표는, 가스비 문제로 악명이 높은 Account Abstraction Infra를 XRPL EVM Sidechain에서 구현해보고, 이를 통해 XRPL 생태계에 기여할 수 있는 가능성을 확인하는 것이었습니다. 이를 위해, Entrypoint 컨트랙트, Simple Account Factory, Simple Account, 그리고 Bundler를 포크하여 테스트를 진행했습니다. 이 과정에서 다음과 같은 목표를 설정했습니다:

1. Entrypoint 및 번들러 구현 기록:
   XRPL Sidechain에서 어떻게 구현했는지에 대한 기록 작성.
2. EVM 개발 시 고려사항 파악:
   새로운 EVM 환경에서 개발 시 주의해야 할 주요 포인트 탐색.
3. Account Abstraction Infrastructure 구현 시 장단점 분석:
   XRPL EVM Sidechain에서 지갑 추상화 구현 과정에서 느낀 장점과 한계점 분석.

_

이제 XRPL EVM sidechain 에서 Account Abstraction Infrastructure를 구현하는 단계와 그 과정에서 마주한 기술적 도전 과제를 소개하고자 합니다.

이 글은 Hardhat을 이용해 컨트랙트 배포 및 테스트를 진행한 경험을 바탕으로 작성되었으며, 인피니티즘의 Git을 포크하여 개발 테스트 목적으로 실행한 내용을 다루고 있습니다. 실제 라이브 환경이 아닌 테스트 환경에서 수행된 작업임을 참고하시기 바랍니다. 현재 지갑 추상화는 v0.7.0까지 업데이트된 상태지만, 이 글은 v0.6.0을 기준으로 작성되었습니다.

_

XRPL EVM sidechain은 기존 EVM에서 사용하던 코드와 환경을 그대로 사용할 수 있다는 큰 장점을 가지고 있습니다. 이는 현재도 계속해서 업데이트 중이며, 이더리움 창시자인 비탈릭 부테린이 주도하는 지갑 추상화를 XRPL EVM sidechain 에서 실험할 수 있다는 점에서 그 의미가 큽니다.

그렇다면 실제로 이 인프라를 얼마나 쉽게 도입할 수 있을지, 그리고 도입 과정에서 맞닥뜨린 주요 한계점은 무엇인지 살펴보겠습니다. 먼저 개발 과정에서 다뤘던 주요 내용들을 설명하기 전에, 핵심 구성 요소들에 대해 알아보겠습니다.

ㅤ

3. Account Abstraction Infra 주요 구성요소 소개

지갑 추상화를 구현하기 위해서는 다음과 같은 요소들이 필요합니다:

스마트 컨트랙트 및 번들러 서버(Bundler Server) 그리고 외부 지갑(EOA):

• 엔트리포인트(Entrypoint) 컨트랙트,
  스마트 월렛(Smart Wallet) 컨트랙트,
  스마트 월렛 팩토리(Smart Wallet Factory) 컨트랙트
• UserOps 전송을 위한 충분한 자산을 보유하고 엔트리포인트(Entrypoint)에 예치된 상태의 번들러 서버(Bundler Server)
• 유저가 UserOps 및 컨트랙트 배포를 전송할 수 있는 외부 지갑(EOA)

각 요소에 대해 간단히 설명하자면 다음과 같습니다:

• 엔트리포인트(Entrypoint) 컨트랙트는 지갑 추상화 인프라의 ‘치안 담당관’과 같은 역할을 합니다. 이 컨트랙트는 서비스가 유저로부터 서명 구조체를 받아 서명을 탈취하거나 악용할 수 있는 경우를 방지하는 중계기 역할을 합니다.
• 스마트 월렛 팩토리(Smart Wallet Factory)와 스마트 월렛(Smart Wallet)은 유저들이 지갑 추상화 인프라를 쉽게 이용할 수 있도록 돕는 도구입니다. 이는 마치 스마트폰으로 다양한 앱을 손쉽게 사용하는 것처럼, 지갑 추상화가 적용된 블록체인 서비스를 편리하게 이용할 수 있게 해줍니다.
• 번들러 서버(Bundler Server)는 지갑 추상화 인프라의 ‘교통 인프라’와 같은 역할을 합니다. 이 번들러 서버(Bundler Server)는 유저가 지갑 추상화 서비스를 더 원활하게 사용할 수 있도록 도와줍니다.
• UserOps는 지갑 추상화 인프라의 표준으로, 이를 준수하지 않으면 지갑 추상화 서비스를 이용할 수 없습니다.

ㅤ

4. Account Abstraction Infra 주요 구성요소 개발

4.1 GitHub 레포지토리 포크 및 클론

지갑 추상화 인프라를 구현하기 위해, 아래 링크에서 각각의 GitHub 레포지토리를 포크또는 클론하여 개발을 시작하세요:

• Smart Contract GitHub: Smart Contract Repository
• Bundler GitHub: Bundler Repository

ㅤ

4.2 테스트용 EOA 설정 및 Faucet 수령

테스트를 위해 두 개의 EOA(외부 지갑)에 Faucet을 받아야 합니다:

1. 배포 및 번들러용 EOA
2. 트랜잭션 용 EOA

Faucet을 받는 방법은 XRPL Sidechain 공식 홈페이지의 Faucet Guide를 참고하세요.

ㅤ

4.3 UserOps와 가스비 설정

지갑 추상화 인프라 개발과 테스트에서 중요한 부분 중 하나는 UserOps입니다.

여기서 유심히 살펴봐야 할 것은 maxPriorityFeePerGas로, 이는 EIP-1559에 따라 설정된 체인의 baseFee보다 높아야 트랜잭션이 성공할 수 있습니다.

ㅤ

4.4 엔트리포인트(Entrypoint) 도입 과정

엔트리포인트(Entrypoint)는 ERC-4337의 핵심 요소 중 하나로, User Operation의 검증 및 실행을 담당하는 스마트 컨트랙트입니다. 모든 User Operation은 이 엔트리포인트(Entrypoint)를 통해 처리됩니다.

엔트리포인트(Entrypoint) 도입 과정은 XRPL EVM Sidechain에 맞는 01 네트워크 세팅, 02 배포 과정 순서로 진행됩니다.

_

01 네트워크 세팅

먼저 인피니티즘의 Account-Abstraction 리포지토리를 포크한 후, 해당 리포의 Hardhat 설정을 XRPL EVM Sidechain에 맞춰 설정합니다. 편의성을 위해 mnemonic 구문을 그대로 사용할 수 있지만, 번들러를 새로 구축할 경우에는 환경 변수로 설정하는 것이 좋습니다.

_

02 배포

배포 스크립트를 통해 각 컨트랙트를 배포할 때 사용하는 부분을 간단히 알아보겠습니다:

02-1 엔트리포인트(Entrypoint) 컨트랙트

이 컨트랙트는 CREATE2 OPCODE를 사용하여 배포됩니다. CREATE2는 오프체인에서 미리 검증할 수 있기 때문에 더 안전하게 사용됩니다. CREATE2에 대한 자세한 내용은 여기를 참고하십시오.

02-2 SimpleAccountFactory 컨트랙트

Account Factory 컨트랙트는 엔트리포인트(Entrypoint) 컨트랙트의 주소를 인자로 받아, 지갑 생성 시 해당 주소로 UserOp를 검증하고 지갑을 생성하는 역할을 합니다.

배포 후, 터미널에서 배포된 모습을 확인하고 관련 파일들이 xrplEvmSideChain에 생성된 것을 확인할 수 있습니다.

ㅤ

4.5 엔트리포인트(Entrypoint) 컨트랙트 테스트

엔트리포인트(Entrypoint) 컨트랙트는 정상적으로 작동하기 위해 여러 테스트가 필요합니다. 기존에 검증된 코드라도 새로운 체인에 배포할 때는 동일하게 작동하는지 확인해야 합니다.

테스트 시 확인해야 할 주요 사항:

• 페이마스터(Paymaster)가 있을 때와 없을 때 모두 정상적으로 작동하는가?
• 엔트리포인트(Entrypoint)와의 시뮬레이션이 제대로 작동하는가?
• XRPL EVM sidechain에서 이벤트 로깅이 잘 이루어지는가?

이를 위해 Hardhat의 포크 기능을 사용하여 XRPL EVM Sidechain을 로컬 노드에서 실행합니다.

로컬 노드의 주소 http://127.0.0.1:8545/를 hardhat.config.ts의 네트워크 설정에 추가합니다.

이후 yarn test-dev스크립트를 실행하면 테스트 결과를 얻을 수 있습니다.

ㅤ

4.6 테스트 결과 및 주요 실패 사례

총 125개의 테스트 중 대부분은 통과했지만, 6개의 테스트는 XRPL EVM Sidechain에서 실패했습니다. 주요 실패 이유는 다음과 같습니다:

1. DepositPaymaster의 엔트리포인트(Entrypoint)에서 handleOps 로그를 가져오는 과정에서, maximum [from, to] blocks distance: 10000 에러로 인해 실패.
2. Gnosis Proxy 테스트에서 현재 지갑 관리 내역을 가져오는 과정에서, 동일한 maximum [from, to] blocks distance: 10000 에러로 인해 실패.

엔트리포인트(Entrypoint) 컨트랙트의 사용 로그는 여기에서 확인할 수 있습니다.

4.7 한계점

두 테스트는 모두 블록 범위를 초과한 데이터를 가져오는 과정에서 실패했으며, 이는 퍼블릭 RPC에서 한 번에 많은 블록 데이터를 처리하지 못하기 때문으로 보입니다. I/O 비용이나 데이터 처리 범위가 제한되어 발생한 문제일 가능성이 큽니다. 현재 devnet 단계에서는 많은 블록을 한 번에 불러오는 것을 피하는 것이 좋습니다.

또한, XRPL EVM Sidechain은 이더스캔 API를 지원하지 않아 코드 검증 및 퍼블리싱 과정이 제한적입니다. 이는 향후 개선될 여지가 있으며, XRPL EVM Sidechain Explorer에서 다른 API 지원이 가능한 것으로 보이지만, 사용 방법이 상이하여 적용하지 못했습니다.

정리하자면,

1. 퍼블릭 RPC에서 이벤트 로그를 한 번에 많이 가져오는 것이 불가능하며, 이를 해결하기 위해서는 아카이브 노드를 제공하는 RPC 제공자의 엔드포인트를 사용해야 합니다.
2. 이더스캔 API를 지원하지 않아 코드 검증과 공개가 어려운 상황이며, 이를 대체할 수 있는 XRPL EVM Sidechain Explorer의 활용도 제한적입니다.

위 테스트를 통해 UserOps의 검증과 가스비 설정이 정상적으로 작동함을 확인했다면, 이제 번들러(Bundler) 구축을 통해 지갑 추상화 인프라의 다음 단계를 진행할 수 있습니다.

5. Bundler 서버 도입기

_

Bundler는 ERC-4337의 또 다른 주요 구성 요소로, 사용자가 보낸 User Operation을 수집하여 EntryPoint에 제출하는 역할을 합니다. Bundler 도입 과정은 다음과 같습니다.

1. 충전:
   가스비 대납을 위한 번들러용 EOA 자산 충전, 그리고 유저 역할을 하는 EOA의 자산 충전.
2. 설정:
   XRPL-EVM-Sidechain의 환경에 맞는 가스비 설정 및 RPC 설정.
3. 테스트:
   번들러 테스트 (페이마스터 없는 상태로)

*유의사항

번들러에 설정된 EOA에 충분한 자산을 충전해야 하며, 자산을 충전한 이후에는 엔트리포인트 컨트랙트에 악의적인 번들러가 아님을 증명하기 위한 충분한 자산을 예치해야 합니다. 만약 번들러 서버를 구축했으나 엔트리포인트에 자산을 예치하지 않았다면, 서버를 구축해도 UserOps를 엔트리포인트에 보내지 못합니다. 그 결과, 엔트리포인트 컨트랙트는 해당 번들러를 악의적인 사용자로 판단하여 실행을 막아버립니다.

_

01 충전: EOA(번들러, 유저) 자산 충전

번들러 실행을 위해 계정을 만들고 새로운 계정에 자산을 충전 및 대납, 그리고 새롭게 만들어진 계정 대신 서명하는 계정이 필요합니다.

그러므로 두개의 EOA가 필요합니다.

• 번들러 EOA
• 서명을 위한 유저 EOA

각각의 자산을 Faucet 받기 위해 XRPL EVM Sidechain Faucet Guide를 참고하자.

이 후 서명을 위한 EOA의 menmonic을 따로 저장하여 놓아야합니다.
필자의 경우 localconfig/mnemonic2.txt에 저장을 하였습니다.

_

02 설정: 가스비 및 RPC

localconfig의 bundler.config.json 파일에서 XRPL EVM Sidechain의 RPC 주소를 넣어 사용하고, 위에서 배포한 엔트리포인트 컨트랙트 주소와 수익을 쌓을 외부 지갑 주소를 설정합니다.

XRPL EVM Sidechain에서 가스비가 많이 드는 UserOps를 보내기 위해서는 gasFactor를 하나씩 올리면서 maxPriorityFeePerGas를 설정하고 테스트를 진행해야 합니다.

_

03 테스트: 번들러 테스트 (페이마스터 없이)

이제 알맞은 gasFactor를 찾기 위해 다음과 같이 테스트를 진행합니다.

1. 입력한 RPC 주소를 사용하여 번들러를 unsafe 모드로 실행합니다.

2. 그 후 runOp.ts를 실행하는 스크립트를 터미널에 입력하여 실행시킨다.

3. 가스비 부족 이슈가 나올 때마다 gasFactor 를 하나씩 올려 준다.

_

04 테스트 결과

UserOps의 이벤트를 가져오는 과정에서 `error: Error: maximum [from, to] blocks distance: 10000` 오류가 발생했습니다.

인피니티즘 번들러에 장착된 Account API SDK에서는 블록 범위를 조정하는 것이 불가능하기 때문에 커스텀하여 진행해야 합니다. 번들러의 트랜잭션 내역은 여기에서 확인할 수 있습니다.

6. OUTRO

_

01 XRPL EVM Sidechain의 미래와 한계점 (정량적인 분석)

• 현재 이더리움 계열의 DeFi (ETH, BSC , BLAST, POLYGON, AVALANCHE) 총 TVL은 $63,359,760,000 이며 XRPL 토큰의 총 시총은 $23,637,235,812 이다.
• 평균적으로 801.5 Gwei의 gas price를 형성하고 있어 매우 높은것을 알 수 있다. 이 점 때문에 평소에 이더리움에 개발하거나 타 EVM에서 개발하던것처럼 진행한다면 가스비 이슈때문에 개발이 늦어 질 수 있다.

_

02 XRPL EVM Sidechain에서 개발하면서 느낀 점 (정성적인 분석)

• 장점: 타 EVM 블록체인보다 빠른 TPS를 자랑하며 XRPL 생태계임에도 불구하고 다른 EVM과 브릿징이 가능하다.
• 한계점:
• RPC Endpoint 를 제공하는 업체가 적어 기존에 개발하던 방식보다 제한된 방식으로 개발해야 한다는점.
• 이더스캔 API 와 다른 EVM에서 사용하는 인프라들을 사용할 수 없어 불편하다.

_

03 결론

이번에 곧 런칭될 XRPL-EVM-Sidechain에서 지갑 추상화 인프라를 처음부터 구축해보며, 같은 EVM이라도 새로운 체인에 동일한 코드를 넣을 때 어떤 부분을 조심해야 하는지에 대해 다뤄보았습니다. 구축하는 데 어려움을 겪었던 번들러를 통해 새로운 EVM 환경에서 개발 시 주의해야 할 점을 논의했습니다. 지갑 추상화를 조금이나마 공부해본 독자라면 이 글을 바탕으로 어려움 없이 Sidechain에 스마트 월렛을 만들어볼 수 있을 것입니다.

이더리움 생태계의 총 TVL이 리플 시총의 세 배에 달하기 때문에, 이더리움 생태계의 사용자들과 리플 생태계의 유동성을 상호작용할 수 있다면 EVM Sidechain의 유용성이 증명될 것입니다.

XRPL뿐만 아니라 모든 블록체인 서비스가 사용하기 어렵기 때문에, 해당 인프라를 도입하여 더 쉬운 DApp이 많이 생기길 바랍니다.

_

이 구축에 대한 자세한 내용에 대해서 연락주시면 상세하게 답변드리겠습니다. 주저하지 말고 문의해 주세요.

Reference

• https://docs.xrplevm.org/docs/evm-sidechain/intro-to-evm-sidechain/
• https://opensource.ripple.com/docs/evm-sidechain/get-started-evm-sidechain
• https://github.com/eth-infinitism
• https://medium.com/r?url=https%3A%2F%2Fgithub.com%2Feth-infinitism%2Faccount-abstraction%2Ftree%2Freleases%2Fv0.6
• https://github.com/eth-infinitism/bundler/tree/ver0.6
• https://explorer.xrplevm.org/address/0x5FF137D4b0FDCD49DcA30c7CF57E578a026d2789

XRPL SERIES_02 XRPL AA Infra Introduction was originally published in CURG on Medium, where people are continuing the conversation by highlighting and responding to this story.

• Author: XRPL Korea & 박세준, 남민우
• Review: Jake Ku

본 글은 단순 정보 제공을 위해 작성 되었고 투자, 법률, 자문 등 어떤 부분에서도 책임을 지지 않습니다. 특정 자산에 대한 투자를 추천하는 것이 아님을 밝히며, 본문의 내용만을 바탕으로 투자에 대한 의사결정을 내리지 마십시오.

이 글은 XRPL SERIES_02 XRPL AA Infra Introduction 이전 글로 개발 배경과 함께 다음편의 글을 이해할 때 필요한 전반적인 개념을 정리한 글입니다.

목차

1. INTRO
2. XRPL EVM Sidechain
3. XRPL EVM Sidechain Bridge
4. Account Abstraction(ERC-4337) Infrastructure
5. XRPL AA Wallet Project 요약 및 정리

Abstract

XRPL AA Wallet Project는 한국의 XRP 보유자들이 겪고 있는 주요 문제를 해결하기 위해 계정추상화(Account Abstraction; AA) 기술을 활용하여 사용자 경험(UX)을 개선하고, 탈중앙화 금융(DeFi) 서비스를 도입하는 것을 목표로 하고 있습니다. 이 프로젝트는 XRPL의 기존 인프라를 기반으로, 상당한 양의 XRP를 보유한 중장년층 장기 투자자들의 요구를 충족시키기 위해 안전하고 직관적인 블록체인 지갑 솔루션을 제공합니다. 또한, 이더리움 가상 머신(EVM) 호환성을 통합하여, 다양한 DeFi 서비스에 대한 접근성을 높이고, XRP의 전반적인 활용도를 크게 향상시킵니다.

01. INTRO

_

XRPL 소개

XRP Ledger(XRPL)는 David Schwartz, Jed McCaleb, 그리고 Arthur Britto가 개발한 퍼블릭 블록체인으로, 글로벌 비즈니스와 개발자들이 문제를 해결하고 가치를 창출하는 데 중점을 두고 있습니다. 10년 이상의 무결점 운영으로 신뢰성을 입증한 XRPL은 간편한 개발 환경, 저렴한 거래 비용, 높은 성능, 그리고 지속 가능성을 자랑합니다.

XRPL의 주요 특징은 다음 세 가지로 요약할 수 있습니다:

1. 분산형 암호화 원장:
   XRP 원장은 P2P 서버 네트워크에 의해 운영되는 분산형 암호화 원장으로, 모든 거래가 탈중앙화된 방식으로 검증됩니다.
2. 고유 노드 목록(UNL):
   신뢰할 수 있는 검증자들에 의해 검증되며, 150개 이상의 노드 중 재단에 의해 선별된 검증자들이 네트워크의 무결성을 유지합니다. UNL 노드의 수는 약 36개를 기준으로 변동할 수 있습니다.
3. 글로벌 결제 프로토콜:
   XRPL은 낮은 비용과 빠른 송금을 지원하며, 기본적으로 스마트 컨트랙트를 사용할 수는 없지만, 게이트웨이를 통해 커스텀 통화 거래가 가능합니다.

ㅤ

한국의 XRPL 현황

전체 보유자의 XRP 평균 보유량은 148,184개로, 개당 약 $0.5라고 가정했을 때, $74,092의 XRP를 보유하고 있습니다. 그리고 XRP 평균 보유기간은 2.83년으로 70% 이상의 사람이 2년 이상의 장기보유자들로 이루어져 있습니다. 실제로 현재 한국 홀더들이 보유한 XRP의 총 시가총액은 약 5조 원에 달하며, 전세계 XRP 생태계에 한국이 기여하는 비율이 약 20%가 되고 있습니다.

이를 통해서 한국의 XRP 보유자들은 많은 량의 XRP를 장기투자의 목적으로 보유하고 있음을 알고 있었고, 또한 시장의 크기가 굉장히 커서 한국의 보유자들을 위한 프로젝트를 진행하는 것이 의미가 있다고 판단하였습니다.

다음으로 한국 XRP 보유자들의 보유 형태입니다. 전체 보유자의 63.5%가 한국 CEX(업비트, 빗썸 etc)으로 보유하고 있음을 알 수 있습니다. 또한 XUMM 같은 크롬 익스텐션 형태의 소프트 월렛이 있었음에도 불구하고, 사용량이 13.8% 로 그리 높지 않았습니다. 이를 통해서 사용자들은 탈중앙성 등의 가치나 세금에서 벗어나는 등의 이익보다는 UX 측면에서의 편의성을 훨씬 선호하거나, 대안적인 저장 방법에 대한 인식 또는 신뢰 부족 문제가 있을 수 있다고 판단하였습니다. 여기서 UX 측면에서 많은 개선을 이뤄낸 프로덕트를 XRPL Foundation 의 검수를 받아 인증을 받고 진행하게 된다면 신뢰 및 홍보, UX 개선 등의 문제를 한번에 해결할 수 있을 것이라 판단하였습니다.

지금 까지는 XRP 보유와 관련된 내용이었다면, 다음으로는 보유자들의 개인적인 특성입니다.

전체 XRP 보유자의 87.9%로 대부분 남성이었고, 평균 나이가 47.86세로 중장년층임을 확인할 수 있었습니다. 이를 통해서 기존의 보유한 현금 등 투자여력이 많은 중장년층이 투자를 많이 하고 있다고 판단하였고, 이러한 페르소나들은 개발적인 지식이 없더라도 편하게 활용가능한 UX 를 선호하고 있다고 판단하였습니다.

전체 보유자의 평균 연봉이 62,470,000 KRW 으로, 2024년 한국 직장인 평균 연봉이 42,140,000 KRW 에 비해 약 48%가 높습니다. 이러한 XRP 보유자들은 평균보다 높은 투자 여력을 가지고 있고, 더 높은 금융 지식과 투자 성향을 가지고 있을 가능성이 큽니다. 또한 합리적이고 효율적인 투자기회에 관심과 실행을 하는 사람으로, DeFi 서비스나 스테이킹 같은 금융 상품에 대해서 관심을 가질 확률이 높다고 판단하였습니다.

ㅤ

XRPL AA Wallet Project 개발 배경 및 목표

저희 서비스의 주요 사용자층인 한국의 XRP 보유자들에 대한 설문조사 결과를 요약해 보면, 다음과 같은 경향성을 확인할 수 있었습니다:

• 중장년층 중심:
  XRP 보유자의 평균 나이는 47.86세로, 대부분이 중장년층에 속합니다. 이 연령대의 사용자들은 기술적인 지식이 없어도 쉽게 사용할 수 있는 편리한 UI와 서비스를 필요로 합니다.
• 긴 보유 기간:
  XRP 보유자의 평균 보유 기간은 2.83년으로, 매우 높은 충성도를 보이며 장기 투자자로서 XRP를 유지하고 있습니다.
• 큰 보유량:
  평균 $74,092 상당의 XRP를 보유하고 있어, 향상된 금융 서비스에 대한 수요가 존재합니다.
• 저조한 스테이킹 서비스 이용률:
  스테이킹 서비스 이용률이 전체의 2.3%에 불과해, XRPL 생태계 내에서 스테이킹 서비스를 도입하고 홍보할 기회가 큽니다.
• 중앙화 거래소(CEX) 선호:
  약 63.5%의 사용자가 중앙화 거래소(CEX)를 통해 XRP를 저장하고 있으며, 이는 사용자들이 편리한 UX를 선호하는 경향을 다시 한번 확인할 수 있었습니다.

이러한 조사 결과를 바탕으로, XRPL AA Wallet Project는 아래와 같은 속성을 반영하여 기획 및 개발되었습니다:

1. 사용자 친화적인 UI 제공:
   기술적인 지식이 없는 중장년층도 쉽게 사용할 수 있는 편리하고 직관적인 UI와 서비스를 제공합니다.
2. 장기 투자자 혜택 극대화:
   장기 투자자들이 더 나은 투자 수익을 얻을 수 있도록 DeFi 서비스와 스테이킹 기능을 제공하여, XRP의 유용성을 극대화하고 보유 기간 동안 더 많은 혜택을 누릴 수 있게 합니다.
3. 고액 보유자를 위한 금융 서비스 제공:
   고액 보유자들에게 높은 수익을 기대할 수 있는 금융 서비스를 제공하기 위해, EVM 기반의 스마트 컨트랙트를 활용한 자산 관리 기능과 맞춤형 금융 서비스를 도입할 필요가 있습니다.
4. 스테이킹 서비스 활성화:
   스테이킹의 장점을 사용자들에게 알리고, 쉽게 접근할 수 있는 스테이킹 기능을 제공함으로써 XRPL 생태계 내에서 더 많은 참여를 유도하고, 추가적인 수익 창출 기회를 제공합니다.
5. 편리한 UX 제공:
   중앙화 거래소(CEX)와 유사한 직관적이고 사용하기 쉬운 인터페이스를 제공하여, 사용자가 익숙한 환경에서 쉽게 이용할 수 있도록 하며, CEX와의 연동을 통해 원활한 사용 경험을 제공합니다.

결국, 중장년층 사용자를 위한 편리한 UI, 장기 투자자를 위한 DeFi 및 스테이킹 기능, 고액 보유자를 위한 맞춤형 금융 서비스, 스테이킹 서비스 도입 및 홍보, 그리고 중앙화 거래소와의 연동을 통해 사용자 편리성을 극대화하는 것이 이 프로젝트의 핵심 목표입니다. 이를 통해 XRP 보유자들의 충성도를 강화하고, XRPL 생태계의 확장을 도모할 수 있을 것으로 기대됩니다.

다음 글에서는 저희 개발 부분에 대해 다루기 전에, XRPL 관련 주요 개념을 먼저 정리할 예정입니다. 이미 알고 계신다면 바로 다음 편으로 넘어가셔도 좋습니다.

02. XRPL EVM Sidechain

_

XRPL EVM Sidechain 소개

XRPL은 2024년 7월 6일 기준으로 시가총액 33조 원을 기록하며 전 세계에서 7번째로 큰 블록체인입니다. 그러나 이러한 규모에 비해 실제 활용도가 낮은 점은 XRPL이 해결해야 할 중요한 과제 중 하나입니다. 복잡한 사용자 경험(UX)을 가진 블록체인 서비스는 일반 사용자에게 큰 진입 장벽이 되며, 이는 XRPL뿐만 아니라 기존의 많은 DApp 개발자들이 해결하려고 노력하는 문제입니다. 최근에는 Vertex Protocol과 pump.fun 같은 DApp들이 오프체인에서 사용자의 트랜잭션을 대신 처리하거나 묶어서 처리하는 방식으로 이러한 문제를 해결하려 하고 있습니다.

XRPL 생태계는 개발이 상대적으로 용이할 수 있지만, 많은 블록체인 개발자들이 EVM 환경에 익숙하다는 점을 고려해야 합니다. 이러한 상황에서 XRPL EVM Sidechain의 등장은 매우 주목할 만합니다. 이 사이드체인은 Ethermint 기반으로 구축되었으며, 높은 TPS(초당 처리 트랜잭션 수)와 낮은 수수료를 제공하면서도 기존의 EVM 생태계 개발 도구를 그대로 활용할 수 있다는 장점을 갖추고 있습니다. Ethermint는 Cosmos SDK와 Tendermint Core 합의 알고리즘을 기반으로 하여 이미 검증된 기술입니다.

이더민트에 대한 자세한 정보는 아래 링크에서 확인할 수 있습니다:
Ethermint: https://github.com/evmos/ethermint

XRPL EVM Sidechain은 이더리움 가상 머신(EVM)과 호환되는 사이드체인으로, XRPL의 기능을 확장하여 다양한 DApp과 스마트 계약을 지원합니다. 이를 통해 XRPL 사용자는 이더리움 생태계와의 상호운용성을 확보하게 됩니다.

이 사이드체인은 Tendermint에서 포크한 Comet BFT 합의 알고리즘을 사용하는 Cosmos SDK 기반의 Ethermint로 만들어졌으며, 초당 1000개의 트랜잭션을 처리할 수 있어 EVM과 완벽히 호환됩니다.

그러나 EVM 호환성만으로는 모든 문제가 해결되지 않습니다. 각 체인별 클라이언트 환경의 차이로 인해 고도화된 서비스를 도입할 때에는 신중한 접근이 필요합니다. 예를 들어, 무분별한 서비스 도입은 트랜잭션 실패를 유발할 수 있습니다. 특히, 높은 가스비로 논란이 되었던 지갑 추상화 기술을 도입할 때는 더욱 주의가 필요합니다.

_

주요 기능 및 장점

XRPL EVM Sidechain의 주요 강점은 XRPL과의 높은 호환성 및 빠른 거래 속도입니다. 이 사이드체인은 XRPL의 기존 인프라를 활용하면서도 이더리움의 스마트 계약 기능을 통합해 사용자에게 더 많은 기능을 효율적으로 제공합니다.

• 높은 호환성:
  XRPL과 완벽하게 통합되어, 기존 XRPL 사용자는 별도의 설정 없이도 새로운 기능을 바로 활용할 수 있습니다.
• 빠른 거래 속도:
  초당 1000개의 트랜잭션을 처리할 수 있어 사용자는 지연 없이 신속한 거래를 경험할 수 있습니다.
• 낮은 거래 비용:
  저렴한 수수료 구조 덕분에 많은 트랜잭션을 저비용으로 처리할 수 있습니다.
• EVM 호환성:
  이더리움 스마트 계약을 실행할 수 있어 다양한 DApp 개발이 가능합니다.

_

곧 메인넷 출시 예정

XRPL EVM Sidechain은 곧 메인넷 출시를 앞두고 있으며, 더 많은 사용자와 개발자들이 이 기능을 활용할 수 있게 될 것입니다. 이는 XRPL 생태계의 확장과 발전에 중요한 전환점이 될 것입니다.

다음으로, XRPL과 EVM 간의 호환성을 더욱 높이기 위해 크로스체인 토큰 전송 기술이 필수적입니다. 이를 위해 사이드체인에서 고려해야 할 주요 요소들에 대해 알아보겠습니다.

ㅤ

03. XRPL EVM sidechain Bridge

_

XRPL EVM sidechain Bridge소개

XRPL EVM sidechain Bridge는 XRP Ledger (XRPL)와 이더리움 가상 머신(EVM) 호환 사이드체인을 연결하는 기술로, 두 블록체인 간 자산 및 데이터를 원활하게 전송할 수 있도록 도와줍니다. 이 브리지는 상호운용성을 크게 강화하여, 사용자가 두 블록체인의 장점을 동시에 활용할 수 있게 설계되었습니다. 이를 통해 XRPL의 빠르고 저렴한 거래 처리 속도와 EVM의 스마트 계약 기능을 결합하여 다양한 응용 프로그램을 개발할 수 있게 됩니다.

_

주요 구성 요소

브리지는 크게 세 가지 주요 구성 요소로 이루어져 있습니다:

1. 브리지 도어(Bridge Door):
   자산 이동의 입구와 출구를 관리하는 스마트 컨트랙트입니다. 자산이 이동하는 시작점과 끝점을 정의하여, 자산이 안전하게 이동될 수 있도록 보장합니다.
2. 위트니스 서버(Witness Server):
   트랜잭션을 검증해 브리지가 안전하고 신뢰할 수 있도록 유지하는 역할을 합니다. 위트니스 서버는 트랜잭션의 정확성을 확인하고 기록하여, 분산된 네트워크 내에서 신뢰성을 확보해 줍니다.
3. 브리지 클라이언트(Bridge Client):
   사용자가 브리지와 쉽게 상호작용할 수 있도록 돕는 직관적인 인터페이스입니다. 이 클라이언트를 통해 사용자는 자산을 간편하게 전송하고, 체인 간 데이터 교환을 쉽게 관리할 수 있습니다. 복잡한 기술 지식 없이도 누구나 쉽게 사용할 수 있도록 설계되었습니다.

_

장점- 상호운용성(Interoperability) 향상

XRPL EVM Sidechain Bridge는 XRPL과 EVM의 장점을 한데 모아, 블록체인 간의 상호운용성을 대폭 향상시킵니다. 이를 통해 사용자는 XRP Ledger의 빠르고 저렴한 트랜잭션 처리와 EVM의 다양한 스마트 계약 기능을 동시에 누릴 수 있습니다. 이는 블록체인 기술의 활용 범위를 넓혀주고, 새로운 혁신적인 서비스와 응용 프로그램 개발을 촉진할 수 있게 합니다.

XRPL과 EVM 생태계를 유기적으로 통합한 이 브리지를 통해, 사용자들은 더 풍부하고 다양해진 블록체인 경험을 할 수 있으며, 탈중앙화된 다양한 서비스와 도구를 쉽게 이용할 수 있게 됩니다.

04. Account Abstraction (ERC-4337) Infrastructure

_

계정추상화(Account Abstraction) 소개

계정추상화(Account Abstraction) 인프라는 EVM 계열 체인에서 사용자의 계정 관리와 거래를 더 안전하고 효율적으로 만들어주는 인프라입니다. 이를 통해 사용자는 더욱 직관적이고 간편하게 블록체인 서비스를 이용할 수 있습니다.

계정추상화(Account Abstraction)는 사용자가 기존의 외부 소유 계정(Externally Owned Accounts, EOA) 대신 스마트 계약 기반의 계정을 사용할 수 있도록 하여, 더 다양한 기능과 보안을 제공합니다. ERC-4337은 이러한 Account Abstraction을 구현하기 위한 표준으로, 블록체인의 근본적인 프로토콜 변경 없이도 계정 추상화를 가능하게 합니다.

_

주요 구성 요소

📌 EntryPoint:
모든 사용자 작업(User Operation)을 검증하고 실행하는 중심 스마트 계약입니다. 모든 거래는 EntryPoint를 통해 처리되며, 보안 및 효율성을 극대화합니다.

📌 Bundler:
사용자의 작업을 수집하고 이를 EntryPoint에 제출하는 역할을 합니다. Bundler는 사용자의 작업을 패키징하고 블록체인에 제출하여 거래가 원활하게 이루어지도록 합니다.

📌 Smart Account (Contract Account):
사용자의 계정을 스마트 계약 형태로 구현한 것입니다. 이는 다중 서명, 소셜 복구, 사용자 정의 검증 로직 등 다양한 기능을 지원할 수 있습니다.

📌 Paymaster:
거래 수수료를 대납해주는 역할을 합니다. 이를 통해 사용자는 특정 토큰으로 거래 수수료를 지불하거나, 앱 내에서 거래 수수료를 스폰서링할 수 있습니다.

📌 Aggregator:
다수의 사용자 서명을 집계하여 검증하는 역할을 합니다. 이는 거래 검증을 효율적으로 처리할 수 있도록 도와줍니다.

_

주요 기능 및 장점

• 유연한 거래 수수료 지불 방식:
  사용자는 이더리움의 네이티브 토큰인 ETH 대신 ERC-20 토큰으로 거래 수수료를 지불할 수 있습니다. 또한, Paymaster 기능을 활용해 수수료를 대신 지불(대납)하거나, 특정 토큰을 사용해 거래 수수료를 결제할 수 있어 더욱 편리한 거래 환경을 제공합니다.
• 다양한 인증 방식 지원:
  기존의 단일 서명 방식 외에도, 다중 서명이나 소셜 로그인 같은 더욱 안전한 인증 방식을 사용할 수 있어 보안이 강화됩니다.
• 개발자 친화성:
  스마트 컨트랙트 계정을 통해 개발자는 더욱 복잡한 거래 논리를 구현할 수 있으며, 이를 통해 사용자들은 보다 향상된 사용자 경험을 누릴 수 있습니다.
• 강화된 탈중앙화 보안:
  사용자 계정을 스마트 컨트랙트로 관리함으로써, 기존 외부 소유 계정(EOA)에서 발생할 수 있는 보안 취약점을 줄이고, 더 안전한 환경을 제공합니다.
• 높은 상호 운용성:
  ERC-4337 표준은 블록체인 프로토콜을 변경하지 않고도 적용 가능하므로, 기존 인프라와의 호환성이 매우 뛰어납니다.

ㅤ

05. XRPL AA Wallet Project 요약 및 정리

XRPL AA Wallet Project는 XRPL의 기존 기능을 확장하고, 사용자 경험을 혁신적으로 개선하기 위해 개발된 종합적인 블록체인 지갑 솔루션입니다. 이 프로젝트는 다음과 같은 주요 목표와 기능을 가지고 있습니다.

_

1. 문제 정의 (Problem)

• 사용자 경험(UX)의 문제:
  현재 XRP 지갑의 생성 및 관리 과정이 복잡하고 불편하여 많은 사용자들이 어려움을 겪고 있습니다.
• EVM 기반 스마트 컨트랙트와의 연계 문제:
  XRPL은 자체적으로 스마트 컨트랙트를 지원하지 않아, EVM 기반의 DeFi 상품 및 서비스와의 연계가 어렵습니다.
• 기회 비용:
  많은 사용자들이 XRP를 오랜 기간 보유만 하고 있으며, 이를 통해 얻을 수 있는 추가적인 이익을 놓치고 있습니다.

_

2. 해결책 (Solution)

Account Abstraction (AA) 기술을 도입하여 이러한 문제를 해결합니다:

• 개선된 UX:
  AA 기술을 통해 사용자는 보다 간편하게 지갑을 생성하고 관리할 수 있습니다.
• 스마트 컨트랙트 연계:
  XRPL과 EVM 기반의 스마트 컨트랙트를 연결하여, DeFi와 같은 다양한 블록체인 서비스를 활용할 수 있게 됩니다.

_

3. 기대 효과 (Impact)

XRPL EVM Sidechain에 Account Abstraction(AA) 기술을 도입하면 사용자 경험(UX), 보안, 상호 운용성, 그리고 DeFi 접근성 측면에서 큰 개선이 기대됩니다. AA 기술을 통해 스마트 컨트랙트를 기반으로 복잡한 거래와 다양한 인증 방식을 지원함으로써 사용자들은 보다 직관적이고 안전한 서비스를 누릴 수 있습니다. 특히 다중 서명과 소셜 로그인 같은 혁신적인 인증 방식은 보안을 강화하면서도 사용의 편리성을 높입니다. 또한, eXRP뿐만 아니라 ERC-20 기반 토큰으로도 거래 수수료를 지불할 수 있는 유연한 수수료 시스템이 도입되어 사용자 선택의 폭이 넓어집니다. 이와 함께 스마트 컨트랙트를 통한 계정 관리로 보안이 한층 강화되어 기존 시스템의 취약점을 보완하고, 탈중앙화 환경에서도 높은 신뢰성을 확보할 수 있습니다. AA 기술은 ERC-4337 표준을 기반으로 Ethereum 생태계와의 상호 운용성을 높여 기존 인프라와 호환성을 유지하며, XRP 보유자들은 스테이킹과 같은 DeFi 상품에 더 쉽게 접근할 수 있게 되어 블록체인 생태계 전반의 확장성을 촉진합니다. 이러한 개선 사항은 더 많은 사용자 유입을 가능하게 하고, XRPL EVM Sidechain의 경쟁력을 높이는 중요한 전환점이 될 것입니다.

_

이번 글에서는 저희가 진행했던 XRPL 최초의 계정추상화(AA; Account Abstraction) 프로젝트인 XRPL AA Wallet Project 에 대한 개괄적인 설명을 드렸습니다. 다음 글에서는 구체적으로 어떠한 개발의 과정을 거쳤는 지 말씀드리겠습니다.

Reference

• Survey results on Korean XRPL holders conducted by XRPL Korea
• https://github.com/evmos/ethermint
• https://xrpl.org/docs/concepts/xrpl-sidechains
• https://xrpl.org/docs/concepts/xrpl-sidechains/cross-chain-bridges
• https://www.erc4337.io/docs

XRPL SERIES_01 XRPL AA Wallet Project was originally published in CURG on Medium, where people are continuing the conversation by highlighting and responding to this story.