摘要：物联网区块链的超流架构主要包括几个特点：一是NDPOS共识算法；第二，不对称的账簿结构；第三，点对点加密通信。

其中，NDPoS主要解决在多链架构下，如何保证区块链系统中跨链原子交易操作的实时性和可靠性；不对称账本结构解决了所有账本数据相同导致的大量无效存储、数据冗余和占用带宽的问题；点对点加密通信侧重于物联网设备之间通信的安全可靠机制。从NDPoS一致性算法的设计目的和解决方案出发，描述了在区块链跨链交易中，如何保证多链间原子操作的实时性和可靠性。

前言

近年来，随着区块链技术社区的不断增加，对一致性算法的研究不断深入。自中本聪首次提出PoW以来，人们对大规模分布式对等网络节点的数据一致性进行了深入的思考和创新。

PoW和PoS都可以归属于同步一致算法的范畴。PoW和PoS的初衷是通过某种机制定期从所有对等网络节点中选择一个“幸运儿”作为日志(即记账)的基准节点，节点将自己记录的交易写入日志文件(账本)并发送给其他节点。这种机制将传统数据库的主从结构扩展到多节点对等结构(多活动)，整个集群可以保证写入总账并经多方确认的账目的强一致性。

然而，当集群网络中的节点数量大大增加时，这种机制将面临许多问题。比如比特币平均每十分钟1MB数据块的频率，使得整体吞吐量极其有限；然而，无论是增加数据块的大小还是缩短分块的时间，都会从带宽或分叉等多个方面引入越来越复杂的问题。

因此，除了通过一系列附加手段增强集群能力外，另一个典型的思路是减少参与共识协议的节点数量，以满足提高集群整体性能、吞吐量和响应速度的需求。

股票授权证明机制(DPOS)

DPoS就是一个典型的架构。通过书与书之间的投票选出一定数量的代理书，在这些书之间形成共识网络，而其他未被选出的书与代理书同步，以满足减少共识节点参与的需求。

然而，无论任何形式的共识算法，整个集群的整体吞吐量仍然受到参与共识节点之间的网络带宽的限制。例如，在典型的公共网络环境中，两个通用设备之间的上行和下行带宽通常高达5-10MB/s (100 MB带宽)。假设每条记录为100字节，有两个节点参与一致的最小网络的吞吐量在物理上被限制为不超过10mb/100/2=50000/s(由于需要发送账本和实时交易数据，需要两倍的数据传输)。当参与共识的节点数量增加时，假设每个账本平均通过P2P协议连接10个账本，吞吐量基本不会超过5千/秒

全网每秒上千笔交易的吞吐量对于私有链甚至联盟链来说可能足够了，但远远不能满足一个典型的公有链的需求。因此，对于基本上任何一个公链项目，采用单链DPoS架构都无法满足未来业务扩展的需求。

分片

而这个问题的解决方案就在于分片。最早也是最常见的分片场景来自分布式数据库，它的前身叫做分区。引入DHT(分布式哈希表，一种一致的哈希算法)后，每个基本哈希单元都可以称为分片。

在区块链的世界里，基本上碎片化的概念类似于分区，即在构建多个独立区块链的基础上，通过某种机制打通多个区块链之间的通信，使不同链之间的节点可以相互通信，从而提高o

然而，无论任何形式的共识算法，整个集群的整体吞吐量仍然受到参与共识节点之间的网络带宽的限制。例如，在典型的公共网络环境中，两个通用设备之间的上行和下行带宽通常高达5-10MB/s (100 MB带宽)。假设每条记录为100字节，有两个节点参与一致的最小网络的吞吐量在物理上被限制为不超过10mb/100/2=50000/s(由于需要发送账本和实时交易数据，需要两倍的数据传输)。当参与共识的节点数量增加时，假设每个账本平均通过P2P协议连接10个账本，吞吐量基本不会超过5千/秒

全网每秒上千笔交易的吞吐量对于私有链甚至联盟链来说可能足够了，但远远不能满足一个典型的公有链的需求。因此，对于基本上任何一个公链项目，采用单链DPoS架构都无法满足未来业务扩展的需求。

正如设计良好的数据库分区机制必须保证尽可能减少分区之间的通信一样，区块链碎片化机制也必须保证从业务逻辑上尽可能减少分区之间的通信需求。

