Robinhood 本可以构建在 Solana 上：这是为什么

Raiku @raikucom

Robinhood 本可以构建在 Solana 上：原因如下

Raiku

@raikucom

· 7月12日

文章

为什么 Offchain Compute 对 Solana 如此重要

随着加密货币应用程序扩展到金融、人工智能、DePIN 和零售交易等现实世界领域，它们开始触及基础设施的天花板。例如，在 Solana 上，超过 95% 的...

4

5

35 4.9K ##

Arbitrum Orbit: 控制是以互操作性为代价的

在传统金融中，像抢先交易和滞后交易这样的交易操纵是非法的；中介机构必须保证公平、有序的执行。在链上，公共验证者无法强制执行这一点，Robinhood 需要基础设施来完全控制交易排序。

这就是它选择 Arbitrum Orbit 的原因：通过运营自己的排序器，Robinhood 可以完全阻止 MEV，确保交易不会被重新排序、抢先交易或滞后交易，这是合规性和可审计性的关键要求。但这种控制是有代价的：Robinhood 失去了对更广泛的 DeFi 生态系统的无缝访问，因为像 Orbit 这样的 L2 链缺乏内置的互操作性。 > 流动性被锁定在一个围墙花园中，与更广泛的 DeFi 市场、流畅的跨链交互以及与生态系统其余部分的轻松连接隔绝。Arbitrum Orbit 链无法即插即用地访问其他 Orbit 链或外部网络。

因此，用户必须依赖中介机构来转移资产和跨生态系统执行逻辑，通常会产生额外的成本，同时在严格许可的框架内运作。

为什么仅有 Solana 并不够，以及 Raiku 如何使其成为可能

Solana 是世界上最快的区块链之一——这要归功于其单体设计，所有应用程序共享相同的运行时。这允许与其他程序（如预言机、稳定币或 DeFi 协议）进行无缝的可组合性，而无需桥接或额外的基础设施。

但是，这种共享设计恰恰带来了 Robinhood 无法接受的限制。

应用程序无法决定自己的交易顺序。相同的验证器集一起处理所有内容，因此交易应用程序无法保证交易何时完成或防止其被 MEV。它也不能轻易地构建合规性检查或执行自定义规则，因为执行在所有应用程序中都是统一处理的。

这就是 Raiku 的用武之地。

Raiku 为 Solana 上的应用程序提供了通常只有在特定于应用程序的链上才能获得的控制权，但又不会牺牲 Solana 的性能或其对充满活力的共享生态系统的访问。

借助 Raiku，应用程序可以：

• 消除 MEV 风险

• 选择何时何地包含其交易

• 通过插槽拍卖预留未来区块中的空间

• 在最终结算之前收到加密预确认

• 私下运行合规性检查和业务逻辑，并且仅在链上发布最终结果

在我们演练 Robinhood 如何在 Raiku 上运行并追踪完整的交易生命周期之前，重要的是要了解 Raiku 支持的两种执行模型：原生应用程序和扩展应用程序。

• 原生应用程序直接在 Solana 上运行，但可以获得诸如计划包含、早期确认和减少 MEV 风险之类的增强功能。

• 扩展应用程序私下运行其执行逻辑，保持对交易排序的完全控制，并且仅将最终结果提交给 Solana。它们非常适合需要法规遵从性、自定义运行时环境以及对交易排序方式和时间进行严格控制以防止所有形式的 MEV 的应用程序。

现在让我们分解使这成为可能的关键组件。

Raiku 组件

1. Ackermann 节点

Ackermann 节点是 Raiku 的链下大脑。可以将其视为去中心化调度程序，使应用程序可以控制其交易如何在 Solana 上落地，何时落地以及在何处落地，而无需修改 Solana 的核心共识。它协调交易的整个生命周期，并通过以下系统实现有保证的交易包含：

a. 插槽拍卖 (AOT / JIT)

Raiku 的 Ackermann 节点使应用程序能够通过两种插槽拍卖模式预留区块空间：提前 (AOT) 和 Just-in-Time (JIT)。这些机制提供有保证的交易包含，并通过绕过公共 mempool 显着降低了遭受 MEV 攻击（例如抢先交易或三明治攻击）的风险。

通过 AOT 调度，Robinhood 可以提前预留特定的未来插槽，就像在日历上预订时间一样。这些插槽是提前保护的，因此交易永远不会进入 mempool，这意味着它们对其他参与者不可见，并且受到 MEV 的完全保护，包括抢先交易和重新排序。这保证了精确的计时，为用户实现了早期确认，并支持监管工作流程。

AOT 非常适合可预测的操作，如每日资产净值 (NAV) 报告，这需要准确且一致的估值快照，以及合规性驱动的交易批处理或计划结算，其中确定性和可审计性至关重要。

通过 JIT 调度，Robinhood 在提交交易前片刻对插槽进行投标。这使其可以灵活地快速响应市场状况，例如大型报价请求 (RFQ)，其中买方要求多个卖方提供报价，或高频交易，同时仍保持交易完全私密，直到确认。

该交易直接提交给选定的验证者，而无需进入任何公共或私有 mempool，这可以防止其他参与者在包含之前看到或利用它。虽然 JIT 也可以防止 MEV，但由于它更接近实时执行，因此与 AOT 相比，它带来的风险略高，因为验证者的不当行为可能会产生更大的影响。

简而言之：

• AOT 提供最强的 MEV 保护和有保证的包含，适用于计划的交易。

• JIT 为反应性交易提供快速执行和隐藏的订单流，但由于其即时性，MEV 保护略有降低。

b. 服务质量 (QoS) 保证

服务质量 (QoS) 是指系统如何可靠且可预测地兑现其性能承诺，尤其是在需求较高时。在 Raiku 中，QoS 是关于确保某些交易被优先处理并在需要时准确包含，同时仍为较低优先级的流程留出空间。

Raiku 引入了两个级别的 QoS，以帮助像 Robinhood 这样的应用程序在确定性包含和吞吐量效率之间取得平衡：

插槽包含 QoS (siQoS)：专门为赢得 Raiku 的 AOT 或 JIT 插槽拍卖的交易预留每个 Solana 区块的可配置部分（例如，25%）。

Stake-Weighted QoS (swQoS)：根据验证者权益和性能分配剩余带宽。此路径适用于较低优先级或对成本敏感的交易，从而使 Robinhood 能够优化吞吐量，同时保持可靠性。

siQoS 和 swQoS 共同构成了分层 QoS 系统，该系统为 Robinhood 提供了对敏感合规性流程的确定性，并为其他一切提供了灵活性。

c. 交易分类和路由 每笔交易都会根据策略、负载和插槽可用性与最佳验证者匹配。Ackermann 评估：

• 领导者时间表

• 验证者权益和正常运行时间

• Sidecar 可用性和运行状况

• 当前网络带宽

• 任何自定义 Robinhood 约束（例如，SOC 2 合规性）

这种智能路由可确保交易按时且通过受信任的基础设施交付。Ackermann 还会随着时间的推移跟踪验证者的可靠性，以改进未来的路由决策。

d. 预确认信号 预确认是加密承诺，即交易将被包含在特定插槽中，即使在链上达到最终确认之前也是如此。它们使像 Robinhood 这样的应用程序能够提前确保交易已锁定，从而实现更快的用户反馈和监管确定性。

• 对于基于 siQoS 的交易，Ackermann 在插槽安全后会发送加密预确认。这使 Robinhood 可以在链上最终确认之前向用户显示即时“交易已确认”状态。

• 对于基于 swQoS 的交易，如果满足验证者容量和可靠性阈值，则可能会发出软预确认。

e. 回退和惩罚逻辑 如果包含失败，Ackermann 可以将交易重新路由到备用验证者或 Sidecar。如果没有可行的替代方案，则会触发回退到 swQoS 或本机提交。错过预先提交的插槽的验证者可能会在未来的路由决策中受到惩罚或降低优先级，从而在网络压力下保持可靠性。

2. Ackermann Sidecar

运行 Raiku 的每个 Solana 验证者也运行一个 Sidecar，这是一个轻量级进程，用于强制执行 Ackermann 的链下调度决策。一旦 Ackermann 将交易分配给验证者，Sidecar 就会接管：

• 根据 QoS 类（siQoS 或 swQoS）对交易进行排队和执行

• 强制执行插槽包含保证，特别是对于高优先级 siQoS 通道

• 运行本地检查以进行预确认逻辑（例如，余额、合规性、风险模型）

• 监控验证者执行并向 Ackermann 报告错过的插槽或故障

简而言之，Sidecar 桥接了链下协调和链上执行，确保 Raiku 的调度逻辑在整个网络中得到精确和可靠的执行。

3. 全局帐户模型

Raiku 的全局帐户模型 (GAM) 允许原生和扩展应用程序以统一且可组合的方式与 Solana 的全局状态进行交互。

• 原生应用程序像往常一样继续使用 Solana 的内置 VM 和运行时。

• 扩展应用程序可以在自定义 VM 上运行，例如 EVM、Move 或 WASM，在 Solana 运行时之外执行逻辑，但仍然通过 GAM 将状态更改提交回 Solana。

这使开发人员可以灵活地使用专门的执行环境，而不会使流动性分散或降低其可组合性。这在精神上类似于 Arbitrum Orbit 通过 Stylus 提供的功能，Stylus 允许应用程序使用 Rust 或 C++ 以及 Solidity 编写合约。这种灵活性是 Robinhood 选择 Arbitrum 的原因之一，但借助 Raiku，扩展应用程序可以获得相同的灵活性，同时保持与 Solana 的共享全局状态的连接。

Robinhood 在 Solana 上的两条路径

有了这些组件，Raiku 为 Robinhood 在 Solana 上线开辟了两条截然不同的路径：作为原生应用程序或作为扩展应用程序。

如果 Robinhood 将 Raiku 用作 Solana 上的原生应用程序会怎样？

如果 Robinhood 使用 Raiku 作为原生应用程序运行，则其交易仍将在 Solana 的运行时内执行，但会有重大改进，以下是它的外观：

1. 用户下达交易指令（例如，购买代币化的 Apple 股票）。

2. Robinhood 通过 Raiku SDK 将交易提交给 Ackermann 节点。

3. Ackermann 使用以下两种方式之一安排交易：

4. AOT 用于预先安排的流程（例如，NAV 批处理）。

5. JIT 用于实时市场反应（例如，RFQ、HFT）。

6. 获得插槽后，Robinhood 会收到加密预确认。

7. 该交易私下交付给选定的验证者。

8. 验证者在 Solana 的运行时中按照确切的计划时间执行交易。

9. 返回最终确认；状态更改记录在链上。

原生应用程序（使用 Raiku）的优势：

• 确定性包含：借助 AOT/JIT 插槽拍卖，Robinhood 确切地知道交易何时落地。

• 网络层 MEV 保护：交易绕过公共 mempool 并以私密方式路由，从而降低了提交时的抢先交易和三明治风险。

• 预确认：加密预确认在最终结算之前为用户提供了实时信心。

• 共享流动性：原生应用程序在 Solana 的全局状态内运行，确保无缝访问 DeFi 协议、稳定币、预言机和其他程序。

但是原生应用程序还不够

即使使用 Raiku 的升级，原生应用程序仍然在 Solana 的共享运行时内运行，这限制了关键领域的控制：

• 没有自定义执行逻辑：原生应用程序必须使用 Solana 的标准 VM，这使得嵌入 KYC 检查、每个用户的限制或内部风险模型变得困难。

• 没有私有排序器：应用程序无法完全控制自己的交易顺序，这对于批量处理、匹配和强制执行合规性规则至关重要。

• MEV 风险仍然存在：虽然 Raiku 消除了公共 mempool 风险，但验证者可能仍然私下共享订单流，从而使交易面临抢先交易或三明治攻击。

对于像 Robinhood 这样的受监管平台来说，这还不够。完全控制需要私有执行，而这只有扩展应用程序才能提供。

推出 Raiku Extensions 作为完整的解决方案

扩展应用程序遵循原生应用程序流程直至执行，但将逻辑转移到专用基础设施，从而为像 Robinhood 这样的平台提供：

• 独立的排序器：完全控制交易排序以防止 MEV 风险。

• 链下模拟：在链上提交之前批量处理、匹配和验证交易。

• 自定义合规性逻辑：强制执行 KYC、风险规则和法规过滤器。

• 自定义 VM 支持：在 Solana 的标准 VM 之外执行逻辑。

• 单一承诺：仅在链上提交最终结果。

• 执行主权：不依赖验证者端排序，确保隐私以及与 Solana 生态系统的可组合性。

结算在链上进行，但执行逻辑仍由 Robinhood 控制，从而在控制和互操作性之间取得平衡。

工作原理：分步流程

1. 用于交易排序的私有排序器：用户交易进入 Robinhood 的私有排序器，避免公共或私有 mempool，从而消除三明治攻击等 MEV 风险。排序器强制执行内部规则（例如，每个用户的限制、风险敞口限制、实时风险检查），确保金融产品所需的确定性排序，这在 Solana 的共享运行时中是无法实现的。

