46 lines
3.6 KiB
Markdown
46 lines
3.6 KiB
Markdown
---
|
||
title: 区块确认
|
||
---
|
||
|
||
验证节点对历史证明哈希投票有两个目的。 首先，投票表明它认为该账本在该时间点之前是有效的。 其次，由于在给定的高度上可能存在许多有效的分叉，因此投票也表示对该分叉的排他性支持。 本文档仅描述前者。 后者在 [Tower BFT](../implemented-proposals/tower-bft.md) 中进行了描述。
|
||
|
||
## 当前设计
|
||
|
||
要开始投票，验证节点首先注册一个帐户，投票将发送到该帐户。 然后，它将投票发送到该帐户。 投票包含正在投票的块的刻度高度。 该帐户存储32个最高高度。
|
||
|
||
### 面临的问题
|
||
|
||
- 只有验证节点知道如何直接找到自己的选票。
|
||
|
||
其他组件，例如计算确认时间的组件，需要放入验证节点代码中。 验证节点代码向银行查询投票程序拥有的所有帐户。
|
||
|
||
- 投票选票不包含历史证明哈希。 验证节点仅投票表明它已观察到某个高度的任意块。
|
||
|
||
- 投票选票不包含验证节点状态的哈希值。 没有该哈希值，就没有证据表明验证节点执行了交易并确认没有重复消费。
|
||
|
||
## 拟定设计
|
||
|
||
### 初始状态无跨区块
|
||
|
||
在生成区块的那一刻，领导者应向分类账中添加一个新区块交易，其中包含代表验证奖励的多个代币。 它实际上是一个增量的多重签名事务，它将代币从矿池发送到验证节点。 该帐户应分配足够的空间来收集实现多数票所需的票数。 当验证节点观察到新区块交易时，它可以选择提交包含其账本状态(验证节点状态) 的哈希值的投票。 帐户获得足够的票数后，投票程序应将代币分配给验证节点，这将导致帐户被删除。
|
||
|
||
#### 日志确认时间
|
||
|
||
账本需要知道投票方案。 每次交易后，应该检查它是否属于一个投票交易，如果是，就需要检查该帐户的状态。 如果交易通过绝大多数实现了，它应该记录提交NewBlock交易以来的时间。
|
||
|
||
### 最终确认和付款
|
||
|
||
[Tower BFT](../implemented-proposals/tower-bft.md) 是拟议的分叉选择算法。 它提议将付给矿工的款项推迟到 _堆栈_ 的验证节点投票达到一定深度， 通过这样来防止回滚。 因此，投票程序可能会实现 Tower BFT 。 投票指令需要引用一个全局Tower帐户，以便它能够跟踪交叉区块状态。
|
||
|
||
## 难点
|
||
|
||
### 链上投票
|
||
|
||
使用程序和帐户来实现这一点有点乏味。 最难的部分是弄清楚要在新区块中分配多少空间。 这两个变量是这些验证程序的 _活动集_ 和质押。 如果我们在提交新区块时计算活动集，则预先知道要为其分配空间的验证节点的数量。 但是，如果我们允许新的验证节点对旧块进行投票，那么我们需要一种动态分配空间的方法。
|
||
|
||
从本质上讲，如果领导者在新区块时缓存股份，则投票程序在处理投票时无需与银行进行交互。 如果我们不这样做，那么我们可以选择允许质押浮动，直到提交投票为止。 可以想像的是，验证节点可以引用其自己的质押帐户，但这将是当前帐户值，而不是最后确定的账本状态的帐户值。 账本目前不提供从特定时间点引用帐户的方法。
|
||
|
||
### 投票对前几个区块的影响
|
||
|
||
对一个高度进行投票是否意味着对该分叉的所有较低高度的区块进行投票？ 如果是这样，我们将需要一种方法来查找尚未达到绝大多数的所有区块的账户。 如果不是，验证节点可以将投票明确地发送到所有区块以获得区块奖励。
|