3.1 KiB
title
| title |
|---|
| 嵌入Move编程语言 |
面临的问题
Solana使开发人员能够使用通用编程语言（例如C或Rust）编写链上程序，但这些程序包含特定于Solana的机制。 例如，没有其他区块链要求开发人员使用process_instruction(KeyedAccounts)函数创建Rust模块。 如果可以，Solana应该为应用程序开发者提供更多可移植的选项。
直到最近，还没有流行的区块链提供一种可以揭示Solana大规模并行runtime价值的语言。 例如，Solidity合约不会将对共享数据的引用与合约代码分开，因此需要顺序执行以确保确定性行为。 在实践中，我们看到最积极优化的基于EVM的区块链似乎都达到了约1,200 TPS的峰值——但这只是Solana能做到的冰山一角。 另一方面，Libra项目设计了一种称为Move的链上编程语言，该语言更适合于并行执行。 像Solana的runtime一样，Move程序依赖于帐户的所有共享状态。
Solana的runtime和Libra的Move VM之间最大的设计差异是它们如何管理模块之间的安全调用。 Solana采用操作系统方法，而Libra采用特定领域语言方法。 在runtime中，模块必须捕获回到runtime中，以确保调用方的模块未写入被调用方拥有的数据。 同样，当被调用方完成操作时，它必须再次陷阱回到runtime，以确保被调用方未写入调用方拥有的数据。 另一方面，Move包含一个高级类型的系统，该系统允许其字节码验证程序运行这些检查。 由于可以验证Move字节码，因此在链上加载模块时，只需支付一次验证费用。 在runtime中，每笔交易在模块之间交叉时都要支付费用。 从本质上讲，这种区别类似于动态类型的语言（如Python）与静态类型的语言（如Java）之间的差异。 Solana的runtime允许使用通用编程语言编写应用程序，但这在程序之间跳转时会带来runtime检查的费用。
该提议尝试定义一种嵌入Move VM的方式，从而实现：
-
跨模块调用中，Move不需要runtime的跨程序
跨程序runtime检查
-
Move程序可以利用其他Solana程序中的功能，反之
亦然
-
Solana的runtime并行性暴露于批量Move和non-Move中的
交易
拟定的解决方案
将Move VM作为Solana加载器
Move VM应该作为Solana加载器嵌入在标识符MOVE_PROGRAM_ID下，以便可以将Move模块标记为可执行的，而VM是其所有者。 这将允许模块加载模块依赖性，支持并行执行Move脚本。
Move模块拥有的所有数据帐户必须将其所有者设置为加载程序MOVE_PROGRAM_ID。 由于Move模块以与Solana程序封装其帐户相同的方式封装其帐户数据，因此Move模块所有者应嵌入在帐户数据中。 Runtime将授予对Move VM的写访问权限，而Move将授予对模块帐户的访问权限。
与Solana程序交互
要在非Move程序中调用指令，Solana需要通过process_instruction()系统调用来扩展MoveVM。 它和Rust BPF程序的process_instruction()方法一样。