将 Move 语言嵌入 Solana 运行时MOVE_PROGRAM_ID 加载器设计提案解析【免费下载链接】solanaWeb-Scale Blockchain for fast, secure, scalable, decentralized apps and marketplaces.项目地址: https://gitcode.com/GitHub_Trending/so/solana本篇技术文章以 Solana 仓库中的设计提案 embedding-move.md 为骨架深入剖析将 Move VM 嵌入为 Solana Loader这一方案的设计动机、核心机制与源码依据。读者读完本文后将能理解 Solana 运行时与 Move VM 在跨模块安全调用上的本质差异、MOVE_PROGRAM_ID加载器与账户所有权模型的工作原理以及该提案如何让 Move 程序与 Solana 原生程序双向互操作。阅读前提提示该提案文档开头明确标注This document is outdated and a new approach to support move is in the works本文档已过时支持 Move 的新方案正在推进中。因此本文将其定位为一份历史设计提案的深度解读而非当前 Solana 运行时对 Move 支持的最终实现说明。文中描述的能力均以提案内容与仓库现存源码为准。一、提案背景运行时现状与可移植性痛点1.1 通用语言编写链上程序的锁定问题Solana 允许开发者用 C、Rust 等通用编程语言编写链上程序on-chain programs但这些程序天然携带 Solana 专属机制。提案中明确指出没有任何其他链要求开发者编写一个带有process_instruction(KeyedAccounts)签名的 Rust 模块。这意味着用 Rust 编写的 Solana 程序无法直接移植到其他链上——process_instruction是 Solana 运行时定义的入口约定而非通用语言特性。从当前仓库源码看这一入口约定在运行时中确实是硬编码的执行契约。message_processor.rs 中运行时通过invoke_context.process_instruction(...)将交易指令路由到已加载程序而 invoke_context.rs 则作为每次指令执行的上下文容器。这印证了提案的核心论断Solana 的运行时方案需要每次跨模块跳转都做检查而这是提案想要优化的核心开销。1.2 并行执行能力EVM 的短板与 Move 的优势提案对比了两种主流链上语言设计SolidityEVM不区分共享数据引用与合约代码为确定性必须串行执行。提案引用行业观察称优化最激进的 EVM 系区块链 TPS 峰值也仅约 1,200远低于 Solana 可达到的吞吐。MoveLibra 项目设计一种专为并行执行设计的链上编程语言。与 Solana 运行时一样Move 程序的所有共享状态都依赖账户accounts这为数据依赖分析提供了基础从而支持并行执行。提案认为直到不久之前还没有主流区块链提供一种能充分发挥 Solana 大规模并行运行时价值的语言。而 Move 的数据模型与 Solana 的账户模型天然契合这是本提案成立的逻辑起点。二、核心分歧操作系统方案 vs 领域特定语言方案提案将 Solana 运行时与 Libra Move VM 之间最大的设计差异概括为模块间安全调用safe invocations between modules的管理方式维度Solana 运行时操作系统方案Libra Move VMDSL 方案检查方式运行时陷回trap检查字节码验证器bytecode verifier静态检查检查时机每次跨模块调用时执行模块链上加载时一次性验证检查内容调用方不得写入被调方数据被调方不得写入调用方数据类型系统层面静态保证所有权隔离语言类比动态类型语言如 Python静态类型语言如 Java在 Solana 运行时中当一个模块调用另一个模块时必须**陷回trap back**到运行时以确认调用方没有写入被调方拥有的数据被调方完成时同样要陷回运行时确认没有写回调用方的数据。这些运行时检查保证了 runtime.md 中所列的运行时规则——只有账户的 owner 程序才能修改账户内容。而 Move 依靠高级类型系统让这些所有权检查由字节码验证器在模块加载上链时一次性完成。因此在 Move 中验证成本只在模块加载时支付一次在 Solana 运行时中成本在每次跨模块交易时都要支付。这就是本提案的出发点——能否把 Move 的静态验证优势引入 Solana从而省去跨模块调用时的运行时检查开销三、提案目标该提案试图以如下方式嵌入 Move VM明确列出三个目标Move 内部的跨模块调用不需要运行时的跨程序检查——将检查前置到加载期验证Move 程序可以利用其他 Solana 程序的功能反之亦然——实现双向互操作Solana 运行时的并行能力可作用于 Move 与非 Move 交易的混合批次——不因引入 Move 而牺牲并行度。这三个目标分别对应后文设计的三个机制Loader 化、process_instruction()系统调用、账户所有权模型。四、核心设计方案Move VM 作为 Solana Loader4.1MOVE_PROGRAM_ID与可执行账户提案的核心构思是将 Move VM 嵌入为 Solana 的一个 Loader并赋予标识符MOVE_PROGRAM_ID。其效果是Move 模块module账户可以被标记为executable并将 VM 设为它的owner这允许模块加载模块依赖module dependencies也允许 Move 脚本scripts的并行执行。这一机制与 Solana 现有 Loader如 BPF Loader的定位一致Loader 是负责解释/执行程序代码的链上程序普通程序账户只要将 owner 指向某个 Loader即可被该 Loader 加载执行。Move VM 在此扮演同样的角色只是它的程序是 Move 字节码而非 SBF 字节码。4.2 数据账户的所有权模型提案进一步规定所有由 Move 模块拥有的数据账户必须将其 owner 设置为 Loader——MOVE_PROGRAM_ID。这里存在一个需要理解的双层所有权设计外层运行时层面由于 Move 模块与 Solana 程序一样封装自己的账户数据Move 模块的真实 owner被嵌入在账户数据内部即 Move 模块字节码中声明的所有权内层Move 层面运行时将写权限授予 Move VM因为 VM 是账户的 owner而 Move VM 内部再根据数据内嵌的模块所有权信息将访问权授予对应模块。运行时把写访问权授予 Move VMMove 再把访问权授予模块账户。这种运行时只认 Loader、Loader 内部分发权限的模式恰好复用了 Solana 现有的账户所有权安全模型runtime.md 中Only the owner program may modify the contents of an account的规则同时又让 Move 的类型系统接管了模块间的细粒度权限判断。4.3 并行性如何被暴露由于 Move 与 Solana 一样以账户为共享状态单元运行时已有的数据依赖分析交易预先声明数据依赖、只读账户并行执行、可写账户串行化可以直接套用在 Move 交易上。混合批次Move 交易 非 Move 交易仍能由运行时统一调度并行这正是目标 3 的实现路径。五、Move 与 Solana 程序的互操作process_instruction()系统调用为了在非 Move 程序中调用指令提案提出Solana 需要为 Move VM 扩展一个process_instruction()系统调用system call其工作方式与 Rust SBF 程序的process_instruction()完全一致。这意味着Move → SolanaMove 代码通过该系统调用可以像 Solana 原生程序调用其他程序一样发起对任意 Solana 程序如 System Program、Token Program的调用Solana → Move反之Solana 程序也能把 Move 模块当作普通程序账户来调用前提是 Move 模块暴露了与process_instruction兼容的入口。这一对称设计保证了目标 2 的双向互操作性。5.1 源码对照Solana 侧调用链当前仓库中Solana 程序间的互操作正是通过一组 SDK 函数完成的见 program.rsinvoke(instruction, account_infos)——标准跨程序调用执行全部安全检查invoke_unchecked(...)——跳过部分检查的调用invoke_signed(...)/invoke_signed_unchecked(...)——携带 PDA 签名program-derived address signature的调用。这些函数最终会经由 syscalls/definitions.rs 中定义的系统调用如sol_invoke_signed陷回运行时由 invoke_context.rs 完成参数校验与递归执行。提案设想的 Move VM 内process_instruction()系统调用走的正是同一条路径——这也是它宣称工作方式与 Rust SBF 程序一致的源码级依据。六、提案的意义与适用边界6.1 收益总结关注点传统 Solana 程序嵌入 Move 后跨模块安全检查每次运行时陷回检查加载期字节码验证一次支付语言可移植性绑定 Solana 专属入口Move 生态语言资产可复用并行执行运行时数据依赖分析保持并行且覆盖 Move 交易程序生态互操作—Move 程序 ↔ Solana 程序双向调用6.2 提案状态与局限需要特别说明的是本文解读的是一份设计提案而非已实现特性提案文档自身标注为 outdated仓库维护者表示支持 Move 的新方案正在推进中意味着本文描述的具体设计如MOVE_PROGRAM_ID的确切形态可能不会按原样落地该文档存放于 proposals 目录而 accepted-design-proposals.md 明确说明被接受的架构提案可能按描述实现、可能以不同方式实现、也可能根本不实现提案中EVM 约 1,200 TPS等数据属于提案写作时的行业观察表述并非本仓库可验证的性能承诺。因此读者应将本文视为理解Solana 运行时抽象Loader 账户所有权 跨程序调用如何能够承载一门新语言的架构分析样本而非对当前 Solana 网络 Move 支持状态的断言。七、延伸阅读完整提案原文embedding-move.mdSolana 运行时架构账户结构、执行规则、并行模型validator/runtime.md运行时指令处理入口实现program-runtime/src/message_processor.rs指令执行上下文与校验program-runtime/src/invoke_context.rs跨程序调用 SDK 函数sdk/program/src/program.rs系统调用定义sdk/program/src/syscalls/definitions.rs提案管理机制accepted-design-proposals.md【免费下载链接】solanaWeb-Scale Blockchain for fast, secure, scalable, decentralized apps and marketplaces.项目地址: https://gitcode.com/GitHub_Trending/so/solana创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考