Zero-Knowledge Proof Chaining for Private Ledger Transaction Verification
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing distributed ledger networks (DLNs) face challenges in reconciling transaction executions while maintaining privacy, as previous methods compromise the privacy of parties involved and transaction details.
Innovation Solution
The use of zero-knowledge proofs (ZKPs) to anonymize transaction preimages and embed portions of previous transactions into subsequent ones, allowing for verification and execution of transactions without revealing sensitive information, while ensuring the correctness of previous transactions.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If all transaction information is made publicly available for verification, then transaction verifiability is improved, but privacy of parties and transactions is compromised
Solution Approach 1:
The transaction data is segmented into two distinct components: preimages (sensitive information) and ZKPs (verification data). The preimages remain private and are never published, while the ZKPs are posted on the ledger for verification. This segmentation allows the system to achieve both privacy and verifiability simultaneously by separating what needs to be hidden from what needs to be verified.
Solution Approach 2:
Zero-knowledge proofs serve as an intermediary mechanism that enables verification without disclosure. The ZKP acts as a mediator between the private preimage and the public ledger, allowing nodes to verify transaction validity without accessing the underlying sensitive data. This intermediary approach resolves the contradiction by providing a third pathway that satisfies both privacy and verifiability requirements.
2Loss of information
If ZKPs are used to anonymize preimages, then privacy is improved, but transaction linking and ordering verification becomes more difficult
Solution Approach 1:
The system creates a cryptographic copy relationship where the ZKP contains verified information about the preimage without revealing the preimage itself. The ZKP is a mathematical copy that proves the validity of the original data while maintaining anonymity. This copying approach allows verification of transaction ordering and linking without exposing sensitive information, resolving the contradiction between privacy and detectability.
Solution Approach 2:
The system transforms the preimage into a different parameter representation (the ZKP) that has different properties. The ZKP maintains the essential verification functionality while changing the form of data to be anonymous and mathematically verifiable. This parameter transformation allows the system to preserve privacy while enabling verification of transaction sequences and links.
3Reliability
If preimages are embedded in subsequent requests, then transaction ordering verification is improved, but privacy is compromised
Solution Approach 1:
The system segments the verification process into two stages: first, the preimage is used to generate a ZKP that proves validity; second, the ZKP (not the preimage) is embedded in subsequent transactions for verification. This segmentation ensures that sensitive preimage data never appears in the public ledger, while still enabling ordering verification through the embedded ZKP references.
Solution Approach 2:
The ZKP serves as an intermediary that replaces the preimage in subsequent transaction links. Instead of embedding sensitive preimage data directly, the system embeds ZKPs that act as verifiable proxies. This intermediary approach maintains privacy while enabling the chaining and ordering verification functionality that would otherwise require direct preimage exposure.
Data Source
AI summary
A non-transitory, processor-readable medium storing instructions that executed by a processor, cause the processor to generate a new zero-knowledge proof (ZKP) for a transaction based on a correctness of a prior ZKP and a prior transaction. The processor is caused to generate a ZKP using data for a first transaction and embed that data into data of a second transaction, to generate a ZKP for the second transaction. The generated ZKPs can be verified by a smart contract on a distributed ledger network that executes the second transaction based on the verification of the ZKP of the second transaction, which in turn is verified if the ZKP of the first transaction is verified.


