ZK Proof

When edge nodes communicate with each other without a centralized server to validate the data, each node must independently verify the data’s validity. This verification can be accomplished using zk-SNARK proofs.

Publisher

  1. Download zk-SNARK Proof Circuit from IPFS: Before generating a zk proof for the first time, the publisher edge node downloads the zk-SNARK proof circuit from IPFS storage.

  2. Generate Initial zk Proof: Using the downloaded proof circuit, the publisher generates an initial zk proof for the user's location (e.g., moving to (10, 20, 15)). This proof demonstrates that the user's location is valid and adheres to the game's rules.

  3. Recursive zk Proof Generation for Subsequent Movements: For subsequent movements (e.g., from (10, 20, 15) to (10, 22, 17)), the publisher uses the previous zk proof to generate a new zk proof recursively. This recursive process allows the publisher to prove the validity of the new location based on the previous location's proof, without needing to re-verify the entire history of movements.

  4. Publish the zk Proof and Location: The publisher then publishes this new zk proof, along with the updated location, over the network to the subscribers.

Subscriber

  1. Receive the zk Proof and Location: Subscriber edge nodes receive the new zk proof and the updated location from the publisher.

  2. Verify the zk Proof: Each subscriber verifies the zk proof against the verifier smart contract deployed on the Hokum blockchain. This verification process ensures that the new location is valid and adheres to the game's rules. The verification is done recursively, using the previous zk proof to verify the new location's proof.

  3. Update Game State: If the zk proof is verified successfully, the subscriber updates its game state to reflect the new location of the user. This ensures that all players in the game have a consistent view of the user's location.

Handling Recursive zk Proofs

  • Efficiency: By using recursive zk proofs, the system can efficiently handle the verification of user movements without the need to re-verify the entire history of movements for each new location. This approach significantly reduces the computational overhead and improves the overall efficiency of the network.

  • Security: Recursive zk proofs enhance the security of the system by ensuring that each new location is validated based on the previous location's proof. This recursive verification process prevents unauthorized modifications to the user's location.

  • Scalability: The use of recursive zk proofs allows the system to scale to a large number of user movements without significantly impacting performance. This is crucial for maintaining a fluid and engaging gaming experience, especially in a game like Minecraft with potentially thousands of concurrent users.

Payment Collector

  • Aggregate zk-SNARK Proofs: A specialized edge node, referred to as the Payment Collector, aggregates zk-SNARK proofs from various publishers. This aggregation is necessary for efficiently processing and billing for the bandwidth costs associated with the data published on the network.

  • Submit Proofs to the Edge Sequencer Controller Contract: The Payment Collector submits the aggregated proofs to the Edge Sequencer Controller Contract. This contract is responsible for processing the proofs and billing game developers for the bandwidth costs associated with the data published on the network.

  • Billing for Bandwidth Costs: The Edge Sequencer Controller Contract processes the proofs to determine the bandwidth costs. These costs are then billed to the game developers, who are responsible for covering the costs associated with the use of the P2P network.

Last updated