A blockchain processing method, apparatus, device storage medium and program product

Abstract

This application provides a blockchain processing method, apparatus, device storage medium, and program product, relating to the field of communication technology. The method includes: upon receiving a write notification for a first block, sending a first request to a second node; receiving an access token sent by the second node in response to the first request; sending a second request to the second node; receiving a response message returned by the second node in response to the second request; obtaining block body metadata of the first block based on the response message; and storing the block body metadata locally. The blockchain processing method of this application, by storing the block header and block body separately and storing the block body data of multiple blocks from at least one node on the same storage node, reduces the overall storage overhead and node storage overhead of the blockchain system, overcoming the bottlenecks limiting the overall system ledger, transaction scale, and blockchain node storage capacity.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to a blockchain processing method, apparatus, device storage medium, and program product. Background Technology

[0002] Blockchain is a new type of information processing and storage technology that adopts a decentralized network structure for distributed ledger management and maintenance. It uses a consensus mechanism to ensure the fairness and immutability of ledger data, supports the neutral execution of contracts (code recognized by multiple parties), and solves problems such as lack of transparency, insufficient trust, and poor collaboration among partners.

[0003] However, in blockchain systems, the distributed ledger method, where each node stores its own data, ensures the temporal order and information consistency of the data through a chain-like structure of the ledger data combined with cryptographic algorithms. Furthermore, the code (smart contracts) signed and approved by relevant nodes runs in a secure environment, guaranteeing the neutrality and trustworthiness of the information processing process. Therefore, blockchain requires significant redundancy and cross-validation processes in storage, communication, and computation, leading to increased resource consumption and reduced processing performance. Summary of the Invention

[0004] The purpose of this application is to provide a blockchain processing method, apparatus, device storage medium, and program product to avoid the problems of increased resource consumption and reduced processing performance caused by the large amount of redundant processing and cross-validation required by blockchain in storage, communication, and computing.

[0005] To achieve the above objectives, embodiments of this application provide a blockchain processing method, executed by a first node, comprising:

[0006] Upon receiving a write notification for the first block, a first request is sent to the second node; wherein the second node includes one or more storage media, and the first request is used to request storage media allocation;

[0007] Receive the access token sent by the second node in response to the first request;

[0008] Send a second request to the second node. The second request carries the access token and the block object to be stored in the first block. The second request is used to request that the block object be stored in the allocated storage medium.

[0009] Receive the response message returned by the second node in response to the second request;

[0010] The block body metadata of the first block is obtained based on the response message, and the block body metadata is stored locally.

[0011] Furthermore, the block body metadata includes:

[0012] The hash value of the block object;

[0013] The list of access addresses for the block object;

[0014] Furthermore, the block body metadata also includes:

[0015] The encryption / decryption key identifier of the block object;

[0016] The encryption / decryption algorithm identifier of the block object.

[0017] Furthermore, the method also includes:

[0018] Upon receiving a read notification for the first block, obtain the block body metadata of the first block stored locally;

[0019] A third request is sent to the second node based on the block body metadata. The third request is used to request to read the block object of the first block.

[0020] Receive the block object sent by the second node in response to the third request.

[0021] Furthermore, after receiving the block object sent by the second node in response to the third request, the method further includes:

[0022] The integrity of the block object is verified based on the block body metadata.

[0023] Further, obtaining the block body metadata of the first block based on the response message includes:

[0024] If the first block is located on the target blockchain, the block body metadata of the first block is updated based on the list of access addresses of the block object in the response message.

[0025] Furthermore, before sending the first request to the second node, the process also includes:

[0026] Receive first configuration information sent by the third node, the first configuration information including information for instructing the second node, and relevant information used to request storage media;

[0027] The second node and the first request are determined based on the first configuration information.

[0028] Furthermore, the read notification is triggered by a blockchain migration.

[0029] Furthermore, the write notification is triggered by a blockchain migration;

[0030] After receiving the block object sent by the second node, the method further includes:

[0031] Based on the blockchain migration goals, determine the updated second node;

[0032] Send the first request to the updated second node.

[0033] Furthermore, the first request carries:

[0034] The chain identifier of the block;

[0035] The channel identifier of the block;

[0036] Block height;

[0037] Block body hash value.

[0038] Furthermore, the third request carries:

[0039] The chain identifier of the block;

[0040] The channel identifier of the block;

[0041] Block height;

[0042] Block body hash value;

[0043] List of access addresses for the block.

[0044] To achieve the above objectives, embodiments of this application provide a blockchain processing method executed by a second node, the second node comprising one or more storage media, the method comprising:

[0045] Receive the first request sent by the first node;

[0046] According to the first request, a storage medium is allocated to the first block, and an access token corresponding to the allocated storage medium is sent to the first node;

[0047] Receive a second request sent by the first node, the second request carrying the access token and the block object to be stored in the first block;

[0048] The block object is stored in the allocated storage medium according to the second request, and a response message is returned.

[0049] Further, the step of allocating storage medium for the first block according to the first request includes:

[0050] Based on the information carried in the first request, query whether the storage medium has already stored the block object of the first block;

[0051] If the query results indicate that the storage medium does not store the block object of the first block, determine the allocated storage medium and access token.

[0052] Further, the step of storing the block object in the allocated storage medium according to the second request and returning a response message includes:

[0053] The block object is fragmented based on the properties of the storage medium;

[0054] Based on the access token, each fragment is uploaded to the corresponding storage medium for storage;

[0055] A response message containing a list of access addresses for the block object is generated based on the storage location of each fragment;

[0056] The response message is sent to the first node.

[0057] Furthermore, after uploading each fragment to the corresponding storage medium for storage based on the access token, the process further includes:

[0058] The block object is cached.

[0059] Furthermore, the method also includes:

[0060] Receive a third request sent by the first node, the third request being used to request to read the block object of the first block;

[0061] The block object is sent according to the third request.

[0062] Further, sending the block object according to the third request includes:

[0063] Based on the third request, query whether the block object should be cached;

[0064] If the block object is cached, then the block object is sent directly;

[0065] If the block object is not cached, then based on the access address list of the block object, each fragment is read from the storage medium, and the fragments are concatenated to obtain and send the block object.

[0066] Furthermore, before receiving the first request sent by the first node, it also includes:

[0067] Receive the second configuration information sent by the third node;

[0068] Configure the one or more storage media according to the second configuration information.

[0069] To achieve the above objectives, embodiments of this application provide a blockchain processing method, executed by a third node, comprising:

[0070] If a first condition is met, a write notification is sent to the first node; wherein the first condition includes at least one of the following:

[0071] Blockchain or blockchain channel created successfully;

[0072] The first node joins the blockchain or blockchain channel.

[0073] Furthermore, the method also includes:

[0074] If the first condition is met...

[0075] Send first configuration information to the first node, the first configuration information including information for instructing the second node, and relevant information used in requesting storage media; and,

[0076] Send second configuration information to the second node, the second configuration information being used to configure one or more storage media included in the second node.

[0077] Furthermore, the method also includes:

[0078] Send a read notification to the second node.

[0079] Furthermore, the method also includes:

[0080] In the event of a blockchain migration, the write notification and the read notification are generated.

[0081] To achieve the above objectives, embodiments of this application provide a blockchain processing apparatus applied to a first node, comprising:

[0082] A first sending module is configured to send a first request to a second node upon receiving a write notification for a first block; wherein the second node includes one or more storage media, and the first request is used to request storage media allocation;

[0083] The first receiving module is used to receive the access token sent by the second node in response to the first request;

[0084] The second sending module is used to send a second request to the second node. The second request carries the access token and the block object to be stored in the first block. The second request is used to request that the block object be stored in the allocated storage medium.

[0085] The second receiving module is used to receive the response message returned by the second node in response to the second request;

[0086] The first processing module is configured to obtain the block body metadata of the first block according to the response message, and store the block body metadata locally.

[0087] To achieve the above objectives, embodiments of this application provide a blockchain processing apparatus applied to a second node, the second node including one or more storage media, comprising:

[0088] The third receiving module is used to receive the first request sent by the first node;

[0089] The second processing module is used to allocate storage medium for the first block according to the first request, and send an access token corresponding to the allocated storage medium to the first node.

[0090] The fourth receiving module is used to receive a second request sent by the first node, wherein the second request carries the access token and the block object to be stored in the first block;

[0091] The third sending module is used to store the block object in the allocated storage medium according to the second request and return a response message.

[0092] To achieve the above objectives, embodiments of this application provide a blockchain processing apparatus applied to a third node, comprising:

[0093] The fourth sending module is configured to send a write notification to the first node when a first condition is met; wherein the first condition includes at least one of the following:

[0094] Blockchain or blockchain channel created successfully;

[0095] The first node joins the blockchain or blockchain channel.

[0096] To achieve the above objectives, embodiments of this application provide a blockchain processing device, including: a transceiver, a processor, a memory, and a program or instructions stored in the memory and executable on the processor; when the processor executes the program or instructions, it implements the blockchain processing method described above.

[0097] To achieve the above objectives, embodiments of this application provide a readable storage medium storing a program or instructions that, when executed by a processor, implement the steps in the blockchain processing method described above.

[0098] To achieve the above objectives, embodiments of this application provide a computer program product, including computer instructions, which, when executed by a processor, implement the steps of the blockchain processing method described above.

[0099] The beneficial effects of the above technical solution in this application are as follows:

[0100] The blockchain processing method of this application embodiment, upon receiving a write notification for a first block, sends a first request to a second node, causing the second node to allocate storage medium for the first block and return an access token corresponding to the allocated storage medium to the first node; the first node sends the access token and the block object to be stored for the first block to the second node, causing the second node to store the block object to be stored; the first node obtains and stores the block body metadata of the first block based on the response message returned by the second node. This blockchain processing method of this application embodiment, by storing the block header and block body separately and storing the block body data of multiple blocks from at least one node in the same storage node, reduces the overall storage overhead and node storage overhead of the blockchain system, overcoming the bottlenecks limiting the overall system ledger, transaction scale, and blockchain node storage capacity. Attached Figure Description

[0101] Figure 1 A schematic diagram illustrating the ledger principle of blockchain in existing technologies;

[0102] Figure 2 This is a schematic diagram of the ledger data structure of a service node in the existing technology;

[0103] Figure 3 This is a schematic diagram illustrating the ledger storage method of the blockchain system according to an embodiment of this application;

[0104] Figure 4 This is a schematic diagram of the functional components of the storage management submodule of the second node in an embodiment of this application;

[0105] Figure 5 This is one of the flowcharts illustrating the blockchain processing method according to an embodiment of this application;

[0106] Figure 6 This is a schematic diagram of the ledger data structure of the service node in an embodiment of this application;

[0107] Figure 7 This is a schematic diagram illustrating the process of storing the first block into the second node according to an embodiment of this application;

[0108] Figure 8 This is a schematic diagram illustrating the process of the first block reading a block object from the second node in an embodiment of this application.

[0109] Figure 9 This is a second schematic flowchart of the blockchain processing method according to an embodiment of this application;

[0110] Figure 10 This is the third flowchart illustrating the blockchain processing method according to an embodiment of this application;

[0111] Figure 11 This is one of the schematic diagrams of the module structure of the blockchain processing device according to an embodiment of this application;

[0112] Figure 12 This is a second schematic diagram of the module structure of the blockchain processing device according to an embodiment of this application;

[0113] Figure 13 This is the third schematic diagram of the module structure of the blockchain processing device according to an embodiment of this application;

[0114] Figure 14 This is a schematic diagram of the structure of a blockchain processing device according to an embodiment of this application. Detailed Implementation

[0115] To make the technical problems, technical solutions and advantages of this application clearer, a detailed description will be provided below in conjunction with the accompanying drawings and specific embodiments.

[0116] It should be understood that the phrase "one embodiment" or "an embodiment" throughout the specification means that a specific feature, structure, or characteristic related to the embodiment is included in at least one embodiment of this application. Therefore, "in one embodiment" or "in an embodiment" appearing throughout the specification does not necessarily refer to the same embodiment. Furthermore, these specific features, structures, or characteristics can be combined in any suitable manner in one or more embodiments.

[0117] In the various embodiments of this application, it should be understood that the sequence number of each process described below does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0118] In addition, the terms "system" and "network" are often used interchangeably in this article.

[0119] In the embodiments provided in this application, it should be understood that "B corresponding to A" means that B is associated with A, and B can be determined based on A. However, it should also be understood that determining B based on A does not mean determining B solely based on A; B can also be determined based on A and / or other information.

[0120] For ease of understanding, the following describes some aspects of the embodiments of this application:

[0121] In existing technologies, such as Figure 1As shown: In traditional centralized ledger systems (including databases, file systems, etc.), typically one node / program is responsible for accessing specific data to ensure data consistency and transaction atomicity. Even in distributed processing systems (such as distributed databases, distributed file systems, etc.), multiple nodes may work in a master-slave or load-sharing manner to process a set of data. However, for the processing of a specific piece of data, an algorithm will define a specific data operation node. Therefore, traditional data processing methods employ centralized ledgers. For distributed ledgers represented by blockchain, blockchain nodes representing different organizations and roles maintain their own ledgers, autonomously reading and writing their own ledger data, relying on specified accounting rules (consensus mechanisms) and algorithms to maintain eventual consistency of the distributed ledger data across all nodes. Clearly, due to the inherent distrust of ledger data from nodes that do not belong to them, each node needs to verify each transaction in each block using its own rules and methods, and then record what it considers legitimate and reasonable accounting data in its own ledger based on its own verification results.

[0122] Each node's ledger (i.e., locally stored blocks linked together by generation time and block sequence number to form a chain, where: blocks are real, and the chain is logical), typically has the following data structure: Figure 2 As shown:

[0123] A block, as the basic structural unit of a blockchain, consists of two parts: a block header containing basic information and a block body containing transaction data. Taking Bitcoin as an example, the block is composed of:

[0124] (1) Block header, used for: connecting the preceding blocks, indexing the hash value of the parent block; describing the timestamp and nonce of this block (a random number that records the answer to the mathematical problem related to decrypting the block and is used to prove the legality of this block); Merkle root data that can summarize and quickly summarize and verify all transaction data in the block, as well as other data, such as: version number; the size of the block header is fixed, for example: the size of the public chain Bitcoin block body is 80 bytes, and the unserialized block header of the consortium chain Fabric is 72 bytes;

[0125] (2) Block body: Used for storage overhead. The transaction information recorded in the block body is the task data carried by the block, specifically including the private keys of the two parties to the transaction, the amount of the transaction, the digital signature of the electronic currency, etc. The block body size is usually fixed. For example, at the beginning of its creation, the block body size of classic Bitcoin was 1M bytes, and the default block body size of the consortium chain Fabric is 2MB. This size can be changed by system forks or forced upgrades.

[0126] The blockchain processing method in this application embodiment needs to be implemented through a combination of software and hardware, specifically:

[0127] If the service-providing nodes (physical computers, virtual machines, or containers) of the entire blockchain system are located in multiple cloud data centers but these data centers have internal direct links; all service-providing nodes, regardless of whether they are physically located in the same data center, can be connected through networking technologies (such as Virtual Private Network (VPN), Virtual Local Area Network (VLAN / VxLAN), leased lines, Internet, etc.), and the communication latency can meet the basic requirements of business access.

[0128] The storage media of the second node can be composed of various heterogeneous methods such as raw disks, disk arrays, storage area networks (SAN), network attached storage (NAS), block storage, file storage, and object storage. After adaptation, it can provide a unified access interface, be linearly scalable, deployed in multiple centers and geographically, and can be stored in multiple replicas. The content stored on the storage media can be backed up and restored through the storage management submodule to improve the high availability of the entire storage module.

[0129] In consortium blockchain scenarios, all modules, nodes, and software services can obtain an identifier and a pair of public and private keys for functions such as node identity verification, access authorization, session key negotiation, and content encryption.

[0130] This application optimizes the ledger storage method of the blockchain system, and the specific modules and connection methods are as follows: Figure 3 As shown,

[0131] This application adds a storage module to the blockchain, which includes two new components: a storage management submodule SM and a storage medium MS. For the storage module S, in accordance with security requirements, it can be set up separately for a specific chain / channel, or the same storage module S can be set up for multiple chains and multiple channels. Simultaneously, a chain management module M is added (for consortium blockchains, its functionality can be extended within a Blockchain as a Service (BaaS) platform; for public blockchains, it can be an extension of the management console functionality of a mining pool). Furthermore, the block reading module of the blockchain node P undergoes interface reloading and corresponding storage access functionality is added.

[0132] In this embodiment of the application, in the scenario of a consortium blockchain:

[0133] (1) Storage module S includes two types of components: storage medium and storage management submodule;

[0134] A. Storage Media: A linearly scalable cluster of storage media consisting of various forms such as raw disks, disk arrays, SAN / NAS, block storage, file storage, and object storage, using homogeneous or heterogeneous technologies; after functional adaptation, it provides a unified data access interface to the outside world; based on the characteristics of block storage, under the control of the storage management submodule, the storage media can work in a "write once then read only" mode.

[0135] B. Storage Management Submodule: Responsible for managing the storage medium MS and adapting the block access interface between the storage medium and blockchain nodes;

[0136] (2) Chain Management Module (optional) is only for consortium blockchain scenarios. It is used to configure and manage data such as chains, channels, and users, centrally schedule computing, network, and storage resources, and uniformly monitor and maintain the entire chain service.

[0137] Specifically, in a consortium blockchain scenario, the functional components of the storage management submodule SM of the second node are configured as follows: Figure 4 As shown, it includes:

[0138] Block access interface: responsible for interacting with blockchain nodes, providing blockchain nodes with the specific medium address, access entry point, and access credentials for reading and writing content in a stateless interface manner;

[0139] Access Control File (ACF): Based on the set security policy, it performs access control, access logging, and analysis and blocking of abnormal access behavior requests to access the block access interface;

[0140] Block storage metadata database: responsible for maintaining the mapping relationship between "chain identifier, channel identifier, block information (including key content such as block depth, block body hash value, etc.), the location of the block body ID (logical address) on the storage medium and the block read address (physical address)";

[0141] Caching function: Used to cache block objects that have been saved on the storage medium, avoiding the need to access the storage medium for each block read, thereby improving access efficiency and reducing latency; it should be noted that this function module is optional.

[0142] Fragmentation function: Based on the characteristics of the storage medium, the block to be stored is divided into several fragments according to specified rules to enable parallel writing and parallel reading, improve storage efficiency, and more effectively utilize the storage module S. It should be noted that this function module is optional.

[0143] Deduplication detection function: This function checks whether a block body with a specified "chain ID, channel ID, and block depth (ID)" has been saved on the storage medium MS. The deduplication method can be based on the entire block or each storage fragment of the block as the smallest unit of deduplication. Deduplication methods include, but are not limited to, the hash value and checksum of the corresponding content. Through the deduplication function, only one application-layer accessible storage object for a specific block will be saved in the storage medium (the storage medium's own multi-replica high availability mechanism still applies at the storage layer, but these replicas cannot be read and written as different replicas at the application layer).

[0144] Backup / Restore Function: Based on block storage metadata, this function reads block body data from the storage medium and combines it with block header data obtained from the block storage metadata to output block backup data in a specified format; alternatively, it imports data from the specified format block backup data into the block storage metadata and storage medium. Besides disaster recovery, this function can also be used for blockchain migration across deployment locations and clouds. It should be noted that this module is optional.

[0145] Media management and adaptation functions: used to manage various media that provide storage services, including media addressing information, media online and service status, media capacity management, and media access interface adaptation.

[0146] like Figure 5 As shown in the figure, a blockchain processing method according to an embodiment of this application, executed by a first node, includes the following steps:

[0147] Step 501: Upon receiving a write notification for the first block, a first request is sent to the second node; wherein the second node includes one or more storage media, and the first request is used to request storage media allocation;

[0148] Step 502: Receive the access token sent by the second node in response to the first request;

[0149] Step 503: Send a second request to the second node. The second request carries the access token and the block object to be stored in the first block. The second request is used to request that the block object be stored in the allocated storage medium.

[0150] Step 504: Receive the response message returned by the second node in response to the second request;

[0151] Step 505: Obtain the block body metadata of the first block according to the response message, and store the block body metadata locally.

[0152] Thus, the method of this application embodiment, by storing the block header and block body separately, storing only the block header and simplified block object in the node, and storing the block body data of multiple blocks of at least one node in the same additional, public storage node (second node), reduces the overall storage overhead of the blockchain system and the node storage overhead, and breaks through the bottleneck that limits the ledger, transaction scale and storage capacity of the entire system.

[0153] It should be noted that the first node is the service node P in the blockchain; the second node is the storage node equipped with the storage module S, or the second node is the storage module S; and the third node is the chain management node M, or the third node is the chain management module.

[0154] Optionally, the first block may include one or more blocks.

[0155] Optionally, the method further includes:

[0156] After receiving the write notification for the first block, the first block is verified.

[0157] The block body of the first block is packaged to obtain the block object in a preset format;

[0158] The block object is encrypted.

[0159] Optionally, the first request carries:

[0160] The chain identifier of the block;

[0161] The channel identifier of the block;

[0162] Block height;

[0163] Block body hash value.

[0164] As an optional implementation, in this embodiment of the application, the first request carries:

[0165] The block's chain identifier, the block's channel identifier, the block height, the block body hash value, and the block body size.

[0166] As a possible embodiment of this application, the first request carries the block size.

[0167] It should be noted that the block body metadata includes the simplified block object.

[0168] Optionally, the block body metadata includes:

[0169] The hash value of the block object;

[0170] The list of access addresses for the block object.

[0171] Optionally, the block body metadata also includes:

[0172] The encryption / decryption key identifier of the block object;

[0173] The encryption / decryption algorithm identifier of the block object.

[0174] As a possible embodiment of this application, the block body metadata also includes the block body size.

[0175] Optionally, after receiving the first request, the second node queries the block storage metadata database to see if the block object of the first block has been stored in the storage medium.

[0176] If the block object has already been stored in the storage medium and the storage status is valid, then return a list of access addresses including the storage location of the block object to the first node.

[0177] If the block object is not stored in the storage medium, a list of storage media is allocated and an access token is returned.

[0178] Optionally, querying the block storage metadata database to see if the block object of the first block has already been stored in the storage medium can be understood as:

[0179] By comparing the block body metadata with the data queried in the storage medium, if they match, it is determined that the block object has been stored in the storage medium.

[0180] Specifically, receiving the response message returned by the second node in response to the second request can be understood as:

[0181] After completing the storage of the block object, the second node sends a response message to the first node, which carries a list of access addresses for the block object.

[0182] The block body metadata of the first block is obtained based on the response message, and the block body metadata is stored locally. This can be understood as follows:

[0183] The first node generates the block body metadata based on the access address list, and stores the block information of the first block and the block body metadata on disk locally.

[0184] In this embodiment of the application, the block body metadata includes:

[0185] The hash value of the block object and the list of access addresses of the block object.

[0186] Optionally, the simplified block body - block body metadata includes at least the fields shown in Table 1:

[0187] Table 1

[0188]

[0189]

[0190] In the blockchain processing method of this application embodiment, adjustments have been made to the block organization structure and storage method:

[0191] like Figure 6 As shown, the block body is simplified to obtain the block body metadata. Only the necessary block body metadata (such as: block body size, block body hash value, block body storage access bit address list, (optional) encryption and decryption password, etc.) is stored on the local blockchain node. The block body content (block object) will be stored in the storage medium MS of the independent storage module S.

[0192] Meanwhile, adjustments were made to the storage and retrieval functions of the blockchain data storage module blocks:

[0193] Specifically, the enhancements are achieved by reloading the original system's block data write and read interfaces: When a new block is verified and needs to be written, a block body metadata construction function and a function to package the block body into a storage object based on a specified format (including an optional encryption process) are added according to specified requirements. The storage access interface is then called to write the block body to the storage medium MS of the specified storage module S. Based on the returned result (access address list), the block body metadata is improved and then stored in the simplified block body metadata. When a specific block needs to be accessed, blockchain node P first retrieves the corresponding block N from local storage, then retrieves the block body metadata from the simplified block body, obtaining the block object storage access address list, the hash value of the block body file, and (optional) a decryption password. Then, the block object is obtained by calling the storage medium MS of storage module S through the interface (decryption password optional), and verified using the locally stored block body metadata (size, hash value, etc.) to confirm that the block body data stored in the storage module has not been tampered with.

[0194] As a feasible embodiment of this application, the block body metadata includes:

[0195] The size of the block object, the hash value of the block object, and the list of access addresses of the block object.

[0196] As a feasible embodiment of this application, the block body metadata includes:

[0197] The hash value of the block object, the list of access addresses of the block object, the encryption / decryption key identifier of the block object, and the encryption / decryption algorithm identifier of the block object.

[0198] As a feasible embodiment of this application, the block body metadata includes:

[0199] The block object's size, hash value, access address list, encryption / decryption key identifier, and encryption / decryption algorithm identifier.

[0200] It should be noted that, when it is necessary to encrypt the block object of the first block, the block body metadata also needs to include: the encryption / decryption key identifier of the block object and the encryption / decryption algorithm identifier of the block object.

[0201] Optionally, the method further includes:

[0202] Upon receiving a read notification for the first block, obtain the block body metadata of the first block stored locally;

[0203] A third request is sent to the second node based on the block body metadata. The third request is used to request to read the block object of the first block.

[0204] Receive the block object sent by the second node in response to the third request.

[0205] It should be noted that the first node accesses the storage module of the second node in two ways: through proxy and redirection.

[0206] Optionally, the third request carries:

[0207] The chain identifier of the block;

[0208] The channel identifier of the block;

[0209] Block height;

[0210] Block body hash value

[0211] List of access addresses for the block.

[0212] As a possible embodiment of this application, the third request also carries the block size.

[0213] Optionally, after receiving the third request, the second node queries whether the corresponding block object has been cached using the query cache function;

[0214] If the block object has already been cached, then the block object is sent to the first node;

[0215] If the block object is not cached, it is read from the storage medium and sent to the first node.

[0216] Optionally, by obtaining the block body metadata of the first block stored locally, it is possible to determine the list of access addresses corresponding to the first block;

[0217] Based on the list of access addresses, the second node obtains the block object.

[0218] The blockchain processing method of this application embodiment determines the access address list of the first block on the second node based on the block body metadata of the first block stored on the first node, thereby reading the block object of the first block in the second node.

[0219] Optionally, after receiving the block object sent by the second node in response to the third request, the method further includes:

[0220] The integrity of the block object is verified based on the block body metadata.

[0221] Optionally, verifying the integrity of the block object based on the block body metadata includes:

[0222] The integrity of the block object is verified based on the block body metadata;

[0223] If the integrity verification is passed, the block object is adopted.

[0224] The blockchain processing method in this application embodiment verifies the block object sent by the second node, thereby ensuring the integrity of the block object read by the first node and thus guaranteeing the availability and credibility of the entire blockchain system.

[0225] Optionally, obtaining the block body metadata of the first block based on the response message includes:

[0226] If the first block is located on the target blockchain, the block body metadata of the first block is updated based on the list of access addresses of the block object in the response message.

[0227] Optionally, based on the list of access addresses of the block object in the response message, the block body metadata of the first block is updated, including:

[0228] After migrating the block object of the first block, the list of access addresses stored thereafter is updated to the block body metadata of the first block.

[0229] In the blockchain processing method of this application embodiment, each service node in the blockchain only stores the block header and a simplified block body, and does not store block objects that occupy a large storage space. Therefore, the amount of data migration during the node migration process is reduced, thereby reducing the workload and implementation cycle of the migration.

[0230] Optionally, before sending the first request to the second node, the method further includes:

[0231] Receive first configuration information sent by the third node, the first configuration information including information for instructing the second node, and relevant information used to request storage media;

[0232] The second node and the first request are determined based on the first configuration information.

[0233] Optionally, the first configuration information includes:

[0234] The ID of the second node and at least one of the following:

[0235] The chain identifier of the block;

[0236] The channel identifier of the block;

[0237] Block height;

[0238] Block body hash value.

[0239] As a feasible embodiment of this application, the first configuration information further includes: block size.

[0240] In the embodiments of this application, such as Figure 7 As shown, the process of storing the first block into the second node is as follows:

[0241] After receiving a new block notification, the first node verifies the validity of the block structure and transaction items in the block body based on the blockchain consensus mechanism and rules.

[0242] The first node organizes the block structure and packages the block body into a specified storage object format, including necessary source-end encryption of the block body;

[0243] The first node sends the first request to the second node for media storage allocation;

[0244] After receiving the first request, the second node queries the block storage metadata database to determine whether the corresponding block object has been stored in the storage medium. Specifically, if the block object has been stored in the storage medium and the storage status is valid, the second node sends the response message to the first node, carrying the access address list Body_AccessAddr of the block body storage location in the response message. If the block object has not yet been stored in the storage medium, the second node allocates the storage medium list {MSx, x = 1, 2, ...} and the access token, and sends the access token to the first node.

[0245] The first node sends a second request to the second node, carrying the access token and the block object to be stored for the first block;

[0246] According to the second request, the second node stores the block object to be stored in the storage medium of the second node; specifically, after receiving the second request, the second node divides the received block object into fragments {BBi, i = 1, 2, ...} according to the technical specifications of the storage medium (e.g., the size of the storage block); then uploads the fragments BBj to the corresponding storage medium MSx one by one.

[0247] The storage medium stores the corresponding fragments and performs corresponding backups according to the storage medium's own replication control strategy. After the fragment storage is completed, the read and write access control logic of the medium marks the corresponding storage area as "read-only" mode (unless the system operator reinitializes the storage medium next time), so that the storage area corresponding to the block cannot be modified, thereby achieving the effect of "write once, read forever".

[0248] After the storage medium completes storage, it sends a message to the storage management submodule indicating that storage is complete.

[0249] The storage management submodule records and caches the block body information and sends a response message back to the first node. The response message carries a list of access addresses for the block body storage location, Body_AccessAddr.

[0250] After receiving the response message, the first node fills the access address list Body_AccessAddr into the block body metadata to form complete block body metadata content, and writes the block header and block body metadata of the first block to disk for local storage.

[0251] In the embodiments of this application, such as Figure 8 As shown, the process of reading the block object from the second node is as follows:

[0252] When the first node receives a block verification request, it needs to read the block object of a specific block from the second node.

[0253] The first node parses the block body metadata to obtain the access address Body_AccessAddr;

[0254] The first node accesses the storage management submodule stored on the second node by sending the third request to the second node, carrying its own identity.

[0255] The storage management submodule queries whether the corresponding block object has been cached based on the third request using the query function. Specifically, if the block object has been cached in the storage management submodule, the cached block object is returned to the first node. If the block object has not been cached in the storage management submodule, the storage medium list {MSx, x = 1, 2, ...} of the block body fragment {BBi, i = 1, 2, ...} is obtained, and the fragment BBj is read from the corresponding storage medium MSx fragment by fragment through the block storage metadata database.

[0256] The storage management submodule will concatenate and verify the read fragment BBj, and cache the block object according to the caching rules;

[0257] The second node sends the block object to the first node;

[0258] After receiving the block object, the first node verifies the integrity of the block object based on the stored block body metadata. If the integrity verification passes, the block object is adopted.

[0259] Optionally, the read notification is triggered by a blockchain migration.

[0260] Optionally, after the first node receives the read notification triggered by the blockchain migration, it obtains the block body metadata of the first block stored locally.

[0261] A third request is sent to the second node based on the block body metadata. The third request is used to request to read the block object of the first block.

[0262] Receive the block object sent by the second node in response to the third request.

[0263] Optionally, the write notification is triggered by a blockchain migration;

[0264] After receiving the block object sent by the second node, the method further includes:

[0265] Based on the blockchain migration goals, determine the updated second node;

[0266] Send the first request to the updated second node.

[0267] Optionally, after receiving the write notification triggered by the blockchain migration, the first node determines the updated second node according to the blockchain migration target;

[0268] Send the first request to the updated second node and receive the target access token from the updated second node;

[0269] Send the second request to the updated second node;

[0270] Receive the target response message returned by the updated second node;

[0271] Obtain the block body metadata of the first block based on the target response message, and store the block body metadata locally.

[0272] In this embodiment of the application, the blockchain data migration includes block migration and blockchain node migration, wherein:

[0273] (1) Block migration:

[0274] Use such as on the blockchain system to be migrated (e.g., System 1) Figure 8 The block data reading process shown involves the backup / restore function traversing the block storage metadata database to locate the block storage information of a specific chain and channel.

[0275] Read each valid block object in block depth order and save it as the corresponding backup file;

[0276] Then export the block storage metadata database;

[0277] Deploy a storage module on the blockchain system to be migrated (e.g., System 2), retrieve the corresponding block objects from the backup file item by item according to the block storage metadata database backed up in System 1, write them to the storage medium MS using the aforementioned block body data storage process, and update the access address Body_AccessAddr of the block body in the specific chain and channel in the block storage metadata database based on the latest access path.

[0278] (2) Blockchain node migration:

[0279] The data backup and migration of the first node of the blockchain of each chain, channel and organization is completed. After the migration is completed, each node sends a request to the storage management submodule SM to change the field of Body_AccessAddr, the access address list of the corresponding block body metadata.

[0280] like Figure 9 As shown in the figure, a blockchain processing method according to an embodiment of this application is executed by a second node, the second node including one or more storage media, and the method includes the following steps:

[0281] Step 901: Receive the first request sent by the first node;

[0282] Step 902: Allocate storage medium for the first block according to the first request, and send an access token corresponding to the allocated storage medium to the first node;

[0283] Step 903: Receive a second request sent by the first node, the second request carrying the access token and the block object to be stored in the first block;

[0284] Step 904: Store the block object in the allocated storage medium according to the second request, and return a response message.

[0285] The blockchain processing method of this application embodiment, in which the first node only stores the block header and a simplified block body (block body metadata), and stores the block object corresponding to at least one block of the first node through an additional, public second node, can reduce the overall storage overhead and node storage overhead of the blockchain system, and break through the bottleneck that limits the entire system ledger, transaction scale and blockchain node storage capacity.

[0286] Optionally, allocating storage medium for the first block according to the first request includes:

[0287] Based on the information carried in the first request, query whether the storage medium has already stored the block object of the first block;

[0288] If the query results indicate that the storage medium does not store the block object of the first block, determine the allocated storage medium and access token.

[0289] Optionally, if the block object of the first block has already been stored in the storage medium and the storage status is valid, then the list of access addresses of the block object is sent to the first node.

[0290] Optionally, the step of storing the block object in the allocated storage medium according to the second request and returning a response message includes:

[0291] The block object is fragmented based on the properties of the storage medium;

[0292] Based on the access token, each fragment is uploaded to the corresponding storage medium for storage;

[0293] A response message containing a list of access addresses for the block object is generated based on the storage location of each fragment;

[0294] The response message is sent to the first node.

[0295] Optionally, after uploading each fragment to the corresponding storage medium for storage based on the access token, the method further includes:

[0296] The block object is cached.

[0297] Optionally, the method further includes:

[0298] Receive a third request sent by the first node, the third request being used to request to read the block object of the first block;

[0299] The block object is sent according to the third request.

[0300] Optionally, sending the block object according to the third request includes:

[0301] Based on the third request, query whether the block object should be cached;

[0302] If the block object is cached, then the block object is sent directly;

[0303] If the block object is not cached, then based on the access address list of the block object, each fragment is read from the storage medium, and the fragments are concatenated to obtain and send the block object.

[0304] Optionally, before receiving the first request sent by the first node, the method further includes:

[0305] Receive the second configuration information sent by the third node;

[0306] Configure the one or more storage media according to the second configuration information.

[0307] like Figure 10 As shown in the figure, a blockchain processing method according to an embodiment of this application, executed by a third node, includes the following steps:

[0308] Step 1001: If a first condition is met, send a write notification to the first node; wherein the first condition includes at least one of the following:

[0309] Blockchain or blockchain channel created successfully;

[0310] The first node joins the blockchain or blockchain channel.

[0311] It should be noted that after the blockchain or blockchain channel is successfully created, when the third node wants to join the blockchain or blockchain channel, it sends a write notification to the first node, so that the first node sends a first request to the second node to apply for storage medium allocation according to the write notification, thereby enabling the second node to allocate storage medium to the block object of the first node according to the first request.

[0312] Optionally, the method further includes:

[0313] If the first condition is met...

[0314] Send first configuration information to the first node, the first configuration information including information for instructing the second node, and relevant information used in requesting storage media; and,

[0315] Send second configuration information to the second node, the second configuration information being used to configure one or more storage media included in the second node.

[0316] Optionally, the method further includes:

[0317] Send a read notification to the second node.

[0318] Optionally, the method further includes:

[0319] In the event of a blockchain migration, the write notification and the read notification are generated.

[0320] like Figure 11 As shown in the figure, a blockchain processing device 1100 according to an embodiment of this application is applied to a first node and includes:

[0321] The first sending module 1101 is configured to send a first request to the second node upon receiving a write notification for the first block; wherein the second node includes one or more storage media, and the first request is used to request storage media allocation;

[0322] The first receiving module 1102 is used to receive the access token sent by the second node in response to the first request;

[0323] The second sending module 1103 is used to send a second request to the second node. The second request carries the access token and the block object to be stored in the first block. The second request is used to request that the block object be stored in the allocated storage medium.

[0324] The second receiving module 1104 is used to receive the response message returned by the second node in response to the second request;

[0325] The first processing module 1105 is used to obtain the block body metadata of the first block according to the response message, and store the block body metadata locally.

[0326] The blockchain processing apparatus of this application reduces the overall storage overhead and node storage overhead of the blockchain system by storing the block header and block body separately, storing only the block header and simplified block object in the node, and storing the block body data of multiple blocks of at least one node in the same additional, public storage node. This breaks through the bottleneck that limits the ledger, transaction scale and storage capacity of the entire system.

[0327] Optionally, the blockchain processing device further includes:

[0328] The first acquisition module is used to acquire the block body metadata of the first block stored locally when receiving a read notification of the first block;

[0329] The fifth sending module is used to send a third request to the second node based on the block body metadata, the third request being used to request to read the block object of the first block;

[0330] The fifth receiving module is used to receive the block object sent by the second node in response to the third request.

[0331] Optionally, the blockchain processing device further includes:

[0332] The verification module is used to verify the integrity of the block object based on the block body metadata.

[0333] Optionally, the first processing module is further configured to:

[0334] If the first block is located on the target blockchain, the block body metadata of the first block is updated based on the list of access addresses of the block object in the response message.

[0335] Optionally, the read notification is triggered by a blockchain migration; the write notification is triggered by a blockchain migration; the blockchain processing device further includes:

[0336] The update module is used to determine the second node to be updated based on the blockchain migration target;

[0337] The sixth sending module is used to send the first request to the updated second node.

[0338] like Figure 12 As shown in the figure, a blockchain processing device 1200 according to an embodiment of this application is applied to a second node, the second node including one or more storage media, including:

[0339] The third receiving module 1201 is used to receive the first request sent by the first node;

[0340] The second processing module 1202 is used to allocate storage medium to the first block according to the first request, and send an access token corresponding to the allocated storage medium to the first node.

[0341] The fourth receiving module 1203 is used to receive a second request sent by the first node, wherein the second request carries the access token and the block object to be stored in the first block;

[0342] The third sending module 1204 is used to store the block object in the allocated storage medium according to the second request and return a response message.

[0343] In the blockchain processing apparatus of this application embodiment, the first node only stores the block header and a simplified block body (block body metadata), and stores the block object corresponding to at least one block of the first node through an additional, public second node. This can reduce the overall storage overhead and node storage overhead of the blockchain system, and break through the bottlenecks that limit the ledger, transaction scale and blockchain node storage capacity of the entire system.

[0344] Optionally, the second processing module is further configured to:

[0345] Based on the information carried in the first request, query whether the storage medium has already stored the block object of the first block;

[0346] If the query results indicate that the storage medium does not store the block object of the first block, determine the allocated storage medium and access token.

[0347] Optionally, the third sending module is further configured to:

[0348] The block object is fragmented based on the properties of the storage medium;

[0349] Based on the access token, each fragment is uploaded to the corresponding storage medium for storage;

[0350] A response message containing a list of access addresses for the block object is generated based on the storage location of each fragment;

[0351] Send the response message to the first node;

[0352] The block object is cached.

[0353] Optionally, the blockchain processing device further includes:

[0354] The sixth receiving module is used to receive a third request sent by the first node, the third request being used to request to read the block object of the first block;

[0355] The seventh sending module is used to send the block object according to the third request.

[0356] Optionally, the seventh sending module is further configured to:

[0357] Based on the third request, query whether the block object should be cached;

[0358] If the block object is cached, then the block object is sent directly;

[0359] If the block object is not cached, then based on the access address list of the block object, each fragment is read from the storage medium, and the fragments are concatenated to obtain and send the block object.

[0360] Optionally, the blockchain processing device further includes:

[0361] The seventh receiving module is used to receive the second configuration information sent by the third node;

[0362] The third processing module is used to configure the one or more storage media according to the second configuration information.

[0363] like Figure 13 As shown in the figure, a blockchain processing device 1300 according to an embodiment of this application is applied to a third node and includes:

[0364] The fourth sending module 1301 is configured to send a write notification to the first node when a first condition is met; wherein the first condition includes at least one of the following:

[0365] Blockchain or blockchain channel created successfully;

[0366] The first node joins the blockchain or blockchain channel.

[0367] Optionally, the blockchain processing device further includes an eighth sending module, used for:

[0368] If the first condition is met...

[0369] Send first configuration information to the first node, the first configuration information including information for instructing the second node, and relevant information used in requesting storage media; and,

[0370] Send second configuration information to the second node, the second configuration information being used to configure one or more storage media included in the second node.

[0371] Optionally, the blockchain processing device further includes:

[0372] The ninth sending module is used to send read notifications to the second node.

[0373] Optionally, the blockchain processing device further includes: a generation module;

[0374] Used to generate the write notification and the read notification in the event of a blockchain migration.

[0375] The first node in this embodiment includes a processor and a transceiver, wherein,

[0376] The transceiver is used to send a first request to a second node upon receiving a write notification for a first block; wherein the second node includes one or more storage media, and the first request is used to request storage media allocation;

[0377] Receive the access token sent by the second node in response to the first request;

[0378] Send a second request to the second node. The second request carries the access token and the block object to be stored in the first block. The second request is used to request that the block object be stored in the allocated storage medium.

[0379] Receive the response message returned by the second node in response to the second request;

[0380] The processor is used to obtain the block body metadata of the first block according to the response message, and store the block body metadata locally.

[0381] Optionally, the processor is further configured to, upon receiving a read notification of the first block, obtain the block body metadata of the first block stored locally;

[0382] The transceiver is also configured to send a third request to the second node based on the block body metadata, the third request being used to request to read the block object of the first block;

[0383] Receive the block object sent by the second node in response to the third request.

[0384] Optionally, the processor is further configured to verify the integrity of the block object based on the block body metadata.

[0385] Optionally, the processor is further configured to update the block body metadata of the first block based on the list of access addresses of the block object in the response message if the first block is located on the target blockchain for migration.

[0386] Optionally, the transceiver is further configured to receive first configuration information sent by the third node, the first configuration information including information for instructing the second node, and relevant information used in requesting storage media;

[0387] The processor is also configured to determine the second node and the first request based on the first configuration information.

[0388] Optionally, the read notification is triggered by a blockchain migration; the write notification is triggered by a blockchain migration.

[0389] The processor is also used to determine the updated second node based on the blockchain migration target;

[0390] The transceiver is also used to send the first request to the updated second node. The second node in this embodiment includes a processor and a transceiver, wherein...

[0391] The transceiver is used to receive the first request sent by the first node;

[0392] According to the first request, a storage medium is allocated to the first block, and an access token corresponding to the allocated storage medium is sent to the first node;

[0393] Receive a second request sent by the first node, the second request carrying the access token and the block object to be stored in the first block;

[0394] The transceiver is used to store the block object in the allocated storage medium according to the second request and return a response message.

[0395] Optionally, the processor is further configured to query whether the storage medium has stored the block object of the first block based on the information carried in the first request;

[0396] If the query result indicates that the storage medium does not store the block object of the first block, the allocated storage medium and access token are determined. Optionally, the processor is further configured to fragment the block object based on the attributes of the storage medium;

[0397] Based on the access token, each fragment is uploaded to the corresponding storage medium for storage;

[0398] A response message containing a list of access addresses for the block object is generated based on the storage location of each fragment;

[0399] The transceiver also sends the response message to the first node.

[0400] Optionally, the transceiver is further configured to receive a third request sent by the first node, the third request being used to request to read the block object of the first block;

[0401] The block object is sent according to the third request.

[0402] Optionally, the processor is further configured to query whether to cache the block object based on the third request;

[0403] If the block object is cached, then the block object is sent directly;

[0404] If the block object is not cached, then based on the access address list of the block object, each fragment is read from the storage medium, and the fragments are concatenated to obtain and send the block object.

[0405] Optionally, the transceiver is also configured to receive second configuration information sent by the third node;

[0406] The processor is also configured to set the one or more storage media according to the second configuration information.

[0407] The third node in this embodiment includes a transceiver, wherein...

[0408] The transceiver is configured to send a write notification to the first node when a first condition is met; wherein the first condition includes at least one of the following:

[0409] Blockchain or blockchain channel created successfully;

[0410] The first node joins the blockchain or blockchain channel.

[0411] Optionally, the transceiver is further configured to, when the first condition is met,

[0412] Send first configuration information to the first node, the first configuration information including information for instructing the second node, and relevant information used in requesting storage media; and,

[0413] Send second configuration information to the second node, the second configuration information being used to configure one or more storage media included in the second node.

[0414] Optionally, the transceiver is also used to send a read notification to the second node.

[0415] Optionally, the third node also includes a processor, which is further configured to generate the write notification and the read notification in the event of a blockchain migration.

[0416] An embodiment of this application provides a blockchain processing device, such as... Figure 14As shown, it includes a transceiver 1410, a processor 1400, a memory 1420, and a program or instructions stored in the memory 1420 and executable on the processor 1400; when the processor 1400 executes the program or instructions, it implements the above-described blockchain processing method.

[0417] The transceiver 1410 is used to receive and send data under the control of the processor 1400.

[0418] Among them, Figure 14 In this context, the bus architecture can include any number of interconnected buses and bridges, specifically linking various circuits together, such as one or more processors represented by processor 1400 and memory represented by memory 1420. The bus architecture can also link together various other circuits, such as peripheral devices, voltage regulators, and power management circuits, which are well known in the art and therefore will not be described further herein. The bus interface provides an interface. The transceiver 1410 can be multiple elements, including transmitters and receivers, providing a unit for communicating with various other devices over a transmission medium.

[0419] The processor 1400 is responsible for managing the bus architecture and general processing, while the memory 1420 can store the data used by the processor 1400 when performing operations.

[0420] This application provides a readable storage medium storing a program or instructions. When the program or instructions are executed by a processor, they implement the steps in the blockchain processing method described above and achieve the same technical effect. To avoid repetition, further details are omitted here.

[0421] The processor mentioned above is the processor in the blockchain processing device described in the above embodiments. The readable storage medium includes computer-readable storage media, such as computer read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0422] This application also provides a computer program product, including computer instructions. When executed by a processor, the computer instructions implement the various processes of the above-described blockchain processing method embodiments and achieve the same technical effect. To avoid repetition, they will not be described again here.

[0423] It should be further noted that the terminals described in this specification include, but are not limited to, smartphones, tablets, etc., and many of the functional components described are referred to as modules in order to emphasize the independence of their implementation.

[0424] The exemplary embodiments described above are with reference to the accompanying drawings. Many different forms and embodiments are feasible without departing from the spirit and teachings of this application. Therefore, this application should not be construed as limiting the exemplary embodiments set forth herein. Rather, these exemplary embodiments are provided to make this application complete and convey the scope of this application to those skilled in the art. In these drawings, component dimensions and relative dimensions may be exaggerated for clarity. The terminology used herein is for the purpose of describing particular exemplary embodiments only and is not intended to be limiting. As used herein, unless clearly indicated otherwise, the singular forms “a,” “an,” and “the” are intended to include all such forms. It will be further understood that the terms “comprising” and / or “including”, when used in this specification, indicate the presence of the stated features, integers, steps, operations, components, and / or elements, but do not exclude the presence or addition of one or more other features, integers, steps, operations, components, and / or groups thereof. Unless otherwise indicated, when stated, a range of values ​​includes the upper and lower limits of the range and any subranges in between.

[0425] The above description is the preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principles described in this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A blockchain processing method, characterized in that, Executed by the first node, including: Upon receiving a write notification for the first block, a first request is sent to the second node; wherein the second node includes one or more storage media, and the first request is used to request storage media allocation; Receive the access token sent by the second node in response to the first request; Send a second request to the second node. The second request carries the access token and the block object to be stored in the first block. The second request is used to request that the block object be stored in the allocated storage medium. Receive the response message returned by the second node in response to the second request; The block body metadata of the first block is obtained based on the response message, and the block body metadata is stored locally.

2. The method according to claim 1, characterized in that, The block body metadata includes: The hash value of the block object; The list of access addresses for the block object.

3. The method according to claim 1, characterized in that, The block body metadata also includes: The encryption / decryption key identifier of the block object; The encryption / decryption algorithm identifier of the block object.

4. The method according to claim 1, characterized in that, Also includes: Upon receiving a read notification for the first block, obtain the block body metadata of the first block stored locally; Based on the block body metadata, a third request is sent to the second node, the third request being used to request to read the block object of the first block; Receive the block object sent by the second node in response to the third request.

5. The method according to claim 4, characterized in that, After receiving the block object sent by the second node in response to the third request, the method further includes: The integrity of the block object is verified based on the block body metadata.

6. The method according to claim 1, characterized in that, The step of obtaining the block body metadata of the first block based on the response message includes: If the first block is located on the target blockchain, the block body metadata of the first block is updated based on the list of access addresses of the block object in the response message.

7. The method according to claim 1, characterized in that, Before sending the first request to the second node, it also includes: Receive first configuration information sent by the third node, the first configuration information including information for instructing the second node, and relevant information used to request storage media; The second node and the first request are determined based on the first configuration information.

8. The method according to claim 4, characterized in that, The read notification was triggered by a blockchain migration.

9. The method according to claim 4 or 8, characterized in that, The write notification is triggered by a blockchain migration; After receiving the block object sent by the second node, the method further includes: Based on the blockchain migration goals, determine the updated second node; Send the first request to the updated second node.

10. The method according to claim 1, characterized in that, The first request carries: The chain identifier of the block; The channel identifier of the block; Block height; Block body hash value.

11. The method according to claim 4, characterized in that, The third request carries: The chain identifier of the block; The channel identifier of the block; Block height; Block body hash value List of access addresses for the block.

12. A blockchain processing method, characterized in that, The method, executed by a second node comprising one or more storage media, includes: Receive the first request sent by the first node; According to the first request, a storage medium is allocated to the first block, and an access token corresponding to the allocated storage medium is sent to the first node; Receive a second request sent by the first node, the second request carrying the access token and the block object to be stored in the first block; The block object is stored in the allocated storage medium according to the second request, and a response message is returned.

13. The method according to claim 12, characterized in that, The step of allocating storage medium for the first block according to the first request includes: Based on the information carried in the first request, query whether the storage medium has already stored the block object of the first block; If the query results indicate that the storage medium does not store the block object of the first block, determine the allocated storage medium and access token.

14. The method according to claim 12, characterized in that, The step of storing the block object in the allocated storage medium according to the second request and returning a response message includes: The block object is fragmented based on the properties of the storage medium; Based on the access token, each fragment is uploaded to the corresponding storage medium for storage; A response message containing a list of access addresses for the block object is generated based on the storage location of each fragment; The response message is sent to the first node.

