A blockchain network service platform, a data storage method, and a storage medium

Abstract

An embodiment of the present invention discloses a blockchain network service platform, a data storage method, and a storage medium, including: when a transaction proposal initiated by a client is obtained, an endorsing node processes the transaction proposal using snapshot isolation of a relational database to obtain a transaction result, and the data type of the transaction result is the same as the data storage type of the relational database; when the transaction result passes verification, a verification node is used to store the transaction result in the relational database, improving the security when the blockchain network service platform stores data.

Description

Technical Field

[0001] The present invention relates to the field of data storage, and in particular to a blockchain network service platform, a data storage method, and a storage medium. Background Art

[0002] In recent years, ledger data, as the center of the blockchain network, records all transaction proposals in the entire network. The storage method of ledger data plays a crucial role in the security and performance of the entire blockchain system.

[0003] In the prior art, the blockchain network service platform processes the received transaction proposals, and stores the obtained transaction results in the state database. Since the state database is embedded in the process of the peer node, in the case of abnormal termination of the node, the node cannot store data in the state database, reducing the security of the blockchain network service platform when storing data. Summary of the Invention

[0004] To solve the above technical problems, embodiments of the present invention are expected to provide a blockchain network service platform, a data storage method, and a storage medium, which improve the security of the blockchain network service platform when storing data.

[0005] The technical solution of the present invention is implemented as follows:

[0006] In a first aspect, an embodiment of the present invention provides a data storage method for a blockchain network service platform, including:

[0007] When a transaction proposal initiated by a client is obtained, an endorsing node processes the transaction proposal using snapshot isolation of a relational database to obtain a transaction result, and the data type of the transaction result is the same as the data storage type of the relational database;

[0008] When the transaction result passes the verification, a verification node stores the transaction result in the relational database.

[0009] In a second aspect, an embodiment of the present invention provides a blockchain network service platform, where the blockchain network service platform includes:

[0010] An endorsing node, configured to process a transaction proposal using snapshot isolation of a relational database to obtain a transaction result when a transaction proposal initiated by a client is obtained;

[0011] A verification node, configured to store the transaction proposal in the relational database when the transaction result passes the verification.

[0012] In a third aspect, an embodiment of the present invention provides a blockchain network service platform, where the blockchain network service platform includes:

[0013] At least one memory for storing executable instructions;

[0014] At least one processor for executing the executable instructions stored in the at least one memory to implement the data storage method of the blockchain network service platform as described above.

[0015] In a fourth aspect, an embodiment of the present invention provides a storage medium storing executable instructions, which when executed are used to cause a processor to execute the method described above.

[0016] An embodiment of the present invention provides a blockchain network service platform, a data storage method, and a storage medium. The data storage method of the blockchain network service platform includes: when a transaction proposal initiated by a client is obtained, an endorsing node processes the transaction proposal using snapshot isolation of a relational database to obtain a transaction result, and the data type of the transaction result is the same as the data storage type of the relational database; when the transaction result is verified to be passed, a verification node is used to store the transaction result in the relational database, improving the security when the blockchain network service platform stores data. Using the data storage method of the above blockchain network service platform, the blockchain network service platform can obtain a transaction result of a data type that is the same as the data storage type of the relational database by processing the transaction proposal using snapshot isolation of the relational database. When the transaction result is verified to be passed, the blockchain network service platform can directly store the transaction result in the relational database. When an exception occurs in a node of the blockchain network service platform, the blockchain network service platform can still store transaction data in the relational database, improving the security during data storage. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] Figure 1 It is a schematic diagram of the functional architecture of the blockchain network service platform provided by an embodiment of the present application;

[0018] Figure 2 It is a schematic diagram of the structure in which the resource layer is constructed as a container cluster 200 by deploying a container management system provided by an embodiment of the present application;

[0019] Figure 3 It is a schematic diagram of a developer accessing the blockchain network service platform 100 through a terminal 300 provided by an embodiment of the present application;

[0020] Figures 4A to 4Q It is a schematic diagram showing the display of various function management pages of the blockchain network service platform provided by an embodiment of the present application;

[0021] Figure 5Schematic diagram of a blockchain network deployed using a blockchain network service platform provided by an embodiment of the present application;

[0022] Figure 6 Flowchart of a transaction using a blockchain network service platform provided by an embodiment of the present application;

[0023] Figure 7 Ledger schematic diagram in Fabric in the prior art provided by an embodiment of the present invention;

[0024] Figure 8 Schematic diagram of an exemplary Fabric transaction process provided by an embodiment of the present invention;

[0025] Figure 9 Flowchart of a data storage method for a blockchain network service platform provided by an embodiment of the present invention;

[0026] Figure 10 Schematic diagram of an exemplary data storage method for a blockchain network service platform provided by an embodiment of the present invention;

[0027] Figure 11 Structural schematic of a blockchain network service platform provided by an embodiment of the present invention Figure 1 ;

[0028] Figure 12 Structural schematic of a blockchain network service platform provided by an embodiment of the present invention Figure 2 。 Detailed implementation manners

[0029] In order to make the objectives, technical solutions and advantages of the present invention clearer, the present invention will be further described in detail below with reference to the accompanying drawings. The described embodiments should not be construed as limiting the present invention. All other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the scope of protection of the present invention.

[0030] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by those of ordinary skill in the technical field of the present invention. The terms used herein are only for the purpose of describing the embodiments of the present invention and are not intended to limit the present invention.

[0031] Before further elaborating on the embodiments of the present invention, the nouns and terms involved in the embodiments of the present invention are explained. The nouns and terms involved in the embodiments of the present invention are subject to the following explanations.

[0032] 1) Block, a data structure that records the ledger data updated by an exchange over a period of time, marked with a timestamp and a unique identifier (such as a digital fingerprint) of the previous block. After being verified by consensus among nodes in the blockchain network, the block is appended to the end of the blockchain to become a new block.

[0033] 2) Blockchain, a chain - like data structure formed by blocks connected in sequence. In each block, the hash value of the previous block or its subset is referenced, thus ensuring the immutability and non - forgery of the recorded transactions in a cryptographic way.

[0034] 3) Ledger, the sum of the data recorded in the blockchain network in terms of accounts, including elements such as ledger data, ledger status, ledger status proof, and block index.

[0035] 4) Consensus, a process in the blockchain network used to reach an agreement on the transaction results among multiple involved nodes. The mechanisms to achieve consensus include Proof of Work (PoW), Proof of Stake (PoS), Delegated Proof - of - Stake (DPoS), Proof of Elapsed Time (PoET), etc.

[0036] 5) Smart Contracts, also known as Chaincode, are program chains triggered according to conditions and deployed in the blockchain network. Chaincode runs in a secure container to initialize and manage ledger data and ledger status.

[0037] The following describes the exemplary functional architecture of the blockchain network implementing the embodiments of the present invention. Refer to Figure 1 , Figure 1 The schematic diagram of the functional architecture of the blockchain network provided by the embodiments of the present invention includes an application layer 101, a consensus layer 102, a network layer 103, a data layer 104, and a resource layer 105, which will be described separately below.

[0038] The resource layer 105 encapsulates various available computing resources and storage resources, such as computing resources and storage resources in computers, servers / clusters, and clouds, abstracts them, and provides a unified interface to the data layer 104 to shield the differences in the underlying hardware implementing the resource layer 105.

[0039] Computing resources include various forms of processors, such as central processing units (CPUs), application specific integrated circuits (ASICs), various forms of processors of application specific integrated circuits and field-programmable gate arrays (FPGAs).

[0040] Storage resources include various types of storage media such as various volatile memories and non-volatile memories. Among them, the non-volatile memory can be a read-only memory (ROM), a programmable read-only memory (PROM). The volatile memory can be a random access memory (RAM), which is used as an external cache.

[0041] The computing resources and storage resources of the resource layer 105 can be mapped to various types of nodes in the blockchain network. The storage medium of the embodiment of the present invention stores executable instructions for implementing the blockchain network deployment method of the embodiment of the present invention. Once the executable instructions deployed to the nodes are executed, the underlying resources of the nodes (such as various types of processors) will implement the deployment of various types of nodes in the blockchain network and execute the functions of various types of nodes, thereby implementing the ledger for transactions in the business process and various applications based on the ledger.

[0042] As an example, the executable instructions can be in the form of software (including system programs and application programs), software modules, scripts, plugins, etc., written in any form of programming language (including compiled or interpreted languages, or declarative or procedural languages), and can be deployed in any form, including being deployed as an independent program or being deployed as a module, component or other unit suitable for use in a computing environment.

[0043] The data layer 104 encapsulates various data structures for implementing the ledger, including ledger data implemented by a file system, ledger status and existence proofs implemented in the form of a database.

[0044] The network layer 103 encapsulates the peer-to-peer (P2P) network protocol, data propagation mechanism and data verification mechanism, access and authentication mechanism and business entity identity. The P2P network protocol realizes the communication between nodes in the blockchain network. The data propagation mechanism ensures the propagation of transactions / transaction results in the blockchain network. The data verification mechanism is used to realize the reliability of data transmitted between nodes based on cryptographic methods (such as digital certificates, digital signatures, public / private key pairs); the access and authentication mechanism is used to manage the access and authentication of terminals based on the business entity identity.

[0045] The consensus layer 102 encapsulates the mechanism for reaching consensus on the transaction results propagated in the blockchain, including POS, POW, DPOS, etc., and supports the pluggability of the consensus mechanism.

[0046] The application layer 101 encapsulates various services that the blockchain network can implement, including transaction settlement, traceability, and evidence storage, etc.

[0047] See Figure 2 , which is a schematic structural diagram of the resource layer provided by the embodiment of the present invention being constructed as a container cluster 200 by deploying a container management system. In the machines that provide resources to the resource layer, two types of nodes, namely, a management node (Master Server) 200 and a service node 300 (Node), are formed by deploying the corresponding components of the container management system. The management node is used to manage the scheduling and operation of containers in the service node. The service node is mainly used to run various containers and provide an isolated running environment for various applications in the blockchain network. For example, a chain code container for running chain code, a node container for running node (i.e., the code of various types of nodes in the blockchain network) code, etc. The following will be described separately.

[0048] The management node (Master Server) 200 is responsible for managing the cluster and providing an access entry for the resource data of the cluster in the form of a service (Service). The management node includes several exemplary components.

[0049] 1) The status component (etcd) is used to save the status of the entire cluster.

[0050] 2) The application programming interface service (API Server) component provides the only entry for resource operations and provides mechanisms such as authentication, authorization, access control, API registration, and discovery.

[0051] 3) The scheduling (Scheduler) component is responsible for resource scheduling and schedules containers to appropriate nodes for running according to a predetermined scheduling policy. The container group (Pod) in which the containers running on the service node share the same set of resources in the machine (i.e., the machine on which the service node components are deployed) is the smallest unit of invocation. For the applications of the blockchain network, it can be implemented through one or more container groups. The resources shared by the containers in the container group include: application namespace, network namespace, hostname, and storage volume (Volume).

[0052] Taking a shared storage volume as an example, when a shared file system component is deployed on a node, such as a Network File System (NFS), a GlusterFS, or a Ceph File System (Cephfs), the scheduling component can easily schedule (mount) the container groups mounted on the storage volume to the storage volumes of other machines (nodes).

[0053] 4) The Controller Manager component is responsible for monitoring / maintaining the status of the cluster. Through the interfaces provided by the Application Programming Interface Service component, it can monitor the current status of each resource object in the entire cluster in real time. When various failures cause changes in the system status, it will restore to the desired state.

[0054] 5) The Replication Controller (RC) component controls the running of a certain number of Pod replicas within a certain period of time. For example, if the number of running Pod replicas exceeds the set value, some Pod replicas will be shut down; if the number of Pod replicas is less than the set value, new Pod replicas will be created.

[0055] 6) The Deployment Controller component is used to manage and maintain the resource object - Deployment object in the container cluster, associate the Deployment object with the Replication Controller, and provide declarative updates for the container group and the Replication Controller in the Deployment object to declare the target state of the container group and the Replication Controller. Thus, when the Deployment object is updated, it controls the update of the Replication Controller and the container group.

[0056] The service node 300 includes the following exemplary components.

[0057] 1) The container engine (denoted as Docker) is responsible for all specific image downloads and container runs.

[0058] 2) The daemon process component (denoted as Kubelet) is responsible for maintaining the life cycle of the container (creation, start, and stop), and is also responsible for the management of the storage volume and the Container Network Interface (CNI).

[0059] Taking the management of the storage volume as an example, the daemon process component mounts each container in a container group to the same storage volume through the components of the shared file system deployed in the node, such as the Network File System (NFS), the GlusterFS, or the Ceph File System (Cephfs), so that each container uses the same storage volume to store the data generated during operation. The data in the storage volume can be accessed by any container in the same container group.

[0060] 3) The load - balancing component (denoted as Proxy) is responsible for providing service discovery and load - balancing within the cluster for the Service.

[0061] Based on Figure 2 For the cluster shown, an exemplary process of encapsulating the image of an application of a blockchain network into a container group (referred to as the target Pod in the following example) and running it on a node (referred to as the target Node in the following example) is described as follows.

[0062] First, the management tool (Kubectl) of the container cluster 200 submits a request to create a replication controller (RC, Replication Controller), which includes information such as the definition of the target Pod, the number of replicas the target Pod needs to run, and the labels (Lable) of the target Pod to be monitored.

[0063] Next, the request is written into etcd through the API Server. At this time, the Controller Manager monitors this RC event through the interface of the APIServer that listens for resource changes. Since there is no corresponding Pod instance in the current cluster, it generates a Pod object according to the Pod template definition in the RC and writes it into etcd through the API Server.

[0064] Immediately afterwards, the RC event is discovered by the Scheduler, and it immediately executes a scheduling process: selects a node for this new Pod to settle in, and then writes this result into etcd through the API Server. Subsequently, the Kubelet process running on the target Node monitors this new Pod through the API Server and starts the new Pod according to its definition until the life of the Pod ends.

[0065] Subsequently, Kubectl submits a new request to create a Service mapped to the target Pod. The ControllerManager will query the associated Pod instances through the Label, then generate the endpoint (Endpoints) information of the Service (including the address and port), and write it into etcd through the API Server; the Proxy processes running on all Nodes in the container cluster query and listen for the Service object and its corresponding Endpoints information through the API Server, and establish a software - based load - balancer to implement the traffic forwarding function from the Service to the backend Pod.

[0066] As can be seen from the above, the blockchain network service platform according to the embodiments of the present invention is implemented by deploying a container cluster at the resource layer and running containers encapsulating blockchain network applications. Thus, the blockchain network according to the embodiments of the present invention can be provided in the form of a memory and a processor. Executable instructions are stored in the memory. When the executable instructions are executed by the processor, a container cluster is established on multiple nodes running the processor and the memory. By running the encapsulated applications in the containers, the chain code installation method in the blockchain service network platform according to the embodiments of the present invention is implemented.

[0067] The blockchain network platform according to the embodiments of the present invention is connected to developers in various ways and provides various graphical ways for the deployment and management of the blockchain network. The following will be described.

[0068] See Figure 3 , Figure 3 which is a schematic diagram of a developer accessing the blockchain network service platform 100 through the terminal 300 according to the embodiments of the present invention. The SDK / Web 320 interface of the developer terminal 300 is connected to the corresponding SDE / Web interface of the data layer 104 in the blockchain network service platform 100, supporting the remote deployment of a blockchain network for specific services locally on the developer's terminal 300. Management pages of various functions of the blockchain network service platform 100 are displayed in the graphical interface 310 of the terminal 300, including the creation of a container cluster and the access of a new container cluster, the management of storage resources, the one-click deployment of the blockchain network, chain code management (viewing the running status), application store management, etc.

[0069] See Figures 4A to 4Q , which is a schematic diagram of the display of management pages of various functions of the blockchain network service platform according to the embodiments of the present invention. It will be described by way of example in Figures 4A to 4Q the functional management page displayed in the graphical interface 310 of the developer terminal 300 as in Figure 3 .

[0070] Figure 4A shows the status viewing page of the blockchain network service platform 100, in which the running status of the blockchain network, such as CPU usage, memory usage, and resource (node) usage, is shown.

[0071] Figure 4B shows the console page for the one-click deployment of the blockchain network service platform 100, supporting developers to set the basic information of the blockchain network (including the block domain name, version number) and the organization (including the organization name, the number of nodes, the number of users, etc.), and using default values to set advanced options, including the sorting node type, channel name, and chain code name, etc.

[0072] Figure 4CThe console page for resource management of the resource layer 105 of the blockchain network service platform 100 is shown, which displays relevant information about the clusters that developers can deploy through the blockchain network service platform 100, including the connection status, CPU / memory usage, etc.

[0073] In Figure 4D it supports adding a container cluster for supporting the blockchain network and entering the cluster name; after the function option for creating a cluster is triggered, the creation page will be entered.

[0074] In Figure 4E the console page for querying clusters of the blockchain network service platform 100 is shown. When the function button for querying clusters is triggered, the cluster list page will be entered, supporting operations such as adding clusters, querying clusters, deleting clusters, and editing clusters.

[0075] In Figure 4F the console page for storage management of the blockchain network service platform 100 is shown. When the function button for storage management is triggered, the storage management list page will be entered, displaying the created storage projects in the cluster, which includes storage query and deletion functions.

[0076] In Figure 4G the console page for storage details of the blockchain network service platform 100 is shown. In Figure 4H the details of the storage are displayed, and it supports dynamic expansion of the storage space for the storage.

[0077] In Figure 4I the console page for adding storage of the blockchain network service platform 100 is shown, supporting setting the added storage name and nodes. According to the settings, the nodes will be added to the container cluster, and in Figure 4J the details information after adding the storage is displayed, including the list of nodes in the container cluster.

[0078] In Figure 4K the console page for the Hyperledger of the blockchain network service platform 100 is shown, displaying information such as the name, network version, status, and creation time of the Hyperledger used for deploying the blockchain network.

