THINKIUM SYSTEM ARCHITECTURE

1. Hierarchical multi-level chain structure
The chain structure of the Thinkium core engine is a hierarchical multi-level chain structure. The chain is divided into two types: the main chain and the business chain. Each chain is a completely independent system with its status. The main chain acts as the leader and coordination of the entire system. As an entry point and source of trust for the business chain, it records the metadata and summary of the confirmed blocks of each business chain, generates random seeds used in committee elections for all chains, and records the election results. At the same time, from the business, the workload is shared by all business chains and the contract is calculated in parallel using a message-driven protocol based on the Actor model. All nodes in the system maintain the state of the main chain, by updating and verifying the main chain’s blocks, nodes can verify that they have included any block data of the business chain in the main chain. This structure has the following main advantages:
• Nodes joining the system only need to obtain the current state of the main chain from a trusted source or rebuild from the genesis block and do not need to synchronize all the data of the entire system, which greatly reduces the load of the entire system.
• The consensus of each chain is executed independently and in parallel, which greatly reduces the network bandwidth and computing processing requirements.
• The main chain can act as the coordinator of the system; it provides cross-chain synchronization and allows the entire system topology to be dynamically adjusted.
• Nodes can use the summary in the main chain and Merkle proof to verify transactions initiated from another business chain. Therefore, the block producer of the business chain does not need any information from other business chains to process inter-chain transactions. According to different transaction types or business entities, different business chains can be divided into separate operations.
They can run independently and completely independently. Cross-chain communication can be carried out through the evidence provided by the main chain. It can also form dependent parent-child relationship chains with dependent links. The child chain inherits some attributes of the parent chain. The currency type of the account balance on this chain, the election method of the chain, etc.
The Thinkium core engine allows each business chain to expand its sub-chain, but in fact, the problem can be solved within three layers. Whether it is the main chain or the business chain, there may be congestion due to too many requests and become slow. When congestion occurs, the chain can be shard to distribute requests to different shards to improve the throughput of the chain. As the number of shards increases, the throughput of the chain increases linearly.
The shard itself is also an independently running chain, and there will be a parallel model for cross-shard transaction requests between shards, which greatly improves the speed of cross-shard transaction execution between shard chains. This hierarchical and multi-level structure has good flexibility and scalability and can be dynamically adjusted, so each chain will not become a performance bottleneck for the entire network. Also, as the number of chains increases, the overall system’s throughput increases linearly without generating too many redundant messages.
2. Four-Layer System Structure
Based on the above hierarchical multi-level chain structure, a four-layer implementation framework is designed to facilitate the future scalability and upgrade of the system. The first layer mainly addresses the overall system-wide consensus and is mainly responsible for dividing requests and nodes and assigning different requests to specific committees for processing. All requests are first sent to the task layer, where they will be split and assigned to different committees for parallel processing. Since not all requests can be processed in parallel, they need to be divided according to their type. Besides, all active nodes are registered at the task layer. These nodes are randomly divided into different committees and assigned different requests. We need to ensure that each committee is credible, that is, the proportion of malicious nodes within each committee does not exceed a certain threshold set by the system. The second layer mainly solves the single-chain consensus problem and needs to process the allocated requests and generate logs.
Each committee contains a set of nodes. When the committee receives a given request, it needs to process the request, reach a consensus, and generate a log. Since each, the trustworthiness of the committee is guaranteed by the upper layer, this layer only needs to consider how to reach consensus in the committee as soon as possible.
The third layer mainly solves the consensus between multiple chains. The logs and request data generated by each committee are aggregated according to a specific encoding method to form a single log. The goal of the system is to generate a consistent log for each node. Therefore, aggregation algorithms are needed to integrate all the logs generated by the nodes in the committee and reach a unified log. Coding methods are also needed to reduce the storage of each node. Besides, since nodes will join and leave the committee from time to time, it is necessary to make the corresponding from the data layer is synchronized.
The fourth layer is the network layer, which is the basic layer that establishes connections between nodes and provides communication. This layer is the basis of the entire system and establishes communication between computing nodes. Within the network layer, we can build a multi-layer network with a consensus network layer for each committee.
Browser Github
Community and media： Twitter Telegram Discord
Medium GitHub Reddit