2. 自定义 VM 中的链下模拟：交易捆绑成批量并在 Robinhood 的自定义虚拟机（例如，LightSVM 或基于 WASM 的引擎）中处理。VM 确定性地模拟定价、费用逻辑和订单匹配。Raiku 的 GAM 实现了与 Solana 全局状态的互操作性，确保了无缝集成，同时保持执行的独立性。

3. Ackermann 节点通过 siQoS 安排批处理：最终确定的交易批处理将发送到 Ackermann 节点，该节点使用 AOT 或 JIT 拍卖通过 siQoS 路由它。该节点预留一个验证者插槽以确保包含，从而优化时间和可靠性。

4. 用户反馈的预确认：安排后，Ackermann 节点会将加密预确认发送到 Robinhood 的 UI，从而实现即时“交易已确认”状态。这支持合规性工作流程并增强用户体验，但最终确定性取决于 Solana 的共识。

5. Sidecar 验证者执行批处理：交易批处理会传递到分配的验证者的 Ackermann-sidecar。当预留的插槽到达时，Sidecar 会将批处理转发给区块领导者以包含在区块中。

6. Solana 上的最终确定性：Solana 的共识在大约 150 毫秒内最终确定批处理（通过 APE/MCL 等升级）。Robinhood 的 UI 会从“已确认”更新为“已最终确定”，反映已完成的交易。

为什么 Extensions 对于 Robinhood 来说是理想的

与在 Arbitrum Orbit 上相比，Raiku 的扩展模型为 Robinhood 提供了更多的控制和灵活性，同时保持了 Solana 的速度和互操作性。主要优势包括：

• 通过私有排序实现 MEV 保护 借助 Raiku Extensions 提供支持的自定义排序器，Robinhood 可以准确地决定何时以及以何种顺序处理其交易。这可以防止任何人干扰交易 - 没有抢先交易，没有滞后交易，也没有在其周围插入交易（三明治）。

• 自定义执行环境 扩展允许 Robinhood 使用自定义虚拟机来强制执行内部逻辑，如 KYC/AML 检查、风险评分和 SOC 2 控制，所有这些对于受监管的交易都至关重要。

• 通过全局帐户模块 (GAM) 实现可组合的结算 即使执行发生在链下，Robinhood 仍然可以结算到 Solana 的共享状态。这意味着它可以保留对 DeFi 协议、稳定币预言机和流动性的无缝访问，这与 Orbit 不同，Orbit 将流动性隔离在每个应用程序链上。

• 无碎片化的完全执行主权 Robinhood 可以在不离开 Solana 生态系统或放弃共享安全性、原子可组合性或低延迟最终确定性的情况下获得类似 rollup 的控制。

Raiku 的扩展使 Robinhood 能够在 Solana 上构建代币化股票平台，超越 Arbitrum Orbit 排序器模型的控制，同时利用 Solana 的高性能和互操作性。私有排序器通过避免 mempool 风险消除了三明治攻击等 MEV 风险（根据 Helius 的数据，占 Solana MEV 的 50%）。自定义 VM 启用了合规性逻辑（例如，KYC/AML、SOC 2）和复杂的交易执行。GAM 确保与 Solana 的 DeFi 生态系统无缝集成，从而克服了 Orbit 的流动性隔离，从而创建了一个可扩展、安全且合规的平台。

那么，Robinhood 和下一波机构是否已准备好迎接 Solana？

绝对是的。

借助 Raiku，Solana 为 Robinhood 提供了两全其美的优势：机构级执行控制以及对世界上最快、最具可组合性的 Layer 1 的完全访问。

Robinhood 现在可以获得所需的一切：通过 AOT/JIT 拍卖保证交易包含、灵活的排序、链下模拟、嵌入式合规性逻辑以及完全的执行控制，同时保持 Solana 全局状态的可组合性。没有 rollups、没有桥接、没有流动性碎片化，也没有在性能或可审计性上做出妥协。

Raiku 不仅使 Solana 为 Robinhood 做好了准备，而且为每个需要合规级执行而又不放弃速度或可组合性的机构做好了准备。Arbitrum 可能赢得了 Robinhood，但下一波 Fidelity、Visa、Stripe、FanDuel 仍然前景广阔。

Solana 已经准备好了。Raiku 使其成为可能。

• 原文链接： x.com/raikucom/status/19...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～