【白皮书拆解-4】Radix DLT：基于逻辑时钟的分片DAG项目

本篇想要拆解的一个区块链项目是RadixDLT，项目官网是：https://www.radixdlt.com/。

阅读的白皮书版本是：

此白皮书只涉及公链的共识算法以及系统架构，只在Layer1层，具体到上层的智能合约部分，虽然也是图灵完备，且基于Java来进行开发，但不是这份白皮书的重点。

从局外人的角度来看，现在的公链设计，是为上层应用生态提供基石，基础设施好不好，才是项目的关键，上层应用开发，筑巢引凤，只有工具箱完备，也只有巢筑得好，才会有繁荣生态的可能。

Radix后面跟着的这个Tempo，是它的共识机制的名称，也表示时序的含义，后面会做展开。

提起公链的设计，将经典的比特币系统架构作为起点，是一个很好的选择。

比如说，到底比特币系统有哪些问题，使其满足不了现在对区块链的需求了呢？先提出想知道的问题，其次我们将带着问题来看待一个新项目到底有没有核心竞争力，至少，可以看到它们的差异性，以及创新的点。

本篇行文组织结构如下：

• 基于区块的区块链的可扩展性问题
• DAG的基本概念以及扩展性问题
• DAG分片解决方案与双花问题
• Radix Tempo组成成分
• 事件定序之Tempo共识基础--逻辑钟

具体标题略有差异，但是核心点与组织结构相匹配。

1.区块链为什么扩展性差？

谈起可扩展性，这个概念或许会有不同的感性解读，更加精确的描述是：系统计算处理能力的一种衡量指标。通俗一点说，就是够不够快。我们为什么这么在意系统快不快呢？这个看似废话的问题，想引申的思考是：能不能大规模商用。

区块链发展的方向一定是要深入到我们的生活，而不是局限在信仰。

看下图的左半部分，是经典的区块链的图像化描述。从下往上延伸，每一个区块包含上一个区块之后到当前打包时的未处理交易，每一个区块的容量有限，所以当网络有大量未处理交易时，打包一个区块只能处理一部分。这里多说一句的原因是很多文字描述里会说打包上一个区块之后的所有交易，这是不精确的。

以PoW算法为例，我们已经知道了矿工用大量算力计算一个哈希值，具体来说就是，对区块本身计算出来一个哈希值，记为H(Block)，这个确定，寻找一个随机数Nonce，使得：

• H(Block) + Nonce < target目标值

比如我们常说找到比特币哈希值前导0的个数，前导0越多，值越小，那么小于定的目标值的可能性就越大。所以正确答案并不是唯一的，也意味着答案还有好与更好的比较。

我们举一个例子，来说明区块链存在的性能差的问题。

现在假定挖到了第100号区块，圆圈表示节点，A、z节点都收到了100号区块的信息，但不是同一块，这是数字可以认为是本轮抢记账权游戏的编号。

A和z都会广播给自己的邻居节点，我们故意放大一点：在A这里网络延迟很大，传播到邻居得1个小时，z这里比较快，5分钟就广播给了自己的邻居节点。但是广播不会停留在邻居节点，而是接着传播。我们假设网络复杂，1小时后z节点的100'区块信息传递到了ABCD这里，此时ABCD都已经收到了标号为100的区块信息，那么此时会比较哈希值，谁的更优，一看ABCD持有的更有，于是抛弃从z这里传过来的信息，并将100号区块的信息向z那里广播。

这个场景下，我们可以看出带宽浪费，网络拥堵，节点瞎忙问题。对于区块链网络而言，P2P网络是核心，不管共识多么先进，网络的延迟性也是非常关键的瓶颈。

2.DAG解决方案没有扩展性问题吗？

DAG的全称是有向无环图，在区块链里，以区块为单位，每个区块里包含很多个交易，共识是针对区块的共识，是最长链共识，因此上面这个图里左边的形状，紫色的区块是不作数的，需要重新打包，不过在以太坊里，经常出现叔块，矿工也能得到部分奖励。

DAG没有区块的概念，每一笔交易需要与之前的至少一个已经验证的事务相连，即后面的交易至少验证前面的一笔交易，一般是2笔，以此构成一个图结构，如右半部分所示。

一般提起DAG的弱点，可扩展性都不在其中。但是Radix的CTO有提到，随着交易事务越来越多，可以看到当前的圆圈所占据的空间越来越大。那么每个节点需要的存储空间也越来越大。到最后，能够存储全账本数据的节点就会减少，如果网络能不要求每个节点都存储所有数据，将提高网络的可扩展性，比如一般的物联网设备也能加入到这个网络。

DAG最为人诟病的是异步操作导致的数据的不一致性，这也是Radix要解决的重点之一。

针对这种数据膨胀问题，有一个解决方案是：对账本数据进行分片，一些节点保存全部账本，其他节点只保存部分数据。

但是，这带来一个新的问题：双花问题。

3.DAG分片方案与双花问题

讲一讲在DAG之下的双花问题是如何产生的。下面这图是Radix项目CTO的手稿：

中间蓝色的横线是将账本数据进行了分片划分，左边的x是很早之前的某个人的交易，假定这笔交易之后，账户还有余额，现在此人要花费这笔余额了，于是他在上面的分片选择签署一笔交易，这笔交易就近选择过去的两笔交易进行验证，于是这个事件y合法；与此同时，他又跑到下面的分片签署同样的事件，也找两个过去的交易进行验证，我们把这个事件标记为y'。现在两个交易都能追溯到x，看起来都是合法的，但是一笔钱被花了两次，这就是双花问题。

为什么会出现这种情况呢？原因在于两个分片之间不能感知，不能通信，不知道一个相同的事件发生了两次。

针对这个问题提出下面三个解决方案：

1.不用分片

2.跨片通信

3.中心化机构来监视所有分片

其中第一种方法是开倒车，等同于退回到前一步了，不可行，第三种方法是寻找一个中心化的机构来监视分片上的事件，这显然与区块链精神相悖。

第二种是可行的方向，Radix也是在这个方向上的尝试。

4.Radix的解决方案

总体来说，Radix Tempo有三个组成部分：

• 节点P2P网络
• 全球化分布式账本数据库，以DAG的形式
• 生成有序事件的算法：DAG分片，为了解决双花问题，引入逻辑钟算法

Universe && Shards

Universe

P2P网络节点总称为Universe。

上图是节点关系图，前面的几张图都是账本图。Universe被分成多个分片，节点，节点上存储账本，可以只存储部分账本。每个节点上可以存储多个分片，或者全部分片。仔细看蓝色圆圈，第二行标记了该节点存储了哪些分片。

节点ID

在Universe中每个节点都有自己的ID，设定ID有两个目的：

1.标记谁是邻居

2.路由

具体的ID设定方法这里不做展开。

Shard: 部分账本

在Radix的节点网络里，全球账本的子集称作分片。相当于一本书分成多分，每份叫作分片。分片是Radix的基础特征。

P2P网络和全球分布式账本均已提及，现在重点在第三个：生成有序事件的算法。再拆解来说，首先看事件的分类。

两种事件：Protocol Event && Ledger Event

• Protocol Event: 协议事件，用于节点之间进行交流。

• Ledger Event: 账本事件，用于更新账本

节点之间主要通过Gossip协议进行通信，完成必要信息的同步。

Gossip协议

下面是一种场景化描述：

A: 对x事件的哈希值H(x)进行广播: 有人想了解事件x吗？

B: 给我把事件x的详情发过来吧！

A: 好的，马上发送事件x的信息给你~

B: 验货完毕。开始广播给H(x)自己的邻居：有人想了解事件x吗？

所以Gossip这个词的含义本身就是指代八卦，八卦的传播通常是指数级扩散速率。

