Blockchain-based digital asset data processing method

Abstract

The application discloses a digital asset data processing method based on a block chain, and belongs to the technical field of block chain data processing. The method comprises the following steps: in response to a digital asset issuance transaction, obtaining an attribute description text and performing entity recognition to obtain an entity relationship tree; based on the entity relationship tree, searching historical digital asset accounting records in a block chain network, and extracting circulation constraint conditions matched with leaf nodes; performing conflict detection on initial issuance rules according to the circulation constraint conditions, and adjusting an upper limit of an issuance total amount according to the depth of the entity relationship tree when a conflict is detected; writing the adjusted issuance rules into an auxiliary data section and storing the auxiliary data section in association with a main data section into a new block; obtaining a block hash value of the new block, rearranging the auxiliary data section according to a front check bit of the block hash value, and generating issuance rule ciphertext. The method realizes dynamic adaptation of digital asset issuance rules and historical constraints and block binding ciphertext storage of rule data.

Description

Technical Field

[0001] This invention relates to the field of blockchain data processing technology, specifically to a blockchain-based digital asset data processing method. Background Technology

[0002] When digital assets are issued on a blockchain network, the asset type, equity structure, and issuance rules need to be defined. These rules typically include parameters such as total supply limits and single issuance amounts. In cases where similar digital assets are issued multiple times or by different issuers, the lack of a linkage and verification mechanism between the issuance rules set for each issuance instance can easily lead to conflicts with the issuance history of similar assets due to inappropriate total supply or single issuance limits, resulting in over-issuance or equity dilution. Existing blockchain asset issuance processing methods generally only verify signature validity and account balance for a single transaction, lacking the ability to check rule consistency across transactions and blocks, and failing to automatically identify and correct rule parameters that conflict with existing circulation conditions during the issuance phase.

[0003] Meanwhile, the issuance rules for digital assets are typically written in plaintext to additional fields of transactions or smart contract states, lacking anonymization measures tied to the characteristics of the blockchain itself during storage and dissemination. Although such rule data can be prevented from being tampered with after the fact by leveraging the consensus mechanism of blockchain, it can still be read and analyzed by any node during transmission and static storage. The structure, limits, and related entity information of the rules are exposed, posing a risk of information exposure in application scenarios that require protection of the sensitivity of issuance strategies.

[0004] To address the aforementioned issues, a method is needed that can reuse historical circulation constraints of the same asset class during digital asset issuance, and automatically compensate the issuance cap based on the structured depth of asset relationships when rule conflicts are detected. At the same time, the storage format of issuance rule data needs to be dynamically associated with the inherent characteristics of generated blocks to achieve block-level binding rule concealment. Summary of the Invention

[0005] This paper provides a blockchain-based digital asset data processing method. During the digital asset issuance stage, the method uses an entity relationship tree to match historical circulation constraints, performs conflict detection and adaptive adjustment on the issuance rules, and combines the adjusted issuance rules with the block hash characteristics to generate encrypted storage.

[0006] To achieve the above objectives, the present invention provides the following technical solution: The present invention provides a blockchain-based digital asset data processing method, which aims to solve the problems in the prior art such as the easy conflict between digital asset issuance rules and historical circulation constraints, the lack of basis for adjusting issuance parameters, and the insufficient security of rule storage.

[0007] In the technical solution of this invention, the method includes: responding to a digital asset issuance transaction, obtaining the attribute description text of the digital asset to be issued, and performing entity recognition on the attribute description text to obtain an entity relationship tree. Based on the entity relationship tree, retrieving historical digital asset accounting records with the same root node in the blockchain network, and extracting the circulation constraints that match each child node of the entity relationship tree in the historical digital asset accounting records. According to the circulation constraints, performing conflict detection on the initial issuance rules in the digital asset issuance transaction, and when a conflict is detected, adjusting the upper limit of the total issuance in the initial issuance rules according to the depth of the entity relationship tree. Writing the adjusted issuance rules into the auxiliary data segment of the digital asset issuance transaction, and associating the auxiliary data segment with the main data segment of the digital asset issuance transaction and storing it in a new block. Obtaining the block hash value of the new block, and rearranging the auxiliary data segment according to the pre-check bit of the block hash value to generate the ciphertext of the issuance rules.

[0008] By transforming attribute description text into a structured entity relationship tree, key entities such as asset categories, issuers, and equity types can be accurately extracted, and the hierarchical relationships between entities reflect the inherent structure of the assets. Based on this, historical accounting records are retrieved using the asset category entity corresponding to the root node as an index, and the flow constraints matching the equity type entities in the leaf nodes are extracted, making the historical constraint matching process more accurate and reducing mismatches and omissions. During conflict detection, the single issuance volume and cumulative issuance volume in the initial issuance rules are compared with the historical single issuance limit and historical cumulative issuance limit, respectively. Once an exceedance is found, a conflict is determined, and a reduction coefficient is determined based on the depth of the entity relationship tree to adjust the total issuance limit. This links the adjustment of the issuance limit to the complexity of the asset description, avoiding the arbitrariness caused by manually setting the adjustment range. The adjusted issuance rules are placed in the supplementary data segment and stored in association with the main data segment recording the issuer's signature and asset quantity in the block. This maintains the simplicity of the core transaction data while incorporating the rule data into the block's extended data area for easy verification and traceability. The permutation seed is generated using the block hash value of the new block. The rule byte stream in the auxiliary data segment is rearranged to generate the issuance rule ciphertext, which binds the issuance rule to the block characteristics. Any tampering with the block or rule will result in the ciphertext becoming unverifiable, thus enhancing the confidentiality and anti-counterfeiting capabilities of the issuance rule stored on the chain.