[0079] In Figure 4L the console page for one-click deployment of the Hyperledger of the blockchain network service platform 100 is shown, providing configuration items for the basic information of Hyperledger deployment, as well as advanced configuration items with default values, such as sorting node type, channel, default chain code, and initialization parameters, etc.

[0080] In Figure 4MThe console page for uploading / installing the chaincode of the blockchain network service platform 100 is shown in / N. In the upload console page, setting items for the chaincode name and version number are provided; in the install console page, configuration items for the chaincode version, initialization parameters, organization, and nodes are provided.

[0081] In Figure 4O the console page for the network details of the blockchain network service platform 100 is shown. It supports viewing information such as organization members, block height, transaction quantity, and contract quantity of different channels, and can also display information such as the organization name of the viewed channel, node names within the channel, and chaincode names within the channel.

[0082] In Figure 4P the console page for chaincode query of the blockchain network service platform 100 is shown. It supports querying the chaincode in ways such as using the network name, chaincode name, chaincode parameters, ledger name, and chaincode function, and the query dimensions include status, message, and data.

[0083] In Figure 4Q the console page for the application store of the blockchain network service platform 100 is shown. It supports developers to select the applications to be deployed. Once an application is determined to be deployed to the blockchain network, the rapid deployment to the container cluster of the resource layer 105 will be completed by reusing the image of the application.

[0084] See Figure 5 , which is an exemplary structure of the blockchain network deployed using the blockchain network service platform. The application program obtains a legal identity certificate from the CA to join the application channel within the network. Before initiating an official transaction, it is necessary to first construct a transaction proposal (Proposal) and submit it to the endorsing nodes in Organization 1 and Organization 2 for endorsement; after the client collects sufficient (the quantity is determined according to the endorsement policy) endorsement support, it can use the endorsement to construct a legal transaction request (carrying the endorsement of the endorsing nodes) and send it to the ordering node (Orderer) in the ordering service for ordering, so as to encapsulate the transaction to form a block.

[0085] See Figure 6 , which is the transaction process between the application program and the blockchain network. Among them, the functions of the client and each node in the transaction process are as follows:

[0086] Client (Application): Uses the SDK to interact with the blockchain network. First, the client obtains a legal identity certificate from the CA to join the application channel within the network. Before initiating an official transaction, it is necessary to first construct a transaction proposal and submit it to the endorser node for endorsement. After the client collects sufficient (the quantity is determined according to the endorsement policy) endorsement support, it can use the endorsement to construct a legal transaction request (carrying the endorsement of the endorser node) and send it to the orderer node for sorting, so as to encapsulate the transaction into a block. The client can also use the event mechanism to listen for messages in the network to find out whether the transaction has been successfully received.

[0087] Endorser: Mainly provides methods for the client to call to complete the endorsement (signing) process of the transaction proposal. After receiving the transaction proposal from the client, it first performs legality and ACL permission checks. If the checks pass, it simulates running the transaction (the chain code name and parameters to be executed will be executed during the transaction. Executing the transaction essentially means executing the chain code specified in the transaction), endorses (that is, performs a digital signature) the state changes caused by the transaction (recorded in the form of read-write sets, including the keys and versions of the read states, and the key values of the written states) and returns the result of whether the client is supported.

[0088] Orderer: Receives the transaction containing the endorsement signature, sorts the un-packaged transactions to generate a block, and broadcasts it to the Peer nodes.

[0089] Leader Peer: The node that communicates with the orderer node, responsible for obtaining the latest block from the orderer node and synchronizing it internally in the blockchain network.

[0090] Committer: Maintains the structure of the blockchain and the ledger (including the state DB, history DB, index DB, etc.). This node will regularly obtain the sorted batch transaction block structure from the orderer node and check these transactions (including the transaction message structure, signature integrity, whether there are duplicates, whether the read-write set versions match, etc.). After passing the checks, it executes the legal transactions, writes the results to the ledger, and constructs a new block at the same time.

[0091] It's important to note that all peer nodes are ledger nodes, responsible for validating transactions from orderer blocks and maintaining copies of state data and ledgers. Some peer nodes execute transactions and sign and endorse the results, acting as endorsing nodes. Endorsing nodes are dynamic roles, bound to specific chaincodes. Each chaincode in the chaincode container sets an endorsement policy upon instantiation, specifying which peers' endorsements are considered valid. A peer node acts as an endorsing node only when an application requests a transaction endorsement. Otherwise, it acts as a standard ledger node, solely responsible for validating transactions and recording them.

[0092] Ledger data, at the core of a blockchain network, records all transactions across the network. Ledger data is often stored in a distributed manner within a blockchain network, reflecting the decentralized nature of blockchain. The storage method for ledger data plays a crucial role in the security and performance of the entire blockchain system.

[0093] The ledger data in Hyperdeger Fabric is called Ledger, which consists of two parts: Block Database (Chain) and State Database (State Database). These two parts are different but also related. Figure 7 As shown in Figure 2. The state database does not interact directly with the ledger database. Instead, the ledger reads and writes transaction data to the state database through the TxMgr (Transaction Manager) object. The block database is a linked list logically connected by the block data structure, which is why it gets its name from blockchain. The block database uses file system storage.

[0094] The state database records transaction execution results and represents the latest results for all keys on the channel, hence Fabric's term for it: world state. The state database is also closely tied to blockchain applications. Typically, applications interact with the state database through contracts, eliminating the need to traverse the entire transaction log to query specific content. In Fabric, ledger state is represented by key-value pairs by default. Fabric also offers extensibility. Furthermore, a state database with efficient add, delete, modify, and query capabilities can significantly improve chaincode execution efficiency. Therefore, research on the ledger state database is crucial.

[0095] Fabric state databases include: LevelDB and CouchDB.

