OmniLedger

使用的是 utxo 模型

使用Randhound 在拜占庭集合中生产分布式的无偏差随机数。
Randhound是需要领导者的，所以需要再所有的节点中选举出一个领导者来主持 RandHound 算法。

问题是 如何选举领导者？ 这个问题后面解决

然后利用生成的随机数进行分片，这样保证分片的过程是无偏的。因为 ELASTICO中，是自己计算一个 pow的结果来定位分片，恶意节点可以丢弃一些对自己不利的结果，造成偏差。

ELASTIC 的不足

1. 在每个shard比较小的时候,共识失败概率高，恶意节点数占 1、4，当每个shard有100个节点，公式失败的概率高达 2.76% (Cumulative binomial distribution (P =0.25, N = 100, X ≥ 34))
2. 一些的矿工可以选择性的丢弃 pow 的结果造成分片结果的偏移
3. 不能保障跨分片交易
4. validator 频繁更换shard，导致需要存储全局性的状态。

OVERVIEW

• 每个节点有他的公钥私钥作为他的身份。
• 系统运行分为多个 epoch，每个epoch运行一段时间，比如一天，在一个epoch中进行多轮的共识。
• 设置 identity chain， 为了防御女巫攻击，可以使用一些女巫攻击的防御机制来限制身份提交到 identity chain

结构草图

通过可信随机信标将随机数 $rn{d}_e$广播到整个 epoch中。
想要参与到epoch e中的validator，需要在 e-1 轮时注册到 identity chain中。
通过上一轮的随机数 $rn{d}_{e-1}$ 来选举下一个epoch的leader。leader 负责将身份区块添加到 identity chain中。
通过随机数 $rn{d}_e$ 来决定每个validator被分配到那个分片中。
在各个分片中运行 ByzCoin 共识

有几个问题;

• 如果使用随机信标 randomness beacon 产生随机数，会引入一个可信的第三方。但是这是不可靠的。如何在不信任任何一方的情况下进行？
• 在进行分片重新配置的过程中，对交易的共识完全停止了，因此会损失性能。
• 没有对跨分片交易的支持机制，

OmniLedger 的设计

使用RandHound 生成随机数

RandHound 算法需要一个leader来协调所有的交易，使用 vrf-based leader选举算法

每个validator 计算一个 ticket，并且高索所有的节点。从中选择一个最小的值作为leader。
$ticke{t}_{i,e,v}=VR{F}_{ski}(“leader”\Vert confi{g}_e\Vert v)$

如果运行失败，则忽略这个validator，view = v+1，并重新运行。

然后leader 运行 randhound广播随机数 $rn{d}_e$ 和证明，根据这个随机数计算一个排列并将所有的validator均匀的分配到各个桶中。这个随机数的生成过程是不收单个节点影响的。
如果恶意节点做leader，他只能将随机值藏起来，不广播出去，导致重新选择leader并重新生成随机数。但是这样连续进行 a次，重新生成a次随机数的概率为 $(f/n{)}^a$

validator 重分配同时能进行交易处理

omniledger 采用逐渐过渡的策略。

• 每次最多换出整个shard的1/3.
• 对于每个shard，通过一个随机种子 $H(j||rn{d}_e)$ 计算一个排列 ${\pi }_{j,e}$ ，将分成许多的batch
• $H(0||rn{d}_e)$ 来计算新加入epoch的节点的排列。
• 每个batch等待 $\Delta$ 的时间，每个validator准备好时，就会选择加入新的shard

Atomix 处理跨片交易的原子性提交

面对跨片交易时，使用 lock-then-unlock 的方式。
但是，解锁是通过 client来驱动的。如果client 故障掉线了，没有人来驱动解锁过程。
所以系统中的一个节点来填充 client的位置，发出解锁交易。

ByzcoinX 进行片内共识

• 论文中提到了ByzCoinX，所谓是byzcoin的改善版本，两者的区别是，前者是一个三层的树，第一层也就是leader，第二层是一个片的group中的一个组长，第三层就是该片的其它成员。后者是一个层数为log（k）的树，可以是二叉树。

Parallelizing Block Commitments 。ByzcoinX每次直达包没有冲突的交易。
冲突的交易:

1. txA txB 花费同一笔UTXO
2. txA 的输出，是txB的输入，两笔交易有先后顺序。

情况1 txA txB 只能提交其中之一，避免双花
情况2 构建一个DAG 来确定他们的顺序。

使用state block

将上一个epoch的的状态进行总结，构建状态块，并作为下一个epoch的创世块。
相当于检查吊的思想。
为了能够提供交易的证明，上一个epoch 的区块暂时保留。
这样，在进行validator的重分配的时候，就不需要获取所有的区块，对于存储过程进行剪枝。

trust-but-verify transaction validation

validator 分成 opotimistic validator 和 core validator。
optimistic validator 用于验证较小的价值的交易，减少等待时间。
core validator 验证所有的交易。
optimistic validator 的规模较小，如果作恶会受到惩罚。

问题

1. 关于如何加入 identity chain的过程，讲的不是很清楚？ 需要哪些节点来负责共识？
2. 使用state block ，会不会降低安全性？无法追溯之前的交易
3. 使用 RandHound的过程没讲。
4. 关于 Byzcoin 我并不太熟悉。
5. optimistic validator 被惩罚的时候，如何惩罚？
6. 关于选举leader的过程，没有分析安全性。 如何保证leader被大家所知道，广播的话会造成 O(n2）的消息复杂度，是否可取？