15. The method according to claim 14, characterized in that, After uploading each fragment to its corresponding storage medium for storage based on the access token, the process further includes: The block object is cached.

16. The method according to claim 12, characterized in that, Also includes: Receive a third request sent by the first node, the third request being used to request to read the block object of the first block; The block object is sent according to the third request.

17. The method according to claim 16, characterized in that, Sending the block object according to the third request includes: Based on the third request, query whether the block object should be cached; If the block object is cached, then the block object is sent directly; If the block object is not cached, then based on the access address list of the block object, each fragment is read from the storage medium, and the fragments are concatenated to obtain and send the block object.

18. The method according to claim 12, characterized in that, Before receiving the first request sent by the first node, it also includes: Receive the second configuration information sent by the third node; Configure the one or more storage media according to the second configuration information.

19. A blockchain processing method, characterized in that, Executed by the third node, including: If a first condition is met, a write notification is sent to the first node; wherein the first condition includes at least one of the following: Blockchain or blockchain channel created successfully; The first node joins the blockchain or blockchain channel; The method further includes: If the first condition is met... Send first configuration information to the first node, the first configuration information including information for instructing the second node, and relevant information used in requesting storage media; and, Send second configuration information to the second node, the second configuration information being used to configure one or more storage media included in the second node.

20. The method according to claim 19, characterized in that, Also includes: Send a read notification to the second node.

21. The method according to claim 20, characterized in that, Also includes: In the event of a blockchain migration, the write notification and the read notification are generated.

22. A blockchain processing device, characterized in that, Applied to the first node, including: A first sending module is configured to send a first request to a second node upon receiving a write notification for a first block; wherein the second node includes one or more storage media, and the first request is used to request storage media allocation; The first receiving module is used to receive the access token sent by the second node in response to the first request; The second sending module is used to send a second request to the second node. The second request carries the access token and the block object to be stored in the first block. The second request is used to request that the block object be stored in the allocated storage medium. The second receiving module is used to receive the response message returned by the second node in response to the second request; The first processing module is configured to obtain the block body metadata of the first block according to the response message, and store the block body metadata locally.

23. A blockchain processing device, characterized in that, Applied to a second node, the second node including one or more storage media, including: The third receiving module is used to receive the first request sent by the first node; The second processing module is used to allocate storage medium for the first block according to the first request, and send an access token corresponding to the allocated storage medium to the first node. The fourth receiving module is used to receive a second request sent by the first node, wherein the second request carries the access token and the block object to be stored in the first block; The third sending module is used to store the block object in the allocated storage medium according to the second request and return a response message.

24. A blockchain processing device, characterized in that, Applied to the third node, including: The fourth sending module is configured to send a write notification to the first node when a first condition is met; wherein the first condition includes at least one of the following: Blockchain or blockchain channel created successfully; The first node joins the blockchain or blockchain channel; The device further includes: The eighth sending module is used to, when the first condition is met, Send first configuration information to the first node, the first configuration information including information for instructing the second node, and relevant information used in requesting storage media; and, Send second configuration information to the second node, the second configuration information being used to configure one or more storage media included in the second node.

25. A blockchain processing device, comprising: A transceiver, a processor, a memory, and a program or instructions stored in the memory and executable on the processor; characterized in that, when the processor executes the program or instructions, it implements the blockchain processing method as described in any one of claims 1-11, or the blockchain processing method as described in any one of claims 12-18, or the blockchain processing method as described in any one of claims 19-21.

26. A readable storage medium having a program or instructions stored thereon, characterized in that, When the program or instructions are executed by the processor, they implement the blockchain processing method as described in any one of claims 1-14, or the blockchain processing method as described in any one of claims 12-18, or the blockchain processing method as described in any one of claims 19-21.

27. A computer program product, characterized in that, The method includes computer instructions that, when executed by a processor, implement the steps of the blockchain processing method as described in any one of claims 1-11, or the blockchain processing method as described in any one of claims 12-18, or the blockchain processing method as described in any one of claims 19-21.

Images