Blockchain Naming System for High Integrity Distributed Storage
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Conventional blockchain processing systems face issues such as loss of transaction semantics, high bandwidth and latency costs, and inefficiencies due to reliance on read-write sets and frozen states during consensus, leading to wasted transactions and poor performance.
Innovation Solution
The implementation of a blockchain naming system (BNS) and functional transactions (FTs) that encapsulate transaction logic in function closures, allowing for parallel processing and optimized block ordering, reducing the need for frozen states and improving transaction validation.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Quantity of substance
If conventional read-write sets are used to record transactions, then data redundancy is minimized and storage efficiency is improved, but transaction semantics are lost and audit requirements cannot be met
Solution Approach 1:
The patent segments the transaction recording into two distinct parts: a compact RW-set for state transitions (minimizing redundancy) and a separate execution log for transaction semantics (preserving information). This allows each component to serve its optimal purpose independently.
Solution Approach 2:
The execution log acts as an intermediary layer between the RW-set and the audit trail. It captures the semantic details of transactions while the RW-set maintains efficient state tracking, resolving the contradiction between storage efficiency and information preservation.
2Productivity
If large RW-sets are transferred around the blockchain network, then transaction processing is completed, but bandwidth and latency costs increase
Solution Approach 1:
The patent extracts the transaction semantics from the RW-set and places them in a separate execution log. Only the essential RW-set is transferred across the network, while the semantic details remain localized, significantly reducing bandwidth requirements and latency.
Solution Approach 2:
Instead of copying large RW-sets across all network nodes, the system creates a compact representation (execution log) that can be efficiently replicated and stored locally, reducing network traffic while maintaining processing capability.
3Reliability
If all endorsing peers must achieve consensus on an identical RW-set, then data integrity is maintained, but overlapping state changes waste transactions due to latency
Solution Approach 1:
The patent introduces dynamic execution logs that can be updated independently by different endorsing peers without requiring consensus on the entire RW-set. This allows the system to maintain data integrity through the execution log while improving throughput by avoiding delays from overlapping state changes.
Solution Approach 2:
By segmenting the consensus requirement into two parts (RW-set for state changes, execution log for semantics), the system allows overlapping transactions to proceed in parallel without wasting resources, while still maintaining integrity through the linked execution logs.
4Loss of information
If private transaction context is recorded to maintain context, then transaction completeness is improved, but data privacy is compromised
Solution Approach 1:
The patent applies local quality by differentiating between public and private transaction components. The execution log stores private context locally at each node without broadcasting it across the network, while only the necessary public RW-set is shared, maintaining both completeness and privacy.
Data Source
AI summary
An example operation may include one or more of constructing a transaction proposal and sending the constructed transaction proposal to a plurality of endorsing nodes, by a client application of a computing system, wherein inputs to the transaction proposal are named using a blockchain naming system (BNS), receiving a set of transaction responses from the plurality of endorsing nodes, by the client application of the computing system, the transaction responses each comprising a transaction validation function, assembling the received transaction responses into a transaction, by the client application of the computing system, and sending the transaction to an orderer node for distribution, by the client application of the computing system.


