ZK API 사용 크레딧: LLM 및 그 이상

다비데 크라피스와 비탈릭 부테린

API 사용량 측정의 핵심 과제는 개인정보 보호 , 보안 및 효율성을 동시에 달성하는 것입니다. 이는 사용자가 매우 민감한 개인 데이터를 제출하는 LLM을 사용한 AI 추론에 특히 중요하지만, 일반적으로 사용량이 많은 모든 디지털 서비스에 적용됩니다. 현재 API 제공업체는 두 가지 차선책 중에서 하나를 선택해야 합니다.

1. Web2 Identity: 인증(이메일/신용카드)을 요구하므로 모든 요청이 실제 신원과 연결되어 심각한 개인정보 유출 및 프로파일링 위험을 초래합니다.
2. 온체인 결제: 요청당 하나의 거래가 필요하므로 속도가 매우 느리고 비용이 많이 들며, 사용자의 전체 거래 내역을 숨기기 어렵습니다.

사용자가 한 번만 자금을 입금하면 수천 번의 API 호출을 익명으로, 안전하게, 효율적으로 수행할 수 있는 시스템이 필요합니다. 서비스 제공자는 지불 보장과 스팸 방지 기능을 확보해야 하며, 사용자는 자신의 요청이 신원이나 다른 사용자와의 연결 고리가 되지 않도록 보장받아야 합니다. 본 논문에서는 LLM 추론을 구체적인 사용 사례로 제시하지만, 이 접근 방식은 일반적이며 RPC 호출이나 기타 고정 비용 API, 이미지 생성, 클라우드 컴퓨팅 서비스, VPN, 데이터 API 이더리움 클래식(ETC) 도 적용할 수 있습니다.

예시:

1. LLM 추론: 사용자가 스마트 계약에 100 USDC를 예치하고 호스팅된 LLM에 500번의 쿼리를 보냅니다. 공급자는 500건의 유효하고 결제된 요청을 수신하지만, 이 요청들을 동일한 예치자(또는 서로)와 링크(Chainlink) 수 없으며, 사용자의 요청 메시지 또한 사용자 신원과 연결되지 않습니다.
2. 이더리움 RPC: 사용자가 10 USDC를 예치하고 이더리움 RPC 노드(예: eth_call / eth_getLogs )에 10,000번의 요청을 보내 지갑, 인덱서 또는 봇을 작동시킵니다. RPC 제공자는 스팸 방지 및 지불 보장 기능을 갖추고 있지만, 이러한 요청을 사용자 프로필에 영구적으로 저장할 수는 없습니다.

제안 개요: 본 제안 에서는 속도 제한 무효화 (RLN)를 활용하여 익명성을 금전적 예치(stake) 과 연동합니다. 프로토콜 제한 내에서 사용하는 정직한 사용자는 연결되지 않지만, 이중 지출(또는 허용된 용량 초과)을 하는 사용자는 암호학적으로 비밀 키를 공개하여 슬래싱 가능해집니다. 본 프로토콜은 API 사용 비용이 가변적인 경우에도 작동하도록 설계되었지만, 특별한 경우로 호출당 고정 비용이 발생하는 간단한 방식도 직접 지원합니다.

저희는 유연한 회계 프로토콜을 사용합니다. 각 요청마다 호출당 최대 비용을 사전에 설정하고, 호출 종료 후 실제 비용이 확정되면 서버에서 환불을 처리합니다. 사용자는 서명된 환불 티켓을 비공개로 누적하여 사용하지 않은 크레딧을 회수하고, 실제 호출당 비용이 실행 후에만 확인되는 경우에도 향후 용량을 확보할 수 있습니다. 이중 스테이킹 메커니즘을 통해 서버는 규정 준수 정책을 시행하는 동시에 공개적으로 책임을 질 수 있습니다.

ZK API 사용 크레딧 프로토콜

이 프로토콜은 서버 환불 과 환불 누적, 그리고 클라이언트 측의 지급 능력 증명을 활용합니다. 이 모델은 사용자가 현재 티켓 인덱스 로 표시되는 누적 지출액이 최초 예치금 및 검증된 환불 내역 범위 내에 있음을 증명하도록 요구함으로써 지급 능력을 보장합니다.

스팸 방지 기능은 경제적인 방식으로 작동합니다. 사용자의 처리량은 사용 가능한 예치금 버퍼에 따라 자연스럽게 제한되며, 특정 티켓 인덱스를 재사용하려는 시도(이중 지출)는 속도 제한 무효화 기능에 의해 방지됩니다.

원시인들

• k k : 사용자의 비밀 키.
• D D : 초기 예치금.
• C_{max} C m a x : 요청당 최대 비용(선불).
• i i : 티켓 인덱스(엄격하게 증가하는 카운터: 0, 1, 2, \dots 0 , 1 , 2 , … ).
• \{r_1, r_2, \dots, r_n\} { r 1 , r 2 , … , r n } : 서버에서 수신한 서명된 환불 티켓의 개인 컬렉션입니다.

프로토콜 흐름

등록
사용자는 비밀 키 k를 생성하고, ID 커밋먼트 ID = 해시(k) ID = Hash ( k ) 를 도출 한 후 , ID 를 스마트 컨트랙트에 예치합니다. 컨트랙트는 ID ID 를 온체인 머클 트리에 삽입합니다.

환불 처리(비동기식)
요청이 처리되면 서버는 서명된 환불 티켓 r = \{v, \text{sig}\} 을 제공 합니다 . 여기서 v 는 환불 금액 이고 \text{sig} 는 서버가 v 에 대해 서명한 값입니다(그리고 경우에 따라 고유한 요청 ID가 포함될 수 있습니다). 사용자는 이러한 정보를 로컬에 저장합니다.

요청 생성(병렬 처리 가능)
사용자는 다음으로 사용 가능한 티켓 인덱스 i 를 선택합니다. 사용자는 여러 요청(예: 티켓 i, i+1, i+2 , i + 1 , i + 2 ) 을 동시에 생성할 수 있습니다.

사용자는 ZK-STARK \pi_{리퀘스트(REQ)} π r e q 를 생성하여 증명합니다.

1. 멤버십: ID \in I D ∈ MerkleRoot.

2. 환불 총액:
   이 회로는 환불 티켓 목록 \{r_1, \dots, r_n\} { r 1 , … , r n }을 비공개 입력으로 받습니다.

   • 티켓 한 장당 회로는 다음과 같습니다.
     • 서버의 서명을 확인합니다.
     • v_j v j 값을 추출합니다.
   • 회로는 합을 계산합니다: R = \sum_{j=1}^{n} v_j R = ∑ n j = 1 v j .

3. 지급능력(신용도 조사): 인덱스 i i 에서의 총 예상 지출액은 예치금과 확인된 모든 환불액의 합계로 충당됩니다.

   (i + 1) \cdot C_{max} \le D + R ( i + 1 ) ⋅ C max ≤ D + R .

4. RLN 공유 및 무효화:

   • 기울기: a = 해시(k, i ) a = Hash ( k , i ) .
   • 신호:
     • x= 해시(M) x = H a s h ( M ) ,
     • y = k + a \cdot x y = k + a ⋅ x .
   • 해시 파이어 : 널리 파이어 = 해시 ( a ) 널리 파이어 = 해시 ( a ) .

제출

사용자가 전송하는 데이터: 페이로드(M) + 널라이저 + 신호(x, y) + 증명.

검증 및 슬래싱
서버는 "소모된 티켓" 데이터베이스에서 널리파이어를 확인합니다.

• 포크(Fork)/이중 지출 검사: nullifier가 다른 x x (메시지)와 함께 존재하는 경우, 사용자가 동일한 티켓을 두 개의 다른 요청에 사용하려고 시도한 것입니다. k k 와 SLASH를 계산하세요.
• 지급능력 확인: 티켓 인덱스 i i가 사용자의 현재 자금 수준에 따라 승인되었는지 확인하기 위해 \pi_{리퀘스트(REQ)} π r e q를 검증합니다.

합의

• 서버가 요청을 실행합니다.
• 환불: 서버는 서명된 환불 티켓 r = (C_{max} - C_{ actual } ) r = ( C max − C actual ) 을 발행 합니다 .
• 사용자가 누적기에 r r을 추가하여 향후 더 높은 티켓 지수를 "잠금 해제"합니다.

서버 측 책임성(듀얼 스테이킹)

단순한 속도 제한을 넘어 API 남용(예: 서비스 약관 위반, 불법 콘텐츠 생성, 탈옥 시도)을 방지하기 위해, 우리는 2차 스테이킹 계층을 도입합니다. 예를 들어, 사용자가 모델에 무기 제작 방법을 요청하거나 보안 제어를 우회하는 방법을 알려달라고 요청할 수 있는데, 이러한 요청은 많은 서비스 제공업체의 사용 정책을 위반하는 것입니다. 우리는 서비스 제공업체가 오탐을 통해 손쉽게 수익을 올리지 않도록 하면서 이러한 정책을 시행할 수 있는 방법을 찾고자 합니다.

구체적으로:

사용자가 총액을 입금합니다. 총액 = D + S T o t a l = D + S .

• D D (RLN 예치(stake)): 프로토콜의 수학적 원리에 따라 관리됩니다. 이중 신호(공개된 비밀 키 k k )에 대한 수학적 증명을 제공하는 사람이라면 누구든지 (서버 포함) 스테이크를 획득할 수 있습니다.
• 정책 예치(stake)( S S ): 서버 정책에 따라 관리됩니다. 사용자가 사용 정책을 위반할 경우 서버에서 지분을 차감(삭감)할 수 있지만, 다시 청구할 수는 없습니다 .

이렇게 하는 목적은 단순히 D D 값을 높이는 대신, 서버가 사용자의 예치금을 부정하게 가져갈 유인을 제거하기 위함입니다. 예치금의 크기에 따라 이러한 부정한 행위의 가능성은 매우 높아질 수 있습니다.

S에 대한 슬래싱 메커니즘

사용자가 정책을 위반하는 유효한 RLN 요청을 제출한 경우(단, 수학적 이중 지출 함정을 유발하지는 않음):

1. 위반: 서버에서 요청 페이로드에서 정책 위반(예: 금지된 콘텐츠)을 감지했습니다.
2. 소각 거래: 서버는 스마트 계약에서 slashPolicyStake() 함수를 호출합니다.
   • 입력: 문제가 된 요청의 Nullifier 와 ViolationEvidence (선택 사항으로 해시/사유 포함).
   • 동작: 계약은 사용자의 예치금에서 S 만큼 을 소각합니다.
   • 제약 조건: 서버는 S S를 스스로 획득 할 수 없으며 , 소각 주소로 전송됩니다. 이는 서버가 이익을 위해 사용자를 허위로 차단하도록 유도하는 것을 방지합니다.
3. 공개적 책임성: 슬래싱 이벤트는 관련 Nullifier 와 함께 온체인에 기록됩니다. 사용자의 신원은 공개되지 않지만, 커뮤니티는 서버가 스테이킹된 스테이킹을 소각하는 속도 와 이러한 소각에 대한 증거를 확인할 수 있습니다.