Method and apparatus for reading and writing account data

Abstract

One or more embodiments of this specification provide a method and apparatus for reading and writing account data. The method is applied to a first blockchain node in a first blockchain network. In the node device where the first blockchain node is located, blockchain nodes of other blockchain networks are also deployed, and the node device maintains a public database corresponding to multiple blockchain nodes. The public database is used to record the account data of public accounts between multiple blockchain networks. The method includes: obtaining a read / write request for a target account; when the account data of the target account is recorded in the public database, searching for the target account in the public database and performing a read / write operation on the account data of the target account.

Description

Technical Field

[0001] One or more embodiments of this specification relate to the field of blockchain technology, and in particular, to a method and apparatus for reading and writing account data. Background Art

[0002] Blockchain technology is built on a peer-to-peer network. Nodes in a blockchain network use a chained data structure to verify and store data, and adopt a distributed node consensus algorithm to generate and update data. In some blockchain networks, some of the node members corresponding to the nodes sometimes have a need to participate in multiple blockchain networks, that is, multiple blockchain nodes belonging to different blockchain networks may be deployed in a certain node device at the same time. In this scenario, the node device needs to manage the account data of the blockchain accounts in different blockchain networks it participates in. Summary of the Invention

[0003] In view of this, one or more embodiments of this specification provide a method and apparatus for reading and writing account data.

[0004] To achieve the above object, one or more embodiments of this specification provide the following technical solutions:

[0005] According to a first aspect of one or more embodiments of this specification, a method for reading and writing account data is proposed, which is applied to a first blockchain node in a first blockchain network. Other blockchain nodes of other blockchain networks are also deployed in the node device where the first blockchain node is located, and the node device maintains a common database corresponding to multiple blockchain nodes. The common database is used to record the account data of common accounts between multiple blockchain networks. The method includes:

[0006] Obtain a read / write request for a target account;

[0007] In the case where the account data of the target account is recorded in the common database, search for the target account in the common database and perform a read / write operation on the account data of the target account.

[0008] According to a second aspect of one or more embodiments of this specification, a method for reading and writing account data is proposed, which is applied to a node device. Multiple blockchain nodes belonging to different blockchain networks are deployed in the node device, and the node device maintains a common database corresponding to multiple blockchain nodes. The common database is used to record the account data of common accounts between multiple blockchain networks. The method includes:

[0009] Obtain a read / write request for a target account;

[0010] In the case where the account data of the target account is recorded in the public database, search for the target account in the public database and perform read and write operations on the account data of the target account.

[0011] According to the third aspect of one or more embodiments of this specification, a device for reading and writing account data is proposed, which is applied to a first blockchain node in a first blockchain network. In the node device where the first blockchain node is located, blockchain nodes of other blockchain networks are also deployed, and the node device maintains a public database corresponding to multiple blockchain nodes. The public database is used to record the account data of public accounts between multiple blockchain networks. The device includes:

[0012] A request acquisition module, configured to acquire a read / write request for a target account;

[0013] A first read / write module, configured to search for the target account in the public database and perform read and write operations on the account data of the target account in the case where the account data of the target account is recorded in the public database.

[0014] According to the fourth aspect of one or more embodiments of this specification, a device for reading and writing account data is proposed, which is applied to a node device. In the node device, multiple blockchain nodes belonging to different blockchain networks are deployed, and the node device maintains a public database corresponding to multiple blockchain nodes. The public database is used to record the account data of public accounts between multiple blockchain networks. The device includes:

[0015] A request acquisition module, configured to acquire a read / write request for a target account;

[0016] A first read / write module, configured to search for the target account in the public database and perform read and write operations on the account data of the target account in the case where the account data of the target account is recorded in the public database.

[0017] According to the fifth aspect of one or more embodiments of this specification, an electronic device is proposed, including:

[0018] A processor;

[0019] A memory for storing instructions executable by the processor;

[0020] Wherein, the processor realizes the method described in the first aspect or the second aspect by running the executable instructions.

[0021] According to a sixth aspect of one or more embodiments of this specification, a computer-readable storage medium is provided, on which computer instructions are stored, and when the instructions are executed by a processor, the steps of the method described in the first aspect or the second aspect are implemented.

[0022] In summary, through the technical solution of this specification, in the case where multiple blockchain nodes belonging to different blockchain networks are deployed in a node device, the node device also maintains a public database corresponding to the multiple blockchain nodes, and the public database is used to record the account data of the public accounts between the multiple blockchain networks. Based on this recording method of the account data, for a read / write request for a target account obtained, the first blockchain node or the node device can, when the account data of the target account is recorded in the public database, find the target account in the public database and perform a read / write operation on its account data.

[0023] In the above manner, the node device can store the account data of the public accounts between different blockchain networks in the public database, and in response to a read / write request for a public account, perform a read / write operation on the account data of the account recorded in the public database. It can be seen that multiple blockchain networks can jointly maintain public accounts, realizing a shared management solution for public accounts, enabling multiple independent blockchain networks to have shared public accounts, simplifying the account system in the multi-blockchain network scenario to a certain extent, and helping to reduce the workload of the node device in maintaining accounts. And because of the shared characteristic of the public accounts, the operation results of the read / write operations performed by the first blockchain network on the account data of the target account can also be used (such as read) by other blockchain networks, thus realizing the unified operation of different blockchain nodes on the same account, and helping to improve the management and utilization efficiency of public accounts. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] Figure 1 is a schematic diagram of creating a smart contract provided by an exemplary embodiment.

[0025] Figure 2 is a schematic diagram of invoking a smart contract provided by an exemplary embodiment.

[0026] Figure 3 is a schematic diagram of creating and invoking a smart contract provided by an exemplary embodiment.

[0027] Figure 4 is a schematic diagram of a multi-level tree structure provided by an exemplary embodiment.

[0028] Figure 5 is a schematic diagram of the database deployment situation in a node device provided by an exemplary embodiment.

[0029] Figure 6 It is a flowchart of a method for reading and writing account data provided by an exemplary embodiment.

[0030] Figure 7 It is a flowchart of another method for reading and writing account data provided by an exemplary embodiment.

[0031] Figure 8 It is a schematic structural diagram of a device provided by an exemplary embodiment.

[0032] Figure 9 It is a block diagram of a device for reading and writing account data provided by an exemplary embodiment.

[0033] Figure 10 It is a block diagram of another device for reading and writing account data provided by an exemplary embodiment. Detailed implementation manners

[0034] Here, the exemplary embodiments will be described in detail, and the examples are shown in the drawings. When the following description refers to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The implementation manners described in the following exemplary embodiments do not represent all the implementation manners consistent with one or more embodiments of this specification. On the contrary, they are merely examples of devices and methods consistent with some aspects of one or more embodiments of this specification as detailed in the appended claims.

[0035] It should be noted that: in other embodiments, the steps of the corresponding method are not necessarily executed in the order shown and described in this specification. In some other embodiments, the steps included in the method may be more or less than those described in this specification. In addition, a single step described in this specification may be decomposed into multiple steps for description in other embodiments; and multiple steps described in this specification may also be combined into a single step for description in other embodiments.

[0036] Blockchains are generally divided into three types: public blockchains, private blockchains, and consortium blockchains. In addition, there are various combinations, such as private blockchain + consortium blockchain, consortium blockchain + public blockchain, and other different forms. Among them, the public blockchain has the highest degree of decentralization. Participants in the public blockchain can read the data records on the chain, participate in transactions, and compete for the right to record new blocks. Moreover, each participant (i.e., node) can freely join and exit the network and perform related operations. In contrast, for private blockchains, the write permission of the network is controlled by a certain organization or institution, and the data read permission is subject to the organization's regulations. Simply put, a private blockchain can be a weakly decentralized system with strictly limited and few participating nodes. This type of blockchain is more suitable for internal use within a specific institution. Consortium blockchains are blockchains that lie between public and private blockchains and can achieve "partial decentralization". Each node in a consortium blockchain usually corresponds to a corresponding entity organization; participants join the network through authorization and form an interest-related consortium to jointly maintain the operation of the blockchain.

[0037] Whether it is a public blockchain, a private blockchain, or a consortium blockchain, they may all provide the function of smart contracts. Smart contracts on the blockchain are contracts that can be triggered and executed by transactions on the blockchain system. Smart contracts can be defined in the form of code.

[0038] Taking Ethereum as an example, it supports users to create and call some complex logics in the Ethereum network. The core of Ethereum as a programmable blockchain is the Ethereum Virtual Machine (EVM), and each Ethereum node can run the EVM. The EVM is a Turing-complete virtual machine, which means that various complex logics can be implemented through it. When users publish and call smart contracts in Ethereum, they are running on the EVM. In fact, what the virtual machine directly runs is the virtual machine code (virtual machine bytecode, hereinafter referred to as "bytecode" for short). Smart contracts deployed on the blockchain can be in the form of bytecode.

[0039] For example Figure 1 as shown, after Bob sends a transaction containing information about creating a smart contract to the Ethereum network, the EVM of Node 1 can execute this transaction and generate the corresponding contract instance. Figure 1"0x6f8ae93…" in it represents the address of this contract. The data field of the transaction can store bytecode, and the to field of the transaction is empty. After the nodes reach an agreement through the consensus mechanism, this contract is successfully created and can be called in subsequent processes. After the contract is created, a contract account corresponding to this smart contract appears on the blockchain and has a specific address. The contract code will be stored in this contract account. The behavior of the smart contract is controlled by the contract code. In other words, smart contracts enable virtual accounts containing contract code and account storage to be generated on the blockchain.

[0040] As Figure 2 shown, still taking Ethereum as an example, after Bob sends a transaction for calling a smart contract to the Ethereum network, the EVM of a certain node can execute this transaction and generate a corresponding contract instance. Figure 2 In the transaction, the from field is the address of the account of the transaction initiator (i.e., Bob), and "0x6f8ae93…" in the to field represents the address of the smart contract to be called. The value field is the value of Ether in Ethereum. The data field of the transaction stores the method and parameters for calling the smart contract. After calling the smart contract, the value of balance may change. Subsequently, a certain client can view the current value of balance through a certain blockchain node (such as Figure 2 the node 6 in). The smart contract is independently executed at each node in the blockchain network in a prescribed manner, and all execution records and data are stored on the blockchain. Therefore, after the transaction is completed, the transaction vouchers that cannot be tampered with and will not be lost are saved on the blockchain.

[0041] The schematic diagrams for creating and calling smart contracts are as Figure 3 shown. In Ethereum, to create a smart contract, processes such as writing the smart contract, compiling it into bytecode, and deploying it to the blockchain are required. In Ethereum, calling a smart contract is to initiate a transaction pointing to the address of the smart contract, and the smart contract code runs distributedly in the virtual machines of each node in the Ethereum network.

[0042] It should be noted that in addition to being created by users, smart contracts can also be set by the system in the genesis block. Such contracts are generally called genesis contracts. Generally, some data structures, parameters, attributes, and methods of the blockchain network can be set in the genesis contract. In addition, accounts with system administrator permissions can create system-level contracts or modify system-level contracts (referred to as system contracts for short). In addition, in addition to the EVM in Ethereum, different blockchain networks may also adopt various virtual machines, which are not limited here.

[0043] After a node in the blockchain network executes a transaction that invokes a smart contract, it generates a corresponding receipt to record information related to the execution of the smart contract. In this way, relevant information about the contract execution result can be obtained by querying the receipt of the transaction. The contract execution result can be represented as an event in the receipt. The messaging mechanism can achieve message passing through the events in the receipt to trigger corresponding processing by the blockchain node or the node device that deploys the blockchain node. The structure of the event can be, for example:

[0044] Event:

[0045] [topic][data]

[0046] [topic][data] ......

[0048] In the above example, the number of events can be one or more; each event includes fields such as a topic and data. The blockchain node or the node device that deploys the blockchain node can execute preset processing when it listens for a predefined topic by listening to the topic of the event, or read relevant content from the data field of the corresponding event, and can execute preset processing based on the read content.

[0049] In the above event mechanism, it is equivalent to having a client with a listening function at the listener (such as a user with a listening requirement). For example, an SDK for implementing the listening function is running on the client, and the client listens for the events generated by the blockchain node, while the blockchain node only needs to generate receipts normally. In addition to the above event mechanism, transaction information can also be disclosed in other ways. For example, listening code can be embedded in the blockchain platform code running on the blockchain node, so that the listening code can listen for one or more types of data such as the transaction content of the blockchain transaction, the contract status of the smart contract, and the receipts generated by the contract, and send the listened data to a predefined listener. Since the listening code is deployed in the blockchain platform code rather than on the client of the listener, this implementation method based on the listening code is relatively more proactive compared to the event mechanism. Among them, the above listening code can be added to the blockchain platform code by the developer of the blockchain platform during the development process, or can be embedded by the listener based on its own needs, and this specification does not limit this.

[0050] One of the decentralized features that distinguish blockchain technology from traditional technologies is that accounting is carried out on each node, or distributed accounting, rather than traditional centralized accounting. For a blockchain system to become a decentralized, honest and trustworthy system that is difficult to break, has open and immutable data records, it is necessary to achieve the security, clarity and irreversibility of distributed data records in the shortest possible time. In different types of blockchain networks, in order to keep the ledgers consistent among the nodes that record the ledgers, a consensus algorithm is usually adopted to ensure, that is, the aforementioned consensus mechanism. For example, a consensus mechanism at the block granularity can be achieved among blockchain nodes. For instance, after a block is generated at a node (such as a unique node), if the generated block is recognized by other nodes, the other nodes record the same block. Another example is that a consensus mechanism at the transaction granularity can be achieved among blockchain nodes. For example, after a blockchain transaction is obtained at a node (such as a unique node), if this blockchain transaction is recognized by other nodes, each node that recognizes the blockchain transaction can respectively add the blockchain transaction to the latest block maintained by itself, and ultimately ensure that the same latest block is generated by each node. The consensus mechanism is a mechanism for blockchain nodes to reach a consensus on the block information (or block data) across the network, which can ensure that the latest block is accurately added to the blockchain. The current mainstream consensus mechanisms include: Proof of Work (POW), Proof of Stake (POS), Delegated Proof of Stake (DPOS), Practical Byzantine Fault Tolerance (PBFT) algorithm, HoneyBadgerBFT algorithm, etc.

[0051] Due to the decentralized characteristics of the blockchain network, all blockchain nodes in the blockchain network will maintain the same block data, which cannot meet the special needs of some nodes. Taking the consortium blockchain as an example, all consortium members (i.e., node members within the consortium) can form a blockchain network. All consortium members have corresponding blockchain nodes in this blockchain network and can obtain all transactions and related data that occur on this blockchain network through the corresponding blockchain nodes. However, in some cases, there may be some consortium members who also participate in forming other blockchain networks, so other blockchain nodes will also be deployed in the node devices where the blockchain nodes corresponding to these members in the above blockchain network are located.

[0052] For example, there may be some consortium members who wish to complete transactions with confidentiality requirements. These consortium members not only hope that these transactions can be recorded on the blockchain or take advantage of other benefits of blockchain technology, but also want to prevent other consortium members from viewing these transactions and related data. Although these consortium members can create a new blockchain network separately, with a similar establishment method as the above-mentioned blockchain network that includes all consortium members, building a new blockchain network from scratch requires a large amount of resources, and both the establishment process and the subsequent configuration process of this blockchain network are very time-consuming. The needs among consortium members are often temporary or time-sensitive, causing the newly created blockchain network to quickly lose its meaning due to the disappearance of the needs, thereby further increasing the chain-building cost of the above-mentioned blockchain network. Moreover, the needs among consortium members often change, and the consortium members corresponding to each need are also often different. Therefore, whenever the consortium members change, a new blockchain network may need to be created, resulting in a significant waste of resources and time.

[0053] Therefore, the created blockchain network can be used as the main blockchain network, and blockchain subnets can be created based on this main blockchain network. Then, in a consortium chain scenario such as the above, consortium members can create the required blockchain subnets based on their own needs on the basis of already participating in the main blockchain network. Since the blockchain subnets are established based on the main blockchain network, the creation process of the blockchain subnets consumes significantly fewer resources and takes much less time compared to creating a blockchain network completely independently, with extremely high flexibility.

[0054] The following briefly introduces the process of quickly creating a blockchain subnet based on the main blockchain network: Each main network node in the main blockchain network obtains the transaction for creating the blockchain subnet to disclose the configuration information. When the configuration information contains the identity information of the node member corresponding to the first main network node, the node device deploying the first main network node starts the first subnet node belonging to the blockchain subnet based on the genesis block containing the configuration information.

[0055] The transaction for creating the blockchain subnet can be initiated by the administrator of the main blockchain network, that is, only the administrator is allowed to create the blockchain subnet based on the main blockchain network, while avoiding opening the creation permission of the blockchain subnet to ordinary users to prevent security issues caused thereby. In some cases, ordinary users of the main blockchain network can also be allowed to initiate the above-mentioned transaction for creating the blockchain subnet to meet the networking needs of ordinary users, enabling ordinary users to quickly create blockchain subnets even when the administrator is not convenient to initiate the transaction.

[0056] Take Figure 4Taking the following as an example, the blockchain mainnet is mainnet0, and the blockchain nodes included in this mainnet0 are nodeA, nodeB, nodeC, nodeD, nodeE, etc. Assume that nodeA, nodeB, nodeC, and nodeD hope to create a blockchain subnet: If nodeA is the administrator and only the administrator is allowed to initiate the transaction for creating a blockchain subnet, then nodeA can initiate the above-mentioned transaction for creating a blockchain subnet to mainnet0; alternatively, nodeB to nodeE can request nodeA to make nodeA initiate the above-mentioned transaction for creating a blockchain subnet to mainnet0. If nodeA is the administrator but allows ordinary users to initiate the transaction for creating a blockchain subnet, then nodeA to nodeE can all initiate the above-mentioned transaction for creating a blockchain subnet to mainnet0. Of course, whether it is the administrator or an ordinary user, the blockchain node that initiates the transaction for creating a blockchain subnet does not necessarily participate in the created blockchain subnet. For example, although the blockchain subnet is finally created by nodeA, nodeB, nodeC, and nodeD, nodeE can initiate the above-mentioned transaction for creating a blockchain subnet to mainnet0, and it is not necessarily initiated by nodeA to nodeD.

[0057] When creating a blockchain subnet based on the blockchain mainnet, it is easy to understand that there will be a logical hierarchical relationship between the blockchain subnet and the blockchain mainnet. For example, when creating a blockchain subnet subnet1 on the mainnet0 shown in Figure 4 , it can be considered that mainnet0 is at the first layer and subnet1 is at the second layer, that is, mainnet0 is the parent network of subnet1, and subnet1 is the subnet of mainnet0. And on the basis of the blockchain subnet, a lower-level blockchain subnet can be further created. For example, another blockchain subnet subnet1.1 can be further created on the basis of Figure 4 subnet1. At this time, it can be considered that subnet is at the third layer, subnet1 is the corresponding parent network of subnet1.1, subnet1.1 is the subnet of subnet1, and subnet1.1 is the grandchild network of mainnet0. Similarly, subnet1.1 can still create a new blockchain subnet on its basis, so that a multi-level tree structure is formed among the blockchain networks.

[0058] In this specification, any blockchain network can be managed by its corresponding parent network, that is, by the blockchain network that creates the any blockchain network. For example, in Figure 4In this multi-level tree structure with the blockchain mainnet as the root node (the root node has the lowest level) and each blockchain subnet as other nodes, the blockchain subnet represented by any node is managed by the blockchain network corresponding to its parent node. As a special case, when the blockchain mainnet is the underlying blockchain network, the blockchain mainnet is managed by itself. The blockchain mainnet in this specification can be the underlying blockchain network. The underlying blockchain network refers to a blockchain subnet that is not created based on other blockchain networks. Therefore, there is no other blockchain network other than this blockchain mainnet that can manage the blockchain mainnet. For example Figure 4 mainnet0 in Figure 4 can be considered as a blockchain mainnet belonging to the type of the underlying blockchain network, and mainnet0 manages itself. Of course, the blockchain mainnet can also be a subnet of other blockchain networks, and this specification does not impose any restrictions on this. Through the method of the parent node managing the corresponding child node, the above multi-level tree structure realizes layer-by-layer management, reduces the management pressure of the blockchain mainnet, and at the same time avoids exposing the subnet information of the upper layer network to the lower layer network, thereby realizing the confidential management of each level of network.

[0059] In this specification, the node device can deploy the blockchain node by creating an instance running the blockchain platform code in the process. For example, the node device can first create a first instance in the process to form a blockchain node in the blockchain mainnet; and when the node member corresponding to the node device hopes to participate in creating a blockchain subnet, a second instance can be created in the above process. The second instance is different from the above first instance, and the second instance forms a blockchain node in the blockchain subnet. When the first instance and the second instance are in the same process, since there is no cross-process interaction, the deployment difficulty of the first subnet node can be reduced and the deployment efficiency can be improved. Of course, the second instance may also be in different processes on the node device from the first instance, and this specification does not limit this.

[0060] In fact, each blockchain node deployed on any node device involved in the embodiments of this specification is a different blockchain instance running on the said any node device. The blocks generated by each blockchain node deployed on any node device and the account data of the target accounts created are respectively stored in different independent databases on the said any node device, and the various independent databases respectively used by each blockchain node deployed on any node device are isolated from each other. For example, the node device can create a first instance in the first process to form a first blockchain node in the blockchain mainnet; and when the node member corresponding to the node device hopes to participate in creating a blockchain subnet, a second process different from the first process can be started, and a second instance can be created in this second process. The second instance is different from the above first instance, and then the second instance forms a second blockchain node in the blockchain subnet.

[0061] In the above manner, a blockchain subnet managed by the blockchain mainnet can be created on the blockchain mainnet. Taking Figure 4 as an example, for mainnet0 containing nodeA to nodeE, subnet1 can be created based on mainnet0. Subnet1 contains nodeA1 to nodeD1, and any subnet node in subnet1 and its corresponding mainnet node in mainnet0 are deployed on the same node device. For example, nodeA and nodeA1 are deployed on node device A, nodeB and nodeB1 are deployed on node device B, nodeC and nodeC1 are deployed on node device C, and nodeD and nodeD1 are deployed on node device D. Similarly, subnet2 or more blockchain subnets can also be created on mainnet0. Subnet2 contains nodeA2, nodeB2, nodeC2, and nodeE2, and nodeA and nodeA1, nodeA2, nodeB and nodeB1, nodeB2, nodeC and nodeC1, nodeD and nodeD1, nodeE and nodeE2 are respectively deployed on the same node device. Moreover, subnet1, subnet2, etc. can be used as the blockchain mainnet, and on this basis, further blockchain subnets can be created. For example, blockchain subnet subnet1.1 can be created based on subnet1. The process is similar to the creation of subnet1 or subnet2, only replacing the blockchain mainnet with blockchain subnet subnet1, which will not be elaborated here. Finally, subnet1.1 contains nodeA3, nodeB3, and nodeC3, such that nodeA and nodeA1, nodeA2, nodeA3, nodeB and nodeB1, nodeB2, nodeB3, nodeC and nodeC1, nodeC2, nodeC3 are respectively deployed on the same node device. It can be seen that the mainnet node nodeA and subnet nodes nodeA1, nodeA2, and nodeA1.1 are deployed in node device A, the mainnet node nodeB and subnet nodes nodeB1, nodeB2, and nodeB1.1 are deployed in node device B. Node devices B and C are similar to node device A and will not be elaborated. The mainnet node nodeD and subnet node nodeD are deployed in node device D, and the mainnet node nodeE and subnet node nodeE2 are deployed in node device E.

[0062] In addition, for a node device deployed with multiple blockchain nodes, a common database corresponding to the multiple blockchain nodes is also maintained therein. The common database is used to record the account data of the common accounts between the multiple blockchain networks. Among them, at least one common database can be maintained in the node device, and any common database can correspond to multiple networks in all the blockchain networks participated by the node device. Taking Figure 4 node device A where the four blockchain nodes of nodeA, nodeA1, nodeA1.1, and nodeA2 are located as shown in the figure as an example, as Figure 5 shown, a common database corresponding to multiple blockchain networks is deployed in the blockchain node. The database can be used to record the account data of the common accounts between the multiple blockchain networks. For example, if the common database corresponds to two blockchain networks, mainnet0 and subnetA, the account can record the account data of the common accounts between the two; if the common database corresponds to three blockchain networks, subnetA, subnetA1, and subnetA2, the account can record the account data of the common accounts among the three.

[0063] In addition, in some embodiments, independent databases corresponding to each blockchain node can also be maintained in the node device: independent database 0 corresponding to nodeA, independent database 1 corresponding to nodeA, independent database 1.1 corresponding to nodeA1.1, and independent database 2 corresponding to nodeA2. Among them, any of the above independent databases can be used to record the account data of the target accounts created in the corresponding blockchain nodes. For example, independent database 0 is used to record the account data of the target accounts created in nodeA, such as Accounts on mainnet0 in the figure. Among them, the above independent accounts can be external accounts or contract accounts; the account data of any target account can be the account address, account public-private key pair, account historical operation records, etc. In addition, the independent database corresponding to any blockchain node can also record the smart contracts created in the blockchain network where the account is located, such as Contract in the figure, and the historical blocks generated in the blockchain network where the account is located, such as Block in the figure. It can be seen that the common databases corresponding to multiple blockchain nodes can be only used to record the account data of the common accounts between the blockchain networks to which the multiple blockchain nodes belong. Considering that the data such as blocks and smart contracts maintained by the blockchain nodes in different blockchain networks are often different, such information in any blockchain network can be recorded in the independent database corresponding to the network, rather than in the common database with other blockchain networks, so as to realize the isolation of this part of the data.

