文章原标题为 铭文补完计划 和 英文翻译，这里为了更好的理解，改为 使用铭文思路对智能合约改进。
铭文现象
铭文在 2023年末的时候大火了一把，这一现象让众多链圈开发者跌破了眼镜。
从技术上来讲，铭文采用了链下计算（indexer）的方式，使得本来智能合约能力有限的比特币可以实现类似 ERC20 的基本功能。由于使用此类技术实现的功能有限，比如 ERC20 和 NFT 中常用的白名单技术，较难实现，所以市场以“公平发射”的名义给铭文技术注入了活力。
从不理解铭文（币圈理解为“公平发射”），到理解比特币铭文（实际上为矿工创造了很多额外的挖矿收入，从而得到了矿工的支持），到其他EVM链甚至Non-EVM链的跟进（理解为蹭热度）。大众对于铭文的理解，更多偏向于短期挣快钱的炒作。
当热度开始消退，当大家在思考铭文还能持续多久的时候，我们从铭文技术思路中，看到了对区块链底层技术发展的可取之处。本文试着给铭文技术做一些变形，探讨使用铭文技术是否可以演化出更有意思的区块链技术？
前置知识
阅读本文需要对区块链和智能合约底层有一定的了解。
我们使用状态机来建模区块链和智能合约。状态机接收一个输入，通过状态转换函数定义的规则，转换为下一个状态。
- 其中，输入就是被打包进一个区块的所有交易。
- 状态转换函数可以是区块链的规则，比如转账，也可以通过智能合约自定义规则。铭文的 indexer 也是一种状态转换函数。
- 状态机的状态，对应着区块链和智能合约的全局状态。如果所有的全局状态都被删除，但是所有历史交易都是被保存的，就可以通过交易和状态转换函数，重建所有状态。
将规则放到链上
诟病铭文技术的主要原因，来自于铭文系统的中心化。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 合约的状态计算。对于其他节点，可以做与 USDT 无关的状态计算，比如 USDC，或者 NFT 的状态。
铭文智能合约区块链
由此，我们设计了一个铭文思路驱动的智能合约的区块链。它的核心有两点，1) 把 indexer 程序规则放到链上 2) 先共识交易输入，后计算状态。
在实现和测试之前，我们不知道这个想法会发生什么？我们预期它可以改进智能合约的性能瓶颈，由于不需要在共识过程中运行智能合约，区块链的处理能力会被解放，并且全局状态爆炸问题也可以得到解决。
欢迎大家给一些点评和反馈。
