# 铭文补完计划

By [0xKJ](https://paragraph.com/@0xkj) · 2024-01-02

---

铭文在 2023年末的时候大火了一把，这一现象让众多链圈开发者跌破了眼镜。

从技术上来讲，铭文采用了链下计算（indexer）的方式，使得本来智能合约能力有限的比特币可以实现类似 ERC20 的功能。由于使用此类技术实现的功能有限，比如 ERC20 和 NFT 中常用的白名单技术，较难实现，所以市场以“公平发射”的名义给铭文技术注入了活力。

当热度开始消退，我们并不需要立刻否定这一技术。本文试着给铭文技术做一些变形，探讨使用铭文技术是否可以演化出更有意思的区块链技术。

**将规则放到链上**

诟病铭文技术的主要原因，来自于铭文系统的中心化。Indexer来自于一个第三方为比特币的交易赋予新的规则。如果多方使用不一样的规则解释铭文交易，就会出现不一样的结果。

一个显而易见的方式，就是将 indexer 程序写到链上。这在比特币中是较为昂贵的操作，如果在新设计的区块链上实现，则相对简单。

实现规则上链以后，我们会发现，铭文和区块链合约的差距在缩小。验证铭文交易变的去中心化了，因为规则是一样的。但是，剩下的差异是什么呢？

**先上链，再验证**

合约的规则在于，先验证，再上链。如果一个NFT数量有 100 个，那么前 100 个 mint 操作会成功，第 101 个mint则会失败。如果合约被正确的实现，第 101 个 mint 操作不应该收取交易手续费，也不会被打包进区块链。

铭文完全不同，是因为矿工在打包交易的时候，完全不用管 100 个 mint 名额是否耗尽，它只负责把交易打包进区块当中，而不执行交易内容，不去验证交易的合法性。

这对于矿工来说，降低了很大负担 1) 不需要运行虚拟机 2) 不需要保存全局状态。当然，负面影响也很大，用户发出的交易有可能不成功。比如用户只有10U，尝试转出15U，交易也会被矿工打包，手续费也会被收取，但是交易是无效的，用户必须自己验证转账是否成功。

**状态的延迟计算**

总结上面的铭文模式，先上链，再验证，我们得到了状态的延迟计算。

如果我们将现有区块链改成这样的模式，是不是可以大规模的提高区块链的吞吐量。由于这样的区块链在共识阶段完全不需要考虑状态大小和虚拟机执行效率，它的速度是极快的。

进一步，我们是不是可以在铭文智能合约上进行新的优化？

**专注合约计算**

大家知道，智能合约有全局状态，所有的节点都需要计算所有的交易输入。那么这个世界计算机的执行速度，是远远满足不了全人类的需求的。但是，有可能大部分的需求，会集中在 ERC20 转账合约，SWAP 以及其他 DeFi 应用。延迟计算是否意味着不需要对所有的共识过的交易进行计算，我们可以让一个节点专注于 USDT 的合约状态计算。

对于其他运算和存储能力较强的节点，可以做更强一点的状态计算：比如 SWAP，通常一个SWAP 需要两个它依赖的 ERC20 合约参与，所以一个节点可以专注于一个 SWAP 池子和它依赖的两个 ERC20 合约的状态计算。

**铭文智能合约区块链**

由此，我们设计了一个铭文技术驱动的智能合约的区块链。它的核心有两点，1) 把 indexer 程序规则放到链上 2) 先共识交易输入，后计算状态。

在实现和测试之前，我们不知道这个想法会发生什么？欢迎大家给一些点评。我们的后续思考 [铭文空间](https://mirror.xyz/0x719C8d75FAF8f1b117EA56205414892CAAb4A1b7/aqgDkgHhnJfQJj11dkwaa8wCBqpFjDDxMqKVdDWp3DI) 已经发布，欢迎继续阅读。

---

*Originally published on [0xKJ](https://paragraph.com/@0xkj/GbCdjizt5MpwAaCjvgZc)*