Introduction

This research article explains how we achieve efficient and complete on-chain shuffling through optimized cryptography (PlonK), including:

• "Mental Poker" and zk-shuffle ensuring fairness within the game

• Zypher's shuffle SDK as a core component of its Secret Engine

• Optimizing the "Reveal" process using SNARK

• Optimizing the "Shuffle" process using "local" storage

• Zypher's upcoming ZERO GAS Alpha Net, supporting shuffling as a precompiled contract

What is Zypher Secret Engine?

As the name suggests, the Zypher Secret Engine protects "on-chain privacy".

Due to predictable game mechanics, the inherent transparency of blockchain made full-chain strategy games impractical in the past.

The Secret Engine supports secure execution of encrypted computations, ensuring the "privacy" of strategic elements on-chain. Mechanisms such as social deception, fog of war, shuffling, randomness, and secret placing can now be integrated into on-chain games with provability.

Currently, the engine provides two core components:

• zk-Shuffle SDK

• zk-Matchmaking SDK

On-chain Shuffling for Mental Poker/Card Games

In 1979, Rivest, Shamir, and Adleman posed a challenge: how to ensure fairness in online poker games without physical cards, without a trusted third party, and with all participants assumed to be dishonest (i.e., cheating)? This problem is also known as "Mental Poker".

In Mental Poker games, ensuring fairness is crucial, and zk-shuffle is a key step. However, the shuffling time significantly affects user experience. The Re-mask operation involves elliptic curve cryptography, resulting in a large circuit for shuffling 52 cards. To reduce the circuit size, we redesigned the PlonK circuit gates, embedding the zk-shuffle algorithm into the base layer (constraint system).

In practice, aside from zk-shuffle, we also face the high gas fee issue of on-chain verification. This article will mainly discuss our optimization insights to reduce gas costs.

Optimizing the "Reveal" Process

zk-shuffle includes two actions:

1) Permuting cards,

2) Re-masking cards.

Assuming the masked card is:

Random numbering:

The remask operation on the masked card C is:

Where G: group element, i.e., Baby Jubjub, H is the aggregated public key.

After completing the above remask operation, we obtain a new masked card:

The actual mask factor for obtaining the masked card is:

Therefore, to reveal the card, each player needs to provide their mask factor. Additionally, there is another method that does not require providing the mask factor, which is the reveal method discussed in this section.

Assuming the player's public-private key pair is:

When revealing a card, the player only needs to compute:

Although revealing a card is just a simple dot product operation, it is important to note that we cannot ensure the player is honest, and we cannot guarantee that the player actually executed the reveal operation. Therefore, we need the player to provide evidence of their reveal action simultaneously.

In the Mental Poker protocol implemented by Geometry Research, they built a reveal proof based on the Chaum Pedersen protocol. However, this proof is extremely costly to verify on-chain, mainly because the entire Chaum Pedersen protocol is based on the Baby Jubjub curve, which is currently not supported as a precompiled contract in the EVM. Therefore, we must natively implement point addition and multiplication operations in the contract, as detailed on GitHub, resulting in very high gas costs for verifying the reveal proof. Although verifying the reveal proof only involves a small number of point multiplications and additions, test results show that the gas cost for native verification can reach 7,629,888, which is clearly unacceptable.

Considering that Baby Jubjub is an embedded curve of BN254, we can use SNARK for the reveal proof. According to the Groth16 verification gas cost, on-chain verification of the reveal proof using Groth16 only requires about 200,000 gas, which is almost 30 times less than the native verification method. Compared to the native verification method, this seems like a very good option. The reveal circuit is as follows:

Optimizing the "Shuffle" Process

Let's take Texas Hold'em as an example. In the game, we need to store the result of the "Shuffle" on-chain. This not only serves as the current Shuffle result but also acts as public input for subsequent "Shuffles," as shown in the set deck operation. Initially, the set deck is stored as the initialized deck by default. However, it is well known that on-chain storage costs are high, especially with large data volumes. A deck of 52 cards contains a total of 208 uint256 type data, making storage costs a significant consideration.

Our solution is to only store partial data on-chain after shuffling, specifically, we only need to store 2n+5 cards, where n is the number of players. Since our game supports a maximum of 6 players, we will use at most 17 cards. This means we ultimately only need to store these 17 cards on-chain.

Although we ultimately only need to store 17 cards on-chain, another purpose of the aforementioned on-chain storage is that these cards will also serve as public input for subsequent shuffles. Therefore, if we only store 17 cards, we cannot verify the correctness of the shuffling.

To address this issue, our zk-shuffle circuit will additionally output the hash of the entire deck as public input, which is also stored on-chain. When verifying zk-shuffle, users will upload the pre-shuffled cards as public input, and the circuit will compute the hash of the uploaded cards and compare it with the hash stored on-chain.

Finally, since only partial data is stored on-chain, users may need to retrieve the complete set of 52 cards. For this purpose, we can use contract events. Events are an extremely low-cost communication method that allows users to obtain complete game data by listening to events.

In summary, this optimization not only effectively reduces storage costs but also ensures the fairness and integrity of the game. All relevant code can be found in the uzkge repository (an early version of the Secret Engine open-sourced under GPLv3).

Zypher Alpha Net: Revolutionizing On-chain Card Games

As emphasized in the Risc Zero partnership announcement, the development team of ZACE is working on a fair on-chain shuffling solution powered by Zypher's zk-Shuffle SDK, while Risc Zero zkVM is used for provable game logic in a full on-chain Texas Hold'em game, currently in the gaming testing phase on the opBNB testnet, significantly optimizing latency and gas costs.

To further provide a Web 2.0 experience for the game, we will soon launch the Alpha Net powered by Zytron Kit (Zytron One Pager), which is our game-specific Sovereign Rollup Stack, featuring 0 Gas, 0.2s Blocktime, enhanced cryptographic precompiles, Zypher game engine, and other precompiled contracts. The Alpha Net will launch several pioneering full-chain games, including Crypto Rumble, z2048, zAce, and other games supporting 0 Gas. Stay tuned!

About Zypher Network

Zypher Network is building the next generation of autonomous world infrastructure, including a range of ZKP-driven game engines from sovereign Layer 3 Rollups to ZK-as-a-service SDKs. Our technology provides the necessary composability, programmability, scalability, and cryptographic primitives for decentralized gaming. It empowers game developers to create rich, interactive on-chain worlds, emphasizing scalability, fairness, and the complexity of game strategies.