[0009] As a preferred technical solution of the present invention, when performing entity recognition on attribute description text to obtain an entity relationship tree, asset category entities, issuer entities, and equity type entities are extracted from the attribute description text according to a preset asset entity category dictionary; the asset category entity is determined as the root node, and the issuer entity and equity type entity are taken as child nodes, and dependent edges between child nodes are determined according to the dependency syntax relations in the attribute description text; the root node and child nodes are connected according to the dependent edges to construct the entity relationship tree. Preferably, when determining the dependent edges between child nodes according to the dependency syntax relations in the attribute description text, the attribute description text is segmented to obtain multiple words, and the part-of-speech tag and dependency arc direction of each word are determined; the words corresponding to the issuer entity and equity type entity are taken as endpoints, and the dependency path between the endpoints is found according to the dependency arc direction, and the shortest path in the dependency path is determined as a candidate dependent edge; when the dependency arc label of the candidate dependent edge belongs to a preset dependent label set, the candidate dependent edge is determined as a dependent edge between child nodes. By constructing an entity relationship tree through a combination of dictionary matching and syntactic analysis, we can not only identify independent entities, but also capture the semantic relationships between entities. This allows the relationship between the equity type represented by the leaf node and the asset class of the root node to be accurately solidified, providing a reliable structured input for subsequent condition matching.

[0010] As another preferred technical solution of the present invention, when retrieving historical digital asset accounting records with the same root node in the blockchain network based on the entity relationship tree and extracting circulation constraints, the asset category entity corresponding to the root node of the entity relationship tree is used as the search keyword to query the asset issuance record headers of all recorded blocks in the blockchain network, and candidate accounting records with the same asset category entity are filtered out; the circulation condition field of each candidate accounting record is read, and the condition entity in the circulation condition field is compared one by one with the equity type entity corresponding to the leaf node of the entity relationship tree; the circulation condition field in which the condition entity and the equity type entity are successfully matched is determined as the circulation constraint. Preferably, the circulation condition field contains a list of condition entities, and the comparison is performed one by one by performing a string-complete match between each condition entity in the condition entity list and the equity type entity. In this way, in the massive accounting records of the blockchain, the search scope can be quickly narrowed by only the asset category index, and then the equity type entity of the leaf node is accurately matched with the condition entity to ensure that the extracted circulation constraints directly correspond to the equity structure of the current issuance and transaction, thereby improving the efficiency and accuracy of constraint extraction.

[0011] In another preferred embodiment of the present invention, when performing conflict detection and adjusting the total issuance limit based on the circulation constraints of the initial issuance rules, the historical single issuance limit and the historical cumulative issuance limit are extracted from the circulation constraints. The single issuance amount in the initial issuance rules is numerically compared with the historical single issuance limit, and the cumulative issuance amount in the initial issuance rules is numerically compared with the historical cumulative issuance limit. If the single issuance amount exceeds the historical single issuance limit or the cumulative issuance amount exceeds the historical cumulative issuance limit, a conflict is determined. A reduction coefficient is determined based on the depth of the entity relationship tree, and the total issuance limit in the initial issuance rules is multiplied by the reduction coefficient to obtain the adjusted total issuance limit. The depth of the entity relationship tree reflects the complexity of the asset's equity structure; a greater depth usually means that the asset involves more levels of equity relationships, requiring a more conservative issuance strategy. Using this depth to determine the reduction coefficient can adaptively balance issuance flexibility and risk control requirements, making the adjusted total issuance limit more reasonable.

[0012] Regarding the on-chain storage of rule data, as a further improvement, when writing the adjusted issuance rules into the auxiliary data segment of the digital asset issuance transaction and storing the auxiliary data segment in association with the main data segment, the adjusted issuance rules are serialized into a rule byte stream, and a length identifier and checksum of the rule byte stream are generated. The length identifier, checksum, and rule byte stream are then concatenated to form the auxiliary data segment. The issuer's digital signature and asset quantity field are extracted from the digital asset issuance transaction as the main data segment, and a mapping index between the storage pointer of the auxiliary data segment and the main data segment is established. The mapping index and the main data segment are written into the transaction body of the new block, and the auxiliary data segment is written into the extended data area of ​​the new block. Preferably, when establishing the mapping index between the storage pointer of the auxiliary data segment and the main data segment, the starting offset address and data length of the auxiliary data segment in the extended data area are obtained, and the storage pointer is formed using the starting offset address and data length. The asset issuer identifier and asset issuance sequence number are extracted from the main data segment, and the asset issuer identifier and asset issuance sequence number are concatenated to form a mapping primary key. The mapping primary key and the storage pointer are stored correspondingly in the mapping index table in the block header of the new block. By storing the main data segment and the auxiliary data segment separately and establishing an index association, the efficiency of core transaction verification is ensured, while detailed issuance rules can be quickly located and read through the index; the introduction of length identifiers and check codes facilitates the integrity verification of auxiliary data segments.

[0013] In generating the ciphertext of the issuance rules, the block hash value of the new block is obtained, and the last four bytes of the block hash value are extracted as a pre-check bit and converted into a permutation seed. The rule byte stream in the auxiliary data segment is then cyclically shifted left according to the permutation seed to obtain a rearranged byte stream. This rearranged byte stream is then recombinated with the length identifier and checksum in the auxiliary data segment to generate the ciphertext of the issuance rules. Preferably, the rearrangement of the auxiliary data segment involves determining the number of bits to cyclically shift left based on the permutation seed, and then cyclically shifting the entire rule byte stream in the auxiliary data segment byte-by-byte. This process forcibly associates the ciphertext of the issuance rules with the hash characteristics of the new block. Any unauthorized modification of the rule content or reconstruction of the block will fail the verification due to the mismatch in the permutation seed, thereby significantly improving the tamper resistance and storage security of the issuance rules.

[0014] The technical effects and advantages provided by the present invention in the above technical solution are as follows: By performing entity recognition on the attribute description text of digital assets, an entity relationship tree is constructed with asset category entities as root nodes and issuer entities and equity type entities as child nodes. Historical digital asset ledger records with the same root node are retrieved from the blockchain network, and circulation constraints matching each child node are extracted. This allows for the direct reuse of established circulation restriction rules for similar historical assets. When a conflict is detected where the single issuance volume or cumulative issuance volume in the initial issuance rules exceeds the historical single issuance limit or historical cumulative issuance limit, a reduction coefficient is determined based on the depth value of the entity relationship tree. This reduces the upper limit of the total issuance volume, ensuring that the scale of the new issuance rules is inversely adapted to the complexity of the asset relationship structure. This approach no longer relies on statically preset fixed thresholds or manual adjustments. Instead, it uses the semantic structure depth of the asset description as an adjustment parameter, establishing a dynamically coordinated issuance volume constraint relationship between different issuance instances of similar assets. This allows the issuance limit to automatically converge as the asset relationship tree changes in hierarchy, preventing multiple rounds of issuance from exceeding historical cumulative total constraints. It also avoids conflicts caused by differences in rules set by different issuers for similar assets.

[0015] The process involves obtaining the block hash value of a new block with the adjusted issuance rules, extracting its last four bytes as a pre-check bit, and converting them into a permutation seed. Following this seed, a circular left shift operation is performed on the rule byte stream in the auxiliary data segment, generating a rearranged byte stream. This rearranged byte stream is then combined with the length identifier and checksum to form the ciphertext of the issuance rules. This process ensures that the byte arrangement sequence of the rule data is entirely determined by a specific bit segment of the block hash value. Any tampering with the auxiliary or main data segment will change the block hash value, leading to a change in the pre-check bit and disrupting the permutation seed used in ciphertext generation. After decryption, the rule byte stream will be unable to reconstruct the correct rule data, and the tampering will be directly detectable. Furthermore, since the permutation seed originates from the block's own hash characteristics, the same issuance rule will exhibit different byte arrangements in different blocks. This achieves block binding obfuscation of rule data in storage without adding additional key management, reducing the risk of rule information being statically analyzed and extracted without authorization. Attached Figure Description

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

[0017] Figure 1 This is a flowchart of a blockchain-based digital asset data processing method. Figure 2 This is a flowchart for extracting constraints on the transfer of digital assets based on an entity relationship tree. Figure 3 This is a flowchart of the issuance rule serialization and associated data segment mapping index construction process; Figure 4 This is a confidence distribution chart of asset entity matching in the attribute description text of digital assets; Figure 5 This is a graph showing the distribution of bytes in a cyclic left shift of the byte stream according to the distribution rules. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, 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, 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.

[0019] See Figure 1This invention provides a blockchain-based digital asset data processing method. In response to a digital asset issuance transaction, it obtains the attribute description text of the digital asset to be issued, performs entity recognition on the attribute description text, and obtains an entity relationship tree. Based on the entity relationship tree, it retrieves historical digital asset accounting records with the same root node in the blockchain network, and extracts the flow constraints from the historical digital asset accounting records that match the leaf nodes of the entity relationship tree. It performs conflict detection on the initial issuance rules in the digital asset issuance transaction according to the flow constraints. When a conflict is detected, it adjusts the upper limit of the total issuance in the initial issuance rules according to the depth of the entity relationship tree. It writes the adjusted issuance rules into the auxiliary data segment of the digital asset issuance transaction, and associates the auxiliary data segment with the main data segment of the digital asset issuance transaction and stores it in a new block. It obtains the block hash value of the new block, rearranges the auxiliary data segment according to the pre-check bit of the block hash value, and generates the encrypted issuance rules.

[0020] Example 1: In specific implementation, an asset entity category dictionary is pre-constructed. This dictionary stores entries for asset category entities, the institution name entries corresponding to the issuer entity, and the equity description entries corresponding to the equity type entity. In response to digital asset issuance and trading, the attribute description text of the digital asset to be issued is obtained. Entity recognition is performed on the attribute description text to obtain the entity relationship tree, as follows.

[0021] In some embodiments, asset class entities, issuer entities, and equity type entities are extracted from the attribute description text by matching the attribute description text with an asset entity category dictionary. During the matching process, a dictionary-based forward maximum matching algorithm is used to scan the attribute description text from left to right, each time extracting a text fragment of equal length to the longest term in the dictionary for matching. If a match is successful, the text fragment is recorded as an entity of the corresponding entity type; if a match fails, the extraction length is reduced character by character until a match is successful or only one character remains. All matched entities are categorized into asset class entity sets, issuer entity sets, and equity type entity sets according to the entity type marked in the asset entity category dictionary. When multiple candidate entities appear in a set, the entity that first appears in the attribute description text and is completely contained within a dependency subtree is selected as the final extraction result.

[0022] After extracting the asset class entity, issuer entity, and equity type entity, the asset class entity is determined as the root node of the entity relationship tree, and the issuer entity and equity type entity are designated as child nodes. The entity relationship tree is represented using a multi-branch tree structure, with the root node storing the character sequence of the asset class entity and the child nodes storing the character sequences of the issuer entity and equity type entity, respectively.

[0023] Dependent edges between child nodes are determined by analyzing the dependency syntax relations of the attribute description text. The attribute description text is segmented into multiple words, and the part-of-speech tag and dependency arc direction for each word are determined. A Chinese word segmentation model based on conditional random fields is used for segmentation. This model takes character n-gram features, character position tag features, and dictionary features as input, and outputs the boundary and corresponding part-of-speech tag for each word. Based on the segmentation results, a neural network-based dependency parser is used to determine the dependency arc direction between words. The dependency arc direction indicates the dependency relationship from the center word to the dependent word. The dependency parser uses a dual affine attention mechanism to calculate the score matrix of each word as the center word and dependent word in the segmented word sequence, and decodes the globally optimal set of dependency arcs using the maximum spanning tree algorithm. Each dependency arc is accompanied by a dependency arc label.

[0024] Using the terms corresponding to the issuer entity and the terms corresponding to the equity type entity as two endpoints, dependency paths between the two endpoints are found based on the direction of the dependency arcs. The dependency path search is performed by a breadth-first search on the dependency graph output by the dependency parser: starting from the term node corresponding to the issuer entity, adjacent nodes are expanded along the direction and reverse direction of the dependency arc until the term node corresponding to the equity type entity is reached. The sequence of nodes traversed and the sequence of dependency arc labels traversed during the traversal are recorded. If multiple dependency paths exist, the number of dependency arcs traversed by each path is calculated, and the dependency path with the fewest dependency arcs is identified as a candidate dependent edge.

[0025] After identifying candidate dependent edges, it is determined whether the dependency arc labels of the candidate dependent edges belong to a predefined set of dependent labels. The predefined set of dependent labels includes dependency relationship labels representing attribute dependence, ownership, or issuance relationships, specifically including labels such as "limited," "belonging," "of," "agent," and "patient." If at least one dependency arc label in a candidate dependent edge belongs to the predefined set of dependent labels, that candidate dependent edge is identified as a dependent edge between child nodes. If none of the dependency arc labels of a candidate dependent edge belong to the predefined set of dependent labels, no dependent edges are established between child nodes. In this case, the entity relationship tree only contains direct connections between the root node and each child node; there are no connections between child nodes.

[0026] After determining the dependent edges, the root node and child nodes are connected based on these edges to construct the entity relationship tree. Specifically, the tree is constructed as follows: a root node is created and assigned the asset class entity value; issuer entity child nodes and equity type entity child nodes are created, and edges from the root node to these two child nodes are added respectively; if dependent edges exist between child nodes, an edge representing the dependent relationship is added between the issuer entity child node and the equity type entity child node, with the edge direction consistent with the dependency direction determined by the dependent edge. The edge's attribute records the dependency arc label sequence contained in the dependent edge. The final entity relationship tree has the asset class entity as its root, and the issuer entity and equity type entity as its direct child nodes. Labeled directed edges may exist between child nodes based on dependency syntax relationships.

[0027] See Figure 4 In the graph, the horizontal axis represents the character offset of the attribute description text, ranging from 0 to 600 characters, and the vertical axis represents the match confidence score, ranging from 0.0 to 1.0. The graph shows three curves, corresponding to the changing trends of match confidence score as the character offset of the attribute description text for asset class entities (solid blue line), issuer entities (dashed orange line), and equity type entities (dotted green line).

[0028] The matching confidence curves for asset class entities exhibit multiple peaks and troughs, with most peaks concentrated between 0.2 and 0.5. Significant peaks appear at offsets of approximately 150, 180, 400, and 600 characters, indicating a high degree of identification and matching for asset class entities at these text locations. The overall matching confidence curve for issuer entities is slightly lower than that for asset class entities, with peaks mainly concentrated between 0.2 and 0.4, and a relatively even distribution of peaks. Notable matching peaks are observed at offsets of approximately 120, 220, and 380 characters, demonstrating effective identification of issuer entities in the corresponding attribute description text paragraphs. The matching confidence curves for equity type entities fluctuate more frequently, with peaks mostly distributed between 0.1 and 0.5. Multiple matching peaks appear at offsets of approximately 110, 200, 320, and 500 characters, reflecting high matching confidence for equity type entities in multiple locations within the text.

[0029] Example 2: In specific implementation, refer to Figure 2 Based on the entity relationship tree, historical digital asset transaction records with the same root node are retrieved in the blockchain network. The flow constraints matching the leaf nodes of the entity relationship tree are extracted from these historical records. This is achieved through the asset record index module built into the blockchain node. The asset record index module maintains an inverted index, where asset class entities are used as keys, and the values ​​are a list of block heights of recorded blocks containing that asset class entity and a list of asset issuance record header offset addresses.

[0030] In some embodiments, the process of querying the asset issuance record headers of all recorded blocks in the blockchain network using the asset category entity corresponding to the root node of the entity relationship tree as the search keyword is as follows: extract the character sequence of the asset category entity from the root node of the entity relationship tree, and input the character sequence of the asset category entity as the search keyword into the asset record index module; the asset record index module searches for entries in the inverted index library whose keys exactly match the search keyword; if a matching entry exists, it reads the asset issuance record header offset address list corresponding to the matching entry; according to each offset address in the asset issuance record header offset address list, it reads the asset issuance record header data from the corresponding storage location of the corresponding block; each asset issuance record header data contains storage pointers for the asset category entity field and the circulation condition field.

[0031] After retrieving the header data of all asset issuance records, a secondary string matching check is performed on the asset category entity field in the asset issuance record header data. The accounting records corresponding to the asset issuance record headers whose asset category entity fields completely match the search keywords are marked as candidate accounting records. The secondary string matching check uses a byte-level comparison method, comparing the binary code of the asset category entity field with the binary code of the search keywords byte by byte. A successful match is determined when all bytes are equal.

[0032] Optionally, after obtaining the candidate accounting records, the flow condition field of each candidate accounting record is read. The flow condition field contains a list of condition entities, which consists of multiple condition entities, each of which is a string describing the type of interest. The condition entity list is stored using a length prefix encoding format. The length prefix encoding format uses a four-byte unsigned integer to represent the total byte length of the condition entity list and a two-byte unsigned integer to represent the number of condition entities in the list. Then, the length prefix and the string content of each condition entity are stored sequentially. When reading the flow condition field, the four-byte total byte length is read first to determine the data boundary of the flow condition field; then, the two-byte number of condition entities is read to determine the number of condition entities to be parsed; finally, the two-byte length prefix and the corresponding length of the condition entity string are read one by one according to the number of condition entities.

[0033] After reading each condition entity in the condition entity list, each condition entity is compared with the equity type entity. This comparison involves performing a complete string match between each condition entity in the condition entity list and the corresponding equity type entity at each leaf node of the entity relationship tree. Specifically, the complete string match is executed as follows: the character sequences of the equity type entities at all leaf nodes are extracted from the entity relationship tree. For each condition entity in the condition entity list, the string of the condition entity is compared character-by-character with the string of the equity type entity at each leaf node. A successful match is determined when the string of the condition entity is identical to the string of at least one equity type entity at a leaf node.

[0034] In some embodiments, the quantification of matching success rate is performed in the following manner: by This indicates the matching status between the condition entity and the equity type entity. The value can be set to 0 or 1. The condition is defined when at least one condition entity in the condition entity list has the exact same string as the equity type entity string of any leaf node. The value is 1; when all condition entities in the condition entity list are different from the equity type entity strings of all leaf nodes, The value is 0. The method for obtaining it is as follows: traverse all condition entities in the condition entity list, and for each condition entity, traverse all leaf nodes of the entity relationship tree for the right type entity, perform a string exact match judgment, and terminate the traversal if any match is successful. Set to 1; if all iterations are completed and no match is found, then... Set to 0.

[0035] The transfer condition fields that successfully match the condition entity and the equity type entity are defined as transfer constraints, that is... The flow condition fields corresponding to candidate accounting records with a value of 1 are extracted as flow constraints. The flow constraints contain all the contents of the flow condition fields that successfully match the condition entities, including the list of condition entities, the flow threshold associated with each condition entity, the upper limit of flow frequency, and the flow validity period field.

[0036] Example 3: In specific implementation, the process of extracting the historical single-issue limit and historical cumulative issue limit from the circulation constraints is achieved by parsing the structured constraint fields stored within the circulation constraints. The circulation constraints contain constraint parameter blocks organized in key-value pairs. The key name of the constraint parameter block identifies the constraint type, and the key value stores the corresponding limit value. The key name corresponding to the historical single-issue limit is "single_issue_limit", and the key name corresponding to the historical cumulative issue limit is "cumulative_issue_limit". When reading the binary data of the circulation constraints, the key name string is parsed byte by byte. When "single_issue_limit" or "cumulative_issue_limit" is matched, the four-byte unsigned integer immediately following the key name is read. This four-byte unsigned integer is the corresponding limit value. The extracted historical single-issue limit and historical cumulative issue limit are stored in preset constraint limit registers.

[0037] The initial issuance rules compare the single issuance amount in the initial issuance rules with the historical single issuance limit, and compare the cumulative issuance amount in the initial issuance rules with the historical cumulative issuance limit. The initial issuance rules are stored in the transaction payload of digital asset issuance transactions, expressed in a structured data format, and include fields for single issuance amount, cumulative issuance amount, and total issuance limit.

[0038] By parsing the field offsets of the transaction payload, the starting address of the single issuance amount field is located. The four-byte unsigned integer starting at that address is read to obtain the single issuance amount value. The cumulative issuance amount field and the total issuance limit field are read in the same way. Value comparison is performed using an integer comparison unit, which contains two input ports and one output port. The historical single issuance limit is sent to the first input port, and the single issuance amount is sent to the second input port. The integer comparison unit outputs a first comparison result flag. Similarly, the historical cumulative issuance limit is sent to the first input port, and the cumulative issuance amount is sent to the second input port. The integer comparison unit outputs a second comparison result flag. When either the first or second comparison result flag is true, it indicates that the single issuance amount exceeds the historical single issuance limit or the cumulative issuance amount exceeds the historical cumulative issuance limit, indicating a conflict.

[0039] In some embodiments, the logical expression for conflict determination is: ,in, Indicates the conflict determination result. The value can be a Boolean value, with a true value indicating a conflict. This represents the numerical value of a single issuance extracted from the initial issuance rules; This represents the historical single issuance limit value extracted from the circulation constraints; This represents the cumulative issuance amount extracted from the initial issuance rules; This represents the historical cumulative issuance limit extracted from the circulation constraints; For logical OR operator; The comparison operator is for numbers greater than or equal to.

[0040] When the conflict determination result When true, the reduction factor is determined based on the depth value of the entity relationship tree. The depth value of the entity relationship tree is defined as the number of edges traversed from the root node to the farthest leaf node. The depth value is calculated by the tree structure traversal module after the entity relationship tree is constructed. This module recursively visits all child nodes starting from the root node, records the number of edges traversed on the visited path, and takes the maximum value of the number of edges on all paths as the depth value of the entity relationship tree, denoted as . , It is a positive integer. The reduction factor is denoted as... , The method of obtaining it is: based on the depth value of the entity relationship tree. As input, a pre-defined depth-reduction factor mapping table is queried. This table stores the reduction factor values ​​corresponding to different depth ranges. The depth-reduction factor mapping table is constructed based on the following principle: the higher the depth value of the entity relationship tree, the more complex the asset attribute description, and the greater the adjustment range of the issuance rules, the smaller the reduction factor value. In the depth-reduction factor mapping table, when... hour, ;when hour, ;when hour, ;when hour, The endpoints of the depth value range and the corresponding reduction coefficient are set through preset business rule configuration parameters, which are determined based on the guidance on the adjustment range of the issuance cap for different types of assets in the regulatory compliance framework.

[0041] The adjusted total issuance limit is obtained by multiplying the initial issuance limit by a reduction factor. This adjustment is performed in the numerical calculation module, which reads the issuance limit value from the initial issuance rules and multiplies it by the reduction factor. The product is fed into a floating-point multiplier, which outputs the result. The product is then rounded down to the nearest integer, which is the adjusted upper limit of the total issuance. This adjusted upper limit replaces the upper limit field in the initial issuance rules, thus completing the adjustment of the initial issuance rules.

[0042] Example 4: In specific implementation, refer to Figure 3 The adjusted issuance rules are serialized into a rule byte stream using a predefined structured serialization protocol. The adjusted issuance rules include numerical fields such as the adjusted total issuance limit, the adjusted single issuance amount, and the adjusted cumulative issuance amount, as well as string fields such as asset class entities and equity type entities. During serialization, each field is converted to its corresponding binary representation in the predefined field order: numerical fields are converted to four-byte unsigned integer binary codes in little-endian byte order; string fields are first written with a two-byte prefix, followed by the UTF-8 encoded byte sequence of the string. All field binary codes are concatenated end-to-end in field order to form the rule byte stream.

[0043] Generate a length identifier and a checksum for the regular byte stream. The length identifier is a four-byte unsigned integer representing the total number of bytes in the regular byte stream, stored in little-endian byte order. The checksum is calculated using the CRC-32 algorithm to generate a four-byte checksum. Concatenate the length identifier, checksum, and regular byte stream sequentially into an auxiliary data segment: the four bytes of the length identifier are placed at the beginning of the auxiliary data segment, the four bytes of the checksum follow immediately after the length identifier, and the complete regular byte stream is appended after the checksum. The resulting byte sequence is the auxiliary data segment.

[0044] In some embodiments, the issuer's digital signature and asset quantity field are extracted from the digital asset issuance transaction as the main data segment. The digital asset issuance transaction is stored in a predefined organizational structure, which includes a transaction header, a transaction payload, and a transaction tail. The transaction header contains a transaction version number and a transaction type identifier; the transaction payload contains fields such as issuer identifier, asset class entity, asset quantity field, and issuance rules; and the transaction tail contains the issuer's digital signature and a timestamp. When parsing the binary data of the digital asset issuance transaction, the boundary between the transaction payload and the transaction tail is located using the length field in the transaction header. The binary code of the asset quantity field is extracted from the transaction payload, and the complete byte sequence of the issuer's digital signature is extracted from the transaction tail. The binary code of the asset quantity field and the complete byte sequence of the issuer's digital signature are then concatenated in chronological order to form the main data segment.

[0045] Optionally, establish a mapping index between the storage pointer of the auxiliary data segment and the main data segment. Obtain the starting offset address and data length of the auxiliary data segment in the extended data area. The extended data area is a storage area reserved in the new block for storing auxiliary data. The extended data area is located after the transaction body of the new block, and its starting address is indicated by the extended data area offset field in the block header. When writing the auxiliary data segment to the extended data area, record the starting offset address after the write operation is completed and the total number of bytes of the auxiliary data segment actually written. Assign the starting offset address and the total number of bytes to the starting offset address variable and the data length variable, respectively. Use the starting offset address variable and the data length variable to form a storage pointer. The storage pointer adopts an eight-byte data structure, with the first four bytes storing the unsigned integer value of the starting offset address and the last four bytes storing the unsigned integer value of the data length.

[0046] Extract the asset issuer identifier and asset issuance sequence number from the main data segment. The asset issuer identifier is represented by a globally unique identifier of 16 bytes, located in the issuer identifier field in the digital asset issuance transaction; the asset issuance sequence number is represented by a 4-byte unsigned integer, located in the asset issuance sequence number field of the transaction payload in the digital asset issuance transaction. Concatenate the 16-byte sequence of the asset issuer identifier and the 4-byte sequence of the asset issuance sequence directly in little-endian order to form a 20-byte mapping primary key.

[0047] The mapping key and the corresponding storage pointer are stored in the mapping index table in the block header of the new block. The mapping index table is a key-value pair storage structure maintained in the block header, where the key is the mapping key and the value is the storage pointer. During the generation of a new block, the mapping key and the storage pointer are combined into a key-value pair and inserted into the mapping index table. If an entry with the same mapping key already exists in the mapping index table, the new storage pointer overwrites the old one.

[0048] When writing the mapping index and main data segment to the transaction body of a new block, and when writing the auxiliary data segment to the extended data area of ​​the new block, the write operation is performed according to the block data structure layout. The transaction body of the new block consists of a transaction counter and multiple transaction data slots. An empty transaction data slot is found within the transaction body, and the entire main data segment is written to that slot. Simultaneously, all mapping primary keys and storage pointer key-value pairs generated in the current new block from the mapping index are serialized and written to the dedicated mapping index storage area within the transaction body. When writing the auxiliary data segment to the extended data area of ​​the new block, all bytes of the auxiliary data segment are written sequentially starting from the current free offset address in the extended data area, and the free offset address in the extended data area is updated.

[0049] Example 5: In specific implementation, the block hash value of the new block is obtained. After the block header construction, transaction body filling, and extended data area writing are completed, the hash calculation module of the blockchain node performs SHA-256 hash operation on all fields of the new block header to generate a 32-byte block hash value. The block hash value is stored in the block hash value field of the block header in binary sequence form and can be read through the node interface.

[0050] In some embodiments, the last four bytes of the block hash value are extracted as a checksum bit. Specifically, the operation is as follows: offset four bytes forward from the end of the 32-byte sequence of the block hash value, and take the four bytes at offset addresses 28, 29, 30, and 31, and form the checksum bit in its original order. The checksum bit retains the original byte order of the last four bytes of the block hash value, without any byte order conversion.

[0051] The parity bit is converted into a permutation seed. The conversion method is as follows: the four bytes of the parity bit are parsed into a 32-bit unsigned integer in big-endian byte order. During parsing, the byte at offset address 28 is taken as the most significant byte, and the byte at offset address 31 is taken as the least significant byte. The combination of these bytes yields the integer value of the permutation seed. The permutation seed value is a closed interval. All integers within.

[0052] The number of bits for the circular left shift is determined based on the permutation seed, and the entire regular byte stream in the auxiliary data segment is then circularly shifted left byte by byte. Since the circular left shift is based on bytes, the actual number of bits for the circular left shift is the number of bytes shifted left multiplied by 8. The number of bytes shifted left is determined as follows: Indicates the number of bytes shifted left in a circular shift. It is obtained by taking the integer value of the permutation seed modulo the total number of bytes in the regular byte stream.

[0053] The modulo operation uses the following formula: ,in, Indicates the number of bytes shifted left in a circular shift. The range of values ​​is a closed interval. All integers within; This represents the integer value of the permutation seed obtained by parsing the four bytes of the front parity bit in big-endian byte order; This indicates the total number of bytes in the rule byte stream. This is the actual byte length of the rule byte stream obtained after serialization and adjustment of the distribution rules; This represents the modulo operator. When... When the result is 0, If the value is 0, the circular left shift operation is not performed.

[0054] The specific operation for performing a byte-by-byte circular left shift on a regular byte stream is as follows: when At that time, the offset address in the regular byte stream is changed from 0 to... The former Extract each byte and temporarily store it in the shift buffer; move the offset address from the regular byte stream... arrive The remaining bytes are shifted forward sequentially to the position starting at offset address 0; then the bytes in the shift buffer are... 1 byte sequentially written to the offset address Starting from the beginning, perform a circular left shift of the regular byte stream to obtain a rearranged byte stream. The total number of bytes in the rearranged byte stream remains the same. The total number of bytes in the original rule byte stream is the same.

[0055] After obtaining the rearranged byte stream, it is recombined with the length identifier and checksum from the auxiliary data segment to generate the issuance rule ciphertext. During recombination, the original three-segment structure of the auxiliary data segment is maintained, i.e., the order of the length identifier, checksum, and rule byte stream remains unchanged, but the rule byte stream is replaced with the rearranged byte stream. The specific recombination steps are as follows: obtain the four-byte binary code of the original length identifier from the auxiliary data segment, obtain the four-byte binary code of the original checksum from the auxiliary data segment, and then sequentially combine the four bytes of the length identifier, the four bytes of the checksum, and the entire rearranged byte stream. The byte sequence is concatenated sequentially; the resulting complete byte sequence is the ciphertext of the issuance rules. The total number of bytes in the ciphertext of the issuance rules is [number missing]. byte.

[0056] Optionally, the generation process of the permutation seed can be linked to the distributed consensus result of the block hash value. Since the block hash value is determined by the proof-of-work or proof-of-stake consensus mechanism, it possesses randomness and unpredictability. Therefore, the pre-check bits and permutation seed also inherit the random distribution characteristics of the block hash value. The generation of the issuance rule ciphertext does not rely on additional key management; the obfuscation and rearrangement of the rule byte stream in the auxiliary data segment can be completed using the block hash value of the new block.

[0057] See Figure 5 The horizontal axis in the graph represents the total number of bytes in the regular byte stream. The range is approximately 20 to 300 bytes, with the vertical axis representing the corresponding number of bytes for a circular left shift. The range is approximately 0 to 300 bytes. The scatter points in the graph represent the number of bytes for a circular left shift corresponding to different byte stream rules. The actual values ​​are shown; the red dashed line represents the theoretical mean. Reference lines.

[0058] As can be seen from the graph, the number of bytes for a circular left shift is... Total number of bytes in the rule-based byte stream The increase in the number of bytes shifted left shows an overall upward trend, and the data points are relatively scattered, indicating that the number of bytes shifted left in a circular shift is increasing. Based on the length of the regular byte stream Modulo operations on the modulus exhibit good uniform distribution characteristics. Specifically, in Within a relatively small range (approximately 20 to 100 bytes), the scattered points are relatively dense and evenly distributed, with a circular left shift of bytes. Covering from 0 to near The integer values ​​verified the random uniformity of the modulo operation. Within medium-sized byte ranges (approximately 100 to 200 bytes) and large-sized byte ranges (approximately 200 to 300 bytes), the number of bytes for the circular left shift was [number missing]. It continues to maintain a dispersed distribution, with the maximum value approaching... The minimum value is close to 0, and there is no obvious clustering or deviation.

[0059] Red dashed line As the theoretical mean, it is located in the center of the scatter plot, reflecting the determination of the number of bytes for the circular left shift after using the last four bytes of the new block hash value to generate the permutation seed and then performing a modulo operation. It can achieve a uniform distribution with the length of the regular byte stream as the period, avoid the cyclic left shift biased towards a fixed interval, and thus ensure the randomness and diversity of the confusion and rearrangement effect of the regular byte stream in the auxiliary data segment.

[0060] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application.

Claims

1. A blockchain-based digital asset data processing method, characterized in that, include: In response to the issuance and trading of digital assets, the system obtains the attribute description text of the digital assets to be issued, and performs entity recognition on the attribute description text to obtain an entity relationship tree; Based on the entity relationship tree, historical digital asset accounting records with the same root node are retrieved in the blockchain network, and the flow constraints that match the leaf nodes of the entity relationship tree in the historical digital asset accounting records are extracted. Based on the circulation constraints, conflict detection is performed on the initial issuance rules in the digital asset issuance and transaction. When a conflict is detected, the upper limit of the total issuance in the initial issuance rules is adjusted according to the depth of the entity relationship tree. The adjusted issuance rules are written into the auxiliary data segment of the digital asset issuance transaction, and the auxiliary data segment is associated with the main data segment of the digital asset issuance transaction and stored in a new block; Obtain the block hash value of the new block, rearrange the auxiliary data segments according to the pre-check bit of the block hash value, and generate the ciphertext of the issuance rules.