[0096] LevelDB is a Key-Value database developed by Google. LevelDB is the default state database selected by Fabric and is used embedded in the Peer process. The value in LevelDB is saved as binary data, and it only supports query operations based on keys. From the source code of Fabric, it can be seen that in the github.com / syndtr / goleveldb / leveldb library, the database objects and operations of leveldb are encapsulated into its own objects for use. Under common / ledger / util / leveldbhelper, in leveldb_helper.go, DB is a database object that encapsulates conf, leveldb.DB, and synchronous or asynchronous read and write options. In leveldb_provider.go, a database processing object DBHandle is defined, which encapsulates DB and the corresponding database name and provides Put, Get, and Delete operations.

[0097] CouchDB is a NoSQL database and it is a database of JSON documents. CouchDB is an optional additional extended state database. Similar to LevelDB, it can store any binary data modeled in the chaincode. At the same time, when supporting JSON data modeling, it additionally supports rich queries on chaincode data. The code related to CouchDB in Fabric is concentrated in core / ledger / util / couchdb. CouchDB can also enhance the security of compliance and data protection in the blockchain. Because it can achieve field-level security by filtering and masking each attribute in the transaction and only authorizes read-only permissions when needed.

[0098] Among them, the Fabric transaction process is as Figure 8 shown: 1. First, the client initiates a transaction proposal, which includes information such as <client ID, chaincode ID, tx payload, timestamp, and client signature>, indicating the three W elements: who the message is from, when, and what was sent. According to the endorsement policy in the chaincode, this message is sent to the three nodes EP1, EP2, and EP3. 2. The three nodes EP1, EP2, and EP3 simulate the execution of the smart contract and send the results and their respective CA certificate signatures back to the client. The client proceeds to the next step after collecting enough results. 3. The client sends the tx transaction containing the endorsement results to the ordering node. 4. The ordering node delivers the packaged block to CP1 as well as EP1, EP2, and EP3. At this time, the endorsement nodes EP1, EP2, and EP3 will verify the results and write them into the world state and the ledger. At the same time, since the client has subscribed to the message, it will also receive a notification.

[0099] LevelDB is only suitable for ledger content that is simple key-value pairs and has poor adaptability to complex ledger states. LevelDB is embedded in the peer node process. If the peer process terminates abnormally, the LevelDB process will also end, easily causing data loss. CouchDB only supports ledger content represented as JSON-formatted data and does not support relational data. CouchDB and LevelDB have significant deficiencies in data consistency and complex queries (such as multi-table queries, nested queries, grouping queries, etc.).

[0100] For the problems existing in the prior art, they can be specifically solved by the method in Embodiment 1.

[0101] Embodiment 1

[0102] The embodiment of the present invention provides a data storage method for a blockchain network service platform. Figure 9 It is a process flow of a data storage method for a blockchain network service platform provided by the embodiment of the present invention Figure 1 as Figure 9 shown. The data processing method of the blockchain network service platform may include:

[0103] S101. When a transaction proposal initiated by a client is obtained, the endorsing node processes the transaction proposal using snapshot isolation of the relational database to obtain a transaction result, and the data type of the transaction result is the same as the data storage type of the relational database.

[0104] The data storage method for a blockchain network service platform provided by the embodiment of the present invention is applied to the scenario where the blockchain network service platform stores transaction results.

[0105] In the embodiment of the present application, the transaction result includes two parts: a read set and a write set.

[0106] It should be noted that the read set and write set obtained by the blockchain network service platform processing the transaction proposal using snapshot isolation of the relational database are data that match the data storage format of the relational database.

[0107] In the embodiment of the present application, after the endorsing node of the blockchain network service platform processes the transaction proposal using snapshot isolation of the relational database to obtain a transaction result, the verification node of the blockchain network service platform processes the transaction proposal using the chain code method of the state database to obtain a first transaction result.

[0108] In the embodiment of the present application, the transaction proposal includes chain code method information. When the endorsement node receives the transaction proposal, the endorsement node can obtain the chain code method information from the transaction proposal, determine the corresponding chain code method according to the chain code method information, and use the chain code method to process the transaction proposal, so as to obtain the first transaction result.

[0109] In the embodiment of the present application, before the verification node of the blockchain network service platform processes the transaction proposal using the chain code method of the state database to obtain the first transaction result, the verification node will also verify the legality of the transaction proposal; after the verification node verifies the legality of the transaction proposal, the process of the verification node using the chain code method of the state database to process the transaction proposal to obtain the first transaction result specifically includes: when the verification node determines that the legality verification of the transaction proposal passes, the verification node uses the chain code method of the state database to process the transaction proposal to obtain the first transaction result.

[0110] In the embodiment of the present application, the verification node includes a Block Processor, and the Block Processor can create a database backend process for the transaction proposals in the block according to the execution order set to verify the legality of the transaction proposals.

[0111] It should be noted that the number of processes can be multiple, and the processes can be multiple concurrent processes.

[0112] In the embodiment of the present application, after the verification node determines that the transaction proposal is legal, the verification node will also verify whether the transaction corresponding to the transaction proposal has occurred. If the transaction corresponding to the transaction proposal has not occurred, the verification node will call the verification system chain code to check whether the endorsement signature of the transaction proposal is legal and whether the number of endorsements meets the requirements of the endorsement policy. Only when the above verifications pass can the verification node store the transaction result in the relational database.

[0113] In the embodiment of the present application, before the endorsement node of the blockchain network service platform processes the transaction proposal using snapshot isolation of the relational database to obtain the transaction result, the endorsement node will also obtain the data information after the relational database is updated; use snapshot isolation to read the proposal data information corresponding to the transaction proposal. When the data information is different from the proposal data information, the endorsement node uses snapshot isolation of the relational database to process the transaction proposal to obtain the transaction result.

[0114] It should be noted that the way for the endorsement node to obtain the data information after the relational database is updated can specifically be that the endorsement node obtains a consistent view from the relational database, thereby obtaining the data information.

[0115] In an embodiment of the present application, the endorsing node may first obtain the data information updated by the relational database, and then the endorsing node uses snapshot isolation to read the proposal data information corresponding to the transaction proposal; the endorsing node may also first use snapshot isolation to read the proposal data information corresponding to the transaction proposal, and then the endorsing node obtains the data information updated by the relational database; the endorsing node may also obtain the data information updated by the relational database while using snapshot isolation to read the proposal data information corresponding to the transaction proposal; specifically, it can be determined according to the actual situation, and the embodiments of the present application do not limit this.

