A high-speed consortium blockchain system based on reflective memory

Abstract

The application provides a high-speed alliance blockchain system based on a reflective memory, each node in the system comprising a network transmission layer and a block management layer. The block management layer is used for completing a process from node transaction initiation to reflective memory-based block consensus and block synchronization on-chain. The network transmission layer comprises an Ethernet-based transmission layer and a reflective memory-based transmission layer. The Ethernet-based transmission layer is used for communication between nodes based on a TCP / IP protocol P2P protocol irrelevant to the consensus process. The reflective memory-based transmission layer comprises a reflective memory communication API interface and a reflective memory. The reflective memory communication API is used for providing the node with interface functions for reading and writing a reflective memory address space, interrupt mechanism event notification and reflective memory ID acquisition. The reflective memory is used for responding to the calling of the reflective memory communication API interface function to complete reading and writing of the reflective memory address space, interrupt mechanism event notification and reflective memory ID acquisition. The application can improve the throughput of the blockchain system.

Description

Technical Field

[0001] This invention relates to blockchain technology, and more particularly to high-speed consortium blockchain technology based on reflective memory. Background Technology

[0002] Reflective memory networking is a shared memory system designed for efficient data sharing among multiple independent computers. In this system, nodes communicate via fiber optic connections, and each node has its own independent copy of shared memory, aiming to provide real-time data access and collaborative operation. Each node has write permissions and read permissions from its local memory, allowing for fast and flexible information exchange between nodes.

[0003] In the architecture of a real-time reflective memory network, when data is written to local memory, the system uses a field-programmable gate array (FPGA) to capture the data and send it to the next node in the network. This process continues until the data is returned to the source node, at which point the system removes the data from the network. This design allows data to be transmitted efficiently throughout the network, meeting the requirements for real-time performance and real-time collaboration. Simultaneously, reflective memory provides an interrupt mechanism that enables rapid event notification between nodes. Overall, reflective memory networks offer an innovative data sharing solution that meets high demands for real-time performance, efficiency, and collaboration by minimizing data access latency and achieving real-time data transmission.

[0004] As a distributed ledger technology, blockchain connects data in the form of blocks in a blockchain network. Each block contains the hash value of the previous block, giving it characteristics such as decentralization, immutability, and high security.

[0005] Consortium blockchains represent the evolution of blockchain technology within enterprises and organizations. Compared to public blockchains, consortium blockchains focus more on establishing a limited group of authorized participants who jointly manage and maintain the entire blockchain network. Consortium blockchains typically employ access control mechanisms, ensuring that only authorized members can participate in transactions and verification. This design improves transaction speed, reduces energy consumption, and maintains a degree of decentralization and transparency.

[0006] Consensus algorithms in blockchain distributed storage systems are used to confirm the authenticity, integrity, and availability of stored data. However, most existing blockchain consensus algorithms are based on the TCP protocol for communication. Data packets need to be copied and sent from the application layer through different layers such as the kernel layer, link layer, and physical layer. This results in defects such as multiple rounds of network communication, large amounts of interactive data, and high communication latency in current blockchain networks. These defects greatly limit the transaction packaging rate of blockchain systems, leading to low overall system performance and restricting the further application and development of blockchain. Summary of the Invention

[0007] This invention addresses the problems of low communication efficiency and high latency in existing blockchain networks by proposing a high-speed consortium blockchain system that improves system throughput through higher consensus efficiency.

[0008] The technical solution adopted by the present invention to solve the above-mentioned technical problems is a high-speed consortium blockchain system based on reflective memory, wherein each node in the system includes a network transport 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 conduct communication between nodes that is independent of the consensus process. Examples include block synchronization, transaction query, and snapshot communication between blockchain nodes. These operations are usually data synchronization between nodes and do not affect the transaction throughput of blocks. At the same time, using Ethernet for communication can reduce the burden on reflective memory and improve consensus efficiency.

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

[0011] The Reflective Memory Communication API provides nodes with interface functions for reading and writing the reflective memory address space, interrupt mechanism event notification, and retrieving the reflective memory ID. The block management layer operates on the reflective memory by calling the interface functions in the Reflective Memory Communication API. The specific functions of the API are implemented by the reflective memory hardware and do not consume node CPU resources.

