Tín dụng sử dụng API ZK: LLMs và hơn thế nữa

Davide Crapis và Vitalik Buterin

Một thách thức cốt lõi trong việc đo lường API là đạt được sự riêng tư , bảo mật và hiệu quả cùng một lúc. Điều này đặc biệt quan trọng đối với suy luận AI với LLM, nơi người dùng gửi dữ liệu cá nhân rất nhạy cảm, nhưng cũng áp dụng chung cho bất kỳ dịch vụ kỹ thuật số tần suất cao nào. Hiện tại, các nhà cung cấp API buộc phải lựa chọn giữa hai con đường không tối ưu:

1. Web2 Identity: Yêu cầu xác thực (email/thẻ tín dụng), điều này liên kết mọi yêu cầu với một danh tính thực tế, tạo ra nguy cơ rò rỉ thông tin cá nhân và thu thập thông tin cá nhân rất lớn.
2. Thanh toán on-chain : Yêu cầu một giao dịch cho mỗi yêu cầu, điều này cực kỳ chậm, tốn kém và gây khó khăn trong việc che giấu toàn bộ biểu đồ giao dịch của người dùng.

Chúng ta cần một hệ thống cho phép người dùng nạp tiền một lần và thực hiện hàng nghìn cuộc gọi API một cách ẩn danh, an toàn và hiệu quả . Nhà cung cấp phải được đảm bảo thanh toán và bảo vệ khỏi thư rác, trong khi người dùng phải được đảm bảo rằng các yêu cầu của họ không thể liên kết với danh tính của họ hoặc với nhau. Chúng tôi tập trung vào suy luận LLM như một Use Case điển hình, nhưng phương pháp này mang tính tổng quát và cũng áp dụng cho các cuộc gọi RPC hoặc bất kỳ API có chi phí cố định nào khác, tạo ảnh, dịch vụ điện toán đám mây, VPN, API dữ liệu, ETC

Ví dụ:

1. Suy luận LLM: Một người dùng gửi 100 USDC vào hợp đồng thông minh và thực hiện 500 truy vấn đến máy chủ LLM. Nhà cung cấp nhận được 500 yêu cầu hợp lệ, đã thanh toán nhưng không thể LINK (Chainlink) chúng với cùng một người gửi tiền (hoặc với nhau), trong khi các yêu cầu của người dùng vẫn không thể liên kết với danh tính người dùng.
2. Ethereum RPC: Một người dùng gửi 10 USDC và thực hiện 10.000 yêu cầu đến một node Ethereum RPC (ví dụ: eth_call / eth_getLogs ) để vận hành ví, trình lập chỉ mục hoặc bot. Nhà cung cấp RPC được bảo vệ chống lại thư rác và được đảm bảo thanh toán, nhưng không thể liên kết các yêu cầu thành một hồ sơ người dùng lâu dài.

Tổng quan đề xuất: Chúng tôi tận dụng Bộ vô hiệu hóa giới hạn tỷ lệ (RLN) để ràng buộc tính ẩn danh với một Stake tài chính: người dùng trung thực tuân thủ giới hạn giao thức sẽ không thể bị liên kết, trong khi người dùng chi tiêu gấp đôi (hoặc vượt quá dung lượng cho phép) sẽ tiết lộ khóa bí mật của họ bằng mật mã, cho phép áp dụng Slashing. Chúng tôi thiết kế giao thức để hoạt động khi việc sử dụng API phát sinh chi phí thay đổi, nhưng nó cũng trực tiếp hỗ trợ chi phí cố định đơn giản hơn cho mỗi lần gọi như một trường hợp đặc biệt.

Chúng tôi sử dụng một giao thức kế toán linh hoạt, trong đó mỗi yêu cầu sẽ thiết lập mức chi phí tối đa cho mỗi lần gọi ngay từ đầu, và sau khi chi phí thực tế được xác định vào cuối cuộc gọi, máy chủ sẽ hoàn tiền. Người dùng tích lũy riêng các phiếu hoàn tiền đã ký để lấy lại số tiền tín dụng chưa sử dụng và mở khóa dung lượng trong tương lai, ngay cả khi chi phí thực tế cho mỗi lần gọi chỉ được biết sau khi thực hiện. Cơ chế Dual Staking cho phép máy chủ thực thi các chính sách tuân thủ trong khi vẫn chịu trách nhiệm trước công chúng.

