由于当前智能合约多为串行继续执行和串行检验，造成性能一般，无法符合业务市场需求。百度超级链明确提出了一种新的区块链数据模型：XuperModel。基于这样的底层数据模型，XuperChain可以用于多核计算能力来同时继续执行和检验智能合约，大大提高效率。

本期超级链学院微课堂的主题就是“为你揭露智能合约的高所发面纱——XuperModel”！明星讲师超哥先来为你划出重点啦，本次课程不会讲清楚以下几点：1. 底层的数据模型对于区块链系统的重要性2. 超级链独有数据模型——XuperModel编撰3. 智能合约的性能瓶颈问题超级链如何解决问题4. XuperModel与其他数据模型的详点5. XuperModel为开发者获取了哪些能力Q1：数据模型对一个区块链系统而言最重要么？十分最重要。数据模型反映了一个区块链系统对数据的的组织方式，归属于核心设计，是其区别于其他系统的最重要特征。例如，比特币的UTXO，以太坊的MPT，HyperLedger Fabric的读取集，都是大家所熟悉的区块链数据模型。

Q2：超级链的数据模型是什么？超级链的数据模型是XuperModel，是基于UTXO模型更进一步一般化、抽象化而来的一种通用数据模型。经典的UTXO模型不能叙述数字资产的移往，而XuperModel可以叙述由智能合约继续执行而引发的数据更改， 同时又没壮烈牺牲丢弃UTXO所发性能好的优点。Q3: XuperModel和UTXO比起，相同点和不同点是什么？相同点是每笔交易都会提到和它涉及的之前再次发生的交易。只不过，UTXO模型中，交易的提到关系指出了资金的来源，而XuperModel中不存在两种提到关系：一种是阐释数字资产的来源，另一种是阐释数据的版本倚赖关系。

两种提到关系分别用TxInput和TxInputExt两个字段来回应。当交易中只不存在数字资产移往时，XuperModel就发育为UTXO模型。

Q4: 如何告诉智能合约继续执行倚赖的数据版本呢？在超级链中通过实继续执行来确认智能合约倚赖的数据版本。在实继续执行阶段，超级链内核不会为每个智能合约的催促结构一个“沙箱”环境，其发动的加载和载入催促都会被内核捕捉，从而可以记录到它加载的数据的版本和将要载入的数据内容。

Q5: 其他节点如何检验智能合约的正确性呢？每个交易都是自描述的，其他节点可以根据交易中的提到信息复原智能合约的“沙箱”环境，复原的过程中必须检测其倚赖的资产来源和数据版本否依然有效地。如果是过期的版本，或者资产早已被其他交易用于，那么复原沙箱告终。

如果复原环境顺利，接下来就不会调用虚拟机去继续执行这个合约，继续执行合约的过程是Lock-Free的，因此所发性能好。最后，在内核数据生效时，不会Double-Check提到关系的有效性，最后生效到状态机里面。Q6: 那么各个节点如何最后达成协议完全一致的状态呢？主要是解决问题辨别冲突的问题。

大家应当都用过git，当我们运营git pull的时候，常常不会再次发生你的本地内容和他人冲突，而必须手动插手解决问题冲突。XuperModel的原理很类似于，数据的唯一标识是Bucket + Key， 其中Bucket对应合约名字，网卓新闻网，Key对应读取的变量名。如果多个交易都改动了同一个数据，且他们不不存在父子提到的话，那么就是互相冲突的。

在XuperModel中，区块中的交易享有更高优先权，可以返滚掉和它冲突的未证实交易。Q7: 超级链中的数据底层是怎么存储的呢？底层有两个DB，一个DB记录了账本，另一个DB确保着状态机。

数据每个版本的更改的详尽内容都是记录在账本中的，状态机中只是为每个变量存储了一个Hash指针，这个Hash指针可以定位到账本中的某个交易的某项输入，反映的是这个变量的近期内容。Q8： 这种模型是反对多版本的么？是的。配置文件情况下状态机中的变量的Hash指针式指向近期版本的，通过交易的TxInputExt字段，可以往前回溯到早的版本。

这种多版本机制的优势是对递归查找、区间查找也很友好关系，可以防止因迭代违宪版本而产生的IO支出。同时，超级链节点也获取了账本偏移的功能，类似于“git checkout”， 可以转换到历史上给定区块对应的状态。