而当跨链业务真正发生时，也必须有一个可靠可信的机制来保证跨链通信事务的原子性和一致性。

ACID

在传统的关系数据库中，任何成熟的商业数据库产品都必须满足ACID的特性。

A(Atomic):原子性，一个事务中的所有操作都必须成功或失败，其中一部分不能成功或一部分失败；

C(一致性):一致性，数据读写必须一致，不能出现写成功但查询不到，或者破坏主键和外键一致性等问题；

I(隔离):隔离，即同时发生的事务在事务结果上互不影响。比如一个账户，里面有100元钱，同时从两个地方取10元，最后的账户结果应该是80元而不是90元；

D(持久性):持久性，任何被确认完成的事务在任何情况下都必须保持完成。即使数据库由于故障而重新启动，确认完成的事务也不会丢失。

关系数据库已经发展了30年，在业界得到了广泛的应用。目前业内银行、金融机构、保险公司或证券公司几乎所有的交易和结算业务都必须基于ACID原则。同时，从业务特点来说，任何不能保证ACID原则的系统都不应该用于金融交易。

与数据库日志不同，区块链不能直接使用传统的数据库事务日志结构进行事务控制，因为用活度架构很难实现高效的全局锁。因此，当大多数区块链项目被写入分类账时，每个交易记录将包含交易来源和交易对手以及金额，而不是传统的数据库日志，其中金额的增加和减少以交易方式串联为多个记录。

区块链分类帐结构

数据库日志结构

因此，区块链分类帐记录结构作为一种特定的交易模型，在仅为虚拟货币交易设计的特殊场景下，能够满足原子性要求。一致性由一些分歧解决方案处理。

隔离可以通过使用UTXO结构(记录变化的历史顺序而不是最终结果)或者增加nonce操作的序号来实现，从而保蓑衣网小编2022证对同一条记录的并发操作可以按顺序识别，避免双花问题。

最后，无论比特币还是以太坊，几乎都是从单个节点的角度忽略了持久性机制。而是在链式结构中采用了Merkel树来支持现有块的自检，从其他正常节点同步损坏块的方式满足了全局持久性(假设所有节点不会同时损坏)。

因此可以看出，在单个区块链段中，无论是以太坊还是比特币，基本上都能保证ACID，最低也能满足金融交易和结算的需求

但是，单个区块链ACID的满足并不意味着跨链交易也满足ACID，因此如何在多链环境下满足ACID是公有链项目能否大规模应用的关键。

分区间原子操作

从MPP数据库时代开始，分区间原子操作就是所有技术团队都在努力解决的问题。从传统的两阶段提交和三阶段提交到新的Spanner架构，所有的分布式数据库都在努力解决分区之间的原子操作问题。

为什么分区之间的原子操作极难解决？在MPP数据库系统中，每个分区在逻辑上是完全独立的，其度量也是完全不同的。从时间戳到锁定机制，不同分区的进程在执行原子操作时无法有统一的参考。

所以解决分区间原子操作的唯一策略就是指定一个引用对象，让多个节点统一协调。

例如，两阶段提交和三阶段提交的机制引入了一个协调者。这种机制在数据库领域统称为XA。其原理是协调器发起原子操作后，协调器判断跨越多个分区的事务应该提交成功还是中途回滚。具体机制读者可以参考相关文章。

蓑衣网小编2022 Google的Spanner架构需要专门的硬件(原子钟)来统一协调节点间的时间戳，结合提交操作记录的全局时间戳来判断每个分区记录的提交回滚状态。

NDPoS

如前所述，区块链试图通过日志(账本流水)的方式将一次原子操作中多个账户的修改合并到一条交易操作记录中，同时通过Merkel树的方式保证日志文件的正确性，从而保证多账户原子操作在解锁状态下进行。

而NDPoS的核心机制是用更高的逻辑链抽象出多个链之间的原子操作。在更高的逻辑链中，DPoS算法也被用来保证每个成员之间操作的原子性。高级逻辑链中的成员也是每个分区链中的一个或多个代理节点。该节点会根据高层逻辑链中达成的共识，筛选出自身链中包含的变更数据，并作为链中的原子操作来执行，从而达到跨链原子操作的目的。

