High-speed alliance block chain system based on reflective memory

Abstract

The invention provides a high-speed alliance block chain system based on a reflective memory. Each node in the system comprises a network transmission layer and a block management layer. And the block management layer is used for completing a process from node transaction initiation to block consensus and block synchronous uplink based on the reflective memory. The network transmission layer comprises an Ethernet-based transmission layer and a reflective memory-based transmission layer; the transmission layer based on the Ethernet is used for carrying out communication irrelevant to a consensus process among nodes based on a P2P protocol of a TCP / IP protocol; the transmission layer based on the reflective memory comprises a reflective memory communication API (Application Program Interface) and the reflective memory; the reflective memory communication API is used for providing a read-write reflective memory address space, an interrupt mechanism event notification and an interface function acquired by a reflective memory ID for the node; the reflective memory is used for responding to calling of a reflective memory communication API interface function and completing read-write of a reflective memory address space, notification of an interrupt mechanism event and acquisition of a reflective memory ID. According to the invention, the throughput of the block chain system can be improved.

Description

Technical Field

[0001] The present invention relates to blockchain technology, and in particular to a high-speed alliance blockchain technology based on reflective memory. Background Art

[0002] Reflective memory network is a shared memory system designed for efficient data sharing between multiple independent computers. In this system, nodes communicate through optical fiber connections, and each node has an independent copy of shared memory, aiming to provide real-time data access and collaborative operations. Each node has the authority to write data and read local memory, allowing fast and flexible information exchange between nodes.

[0003] In the architecture of the real-time reflective memory network, when data is written to the local memory, the system uses the field programmable gate array FPGA to capture it and send the data to the next node in the network. This process continues until the data returns to the source node, and then the system removes the data from the network. This design allows data to be transmitted throughout the network in an efficient manner, achieving real-time and real-time collaboration requirements. At the same time, reflective memory provides an interrupt mechanism that can quickly implement event notifications between nodes. Overall, the reflective memory network provides an innovative data sharing solution that meets the high requirements for real-time, efficiency, and collaboration by minimizing data access latency and achieving real-time data delivery.

[0004] As a distributed ledger technology, blockchain is a network where data is connected in the form of blocks. Each block contains the hash value of the previous block, making it decentralized, unalterable, and highly secure.

[0005] Consortium chains are the evolution of blockchain technology within enterprises and organizations. Compared with public chains, consortium chains focus more on establishing a limited group of participants who are authorized to jointly manage and maintain the entire blockchain network. Consortium chains usually adopt a permission control mechanism, and only authorized members can participate in transactions and verification. This design increases transaction speed and reduces energy consumption while maintaining a certain degree of decentralization and transparency.

[0006] The consensus algorithm in the blockchain distributed storage system is used to confirm the authenticity, integrity and availability of the stored data. However, most of the existing blockchain consensus algorithms are based on the TCP protocol for communication. The data packet needs to start from the application layer and be copied and sent through different layers such as the kernel layer, link layer, and physical layer. This makes the current blockchain network have defects such as many network communication rounds, large interactive data, and high communication delay. This defect greatly limits the transaction packaging rate of the blockchain system, resulting in low overall system performance and limiting the further application and development of blockchain. Summary of the invention

[0007] In view of the problems of low communication efficiency and high latency in existing blockchain networks, the present invention proposes a high-speed alliance blockchain system that improves system throughput through higher consensus efficiency.

[0008] The technical solution adopted by the present invention to solve the above technical problems is a high-speed alliance blockchain system based on reflective memory, in which each node in the system includes a network transmission layer and a block management layer;

[0009] The network transport layer includes an Ethernet-based transport layer and a reflective memory-based transport layer. The Ethernet-based transport layer is used for P2P protocols based on TCP / IP to communicate between nodes that are not related to the consensus process. For example, block synchronization, transaction query, and snapshot communication between blockchain nodes are usually data synchronization between nodes and do not affect the transaction throughput of the block. At the same time, using Ethernet to communicate can reduce the burden of reflective memory and improve consensus efficiency.

[0010] The reflective memory-based transport layer includes a reflective memory communication API interface and reflective memory;

[0011] The reflective memory communication API is used to provide nodes with interface functions for reading and writing reflective memory address space, interrupt mechanism event notification, and reflective memory ID acquisition. The block management layer implements operations on reflective memory by calling interface functions in the reflective memory communication API. The specific functions of the API are implemented by reflective memory hardware without occupying node CPU resources.

