專為金融協作設計的非 EVM 執行層專用 Rollup 提案

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

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

---

核心論點

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

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

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

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

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; // 狀態在外部調用後才更新
}

withdraw 函數在更新餘額之前發送了 ETH。因為 EVM 允許重入調用，攻擊者可以在餘額遞減之前遞迴地調用 withdraw。而 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 中，這類漏洞被完全抹除，並非透過添加重入鎖（reentrancy guard）或重新排列邏輯，而是因為執行環境從根本上就不允許這種狀態轉換存在。

---

界限

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

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

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

---

原語集

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

system: <string>   # 系統名稱
pool:    <config>  # 資產收集規則
rules:   <config>  # 條件邏輯與分配
rights:  <map>     # 權限定義
time:    <config>  # 時間約束
oracles: <list>    # 外部數據源

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

• 借貸池：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 安全性和可驗證性特性的基石。

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

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

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

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

---

架構

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

┌─────────────────────────────────────────┐
│        宣告層 (YAML)                     │
│  解析、驗證、系統 ID (System ID)         │
└─────────────────┬───────────────────────┘
                  ▼
┌─────────────────────────────────────────┐
│     執行層 — FVL 運行時                  │
│  確定性狀態轉換、                        │
│  區塊生產、狀態根                        │
└─────────────────┬───────────────────────┘
                  ▼
┌─────────────────────────────────────────┐
│     結算層 — 以太坊 L1                   │
│  狀態根錨定、數據                        │
│  可用性、欺詐證明裁決                    │
└─────────────────────────────────────────┘

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

system_id = Keccak256(canonical_json(system))

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

---

原語擴展 (FIPs)

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

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

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

---

延伸閱讀

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

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

---

        1 則貼文 - 1 位參與者

        [閱讀完整主題](https://ethresear.ch/t/a-specialized-rollup-with-a-non-evm-execution-layer-for-financial-coordination/24258)