Offline access methods, devices, electronic equipment and storage media for block data

Abstract

This specification provides one or more embodiments of a method, apparatus, electronic device, and machine-readable storage medium for offline access to block data. The method is applied to an application that initiates offline access to offline archived block data; the method includes: receiving an offline data access request for an archived file; wherein the archived file is obtained by offline archiving of block data for at least one block; the archived file contains the block data of the at least one block that has been offline archived; in response to the offline data access request, performing offline parsing on the archived file based on metadata corresponding to the archived file to determine a target block to be accessed corresponding to the offline data access request from the at least one block, and offline reading the block data of the target block from the archived file.

Description

Technical Field

[0001] This specification relates to the field of blockchain technology, and more particularly to an offline access method, apparatus, electronic device, and machine-readable storage medium for block data. Background Technology

[0002] Because blockchain data stored on-chain only increases and never decreases, the amount of online data stored on-chain also increases as the blockchain runs longer, which will occupy a large amount of the blockchain system's storage capacity and may affect system performance.

[0003] In fact, since the data generated during the production process usually has a certain time sensitivity and some of the data is used less frequently, this less frequently used data can be archived to transfer this online data to offline, thereby keeping the amount of on-chain data in the blockchain system at a stable level.

[0004] After offline archiving of block data stored on the blockchain, how to quickly and cost-effectively meet the access needs for the archived data while ensuring the trustworthiness of the block data is a challenge that urgently needs to be addressed. Summary of the Invention

[0005] In view of this, this application discloses an offline access method, apparatus, electronic device, and machine-readable storage medium for block data, which can quickly and cost-effectively meet the access needs for archived data after offline archiving of block data stored on the blockchain, while ensuring the trustworthiness of the block data.

[0006] This application provides an offline access method for block data, the method being applied to an application that initiates offline access to offline archived block data; the method includes:

[0007] Receive an offline data access request for an archived file; wherein the archived file is obtained by offline archiving of block data of at least one block; the archived file contains the block data of the at least one block that has been offline archived;

[0008] In response to the offline data access request, based on the metadata corresponding to the archive file, the archive file is parsed offline to determine the target block to be accessed corresponding to the offline data access request from the at least one block, and the block data of the target block is read offline from the archive file.

[0009] This application also provides an offline access device for block data, the device comprising:

[0010] A receiving unit is configured to receive an offline data access request for an archived file; wherein the archived file is obtained by offline archiving of block data of at least one block; the archived file contains the block data of the at least one block that has been offline archived.

[0011] An offline parsing unit is configured to respond to the offline data access request by performing offline parsing on the archive file based on the metadata corresponding to the archive file, in order to determine the target block to be accessed corresponding to the offline data access request from the at least one block, and to read the block data of the target block offline from the archive file.

[0012] This application also provides an electronic device, including a communication interface, a processor, a memory, and a bus, wherein the communication interface, the processor, and the memory are interconnected via the bus;

[0013] The memory stores machine-readable instructions, and the processor executes the above method by invoking the machine-readable instructions.

[0014] This application also provides a machine-readable storage medium storing machine-readable instructions, which, when called and executed by a processor, implement the above-described method.

[0015] Through the above embodiments, in response to an offline data access request for an archived file, the archived file can be parsed offline based on the metadata corresponding to the archived file to determine the target block to be accessed from at least one block contained in the archived file, and the block data of the target block can be read offline from the archived file. Therefore, after offline archiving of the block data stored on the blockchain, the block data contained in the archived file can be accessed offline quickly and at low cost, meeting the access requirements for the archived data, while ensuring the trustworthiness of the block data, without having to restore the offline archived block data to the chain for online access. Attached Figure Description

[0016] To more clearly illustrate the technical solutions of the embodiments in this specification, the drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this specification. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0017] Figure 1 This is a schematic diagram illustrating a blockchain-related network environment as an exemplary embodiment;

[0018] Figure 2This is a schematic diagram illustrating an archive file as an exemplary embodiment;

[0019] Figure 3 This is a flowchart illustrating an offline access method for block data, as shown in an exemplary embodiment.

[0020] Figure 4 This is a schematic diagram of the structure of an electronic device containing an offline access device for block data, as shown in an exemplary embodiment.

[0021] Figure 5 This is a block diagram illustrating an offline access device for block data, as shown in an exemplary embodiment. Detailed Implementation

[0022] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this specification.

[0023] It should be noted that the steps of the corresponding methods are not necessarily performed in the order shown and described in this specification in other embodiments. In some other embodiments, the methods may include more or fewer steps than described in this specification. Furthermore, a single step described in this specification may be broken down into multiple steps in other embodiments; and multiple steps described in this specification may be combined into a single step in other embodiments.

[0024] Blockchain is generally classified into three types: public blockchain, private blockchain, and consortium blockchain. Furthermore, combinations of these types are possible, such as a combination of private and consortium blockchains, or a combination of consortium and public blockchains.

[0025] Of the three types of blockchains mentioned above, public blockchains offer the highest degree of decentralization. Participants in a public blockchain (also known as nodes in the blockchain) can read data records on the chain, participate in transactions, and compete for the right to record new blocks. Moreover, nodes can freely join or leave the network and perform related operations.

[0026] In contrast, private blockchains have write permissions controlled by a specific organization or institution, and data read permissions are governed by the organization's regulations. That is, a private blockchain can be viewed as a weakly centralized system, with strict restrictions on the number of nodes and a relatively small number of nodes. This type of blockchain is more suitable for use within specific organizations.

