Distributed Transaction Validation for Byzantine Fault Detection

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

Existing data management systems face challenges in detecting Byzantine faults while ensuring strict serializability and enabling parallel transaction execution, as secondary nodes in systems like PeerReview require sequential replay of total-order hash-chained execution logs, limiting overall parallelism.

Innovation Solution

A data management system with first and second computer systems, where a client transmits transaction requests to first and second servers that execute a same decision function, involving an ordering, commit, and validation phase to detect Byzantine faults, ensuring strict serializability and parallel transaction execution.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If secondary nodes sequentially replay the total-order hash-chained execution log to detect Byzantine faults, then Byzantine fault detection capability is improved, but transaction execution parallelism deteriorates

Engineering Contradiction:

ImproveByzantine fault detection capabilityVSAvoidtransaction execution parallelism

Core Design Contradiction:

ReliabilityVSProductivity

Solution Approach 1:

The system divides the verification process into segments by having multiple secondary nodes independently verify different portions of the execution log simultaneously. Each secondary node maintains its own verification state and can process log entries in parallel, transforming the sequential verification bottleneck into a parallelizable process while maintaining Byzantine fault detection capability.

Inventive Principle:

Principle #1Segmentation

Solution Approach 2:

The primary node performs preliminary actions by creating and broadcasting the total-order hash-chained execution log before secondary nodes begin verification. This pre-computed log structure with embedded state roots enables secondary nodes to independently verify transactions without needing to replay entire execution histories sequentially, allowing parallel verification while maintaining security.

Inventive Principle:

Principle #10Preliminary action

2Stability of the object's composition

If the system ensures strict serializability through sequential log replay, then consistency is improved, but transaction throughput deteriorates

Engineering Contradiction:

Improvestrict serializability consistencyVSAvoidtransaction throughput

Core Design Contradiction:

Stability of the object's compositionVSProductivity

Solution Approach 1:

The system adds a new dimension to consistency verification by using cryptographic state roots and hash chains instead of sequential state transitions. This allows multiple secondary nodes to verify consistency in parallel by checking cryptographic proofs rather than replaying transactions sequentially, maintaining strict serializability guarantees while enabling parallel throughput.

Inventive Principle:

Principle #17Another dimension (Dimensionality change)

Solution Approach 2:

Secondary nodes create and verify copies of the execution log and state roots independently in parallel. Each node maintains a copy of the total-order log and verifies it against the primary node's state, allowing simultaneous verification without interfering with each other's processing, thus improving throughput while preserving consistency.

Inventive Principle:

Principle #26Copying

3Productivity

If secondary nodes independently execute transactions without sequential replay, then transaction parallelism is improved, but Byzantine fault detection accuracy deteriorates

Engineering Contradiction:

Improvetransaction execution parallelismVSAvoidByzantine fault detection accuracy

Core Design Contradiction:

ProductivityVSMeasurement precision

Solution Approach 1:

The system implements feedback mechanisms where secondary nodes continuously verify the primary node's execution against the total-order log and report discrepancies. The hash-chained structure provides cryptographic feedback that allows parallel nodes to detect Byzantine faults by verifying state roots and transaction outcomes, maintaining detection accuracy while enabling parallel execution.

Inventive Principle:

Principle #23Feedback

Solution Approach 2:

The total-order hash-chained execution log serves as an intermediary structure that all nodes can independently verify. This intermediary provides a shared reference point that enables parallel verification without requiring sequential replay, as each node can independently check the cryptographic integrity of the log against the primary node's state, maintaining Byzantine fault detection accuracy.

Inventive Principle:

Principle #24Intermediary (Mediator)

Data Source

PatentUS12481645B2Data management system and method for detecting byzantine fault

Publication Date: 2025.11.25 SCALAR INC

AI summary

A data management system constituted of first and second computer systems includes a client, and first and second servers which execute a same decision function with respect to identical transaction requests. The first server is provided in the first computer system and the second server is provided in the second computer system. For each transaction request, in an ordering phase, the second server orders a transaction request from the client into a strict serializable partial order, in a commit phase, the first server executes a transaction in accordance with the transaction request from the client in the partial order and returns to the client a first response, and in a validation phase, the second server executes a transaction in accordance with the transaction request from the client in the partial order and returns to the client a second response.