大家好，我提交此條目是為了提出一個Rollup設計方案，其唯一目的是為了進行財務協調。
自以太坊誕生以來，DeFi 已經發展成熟，可程式金融的概念也已成為現實。誠然如此，但這條路並非一帆風順，漏洞利用導致數十億美元的損失。解決方案是加強審計和改進工具，但我認為該領域一直以來都找錯了方向。如今，審計和形式化驗證已成為標準流程，但安全問題仍然像一場永無止境的修補遊戲，總是修補錯誤的地方。我們把智能合約漏洞視為極端情況或開發者失誤，但它們實際上是我們執行環境所允許的必然結果。
核心論點
以太坊從設計之初就具備圖靈完備性。這種通用性固然強大且必要，但並非所有應用程式場景都需要它嗎？答案是否定的，金融體係就是最明顯的例子。
金融始終遵循一套有界規則。從最早的糧食貸款到現代的清算機構，所有金融體系的核心都是一個約束系統：明確的參與者、明確的資產、明確的觸發條件、明確的公式和明確的時間範圍。任何超出這些界限之外的事物都是不允許的，也與此無關。這一點從未改變。改變的是我們選擇建構這些體系的執行環境。
大多數 DeFi 漏洞並非源自於金融邏輯本身，而是源自於圍繞金融邏輯的任意計算。當你在圖靈完備的環境中實現聲明式模式時，你便繼承了該環境的全部攻擊面，而無需利用其任何強大功能。
DAO 駭客事件就是最明顯的例子。 2016 年，360 萬枚ETH透過重入漏洞被竊。其根本原因並非傳統意義上的開發者失誤，而是將一個受限的金融體係部署在不受限制的執行層上，其必然結果。
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}提現函數在更新餘額之前發送了ETH 。由於 EVM 允許可重入調用，攻擊者可以在餘額遞減之前遞歸調用提現函數。 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 ]在 FVL 中，這類錯誤被完全消除，不是透過添加重入保護，也不是透過重新排序邏輯，而是因為執行環境從一開始就不允許這種狀態轉換存在。
邊界
我的提議劃定了一條正式的界線。
如果一個金融系統可以用已知原語的確定性狀態轉換進行端到端描述，那麼它就應該部署在FVL上。如果它需要任意計算，且計算結果在執行前無法預知，那麼它就應該部署在以太坊上。
有一小類合法的協議， Aave和 Compound 是主要的例子，它們的複雜性確實需要通用計算。
原始集
從根本上講，任何金融體係都是由五個基本要素構成的：
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這些基本元素的組合產生了：
- 借貸池：
pool + rights + oracles + rules - 質押池：
pool + time + rights - 群眾募資：
pool + time + rules + rights - DAO：
pool + rights + rules + oracles + time
一個實際應用範例，一個社區質押系統：
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: []執行模型
每個 FVL 系統都是有限狀態機。這是 FVL 安全性和可驗證性的基礎。
決定論：
此轉換函數在執行過程中不會讀取任何外部狀態。給定相同的初始狀態和相同的有序事務序列，任兩個參與者都會得到相同的結果。狀態轉換完全有界，執行過程中不會發生任何干擾。
終止：
所有交易均在 O(k) 時間內完成，其中 k 是系統部署時定義的條件數量。 k 部署時固定不變。執行成本完全可預測，且不存在任何一類拒絕服務攻擊向量。
有界攻擊面：
輸入字母表是類型化的且有限的。無法提交呼叫任意函數、引用未聲明的預言機或觸發超出已定義基本集合的行為的事務。
可重玩性：
由於狀態轉移函數是確定性的，且所有輸入都記錄在僅追加的日誌中，因此始終可以從頭開始重建當前狀態。任何有權存取該日誌的人員都可以獨立驗證所報告的狀態是否正確。
大樓
FVL 是一個樂觀Rollup，它結算到以太坊主網，用專門構建的受限運行時環境取代了 EVM 執行環境。
┌─────────────────────────────────────────┐│ 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 │└─────────────────────────────────────────┘每個已部署的系統都由一個內容尋址的系統 ID 標識：
system_id = Keccak256(canonical_json(system))
對定義、任何欄位、任何條件或任何權限的任何變更都會產生不同的 ID。重複部署會在協議層級被拒絕。任何人都可以本地驗證已部署的系統是否符合預期定義，而無需信任部署者。
原始擴充（FIPs）
原語集是故意設定為有限的，這是其安全性的保障。新的原語透過 FVL 改進提案添加，其流程仿照以太坊的 EIP 流程。
接受標準只有一個問題：這個原語能否在不符合圖靈完備性的情況下實現？
如果答案是肯定的，則該用例可以考慮納入以太坊。如果答案是否定的，則該用例應在以太坊本身中實現。此邊界具有承重作用。如果 FVL 版本為了適應邊緣情況而添加了通用運算，則會失去其靜態分析特性、簡單的詐欺證明驗證器以及有界執行保證。
延伸閱讀
如需詳細了解 FVL 的概念並查看其範例實現，請查看以下內容。