[0027] Consortium blockchains fall between public and private blockchains, enabling "partial decentralization." Each node in a consortium blockchain typically has a corresponding entity or organization; nodes join the network through authorization and form a consortium of stakeholders to jointly maintain the operation of the blockchain.

[0028] In a blockchain network, a blockchain node is a logical communication entity; multiple blockchain nodes of different types can run on the same physical server or on different physical servers.

[0029] Please see Figure 1 , Figure 1 This is a schematic diagram illustrating an exemplary embodiment of a blockchain-related network environment. In such... Figure 1 The network environment shown may include a user-side computing device 101, a server 102, and at least one blockchain system; for example, blockchain system 103, blockchain system 104, and blockchain system 105.

[0030] In one embodiment shown, the user-side computing device 101 may include various different types of user-side computing devices; for example, user-side computing devices may include PC computing devices, mobile computing devices, Internet of Things devices, and other forms of smart devices with certain computing capabilities, etc.

[0031] It should be noted that user-side computing device 101 does not mean that all user-side computing devices are in the same communication network, but is merely a collective term for these user-side computing devices.

[0032] In one embodiment shown, some computing devices in the user-side computing device 101 can be coupled to the server 102 via various communication networks; for example, device 3 is coupled to the server 102.

[0033] Some computing devices in the user-side computing device 101 may not be coupled to the server 102, but may be directly coupled to the blockchain system as blockchain nodes; for example, device 4 may be directly coupled to the blockchain system 103 as a blockchain node.

[0034] In one embodiment shown, the user-side computing device 101 may further include one or more user-side servers, such as devices 5 and 6. Some computing devices in the user-side computing device 101 may be coupled to the user-side server; for example, device 1 is coupled to device 5, and device 2 is coupled to device 6. The user-side server may further be directly coupled to the blockchain system as a blockchain node, or it may be further coupled to the server-side 102 via various communication networks; for example, device 5 may be directly coupled to the blockchain system as a blockchain node, and device 6 may be further coupled to the server-side 102.

[0035] In one embodiment shown, the user-side server can be implemented by a service entity that has established a user account system; the service entity may include the operating entity of the service carrier that provides various online and / or offline services to users. Accordingly, the operating entity may include the operator corresponding to the service carrier; for example, the operating entity may include individuals, institutions, organizations, etc., that operate and manage the service carrier.

[0036] In one embodiment shown, server 102 may also be coupled to one or more blockchain systems via various communication networks; for example, server 102 may be coupled to blockchain system 103, blockchain system 104 and blockchain system 105, etc.

[0037] In one embodiment shown, the communication network may include wired and / or wireless communication networks; for example, it may be a local area network (LAN), wide area network (WAN), Internet, or a combination thereof, implemented based on a wired access network or wireless access network (such as a mobile cellular network) provided by an operator.

[0038] In one embodiment shown, each blockchain system can maintain one or more blockchains (e.g., public blockchain, private blockchain, consortium blockchain, etc.) and include multiple blockchain nodes for hosting the aforementioned one or more blockchains; for example, such as Figure 1 The blockchain nodes 1, 2, 3, 4, and i shown can collectively support one or more blockchains. Cross-chain data access is also possible between the blockchains within each blockchain system, and between different blockchain systems themselves.

[0039] In one embodiment shown, a blockchain node can be a physical device or a virtual device implemented in a server or server cluster. For example, a blockchain node can be a physical host in a server cluster, or a virtual machine created by virtualizing the hardware resources of a server or server cluster based on virtualization technology. Each blockchain node can be coupled together to form a network through various types of communication methods (e.g., TCP / IP) to carry one or more blockchains.

[0040] In one embodiment shown, server 102 may include a BaaS platform (also known as a BaaS cloud) for providing blockchain services (BaaS).

[0041] BaaS platforms can provide blockchain services to user-side computing devices coupled to the BaaS platform by providing pre-written software for activities that occur on the blockchain, such as subscriptions and notifications, user authentication, database management and remote updates.

[0042] For example, a BaaS platform can provide software such as MQ (Message Queue) services; user-side computing devices coupled to the BaaS platform can subscribe to smart contracts deployed on a blockchain in a blockchain system coupled to the BaaS platform, and the contract events generated on the blockchain after the smart contract is triggered and executed; the BaaS platform can listen to the events generated on the blockchain after the smart contract is triggered and executed, and then, based on the MQ service-related software, add the contract events to the message queue in the form of notification messages, so that user-side computing devices that subscribe to the message queue can receive notifications related to the aforementioned contract events.

[0043] For data generated outside the blockchain, it can be constructed into a standard transaction format supported by the blockchain, and then published to the blockchain. All nodes in the blockchain network will reach a consensus on the transaction. After consensus is reached, the nodes acting as ledger nodes in the blockchain network can persistently store this transaction on the blockchain.

[0044] In programmable blockchains, the functionality of smart contracts allows users to create and invoke complex logic within the blockchain network. A smart contract is a program on the blockchain that can be triggered by transactions. Smart contracts can be defined in the form of code.

[0045] After a smart contract is created, a contract account corresponding to that smart contract appears on the blockchain, and it has a specific address. The behavior of the smart contract is controlled by the contract code in the contract account, while the account storage saves the state of the smart contract.

