今年早些时候，我们推出了 错误赏金程序 专注于在信标链规范和/或客户实施中查找问题（灯塔，nimbus，teku，prysm等…）。结果（和脆弱性报告）在修补潜在问题的同时所学到的经验教训都在启发。
在这个新系列中，我们旨在探索和分享迄今为止从安全工作中获得的一些洞察力，并随着我们的前进。
第一篇文章将分析一些专门针对BLS原语的提交。
免责声明：这篇文章中提到的所有错误都已修复。
BLS无处不在
几年前 迭戈F.蜘蛛 在 椭圆曲线密码学的第21届研讨会 标题： 配对没有死，只是休息。 多么预言。
我们在2021年，配对是区块链空间（及以后）中使用的许多加密原语的主要参与者之一： BLS 骨料签名，ZK-SNARKS系统等。
与BLS签名相关的开发和标准化工作已成为EF研究人员的一个持续项目，一段时间以来。 贾斯汀·德雷克（Justin Drake） 并总结 他在Reddit上的最新帖子。
最新，最伟大的
同时，已经有很多更新。 BLS12-381 现在被普遍认为是 配对曲线 被使用 鉴于我们目前的知识。
目前正在开发三种不同的IRTF草案：
而且， 信标链规范 已经成熟并且已经部分部署了。如上所述， BLS签名 是验证证明（POS）和信标连锁店背后的难题的重要部分。
最近的经验教训
在收集针对共识层中使用的BLS原语的意见书之后，我们能够将报告的错误分为三个领域：
- IRTF草案监督
- 实施错误
- IRTF违规草案
让我们放大每个部分。
IRTF草案监督
记者之一（（nguyen thoi minh quan），在 IRTF草案，并发表了两份具有发现的白皮书：
而特定的不一致仍然是遵守 辩论，他发现一些有趣的 执行 问题 在进行研究时。
实施错误
Guido Vranken 能够发现几个“小”问题 布尔斯特 使用 差分模糊。请参阅下面的示例：
他发现了一个适度的脆弱性影响 BLST的BLST_FP_EUCL_INVERSE函数。
IRTF违规草案
第三类错误与IRTF违反IRTF草案有关。第一个影响了 Prysm客户端。
为了描述这一点，我们首先需要提供一些背景。这 BLS签名 IRTF草案包括3个计划：
- 基本方案
- 消息增加
- 拥有证明
这 Prysm客户端 在其API中没有任何区别，这在实现之间是独一无二的（例如 py_ecc）。关于 基本方案 是 逐字引用： “此功能首先确保所有消息都是不同的” 。这不是在 聚集 功能。 prysm修复了这种差异 贬低用法 的 聚集 （在信标链规范中未使用）。
第二个问题影响了 py_ecc。在这种情况下，在 ZCash BLS12-381规范 该存储整数始终在 [0, p – 1]。这 py_ecc 实施对BLS12-381的G2组进行了此检查 真实的部分 但没有执行模量操作 虚构部分。该问题已通过以下拉请求解决： py_ecc中对dexpompress_g2的验证验证不足。
总结
今天，我们查看了我们收到的与BLS相关的报告 错误赏金程序，但这绝对不是故事的结局，即安全工作或与BLS相关的冒险。
我们 强烈 鼓励 你 为了确保随着时间的流逝，共识层继续变得更安全。这样，我们期待您的来信，并鼓励您挖掘！如果您认为自己找到了安全漏洞或与信标链或相关客户有关的任何错误， 提交错误报告呢💜🦄
