{"id":33888,"date":"2019-10-31T21:55:15","date_gmt":"2019-10-31T18:55:15","guid":{"rendered":"https:\/\/prohoster.info\/blog\/sluchajnye-chisla-i-detsentralizovannye-seti-implementatsii\/"},"modified":"2019-10-31T21:55:15","modified_gmt":"2019-10-31T18:55:15","slug":"sluchajnye-chisla-i-detsentralizovannye-seti-implementatsii","status":"publish","type":"post","link":"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/sluchajnye-chisla-i-detsentralizovannye-seti-implementatsii","title":{"rendered":"Random numbers and decentralized networks: implementations","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<h1 id=\"vvedenie\">Introduction<\/h1>\n<p><\/p>\n<pre><code class=\"plaintext\">function getAbsolutelyRandomNumer() {\n        return 4; \/\/ returns absolutely random number!\n}<\/code><\/pre>\n<p><\/p>\n<p>As with the concept of an absolutely secure cipher in cryptography, real protocols for 'Publicly Verifiable Random Beacon' (hereinafter PVRB) only attempt to get as close as possible to the ideal scheme since, in real networks, it cannot be applied in its pure form: agreements must be made strictly on a single bit, there should be many rounds, and all messages must be perfectly fast and always delivered. Obviously, this is not the case in real networks. Therefore, when designing the PVRB for specific tasks in modern blockchains, besides the impossibility of controlling the randomness obtained and cryptographic robustness, many purely architectural and technical problems arise.<\/p>\n<p><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p>The blockchain itself essentially serves as the communication medium for the PVRB, where messages=transactions. This allows for partial abstraction from network issues, message delivery failures, and intermediary software problems \u2014 all these risks are accepted by the decentralized network, and its main value for PVRB is the impossibility of retracting or corrupting an already sent transaction \u2014 this prevents participants from withdrawing from the protocol, unless they have successfully attacked the consensus. Such a level of security is acceptable, so the PVRB must be resilient to collusions among participants to the same extent as the main blockchain chain. It also implies that the PVRB must be part of the consensus; if the network agrees on the main chain of blocks, it should simultaneously agree on a single honest resulting randomness. Alternatively, the PVRB is simply a standalone protocol implemented via a smart contract, working asynchronously relative to the blockchain and the blocks. Both methods have their advantages and disadvantages, and the choice between them is extremely non-trivial. <\/p>\n<p><\/p>\n<h2 id=\"dva-sposoba-implementacii-pvrb\">Two Methods of Implementing PVRB<\/h2>\n<p><\/p>\n<p>Let\u2019s describe in more detail two implementation options for PVRB \u2014 a standalone version that operates using a blockchain-independent smart contract, and a consensus-integrated version \u2014 embedded in the protocol by which the network agrees on the chain of blocks and included transactions. In all cases, I will have in mind popular blockchain engines: Ethereum, EOS, and all those similar in how they deploy and process smart contracts. <\/p>\n<p><\/p>\n<h3 id=\"standalone-contract\">Standalone contract<\/h3>\n<p><\/p>\n<p>In this variation, PVRB represents a smart contract that accepts transactions from random producers (hereinafter RP), processes them, combines the results, and ultimately arrives at a certain value that any user can obtain from this contract. This value may not be stored directly in the contract but represented only by data from which it is deterministically possible to derive exactly one value of the resulting random. In this scheme, RP are the users of the blockchain, and anyone can be allowed to participate in the generation process.<\/p>\n<p><\/p>\n<p>The standalone contract variation is good for:<\/p>\n<p><\/p>\n<ul>\n<li>portability (contracts can be transferred from one blockchain to another)<\/li>\n<li>simplicity in implementation and testing (contracts are easy to write and test)<\/li>\n<li>convenience in implementing economic schemes (it's easy to create your token whose logic serves the goals of PVRB)<\/li>\n<li>the ability to launch in already operational blockchains<\/li>\n<\/ul>\n<p><\/p>\n<p>However, it also has drawbacks:<\/p>\n<p><\/p>\n<ul>\n<li>significant resource constraints on computations, transaction volume, and storage (in simpler terms, cpu\/mem\/io)<\/li>\n<li>limitations on operations within the contract (not all instructions are available, connecting external libraries is difficult)<\/li>\n<li>inability to organize message exchanges faster than transactions are included in the blockchain<\/li>\n<\/ul>\n<p><\/p>\n<p>This option is suitable for implementing PVRB that needs to be launched in an existing network, without complex cryptography and requiring minimal interactions.<\/p>\n<p><\/p>\n<h3 id=\"consensus-integrated\">Consensus-integrated<\/h3>\n<p><\/p>\n<p>In this variant, PVRB is implemented within the code of the blockchain node, either integrated or operating in parallel with message exchanges between blockchain nodes. The results of the protocol are recorded directly in the produced blocks, and the protocol messages are sent over the p2p network between nodes. Since the protocol results in numbers that must be recorded in the blocks, the network must reach a consensus on them. This means that PVRB messages, like transactions, must be validated by the nodes and included in the blocks so that any participant in the network can validate compliance with the PVRB protocol. This naturally leads us to an obvious solution \u2014 if the network agrees on consensus regarding a block and the transactions within it, then PVRB must be part of the consensus, not a stand-alone protocol. Otherwise, it is possible for a block to be valid from the consensus perspective but not comply with the PVRB protocol, meaning that from the PVRB standpoint the block cannot be accepted. Therefore, if the \u201cconsensus-integrated\u201d option is chosen, PVRB becomes an essential part of the consensus.<\/p>\n<p><\/p>\n<p>When describing the implementations of PVRB at the consensus level in the network, it is essential to address the questions of finality. Finality is a mechanism used in deterministic consensus systems to fix a block (and the chain leading to it) that is considered final and will never be discarded, even if a parallel fork appears. For example, Bitcoin lacks such a mechanism \u2014 if a chain with greater difficulty is published, it will replace any less complex chain, regardless of chain length. In EOS, for instance, the so-called Last Irreversible Blocks are considered final, which appear on average every 432 blocks (12*21 + 12*15, pre-vote + pre-commit). This process essentially involves waiting for 2\/3 of the block producers' signatures (hereafter BP). When forks older than the last LIB appear, they are simply discarded. This mechanism guarantees that a transaction included in the blockchain will never be reverted, regardless of the resources the attacker may have. Additionally, final blocks are blocks signed by 2\/3 of the BPs in Hyperledger, Tendermint, and other pBFT-based consensus systems. Furthermore, it makes sense to establish a protocol for ensuring finality as an extension of the consensus, as it can operate asynchronously with the production and publishing of blocks. <noindex><a rel=\"nofollow\" href=\"https:\/\/arxiv.org\/pdf\/1710.09437.pdf\">article<\/a><\/noindex> on finality in Ethereum.<\/p>\n<p><\/p>\n<p>Finality is extremely important for users, who might fall victim to a 'double spend' attack without it, where the BP 'holds back' blocks and publishes them after the network has 'seen' a valid transaction. Without finality, a published fork replaces the block with the 'good' transaction with another from the 'bad' fork, in which the same funds are transferred to the attacker's address. In the case of PVRB, the requirements for finality are even stricter, as constructing forks for PVRB allows the attacker to prepare multiple random variants with the aim of publishing the most advantageous one and limiting the time for a potential attack \u2014 a solid solution.<\/p>\n<p><\/p>\n<p>Therefore, the best option is to combine PVRB and finality into a single protocol \u2014 then a finalized block = finalized random, which is exactly what needed to be achieved. Now players will receive guaranteed random within N seconds and can be assured that rolling it back or replaying it is impossible.<\/p>\n<p><\/p>\n<p>The option with consensus-integrated is good:<\/p>\n<p><\/p>\n<ul>\n<li>with the possibility of asynchronous implementation concerning block production \u2014 blocks are produced as usual, but in parallel, the PVRB protocol can operate, generating randoms not every block.<\/li>\n<li>with the ability to implement even heavy cryptography, without the limitations imposed on smart contracts.<\/li>\n<li>with the ability to organize message exchanges faster than transactions are included in the blockchain, for example, part of the protocol can operate between nodes without disseminating messages across the network.<\/li>\n<\/ul>\n<p><\/p>\n<p>However, it also has drawbacks:<\/p>\n<p><\/p>\n<ul>\n<li>difficulties in testing and development \u2014 it will be necessary to emulate network errors, missing nodes, hard forks of the network.<\/li>\n<li>implementation errors require a hard fork of the network.<\/li>\n<\/ul>\n<p><\/p>\n<p>Both implementation methods of PVRB have their right to exist, but the implementation on smart contracts in modern blockchains is still quite limited in computational resources, and any transition to serious cryptography is often simply impossible. And serious cryptography will be needed, as will be demonstrated later. Although this issue is clearly temporary, serious cryptography in contracts is necessary to solve numerous tasks, and it is gradually emerging (for example, system contracts for zkSNARKs in Ethereum).<\/p>\n<p><\/p>\n<p>The blockchain that provides a transparent and reliable protocol messaging channel is not free of charge. Any decentralized protocol must consider the possibility of a Sybil attack; any action can be made consistent by a multitude of accounts working together. Therefore, when designing the protocol, one must take into account the attackers' capabilities of creating an arbitrary number of participants operating in collusion. <\/p>\n<p><\/p>\n<h2 id=\"pvrb-i-peremennye-bloka\">PVRB and block variables.<\/h2>\n<p><\/p>\n<p>I wasn't lying when I said that there has yet to be a good PVRB, verified by numerous gambling applications, implemented in blockchains. So where does the large number of gambling apps in Ethereum and EOS come from? I'm just as surprised as you are; how could we find so many 'resilient' randoms in an entirely deterministic environment?<\/p>\n<p><\/p>\n<p>One of the favorite ways to derive randomness in the blockchain is to take some 'unpredictable' information from a block and use it to generate randomness\u2014simply by hashing one or several values. Here\u2019s a good article on the issues with such schemes. <noindex><a rel=\"nofollow\" href=\"https:\/\/blog.positive.com\/predicting-random-numbers-in-ethereum-smart-contracts-e5358c6b8620\">here<\/a><\/noindex>You can take any of the 'unpredictable' values in a block, such as the block hash, the number of transactions, network difficulty, and other unknown values. Then, hash them, one or more, and, in theory, you should get genuine randomness. You might even add to your whitepaper that your scheme is 'post-quantum secure' (as there are quantum-proof hash functions :)).<\/p>\n<p><\/p>\n<p>But even post-quantum secure hashes are unfortunately not enough. The secret lies in the requirements for PVRB; let me remind you of them from the previous article:<\/p>\n<p><\/p>\n<ol>\n<li>The result must have provably uniform distribution, i.e., it is based on provably secure cryptography.<\/li>\n<li>It is impossible to control any of the bits of the result. As a consequence, the result cannot be predicted in advance.<\/li>\n<li>The protocol for generating randomness cannot be sabotaged by not participating in the protocol or by overwhelming the network with attacking messages.<\/li>\n<li>All of the above must be resistant to collusion among an acceptable number of dishonest participants in the protocol (for example, 1\/3 of participants).<\/li>\n<\/ol>\n<p><\/p>\n<p>In this case, only requirement 1 is met, while requirement 2 is not. By hashing unpredictable values from the block, we achieve an even distribution and good randomness. However, the BP has at least the option to 'publish the block or not.' Thus, the BP can choose between TWO options of randomness: 'their own' and the one that results if someone else publishes the block. The BP can 'peek' in advance at what will happen if they publish the block, deciding whether to do so or not. Therefore, when playing, for example, 'even-odd' or 'red\/black' in roulette, they can only publish the block if they see a win. This also renders ineffective the strategy of using, for example, the block's hash 'from the future.' In this case, it is said that 'the randomness produced will be that obtained by hashing the current data and the hash of a future block at height, for instance, N + 42, where N is the current block height. This slightly strengthens the scheme but still allows the BP, albeit in the future, to choose whether to hold or publish the block.<\/p>\n<p><\/p>\n<p>The BP software in this case becomes more complicated, but not significantly. During the validation and inclusion of the transaction in the block, a quick check will determine whether a win will occur, and possibly tweak one of the transaction parameters to achieve a higher probability of winning. Furthermore, catching a clever BP engaging in such manipulations is nearly impossible; new addresses can be used each time, allowing for small wins without raising suspicion.<\/p>\n<p><\/p>\n<p>Thus, methods that utilize information from the block are unsuitable for a universal implementation of PVRB. In a limited variant, with restrictions on bet sizes, limitations on the number of players, and\/or KYC registration (to prevent a single player from using multiple addresses), these schemes might work for small games, but no more.<\/p>\n<p><\/p>\n<h2 id=\"pvrb-i-commit-reveal\">PVRB and commit-reveal.<\/h2>\n<p><\/p>\n<p>Well, thanks to hashing and at least the relative unpredictability of the block's hash and other variables. If the problem of miner front-running can be solved, something more viable should emerge. Let's add users to this scheme\u2014let them also influence randomness: any tech support staff will tell you that the most random factor in IT systems is user behavior \ud83d\ude42<\/p>\n<p><\/p>\n<p>The naive scheme where users simply send random numbers, and the result is calculated as, for example, a hash of their sum, is inadequate. In this case, the last player can control the outcome by choosing their own random number. Therefore, a widely used pattern called commit-reveal is employed. Participants first send hashes of their random numbers (commits), and then reveal their actual random numbers (reveals). The reveal phase starts only after the necessary commits have been gathered, allowing participants to send exactly the random value for which they previously submitted a hash. Now, let's combine this with block parameters, preferably taken from the future (the random can only be known in one of the future blocks), and voil\u00e0 \u2014 the random is ready! Now any player can influence the resulting random and can<\/p>\n<p><\/p>\n<p>defeat<br \/>\nthe malicious BP by overriding their random with their own, which is unknown in advance. We can also add protection against protocol sabotage during the reveal stage by simply requiring a certain amount to be attached to the transaction during the commit \u2014 a security deposit that will only return during the reveal process. In this case, committing without revealing would be disadvantageous.<\/p>\n<p><\/p>\n<h2 id=\"pvrb-i-determinirovannye-podpisi\">That was a good attempt, and such schemes do exist in gaming DApps, but unfortunately, this is still insufficient. Now, the result can be influenced not only by the miner but by any participant in the protocol. Controlling the value is still possible, with less variability and for a fee, but, as with the miner, if the prize draw results are worth more than the participation fee in the PVRB protocol, the random producer (RP) can decide whether to reveal and can still choose from at least two random options.<\/h2>\n<p><\/p>\n<p>There is another way to force the RP to provide a pseudo-random number that it cannot influence by providing a 'template'\u2014this is a deterministic signature. An example of such a signature is RSA, while ECS is not. If the RP has a key pair: RSA and ECC, and it signs a certain value with its private key, then in the case of RSA, it will produce ONE AND ONLY ONE signature, while in the case of ECS, it can generate any number of different valid signatures. This happens because when creating an ECS signature, a random number is chosen by the signer, and it can be selected in any way, allowing the signer to choose from several signatures. In the case of RSA: 'one input value' + 'one key pair' = 'one signature'. It is impossible to predict what signature another RP will produce, so PVRB with deterministic signatures can be organized by combining RSA signatures from multiple participants who have signed the same value. For example\u2014the previous random number. This scheme saves a lot of resources since signatures simultaneously serve as confirmations of correct behavior according to the protocol, while also being a source of randomness.<\/p>\n<p><\/p>\n<p>However, even with deterministic signatures, the scheme is still vulnerable to the 'last actor' problem. The last participant can still decide whether to publish their signature or not, thus controlling the outcome. The scheme can be improved by adding block hashes, creating rounds so that the result cannot be predicted in advance, but all these techniques, even considering numerous enhancements, still leave unresolved the issue of one participant's influence on the collective result in an untrusted environment and can only work under economic and time constraints. Furthermore, the size of RSA keys (1024 and 2048 bits) is quite large, while the size for blockchain transactions is a critically important parameter. Apparently, there is no simple solution to the problem, so let's move on.<\/p>\n<p><\/p>\n<h2 id=\"pvrb-i-secret-sharing-shemy\">PVRB and secret sharing schemes<\/h2>\n<p><\/p>\n<p>In cryptography, there are schemes that can allow a network to agree on one and only one PVRB value, while these schemes are resistant to any malicious actions by some participants. One useful protocol worth exploring is the Shamir Secret Sharing scheme. It is designed to divide a secret (for example, a secret key) into several parts and distribute these parts to N participants. The secret is distributed in such a way that to reconstruct it, any M parts out of N are sufficient, where these can be any M parts. Simply put, having a graph of an unknown function, participants exchange points on the graph, and after receiving M points, the entire function can be reconstructed.<br \/>\nA good explanation is provided in <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Shamir%27s_Secret_Sharing\">wiki<\/a><\/noindex> and to play around with it practically, to mentally simulate the protocol is useful on the <noindex><a rel=\"nofollow\" href=\"http:\/\/point-at-infinity.org\/ssss\/demo.html\">demo<\/a><\/noindex> page.<\/p>\n<p><\/p>\n<p>If the FSSS (Fiat-Shamir Secret Sharing) scheme could be applied in its pure form \u2014 it would be an unbreakable PVRB. In its simplest variant, the protocol might look like this:<\/p>\n<p><\/p>\n<ul>\n<li>Each participant generates their own random value and distributes shares of it to the other participants.<\/li>\n<li>Each participant reveals their share of the secrets of the other participants.<\/li>\n<li>If a participant has accumulated more than M shares, the number associated with that participant can be calculated, and it will be unique, regardless of the set of revealed participants.<\/li>\n<li>The combination of the revealed random values is the sought-after PVRB.<\/li>\n<\/ul>\n<p><\/p>\n<p>Here, an individual participant no longer influences the results of the protocol, except in cases where achieving the threshold for revealing randomness solely depends on them. Therefore, this protocol, when the necessary share of participants working under it and accessible RPs is present, fulfills the requirements for cryptographic strength and is resistant to the 'last actor' problem.<\/p>\n<p><\/p>\n<p>This could be the ideal case; this PVRB scheme based on Fiat-Shamir secret sharing is described, for example, in <noindex><a rel=\"nofollow\" href=\"https:\/\/eprint.iacr.org\/2017\/216.pdf\">this<\/a><\/noindex> the article. However, as mentioned above, if one tries to apply it directly in the blockchain, technical limitations arise. Here is an example of a test implementation of the protocol in an EOS smart contract and its most important part \u2014 the verification of the published share of a participant: <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/mixbytes\/eoscraper\/blob\/master\/Proof.hh#L23\">code<\/a><\/noindex>The code indicates that the validation of the proof requires several scalar multiplications, and the numbers involved are very large. It is important to understand that in blockchains, verification happens at the moment when the block producer processes the transaction, and any participant must be able to easily verify the correctness of the protocol. Therefore, the requirements for the speed of the verify function are very strict. In this case, the approach turned out to be unworkable, as the verification did not meet the transaction time limit (0.5 sec).<\/p>\n<p><\/p>\n<p>The efficiency of verification is one of the most important requirements for using any advanced cryptographic schemes in blockchain. Creating proofs and preparing messages can be done off-chain on high-performance computers, but verification cannot be bypassed \u2014 this is another critical requirement for PVRB. <\/p>\n<p><\/p>\n<h2 id=\"pvrb-i-threshold-signatures\">PVRB and threshold signatures<\/h2>\n<p><\/p>\n<p>Having familiarized ourselves with the secret sharing scheme, we uncovered a whole class of protocols united by the keyword 'threshold'. When revealing some information requires the participation of M honest participants out of N, and the set of honest participants can be any subset of N, we refer to 'threshold' schemes. These schemes help address the 'last actor' problem: if an attacker does not reveal their part of the secret, another honest participant will do it for them. These schemes allow for the agreement on one and only one value, even if some participants sabotage the protocol. <\/p>\n<p><\/p>\n<p>The combination of deterministic signatures and threshold schemes has allowed for the development of a very convenient and promising scheme for implementing PVRB \u2014 this is deterministic threshold signatures. Here <noindex><a rel=\"nofollow\" href=\"https:\/\/eprint.iacr.org\/2002\/081.pdf\">article<\/a><\/noindex> are various applications of threshold signatures, and here is another good example <noindex><a rel=\"nofollow\" href=\"https:\/\/blog.dash.org\/secret-sharing-and-threshold-signatures-with-bls-954d1587b5f\">longread<\/a><\/noindex> from Dash. <\/p>\n<p><\/p>\n<p>The latest article describes BLS signatures (BLS stands for Boneh-Lynn-Shacham, <noindex><a rel=\"nofollow\" href=\"https:\/\/www.iacr.org\/archive\/asiacrypt2001\/22480516.pdf\">here<\/a><\/noindex> These articles possess a very important and extremely convenient quality for programmers \u2014 public, secret, public keys and BLS signatures can be combined with each other through simple mathematical operations, while their combinations remain valid keys and signatures, allowing for easy aggregation of many signatures into one and many public keys into one. They also have determinism and produce the same result for the same input. Thanks to this quality, the combinations of BLS signatures themselves are valid keys, allowing for a scenario where M out of N participants produce one and only one deterministic, publicly verifiable, and unpredictable signature until revealed by the M-th participant.<\/p>\n<p><\/p>\n<p>In the threshold BLS signatures scheme, each participant signs something (for example, the previous random) using BLS, and the overall threshold signature is the desired random. The cryptographic properties of BLS signatures meet the requirements for the quality of randomness, the threshold part protects against the 'last-actor' issue, and the unique combinability of keys allows for the implementation of many interesting algorithms that can, for instance, effectively aggregate protocol messages.<\/p>\n<p><\/p>\n<p>So, if you are building PVRB in your blockchain, you will most likely arrive at the BLS threshold signatures scheme, which is already used by several projects. For example, DFinity (<noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/dfinity\/random-beacon\">here<\/a><\/noindex> a benchmark implementing the scheme, and <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/dfinity\/vss\/blob\/master\/docs\/index.md\">here<\/a><\/noindex> an example of verifiable secret sharing implementation), or Keep.network (here is their random beacon <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/keep-network\/random-beacon-yellowpaper\">yellowpaper<\/a><\/noindex>, and here <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/keep-network\/random-beacon-box\">an example<\/a><\/noindex> smart contract supporting the protocol).<\/p>\n<p><\/p>\n<h2 id=\"implementaciya-pvrb\">PVRB implementation<\/h2>\n<p><\/p>\n<p>Unfortunately, we still do not see a completed protocol implemented on PVRB blockchains that has proven its security and resilience. Although the protocols themselves are ready, applying them technically to existing solutions is not easy. For centralized systems, PVRB makes no sense, and decentralized ones are strictly limited in all computational resources: CPU, memory, storage, I\/O. Designing PVRB is about combining different protocols to create something that meets all requirements for at least a viable blockchain. One protocol calculates more efficiently but requires more messages between RPs, while another requires very few messages, but generating a proof can take tens of minutes or even hours.<\/p>\n<p><\/p>\n<p>I will list the factors you need to consider when choosing a quality PVRB:<\/p>\n<p><\/p>\n<ul>\n<li><em>Cryptographic resilience<\/em>. Your PVRB must be strictly unbiasable, with no possibility of controlling a single bit. In some schemes, this is not the case, so consult a cryptographer.<\/li>\n<li><em>The 'last actor' problem<\/em>. Your PVRB must be resistant to attacks where an attacker controlling one or several RPs can choose between two outcomes.<\/li>\n<li><em>Protocol sabotage problem<\/em>. Your PVRB must be robust against attacks where an attacker, controlling one or several RPs, decides whether to introduce randomness or not and can significantly, or with a specified probability, influence this.<\/li>\n<li><em>Message count problem<\/em>. Your RPs should send a minimum number of messages to the blockchain and avoid synchronous actions like 'I sent some information and am waiting for a response from a specific participant.' In P2P networks, especially those geographically dispersed, one cannot expect a quick response.<\/li>\n<li><em>Computational complexity problem<\/em>. The verification of any stage of the PVRB on-chain should be extremely easy since it is performed by all full clients in the network. If the implementation is done using a smart contract, the speed requirements are very strict.<\/li>\n<li><em>Availability and liveness problem<\/em>. Your PVRB should strive to be resistant to situations where part of the network becomes unavailable for a time, and some RPs simply cease to function.<\/li>\n<li><em>Trusted setup and initial key distribution problem<\/em>. If your PVRB uses the primary setup protocol, that's a whole different and serious story. Here's <noindex><a rel=\"nofollow\" href=\"https:\/\/z.cash\/ru\/blog\/the-design-of-the-ceremony\/\">an example<\/a><\/noindex>. If participants need to share their keys with each other before starting the protocol, that's also a problem when the composition of participants changes<\/li>\n<li><em>Development issues<\/em>. The availability of libraries in the necessary languages, their security and performance, public accessibility, complex testing, and so on.<\/li>\n<\/ul>\n<p><\/p>\n<p>For instance, the threshold BLS signatures have a significant issue \u2014 before they can start working, participants must share their keys with each other to form a group within which the threshold will operate. This means that at least one round of exchange in a decentralized network must be waited out, and considering that the generated randomness, for example, is necessary for games in almost real-time, this implies that sabotage of the protocol is possible at this stage, thus compromising the advantages of the threshold scheme. This problem is simpler than the previous one but still requires the development of a separate procedure for forming threshold groups, which must be economically protected through deposits and slashing of funds from participants who don\u2019t adhere to the protocol. Furthermore, BLS verification with an acceptable level of security simply cannot fit, for instance, in a standard EOS or Ethereum transaction \u2014 there\u2019s just not enough time for verification. The code of contracts is WebAssembly or EVM, executed by a virtual machine. Cryptographic functions are not implemented natively (yet) and run dozens of times slower than standard cryptographic libraries. Many protocols do not meet the requirements just based on key volume, for example, they require 1024 and 2048 bits for RSA, which is 4-8 times greater than the standard transaction signature in Bitcoin and Ethereum.<\/p>\n<p><\/p>\n<p>The availability of implementations in various programming languages is also a factor \u2014 there are few, especially for new protocols. The integration option into the consensus requires writing the protocol in the platform's language, so you\u2019ll have to look for code in Go for geth, in Rust for Parity, in C++ for EOS. Everyone will need to search for JavaScript code, and since JavaScript and cryptography aren\u2019t particularly close friends, WebAssembly will help, which now certainly aspires to be the next important internet standard.<\/p>\n<p><\/p>\n<h2 id=\"zaklyuchenie\">Conclusion<\/h2>\n<p><\/p>\n<p>I hope in the previous <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/448330\/\">article<\/a><\/noindex> I have managed to convince you that generating random numbers on the blockchain is critically important for many aspects of decentralized network life, and this article has shown that this task is extremely ambitious and complex, but good solutions already exist. In general, the final design of the protocol can only be achieved after conducting massive tests that take into account all aspects from setup to failure emulation. Therefore, you are unlikely to find ready-made recipes in teams' whitepapers and articles, and we probably won't dare to write 'do it this way, this is definitely correct' in the next year or two. <\/p>\n<p><\/p>\n<p>For now, for our PVRB in the developing blockchain, <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/mixbytes\/haya\">Haya<\/a><\/noindex>, we have decided to adopt threshold BLS signatures, planning to implement PVRB at the consensus level, as verification in smart contracts with an acceptable level of security is still not possible. We may end up using two schemes: initially an expensive secret sharing to create a long-term random_seed, and then use it as a basis for high-frequency random generation with deterministic threshold BLS signatures, but we might stick to just one of the schemes. It's impossible to say in advance what the protocol will look like; however, it is comforting that, just like in science, in engineering tasks, a negative result is still a result, and each new attempt to solve the problem is another step in the research of all those involved in the issue. To meet business requirements, we are tackling a specific practical task\u2014providing game applications with a reliable source of entropy. Therefore, we also need to pay attention to the blockchain itself, particularly concerning chain finality and network governance. <\/p>\n<p><\/p>\n<p>And even though we do not yet see a proven robust PVRB in blockchains that has been used long enough to withstand the tests of real applications, multiple audits, loads, and certainly real attacks, the number of possible paths confirms that a solution exists, and one of these algorithms will eventually solve the problem. We are happy to share our results and thank other teams who are also working on this issue for their articles and code that allow engineers not to stumble twice on the same rake. <\/p>\n<p><\/p>\n<p>So, when you meet a programmer designing a decentralized random generator, be cautious and caring, and provide psychological support if necessary \ud83d\ude42<\/p>\n<p>Source: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/452340\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u0412\u0432\u0435\u0434\u0435\u043d\u0438\u0435 function getAbsolutelyRandomNumer() { return 4; \/\/ returns absolutely random number! } \u041a\u0430\u043a \u0438 \u0432 \u0441\u043b\u0443\u0447\u0430\u0435 \u0441 \u043a\u043e\u043d\u0446\u0435\u043f\u0446\u0438\u0435\u0439 \u0430\u0431\u0441\u043e\u043b\u044e\u0442\u043d\u043e \u0441\u0442\u043e\u0439\u043a\u043e\u0433\u043e \u0448\u0438\u0444\u0440\u0430 \u0438\u0437 \u043a\u0440\u0438\u043f\u0442\u043e\u0433\u0440\u0430\u0444\u0438\u0438, \u0440\u0435\u0430\u043b\u044c\u043d\u044b\u0435 \u043f\u0440\u043e\u0442\u043e\u043a\u043e\u043b\u044b \u201cPublicly Verifiable Random Beacon\u201d (\u0434\u0430\u043b\u0435\u0435 PVRB) \u043b\u0438\u0448\u044c \u043f\u044b\u0442\u0430\u044e\u0442\u0441\u044f \u043c\u0430\u043a\u0441\u0438\u043c\u0430\u043b\u044c\u043d\u043e \u043f\u0440\u0438\u0431\u043b\u0438\u0437\u0438\u0442\u044c\u0441\u044f \u043a \u0438\u0434\u0435\u0430\u043b\u044c\u043d\u043e\u0439 \u0441\u0445\u0435\u043c\u0435, \u0442.\u043a. \u0432 \u0440\u0435\u0430\u043b\u044c\u043d\u044b\u0445 \u0441\u0435\u0442\u044f\u0445 \u0432 \u0447\u0438\u0441\u0442\u043e\u043c \u0432\u0438\u0434\u0435 \u043e\u043d\u0430 \u043d\u0435\u043f\u0440\u0438\u043c\u0435\u043d\u0438\u043c\u0430: \u0434\u043e\u0433\u043e\u0432\u0430\u0440\u0438\u0432\u0430\u0442\u044c\u0441\u044f \u043d\u0430\u0434\u043e \u0441\u0442\u0440\u043e\u0433\u043e \u043e\u0431 \u043e\u0434\u043d\u043e\u043c \u0431\u0438\u0442\u0435, \u0440\u0430\u0443\u043d\u0434\u043e\u0432 \u0434\u043e\u043b\u0436\u043d\u043e [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-33888","post","type-post","status-publish","format-standard","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.1.1 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u0412\u0432\u0435\u0434\u0435\u043d\u0438\u0435 function getAbsolutelyRandomNumer() { return 4; \/\/ returns absolutely random number!\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/sluchajnye-chisla-i-detsentralizovannye-seti-implementatsii\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.1.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"en_US\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u0421\u043b\u0443\u0447\u0430\u0439\u043d\u044b\u0435 \u0447\u0438\u0441\u043b\u0430 \u0438 \u0434\u0435\u0446\u0435\u043d\u0442\u0440\u0430\u043b\u0438\u0437\u043e\u0432\u0430\u043d\u043d\u044b\u0435 \u0441\u0435\u0442\u0438: \u0438\u043c\u043f\u043b\u0435\u043c\u0435\u043d\u0442\u0430\u0446\u0438\u0438 | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u0412\u0432\u0435\u0434\u0435\u043d\u0438\u0435 function getAbsolutelyRandomNumer() { return 4; \/\/ returns absolutely random number!\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/sluchajnye-chisla-i-detsentralizovannye-seti-implementatsii\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2019-10-31T18:55:15+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2019-10-31T18:55:15+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Random Numbers and Decentralized Networks: Implementations | ProHoster","description":"function getAbsolutelyRandomNumber() { return 4; \/\/ returns absolutely random number!","canonical_url":"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/sluchajnye-chisla-i-detsentralizovannye-seti-implementatsii","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"en_US","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0421\u043b\u0443\u0447\u0430\u0439\u043d\u044b\u0435 \u0447\u0438\u0441\u043b\u0430 \u0438 \u0434\u0435\u0446\u0435\u043d\u0442\u0440\u0430\u043b\u0438\u0437\u043e\u0432\u0430\u043d\u043d\u044b\u0435 \u0441\u0435\u0442\u0438: \u0438\u043c\u043f\u043b\u0435\u043c\u0435\u043d\u0442\u0430\u0446\u0438\u0438 | ProHoster","og:description":"\u0412\u0432\u0435\u0434\u0435\u043d\u0438\u0435 function getAbsolutelyRandomNumer() { return 4; \/\/ returns absolutely random number!","og:url":"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/sluchajnye-chisla-i-detsentralizovannye-seti-implementatsii","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T18:55:15+00:00","article:modified_time":"2019-10-31T18:55:15+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"33888","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-21 17:06:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 02:31:23","updated":"2026-01-21 17:06:19","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/posts\/33888","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/comments?post=33888"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/posts\/33888\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/media?parent=33888"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/categories?post=33888"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/tags?post=33888"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}