Asset tracking management system and method based on non-account balance mode blockchain

Abstract

The present invention discloses an asset tracking management system and method based on a non-account balance mode blockchain, wherein each layer works in coordination: the blockchain data index layer first obtains, parses and indexes basic data, the address analysis association layer builds an address relationship network on this basis, and the address legitimacy verification layer verifies the newly added addresses in the address relationship network; the address data management layer is responsible for managing the asset data of all legal addresses in the address relationship network, and provides an external interaction path through an external query service layer. The present invention solves the problem of difficulty in indexing address information of a non-account balance mode blockchain, realizes the determination of the asset flow direction between addresses of a non-account balance mode blockchain, and effectively improves the security and manageability of assets on the non-account balance mode blockchain chain.

Description

Technical Field

[0001] The present invention relates to the field of blockchain, and in particular to an asset tracking management system and method based on a non-account balance mode blockchain. Background Art

[0002] With the rapid development of blockchain technology, non-account balance model blockchains, represented by Bitcoin, have created a new category of blockchains since their birth in 2008. However, while the decentralized nature of such non-account balance model blockchains brings advantages, it also brings many challenges to the tracking and management of on-chain assets.

[0003] The ledger structure implementation of non-account balance mode blockchain is quite different from that of conventional blockchains that run transactions based on smart contracts. Specifically, the ledger structure of non-account balance mode blockchain does not rely on the traditional concept of account balance, but records the asset status of the address by tracking UTXO (unspent transaction output). This makes it difficult to track and analyze address information directly. In addition, since there is no centralized management agency, it is also difficult to determine the flow and ownership of assets on the non-account balance mode blockchain.

[0004] On the other hand, in non-account balance mode blockchains, the address generation methods are complex and diverse. For example, more sub-public keys can be derived from the same address public key. Furthermore, the same public key can generate addresses of different encoding types according to different application scenarios. This makes it difficult to sort out and verify the relationship between addresses.

[0005] In addition, the continuous emergence of asset-anchored cross-chain bridges in recent years has made the on-chain asset management of the underlying non-account balance model blockchain to which the cross-chain assets are anchored increasingly complex and important.

[0006] In order to solve these problems, there is an urgent need for an efficient and accurate non-account balance model blockchain on-chain asset tracking management service system and method to improve the security and manageability of on-chain assets and provide strong technical support for regulators, holders, and trading platforms of relevant on-chain assets. Summary of the invention

[0007] In view of the shortcomings of the prior art, the present invention proposes an asset tracking management system and method based on a non-account balance mode blockchain. The on-chain assets of the non-account balance mode blockchain are tracked and managed comprehensively and efficiently, the dynamic changes of on-chain assets are monitored in real time, potential risks are detected and handled in a timely manner, the security of assets is effectively guaranteed, and accurate monitoring and scientific management of assets are achieved, providing solid technical support for regulatory agencies, holders and trading platforms of on-chain assets of the non-account balance mode blockchain.

[0008] The specific technical solutions are as follows:

[0009] An asset tracking management system based on a non-account balance mode blockchain, comprising: a blockchain data indexing layer, an address analysis association layer, an address legitimacy verification layer, an address data management layer, and an external query service layer;

[0010] The blockchain data index layer is used to achieve real-time synchronization of non-account balance mode blockchain block information and store address information index locally, and build a blockchain address index program interface for other layers to obtain data;

[0011] The address analysis association layer is used to construct an address relationship network by analyzing the address transaction history of the local non-account balance mode blockchain;

[0012] The address legitimacy verification layer is used to verify the legitimacy of the addresses in the address relationship network. The legitimacy verification includes: root public key derived address cluster verification, same public key conversion type address verification, and whitelist address verification. If any of these verifications pass, the address is considered legal. Otherwise, the address is considered illegal and the user is notified of the illegal address.

[0013] The address data management layer is used for the management of assets on the non-account balance mode blockchain, and updates, saves and counts the address balance information of the legal addresses in the address relationship network in real time. The address balance information and balance change records are stored in the database;

[0014] The external query service layer is used to provide external queries through an interface that conforms to the representational state transfer architectural style, and provide the required on-chain asset information to authorized users.

[0015] Furthermore, the blockchain data index layer includes: a block synchronization module, an address transaction index module, and an address balance acquisition module;

[0016] The block synchronization module synchronizes the latest block of the non-account balance mode blockchain to the local based on the non-account balance mode blockchain full node service program;

[0017] The address transaction index module uses a blockchain index program to implement an index of address transaction history in a non-account balance mode blockchain, and provides a blockchain address index program interface;

[0018] The address balance acquisition module uses the blockchain address index program interface to obtain the real-time balance information of the specified address from the local query.

[0019] Furthermore, the address analysis association layer includes: a transaction information parsing module, an address association building module, and an asset flow combing module;

[0020] The transaction information parsing module starts from the starting address of the transaction and comprehensively parses the UTXO input and UTXO output in each transaction directly or indirectly associated with the starting address in the non-account balance mode blockchain;

[0021] The address association construction module, based on the analysis of the transaction by the transaction information analysis module, filters the output addresses in the transaction according to the filtering conditions, and then constructs the address relationship network through the queue mechanism and breadth-first algorithm;

[0022] The asset flow combing module is used to visualize the address association relationship and the flow of assets on the chain.

[0023] Furthermore, the filtering condition is: if there is a situation where the output address is the same as the input address, then the output address is excluded.

[0024] Furthermore, the address legitimacy verification layer includes: a root public key derived address cluster verification module, a same public key conversion type address verification module, a whitelist address verification module, and an illegal address notification module;

