56 lines
3.8 KiB
Markdown
56 lines
3.8 KiB
Markdown
---
|
||
title: 领导者之间的过渡
|
||
---
|
||
|
||
这个设计描述了领导者如何在每个领导者产生自己的插槽时，相互之间过渡PoH账本的生产。
|
||
|
||
## 挑战
|
||
|
||
当前领先者和下一个领先者都在竞相产生当前插槽的最后一个刻度。 下一个领导者可能会在处理当前领导者的条目时到达该插槽。
|
||
|
||
理想的情况是，下一个领导者在能够为当前领导者投票之后，马上生成自己的插槽。 很有可能在当前领导者完成整个区块的广播之前，下一个领导者就会到达自己的PoH插槽高度。
|
||
|
||
下一任领导者必须做出决定，是将自己的区块附加到最后完成的区块上，还是等待最后确定待播区块。 下一个领导者有可能会产生一个提出当前领导者失败的区块，即使网络的其他部分观察到该区块成功。
|
||
|
||
当前领导者有激励机制来尽早启动其区块以获取经济奖励。 这些激励因素需要与领导者需要将其区块附加到一个网络其余部分承诺最多的区块上进行平衡。
|
||
|
||
## 领导者超时
|
||
|
||
当一个领导者正在积极地接收前一个插槽的条目时，领导者可以实时延迟广播其块的开始。 延时时间由每个领队在本地配置，可以根据前一个领队的行为进行动态配置。 如果在超时之前，前一个领队的区块被领队的TVU确认，则PoH被重置为该插槽的开始，这个领队立即产生其区块。
|
||
|
||
缺点是
|
||
|
||
- 领导者延迟了自己的时间，可能让下一个领导者有更多的时间追赶。
|
||
|
||
.
|
||
|
||
优点是：
|
||
|
||
- 一个区块中所有的空间都被用于输入。
|
||
- 超时不固定。
|
||
- 超时是领导者的局部，因此可以很聪明。 领导者的启发式可以考虑涡轮性能。
|
||
- 这种设计不需要账本硬分叉更新。
|
||
- 上一个领导者可以将区块中的最后一个条目冗余地传送给下一个领导者，下一个领导者可以推测性地决定信任它来生成它的区块，而不需要验证上一个区块。
|
||
- 领导者可以推测性地从最后一个接收到的条目中生成最后一个行情。
|
||
- 领导者可以投机地处理交易，猜测哪些交易不会被上一个领导者编码。 这也是一种审查攻击向量。 当前的领导者可能会扣留从客户端收到的交易，这样它就可以将它们编码到自己的插槽中。 一旦处理完毕，条目就可以快速重放到PoH中。
|
||
|
||
## 其他设计方案
|
||
|
||
### 警卫在插槽的末端打勾
|
||
|
||
一个领导者在_倒数第二个tick_之后不会在其区块中产生条目，这是下一个插槽的第一个tick之前的最后一个tick。 网络会对_最后一个tick_进行投票，所以_倒数第二个tick_和_最后一个tick_之间的时间差是整个网络的强制延迟，也是下一个领导者在产生新的插槽之前的延迟。 网络可以从_倒数第二个tick_产生_最后一个 tick_。
|
||
|
||
如果下一个领导者在它产生自己的_第一个tick_之前收到了_倒数第二的tick_，它将重置它的PoH，并从上一个领导者的_倒数第二个tick_产生_第一个tick_。 其余的网络也会重置自己的PoH，产生_最后一个tick_作为投票的id。
|
||
|
||
弊端：
|
||
|
||
- 每次投票和确认都会有固定的超时时间。 1 tick，也就是100ms左右。
|
||
- 平均一个交易的案例确认时间至少会差50ms。
|
||
- 这是账本定义的一部分，所以要改变这种行为需要硬分叉。
|
||
- 并非所有可用空间都用于条目。
|
||
|
||
与领导者超时相比，其优点是：
|
||
|
||
- 下一个领导者已经收到了之前所有的条目，所以它可以开始处理交易，而不需要将它们记录到PoH中。
|
||
- 上一个领导者可以将包含_倒数第二个tick_的最后一个条目冗余地传输给下一个领导者。 下一个领导可以在收到_倒数第二个tick_后立即推测生成_最后一个tick_，甚至在验证它之前。
|