Q9： XuperModel和Fabric的数据模型有什么详？首先，Fabric的数据模型是不内置数字资产移往的叙述的， 而XuperModel则是UTXO模型的一般化，天然反对了数字资产移往的场景。其次，Fabric的数据模型中，数据的版本是初始化到区块高度的，因此对同一个Key的多次改动无法再次发生在一个区块，就造成他无法构建“Read Your Own Update”的场景。XuperModel中数据的版本是必要提到前置交易的，因此可以立刻生效，在同一个区块中可以包相关联的对同一个数据的一系列改动不道德。Q10： 对于应用于开发者而言，基于XuperModel可以取得哪些能力？首先，取得了天然的数据追溯能力。

智能合约中的变量不会随着合约的调用大大地再次发生更改，由于XuperModel确保了每次更改的前一个版本的哈希指针，可以顺藤摸瓜获得之前这个合约变量的所有版本。例如，我们之前曾多次有篇小短文讲解了如何用200行智能合约代码构建一个可追溯的文件系统：https://mp.weixin.qq.com/s/8CWKX92WRkeG6MMXkPZmVQ。

其次， XuperModel 解法耦了智能合约的计算出来和存储，使得智能合约的继续执行可以利用上CPU多核的算力，提高整体的性能。共享完结后，群里也辈出了一些精彩问题，摘部分共享给各位。

问：「 直说XuperModel和超级链说的DAG有什么关系？」问：DAG是有向无环图，是多个交易根据倚赖关系包含的。那么，如何建构这种倚赖关系呢？就必须利用XuperModel的能力为智能合约继续执行结构一个沙箱，为其捕捉到倚赖关系，最后把这些交易串一起，构成DAG。问：「XuperModel是每个节点仍然保持着一张大图还是每个交易都必须追溯？如果是前者，那账本大了之后新的节点重新加入必须花费相当大时间，而且账本大了这个表会很占到内存，该如何解决问题？」问：在超级链里面，要想要结构交易，必须再行“实继续执行”，实继续执行就锚定了交易倚赖的数据版本，支出相等于在DB中的随机坎（点坎）。状态机DB配置文件是leveldb，不必须宽派驻内存。

问：「那是每个交易数据之中就写出好了前向的交易，必须实继续执行的时候展开迭代搜寻，还是在leveldb中专门保持了一种联系表格？」问：前半句对。交易的TxInputExt是这样的：（ref_txid, ref_offset）, 根据ref_txid可以反查到账本中的这个被倚赖的交易内容，通过ref_offset可以获得这个交易的TxOutput[ref_offset]这条数据内容。因此不必须迭代。

问：「 两个DB如何确保事务 」问：超级链中，一个DB是账本，相等于binlog， 一个DB是状态机，里面有个Hash指针指向最后一次继续执行顺利的区块。状态生效的粒度是区块，通过Batch写出确保原子性，只要当区块中的交易数据更改全部顺利载入状态机后，这个Hash指针才不会往后『滑动』。Hash指针本身也存储在状态DB中，随同一个Batch刷下去。

问：「 智能交通业务中，节点的数据否可以飘移在各共识节点？如果是秒级业务又该如何解决问题？」问：数据的传播通路有两个：交易的广播和区块的广播。区块的广播是线性的，交易的广播是乱序的。因此，有可能经常出现交易对象结构的交易倚赖了一个对方节点还没有实时到的版本。但是，每个节点都会有例程广播自己本地并未证实的交易。

如果是秒级业务的话，就要看交易倚赖的数据量有多大了，还有网络的比特率是公网环节还是内网环境。在超级链中，首先是交易广播先行（尽最大努力、立刻广播），然后是区块作为定序后的兜底，保证数据的最后一致性。问：「用于UTXO数据模型，当区块数据很多的时候，查询某个区块中的交易ID所对应的时间消耗就较为大，必须迭代每个区块，效率较低，那么百度超级链，在交易信息查找方面做到了哪些优化？」问：在超级链是这样存储的：Block Namespace：blockid -. (block header, txid[N])Tx Namespace:txid - (blockid, tx content....）因此，坎一个交易，不必迭代区块，而是一次『点坎』。

本文来源：奇异果体育官网登录-www.kuaitui360.com