36 lines
3.8 KiB
Markdown
36 lines
3.8 KiB
Markdown
---
|
||
title: 乐观确认与罚没
|
||
---
|
||
|
||
乐观确认的进展可以在这里追踪
|
||
|
||
https://github.com/solana-labs/solana/projects/52
|
||
|
||
5月底，mainnetbeta移至1.1版本，而testnet移至1.2版本。 在1.2版本中，只要至少不超过4.66％的验证节点作恶，testnet就能获得乐观的终结性。 应用程序可以假设，在八卦中观察到的超过 2/3 的投票确认了某个区块，或者至少有4.66％的网络违反了该协议。
|
||
|
||
## 工作原理
|
||
|
||
一般的想法是，验证节点必须在最后一次分叉之后继续投票，除非验证节点可以构造证明其当前分叉可能未达到最终确定性的证据。 验证节点构造此证明的方式是通过收集所有分叉，但不包括他们自己分叉的投票。 如果有效投票集代表了该时代的质押权重的 1/3+X，则验证节点当前的分叉可能无法达到超过 2/3 的最终性。 验证节点对证据进行哈希处理(创建证人)，并将其投票提交给替代分叉。 但是，如果同一个区块获得超过 2/3 的投票，则任何验证节点都不可能构造该证明，因此，没有验证节点能够切换分叉，并且将最终确定该区块。
|
||
|
||
## 权衡
|
||
|
||
安全阈值为 1/3+X，其中 X 表示在违反协议的情况下将被罚没的最低抵押金额。 折衷方案是，最坏情况下的活性降低了两倍。 如果超过 1/3-2X 的网络不可用，则网络可能会停止，并且仅在网络恢复到故障节点的 1/3-2X 以下才恢复确认区块。 到目前为止，我们还没有发现主网、cosmos或tezos遭受巨大的不可用性影响。 对于主要由高可用性系统组成的网络而言，这似乎不太可能。 当前，我们将阈值百分比设置为 4.66％，这意味着如果 23.68％ 的网络失败，则网络可能会停止出块。 对于我们高可用性系统网络而言，可用性下降似乎不存在 23.68％ 的联系。 1:10^12 的概率假设有五个 4.7％ 的抵押节点的正常运行时间为 0.995。
|
||
|
||
## 安全性
|
||
|
||
每个插槽的长期平均票数为 670,000,000票/12,000,000插槽，即 64 个投票验证节点中的 55 个。 这包括由于出块节点故障而丢失的区块。 当客户端观察到 55/64 或约 86％ 的概率确认区块后，可以预期必须约 24％ 或`(86-66,666.. +4,666..％)` 的网络遭受罚没才会导致该区块无法完全确认最终性。
|
||
|
||
## 为什么选择Solana？
|
||
|
||
这种方法也可以在其他网络上实施，但是在Solana实现的复杂性大大降低了，因为我们的投票有一个可证明的基于VDF超时。 尚不清楚是否可以在对时间假设较弱的网络中轻松构建切换证明。
|
||
|
||
## 罚没路线图
|
||
|
||
罚没是一个困难的问题，当网络的目标是使延迟尽可能短时，它就变得更加困难。 在针对延迟进行优化时，折衷尤为明显。 例如，理想情况下，验证节点应该在内存已同步到磁盘之前进行投票并传播其投票，这意味着本地状态损坏的风险要高得多。
|
||
|
||
从根本上讲，我们的罚没目标是在节点恶意尝试违反安全规则的情况下罚没100％，在常规操作期间罚没0％。 我们的目标是首先实施罚没证明，而不进行任何自动罚没。
|
||
|
||
目前，为了定期达成共识，在违反安全规定后，网络将停止。 我们可以分析数据并找出谁负责，并建议重新启动后进行罚没。 乐观conf将使用类似的方法。 乐观的conf安全违规很容易观察到，但是在正常情况下，乐观确认的安全违规可能不会阻止网络。 一旦观察到违规，验证节点将在下一个时期冻结受影响的股份，如果违规需要罚没，则将决定下一次升级。
|
||
|
||
从长远来看，如果证明存在乐观的安全违规行为，交易应该能够收回罚没的抵押品。 在那种情况下，每个区块都由网络有效地保护。
|