[0025] The root public key derived address cluster verification module is used to perform root public key derived address cluster verification, using the specified root public key and key generation path, traversing the key generation path index within the specified range, deriving and calculating possible derived child public keys based on the root public key, the possible derived child public keys and their corresponding addresses are recorded as derived address clusters derived from the root public key, and the derived address clusters derived from the root public key are stored in the database; when a new address appears in the address relationship network, it is determined whether the new address belongs to the derived address cluster derived from the root public key, if so, the new address is determined to be legal; if not, the root public key derived address cluster verification of the new address is determined to have failed;

[0026] The same public key conversion type address verification module is used to perform the same public key conversion type address verification, and generates multiple different types of addresses according to the address generation method subsequently selected by each derived sub-public key, and saves them in the database. The address generation method includes: generation rules, encryption algorithm, encoding method, and application scenario characteristics; when a new address appears in the address relationship network, it is determined whether the new address exists in the database. If so, the new address is determined to be legal; if not, the same public key conversion type address verification of the new address is determined to fail;

[0027] The whitelist address verification module is used to perform whitelist address verification. A preset whitelist is stored and maintained in a configuration file in the system memory. The addresses in the whitelist are legal addresses that have passed review and confirmation. When a new address appears in the address relationship network, it is determined whether the new address is in the whitelist. If so, the new address is determined to be legal; otherwise, the whitelist address verification of the new address is determined to fail.

[0028] If for a new address appearing in the address relationship network, the judgment results in the root public key derived address cluster verification module, the same public key conversion type address verification module, and the whitelist address verification module are all failed, then the new address is judged to be an illegal address, and the illegal address notification module triggers the corresponding exception notification mechanism to notify the downstream entities of the system.

[0029] Furthermore, the key generation path specification is based on the Bitcoin proposal standards: BIP-32 and BIP-44; the database for storing the derived address clusters and different types of addresses derived from the root public key is PostgreSQL;

[0030] The different types of addresses include: any one of the following: public key hash address, uncompressed public key hash address, multi-signature payment address, script hash payment address, nested segregated witness address, witness public key hash payment address, script hash multi-signature payment address, script hash segregated witness multi-signature payment address, Merkelized abstract syntax tree payment address, native segregated witness address, and their variants and combinations;

[0031] The abnormal notification mechanism is to write to the Kafka message queue and notify the downstream entities of the system according to the configuration of the events subscribed by the user.

[0032] Furthermore, the address data management layer includes: an address status refresh module, a new transaction filtering module, and an address asset inventory module;

[0033] The address status refresh module is used to periodically obtain the latest full transaction history information of each address in the address relationship network from the blockchain data index layer, and the full transaction history information includes all relevant transaction records of the UTXO owned by the address as transaction input or output;

[0034] The new transaction filtering module adopts a timestamp-based filtering method to locally record the update timestamp of the most recent full transaction history information of each address; after obtaining new full transaction history information from the address status refresh module, it traverses the full transaction history information and checks the transaction timestamp. If it is less than or equal to the most recent update timestamp, the transaction is considered to have been processed and filtered; otherwise, the transaction is considered to be a new transaction, triggering the address asset inventory module to perform relevant update operations;

[0035] The address asset inventory module is used to store and manage the balance and balance change records of each legal address in the address relationship network by using a combination of a hash table and a tree structure.

[0036] Furthermore, the external query service layer includes: an access control module, a request frequency control module, and a data request service module;

[0037] The access control module is used to verify the user's access rights; when an external user initiates a query request, it checks whether the request contains an access token, and returns a corresponding error prompt if it does not; if it does, the access token is verified according to a predefined key and algorithm, and if the verification is successful, the user is allowed to access; if the verification fails, access is denied and an error message is returned to inform the user that the access token is invalid;

[0038] The request frequency control module is used to record the request time information of each client; the module obtains the IP address of the client and maintains a mapping locally to record the last request time of each IP address; when a new request is received, the last request time of the client is checked. If the interval from the last request time is less than the preset time limit, the request is considered too frequent, and a corresponding error response is returned to prompt the user to try again later; if the request time interval meets the requirements, the query request is allowed to continue, and the last request time record of the client is updated;

[0039] The data request service module is used to establish a connection with the database that stores balance information and balance change records at the address data management layer; after the query request initiated by the external user is verified by the access control module and the request frequency control module, the data request service module obtains the required on-chain asset information from the database according to the preset query statement, processes and encapsulates the query results, and returns them to the external user.

[0040] Furthermore, the access token uses JSON Web Token; the query result is processed and encapsulated into a data structure of JSON;

[0041] The external users include: participants in relevant Bitcoin asset pledge agreements, Bitcoin asset locking and custody, cross-chain bridge asset anchoring supervision, and decentralized financial project market value statistics.

[0042] An asset tracking management method based on a non-account balance mode blockchain is implemented according to the asset tracking management system based on a non-account balance mode blockchain, comprising the following steps:

[0043] S1: Use the full node service program and blockchain index program to synchronize the latest block of non-account balance mode blockchain transactions to the local computer, and build a blockchain address index program interface to implement address transaction history indexing and balance query functions;

[0044] S2: Taking the transaction start address as the entry point, analyze the UTXO input and output in the transaction directly or indirectly associated with the start address, exclude some output addresses according to specific filtering conditions, and use the queue mechanism and breadth-first algorithm to build a comprehensive address relationship network to sort out the flow of assets;