[0012] Reflective memory is used to respond to the call of the reflective memory communication API interface function to complete the reading and writing of the reflective memory address space, the interrupt mechanism event notification and the acquisition of the reflective memory ID; wherein, the interrupt mechanism event notification is the notification event generated in the blockchain consensus process and the corresponding interrupt callback function, including the notification of the new block to be verified sent by the block-producing node to the verification node, the notification of the completed verification sent by the verification node to the block-producing node, the notification of the confirmation synchronization of the new block sent by the block-producing node to all nodes, and the notification of entering the next round of consensus sent by the block-producing node to all nodes; four types of interrupt events, and there is no priority distinction; the ID of the reflective memory is the board ID number used to identify the identity of each node in the consensus process;

[0013] The block management layer is used to complete the process from node transaction initiation to block consensus based on reflective memory and block synchronization on the chain.

[0014] Specifically, when the system is initialized, the functional areas of the reflective memory are divided according to the requirements for completing the consensus, and the read and write permissions of each functional area are set; the functional areas include the time synchronization area, the block verification area, and the node-exclusive area.

[0015] The time synchronization area is used to maintain a system time, which is updated by the system's time synchronization machine and read by each node regularly to synchronize the system time of each node. The write permission of the time synchronization area is only owned by the system's time synchronization machine, and the read permission is owned by the system's time synchronization machine and all nodes.

[0016] The block verification area is used to store new blocks to be verified during the consensus process and to maintain transaction acquisition tags; the write permission of the block verification area is owned by the block-producing node, and the read permission is owned by all verification nodes; the transaction acquisition tag is used to save the node address of the transaction to be verified in the reflective memory; in the process of block generation, the block-producing node obtains the transaction acquisition tag and obtains a set number of transactions from the transaction set space of the node it points to and packs them into the block; after packing a set number of transactions at each node, the block-producing node will jump to the next adjacent node to continue to obtain transactions, and write the address of the jumped node into the transaction acquisition tag. Transaction acquisition ensures that the transaction confirmation of each round of consensus process is carried out according to the mechanism of node rotation and transaction time sequence.

[0017] The node-specific area is used to store the transaction set space of the transactions initiated by the node and the verification result space of the new block; each node has a node-specific partition in the reflective memory; the write permission of the node-specific area is owned by the node and the block-producing node, and the read permission is owned by all nodes. The transaction set space is divided into several transaction slots; each transaction can only occupy an integer number of transaction slots; the node also maintains a write tag variable for the transaction set space.

[0018] The arrangement order of the node exclusive areas is from top to bottom based on the time when the nodes joined the system. The size of each area is a fixed value. The block-producing node can traverse according to the size of the node exclusive area when obtaining node transactions.

[0019] Specifically, the block management layer includes node clients, block data layer, transaction generator, block generator, and block validator;

[0020] The node client is used to complete the user's digital asset management, transaction initiation, block synchronization between nodes, and transaction information query and acquisition;

[0021] The block data layer is used to store transaction data that has reached consensus in the current system in blocks;

[0022] The transaction generator is used to encapsulate the transaction data initiated by the block client, and calls the read and write API interface of the reflective memory to write the transaction data into the transaction slot of the transaction set space in the node exclusive area;

[0023] The block generator is used to complete the leader election, pending transaction acquisition and transaction verification packaging of the Byzantine consensus mechanism based on reflective memory, generate new blocks to be verified, and send them to the block verification area of ​​the reflective memory. At the same time, the notification of the new block to be verified is sent to all verification nodes; the leader election of the Byzantine consensus mechanism based on reflective memory is specifically: the leader, that is, the block-producing node, is generated by a rotation system; the rotation system is: the block-producing node is acted as by all nodes of the system in turn according to the node ID order, where the ID value is provided by the reflective memory communication API, and can be changed if necessary according to the jumper cap of the reflective memory hardware.

[0024] The block validator is used for consensus process, and its functions are divided into verification node function and block generation node function according to the current node identity. The block validator of the verification node function includes block verification part and block synchronization part; the block verification part is that after the verification node receives the notification of the new block to be verified from the block generation node, it calls the reflective memory communication API to obtain the new block to be verified, completes the verification of the new block, writes the verification result into the verification result of the node exclusive area, and sends the notification of completed verification to the block generation node; the block synchronization part is that when the verification node receives the notification of confirmation synchronization of the new block, it adds the new block synchronously and clears the transaction data slot of the node in the current new block in the transaction slot; the block validator of the block generation node function is used to wait for the verification result of the verification node for the new block and count it; when the waiting time is set or two-thirds of the votes of the system are received, if the new block passes the verification, the new block is added to the end of the blockchain, the block status is updated, and the notification of confirmation synchronization of the new block and the notification of entering the next round of consensus are initiated to all nodes of the system.

[0025] The beneficial effects of the present invention are that the excellent characteristics of different network transmission layers are fully utilized, and reflective memory and Ethernet card are used simultaneously for communication between nodes of the blockchain system; reflective memory can realize memory sharing, and its use in the consensus process of the alliance chain system can greatly improve the consensus efficiency, thereby improving the overall efficiency of the system; the solution based on reflective memory from transaction initiation to block consensus synchronization can greatly improve the transaction confirmation speed and improve the throughput of the blockchain system. BRIEF DESCRIPTION OF THE DRAWINGS

[0026] The present invention is further described below in conjunction with the accompanying drawings, and the structure and principle of the present invention are very clear to people in the field. It should be understood that the specific embodiments described herein are only used to explain the present invention and are not used to limit the present invention.

[0027] Figure 1 A schematic diagram of the structure of a high-speed alliance blockchain system based on reflective memory provided by an embodiment of the present invention;

[0028] Figure 2 A workflow diagram of a high-speed alliance blockchain system based on reflective memory provided by an embodiment of the present invention;

[0029] Figure 3 A flowchart of a transaction initiation process provided by an embodiment of the present invention;

[0030] Figure 4 A flowchart of a block generation process provided by an embodiment of the present invention;

[0031] Figure 5 A flowchart of the block verification process provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0032] In order to make the purpose, technical solution and advantages of the embodiments of the present invention clearer, the technical solution in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0033] The main functions realized by the system of the present invention are: using reflective memory optical fiber with fast communication speed, communication process handled by hardware without node CPU participation, and setting interrupt notification mechanism to realize similar memory sharing characteristics between blockchain nodes; at the same time, a method based on reflective memory and Byzantine consensus from transaction initiation to block consensus synchronization is provided, which can greatly improve the transaction confirmation speed and the throughput of the blockchain system. The network transmission method of this system also includes Ethernet-based TCP transmission. Nodes use P2P protocol to communicate unrelated to the consensus process to reduce the burden of reflective memory and improve the overall efficiency of the system.

[0034] The embodiments are described in detail below with reference to the accompanying drawings.

[0035] like Figure 1 The figure shows the structural composition diagram of the system. The system consists of blockchain nodes with a blockchain management layer and a network transmission layer. The block management layer includes a block data layer, a block generator, a block validator, a transaction generator, and a node client.

[0036] The node client is used to generate transactions and communication between nodes that is unrelated to consensus; the transaction generator is used to encapsulate the transaction data generated by the client and write it into the transaction set space of the reflective memory according to the protocol specified by the system; the block data layer is used to store confirmed transaction blocks.

[0037] The block generator and block validator play a role in the block consensus process of the system; the block generator only plays a role when the current node passes the Byzantine consensus and is elected as the block generating node of the current round of consensus. Its function is to obtain the node transaction set space in the verification reflection memory in turn, and package the verified transactions into blocks and send them to the block verification area. The block generating node sends a notification of the new block to be verified to the verification node, receives the notification of the completed verification from the verification node and counts the verification result information. After the verification is passed, the block generating node sends a notification to all nodes to confirm the synchronization of the new block and the notification of entering the next round of consensus.

[0038] The caller of the block validator is the verification node, whose function is to obtain new blocks and verify them, write the verification results into the verification area of ​​the node's exclusive area, and send a notification of completed verification to the block-producing node, waiting for the block-producing node to confirm the synchronization of the new block notification and the notification of entering the next round of consensus.

[0039] The network transport layer includes a reflective memory-based transport layer and an Ethernet-based transport layer. The reflective memory-based transport layer divides the address space of the reflective memory into functional areas: a time synchronization area, a block verification area, and a node-exclusive area. These functional areas are respectively used in the block consensus process.

[0040] Figure 2 A workflow diagram of a high-speed alliance blockchain system based on reflective memory provided by an embodiment of the present invention. The workflow of the system is mainly divided into two stages: system initialization stage and system operation stage. The workflow of the system is described in detail below with reference to the accompanying drawings.

