Solana扩容机制分析（2）：牺牲可用性换取高效率的极端尝试 | CatcherVC Research

 4.POH（Proof Of History）：前文提到，Turbine协议允许Leader将交易序列切碎，把不同的碎片发布出去。这种做法要有一个保障：交易序列被切碎后，要容易被拼凑复原。为了解决这个问题，Solana特意在数据包中掺杂纠删码（可防止数据丢失），并且引入独创的POH（Proof Of History）机制为交易事件排序。

在Solana白皮书中，Yakovenko以哈希函数SHA256为案例，展示了POH的原理。为了便于理解，本文将以下面的例子解释POH机制：

（由于POH及对应的时间演进逻辑较难用语言描述，建议先阅读Solana中文白皮书对POH的解读， 再将本文以下桥段作为辅助阅读）

SHA256函数的输入值和输出值是唯一映射的（1对1），输入参数X后，仅有唯一的输出结果SHA256（X）=？；不同的X会得到不同的 ？=SHA256（X）；

如果循环、递归的计算SHA256，比如：
定义X2 = SHA256 ( X1 )， 再用X2计算X3 = SHA256 (X2)，再算X4 = SHA256 (X3)，如此重复迭代下去，Xn = SHA256 ( X[n-1] )；

反复执行这个过程，最终我们会得到一个X1，X2，X3......Xn的序列，该序列有个特点：Xn = SHA256 ( X[n-1] )，排在后面的Xn是前面X[n-1]的“后代”。

将该序列公开发布后，如果有外人想验证序列的正确性，比如他想判断Xn是否真的是X[n-1]的“合法后代”，可以直接将X[n-1]代入SHA256函数去算，看结果和Xn是否相同。

在这种模式下，没有X1就得不到X2，没有X2得不到X3......没有Xn得不到后面的X[n+1]。这样一来，序列就具有了连续性和唯一性。

最关键的一点：交易事件可以被插进序列里。比如： 在x3出生后、x4未出现时，交易事件T1可作为外部输入，和X3迭加在一起，得到x4 = SHA256（X3+T1）。其中，X3的出现略早于T1，X4则为（T1+X3）孕育的后代，T1实质被夹在X3和X4的“生日”之间。

以此类推，T2可以在X8产生后，作为外界的输入参数，计算X9=SHA256（T2+X8），这样T2的出现时间就被夹在x8和x9的“生日”之间；

在上面的场景中，实际的POH序列为以下形式：

其中，交易事件T1和T2是外界插入序列里的数据，在POH序列的时间记录上，他晚于X3早于X4。
只要给出T1在POH序列里的次序号，可得知它之前发生了多少次SHA256计算（T1前面有X1、X2、X3，发生了3次SHA256计算）。
同样的道理，T2前面有X1~X8八个X，发生了8次计算。

以上过程的白话解释如下：有个人拿着秒表在那里数秒，每当他收到一封信，他就按照秒表的读数，在信封上记下时间。收到十封信后，这十封信上记录的秒数肯定不同，有先后区分，这就给不同的信件排了序，根据信件上的记录还可以知道两封信之间隔多久。

Leader在对外发布交易序列时，只要在T1的数据包里给出X3的数值，并告知X3的序号（第3个），接收数据包的Validator便可解析出T1之前的完整POH序列；
只要在T2的数据包里，提供X8的数值，及其序号8，Validator便可解析出T2之前的完整