Blockchain Verification Key Recording with Off-Chain Hashes
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing blockchain technologies face challenges in securely and efficiently recording large data blocks, such as verification keys, while maintaining privacy and ensuring cryptographic verifiability, particularly in transactions involving smart contracts and digital assets.
Innovation Solution
A method and system that utilize cryptographic techniques to generate and verify attestation of verification keys using elliptic curve points, enabling secure and efficient recording on the blockchain by outsourcing computational tasks to workers, and generating proofs of correctness that can be verified by nodes, thus reducing computational overhead and power consumption.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If verification keys are recorded directly on the blockchain, then cryptographic verifiability is improved, but blockchain data size and storage requirements increase significantly
Solution Approach 1:
The patent extracts only the essential verification elements (hashes of verification keys) from the complete verification keys and stores them on the blockchain. The full verification keys remain off-chain, allowing cryptographic verification while minimizing on-chain data storage requirements.
Solution Approach 2:
The patent creates cryptographic hashes (copies) of the verification keys that can be stored on the blockchain. These hash copies enable verification of the original keys without storing the full keys on-chain, reducing data size while maintaining verifiability.
2Reliability
If complex cryptographic verification is performed by all blockchain nodes, then security is improved, but computational overhead and power consumption increase
Solution Approach 1:
The patent segments the verification process into two parts: lightweight verification of hashes (performed by all blockchain nodes) and heavy cryptographic verification (performed only when needed by specific participants). This segmentation reduces the computational burden on all nodes while maintaining security.
Solution Approach 2:
The patent enables participants to perform their own verification of transaction validity using the stored hash data, reducing the need for all nodes to perform heavy cryptographic computations. The system serves verification needs through self-verification mechanisms rather than requiring all nodes to perform full verification.
3Loss of information
If anonymous transactions are implemented, then privacy is improved, but ability to verify transaction authenticity becomes more difficult
Solution Approach 1:
The patent introduces cryptographic hashes as an intermediary between anonymous transaction participants and the verification system. These hashes serve as verifiable proof of transaction authenticity without revealing participant identities, bridging the gap between anonymity and verifiability.
Solution Approach 2:
The patent changes the verification parameter from verifying participant identities to verifying cryptographic hashes associated with transactions. This parameter change allows verification of transaction authenticity while maintaining participant anonymity, as the verification focuses on the hash values rather than identity information.
Data Source
Figure 1
Figure 2
Figure 3
AI summary
Systems and methods described herein relate to the execution of locking transactions in a blockchain system. In the context of smart contracts, it may be advantageous to have a public record (e.g., recorded on a blockchain) of a proof of correct execution of a circuit published by a worker and the verification key, thereby allowing anyone (e.g., nodes of the blockchain) to verify validity of the computation and proof. However, there are challenges to recording large blocks of data (e.g., large keys that may comprise multiple elliptic curve points) on the blockchain. For example, in a Bitcoin-based blockchain network, a protocol that utilizes standard transactions may be constrained to locking scripts and unlocking scripts that are collectively not larger than a first predetermined size limit, and the size of a redeem script (if utilized) may be limited to being no more than a second predetermined size limit.