Distributed Blockchain Transaction Processing via Segmented Runtime Environments
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing blockchain systems running within a single data center face performance limitations due to the inability of transaction processing elements to perform transactions in parallel, which restricts their capacity and efficiency.
Innovation Solution
Implementing a distributed blockchain transaction processing component across multiple servers in a data center, where calls to smart contracts are dispatched to runtime environments on different servers, enabling parallel execution and consensus mechanisms to efficiently commit transactions to a blockchain database.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If transaction processing elements run on individual servers communicating via IP protocol, then system reliability is improved through distribution, but transaction processing speed deteriorates due to inability to perform parallel transactions
Solution Approach 1:
The transaction processing element is segmented into multiple independent runtime environments distributed across multiple servers. Each runtime environment can independently execute transactions in parallel, eliminating the bottleneck of sequential processing while maintaining distributed architecture for reliability.
Solution Approach 2:
The system transitions from single-dimension sequential transaction processing to multi-dimension parallel processing by introducing multiple runtime environments that can simultaneously handle different transactions. This dimensional expansion enables parallel execution while preserving the distributed system structure.
2Adaptability or versatility
If transaction processing elements communicate via IP protocol across wide area network, then system adaptability is improved for peer-to-peer distribution, but transaction processing capacity deteriorates due to communication overhead
Solution Approach 1:
Multiple runtime environments are merged into a unified transaction processing system that shares common resources and coordination mechanisms. This merging enables parallel transaction processing while reducing communication overhead through optimized inter-runtime communication protocols.
Solution Approach 2:
An intermediary coordination layer is introduced between the distributed runtime environments and the blockchain database. This mediator optimizes communication by batching transactions, managing consensus coordination, and reducing individual communication overhead between runtime environments and persistent storage.
3Device complexity
If single server hosts transaction processing element, then device complexity is reduced, but system availability deteriorates due to single point of failure
Solution Approach 1:
The single transaction processing element is segmented into multiple independent runtime environments distributed across multiple servers. This segmentation eliminates single points of failure while maintaining manageable system complexity through standardized runtime environment templates that can be replicated across servers.
Solution Approach 2:
Each server in the distributed system is configured with specific local qualities - certain runtime environments are deployed on specific servers based on workload characteristics, resource availability, and failure domain considerations. This local optimization improves overall system availability while keeping individual server configurations relatively simple.
Data Source
Figure 1
Figure 2
Figure 3
AI summary
Methods and systems for implementing a distributed blockchain transaction processing element in a data center are described. A call to a function is received. The call for the function is dispatched to a first runtime environment of a first server. Code is fetched from the blockchain database. The code is executed in the first runtime environment resulting in a blockchain transaction. A copy of the blockchain transaction is written in a storage medium that is locally accessible by the first server. The blockchain transaction is added to a first block. A consensus mechanism is used to determine whether the first block is to be added to the blockchain database; and responsive to determining that the first block is to be added to the blockchain database, the first block is caused to be stored in a persistent storage as part of the blockchain database.