大家好，我撰寫這篇條目是為了提議一種專為金融協調目的而設計的 Rollup 方案。

自以太坊誕生以來，DeFi 已經發展成熟，可程式化金融的概念已成為現實。雖然如此，發展過程並非一帆風順，其因果影響表現為各種漏洞利用，導致數十億美元的損失。目前的解決方案是增加審計和更好的工具，但我認為業界一直在錯誤的層次上進行修補。我們已經達到審計和形式驗證成為標準的階段，但安全性仍然是一場永遠在修補錯誤對象的遊戲。我們將智能合約漏洞視為邊緣案例或開發者錯誤，但它們其實是我們的執行環境所允許的必然結果。

---

核心論點

以太坊在設計上是圖靈完備（Turing-complete）的。這種通用性強大且必要，但每個使用場景都需要它嗎？答案是否定的，而金融系統就是最明顯的例子。

金融一直是一套有界限的規則集。從最早的穀物貸款到現代結算所，歷史上構建的每個金融系統其核心都是一個約束系統：一組定義好的參與者、定義好的資產、定義好的觸發條件、定義好的公式、以及定義好的時間範圍。任何超出這些界限的內容都是不被允許或無關緊要的。這一點從未改變。改變的是我們選擇用來構建它們的執行環境。

大多數 DeFi 漏洞並非源於金融邏輯，而是源於圍繞其周邊的任意計算。當你在圖靈完備的環境中實現宣告式模式（declarative pattern）時，你繼承了該環境的整個攻擊面，卻不需要用到它的任何功能。

The DAO 駭客事件是最清晰的例子。2016 年，360 萬枚 ETH 透過重入漏洞（reentrancy vulnerability）被盜取。根本原因並非傳統意義上的開發者錯誤，而是將一個受限的金融系統部署在不受限的執行層上的必然結果：

withdraw 函數在更新餘額之前發送了 ETH。因為 EVM 允許重入調用，攻擊者可以在餘額遞減之前遞迴地調用 withdraw。而 FVL 的等效實現如下：

在 FVL 中，這類漏洞被完全抹除，並非透過添加重入鎖（reentrancy guard）或重新排列邏輯，而是因為執行環境從根本上就不允許這種狀態轉換存在。

---

界限

我的提案劃定了一條正式的界限。

如果一個金融系統可以透過已知原語（primitives）上的確定性狀態轉換進行端到端的描述，那麼它就屬於 FVL。如果它需要執行前無法得知數值的任意計算，那麼它就屬於以太坊。

存在一小類合理的協議（以 Aave 和 Compound 為主要代表），其複雜性確實需要通用計算。

---

原語集

在最基礎的層面上，每個金融系統都是由五個原語組成的：

這些原語的組合可以產生：

• 借貸池：pool + rights + oracles + rules
• 質押池：pool + time + rights
• 群眾募資：pool + time + rules + rights
• DAO：pool + rights + rules + oracles + time

一個運行中的範例，社區質押系統：

---

執行模型

每個 FVL 系統都是一個有限狀態機。這是 FVL 安全性和可驗證性特性的基石。

確定性（Determinism）：
轉換函數在執行期間不讀取外部狀態。給定相同的初始狀態和相同的有序交易序列，任何兩方都會得到相同的結果。狀態轉換是完全有界的，執行過程中不可能發生干擾。

終止性（Termination）：
每筆交易都在 O(k) 時間內終止，其中 k 是部署時系統中定義的條件數量。k 在部署時固定且無法更改。執行成本是完全可預測的，且一整類拒絕服務（DoS）攻擊向量將不復存在。

有界攻擊面（Bounded attack surface）：
輸入字母表是具備類型且有限的。不可能提交一個調用任意函數、引用未宣告的預言機或觸發定義原語集之外行為的交易。

可重放性（Replayability）：
由於轉換函數是確定性的，且所有輸入都記錄在僅限附加（append-only）的日誌中，當前狀態始終可以從頭開始重建。任何有權訪問日誌的參與者都可以獨立驗證報告的狀態是否正確。

---

架構

FVL 是一個結算至以太坊主網的 Optimistic Rollup，它將 EVM 執行環境替換為專門構建的受限運行時（runtime）。

每個部署的系統都由一個內容定址的系統 ID（System ID）標識：

system_id = Keccak256(canonical_json(system))

定義的任何更改、任何欄位、任何條件、任何權限，都會產生不同的 ID。重複部署會在協議層被拒絕。任何人都可以本地驗證部署的系統是否符合他們預期的定義，而無需信任部署者。

---

原語擴展 (FIPs)

原語集被刻意設計為有限的。這是其安全保證的來源。新的原語透過 FVL 改進提案（FIPs）添加，模仿以太坊的 EIP 流程。

驗收標準只有一個問題：這個原語是否可以在不具備圖靈完備性的情況下實現？

如果是，則可以考慮納入。如果否，則該使用場景應屬於以太坊本體。這個界限至關重要。如果 FVL 為了適應邊緣案例而添加通用計算，它將失去其靜態分析特性、簡單的欺詐證明驗證器以及有界執行保證。

---

延伸閱讀

欲了解更多關於 FVL 的詳細內容並查看其原型實現，請參閱以下連結：

• 白皮書：Whitepaper
• 原型實現：Github
• 語言規範：Language Specification

---