[0064] It can be understood that Figure 4The multi-level tree structure including the blockchain main network and the blockchain subnet shown is only exemplary and represents a possible structural form between the first blockchain network described in this solution and other blockchain networks. In practical applications, the blockchain networks to which multiple blockchain nodes deployed in the node device belong may not follow the above multi-level structural form at all. In other words, in addition to the blockchain main network and the blockchain subnets it manages, the blockchain network to which any blockchain node deployed in the node device described in this solution can also be an independent blockchain network, and there is no such management / being managed relationship between such independent blockchain networks and other blockchain networks. As Figure 1 shown, the independent blockchain network mainnet1 is independent of the aforementioned mainnet0 and subnets subnet1, subnet2, subnet1.1, etc., that is, there is no such management / being managed relationship between mainnet1 and other blockchains as between the blockchain main network and the blockchain subnets. However, cross-chain interaction can also be achieved between any independent blockchain network and other blockchain networks. For example, when nodeF, nodeG, and nodeH in mainnet1 are respectively deployed in the aforementioned node device A, node device B, and node device C, network connection links are respectively established between the above nodes in mainnet1 and nodes nodeA1, nodeB1, and nodeC1 in subnet1. Therefore, the independent blockchain network mainnet1 and the blockchain subnet subnet1 can achieve cross-chain interaction based on the above network connection links. Similarly, the independent blockchain network mainnet1 and the blockchain subnet subnet2 as well as the blockchain main network mainnet0 can also achieve cross-chain interaction based on the corresponding network connection links. Additionally, it is worth noting that even if the node devices where the nodes of any two blockchain networks are located are not completely the same or even completely different, cross-chain interaction between the two blockchain networks can still be achieved based on the inter-device network connection between the node devices where each node is located and other node devices. The specific process will not be elaborated here.

[0065] As mentioned above, multiple blockchain nodes belonging to different blockchain networks can be deployed in the same node device. Among them, in the process of implementing functions such as message consensus and contract execution, any blockchain network may create and maintain corresponding accounts, and the account data of these accounts is usually recorded in the database by the node device. In other words, the node device will maintain the account systems of the blockchain networks to which each blockchain node belongs.

[0066] In this scenario, to manage and utilize the relevant accounts and their data within the blockchain network, node devices and the blockchain nodes deployed within them need to record the account data of each blockchain account in the blockchain network through a database and perform read and write operations on it. In the process of recording account data and performing read and write operations, how to reduce the amount of account data that node devices need to maintain is a pressing issue.

[0067] The inventors discovered that multiple blockchain networks may share the same blockchain accounts. If the account data for these blockchain accounts could be centrally managed and read and written, node devices would only need to maintain one copy of the account data, potentially reducing the amount of account data that nodes need to maintain.

[0068] To this end, this specification proposes a method for reading and writing account data. For multiple blockchain nodes deployed on different blockchain networks, the node device maintains a public database corresponding to the multiple blockchain nodes and uses this database to record the account data of public accounts across the multiple blockchain networks. Based on this data recording method, the node device then responds to read and write requests for target accounts and performs read and write operations on the corresponding account data. The following describes the blockchain subnet creation scheme of this specification with reference to the accompanying figures.

[0069] Figure 6 FIG. 1 is a flowchart of a method for reading and writing account data provided by an exemplary embodiment. Figure 6 As shown, the method is a first blockchain node in a first blockchain network, and the node device where the first blockchain node is located also has blockchain nodes of other blockchain networks deployed, and the node device maintains a public database corresponding to multiple blockchain nodes, and the public database is used to record account data of public accounts between multiple blockchain networks. The method includes the following steps:

[0070] Step 602: Obtain a read / write request for the target account.

[0071] As described above, multiple blockchain nodes are deployed in the node device described in this specification, and each blockchain node belongs to a different blockchain network. In addition, the node device maintains a public database corresponding to multiple blockchain nodes, and this database is used to record the account data of the public accounts between the blockchain networks to which the multiple nodes belong. Among them, the first blockchain node can be any one of the multiple blockchain nodes deployed in the node device. Obviously, the first blockchain network to which this node belongs is any one of the above-mentioned multiple blockchain networks. In addition, the blockchain networks to which the respective blockchain nodes deployed in the node device described in this specification belong can follow the aforementioned multi-level tree structure. For example, the first blockchain network can be any one of the blockchain networks, that is, the first blockchain network can be any blockchain subnet or blockchain main network in the multi-level tree structure.

[0072] Multiple public databases can be maintained in the same node device. Any public database can be used to record the account data of the public accounts between at least two blockchains; or, only one public database can also be maintained in the same node device. This public database can record the account data of the public accounts between any number of blockchains. Moreover, in order to avoid confusion between any public account and the blockchain network to which it corresponds, corresponding network identifiers can be added to the account data of each public account to indicate which blockchain networks each account can be shared by. The public database described in the embodiments of this specification can be any public database maintained by the node device. Any public account recorded in this database can be jointly managed by the blockchain networks corresponding to this account. Correspondingly, the blockchain nodes belonging to the blockchain networks corresponding to this account deployed in the node device can respectively perform read and write operations.

[0073] As Figure 4As shown in the figure, public databases D1 and D2 can be deployed in node device A. Among them, public database D1 can be used to record the account data of the public accounts between subnet1 and subnet2. Public database D2 can be used to record the account data of the public accounts between mainnet0, subnet1 and subnet2. Of course, other public databases can also be deployed to record the account data of the public accounts between subnet1 and subnet2, the account data of the public accounts between subnet2 and subnet1.1, etc. Or, when any node (such as nodeF) in mainnet1 is deployed in node device A, other public databases can also be deployed to record the account data of the public accounts between mainnet0 and mainnet1, the account data of the public accounts between mainnet1, subnet1 and subnet2, etc., which will not be elaborated one by one. Or, a public database D can also be deployed in node device A. Among them, this public database D can be used to record Figure 1 the account data of the public accounts between any number of networks shown in the figure. For example, it can record the account data of the public accounts between subnet1 and subnet2, and can add the network identifiers of these two networks to this part of the account data to indicate that this part of the account data is jointly managed by subnet1 and subnet2. This public database D can also record the account data of the public accounts between mainnet0, subnet1 and subnet2, and can add the network identifiers of these three networks to this part of the account data to indicate that this part of the account data is jointly managed by mainnet0, subnet1 and subnet2, which will not be elaborated.

[0074] It should be noted that for the account data of the public accounts between multiple blockchain networks recorded in any public database, the blockchain nodes of any blockchain network among the multiple blockchain networks can perform read and write operations on this account data. Among them, in the case of performing a write operation, the newly written data can be read by the blockchain nodes of any blockchain network among the multiple blockchain networks. Of course, it can also be changed after other data is rewritten by the blockchain nodes of any blockchain network among the multiple blockchain networks, which will not be elaborated.

[0075] In one embodiment, in addition to public accounts, the first blockchain network may further include independent accounts, that is, the blockchain accounts in the first blockchain network may include two types: public accounts and independent accounts; correspondingly, any blockchain account in the first blockchain network may be a public account or an independent account. Among them, an independent account in any blockchain network is a blockchain account that belongs only to that network, and the account data of this blockchain account is only recorded in the independent database corresponding to that blockchain network, and will not be recorded in other databases. Regarding independent accounts and independent databases, please refer to the detailed description in the following embodiments, and will not be elaborated here for the time being.

[0076] In this embodiment, the above read / write requests for the target account are used to trigger read / write operations on the account data of the target account. Specifically, it may be a data read operation or a data write operation. Among them, the read / write request may include the network identifier of the blockchain network to which the target account belongs (hereinafter referred to as the target blockchain network), so that the first blockchain node can determine which blockchain network should respond to this request accordingly; the read / write request may also include identity information such as the account address and / or public key of the target account, so that the first blockchain node can determine which account the target account is accordingly; the read / write request may further include operation information for the read / write operation on the target account, such as the data identifier of the data to be read, the data to be written, etc., so that the first blockchain node can perform corresponding read / write operations accordingly. It should be noted that from the perspective of the underlying operations of the database, the above data read operation may correspond to the read behavior for data, and the above data write operation may correspond to the behaviors of adding, deleting, and modifying data.

[0077] In addition, the first blockchain node may obtain the above read / write requests in various ways. For example, the first blockchain node may receive the read / write requests obtained and sent by node devices; for another example, the first blockchain node may also receive the read / write requests sent by other blockchain nodes deployed in the node devices (such as blockchain nodes in the first blockchain network or other blockchain networks); in these two ways of obtaining, the read / write requests may be blockchain transactions or non-transaction blockchain messages. For another example, the first blockchain node may also generate the above read / write requests during the execution of blockchain transactions. At this time, the request may be a non-transaction blockchain message, and the embodiments of this specification do not limit this.

