Blockchain Transaction Verification via Homomorphic Encryption

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing blockchain transaction verification methods are time-consuming due to the need for sequential verification of multiple transactions, which is inefficient for time-sensitive tasks and can compromise privacy by revealing transaction amounts and account balances.

Innovation Solution

Implementing non-interactive privacy-preserving verification methods using commitment schemes and homomorphic encryption to validate multiple blockchain transactions in parallel without revealing transaction amounts, account balances, or random numbers, allowing zero-knowledge proofs for validation without interaction between nodes.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If sequential verification of multiple transactions is used to ensure correctness, then transaction validation accuracy is improved, but verification time increases significantly

Engineering Contradiction:
Improvetransaction validation accuracyVSAvoidverification time
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

The patent applies preliminary action by pre-generating range proofs for multiple transactions before they are submitted to the blockchain network. These range proofs are created in advance using the account balance model, allowing verification nodes to validate multiple transactions simultaneously without performing sequential cryptographic operations. This pre-computation approach enables parallel verification while maintaining the mathematical correctness guarantees of traditional sequential verification.

Inventive Principle:
Principle #10Preliminary action

2Reliability

If encryption technologies are implemented to protect user privacy, then data security is improved, but computational complexity increases

Engineering Contradiction:
Improvedata securityVSAvoidcomputational complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The patent extracts the computationally intensive cryptographic operations from the verification process. By using the account balance model with pre-generated range proofs, the heavy computational burden of proving transaction validity is shifted to the transaction initiator rather than the verification nodes. Verification nodes only need to perform simple validation checks on the provided proofs, dramatically reducing their computational complexity while maintaining strong privacy protection through cryptographic commitments.

Inventive Principle:
Principle #2Taking out (Extraction)

3Reliability

If multiple range proofs are verified sequentially to ensure transaction validity, then proof correctness is improved, but processing efficiency deteriorates

Engineering Contradiction:
Improveproof correctnessVSAvoidprocessing efficiency
Core Design Contradiction:
ReliabilityVSProductivity

Solution Approach 1:

The patent merges multiple individual range proof verifications into a single parallel verification process. By representing multiple transactions and their corresponding range proofs in a unified account balance model framework, the system can verify all proofs simultaneously using homomorphic properties of the underlying cryptographic commitments. This combining approach maintains the rigorous correctness checks of individual proof verification while achieving parallel processing efficiency.

Inventive Principle:
Principle #5Merging (Combining)

Data Source

PatentUS11063769B2Blockchain data protection based on generic account model and homomorphic encryption
Publication Date: 2021.07.13 ANTCHAIN TECHNOLOGY PTE LTD
  • US11063769B2 patent drawing
  • US11063769B2 patent drawing
  • US11063769B2 patent drawing

AI summary

Implementations of the specification include receiving transaction data associated with the transaction, the transaction data comprising: data representative of a plurality of assets, a first commitment hiding a first random number and a transaction amount of the transaction, a second commitment that hides a second random number and a change, the transaction amount and a third random number both encrypted by a public key of the second node, the change and a fourth random number both encrypted by a public key of the first node, and a zero-knowledge proof (ZKP); determining, based on the ZKP, whether the transaction is valid based on determining if the first random number is equal to the third random number, the second random number is equal to the fourth random number, and the transaction amount hidden in the first commitment is equal to the transaction amount encrypted by the public key of the second node.