预言机区块链_基于区块链数字签名的随机预言机

预言机区块链

From idea to implementation: modifying the existing elliptic curve signature scheme to be deterministic and providing functions on it to obtain verifiable within the blockchain pseudorandom numbers.

从构思到实现：将现有的椭圆曲线签名方案修改为确定性的，并在其上提供功能以在区块链伪随机数内获得可验证的。

理念 (Idea)

In the autumn of 2018, when first smart contracts were activated on the Waves blockchain, the topic of obtaining pseudorandom numbers in a trusted way arose naturally.

在2018年秋天，当第一批智能合约在Waves区块链上被激活时，以可信赖的方式获取伪随机数的话题自然就出现了。

Thinking about it, I came to the conclusion that any blockchain is sort of a cage, and getting a trusted source of entropy in an enclosed system is impossible.

考虑到这一点，我得出的结论是，任何区块链都是笼子，在封闭的系统中获得可靠的熵源是不可能的。

However, I liked one idea. If a random oracle signs user data with a deterministic algorithm, the user will always be able to verify such a signature by the public key to make sure that the obtained value is unique. The oracle wouldn't be able to make any changes because the algorithm comes up with a single-valued result. Basically, the user fixes the result but doesn't know it until it is published by the oracle. So, you may not trust the oracle at all, but still be able to verify the result of its operation. Then, in case of successful verification, such a signature can be a source of entropy for a pseudorandom number.

但是，我喜欢一个主意。 如果随机预言机使用确定性算法对用户数据进行签名，则用户将始终能够通过公钥验证此类签名，以确保获得的值是唯一的。 Oracle将无法进行任何更改，因为该算法带有单值结果。 基本上，用户会修复结果，但直到Oracle将结果发布后才知道。 因此，您可能根本不信任oracle，但仍然能够验证其操作结果。 然后，在成功验证的情况下，这样的签名可能是伪随机数的熵的来源。

On the Waves blockchain, the signature scheme EdDSA variant Ed25519 is used. In that scheme, the signature consists of the values R and S. R is dependable on a random value and S is calculated on the basis of a signed message, a private key and the same random number as R. There is no unique dependence, and several valid signatures exist for the same user message.

在Waves 区块链上，使用签名方案EdDSA变体Ed25519 。 在该方案中，签名由值R和S组成。R依赖于随机值，并且S是根据签名消息，私钥和与R相同的随机数来计算的。并且同一条用户消息存在几个有效的签名。

Apparently, this kind of signature by itself cannot be used as a source of pseudorandom numbers because it is indeterminate and, therefore, can easily be manipulated by the oracle.

显然，这种签名本身不能用作伪随机数的来源，因为它是不确定的，因此很容易被oracle操纵。

However, as it turns out, it's actually possible to make it deterministic.

但是，事实证明，实际上可以使其具有确定性。

My high hopes were set for the verifiable random function (VRF), but, after studying its specifics, i have to reject that option. Although VRF offers a determinate version of a signature and its proofs, the algorithm has an odd place that opens a black hole for manipulations by the oracle (this statement is wrong, see Update). Specifically, for calculating the value of k (section 5.1), a private key is used, which remains unknown to the user, so the user cannot verify the correctness of calculating k. As a result, the oracle can use any value of k that it needs and simultaneously run a database for correlations between k and signed data to be able to always re-calculate a correct result for VRF. If you see a VRF-based raffle without revealing the private key, you can show off and point to the need to either reveal the key or remove it from calculating k so it will automatically reveal itself after the first signature. Overall, as said above, this is an odd scheme for the random oracle.

我对可验证的随机函数(VRF)寄予了很高的期望，但是在研究了它的细节之后，我不得不拒绝该选项。 尽管VRF提供了签名及其证明的确定版本，但是该算法具有一个奇怪的地方，为Oracle的操作开了一个黑洞(此语句是错误的，请参见Update )。 具体地，为了计算k的值( 5.1节 )，使用了私钥，该私钥对于用户仍然是未知的，因此用户不能验证计算k的正确性。 结果，oracle可以使用它所需的k的任何值，并同时运行一个数据库以用于k和带符号数据之间的相关性，从而能够始终为VRF重新计算正确的结果。 如果您看到基于VRF的抽奖活动而没有公开私钥，则可以炫耀并指出需要公开密钥或将其从计算k中删除，这样它将在第一个签名后自动显示其自身。 总体而言，如上所述，这对于随机预言机来说是一个奇怪的方案。

Upon some reflection and with support from local analysts, a scheme for VECRO operation was born.

经过一番思考并得到当地分析家的支持，VECRO运作方案诞生了。

VECRO stands for the Verifiable Elliptic Curve Random Oracle. It turned out to be rather simple. To achieve determinacy, we need to fix the value of R before appearance of a message to be signed. If R is fixed and R is part of the message, which additionally guarantees that R is fixed before the message. The value of S is completely determined by a user message and, therefore, can be used as a source of pseudorandom numbers.

