详解everiToken“基于通证”的事务模型

everiToken采用“基于通证”的事务模型（'Token-based' Transcation Model）来处理“非同质化通证”(NFTs)。

简而言之, everiToken会记录任何一个通证所有权及更改记录, 并为之创建独立的存储空间。通过这种方式，everiToken可以轻松实现分片和多核并行处理，因为每个通证的空间相对独立。不同Token之间的操作可以并行处理，没有冲突。这种设计带来了高性能，甚至可以通过分片以及增加CPU数量大幅提升TPS。

“基于通证”的事务模型是由everiToken几个核心团队成员蔡恒进教授、王昊、程希冀提出并落地，被证明在everiToken上非常适合处理非同质化通证（NFTs）。相关的论文已经提交IEEE并正在审核中。

技术细节

everiToken可以被视为一种状态机, 只有在每个不可逆区块上执行操作时才会改变其状态。

对于“基于通证”的事务模型的公链，如everiToken, 它可能将数据库分为两部分，一个是 “通证数据库（Token DB）”, 另一个是“区块数据库（Block DB）”。对于“基于通证”的事务模型，“通证数据库（Token DB）”用来存储、管理所有与非同质化通证相关的事物；而“区块数据库（Block DB）”用于存储元素区块数据。

“通证数据库（Token DB）”和 “区块数据库（Block DB）”都属于版本化的数据库, 可用于在区块被逆转时快速回滚。

1

“通证数据库（Token DB）”

“通证数据库（Token DB）”是一个索引型数据库, 可用于快速查找区块链的最新状态, 例如通证的所有权以及链上某账户同质化通证的余额。

“通证数据库（Token DB）”也是键值型数据库。键（Key）代表通证的ID，值代表当前通证的所有权。由于这种数据库只能添加，每一个键可以对应多个值，但是最近的值代表当前通证的所有权状态，其它值只用历史参考以及回滚。对于每个通证来说，everiToken将分配一个单独的存储空间用于存储包括所有权更改记录等数据，就像一条单独的链。

链上最先初始化地便是所有权值。当用户执行交易（包括转移通证的动作），新的所有权将会附加在后面。如果区块被逆转，旧版本可用于回滚数据，最终被当做垃圾处理。

由于每个通证都有独立的数据空间，everiToken可以轻松实现分片。例如，如果一个节点由两台电脑组成，那么每台计算机可以只处理一半的通证。假如有100个通证，1-50的通证将由第一台电脑处理，剩下的通证将由第二台电脑处理。改变通证的所有权不影响其他通证，两台电脑可以并行处理。

2

“区块数据库（Block DB）”

“区块数据库（Block DB）”负责存储链上所有原始不可逆块。每个块都存储所有详细信息, 包括执行操作的名称、参数、块上的签名以及一些额外信息。

下图显示了两种数据库如何协同处理非同质化通证（NFTs）:

与其他事务模型对比

1

UTXO

在UTXO模型中, 每个通证所有者要转移通证，首先要对之前交易以及拥有者的公钥哈希后进行数字签名，然后将其添加到通证的尾部。该机制本质上是连续的输入和输出账本，通证的所有者实际上并不直接拥有通证, 而是拥有特定数量的通证的输出值, 然后在签名之后，作为输入传给新的所有者，循环往复。

如图所示, UTXO非常适合处理双花问题, 因为任何输入都只能使用一次. 但它也有一些缺点:

BTC不是非同质化（NTFs）类型通证, 它是同质化类型通证（FT）。为每个UTXO保留唯一ID是没有意义的。（everiToken将这一特性用于非同质化类型通证。）

UTXO是一次性的。存储大量UTXO账户会导致计算资源和磁盘容量的浪费。

2

账户模型

“基于账户”的事务模型就像银行一样，用户在银行中创建一个帐户，然后将钱存入帐户。会出现银行更改用户帐户余额的现象。这种事务处理方式比UTXO更为高效，但是它只更改数据库中的数字，显然不适合非同质化通证（NFTs）。

而且，“基于账户”的事务模型不适用于分片，因为转移通证需要两步：第一，修改旧持有人的帐户数据；第二，修改新持有人的帐户数据。为了安全起见，您必须将两个步骤合为一个原子操作，但在分片环境中，这种方式很难实现并且性能很差。但在基于令牌的事务模型中，只有一个步骤，即附加令牌的新所有权。但是在“基于通证”的事务模型中，只须向通证添加新的所有权者即可。