This paper is available on arxiv under CC 4.0 license. Authors: (1)Eason Chen, Carnegie Mellon University; (2) Justa Liang, Bucket Protocol; (3) Ray Huang, Bucket Protocol; (4) Pierce Hung, Bucket Protocol; (5) Damien Chen, Bucket Protocol; (6) Ashley Hsu, Bucket Protocol; (7) Konstantinos Chalkias, Mysten Labs; (8) Stefanos Pleros Mysten Labs. TABLE OF LINKS Abstract and Introduction Background Randomness Practice in Blockchain System Development Transaction Fee Comparison Discussion Conclusion and References 3. RANDOMNESS PRACTICE IN BLOCKCHAIN In general, the implementation of verifiable random functions (VRF) on blockchain can be broken down into the following two steps: (1) : Define validation criteria and operational logic through a smart contract for an unknown and unpredictable random number. Initiate (2) and Execute: Once the random value is known, validate it against the specified criteria. If it meets the conditions, execute subsequent logic using this random number. Verify The following sub-sections explain various practical methods of implementing randomness. 3.1 Block-Hash Randomness In the early days of the Proof-of-Work (PoW) blockchain, the block hash was one method for getting random values. At PoW, miners competed in computational works to be the first to create new valid Building Random, Fair, and Verifiable Games on Blockchain. Raffle smart contract designs on Sui Network blocks with hash matching certain criteria [16]. Since the block hash is randomly generated, it can achieve randomness by specifying a hash of a future block in the smart contract logic as the seed of randomness [2]. However, there are three to using the block’s hash as a random value. Firstly, miners may intentionally calculate hashes that meet randomness conditions if the reward for generating a hash that meets certain conditions exceeds the block generation reward [2]. Secondly, the concentration of mining power in a few groups in today’s PoW blockchain makes it susceptible to manipulation. Lastly, this method only applies to PoW blockchains, and as blockchain technology shifts towards more efficient methods of block production like Proof of Stake [10], in which a group of miners who are stakeholders takes turns producing blocks, block hash randomness is no longer applicable, as there is greater freedom for miners to manipulate block hashes when producing blocks. limitations 3.2 Oracle-based Randomness Committee-based Oracles are another common randomization[4]. Provided by third-party services, Oracles offer verifiable randomness for smart contracts, guaranteeing fairness in applications such as gaming and lotteries. When using Oracle-based random beacons, users first initiate a transaction and send it to the Oracle provider(s). Then, that provider sends a second transaction to input a committee-derived random value into the contract. However, an Oracle-based random beacon has two . Firstly, its usage requires costly fees (i.e. 3 USD per request on Ethereum). Moreover, Oracle lacks the decentralization levels of a Layer 1 blockchain, typically due to smaller committees and with different incentives or byzantine fault tolerance guarantees. If the Oracle provider experiences downtime or is compromised by hackers, it may result in service interruptions and potentially impact the integrity of the service. There is also another potential issue related to long range attacks and the fact that the Oracles can perform blind, untraceable attacks (i.e. produce a future beacon before anyone else knows, and hence win a lottery without leaving footprints) [5]. It is necessary to have a more cost-effective and decentralized approach to ensure the availability of randomness on a blockchain DApp. limitations 3.3 DRAND Some modern blockchains support functionality to verify random beacons from the League of Entropy’s DRAND, a distributed randomness beacon daemon [19]. The League of Entropy is a collaborative project that provides a verifiable, decentralized source of randomness accessible to anyone who needs public randomness. League members maintained the DRAND network by hosting nodes running the DRAND protocol. Note that although the DRAND network is also considered an Oracle service, we distinguish between paid Oracles, and a community transparent service like DRAND, cause use of it does not impose any paid services to the Oracle provider. Additionally, DRAND follows a standard cadence in producing publicly verifiable beacons, and it’s not per request, hence reused by everyone for free. The current DRAND mainnet network generates a random value every 30 seconds, called a "round"[1] . The generation process of a DRAND random value follows a specific set of steps [20]: (1) : To establish the network, each node is equipped with an identical private key by Distributed Private Key Generation [9] and agreed with a threshold. The threshold, typically set at 50% of the total node count, represents the minimum number of node signatures needed to reconstruct a complete signature. DRAND Network Setup (2) : For each new round, a node generates a partial signature by the current round number and the signature from the previous round. Then, broadcast it to the DRAND Network. Partial Beacon Creation and Broadcast (3) : For each incoming partial signature, a DRAND node first verifies it and then stores it in a temporary cache if it is valid. Once a minimum threshold of valid partial signature is reached, the node combines them according to the BLS12-381 protocol [8]. This combination involves mapping these partial signatures to points on an elliptic curve, producing the final signature. By design, BLS signatures are deterministic; hence the threshold-combined BLS signature bytes can be considered a VRF output. Final Signature Creation (4) : The node validates the new signature by public key and previous signatures, then saves the signature with the round number to the database. Validation and Storage The random value of a DRAND round can be obtained by hashing the signature of that round with SHA-256. When utilizing DRAND for generating randomness within a smart contract, it typically involves the following steps: (1) : When deployed, hardcode the threshold-combined public key of the DRAND network into the contract as a constant. Set Up (2) : Calculate the current DRAND round number and designate a future round with a number greater than the current one as the target random value. Then, write the logic in the smart contract that should be executed based on this random value. Initiate (3) : Wait until the future round is announced at DRAND, then input DRAND’s signature to the contract. The contract will first verify the legitimacy of the DRAND signature through the round number, public key, and the signature of the previous round. Following successful verification, it proceeds to hash the signature to derive the random beacon, subsequently executing the predefined logic with it. Verify and Execute The of DRAND are that it is free, well recognized, decentralized, and has been widely adopted by many projects [19]. Additionally, thanks to the open nature of the DRAND Protocol, anyone can retrieve signatures from a DRAND Node and use them to invoke smart contracts for verification and execution once the designated DRAND round time passed. advantages However, there is a fatal when using DRAND randomness: users need to wait at least 30 seconds to obtain results. Such a lengthy wait may influence the user experience in games. limitation 3.4 Single-key VRF beacons To enhance the immediacy of random outcomes, a more centralized but timely, unpredictable, and verifiable random technique has emerged, using a single entity VRF variation of the known commit-reveal schemes [3], which involves the following procedure: (1) : Write the host’s public key as a constant into the smart contract. Set up (2) : The user inputs a seed into the smart contract. Then, the smart contract saves it with a unique and uncontrollable variable, such as a timestamp or block hash (this is to avoid replay attacks). Initiate (3) Sign the seed: The host uses a private key to sign the seed and the unique variable at the backend and obtains the VRF output (i.e., BLS signature). (4) : The host calls the smart contract with the VRF output as a parameter. The smart contract verifies the validity of the signature using the host’s public key, seed, and unique variable. Then, after successful verification, the smart contract hashes the signature to obtain a random value and execute the random logic. Verify and Execute The of single-key VRF is its remarkable immediacy. After users initiate a transaction, the host can promptly sign and invoke the contract to complete the randomness. In products currently employing single-key VRF, users can receive the random result within five seconds after sending the initiated transaction, demonstrating low latency advantage However, this method has two notable . First, if a hacker compromised the VRF’s private key, it could jeopardize the randomness, potentially leading to the complete depletion of the contract’s assets. Moreover, only the host can Verify and Execute, as no one else can use the private key to create the signature / beacon. As a result, if the host encounters downtime, users may be unable to finish the execution and withdraw their assets from the contract. To circumvent the latter, solutions using time-locks have been proposed, by introducing penalties to VRF hosts who delay publishing their VRF outputs [5, 21]. limitations [1] As of Aug 3rd 2023, DRAND is also running a second mainnet with a 3-second random beacon cadence, and official developer docs are expected [22]. This paper is under CC 1.0 license. available on arxiv

Too Long; Didn't Read

Discover Saakuru: Web3 Mass-Adoption with 0-FEES

Designing Fair and Efficient Blockchain Games: Randomness Practice in Blockchain

Too Long; Didn't Read

EScholar: Electronic Academic Papers for Scholars

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

Designing Fair and Efficient Blockchain Games: Randomness Practice in Blockchain

Too Long; Didn't Read

EScholar: Electronic Academic Papers for Scholars

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES