CN116662440A - Block chain storage method, device, electronic equipment, storage medium and program product - Google Patents

Block chain storage method, device, electronic equipment, storage medium and program product Download PDF

Info

Publication number
CN116662440A
CN116662440A CN202210148917.0A CN202210148917A CN116662440A CN 116662440 A CN116662440 A CN 116662440A CN 202210148917 A CN202210148917 A CN 202210148917A CN 116662440 A CN116662440 A CN 116662440A
Authority
CN
China
Prior art keywords
block
data
database
stored
latest
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.)
Pending
Application number
CN202210148917.0A
Other languages
Chinese (zh)
Inventor
邵珠光
苏蹦蹦
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Tencent Technology Shenzhen Co Ltd
Original Assignee
Tencent Technology Shenzhen Co Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Tencent Technology Shenzhen Co Ltd filed Critical Tencent Technology Shenzhen Co Ltd
Priority to CN202210148917.0A priority Critical patent/CN116662440A/en
Publication of CN116662440A publication Critical patent/CN116662440A/en
Pending legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/22Indexing; Data structures therefor; Storage structures
    • YGENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02DCLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D10/00Energy efficient computing, e.g. low power processors, power management or thermal management

Abstract

The embodiment of the application discloses a blockchain storage method, a blockchain storage device, electronic equipment, a storage medium and a program product. The method is applied to a block chain node, a plurality of database clients are deployed in the block chain node, and the block chain storage method comprises the following steps: dividing the block data to be stored into a plurality of batches of block sub-data; distributing the block sub-data of multiple batches to multiple database clients; and the received block sub-data is written into the database cluster by a plurality of database clients. According to the block chain storage method disclosed by the application, the block data to be stored in the block chain node is divided into a plurality of batches of block sub-data, and the block sub-data is written into the database cluster by different database clients in the block chain node simultaneously, so that the writing efficiency of the block data to be stored is improved.

Description

Block chain storage method, device, electronic equipment, storage medium and program product
Technical Field
The present application relates to the field of blockchain technologies, and in particular, to a blockchain storage method, a device, an electronic apparatus, a storage medium, and a program product.
Background
The blockchain technology is a brand new distributed infrastructure and computing mode which uses a blockchain data structure to verify and store data, uses a distributed node consensus algorithm to generate and update data, uses a cryptography mode to ensure the safety of data transmission and access, and uses an intelligent contract consisting of automated script codes to program and operate the data. The blockchain refers to a set of basic framework which is decentralized and has the characteristic of distributed storage, in particular to a data structure which is formed by using a mode similar to a linked list for data blocks according to a time sequence, can safely store data which have a precedence relationship and can be verified in a system, and ensures that the data cannot be tampered or counterfeited in a cryptography mode.
Among them, for blockchain storage, single node storage and distributed database storage are currently included. For single-node storage, the limitation of a storage server per se causes that the single-node storage cannot meet the requirement of mass data storage; for the storage of the distributed database, the transaction provided by the distributed database is used for storage, so that the problem of low transaction performance exists, and the storage efficiency is low.
Disclosure of Invention
In order to solve the above technical problems, embodiments of the present application provide a blockchain storage method, a device, an electronic apparatus, a storage medium, and a program product.
According to an aspect of an embodiment of the present application, there is provided a blockchain storage method applied to a blockchain node having a plurality of database clients deployed therein, the method including:
dividing the block data to be stored into a plurality of batches of block sub-data;
distributing the block sub-data of the plurality of batches to the plurality of database clients;
and the plurality of database clients write the received block sub-data into the database cluster in parallel.
According to an aspect of an embodiment of the present application, there is provided a blockchain storage device including:
the dividing module is configured to divide the block data to be stored into a plurality of batches of block sub-data;
a distribution module configured to distribute the plurality of batches of block sub-data into the plurality of database clients;
and the writing module is configured to write the received block sub-data into the database cluster by the plurality of database clients.
According to an aspect of an embodiment of the present application, there is provided an electronic apparatus including:
a memory storing computer readable instructions;
a processor that reads the computer readable instructions stored by the memory to perform the blockchain storage method of any of the above.
According to an aspect of an embodiment of the present application, there is provided a computer-readable storage medium having stored thereon computer-readable instructions which, when executed by a processor of a computer, cause the computer to perform a blockchain storage method as described above.
According to an aspect of embodiments of the present application, there is also provided a computer program product comprising a computer program which, when executed by a processor, implements the steps in a blockchain storage method as described above.
In the technical scheme provided by the embodiment of the application, the block data to be stored is divided into a plurality of batches of block sub-data in the block link points, and the block sub-data is written into the database cluster from different database clients deployed in the block link points at the same time, so that the writing efficiency of the block data to be stored can be improved.
It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the application as claimed.
Drawings
The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the application and together with the description, serve to explain the principles of the application. It is evident that the drawings in the following description are only some embodiments of the present application and that other drawings may be obtained from these drawings without inventive effort for a person of ordinary skill in the art. In the drawings:
FIG. 1 is a schematic diagram of a blockchain network in accordance with an exemplary embodiment;
FIG. 2 is a schematic diagram of an implementation environment in which the present application is directed;
FIG. 3 is a schematic illustration of another implementation environment in which the present application is directed;
FIG. 4 is a flowchart illustrating a blockchain storage method in accordance with an exemplary embodiment of the present application;
FIG. 5 is an effect diagram of a blockchain storage method according to an exemplary embodiment of the present application;
FIG. 6 is a flowchart illustrating a blockchain storage method in accordance with another exemplary embodiment of the present application;
FIG. 7 is a flowchart of an exemplary embodiment following step S430 in the blockchain storage method of FIG. 4;
FIG. 8 is a flow chart of step S720 in the embodiment shown in FIG. 7 in an exemplary embodiment
FIG. 9 is a flowchart illustrating a blockchain storage method in accordance with another exemplary embodiment of the present application; the method comprises the steps of carrying out a first treatment on the surface of the
FIG. 10 is a general flow diagram of a blockchain storage method shown in an exemplary embodiment of the application;
FIG. 11 is a flow chart illustrating a block chain node downtime condition in a block chain storage method in accordance with an exemplary embodiment of the present application;
FIG. 12 is a flow chart illustrating a process of downtime of block chain nodes in the block chain storage method of the embodiment shown in FIG. 11;
FIG. 13 is a block diagram of a blockchain device shown in an exemplary embodiment of the application;
fig. 14 shows a schematic diagram of a computer system suitable for use in implementing an embodiment of the application.
Detailed Description
Reference will now be made in detail to exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, the same numbers in different drawings refer to the same or similar elements, unless otherwise indicated. The implementations described in the following exemplary examples do not represent all implementations consistent with the application. Rather, they are merely examples of apparatus and methods consistent with aspects of the application as detailed in the accompanying claims.
The block diagrams depicted in the figures are merely functional entities and do not necessarily correspond to physically separate entities. That is, the functional entities may be implemented in software, or in one or more hardware modules or integrated circuits, or in different networks and/or processor devices and/or microcontroller devices.
The flow diagrams depicted in the figures are exemplary only, and do not necessarily include all of the elements and operations/steps, nor must they be performed in the order described. For example, some operations/steps may be decomposed, and some operations/steps may be combined or partially combined, so that the order of actual execution may be changed according to actual situations.
In the present application, the term "plurality" means two or more. "and/or" describes an association relationship of an association object, meaning that there may be three relationships, e.g., a and/or B may represent: a exists alone, A and B exist together, and B exists alone. The character "/" generally indicates that the context-dependent object is an "or" relationship.
First, embodiments of the present application relate to Blockchain (Blockchain) technology. The blockchain technology is a brand new distributed infrastructure and computing mode which uses a blockchain data structure to verify and store data, uses a distributed node consensus algorithm to generate and update data, uses a cryptography mode to ensure the safety of data transmission and access, and uses an intelligent contract consisting of automated script codes to program and operate the data. The blockchain refers to a set of basic framework which is decentralized and has the characteristic of distributed storage, in particular to a data structure which is formed by using a mode similar to a linked list for data blocks according to a time sequence, can safely store data which have a precedence relationship and can be verified in a system, and ensures that the data cannot be tampered or counterfeited in a cryptography mode. Briefly, blockchains are decentralized distributed ledgers, each chain corresponding to a separate ledger.
Fig. 1 is a schematic diagram of a blockchain network in accordance with an exemplary embodiment. The blockchain network 100 shown in fig. 1 may include node devices 10a, 10b, 10c, 10d. The node devices 10a, 10b, 10c, and 10d are each blockchain nodes (simply referred to as nodes) in the blockchain network 100 shown in fig. 1, and these nodes may be any form of computing device that accesses the blockchain network 100, such as a server, a user terminal, and so on. The node devices 10a, 10b, 10c, and 10d shown in fig. 1 may also be connected to form the blockchain network 100 by way of network communication.
It should be appreciated that the nodes in the blockchain network architecture shown in fig. 1 may form a point-to-point (P2P) network, where the P2P protocol may be an application layer protocol running on top of a transmission control protocol (TCP, transmissionContro lpoll) protocol. In the network architecture corresponding to the blockchain network 100, any machine, such as a server, a terminal, may be added to become a node, and the node may specifically include a hardware layer, a middle layer, an operating system layer, and an application layer.
Each node in the blockchain network 100 may be configured to maintain the same blockchain ledger (i.e., the blockchain ledger 10e shown in fig. 1), where a plurality of intelligent contracts may be pre-deployed on the blockchain corresponding to the blockchain ledger 10e, for example, may be pre-deployed: agent contracts, rights management contracts, data contracts, agent management contracts, and the like have different data processing functions. Intelligent contracts are also understood to mean computerized agreements that can execute the terms of a certain contract, implemented by code deployed on a blockchain ledger for execution when certain conditions are met, for completing automated transactions according to actual business demand code.
It will be appreciated that the types of blockchains involved in the blockchain network architecture shown in fig. 1 may include, in particular: public chains (Public Blockchain), private chains (Private Blockchain), and federated chains (Consortium blockchain), the types of blockchains employed in different blockchain application scenarios may be different. The public chain refers to a blockchain which can be externally disclosed and can be added and accessed by anyone; the blocks on the public chain can be checked by anyone, and the anyone can initiate the transaction on the public chain and can participate in the consensus process of the public chain at any time. The private chain can be used in private organization, and the read-write authority and participation accounting authority on the blockchain can be formulated according to the rules of the private organization; typically for data management, auditing, etc. within an enterprise. The alliance chain refers to the read-write authority of alliance members participating in the alliance chain on the blockchain, and the participation accounting authority can be formulated according to alliance rules; generally used in the context of transactions, settlements or clearing between institutions.
Fig. 2 is a schematic diagram of an implementation environment in which the present application is directed. The implementation environment includes a blockchain node 210, the blockchain node 210 including a plurality of database clients 211 and a database cluster 212, the blockchain node 210 pre-establishing a wired or wireless network connection with the plurality of database clients 211, the plurality of database clients 211 and the database cluster 212 pre-establishing a wired or wireless network connection.
As shown in fig. 2, the blockchain node 210 divides the blockdata to be stored into multiple batches of blocksub-data, and distributes the multiple batches of blocksub-data to the multiple database clients 211, the multiple database clients 211 receive the multiple batches of blocksub-data distributed by the blockchain node 210, and write the received multiple batches of blocksub-data into the database cluster 212 in parallel, and the database cluster 212 stores the multiple batches of blocksub-data written by the multiple database clients 211 in parallel.
Further, in view of the storage bottleneck of the database cluster 212 in the blockchain node 210, the present application provides another implementation environment for expanding the storage capacity of the database cluster, and the details refer to fig. 3. Fig. 3 is a schematic diagram of another implementation environment to which the present application relates. The implementation environment includes a blockchain node 310 and a database cluster 320, the blockchain node 310 includes a plurality of database clients 311, the blockchain node 310 pre-establishes wired or wireless network connections with the plurality of database clients 311, and the plurality of database clients 311 and the database cluster 320 pre-establish wired or wireless network connections.
As shown in fig. 3, the blockchain node 310 divides the blockdata to be stored into multiple batches of blocksub-data, and distributes the multiple batches of blocksub-data to the multiple database clients 311, the multiple database clients 311 receive the multiple batches of blocksub-data distributed by the blockchain node 310, and write the received multiple batches of blocksub-data into the database cluster 320 concurrently, and the database cluster 320 stores the multiple batches of blocksub-data concurrently written by the multiple database clients 311.
The blockchain node shown in fig. 2 or fig. 3 may be any terminal device supporting blockchain storage, such as a smart phone, a vehicle-mounted computer, a tablet computer, a notebook computer, or a wearable device, but is not limited thereto. The database cluster shown in fig. 2 or fig. 3 may be a storage server, for example, may be an independent physical server, may be a server cluster or a distributed system formed by a plurality of physical servers, or may be a cloud server that provides cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN (Content Delivery Network ), and basic cloud computing services such as big data and artificial intelligence platforms, which are not limited herein.
Referring to fig. 4, fig. 4 is a flowchart illustrating a blockchain storage method according to an exemplary embodiment of the application. The blockchain storage method can be applied to the implementation environment shown in fig. 2 or 3 and is specifically executed by the blockchain link points in the implementation environment. It should be understood that the method may be adapted to other exemplary implementation environments and be specifically executed by devices in other implementation environments, and the implementation environments to which the method is adapted are not limited by the present embodiment.
The block chain node with functions of storage, calculation and the like is used as a specific execution body to describe the block chain node method according to the embodiment of the application in detail.
As shown in fig. 4, in an exemplary embodiment, the blockchain storage method includes at least steps S410 to S430, which are described in detail below:
in step S410, the block data to be stored is divided into a plurality of blocks of sub-data.
It should be noted that the block data to be stored refers to the data contained in the block to be stored. For example, the block data to be stored may include block data in a block body and block data in a block header. The block data in the block main body comprises input data, and the block data in the block header comprises input information characteristic data, version data, timestamp data, difficulty data and the like. It should be further noted that, for convenience of storage, the block data to be stored generally exists in a key-value pair manner.
The block sub-data refers to part of the block data contained in the block to be stored.
The block link point divides the block data to be stored into a plurality of batches of block sub-data. It should be noted that, in order to improve the concurrent writing efficiency, the blockchain node may divide the block data to be stored according to the attribute of the database client. For example, if the blockchain node includes 3 database clients, the blockchain node may divide the 10 key-value data into 3 batches according to the 3 database clients, and each batch includes 3 key-value data, 4 key-value data, and 3 key-value data, where the 3 key-value data is a batch of blocksub-data. Of course, the blockchain node may also divide the 10 key-value data into 2 batches, each batch including 3 key-value data and 7 key-value data, respectively. The embodiments of the present application are not limited in this regard.
In step S420, the block sub-data of multiple batches are distributed to multiple database clients.
The block link distributes the partitioned batches of block sub-data to a plurality of database clients. It should be noted that, in order to facilitate distributing the block sub-data of multiple batches to multiple database clients, the blockchain node may further include a database client connection pool, and in detail, referring to fig. 5, the database client connection pool includes several database clients. The database client connection pool is used for distributing block data to be stored to a plurality of database clients. The block link point sends the block data to be stored to a database client connecting pool, and the database client connecting pool distributes block sub-data according to the writing capability of each database client or the number of the database clients included by the database client connecting pool.
In step S430, the plurality of database clients write the received block sub-data into the database cluster concurrently.
The database cluster refers to a storage module for block data to be stored. Wherein the database cluster comprises at least one database. The database cluster may be a storage module included in the block node, or may be a remote storage module, i.e., a remote storage server.
And the plurality of database clients in the blockchain node write the received block sub-data into the database cluster in parallel.
As shown in fig. 5, in order to facilitate the plurality of database clients in the blockchain node to write the received blockchain sub-data into the database cluster concurrently, the blockchain node of this embodiment further includes a database scheduling module, where the database scheduling module is configured to write the blockchain sub-data received by the plurality of database clients into the database clients concurrently.
It should be noted that, the database scheduling module may implement the concurrent writing function independently, or may exist in multiple database clients, so as to implement the concurrent writing function.
In addition, in order to ensure the atomicity of writing of the block data to be stored, any one of the plurality of database clients determines a first latest block height in the database cluster. The first latest block height may be understood as a sequence number of a block corresponding to the block data to be stored in the database cluster, or may be understood as the number of blocks in the database cluster after the block data to be stored is written into the database cluster.
It can be seen that, in the blockchain storage method of the embodiment, the block data to be stored is divided into multiple batches of block sub-data, and the block sub-data is written into the database cluster from different database clients simultaneously, so that compared with the prior art that the single data client operates the writing of the block data to be stored into the database cluster, the writing efficiency of the block data to be stored is improved.
Based on the above embodiments, it is considered that in the present application, a plurality of database clients write the block sub-data of a plurality of batches into the database cluster concurrently, and there are cases where writing of the block data to be stored is incomplete. For this reason, the present embodiment provides the following solution to the above technical problems.
As shown in fig. 6, according to the above exemplary embodiment, before the step of dividing the block data to be stored into multiple batches of block sub-data, the blockchain storage method further includes at least steps S610 to S620, which are described in detail below:
in step S610, the block data to be stored is cached.
The block chain link point caches the block data to be stored, so that the cached block data to be stored can be called into the database cluster when the block data to be stored is not completely written into the database cluster, and the atomicity of the block data to be stored is ensured. For example, the block data to be stored may be cached in a pre-written log module of the blockchain node, i.e., WAL (Write-Ahead Logging).
In step S620, a second latest block height of the block data cached by the blockchain node is determined.
The second latest block height refers to the block sequence number corresponding to the block data to be stored after the block link point caches the block data to be stored. For example, if the block link point buffers the block data to be stored in the WAL system, the second latest block height also refers to the number of buffered blocks in the WAL system.
The blockchain node determines a second most recent block height of the blockdata cached by the blockchain node. Illustratively, the blockchain node may determine the number of cached blocks in the pre-write log module as the second most recent block height.
It should be noted that, considering the limitation of the buffer space, in order to avoid the upper limit of the buffer space from affecting the buffer of the block data to be stored subsequently, and further affecting the recovery of the block data incompletely written into the database cluster, the blockchain node may reserve the block data of the preset number of blocks in the buffer space. For example, if the buffer space is a pre-write log module, the blockchain node may reserve the blockdata of the predetermined number of blocks in the pre-write log module. For example, the preset number of blocks is 5, the block data of 5 blocks are sequentially cached in the pre-write log module, and then each time the block chain node caches the block data of one block to the pre-write log module, the block data corresponding to the first serial number in the WAL system is deleted, so that the redundancy of the cache space is avoided.
It can be seen that, in the blockchain storage method of the embodiment, before dividing the block data to be stored into multiple batches of block sub-data, the block data to be stored is cached, so that when the block data to be stored is not completely written into the database cluster, the cached block data to be stored can be fetched into the database cluster, and the atomicity of the block data to be stored is ensured.
Based on the above embodiments, it is determined whether a plurality of batches of block sub-data have been written to the database cluster concurrently. The present embodiment provides the following solution.
As shown in fig. 7, according to the above exemplary embodiment, after determining the first latest block height in the database cluster by any one of the plurality of database clients, the blockchain storage method further includes at least steps S710 to S720, which are described in detail below:
in step S710, it is determined whether the first latest block height is equal to the second latest block height.
The blockchain node determines whether the first latest block height is equal to the second latest block height, if not, step S720 is executed, and if so, it indicates that the plurality of database clients have completely written the multi-batch of block sub-data into the database cluster.
In step S720, the block data corresponding to the second latest block height is written into the database cluster.
The block data corresponding to the second latest block height refers to the block data which is latest cached by the block chain node.
And the block data which is cached latest by the block chain node is written into the database cluster when the block chain node judges that the height of the first latest block is not equal to the height of the second latest block.
It can be seen that, in the blockchain storage method of this embodiment, whether the blockdata to be stored is completely written into the database cluster is determined by judging whether the second latest blockdata and the first latest blockdata are equal, if not, the blockdata cached by the blockchain node is written into the database cluster, so that the cached blockdata to be stored can be retrieved into the database cluster when the blockdata to be stored is not completely written into the database cluster, and the atomicity of the blockdata to be stored is ensured.
Fig. 8 is a flow chart of step S720 in the embodiment shown in fig. 7 in an exemplary embodiment. As shown in fig. 8, according to the above exemplary embodiment, the process of writing the block data corresponding to the second latest block height into the database cluster may further include steps S810 to S820, which are described in detail as follows:
In step S810, a target block height is determined in the blockchain node that is greater than the first latest block height.
The target block height refers to the block height of the block cached by the blockchain node that is greater than the first latest block height. For example, if the block link point caches the block data to be stored in the pre-write log module, that is, the WAL system, the block height greater than the first latest block height in all the block data cached in the pre-write log module is the target block height.
Considering that the first latest block height is not equal to the second latest block height, there are cases where the block data to be stored is not written to the database cluster in its entirety or the block data to be stored is partially written to the database cluster. To achieve full writing of the block data to be stored to the database cluster, the block link point will determine a target block height in the blockchain node that is greater than the first latest block height.
In step S820, the block data corresponding to the target block height is written into the database cluster.
The block link point writes the block data corresponding to the target block height into the database cluster. Illustratively, the block link writes block data corresponding to a target block height greater than the first latest block height in the pre-write log module into the database cluster.
It can be seen that, in the blockchain storage method of this embodiment, when the first latest block height is not equal to the second latest block height, a target block height greater than the first latest block height is determined in the blockchain node, and the block data corresponding to the target block height is written into the database cluster, so that complete writing of the block data to be stored is realized, and atomicity of the block data to be stored is ensured.
As shown in fig. 9, according to the above exemplary embodiment, before the step of dividing the block data to be stored into multiple batches of block sub-data, the blockchain storage method further includes at least steps S910 to S920, which are described in detail below:
step S910 performs serialization processing on the block data to be stored to obtain serialized block data.
Serialization refers to converting block data to be stored into key-value mode data.
And the block chain node performs serialization processing on the block data to be stored to obtain serialized block data.
In step S920, the de-duplication process is performed on the serialized block data.
The same block data is operated when writing is caused in consideration that the same block data may exist in the block data to be stored. Therefore, the block chain node performs de-duplication processing on the serialized block data, and then performs multi-batch division processing on the block data to be stored after de-duplication.
It can be seen that, in the blockchain storage method of the embodiment, by performing serialization processing on the block data to be stored and performing deduplication processing on the serialized block data, the same block data is prevented from being operated when the same block data exists in the block data to be stored, and the writing efficiency of the block data is improved.
In order to clearly describe the above embodiments, the following describes them in full based on the specific flowchart in fig. 10. As shown in fig. 10, block means a Block to be stored, tx (0) to Tx (…) means transaction data transfer, block header means Block header data, RWSet (0) to RWSet (…) means read-write set data. The detailed flow is presented as follows:
specifically, the block link point performs serialization processing on each block data of the block to be stored, and caches the block data after serialization processing into a pre-write log module, namely a WAL system, further performs deduplication processing on the block data after serialization to obtain block data after deduplication, namely generating a new kvs in fig. 10, then sending the block data after deduplication to a database client connection pool, then performing data division processing on the block data to be stored in the database client connection pool to obtain multiple batches of block sub-data, distributing the multiple batches of block sub-data to multiple database clients, further enabling the multiple database clients to concurrently write the multiple batches of block sub-data into a database cluster, and finally updating the latest block height in the database cluster, namely the first latest block height, by any database client in the multiple database clients.
It should be noted that, the database client connection pool may divide the block data to be stored according to the included database client, that is, the sub-data amount of the block of each batch may be dynamically adjusted, and the batch amount may also be dynamically adjusted. For example, the database client connection pool includes 3 database clients, the block data to be stored includes 10 key-value data, the database client connection pool may divide the 10 key-value data into 3 batches according to the 3 database clients, each batch includes 3 key-value data, 4 key-value data and 3 key-value data, and at this time, the 3 key-value data is a batch of block sub-data. In addition, the database client connection pool can also divide 10 key-value data into 2 batches, and each batch respectively comprises 3 key-value data and 7 key-value data. The embodiments of the present application are not limited in this regard.
It should be further noted that, in the embodiment of the present application, on the basis of concurrently writing multiple batches of block sub-data into the database cluster by using multiple database clients, the downtime condition of the block chain node is perfected, and the details can be refer to fig. 11.
FIG. 11 is a flowchart illustrating a blockchain node downtime condition in a blockchain storage method in accordance with an exemplary embodiment of the present application. As shown in fig. 11, the blockchain storage method according to the embodiment of the present application further includes steps S1110 to S1130, which are described in detail below:
In step S1110, in the process of storing the block data to be stored in the database cluster by the block link node, if the block chain node is detected to be down, determining a third latest block height of the block data cached by the block chain node, and determining a fourth latest block height in the database cluster.
The downtime of the block chain node refers to the situation that the block chain node cannot store the block data to be stored to the database cluster due to the existence of a network and other reasons. It should be noted that, the downtime of the blockchain node may exist in any step in the flowchart of fig. 10, which is not limited in this embodiment.
The third latest block height refers to the block height of the latest block data cached by the blockchain node when the blockchain node is down. For example, if the block link point caches the block data to be stored in the pre-write log module, that is, in the WAL system, when the block link point is down, the block height corresponding to the block data stored most recently in the pre-write log module is the third most recent block height.
The fourth latest block height refers to a latest block height updated by any one of the plurality of database clients when the blockchain node is down. It should be noted that, the fourth latest block height may be the block height updated after writing the block sub-data of multiple batches into the database cluster, or may be the block height when the block sub-data of multiple batches is not written into the database cluster, that is, the block height in the database cluster determined when the previous block data is written into the database cluster.
In the process of storing the block data to be stored into the database cluster, the block chain node detects whether the block chain link point is down, if the down condition exists, the third latest block height of the block data cached by the block chain node is determined, and any database client in a plurality of database clients determines the fourth latest block height in the database cluster. For example, if there is a downtime, the blockchain node determines that the block height corresponding to the block data stored most recently in the pre-write log module is the third most recent block height.
In step S1120, it is determined whether the third latest block height is equal to the fourth latest block height.
The blockchain node determines whether the third latest block height is equal to the fourth latest block height, if not, step S1130 is performed, and if so, it indicates that the plurality of database clients have completely written the multi-batch of block sub-data into the database cluster.
In step S1130, the block data corresponding to the third latest block height is written into the database cluster.
The block data corresponding to the third latest block height is the block data which is latest cached by the block chain node when the block chain node is down.
And the block chain node writes the block data corresponding to the third latest block height into the database cluster when judging that the third latest block height is not equal to the fourth latest block height. For example, the blockchain node may determine in the pre-write log module that the blockheight is greater than the fourth most recent blockheight and write the blockdata into the database cluster.
It should be noted that, it is considered that when the blockchain node is down, the same blockdata may exist in the newly cached blockdata of the blockchain node, so that the write operation is repeated. Therefore, in order to avoid the above problem, before writing the block data corresponding to the third latest block height into the database cluster, the blockchain node may perform deduplication processing on the block data corresponding to the third latest block height, and write the deduplicated block data into the database cluster.
In order to clearly describe the above embodiments, the downtime of the blockchain node described in the above embodiments is described below based on the specific flowchart in fig. 12. As shown in fig. 12, the following is described in detail:
in the process of storing the block data to be stored into the database cluster, if the block chain node is detected to be down, the block chain node acquires the latest block height h0 from the database cluster, namely the fourth latest block height, acquires the latest block height h1 cached in the pre-written log module, namely the third latest block height, compares the latest block heights h0 and h1, if h0 is equal to h1, the data loss in the database cluster is avoided, if h0 is smaller than h1, the block height of the block with the block height larger than h0 is determined from all the block heights of the pre-written log module, the block data corresponding to the block height with the block height larger than h0 is subjected to de-duplication processing, the de-duplicated block data is written into the database cluster in parallel, the latest block height of the database cluster is updated by any one database client of a plurality of database clients, and finally, the operation of other modules is started.
It can be seen that, in the blockchain storage method of this embodiment, in the process that the blockchain link stores the blockdata to be stored into the database cluster, if the blockchain node is detected to be down, determining a third latest blockheight of the blockdata cached by the blockchain node, and determining a fourth latest blockheight in the database cluster, further determining whether the third latest blockheight is equal to the fourth latest blockheight, and if the third latest blockheight is not equal to the fourth latest blockheight, writing the blockdata corresponding to the third latest blockheight into the database cluster. Based on the fact that a plurality of database clients are used for writing the block sub-data of a plurality of batches into the database cluster, the downtime condition of the block chain node is perfected, and the problem of data loss caused by downtime of the block chain node is avoided.
FIG. 13 is a block diagram of a blockchain storage device shown in an exemplary embodiment of the application. The blockchain storage may be used in the implementation environments shown in fig. 2 or 3. The blockchain storage device may also be suitable for other exemplary implementation environments, and the present embodiment is not limited to the implementation environment in which the blockchain storage device is suitable.
As shown in fig. 13, the exemplary blockchain storage 1300 includes a partitioning module 1310, a distributing module 1320, and a writing module 1330, specifically:
the dividing module 1310 is configured to divide the block data to be stored into a plurality of blocks of sub-data. The block data to be stored refers to data contained in the block to be stored. For example, the block data to be stored may include block data in a block body and block data in a block header. The block data in the block main body comprises input data, and the block data in the block header comprises input information characteristic data, version data, timestamp data, difficulty data and the like. It should be further noted that, for convenience of storage, the block data to be stored generally exists in a key-value pair manner.
The block sub-data refers to part of the block data contained in the block to be stored.
It should be noted that, in order to improve the concurrent writing efficiency, the blockchain node may divide the block data to be stored according to the attribute of the database client. For example, if the blockchain node includes 3 database clients, the blockchain node may divide the 10 key-value data into 3 batches according to the 3 database clients, and each batch includes 3 key-value data, 4 key-value data, and 3 key-value data, where the 3 key-value data is a batch of blocksub-data. Of course, the blockchain node may also divide the 10 key-value data into 2 batches, each batch including 3 key-value data and 7 key-value data, respectively. The embodiments of the present application are not limited in this regard.
A distribution module 1320 is configured to distribute the plurality of batches of tile sub-data to a plurality of database clients. In order to facilitate distributing the block sub-data of multiple batches to multiple database clients, the blockchain node may further include a database client connection pool, where the database client connection pool includes a plurality of database clients. The database client connection pool is used for distributing block data to be stored to a plurality of database clients. The block link point sends the block data to be stored to a database client connecting pool, and the database client connecting pool distributes block sub-data according to the writing capability of each database client or the number of the database clients included by the database client connecting pool.
The writing module 1330 is configured to write the received block sub-data to the database cluster concurrently by the plurality of database clients. The database cluster refers to a storage module for storing block data. The database cluster includes at least one database. The database cluster may be a storage module included in the block node, or may be a remote storage module, i.e., a remote storage server.
In order to facilitate the plurality of database clients in the blockchain node to write the received blockchain sub-data into the database cluster concurrently, the blockchain node of this embodiment further includes a database scheduling module, where the database scheduling module is configured to write the blockchain sub-data received by the plurality of database clients into the database clients concurrently. It should be noted that, the database scheduling module may implement the concurrent writing function independently, or may exist in multiple database clients, so as to implement the concurrent writing function.
In the exemplary blockchain storage device, the writing efficiency of the block data to be stored is improved by dividing the block data to be stored into a plurality of batches of block sub-data and writing the block sub-data into the database cluster from different database clients.
Based on the above exemplary embodiment, after the writing module 1330, the blockchain storage 1300 further includes:
the first latest block height determination module is configured to determine a first latest block height in the database cluster by any one of the plurality of database clients. The first latest block height may be understood as a sequence number of a block corresponding to the block data to be stored in the database cluster, or may be understood as the number of blocks in the database cluster after the block data to be stored is written into the database cluster.
In the exemplary blockchain storage device, the blockchain node determines the height of the first latest block in the database cluster through any database client in the plurality of database clients, so that the atomicity of writing of the block data to be stored is ensured.
Based on the above exemplary embodiment, before the partitioning module 1310, the blockchain storage device 1300 further includes:
And the buffer module is configured to buffer the block data to be stored. For example, the block data to be stored may be cached in a pre-written log module of the blockchain node, i.e., WAL (Write-Ahead Logging).
The second latest block height determining module is configured to determine a second latest block height of the block data cached by the blockchain node. The second latest block height refers to a block sequence number corresponding to the block data to be stored after the block link point caches the block data to be stored. For example, if the block link point buffers the block data to be stored in the WAL system, the second latest block height also refers to the number of buffered blocks in the WAL system.
It should be noted that, considering the limitation of the buffer space, in order to avoid the upper limit of the buffer space from affecting the buffer of the block data to be stored subsequently, and further affecting the recovery of the block data incompletely written into the database cluster, the blockchain node may reserve the block data of the preset number of blocks in the buffer space. For example, if the buffer space is a pre-write log module, the blockchain node may reserve the blockdata of the predetermined number of blocks in the pre-write log module. For example, the preset number of blocks is 5, the block data of 5 blocks are sequentially cached in the pre-write log module, and then each time the block chain node caches the block data of one block to the pre-write log module, the block data corresponding to the first serial number in the WAL system is deleted, so that the redundancy of the cache space is avoided.
In the exemplary blockchain storage device, before the blockchain node divides the blockdata to be stored into the blocksub data of multiple batches, the blockdata to be stored is subjected to buffer processing, so that the buffered blockdata to be stored can be called into the database cluster when the blockdata to be stored is not completely written into the database cluster, and the atomicity of the blockdata to be stored is ensured.
Based on the above exemplary embodiment, after the writing module 1330, the blockchain storage 1300 further includes:
the first comparison module is configured to write the block data corresponding to the second latest block height into the database cluster if the first latest block height is not equal to the second latest block height. The block data corresponding to the second latest block height refers to the block data which is latest cached by the block chain node.
In the exemplary blockchain storage device, the blockchain node determines whether the block data to be stored is completely written into the database cluster by judging whether second latest block data cached before dividing the block data to be stored into multiple batches of block sub-data and first latest block data after the received block sub-data are written into the database cluster by multiple database clients in parallel, if not, the latest cached block data of the blockchain node is written into the database cluster, so that the cached block data to be stored can be called into the database cluster when the block data to be stored is not completely written into the database cluster, and the atomicity of the block data to be stored is ensured.
In accordance with the above exemplary embodiment, the first comparison module further includes:
the target block height determination module is configured to determine a target block height in the blockchain node that is greater than the first latest block height. The target block height refers to a block height of a block cached by the blockchain node that is greater than a first latest block height. For example, if the block link point caches the block data to be stored in the pre-write log module, that is, the WAL system, the block height greater than the first latest block height in all the block data cached in the pre-write log module is the target block height.
And the target block height writing module is configured to write block data corresponding to the target block height into the database cluster.
In the exemplary blockchain storage device, the blockchain node determines a target block height greater than the first latest block height in the blockchain node under the condition that the first latest block height is not equal to the second latest block height, and writes the block data corresponding to the target block height into the database cluster, so that the complete writing of the block data to be stored is realized, and the atomicity of the block data to be stored is ensured.
In accordance with the above exemplary embodiments, the blockchain storage 1300 further includes:
and the third latest block height and fourth latest block height determining module is configured to determine the third latest block height of the block data cached by the block chain node and determine the fourth latest block height in the database cluster if the block chain node is detected to be down in the process of storing the block data to be stored in the database cluster by the block chain node. The downtime of the blockchain node refers to a situation that the blockchain node cannot store the blockdata to be stored to the database cluster due to the existence of a network and other reasons. It should be noted that, the downtime of the blockchain node may exist in any step in the flowchart of fig. 10, which is not limited in this embodiment.
The third latest block height refers to the block height of the latest block data cached by the blockchain node when the blockchain node is down. For example, if the block link point caches the block data to be stored in the pre-write log module, that is, in the WAL system, when the block link point is down, the block height corresponding to the block data stored most recently in the pre-write log module is the third most recent block height.
The fourth latest block height refers to a latest block height updated by any one of the plurality of database clients when the blockchain node is down. It should be noted that, the fourth latest block height may be the block height updated after writing the block sub-data of multiple batches into the database cluster, or may be the block height when the block sub-data of multiple batches is not written into the database cluster, that is, the block height in the database cluster determined when the previous block data is written into the database cluster.
And the second comparison module is configured to write the block data corresponding to the third latest block height into the database cluster if the third latest block height is not equal to the fourth latest block height.
In the exemplary blockchain storage device, in the process that the blockchain node stores the blockdata to be stored into the database cluster through the blockchain link point, if the blockchain node is detected to be down, determining a third latest blockheight of the blockdata cached by the blockchain node, determining a fourth latest blockheight in the database cluster, further judging whether the third latest blockheight is equal to the fourth latest blockheight, and if the third latest blockheight is not equal to the fourth latest blockheight, writing the blockdata corresponding to the third latest blockheight into the database cluster. Based on the fact that a plurality of database clients are used for writing the block sub-data of a plurality of batches into the database cluster, the downtime condition of the block chain node is perfected, and the data loss caused by the downtime of the block chain node is avoided.
Based on the above exemplary embodiment, before the partitioning module 1310, the blockchain storage device 1300 further includes:
and the serialization module is configured to perform serialization processing on the block data to be stored to obtain serialized block data. The serialization refers to converting the block data to be stored into key-value data.
And the de-duplication module is configured to perform de-duplication processing on the serialized block data.
In the exemplary blockchain storage device, the blockchain node performs serialization processing on the block data to be stored, and performs deduplication processing on the serialized block data, so that the same block data is prevented from being operated when writing due to the fact that the same block data exists in the block data to be stored.
It should be noted that, the blockchain storage device provided in the foregoing embodiment and the blockchain storage method provided in the foregoing embodiment belong to the same concept, and the specific manner in which each module and unit perform the operation has been described in detail in the method embodiment, which is not repeated herein. In practical applications, the blockchain storage device provided in the foregoing embodiments may allocate the functions to different functional modules according to needs, that is, the internal structure of the device is divided into different functional modules to perform all or part of the functions described above, which is not limited herein.
The embodiment of the application also provides electronic equipment, which comprises: one or more processors; and a storage device for storing one or more programs which, when executed by the one or more processors, cause the electronic device to implement the blockchain storage method provided in the various embodiments described above.
Fig. 14 shows a schematic diagram of a computer system suitable for use in implementing an embodiment of the application. It should be noted that, the computer system 1400 of the electronic device shown in fig. 14 is only an example, and should not impose any limitation on the functions and the application scope of the embodiments of the present application.
As shown in fig. 14, the computer system 1400 includes a central processing unit (Central Processing Unit, CPU) 1401, which can perform various appropriate actions and processes, such as performing the methods described in the above embodiments, according to a program stored in a Read-Only Memory (ROM) 1402 or a program loaded from a storage section 1408 into a random access Memory (Random Access Memory, RAM) 1403. In the RAM 1403, various programs and data required for system operation are also stored. The CPU 1401, ROM 1402, and RAM 1403 are connected to each other through a bus 1404. An Input/Output (I/O) interface 1405 is also connected to bus 1404.
The following components are connected to the I/O interface 1405: an input section 1406 including a keyboard, a mouse, and the like; an output portion 1407 including a Cathode Ray Tube (CRT), a liquid crystal display (Liquid Crystal Display, LCD), and a speaker; a storage portion 1408 including a hard disk or the like; and a communication section 1409 including a network interface card such as a LAN (Local Area Network ) card, a modem, or the like. The communication section 1409 performs communication processing via a network such as the internet. The drive 1410 is also connected to the I/O interface 1405 as needed. A removable medium 1411 such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, or the like is installed as needed on the drive 1410 so that a computer program read therefrom is installed into the storage portion 1408 as needed.
In particular, according to embodiments of the present application, the processes described above with reference to flowcharts may be implemented as computer software programs. For example, embodiments of the present application include a computer program product comprising a computer program embodied on a computer readable medium, the computer program comprising a computer program for performing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network via the communication portion 1409 and/or installed from the removable medium 1411. When executed by a Central Processing Unit (CPU) 1401, performs the various functions defined in the system of the present application.
It should be noted that, the computer readable medium shown in the embodiments of the present application may be a computer readable signal medium or a computer readable storage medium, or any combination of the two. The computer readable storage medium may be, for example, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of the computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-Only Memory (ROM), an erasable programmable read-Only Memory (Erasable Programmable Read Only Memory, EPROM), flash Memory, an optical fiber, a portable compact disc read-Only Memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the present application, a computer-readable signal medium may comprise a data signal propagated in baseband or as part of a carrier wave, with a computer-readable computer program embodied therein. Such a propagated data signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination of the foregoing. A computer readable signal medium may also be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. A computer program embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to: wireless, wired, etc., or any suitable combination of the foregoing.
The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present application. Where each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams or flowchart illustration, and combinations of blocks in the block diagrams or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.
The units involved in the embodiments of the present application may be implemented by software, or may be implemented by hardware, and the described units may also be provided in a processor. Wherein the names of the units do not constitute a limitation of the units themselves in some cases.
Another aspect of the application also provides a computer readable storage medium having stored thereon a computer program which when executed by a processor implements a blockchain storage method as described above. The computer-readable storage medium may be included in the electronic device described in the above embodiment or may exist alone without being incorporated in the electronic device.
Another aspect of the application also provides a computer program product or computer program comprising computer instructions stored in a computer readable storage medium. The processor of the computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device performs the blockchain storage method provided in the above embodiments.
The foregoing is merely illustrative of the preferred embodiments of the present application and is not intended to limit the embodiments of the present application, and those skilled in the art can easily make corresponding variations or modifications according to the main concept and spirit of the present application, so that the protection scope of the present application shall be defined by the claims.

