Designing Fair and Efficient Blockchain Games: Discussion

TABLE OF LINKS

Abstract and Introduction

Background

Randomness Practice in Blockchain

System Development

Transaction Fee Comparison

Discussion

Conclusion and References

6. DISCUSSION

Through the case study of building a random, fair, and verifiable raffle game on Sui Network, we explored various design approaches, inherent limitations, and potential solutions when developing games with randomness using smart contracts. Each design option comes with its unique set of advantages and drawbacks, and the choice should be made depending on the particular circumstances at hand.

6.1 Randomness on Blockchain

Two methods for achieving randomness in smart contracts are considered best practices: DRAND Randomness and host’s key Signature Randomness. As shown in Table 1, both methods have a comparable transaction fee. Drand Randomness aggregates input from nodes across the DRAND network to generate random values, making it more decentralized and secure. However, the current official (before the mainstream update to a 3-second cadence) using DRAND requires a 30-second wait each round, which could impact the user experience. On the other hand, single-key VRF randomness generates signatures using the raffle host’s private key for randomness and is faster. However, it is more centralized, requiring the host to secure the private key and provide a signature each time.

6.2 Smart Contract Design Limitations, Solutions, and Recommendations

When building a raffle in smart contracts, it’s critical to consider network limitations, especially concerning the size of arrays and objects. We propose two solutions to address size constraints: "Raffle with Object Tables" and "Zero Knowledge Raffle."

"Raffle with Object Tables" involves transforming the content of arrays into a multi-layered table data storage structure, maximizing the data storage capacity. The advantage of this approach is that all data remains on the blockchain. However, it has higher computational costs, requires multiple setup transactions, and incurs higher storage fees. The need for multiple setup transactions can be mitigated using the "Delegate Object Creation" method, where a delegate host assists in creating Object Tables. Storage fees can be reduced by reclaiming storage space through Storage Rebates by clearing data at the end of the Raffle.

The raffle with Object Tables is perfect for situations that require absolute transparency and decentralization, such as selecting lucky winners among players to receive exclusive event prizes. Additionally, a host can utilize Raffle with Object Tables to create games like lotteries that require active participation from players.

On the other hand, the Zero Knowledge Raffle transforms array fields into a Merkle Tree, enabling an infinite capacity of addresses by uploading only the root of the Merkle Tree to the smart contract. However, it comes with higher transaction fees when verifying the Merkle Tree during prize distribution.

The Zero Knowledge Raffle is well-suited to reduce transaction costs in scenarios involving many candidate entities, such as Loot Box and Gacha Games. Moreover, by combining Private Key Randomness with the Zero Knowledge Raffle, it is possible to enhance the efficiency of the raffle while ensuring decentralization and incentives for the host to provide a Merkle Proof to settle the raffle.