在NDPoS结构中，每个链条中的账簿分为两个角色：代理节点和从节点。其中，代理节点负责小范围内的共识协商，协商结果通知跟随者节点进行计费。当存在嵌套结构时，底层链中的代理节点作为上层虚拟链中的普通记账节点进行投票，其中一部分代理节点作为上层虚拟链中的代理节点达成共识，协商链间通信。因此，任何账簿节点都可以同时有一种或多种状态。既可以作为独立的跟随者节点，也可以作为底层链的代理节点和上层虚拟链的跟随者节点，还可以作为底层链和上层虚拟链的代理节点。

当网络中有三个或三个以上的嵌套结构时，每个账簿节点可能同时具有多个角色。

以三方交易为例。假设转账交易的三个分片链中有X、Y、Z记录，其中记录X来自分片A；记录y来自切片b；记录z来自切片C.

可以看出，分段链A、B、C是完全独立的，而每个分段的投票节点中有一个或多个代理节点，构成了分段链之间的虚拟链。这个虚拟链中的所有节点也使用DPoS机制来达成共识。

当存在同时从X向Y和Y向Z转账的交易时，首先由X所在的片发起交易。

蓑衣网小编2022此时，接收转账操作的账簿节点根据DPoS规则将操作转发给代理节点进行协商一致。如果代理节点发现事务中的任何记录是跨片操作，它将该操作转发给上层虚拟链中的代理节点，以获得跨链一致性。

在跨链共识的过程中，发起分片的代理节点也根据DPoS原理将事务转发给上层虚拟链中的上层代理节点，上层代理节点先在上层虚拟链中发起共识。

达成共识后，上层虚拟链中的协调节点将根据DPoS原理通知上层虚拟链中的其他跟随节点，即碎片链中的普通代理节点。

然后，按照自己的DPoS规则广播到每个碎片链中自己的跟随节点，从而达成跨链共识。

可见，NDPoS的核心思想是先在顶层虚拟链中达成共识，然后将结果传达给底层切片链。当有两个以上的虚拟链时，模式以递归的方式从顶层向下传递。

比如这种模式类似于公司管理制度，部门是基本单位。首先，在每个部门中，管理层被挑选出来代表部门员工作出决定。同时，这些部门级管理层是事业部的代表，其中选出若干业务级管理层参与事业部的决策，并将决策结果通报给其他事业部代表(即事业部所有部门管理层)。同时，业务层面的管理层也是分公司的代表，其中有若干人被推选为分公司层面的管理层进行决策……等等。在这种模式下，参与者可以是分公司管理层、部门管理层和部门管理层，也可以是部门代表和部门管理层。

商务谈判发生时，如果参与谈判的各方都在同一个部门，所有谈判只需要在部门内部管理上达成共识即可。但是，如果要谈判的双方在同一个事业部的不同部门，所有谈判都应在事业部的管理团队之间进行，并将谈判结果通知一些受影响的部门。如果谈判双方位于分行不同业务部门的部门之间，首先必须在分行的管理团队之间做出决定，然后通知各自的业务部门，业务部门通知底层部门执行。

选举策略

选举策略可以根据各个项目的业务特点来实现，但其核心必须保证每个底层链中必须有一个或多个代理节点作为上层虚拟链的节点参与跨链共识，否则涉及底层链的通信无法传递到链中的其他后续节点。

因此，每发生一次上层虚拟链共识，都需要先计算数据块涉及的所有底层链中是否至少有一个成员，共识的发起者必须得到三分之二以上成员的同意(以BPFT为例)，并且数据块涉及的所有底层链中每个底层链的代理节点都达成了同意共识，才能认为共识成功。

在NDPoS多层架构中，其总账的支持数量和吞吐量可以随着层数的增加而弹性扩展。例如，假设一个典型的单链DPoS的最大账号为10，000，代理账号为101，单链设计的理想吞吐量为5，000/s，那么两层结构可以支持大约10，000*(10，000/101)~=1，000，000个节点，理论上的理想吞吐量为5，000。三层结构可以达到10，000 * (10，000/101) 2 ~=1，000，000，000个节点，理论上的理想吞吐量是5，000 * (10，000/101) 2 ~=500，000，000/s.

跨链查询和检索

