Sparse Peer Node for Blockchain Data Selection and Bootstrap
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
1Device complexity
If a centralized database is used, then data storage and management is 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 network. Each peer maintains a copy or portion of the data, eliminating the single point of failure while distributing management responsibilities. This segmentation transforms the monolithic centralized structure into a resilient distributed architecture where failure of individual nodes does not compromise the entire system.
2Ease of operation
If a centralized database is used, then control and security are easier to manage, but transaction speed is slow and network dependency is high
Solution Approach 1:
The patent divides the centralized database control functions among multiple peer nodes in the network. Each peer can independently process transactions and validate data, reducing network dependency and increasing transaction throughput. This distributed control architecture eliminates the bottleneck of centralized processing while maintaining security through consensus mechanisms.
Solution Approach 2:
The patent implements data replication across multiple peers, creating redundant copies of data beyond the single centralized location. This excessive replication ensures that transactions can be processed in parallel across multiple nodes, significantly increasing transaction speed while maintaining data integrity through consensus validation.
3Quantity of substance
If a centralized database is used, then data redundancy is minimized, but data access by multiple devices is limited
Solution Approach 1:
The patent segments data storage across multiple peer nodes, with each peer holding a copy or portion of the data. This segmentation enables multiple devices to access data simultaneously from different peers, greatly enhancing data access capability while the replication strategy ensures appropriate redundancy for fault tolerance.
Solution Approach 2:
The patent creates multiple copies of data across distributed peer nodes in the network. These replicated copies enable simultaneous access by multiple devices without interfering with each other, while the copying mechanism itself provides the necessary redundancy for system reliability and data availability.
4Reliability
If full blockchain replication is implemented, then data security and integrity are improved, but bootstrap time is excessive
Solution Approach 1:
The patent extracts and removes unnecessary data from the replication process by implementing selective data replication. Peers only replicate and store data that is relevant to their specific functions and requirements, rather than replicating the entire blockchain dataset. This extraction significantly reduces bootstrap time while maintaining security and integrity for the replicated portions.
Solution Approach 2:
The patent implements partial replication where peers replicate only a subset of blockchain data rather than the complete dataset. This partial action approach reduces the time and resources required for bootstrapping new peers while maintaining sufficient data security and integrity for the specific use case, trading off complete replication for faster deployment.
Data Source
AI summary
An example operation may include one or more of connecting, by a sparse peer, to a blockchain network of a plurality of peers controlled by orderers, selecting, by the sparse peer, a subset of data to be replicated, specifying, by the sparse peer, data selection filters based on the selected subset of the data, providing, by the sparse peer, the selection filters to the plurality of the peers, receiving, by the sparse peer, blocks matching the selection filters over a gossip protocol from the plurality of the peers, constructing, by the sparse peer, a local ledger of the sparse peer from the received blocks, and bootstrapping the sparse peer based on the local ledger.