Token溯源问题

介绍什么是Token溯源问题以及为什么需要溯源。

在UTXO类型的合约中需要维护合约状态，合约状态需要通过溯源来实现，溯源状态需要从当前状态一路校验到创世状态，这个过程可能会导致状态无限膨胀。

我们举一个实际的例子：

FT，也就是Fungible Token同质化代币合约，是一种标准的代币合约。与以太坊的全局合约账本状态不同的是，在MVC中，它的合约状态是一个个UTXO，这些FT UTXO的状态包括代币的代号，创始信息，代币数量，所有权等多个信息。合约需要让有FT所有权的人可以解锁，而没有控制权（私钥）的人无法解锁并转账FT。控制权的问题很好解决，只要在合约中要求状态转移函数携带所有者的签名，并且签名正确才可以转移所有权。

但是有另一个问题仅仅通过所有权校验无法被解决，那就是token真实性的问题。由于UTXO自身是无状态的，它无法感知到自身之外的信息，除非将外部信息作为参数传递给函数。另外由于UTXO函数的代码和状态数据都是链上公开的，任何人都可以伪造一个一模一样的UTXO，这个UTXO的状态和代码都是正确的，但是它并不是真正的FT UTXO，如果允许这样的行为，那么意味着FT将会被任意超发，发行者和持有者将会受到重大损失。

在UTXO合约中理论上当然可以解决这样的问题，编写FT合约的时候，我们强制要求参数中携带当前FT的所有祖先交易信息（无论通过递归方式还是通过循环方式），然后逐一校验祖先交易的合法性，一直追溯到创始交易，能够完整形成溯源证据链条的才被当作合法交易。而刚才伪造的交易一定无法构建溯源证据链条。

我们可以看到，随着FT合约的换手或者交易次数的累加，校验祖先信息所携带的证据链数据越来越多，会导致解锁状态所需要的数据量越来越大，这个过程可能会导致状态无限膨胀，这个问题在UTXO合约中是一个非常严重的问题，严重影响token的可用性。

在一些竞争链解决方案中，token正确性一般通过两种方式来解决，一种是indexer共识，在一层utxo状态外再建立一套indexer机制，由indexer负责校验utxo是否合法，这是一种二层方案。二层方案最大的弊端就是无法保证和主链的一致性，比如说，brc20依赖indexer，你可以意外把brc20token当作普通satoshi花费掉，还有一些场景，layer1可以解锁的合约在indexer上并不合法，也就是说，共识不仅仅是layer1来保证，而是通过layer1和indexer共同保证，出bug和问题的可能性大大增加。另一种解决方法是使用oracle，这是一种利用外部可信数据源来保证token正确性的方案，但是oracle的问题是，它依赖于外部数据源，一旦外部数据源出现问题，那么token的正确性也会受到影响（oracle作恶问题）。

MVC使用了一种称为MetaTxid 的技术，可以在不引起交易膨胀的前提下，实现纯一层合约的溯源功能，不再依赖外部indexer和oracle来维护状态正确性，而是仅仅通过utxo本身以及部分前序交易就可以鉴别token合法性，也就是说token是否合法的信息，已经全部包含在合约内部了，不需要区块链外部状态辅助判断（这是layer1的一个重要特征）。