[0116] It should be noted that when the data information and the proposal data information are the same, the endorsing node does not process the transaction proposal using the snapshot isolation of the relational database.

[0117] In an embodiment of the present application, the number of transaction proposals can be one, two, or multiple, and specifically can be determined according to the actual situation, and the embodiments of the present application do not limit this.

[0118] In an embodiment of the present application, the endorsing node will also collect the correspondence between the transaction proposal and the execution order of the Structured Query Language (SQL) query order and the transaction proposal.

[0119] In an embodiment of the present application, the endorsing node will transmit the collected correspondence between the transaction proposal and the SQL query order to the verification node for the verification node to process the transaction proposal using the chain code method of the state database and the correspondence between the transaction proposal and the SQL query order to obtain a first transaction result.

[0120] In an embodiment of the present application, relational database query statements can be divided into four categories: SELECT, INSERT, UPDATE, and DELETE. For complex SELECT queries, only the beginning of the query plan tree needs to be collected, and the chain code will only read values from the fields corresponding to these beginnings; for INSERT queries, the write set at the last level of the query plan tree needs to be captured (that is, before the actual tuples are stored in the disk blocks of the table). For UPDATE queries (even with sub-select queries), the write set needs to be collected at the last level of execution (that is, before the actual tuples in the disk blocks of the table are updated), and part of the read set only contains the old rows that have just been updated. For DELETE queries, the deleted rows are added to their corresponding write sets. Among them, the data structure of the read and write sets of the relational database is as follows:

[0121] Data structure of the transaction read set:

[0122] List<a SELECT Query, List of<Table_Row_ID, Version#>>, where a SELECT Query represents a query statement, Table_Row_ID represents the table_row_id to be queried, which can be regarded as a unique key. Version# is similar to the previous version number.

[0123] The data structure of the write set contains three because there are three types of queries involving data modification:

[0124] List<a INSERT Query, List of<table_name, row_data>>, where table_name represents the name of the table to insert data into, and row_data represents the actual row data to be inserted. The hash value corresponding to the row data can also be saved, and a trade-off can be made according to the actual situation.

[0125] List<a UPDATE Query, List of<old row’s Table_Row_ID, Version#, new row_data>>, where old row’s Table_Row_ID represents the identifiers of the rows that need to be updated, version# represents the current version situation, and new row_data represents the row data to be updated.

[0126] List<a DELETE Query, List of<Table_Row_ID, Version#>>. For the query to be deleted, the row_id to be deleted and the corresponding version number are recorded here.

[0127] In the embodiment of the present application, for the reading and writing of rows, according to the selected query plan, on different database nodes, the order in which rows are added to the read / write set may be different. Therefore, the endorsing node needs to sort the read set and the write set separately before signing. To ensure that the query is correctly executed again during the verification phase, an execution order set needs to be maintained during the endorsement phase to ensure that the stored order is the same as the order submitted by the chain code. This can be achieved by storing the id of the SQL query and the corresponding timestamp.

[0128] S102. When the transaction result verification passes, use the verification node to store the transaction result in the relational database.

[0129] In an embodiment of the present application, endorsement nodes in a blockchain network service platform process transaction proposals using snapshot isolation of a relational database. After obtaining a transaction result, when the transaction result passes verification, the blockchain network service platform uses verification nodes to store the transaction result in the relational database.

[0130] In an embodiment of the present application, when verification nodes process a transaction proposal using the chaincode method of a state database and obtain a first transaction result, the process of the verification nodes storing the transaction result in the relational database includes: when the verification nodes determine that the first transaction result matches the transaction result, the verification nodes store the transaction result in the relational database.

[0131] In an embodiment of the present application, when the verification nodes determine that the first transaction result does not match the transaction result, the verification nodes use a block processing program to terminate the transaction corresponding to the transaction proposal.

[0132] In an embodiment of the present application, the blockchain network service platform further includes ordering nodes.

[0133] In an embodiment of the present application, the number of transaction proposals can be multiple. After endorsement nodes process the transaction proposals using snapshot isolation of a relational database and obtain transaction results, before verification nodes store the transaction results in the relational database, ordering nodes obtain multiple channel sequence numbers and multiple transaction times corresponding to the multiple transaction proposals; after the ordering nodes obtain the multiple channel sequence numbers and multiple transaction times corresponding to the multiple transaction proposals, the ordering nodes determine at least two first transaction proposals with the same channel sequence number from the multiple channel sequence numbers; then, the ordering nodes sort the at least two first transaction proposals according to at least two first transaction times corresponding to the at least two first transaction proposals to obtain sorted transaction proposals; then, the ordering nodes package the sorted transaction results corresponding to the sorted transaction proposals to obtain block data.

[0134] It should be noted that the transaction time is the time when the client initiates a transaction. After the client initiates a transaction, the client first obtains the timestamp information of the transaction, and then the client adds the timestamp information to the transaction proposal.

[0135] In an embodiment of the present application, the ordering nodes can sort the at least two first transaction proposals according to at least two first transaction times corresponding to the at least two first transaction proposals and a formula strategy to obtain sorted transaction proposals.

[0136] It should be noted that the consensus strategy can specifically be the Raft consensus strategy, or it can be other consensus strategies, which can be specifically determined according to the actual situation, and the embodiments of the present application do not limit this.

[0137] In the embodiments of the present application, a transaction proposal includes a channel serial number and a transaction time. After obtaining the transaction proposal, the ordering node can obtain the channel serial number and the transaction time corresponding to the transaction proposal from the transaction proposal. When the ordering node receives multiple transaction proposals, the ordering node can obtain multiple channel serial numbers and multiple transaction times from the multiple transaction proposals.

[0138] In the embodiments of the present application, the ordering node can directly package the sorted transaction results to obtain block data; the ordering node can also package the sorted transaction results that meet a preset quantity threshold when the quantity of the sorted transaction results meets the preset quantity threshold, so as to obtain block data; specifically, it can be determined according to the actual situation, and the embodiments of the present application do not limit this.

[0139] In the embodiments of the present application, the block data may specifically include a read set and a write set; the block data may also include a write set, and specifically, it can be determined according to the actual situation, and the embodiments of the present application do not limit this.

[0140] In the embodiments of the present application, the block data includes multiple transaction results. When the verification node determines that the first transaction result matches the transaction result, the verification node queries the transaction result of the next transaction proposal in the block data until all the transaction results in the block data pass the query.

[0141] In the embodiments of the present application, when all the multiple transaction proposals in the block data pass the verification, the verification node uses the block processing program to submit the transaction results.

[0142] In the embodiments of the present application, after the ordering node packages the sorted transaction proposals to obtain block data, the verification node stores the block data in a relational database in a relational data format.

[0143] It should be noted that the relational data format is the data format when using a relational database to store data.

[0144] In the embodiments of the present application, when submitting the transaction results, the verification node can update the relational database according to <Row_ID,Version#> and store the block data in the relational database, that is, realize the persistence of the transaction.

[0145] In the embodiments of the present application, when the verification node submits multiple transaction results, it can submit the multiple transaction results serially.

[0146] It can be understood that using a relational database as the state database of the ledger can facilitate the rapid development of smart contracts for traditional applications based on relational databases, making it easier for applications to go on-chain. Relational databases can support various types of queries, such as multi-table join queries, nested queries, grouped queries, etc. Relational databases can restrict user access rights and row-level security policies, and compared with non-relational databases, the granularity of access control provided is finer.

[0147] Exemplarily, as Figure 10 shown: When the client receives a transaction proposal, the client transmits the transaction proposal to the endorsement nodes (the number of endorsement nodes can be one or multiple); the transaction proposal includes the signature of the client. When the endorsement node receives the transaction proposal sent by the client, the endorsement node processes the transaction proposal based on the snapshot isolation of the relational database to obtain a transaction result, and endorses and signs the transaction proposal. Then, the endorsement node transmits the endorsement signature and the transaction result to the client. After the client receives the endorsement signature and the transaction result transmitted by the endorsement node, the client compares whether the endorsement signatures returned by each endorsement node are the same, and whether the transaction results returned by each endorsement node are the same. If the endorsement signatures are the same and the transaction results are also the same, the client transmits the transaction result, the endorsement signature, and the transaction proposal to the ordering node (if there are multiple transaction proposals, there are also multiple corresponding transaction results and multiple corresponding endorsement signatures). When the ordering node receives the transaction result, the endorsement signature, and the transaction proposal, the endorsement node obtains the transaction times and multiple channel serial numbers corresponding to the multiple transaction proposals from the multiple transaction proposals, determines at least two first transaction proposals with the same channel serial number from the multiple channel serial numbers, sorts the at least two first transaction proposals according to the at least two first transaction times corresponding to the at least two first transaction proposals, obtains the sorted transaction proposals, packs the sorted transaction results corresponding to the sorted transaction proposals to obtain block data, and then the ordering node transmits the block data to the verification nodes (the number of verification nodes can be multiple). After receiving the block data, the verification node first verifies the legality of the multiple transaction proposals corresponding to the multiple transaction results in the block data; when the legality verification of the multiple transaction proposals passes, the verification node processes the multiple transaction proposals using the chaincode method of the state database to obtain multiple first transaction results; the verification node respectively matches the multiple first transaction results with the multiple transaction results, and when the multiple first transaction results match the multiple transaction results, the verification node stores the block data in the relational database.

[0148] It should be noted that the chaincode method can be the chaincode method for the requirement of updating the ledger or the chaincode method for the requirement of querying the ledger, and can be specifically determined according to the actual situation. The embodiments of the present application do not make any limitations in this regard.

[0149] It can be understood that by using snapshot isolation of a relational database to process transaction proposals, the blockchain network service platform can obtain transaction results of the same data type as the data storage type of the relational database. When the transaction results are verified and passed, the blockchain network service platform can directly store the transaction results in the relational database. In the case where nodes of the blockchain network service platform are abnormal, the blockchain network service platform can still store transaction data in the relational database, improving the security during data storage.

[0150] Embodiment 2

[0151] Based on the same inventive concept as in Embodiment 1, an embodiment of the present invention provides a blockchain network service platform 100, as Figure 11 shown, the blockchain network service platform 100 includes:

[0152] The endorsing node 11 is configured to, when obtaining a transaction proposal initiated by a client, use snapshot isolation of a relational database to process the transaction proposal to obtain a transaction result, and the data type of the transaction result is the same as the data storage type of the relational database;

[0153] The verification node 12 is configured to, when the transaction result is verified and passed, use the verification node to store the transaction result in the relational database.

[0154] In some embodiments of the present invention, the verification node 12 is configured to use the chaincode method of the state database to process the transaction proposal to obtain a first transaction result; when the first transaction result matches the transaction result, store the transaction result in the relational database.

[0155] In some embodiments of the present invention, the verification node 12 is configured to verify the legality of the transaction proposal; when the legality of the transaction proposal is verified and passed, use the chaincode method of the state database to process the transaction proposal to obtain the first transaction result.

[0156] In some embodiments of the present invention, the endorsing node 11 is configured to obtain the updated data information of the relational database; use the snapshot isolation to read the proposal data information corresponding to the transaction proposal; when the data information is different from the proposal data information, the endorsing node uses snapshot isolation of the relational database to process the transaction proposal to obtain the transaction result.

[0157] In some embodiments of the present invention, the blockchain network service platform further includes an ordering node;

[0158] The sorting node is used to obtain a plurality of channel sequence numbers and a plurality of transaction times corresponding to a plurality of transaction proposals; determine at least two first transaction proposals with the same channel sequence number from the plurality of channel sequence numbers; sort the at least two first transaction proposals according to the at least two first transaction times corresponding to the at least two first transaction proposals to obtain sorted transaction proposals; and package the sorted transaction results corresponding to the sorted transaction proposals to obtain block data.

[0159] In some embodiments of the present invention, the verification node is used to store the block data in a relational database in a relational data format by using the verification node.