[0046] A transaction used to invoke a smart contract can include the address of the account initiating the call, the address of the smart contract being invoked, and the method and parameters used to invoke the smart contract. After the smart contract is invoked, its state may change; the state of the smart contract can be viewed by communicating with blockchain nodes.

[0047] Smart contracts can be executed independently by nodes in a blockchain network in a prescribed manner. All execution records and related data can be stored on the blockchain. Therefore, once such a transaction is completed, the blockchain stores an immutable and unlost transaction certificate.

[0048] Because blockchain data stored on-chain only increases and never decreases, the amount of online data stored on-chain also increases as the blockchain runs longer, which will occupy a large amount of the blockchain system's storage capacity and may affect system performance.

[0049] In fact, since the data generated during the production process usually has a certain time sensitivity and some of the data is used less frequently, this less frequently used data can be archived to transfer this online data to offline, thereby keeping the amount of on-chain data in the blockchain system at a stable level.

[0050] For example, historical data with low usage frequency can be archived periodically; or, when upgrading the blockchain technology used in the production system, if the new chain is incompatible with the old chain, only the data with high migration value can be migrated from the old chain to the new chain, and the data with low usage frequency can be directly archived to reduce data migration costs.

[0051] Offline archiving is a method of data archiving that involves storing online data and its metadata on an offline storage medium for transfer to the data management entity (such as an archives department or an electronic document management system). Offline archiving can also be called offloading archiving or offline archiving, but this manual does not specify the exact terminology.

[0052] It should be noted that, unlike data backup, offline archived data needs to meet occasional access requirements, that is, the offline archived data can be read when needed.

[0053] In one embodiment of a related technology, the offline archived blockchain data can be restored to the online system first, and then the archived data restored to the online system can be accessed based on the online data access mechanism provided by the online system.

[0054] Therefore, in the embodiments shown above, if the amount of archived data is large, the cost of restoring the archived data to the online system is also high, while the actual amount of data that needs to be read is usually small, resulting in a high cost of accessing the archived data. In addition, restoring a large amount of archived data to the online system may also pose a potential risk to the transactions of the online system.

[0055] In another embodiment of the related technology, offline archived blockchain data can be imported into a traditional database system, and the archived data stored in the traditional database system can be maintained; subsequently, the archived data stored in the traditional database system can be read.

[0056] Therefore, in the embodiments shown above, archived data stored in traditional database systems no longer possesses the immutability characteristic of blockchain data; in addition, the traditional database system requires additional maintenance, resulting in high costs for accessing archived data.

[0057] In summary, after offline archiving of block data stored on the blockchain, how to quickly and cost-effectively meet the access needs for the archived data while ensuring the trustworthiness of the block data is a challenge that urgently needs to be addressed.

[0058] In view of this, this specification aims to propose a technical solution for offline parsing of archive files based on the metadata corresponding to the archive files, so as to read block data offline from the archive files.

[0059] In implementation, block data of at least one block stored on the blockchain can be archived offline to obtain an archive file containing the block data of the at least one block that has been archived offline. Subsequently, users can initiate an offline data access request for the archive file through an application that initiates offline access for the offline archived block data, so as to access the block data contained in the archive file offline.

[0060] The application can receive an offline data access request for the archived file; further, in response to the offline data access request, the application can perform offline parsing of the archived file based on the metadata corresponding to the archived file, to determine the target block to be accessed corresponding to the offline data access request from the at least one block, and read the block data of the target block offline from the archived file.

[0061] For example, see Figure 2 , Figure 2 This is a schematic diagram illustrating an archive file as an exemplary embodiment. (As shown) Figure 2 As shown, the archived file can contain block data of N (N can be any positive integer) blocks that have been archived offline; the application that initiates offline access to the offline archived block data can maintain and... Figure 2 The metadata corresponding to the archived file shown. The application can receive metadata for, for example... Figure 2 The application can perform offline data access requests for the archived file shown; further, in response to the offline data access requests, the application can perform offline parsing of the archived file based on the metadata it maintains corresponding to the archived file, in order to determine the target block corresponding to the offline data access requests from the N blocks contained in the archived file, and read the block data of the target block offline from the archived file.

[0062] Therefore, in the technical solution described in this specification, in response to an offline data access request for an archived file, the archived file can be parsed offline based on the metadata corresponding to the archived file to determine the target block to be accessed from at least one block contained in the archived file, and the block data of the target block can be read offline from the archived file. Therefore, after offline archiving of the block data stored on the blockchain, the block data contained in the archived file can be accessed offline quickly and at low cost, meeting the access requirements for the archived data, while ensuring the trustworthiness of the block data, without having to restore the offline archived block data to the chain for online access.

[0063] The present application will now be described through specific embodiments and in conjunction with specific application scenarios.

[0064] Please see Figure 3 , Figure 3 This is a flowchart illustrating an offline access method for block data, as shown in an exemplary embodiment.

[0065] In this specification, the method is applied to an application that initiates offline access to offline archived block data.

[0066] For example, when offline access is required for block data that has been archived offline, the user can initiate an offline data access request for the archived file through the application; the application can initiate offline access for the block data contained in the archived file.

[0067] In one embodiment shown, the application may include a service program deployed on a blockchain service platform.

[0068] For example, combined with Figure 1 In the network environment shown, the application can be a service program deployed on server 102, which can be used to initiate offline access to offline archived block data.

