Blockchain Pruning With State Databases for Transaction Validation
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing blockchains face inefficiencies due to significant data sizes, making transmission and storage impractical, and existing pruning methods require full copies of the blockchain for validation, limiting their effectiveness.
Innovation Solution
Implementing a system that uses current genesis blocks, configuration values, and state databases to enable pruning while maintaining the ability to validate transactions and execute smart contracts without requiring full blockchain copies, by utilizing state databases to store unspent transaction outputs and aggregating smart contract states.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If traditional immutable blockchain storage is used, then transaction validation reliability is ensured, but blockchain data size grows indefinitely making storage and transmission impractical
Solution Approach 1:
The blockchain data is segmented into two distinct parts: immutable block headers that remain on the ledger, and mutable transaction data that can be pruned. This segmentation allows nodes to store only essential validation information while removing redundant transaction details, resolving the contradiction between maintaining validation reliability and reducing data size.
Solution Approach 2:
Transaction data is extracted from the immutable blockchain structure and stored separately in a state database. The blockchain retains only block headers containing cryptographic references, while the extracted transaction details can be pruned without affecting validation capability, as the state database preserves the necessary validation information.
2Quantity of substance
If blocks are pruned from blockchain storage, then data size is reduced, but nodes unable to retain full copies cannot validate transactions whose inputs are in pruned blocks
Solution Approach 1:
A state database acts as an intermediary between the pruned blockchain and transaction validation. It stores unspent transaction outputs and enables nodes to validate transactions without requiring access to the original transaction data in pruned blocks, thus maintaining validation capability while allowing aggressive pruning.
Solution Approach 2:
Essential validation information is copied from the original transaction data into the state database. Instead of storing complete transaction records, nodes maintain compact copies of unspent transaction outputs that are sufficient for validation, enabling pruning of the original data while preserving validation functionality.
3Measurement precision
If complete transaction data is retained for validation, then transaction validation accuracy is maintained, but storage requirements become prohibitive over time
Solution Approach 1:
Validation-critical information is extracted from complete transaction records and stored in the state database. Only essential data elements needed for validation (such as unspent transaction output information) are retained, while redundant transaction details are removed, maintaining validation accuracy with minimal storage requirements.
Solution Approach 2:
The storage model transitions from retaining complete transaction records to storing only essential validation parameters in the state database. This parameter change reduces storage requirements from gigabytes to much smaller sizes while preserving the ability to perform accurate transaction validation through cryptographic verification.
Data Source
AI summary
A method for confirming configuration of a new current genesis block in a blockchain configured to enable pruning before the new current genesis block includes: receiving, by a blockchain node in a blockchain network, a genesis response message from another node in the network, the message including a configuration value and an ordinal value; identifying a plurality of standard blocks in the blockchain added subsequent to an earlier genesis block that includes a number preceding the ordinal value; aggregating smart contract state changes from each of the identified plurality of standard blocks; and validating the configuration value included in the received genesis response message based on the aggregated smart contract state changes. The aggregating of smart contract states can be done by the processor of the blockchain node configuring the new current genesis block, or by another blockchain node.