Giao thức tín dụng sử dụng API ZK

Giao thức này sử dụng cơ chế hoàn tiền từ máy chủ kết hợp với tích lũy tiền hoàn lại và bằng chứng về khả năng thanh toán ở phía máy khách. Mô hình này đảm bảo khả năng thanh toán bằng cách yêu cầu người dùng chứng minh rằng tổng chi tiêu của họ — được thể hiện bằng chỉ số vé hiện tại — vẫn nằm trong giới hạn số tiền gửi ban đầu và lịch sử hoàn tiền đã được xác minh của họ.

Cơ chế chống thư rác được thực thi về mặt kinh tế: Xuất lượng của người dùng được giới hạn tự nhiên bởi lượng tiền gửi có sẵn, trong khi mọi nỗ lực tái sử dụng chỉ mục vé cụ thể (chi tiêu kép) đều bị ngăn chặn bởi Bộ vô hiệu hóa giới hạn tỷ lệ.

Nguyên thủy

• k k : Khóa bí mật của người dùng.
• D D : Tiền gửi ban đầu.
• Cmax : Chi phí tối đa cho mỗi yêu cầu (được khấu trừ trước).
• i i : Chỉ số vé (Một bộ đếm tăng dần nghiêm ngặt: 0, 1, 2, . 0 , 1 , 2 , … ).
• \{r_1, r_2, \dots, r_n\} { r 1 , r 2 , … , r n } : Một tập hợp riêng tư các Phiếu Hoàn Tiền đã ký nhận được từ máy chủ.

Luồng giao thức

Sự đăng ký
Người dùng tạo ra bí mật k k , suy ra cam kết danh tính ID = Hash(k) I D = H a s h ( k ) , và gửi D D vào hợp đồng thông minh. Hợp đồng chèn ID I D vào Cây Merkle on-chain .

Thu hồi tiền hoàn trả (Không đồng bộ)
Sau khi yêu cầu được xử lý, Máy chủ sẽ cung cấp một Phiếu hoàn tiền đã ký r = \{v, \text{sig}\} r = { v , sig } , trong đó v là giá trị hoàn tiền và \text{sig} là chữ ký của Máy chủ trên v (và có thể là ID yêu cầu duy nhất). Người dùng lưu trữ các thông tin này cục bộ.

Tạo yêu cầu (có thể xử lý song song)
Người dùng chọn Chỉ số Vé khả dụng tiếp theo i i . Họ có thể tạo nhiều yêu cầu (ví dụ: vé i, i+1, i+2 i , i + 1 , i + 2 ) cùng lúc.

Người dùng tạo ra một chứng minh ZK-STARK \pi_{REQ} π r e q :

1. Thành viên: ID \in I D ∈ MerkleRoot.

2. Tổng số tiền hoàn trả:
   Mạch này nhận danh sách các phiếu hoàn tiền {r_1, \dots, r_n\} { r 1 , … , r n } làm đầu vào riêng.

   • Đối với mỗi vé, lộ trình như sau:
     • Xác minh chữ ký của máy chủ.
     • Trích xuất giá trị v_j v j .
   • Mạch tính tổng: R = \sum_{j=1}^{n} v_j R = ∑ n j = 1 v j .

3. Khả năng thanh toán (Kiểm tra tín dụng): Tổng chi tiêu tiềm năng tại chỉ số i i được đảm bảo bằng tiền đặt cọc cộng với tổng số tiền hoàn trả đã được xác minh:

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

4. RLN Share & Nullifier:

   • Độ dốc: a = Hash(k, i) a = H a s h ( k , i ) .
   • Tín hiệu:
     • x = Hash( M ) x = Hash ( M ) ,
     • y = k + a \cdot x y = k + a ⋅ x .
   • Nullifier: Nullifier = Hash(a) N u l l i f i e r = H a s h ( a ) .

Bài nộp

Người dùng gửi: Tải trọng (M) + Bộ vô hiệu hóa + Tín hiệu (x, y) + Bằng chứng.