[0069] In one possible embodiment, the blockchain service platform can be a BaaS (Blockchain as a Service) platform; the service program can be a cloud application.

[0070] In another embodiment shown, the application may include a blockchain client program.

[0071] For example, combined with Figure 1 In the network environment shown, the application can be a blockchain client program running on the user-side computing device 101, which can be used to initiate offline access to offline archived block data.

[0072] The method can perform the following steps:

[0073] Step 302: Receive an offline data access request for an archived file; wherein the archived file is obtained by offline archiving of block data of at least one block; the archived file contains the block data of the at least one block that has been offline archived.

[0074] For example, the application can receive requests for, such as Figure 2 The offline data access request for the archived file shown; such as Figure 2 The archive file shown can be obtained by offline archiving of block data from blocks 1 to N on the blockchain; the archive file contains the block data of N blocks that have been offline archived. The blockchain can be, for example,... Figure 1 This specification does not specifically limit the scope to any blockchain maintained by any blockchain system in the network environment shown.

[0075] In one embodiment shown, the offline data access request may include a command line submitted by the user through a command-line interface to initiate offline data access.

[0076] For example, the application can provide a command-line interface as an entry point for users to interact with the application; users can submit command lines to the application for initiating offline data access to the archive file through the command-line interface; the application can respond to the command line and initiate offline access to the block data contained in the archive file.

[0077] Step 304: In response to the offline data access request, based on the metadata corresponding to the archive file, perform offline parsing on the archive file to determine the target block to be accessed corresponding to the offline data access request from the at least one block, and read the block data of the target block offline from the archive file.

[0078] For example, upon receiving a request for such Figure 2 Following the offline data access request for the archive file shown, in response to the offline data access request, the application can perform offline parsing on the archive file based on the metadata it maintains corresponding to the archive file, in order to determine the target block corresponding to the offline data access request from the N blocks contained in the archive file, and read the block data of the target block offline from the archive file.

[0079] In this specification, the application can provide a variety of query modes to support users in flexibly initiating offline access to offline archived block data according to different needs.

[0080] In one embodiment shown, the application can initiate offline access to block data for a specific block.

[0081] In step 304, the metadata corresponding to the archive file may specifically include storage structure metadata corresponding to the archive file; the storage structure metadata may include metadata describing the storage location of block data of the at least one block in the archive file. In this case, the step of performing offline parsing on the archive file based on the metadata corresponding to the archive file to determine the target block to be accessed corresponding to the offline data access request from the at least one block, and offline reading the block data of the target block from the archive file, may specifically include: performing offline parsing on the archive file based on the storage structure metadata corresponding to the archive file to determine a first target storage location of the block data of the target block corresponding to the offline data access request in the archive file; and offline reading the block data of the target block from the archive file based on the first target storage location.

[0082] In one possible embodiment, the offline data access request may include the block identifier of the target block; the storage structure metadata may specifically include the correspondence between the block identifiers of the at least one block and the storage locations of the block data of the at least one block in the archive file. In this case, the offline parsing of the archive file based on the storage structure metadata corresponding to the archive file to determine the first target storage location of the block data of the target block corresponding to the offline data access request in the archive file may specifically include: querying the correspondence between the block identifiers of the at least one block and the storage locations of the block data of the at least one block in the archive file based on the block identifier of the target block included in the offline data access request, to determine the first target storage location corresponding to the block identifier of the target block.

[0083] For example, such as Figure 2 As shown, the target block to be accessed can be "Block 2" contained in the archive file; the offline data access request for the archive file received by the application can contain the block identifier of "Block 2"; in response to the offline data access request, the application can query the correspondence between the block identifiers of each block in the N blocks it maintains and the storage location of the block data of each block in the archive file based on the block identifier of "Block 2", so as to determine the first target storage location corresponding to the block identifier of "Block 2", and can read the block data of "Block 2" offline from the archive file based on the first target storage location.

[0084] It should be noted that, in the embodiments shown above, the block identifier can be used to uniquely identify different blocks in the archive file; the specific form of the block identifier is not particularly limited in this specification. For example, the block identifier can specifically be the block number of the corresponding block in the blockchain system; or, the block identifier can be a block identifier reassigned to the at least one block during the process of offline archiving of the block data of the at least one block on the chain to obtain the archive file.

[0085] In another possible embodiment, the offline data access request may not include the block identifier of the target block. In this case, the application can perform offline parsing of the archive file based on the metadata it maintains corresponding to the archive file, traverse the block data of the at least one block contained in the archive file to determine the target block to be accessed from the at least one block, and can read the block data of the target block offline from the archive file.

[0086] It should be noted that, in the embodiments shown above, the storage structure metadata may also include metadata for describing information such as the number of blocks contained in the archive file, which will not be elaborated here.

[0087] In another embodiment shown, the application can initiate offline access to transaction data for a particular transaction.

[0088] In step 304, the offline data access request can specifically be used to access the transaction data of the target transaction contained in the target block offline; the metadata corresponding to the archive file may further include block metadata corresponding to the at least one block; the block metadata may include metadata describing the storage location of the transaction data of each transaction contained in the at least one block within the block data of the at least one block. In this case, after step 304, the method may further include:

[0089] Step 306: Based on the block metadata corresponding to the target block, perform offline parsing on the block data of the target block to determine the second target storage location of the transaction data of the target transaction corresponding to the offline data access request in the block data of the target block, and read the transaction data of the target transaction offline from the block data of the target block based on the second target storage location.