[0045] S3: For the new address in the address relationship network, the root public key derived address cluster verification, the same public key conversion type address verification and the whitelist address verification are sequentially performed. If any one of the verifications passes, the new address is considered legal. If all of them fail, the new address is determined to be an illegal address and the abnormal notification mechanism is triggered; the root public key derived address cluster verification calculates the derived child public key of the specified root public key according to the specified root public key and the key generation path, and determines whether the new address belongs to the address corresponding to these derived child public keys. If so, the verification passes, otherwise it fails; the same public key conversion type address verification generates different types of addresses according to the derived child public keys according to the address generation method, and the address generation method includes: generation rules, encryption algorithms, and encoding methods; determines whether the new address belongs to these different types of addresses. If so, the verification passes, otherwise it fails; the whitelist address verification determines whether the new address belongs to an address in a preset whitelist. If so, the verification passes, otherwise it fails;

[0046] S4: Through the blockchain address index program interface provided by S1, the full transaction history information is obtained regularly, and new transactions are filtered out based on timestamps. For new transactions, the hash table and tree structure are combined to count the legal address balances and save the change records in the database;

[0047] S5: When receiving an external query request, first perform user authority verification and verify the validity of the user access token. If it is invalid, deny access. If it is valid, further check whether the request time interval meets the requirements. If it does, connect to the database described in S4 and obtain asset information according to the preset query statement. After processing and encapsulating it into the required format, return it to the external user to achieve interaction with the outside.

[0048] The beneficial effects of the present invention are:

[0049] (1) The system of the present invention solves the problem of difficulty in indexing address information of blockchains in non-account balance mode, realizes the determination of asset flows between addresses in blockchains in non-account balance mode, and provides a method for constructing and verifying a legal address relationship network.

[0050] (2) The present invention can provide effective regulatory tools for regulatory agencies, helping to maintain the healthy and stable development of non-account balance model blockchains and related digital asset markets; provide asset security and convenient management tools for asset holders on non-account balance model blockchains, enabling them to understand the status of their assets in real time; and provide reliable asset tracking and risk management methods for non-account balance model blockchain asset trading platforms (such as cross-chain bridges based on asset anchoring on non-account balance model blockchains), thereby ensuring the security and stability of asset transactions. BRIEF DESCRIPTION OF THE DRAWINGS

[0051] Figure 1 It is a main block diagram of an asset tracking and management system based on a non-account balance mode blockchain in an embodiment of the present invention.

[0052] Figure 2 It is a flowchart of the blockchain data index layer including modules and implementation methods in an embodiment of the present invention.

[0053] Figure 3 The invention discloses a flowchart of a method for implementing address association analysis and including modules in an address analysis association layer in an embodiment of the invention.

[0054] Figure 4 The address legitimacy verification layer includes modules and a flow chart of a method for verifying address legitimacy in an embodiment of the present invention.

[0055] Figure 5 It is a flow chart of the modules included in the address data management layer and the method for implementing address data management in an embodiment of the present invention.

[0056] Figure 6 It is a flow chart of the method of including modules and providing services in the external query service layer in an embodiment of the present invention. DETAILED DESCRIPTION

[0057] In order to make the purpose, technical solution and advantages of the embodiments of the present application clearer, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of this application.

[0058] In the following description, reference is made to “one specific embodiment”, which describes a subset of all possible embodiments, but it can be understood that “one specific embodiment” describes the same subset or different subsets of all possible embodiments and can be combined with each other without conflict.

[0059] Unless otherwise defined, all technical science and technology used herein have the same meaning as commonly understood by those skilled in the art of the present invention. The terms used herein are only for the purpose of describing the embodiments of the present invention and are not intended to limit the present invention.

[0060] Before further describing the embodiments of the present invention in detail, the nouns and terms involved in the embodiments of the present invention are described. The nouns and terms involved in the embodiments of the present invention are subject to the following explanations.

[0061] (1) UTXO (unspent transaction output): In non-account balance mode blockchains, UTXO is a key data structure and transaction processing mechanism. As a discrete unit representing the number of assets on the chain, it is in an "unused" state and is associated with historical transaction outputs. Transactions transfer value by consuming old UTXO to generate new UTXO, ensuring that transactions are independent and traceable. Non-account balance mode blockchains use this to verify the validity of UTXO and confirm the legality of transactions. The nodes of non-account balance mode blockchains maintain the consistency of UTXO sets through a consensus mechanism, ensuring efficient and secure asset recording and transaction processing, and achieving stable circulation of assets on the chain.

[0062] (2) Blockchain data index: For non-account balance mode blockchains, blockchain data indexes include indexes for block information, transaction information, address information, etc. Among them, the index for block information includes the mapping relationship between key identifiers such as block height and block hash value and detailed block data, so that the corresponding complete block content can be quickly found based on these identifiers. The index for transaction information involves the association between transaction hash value and detailed transaction data such as transaction UTXO input, UTXO output, timestamp, etc., so that specific transactions can be quickly located and queried. For address information, the index will establish a connection between the address and the transaction history, balance information (data that can be regarded as balance-related data calculated through UTXO in non-account balance mode), etc. related to the address, making it easier to track the asset changes and transaction status of the address.

[0063] Based on the above architecture, the embodiment of the present invention proposes an asset tracking management system based on a non-account balance mode blockchain. The system adopts a hierarchical design, such as Figure 1 As shown in the figure, it includes: blockchain data index layer, address analysis and association layer, address legitimacy verification layer, address data management layer, and external query service layer. Among them, the blockchain data index layer and address analysis and association layer continue to run during the system operation, synchronize and update the latest blockchain block information, address information index and address relationship network in real time; the address legitimacy verification layer, address data management layer, and external query service layer will only be called when asset tracking is required. The structure and function of each layer are further discussed below.

