Sparse Peer Node for Blockchain Data Filtering
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Centralized databases face issues such as single points of failure, dependency on network connectivity, limited access, and slow transaction speeds, along with challenges in data redundancy and retrieval.
Innovation Solution
Implementing a sparse peer node with transient participation in a blockchain network, utilizing a processor to connect to a blockchain network, select data for replication, specify filters, receive blocks via gossip protocol, and construct a local ledger to bootstrap the sparse peer, allowing for decentralized and secure data storage.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Ease of operation
If a centralized database is used, then data management and control are simplified, but the system has a single point of failure and limited access
Solution Approach 1:
The patent segments the centralized database into multiple distributed peer nodes across a blockchain network. Each peer maintains a copy of the ledger, eliminating the single point of failure while distributing data management responsibilities across multiple entities rather than centralizing control in one location.
Solution Approach 2:
The patent creates multiple copies of the database ledger distributed across numerous peer nodes in the blockchain network. Each peer maintains an identical copy of the ledger, ensuring data availability and reliability even if individual nodes fail, while maintaining consistency through consensus mechanisms.
2Quantity of substance
If a centralized database is used, then data redundancy is minimized, but data accessibility and transaction speed are limited
Solution Approach 1:
The patent segments the monolithic centralized database into a distributed network of peer nodes, where each node independently processes transactions and maintains ledger copies. This segmentation enables parallel transaction processing across multiple nodes, significantly increasing throughput and transaction speed while maintaining data redundancy through distributed storage.
Solution Approach 2:
The patent implements sparse peers that participate transiently in the blockchain network only when needed for specific transactions or data queries. These sparse peers receive selective data subsets matching their filters, reducing unnecessary data transmission and processing overhead while maintaining adequate data redundancy for their specific needs.
3Reliability
If a centralized database is used, then network connectivity dependency is reduced, but the system experiences bottlenecks under high traffic
Solution Approach 1:
The patent segments the centralized processing bottleneck into distributed processing across multiple peer nodes. Each peer independently validates and processes transactions according to its capabilities and filter criteria, eliminating the single-point bottleneck while maintaining network connectivity through peer-to-peer communication protocols.
Solution Approach 2:
The patent implements sparse peers that selectively process only the subset of transactions and data relevant to their specific filters and purposes. This partial participation reduces overall network traffic and processing load, preventing bottlenecks under high traffic conditions while maintaining adequate throughput for each peer's specific needs.
4Stability of the object's composition
If full blockchain synchronization is implemented, then data consistency is ensured, but bootstrap time is increased
Solution Approach 1:
The patent implements sparse peers that synchronize only a partial subset of the blockchain ledger data relevant to their specific filter criteria and operational needs. Instead of downloading and processing the entire blockchain history, sparse peers receive selective data transmissions containing only the transactions and blocks matching their filters, dramatically reducing bootstrap time while maintaining data consistency for their specific purposes.
Solution Approach 2:
The patent establishes filter criteria and data selection rules in advance during peer initialization, allowing the network to pre-filter and prepare relevant data subsets before sparse peers join. This preliminary action enables faster synchronization when sparse peers connect, as the data transmission is already optimized to match their specific needs rather than requiring full ledger synchronization.
Data Source
AI summary
An example operation may include one or more of connecting, by a lead peer, to a blockchain network of an organization configured to store assets, receiving, by the lead peer, from an ordering server, a block that contains a plurality of chaincode transactions belonging to plurality of peers of the blockchain network, applying, by the lead peer, a filter to the block, determining, by the lead peer, a recipient peer of the block in response to the application of the filter, receiving, by the lead peer, a validation result of the block from the recipient peer, and committing, by the lead peer, the block to the blockchain network.