[0078] Under normal circumstances, accounts in a blockchain network can include external accounts and contract accounts. Among them, an external account can be controlled by a corresponding public-private key pair, while a contract account can be created by a smart contract and controlled by the corresponding contract code. Any independent account in the first blockchain network may be an external account or a contract account. Therefore, the target account described in this specification can be either an external account or a contract account. Of course, when the number of target accounts is multiple, the multiple target accounts can be multiple external accounts, multiple contract accounts, or at least one external account and at least one contract account. The embodiments of this specification only illustrate any one of the accounts.

[0079] Step 604, when the account data of the target account is recorded in the public database, search for the target account in the public database and perform read and write operations on the account data of the target account.

[0080] In response to the obtained read and write request, the first blockchain node can first determine whether the account data of the target account is recorded in the public database corresponding to the first blockchain network to which it belongs. For example, when the first blockchain node maintains the account addresses of each blockchain account in the first blockchain network, the first blockchain node can determine whether the target account is a blockchain account maintained by itself according to the account address of the target account carried in the read and write request: when the account address of any blockchain account maintained by itself is the same as the account address of the target account, the blockchain account can be determined as the target account; conversely, if the account addresses of each blockchain account maintained by itself are all different from the account address of the target account, it can be determined that the target account does not belong to the first blockchain network, and thus the response process for the read and write request can be terminated.

[0081] When it is determined that the target account is maintained by itself, the first blockchain node can determine the public database corresponding to the first blockchain network according to the correspondence between the network identifier of the first blockchain network and the public database. Furthermore, the first blockchain node can search for the target account in the public database and perform read and write operations on its account data.

[0082] When multiple blockchain nodes belonging to different blockchain networks are deployed in the node device, the node device also maintains public databases corresponding to the multiple blockchain nodes, and this public database is used to record the account data of public accounts between the multiple blockchain networks. Based on this recording method of account data, for the obtained read and write request for the target account, the first blockchain node or the node device can search for the target account in the public database and perform read and write operations on its account data when the account data of the target account is recorded in this public database.

[0083] In the above manner, the node device can store the account data of the public account between different blockchain networks in the public database, and in response to read and write requests for the public account, perform read and write operations on the account data of this account recorded in the public database. It can be seen that multiple blockchain networks can jointly maintain the public account, implementing a shared management solution for the public account, enabling multiple independent blockchain networks to have a shared public account, which simplifies the account system in the multi-blockchain network scenario to a certain extent and helps reduce the workload of the node device in maintaining accounts. Moreover, due to the shared characteristics of the public account, the operation results of the read and write operations performed by the first blockchain network on the account data of the target account can also be used (such as read) by other blockchain networks, thus realizing the unified operation of different blockchain nodes on the same account, which helps improve the management and utilization efficiency of the public account.

[0084] In one embodiment, the above read and write request may be a blockchain transaction containing the account address of the target account. The first blockchain node can determine the independent database in a corresponding manner according to the recording method of the account address in the blockchain transaction and perform read and write operations. As an exemplary embodiment, the account address of the target account may be included in the from field of the blockchain transaction, and this recording method indicates that the above blockchain transaction is initiated by the target account. Thus, the first blockchain node can search for the target account in the public database corresponding to the first blockchain network according to the account address, and read the recorded account public key from the found target account. It can be seen that the read and write operation performed by the first blockchain node is to read the account public key of the target account from the target account, that is, the read and write operation is a data read operation. Among them, the account public key of the target account read in the above manner can be used to verify the transaction signature of the blockchain transaction (that is, verify the transaction signature added by the target account to this transaction). When the verification passes, the first blockchain node can submit this transaction to the first blockchain network to participate in consensus or directly execute this transaction; while when the verification fails, the first blockchain node can terminate the response process for this transaction, and can record, alarm, etc. for this illegal transaction. In this way, the first blockchain node can read the account public key of the target account from the public database recording the account data of the public account in response to the read and write request, and verify the blockchain transaction initiated by the target account based on this public key, which helps ensure the legality and reliability of the blockchain transaction responded by the first blockchain node.

[0085] As another exemplary embodiment, the account address of the target account may be included in the to field of the blockchain transaction, and the input parameter information may also be included in the data field of the transaction. The above recording method of the account address of the target account indicates that the blockchain transaction is initiated by other accounts to the target account. Thus, the first blockchain node may search for the target account in the public database corresponding to the first blockchain network according to the account address, and perform read and write operations on the account data of the found target account according to the input parameter information. Among them, the read and write operation performed by the first blockchain node may be a data read operation. At this time, the input parameter information may be a data read method or information such as a data identifier of the data to be read and the account balance; or, the read and write operation performed by the first blockchain node may also be a data write operation. At this time, the input parameter information may be the data to be written. In this way, the first blockchain node may perform read and write operations on the account data of the target account according to the input parameter information in response to the read and write request, thereby completing the execution process of the above blockchain transaction.

[0086] In one embodiment, the public databases corresponding to multiple blockchain nodes may also be used to record the account data of independent accounts in the blockchain networks to which these blockchain nodes respectively belong, and the account types of each public account and the target account are also recorded in the public databases. In this scenario, the first blockchain node may search for the target account from the public accounts according to the account type. For example, when the account type of the target account is a public account, the first blockchain node may search for the target account from the public accounts recorded in the public database; while when the account type of the target account is an independent account, the first blockchain node may search for the target account from the independent accounts recorded in the public database. In this way, when the first blockchain node searches for the target account among the multiple blockchain accounts maintained by the public database, it may first divide the blockchain accounts to be searched according to the account type, and then search for the target account only from the blockchain accounts of the type to which the target account belongs, which helps to reduce the number of accounts to be searched and improve the search efficiency of the target account.

[0087] In another embodiment, in addition to maintaining the aforementioned common database, the node device may also maintain independent databases corresponding to each blockchain node, and these independent databases are used to record the account data of target accounts in the blockchain network to which the corresponding blockchain node belongs. In this scenario, for the above read / write request obtained by the first blockchain node, the account data of its corresponding target account may be recorded in the common database corresponding to the first blockchain network, or may be recorded in the independent database corresponding to other blockchain networks. In other words, the target account may be a common account or an independent account. Based on this, when the first blockchain node determines that the account type of the target account is a common account, it can search for the target account in the common database and perform read / write operations on its account data. Additionally, when the account type of the target account is an independent account, the first blockchain node can first determine the independent database corresponding to the first blockchain node on the node device, and then search for the target account in this independent database and perform read / write operations on its account data. In this way, the first blockchain node can quickly determine the database that records the account data of the target account according to the account type of the target account, and perform read / write operations on its account data, and the response efficiency of the read / write request is relatively high.

[0088] In addition, when it is determined that the account data of the target account is not recorded in the common database corresponding to the first blockchain node, the first blockchain node may transparently transmit the read / write request to the node device, so that the node device can determine the independent database that records the account data of the target account from the independent databases maintained by itself, and submit this request to the blockchain network corresponding to the determined independent database. It can be understood that the node device can access any database deployed locally, so the node device can access the independent database corresponding to the first blockchain network and the independent databases corresponding to other blockchain networks respectively. Let's denote the blockchain network to which the target account belongs as the target blockchain network. Based on the above method, when the first blockchain node determines that the account data of the target account is not recorded in the common database corresponding to itself, it can transparently transmit this request to the node device, so that the node device can determine the target blockchain network in each blockchain network according to whether the databases corresponding to each blockchain network record the target account, and then submit the above read / write request to the determined network. Of course, after the node device submits the read / write request to the target blockchain network, the blockchain node belonging to this network deployed in the node device can also respond to this request and perform read / write operations on the account data of the target account recorded in the independent database corresponding to this network. The specific process is similar to the execution process of the first blockchain node and will not be elaborated here.

[0089] In this way, by taking advantage of the feature that the node device can access any locally deployed database, even when the account data of the target account is not recorded in the public database corresponding to the first blockchain network, it is still possible to determine, from the independent databases corresponding to each network, the independent database that records the account data of the target account, and then perform read and write operations on the account data in this database, so as to effectively respond to the read and write requests.

[0090] Among them, when the read and write request is a blockchain transaction, the transaction may include an account type field for characterizing the account type of the target account. For example, this account type field may be part of the data field of the blockchain transaction, that is, the account type of the target account is recorded in the data field of this blockchain transaction. Thus, the first blockchain node can determine the account type of the target account according to the field value of the above-mentioned account type field. In this way, the initiator of the blockchain transaction can directly specify the account type of the target account to be operated, so that the first blockchain node can quickly perform read and write operations on the account data according to this account type, which helps to reduce the data maintenance volume of the first blockchain node and improve the response efficiency of the read and write requests.

[0091] As described above, in the case where the account data of the target account is not recorded in the public database corresponding to the first blockchain network, the node device can determine the independent database that records the account data of the target account from the independent databases respectively corresponding to each blockchain node deployed locally. Among them, the node device can determine the independent database in various ways. For example, based on the fact that the node device can access any database maintained by itself, the node device can determine the independent database that records the account data of the target account from all the independent databases maintained by itself. For another example, considering that the first blockchain node in the first blockchain network executes the read and write operations in response to the above read and write requests, the node device can, in the case where the account data of the target account is not recorded in the independent database corresponding to the first blockchain network and the first blockchain network has access rights to the independent databases corresponding to other blockchain networks, determine the independent database that records the account data of the target account from the independent databases corresponding to other blockchain networks. The independent database determined in this way records the account data of the target account, and the first blockchain network has access rights to this database. Naturally, the first blockchain node in the first blockchain network also has access rights. Therefore, the first blockchain node can execute read and write operations on the account data in this database based on this access right. For this independent database, the first blockchain node that performs read and write operations on the account data recorded therein has legal access rights, thus ensuring the legality of the read and write operations implemented. In addition, the first blockchain network may only have access rights to some of the independent databases deployed on the node device. Therefore, to improve the efficiency of determining the independent database that records the account data of the target account, the node device can first determine the part of the independent databases to which the first blockchain network has access rights, and then determine the independent database that records the account data of the target account from this part of the databases.

[0092] Specifically, the node device can maintain the network identifiers of the blockchain networks to which each blockchain node deployed locally belongs, so as to determine which network among the blockchain networks to which each blockchain node deployed locally belongs is the target blockchain network according to the network identifier of the target blockchain network included in the read and write request. The database corresponding to this target blockchain network can be used as the independent database that records the account data of the target account.

[0093] Furthermore, the blockchain networks to which the multiple blockchain nodes deployed on the node device belong respectively can form a multi-level blockchain system, and any one of the blockchain networks can be managed by the parent blockchain network in this multi-level blockchain system. Among them, the independent database corresponding to the first blockchain node can inherit and maintain a copy of the account data of the target account in its parent blockchain network. Among them, the multi-level blockchain system can be in the Figure 4 multi-level tree structure as shown below. The following will be combined with Figure 5The node device A shown is described as follows: For the sake of example, assume that the first blockchain network is subnet1 and the parent blockchain network is mainnet0. When the node device A participates in creating subnet1 based on mainnet0, it can first determine the accounts to be inherited from all the blockchain accounts in mainnet0, then read the account data of the accounts to be inherited from the independent database 0, and write this part of the data into the independent database 1 corresponding to the newly created subnet1, so as to form a copy of the account data of the accounts to be inherited in this database.

[0094] It can be understood that the copy of the account data saved in the above-mentioned independent database 1 is only the account data recorded in mainnet0 at the moment of creating subnet1 (i.e., the moment of reading the account data of the accounts to be inherited from the independent database 0). That is, this data copy can be regarded as a "snapshot" of the account data saved in the independent database 1 at the above-mentioned creation moment. After subnet1 is created, the account data recorded in the independent database 0 can be updated as mainnet0 runs, and the copy of the account data recorded in the independent database 1 can be updated as subnet1 runs, and the update processes of the two are independent of each other. Of course, the node device can also only create each account to be inherited in the independent database 1 corresponding to the newly created subnet1, without copying the corresponding account data copy, so as to only save the account data generated by the running nodes in subnet1 in the independent database 1. Through the above method, the first blockchain network can inherit the original target accounts from its parent blockchain network, or inherit the original target accounts and their account data, so that users do not need to repeatedly create the accounts that already exist in mainnet0 in the newly created subnet1, and each node in subnet1 does not need to obtain account data from other blockchain networks, thus simplifying the creation process of the new network and helping to improve the creation efficiency.

[0095] Alternatively, the above-mentioned first blockchain node can also have access rights to the independent database corresponding to its parent blockchain network. Still taking Figure 4 and Figure 5For example, let's assume that the first blockchain network is subnet1, the parent blockchain network is mainnet0, and nodeA1 in subnet1 is the first blockchain node. Then, the first blockchain node can have access rights to the independent database 0 corresponding to mainnet0. To ensure the security of the account data recorded in the independent database of the parent blockchain network as much as possible, only some nodes may have access rights to the independent database 0. For example, the main node of subnet1 has such access rights, while other nodes do not. Among them, the above-mentioned first blockchain node is a node with access rights to the independent database corresponding to the parent blockchain network. Of course, any node in mainnet0 can also have access rights to the independent database 1 corresponding to subnet1, which will not be elaborated here.

[0096] Based on the description of the foregoing embodiments, this specification also proposes another method for reading and writing account data. As Figure 7 shown, this method should be applied to a node device, in which multiple blockchain nodes belonging to different blockchain networks are deployed, and the node device maintains a common database corresponding to the multiple blockchain nodes. The common database is used to record the account data of the common accounts between the multiple blockchain networks. The method includes the following steps:

[0097] Step 702, obtain a read / write request for a target account.

[0098] Step 704, when the account data of the target account is recorded in the common database, search for the target account in the common database and perform read / write operations on the account data of the target account.

[0099] In one embodiment, the node device also maintains independent databases corresponding to each blockchain node respectively. The independent databases are used to record the account data of the target accounts in the blockchain networks to which the corresponding blockchain nodes belong;

[0100] The searching for the target account in the common database and performing read / write operations on the account data of the target account includes: when the account type of the target account is a common account, searching for the target account in the common database and performing read / write operations on the account data of the target account;

[0101] The method further includes: when the account type of the target account is an independent account, determining the independent database corresponding to the first blockchain node on the node device, searching for the target account in the determined independent database, and performing read / write operations on the account data of the target account.

[0102] In one embodiment, it further includes:

[0103] Receive an assistance request relayed by a first blockchain node in a first blockchain network, where the assistance request is relayed by the first blockchain node when the account data of the target account is not recorded in the public database;

[0104] Determine, from each independent database maintained by itself, an independent database that records the account data of the target account, and submit the assistance request to the blockchain network corresponding to the determined independent database.

[0105] In one embodiment, determining, from each independent database maintained by itself, an independent database that records the account data of the target account includes:

[0106] Determine, from all the independent databases maintained by the node device, an independent database that records the account data of the target account; or,

[0107] In the case where the account data of the target account is not recorded in the independent database corresponding to the first blockchain network and the first blockchain network has access rights to other independent databases corresponding to other blockchain networks, determine, from the other independent databases, an independent database that records the account data of the target account.

[0108] In one embodiment, the blockchain networks to which the multiple blockchain nodes deployed on the node device respectively belong form a multi-level blockchain system, and any blockchain network is managed by the parent blockchain network in the multi-level blockchain system; where:

[0109] The independent database corresponding to the first blockchain node inherits and maintains a copy of the account data of the target account in its parent blockchain network; or,

[0110] The first blockchain node has access rights to the independent database corresponding to its parent blockchain network.

[0111] In one embodiment, the public database is further used to record the account data of the target account in multiple blockchain networks, and the public database also records the account types of each public account and the target account therein; searching for the target account from the public database includes:

[0112] In the case where the account type of the target account is a public account, search for the target account from the public accounts recorded in the public database;

[0113] In the case where the account type of the target account is an independent account, search for the target account from the independent accounts recorded in the public database.

[0114] In one embodiment, the target account includes: an external account and / or a contract account.

[0115] The node device can store the account data of the common account between different blockchain networks in a common database, and in response to a read / write request for the common account, perform read / write operations on the account data of this account recorded in the common database. It can be seen that multiple blockchain networks can jointly maintain the common account, realizing a shared management solution for the common account, enabling multiple independent blockchain networks to have a shared common account, simplifying the account system in the multi-blockchain network scenario to a certain extent, and helping to reduce the workload of the node device for maintaining accounts. Moreover, due to the shared characteristics of the common account, the operation results of the read / write operations performed by the first blockchain network on the account data of the target account can also be used (such as read) by other blockchain networks, thus realizing the unified operation of different blockchain nodes on the same account, which helps to improve the management and utilization efficiency of the common account.

[0116] Figure 8 It is a schematic structural diagram of a device provided by an exemplary embodiment. Please refer to Figure 8 , at the hardware level, the device includes a processor 802, an internal bus 804, a network interface 806, a memory 808, and a non-volatile memory 810. Of course, there may also be other hardware required for other services. One or more embodiments of this specification can be implemented in a software manner. For example, the processor 802 reads the corresponding computer program from the non-volatile memory 810 into the memory 808 and then runs it. Of course, in addition to the software implementation manner, one or more embodiments of this specification do not exclude other implementation manners, such as logic devices or a combination of software and hardware, etc. That is to say, the execution subject of the following processing flow is not limited to each logic unit, and can also be hardware or a logic device.

