从这一期开始我们把视角切换到“当前 IOTA”。也就是说不再只停留在早期 Tangle 的历史叙事而是开始理解今天的 IOTA 到底由哪些部分组成开发者应该如何看待它的整体架构。如果用一句话概括当前 IOTA可以这样理解当前 IOTA 已经不只是一个基于 DAG 思想的账本项目而是一个包含验证者网络、共识机制、对象模型、MoveVM、交易系统和开发工具链的可编程区块链基础设施。这一期先不深入写代码而是先把整体架构图谱搭起来。1. 从“DAG 账本”到“可编程区块链基础设施”早期 IOTA 最有代表性的标签是 Tangle。那时学习 IOTA重点是理解交易如何在 DAG 中相互引用交易如何参与确认为什么这种结构不同于传统区块链。但是随着 IOTA 的持续演进尤其是 Rebased 之后今天的 IOTA 已经不能只用“DAG 账本”来概括。当前 IOTA 更接近一个完整的 Layer 1 区块链基础设施。它不仅要维护账本还要支持智能合约、对象状态、链上资产、开发者工具、交易执行、gas 计量和生态应用。这意味着学习 IOTA 的重点发生了变化。早期学习重点是Tangle DAG Tip Selection 交易引用 无区块账本当前学习重点则变成验证者网络 共识机制 对象模型 MoveVM 交易生命周期 Gas Package Object CLI / SDK / Localnet这并不是说早期 Tangle 不重要。Tangle 仍然是理解 IOTA 历史和技术起点的重要概念。但如果要真正使用当前 IOTA就必须进一步理解 Rebased 之后的新架构。2. 当前 IOTA 可以分成哪些层为了便于理解可以把当前 IOTA 的架构粗略分成五个层次应用层钱包、浏览器、DApp、生态应用 开发层CLI、SDK、Localnet、API、工具链 执行层MoveVM、智能合约、Package 状态层Object、Owner、Coin、链上资产 共识与网络层验证者、交易排序、检查点、最终确认这不是官方严格分层而是为了学习方便做的逻辑拆分。其中最底层是网络和共识。它负责让不同节点对交易顺序和状态变化达成一致。再往上是状态层。当前 IOTA 使用对象模型来组织链上状态。很多链上内容都可以理解为对象例如代币对象、合约包对象、用户创建的业务对象等。执行层负责运行智能合约。IOTA 引入 MoveVM开发者可以使用 Move 语言编写链上逻辑。开发层提供和网络交互的工具例如命令行工具、SDK、本地网络、RPC 接口等。应用层则是最终用户直接接触的部分例如钱包、浏览器、DApp 和各类生态应用。这样分层之后IOTA 的整体结构会清晰很多底层负责共识上层负责开发和应用中间通过对象模型和 MoveVM 把状态与逻辑连接起来。3. 网络层节点、验证者和客户端在当前 IOTA 中网络不是由单个中心服务器维护的而是由一组节点共同参与运行。可以先区分三个角色普通节点、验证者和客户端。普通节点负责连接网络、同步数据、转发交易和提供查询能力。它们可以帮助用户读取链上状态也可以把交易提交到网络中。验证者是共识中的核心角色。它们负责参与交易排序、执行和确认让网络中的节点对账本状态达成一致。验证者需要承担更高的安全和性能要求。客户端则是用户或开发者使用的入口。比如命令行工具、钱包、SDK、DApp 后端都可以看作客户端。客户端不直接维护整个网络共识而是通过 RPC 或 SDK 与 IOTA 网络交互。可以简单理解为用户 / 开发者 ↓ 客户端工具 / SDK / 钱包 ↓ IOTA 节点 / RPC ↓ 验证者网络 ↓ 链上状态这个结构和很多现代公链类似。用户并不需要直接参与底层共识但用户提交的交易最终需要被验证者网络处理并写入链上状态。4. 共识层为什么交易需要被排序和确认任何分布式账本都必须解决一个核心问题不同节点如何对同一批交易形成一致判断假设两个用户几乎同时提交交易或者两笔交易都试图操作同一个链上对象网络就必须判断这些交易的有效性和顺序。如果没有统一规则不同节点可能看到不同状态账本就会分裂。因此共识层的任务就是让网络对交易顺序、交易结果和最终状态形成一致。在当前 IOTA 中并不是所有交易都以完全相同的方式处理。尤其是涉及共享对象的交易需要通过共识流程来确保所有节点对其顺序达成一致。这里先理解一个关键点共识不是为了“让交易看起来更复杂”而是为了保证多个节点在面对并发交易、冲突交易和共享状态时能够得到一致的账本结果。可以用一个简单例子说明。如果一个对象只属于某个用户并且只有这个用户能修改它那么交易处理相对简单。但如果一个对象是共享对象多个用户都可能同时操作它那么必须确定这些操作的顺序。例如用户 A 修改共享对象 X 用户 B 也修改共享对象 X如果两个操作顺序不同最终结果可能不同。因此网络必须通过共识决定谁先执行、谁后执行。这就是为什么智能合约平台必须认真处理共识和交易排序问题。5. 检查点给链上状态形成稳定参考在当前 IOTA 的交易生命周期中检查点是一个重要概念。检查点可以理解为网络周期性形成的稳定状态记录。它记录已经最终确定的一批交易和对应状态方便节点同步、查询和验证。如果把交易看作连续发生的事件那么检查点就像是在账本历史中不断打下的稳定标记。可以简单理解为交易流 → 共识处理 → 状态更新 → 形成检查点检查点的意义在于它为网络提供了一个稳定的参考点。节点可以基于检查点同步状态开发者也可以通过检查点观察网络进展。在本地启动 IOTA Localnet 时经常可以看到 checkpoint 相关日志。这些日志说明本地网络正在推进交易处理和状态记录。所以后面做本地网络实验时如果看到 checkpoint sequence 变化不要把它当成无意义日志。它实际上反映了网络正在不断形成新的稳定状态点。6. 状态层对象模型是理解当前 IOTA 的关键如果说 Tangle 是理解早期 IOTA 的关键那么对象模型就是理解当前 IOTA 的关键。在当前 IOTA 中链上状态不是简单理解为“某个账户里的一组变量”而是由一个个对象组成。每个对象都有自己的 ID、类型、所有者和数据。可以把对象理解为链上的“状态单元”。例如Coin 对象表示某个用户拥有的一笔代币 Package 对象表示发布到链上的智能合约包 普通业务对象表示开发者自定义的链上状态 共享对象表示多个用户都可能访问或修改的状态对象模型的好处是非常直观。现实中很多东西都可以抽象为对象资产、凭证、订单、身份、权限、游戏道具、投票记录、配置状态等。传统账户模型更像这样账户地址 → 存储变量对象模型更像这样地址 → 拥有对象 A 地址 → 拥有对象 B 地址 → 拥有对象 C也就是说一个地址可以拥有多个对象而每个对象都有独立身份和状态。这个思路对 Move 智能合约尤其重要。因为 Move 合约经常围绕对象展开创建对象、读取对象、修改对象、转移对象、销毁对象。因此从当前 IOTA 开发角度看理解对象比理解“账户余额”更重要。7. 执行层MoveVM 和智能合约当前 IOTA 引入 MoveVM 作为重要执行环境。MoveVM 用来执行 Move 智能合约。Move 是一种面向链上资产和对象管理的智能合约语言。相比传统合约语言Move 更强调资源安全、对象所有权和状态转移。从开发者角度看Move 合约通常由 module、struct 和 function 组成。可以简单理解为module合约模块 struct链上对象或数据结构 function可以被调用的链上逻辑例如一个最简单的 Counter 合约可能包含Counter 对象 create 函数 increment 函数 get_value 函数其中Counter 是对象create 用来创建对象increment 用来修改对象get_value 用来读取数值。这和传统 Web2 编程中“创建对象、调用方法、修改状态”的直觉有相似之处。但不同的是链上对象的创建、修改和转移需要遵守严格的所有权、权限和交易规则。因此学习 IOTA Move 合约时不能只看函数语法还要重点理解函数操作了哪些对象以及这些对象的所有权如何变化。8. 交易层一笔交易到底做了什么在 IOTA 中交易不是简单的“转账记录”。一笔交易可能包含对象输入、函数调用、gas 支付、对象修改和结果输出。可以把交易理解为一次链上状态转换。交易执行前链上有一组对象状态。交易执行后这些对象可能被修改、转移、创建或销毁。可以用下面的方式理解交易输入 - 调用者地址 - Gas 对象 - 被操作对象 - Move 函数参数 交易执行 - 检查权限 - 检查对象所有权 - 执行 Move 函数 - 计算 gas - 生成结果 交易输出 - 更新后的对象 - 新创建的对象 - 被转移的对象 - 交易执行状态因此一笔 IOTA 交易的核心不是“在账本上写一行记录”而是“按照规则改变链上对象状态”。这个理解非常重要。后面学习 PTB也就是 Programmable Transaction Block 时会发现一笔交易还可以组合多个操作。例如拆分 coin、调用 Move 函数、转移对象等。所以当前 IOTA 的交易模型可以先这样理解交易是由用户发起、由网络验证和执行、最终改变链上对象状态的一次操作。9. Gas为什么需要资源计量早期 IOTA 经常强调无手续费但当前 IOTA 作为可编程智能合约平台需要更明确的资源计量机制。这是因为智能合约执行会消耗计算资源链上状态存储会占用存储资源验证者维护网络也需要成本。如果交易完全没有资源约束系统就容易被垃圾交易或恶意合约拖垮。Gas 的作用就是衡量和约束交易执行成本。可以简单理解为Gas 执行交易和使用链上资源所需的成本计量Gas 并不只是收费工具它还有三个作用。第一防止资源滥用。如果每笔交易都需要消耗 gas攻击者就不能无限制地提交垃圾交易。第二衡量执行成本。复杂交易和简单交易消耗资源不同gas 可以反映这种差异。第三支持网络可持续运行。验证者和网络基础设施需要长期运行资源计量有助于维持系统安全和稳定。因此从当前 IOTA 角度看gas 是智能合约平台的基本组成部分。10. 开发工具链CLI、SDK、Localnet 和 Explorer理解架构之后还需要知道开发者如何与 IOTA 交互。常见入口包括 CLI、SDK、Localnet 和 Explorer。CLI 是命令行工具。开发者可以用它创建地址、切换网络、查看对象、发布合约、调用函数和提交交易。SDK 是开发工具包。它适合在应用程序中集成 IOTA 功能例如在后端服务或前端 DApp 中构造交易、签名和查询链上状态。Localnet 是本地网络。开发者可以在本机启动一个 IOTA 网络用于测试合约、调试交易和反复重置状态。Explorer 是区块链浏览器。它适合查看交易、对象、地址、package、checkpoint 等链上信息。可以简单理解为CLI适合学习和手动操作 SDK适合开发应用 Localnet适合本地测试 Explorer适合查看链上状态后续学习 IOTA 时CLI 和 Localnet 会非常重要。因为它们能帮助我们把抽象概念变成可观察的实验结果。11. 当前 IOTA 架构的整体理解到这里可以把当前 IOTA 的整体运行过程串起来。用户通过钱包、CLI 或 SDK 构造交易。交易被提交到 IOTA 网络。网络检查交易签名、对象所有权、gas 和参数。涉及共享对象的交易进入共识流程。交易被排序并执行。MoveVM 根据合约逻辑修改对象状态。执行结果写入链上。网络形成检查点。用户可以通过 CLI、SDK 或 Explorer 查询结果。用一条线表示就是用户 / 开发者 ↓ CLI / SDK / 钱包 ↓ 提交交易 ↓ 验证签名、Gas、对象权限 ↓ 共识排序 ↓ MoveVM 执行 ↓ 对象状态更新 ↓ Checkpoint ↓ 查询交易和对象这条流程就是理解当前 IOTA 的基础。如果后面遇到命令报错也可以沿着这条流程排查是客户端构造交易错了是地址或网络环境错了是 gas 不够是对象 ID 不对是对象所有权不对是 Move 函数参数不匹配是共享对象需要共识是交易执行失败这样排查会比单纯看报错更有方向。12. 小结这一期主要搭建了当前 IOTA 的架构视角。早期 IOTA 的核心关键词是 Tangle、DAG 和交易引用而当前 IOTA 的核心关键词则变成验证者、共识、对象模型、MoveVM、交易、gas 和开发工具链。从整体上看当前 IOTA 可以理解为一个可编程区块链基础设施。底层通过验证者网络和共识机制维护账本一致性中间通过对象模型组织链上状态执行层通过 MoveVM 运行智能合约开发者则通过 CLI、SDK、Localnet 和 Explorer 与网络交互。因此学习当前 IOTA 的关键不是只记住某一个概念而是建立完整链路交易如何提交 对象如何被操作 Move 合约如何执行 共识如何保证顺序 状态如何最终确认 开发者如何查询结果下一期我会专门讲对象模型。因为在 Rebased 之后Object、Owner、Package 和 Coin 是理解 IOTA 开发的基础。只有先理解对象模型后面学习 Move 合约和交易调用才不会混乱。