从构想到实现：我们在椭圆曲线上修改现有的数字签名方案，使其具有确定性，并在此基础上提供获取在区块链内验证的伪随机数的功能。
主意
在2018年秋天，第一批智能合约在 Waves区块链上被激活 ，立刻就产生了获取可信任的伪随机数的可能性的问题。
突破这个问题，我终于得出结论：任何区块链都是一个单元，在封闭系统中不可能获得可信的熵源。
但是我仍然喜欢一个想法：如果随机预言将使用户数据的签名成为确定性算法，则用户将始终能够使用公钥来验证这种签名，并确保接收到的值是唯一的。 甲骨文全力以赴，无权更改任何东西，该算法产生了清晰的结果。 实际上，用户捕获了结果，但直到oracle将其发布后才知道。 事实证明，您根本无法信任oracle，但要检查其工作结果。 然后，在成功验证的情况下，可以将这种签名视为伪随机数的熵的来源。
Waves 区块链平台使用EdDSA签名方案，这是Ed25519 的变体。 在此方案中，签名由R和S的值组成，其中R取决于随机值，并且S是根据正在签名的消息，私钥和与R相同的随机数来计算的。事实证明，对于相同的消息没有一对一的依赖关系。自定义消息具有许多有效的签名。
显然，以其纯形式，这样的签名不能用作伪随机数的来源，因为它是不确定的，因此很容易受到Oracle的操纵。
但是，事实证明，确定它实际上是可能的。
我对测试的随机函数（VRF）寄予厚望，但是研究了装备之后，我不得不拒绝该选项。 尽管VRF提供了确定性版本的签名及其证明，但是该算法有一个奇怪的地方，为操纵oracle开了一个黑洞（这是错误的说法，请参见Update ）。 即，在计算k的值时（ 第5.1节 ），使用了私钥，该私钥对于用户而言仍然未知，这意味着用户无法验证k的计算的正确性，因此oracle可以使用他需要的k的任何值，同时维护对应k和签名数据的数据库。始终能够从VRF的角度重新计算正确的结果。 您将看到一个基于VRF的绘图而没有公开私钥，您可以考虑一下：指出需要或打开密钥，或将其从k的计算中排除，然后私钥将在第一个签名出现时自动自动打开。 通常，如前所述，随机预言机是一个奇怪的方案。
经过一番思考，并获得了当地分析师的支持，VECRO工作流程诞生了。
VECRO是可验证椭圆曲线随机Oracle的缩写，在俄语中表示椭圆曲线上已检查的随机Oracle。
事实证明，一切都很简单，要实现确定性，必须在出现签名消息之前固定R的值。 如果R是固定的并且是已签名消息的一部分，这另外保证了R在已签名消息本身中是固定的，则S的值由用户消息唯一确定，因此可以用作伪随机数的来源。
在这样的方案中，R的固定方式无关紧要，它仍然保留在预言家的职责范围内。 重要的是，S由用户唯一确定，但是在Oracle发布之前，其值是未知的。 我们想要的一切！
说到固定R，请注意，在签署各种消息时重用R会唯一地揭示EdDSA方案中的私钥。 对于oracle的所有者，排除重用R对不同的用户消息进行签名的可能性变得极为重要。 也就是说，在任何操纵或阴谋中，甲骨文总是会冒失去其私钥的风险。
总体而言，oracle必须为用户提供两个功能：初始化（用于固定R的值）和签名（用于返回S的值）。此外，对R和S是包含固定值R和任意用户数据的用户消息的常规验证签名。
可以说，这种针对区块链的方案无非是一种普通的提交-披露方案 。 实际上，是的，就是她。 但是有一些细微差别。 首先，oracle在所有操作中始终使用相同的密钥，例如，在合同中使用起来很方便。 其次，由于行为不正确，甲骨文可能会丢失私钥，例如，甲骨文允许您对结果进行抽样，然后仅进行两个测试即可找出私钥并获得对钱包的完全访问权限。 第三，在区块链中经过本地验证的签名是很漂亮的。
半年以来，实施的想法一直在我的脑海中，直到最终有了Waves Labs赠款形式的动力。 有了大笔赠款，重大责任就来了，这意味着项目必做！
实作
因此，在这个项目中， VECRO是在Waves 区块链上以请求-响应模式使用用户与oracle之间的转移交易实现的。 同时，在oracle帐户上安装了一个脚本，该脚本严格按照上述逻辑监视操作。 验证Oracle事务可恢复整个用户交互链。 所有这四个交易都参与最终价值的验证，智能合约将它们绑在严格的验证线程上，逐步检查所有值，并且没有任何操作余地。
再次，要推迟，并使其更加明确。 甲骨文不只是按照建议的方案工作。 通过紧密建立的智能合约，其工作在区块链级别得到完全控制。 向左移一步，交易就根本无法进行。 因此，如果交易落入了区块链，用户甚至不需要检查任何东西，数百个网络节点已经为他检查了所有东西。
目前，一个VECRO正在主Waves网络中运行（您可以运行自己的网络，这并不困难，只需查看配置示例即可 ）。 当前代码可在PHP中运行（在我之前提到的 WavesKit中 ）。
为了使用oracle服务，您必须：
- 修正R;
- 发送至少0.005 Waves到oracle别名init @ vecr;
- 在从甲骨文到用户的1个R-vecr令牌转移中，获取附件字段中的R代码；
- 获取签名
- 向Oracle别名random @ vecr发送至少0.005个Wave，并且始终在附件字段中指示先前接收到的R代码和其他用户数据；
- 在从Oracle到用户的1 S-vecr令牌转移中，在附件字段中获取S代码；
- 使用S代码作为伪随机数源。
当前实施的细微差别：
- 发送到oracle的wave用作向用户进行反向交易的佣金，最多1个Wave；
- R代码是base58编码中字符“ R”的字节与R的32字节值的串联；
- 附件中的R代码应该是第一个，用户数据位于R代码之后；
- S代码是base58编码中“ S”字符的字节与S值的32个字节的串联；
- S是模数除法的结果，因此不能将S用作完整的256位伪随机数（该数字最多可以视为252位伪随机数）；
- 最简单的选择是将S代码中的哈希值用作伪随机数。
获取S代码的示例：
从技术角度来看，oracle已完全准备就绪，可以安全使用它。 从普通用户的使用角度来看，方便的图形界面是不够的，这将不得不等待。
我将很乐意回答问题并接受评论，谢谢。
更新2019年5月8日
关于VRF是错误的。 是的，确实，ECVRF签名不能用作伪随机数的来源，但不能用于此目的。 需要签名来构建Gamma值唯一性的证明（ 第5.3节 ，第6步）。 但是使用签名验证的Gamma值已经作为伪随机数的来源参与（ 第5.2节 ，第5步）。 感谢Oleg Taraskin Crittografo指出的这一点，我承认自己的错误。 ECVRF拥有一切生命权。
不幸的是，由于在智能合约中缺少必要的数学工具，因此仍然没有机会在Waves区块链级别使用ECVRF。
当此功能或RSA支持可用时，您可以编写新的Oracle。 至于VECRO方案，无论如何，它都占据了自己的位置，并且使您无需任何其他功能即可工作。