VECRO代表可验证椭圆曲线随机Oracle。 事实证明这很简单。 为了获得确定性，我们需要在出现要签名的消息之前固定R的值。 如果R是固定的，并且R是消息的一部分，则另外保证R在消息之前是固定的。 S的值完全由用户消息确定，因此可以用作伪随机数的来源。

In a scheme of this kind, how exactly R is fixed is irrelevant and remains in the oracle's zone of responsibility. What is important is that S is completely determined by the user, but its value is not revealed until published by the oracle. This is exactly what we wanted!

在这种方案中，R的确切固定方式无关紧要，而是保留在预言家的职责范围内。 重要的是S完全由用户确定，但是直到Oracle发布它的值才显示出来。 这正是我们想要的！

Speaking of fixating R, note that re-usage of R for signing various messages completely reveals the private key in the EdDSA scheme. For the oracle's owner, it's vital to exclude re-usage of R for signing various user messages. I.e., in any manipulations or collusion, the oracle will always risk losing its private key.

说到固定R，请注意重新使用R来签名各种消息完全揭示了EdDSA方案中的私钥。 对于oracle的所有者，至关重要的是要排除R的重新使用以签署各种用户消息。 也就是说，在任何操纵或串通中，oracle总是会冒丢失其私钥的风险。

So, the oracle will offer two functions to the user: initialization, which fixes the value of R and a signature, which returns the value of S. Meanwhile, the R, S pair is a regular verifiable signature for a user message containing a fixed value of R and the user's random data.

因此，oracle将为用户提供两个功能：初始化(用于固定R的值)和签名(返回S的值)。同时，R，S对是包含固定值的用户消息的常规可验证签名。 R的值和用户的随机数据。

One can argue that for blockchain, this is nothing but a regular commit reveal scheme. Basically, that's what it is. But there are a few nuances. First, the oracle uses the same key in all transactions, which, for instance, is convenient for contracts. Second, there is a risk of losing a private key by the oracle because of incorrect performance. For instance, if the oracle facilitates tests of the result, just two tests will be sufficient to figure out the private key and get access to the wallet. Third, a natively verified signature on the blockchain, which is the source of randomness, is just beautiful.

有人可以说，对于区块链来说，这只是一个常规的提交揭示计划 。 基本上就是这样。 但是有一些细微差别。 首先，oracle在所有事务中都使用相同的密钥，例如，对于合同而言很方便。 其次，由于性能不正确，oracle可能会丢失私钥。 例如，如果oracle方便了对结果的测试，则只需两个测试就足以找出私钥并访问钱包。 第三，作为随机性来源的区块链上经过本地验证的签名非常漂亮。

For about six months, this idea was germinating, until a motivation to implement it arrived in the form of a grant from Waves Labs. With the great grant comes great responsibility, it means the project to be!

在大约六个月的时间里，这个想法开始萌芽，直到通过Waves Labs的赠款形式来实现它的动机为止。 巨大的资助伴随着巨大的责任，这意味着要成为项目！

实作 (Implementation)

VECRO was implemented on the Waves blockchain in the request/reply mode using transfer transactions between the user and the oracle. On the oracle's account, a script is set that controls operation strictly in accordance with logic described above. The oracle's transactions are verified by recreation of the entire chain of user interaction. All four transactions are involved in verifying the final value. A smart contract adds all of them to a strict verification thread, checking values step by step and leaving no room for any manipulations.

VECRO是在Waves 区块链上以请求/回复模式使用用户与Oracle之间的转移交易实现的。 在Oracle的帐户上，设置了一个脚本，该脚本严格按照上述逻辑来控制操作。 通过重新创建整个用户交互链来验证oracle的事务。 所有四笔交易都涉及验证最终价值。 智能合约将所有这些添加到严格的验证线程中，逐步检查值，并且不留任何操作余地。

Let's try to put it in simple terms. The oracle doesn't just work under a proposed scheme. Its operation is fully controlled at the blockchain level by a dead-strict smart contract. Any tiny diversion would lead to transaction rejection. So, if the transaction is on the blockchain, users don't have to verify anything, as all verification has already been done by hundreds of the blockchain's nodes.

让我们尝试简单地说。 Oracle不仅在建议的方案下工作。 它的操作由严格的智能合约在区块链级别上完全控制。 任何微小的转移都会导致交易被拒绝。 因此，如果交易在区块链上，则用户无需验证任何内容，因为所有验证已由数百个区块链节点完成。

At the moment, one VECRO is operable on Waves' mainnet. You could actually launch yours: it's simple, just look at the configuration example. The current code works on PHP (on WavesKit, which I discussed earlier).

目前，一个VECRO可在Waves的主网上运行。 您实际上可以启动它：很简单，只需看一下配置示例 。 当前代码可在PHP上运行 (在我之前讨论过的 WavesKit上 )。

To use the oracle, you need to:

要使用oracle，您需要：

• Fixate R;

  注视R;

  • Send a minimum of 0.005 WAVES to the oracle's alias init@vecr;
    向Oracle的别名init @ vecr发送至少0.005 WAVES;
  • Receive an R-code in the attachment field in the 1 R-vecr token transfer from the oracle to the user;
    从Oracle到用户的1个R-vecr令牌传输中的附件字段中接收R代码；