Atom是事件的实例

在Radix里，对应到Universe宇宙这个名词，他们用Atom原子来表示事件的名称。前面说事件分为两类，相应的原子也有两类：

• Payload Atom: 对应的是协议事件，用于节点之间互通有无
• Transfer Atom: 对应的是账本事件，是对分布式账本进行更新

其中Transfer Atom要比Payload Atom复杂得多，感性的认识是，节点之间互通八卦是简单的，而牵涉到更新账本数据，事件的处理要复杂得多。比如双花问题。

结合前面提及的双花问题情景展示和更新账本的事件，我们能想到，双花问题源头在于事件，而处理这个问题的方法也最好从源头入手。

逻辑钟就是这样一种解决方案。

4.逻辑钟的魔力是什么

通过逻辑钟来解决双花问题的核心思想是：先对进入网络的事件进行预处理。

这里简单讲一讲处理流程。我们先假定对于分布式的节点上的事件有了排序方式。比如上图里，x,y,A,B,C,D,E等等都是事件，这些事件下方的数字表示按照逻辑时间进行的排序。每两个事件形成一个向上的哈希值比如，H0，最上方H0和H1形成根哈希，根哈希值与整棵树的节点息息相关。

给定一个事件y，现在我们验证它是否合法，根据时间顺序，找到它的相邻事件x，计算得出哈希值：H0；然后再根据H1计算出根哈希，比对已经保存的根哈希C1，如果相同，则事件x合法。

形成的默克尔树之间也会相连，比如第一棵树的根哈希作为第二棵树的一个叶子节点。

具体的验证机制牵涉到的数学公式比我这里提到的要更加复杂，而这样的机制，非常依赖于事件的定序。下面讲一讲逻辑钟的概念。

逻辑钟

每个节点都有一个本地逻辑钟，是一个只增长的整数生产器，用于标记节点上看到的新事件。见到一个新事件，数字加1。

区块链的P2P网络是一种分布式系统，分布式系统中事件的顺序非常重要。一般来说，在单机上可以按照物理时间定先后顺序，但是在分布式系统中，这个方法就不可行，因为两个节点上的时间做不到完全同步。事件的先后顺序可能在毫厘之差。现在的科技进步，可能已经足够满足绝大部分的事件定序，但是逻辑钟，是另外一种分布式系统的奠基思想。

全序与偏序

全序关系：可以比较大小关系，比如1，2，3，4，5这种数字就可以比较大小，属于全序关系

偏序关系：部分可以比较。

定义事件的全序关系的算法可以用来实现任意的分布式系统。其中，分布式系统可以认为是多个网络互联的处理机组成的串行状态机，如果可以对输入请求（事件）进行排序，那么就可以实现任意的互联的分布式系统。

分布式系统是物理上分离的多个进程，进程之间通过交换消息进行通信。

不用钟表来定义哪些事件发生在前。

分布式系统里包含多个进程，每个进程要处理一系列事件，进程内的事件按照先来后到定序没有问题，而进程之间的时间定序，在不用时间戳的情况下，怎么办呢？

总体而言，两种情况是可以定序的：

• 发生在一个进程内的事件a,b，先后是定的
• 两个进程之间的事件a,b，如果b是由a触发的，那么根据因果关系可知a前b后

在这两种情况之外的定序，就需要人为设定一种规则。

当前节点有自己的逻辑时钟，不同节点之间的逻辑钟标记不同，每个节点可以记录其他节点的时钟数据，这个称之为向量时钟。

当两个节点的逻辑时钟顺序出现冲突时，我们可以联想到印象笔记的数据更新，当事件有先后时，后者可以更新前者，但是有时冲突发生，系统无法判别如何更新数据，就会交给人来进行选择。

关于逻辑时钟的细节，可以参考文献：

Leslie Lamport, Time, Clocks, and the Ordering of Events in a Distributed System, 1978.

END.