Xác minh & Slashing
Máy chủ kiểm tra Nullifier trong cơ sở dữ liệu “Vé đã sử dụng” của nó:

• Kiểm tra Fork/chi tiêu kép: Nếu Nullifier tồn tại với x x khác nhau (Thông báo), người dùng đã cố gắng chi tiêu cùng một vé cho hai yêu cầu khác nhau. Giải quyết tìm k k và dấu gạch chéo.
• Kiểm tra khả năng thanh toán: Xác minh \pi_{REQ} π r e q để đảm bảo chỉ số vé i i được ủy quyền bởi mức tài trợ hiện tại của người dùng.

Khu định cư

• Máy chủ thực thi yêu cầu.
• Hoàn tiền: Máy chủ phát hành Phiếu hoàn tiền đã ký r = (C_{max} - C_{actual}) r = ( C m a x − C a c t u a l ) .
• Người dùng cộng thêm r vào bộ tích lũy của họ để "mở khóa" các chỉ số vé cao hơn để sử dụng trong tương lai.

Trách nhiệm giải trình phía máy chủ ( Staking kép)

Để ngăn chặn việc lạm dụng API vượt quá giới hạn tốc độ đơn giản (ví dụ: vi phạm Điều khoản dịch vụ, tạo nội dung bất hợp pháp hoặc cố gắng bẻ khóa thiết bị), chúng tôi giới thiệu một lớp Staking thứ cấp. Ví dụ, người dùng có thể gửi yêu cầu mô hình tạo hướng dẫn chế tạo vũ khí hoặc giúp họ vượt qua các biện pháp kiểm soát bảo mật – những yêu cầu này sẽ vi phạm chính sách sử dụng của nhiều nhà cung cấp. Chúng tôi muốn có một cách để thực thi các chính sách đó mà không tạo điều kiện cho nhà cung cấp dễ dàng kiếm lợi từ các trường hợp báo động sai.

Cụ thể:

Người dùng gửi tổng số tiền là Tổng = D + S Tổng = D + S .

• D D (RLN Stake): Được điều chỉnh bởi các quy tắc toán học của giao thức. Bất kỳ ai (bao gồm cả Máy chủ) cung cấp bằng chứng toán học về việc báo hiệu kép (bí mật được tiết lộ k k ) đều có thể yêu cầu được nhận.
• S S (Policy Stake): Được quản lý bởi Chính sách Máy chủ. Có thể bị cắt (đốt), nhưng không thể được yêu cầu , bởi Máy chủ nếu người dùng vi phạm các chính sách sử dụng.

Mục đích của việc này, thay vì chỉ đơn giản là đặt D D cao hơn, là để loại bỏ động cơ của máy chủ trong việc gian lận chiếm đoạt tiền gửi của người dùng, điều này có thể dẫn đến khoản tiền gửi rất lớn tùy thuộc vào số tiền gửi.

Cơ chế Slashing cho S

Nếu người dùng gửi yêu cầu RLN hợp lệ nhưng vi phạm chính sách (nhưng không kích hoạt bẫy chi tiêu kép về mặt toán học):

1. Vi phạm: Máy chủ phát hiện vi phạm chính sách trong dữ liệu yêu cầu (ví dụ: nội dung bị cấm).
2. Giao dịch đốt: Máy chủ gọi hàm slashPolicyStake() trên hợp đồng thông minh.
   • Đầu vào: Nullifier của yêu cầu vi phạm và Bằng ViolationEvidence ( Hash/lý do tùy chọn).
   • Hành động: Hợp đồng sẽ trừ số tiền S từ tài khoản của người dùng.
   • Ràng buộc: Máy chủ không thể tự nhận S S , nó được gửi đến một địa chỉ dùng để đốt. Điều này ngăn máy chủ bị khuyến khích cấm người dùng một cách sai trái để kiếm lợi nhuận.
3. Trách nhiệm giải trình công khai: Sự kiện Slashing được ghi lại on-chain với Nullifier liên quan. Mặc dù danh tính người dùng vẫn được giữ kín, cộng đồng có thể kiểm tra tốc độ máy chủ đốt tiền đặt cược và bằng chứng được đăng tải cho các lần đốt này.