• Get a signature;

  获得签名；

  • Send a minimum of 0.005 WAVES to the oracle's alias random@vecr. You are also REQUIRED to enter in the attachment field the received R-code and additional user data;
    向Oracle的别名random @ vecr发送至少0.005 WAVES。 您还需要在附件字段中输入收到的R代码和其他用户数据；
  • Receive an S-code in the attachment field in the 1 S-vecr token transfer from the oracle to the user;
    在从Oracle到用户的1 S-vecr令牌传输中的附件字段中接收S代码；
• Use the S-code as a source of pseudorandom numbers.
  使用S代码作为伪随机数的来源。

Nuances of current implementation:

当前实施的细微之处：

• WAVES sent to the oracle are used as fees for the return transaction to the user, up to the maximum of 1 WAVES;
  发送到oracle的WAVES用作向用户进行退货交易的费用，最多1 WAVES；
• R-code is a concatenation of the ‘R’ symbol byte and 32 bytes R value in the base58 coding;
  R代码是base58编码中“ R”符号字节和32字节R值的串联；
• R-code in the attachment has to precede user data;
  附件中的R代码必须位于用户数据之前；
• S-code is a concatenation of the ‘S’ symbol byte and 32 bytes S value in the base58 coding;
  S代码是base58编码中'S'符号字节和32字节S值的串联；
• S is the result of a modulo division and cannot be used as a proper 256 bit pseudorandom number (it can be considered a 252 bit pseudorandom number at most);
  S是取模的结果，不能用作适当的256位伪随机数(最多可以认为是252位伪随机数)；
• The easiest option is the use of S-code's hash as a source for pseudorandom number.
  最简单的选择是使用S代码的哈希作为伪随机数的来源。

Examples of receiving S-code:

接收S代码的示例：

• Initialization: https://wavesexplorer.com/tx/8gc8jwM7JrPNehoDs7NVyos7BsufYktvkwVW1B6FAY6

  初始化： https : //wavesexplorer.com/tx/8gc8jwM7JrPNehoDs7NVyos7BsufYktvkwVW1B6FAY6

• Receiving R-code: https://wavesexplorer.com/tx/9eB25SbzEwvHEbm8pcKj7MGDrYv1u3Fxpj696FkJ96hd

  接收R码： https : //wavesexplorer.com/tx/9eB25SbzEwvHEbm8pcKj7MGDrYv1u3Fxpj696FkJ96hd

• Request of signing R-code and user message with value “ random”: https://wavesexplorer.com/tx/6faoFJobEsugDFYmYmfsbtQYABmckNuE2kevaLh7ifzz

  要求对R代码和带有“随机”值的用户消息进行签名的请求： https : //wavesexplorer.com/tx/6faoFJobEsugDFYmYmfsbtQYABmckNuE2kevaLh7ifzz

• Receiving S-code: https://wavesexplorer.com/tx/C5VrFLQcprbA1KXAToaNvMP4Kg2rq43NkwWuADAA7wXX

  接收S代码： https : //wavesexplorer.com/tx/C5VrFLQcprbA1KXAToaNvMP4Kg2rq43NkwWuADAA7wXX

From a technical point of view, the oracle is fully operational, you can safely use it. From the point of view of an ordinary user, there is not enough user-friendly GUI, that will have to wait.

从技术角度来看，oracle是完全可操作的，您可以安全地使用它。 从普通用户的角度来看，用户友好的GUI不足，需要等待。

I will be happy to answer questions and accept comments, thank you.

我很乐意回答问题并接受评论，谢谢。

更新(2019年5月8日) (Update (May 8th, 2019))

I was wrong on VRF. Yes, it is true that the ECVRF signature cannot be used as a source of a pseudorandom number, but it is not used for this purpose. The signature is needed to prove the uniqueness of the Gamma value (section 5.3, step 6). And the verified value of Gamma will be used as a source of a pseudorandom number (section 5.2, step 5). Thanks to Oleg Taraskin Crittografo for pointing at this moment, I admit my mistake. ECVRF has the full right to live.

我在VRF上错了。 是的，确实可以将ECVRF签名用作伪随机数的来源，但不能将其用于此目的。 需要签名来证明Gamma值的唯一性( 第5.3节 ，第6步)。 验证后的Gamma值将用作伪随机数的来源( 第5.2节 ，第5步)。 感谢Oleg Taraskin Crittografo在这一刻的指点，我承认自己的错误。 ECVRF拥有完整的生存权。

Unfortunately, there is still no possibility to use ECVRF at the Waves blockchain level, because of the lack of the necessary mathematical functionality in smart contracts.

不幸的是，由于在智能合约中缺少必要的数学功能，因此仍无法在Waves区块链级别使用ECVRF。

When this functionality or RSA support will become available, new oracles can be created. As for the VECRO scheme, it occupies its niche in any case and allows you to work without any additional functionality.

当此功能或RSA支持可用时，可以创建新的Oracle。 至于VECRO方案，它在任何情况下都占据着优势，并且使您无需任何其他功能即可工作。

翻译自: https://habr.com/en/post/449342/

预言机区块链