[0160] Under the same inventive concept as in Embodiment 1, an embodiment of the present application provides a blockchain network service platform, as Figure 12 shown. Figure 12 is a schematic structural diagram of a blockchain network service platform proposed in an embodiment of the present application Figure 2 The blockchain network service platform 100 of the embodiment of the present application includes: at least one processor 13, at least one memory 14, and at least one communication bus 15. In the process of specific embodiments, the at least one processor 13 may be at least one of an application specific integrated circuit (ASIC), a digital signal processor (DSP), a digital signal processing device (DSPD), a programmable logic device (PLD), a field programmable gate array (FPGA), a CPU, a controller, a microcontroller, and a microprocessor. It can be understood that for different devices, the electronic devices for implementing the functions of the above processor may also be others, and the embodiments of the present application do not make specific limitations.

[0161] In the embodiment of the present application, the at least one communication bus 15 is used to implement connection communication between the at least one processor 13 and the at least one memory 14; the at least one memory 14 is used to store executable instructions;

[0162] The at least one processor 13 is used to execute the executable instructions stored in the at least one memory 14 to implement the block data storage method as described in Embodiment 1.

[0163] An embodiment of the present application provides a storage medium. The storage medium stores one or more programs. The one or more programs can be executed by one or more processors and are applied to a blockchain network service platform. When the program is executed by at least one processor, it implements the block data storage method described in Embodiment 1.

[0164] It can be understood that the blockchain network service platform can obtain a transaction result of the same data type as the data storage type of the relational database by processing transaction proposals using snapshot isolation of the relational database. When the transaction result is verified, the blockchain network service platform can directly store the transaction result in the relational database. When an exception occurs in the nodes of the blockchain network service platform, the blockchain network service platform can still store transaction data in the relational database, improving the security during data storage.

[0165] Those skilled in the art should understand that the embodiments of the present invention can be provided as a method, a system, or a computer program product. Therefore, the present invention can take the form of an embodiment implemented in hardware, a software embodiment, or an embodiment combining software and hardware aspects. Moreover, the present invention can take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage and optical storage, etc.) that contain computer-usable program code.

[0166] The present invention is described with reference to the flowcharts and / or block diagrams of methods, apparatuses (systems), and computer program products according to embodiments of the present invention. It should be understood that each flow and / or block in the flowcharts and / or block diagrams, as well as the combination of flows and / or blocks in the flowcharts and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to the processors of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing devices to generate a machine, such that the instructions executed by the processors of the computer or other programmable data processing devices generate means for implementing the functions specified in Figure 1 one flow or multiple flows and / or blocks Figure 1 one block or multiple blocks.

[0167] These computer program instructions can also be stored in a computer-readable memory that can direct a computer or other programmable data processing device to work in a specific manner, such that the instructions stored in the computer-readable memory generate a manufactured article including instruction means that implement the functions specified in Figure 1 one flow or multiple flows and / or blocks Figure 1 one block or multiple blocks.

[0168] These computer program instructions can also be loaded onto a computer or other programmable data processing apparatus, so that a series of operation steps are executed on the computer or other programmable apparatus to produce a computer-implemented process, thereby the instructions executed on the computer or other programmable apparatus provide steps for realizing the functions specified in one process Figure 1 one process or more processes and / or blocks Figure 1 or steps for realizing the functions specified in one block or more blocks.

[0169] As mentioned above, the above are only the preferred embodiments of the present invention, and are not intended to limit the protection scope of the present invention.

Claims

1. A data storage method for a blockchain network service platform, characterized in that, including: When a transaction proposal initiated by a client is obtained, an endorsing node obtains the updated data information of the relational database; The endorsing node uses snapshot isolation of the relational database to read the proposal data information corresponding to the transaction proposal; When the data information is different from the proposal data information, the endorsing node uses the snapshot isolation to process the transaction proposal to obtain a transaction result, and the data type of the transaction result is the same as the data storage type of the relational database; The validating node uses the chaincode method of the state database to process the transaction proposal to obtain a first transaction result; When the first transaction result matches the transaction result, the validating node stores the transaction result in the relational database.

2. The method according to claim 1, wherein Before using the chaincode method of the state database to process the transaction proposal to obtain a first transaction result, the method further includes: Validating the legality of the transaction proposal; Correspondingly, using the chaincode method of the state database to process the transaction proposal to obtain a first transaction result includes: When the legality verification of the transaction proposal passes, using the chaincode method of the state database to process the transaction proposal to obtain the first transaction result.

3. The method according to claim 1, characterized in that, When the number of the transaction proposals is multiple, after the endorsing node uses snapshot isolation of the relational database to process the transaction proposals to obtain transaction results, and before using the validating node to store the transaction results in the relational database, the method further includes: Obtaining multiple channel sequence numbers and multiple transaction times corresponding to the multiple transaction proposals; Determining at least two first transaction proposals with the same channel sequence number from the multiple channel sequence numbers; Using a sorting node to sort the at least two first transaction proposals according to the at least two first transaction times corresponding to the at least two first transaction proposals to obtain sorted transaction proposals; Packing the sorted transaction results corresponding to the sorted transaction proposals to obtain block data.

4. The method according to claim 3, wherein Using the validating node to store the transaction result in the relational database includes: Using the validating node to store the block data in the relational database in the relational data format.

5. A blockchain network service platform, characterized in that, The blockchain network service platform includes: An endorsing node, configured to obtain the updated data information of the relational database when a transaction proposal initiated by a client is obtained; use snapshot isolation of the relational database to read the proposal data information corresponding to the transaction proposal; and when the data information is different from the proposal data information, use the snapshot isolation to process the transaction proposal to obtain a transaction result; A validating node, configured to use the chaincode method of the state database to process the transaction proposal to obtain a first transaction result; The validating node is further configured to store the transaction proposal in the relational database when the first transaction result matches the transaction result.

6. A blockchain network service platform, characterized in that, The blockchain network service platform includes: At least one memory, configured to store executable instructions; At least one processor for executing executable instructions stored in the at least one memory to implement the data storage method of the blockchain network service platform as described in claims 1-4.

7. A storage medium, characterized in that, Stored with executable instructions that, when executed, cause the processor to execute the method as described in claims 1-4.

Images