分布式链上随机数和keyless account

1. 引言

2. 分布式链上随机数

现有链上随机数放啊对比：
在这里插入图片描述
其中：

DFINITY：依赖于threshold DKG (tDKG) and a threshold VRF (tVRF)，而不是权重。因DFINITY采用的是non-PoS安全模型，其认为只要不超过三分之一的validators（而不是质押量）被compromised，该链仍是安全的。这样，其门限设置，要比Aptos的权重设置，简单得多。因为这样shares的总数可设置为validators数量（如数百个）。而Aptos的权重设置，shares的总量与总质押量呈比例，即使向下取整，也要大得多（如数千个）。
Drand：也依赖于在servers委员会中实现tDKG和tVRF。在门限设置下，实现要更简单。但，当某dapp消费了所生成的随机数，其必须对randomness beacon的安全性和可用性附加额外信任。此外，该随机数无法即时消费，而是通过一个commit-and-reveal流程，使得开发很笨重，对随机数的访问也有更大的延迟。同理，Algorand的随机数beacon设计也存在类似的问题，其消费的随机数源自不同的外部随机数beacon。
Chia采用 verifiable delay functions (VDFs)，其优势在于，即使所有validators都堕落了，其仍具有不可预测性。其基于的假设为，无人可evaluate the VDF faster than the delay it was originally set up with。但其缺陷在于，无法快速生成随机数，因其内部依赖于随机数计算的延迟性。此外，基于 VDF 的方法无法轻松提供即时交付的随机性，因为这需要为每个块生成一个 VDF，这对于低延迟区块链来说很困难，因为 VDF 本质上很慢。换句话说，如果区块的生成频率高于 VDF，那么这些区块将无法获得即时随机性。
Flow ：validators验证者投票并附上他们对提议区块A的 VRF 评估，允许下一个区块B的提议者聚和投票并揭示A的随机性。这通过策略性地不提议 block B、将 block A 渲染为orphan孤儿区块来实现偏差。
Celo：让区块的提议者选择随机数，对其进行承诺并在后续区块中揭示。这为拒绝揭示随机数或根据后续区块中的预期交易做出明智的预测以最大化利润开辟了途径。
以太坊：每个区块提议者都会根据当前epoch纪元数评估 VRF。然后，纪元的随机数被定义为提议者 VRF 评估的best-effort组合。不幸的是，这种方法很容易产生偏见，因为一个或多个共谋的区块提议者如果不喜欢结果，可以选择不混合他们的贡献。此外，这种方法非常慢，因为 epoch 每 6.4 分钟才发生一次。

Aptos团队的 Aline Temesku，提出了：分布式链上随机数和keyless account，致力于称为：

改变链上互动和交易方式的新范式

Aline Temesku 2020年时在VMWare工作，对身份验证的数据结构、向量承诺颇有研究，同时对stateless validation无状态验证非常感兴趣，当时的工作重点是经身份验证的数据结构和门限密码学。在VMWare工作期间，Aline Temesku研究了一种匿名支付方案，该方案可平衡责任或合规性与隐私。Aline Temesku于2022年2月加入Aptos团队。

在语言层面，Sui 和 App Toss 都使用 move，但 move 的子集开始有点有趣的分叉。如，Aptos 支持的脚本比 Sui move 中支持的 ptps 强大得多。

Aptos 的整体理念是改善用户体验和开发人员体验，并将 Web 3 带给下一个十亿用户。

Aptos与Sui的另一个不同之处在于：

Aptos上有一种称为即时链上随机数的东西。该功能背后的想法是让智能合约立即获得无偏见、不可预测的随机性，并改善想要编写游戏、彩票、抽奖、随机 NFT 甚至交互式零知识证明verifier等内容的智能合约编写者的开发体验。

ZK密码学无处不在，即使是签名方案，也可将其看成是“知悉某密钥的零知识证明”。

在Aptos中，发现零知识证明用途广泛，如：

为token转账添加隐私，需对转账金额做范围证明
分布式随机数，可公开验证的秘密共享等协议，使用具有加法全同态功能的函数来对其进行加密，实际最有效的方案是采用了具有零知识范围证明的 Elgamal 加密。
账户管理，当前在做的Aptos Keyless Accounts，利用 OpenID Connect 标准和零知识证明来增加隐私。

