Blockchain Pruning via Merkle Tree Commitments
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
The large disk space requirements of blockchain nodes, particularly for full nodes, make it unfeasible for less powerful devices to participate in the blockchain consensus, and light clients lack the ability to validate transactions and verify the honesty of connected nodes, making them vulnerable to attacks.
Innovation Solution
Creating an active blocks commitments Merkle tree and an active smart contracts commitments Merkle tree, which are stored in a new genesis block, allowing nodes to prune their local copies by compressing or deduplicating old blocks, thereby reducing disk space and ensuring transaction validity through network consensus.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If full nodes store the entire blockchain history to validate transactions and ensure transparency, then transaction validation capability and security are improved, but disk space requirements increase significantly
Solution Approach 1:
The patent extracts only the essential validation data (UTXO set, Merkle roots, block headers) from the complete blockchain history, allowing nodes to prune old blocks while retaining transaction validation capability. The UTXO commitment Merkle tree and active block Merkle tree contain only the necessary information to verify transactions without requiring storage of the entire historical blockchain.
Solution Approach 2:
The patent changes the representation parameters of blockchain data by using Merkle tree commitments and UTXO sets instead of storing complete transaction histories. This parameter transformation allows validation to occur with compressed data structures, reducing disk space from hundreds of gigabytes to a fraction of that size while maintaining security.
2Volume of stationary object
If light clients download only blockchain headers and relevant transactions to reduce disk space, then resource consumption is reduced, but ability to validate transactions and verify node honesty is lost
Solution Approach 1:
The patent introduces Merkle tree commitments and UTXO set summaries as intermediary data structures that light clients can verify without needing the full blockchain. These intermediaries act as cryptographic proofs that allow validation of transactions and verification of node honesty using only compressed data, bridging the gap between minimal storage and full validation capability.
Solution Approach 2:
The patent implements partial action by having light clients download only the essential Merkle commitments and UTXO summaries rather than complete transaction histories. This partial data set is sufficient for validation purposes, providing exactly the right amount of information needed without excess, enabling resource-constrained devices to participate securely.
3Volume of stationary object
If nodes prune old blocks to reduce disk space, then storage requirements are reduced, but transparency and ability to audit historical transactions are compromised
Solution Approach 1:
The patent creates cryptographic copies of historical transaction information through Merkle tree commitments and UTXO set summaries stored in pruned blocks. These cryptographic copies preserve the essential information needed for audit and transparency while occupying minimal space, allowing nodes to prune physical block data while maintaining verifiable historical records through the compressed commitment structures.
Data Source
Figure 1(a)~1(b)
Figure 2
Figure 3
AI summary
A method for pruning a blockchain of a blockchain network includes creating an active blocks commitments Merkle tree from hashes of active blocks and creating an active smart contracts commitments Merkle tree from hashes of active smart contracts. The Merkle trees are created after an amount of blocks created in the blockchain has reached a threshold set by a pruning threshold parameter stored in the blockchain network. Hashes of the roots of the Merkle trees are stored in a header of a new block as a new genesis block. The new genesis block is broadcast to the blockchain network. A local copy of the blockchain is pruned at a pruning point in accordance with the pruning threshold parameter based on the blockchain network having reached consensus on the new genesis block.