类似于任何分布式数据库的分片机制，NDPoS的分片机制都是基于DHT模式的，而且是在这种模式下，指定分区键的精确查询操作性能极高，一般来说，对于均匀分布的分区键，整个集群的数据可以均匀分布。但是，如果查询条件不包含分区键，则必须将查询广播到所有分区，以获得所有分区中的合格记录。

因此，必须对基于NDPoS的DHT分片算法进行优化，以满足非pr的实时高效检索 在分布式数据库领域，所谓的全局索引是一个二级索引，但是这个索引的分区键使用的是索引键而不是表分区键。在这种模式下，用户可以使用哈希分区或范围分区对索引键字段进行分区，使查询者在只访问有限个分区的前提下，得到满足查询条件的记录。

但是这种模式的一大缺点在于一致性。由于全局索引的分区键与数据表的分区键不同，一条记录对应的索引往往不在一个片上。因此，强一致全局索引的引入往往会带来大量的分布式事务开销，因此一般不会被传统数据库广泛采用。。

但是，对于一些满足最终一致性的场景来说，使用非强一致的全局索引往往能够得到意想不到的效果。NDPoS的核心本质在于对主数据以DHT分片的方式进行切分，但是可以针对需要检索的其他属性建立最终一致性全局索引。

这种机制对于每个账本节点需要实现数据库“表”与“索引”等类似的机制，将不同业务属性的数据分别存放。

总结

NDPoS在DPoS的基础之上满足了准实时跨分片的强一致性数据通讯。不同于DAG结构对交易确认时间无法预测的最终一致性，NDPoS通过区块链的对等多活机制，提供了跨链间交易的强一致性。同时，NDPoS通过分层代理的机制，实现了整个网络分片数量的无限弹性扩张，从根本上解决了单链账本数量无法过多的性能与扩展性问题。

参考文献

[1] J. F. Groote, A. Mathijssen, M. van Weerdenburg, and Y. S. Usenko, “From μCRL to mCRL2: motivation and outline,” Electr. Notes Theor. Comput. Sci., vol. 162, pp. 191–196, 2006.[2] M. Atif. mCRL2 code for two-phase and three-phase commit protocols. [Online]. Available: http://www.win.tue.nl/~atif/docs/2pc3pc.zip[3] D. Skeen and M. Stonebraker, “A formal model of crash recovery in a distributed system,” IEEE Trans. Software Eng., vol. 9, no. 3, pp. 219–228, 1983.[4] D. Skeen, “Nonblocking commit protocols,” in SIGMOD Conference, Y. E. Lien, Ed. ACM Press, 1981, pp. 133–142.[5] ——, “A quorum-based commit protocol,” in Berkeley Workshop, 1982, pp. 69–80.[6] T. H?rder and A. Reuter, “Principles of transaction-oriented database recovery,” ACM Comput. Surv., vol. 15, no. 4, pp. 287–317, 1983.[7] D. Kozen, “Results on the propositional mu-calculus,” Theor. Comput. Sci., vol. 27, pp. 333–354, 1983.[8] J. Gray, “Notes on data base operating systems,” in Advanced Course: Operating Systems, ser. Lecture Notes in Computer Science, M. J. Flynn, J. Gray, A. K. Jones, K. Lagally, H. Opderbeck, G. J. Popek, B. Randell, J. H. Saltzer, and H.-R. Wiehle, Eds., vol. 60. Springer, 1978, pp. 393–481.[9] ——, “Spanner: Google’s Globally-Distributed Database” [Online]. Available: https://static.googleusercontent.com/media/research.google.com/zh-CN//archive/spanner-osdi2012.pdf[10] Fay Chang et al. “Bigtable: A Distributed Storage System for Structured Data”. ACM TOCS 26.2 (June 2008), 4:1–4:26.[11] David B. Lomet and Feifei Li. “Improving Transaction-Time DBMS Performance and Functionality”. Proc. of ICDE (2009), pp. 581–591.[12] ——, “Delegated Proof-of-Stake Consensus” [Online]. Available: https://bitshares.org/technology/delegated-proof-of-stake-consensus/[13] Ralph C. Merkle, “A digital signature based on a conventional encryption function” [Online]. Available: https://people.eecs.berkeley.edu/~raluca/cs261-f15/readings/merkle.pdf