Block Consensus Using Transaction Hashes to Reduce Message Size
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
In distributed consensus algorithms using the Byzantine Fault Tolerance (BFT) protocol, the increasing size of transactions degrades the performance of block consensus, as most prepared blocks are occupied by transactions, leading to a need for a method to reduce the impact of increased transaction sizes or numbers on consensus process performance.
Innovation Solution
A method for block consensus that reduces the size of messages exchanged between nodes by using transaction hashes instead of original transactions, where a prepared block is generated based on transaction hashes consented by a predetermined number of nodes, and only the hashes are transmitted, with the primary node requesting original transactions from specific nodes to minimize duplicate transmissions and optimize message size.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Loss of information
If original transactions are included in prepared blocks and transmitted between nodes, then the completeness of transaction data is improved, but the message size increases significantly degrading consensus performance
Solution Approach 1:
The patent extracts only the essential identification element (transaction hash) from the complete transaction data for inclusion in prepared blocks and consensus messages. The original transactions are excluded from these messages, reducing message size while maintaining the ability to identify and verify transactions through their hashes. This extraction principle directly resolves the contradiction by separating the identification function from the data transmission function.
Solution Approach 2:
The patent uses transaction hashes as compact copies or representations of the original transactions. Instead of transmitting full transaction data, nodes exchange hash values that serve as unique identifiers. The original transactions are retrieved separately from node storage when needed, allowing consensus messages to contain only the essential reference information rather than complete data copies.
2Productivity
If transaction hashes are used instead of original transactions in consensus messages, then message size is reduced improving consensus performance, but the ability to execute transactions directly from messages is lost
Solution Approach 1:
The patent implements preliminary action by having nodes store original transactions in their memory pools before the consensus process. When transaction hashes are included in prepared blocks and consensus messages, the receiving nodes can retrieve the corresponding original transactions from their pre-stored copies. This preliminary storage action ensures that transaction execution capability is maintained without requiring full transaction data in consensus messages.
3Loss of information
If all nodes transmit their transactions to the primary node, then the primary node can assemble a complete prepared block, but network bandwidth is wasted due to duplicate transmissions of the same transactions
Solution Approach 1:
The patent merges the transaction submission process by having multiple nodes contribute their transactions to a shared pool before block assembly. Instead of each node independently transmitting complete transactions to the primary node (which would create duplicates), the system combines the transaction sets from multiple nodes, removing duplicates and keeping only unique transactions. This merging approach ensures transaction variety in the prepared block while eliminating redundant network transmissions.
Data Source
AI summary
A block consensus method of a computing device is provided. The computing device receives a delegate request message including transaction hashes from each of a plurality of nodes, generates a prepared block including transaction hashes based on the delegate request message, and transmits a prepare message including the prepared block to the nodes. The computing device receives a commit message including a proof of consensus on a validity of the prepared block from the nodes, and transmits a reply message including a final block decided based on the commit message.