[0041] Phase 1: System initialization phase. The main work of this phase is to initialize the block management area and the network transmission layer. Furthermore, the initialization of the block management area includes the cryptographic library and consensus algorithm required for the system from transaction initiation to consensus to block confirmation.

[0042] The initialization of the network layer includes the initialization of the Ethernet-based TCP communication protocol and the initialization of the reflective memory-based communication. The traditional Ethernet-based communication initialization is not described here; the reflective memory-based communication initialization process includes the initialization of the reflective memory driver, the division of reflective memory functional areas, the initialization of the read and write protocols, the interrupt event setting, and the initialization of the corresponding interrupt callback function.

[0043] The above reflective memory driver initialization provides an API for the communication between the node and the reflective memory. The system node completes the communication process by calling the reflective memory hardware API. The specific communication process is implemented by the reflective memory hardware.

[0044] During the initialization process of reflective memory, its address space is divided into functional areas, and the functions and read and write permissions of each area are specified; the main content includes dividing the reflective memory into a time synchronization area, a block verification area, and a node-exclusive area.

[0045] The time synchronization area is refreshed in real time by the system's time synchronization machine. Other nodes in the system synchronize the system time by periodically reading the time value in this area. This area is writable only by the time synchronization machine and readable by other nodes. The block verification area stores the node tag TX_NODE_TAG and block verification space of the transaction to be obtained at the beginning of the next round of consensus. Only the block-producing node has write permission in this area, and other nodes can read it. The node-exclusive area is a dedicated area divided by the system for each node in the reflective memory. This area is used to store the space of the transaction set to be confirmed initiated by the node and the verification result of the current round of block consensus. This area is only accessible by the node itself and readable by other nodes.

[0046] The transaction set space is divided into N transaction slots of size SLOT_SIZE; each transaction can only occupy an integer number of transaction slots; if the size of the transaction slot is 512 bytes and a transaction has 1000 bytes, then the transaction needs to occupy two slots; the node maintains a write tag variable TX_TAG of the current transaction set space. In order to ensure that transactions are confirmed normally and confirmed transactions can be removed in time, the node needs to add or delete transactions from the transaction set space according to the read-write protocol provided by the system.

[0047] The above-mentioned reflective memory interrupt event setting and its callback function initialization constitute the event notification mechanism of this system;

[0048] Furthermore, there are four interrupt event flags without priority distinction in the reflective memory. This system initializes these four events as four notification events generated by the blockchain consensus process and sets corresponding interrupt callback functions. The specific contents are as follows:

[0049] Define RFM2GEVENT_INTR1 as RMF_EVENT_BLOCK_VERFIY. The content of this event is that after the block producer uploads a new block, it notifies all verification nodes to verify the new block. The callback function corresponding to the event received by the verification node processes the event of reading the new block content and verifying it.

[0050] Define RFM2GEVENT_INTR2 as RMF_EVENT_VERFIY_FINISH. The event content is that the verification node notifies the block-producing node that the verification has been completed. After receiving the callback function corresponding to the event, the block-producing node processes the event by obtaining the corresponding verification information in the reflective memory according to the node ID information carried in the notification event, checking the block confirmation information and signature information therein, and synchronizing the block confirmation statistics.

[0051] Define RFM2GEVENT_INTR3 as RMF_EVENT_ADD_BLOCK. The event content is that the block-producing node notifies the verification node of the system to confirm the synchronization of the new block. The verification node receives the event corresponding to the callback function and processes the event as the synchronization block, and synchronizes the transaction confirmation status of the node itself.

[0052] Define RFM2GEVENT_INTR4 as RMF_EVENT_NEXT_ROUND. The event content is that the block-producing node notifies all nodes to start the next round of consensus process. The callback function corresponding to the event received by other nodes processes the event to start the next round of Byzantine consensus, elect the block-producing node, and enter the next round of consensus.

[0053] The second stage: the system operation stage. In this stage, the nodes perform multi-threaded work, which mainly includes three processes: inter-node communication process, transaction initiation process and consensus process.

[0054] The node communication process is a communication process that is unrelated to the system consensus process. The process consists of inter-node block synchronization based on P2P communication, transaction query, transaction verification error notification, and system time synchronization based on reflective memory.

[0055] The following is combined with Figure 3 Describe in detail the transaction initiation process;

[0056] Step 1: Before initiating a transaction, the node initializes the variable TX_TAG to the initial address of the transaction set space in the node's exclusive area. This variable determines the address in the transaction set space in the node's exclusive area where the currently generated transaction should be written. At the same time, a waiting write queue RMF_TX_QUEUE is initialized.

[0057] Step 2: Wait for the node client to generate transaction data and encapsulate the transaction data into JSON format, named TX_JSON here; calculate the number of bytes occupied by TX_JSON, TX_SIZE;

[0058] Step 3: Further encapsulate TX_JSON into RMF_TX. This transaction data format is used to write into the transaction slot in the node exclusive area. Its encapsulation format is: RMF_TX = {0x5A||TX_SLOT_COUNT||TX_JSON};

[0059] Among them, 0x5A is the data header flag, TX_SLOT_SIZE is the number of transaction slots occupied by the transaction, and its calculation method is: TX_SLOT_COUNT = (TX_SIZE+2)%SLOT_SIZE?

[0060] (TX_SIZE + 2) / SLOT_COUT + 1: TX_SIZE / SLOT_COUT; where SLOT_SIZE is the byte space size occupied by each transaction slot in the transaction set space;

[0061] Step 4: Write the generated RMF_TX into the buffer queue RMF_TX_QUEUE and wait to be written;

[0062] Step 5: Determine whether there is enough space in the transaction set space to write the next transaction. The judgment can be made through the following steps: Take out the number of occupied transaction slots HEAD_SLOT_COUNT of the transaction at the head of the queue, and determine whether the first HEAD_SLOT_COUNT transaction slots starting from TX_TAG can be written; that is, determine whether the value of the address space pointed to by TX_TAG + SLOT_SIZE * n (0 <= n < HEAD_SLOT_COUNT, n is a non - negative integer) has been written as 0x5A. If it is 0x5A, it means that this area has been written by the transaction to be confirmed, and the program jumps to continue generating transaction data; otherwise, a transaction at the head of the RMF_TX_QUEUE queue dequeues and is written into the address corresponding to TX_TAG. Update the value of TX_TAG: TX_TAG += SLOT_SIZE * TX_SLOT_SIZE;

[0063] Step 6: Determine whether the RMF_TX_QUEUE queue is empty. If it is not empty, jump to Step 5 to continue determining whether a transaction can be written into the transaction set space. Otherwise, jump to Step 2 to continue generating transactions.

[0064] Figure 2 The consensus process of the system shown includes the block - producing node election, block generation, and block verification according to the Byzantine consensus mechanism.

[0065] The Byzantine consensus mechanism based on reflective memory adopted by this system selects a rotation mechanism for leader (i.e., block - producing node) election. Its rotation mechanism is: The block - producing nodes take turns to act as all nodes in the system in the order of node IDs. The value of the ID is provided by the API interface of the reflective memory and can be changed according to the jumper caps of the reflective memory hardware if necessary.

[0066] The following combines the append Figure 4 Describe the process of block generation in detail;

[0067] Step 1: Initialize the relevant variables of this process; obtain the value of TX_NODE_TAG from the block verification area of the reflection memory; set the current number of transactions packed as BLOCK_TX_COUNT; set the node transaction set space traversal flag ERGODIC_FLAG = 0; set the current number of transactions obtained by the node as TX_COUNT = 0; set the maximum number of transactions packed by a single node in the same block as MAX1, and the number of transactions contained in a complete block as MAX2;

[0068] Step 2: Enter the ERGODIC_FLAG item of the node transaction set space pointed to by TX_NODE_TAG;

[0069] Step 3: Execute the judgment of ERGODIC_FLAG++ < SLOT_SIZE, that is, judge whether it has reached the end of the transaction slot and increment the traversal flag. If the judgment is FALSE, jump to Step 6; if the judgment is TRUE, take out the transaction in the corresponding transaction slot, parse out the number of transaction slots occupied in the transaction SLOT_COUNT and verify whether the transaction is correct. If the result is TRUE, jump to Step 4; if it is FALSE, jump to Step 5;

[0070] Step 4: The transaction is verified correctly, increment TX_COUNT, and judge whether the number of transactions obtained by the current node is greater than MAX1. If it is FALSE, jump to Step 7; if it is TRUE, jump to Step 6;

[0071] Step 5: The transaction verification fails, send a transaction verification error message to the corresponding node, and jump to Step 7;