[0012] Reflective memory is used to respond to calls to the reflective memory communication API interface functions, completing read and write operations on the reflective memory address space, interrupt mechanism event notifications, and reflective memory ID acquisition. The interrupt mechanism event notifications are notification events generated during the blockchain consensus process and their corresponding interrupt callback functions. These include notifications sent by block-producing nodes to validating nodes regarding new blocks awaiting verification, notifications sent by validating nodes to block-producing nodes indicating completed verification, notifications sent by block-producing nodes to all nodes confirming the synchronization of new blocks, and notifications sent by block-producing nodes to all nodes indicating entry into the next round of consensus. There are four types of interrupt events with no priority distinction. The reflective memory ID is the board ID number used to identify each node during 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, during system initialization, the functional areas of the reflective memory are divided according to the needs of achieving 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-specific area.

[0015] The time synchronization area is used to maintain a system time, which is updated by the system's time synchronization machine and is periodically read by each node to synchronize the system time of each node; write permissions for the time synchronization area are only held by the system's time synchronization machine, while read permissions are held by the system's time synchronization machine and all nodes.

[0016] The block verification area stores new blocks to be verified during the consensus process and maintains transaction retrieval tags. Write access to the block verification area is granted to the block-producing node, while read access is granted to all verification nodes. Transaction retrieval tags store the node addresses of transactions to be verified in the reflected memory. During block generation, the block-producing node retrieves the transaction retrieval tag and extracts a set number of transactions from the transaction set space of the node it points to, packaging them into the block. After packaging the set number of transactions at each node, the block-producing node jumps to the next adjacent node to continue retrieving transactions, simultaneously writing the address of the jumped node into the transaction retrieval tag. Transaction retrieval ensures that transaction confirmation in each round of consensus proceeds according to a mechanism of node rotation and transaction time sequence.

[0017] The node-specific 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-specific partition in the reflected memory. Write permissions for the node-specific area are held by the node and the block-producing node, while read permissions are held 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 that transaction set space.

[0018] The arrangement of the node-specific areas is based on the time the node joined the system, arranged from top to bottom. The size of each area is a fixed value. When a block-producing node retrieves node transactions, it can traverse the node-specific areas according to their size.

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

[0020] The node client is used to manage users' digital assets, initiate transactions, synchronize blocks between nodes, and query and obtain transaction information.

[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 transaction data initiated by the block client and call the read / write API interface of reflected memory to write the transaction data into the transaction slot of the transaction set space in the node's exclusive area;

[0023] The block generator is used to complete the leader election, transaction acquisition and 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, it sends the notification of the new blocks to be verified to all verification nodes. The leader election of the Byzantine consensus mechanism based on reflective memory is as follows: the leader, i.e. the block producing node, is generated by a rotation system. The rotation system is as follows: the block producing node is taken by all nodes in the system in turn according to the node ID order. The value of the ID is provided by the reflective memory communication API and can be changed according to the jumper cap of the reflective memory hardware if necessary.

[0024] Block validators are used in the consensus process, and their functions are divided into validator and block producer functions based on the current node's identity. The validator function includes a block verification component and a block synchronization component. The block verification component involves the validator node receiving a notification from the block producer node that a new block is to be verified. It then calls the reflective memory communication API to obtain the new block, verifies it, writes the verification result to its dedicated verification result area, and sends a notification of verification completion to the block producer node. The block synchronization component involves the validator node receiving a notification confirming the synchronization of a new block, adding the new block, and clearing the transaction slots containing the node's confirmed transactions in the current new block. The block producer function waits to receive and tallies the verification results of the validators for the new block. After a set waiting time or when two-thirds of the system's votes are received, if the new block passes verification, it is added to the end of the blockchain, the block state is updated, and notifications confirming the synchronization of the new block and entering the next round of consensus are sent to all nodes in the system.

[0025] The beneficial effects of this invention are that it fully utilizes the superior characteristics of different network transmission layers, and simultaneously employs both reflective memory and Ethernet cards for communication between nodes in the blockchain system; reflective memory enables memory sharing, and its use in the consensus process of a consortium blockchain system can significantly improve 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 transaction confirmation speed and increase the throughput of the blockchain system. Attached Figure Description

[0026] The present invention will be further described below with reference to the accompanying drawings. The structure and principle of the present invention are very clear to those skilled in the art. It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention.

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

[0028] Figure 2 A flowchart of a high-speed consortium blockchain system based on reflective memory is provided for embodiments of the present invention;

[0029] Figure 3 A transaction initiation workflow diagram provided for embodiments of the present invention;

[0030] Figure 4 A flowchart illustrating the block generation process provided in this embodiment of the invention;

[0031] Figure 5 This is a flowchart illustrating the block verification process provided in an embodiment of the present invention. Detailed Implementation

[0032] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0033] The main functions of this invention are: utilizing high-speed reflective memory fiber optic cables, hardware-processed communication without node CPU involvement, and an interrupt notification mechanism to achieve memory-like characteristics between blockchain nodes; simultaneously, it provides a method based on reflective memory and Byzantine consensus for transaction initiation and block consensus synchronization, which can significantly improve transaction confirmation speed and blockchain system throughput. The system's network transmission also includes Ethernet-based TCP transmission, with nodes using P2P protocols for communication independent of the consensus process to reduce the burden on reflective memory and improve overall system efficiency.

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