Aptos rollup扩容方案中，最大的挑战在于：

计算昂贵的零知识证明的延迟

Aptos对延迟很敏感，若需等待30秒才能完成交易，认为对用户来说并不友好。所以目前并未深入研究如何来构建Aptos rollup方案。

Aptos上目前有个应用程序加改进提案AIP-41：

描述了用于为合约提供无偏且不可预测的随机数的Move API。这些API非常简单：
- 实际上是一个名为“获取随机整数”的函数。如合约调用它，会立即获得一个随机整数。不必等待下一个区块。不需要等待8分钟。不必提前承诺未来将生成的随机数，只需立即获取即可。
实现方式为，确保每个应用程序和区块都有一个随机种子。从随机数种子中，可得出这些合约调用的个体随机数。

问题在于，如何将随机性种子放入其中，以及如何使其无偏见或不可预测？

Aptos中，使用基于 PVSS 的公共可验证秘密共享的分布式密钥生成协议和可验证的不可预测函数或 VUF。在 Aptos Network 的PoS设置中使 DKG 变得实用并不是一件容易的事。在这种情况下，使 VUF 或加权 VUF 实用起来也不是很容易。

DKG，即在PoS委员会中传播了一个密钥。

与VDF类似，但更具挑战性：

Aptos有一个基于委员会的共识协议，该协议在两个小时内进行。因此，每两个小时，validators集可能会发生变化。每当一个新的临时项目以新的valiators集开始时，基本上都希望完成 DKG 协议，以便新的 Epox 委员会拥有共享秘密，并且他们可以计算 VOF，这允许将区块席位放入块中的随机种子。

更多详细技术细节，可参看：Aptos团队2024年论文 Distributed Randomness using Weighted VRFs。

3. keyless account

Aptos 致力于改善用户体验和开发人员体验，并将 Web 3 带给下一个十亿用户。但对于该领域的任何加密货币来说，让新用户进入 Web 3。这些用户必须下载钱包，写下助记词，记住它，了解它的重要性。当用户丢失了助记词，就失去了所有资产。当前Web 3 用户的用户体验就是这样。

在 2023 年左右，Aptos团队思考了很多关于通过为用户管理密钥的 NBC 协议来解决这个问题。但这并没有真正解决问题，因为用户仍然需要向 NPC 系统验证自己的身份。所以他们仍然需要一些凭据来证明他们是用户，以便 NBC 系统为他们提供密钥。因此，当观察周围的 NBC 公司时，发现很多公司都在使用 OpenID Connect，让用户使用 Google 帐户等方式向 NPC 系统证明自己的身份。最初它并不让人满意，但大约一两个月后，很明显，如果 NBC 系统可以验证这个OpenID Connect 凭证，那么区块链也可以，而且实际上并不需要 NBC 系统。

Aptos Keyless 允许用户从现有的 Google 帐户（而不是传统的密钥或助记符）设置 Aptos 区块链帐户。简而言之，使用 Aptos Keyless，用户的区块链帐户就是他们的 Google 帐户。未来，Aptos Keyless 将支持许多 OpenID Connect (OIDC) 提供商，而不仅仅是 Google。

重要的是，Aptos Keyless 通过两种方式维护用户隐私：

用户的电子邮件地址不会在链上向任何人透露，包括其他用户和验证者。
用户的区块链地址和相关交易历史对身份提供商（如谷歌）是隐藏的。

keyless account无钥匙账户对于用户来说是革命性的，原因如下：

通过熟悉的 Web2 登录，如Sign In with Google。
能够在 Aptos 区块链上进行交易，而无需离开应用程序体验来下载钱包。
不需要用户管理密钥。这意味着区块链帐户访问与 OIDC 帐户的访问同义，并且在用户失去对其 OIDC 帐户的访问权限时，可以使用类似 Web2 的恢复流程来重新获得对其区块链帐户的访问权限。
无缝的跨设备体验；用户无论使用什么设备都可以使用 OIDC 帐户登录 - 无需在每台设备上下载钱包软件、导入密钥并使用必须维护的密码进行加密。

参考资料

[1] 2024年3月20日 Zero Knowledge Podcast Episode 316 - Alin Tomescu on Distributed On-chain Randomness and Keyless Accounts
[2] 2024年2月2日博客 Roll with Move: Secure, instant randomness on Aptos
[3] Aptos Keyless