如果只看早期介绍，IOTA 很容易被理解成一个“基于 DAG 的无区块账本”。这个理解有一定道理，但并不完整。因为 IOTA 的技术路线经历了多次重要演进，从最初的 Tangle，到 Coordinator，再到 Coordicide、Stardust、IOTA 2.0 和 Rebased，IOTA 的架构目标和开发方式都发生了很大变化。
这一期的重点不是深入分析每一个协议细节，而是先把 IOTA 的技术演进脉络理清楚：它为什么要不断调整？每个阶段主要解决什么问题？今天学习 IOTA 时，应该如何看待这些历史阶段？
1. 早期 IOTA：从 Tangle 开始
IOTA 最早形成辨识度的地方，是它提出了 Tangle 这一基于 DAG 的账本结构。
在传统区块链中，交易通常被打包进区块，区块再按照时间顺序连接成链。IOTA 早期没有采用这种结构，而是让交易本身成为图中的节点。新交易加入账本时，需要引用并确认之前的交易，交易之间逐渐形成一张有向无环图。
这一设计带来了几个鲜明特点：
第一，没有传统意义上的区块。
交易不需要先进入区块，再等待区块被确认。
第二，没有传统意义上的矿工。
发送交易的过程本身也参与确认旧交易。
第三，强调无手续费。
这与 IOTA 早期面向机器经济和高频小额交互的设想有关。
第四，强调并发扩展潜力。
由于账本结构不是一条线，而是一张图，IOTA 希望通过 Tangle 支持更多交易并行加入网络。
所以，早期 IOTA 的技术叙事可以概括为：
传统区块链：交易 → 区块 → 链 早期 IOTA：交易 → 引用交易 → Tangle这一阶段的核心问题是：能否用 DAG 结构替代传统区块链结构，构建一个更适合高频、轻量交互的分布式账本？
2. Coordinator：早期网络的安全辅助机制
虽然 Tangle 的设计很有特点，但早期 IOTA 面临一个现实问题：当网络规模还不够大、交易活跃度还不够高时，单靠交易之间的自组织引用关系，很难直接保证整个网络的安全性和稳定性。
因此，早期 IOTA 引入了 Coordinator。
Coordinator 可以理解为一种网络安全辅助机制。它会定期发布特殊确认信息，帮助网络判断哪些交易被认为是有效的、被确认的。对早期网络来说，Coordinator 有助于防止攻击、稳定账本状态、保护网络运行。
从工程角度看，Coordinator 的出现并不难理解。一个新型分布式账本在早期阶段往往面临冷启动问题：网络参与者数量有限，交易活动不足，攻击成本相对较低。引入一个临时的安全辅助组件，可以帮助网络先稳定运行。
但是，Coordinator 也带来了一个明显问题：中心化争议。
如果交易确认需要依赖 Coordinator，那么系统就很难被称为完全去中心化。即使 Coordinator 的设计初衷是保护网络，它仍然意味着网络中存在一个具有特殊作用的组件。
因此，Coordinator 是 IOTA 早期发展中一个很典型的矛盾点：它在工程上提高了早期网络安全性，但也削弱了系统的去中心化程度。
3. Coordicide：去掉 Coordinator 的目标
正因为 Coordinator 带来了中心化争议，IOTA 后来提出了 Coordicide。
Coordicide 这个词可以简单理解为“去除 Coordinator”。它不是某一个单独功能，而是 IOTA 为了实现无 Coordinator 网络而进行的一系列协议改造目标。
如果说 Coordinator 阶段的核心问题是“如何让早期网络安全运行”，那么 Coordicide 阶段的核心问题就是：
如何在没有 Coordinator 的情况下，让 IOTA 网络依然能够安全、稳定、去中心化地运行？
这背后涉及很多复杂问题：
第一，交易冲突如何处理？
如果两笔交易互相冲突，网络需要有规则判断哪一笔有效。
第二，账本状态如何达成一致？
没有中心化确认者后，节点之间需要通过协议形成一致判断。
第三，如何防止女巫攻击？
攻击者可能伪造大量身份或节点影响网络判断，因此系统需要抗女巫机制。
第四，如何控制拥塞？
当大量交易同时进入网络时，系统需要控制资源使用，避免垃圾交易拖垮网络。
第五，如何实现最终确认？
DAG 结构中的交易确认不是简单看后续区块深度，因此需要新的确认规则。
因此，Coordicide 的本质不是“删除一个组件”这么简单，而是用一整套去中心化协议机制替代 Coordinator 原本承担的安全和确认功能。
这个阶段对 IOTA 很重要，因为它代表了 IOTA 从“有中心化辅助的 DAG 网络”走向“真正去中心化 DAG 网络”的尝试。
4. IOTA 2.0：围绕去中心化 Tangle 的系统化设计
在 Coordicide 目标之下，IOTA 逐渐形成了 IOTA 2.0 的设计方向。
IOTA 2.0 可以理解为对无 Coordinator 版本 IOTA 的系统化设计。它不只是单纯去掉 Coordinator，而是围绕共识、拥塞控制、女巫防护、确认机制、节点激励等问题进行整体重构。
从学习角度看，可以把 IOTA 2.0 理解成 IOTA 对早期 Tangle 方案的一次系统升级。
早期 Tangle 解决的是账本结构问题：如何不用区块链，而用 DAG 组织交易。
IOTA 2.0 进一步解决的是协议完整性问题：如何让这个 DAG 网络在没有 Coordinator 的情况下仍然可靠运行。
所以，IOTA 2.0 的重点不只是“还是不是 DAG”，而是围绕以下问题展开：
DAG 账本结构 + 去中心化共识 + 抗攻击机制 + 拥塞控制 + 交易确认 + 节点参与规则 = 无 Coordinator 的 IOTA 网络这一阶段体现了 IOTA 的一个重要思路：DAG 只是账本结构，真正要构建可运行的公链，还必须补齐共识、安全、资源控制和激励机制。
5. Stardust：从单纯转账走向更强的资产表达能力
在 IOTA 技术演进中，Stardust 是另一个重要阶段。
如果说 Coordicide 和 IOTA 2.0 更关注去中心化和共识问题，那么 Stardust 更突出的是账本能力和资产表达能力的增强。
Stardust 带来了更丰富的代币化能力和链上资产能力，使 IOTA 不再只是处理基础代币转账，而是可以支持更多类型的数字资产和链上对象表达。
从学习角度看，可以这样理解 Stardust 的意义：
早期 IOTA 更关注“如何组织交易”。
Stardust 开始进一步关注“账本上可以表达什么”。
也就是说，账本不仅要能记录转账，还要能表达更复杂的资产关系、所有权关系和状态变化。
这一步非常关键。因为一个分布式账本如果只能完成基础转账，那么它的应用范围会比较有限。要支持更丰富的应用，就需要让账本具备更强的资产表示能力和状态表达能力。
因此，Stardust 可以看作 IOTA 从“交易账本”向“资产账本”扩展的重要阶段。
6. Rebased：IOTA 技术路线的一次重大转向
如果说 Stardust 增强了 IOTA 的资产表达能力，那么 Rebased 则代表了 IOTA 技术路线的一次更大转向。
Rebased 的一个重要变化，是 IOTA 引入 MoveVM，并从原来的 UTXO 模型转向对象模型。这意味着 IOTA 不再只是围绕传统 UTXO 风格的输出和解锁条件来表达状态，而是进一步采用更适合智能合约和复杂应用的对象模型。
这一步对开发者来说非常重要。因为从 Rebased 开始，学习 IOTA 就不能只停留在 Tangle、DAG 和交易引用关系上，还需要理解：
第一，MoveVM 是什么。
MoveVM 是执行 Move 智能合约的虚拟机。
第二，对象模型是什么。
链上状态可以被组织为一个个对象，每个对象有自己的 ID、所有者和数据结构。
第三，Package 是什么。
智能合约发布后，会成为链上的 package 对象。
第四，Gas 是什么。
交易执行需要消耗资源，因此需要 gas 机制来衡量和约束计算、存储等资源。
第五，开发工具链是什么。
开发者需要使用 CLI、SDK、钱包、浏览器、Localnet 等工具与 IOTA 网络交互。
也就是说，Rebased 之后的 IOTA 更像一个完整的智能合约基础设施，而不仅仅是一个 DAG 账本实验。
可以这样概括：
早期 IOTA：Tangle / DAG / 无区块账本 Stardust：资产表达能力增强 Rebased：MoveVM + 对象模型 + 智能合约平台这也是今天学习 IOTA 必须重视 Rebased 的原因。
7. 从 UTXO 到对象模型：理解 Rebased 的关键
要理解 Rebased，必须先理解 UTXO 模型和对象模型的区别。
UTXO 是 Unspent Transaction Output，即未花费交易输出。比特币就是典型的 UTXO 模型。简单来说，一个用户的余额不是存放在账户里的一个数字，而是由许多尚未花费的输出组成。花费时，用户把已有输出作为输入，再产生新的输出。
UTXO 模型适合表达简单、清晰、可验证的资产转移。但如果要表达复杂智能合约、共享状态、动态资产和复杂权限控制，UTXO 模型就会显得不够直接。
对象模型则更像是把链上状态组织成一个个对象。每个对象有自己的唯一 ID，可以有所有者，也可以保存结构化数据。智能合约函数可以创建对象、修改对象、转移对象或者销毁对象。
可以简单对比：
UTXO 模型： 输入若干旧输出 → 产生若干新输出 对象模型： 读取对象 → 修改对象 → 转移对象 → 创建新对象对于开发者来说，对象模型更加直观。因为很多现实中的链上应用，本质上都可以被理解为对象的创建、更新和转移。例如代币、NFT、权限凭证、订单、游戏道具、身份记录等，都可以映射为对象。
这也是 Rebased 后 IOTA 更强调 Move 和对象模型的原因。
8. 从“无手续费”到“低费用与可持续性”
早期 IOTA 经常强调无手续费，这是它区别于传统区块链的重要特点之一。
但是，随着 IOTA 演进为更完整的智能合约平台，系统需要重新思考费用和激励问题。
一个可持续运行的公链系统需要回答几个问题：
第一，谁来维护网络？
验证者运行节点需要硬件、网络和运维成本。
第二，如何防止资源滥用？
如果交易完全没有成本，攻击者可能发送大量垃圾交易，占用网络资源。
第三，如何激励验证者？
如果没有合理激励，长期维持高质量验证者集合会变得困难。
第四，如何支持复杂智能合约？
复杂合约执行会消耗计算和存储资源，需要有资源计量机制。
因此，Rebased 后的 IOTA 不再简单延续早期“完全无手续费”的叙事，而是转向更低摩擦、更可持续的费用和激励设计。这里的关键不是单纯从“无费”变成“收费”，而是系统定位发生变化：IOTA 要支持更复杂的智能合约和链上应用，就需要更清晰的资源计量、验证者激励和网络安全机制。
这也说明，IOTA 的演进不是简单推翻过去，而是在不同阶段面对不同问题。
早期阶段更关注高频、小额、轻量交互。
后续阶段更关注去中心化、安全性、可编程性和生态可持续性。
9. 为什么 IOTA 会不断调整技术路线？
从外部看，IOTA 的技术路线变化很多：Tangle、Coordinator、Coordicide、Stardust、IOTA 2.0、Rebased。初学者很容易困惑：为什么一个项目要经历这么多变化？
其实可以从三个层面理解。
第一，早期愿景很激进。
IOTA 一开始就想做不同于传统区块链的账本结构，这使得它必须探索很多新问题。DAG 账本、无矿工、无手续费、机器经济，这些方向本身就比复制传统区块链更难。
第二，工程实现需要阶段推进。
一个去中心化网络不可能只靠概念运行。它需要处理安全、确认、拥塞、存储、节点激励、开发工具、生态兼容等大量工程问题。每一个问题都会推动架构调整。
第三，公链竞争环境发生变化。
早期公链主要关注转账和账本结构，后来智能合约、DeFi、NFT、RWA、跨链和开发者生态变得越来越重要。IOTA 如果继续停留在单纯 DAG 账本层面，就很难支撑更广泛的应用需求。
因此，IOTA 的演进可以理解为从“账本结构创新”走向“完整智能合约平台”的过程。
10. 学习 IOTA 时应该如何看待这些阶段？
学习 IOTA 时，最重要的是不要把不同阶段混在一起。
早期 Tangle 适合用来理解 IOTA 的起点。
它回答的是：IOTA 为什么不是传统区块链？
Coordinator 适合用来理解 IOTA 早期网络的现实约束。
它回答的是：早期网络如何在不够成熟时保持安全运行？
Coordicide 和 IOTA 2.0 适合用来理解 IOTA 的去中心化追求。
它们回答的是：如何在没有 Coordinator 的情况下运行 DAG 网络？
Stardust 适合用来理解 IOTA 的资产能力扩展。
它回答的是：IOTA 如何从基础转账走向更丰富的链上资产表达？
Rebased 适合用来理解当前 IOTA 的开发者入口。
它回答的是：今天开发者如何基于 IOTA 编写智能合约、管理对象和构建应用？
可以用下面这条主线概括：
Tangle：账本结构创新 Coordinator：早期安全辅助 Coordicide：去中心化目标 IOTA 2.0：无 Coordinator 协议设计 Stardust：资产能力增强 Rebased：MoveVM 与对象模型这条线理清楚后，学习 IOTA 就不会混乱。
11. 小结
这一期主要梳理了 IOTA 的技术演进路线。
IOTA 最早从 Tangle 出发，用 DAG 结构替代传统区块链的线性区块结构。为了保障早期网络安全，IOTA 引入了 Coordinator，但这也带来了中心化争议。随后，IOTA 提出 Coordicide，希望去除 Coordinator，实现真正去中心化的 Tangle 网络。IOTA 2.0 可以看作围绕这一目标形成的系统化协议设计。
后来，Stardust 增强了 IOTA 的资产表达能力，使其从基础转账账本进一步走向更丰富的链上资产系统。再往后，Rebased 成为 IOTA 技术路线中的重大转向，引入 MoveVM 和对象模型，使 IOTA 进一步具备智能合约平台能力。
因此，今天学习 IOTA，既要理解早期 Tangle 的思想，也要理解当前 Rebased 后的架构。前者解释 IOTA 从哪里来，后者决定开发者今天应该怎么使用 IOTA。
下一期，我会进入当前 IOTA 的整体架构，重点梳理：网络层、共识层、执行层、对象模型和开发工具链之间是什么关系。