[0064] L1, blockchain data index layer: used to achieve real-time synchronization of non-account balance mode blockchain block information and address information indexing, providing a broader data foundation for subsequent analysis and management of other levels of the system. Figure 2 As shown in the figure, the blockchain data index layer includes: block synchronization module, address transaction index module, and address balance acquisition module. Each module performs further processing based on the results of the previous module. The functions of each module are as follows:

[0065] Block synchronization module: This module is based on the non-account balance mode blockchain full node service program, and synchronizes the latest block of the non-account balance mode blockchain transaction to the local. This module provides basic block information for the address transaction index module of this layer. In a preferred embodiment of the present invention, the non-account balance mode blockchain full node service program uses Bitcoin Core.

[0066] Address transaction index module: This module uses a locally running blockchain browser instance equipped with a blockchain indexer (Indexer) to implement the indexing of address transaction history in a non-account balance mode blockchain. This module also provides a full-featured blockchain address indexer interface for the address balance acquisition module at this layer. In a preferred embodiment of the present invention, the blockchain indexer uses Electrum Server (also known as Electrs) and the blockchain browser instance uses EsploraBlock Explorer.

[0067] Address balance acquisition module: This module uses the blockchain address index program interface to obtain the real-time balance information of the specified address from the local query, providing the data basis for the accurate statistical function of the on-chain asset balance for the address data management layer in this system. In a preferred embodiment of the present invention, the blockchain address index program interface uses the Electrs backend API.

[0068] L2, address analysis association layer: used to analyze the address transaction history of the non-account balance mode blockchain, find other addresses that interact with a specific address to build an address relationship network, and thus sort out the flow of assets on the non-account balance mode blockchain. Figure 3 As shown in the figure, the address analysis association layer includes: transaction information parsing module, address association construction module, and asset flow combing module. Each module completes further data processing functions based on the data processing results of the previous module. The functions of each module are as follows:

[0069] Transaction information parsing module: Starting from the starting address of the transaction, this module comprehensively parses the UTXO input and output in each transaction directly or indirectly associated with the starting address in the non-account balance mode blockchain. In one transaction, there may be one or more UTXO inputs and one or more UTXO outputs.

[0070] In a preferred embodiment of the present invention, UTXO is bound to one and only one on-chain address, while one on-chain address can contain multiple UTXOs.

[0071] In a preferred embodiment of the present invention, in a transaction directly or indirectly associated with a starting address, one or more UTXO inputs and one or more UTXO outputs allow the following forms of transaction behavior in a non-account balance mode blockchain:

[0072] ① Transfer from a single UTXO input address to a single other UTXO output address.

[0073] ② Transfers from a single UTXO input address to multiple other UTXO output addresses.

[0074] ③ Transfers from multiple UTXO input addresses to multiple other UTXO output addresses.

[0075] ④ Transfers from multiple UTXO input addresses to a single other UTXO output address.

[0076] Address association construction module: Based on the analysis of transactions by the transaction information analysis module, this module filters the output addresses in the transactions according to the filtering conditions, incorporates them into the analysis scope of the address relationship network, and expands the address relationship network.

[0077] In a preferred embodiment of the present invention, the filtering condition is: when the following situation occurs, that is, when there is an output address that is the same as the input address, the output address is excluded. This situation often occurs in UTXO splitting or change transactions in actual transactions. That is, based on this filtering condition, the output address that is the same as the input address is screened out, and the remaining output addresses are included in the address relationship network analysis scope.

[0078] In a preferred embodiment of the present invention, the address relationship network analysis scope not only considers directly associated addresses, but also continuously expands the scope of associated addresses through a queue mechanism and a breadth-first algorithm, thereby being able to construct a comprehensive address relationship network that covers all addresses directly and indirectly related to the starting address.

[0079] Asset flow sorting module: Based on the accurate analysis of transaction information in the non-account balance mode blockchain by the transaction information analysis module, this module clarifies the address association relationship and the flow of assets on the chain. Based on the address relationship network constructed by the address association construction module, this module is used to efficiently track the transfer path of assets between associated addresses and present the effect of visualization (the main function of this module), thereby helping to determine the ownership of assets and providing support for on-chain asset tracking and management.

[0080] L3, address legitimacy verification layer: This layer is used to verify the legitimacy of addresses in the address relationship network of assets on the blockchain in non-account balance mode from the perspective of ensuring asset security. The legitimacy verification covers root public key derived address cluster verification, same public key conversion type address verification and whitelist address verification. Correspondingly, if Figure 4 As shown, the address legitimacy verification layer includes: root public key derived address cluster verification module, same public key conversion type address verification module, whitelist address verification module, illegal address notification module. The above three verification modules are verified sequentially or simultaneously. If any of the verifications are passed, the address is considered legal. Otherwise, the illegal address notification module in this layer will notify the user of the illegal address. The functions of each module are as follows:

[0081] Root public key derived address cluster verification module: This module uses the specified root public key (Root Public Key) and key generation path (Key Derivation Path) to traverse the key generation path index (PathIndex) within the specified range, derives and calculates possible derived child public keys based on the root public key, and saves these possible derived child public keys and their corresponding addresses (i.e., derived address clusters derived from the root public key) in the database. When a new address appears in the address relationship network constructed by the address analysis association layer, the database is searched to see whether the address is the expected derived address (i.e., whether it belongs to the derived address cluster derived from the root public key). If so, the address is considered legal; if not, the address is input into the same public key conversion type address verification module for verification.

[0082] In a preferred embodiment of the present invention, the key generation path specification is referenced from the Bitcoin proposal standards: BIP-32 (Hierarchical Deterministic Wallets) and BIP-44 (Multi-Account Hierarchy for Deterministic Wallets).

[0083] In a preferred embodiment of the present invention, the database storing the address corresponding to the derived child public key is PostgreSQL.

[0084] Same public key conversion type address verification module: Generate different types of addresses according to the address generation method selected by each derived sub-public key (each derived sub-public key corresponds to multiple different types of addresses, recorded as same public key conversion type addresses), and save them in the database; the address generation method includes: generation rules, encryption algorithms, encoding methods and application scenario characteristics. When a new address appears in the address relationship network constructed by the address analysis association layer, it is first necessary to find out whether the address exists in the database. If it exists, it is considered legal; if it does not exist, the address is entered into the whitelist address verification module for verification.

[0085] In a preferred embodiment of the present invention, different types of addresses include: P2PKH (PayTo Public Key Hash), P2PKH_UNCOMPRESSED (Uncompressed Public Key Hash), P2MS (Pay-to-Multisig Address), P2SH (Pay-to-Script-Hash), P2SH_P2WPKH (Nested SegWit Address), P2WPKH (Pay To Witness Public Key Hash), P2SH_P2MS (Script Hash Multi-Signature Payment Address), P2SH_P2WSH_P2MS (Script Hash Segregated Witness Multi-Signature Payment Address), P2TR (Merkle Abstract Syntax Tree Payment Address, Taproot Address), BECH32 (Native SegWit Address) and other different encoding methods and their variants and combinations.

[0086] In a preferred embodiment of the present invention, the database stored in the address of the same public key conversion type is PostgreSQL.

[0087] Whitelist address verification module: This module maintains a pre-set whitelist in the configuration file before the system is running. The addresses in these whitelists are legal addresses that have been strictly reviewed and confirmed. When the system is running, the module loads this whitelist into the memory in the form of a list. When a new address appears in the address relationship network constructed by the address analysis association layer, the address can be compared with the address in the whitelist to determine its legality. If the address exists in the whitelist, it is determined to be legal; otherwise, the address is determined to be illegal and the illegal address notification module is called.

[0088] Illegal address notification module: When a new address that appears in the address relationship network cannot pass the above three address verification methods, the address is determined to be an illegal address and the corresponding abnormal notification mechanism is triggered so that users can take timely measures to deal with potential security risks.

[0089] In a preferred embodiment of the present invention, the abnormal notification mechanism is to write to the Kafka message queue and implement notification to the downstream entities of the system (ie, users) according to the configuration of the events subscribed by the users.

[0090] L4, address data management layer: used for the management of assets on the blockchain in non-account balance mode, and for real-time updating, saving and statistics of address balance information of legal addresses in the address relationship network. Figure 5 As shown, the address data management layer includes: address status refresh module, new transaction filtering module, and address asset inventory module. After the address status refresh module obtains the latest transaction data, the new transaction filtering module filters and further triggers the address asset inventory module, which uses a specific data structure to count the balance of each address in the address relationship network and trace the history. The functions of each module are as follows:

[0091] Address status refresh module, which periodically obtains the latest full transaction history information of each address in the address relationship network from the blockchain data index layer. This information includes all relevant transaction records of the UTXO owned by the address as transaction input or output.

[0092] New transaction filtering module, this module uses a timestamp-based filtering method to locally record the update time of the most recent full transaction history information of each address. After obtaining new full transaction history information from the address status refresh module, traverse the full transaction history information and check the transaction timestamp of each transaction. If it is less than or equal to the most recent update timestamp, the transaction is considered to have been processed and filtered; if it is greater than the timestamp corresponding to the last update time, the transaction is considered a new transaction, which triggers the address asset inventory module of this layer to perform related update operations. For example, when a transaction involves a change in funds of a certain address, the module can obtain the transaction information within milliseconds and trigger the address asset inventory module to update the balance, transaction history and other attributes of the address corresponding to the transaction information.

[0093] The address asset inventory module is responsible for accurately counting the balances of each legal address in the address relationship network. It uses a combination of hash tables and tree structures to store and manage on-chain asset balance information. This data structure can quickly locate and update address balances while ensuring data accuracy. In addition to the current on-chain asset balance statistics, this module also has a historical data tracing function. Specifically, this module saves the balance change records of each address, and can completely restore the change track of the address balance through timestamps and version control mechanisms. The address asset inventory module stores on-chain asset balance information and balance change records in the database.

[0094] In a preferred embodiment of the present invention, the address relationship network is a set of underlying asset addresses based on a non-account balance model blockchain asset cross-chain bridge.

[0095] L5, external query service layer: through the interface that conforms to the REST (Representational State Transfer) architectural style, it facilitates external queries and provides a convenient way for asset managers and regulators to achieve accurate management and monitoring of assets within the specified address range. Figure 6 As shown, the external query service layer includes: access control module, request frequency control module, and data request service module. The access control module and the request frequency control module can be executed sequentially or synchronously, and the data request service module starts running. The functions of each module are as follows:

[0096] Access control module, which is responsible for verifying the user's access rights. When an external user initiates a query request, the module checks whether the request contains an access token. If so, it further verifies whether the token is valid. If not, it returns a corresponding error prompt. The verification of whether the token is valid requires the verification of the access token based on the predefined key and algorithm. If the verification is successful, the user is allowed to access; if the verification fails, access is denied and an error message is returned to inform the user that the access token is invalid.

[0097] In a preferred embodiment of the present invention, the access token is a JSON Web Token (hereinafter referred to as JWT).

[0098] The request frequency control module is responsible for recording the request time information of each client. The module obtains the IP address of the client and maintains a mapping locally to record the last request time of each IP address. When a new request is received, the last request time of the client is checked first. If the interval from the last request time is less than the preset time limit, the request is considered too frequent and a corresponding error response is returned to prompt the user to try again later; if the request time interval meets the requirements, the query request is allowed to continue and the last request time record of the client is updated.

[0099] The data request service module is responsible for establishing a connection with the database maintained by the address asset inventory module of the address data management layer. After the access control module is verified and the request frequency control module is verified, the module obtains the required on-chain asset information from the database according to the preset query statement. After obtaining the information, the data is processed and encapsulated, and the query results are parsed and encapsulated into a JSON (JavaScript Object Notation) data structure for subsequent return to external users.

[0100] In a preferred embodiment of the present invention, external users include: participants of the relevant Bitcoin asset pledge agreement (Babylon Staking) (Bedrock, Solv, Pump, Lorenzo, Lombard, etc.), Ignition (Bitcoin asset locking and custody), Chainlink Proof of Reserve (cross-chain bridge asset anchoring supervision), and Deflama (decentralized financial project market value statistics). These external users query the information of one or more associated addresses through the external query service layer of the system, realizing the effective clustering, inventory, and asset proof of the legal addresses of the non-account balance mode blockchain.

[0101] According to the asset tracking and management system based on the non-account balance mode blockchain, the embodiment of the present invention also proposes an asset tracking and management method based on the non-account balance mode blockchain, and each layer works in coordination in sequence to ensure that the system effectively implements the tracking and management function of the assets on the non-account balance mode blockchain, such as Figure 2-Figure 6 As shown, the method specifically comprises the following steps:

[0102] S1: This step is implemented based on the blockchain data index layer. First, the block synchronization module is started. Based on the non-account balance mode blockchain full node service program such as BitcoinCore, the blockchain network is monitored in real time and the latest transaction blocks are synchronized to the local, providing basic block information for the address transaction index module. The address transaction index module uses the Esplora Block Explorer blockchain browser instance equipped with an index program such as Electrum Server to index the address transaction history in the non-account balance mode blockchain, build an address index system, and provide a blockchain address index program interface such as the Electrs backend API to the address balance acquisition module of this layer and other layers in the system, so as to facilitate the query of the historical transactions and the latest balance of the specified address. The address balance acquisition module receives the specified address balance query request based on the blockchain address index program interface, sends a query instruction to the local index data, obtains and preprocesses the real-time balance information of the specified address, and provides a data basis for the operation of the address data management layer of the system.

[0103] S2: This step is implemented based on the address analysis association layer. First, starting from the transaction start address, the UTXO input and output in the transaction directly or indirectly associated with the start address are analyzed, and the corresponding relationship and key transaction information are accurately recorded (based on the transaction information analysis module). Based on the analysis results, the output address is filtered according to specific filtering conditions (such as excluding the situation where the output address is the same as the input address, which is common in UTXO splitting or change transactions), and a comprehensive address relationship network is constructed with the help of the queue mechanism and breadth-first algorithm, covering all addresses directly and indirectly related to the start address (based on the address association construction module). Using the constructed address relationship network and the parsed transaction information, the transfer path of assets between associated addresses can be efficiently tracked, and the asset flow effect can be presented through visualization technology to determine the asset ownership, providing a clear context guide for asset tracking and management (based on the asset flow combing module).

[0104] S3: This step is implemented based on the address legitimacy verification layer. For new addresses in the address relationship network, the root public key derived address cluster verification, the same public key conversion type address verification and the whitelist address verification are performed in turn. If any of the verifications pass, the new address is considered legal. If none of them pass, the new address is judged to be an illegal address and the abnormal notification mechanism is triggered.

[0105] Specifically, the root public key derived address cluster verification uses the specified root public key and the key generation path referenced in the Bitcoin proposal standard to traverse the key generation path index, calculate and store the derived child public key and its corresponding address in the PostgreSQL database; when a new address appears in the address relationship network, it searches the database to see if it is a legal derived address. If so, the verification passes. If not, the same public key conversion type address verification is performed. The same public key conversion type address verification generates different types of addresses according to the derived child public key related rules and stores them in the PostgreSQL database. When a new address appears, it is first checked to see if it exists in the database. If not, a whitelist address verification is performed. The new address is compared with the whitelist set in the configuration file before the system runs and loaded into the memory to determine the legitimacy. If the new address exists in the whitelist, the verification passes, otherwise it fails. If the new address fails to pass the above three verifications, it is determined to be an illegal address, triggering the abnormal notification mechanism written to the Apache Kafka message queue, and notifying the downstream system (or user) according to the user subscription event configuration to ensure asset security.

[0106] S4: This step is implemented based on the address data management layer. The address status refresh module periodically obtains the full transaction history information of each address in the address relationship network from the blockchain data index layer. This information contains all UTXO transaction records related to the address. The new transaction filtering module adopts a timestamp-based filtering method to record the most recent transaction history information update timestamp of each address. After obtaining the full transaction history information, it traverses and checks the transaction timestamp. If it is greater than the last update timestamp, it is considered a new transaction, triggering the address asset inventory module to update. The address asset inventory module uses a combination of hash tables and tree structures to store and manage on-chain asset balance information in the database, so as to quickly locate and update the address balance, and save the balance change record in the database. The balance change track is completely restored through the timestamp and version control mechanism, providing efficient and accurate protection for asset data management.

