企业官网建设流程全解析

从这一期开始，我们把视角切换到“当前 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 合约和交易调用才不会混乱。