Blockchain Ordering Service Fault Detection via Signed Promises
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Blockchain transactions with lower transaction fees often become stagnant due to a lack of interest from miners, leading to delayed processing as they wait for more rewarding tasks, and there is a need to detect and address Byzantine faults such as equivocation and denial of service faults in blockchain ordering services.
Innovation Solution
Implementing a method that includes initiating a timer to audit blockchain transactions, randomly selecting a committer node, requesting and verifying the hash of a blockchain block, and using a signed promise mechanism to ensure transaction inclusion based on queue length, thereby detecting and preventing faults like equivocation and denial of service.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Productivity
If miners are rewarded based on transaction fees alone, then low-fee transactions become stagnant and wait longer for processing, but increasing rewards for all transactions increases operational costs
Solution Approach 1:
The system changes the reward parameter from fixed transaction fees to dynamic block space allocation. Instead of miners competing solely on fee bids, the ordering service allocates block space as a reward parameter, allowing transactions to be included based on pre-allocated space rather than fee magnitude alone.
Solution Approach 2:
The ordering service acts as an intermediary between transaction submitters and miners. It receives transactions, assigns them to blocks based on queue length and allocated space, and provides signed promises to miners. This intermediary eliminates the need for miners to directly compete on transaction fees while ensuring fair distribution of block space.
2Productivity
If the ordering service processes transactions without verification, then processing speed increases, but Byzantine faults such as equivocation and denial of service cannot be detected
Solution Approach 1:
The system performs preliminary verification by the ordering service before transactions reach miners. The ordering service validates transaction formats, checks queue lengths, and assigns block numbers in advance. This preliminary action ensures that only valid transactions are included in blocks, preventing Byzantine faults while maintaining processing efficiency.
Solution Approach 2:
The system implements feedback mechanisms where the ordering service monitors transaction queue lengths and provides signed promises to miners about block inclusion. This feedback loop allows the system to detect anomalies such as equivocation (when the ordering service provides conflicting information) and denial of service (when transactions are not included as promised), enabling reliable fault detection without slowing processing.
3Productivity
If miners wait for high-reward transactions, then processing efficiency decreases, but processing low-fee transactions immediately reduces miner incentives
Solution Approach 1:
The system segments the transaction pool into different blocks with pre-allocated space. Instead of miners selecting transactions from a single competitive pool, transactions are divided into separate block assignments. Each miner receives a specific block with guaranteed space, eliminating the need to wait for high-reward transactions while maintaining incentive through assured block inclusion.
Solution Approach 2:
The ordering service performs preliminary allocation of block space to miners before transactions are processed. Miners receive signed promises guaranteeing their inclusion in specific blocks based on queue length and allocated space. This preliminary action ensures miners have immediate work available without sacrificing reward incentives, as their block space allocation serves as the incentive rather than transaction fee competition.
Data Source
AI summary
An example operation may include one or more of signing a blockchain transaction by an endorsement peer member of a blockchain, transmitting the blockchain transaction to an ordering service, identifying a blockchain transaction queue length, and receiving a signed promise from the ordering service that the blockchain transaction will be included in an identified block number based on the blockchain transaction queue length.