可验证计算用于链上 Prop Trading：Carrotfunding 如何使用 ROFL

Source: Dev.to

链上做市交易一直承诺透明性，但实际上大多数平台仍然依赖 不透明的链下引擎 来执行订单、评估交易员以及处理支付逻辑。资本可能已在链上锁定，但最关键的决策——谁获得资金、如何衡量业绩以及何时触发支付——往往发生在黑箱基础设施中。

Carrotfunding.io 正在通过集成 ROFL，在其交易和评估流水线中引入密码学可验证计算，迈出消除这一鸿沟的具体一步。

交易公司中的信任缺口

传统的自营公司建立在信任之上：交易员信任执行，公司信任评估逻辑，投资者信任支付计算。即使是许多“链上”平台也通过在链上锚定资本、将决策逻辑保留在链下的方式复制了这种模型。

Carrot 已经在以下几个方面最小化了这些假设：

• 资本使用 rethink.finance 金库进行保障
• 交易通过 gTrade 执行

剩余的信任依赖在于负责以下工作的 AWS‑based engine：

• 订单编排
• 交易员绩效评估
• 风险指标
• 支付计算

这正是 ROFL 被引入的地方。

ROFL 集成工作原理

与立即替换现有基础设施不同，Carrot 正在将 ROFL 部署为 并行验证层。

• 生产引擎继续运行，以保证性能和延迟。
• ROFL 实例在 受信任执行环境 (TEE) 中独立重新执行相同的计算。

ROFL 生成加密证明，证明：

• 执行了哪些代码
• 使用了哪些输入
• 产生了哪些输出

这些证明会被上链，交易者和资本提供者可以据此验证：

• 评估规则严格按照定义应用
• 没有进行任何酌情更改
• 支付金额是确定性计算得出的

随着时间推移，这种架构支持逐步过渡到 仅使用 ROFL 执行，而不会牺牲当前系统的可靠性。

为什么这在技术上很重要

ROFL 提供了标准链下基础设施无法实现的特性：

• 执行完整性 – 代码在硬件隔离的安全区（enclave）中运行。
• 可复现性 – 相同的输入产生可验证的输出。
• 可审计性 – 验证在链上进行，而不是通过日志或仪表盘。
• 密钥隔离 – 敏感密钥永不离开安全区。

对于做市商交易系统来说，这意味着交易员评分、回撤检查和支付逻辑成为 可证明的协议行为，而不是运营商的承诺。

对交易员和资本提供者的影响

对交易员

• 评估标准变得透明且可验证。
• 争议可以通过密码学方式解决，而非社交方式。
• 资金决策不再主观或不透明。

对资本提供者

• 资金受不可变逻辑治理。
• 风险控制严格按规定执行。
• 业绩声明可以独立验证。

DeFi 基础设施的更广泛信号

此集成是 verifiable compute 如何解锁新型金融应用的有力示例。做市交易需要：

• 高频逻辑
• 复杂的评估规则
• 严格的公平性保证

ROFL 展示了此类系统如何在保持性能的同时实现 trust‑minimized。虽然对于此类工作负载而言，完全链上执行往往不切实际，但 cryptographically verified offchain compute 提供了一个切实可行的折中方案。

展望未来

Carrotfunding 的路线图包括随着时间的推移更深度地依赖 ROFL，甚至可能完全消除中心化执行。更广泛地说，这一模式——

并行验证 → 逐步迁移 → 完全可验证执行

——有望成为复杂 DeFi 系统的标准做法。

随着链上金融的成熟，信任假设将越来越多地从人和服务器转向 代码和密码学。此举是朝着该方向迈出的早期且有意义的一步。