Vấn đề
Các giao thức DeFi không thể tối ưu hóa các tham số nếu không có các giả định về độ tin cậy. Họ hoặc trả hàng triệu đô la mỗi năm cho các nhà tư vấn như Gauntlet, hoặc giữ nguyên các tham số tĩnh khiến tiền không được sử dụng. Con số này rất đáng kể—các LP Uniswap V3 mất hàng trăm triệu đô la do quản lý phạm vi kém, các giao thức cho vay duy trì các tham số bảo thủ không cần thiết.
Giải pháp hiển nhiên là chạy các thuật toán tối ưu hóa on-chain, nhưng điều đó không khả thi. LLM và mạng nơ-ron nhân tạo đòi hỏi các phép toán ma trận dấu chấm động, hàng gigabyte bộ nhớ và lấy mẫu không xác định. Ngay cả các mô hình đơn giản cũng tốn hàng triệu đô la gas.
Một con đường khác: Lập trình di truyền trong zero-knowledge
Tôi đang xây dựng một zkVM cho PUSH3 , một ngôn ngữ lập trình dựa trên stack được thiết kế cho lập trình di truyền. Ý tưởng rất đơn giản:
- Các trình tối ưu hóa phát triển các thuật toán Ngoài chuỗi bằng cách sử dụng các kỹ thuật lập trình di truyền tiêu chuẩn
- Khi một giao thức cần tối ưu hóa, thuật toán sẽ chạy trong zkVM
- Giao thức này có kết quả với bằng chứng STARK về việc thực hiện đúng
Thuật toán di truyền có hiệu quả ở đây vì chúng chỉ là các phép toán số học trên ngăn xếp—không có ma trận, không có sự phức tạp của dấu chấm động, chỉ là phép toán số nguyên ánh xạ rõ ràng tới các mạch số học.
Phương pháp tiếp cận kỹ thuật
Ngôn ngữ PUSH3
PUSH3 là một ngôn ngữ ngăn xếp đơn giản với các ngăn xếp riêng biệt cho các kiểu dữ liệu khác nhau (INTEGER, FLOAT, BOOLEAN, CODE, EXEC, NAME). Chương trình chỉ là một chuỗi các phép toán và giá trị thực. Nếu một phép toán không có đủ đối số trên ngăn xếp, nó sẽ trở thành no-op thay vì bị sập.
Chương trình ví dụ:
( PRICE VOLATILITY FLOAT.* 2.0 FLOAT./RANGE.MIN FLOAT.- RANGE.MAX FLOAT.+ )Triển khai zkVM
Việc triển khai sẽ sử dụng các chương trình PUSH3 và tạo ra bằng chứng STARK về việc thực thi chúng bằng OpenVM :
PUSH3 Program → Trace Recording → OpenVM Chips → STARK ProofViệc tạo bằng chứng mất khoảng 2 phút và tạo ra các bằng chứng có dung lượng ~500KB. Các bằng chứng này sau đó có thể được tổng hợp thành STARK để gửi lên chuỗi.
Tình trạng hiện tại
Đang làm việc:
- Số học cơ bản (ADD, SUB, MUL, DIV) trên các ngăn xếp INTEGER/FLOAT/BOOLEAN
- Ghi lại dấu vết đưa vào OpenVM
- Tạo bằng chứng STARK bằng Plonky3
Chưa được triển khai:
- Các ngăn xếp CODE/EXEC/NAME (cần thiết cho lập trình di truyền thực tế)
- Hầu hết các thao tác ngăn xếp (DUP, YANK, SHOVE)
- Kiểm soát hoạt động luồng
Tầm nhìn
Nếu điều này được xây dựng thành một bản tổng hợp, Ethereum sẽ đạt được điều thú vị: bất kỳ giao thức nào có thể xác định hàm phù hợp đều có thể phát triển các thuật toán tối ưu hóa riêng của nó.
Tôi hình dung ra những hiệu ứng sau:
- AMM phát triển Fee Tiers và phạm vi thanh khoản tập trung
- Các giao thức cho vay phát triển các thông số rủi ro và đường cong lãi suất
- Giao thức tùy chọn phát triển các mô hình định giá
- Bảo vệ MEV phát triển các chiến lược đối phó
Không cần tin tưởng bất kỳ ai—chỉ cần toán học chứng minh thuật toán chạy đúng.
Một hướng phát triển khả thi: hoàn thiện zkVM, sau đó khám phá việc triển khai dưới dạng một bản tổng hợp dựa on-chain.
Vấn đề không phải là thay thế khả năng phán đoán của con người hay xây dựng AGI. Vấn đề là cung cấp cho Ethereum khả năng tối ưu hóa tự nhiên mà không cần sự tin tưởng. Các chuỗi khác đang bổ sung bộ đồng xử lý AI và Oracles LLM — Ethereum có thể có thứ gì đó thực sự hoạt động on-chain.
Lựa chọn câu hỏi mở
- Liệu các chương trình PUSH3 đã phát triển có đủ sức biểu đạt để tối ưu hóa DeFi thực sự không? Lập trình di truyền có thể khám phá ra những giải pháp đáng kinh ngạc, nhưng liệu một ngôn ngữ lập trình dựa trên stack có thực sự mã hóa được các chiến lược phức tạp cần thiết cho những việc như định vị thanh khoản tập trung hay quản lý rủi ro đa tài sản hay không?
- Lợi ích-chi phí thực tế ở đây là gì? Việc tạo ra bằng chứng STARK cho mỗi lần tối ưu hóa sẽ làm tăng chi phí chung. Đối với các tham số được cập nhật thường xuyên, liệu chi phí gas cho việc xác minh có xứng đáng với sự thiếu tin cậy không? Nhất là khi bản thân thuật toán có thể khá tầm thường?
- Bạn xử lý dữ liệu đầu vào của thuật toán như thế nào? Tối ưu hóa DeFi cần nguồn cấp dữ liệu giá, dữ liệu Tổng giá trị khóa (TVL) , biến động lịch sử—liệu mỗi nguồn dữ liệu có cần zkVM riêng không?
bộ chuyển đổi? - Làm thế nào để ngăn chặn việc quá khớp? Một thuật toán được phát triển dựa trên dữ liệu lịch sử có thể trông hoàn hảo nhưng lại thất bại thảm hại trong điều kiện thị trường mới.
- Liệu tối ưu hóa Không cần tin cậy có thực sự có giá trị nếu bạn vẫn cần tin tưởng vào thiết kế hàm phù hợp? Các hàm phù hợp kém có thể còn tệ hơn cả hàm tĩnh?
các tham số. - Bạn có thể đạt được kết quả tương tự với các thuật toán tối ưu hóa xác định dễ xác minh hơn không?