[0107] S5: This step is implemented based on the external query service layer. When receiving an external query request, the access control module works first to check whether the request contains a valid JWT access token. If it does not exist, an error message is returned. If it exists, the token is verified based on the predefined key and algorithm. If it fails, access is denied and an error message is returned. After the access permission is verified, the request frequency control module checks the time interval between the new request made by the client and the last request time. If it is less than the preset time limit, an error response is returned to prompt the user to try again later. Otherwise, the request is allowed to continue and the last request time record is updated. After verification by the above two modules, the data request service module establishes a connection with the database maintained by the address asset inventory module of the address data management layer, obtains the on-chain asset information according to the preset query statement, processes and encapsulates it into a JSON format data structure, and then returns it to external users, providing convenient asset query and monitoring services for asset managers and regulators.

[0108] The present invention provides an asset tracking management system and method based on a non-account balance mode blockchain, focusing on a non-account balance mode blockchain in the field of blockchain technology, and solving the various problems caused by this type of blockchain that records the asset status of addresses by tracking UTXO in a non-traditional way (such as difficulty in indexing address information, difficulty in determining asset flows, and complexity in address relationship network construction and address verification, etc.). The asset tracking and management system and method based on a non-account balance mode blockchain of the present invention can effectively improve the security and manageability of assets on a non-account balance mode blockchain chain, provide strong technical support for regulators, holders, and trading platforms of assets on this type of blockchain chain, and promote the healthy, compliant, and stable development of the relevant digital asset market.

[0109] Those skilled in the art can understand that the above are only preferred examples of the invention and are not intended to limit the invention. Although the invention is described in detail with reference to the above examples, those skilled in the art can still modify the technical solutions recorded in the above examples or replace some of the technical features therein with equivalents. Any modification, equivalent replacement, etc. made within the spirit and principle of the invention shall be included in the protection scope of the invention.

Claims

1. An asset tracking and management system based on a non-account balance mode blockchain, characterized in that: include: Blockchain data indexing layer, address analysis and association layer, address legitimacy verification layer, address data management layer, and external query service layer; The blockchain data index layer is used to achieve real-time synchronization of non-account balance mode blockchain block information and store address information index locally, and build a blockchain address index program interface for other layers to obtain data; The address analysis association layer is used to construct an address relationship network by analyzing the address transaction history of the local non-account balance mode blockchain; The address analysis and association layer includes: a transaction information parsing module, an address association building module, and an asset flow combing module; The transaction information parsing module starts from the starting address of the transaction and comprehensively parses the UTXO input and UTXO output in each transaction directly or indirectly associated with the starting address in the non-account balance mode blockchain; The address association construction module, based on the analysis of the transaction by the transaction information analysis module, filters the output addresses in the transaction according to the filtering conditions, and then constructs the address relationship network through the queue mechanism and breadth-first algorithm; The asset flow combing module is used to visualize the address association relationship and the flow of assets on the chain; The address legitimacy verification layer is used to verify the legitimacy of the addresses in the address relationship network. The legitimacy verification includes: root public key derived address cluster verification, same public key conversion type address verification, and whitelist address verification. If any of these verifications pass, the address is considered legal. Otherwise, the address is considered illegal and the user is notified of the illegal address. The address data management layer is used for the management of assets on the non-account balance mode blockchain, and updates, saves and counts the address balance information of the legal addresses in the address relationship network in real time. The address balance information and balance change records are stored in the database; The address data management layer includes: an address status refresh module, a new transaction filtering module, and an address asset inventory module; The address status refresh module is used to periodically obtain the latest full transaction history information of each address in the address relationship network from the blockchain data index layer, and the full transaction history information includes all relevant transaction records of the UTXO owned by the address as transaction input or output; The new transaction filtering module adopts a timestamp-based filtering method to locally record the update timestamp of the most recent full transaction history information of each address; after obtaining new full transaction history information from the address status refresh module, it traverses the full transaction history information and checks the transaction timestamp. If it is less than or equal to the most recent update timestamp, the transaction is considered to have been processed and filtered; otherwise, the transaction is considered to be a new transaction, triggering the address asset inventory module to perform relevant update operations; The address asset inventory module is used to store and manage the balance and balance change records of each legal address in the address relationship network by using a combination of a hash table and a tree structure; The external query service layer is used to provide external queries through an interface that conforms to the representational state transfer architectural style, and provide the required on-chain asset information to authorized users.

2. The asset tracking and management system based on the non-account balance mode blockchain according to claim 1 is characterized in that: The blockchain data index layer includes: a block synchronization module, an address transaction index module, and an address balance acquisition module; The block synchronization module synchronizes the latest block of the non-account balance mode blockchain to the local based on the non-account balance mode blockchain full node service program; The address transaction index module uses a blockchain index program to implement an index of address transaction history in a non-account balance mode blockchain, and provides a blockchain address index program interface; The address balance acquisition module uses the blockchain address index program interface to obtain the real-time balance information of the specified address from the local query.

3. The asset tracking and management system based on the non-account balance mode blockchain according to claim 1 is characterized in that: The filtering condition is: if there is a situation where the output address is the same as the input address, then the output address is excluded.

