Skip to content

Latest commit

 

History

History
15 lines (8 loc) · 3.51 KB

File metadata and controls

15 lines (8 loc) · 3.51 KB

Proof Of Stake

Mina 中实施的权益证明(PoS)共识机制是Ouroboros Praos协议的一个版本, 为适配我们的简洁区块链进行了一些扩展和修改. 本文将从高层次概述 Ouroboros 权益证明的工作原理, 并详细阐述我们所做的扩展和修改. 如需 Ouroboros 协议的完整描述, 请参阅原始的 Ouroboros 论文: 原版以及Praos版.

A note on Praos, Genesis, and Mina

从形式上讲, 我们对 Ouroboros 的实现是 Praos 的一个扩展. 然而, 有一篇更新的论文对 Praos 进行了扩展, 名为 Ouroboros Genesis. 这一扩展修复了涉及长分叉攻击的一个漏洞, 但如该论文所述, 它无法在简洁区块链协议中实现. 相反, 我们引入了一种全新的, 简洁的方法来防范长分叉攻击.

Additions to Praos

Epoch Ledger Optimization

在 Ouroboros 中, 节点需要呈现/保留前一 epoch 开始时的账本, 以便进行可验证随机函数(VRF)计算. 这是因为仅仅有可验证随机函数的输出并不足以知晓一个区块是被诚实地提议生成的. 为了确定一个区块是由提议它的节点赢得的, 可验证随机函数的输出必须处于由提议者的权益所确定的阈值之下, 该阈值与账本中的总货币量成比例. 在像 Mina 这样的简洁协议中, 呈现/保留过去的账本并非易事. 与非简洁区块链不同, 节点无法随意请求过去链上的部分内容以重构它们感兴趣的信息. 这意味着, 如果我们要以一种简单直接的方式实现这一功能, 在任何时候我们都需要保留整个账本的3份副本, 并且至少要在线等待2个完整 epoch 后才能访问该信息. 不过, 经过一番思考, 我们可以做得更好.

Ouroboros 证明区块获胜者的方式与 Mina 证明的方式存在很大差异. 在 Ouroboros 中, 每个节点在接收到一个区块时都需要验证区块提议者确实赢得了该区块, 这意味着它们必须自行查找进行可验证随机函数计算的公钥对应的余额. 然而, 在 Mina 中, 可验证随机函数评估的正确性可以在 SNARK 中进行计算, 因此其他节点只需验证 SNARK 就能知晓该区块是由获胜者提议的. 由于提议者自行证明这一点, 它可以将其需要存储的关于 epoch 账本的信息限制为仅涉及它能够提议的任何账户(自身及其所有委托账户)的账户记录和默克尔路径. 此外, 由于 Ouroboros 向我们保证最终确定点会在两个 epoch 内达成, 提议者可以等到最终确定之后再捕获此信息, 从而进一步限制了它需要存储的信息. 然后, 这些信息会被输入到 SNARK 中, 该论证可证明: 1) 对于所提供的公钥, 可验证随机函数计算是准确的; 2) 公钥对应的账户存在于 epoch 账本中, 且其余额所产生的可验证随机函数阈值大于可验证随机函数输出(利用默克尔路径从账户来证明 epoch 账本的默克尔根). 这并不能立即解决提议者节点需要在线足够长时间以存储这些必要信息的问题, 但它确实为提议者获取该信息开辟了其他途径. 主要来说, 提议者可以请求账户记录和默克尔路径, 以证明其在给定 epoch 账本中的存在性. 在当前的实现中, 没有节点存储此信息并使其可供访问, 但可以想象在未来会构建一项服务, 通过提供此类信息让提议者能够更快地在线并活跃起来, 或许会收取一定的费用.