Claims (10)

1. A blockchain storage method, the method being applied to a blockchain node having a plurality of database clients disposed therein, the method comprising:
dividing the block data to be stored into a plurality of batches of block sub-data;
distributing the block sub-data of the plurality of batches to the plurality of database clients;
and the plurality of database clients write the received block sub-data into the database cluster in parallel.
2. The method of claim 1, wherein after the step of concurrently writing the received chunk sub-data into a database cluster by the plurality of database clients, the method further comprises:
a first latest block height in the database cluster is determined by any one of the plurality of database clients.
3. The method of claim 2, wherein prior to the step of dividing the block data to be stored into a plurality of batches of block sub-data, the method further comprises:
caching the block data to be stored;
and determining a second latest block height of the block data cached by the block chain node.
4. A method according to claim 3, wherein after the step of determining, by any one of the plurality of database clients, a first latest block height in the database cluster, the method further comprises:
and if the height of the first latest block is not equal to the height of the second latest block, writing the block data corresponding to the height of the second latest block into the database cluster.
5. The method of claim 4, wherein the step of writing the block data corresponding to the second most recent block height into the database cluster comprises:
determining a target block height in the blockchain node that is greater than the first latest block height;
and writing the block data corresponding to the target block height into the database cluster.
6. The method of any of claims 1-5, wherein the blockchain storage method further comprises:
in the process of storing the block data to be stored into the database cluster by the block chain link point, if the block chain node is detected to be down, determining a third latest block height of the block data cached by the block chain node, and determining a fourth latest block height in the database cluster;
And if the third latest block height is not equal to the fourth latest block height, writing the block data corresponding to the third latest block height into the database cluster.
7. The method according to any one of claims 1-5, wherein prior to the step of dividing the block data to be stored into a plurality of batches of block sub-data, the method further comprises:
carrying out serialization processing on the block data to be stored to obtain serialized block data;
and performing de-duplication processing on the serialized block data.
8. A blockchain storage device, the blockchain storage device comprising:
the dividing module is configured to divide the block data to be stored into a plurality of batches of block sub-data;
a distribution module configured to distribute the plurality of batches of block sub-data into the plurality of database clients;
and the writing module is configured to write the received block sub-data into the database cluster by the plurality of database clients.
9. An electronic device, comprising:
a memory storing computer readable instructions;
a processor reading computer readable instructions stored in a memory to perform the method of any one of claims 1-7.
10. A computer readable storage medium having stored thereon computer readable instructions which, when executed by a processor of a computer, cause the computer to perform the method of any of claims 1-7.
CN202210148917.0A 2022-02-17 2022-02-17 Block chain storage method, device, electronic equipment, storage medium and program product Pending CN116662440A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202210148917.0A CN116662440A (en) 2022-02-17 2022-02-17 Block chain storage method, device, electronic equipment, storage medium and program product

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202210148917.0A CN116662440A (en) 2022-02-17 2022-02-17 Block chain storage method, device, electronic equipment, storage medium and program product