[0090] In one possible embodiment, the offline access request may include the transaction identifier of the target transaction; the block metadata may specifically include the correspondence between the transaction identifiers of at least one transaction and the storage locations of the transaction data of the at least one transaction in the block data of the at least one block. In this case, in step 306, the offline parsing of the block data of the target block based on the block metadata corresponding to the target block to determine the second target storage location of the transaction data of the target transaction corresponding to the offline data access request in the block data of the target block may specifically include: based on the transaction identifier of the target transaction included in the offline access request, querying the correspondence between the transaction identifiers of the at least one transaction and the storage locations of the transaction data of the at least one transaction in the block data of the at least one block to determine the second target storage location corresponding to the transaction identifier of the target transaction.

[0091] For example, the block data of "Block 2" may contain transaction data of at least one transaction, and the transaction data of the target transaction to be accessed may be the transaction data of "Transaction 1" contained in the block data of "Block 2"; the offline data access request for the archive file received by the application may contain the transaction identifier of "Transaction 1"; after reading the block data of "Block 2" offline from the archive file, the application may, based on the transaction identifier of "Transaction 1", query the correspondence between the transaction identifiers of each transaction contained in the block data of "Block 2" and the storage location of the transaction data of each transaction in the block data of "Block 2" to determine the second target storage location corresponding to the transaction identifier of "Transaction 1", and may, based on the second target storage location, read the transaction data of "Transaction 1" offline from the block data of "Block 2".

[0092] It should be noted that, in the embodiments shown above, the transaction identifier can be used to uniquely identify different transactions in the archive file; the specific form of the transaction identifier is not particularly limited in this specification.

[0093] Additionally, it should be noted that in the embodiments shown above, the block metadata may also include metadata for describing information such as the block header length of the at least one block; wherein, the block header length can be used to determine the position of the transaction data of each transaction in the block body, which will not be elaborated here.

[0094] In another embodiment shown, the application can initiate offline access to a portion of the transaction content (e.g., the content of a transaction field or a bytecode) contained in the transaction data of a transaction.

[0095] In step 304, the offline data access request can specifically be used to access the target transaction field in the transaction data of the target transaction offline; the block metadata may further include metadata describing the transaction format corresponding to each transaction contained in the at least one block. In this case, after step 306, the method may further include:

[0096] Step 308: Based on the block metadata corresponding to the target block, perform offline parsing on the transaction data of the target transaction to determine the third target storage location of the target transaction field corresponding to the offline data access request in the transaction data of the target transaction, and read the target transaction field offline from the transaction data of the target transaction based on the third target storage location.

[0097] For example, the target transaction field to be accessed can be a target transaction field contained in the transaction data of "Transaction 1"; the offline data access request for the archive file received by the application can contain the field identifier of the target transaction field; after reading the transaction data of "Transaction 1" offline from the block data of "Block 2", the application can perform offline parsing of the transaction data of "Transaction 1" based on the block metadata corresponding to "Block 2" and according to the transaction format corresponding to "Transaction 1" to determine the third target storage location of the target transaction field in the transaction data of "Transaction 1", and read the target transaction field offline from the transaction data of "Transaction 1" based on the third target storage location.

[0098] In one possible embodiment, since the transaction data contained in the block data stored on the chain may be encoded, if an online access is initiated for the encoded transaction data stored on the chain, the blockchain system can perform decoding processing based on a preset decoding algorithm; therefore, the transaction data in the block data contained in the archive file may also be encoded, and if an offline access is initiated for the encoded transaction data contained in the archive file, the application can decode to obtain readable transaction data based on the corresponding encoding algorithm.

[0099] In implementation, the metadata corresponding to the archived file may further include system metadata corresponding to the at least one block; wherein, the system metadata may include metadata describing the encoding algorithm used in the encoded transaction data contained in the at least one block. In this case, before offline reading the target transaction field from the transaction data of the target transaction based on the third target storage location, the method may further include: decoding the encoded transaction data of the target transaction contained in the block data of the target block based on a decoding algorithm corresponding to the encoding algorithm used in the transaction data of the target transaction, to obtain the decoded transaction data of the target transaction.

[0100] For example, the application can maintain system metadata corresponding to "Block 2". The system metadata may specifically include the correspondence between the algorithm identifiers of the encoding algorithms used by the transaction data of each transaction contained in the block data of "Block 2" and the corresponding algorithm identifiers of the decoding algorithms. After reading the transaction data of "Transaction 1" offline from the block data of "Block 2", the application can determine the algorithm identifier of the encoding algorithm used by the transaction data of "Transaction 1" and the algorithm identifier of the decoding algorithm corresponding to the encoding algorithm based on the system metadata corresponding to "Block 2". Then, the application can decode the transaction data of "Transaction 1" based on the decoding algorithm to obtain readable transaction data of "Transaction 1".

[0101] In another possible embodiment, since the transaction data contained in the block data stored on the chain may be encrypted, if an online access is initiated for the encrypted transaction data stored on the chain, the blockchain system can perform decryption processing based on a preset decryption algorithm; therefore, the transaction data in the block data contained in the archive file may also be encrypted. If an offline access is initiated for the encrypted transaction data contained in the archive file, the application can decrypt the transaction content encrypted and stored in the transaction data based on the corresponding decryption algorithm.

[0102] In implementation, the metadata corresponding to the archived file may further include system metadata corresponding to the at least one block; wherein, the system metadata may include metadata describing the encryption algorithm used in the encrypted transaction data contained in the at least one block. In this case, before offline reading the target transaction field from the transaction data of the target transaction based on the third target storage location, the method may further include: decrypting the encrypted transaction data of the target transaction contained in the block data of the target block based on the decryption algorithm corresponding to the encryption algorithm used in the transaction data of the target transaction, to obtain the decrypted transaction data of the target transaction.

[0103] For example, the application can maintain system metadata corresponding to "Block 2". The system metadata may specifically include the correspondence between the algorithm identifiers of the encryption algorithms used in the transaction data of each transaction contained in the block data of "Block 2" and the corresponding algorithm identifiers of the decryption algorithms. After reading the transaction data of "Transaction 1" offline from the block data of "Block 2", the application can determine the algorithm identifier of the encryption algorithm used in the transaction data of "Transaction 1" and the algorithm identifier of the decryption algorithm corresponding to the encryption algorithm based on the system metadata corresponding to "Block 2". Then, the application can decrypt the transaction data of "Transaction 1" based on the decryption algorithm to obtain readable transaction data of "Transaction 1".

[0104] In one embodiment shown, prior to step 304, the method may further include: in response to the completion of offline archiving of block data for the at least one block, obtaining metadata corresponding to the archived file, and maintaining the metadata corresponding to the archived file locally.

[0105] For example, in response to the completion of offline archiving of block data for N blocks on the chain, the application can obtain the metadata corresponding to the archived file and can maintain the metadata corresponding to the archived file locally.

[0106] In one possible embodiment, an archiving program can perform offline archiving of block data on the blockchain to obtain the archive file and metadata corresponding to the archive file. The archiving program can then synchronize the metadata corresponding to the archive file in real time to the application that initiates offline access to the block data contained in the archive file. In implementation, obtaining the metadata corresponding to the archive file and maintaining it locally specifically includes: receiving the metadata corresponding to the archive file synchronized in real time by the archiving program after it has obtained the archive file through offline archiving of block data from at least one block, and maintaining the received metadata locally; wherein the archiving program is used to perform offline archiving of block data on the blockchain.

[0107] For example, the archiving procedure performs offline archiving of block data for at least one block on the blockchain to obtain, as follows: Figure 2 After the archived file is displayed, the application can receive metadata corresponding to the archived file that is synchronized in real time by the archiving program, and the application can maintain the metadata corresponding to the archived file locally.

[0108] It should be noted that, in the embodiments shown above, this specification does not specifically limit the specific implementation method for generating the archived files, and can refer to relevant technologies for offline archiving of on-chain data.

[0109] As can be seen from the above technical solutions, in response to an offline data access request for an archived file, the archived file can be parsed offline based on the metadata corresponding to the archived file to determine the target block to be accessed from at least one block contained in the archived file, and the block data of the target block can be read offline from the archived file. Therefore, after offline archiving of the block data stored on the blockchain, the block data contained in the archived file can be accessed offline quickly and at low cost, meeting the access requirements for the archived data, while ensuring the trustworthiness of the block data, without having to restore the offline archived block data to the chain for online access.

[0110] Corresponding to the embodiments of the offline access method for block data described above, this specification also provides an embodiment of an offline access device for block data.

[0111] Please see Figure 4 , Figure 4This is an exemplary embodiment illustrating the hardware structure of an electronic device housing an offline access device for block data. At the hardware level, the device includes a processor 402, an internal bus 404, a network interface 406, memory 408, and non-volatile memory 410, and may also include other hardware required for various services. One or more embodiments of this specification can be implemented in software, for example, the processor 402 reads the corresponding computer program from the non-volatile memory 410 into memory 408 and then runs it. Of course, besides software implementations, one or more embodiments of this specification do not exclude other implementation methods, such as logic devices or a combination of hardware and software, etc. That is to say, the execution entity of the following processing flow is not limited to individual logic units, but can also be hardware or logic devices.

[0112] Please see Figure 5 , Figure 5 This is a block diagram illustrating an offline access device for block data, as shown in an exemplary embodiment. This offline access device for block data can be applied to, for example... Figure 4 The electronic device shown implements the technical solution of this specification. The offline access device for block data may include:

[0113] The receiving unit 502 is configured to receive an offline data access request for an archived file; wherein the archived file is obtained by offline archiving of block data of at least one block; the archived file contains the block data of the at least one block that has been offline archived.

[0114] The offline parsing unit 504 is configured to respond to the offline data access request by performing offline parsing on the archive file based on the metadata corresponding to the archive file, in order to determine the target block to be accessed corresponding to the offline data access request from the at least one block, and to read the block data of the target block offline from the archive file.

[0115] In this embodiment, the device further includes:

[0116] The acquisition unit is configured to, in response to the completion of offline archiving of block data for the at least one block, acquire the metadata corresponding to the archived file and maintain the metadata corresponding to the archived file locally.

[0117] In this embodiment, the acquisition unit is specifically used for:

[0118] After the receiving archiving program performs offline archiving of block data for at least one block to obtain the archive file, it synchronizes the metadata corresponding to the archive file in real time and maintains the received metadata locally; wherein, the archiving program is used to perform offline archiving of block data on the blockchain.

[0119] In this embodiment, the metadata corresponding to the archive file includes storage structure metadata corresponding to the archive file; wherein, the storage structure metadata includes metadata describing the storage location of block data of the at least one block in the archive file;

[0120] The offline parsing unit 504 is specifically used for:

[0121] Based on the storage structure metadata corresponding to the archive file, offline parsing is performed on the archive file to determine the first target storage location of the block data of the target block corresponding to the offline data access request in the archive file;

[0122] Based on the first target storage location, the block data of the target block is read offline from the archive file.

[0123] In this embodiment, the offline data access request includes the block identifier of the target block; the storage structure metadata includes the correspondence between the block identifier of the at least one block and the block data of the at least one block in the storage location of the archive file;

[0124] The offline parsing unit 504 is specifically used for:

[0125] Based on the block identifier of the target block included in the offline data access request, the correspondence between the block identifier of the at least one block and the block data of the at least one block in the storage location of the archive file is queried to determine the first target storage location corresponding to the block identifier of the target block.

[0126] In this embodiment, the offline data access request is used to access the transaction data of the target transaction contained in the target block offline;

[0127] The metadata corresponding to the archived file also includes block metadata corresponding to the at least one block; wherein, the block metadata includes metadata describing the storage location of transaction data of each transaction contained in the at least one block in the block data of the at least one block;

[0128] The offline parsing unit 504 is also used for:

[0129] Based on the block metadata corresponding to the target block, offline parsing is performed on the block data of the target block to determine the second target storage location of the transaction data of the target transaction corresponding to the offline data access request in the block data of the target block.

[0130] The transaction data of the target transaction is read offline from the block data of the target block based on the second target storage location.

[0131] In this embodiment, the offline access request includes the transaction identifier of the target transaction; the block metadata includes the correspondence between the transaction identifier of at least one transaction and the storage location of the transaction data of the at least one transaction in the block data of the at least one block;

[0132] The offline parsing unit 504 is specifically used for:

[0133] Based on the transaction identifier of the target transaction contained in the offline access request, the correspondence between the transaction identifier of the at least one transaction and the storage location of the transaction data of the at least one transaction in the block data of the at least one block is queried to determine the second target storage location corresponding to the transaction identifier of the target transaction.

[0134] In this embodiment, the offline data access request is used to perform offline access to the target transaction field in the transaction data of the target transaction;

[0135] The block metadata also includes metadata describing the transaction format corresponding to each transaction contained in the at least one block;

[0136] The offline parsing unit 504 is also used for:

[0137] Based on the block metadata corresponding to the target block, the transaction data of the target transaction is parsed offline to determine the third target storage location of the target transaction field corresponding to the offline data access request in the transaction data of the target transaction.

[0138] The target transaction field is read offline from the transaction data of the target transaction based on the third target storage location.

[0139] In this embodiment, the metadata corresponding to the archived file also includes system metadata corresponding to the at least one block; wherein, the system metadata includes metadata describing the encoding algorithm used for the encoded transaction data contained in the at least one block;

[0140] The device further includes:

[0141] The decoding unit is used to decode the encoded transaction data of the target transaction contained in the block data of the target block based on the decoding algorithm corresponding to the encoding algorithm used in the transaction data of the target transaction, so as to obtain the decoded transaction data of the target transaction.

[0142] In this embodiment, the metadata corresponding to the archived file also includes system metadata corresponding to the at least one block; wherein, the system metadata includes metadata describing the encryption algorithm used in the encrypted transaction data contained in the at least one block;

[0143] The device further includes:

[0144] The decryption unit is used to decrypt the encrypted transaction data of the target transaction contained in the block data of the target block based on the decryption algorithm corresponding to the encryption algorithm used in the transaction data of the target transaction, so as to obtain the decrypted transaction data of the target transaction.

[0145] In this embodiment, the offline data access request includes a command line submitted by the user through the command line interface to initiate offline data access.

[0146] In this embodiment, the application includes a service program deployed on a blockchain service platform; or, a blockchain client program.

[0147] In this embodiment, the blockchain service platform is a BaaS platform; the service program is a cloud application.

[0148] The specific implementation process of the functions and roles of each unit in the above device can be found in the implementation process of the corresponding steps in the above method, and will not be repeated here.

[0149] For the device embodiments, since they basically correspond to the method embodiments, the relevant parts can be referred to in the description of the method embodiments. The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of the solution in this specification according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0150] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer, which can take the form of a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email sending and receiving device, game console, tablet computer, wearable device, or any combination of these devices.

[0151] In a typical configuration, a computer includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0152] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0153] Computer-readable media, including both permanent and non-permanent, removable and non-removable media, can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, disk storage, quantum memory, graphene-based storage media or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0154] The user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0155] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0156] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0157] The terminology used in one or more embodiments of this specification is for the purpose of describing particular embodiments only and is not intended to limit the scope of one or more embodiments of this specification. The singular forms “a,” “described,” and “the” as used in one or more embodiments of this specification and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any or all possible combinations of one or more associated listed items.

[0158] It should be understood that although the terms first, second, third, etc., may be used to describe various information in one or more embodiments of this specification, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, first information may also be referred to as second information without departing from the scope of one or more embodiments of this specification, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" as used herein may be interpreted as "when," "in response to a determination," or "when," or "in the event of a determination."

