Exploring the Delegation of zkSNARKs Computation with Aleo
1. Overview of zkSNARKs
zkSNARK is a cryptographic protocol that allows one party (the prover) to convince another party (the verifier) of the truth of a statement without revealing any specific information other than the fact of the truth of the statement. This protocol is “succinct” and “non-interactive”, meaning that the proofs can be very short and do not require extensive message exchange between the parties.
1.1 Practical applications
1.1.1 Private Transactions:
zkSNARKs can be used to ensure transaction confidentiality in the blockchain. This allows users to conduct transactions without disclosing information about the amount, participants, or other details.
1.1.2 Private Smart Contracts:
In the context of smart contracts, zkSNARKs can help create systems where the logic of contract execution remains hidden, but its execution can still be verified.
1.1.3 Decentralized Games with Hidden Information:
Using zkSNARKs, developers can create games where certain information (for example, the cards in a player’s hand) remains hidden from other participants.
Despite these advantages, there is a key issue associated with zkSNARKs: the computational complexity of creating proofs. The process of creating zkSNARK proofs can be extremely resource-intensive, which threatens their practical application in real-world scenarios.
2. Computational Load Problem and Approaches to Delegation
2.1 Description of the Problem: Slow Computation in zkSNARK
One of the main problems in using zkSNARKs is the high computational load, especially in the process of creating proofs. For clarity: if you try to prove something that involves hashing 10 kilobytes of data using SHA-256, it can take more than two minutes, while traditional hashing on a computer takes only milliseconds. This means that creating zkSNARK proofs is a significantly slower process than many other cryptographic operations, which limits their practical application.
2.2 Possible Approaches to Delegation of Computations
In response to this problem, researchers and developers are exploring various ways to delegate the process of creating proofs in zkSNARKs to reduce the computational burden on individual users. Some of the discussed approaches include:
2.2.1 Using Cloud Solutions:
One approach is to use powerful cloud servers to perform computations. This can significantly speed up the proof creation process, especially for complex tasks. For example, using clusters to perform computations can significantly speed up the process.
2.2.2 Confidentiality Issue in Delegation:
However, delegating computations to the cloud carries risks to confidentiality. By delegating work to servers or clusters, you may disclose secret information (so-called “witness” data), which you originally wanted to keep secret.
2.2.3 Delegation with Confidentiality Support:
The ideal scenario includes delegating the proof creation process while maintaining data confidentiality. This approach involves using delegation schemes that allow for the obfuscation (masking) of witness data before sending it for processing in the cloud, as well as minimizing interaction between the cloud and the delegator.
2.2.4 Efficiency and Confidentiality Protection:
It is important that delegated computations are not only efficient but also protect the personal data of the delegator. Direct methods of using cryptographic tools such as multi-party computations (MPC) and fully homomorphic encryption (FHE) often turn out to be too resource-intensive.
2.2.5 Delegation with Threshold Privacy:
Another approach is to delegate computations to a network of machines, where data confidentiality is guaranteed if at least one of the machines remains reliable and does not collude with others. This allows for a more realistic security model, assuming that different cloud providers, such as AWS, Google Cloud, and Azure, may not collude with each other.
3. Protection of Confidentiality in Delegation
When delegating zkSNARK computations, it is especially important to ensure the protection of data confidentiality during their processing.
3.1 General Principles of Confidentiality Protection
The protection of confidentiality in the delegation of zkSNARK computations is associated with ensuring that sensitive information (witness data) remains inaccessible to third parties, even during processing on remote servers. This means that delegated computations must be carried out in such a way as to ensure the complete anonymity of the original data, even if they are being processed on third-party devices or in the cloud.
3.2 Use of Secret Splitting and Additive Homomorphism
One approach to protecting data confidentiality in delegation involves the use of secret splitting and additive homomorphism techniques. Secret splitting allows data to be divided into several parts (or shares), with all parts required to reconstruct the original information. This means that even if some parts of the data become known, without all the other parts, the information remains incomplete and meaningless.
Additive homomorphism is a property of some cryptographic systems that allows arithmetic operations to be performed on encrypted data without decrypting it. In the context of delegating zkSNARK computations, this means that necessary mathematical operations can be performed on the data while maintaining their confidentiality.
These methods together provide a powerful tool for preserving the privacy of data during processing. When applied correctly, they allow for the processing of data without disclosing its content, which is a key requirement for protecting confidentiality in zkSNARKs.