[0072] Step 6: Execute TX_NODE_TAG += 1; ERGODIC_FLAG = 0, and jump to Step 8;

[0073] Step 7: Execute ERGODIC_FLAG += SLOT_COUNT to update the traversal flag;

[0074] Step 8: Increment the current number of transactions added to the block and judge whether it is less than the maximum number of transactions contained in the block, that is, execute ++BLOCK_TX_COUNT <= MAX2; if it is TURE, jump to Step 2; if it is FALSE, jump to Step 9;

[0075] Step 9: Pack the obtained transactions into a new block and write it into the block to-be-verified area, and send a block verification event RMF_EVENT_BLOCK_VERFIY to all verification nodes;

[0076] Step 10: Process the verification completion event RMF_EVENT_VERFIY_FINISH sent by the node and determine whether the waiting time is over. If it is TRUE, jump to step 12, and if it is FALSE, go to step 11;

[0077] Step 11: Determine whether more than two-thirds of the nodes have confirmed. If TRUE, jump to step 12; if FALSE, jump to step 10;

[0078] Step 12: End the block confirmation process;

[0079] Step 13: Determine whether the block is confirmed successfully. If successful, send a block synchronization message RMF_EVENT_ADD_BLOCK and write TX_NODE_TAG to the corresponding position of the block verification area, and go to step 14; if the verification fails, jump to step 14.

[0080] Step 14: If the block confirmation fails, TX_NODE_TAG is restored to the value of the previous round of consensus; the block-producing node initiates the next round of consensus event notification RMF_EVENT_NEXT_ROUND, and the block generation process is now complete.

[0081] The following is combined with Figure 5 A detailed description of the block verification process;

[0082] Step 1: Initialize the MY_TX_SET array, which is used to store the set of ID values ​​belonging to its own node transactions in the verification block; and retrieve the block to be verified from the block verification;

[0083] Step 2: Parse and verify the block, verify the signature of its block-producing node, and determine whether the node is legal. If it is illegal, jump to step 3, and if it is legal, jump to step 4.

[0084] Step 3: The block-producing node is illegal, the block verification fails, and the next round of consensus should be waited for or started;

[0085] Step 4: Take out the transactions in the block one by one, and determine whether all transactions in the block have been verified. If it is FALSE, go to step 5, otherwise jump to step 7;

[0086] Step 5: Determine whether the transaction is initiated by yourself, and record the transaction ID in MY_TX_SET.

[0087] Step 6: Verify whether the transaction is correct. If it is correct, jump to step 4, otherwise jump to step 7;

[0088] Step 7: Generate verification result information, send the verification information to the verification result area of ​​the exclusive area of ​​​​the node; send the verification completion event notification RMF_EVENT_VERFIY_FINISH to the block producing node;

[0089] Step 8: Determine whether a block synchronization event is received within the specified waiting time. If it is TRUE, jump to step 9, otherwise jump to step 12;

[0090] Step 9: Determine whether the block is confirmed successfully. If it is TRUE, jump to step 10, otherwise jump to step 12;

[0091] Step 10: Synchronize block information to the block data layer and update block records; erase the relevant transactions recorded in MY_TX_SET in the node transaction set space in the reflective memory, indicating that the transaction is confirmed successfully;

[0092] Step 11: Wait for the next round of consensus event notification RMF_EVENT_NEXT_ROUND;

[0093] Step 12: Start the next round of consensus; this completes the description of the block verification process.

[0094] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit it. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A high-speed alliance blockchain system based on reflective memory, characterized in that: Each node in the system includes a network transport layer and a block management layer; The network transport layer includes an Ethernet-based transport layer and a reflective memory-based transport layer; The Ethernet-based transport layer is used for P2P protocols based on TCP / IP protocol to communicate between nodes that are not related to the consensus process; The reflective memory-based transport layer includes a reflective memory communication API interface and reflective memory; The reflective memory communication API is used to provide nodes with interface functions for reading and writing reflective memory address space, interrupt mechanism event notification, and reflective memory ID acquisition. The block management layer implements operations on reflective memory by calling the interface functions in the reflective memory communication API. The reflective memory is used to respond to the call of the reflective memory communication API interface function to complete the reading and writing of the reflective memory address space, the interrupt mechanism event notification and the acquisition of the reflective memory ID; wherein the interrupt mechanism event notification is the notification event generated in the blockchain consensus process and the corresponding interrupt callback function, including the notification of the new block to be verified sent by the block-producing node to the verification node, the notification of the completed verification sent by the verification node to the block-producing node, the notification of the confirmation synchronization of the new block sent by the block-producing node to all nodes, and the notification of entering the next round of consensus sent by the block-producing node to all nodes; the ID of the reflective memory is the board ID number used to identify the identity of each node in the consensus process; The block management layer is used to complete the process from node transaction initiation to block consensus based on reflective memory and block synchronization on the chain.

