CN114579354B - Block chain network service platform, data storage method and storage medium - Google Patents
Block chain network service platform, data storage method and storage mediumInfo
- Publication number
- CN114579354B CN114579354B CN202011388433.0A CN202011388433A CN114579354B CN 114579354 B CN114579354 B CN 114579354B CN 202011388433 A CN202011388433 A CN 202011388433A CN 114579354 B CN114579354 B CN 114579354B
- Authority
- CN
- China
- Prior art keywords
- transaction
- proposal
- node
- data
- relational database
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/14—Error detection or correction of the data by redundancy in operation
- G06F11/1402—Saving, restoring, recovering or retrying
- G06F11/1446—Point-in-time backing up or restoration of persistent data
- G06F11/1458—Management of the backup or restore process
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/14—Error detection or correction of the data by redundancy in operation
- G06F11/1402—Saving, restoring, recovering or retrying
- G06F11/1446—Point-in-time backing up or restoration of persistent data
- G06F11/1458—Management of the backup or restore process
- G06F11/1464—Management of the backup or restore process for networked environments
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
- G06F2201/80—Database-specific techniques
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
- G06F2201/84—Using snapshots, i.e. a logical point-in-time copy of the data
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Quality & Reliability (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
The embodiment of the invention discloses a blockchain network service platform, a data storage method and a storage medium, wherein the method comprises the steps that under the condition that a transaction proposal initiated by a client is acquired, an endorsement node processes the transaction proposal by utilizing snapshot isolation of a relational database to obtain a transaction result, the data type of the transaction result is the same as the data storage type of the relational database, and under the condition that the transaction result passes verification, the transaction result is stored into the relational database by utilizing a verification node, so that the safety of the blockchain network service platform in data storage is improved.
Description
Technical Field
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
In recent years, account book data is used as a center of a blockchain network, all transaction proposals in the whole network are recorded, and a storage mode of the account book data plays a vital role in the safety and performance of the whole blockchain system.
In the prior art, the blockchain network service platform processes the received transaction proposal, and the obtained transaction result is stored in the state database, and because the state database is embedded in the process of the peer node, under the condition that the node is abnormally terminated, the node cannot store data in the state database, so that the security of the blockchain network service platform when storing the data is reduced.
Disclosure of Invention
In order to solve the technical problems, the embodiment of the invention expects to provide a block chain network service platform, a data storage method and a storage medium, and improves the safety of the block chain network service platform when storing data.
The technical scheme of the invention is realized as follows:
in a first aspect, an embodiment of the present invention provides a data storage method of a blockchain network service platform, including:
under the condition that a transaction proposal initiated by a client is acquired, an endorsement node processes the transaction proposal by utilizing snapshot isolation of a relational database to obtain a transaction result, wherein the data type of the transaction result is the same as the data storage type of the relational database;
and under the condition that the transaction result passes verification, storing the transaction result into a relational database by using a verification node.
In a second aspect, an embodiment of the present invention provides a blockchain network service platform, including:
the endorsement node is used for processing the transaction proposal by utilizing snapshot isolation of the relational database under the condition that the transaction proposal initiated by the client is acquired, so as to obtain a transaction result;
and the verification node is used for storing the transaction proposal into a relational database under the condition that the transaction result is verified.
In a third aspect, an embodiment of the present invention provides a blockchain network service platform, where the blockchain network service platform includes:
At least one memory for storing executable instructions;
and the at least one processor is used for executing the executable instructions stored in the at least one memory to realize the data storage method of the block chain network service platform.
In a fourth aspect, embodiments of the present invention provide a storage medium storing executable instructions that, when executed, are adapted to cause a processor to perform the method described above.
The embodiment of the invention provides a block chain network service platform, a data storage method and a storage medium, wherein the data storage method of the block chain network service platform comprises the steps that under the condition that a transaction proposal initiated by a client is obtained, an endorsement node processes the transaction proposal by utilizing 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; under the condition that the transaction result is verified, the transaction result is stored in the relational database by using the verification node, so that the safety of the blockchain network service platform when the data is stored is improved. By using the data storage method of the blockchain network service platform, the blockchain network service platform processes the transaction proposal by utilizing snapshot isolation of the relational database, so that a transaction result with the same data type as the data storage type of the relational database can be obtained, under the condition that the transaction result is verified, the blockchain network service platform can directly store the transaction result into the relational database, under the condition that the node of the blockchain network service platform is abnormal, the blockchain network service platform can still store transaction data into the relational database, and the safety during data storage is improved.
Drawings
FIG. 1 is a functional architecture diagram of a blockchain network service platform according to an embodiment of the present application;
FIG. 2 is a schematic diagram of a resource layer configured as a container cluster 200 by deploying a containerized management system according to an embodiment of the present application;
fig. 3 is a schematic diagram of a developer accessing the blockchain network service platform 100 through a terminal 300 according to an embodiment of the present application;
Fig. 4A to fig. 4Q are schematic views showing various function management pages of the blockchain network service platform according to the embodiment of the present application;
FIG. 5 is a block chain network architecture diagram of an exemplary deployment using a block chain network service platform provided by an embodiment of the present application;
FIG. 6 is a flow chart of an exemplary transaction using a blockchain network service platform provided by an embodiment of the present application;
FIG. 7 is a schematic diagram of a Fabric ledger in the prior art according to an embodiment of the present invention;
FIG. 8 is a schematic diagram of an exemplary Fabric transaction flow provided by an embodiment of the present invention;
FIG. 9 is a flowchart of a data storage method of a blockchain network service platform according to an embodiment of the present invention;
FIG. 10 is a schematic diagram of a data storage method of an exemplary blockchain network service platform according to an embodiment of the present invention;
FIG. 11 is a schematic diagram of a block chain network service platform according to an embodiment of the present invention;
fig. 12 is a schematic diagram of a block chain network service platform according to an embodiment of the present invention.
Detailed Description
The present invention will be further described in detail with reference to the accompanying drawings, for the purpose of making the objects, technical solutions and advantages of the present invention more apparent, and the described embodiments should not be construed as limiting the present invention, and all other embodiments obtained by those skilled in the art without making any inventive effort are within the scope of the present invention.
Unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention belongs. The terminology used herein is for the purpose of describing embodiments of the invention only and is not intended to be limiting of the invention.
Before describing embodiments of the present invention in further detail, the terms and terminology involved in the embodiments of the present invention will be described, and the terms and terminology involved in the embodiments of the present invention will be used in the following explanation.
1) A Block (Block) records the data structure of the ledger data updated by transactions over a period of time, is time stamped and a unique tag (e.g., a digital fingerprint) of the previous Block, and after the Block is authenticated by the common identity of nodes in the blockchain network, is appended to the end of the blockchain as a new Block.
2) A blockchain (Blockchain) in which blocks are combined in a sequential manner to form a chained data structure, the hash value of a previous block or a subset thereof being referenced in each block, thereby cryptographically ensuring that the transaction recorded is not tamperable and counterfeit.
3) And the account book (Ledger) is used for summing up data recorded by taking the account as a dimension in the blockchain network, and comprises the elements such as account book data, account book state evidence, block index and the like.
4) Consensus (Consensus) is a process in blockchain networks for agreeing on transaction outcomes among the multiple nodes involved, and the mechanisms by which Consensus is achieved include proof of workload (PoW), proof of equity (PoS, proofofStake), proof of equity authorization (DPoS, DELEGATED PROOF-of-status), proof of elapsed time (PoET, proof of ElapsedTime), and the like.
5) Intelligent contracts (Smart Contracts), also known as chain code (Chaincode), deployed in blockchain networks run in a secure container that triggers execution according to conditions to initialize and manage ledger data and ledger states.
An exemplary functional architecture of a blockchain network implementing an embodiment of the present invention is described below, referring to fig. 1, and a functional architecture schematic of the blockchain network provided in the embodiment of the present invention in fig. 1 includes an application layer 101, a consensus layer 102, a network layer 103, a data layer 104, and a resource layer 105, which are described below.
The resource layer 105 encapsulates various available computing and storage resources, such as those in computers, servers/clusters, and clouds, abstracting and providing a unified interface to the data layer 104 to mask the variability of the underlying hardware implementing the resource layer 105.
Computing resources include various forms of processors such as Central Processing Units (CPUs), application Specific Integrated Circuits (ASICs), and Field-Programmable gate arrays (FPGAs).
Storage resources include various types of storage media such as various volatile memory and non-volatile memory. The nonvolatile Memory may be a Read Only Memory (ROM), a Programmable Read Only Memory (PROM), or a Programmable Read-Only Memory. The volatile memory may be random access memory (RAM, random Access Memory) which acts as external cache memory.
The computing resources and storage resources of resource layer 105 may be mapped to various types of nodes in the blockchain network, and the storage medium implementing embodiments of the present invention stores executable instructions for implementing the blockchain network deployment method of embodiments of the present invention, once the executable instructions deployed to the nodes are executed, the underlying resources (e.g., various types of processors) implementing the nodes will implement the deployment of the various types of nodes in the blockchain network, and perform the functions of the various types of nodes, thereby implementing a ledger for transactions in business processes, and various applications based on the ledger.
By way of example, the executable instructions may be in the form of software (including system programs and application programs), software modules, scripts, plug-ins, and the like, written in any form of programming language (including compiled or interpreted languages, or declarative or procedural languages), and it may be deployed in any form, including as a stand-alone program or as a module, component, or other unit suitable for use in a computing environment.
Data layer 104 encapsulates various data structures implementing the ledger, including ledger data implemented in a file system, ledger status and presence certificates implemented in a database.
The network layer 103 encapsulates point-to-point (P2P) network protocols, data propagation mechanisms and data verification mechanisms, access and authentication mechanisms, and service body identities. The P2P network protocol realizes communication among nodes in the blockchain network, a data transmission mechanism ensures transmission of transaction/transaction results in the blockchain network, a data verification mechanism is used for realizing reliability of data transmission among the nodes based on encryption methods (such as digital certificates, digital signatures and public/private key pairs), and an access and authentication mechanism is used for managing access and authentication of the terminal based on service body identities.
The consensus layer 102 encapsulates mechanisms for agreement of transaction results propagated in the blockchain, including POS, POW, DPOS, etc., supporting pluggable consensus mechanisms.
The application layer 101 encapsulates various services that the blockchain network can implement, including transaction settlement, traceability, and certification.
Referring to fig. 2, a schematic structure diagram of a resource layer configured as a container cluster 200 by deploying a containerized management system according to an embodiment of the present invention forms two types of nodes, namely, a management Node (MASTER SERVER) 200 and a service Node 300 (Node), in a machine for providing resources to the resource layer by deploying corresponding components of the containerized management system, where the management Node is used to manage scheduling and running of containers in the service Node, and the service Node is mainly used to run various containers, and provides an isolated running environment of various applications in a blockchain network, for example, a chain code container used to run chain codes, a Node container used to run codes of nodes (i.e., codes of various types of nodes in the blockchain network), and the like, which are described below.
The management node (MASTER SERVER) 200 is responsible for managing the cluster, providing access to resource data of the cluster to the outside in the form of a Service (Service), and comprises several exemplary components.
1) A state component (etcd) for saving the state of the whole cluster.
2) An application program interface service (API SERVER) component provides a unique portal for resource operations and provides mechanisms for authentication, authorization, access control, API registration, and discovery.
3) A scheduling (Scheduler) component for scheduling the containers to the appropriate nodes according to a predetermined scheduling policy for scheduling the resources. The container group (Pod) of the same set of resources in the container on which the service node operates (i.e., the machine on which the service node component is deployed) is the smallest unit of invocation, and for applications of the blockchain network may be implemented by one or more container groups, where the resources shared by the containers in the container group include an application namespace, a network namespace, a hostname, and a Volume (Volume).
Taking the example of a shared storage volume, when a shared file system component is deployed on a node, such as a Network File System (NFS), network FILE SYSTEM, clustered file system (glumerfs), ceph file system (Cephfs), the scheduling component can easily schedule (mount) the set of containers mounted on the storage volume into the storage volumes of other machines (nodes).
4) And the control management (Controller Manager) component is used for monitoring/maintaining the state of the cluster, monitoring the current state of each resource object of the whole cluster in real time through an interface provided by the application program interface service component, and repairing the current state to a desired state when various faults occur to cause the state of the system to change.
5) A copy controller (RC, replication Controller) component controls the running of a certain number of Pod copies at all times, e.g. if the running Pod copy exceeds a set value, closing part of the Pod copies, if the Pod copy is less than the set value, creating a new Pod copy.
6) A deployment controller (Deployment Controller) component for managing resource object-deployment (Deployment) objects in a maintenance container cluster, associating the deployment objects and replica controllers, providing declarative updates to the container groups and replica controllers in the deployment objects for declaring target states of the container groups and replica controllers, and thereby controlling implementation of updates to the replica controllers and the container groups when the deployment objects are updated.
Service node 300 includes the following exemplary components.
1) A container engine (noted Docker) is used to take care of all specific image downloads and container operations.
2) A daemon component (denoted Kubelet) for taking care of maintaining the lifecycle (creation, start and stop) of the containers, and also taking care of management of storage volumes and Container Network Interfaces (CNIs).
Taking management of storage volumes as an example, daemon components mount individual containers in a container group onto the same storage volume through components of shared file systems deployed in nodes, such as Network file systems (NFS, network FILE SYSTEM), cluster file systems (glumerfs), ceph file systems (Cephfs), so that individual containers store data produced during operation using the same storage volume, and data in a storage volume can be accessed by any container in the same container group.
3) The load balancing component (marked as Proxy) is responsible for providing Service with Service discovery and load balancing inside the cluster.
Based on the clusters shown in fig. 2, an exemplary process of deploying an application of a blockchain network, mirror-encapsulated to a container group (referred to as a target Pod in the following examples) and running at a Node (referred to as a target Node in the following examples) is as follows.
First, the management tool (Kubectl) of the container cluster 200 submits a request to create a copy controller (RC, replication Controller) including a definition of the target Pod, the number of copies the target Pod needs to run, the target Pod label (Lable) to be monitored, and so on.
Next, the request is written to etcd through API SERVER, at which time Controller Manager monitors this RC event through the interface of API SERVER that monitors the resource change, finds that there is no Pod instance corresponding to it in the current cluster, then generates a Pod object according to the Pod template definition in the RC, and writes to etcd through API SERVER.
Immediately after the RC event is discovered by the Scheduler, it immediately performs a scheduling procedure of selecting a drop Node for this new Pod, then writing this result to etcd via API SERVER, then the Kubelet process running on the target Node monitors this new Pod via API SERVER and initiates the new Pod as defined by it until the end of the Pod's life.
Then Kubectl submits a new Service creation request mapped to the target Pod, controller Manager queries the associated Pod instance through Label, generates endpoint (Endpoints) information (including address and port) of the Service, writes the endpoint information into etcd through API SERVER, and queries and monitors Endpoints information corresponding to the Service object through API SERVER by Proxy processes running on all nodes in the container cluster, and establishes a software load balancer to realize the flow forwarding function from the Service access to the back-end Pod.
In view of the foregoing, it is apparent that a blockchain network service platform implementing an embodiment of the present invention is implemented by deploying a container cluster in a resource layer and running a container encapsulated with a blockchain network application, and thus, a blockchain network implementing an embodiment of the present invention may be provided in the form of a memory and a processor, where executable instructions are stored, and when the executable instructions are executed by the processor, the container cluster is established on a plurality of nodes running the processor and the memory, and by running the encapsulated application in the container, a chain code installation method in the blockchain service network platform implementing an embodiment of the present invention is implemented.
The blockchain network platform for implementing the embodiment of the invention is connected with a developer in various modes and provides various graphical modes for deployment and management of the blockchain network, and is described below.
Referring to fig. 3, fig. 3 is a schematic diagram of a developer accessing the blockchain network service platform 100 through the terminal 300, where the SDK/Web 320 interface of the developer terminal 300 is connected to the SDE/Web interface corresponding to the data layer 104 in the blockchain network service platform 100, and supports the local and remote deployment of the blockchain network supporting the specific service at the terminal 300 of the developer, and the 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 container clusters and the access of new container clusters, the management of storage resources, the one-key deployment of the blockchain network, the chain code management (running state viewing), the application store management, and so on.
Referring to fig. 4A to 4Q, which are schematic views showing various function management pages of the blockchain network service platform according to the embodiment of the present invention, the function management pages shown in the graphical interface 310 of the developer terminal 300 in fig. 3 will be exemplarily described with reference to fig. 4A to 4Q.
FIG. 4A illustrates a state view page of the blockchain network service platform 100 in which the operational state of the blockchain network, e.g., CPU usage, memory usage, resource (node) usage, is in use.
Fig. 4B illustrates a console page of the one-touch deployment of the blockchain network service platform 100, supporting a developer to set basic information (including blockname, version number) and organization (including organization name, number of nodes, number of users, etc.) of the blockchain network, with default values to set high-level options including ordering node types, channel names, and chain code names, etc.
FIG. 4C illustrates a Console page of resource management of the resource layer 105 of the blockchain network service platform 100, wherein relevant information of clusters that a developer can deploy through the blockchain network service platform 100 is shown, including whether connected status, CPU/memory usage, etc.
In fig. 4D, the addition of container clusters for supporting the deblocking chain network is supported, the cluster name is entered, and the creation page is entered after the function option for creating the clusters is triggered.
In fig. 4E, a console page of a query cluster of the blockchain network service platform 100 is shown, and when a function button of the query cluster is triggered, a cluster list page is entered to support operations of adding a cluster, querying a cluster, deleting a cluster, and editing a cluster.
In FIG. 4F, a storage management console page of the blockchain network service platform 100 is shown, which when a storage management function button is triggered, will enter a storage management list page, displaying the created storage items in the cluster, including storage query and delete functions.
The console page of the blockchain network service platform 100 is shown in FIG. 4G for storing details, and in FIG. 4H for displaying the details of the storage and supporting dynamic storage space expansion of the storage.
The add store console page of blockchain network service platform 100 is shown in fig. 4I, supports the setting of added store names and nodes, adds nodes to container clusters according to the setting, and displays the added store details, including a list of nodes of the container clusters, in fig. 4J.
The superledger's console page of blockchain network services platform 100 is shown in fig. 4K, showing information of the name, network version, status, and creation time of the superledger used to deploy the blockchain network.
In FIG. 4L, a console page of the one-touch deployment of the super ledger of blockchain network services platform 100 is shown, providing configuration items for basic information of the super ledger deployment, and high-level configuration items employing default values, such as ordering node types, channels, default chain codes, initialization parameters, and the like.
In fig. 4M/N, a console page of uploading/installing the chain code of the blockchain network service platform 100 is shown, setting items of the chain code name and version number are provided in the uploaded console page, and configuration items of the chain code version, initialization parameters, organization and node are provided in the installed console page.
The console page of the blockchain network service platform 100 is shown in fig. 4O, which supports viewing information such as organization members, block heights, transaction numbers, contract numbers, etc. of different channels, and may also display information such as organization names, node names in channels, and chain code names in channels of the viewed channels.
In fig. 4P, a console page of a chain code query of the blockchain network service platform 100 is shown, supporting the use of network names, chain code parameters, ledger names, and chain code functions to cooperate with querying the chain codes, and the dimensions of the query include status, messages, and data.
In FIG. 4Q, a console page of the application store of the blockchain network service platform 100 is shown, supporting a developer to select applications that need to be deployed, once an application is determined to be deployed to the blockchain network, the quick deployment of container clusters to the resource layer 105 will be accomplished by multiplexing the mirror image of the application.
Referring to fig. 5, for one exemplary architecture of a blockchain network deployed using a blockchain network service platform, an application obtains a legitimate identity certificate from a CA to join an application channel within the network. Before the formal transaction is initiated, the transaction proposal (Proposal) needs to be constructed and submitted to the endorsement nodes in the organization 1 and the organization 2 for endorsement, and after the client collects enough endorsement support (the quantity is determined according to the endorsement policy), a legal transaction request (the endorsement carrying the endorsement nodes) can be constructed by utilizing the endorsement and sent to the ordering node (Orderer) in the ordering service for ordering, so that the transaction is packaged into a block.
Referring to fig. 6, a transaction flow of an application program and a blockchain network is shown, wherein the functions of a client and each node in the transaction flow are as follows:
Clients (applications) interact with the blockchain network using the SDKs. First, the client obtains a legal identity certificate from the CA to join an application channel within the network. Before the formal transaction is initiated, the transaction proposal (Proposal) needs to be firstly constructed and submitted to an endorsement node for endorsing, and after a client collects enough endorsement support (the quantity is determined according to an endorsement policy), a legal transaction request (the endorsement carrying the endorsement node) can be constructed by utilizing the endorsement, and the legal transaction request is sent to the ordering node (Orderer) for ordering, so that the transaction is packaged into a block. The client may also listen for messages in the network through an event mechanism to learn whether the transaction was successfully received.
And the endorsement node (Endorser) mainly provides a method for the client to call and complete endorsement (signature) processing of the transaction proposal. After receiving the transaction proposal from the client, firstly checking validity and ACL authority, checking pass the simulation operation transaction (the name and parameters of the chain code to be executed are executed in the transaction, the transaction is executed, the chain code appointed in the transaction is executed essentially), endorsing the state change (recorded in a read-write set form, comprising keys and versions of the read state and key values of the written state) caused by the transaction (namely, carrying out digital signature) and returning the result whether the client is supported or not.
And the ordering node (Orderer) is used for receiving the transaction containing the endorsement signature, ordering the unpacked transaction to generate a block, and broadcasting the block to the Peer node.
The master node (LEADER PEER), the node in communication with the ordering node, is responsible for retrieving the latest block from the ordering node and synchronizing internally within the blockchain network.
Accounting nodes (Committer) maintain blockchain and ledger structures (including state DB, history DB, index DB, etc.). The node periodically obtains the ordered bulk transaction block structure from the ordering node and checks for such transactions (including transaction message structure, signature integrity, whether repeated, whether read-write set versions match, etc.). After checking, legal transaction is executed, the result is written into account book, and new block is constructed.
It should be noted that all the Peer nodes are accounting nodes, which are responsible for verifying transactions from the sequencing node block, maintaining state data and copies of the ledger. Some Peer nodes will perform transactions and sign endorse the results, acting as endorsement nodes. The endorsement node is a dynamic role and is bound to a specific chain code. An endorsement policy is set for each chain code in the chain code container at the time of instantiation, specifying which nodes are valid for transaction endorsements. The endorsement node is only used when an application program initiates a transaction endorsement request to the endorsement node, and the other time is a common accounting node which is only responsible for verifying and accounting the transaction.
The ledger data is used as the core of the blockchain network and records all transaction logs in the whole network. Ledger data is often kept in a distributed fashion in a blockchain network, which also embodies the characteristics of blockchain decentralization. The storage mode of the account book data plays a vital role in the safety and the performance of the whole blockchain system.
The ledger data in HYPERDEGER FABRIC is called Ledger, which is mainly composed of two parts, a block Database (Chain) and a State Database (State Database). The two parts are both distinct and related, as shown in particular in fig. 7. The status database does not interact directly with the ledger database, but rather reads and writes transaction data to the status database via TxMgr (transaction manager) objects. The block database is a linked list logically connected by a block data structure, which is also the source of the blockchain name. The block database employs file system storage.
The status database records the results of the execution of the transaction, representing the most current results of all keys on the channel, so Fabric is also known as world status. The state database is also a database that is tightly related to blockchain applications. Typically, an application may interact with the state database through contracts without having to traverse the entire transaction log to query for a certain content. The ledger state is represented by default in Fabric as key-value pairs. Of course Fabric also provides the capability for expansion. Meanwhile, the state database with high adding, deleting and modifying efficiency can obviously improve the execution efficiency of the chain code. Therefore, the method has great significance in researching the state database of the ledger.
Fabric state databases include LevelDB and CouchDB.
LevelDB is a database of Key-values developed by Google. LevelDB is a Fabric default selected status database that is embedded for use in the Peer process. LevelDB values are saved as binary data, supporting only key-based query operations. As can be seen from the source code of Fabric, the leveldb database object and operation are packaged into own objects in the Github.com/syndtr/goleveldb/leveldb library, and DB is a database object in leveldb _helper.go under common/ledger/util/leveldbhelper, and the conf, leveldb.DB and synchronous or asynchronous read-write options are packaged. In leveldb _provider. Go, a database processing object DBHandle is defined that encapsulates the DB and corresponding database names and provides Put, get, delete operations.
CouchDB is a NoSQL database, which is a database of JSON documents. CouchDB is an optional additional extended state database. Any binary data modeled in the chain code can be stored as LevelDB, while supporting rich queries of the chain code data when modeled with JSON data. Codes for couchDB in Fabric are focused under core/ledger/util/couchdb. CouchDB can also enhance compliance in the blockchain and security of data protection. Because it is able to implement field level security by filtering and masking various attributes in the transaction and grant read-only rights only if needed.
The Fabric transaction flow is shown in fig. 8, wherein 1, firstly, a client initiates a transaction proposal, and the transaction proposal comprises information such as a client ID, a chain code ID, a tx load, a time stamp, a client signature, and the like, which indicates 3W elements, namely, who the message is who, and what whon is sent at what time when. The message is directed to three nodes EP1, EP2 and EP3 according to the endorsement policy in the chain code. 2. The three nodes EP1, EP2 and EP3 simulate executing smart contracts and send the results and the respective CA certificate signatures back to the client. The client proceeds to the next step after collecting a sufficient number of results. 3. The client sends the tx transaction containing the endorsement result to the ordering node. 4. The ordering node gives the packed blocks to CP1 and EP1, EP2 and EP3, and the endorsement nodes EP1, EP2 and EP3 check the results and write them into the world state and ledger. Meanwhile, the client side can also receive the notification due to the subscription of the message.
LevelDB are simple key value pairs suitable for account book contents, and have poor adaptability to complex account book states. LevelDB is embedded in the peer node process, and if the peer process is abnormally terminated, the LevelDB process also ends, which is easy to cause data loss. CouchDB only support data whose ledger contents are expressed in JSON format, and do not support relational data. CouchDB and LevelDB have significant shortcomings in terms of data consistency and complex queries (multi-table queries, nested queries, grouped queries, etc.).
The problems in the prior art can be solved by the method in the first embodiment.
Example 1
An embodiment of the present invention provides a data storage method of a blockchain network service platform, and fig. 9 is a flowchart of a data storage method of a blockchain network service platform provided by the embodiment of the present invention, as shown in fig. 9, a data processing method of a blockchain network service platform may include:
S101, under the condition that a transaction proposal initiated by a client is acquired, an endorsement node processes the transaction proposal by utilizing snapshot isolation of a relational database to obtain a transaction result, wherein the data type of the transaction result is the same as the data storage type of the relational database.
The data storage method of the blockchain network service platform is applied to the scene that the blockchain network service platform stores transaction results.
In an embodiment of the application, the transaction result includes two parts, read set and write set.
It should be noted that, the blockchain network service platform processes the transaction proposal by utilizing snapshot isolation of the relational database, and the obtained read set and write set are data matched with the data storage format of the relational database.
In the embodiment of the application, the endorsement node of the blockchain network service platform processes the transaction proposal by utilizing snapshot isolation of the relational database, and after a transaction result is obtained, the verification node of the blockchain network service platform processes the transaction proposal by utilizing a chain code method of the state database, so as to obtain a first transaction result.
In the embodiment of the application, the transaction proposal comprises the chain code method information, and under the condition that 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 process the transaction proposal by utilizing the chain code method, thereby obtaining a first transaction result.
In the embodiment of the application, the verification node of the block chain network service platform processes the transaction proposal by utilizing the chain code method of the state database, and before the first transaction result is obtained, the verification node also verifies the legitimacy of the transaction proposal, after the verification node verifies the legitimacy of the transaction proposal, the verification node processes the transaction proposal by utilizing the chain code method of the state database, and the process of obtaining the first transaction result comprises the steps that the verification node processes the transaction proposal by utilizing the chain code method of the state database under the condition that the verification node determines that the legitimacy of the transaction proposal passes, and the first transaction result is obtained.
In the embodiment of the application, the verification node comprises a Block Processor (Block Processor), and the Block Processor can create a database back-end process for the transaction proposal in the Block according to the execution sequence set to execute verification of the validity of the transaction proposal.
It should be noted that the number of processes may be plural, and the processes may be plural concurrent processes.
In the embodiment of the application, after determining that the transaction proposal is legal, the verification node also verifies whether the transaction corresponding to the transaction proposal occurs, if not, the verification node calls a 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 an endorsement policy, and if the verification passes, the verification node can store the transaction result in a relational database.
In the embodiment of the application, the endorsement node of the blockchain network service platform processes the transaction proposal by utilizing snapshot isolation of the relational database, and before a transaction result is obtained, the endorsement node also acquires data information updated by the relational database, and reads proposal data information corresponding to the transaction proposal by utilizing snapshot isolation. Under the condition that the data information and the proposal data information are different, the endorsement node processes the transaction proposal by utilizing snapshot isolation of the relational database to obtain a transaction result.
The method that the endorsement node can acquire the updated data information of the relational database can be specifically that the endorsement node acquires the consistency view from the relational database, so that the data information is obtained.
In the embodiment of the application, the endorsement node can acquire the updated data information of the relational database firstly, then the endorsement node can reuse the proposed data information corresponding to the snapshot isolation read transaction proposal, the endorsement node can also use the proposed data information corresponding to the snapshot isolation read transaction proposal firstly, then the endorsement node can acquire the updated data information of the relational database again, the endorsement node can acquire the updated data information of the relational database simultaneously when the endorsement node uses the proposed data information corresponding to the snapshot isolation read transaction proposal, and the determination can be specifically carried out according to the actual situation.
When the data information and the proposal data information are the same, the endorsement node does not process the transaction proposal by using snapshot isolation of the relational database.
In the embodiment of the present application, the number of transaction proposals may be one, two, or a plurality of, and may be specifically determined according to practical situations, which is not limited in the embodiment of the present application.
In the embodiment of the application, the endorsement node also collects the corresponding relation between the transaction proposal and the query sequence of the structured query language (Structured Query Language, SQL) and the execution sequence of the transaction proposal.
In the embodiment of the application, the endorsement node transmits the collected corresponding relation between the transaction proposal and the SQL query sequence to the verification node so that the verification node can process the transaction proposal by utilizing the link code method of the state database and the corresponding relation between the transaction proposal and the SQL query sequence to obtain a first transaction result.
In the embodiment of the application, the relational database query statements can be divided into four categories SELECT, INSERT, UPDATE, 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 corresponding fields at these beginning, and for INSERT queries, the write set at the last level of the query plan tree needs to be captured (i.e., before the actual tuples are stored in the disk blocks of the table). For UPDATE queries (even with sub-select queries), the writeset needs to be collected at the last level of execution (i.e., before the actual tuples in the disk block of the UPDATE table), while the partial read set contains only the old rows that have just been updated. For DELETE queries, rows that are deleted will be added to their corresponding write sets. The data structure of the read-write set of the relational database is as follows:
Data structure of the transaction set:
List < a SELECT Query, list of < table_row_id, version # >, where a SELECT Query represents the Query statement, table_row_id represents the table_row_id to Query, can be considered as a unique key.
The data structure of the write set contains three because there are three queries that involve modification of the data:
List < a INSERT Query, list of < table_name, row_data > >, wherein table_name represents a tag name of data to be inserted, row_data represents data to be actually inserted, a hash value corresponding to the data can be stored, and trade-off can be made according to actual conditions.
List < a UPDATE Query, list of < old Row's table_row_id, version#, new row_data > >, wherein old Row's table_row_id indicates those identifications that need to get updated rows, version# indicates the current Version situation, new row_data represents the Row data to be updated.
List < a DELETE Query, list of < table_row_id, version # >, this side records row_id and corresponding Version number to be deleted for the Query to be deleted.
In embodiments of the present application, the order in which rows are added to the read/write set may be different on different database nodes for the reads and writes of the rows, depending on the query plan selected. Thus, the endorsement node needs to sort the read set and the write set separately before signing. To ensure that the query is executed correctly again during the verification phase, a set of execution sequences needs to be maintained during the endorsement phase to ensure that the order of storage is the same as the order in which the chain code was submitted. This may be accomplished by storing the id of the SQL query and the corresponding timestamp.
S102, when the transaction result is verified, the verification node is utilized to store the transaction result into the relational database.
In the embodiment of the application, the endorsement node in the blockchain network service platform processes the transaction proposal by utilizing snapshot isolation of the relational database, and after the transaction result is obtained, the blockchain network service platform stores the transaction result to the relational database by utilizing the verification node under the condition that the transaction result is verified.
In the embodiment of the application, the verification node processes the transaction proposal by using a chain code method of a state database, and after a first transaction result is obtained, the verification node stores the transaction result in a relational database.
In the embodiment of the application, under the condition that the verification node determines that the first transaction result is not matched with the transaction result, the verification node terminates the transaction corresponding to the transaction proposal by utilizing the block processing program.
In the embodiment of the application, the block chain network service platform also comprises a sequencing node.
In the embodiment of the application, the number of the transaction proposals can be multiple, the endorsement node processes the transaction proposals by utilizing snapshot isolation of the relational database, after a transaction result is obtained, the verification node stores the transaction result in the relational database, the ordering node acquires a plurality of channel serial numbers and a plurality of transaction times corresponding to the transaction proposals, after the ordering node acquires the plurality of channel serial numbers and the plurality of transaction times corresponding to the transaction proposals, the ordering node determines at least two first transaction proposals with the same channel serial number from the plurality of channel serial numbers, then the ordering node orders 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, so as to obtain the ordered transaction proposal, and then the ordering node packages the ordered transaction result corresponding to the ordered transaction proposal, so as to obtain the block data.
It should be noted that, the transaction time is the time when the client initiates the transaction, after the client initiates the transaction, the client first obtains the timestamp information of the transaction, and then the client adds the timestamp information to the transaction proposal.
In the embodiment of the application, the ordering node may order 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 and the formula policy, so as to obtain the ordered transaction proposal.
It should be noted that the consensus strategy may be a Raft consensus strategy, or may be another consensus strategy, and may be specifically determined according to an actual situation, which is not limited in the embodiment of the present application.
In the embodiment of the application, the transaction proposal comprises the channel sequence number and the transaction time, the sorting node can acquire the channel sequence number and the transaction time corresponding to the transaction proposal from the transaction proposal after the transaction proposal is acquired, and the sorting node can acquire the channel sequence number and the transaction time from the transaction proposal under the condition that the sorting node receives a plurality of transaction proposals.
In the embodiment of the application, the sorting node can directly package the sorted transaction results to obtain the block data, and can package the sorted transaction results meeting the preset quantity threshold under the condition that the quantity of the sorted transaction results meets the preset quantity threshold to obtain the block data, and the method and the device can be specifically determined according to actual conditions, and are not limited.
In the embodiment of the application, the block data specifically can comprise a read set and a write set, and the block data also can comprise a write set, which can be specifically determined according to actual conditions, and the embodiment of the application is not limited to the above.
In the embodiment of the application, the block data comprises a plurality of transaction results, and the verification node inquires the transaction result of the next transaction proposal in the block data until all the transaction results in the block data pass under the condition that the verification node determines that the first transaction result is matched with the transaction result.
In the embodiment of the application, when all the transaction proposals in the block data pass verification, the verification node submits the transaction result by using the block processing program.
In the embodiment of the application, the sorting node packages the sorted transaction proposal to obtain the block data, and the verification node stores the block data into the relational database according to the relational data format.
The relational data format is a data format when data is stored in a relational database.
In the embodiment of the application, the verification node can update the relational database according to the < Row_ID and version# > when submitting the transaction result, and store the block data into the relational database, namely realize the persistence of the transaction.
In the embodiment of the application, when the verification node submits a plurality of transaction results, the verification node can serially submit the transaction results.
It can be appreciated that the relational database is utilized as a state database of the ledger, so that the traditional quick development of intelligent contracts based on the application of the relational database can be facilitated, and the application is easier to link. The relational database may support multiple types of queries, such as multi-table join queries, nested queries, grouped queries, and the like. The relational database may limit user access rights and security policies at the row level, providing finer granularity of access control than the non-relational database.
Illustratively, as shown in FIG. 10, upon receiving a transaction proposal, the client transmits the transaction proposal to an endorsement node (the number of endorsement nodes may be one or more), and the transaction proposal includes a signature of the client. Under the condition that the endorsement node receives the transaction proposal sent by the client, the endorsement node processes the transaction proposal based on snapshot isolation of the relational database to obtain a transaction result, endorse the transaction proposal, and then the endorse node transmits the endorse signature and the transaction result to the client. After receiving the endorsement signature and the transaction result transmitted by the endorsement node, the client compares whether the endorsement signature returned by each endorsement node is consistent or not, and whether the transaction result returned by each endorsement node is consistent or not, and if the endorsement signature is consistent and the transaction result is consistent, the client transmits the transaction result, the endorsement signature and the transaction proposal to the ordering node (if the transaction proposal is multiple, the corresponding transaction result is multiple, and the corresponding endorsement signature is also multiple). Under the condition that a transaction result, an endorsement signature and a transaction proposal are received, the endorsement node acquires transaction time and a plurality of channel serial numbers corresponding to the transaction proposals from the transaction proposals, determines at least two first transaction proposals with the same channel serial numbers from the channel serial numbers, sorts the at least two first transaction proposals according to the at least two first transaction time corresponding to the at least two first transaction proposals, packages the sorted transaction result corresponding to the sorted transaction proposal to obtain block data, and then transmits the block data to a verification node (the number of verification nodes can be a plurality of). The verification node receives the block data and verifies the legitimacy of a plurality of transaction proposals corresponding to a plurality of transaction results in the block data, processes a plurality of easy proposals by utilizing a chain code method of a state database to obtain a plurality of first transaction results under the condition that the legitimacy of the plurality of transaction proposals passes, and respectively matches the plurality of first transaction results with the plurality of transaction results.
It should be noted that, the chain code method may be a chain code method for updating the requirement of the ledger, or may be a chain code method for querying the requirement of the ledger, which may be specifically determined according to the actual situation, which is not limited by the embodiment of the present application.
It can be understood that the blockchain network service platform processes the transaction proposal by utilizing snapshot isolation through the relational database, so that a transaction result with the same data type as the data storage type of the relational database can be obtained, the blockchain network service platform can directly store the transaction result into the relational database under the condition that the transaction result is verified, and the blockchain network service platform can still store transaction data into the relational database under the condition that the nodes of the blockchain network service platform are abnormal, thereby improving the security during data storage.
Example two
Based on the embodiments of the present invention, an embodiment of the present invention provides a blockchain network service platform 100, as shown in fig. 11, where the blockchain network service platform 100 includes:
The endorsement node 11 is configured to process the transaction proposal by using snapshot isolation of a relational database under the condition that the transaction proposal initiated by the client is acquired, so as to obtain a transaction result, where a data type of the transaction result is the same as a data storage type of the relational database;
and a verification node 12, configured to store the transaction result in a relational database by using the verification node when the transaction result is verified.
In some embodiments of the present invention, the verification node 12 is configured to process the transaction proposal by using a chain code method of a status database to obtain a first transaction result, and store the transaction result in the relational database if the first transaction result matches the transaction result.
In some embodiments of the present invention, the verification node 12 is configured to verify the validity of the transaction proposal, and in case that the validity of the transaction proposal passes, process the transaction proposal by using a chain code method of a state database to obtain the first transaction result.
In some embodiments of the present invention, the endorsement node 11 is configured to obtain updated data information of the relational database, read proposal data information corresponding to the transaction proposal by using the snapshot isolation, and process the transaction proposal by using the snapshot isolation of the relational database to obtain the transaction result when the data information is different from the proposal data information.
In some embodiments of the invention, the blockchain network service platform further includes a ranking node;
The ordering node is used for acquiring a plurality of channel serial numbers and a plurality of transaction times corresponding to a plurality of transaction proposals, determining at least two first transaction proposals with the same channel serial numbers from the plurality of channel serial numbers, ordering 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 ordered transaction proposals, and packaging ordered transaction results corresponding to the ordered transaction proposals to obtain block data.
In some embodiments of the invention, the validation node is configured to store the block data to a relational database in a relational data format using the validation node.
Based on the same concept of the first embodiment, an embodiment of the present application provides a blockchain network service platform, as shown in fig. 12, fig. 12 is a schematic diagram of a second component structure of the blockchain network service platform according to the embodiment of the present application, and 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 a specific embodiment, the at least one Processor 13 may be at least one of an Application Specific Integrated Circuit (ASIC), a digital signal Processor (DSP, digital Signal Processor), a digital signal processing terminal (DSPD, digital Signal Processing Device), a programmable logic terminal (PLD, programmable Logic Device), a field programmable gate array (FPGA, field Programmable GATE ARRAY), a CPU, a controller, a microcontroller, and a microprocessor. It will be appreciated that the electronics for implementing the above-described processor functions may be other for different devices, and embodiments of the present application are not particularly limited.
In an embodiment of the application, the at least one communication bus 15 is used for realizing connection communication between the at least one processor 13 and the at least one memory 14, the at least one memory 14 is used for storing executable instructions;
at least one processor 13 for executing executable instructions stored in the at least one memory 14 to implement the block data storage method according to the first embodiment.
An embodiment of the present application provides a storage medium, where one or more programs are stored, where the one or more programs may be executed by one or more processors, and the program is applied to a blockchain network service platform, where the program is executed by at least one processor to implement a block data storage method according to the first embodiment.
It can be understood that the blockchain network service platform processes the transaction proposal by utilizing snapshot isolation through the relational database, so that a transaction result with the same data type as the data storage type of the relational database can be obtained, the blockchain network service platform can directly store the transaction result into the relational database under the condition that the transaction result is verified, and the blockchain network service platform can still store transaction data into the relational database under the condition that the nodes of the blockchain network service platform are abnormal, thereby improving the security during data storage.
It will be appreciated by those skilled in the art that embodiments of the present invention may be provided as a method, system, or computer program product. Accordingly, the present invention may take the form of a hardware embodiment, a software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, magnetic disk storage, optical storage, and the like) having computer-usable program code embodied therein.
The present invention is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the invention. It will be understood that each flow and/or block of the flowchart illustrations and/or block diagrams, and combinations of flows and/or blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
The foregoing description is only of the preferred embodiments of the present invention, and is not intended to limit the scope of the present invention.
Claims (7)
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202011388433.0A CN114579354B (en) | 2020-12-01 | 2020-12-01 | Block chain network service platform, data storage method and storage medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202011388433.0A CN114579354B (en) | 2020-12-01 | 2020-12-01 | Block chain network service platform, data storage method and storage medium |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN114579354A CN114579354A (en) | 2022-06-03 |
| CN114579354B true CN114579354B (en) | 2025-08-01 |
Family
ID=81767049
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202011388433.0A Active CN114579354B (en) | 2020-12-01 | 2020-12-01 | Block chain network service platform, data storage method and storage medium |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN114579354B (en) |
Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110827008A (en) * | 2018-08-08 | 2020-02-21 | 华为技术有限公司 | Block chain link point and transaction method |
Family Cites Families (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US11169985B2 (en) * | 2018-07-27 | 2021-11-09 | Oracle International Corporation | System and method for supporting SQL-based rich queries in hyperledger fabric blockchains |
| CN111241589A (en) * | 2018-11-29 | 2020-06-05 | 华为技术有限公司 | A database system, node and method |
| CN111241590B (en) * | 2018-11-29 | 2025-05-16 | 华为技术有限公司 | A database system, node and method |
| CN110544095A (en) * | 2019-09-03 | 2019-12-06 | 腾讯科技（深圳）有限公司 | Transaction processing method of block chain network and block chain network |
-
2020
- 2020-12-01 CN CN202011388433.0A patent/CN114579354B/en active Active
Patent Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110827008A (en) * | 2018-08-08 | 2020-02-21 | 华为技术有限公司 | Block chain link point and transaction method |
Also Published As
| Publication number | Publication date |
|---|---|
| CN114579354A (en) | 2022-06-03 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN108965468B (en) | Block chain network service platform, chain code installation method thereof and storage medium | |
| JP7691550B2 (en) | SYSTEM AND METHOD FOR SUPPORTING SQL-BASED RICH QUERIES IN A HYPERLEGGIA FABRIC BLOCKCHAIN | |
| US11743137B2 (en) | Systems, methods, and apparatuses for implementing a metadata driven rules engine on blockchain using distributed ledger technology (DLT) | |
| CN114365133B (en) | System or method for implementing the right to be forgotten on a metadata-driven blockchain using secret sharing and consensus on reads | |
| EP4047487B1 (en) | File storage method, terminal, and storage medium | |
| US20240248894A1 (en) | Dag based methods and systems of transaction processing in a distributed ledger | |
| US20210226774A1 (en) | Systems, methods, and apparatuses for implementing user access controls in a metadata driven blockchain operating via distributed ledger technology (dlt) using granular access objects and alfa/xacml visibility rules | |
| CN109191124B (en) | Block chain network, deployment method and storage medium | |
| CN110226168B (en) | System and method for providing an interface to blockchain cloud services | |
| CN113169952B (en) | A container cloud management system based on blockchain technology | |
| CN109218079B (en) | Block chain network, deployment method and storage medium | |
| CN111737104B (en) | Block chain network service platform, test case sharing method thereof and storage medium | |
| CN111294379B (en) | Block chain network service platform, authority hosting method thereof and storage medium | |
| WO2020160109A1 (en) | Systems, methods, and apparatuses for implementing efficient storage and validation of data and metadata within a blockchain using distributed ledger technology (dlt) | |
| KR20210151926A (en) | Version history management using blockchain | |
| US12425249B2 (en) | Dividing data storage and service operations among plural blockchains | |
| JP2023544518A (en) | Blockchain-based systems and methods for exposing operating systems | |
| CN114157550B (en) | Alliance block chain system based on conflict-free transaction merging | |
| CN117896130B (en) | Industrial Internet data access control method, device, equipment and medium | |
| US10892887B2 (en) | Method and system for storing a binary large object | |
| CN116671092A (en) | Minimize the impact of a faulty peer on the blockchain | |
| CN114579354B (en) | Block chain network service platform, data storage method and storage medium | |
| CN112181599A (en) | Model training method, device and storage medium | |
| CN115730934B (en) | Block chain-based data processing method, device, equipment and storage medium | |
| CN116975158B (en) | Request processing method, apparatus, computer device and storage medium |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |