A blockchain account model storage method, system and device

Abstract

The application provides a blockchain account model storage method, system and device, relates to the field of blockchain account model storage, and comprises the following steps: a storage proposal is submitted by a blockchain governance committee; the storage proposal is used for defining a mapping relationship between a storage identifier and a storage hierarchical database; the storage identifier is an attribute hash value of an account; the attributes of the account include date, customer type and business domain; a Merkle tree is constructed based on the storage proposal, and a corresponding new storage hierarchical database of the Merkle tree is constructed; when a transaction is performed, it is judged whether the transaction provides an attribute hash value of a to-be-classified account; if yes, based on the storage proposal, the new storage hierarchical database corresponding to the attribute hash value of the to-be-classified account is determined, the Merkle tree is loaded, and the transaction information is stored in the loaded Merkle tree; and if no, the transaction information is stored in a default account tree. The application saves storage cost.

Description

Technical Field

[0001] This invention relates to the field of blockchain account model storage, and in particular to a blockchain account model storage method, system and device. Background Technology

[0002] As applications within the blockchain ecosystem continue to grow, the amount of data in the blockchain ledger is also increasing. The blockchain ledger stores historical transaction records for all individuals and contract addresses. Most implementations use the SHA3-256 hash of the data as the key and store it in key-value databases like LevelDB. To prevent double-spending, the nonce corresponding to each address is incremented for each transaction, resulting in a different storage key value. This leads to an ever-growing storage system, potentially requiring petabytes of storage space when transaction values ​​reach tens of millions. In most consortium blockchains, it's essential to differentiate between historical and frequently used transaction addresses to improve performance and save storage costs. For example, in a bank's supply chain finance system, transactions on-chain can be categorized by business domain attributes such as time, customer type, and region. If these attributes are not differentiated and all are uniformly stored in the account model and storage system, it will incur significant storage costs and slow down transaction performance.

[0003] In existing technologies, account models are stored using Merkle trees, or StateTrieTrees. When constructing a Merkle tree, leaf nodes represent account addresses, while the root node and non-leaf nodes are the combined hash values ​​of all child nodes. When node information is stored in a key-value database (DB), the value is taken as the corresponding bytes array, and the key is the hash value of that bytes array. Therefore, with each transaction, the account nonce changes, the corresponding value changes, and a new key is added, causing the Merkle tree to be constantly updated. Even if the Merkle tree doesn't grow, the storage space and storage costs will continuously increase. Summary of the Invention

[0004] The purpose of this invention is to provide a method, system, and device for storing blockchain account models to solve the problem of high storage costs.

[0005] To achieve the above objectives, the present invention provides the following solution:

[0006] A blockchain account model storage method, comprising:

[0007] A storage proposal is submitted by the Blockchain Governance Committee; the storage proposal is used to define the mapping relationship between storage identifiers and storage hierarchy databases; the storage identifier is the attribute hash value of an account; the attributes of the account include date, customer type, and business domain;

[0008] Based on the storage proposal, a Merkle tree is constructed, and a new storage hierarchy database corresponding to the Merkle tree is constructed.

[0009] When conducting a transaction, determine whether the transaction provides the attribute hash value of the account to be tiered;

[0010] If so, based on the storage proposal, determine the new storage tier database corresponding to the attribute hash value of the account to be tiered, load the Merkle tree, and store the transaction information in the loaded Merkle tree;

[0011] If not, store the transaction information in the default account tree.

[0012] Optionally, a storage proposal may be submitted by the Blockchain Governance Committee, which may then include:

[0013] The blockchain governance committee will vote to determine whether the storage proposal passes.

[0014] If so, if the storage proposal is confirmed, the transaction hash value of the storage proposal is used as the Merkle tree root, and the first 20 bits of the attribute hash value sequence arranged from largest to smallest are stored as addresses in the default account tree; wherein, the storage content is a byte array of all attribute hash values; the primary key corresponding to the storage content is stored in the title library;

[0015] If not, the storage proposal is determined to be invalid, and the operation ends.

[0016] Optionally, a Merkle tree is constructed based on the storage proposal, and a new storage hierarchy database corresponding to the Merkle tree is constructed, specifically including:

[0017] The blockchain governance committee submits a storage addition proposal; the storage addition proposal is used to define the operation of adding the storage identifier.

[0018] The blockchain governance committee will vote to determine whether the proposed addition of storage is approved.

[0019] If so, confirm that the proposed storage addition is valid, and create a Merkle tree on each node of the blockchain;

[0020] The Merkle tree is attached to the root of the Merkle tree, and a new storage hierarchy database corresponding to the Merkle tree is created; wherein, the root value of the Merkle tree is the attribute hash value of the new account;

[0021] If not, the proposed storage addition is deemed invalid, and the operation ends.

[0022] Optionally, the Merkle tree is attached to the root of the Merkle tree, and a new storage hierarchy database corresponding to the Merkle tree is created. This process also includes:

[0023] Update the Merkle tree root and update the root value of the Merkle tree to the default account tree.

[0024] Optionally, based on the storage proposal, a new storage tier database corresponding to the attribute hash value of the account to be tiered is determined, and the Merkle tree is loaded. The transaction information is then stored in the loaded Merkle tree, specifically including:

[0025] The attribute hash value of the account to be classified is used as the classification identifier of the underlying storage;

[0026] Based on the classification identifier and the mapping relationship defined in the storage proposal, determine the new storage classification database corresponding to the attribute hash value of the account to be classified;

[0027] Load the Merkle tree corresponding to the newly added storage hierarchical database, and store the transaction information in the loaded Merkle tree;

[0028] Based on the storage operation, update the Merkle tree and Merkle tree root corresponding to the newly added storage hierarchy database.

[0029] Optionally, based on the storage proposal, a new storage tier database corresponding to the attribute hash value of the account to be tiered is determined, and the Merkle tree is loaded. The transaction information is stored in the loaded Merkle tree. This process further includes:

[0030] When the transaction volume exceeds the set transaction volume, the blockchain governance committee submits a storage modification proposal; the storage modification proposal is used to optimize the storage representation.

[0031] The blockchain governance committee will vote to determine whether the storage modification proposal is approved.

[0032] If so, the storage modification proposal is confirmed, and each node in the blockchain automatically performs the modification operation; the modification operation includes deleting or taking offline the storage hierarchy database corresponding to the attribute hash value of any of the accounts;

[0033] Update the Merkle root tree according to the modification operation;

[0034] If not, the storage modification proposal is determined to be invalid, and the operation ends.

[0035] A blockchain account model storage system, comprising:

[0036] The storage proposal submission module is used by the blockchain governance committee to submit storage proposals; the storage proposal is used to define the mapping relationship between storage identifiers and storage hierarchy databases; the storage identifier is the attribute hash value of an account; the attributes of the account include date, customer type, and business domain;

[0037] The construction module is used to construct a Merkle tree based on the storage proposal and to construct the new storage hierarchy database corresponding to the Merkle tree;

[0038] The first judgment module is used to determine whether the transaction provides the attribute hash value of the account to be tiered during the transaction process;

[0039] The addition and loading module is used to, if so, determine the new storage tier database corresponding to the attribute hash value of the account to be tiered based on the storage proposal, and load the Merkle tree to store the transaction information in the loaded Merkle tree;

[0040] The storage module is used to store the transaction information in the default account tree if necessary.

[0041] Optional, also includes:

[0042] The second judgment module is used for the blockchain governance committee to vote on whether the storage proposal is passed.

[0043] The Merkel root construction module is used to determine if the storage proposal is valid, using the transaction hash value of the storage proposal as the Merkel root, and storing the first 20 bits of the attribute hash value sequence arranged from largest to smallest as addresses into the default account tree; wherein, the storage content is a byte array of all attribute hash values; and storing the primary key corresponding to the storage content into the title library;

[0044] The operation termination module is used to determine if the storage proposal is invalid and terminate the operation.

[0045] An electronic device includes a memory and a processor, the memory being used to store a computer program, and the processor running the computer program to cause the electronic device to perform the blockchain account model storage method described above.

[0046] A computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described blockchain account model storage method.

[0047] According to specific embodiments provided by the present invention, the present invention discloses the following technical effects: The present invention provides a blockchain account model storage method, system and device. Based on the attributes of the account, and according to the mapping relationship between the attribute hash value of the account and the storage hierarchical database, the underlying data storage is segmented without affecting the upper layer application, and a Merkle tree and its corresponding storage hierarchical database are constructed. This satisfies the business segmentation requirements such as distinguishing historical data according to storage level, greatly saves storage costs and improves blockchain performance. Attached Figure Description

[0048] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0049] Figure 1 This is a flowchart of the blockchain account model storage method provided by the present invention;

[0050] Figure 2 This is an execution diagram of the blockchain account model storage method provided by the present invention;

[0051] Figure 3 This is a schematic diagram of the main modules provided by the present invention. Detailed Implementation

[0052] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0053] The purpose of this invention is to provide a method, system, and device for storing blockchain account models, which saves storage costs.

[0054] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0055] Example 1

[0056] like Figure 1 As shown, the present invention provides a blockchain account model storage method, including:

[0057] Step 101: The Blockchain Governance Committee submits a storage proposal; the storage proposal is used to define the mapping relationship between storage identifiers and storage hierarchy databases; the storage identifier is the attribute hash value of the account; the attributes of the account include date, customer type, and business domain.

[0058] In practical applications, after step 101, the following steps are also included: the blockchain governance committee votes to determine whether the storage proposal is passed; if so, the storage proposal is determined to be valid, and the transaction hash value of the storage proposal is used as the Merkle tree root, and the first 20 bits of the attribute hash value sequence arranged from largest to smallest are stored as addresses in the default account tree; wherein, the storage content is a byte array of all attribute hash values; the primary key corresponding to the storage content is stored in the title library (DB_issue); if not, the storage proposal is determined to be invalid, and the operation ends.

[0059] Step 102: Construct a Merkle tree based on the storage proposal, and construct the new storage hierarchy database corresponding to the Merkle tree.

[0060] In practical applications, step 102 specifically includes: the blockchain governance committee submitting a storage addition proposal; the storage addition proposal defining the addition operation for the storage identifier; the blockchain governance committee voting to determine whether the storage addition proposal passes; if yes, the storage addition proposal is determined to be valid, and a Merkle tree is created on each node of the blockchain; the Merkle tree is attached to the root of the Merkle tree, and a corresponding new storage hierarchy database is created; wherein, the root value of the Merkle tree is the attribute hash value of the newly added account; if no, the storage addition proposal is determined to be invalid, and the operation ends.

[0061] In practical applications, the Merkle tree is attached to the root of the Merkle tree, and a new storage hierarchy database corresponding to the Merkle tree is created. The process also includes updating the root of the Merkle tree and updating the root value of the Merkle tree to the default account tree.

[0062] Step 103: When conducting a transaction, determine whether the transaction provides the attribute hash value of the account to be tiered. If yes, proceed to step 104; otherwise, proceed to step 105.

[0063] Step 104: Based on the storage proposal, determine the new storage tier database corresponding to the attribute hash value of the account to be tiered, load the Merkle tree, and store the transaction information in the loaded Merkle tree.

[0064] In practical applications, step 104 specifically includes: using the attribute hash value of the account to be classified as the classification identifier of the underlying storage; determining the new storage classification database corresponding to the attribute hash value of the account to be classified according to the classification identifier and the mapping relationship defined by the storage proposal; loading the Merkle tree corresponding to the new storage classification database and storing the transaction information in the loaded Merkle tree; and updating the Merkle tree and Merkle tree root corresponding to the new storage classification database according to the storage operation.

[0065] In practical applications, after step 104, the following steps are also included: when the transaction volume exceeds a set transaction volume, the blockchain governance committee submits a storage modification proposal; the storage modification proposal is used to optimize the storage representation; the blockchain governance committee votes to determine whether the storage modification proposal passes; if yes, the storage modification proposal is determined to be valid, and each node in the blockchain automatically executes the modification operation; the modification operation includes deleting or taking offline the storage hierarchy database corresponding to the attribute hash value of any of the accounts; updating the Merkle root according to the modification operation; if no, the storage modification proposal is determined to be invalid, and the operation ends.

[0066] Step 105: Store the transaction information in the default account tree.

[0067] This invention enables account transaction storage hierarchies based on date attribute, account transaction storage hierarchies based on customer type, account transaction storage hierarchies based on business domain, quasi-online and offline deletion of historical account transaction data, and account hierarchical storage capabilities for decision-making by the blockchain governance committee.

[0068] Example 2

[0069] Definition 1: First, assume an account has attribute values ​​P{p_0,p_1,p_2,…,p_r}, with a total of r attributes, where r is a natural number greater than 1 or 0. If r = 0, it means that the address does not have hierarchical storage, and queries and usage will use the default DB. If r = 1, it is an error. If r > 1, calculate the hash value H = sha3({P}) of the attribute as the hierarchical identifier of the underlying storage. Based on this identifier and the mapping relationship allowed by the governance committee, find the corresponding DB_i, where p_0 is the root address of the attribute category.

[0070] Applying the method corresponding to Embodiment 1 above to actual operation, such as... Figure 2 As shown, the operation process is as follows:

[0071] Step 1: Storage Tier Proposal.

[0072] 1. First, the Blockchain Governance Committee submits a storage proposal, Issue = map{H,DB,DB_default}, which defines the mapping relationship between the storage identifier H and the storage hierarchy DB.

[0073] 2. If the Blockchain Governance Committee does not approve, the process ends; otherwise, proceed to step 3.

[0074] 3. After the Blockchain Governance Committee approves the issue through blockchain voting, the issue is established. The transaction hash of the issue is used as a brand new Merkle Tree Root (MTR_Issue). The first 20 bits of the hash are used as the address and stored in the default account tree. The content of the stored information, Value, is a combination of bytes arrays of all {H}, and the corresponding primary key Key = Sha3(Value) is stored in the newly opened title library.

[0075] 4. For each key-value pair (K=H, V=DB) added to IssueMap, where K=Sha3(db_name), it is necessary to submit the new storage pair proposal in step 2 and update it to the default Merkle tree.

[0076] Step 2: Add a new storage proposal.

[0077] 5. When a storage DB needs to be added, the Blockchain Governance Committee first submits a storage addition proposal Issue_New({H}), which defines the operation of adding storage identifiers to the storage identifier set {H}.

[0078] 6. If the blockchain governance committee approves a resolution by blockchain vote, the process ends; otherwise, proceed to the next step.

[0079] 7. If Issue_New is established, each node in the blockchain creates a Merkle tree, where Root_i = H_i, and attaches it to MTR_Issue, while also creating the corresponding DB_i; otherwise, the process ends.

[0080] 8. Update the content of MTR_Issue and update the Root value to the default Merkle tree. That is, when calculating the block state tree root, the default account state tree StateTrieTree will also change and record this information.

[0081] Step 3: Tiered storage.

[0082] 9. Query operation:

[0083] a. When submitting a query, you need to provide the attribute hash value of the account, or the attribute list P = {p}. According to definition 1, find the corresponding DB_i.

[0084] b. Load the corresponding Merkle subtree from DB_i, find and return the relevant information for that address.

[0085] 10. Transaction Execution Operation: To begin storing transactions for each block for each account that requires tiered storage, follow these steps.

[0086] c. First, determine whether the transaction provides an extended attribute hash or list {P} of the account. If not, proceed with the default account tree; otherwise, continue.

[0087] d. The hash value H = sha3(P) of the computed attribute serves as the hierarchical identifier of the underlying storage. Based on this identifier and the mapping relationship allowed by the governance committee, the corresponding DB_i can be found.

[0088] e. Obtain the Merkle hash tree from DB_i. Keep the Merkle tree operation algorithm of the account model unchanged. When storing the transaction, obtain the storage level DB_i based on the account hash value H_i and store the transaction body in DB_i.

[0089] f. After the block execution is completed, the Merkle tree of DB_i is finally updated, and then updated to MTR_Issue, which in turn updates the unique StateTrieRoot of the entire block.

[0090] Step 4: Storage and recycling.

[0091] 11. When the transaction volume is too large, it is necessary to delete or take offline the DB corresponding to a certain H. Then the Blockchain Governance Committee submits a storage modification proposal Issue_Mod({H}), which defines the proposal to optimize the storage identifier set {H}.

[0092] 12. Determine the blockchain governance committee's voting results. If the decision is not approved, the process ends; otherwise, proceed to the next step.

[0093] 13. Once Issue_Mod is established, each node in the blockchain automatically performs operations, including deleting or taking the corresponding DB offline, and updating it to MTR_Issue, which in turn updates the unique StateTrieRoot of the entire block.

[0094] Since each transaction operation includes the operation domain attribute {P}, it determines the range of data that can be manipulated. Only the second step (operation outside the second step) will not affect the default database, and the second step is often the most frequently executed.

[0095] In the second step, each transaction only affects the corresponding DB_i. When updating an MTR_Issue, it only affects the header database of that issue; multiple addresses only affect the corresponding DB_i. Even with the addition of a new address, there will be no increase in data in the default DB of the entire account model. Therefore, when storage reclamation is performed in the fourth step, deleting or taking the corresponding DB_i offline will not affect the overall StateTrieRoot, and the consensus of the blockchain's node states can remain consistent.

[0096] In practical applications, such as Figure 3 As shown, the main modules of this invention include:

[0097] A: Merkle tree, mainly maintains information about the Merkle tree, including node addition, updates, and calculation of the final hash root RootHash.

[0098] B: Merkle tree management, mainly the default Merkle state tree StateTrieRoot and the Issue subtrees for various submissions.

[0099] C: Blockchain Governance Decentralized Autonomous Organization (DAO) Management: Primarily responsible for maintaining Issue proposals.

[0100] Step C includes:

[0101] C01: The Issue collection MapSet contains a mapping table of address attribute hash values ​​and DB_i information, and this information has reached a consensus with all nodes.

[0102] C02: PBFT voting device, which votes on existing network nodes when a new proposal occurs, forming a Byzantine fault-tolerant voting result.

[0103] C03: Issue executor, which performs the corresponding DB add, delete, and modify operations when a proposal is passed.

[0104] D: DB Pool Cache: Maintain connection pools for multiple databases based on the hash value of the DB.

[0105] This invention enables hierarchical maintenance of transaction storage based on account date attributes; hierarchical maintenance of transaction storage based on account customer class attributes; hierarchical maintenance of transaction storage based on account business domain attributes; and storage classification maintenance of governance nodes in blockchain governance DAO schemes.

[0106] Example 3

[0107] In order to implement the method corresponding to Embodiment 1 above and achieve the corresponding functions and technical effects, a blockchain account model storage system is provided below.

[0108] A blockchain account model storage system, comprising:

[0109] The storage proposal submission module is used by the blockchain governance committee to submit storage proposals; the storage proposal is used to define the mapping relationship between storage identifiers and storage hierarchy databases; the storage identifier is the attribute hash value of an account; the attributes of the account include date, customer type, and business domain.

[0110] The construction module is used to construct a Merkle tree based on the storage proposal and to construct the new storage hierarchy database corresponding to the Merkle tree.

[0111] The first judgment module is used to determine whether the transaction provides the attribute hash value of the account to be tiered during the transaction process.

[0112] The addition and loading module is used to, if so, determine the new storage tier database corresponding to the attribute hash value of the account to be tiered based on the storage proposal, load the Merkle tree, and store the transaction information in the loaded Merkle tree.

[0113] The storage module is used to store the transaction information in the default account tree if necessary.

[0114] In practical applications, the present invention further includes: a second judgment module, used by the blockchain governance committee to vote on whether the storage proposal is passed; a Merkel root construction module, used to determine if the storage proposal is valid if so, using the transaction hash value of the storage proposal as the Merkel root, and storing the first 20 bits of the attribute hash value sequence arranged from largest to smallest as addresses in the default account tree; wherein the storage content is a byte array of all attribute hash values; storing the primary key corresponding to the storage content in the title library; and an operation termination module, used to determine if the storage proposal is invalid if so, and terminate the operation.

[0115] Example 4

[0116] This invention provides an electronic device including a memory and a processor. The memory stores a computer program, and the processor runs the computer program to enable the electronic device to execute the blockchain account model storage method provided in Embodiment 1.

[0117] In practical applications, the aforementioned electronic devices can be servers.

[0118] In practical applications, electronic devices include: at least one processor, memory, bus, and communication interface.

[0119] The processor, communication interface, and memory communicate with each other via a communication bus.

[0120] A communication interface is used to communicate with other devices.

[0121] The processor is used to execute programs, specifically the methods described in the above embodiments.

[0122] Specifically, the program may include program code, which includes computer operation instructions.

[0123] The processor may be a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to implement embodiments of the present invention. The electronic device may include one or more processors of the same type, such as one or more CPUs; or it may include processors of different types, such as one or more CPUs and one or more ASICs.

[0124] Memory is used to store programs. Memory may include high-speed RAM, and may also include non-volatile memory, such as at least one disk drive.

[0125] Based on the description of the above embodiments, this application provides a storage medium storing computer program instructions thereon, which can be executed by a processor to implement the methods described in any embodiment.

[0126] The blockchain account model storage system provided in this application exists in various forms, including but not limited to:

[0127] (1) Mobile communication devices: These devices are characterized by their mobile communication capabilities and primarily aim to provide voice and data communication. These terminals include: smartphones (e.g., iPhones), multimedia phones, feature phones, and low-end phones, etc.

[0128] (2) Ultra-mobile personal computer devices: These devices fall under the category of personal computers, possessing computing and processing capabilities, and generally also have mobile internet access capabilities. These terminals include PDAs, MIDs, and UMPCs, such as the iPad.

[0129] (3) Portable entertainment devices: These devices can display and play multimedia content. This category includes: audio and video players (such as iPods), handheld game consoles, e-books, as well as smart toys and portable car navigation devices.

[0130] (4) Other electronic devices with data interaction functions.

[0131] Specific embodiments of the subject matter have now been described. Other embodiments are within the scope of the appended claims. In some cases, the actions described in the claims can be performed in a different order and still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require a specific or sequential order to achieve the desired result. In some embodiments, multitasking and parallel processing can be advantageous.

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

[0133] For ease of description, the above apparatus is described by dividing it into various functional units. Of course, in implementing this application, the functions of each unit can be implemented in one or more software and / or hardware components. Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application 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.) containing computer-usable program code.

[0134] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create a machine for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0135] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0136] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

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

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

[0139] Computer-readable media, including both permanent and non-permanent, removable and non-removable media, can store information using any method or technology. Information can be computer-readable instructions, data structures, 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, and CD-ROM.

[0140] Digital multifunction optical disc (DVD) or other optical storage, magnetic cassette tape, magnetic tape, disk storage or other magnetic storage devices

[0141] Or any other non-transmission medium that can be used to store information that can be accessed by a computing device. As defined herein, computer-readable media does not include transient media, such as modulated data signals and carrier waves.

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

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

[0144] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the systems disclosed in the embodiments, since they correspond to the methods disclosed in the embodiments, the descriptions are relatively simple; relevant parts can be referred to the method section.

[0145] This document uses specific examples to illustrate the principles and implementation methods of the present invention. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of the present invention. Furthermore, those skilled in the art will recognize that, based on the ideas of the present invention, there will be changes in the specific implementation methods and application scope. Therefore, the content of this specification should not be construed as a limitation of the present invention.

Claims

1. A blockchain account model storage method, characterized in that, include: The storage proposal was submitted by the Blockchain Governance Committee; The storage proposal is used to define the mapping relationship between storage identifiers and storage hierarchy databases; The storage identifier is the attribute hash value of the account; the account attributes include date, customer type, and business domain; The blockchain governance committee will vote to determine whether the storage proposal passes. If so, if the storage proposal is confirmed, the transaction hash value of the storage proposal is used as the Merkle tree root, and the first 20 bits of the attribute hash value sequence arranged from largest to smallest are stored as addresses in the default account tree; wherein, the storage content is a byte array of all attribute hash values; the primary key corresponding to the storage content is stored in the title library; If not, the storage proposal is determined to be invalid, and the operation ends; Based on the storage proposal, a Merkle tree is constructed, and a new storage hierarchy database corresponding to the Merkle tree is constructed. When conducting a transaction, determine whether the transaction provides the attribute hash value of the account to be tiered; If so, based on the storage proposal, determine the new storage tier database corresponding to the attribute hash value of the account to be tiered, load the Merkle tree, and store the transaction information in the loaded Merkle tree; If not, store the transaction information in the default account tree. 2.The method of claim 1, wherein, Based on the storage proposal, a Merkle tree is constructed, and a new storage hierarchy database corresponding to the Merkle tree is constructed, specifically including: The blockchain governance committee submits a storage addition proposal; the storage addition proposal is used to define the operation of adding the storage identifier. The blockchain governance committee will vote to determine whether the proposed addition of storage is approved. If so, confirm that the proposed storage addition is valid, and create a Merkle tree on each node of the blockchain; The Merkle tree is attached to the root of the Merkle tree, and a new storage hierarchy database corresponding to the Merkle tree is created; wherein, the root value of the Merkle tree is the attribute hash value of the new account; If not, the proposed storage addition is deemed invalid, and the operation ends. 3.The method of claim 2, wherein, The Merkle tree is attached to the root of the Merkle tree, and a new hierarchical storage database corresponding to the Merkle tree is created. This process also includes: Update the Merkle tree root and update the root value of the Merkle tree to the default account tree.

4. The method of claim 1-3, wherein, Based on the storage proposal, the new storage tier database corresponding to the attribute hash value of the account to be tiered is determined, and the Merkle tree is loaded. The transaction information is then stored in the loaded Merkle tree, specifically including: The attribute hash value of the account to be classified is used as the classification identifier of the underlying storage; Based on the classification identifier and the mapping relationship defined in the storage proposal, determine the new storage classification database corresponding to the attribute hash value of the account to be classified; Load the Merkle tree corresponding to the newly added storage hierarchical database, and store the transaction information in the loaded Merkle tree; Based on the storage operation, update the Merkle tree and Merkle tree root corresponding to the newly added storage hierarchy database. 5.The method of claim 4, wherein, Based on the storage proposal, the new storage tier database corresponding to the attribute hash value of the account to be tiered is determined, and the Merkle tree is loaded. The transaction information is stored in the loaded Merkle tree, followed by: When the transaction volume exceeds the set transaction volume, the blockchain governance committee submits a storage modification proposal; the storage modification proposal is used to optimize the storage identifier. The blockchain governance committee will vote to determine whether the storage modification proposal is approved. If so, the storage modification proposal is confirmed, and each node in the blockchain automatically performs the modification operation; the modification operation includes deleting or taking offline the storage hierarchy database corresponding to the attribute hash value of any of the accounts; Update the Merkle root tree according to the modification operation; If not, the storage modification proposal is determined to be invalid, and the operation ends. 6.A blockchain account model storage system, characterized in that, include: The storage proposal submission module is used by the Blockchain Governance Committee to submit storage proposals. The storage proposal is used to define the mapping relationship between storage identifiers and storage hierarchy databases; The storage identifier is the attribute hash value of the account; the account attributes include date, customer type, and business domain; The second judgment module is used for the blockchain governance committee to vote on whether the storage proposal is passed. The Merkel root construction module is used to determine if the storage proposal is valid, using the transaction hash value of the storage proposal as the Merkel root, and storing the first 20 bits of the attribute hash value sequence arranged from largest to smallest as addresses into the default account tree; wherein, the storage content is a byte array of all attribute hash values; and storing the primary key corresponding to the storage content into the title library; The operation termination module is used to determine if the storage proposal is invalid and terminate the operation if not. The construction module is used to construct a Merkle tree based on the storage proposal and to construct the new storage hierarchy database corresponding to the Merkle tree; The first judgment module is used to determine whether the transaction provides the attribute hash value of the account to be tiered during the transaction process; The addition and loading module is used to, if so, determine the new storage tier database corresponding to the attribute hash value of the account to be tiered based on the storage proposal, and load the Merkle tree to store the transaction information in the loaded Merkle tree; The storage module is used to store the transaction information in the default account tree if necessary.

7. An electronic device, comprising: The device includes a memory and a processor, the memory being used to store a computer program, and the processor running the computer program to cause the electronic device to perform the blockchain account model storage method as described in any one of claims 1-5.

8. A computer-readable storage medium, characterized in that, It stores a computer program that, when executed by a processor, implements the blockchain account model storage method as described in any one of claims 1-5.

Images