Anza的新SVM API

Solana正经历着自己的“EVM”时刻，随着“SVM”（Solana虚拟机）的出现，这一术语在加密世界中产生了显著的热议。就像以太坊在2022年一样，许多“SVM”项目正在进行雄心勃勃的冒险，利用Solana的高级交易处理能力来实施多种超出Solana验证器的应用。

随着SVM生态系统的快速扩展，开发者和创新者正在探索新的可能性，推动此强大技术所能实现的边界。那么，SVM究竟是什么？项目如何利用SVM进行构建？

定义SVM

Solana生态系统内的工程师对Solana虚拟机的确切定义持有不同观点。有些人坚持认为它涵盖了从验证器运行时到程序执行的整个交易处理管道。另一些人则认为真正的SVM仅是负责执行程序的低级eBPF虚拟机。

大多数新兴的SVM项目似乎更倾向于Solana虚拟机的前者，更广泛的视角。考虑到这一点，分解交易处理管道并了解其组件变得至关重要。

Agave验证器的 Bank 组件作为验证器内SVM的指挥者。Bank涵盖了大部分验证器运行时，负责在特定时隙内管理网络状态。虽然时隙可以在不同的分叉之间存在，但这一复杂性超出了SVM的范围。

随着Solana网络的正常运转，交易通过网络连接提交给验证器，然后被路由到运行时进行执行。在任何特定的时隙中，该时隙的Bank处理交易并试图将其打包到一个区块中。

Solana协议将交易转发给领导者计划中的下一个领导，而不是利用待处理交易的Mempool。如果一个领导者无法在当前时隙中包含一笔交易，则会将其转发给下一个领导。领导者使用Bank来打包一个区块，而其他节点将会对区块进行重放，试图重建匹配的Bank实例，从而验证一个区块。

无论节点是打包一个区块（领导者）还是重放一个区块（验证器），交易都是批量处理的。每笔交易包含一个或多个指令，每条指令均针对特定程序。

如上图所示，指令包含与加载账户和确定写入锁相关的信息。只读和“可写”账户的概念允许在Bank实例之间进行并行账户数据访问。

在交易被处理之前，它们会经历一个“清理”过程，该过程进行各种检查并从指令中提取处理信息。在清理过程中的一个有用优化是从交易的指令中提取和去重账户密钥。这允许SVM在不重复或不必要的努力的情况下加载整个交易所需的密钥。

一旦所有账户都被加载，SVM便加载每条指令的可执行程序，并提供一个eBPF虚拟机来执行程序并返回结果。为了避免冗余地将字节码转换为机器码，采用了缓存机制，该机制存储翻译过的程序，直到需要重新计算时（或缓存已满）。

所有这些端到端的复杂性都发生在SVM组件内，并由Bank驱动。Bank使用的SVM接口与Bank的耦合度已经显著降低，这带来了围绕这一新、解耦、定义良好的SVM接口的许多有趣机会。主要来说，这意味着SVM可以由其他组件驱动，超出Solana验证器的范围。

SVM的机会

在全面了解SVM的架构后，理解这个独立软件组件可能会用来做什么便变得相关。独立的、可组合的SVM存在许多机会——无论是在Solana验证器节点内还是外。以下是其中一些最受欢迎的例子。

• 链下服务： SVM可以用于构建完全链下运作的服务，这些服务模拟Solana的交易处理协议。这对于模拟交易和模糊测试/测试等操作非常有用。实际上，这种架构可能会导致即将到来的RPC v2中的重大突破。

• 轻客户端： SVM可以支持创建欺诈证明，证明超大多数对无效状态转换的验证。这将使轻量级客户端能够高效运作，而无需处理每笔交易或维护完整的区块链状态。通过依赖欺诈证明，轻客户端可以确保网络的完整性，并以最小的资源要求验证交易的有效性，从而增强可扩展性和安全性。参见 SIMD 0065。

• 状态通道： 项目可以构建基于SVM的 状态通道，为各种令人兴奋和创造性的用例提供动力。通过状态通道，协议可以限制网络中允许的交易类型，并可以选择将连接限制为严格的点对点或基于方的连接。当通道最终关闭时，通道交易的最终结果将被发布到主链。一个经典的例子是代币支付通道，支持一种或多种代币，并发布通道参与者的最终余额。

• Rollup： 需要在没有完整验证器或共识协议的情况下执行交易或区块的网络可以利用SVM构建 Rollups。Rollups可以利用SVM作为执行层，将状态转换的“证明”在rollup中结算至主链。这种架构提供了可观的扩展潜力，因为SVM执行可以并行进行。

• Avalanche子网： 隔离的SVM执行层可以在Avalanche子网中使用，依靠Avalanche模块完成共识和网络连接。

• 扩展SVM： SVM可以扩展自定义协议合规功能。这些“扩展”SVM单元可以接入Solana验证器或上述列示的任何解决方案。

Anza对SVM的主要应用是Agave验证器内的交易处理。然而，如前所述，SVM接口已经与验证器运行时解耦，现在可以通过 官方规范 获取。

这个自包含的SVM，涵盖了交易处理和程序执行的所有复杂细节，现在已经封装在新发布的solana-svm Rust crate中。这个库，配备了解耦的接口，提供了一个多功能和可组合的SVM单元，能够支持上述用例以及更多。

Anza的SVM API

Anza的新solana-svm Rust crate为开发者提供必要的工具，以使用在Solana主网-beta上实时运行的组件构建SVM项目。这确保了整个栈经过了实战检验，并且保证了协议的兼容性。此外，该库经过精心调优以提升性能，并将随着网络的成熟持续获得优化。