2. The blockchain-based digital asset data processing method according to claim 1, characterized in that, Entity recognition is performed on the attribute description text to obtain an entity relationship tree, specifically including: According to the preset asset entity category dictionary, extract asset category entities, issuer entities, and equity type entities from the attribute description text; The asset class entity is identified as the root node, the issuer entity and the equity type entity are identified as child nodes, and the dependent edges between the child nodes are determined based on the dependency syntax in the attribute description text. The entity relationship tree is constructed by connecting the root node and the child nodes based on the dependent edges.

3. The blockchain-based digital asset data processing method according to claim 1, characterized in that, Based on the entity relationship tree, historical digital asset transaction records with the same root node are retrieved from the blockchain network, and the flow constraints matching the leaf nodes of the entity relationship tree in the historical digital asset transaction records are extracted, specifically including: Using the asset category entity corresponding to the root node of the entity relationship tree as the search keyword, query the asset issuance record header of all recorded blocks in the blockchain network, and filter out candidate record records with the same asset category entity; Read the flow condition fields of the candidate accounting records one by one, and compare the condition entities in the flow condition fields with the equity type entities corresponding to the leaf nodes of the entity relationship tree; The transfer condition field that successfully matches the condition entity with the right type entity is determined as the transfer constraint condition.

4. The blockchain-based digital asset data processing method according to claim 1, characterized in that, Based on the aforementioned circulation constraints, conflict detection is performed on the initial issuance rules in the digital asset issuance and trading. When a conflict is detected, the upper limit of the total issuance amount in the initial issuance rules is adjusted according to the depth of the entity relationship tree, specifically including: Extract the historical single issuance limit and historical cumulative issuance limit from the circulation constraints, and compare the single issuance amount in the initial issuance rule with the historical single issuance limit, and compare the cumulative issuance amount in the initial issuance rule with the historical cumulative issuance limit. A conflict is determined when the single issuance volume exceeds the historical single issuance limit or the cumulative issuance volume exceeds the historical cumulative issuance limit. The reduction factor is determined based on the depth value of the entity relationship tree. The upper limit of the total issuance in the initial issuance rule is multiplied by the reduction factor to obtain the adjusted upper limit of the total issuance.

5. The blockchain-based digital asset data processing method according to claim 1, characterized in that, The adjusted issuance rules are written into the supplementary data segment of the digital asset issuance transaction, and the supplementary data segment is associated with the main data segment of the digital asset issuance transaction and stored in a new block, specifically including: The adjusted issuance rules are serialized into a rule byte stream, and a length identifier and a checksum of the rule byte stream are generated. The length identifier, the checksum, and the rule byte stream are then concatenated into the auxiliary data segment. Extract the issuer's digital signature and asset quantity field from the digital asset issuance transaction as the main data segment, and establish a mapping index between the storage pointer of the auxiliary data segment and the main data segment; Write the mapping index and the main data segment into the transaction body of the new block, and write the auxiliary data segment into the extended data area of ​​the new block.

6. The blockchain-based digital asset data processing method according to claim 1, characterized in that, Obtain the block hash value of the new block, rearrange the attached data segments according to the pre-check bit of the block hash value, and generate the issuance rule ciphertext, specifically including: Obtain the block hash value of the new block, extract the last four bytes of the block hash value as the pre-check bit, and convert the pre-check bit into a permutation seed; Perform a cyclic left shift operation on the regular byte stream in the auxiliary data segment according to the arrangement seed to obtain a rearranged byte stream; The rearranged byte stream is recombined with the length identifier and checksum in the auxiliary data segment to generate the ciphertext of the issuance rule.

7. The blockchain-based digital asset data processing method according to claim 2, characterized in that, Based on the dependency syntax relations in the attribute description text, the dependent edges between the child nodes are determined, specifically including: The attribute description text is segmented to obtain multiple words, and the part-of-speech tag and dependency arc direction of each word are determined. Using the terms corresponding to the issuer entity and the rights type entity as endpoints, the dependency path between the endpoints is found according to the dependency arc direction, and the shortest path in the dependency path is determined as the candidate dependent edge; When the dependency arc label of the candidate dependent edge belongs to a preset dependent label set, the candidate dependent edge is determined as a dependent edge between the child nodes.

8. The blockchain-based digital asset data processing method according to claim 5, characterized in that, Establishing a mapping index between the storage pointers of the auxiliary data segments and the main data segments specifically includes: Obtain the starting offset address and data length of the auxiliary data segment in the extended data area, and use the starting offset address and the data length to form the storage pointer; Extract the asset issuer identifier and asset issuance serial number from the main data segment, and concatenate the asset issuer identifier and asset issuance serial number to form a mapping primary key; The mapping primary key and the storage pointer are stored in the mapping index table in the block header of the new block.

9. The blockchain-based digital asset data processing method according to claim 1, characterized in that, The rearrangement of the auxiliary data segment is as follows: the number of bits to be cyclically shifted left is determined according to the arrangement seed, and the entire regular byte stream in the auxiliary data segment is cyclically shifted left by byte.

10. The blockchain-based digital asset data processing method according to claim 3, characterized in that, The circulation condition field contains a list of condition entities, and the step-by-step comparison involves sequentially matching each condition entity in the list with the equity type entity using string matching.

Images