4. The asset tracking and management system based on the non-account balance mode blockchain according to claim 1 is characterized in that: The address legitimacy verification layer includes: root public key derived address cluster verification module, same public key conversion type address verification module, whitelist address verification module, illegal address notification module; The root public key derived address cluster verification module is used to perform root public key derived address cluster verification, using the specified root public key and key generation path, traversing the key generation path index within the specified range, deriving and calculating possible derived child public keys based on the root public key, the possible derived child public keys and their corresponding addresses are recorded as derived address clusters derived from the root public key, and the derived address clusters derived from the root public key are stored in the database; when a new address appears in the address relationship network, it is determined whether the new address belongs to the derived address cluster derived from the root public key, if so, the new address is determined to be legal; if not, the root public key derived address cluster verification of the new address is determined to have failed; The same public key conversion type address verification module is used to perform the same public key conversion type address verification, and generates multiple different types of addresses according to the address generation method subsequently selected by each derived sub-public key, and saves them in the database. The address generation method includes: generation rules, encryption algorithm, encoding method, and application scenario characteristics; when a new address appears in the address relationship network, it is determined whether the new address exists in the database. If so, the new address is determined to be legal; if not, the same public key conversion type address verification of the new address is determined to fail; The whitelist address verification module is used to perform whitelist address verification. A preset whitelist is stored and maintained in a configuration file in the system memory. The addresses in the whitelist are legal addresses that have passed review and confirmation. When a new address appears in the address relationship network, it is determined whether the new address is in the whitelist. If so, the new address is determined to be legal; otherwise, the whitelist address verification of the new address is determined to fail. If for a new address appearing in the address relationship network, the judgment results in the root public key derived address cluster verification module, the same public key conversion type address verification module, and the whitelist address verification module are all failed, then the new address is judged to be an illegal address, and the illegal address notification module triggers the corresponding exception notification mechanism to notify the downstream entities of the system.

5. The asset tracking and management system based on the non-account balance mode blockchain according to claim 4 is characterized in that: The key generation path specification is based on the Bitcoin proposal standards: BIP-32 and BIP-44; the database for storing the derived address clusters and different types of addresses derived from the root public key is PostgreSQL; The different types of addresses include: any one of the following: public key hash address, uncompressed public key hash address, multi-signature payment address, script hash payment address, nested segregated witness address, witness public key hash payment address, script hash multi-signature payment address, script hash segregated witness multi-signature payment address, Merkelized abstract syntax tree payment address, native segregated witness address, and their variants and combinations; The abnormal notification mechanism is to write to the Kafka message queue and notify the downstream entities of the system according to the configuration of the events subscribed by the user.

6. The asset tracking and management system based on non-account balance mode blockchain according to claim 1, characterized in that: The external query service layer includes: access control module, request frequency control module, and data request service module; The access control module is used to verify the user's access rights; when an external user initiates a query request, it checks whether the request contains an access token, and returns a corresponding error prompt if it does not; if it does, the access token is verified according to a predefined key and algorithm, and if the verification is successful, the user is allowed to access; if the verification fails, access is denied and an error message is returned to inform the user that the access token is invalid; The request frequency control module is used to record the request time information of each client; the module obtains the IP address of the client and maintains a mapping locally to record the last request time of each IP address; when a new request is received, the last request time of the client is checked. If the interval from the last request time is less than the preset time limit, the request is considered too frequent, and a corresponding error response is returned to prompt the user to try again later; if the request time interval meets the requirements, the query request is allowed to continue, and the last request time record of the client is updated; The data request service module is used to establish a connection with the database that stores balance information and balance change records at the address data management layer; after the query request initiated by the external user is verified by the access control module and the request frequency control module, the data request service module obtains the required on-chain asset information from the database according to the preset query statement, processes and encapsulates the query results, and returns them to the external user.

7. The asset tracking and management system based on the non-account balance mode blockchain according to claim 6 is characterized in that: The access token uses JSON Web Token; The query results are processed and encapsulated into a data structure of JSON; The external users include: participants in relevant Bitcoin asset pledge agreements, Bitcoin asset locking and custody, cross-chain bridge asset anchoring supervision, and decentralized financial project market value statistics.

8. An asset tracking management method based on a non-account balance mode blockchain, implemented according to the asset tracking management system based on a non-account balance mode blockchain according to any one of claims 1-7, characterized in that: The following steps are involved: S1: Use the full node service program and blockchain index program to synchronize the latest block of non-account balance mode blockchain transactions to the local computer, and build a blockchain address index program interface to implement address transaction history indexing and balance query functions; S2: Taking the transaction start address as the entry point, analyze the UTXO input and output in the transaction directly or indirectly associated with the start address, exclude some output addresses according to specific filtering conditions, and use the queue mechanism and breadth-first algorithm to build a comprehensive address relationship network to sort out the flow of assets; S3: For the new address in the address relationship network, the root public key derived address cluster verification, the same public key conversion type address verification and the whitelist address verification are sequentially performed. If any of the verifications pass, the new address is considered legal. If none of them pass, the new address is determined to be an illegal address and the abnormal notification mechanism is triggered; the root public key derived address cluster verification calculates the derived child public key of the specified root public key according to the specified root public key and the key generation path, and determines whether the new address belongs to the address corresponding to these derived child public keys. If so, the verification passes, otherwise it fails; the same public key conversion type address verification generates different types of addresses according to the derived child public key according to the address generation method. The address generation method includes: generation rules, encryption algorithms, and encoding methods; Determine whether the new address belongs to these different types of addresses. If so, the verification passes, otherwise it fails; the whitelist address verification determines whether the new address belongs to an address in a preset whitelist. If so, the verification passes, otherwise it fails; S4: Through the blockchain address index program interface provided by S1, the full transaction history information is obtained regularly, and new transactions are filtered out based on timestamps. For new transactions, the hash table and tree structure are combined to count the legal address balances and save the change records in the database; S5: When receiving an external query request, first perform user authority verification and verify the validity of the user access token. If it is invalid, deny access. If it is valid, further check whether the request time interval meets the requirements. If it does, connect to the database described in S4 and obtain asset information according to the preset query statement. After processing and encapsulating it into the required format, return it to the external user to achieve interaction with the outside.

Images