大家好，我提交此条目是为了提出一个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 的概念并查看其范例实现，请查看以下内容。