[0159] The above description is merely a preferred embodiment of one or more embodiments of this specification and is not intended to limit the scope of one or more embodiments of this specification. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of one or more embodiments of this specification should be included within the protection scope of one or more embodiments of this specification.

Claims

1. An offline access method for block data, the method being applied to an application that initiates offline access to offline archived block data; the method comprising: Receive an offline data access request for an archived file; wherein the archived file is obtained by offline archiving of block data of at least one block stored on the blockchain; the archived file contains the block data of the at least one block that has been offline archived; In response to the offline data access request, based on the maintained metadata corresponding to the archive file, the archive file is parsed offline to determine the target block to be accessed corresponding to the offline data access request from the at least one block, and the block data of the target block is read offline from the archive file.

2. The method according to claim 1, further comprising: In response to the completion of offline archiving of block data for the at least one block, the metadata corresponding to the archived file is obtained, and the metadata corresponding to the archived file is maintained locally.

3. The method according to claim 2, wherein obtaining the metadata corresponding to the archived file and maintaining the metadata corresponding to the archived file locally includes: After the receiving archiving program performs offline archiving of block data for at least one block to obtain the archive file, it synchronizes the metadata corresponding to the archive file in real time and maintains the received metadata locally; wherein, the archiving program is used to perform offline archiving of block data on the blockchain.

4. The method according to claim 1, wherein the metadata corresponding to the archived file includes storage structure metadata corresponding to the archived file; wherein, The storage structure metadata includes metadata describing the storage location of block data of the at least one block in the archive file; The offline parsing of the archived file, based on the maintained metadata corresponding to the archived file, to determine the target block to be accessed corresponding to the offline data access request from the at least one block, and to read the block data of the target block offline from the archived file, includes: Based on the maintained storage structure metadata corresponding to the archive file, offline parsing is performed on the archive file to determine the first target storage location of the block data of the target block corresponding to the offline data access request in the archive file; Based on the first target storage location, the block data of the target block is read offline from the archive file.

5. The method according to claim 4, wherein the offline data access request is used to perform offline access to the transaction data of the target transaction contained in the target block; The metadata corresponding to the archived file also includes block metadata corresponding to the at least one block; wherein, the block metadata includes metadata describing the storage location of transaction data of each transaction contained in the at least one block in the block data of the at least one block; The method further includes: Based on the maintained block metadata corresponding to the target block, offline parsing is performed on the block data of the target block to determine the second target storage location of the transaction data of the target transaction corresponding to the offline data access request in the block data of the target block. The transaction data of the target transaction is read offline from the block data of the target block based on the second target storage location.

6. The method according to claim 5, wherein the offline data access request is used to perform offline access to the target transaction field in the transaction data of the target transaction; The block metadata also includes metadata describing the transaction format corresponding to each transaction contained in the at least one block; The method further includes: Based on the maintained block metadata corresponding to the target block, the transaction data of the target transaction is parsed offline to determine the third target storage location of the target transaction field corresponding to the offline data access request in the transaction data of the target transaction. The target transaction field is read offline from the transaction data of the target transaction based on the third target storage location.

7. The method according to claim 6, wherein the metadata corresponding to the archived file further includes system metadata corresponding to the at least one block; wherein, The system metadata includes metadata describing the encoding algorithm used for the encoded transaction data contained in the at least one block; Before reading the target transaction field offline from the transaction data of the target transaction based on the third target storage location, the method further includes: Based on the decoding algorithm corresponding to the encoding algorithm used in the transaction data of the target transaction, the encoded transaction data of the target transaction contained in the block data of the target block is decoded to obtain the decoded transaction data of the target transaction.

8. The method according to claim 6, wherein the metadata corresponding to the archived file further includes system metadata corresponding to the at least one block; wherein, The system metadata includes metadata describing the encryption algorithm used in the encrypted transaction data contained in the at least one block; Before reading the target transaction field offline from the transaction data of the target transaction based on the third target storage location, the method further includes: Based on the decryption algorithm corresponding to the encryption algorithm used in the transaction data of the target transaction, the encrypted transaction data of the target transaction contained in the block data of the target block is decrypted to obtain the decrypted transaction data of the target transaction.

9. The method according to claim 1, wherein the offline data access request includes a command line submitted by the user through a command line interface for initiating offline data access.

10. The method according to claim 1, wherein the application includes a service program deployed on a blockchain service platform; or, a blockchain client program.

11. The method according to claim 10, wherein the blockchain service platform is a BaaS platform; and the service program is a cloud application.

12. An offline access device for block data, the device comprising: A receiving unit is configured to receive an offline data access request for an archived file; wherein the archived file is obtained by offline archiving of block data of at least one block stored on the blockchain; the archived file contains the block data of the at least one block that has been offline archived. An offline parsing unit is configured to respond to the offline data access request by performing offline parsing on the archive file based on the maintained metadata corresponding to the archive file, in order to determine the target block to be accessed corresponding to the offline data access request from the at least one block, and to read the block data of the target block offline from the archive file.

13. An electronic device, comprising a communication interface, a processor, a memory, and a bus, wherein the communication interface, the processor, and the memory are interconnected via the bus; The memory stores machine-readable instructions, and the processor executes the method according to any one of claims 1 to 11 by invoking the machine-readable instructions.

14. A machine-readable storage medium storing machine-readable instructions that, when invoked and executed by a processor, implement the method of any one of claims 1 to 11.

Images