Publications (1)

Publication Number Publication Date
CN116662440A true CN116662440A (en) 2023-08-29

Family

ID=87708459

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202210148917.0A Pending CN116662440A (en) 2022-02-17 2022-02-17 Block chain storage method, device, electronic equipment, storage medium and program product

Country Status (1)

Country Link
CN (1) CN116662440A (en)

Similar Documents

Publication Publication Date Title
US10678597B2 (en) Event-driven blockchain workflow processing
US20060123024A1 (en) System for persistent caching of LDAP metadata in a cluster LDAP server topology
US7693882B2 (en) Replicating data across the nodes in a cluster environment
US20200014750A1 (en) Hosted file sync with stateless sync nodes
US9589153B2 (en) Securing integrity and consistency of a cloud storage service with efficient client operations
CN113657900B (en) Cross-chain transaction verification method and system and cross-chain transaction system
CN108616574B (en) Management data storage method, device and storage medium
US20230052935A1 (en) Asynchronous accounting method and apparatus for blockchain, medium and electronic device
CN109783151B (en) Method and device for rule change
CN106713391A (en) Session information sharing method and sharing system
CN111338834A (en) Data storage method and device
CN110795495A (en) Data processing method and device, electronic equipment and computer readable medium
CN111951112A (en) Intelligent contract execution method based on block chain, terminal equipment and storage medium
CN111681011A (en) Data processing method, block chain system, computer system and medium
CN112905676A (en) Data file importing method and device
CN116662440A (en) Block chain storage method, device, electronic equipment, storage medium and program product
CN113076175B (en) Memory sharing method and device for virtual machine
US11157454B2 (en) Event-based synchronization in a file sharing environment
US11176013B2 (en) Method to efficiently and reliably process ordered user account events in a cluster
CN112799849A (en) Data processing method, device, equipment and storage medium
CN111865576A (en) Method and device for synchronizing URL classification data
US20230101740A1 (en) Data distribution in data analysis systems
CN114610740B (en) Data version management method and device of medical data platform
CN115426251B (en) Disaster recovery method, device and medium of cloud host
CN115408360A (en) Method, device, equipment and computer readable medium for storing data

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