[0117] Figure 9 It is a block diagram of a read / write device for account data provided by an exemplary embodiment. Please refer to Figure 9 , this device can be applied to the device as shown in Figure 8 to implement the technical solution of this specification. Among them, this read / write device for account data is applied to the first blockchain node in the first blockchain network. There are also blockchain nodes of other blockchain networks deployed in the node device where the first blockchain node is located, and the node device maintains a common database corresponding to multiple blockchain nodes. The common database is used to record the account data of the common account between multiple blockchain networks. The device includes:

[0118] A request acquisition module 901, configured to acquire a read / write request for a target account;

[0119] The first read / write module 902 is used to find the target account from the public database and perform read / write operations on the account data of the target account when the account data of the target account is recorded in the public database.

[0120] Optionally, the read / write request is a blockchain transaction, and the from field of the blockchain transaction contains the account address of the target account; the first read / write module 902 is further used to:

[0121] Find the target account from the public database according to the account address, and read the recorded account public key from the found target account, where the account public key is used to verify the signature of the blockchain transaction.

[0122] Optionally, the data read / write request is a blockchain transaction, the to field of the blockchain transaction contains the account address of the target account, and the data field of the blockchain transaction contains input parameter information; the first read / write module 902 is further used to:

[0123] Find the target account from the public database according to the account address;

[0124] Perform read / write operations on the account data of the found target account according to the input parameter information.

[0125] Optionally, the node device also maintains independent databases corresponding to each blockchain node, and the independent databases are used to record the account data of the target accounts in the blockchain network to which the corresponding blockchain nodes belong;

[0126] The first read / write module 902 is further used to: when the account type of the target account is a public account, find the target account from the public database and perform read / write operations on the account data of the target account;

[0127] The device further includes a second read / write module 903, which is used to: when the account type of the target account is an independent account, determine the independent database corresponding to the first blockchain node on the node device, find the target account from the determined independent database, and perform read / write operations on the account data of the target account.

[0128] Optionally, it further includes:

[0129] A pass-through module 904, which is used to pass the read / write request through to the node device when the account data of the target account is not recorded in the public database, so that the node device determines the independent database that records the account data of the target account from the independent databases it maintains, and then submits the read / write request to the blockchain network corresponding to the determined independent database.

[0130] Optionally, the pass-through module 904 is further configured to:

[0131] Determine an independent database that records the account data of the target account from all the independent databases maintained by the node device; or,

[0132] In the case where the account data of the target account is not recorded in the independent database corresponding to the first blockchain network and the first blockchain network has access rights to the independent databases corresponding to other blockchain networks, determine an independent database that records the account data of the target account from the independent databases corresponding to other blockchain networks.

[0133] Optionally, the blockchain networks to which the multiple blockchain nodes deployed on the node device belong respectively form a multi-level blockchain system, and any blockchain network is managed by the parent blockchain network in the multi-level blockchain system; where:

[0134] The independent database corresponding to the first blockchain node inherits and maintains a copy of the account data of the target account in its parent blockchain network; or,

[0135] The first blockchain node has access rights to the independent database corresponding to its parent blockchain network.

[0136] Optionally, the public database is further configured to record the account data of the target account in multiple blockchain networks, and the public database also records the account types of each public account and the target account therein; the first read / write module 902 is further configured to:

[0137] When the account type of the target account is a public account, search for the target account from the public accounts recorded in the public database;

[0138] When the account type of the target account is an independent account, search for the target account from the independent accounts recorded in the public database.

[0139] Optionally, the data read / write request is a blockchain transaction, and the blockchain transaction includes an account type field. The apparatus further includes:

[0140] A type determination module 905, configured to determine the account type of the target account according to the field value of the account type field.

[0141] Optionally, the target account includes: an external account and / or a contract account.

[0142] Optionally, the target account includes: an external account and / or a contract account.

[0143] Figure 10 is a block diagram of a device for reading and writing account data provided by an exemplary embodiment. Please refer to Figure 10 , this device can be applied to devices such as Figure 8 shown to implement the technical solutions of this specification. Among them, this device for reading and writing account data is applied to a node device, and multiple blockchain nodes belonging to different blockchain networks are deployed in the node device, and the node device maintains a public database corresponding to the multiple blockchain nodes. The public database is used to record the account data of public accounts between multiple blockchain networks. The device includes:

[0144] A request acquisition module 1001, configured to acquire a read / write request for a target account;

[0145] A first read / write module 1002, configured to, when the account data of the target account is recorded in the public database, find the target account in the public database and perform a read / write operation on the account data of the target account.

[0146] Optionally, the node device also maintains independent databases corresponding to each blockchain node respectively. The independent databases are used to record the account data of target accounts in the blockchain networks to which the corresponding blockchain nodes belong;

[0147] The first read / write module 1002 is further configured to: when the account type of the target account is a public account, find the target account in the public database and perform a read / write operation on the account data of the target account;

[0148] The device further includes a second read / write module 1003, configured to: when the account type of the target account is an independent account, determine the independent database corresponding to the first blockchain node on the node device, find the target account in the independent database, and perform a read / write operation on the account data of the target account.

[0149] Optionally, it further includes:

[0150] An assistance request receiving module 1004, configured to receive an assistance request relayed by a first blockchain node in a first blockchain network. The assistance request is relayed by the first blockchain node when the account data of the target account is not recorded in the public database;

[0151] An assistance request submission module 1005, configured to determine the independent database that records the account data of the target account from the independent databases maintained by itself, and submit the assistance request to the blockchain network corresponding to the determined independent database.

[0152] Optionally, the assistance request submission module 1004 is further configured to:

[0153] Determine the independent database that records the account data of the target account from all the independent databases maintained by the node device; or,

[0154] In the case where the account data of the target account is not recorded in the independent database corresponding to the first blockchain network and the first blockchain network has access rights to other independent databases corresponding to other blockchain networks, determine the independent database that records the account data of the target account from the other independent databases.

[0155] Optionally, the blockchain networks to which the multiple blockchain nodes deployed on the node device respectively belong form a multi-level blockchain system, and any blockchain network is managed by the parent blockchain network in the multi-level blockchain system; wherein:

[0156] The independent database corresponding to the first blockchain node inherits and maintains a copy of the account data of the target account in its parent blockchain network; or,

[0157] The first blockchain node has access rights to the independent database corresponding to its parent blockchain network.

[0158] Optionally, the public database is further used to record the account data of the target account in multiple blockchain networks, and the account types of each public account and the target account are also recorded in the public database; the first reading and writing module 1002 is further used for:

[0159] When the account type of the target account is a public account, search for the target account from the public accounts recorded in the public database;

[0160] When the account type of the target account is an independent account, search for the target account from the independent accounts recorded in the public database.

[0161] Optionally, the target account includes: an external account and / or a contract account.

[0162] The system, device, module or unit illustrated in the above embodiments can be specifically implemented by a computer chip or an entity, or by a product with certain functions. A typical implementation device is a computer. Specifically, the computer can be, for example, a personal computer, a laptop computer, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or any combination of these devices.

[0163] For the convenience of description, the above-mentioned device is described by dividing it into various units according to their functions. Of course, when implementing this specification, the functions of each unit can be realized in one or more software and / or hardware.

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

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

[0166] This specification can be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform specific tasks or implement specific abstract data types. This specification can also be practiced in a distributed computing environment where tasks are performed by remote processing devices connected through a communication network. In a distributed computing environment, program modules can be located in local and remote computer storage media including storage devices.

[0167] These computer program instructions can also be stored in a computer-readable memory that can direct a computer or other programmable data processing device to work in a specific manner, so that the instructions stored in the computer-readable memory generate a manufactured article including an instruction device that realizes the functions specified in Figure 1 one or more of the flows Figure 1 or blocks or the combination of blocks.

[0168] These computer program instructions can also be loaded onto a computer or other programmable data processing device, so that a series of operation steps are executed on the computer or other programmable device to generate a computer-implemented process, and thus the instructions executed on the computer or other programmable device provide for implementing the steps of the function specified in the process Figure 1 one process or multiple processes and / or blocks Figure 1 steps of the function specified in one block or multiple blocks. In a typical configuration, a computer includes one or more processors (CPUs), an input / output interface, a network interface, and a memory.

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

[0170] Computer-readable media includes permanent and non-permanent, removable and non-removable media that can store information by any method or technology. The information can be computer-readable instructions, data structures, program modules, 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, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassette tapes, magnetic disk storage, quantum memory, graphene-based storage media or other magnetic storage devices, or any other non-transmission media that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transitory computer-readable media such as modulated data signals and carrier waves.