[0035] like Figure 1 The diagram shown illustrates the structural composition of this 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 communicates between nodes without regard 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 reflection memory according to the protocol defined by the system; the block data layer is used to store confirmed transaction blocks.

[0037] Block generators and block validators play a role in the system's block consensus process. The block generator only becomes active when the current node is elected as the block producer for the current round of consensus through Byzantine consensus. Its function is to sequentially obtain the transaction set space of the nodes in the verification reflection memory, package the verified transactions into blocks and send them to the block verification area. The block producer sends a notification to the validator nodes that a new block is pending verification, receives a notification from the validator nodes that the verification has been completed and counts the verification results. After verification, the block producer sends a notification to all nodes to confirm the synchronization of the new block and to enter the next round of consensus.

[0038] The caller of the block validator is the validator node. Its function is to obtain a new block and verify it, write the verification result into the verification area of ​​the node's exclusive area, and send a notification that the verification has been completed to the block producing node. It waits for the block producing node to confirm the synchronization of the new block and the notification to enter the next round of consensus.

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

[0040] Figure 2 This invention provides a flowchart of a high-speed consortium blockchain system based on reflective memory. The system's workflow is mainly divided into two stages: system initialization and system operation. The workflow of this system is described in detail below with reference to the accompanying drawings.

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

[0042] The network layer initialization includes the initialization of the Ethernet-based TCP communication protocol and the initialization of the reflection memory communication protocol. The initialization of the traditional Ethernet-based communication protocol will not be described in detail here. The initialization process of the reflection memory communication protocol includes the initialization of the reflection memory driver, the division of the reflection memory functional area and the initialization of the read and write protocol, the setting of interrupt events and the initialization of the corresponding interrupt callback functions.

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

[0044] During the initialization of reflective memory, its address space is divided into functional areas, and the function and read / write permissions of each area are specified. The main contents include dividing the reflective memory into a time synchronization area, a block verification area, and a node-specific area.

[0045] The time synchronization area is refreshed in real time by the system's time synchronization machine. Other nodes in the system synchronize their 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 tags (TX_NODE_TAG) of the transactions acquired at the start of the next round of consensus and the block verification space. This area is writable only by the block-producing node, and readable by other nodes. The node-specific area is a dedicated area allocated by the system to each node in the reflected memory. This area is used to store the set of transactions to be confirmed initiated by the node and the verification results of the current round of block consensus. This area is writable only 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 a transaction slot is 512 bytes and a transaction has 1000 bytes, then that transaction needs to occupy two slots; each node maintains a write tag variable TX_TAG for the current transaction set space. To ensure that transactions are confirmed normally and that confirmed transactions are removed in a timely manner, nodes must add or delete transactions to the transaction set space according to the read / write protocol provided by the system.

[0047] The aforementioned reflection memory interrupt event settings and their callback function initialization constitute the event notification mechanism of this system.

[0048] Furthermore, there are four types of interrupt event flags without priority distinction in the reflection memory. This system initializes these four events as four notification events generated during the blockchain consensus process and sets corresponding interrupt callback functions, as detailed below:

[0049] RFM2GEVENT_INTR1 is defined as RMF_EVENT_BLOCK_VERFIY. The content of this event is that after the block-producing node uploads a new block, it notifies all validator nodes to start verifying the new block. The event that the validator node receives the callback function corresponding to this event is to read the content of the new block and start verifying it.

[0050] Define RFM2GEVENT_INTR2 as RMF_EVENT_VERFIY_FINISH. The event content is that the verification node notifies that the block producing node has completed verification. When the block producing node receives the callback function corresponding to this event, it processes the event by retrieving the corresponding verification information from the reflected memory based on the node ID information carried in the notification event, checking the block confirmation information and signature information, and synchronizing the block confirmation statistics.

[0051] RFM2GEVENT_INTR3 is defined as RMF_EVENT_ADD_BLOCK. The event content is that the block producing node notifies the system's validator node to confirm the synchronization of the new block. When the validator node receives the callback function corresponding to this event, it processes the event as a synchronized block and synchronizes the node's own transaction confirmation status.

[0052] RFM2GEVENT_INTR4 is defined 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. Other nodes receive the callback function corresponding to this event and process it to start the next round of Byzantine consensus, elect a block-producing node, and enter the next round of consensus.

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

[0054] The node communication process is a communication process unrelated to the system consensus process. This 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 in conjunction with the appendix Figure 3 The process of initiating a transaction should be described in detail.