以下是SVM API的详细分解。SVM的核心接口围绕TransactionBatchProcessor结构。

pub struct TransactionBatchProcessor<FG: ForkGraph> {
  /// Bank时隙（即区块）
  slot: Slot,
  /// Bank纪元
  epoch: Epoch,
  /// SysvarCache是从链上程序 
  /// 可访问的一组系统变量。它是由 
  /// 客户端代码（例如Bank）传递给SVM，并转发给MessageProcessor。
  pub sysvar_cache: RwLock<SysvarCache>,
  /// 进行交易批处理所需的程序
  pub program_cache: Arc<RwLock<ProgramCache<FG>>>,
  /// 内置程序ID
  pub builtin_program_ids: RwLock<HashSet<Pubkey>>,
}

实例化这些批处理器对象之一将允许你的应用程序处理一批清理后的Solana交易，利用前面部分中描述的所有下游Agave组件（BPF加载器、eBPF虚拟机等）。

处理交易批的主要API方法为load_and_execute_sanitized_transactions。它需要以下参数：

• callbacks：一个TransactionProcessingCallback特征实例，允许交易处理器召唤有关账户的信息，最重要的是为交易执行加载它们。

• sanitized_txs：一系列清理后的Solana交易。

• check_results：交易检查结果的列表。

• environment：交易批处理的运行时环境。

• config：自定义交易处理行为的配置。

该方法返回一个LoadAndExecuteSanitizedTransactionsOutput对象，下面将详细定义。

交易处理回调

SVM的下游消费者必须实现TransactionProcessingCallback特征，以便向交易处理器提供加载账户和检索其他相关信息的能力。

pub trait TransactionProcessingCallback {
  fn get_account_shared_data(&self, pubkey: &Pubkey) -> Option<AccountSharedData>;
  fn account_matches_owners(&self, account: &Pubkey, owners: &[Pubkey]) -> Option<usize>;
  fn add_builtin_account(&self, _name: &str, _program_id: &Pubkey) {}
}

由于API接受特征实现，消费者可以提供其自定义的加载账户、缓存等实现。这种灵活性允许项目根据其特定需求定制交易处理器，优化性能和资源管理。通过利用这些可定制的特征，开发者可以增强其应用程序的功能和效率，确保与SVM的无缝集成，同时完全控制关键过程。

交易处理环境

交易处理器要求消费者提供描述处理交易时使用的运行时环境的值，通过TransactionProcessingEnvironment对象传递。

• blockhash：用于交易批的区块哈希。

• epoch_total_stake：当前纪元的总质押。

• epoch_vote_accounts：当前纪元的投票账户。

• feature_set：交易批使用的运行时特征集。

• lamports_per_signature：按交易收费的每签名Lamports。

• rent_collector：用于交易批的租金收集器。

这些环境设置为交易提供了精确和受控的执行上下文，确保遵守特定的操作标准。通过配置这些参数，开发者可以模拟各种交易处理环境，以满足特定要求，优化性能并维护网络完整性。

交易处理配置

消费者可以通过TransactionProcessingConfig参数提供各种配置，以调整交易处理器的默认行为。

• account_overrides：封装被覆盖的账户，通常用于交易模拟。

• compute_budget：用于交易执行的计算预算。

• log_messages_bytes_limit：日志消息可消耗的最大字节数。

• limit_to_load_programs：是否限制为交易批加载的程序数量。

• recording_config：交易执行的录制能力。

• transaction_account_lock_limit：一笔交易可以锁定的账户最大数量。

这些配置使开发者能够在不改变整体环境的情况下微调交易处理器的具体操作方面。通过调整这些参数，开发者可以控制如日志限制、计算资源分配和账户处理等行为，确保交易处理器高效运行并满足其应用程序的具体需求。

交易处理输出

交易处理器的主要API方法——load_and_execute_sanitized_transactions——返回一个LoadAndExecuteSanitizedTransactionsOutput对象，封装处理交易批的结果。

• error_metrics：已处理交易的错误指标。

• execute_timings：交易批执行的时间数据。

• execution_results：指示交易是否已被执行的结果列表。

• loaded_transactions：已处理的已加载交易列表。

其他辅助工具和API方法

如果开发者希望，可以通过直接使用MessageProcessor API——主要是MessageProcessor::process_message来绕过处理交易批的步骤。这使得应用程序可以直接处理交易消息，而不是一批交易，但需要更多的设置。

此外，还提供了一些公共助手。

• account_loader::collect_rent_from_account：如果租金仍然启用，从账户中收取租金。

• account_loader::validate_fee_payer：检查付款账户是否有能力支付交易费。

• account_rent_state::RentState：用于处理账户租金状态（支付租金、免租等）的API。

• nonce_info：处理交易非ces的模块，包含特征和结构。

• program_loader::load_program_with_pubkey：通过其公钥加载程序。

展望未来

随着Solana网络的成熟和围绕这些令人兴奋的新SVM项目的社区不断壮大，Solana虚拟机将继续演变。SVM在验证器之外的使用将催生出新的用例，可能需要更高的性能和更强的可组合性。

此外，SVM项目的繁荣催生了Solana工具的新纪元。许多团队将开发自定义软件解决方案，以根据SVM满足其项目需求，以及全新的、前所未有的技术，包括在桥接、结算和证明等领域的突破。

整个行业都将从对开源、可消费工具的协同追求中受益匪浅——类似于Anza的SVM API。这个新兴的SVM团队生态系统应尽可能寻求合作，以增加创新，推动SVM的可能性界限。

• 原文链接： anza.xyz/blog/anzas-new-...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～