[0171] It should also be noted that the term "comprising", "including" or any other variant thereof is intended to cover non-exclusive inclusion, so that a process, method, commodity or device comprising a series of elements not only includes those elements, but also includes other elements not expressly listed, or also includes elements inherent to such process, method, commodity or device. Without further limitation, an element defined by the statement "comprising one..." does not exclude the existence of additional identical elements in the process, method, commodity or device comprising the said element.

[0172] The above describes specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the acts or steps recited in the claims may be performed in a different order than in the embodiments and still achieve the desired results. Additionally, the processes depicted in the figures do not necessarily require the particular order shown or sequential order to achieve the desired results. In certain embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0173] The terms used in one or more embodiments of this specification are for the purpose of describing particular embodiments only and are not intended to limit one or more embodiments of this specification. The singular forms "a", "the", and "said" 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 dictates otherwise. It should also be understood that the term "and / or" as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items.

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

[0175] The above is only the preferred embodiment of one or more embodiments of this specification and is not intended to limit one or more embodiments of this specification. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of one or more embodiments of this specification shall be included within the scope of protection of one or more embodiments of this specification.

Claims

1. A method for reading and writing account data, applied to a first blockchain node in a first blockchain network. Other blockchain nodes of other blockchain networks are also deployed in the node device where the first blockchain node is located, and the node device maintains a common database corresponding to multiple blockchain nodes. The common database is used to record the account data of common accounts among multiple blockchain networks. The common accounts are jointly managed by the multiple blockchain networks and shared by the multiple blockchain networks. The method includes: Obtain a read / write request for a target account; When the account data of the target account is recorded in the common database, search for the target account in the common database and perform read / write operations on the account data of the target account.

2. The method according to claim 1, wherein the read / write request is a blockchain transaction, and the from field of the blockchain transaction contains the account address of the target account. The searching for the target account in the common database and performing read / write operations on the account data of the target account includes: Search for the target account in the common database according to the account address, and read the recorded account public key from the found target account. The account public key is used to verify the transaction signature of the blockchain transaction.

3. According to the method described in claim 1, the data read / write request is a blockchain transaction, the to field of the blockchain transaction contains the account address of the target account, and the data field of the blockchain transaction contains input parameter information; The searching for the target account in the common database and performing read / write operations on the account data of the target account includes: Search for the target account in the common database according to the account address; Perform read / write operations on the account data of the found target account according to the input parameter information.

4. The method according to claim 1, wherein the node device also maintains independent databases corresponding to each blockchain node respectively. The independent databases are used to record the account data of target accounts in the blockchain networks to which the corresponding blockchain nodes belong; Finding the target account from the public database and performing read and write operations on the account data of the target account includes: When the account type of the target account is a common account, search for the target account in the common database and perform read / write operations on the account data of the target account; The method further includes: when the account type of the target account is an independent account, determine the independent database corresponding to the first blockchain node on the node device, search for the target account in the independent database, and perform read / write operations on the account data of the target account.

5. The method according to claim 4, further includes: When the account data of the target account is not recorded in the common database, transparently transmit the read / write request to the node device, so that the node device determines the independent database that records the account data of the target account from the independent databases it maintains, and then submits the read / write request to the blockchain network corresponding to the determined independent database.

6. The method according to claim 5, wherein the node device determines the independent database that records the account data of the target account from the independent databases it maintains, including: Determine the independent database that records the account data of the target account from all the independent databases maintained by the node device; Or, When the account data of the target account is not recorded in the independent database corresponding to the first blockchain network and the first blockchain network has access rights to the independent databases corresponding to other blockchain networks, determine the independent database that records the account data of the target account from the independent databases corresponding to other blockchain networks.

7. The method according to claim 6, wherein the blockchain networks to which the multiple blockchain nodes deployed on the node device belong respectively form a multi-level blockchain system, and any blockchain network is managed by the parent blockchain network in the multi-level blockchain system; wherein: The independent database corresponding to the first blockchain node inherits and maintains a copy of the account data of the target account in its parent blockchain network; or, The first blockchain node has access rights to the independent database corresponding to its parent blockchain network.

8. The method according to claim 1, wherein the public database is further configured to record the account data of the target account in multiple blockchain networks, and the account types of each public account and the target account are also recorded in the public database; the step of finding the target account from the public database includes: When the account type of the target account is a public account, find the target account from the public accounts recorded in the public database; When the account type of the target account is an independent account, find the target account from the independent accounts recorded in the public database.

9. The method according to claim 4 or 8, wherein the data read / write request is a blockchain transaction, and the blockchain transaction includes an account type field, and the method further includes: Determine the account type of the target account according to the field value of the account type field.

10. The method according to claim 1, wherein the target account comprises: External account and / or contract account.

11. A method for reading and writing account data, which is applied to a node device. Multiple blockchain nodes belonging to different blockchain networks are deployed in the node device, and the node device maintains a public database corresponding to the multiple blockchain nodes. The public database is used to record the account data of the public accounts among the multiple blockchain networks. The public accounts are jointly managed by the multiple blockchain networks and shared by the multiple blockchain networks; the method includes: Obtain a read / write request for a target account; When the account data of the target account is recorded in the public database, find the target account from the public database and perform read / write operations on the account data of the target account.

12. The method according to claim 11, wherein the node device further maintains independent databases corresponding to each blockchain node respectively. The independent databases are used to record the account data of the target accounts in the blockchain networks to which the corresponding blockchain nodes belong; Searching for the target account from the public database and performing read and write operations on the account data of the target account, including: When the account type of the target account is a public account, find the target account from the public database and perform read / write operations on the account data of the target account; The method further includes: when the account type of the target account is an independent account, determining an independent database corresponding to the first blockchain node on the node device, and searching for the target account from the determined independent database and performing read and write operations on the account data of the target account.

13. The method according to claim 12, further includes: receiving an assistance request relayed by a first blockchain node in the first blockchain network, where the assistance request is relayed by the first blockchain node when the account data of the target account is not recorded in the public database; determining an independent database that records the account data of the target account from each of the independently maintained databases, and submitting the assistance request to the blockchain network corresponding to the determined independent database.

14. The method according to claim 13, where the determining an independent database that records the account data of the target account from each of the independently maintained databases includes: determining an independent database that records the account data of the target account from all the independently maintained databases maintained by the node device; or when the account data of the target account is not recorded in the independent database corresponding to the first blockchain network and the first blockchain network has access rights to other independent databases corresponding to other blockchain networks, determining an independent database that records the account data of the target account from the other independent databases.

15. The method according to claim 14, where the blockchain networks to which the multiple blockchain nodes deployed on the node device belong respectively form a multi-level blockchain system, and any blockchain network is managed by the parent blockchain network in the multi-level blockchain system; where: the independent database corresponding to the first blockchain node inherits and maintains a copy of the account data of the target account in its parent blockchain network; or the first blockchain node has access rights to the independent database corresponding to its parent blockchain network.

16. The method according to claim 11, where the public database is further used to record the account data of the target account in multiple blockchain networks, and the public database also records the account types of each public account and target account therein; the searching for the target account from the public database includes: when the account type of the target account is a public account, searching for the target account from the public accounts recorded in the public database; when the account type of the target account is an independent account, searching for the target account from the independent accounts recorded in the public database.

17. The method according to claim 11, wherein the target account comprises: External account and / or contract account.

18. A device for reading and writing account data, which is applied to a first blockchain node in a first blockchain network. Other blockchain nodes of other blockchain networks are also deployed in the node device where the first blockchain node is located, and the node device maintains a public database corresponding to multiple blockchain nodes. The public database is used to record the account data of public accounts among multiple blockchain networks, and the public accounts are jointly managed and shared by the multiple blockchain networks; the device includes: A request acquisition module, configured to acquire read / write requests for a target account; A first read / write module, configured to, when the account data of the target account is recorded in the public database, search for the target account in the public database and perform read / write operations on the account data of the target account.

19. A read / write device for account data, applied to a node device, where multiple blockchain nodes belonging to different blockchain networks are deployed in the node device, and the node device maintains a public database corresponding to the multiple blockchain nodes. The public database is used to record the account data of public accounts between the multiple blockchain networks. The public accounts are jointly managed by the multiple blockchain networks and shared by the multiple blockchain networks. The device includes: A request acquisition module, configured to acquire read / write requests for a target account; A first read / write module, configured to, when the account data of the target account is recorded in the public database, search for the target account in the public database and perform read / write operations on the account data of the target account.

20. An electronic device, including: A processor; A memory for storing instructions executable by the processor; Wherein, the processor realizes the method according to any one of claims 1-17 by running the executable instructions.

21. A computer-readable storage medium, on which computer instructions are stored, and when the instructions are executed by a processor, the steps of the method according to any one of claims 1-17 are realized.

Images