[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 of the node's exclusive area where the currently generated transaction should be written; at the same time, it initializes a waiting write queue RMF_TX_QUEUE.

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

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

[0059] Where 0x5A is the data header flag, and TX_SLOT_SIZE is the number of trading slots occupied by the exchange, which is calculated as: 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 for writing;

[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 judge whether the first HEAD_SLOT_COUNT transaction slots starting from TX_TAG can be written; that is, judge 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 pending confirmation transaction, and the program jumps to continue generating transaction data; otherwise, a transaction at the head of the RMF_TX_QUEUE queue is dequeued and 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 judging 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 leader 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., the block-producing node) election. Its rotation mechanism is as follows: The block-producing nodes are rotated among all the nodes of the system in the order of the node IDs, where the ID value 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 attached Figure 4 Describe the block generation process 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 already 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 SLOT_COUNT in the transaction 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: Verify that the transaction is correct, 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;[[ID=十六]] [[ID=十七]]

[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 TRUE, 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 waiting for verification area, and send a block verification event RMF_EVENT_BLOCK_VERFIY to all verification nodes;

[0076] It should be noted that there seems to be an error in the tags [[ID=十六]] and [[ID=十七]] in the original text. They should probably be and for correct numbering consistency. The above translation is based on the corrected understanding.Step 10: Process the verification completion event RMF_EVENT_VERFIY_FINISH sent by the node and determine whether the waiting time has ended. If TRUE, proceed to step 12; otherwise, proceed to step 11.

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

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

[0079] Step 13: Determine if the block has been successfully confirmed. If successful, send a block synchronization message RMF_EVENT_ADD_BLOCK and write TX_NODE_TAG to the corresponding position in the block verification area, then proceed to Step 14; if verification fails, jump to Step 14.

[0080] Step Fourteen: If block confirmation fails, restore TX_NODE_TAG to the value of the previous consensus round; the block-producing node initiates the next consensus event notification RMF_EVENT_NEXT_ROUND. This completes the description of the block generation process.

[0081] The following is in conjunction with the appendix Figure 5 The process of block verification is described in detail;

[0082] Step 1: Initialize the MY_TX_SET array, which stores the set of ID values ​​of transactions belonging to the node itself 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 valid and whether it is a valid block-producing node; if invalid, proceed to Step 3; if valid, proceed to Step 4.

[0084] Step 3: The block-producing node is invalid, block verification fails, and we should wait for or start the next round of consensus.

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

[0086] Step 5: Determine if the transaction was initiated by itself, and record the transaction ID in MY_TX_SET.

[0087] Step Six: Verify whether the transaction is correct. If it is correct, proceed to Step Four; otherwise, proceed to Step Seven.

[0088] Step 7: Generate verification result information and send the verification information to the verification result area of ​​the block-producing 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 has been received within the specified waiting time. If TRUE, proceed to Step 9; otherwise, proceed to Step 12.

[0090] Step 9: Determine if the block has been successfully confirmed. If it is TRUE, proceed to Step 10; otherwise, proceed 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 reflected memory, indicating that the transaction has been successfully confirmed;

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

[0093] Step 12: Proceed to the next round of consensus; this concludes 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, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A high-speed consortium 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; Ethernet-based transport layers are used for TCP / IP-based P2P protocols to conduct communication between nodes that is independent of the consensus process; The transport layer based on reflective memory includes a reflective memory communication API interface and reflective memory; The Reflection Memory Communication API provides nodes with interface functions for reading and writing the reflection memory address space, interrupt mechanism event notification, and obtaining the reflection memory ID. The block management layer performs operations on the reflection memory by calling the interface functions in the Reflection Memory Communication API. Reflective memory is used to respond to calls to the reflective memory communication API interface functions, completing read and write operations in the reflective memory address space, interrupt mechanism event notifications, and reflective memory ID acquisition. The interrupt mechanism event notifications are notification events generated during the blockchain consensus process and their corresponding interrupt callback functions. These include notifications sent by block-producing nodes to validating nodes regarding new blocks awaiting verification, notifications sent by validating nodes to block-producing nodes indicating completed verification, notifications sent by block-producing nodes to all nodes confirming the synchronization of new blocks, and notifications sent by block-producing nodes to all nodes indicating entry into the next round of consensus. The reflective memory ID is the board ID number used to identify each node during 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; The block management layer includes node clients, block data layer, transaction generators, block generators, and block validators; The node client is used to manage users' digital assets, initiate transactions, synchronize blocks between nodes, and query and obtain transaction information. 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 transaction data initiated by the block client and call the read and write API interface of reflected memory to write the transaction data into the transaction slot of the transaction set space in the node's exclusive area. The block generator is used to complete the leader election, transaction acquisition and 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, and send the notification of the new blocks to be verified to all verification nodes. Block validators are used for the consensus process, and their functions are divided into validator functions and block-producing node functions based on the current node's identity. During system initialization, the functional areas of the reflected memory are divided according to the needs of achieving 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-specific area.

2. The system as described in claim 1, 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 periodically by each node to synchronize the system time of each node. Write permissions for the time synchronization zone are held only by the system's time synchronization machine, while read permissions are held 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 held by the block producing node, and the read permission is held by all verification nodes; 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 reflection memory; write permissions for the node-specific area are held by the node and the block-producing node, while read permissions are held by all nodes.

3. The system as described in claim 2, characterized in that, The transaction acquisition tag is used to store the node address of the transaction to be verified in the reflection memory; during the block generation process, the block producing node acquires 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 on each node, the block-producing node will jump to the next adjacent node to continue fetching transactions, and at the same time write the address of the node to which it jumps to the transaction retrieval tag.

4. The system as described in claim 2, characterized in that, The transaction set space is divided into several 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 that transaction set space.

5. The system as described in claim 4, characterized in that, The leader election of the Byzantine consensus mechanism based on reflective memory is as follows: a rotating system is adopted to generate the leader, i.e., the block-producing node; the rotating system is as follows: the block-producing node is taken by all nodes in the system in turn according to the node ID order, where the ID value is provided by the reflective memory communication API.

6. The system as described in claim 1, characterized in that, The block validator function of the validator node includes a block verification part and a block synchronization part. The block verification part is that after receiving a notification from the block producer node that a new block to be verified is to be obtained by calling the reflection memory communication API, verifying the new block, writing the verification result into the verification result in the node's dedicated area, and sending a notification that the verification has been completed to the block producer node. The block synchronization part is that when the validator node receives a notification to confirm the synchronization of a new block, it adds the new block synchronously and clears the transaction slots in the transaction slots where the node has confirmed transaction data in the current new block. The block validator, which is part of the block producing node function, is used to wait for and count the verification results of the validator nodes for new blocks; Once the set waiting time has elapsed or two-thirds of the system's votes have been received, if the new block passes verification, it will be added to the end of the blockchain, the block status will be updated, and a notification to all nodes in the system will be sent to confirm and synchronize the new block and to initiate the next round of consensus.

7. The system as described in claim 1, characterized in that, The communications unrelated to the consensus process include block synchronization, transaction querying, and snapshot communication between nodes.

Images