2. The system according to claim 1, characterized in that: When the system is initialized, the functional areas of the reflective memory are divided according to the requirements for completing the consensus, and the read and write permissions of each functional area are set; the functional areas include the time synchronization area, the block verification area, and the node-exclusive area.

3. The system according to claim 2, characterized in that: The time synchronization area is used to maintain a system time, which is updated by the system's time synchronization machine and is read by each node regularly to synchronize the system time of each node; the write permission of the time synchronization area is only owned by the system's time synchronization machine, and the read permission is owned by the system's time synchronization machine and all nodes; The block verification area is used to store new blocks to be verified during the consensus process and to maintain transaction acquisition tags; the write permission of the block verification area is owned by the block producing node, and the read permission is owned by all verification nodes; The node-exclusive area is used to store the transaction set space for transactions initiated by the node and the verification result space for new blocks; each node has a node-exclusive partition in the reflective memory; the write permission of the node-exclusive area is owned by the node and the block-producing node, and the read permission is owned by all nodes.

4. The system according to claim 3, characterized in that: The transaction acquisition tag is used to save the node address of the transaction to be verified in the reflective memory; during the block generation process, the block generating node obtains the transaction acquisition tag, and obtains a set number of transactions from the transaction set of the node it points to and packages them into the block; After packaging a set number of transactions at each node, the block-producing node will jump to the next adjacent node to continue obtaining transactions, and write the address of the jumped node into the transaction acquisition tag.

5. The system according to claim 3, characterized in that: The transaction set space is divided into a number of transaction slots; each transaction can only occupy an integer number of transaction slots; the node to which it belongs also maintains a write tag variable for the transaction set space.

6. The system according to claim 5, characterized in that: The block management layer includes node clients, block data layer, transaction generator, block generator and block validator; The node client is used to complete the user's digital asset management, transaction initiation, block synchronization between nodes, and transaction information query and acquisition; The block data layer is used to store transaction data that has reached consensus in the current system in blocks; The transaction generator is used to encapsulate the transaction data initiated by the block client, and calls the read and write API interface of the reflective memory to write the transaction data into the transaction slot of the transaction set space in the node exclusive area; The block generator is used to complete the leader election, pending transaction acquisition and transaction verification packaging of the Byzantine consensus mechanism based on reflective memory, generate new blocks to be verified, and send them to the block verification area of ​​reflective memory. At the same time, the notification of the new blocks to be verified is sent to all verification nodes; The block validator is used to carry out the consensus process, and its functions are divided into verification node function and block production node function according to the current node identity.

7. The system according to claim 6, characterized in that: The leader election of the Byzantine consensus mechanism based on reflective memory is as follows: a rotation system is used to generate a leader, that is, a block-producing node; the rotation system is that the block-producing node is rotated by all nodes in the system in the order of the node ID, where the ID value is provided by the reflective memory communication API.

8. The system according to claim 6, characterized in that: The block validator of the verification node function includes a block verification part and a block synchronization part; the block verification part is that after the verification node receives the notification of the new block to be verified from the block-producing node, it calls the reflective memory communication API to obtain the new block to be verified, completes the verification of the new block, writes the verification result into the verification result of the node exclusive area, and sends a notification of the completion of the verification to the block-producing node; the block synchronization part is that when the verification node receives the notification of confirming the synchronization of the new block, it adds the new block synchronously and clears the transaction data slot of the node in the current new block in the transaction slot; The block validator of the block producing node function is used to wait for receiving and counting the verification results of the verification node on the new block; When the waiting time is set or two-thirds of the votes in the system are received, if the new block passes the verification, the new block will be added to the end of the blockchain, the block status will be updated, and a notification will be sent to all nodes in the system to confirm the synchronization of the new block and to enter the next round of consensus.

9. The system according to claim 1, characterized in that: The communications unrelated to the consensus process include block synchronization, transaction queries, and snapshot communications between nodes.

Images