Một hệ thống tổng hợp chuyên dụng với lớp thực thi không dựa trên EVM để điều phối tài chính.

Chào mọi người, tôi viết bài này để đề xuất một thiết kế tổng hợp nhằm mục đích điều phối tài chính.
DeFi đã trưởng thành đáng kể kể từ khi Ethereum ra đời, và khái niệm tài chính lập trình được đã trở thành hiện thực. Mặc dù vậy, không phải lúc nào mọi việc cũng suôn sẻ, hậu quả là các vụ tấn công mạng, gây thiệt hại hàng tỷ đô la. Giải pháp được đưa ra là tăng cường kiểm toán và cải thiện công cụ, nhưng tôi cảm thấy lĩnh vực này đang tập trung vá lỗi ở lớp sai. Chúng ta đã đạt đến điểm mà kiểm toán và Xác minh chính thức là tiêu chuẩn, nhưng bảo mật vẫn là một trò chơi vá lỗi sai chỗ không ngừng. Chúng ta coi các vụ tấn công hợp đồng thông minh là trường hợp ngoại lệ hoặc lỗi của nhà phát triển, nhưng chúng là kết quả có thể dự đoán được từ những gì môi trường thực thi cho phép.

Luận điểm cốt lõi

Ethereum được thiết kế để Turing-Complete . Tính tổng quát đó rất mạnh mẽ và cần thiết, nhưng liệu mọi Use Case có cần đến nó không? Câu trả lời là không, và hệ thống tài chính là ví dụ rõ ràng nhất về điều đó.

Tài chính luôn là một hệ thống có giới hạn về quy tắc. Từ những khoản vay ngũ cốc sơ khai đến các trung tâm thanh toán bù trừ hiện đại, mọi hệ thống tài chính từng được xây dựng đều là một hệ thống ràng buộc ở cốt lõi: một tập hợp các bên tham gia được xác định, các tài sản được xác định, một yếu tố kích hoạt được xác định, một công thức được xác định, một khung thời gian được xác định. Không có gì nằm ngoài những giới hạn đó được cho phép hoặc có liên quan. Điều này chưa bao giờ thay đổi. Điều đã thay đổi là môi trường thực thi mà chúng ta đã chọn để xây dựng chúng.

Hầu hết các lỗ hổng bảo mật DeFi không bắt nguồn từ logic tài chính. Chúng bắt nguồn từ các phép tính tùy ý xung quanh nó. Khi bạn triển khai một mô hình khai báo trong một môi trường Turing-Complete , bạn thừa hưởng toàn bộ bề mặt tấn công của môi trường đó mà không cần đến bất kỳ sức mạnh nào của nó.
Vụ tấn công Tổ chức tự trị phi tập trung (DAO) là ví dụ rõ ràng nhất. Năm 2016, 3,6 triệu ETH đã bị rút sạch thông qua lỗ hổng tái nhập. Nguyên nhân gốc rễ không phải là lỗi của nhà phát triển theo nghĩa thông thường. Đó là kết quả có thể dự đoán được khi triển khai một hệ thống tài chính bị hạn chế trên một lớp thực thi không bị hạn chế:

 function withdraw(uint256 _amount) external {require(balances[msg.sender] >= _amount, "Insufficient balance");(bool sent, ) = msg.sender.call{value: _amount}("");require(sent, "Failed to send Ether");balances[msg.sender] -= _amount; // state updated after external call}

Chức năng rút tiền đã gửi ETH trước khi cập nhật số dư. Vì Máy ảo Ethereum (EVM) cho phép các lệnh gọi đệ quy, kẻ tấn công có thể gọi hàm rút tiền một cách đệ quy trước khi số dư bị giảm. Tương đương trong FVL:

 system: "DAO" pool: collect: from: type: anyone what: type: eth rules: conditions: - if: type: balance_gte value: "1" then: type: enable permission: withdraw distribute: formula: type: proportional to: type: contributors triggers: manual rights: anyone: [ deposit , view ] contributors: [ withdraw ]

Trong FVL, loại lỗi đó hoàn toàn bị xóa bỏ, không phải bằng cách thêm cơ chế bảo vệ chống tái nhập, không phải bằng cách sắp xếp lại logic, mà bởi vì môi trường thực thi không cho phép sự chuyển đổi trạng thái đó tồn tại ngay từ đầu.

Ranh giới

Đề xuất của tôi vạch ra một ranh giới rõ ràng.
Nếu một hệ thống tài chính có thể được mô tả từ đầu đến cuối bằng các chuyển đổi trạng thái xác định trên các yếu tố cơ bản đã biết, thì nó thuộc về FVL. Nếu nó yêu cầu tính toán tùy ý mà giá trị không thể biết trước khi thực thi, thì nó thuộc về Ethereum.
Có một nhóm nhỏ các giao thức hợp lệ, trong đó AAVE và Compound là những ví dụ chính, nơi độ phức tạp thực sự đòi hỏi khả năng tính toán đa năng.

Tập hợp nguyên thủy

Ở cấp độ cơ bản, mọi hệ thống tài chính đều là sự kết hợp của năm yếu tố chính:

 system: <string> # System name pool: <config> # Asset collection rules rules: <config> # Conditional logic and distributions rights: <map> # Permission definitions time: <config> # Temporal constraints oracles: <list> # External data feeds

Sự kết hợp của các yếu tố cơ bản này tạo ra:

• Quỹ cho vay: pool + rights + oracles + rules
• Staking Pool: pool + time + rights
• Gọi vốn cộng đồng: pool + time + rules + rights
• Các tổ chức tự trị phi tập trung (DAO): pool + rights + rules + oracles + time

Một ví dụ thực tế, một hệ thống Staking cộng đồng:

 system: "CommunityStaking" pool: collect: from: type: token_holders address: "0xYourToken" what: type: erc20 address: "0xStakingToken" min: type: value amount: "100" cap: type: value amount: "1000000" rules: conditions: - if: type: time_gt timestamp: "1735689600" then: type: enable permission: withdraw distribute: formula: type: proportional to: type: contributors triggers: continuous time: locks: type: duration seconds: "2592000" vesting: type: linear duration: "7776000" rights: contributors: [ stake , unstake ] admin: [ pause , update_params ] oracles: []

Mô hình thực thi

Mỗi hệ thống FVL đều là một máy trạng thái hữu hạn. Đây là nền tảng mà trên đó các thuộc tính bảo mật và khả năng kiểm chứng của FVL dựa vào.

Thuyết định mệnh :
Hàm chuyển đổi không đọc bất kỳ trạng thái bên ngoài nào trong quá trình thực thi. Với cùng trạng thái ban đầu và cùng trình tự giao dịch được sắp xếp, bất kỳ hai bên nào cũng đạt được cùng một kết quả. Quá trình chuyển đổi trạng thái hoàn toàn bị giới hạn và không thể có sự can thiệp nào xảy ra trong quá trình thực thi.

Kết thúc :
Mỗi giao dịch kết thúc trong thời gian O(k), trong đó k là số điều kiện được định nghĩa trong hệ thống khi triển khai. k được cố định khi triển khai và không thể thay đổi. Chi phí thực thi hoàn toàn có thể dự đoán được, và không tồn tại toàn bộ lớp các vectơ tấn công từ chối dịch vụ.

Bề mặt tấn công có giới hạn :
Bảng chữ cái đầu vào được định kiểu và có giới hạn. Không thể gửi một giao dịch gọi một hàm tùy ý, tham chiếu đến một oracle chưa được khai báo hoặc kích hoạt hành vi nằm ngoài tập hợp các hàm cơ bản đã được định nghĩa.

Khả năng chơi lại :
Vì hàm chuyển đổi là hàm xác định và tất cả các đầu vào được ghi lại trong nhật ký chỉ ghi thêm, nên trạng thái hiện tại luôn có thể được tái tạo lại từ đầu. Bất kỳ bên nào có quyền truy cập vào nhật ký đều có thể xác minh độc lập rằng trạng thái được báo cáo là chính xác.

Kiến trúc

FVL là một Optimistic Rollup) được triển khai trên mạng chính Ethereum, thay thế môi trường thực thi Máy ảo Ethereum (EVM) bằng một môi trường chạy có giới hạn được xây dựng riêng.

 ┌─────────────────────────────────────────┐│ Declaration Layer (YAML) ││ parsing, validation, System ID │└─────────────────┬───────────────────────┘▼┌─────────────────────────────────────────┐│ Execution Layer — FVL Runtime ││ deterministic state transitions, ││ block production, state roots │└─────────────────┬───────────────────────┘▼┌─────────────────────────────────────────┐│ Settlement Layer — Ethereum L1 ││ state root anchoring, data ││ availability, fraud proof adjudication │└─────────────────────────────────────────┘

Mỗi hệ thống được triển khai đều được xác định bằng một ID hệ thống dựa trên nội dung:

system_id = Keccak256(canonical_json(system))

Bất kỳ thay đổi nào đối với định nghĩa, bất kỳ trường nào, bất kỳ điều kiện nào, bất kỳ quyền nào đều tạo ra một ID khác. Việc triển khai trùng lặp bị từ chối ở cấp độ giao thức. Bất kỳ ai cũng có thể xác minh cục bộ rằng hệ thống đã triển khai phù hợp với định nghĩa mà họ mong đợi mà không cần tin tưởng người triển khai.

Phần mở rộng cơ bản (FIPs)

Tập hợp các phần tử cơ bản được thiết kế hữu hạn một cách có chủ ý. Đây là nguồn gốc của các đảm bảo an toàn của nó. Các phần tử cơ bản mới được thêm vào thông qua các Đề xuất Cải tiến FVL, được mô phỏng theo quy trình Đề xuất cải tiến Ethereum (EIP) của Ethereum.

Tiêu chí chấp nhận chỉ là một câu hỏi duy nhất: liệu phép toán cơ bản này có thể được triển khai mà không cần đến tính đầy đủ của Turing hay không?

Nếu có, nó là ứng cử viên để được đưa vào. Nếu không, Use Case đó thuộc về Ethereum chính thức. Ranh giới này có tính chịu tải. Một phiên bản của FVL bổ sung khả năng tính toán tổng quát để xử lý các trường hợp ngoại lệ sẽ mất đi các thuộc tính phân tích tĩnh, trình xác minh chống gian lận đơn giản và đảm bảo thực thi có giới hạn của nó.

Đọc thêm

Để tìm hiểu chi tiết hơn về FVL và xem ví dụ minh họa, vui lòng xem bên dưới.

• Sách trắng: Sách trắng
• Phiên bản thử nghiệm: Github
• Đặc tả ngôn ngữ: Đặc tả ngôn ngữ