Hyperchain的智能合约执行是一个分布在验证节点（VP） 和非验证节点（NVP） 上的协同过程。简单来说，验证节点负责达成交易的共识顺序，而非验证节点则负责具体执行这些交易中的智能合约。
下图可以帮你更直观地理解从你发起一笔交易到合约状态最终上链的完整流程：
flowchart LRsubgraph A [1. 应用层（用户/客户端）]A1[构造交易与 InvokeBean] --> A2[提交交易到任意节点]endsubgraph B [2. 网络与共识层（验证节点 VP）]B1[交易传播与验证] --> B2[共识排序<br>（RBFT算法）]B2 --> B3[打包新区块<br>（仅含交易输入与顺序）]B3 --> B4[广播区块<br>（包含 InvokeBean）]endsubgraph C [3. 合约执行层（非验证节点 NVP）]B4 --> C1[NVP 接收共识后区块]C1 --> C2[执行 InvokeBean 中的逻辑]C2 --> C3[调用合约对象方法]C3 --> C4[访问与更新<br>持久化状态]C4 --> C5[执行结果签名]endsubgraph D [4. 状态提交与存储]C5 --> D1[多节点验证执行结果]D1 --> D2[更新全局账本世界状态]endA2 --> B
🤖 智能合约执行引擎
Hyperchain主要支持两种智能合约执行引擎，适用于不同场景：
| 引擎名称 | 编程语言 | 特点与适用场景 |
|---|---|---|
| HVM | Java | Hyperchain自研的高性能Java合约引擎，提供InvokeBean、合约生命周期钩子等企业级特性。 |
| HyperEVM | Solidity | 深度重构并兼容以太坊EVM的虚拟机，方便以太坊生态项目迁移和开发者复用现有代码。 |
下面我们以最典型的 HVM（Java智能合约） 为例，深入其执行细节。
⚙️ HVM智能合约的核心执行机制
HVM合约的执行围绕 InvokeBean 这一核心概念展开。它本质上是一段由应用开发者编写的Java业务逻辑，会在共识后的执行阶段被非验证节点（NVP）调用。
关键机制一：生命周期的精细控制
HVM为智能合约定义了清晰的生命周期，你可以在不同阶段插入自定义逻辑：
| 生命周期阶段 | 触发时机 | 典型用途 |
|---|---|---|
onCreate() |
合约对象创建后 | 权限检查、非持久化变量的初始化。 |
onPreCommit() |
状态提交前 | 对业务执行结果进行最终校验。 |
onCommitted() |
状态持久化后 | 触发事件通知、记录日志。 |
这些钩子函数让你能像管理一个企业应用一样管理合约状态。
关键机制二：高效的状态管理
在HVM中，你需要用 @StoreField 注解来显式标记哪些变量是需要持久化存储到区块链“世界状态”中的。对于复杂数据结构，HVM提供了原生的 HyperMap 和 HyperList 集合，它们针对区块链的频繁读写进行了深度优化。
关键机制三：面向接口的权限控制
HVM要求合约主体类必须实现一个或多个继承了 BaseContractInterface 的可见接口。应用在调用合约时，必须通过特定的接口进行。这种方式在编译器层面就实现了方法级的调用权限控制，例如，你可以只向合作伙伴开放查询接口，而保留管理接口。
🔧 给开发者的核心建议
- 业务逻辑分离：遵循HVM的最佳实践，将简单、稳定的原子操作（如转账）写在合约方法里，而将复杂、易变的业务流程（如包含多个步骤的贷款申请）写在
InvokeBean中。这样可以在不升级合约的情况下，通过更换InvokeBean来灵活调整业务逻辑。 - 谨慎使用持久化：只为必须记录在链上的核心状态添加
@StoreField注解。过度使用持久化存储会显著增加链的负担和成本。 - 利用类型安全：充分利用“合约可见接口”机制，它能带来编译时类型检查的安全性和代码的易维护性。
总而言之，Hyperchain的智能合约执行是其“共识与执行分离”架构的体现。这种设计将复杂的业务计算从关键的共识路径中剥离，从而在保证确定性和安全性的同时，获得了极高的灵活性和可扩展性。