A distributed-based pledge security management and control method and system

Abstract

The application provides a distributed-based collateral security management method and system, belonging to the technical field of data security management. The method comprises: threshold secret sharing fragmentation of asset disposal authorization data and storage to a distributed witness node network, and configuration of two-level nested time lock. Obtain the time sequence of the collateral from a plurality of preset data sources to determine the real-time state index value based on a preset volatility rate adaptive aggregation model, while injecting privacy noise when sending a query request to the data source. In the case of meeting the preset clearing condition, a clearing trigger voucher is generated to trigger the second level time lock, and a verifiable delay function is started to pass through a preset sequential calculation period; after the end of the preset sequential calculation period, the decryption fragments of the first preset node number and the preset behavior guarantee information are obtained, the clearing trigger voucher, the verifiable delay function output value and the decryption fragments are verified, and the threshold decryption is executed and the asset disposal authorization data is released after the verification passes.

Description

Technical Field

[0001] This application relates to the field of data security management technology, and in particular to a distributed collateral security management method and system. Background Technology

[0002] With the evolution of blockchain and distributed ledger technologies, pure software-based mortgage lending platforms have gradually become an important infrastructure for supply chain finance and digital asset financing. However, as commercial entities, pure software-based mortgage lending platforms cannot access ownership verification interfaces such as government real estate registration centers like traditional financial institutions, nor can they transfer risk control responsibilities to traditional banking institutions.

[0003] This means that the entire security management of collateralized assets must be completed without any centralized authority and under the constraint of purely automated software execution. However, under this constraint, existing distributed systems lack a unified trust anchor to coordinate the entire lifecycle of assets from registration, locking, monitoring to liquidation, resulting in multiple security contradictions that are coupled together and cannot be resolved simultaneously by a single technical means. For example, it is impossible to share the collateral status across platforms without disclosing the plaintext of assets; the same asset can be repeatedly collateralized on multiple platforms without being detected in a timely manner; the locking of asset ownership cannot rely on physical seizure; the purely software environment lacks verifiable temporal enforcement control measures; borrowers can dispose of assets privately during the loan period; and distributed escrow nodes are at risk of being bribed by borrowers to prematurely decrypt authorized data, leading to a loss of impartiality in the liquidation process.

[0004] Therefore, there is an urgent need for a closed-loop security management system that can simultaneously achieve double-collateral detection, mandatory ownership locking, conditional emergency access, and automatic liquidation against bribery, all without external authority reliance and under the constraint of purely automated software execution. Summary of the Invention

[0005] To address the aforementioned issues, this application provides a distributed collateral security management method and system, which enables fully closed-loop security management, including double-collateral detection, mandatory ownership locking, conditional emergency access, and automatic liquidation against bribery, all under the constraint of no external authority reliance and purely automated software execution.

[0006] On the one hand, embodiments of this application provide a distributed method for collateral security management, the method comprising: Based on the unique identifier of the collateral, perform duplicate collateral detection in a distributed witness node network; When the test result is passed, the asset disposal authorization data is segmented into threshold secret sharing data and stored in the distributed witness node network, and a two-level nested time lock is configured; wherein, the first-level time lock is bound to the expiration timestamp, and the second-level time lock is bound to the liquidation trigger certificate; The collateral time series is obtained from multiple preset data sources, and the real-time status index value corresponding to the collateral is determined based on a preset volatility adaptive aggregation model. At the same time, privacy noise is injected when sending query requests to the data sources. When the real-time status indicator meets the preset settlement conditions, the settlement trigger certificate is generated to trigger the second-level time lock, and the verifiable delay function is started after a preset sequential calculation period; After the preset sequential calculation cycle ends, the decryption fragments of the first preset number of nodes and the preset behavior guarantee information are obtained. The liquidation trigger certificate, the verifiable delay function output value and the decryption fragments are verified so that the threshold decryption is performed and the asset disposal authorization data is released after the verification is passed.

[0007] On the other hand, this application also provides a distributed collateral security management system, which includes: The execution module is used to perform duplicate collateral detection in a distributed witness node network based on the unique identifier of the collateral. The sharded storage module is used to perform threshold-based secret sharing sharding of asset disposal authorization data and store it in the distributed witness node network when the detection result is passed, and to configure a two-level nested time lock; wherein, the first-level time lock is bound to the expiration timestamp, and the second-level time lock is bound to the liquidation trigger certificate; The injection acquisition module is used to acquire collateral time series from multiple preset data sources, determine the real-time status indicator value corresponding to the collateral based on a preset volatility adaptive aggregation model, and inject privacy noise when sending query requests to the data sources. The generation and startup module is used to generate the liquidation trigger certificate to trigger the second-level time lock when the real-time status indicator meets the preset liquidation conditions, and to start the verifiable delay function after a preset sequential calculation period. The verification module is used to acquire the decryption fragments of the first preset number of nodes and the preset behavior guarantee information after the preset sequential calculation period ends, and to verify the liquidation trigger certificate, the verifiable delay function output value and the decryption fragments, so as to perform threshold decryption and release the asset disposal authorization data after the verification is passed.

[0008] Compared with the prior art, the significant advantages of this application are as follows: Double-collateral detection is performed through a distributed witness node network, which can identify double-collateralization without disclosing plaintext asset information, thus preventing multiple collateralizations of the same asset at the source. Threshold-based secret sharing is used to store asset disposal authorization data in fragments and configure two-level nested time locks. This mechanism prevents borrowers from unilaterally unlocking the asset during the loan period and also prevents the platform from arbitrarily disposing of it. In case of emergency liquidation, the asset can be released first through legal credentials, achieving verifiable forced locking without relying on physical seizure. Multi-source time-series data is processed based on a volatility adaptive aggregation model, which can effectively suppress the disturbance of short-term outliers to real-time status indicators. At the same time, differential privacy noise is injected during data querying to prevent data sources from inferring the platform's asset distribution and protect business privacy.

[0009] Furthermore, the introduction of a verifiable delay function forces a pre-defined sequential calculation cycle, preventing any node from preemptively clearing the liquidation process by increasing computing power. Combined with threshold decryption, behavioral guarantee information, and multi-factor verification (credentials, delayed output, decryption shards), the economic cost of nodes colluding to prematurely decrypt is extremely high, and their actions are traceable, ensuring the fairness and security of the liquidation process. The sequential steps of this application form a complete data loop, enabling a fully closed-loop security control method that eliminates the need for manual intervention. This method includes features such as double-collateral detection, mandatory ownership locking, conditional emergency channels, and automatic liquidation against bribery. Attached Figure Description

[0010] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings: Figure 1 This is a flowchart illustrating a distributed collateral security management method in an embodiment of this application. Figure 2 This is a schematic diagram of a distributed collateral security management system according to an embodiment of this application. Detailed Implementation

[0011] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0012] Existing distributed systems lack a unified trust anchor to coordinate the entire lifecycle of assets, from registration, locking, monitoring to liquidation. This leads to multiple coupled security contradictions that cannot be resolved simultaneously by a single technical means. For example, it is impossible to share collateral status across platforms without disclosing the plaintext of assets; the same asset can be repeatedly pledged on multiple platforms without timely detection. Locking up asset ownership cannot rely on physical seizure; pure software environments lack verifiable temporal enforcement mechanisms, allowing borrowers to dispose of assets privately during the loan period. Distributed escrow nodes are at risk of being bribed by borrowers to prematurely decrypt authorized data, resulting in a loss of impartiality in the liquidation process.

[0013] Based on this, this application provides a distributed collateral security management method and system to achieve a fully closed-loop security management system, including double collateral detection, mandatory ownership locking, conditional emergency access, and automatic liquidation against bribery, without external authority dependence and purely automated software execution.

[0014] The various embodiments of this application are described in detail below with reference to the accompanying drawings.

[0015] This application provides a distributed collateral security management method that can be executed by a distributed collateral security management system. The distributed collateral security management system includes: a coordination platform node, a distributed witness node network, a management terminal, multiple independent oracle nodes, a verifier terminal, and a preset liquidation execution node. The coordination platform node is responsible for scheduling the method flow, data collection, condition determination, certificate generation, and verification calculations. The distributed witness node network consists of N witness nodes, responsible for performing local equality checks in duplicate collateral detection, threshold signatures, threshold decryption sharding storage and provision, and lock state consensus synchronization; it can be deployed on a consortium blockchain or a permissioned blockchain. The management terminal is responsible for removing abnormal nodes, issuing manual confirmation instructions, and network governance. Multiple independent oracle nodes provide external collateral time-series sequences (sliding window time-series data, which can be understood as time-series data of collateral value or price changes). Verifier terminals (such as lenders' mobile phones, computers, etc.) are used for offline verification of collateral status. The preset liquidation execution node is used to receive reconstructed asset disposal authorization data and execute actual disposal. Figure 1 As shown, the method may include steps S101-S105: S101 performs duplicate collateral detection in a distributed witness node network based on the unique identifier of the collateral.

[0016] It should be noted that the embodiments of this application are executed by a coordination platform node, and its specific hardware device can be a server. That is, the server acts as the execution entity, and the server can maintain a distributed witness node network containing 15 witness nodes, i.e., N=15. Each witness node is operated by a different institution and can be independent of each other. The witness nodes can be interconnected through the network and maintain a consistent distributed ledger. The server as the execution entity of the distributed collateral security management method is only an example, and the execution entity is not limited to the server. This application does not make any specific limitation in this regard.

[0017] This application enables duplicate collateral detection through a distributed witness node network. Specifically, when a borrowing company initiates a collateral order, the server extracts the unique identifier of the corresponding collateral, such as the unified code of real estate or the serial number of machinery and equipment. Subsequently, based on this unique identifier, without disclosing the plaintext of the asset, cryptographic collision detection is used to determine whether the same asset (collateral) has already been registered on other platforms within the network. If the detection result shows that the asset has a duplicate collateral record, the current collateral application is rejected; if the detection passes, the process proceeds to S102.

[0018] In this embodiment of the application, double-collateral detection is performed in a distributed witness node network based on the unique identifier of the collateral, specifically including: The verifiable random function algorithm based on elliptic curves determines a verifiable random value based on a preset system private key, a unique identifier, and a random number from the current consensus round. This verifiable random value is then used in conjunction with a hash operation to determine the corresponding fingerprint data. The fingerprint data is divided into N detection sub-data units and distributed to each witness node. Each witness node then performs an equality check on its locally registered fingerprint database. Here, N is a natural number corresponding to the number of witness nodes. Each witness node performs a first signature operation on the equality check result using a threshold signature algorithm to obtain corresponding node confirmation data. A second signature operation is then performed on this node confirmation data to determine the aggregated confirmation data. The aggregated confirmation data is used to determine if the collateral is duplicated; if so, the corresponding collateral application is rejected.

[0019] In other words, the server performs fingerprint generation based on the Verifiable Random Function (VRF) algorithm using elliptic curves, then distributes fingerprint-corresponding detection sub-data and performs local equality checks, followed by threshold signature aggregation and duplicate staking detection. Specifically, the coordination platform node uses the system private key sk_sks, the unique identifier ID of the collateral, and the random number R of the current consensus round to calculate VRF(sk_sks, ID||R) = ( , ).in, To verify the random value, This provides the corresponding VRF proof. Subsequently, the coordination platform node can... Perform a cryptographic hash operation to obtain fingerprint data.

[0020] The random number for each consensus round is an unpredictable random seed generated by a pre-defined distributed consensus algorithm (such as Improved Practical Byzantine Fault Tolerance, HotStuff, or VRF-based BFT). Specifically, before determining verifiable random values: at the beginning of each consensus round, each witness node locally generates a random bit string. , Let represent the random bit string of the i-th witness node and calculate its cryptographic hash value. =H( ), Let H be the cryptographic hash value of the i-th witness node, where H is a preset cryptographic hash algorithm, such as SHA-1, SHA-256, etc., which is not specifically limited in this application. Subsequently, Broadcast to the distributed witness node network. During the consensus commit phase, each witness node reveals... Verified across the entire network and After achieving consistency, an XOR operation is performed on R= ⊕ ⊕...⊕ Alternatively, a globally random number R can be generated based on the aggregation operation of a verifiable random function. The coordination platform node reads the consensus-confirmed R value from the distributed ledger for this round and concatenates R with the unique identifier ID of the collateral (ID||R) as the input to the VRF. Since R changes in each round, even if the same collateral initiates detection at different times, the generated fingerprint data will be different, thus preventing attackers from bypassing collision detection that implements duplicate collateral detection by replaying old fingerprints or pre-compiling fingerprint tables.

[0021] The server further divides the aforementioned fingerprint data into N detection sub-data. The segmentation method can specifically employ bit-based segmentation, byte-based segmentation, or equal-length segmentation based on erasure coding. The specific method can be set based on the actual use case and is not specifically limited here. Then, the detection sub-data is distributed point-to-point to the corresponding witness node i. After receiving the detection sub-data, each witness node will call its local registered fingerprint database for data comparison, thereby achieving equality detection. This local registered fingerprint database records the fingerprint data and their detection sub-data mappings of all registered collateral or mortgaged assets within the network. Witness node i compares... If there is an equal match between the data at the corresponding shard position stored in the database and the data, the detection result is marked as suspected duplication; otherwise, it is marked as non-duplication.

[0022] Subsequently, each witness node will perform a first signature operation on its own equality check result. This first signature operation can be a partial signature operation performed by each witness node using its local private key on the equality check result using a threshold signature algorithm based on an elliptic curve bilinear mapping (Boneh-Lynn-Shacham, BLS) to generate node confirmation data. This partial signature operation can be an elliptic curve scalar multiplication such as... , This represents the node confirmation data generated by the i-th witness node. This represents the local private key of the i-th witness node. To map the equality check results to hash values ​​on an elliptic curve group, the server then collects node confirmation data from each witness node and performs a second signature operation. This second signature operation is a signature aggregation operation that combines multiple node confirmation data into a single aggregated confirmation data. This signature aggregation operation can be performed using point addition operations on the elliptic curve group to combine the various node confirmation data. conduct: Aggregate to obtain aggregated confirmation data. .in, The second preset number of nodes is a natural number greater than or equal to the number of pre-set nodes. This pre-set number is a threshold value set by the user based on the actual usage scenario. For example, if there are 15 witness nodes, the second preset number of nodes is set to 11. The corresponding first preset number of nodes is the lower limit of the required number of nodes for reconstructing the original secret. The second preset number of nodes can be equal to or different from the first preset number of nodes. The second preset number of nodes can be set based on the actual usage scenario and is not specifically limited here. The second signature operation can verify the legality of the aggregate signature using only the public key, without requiring the participation of the private keys of all nodes.

[0023] The server will also determine whether there is duplicate collateral based on the aggregated confirmation data. The specific judgment process is as follows: if the aggregated confirmation data shows that at least a second preset number of nodes report suspected duplicate collateral, then duplicate collateral is determined to exist; otherwise, the detection passes. This application can also set other specific judgment rules according to actual use scenarios, and no specific limitations are made therein.

[0024] By combining VRF fingerprinting, detection sub-data distribution, and threshold signature, cross-platform and verifiable duplicate collateral detection is achieved without disclosing the complete plaintext identifier of the collateral to any single node. This effectively protects the borrower's business privacy while maintaining the overall asset uniqueness of the network.

[0025] Furthermore, the above-mentioned determination of aggregated confirmation data in this application also includes: The system monitors the response status of each witness node. If no less than the number of aggregated confirmation data corresponding to the second preset number of nodes is received within the preset response time limit, the fingerprint data is re-determined based on the verifiable random function algorithm, and the detection sub-data distribution and signature operation are re-executed. If the preset number of retries is reached, the witness node that has not returned aggregated confirmation data is marked as an abnormal node, and an abnormal event information is sent to the management terminal to remove the abnormal node from the distributed witness node network.

[0026] In other words, during the server's aggregation signature execution process, the server also maintains the fault tolerance and attack resistance of the distributed witness node network. Specifically, after initiating the request for detection sub-data distribution and signature calculation, it continuously monitors the response status of each witness node. Using a pre-set response time limit (e.g., 30 seconds), it determines whether at least a second preset number of aggregation confirmation data nodes have been received within that time limit. This preset response time limit of 30 seconds is merely an example; the specific time limit can be set based on actual usage scenarios and is not specifically limited here. If, as determined above, at least a second preset number of aggregation confirmation data nodes have not been received within the response time limit, the server determines that the aggregation has failed and triggers a retry mechanism. During the retry, the server re-determines new fingerprint data based on the aforementioned verifiable random function algorithm. This can be specifically determined by changing the random number of the current consensus round, and the detection sub-data distribution and aggregation signature calculation are re-executed. If the number of retries reaches a preset number (e.g., 3 times), and a specific witness node fails to provide aggregation confirmation data during multiple retries, the server marks that witness node as an abnormal node. Possible causes of abnormal nodes include, but are not limited to, network partitioning, hardware failure, or Byzantine behavior. The server sends anomaly event information to the management terminal. This information may include the anomaly node identifier, the round record of the missing response, and a timestamp. After verification, the management terminal can broadcast a node removal command to the distributed witness node network, removing the anomaly node from the list of active nodes and updating the network topology and consensus group member information.

[0027] Furthermore, in one embodiment of this application, after removing the abnormal node from the distributed witness node network, the method further includes: Determine if the current number of remaining witness nodes is greater than or equal to the first preset number of nodes. If so, send a refresh command to each remaining witness node to obtain local random share data from each remaining witness node. The local random share data consists of random elements over a finite field shared by the threshold secret. Based on the local random share data, determine the corresponding refresh random parameters and send them to each remaining witness node, so that each remaining witness node can determine the new decryption fragment based on the refresh random parameters and its local old decryption fragment.

[0028] In other words, after removing an abnormal node from the distributed witness node network, the server first determines whether the number of remaining witness nodes is greater than or equal to the first preset number of nodes. If the number of remaining witness nodes is less than the first preset number of nodes, the server determines that the network no longer meets the threshold security conditions and triggers a security mode (such as suspending new order processing and notifying all lenders to verify their status). If the number of remaining witness nodes is greater than or equal to the first preset number of nodes, the server executes a sharding refresh process.

[0029] Specifically, the server can send refresh commands to each remaining witness node, and each remaining witness node can generate local random share data locally. The local random share data is a finite field of threshold secret sharing. The witness nodes can be randomly selected from the above random elements. Each witness node can... Send to the server, or broadcast. The server then... Determine the refresh random parameters. Specifically, the server can select the first t-1 random shares from the received local random share data. As a refresh polynomial Given the coefficients, construct the refresh polynomial:

[0030] in, , … From Selected from, The corresponding coefficient vector ( , , ..., This refers to the refresh random parameter. The server sends this refresh random parameter to each remaining witness node, and each remaining witness node uses its own node index i as the independent variable based on the refresh random parameter. The refresh polynomial is input, the corresponding operation result is calculated, and the result is modulo p to obtain the refresh increment. The specific value of the modulo p is based on expert experience and is not specifically limited here. Then, the remaining witness nodes sum the local old decrypted fragment with the refresh increment and take the modulo p: ,in For the newly decrypted fragment, For the remaining witness node i's local old decryption fragment, To refresh the increment, This indicates taking the modulus of p. Additionally... This ensures that while the original secret remains unchanged, the shards of the managed secret on each witness node are updated. Even if an attacker steals some of the old shards before a node is removed, they cannot combine them with the new shards to reconstruct the secret, thus achieving forward security.

[0031] Through the above technical solution, this application can dynamically update the decryption shards of each node after the removal of abnormal nodes by using a threshold share refresh mechanism. This ensures that the security of the distributed witness node network is not degraded due to the leakage of old shards when the members change dynamically, and maintains the confidentiality and integrity of the long-term custody of asset disposal authorization data.

[0032] S102, when the detection result is passed, the asset disposal authorization data is segmented into threshold secret sharing data and stored in the distributed witness node network, and a two-level nested time lock is configured.

[0033] The first-level time lock is bound to the expiration timestamp, and the second-level time lock is bound to the liquidation trigger certificate.

[0034] After the double-collateral detection is passed, the borrower can submit asset disposal authorization data to the server, specifically an asset disposal authorization letter with a digital signature. The server then uses a threshold secret sharing algorithm (such as the Shamir algorithm) to shard the asset disposal authorization data into n decrypted shards and store them separately on each witness node. Simultaneously, the server configures a two-level nested time lock. The first-level time lock is a slow lock, bound to the loan maturity timestamp, and its unlocking condition is that the current time reaches the maturity timestamp and at least a second preset number of witness nodes have received the maturity signature data. The second-level time lock is a fast lock, bound to the liquidation trigger certificate, and its unlocking condition is that the liquidation trigger certificate is successfully verified, and the activation of the second-level time lock overrides the unlocking condition of the first-level time lock. The lock state data of the two levels of time locks are written to the distributed ledger through a preset witness node consensus algorithm and state synchronization is performed. The liquidation trigger certificate can be understood as a digital signature data structure generated when the liquidation conditions are met, containing a trigger reason code, a trigger timestamp, a corresponding order identifier, a real-time status indicator value, and the system private key digital signature of the above fields. This credential serves as the sole legitimate activation token for the second-level time lock, and successful verification of its digital signature is a necessary condition for unlocking the fast lock. Simultaneously, the trigger timestamp within the credential serves as one of the input parameters to the Verifiable Delay Function (VDF), ensuring a one-to-one binding between the credential and the VDF's calculation cycle, preventing credential replay or VDF bypass attacks.

[0035] In this embodiment of the application, the above-mentioned configuration of a two-level nested time lock specifically includes: The unlocking condition for the first-level time lock is set to the current time reaching its expiration timestamp and receiving expired signature data from at least a second preset number of witness nodes. The unlocking condition for the second-level time lock is set to verification of the liquidation trigger credential. The second-level time lock's activation overrides the first-level time lock's unlocking condition. Based on the witness nodes' consensus algorithm, the lock state data of the first and second-level time locks are written to the distributed ledger, and state synchronization is performed.

[0036] Specifically, the server strictly sets the unlocking condition of the first-level time lock to a logical AND of two sub-conditions: (1) the current blockchain time or system consensus time reaches the aforementioned expiration timestamp; and (2) the server receives expiration signature data signed by at least a second preset number of witness nodes. This expiration signature data is generated by each witness node using its private key to perform a digital signature on the hash value of the order identifier, expiration timestamp, and lock status data. When both of the above sub-conditions are met simultaneously, the first-level time lock enters an unlockable state. During the regular loan period, if an immediate borrower attempts to bribe individual nodes, the asset disposal authorization data cannot be decrypted and released because the threshold condition of at least a second preset number of expiration signatures cannot be met.

[0037] For the second-level time lock, the server sets its unlocking condition to a single condition: verification of the liquidation trigger certificate, which is generated by the server. The second-level time lock is normally dormant and is only activated when the real-time status indicators meet the liquidation conditions. Once activated, even if the current time has not yet reached the expiration date of the first-level time lock, or the number of expired signatures for the first-level time lock is insufficient, the server prioritizes the unlocking path of the second-level time lock to release asset disposal authorization data for emergency liquidation. Simultaneously, based on the witness nodes and using a consensus algorithm, the server writes the lock state data (including lock type, binding timestamp, certificate hash, activation flag, and overwrite flag) of the first and second-level time locks into the blockchain distributed ledger and performs network-wide state synchronization processing to ensure that all witness nodes have a consistent understanding of the current lock state.

[0038] Through the above technical solution, this application nests slow lock and fast lock. In normal scenarios, the borrower's rights are protected by dual constraints of time and threshold signature to prevent early liquidation. In extreme market volatility scenarios, the lender's rights are protected by automatically triggered fast lock to prevent liquidation delays, thereby achieving the unification of mandatory locking and conditional emergency channels.

[0039] S103: Obtain the collateral time series from multiple preset data sources, determine the real-time status indicator value corresponding to the collateral based on a preset volatility adaptive aggregation model, and inject privacy noise when sending query requests to the data sources.

[0040] The server continuously acquires collateral time-series data from multiple independent oracle nodes. These independent oracle nodes can serve as part of the data source; however, the data source in this application is not limited to independent oracle nodes and can also include platforms such as the internet, without specific limitations. The collateral time-series data can specifically include time-series values ​​such as price indices and market quotes of the collateral. The server also uses a preset volatility adaptive aggregation model to dynamically adjust the length parameter of the sliding window based on the historical volatility standard deviation, performing a time-weighted average calculation on the sampled data within the window to obtain a filtered value as a real-time status indicator. Furthermore, when sending query requests to the data source, the server adds Laplace noise data to the query timestamp data and performs random replacement operations on the asset class identifiers according to preset probabilities to prevent the data source from inferring customer asset distribution through query patterns.

[0041] Among them, the asset category identifier is used to identify the asset type of the collateral, such as commercial real estate, industrial equipment, etc., and can be used as a metadata field in the query request.

[0042] In this embodiment of the application, the above-mentioned determination of the real-time status indicator value corresponding to the collateral based on the preset volatility adaptive aggregation model, and the injection of privacy noise when sending a query request to the data source, specifically includes: Acquire sliding window time-series data from multiple independent oracle nodes. Based on the historical volatility standard deviation of the sliding window time-series data, dynamically adjust the corresponding window length parameter to obtain the appropriate sliding window. Calculate the time-weighted average of the sampled data within the sliding window according to the data sampling time and local volatility to obtain the corresponding filtered value, which is then used as a real-time status indicator. When sending query requests to the data source, add Laplace noise to the query timestamp data and perform random replacement operations on the asset class identifier according to a preset probability.

[0043] The server retrieves sliding window time-series data of the collateral from multiple independent oracle nodes. This sliding window time-series data is extracted from the collateral time-series sequence according to a preset or initial sliding window. The preset or initial sliding window can be set during actual use and is not specifically limited here. The interval between each sampling time in the sliding window is equal. Each independent oracle node can report price data at preset intervals; this price data constitutes the collateral time-series data. Simultaneously, the server maintains a sliding window for each independent oracle node to store the most recent historical price sequence, i.e., the collateral time-series sequence. Subsequently, the server calculates the historical volatility standard deviation of the sliding window time-series data, specifically by performing logarithmic calculations on data from adjacent sampling times within the sliding window time-series data. , obtained the The sampled returns; among which, Indicates the first The sampled data is from the time series sequence of the collateral, i.e., the first sampled data. The server calculates the sum of the yields for each sampled collateral, and then compares this sum with... The ratio of the sample sizes is used to obtain the mean of the returns. Then, the standard deviation of historical volatility is calculated using the standard deviation calculation formula. , This represents the standard deviation of historical volatility; This indicates the total number of sampled data. It is a natural number; Indicates the first The rate of return at each sampling time; This represents the mean of the returns. The server dynamically adjusts the window length parameter based on the historical volatility standard deviation. ,in, The length of the sliding window after dynamically adjusting the window length parameter. For a preset or initial sliding window, This represents a pre-set adjustment coefficient, which can be set based on expert experience and is not specifically limited here. When When the threshold is lowered, the window length will be shortened to improve response sensitivity, while When volatility increases, the window length is extended to incorporate more historical data and smooth out extreme noise. This adaptive mechanism automatically strengthens the filtering in high-volatility scenarios, resisting attackers from manipulating single oracle quotes through short-term, high-volatility transactions.

[0044] Subsequently, the server will perform a time-weighted average calculation based on the data sampling time and local volatility. Local volatility refers to the instantaneous volatility of a few recent sampling points within a sliding window, such as the most recent 3 or 5 sampling points, used to reflect the short-term fluctuation characteristics of collateral prices. This local volatility differs from the standard deviation of historical volatility in that the calculation window for local volatility is shorter. Specifically, the server performs the time-weighted average calculation by assigning higher weights to sampling data whose sampling time is closer to the current time. The weighting function can be in the form of exponential decay, such as: , Indicates assigning the first Time-weighted average of each sampled data point. This represents the preset attenuation coefficient. It is negatively correlated with local volatility, such as , The preset negative correlation coefficient, Indicates local volatility; Indicates the current sampling time. Indicates the first The data sampling time for each sampled data point. The filter value is calculated using the following formula:

[0045] in, Indicates the filter value. Indicates the first One sampled data.

[0046] When sending query request data to the data source, the server adds Laplace noise to the query timestamp data. Specifically, the server generates data that follows a Laplace distribution. random noise , where scale parameter , The sensitivity of the query timestamp should be set based on the actual use case, for example, set to 1 second. The privacy budget parameters are preset based on expert experience and are not specifically limited here. The specific query timestamp sent by the server includes the aforementioned random noise. The timestamp will be displayed afterward. Additionally, the server will perform a random replacement operation on the asset class identifier according to a preset probability, replacing the actual asset class with another randomly selected asset class identifier with a preset probability.

[0047] By employing the aforementioned approach, this application combines timestamp noise with random category replacement, preventing data sources from inferring the platform's clients' true asset holdings and collateral size through analysis of query record time patterns and category distributions. Furthermore, by using volatility-adaptive filtering and local differential privacy noise injection, both manipulation resistance and query privacy protection are achieved.

[0048] S104, if the real-time status indicators meet the preset settlement conditions, generate a settlement trigger certificate to trigger the second-level time lock, and start the verifiable delay function to calculate the cycle in the preset order.

[0049] The server compares the real-time status indicator with a preset threshold. If the real-time status indicator exceeds the preset threshold, the server determines that the real-time status indicator meets the preset liquidation conditions. The server automatically generates a liquidation trigger certificate to trigger the second-level time lock and initiates a verifiable delay function (VDF) for a preset sequential calculation period. The calculation process of this VDF is sequential, non-parallelizable, and publicly verifiable, thereby ensuring an incompressible time delay between triggering liquidation and actual execution, preventing any party from preemptively operating through bribery or hardware acceleration. The preset sequential calculation period can be set by experts in actual use cases; this application does not specifically limit it.

[0050] S105, after the preset sequential calculation period ends, obtain the decryption fragments of the first preset number of nodes and the preset behavior guarantee information, verify the liquidation trigger certificate, the verifiable delayed function output value and the decryption fragments, so as to perform threshold decryption and release asset disposal authorization data after the verification is passed.

[0051] After the preset sequential calculation period ends, the server can collect decryption shards and preset behavior guarantee information from each witness node. The server verifies the validity of the digital signature of the liquidation trigger certificate, the validity of the output value of the delay function, and the consistency of the verification fingerprints of each decryption shard, and confirms whether the number of valid decryption shards has reached the first preset number of nodes.

[0052] In this embodiment, the above-mentioned acquisition of the first preset number of decryption shards and preset behavior guarantee information, verification of liquidation trigger certificates, verifiable delay function output values ​​and decryption shards, so as to perform threshold decryption and release asset disposal authorization data after verification, specifically includes: Obtain decryption shards and preset behavior guarantee information from each witness node. The preset behavior guarantee information includes node identity, on-chain token lock-up amount, and lock-up expiration time. Obtain shard verification fingerprint data from each witness node. The shard verification fingerprint data is determined by each witness node based on its node identity, verifiable delay function output value, and decryption shards. Calculate verification fingerprint data based on hash operations on the node identity, verifiable delay function output value, and decryption shards, and compare the shard verification fingerprint data with the original verification fingerprint data to obtain the first verification result. Perform digital signature verification on the liquidation trigger certificate based on the preset public key to obtain the second verification result. Perform verification on the verifiable delay function output value based on the preset verifiable delay function verification algorithm to obtain the third verification result. Finally, determine whether the number of valid decryption shards reaches the first preset number of nodes to obtain the fourth verification result. If there is no premature submission and all verification results are passed, reconstruct the asset disposal authorization data based on the preset Lagrange difference algorithm and send it to the preset liquidation execution node.

[0053] The aforementioned pre-defined behavioral guarantee information includes at least the node identity identifier, the amount of on-chain tokens locked, and the lock-up expiration time. Each witness node must lock at least a pre-defined amount of tokens in the smart contract as behavioral guarantee before participating in liquidation and decryption. If a node submits an incorrect shard or engages in malicious behavior such as premature submission, its locked tokens will be forfeited. The server verifies the validity of each node's behavioral guarantee information by querying the blockchain status. Witness nodes submit shard verification fingerprint data along with the decrypted shard. This shard verification fingerprint data is obtained by concatenating the witness node's node identity identifier, the verifiable delay function output value, and the decrypted shard, and then performing a hash operation. The server will calculate verification fingerprint data locally based on the same input parameters using hash operations and compare the shard verification fingerprint data calculated by the witness node with the original verification fingerprint data. If the comparison results of the shard verification fingerprint data of all active nodes are consistent, the first verification passes. If there are inconsistencies, it indicates that the shard submitted by the corresponding witness node may have been tampered with or the node identity may have been forged; in this case, the first verification result fails.

[0054] The server can also perform digital signature verification on the liquidation trigger credential based on its local preset public key, verifying whether the liquidation trigger credential was issued by a legitimate private key of the system and has not been tampered with, thus obtaining a second verification result. Simultaneously, the server also verifies the output value of the verifiable delay function based on a preset verifiable delay function verification algorithm, such as the Wesolowski verification algorithm, confirming that the output value of the verifiable delay function has undergone sequential computation for no less than a preset sequential computation period and has not been forged by parallel acceleration, thus obtaining a third verification result.

[0055] The server will also count the number of valid decrypted shards and determine whether the first preset number of nodes has been reached, thus obtaining the fourth verification result. Simultaneously, the server detects any premature submissions by comparing the blockchain timestamps of each node's submitted decrypted shards with the VDF calculation cycle end timestamp. If any witness node's submission time is earlier than the VDF cycle end time, premature submission is determined. In simple terms, premature submission refers to a witness node submitting a decrypted shard or shard verification fingerprint data to the server before the preset sequential calculation cycle of the verifiable delay function has ended.

[0056] If there is no premature submission as described above and all four verification results (first, second, third, and fourth) pass, the server will reconstruct the asset disposal authorization data over a finite domain based on a preset Lagrange interpolation algorithm. For example, the server uses t valid decryption fragments... ( This represents the Lagrange interpolation point corresponding to the witness node index. (This represents decryption of fragments), and calculation of the Lagrange fundamental polynomial: and reconstruct the secret ,in This is the original asset disposal authorization data. The server sends the reconstructed asset disposal authorization data to the preset liquidation execution node, which can then execute the asset disposal according to the authorization content, such as handling property transfer, auction, etc.

[0057] In one embodiment of this application, the method further includes: If the number of valid decrypted fragments is less than the first preset number of nodes, a suspension signal is generated and a manual confirmation instruction is awaited. If the deviation between the actual calculation time of the verifiable delay function and the preset time is greater than a preset threshold, the clearing trigger certificate is regenerated and the verifiable delay function is restarted.

[0058] During the collection and decryption of fragments, if the server determines that the number of valid decryption fragments is less than the first preset number of nodes, the server will immediately generate a suspension signal, stop the threshold decryption operation, and send an alarm message to the management terminal, awaiting manual confirmation. Upon receiving a multi-signature authorization or manual review instruction from the management terminal, the server can choose to extend the collection window or switch to a backup clearing process to avoid improper clearing due to automatic execution errors. Furthermore, the server monitors the deviation between the actual calculation time of the verifiable delay function and the preset time. If this deviation exceeds a preset threshold, the server determines that an anomaly exists. This may indicate that an attacker is using dedicated hardware to accelerate the calculation of the VDF to shorten the delay period, or that a computing environment malfunction has caused abnormal latency. In this case, the server initiates the current clearing trigger credential, regenerates a clearing trigger credential containing a new random challenge, and restarts the verifiable delay function to ensure that the incompressibility of the delay period is not compromised.

[0059] By utilizing the above technical solutions and VDF time deviation detection, a safety fallback mechanism can be provided for the automatic clearing process. This can prevent erroneous clearing caused by temporary node failures and also prevent the reduction of latency caused by hardware acceleration attacks.

[0060] In one embodiment of this application, lenders have a need for offline verification. To enable lenders to independently verify the collateral lock status without logging into the platform or trusting the platform's database, the following embodiments are provided, specifically including: The status data of all outstanding mortgage orders recorded in the distributed witness node network at the current moment are encoded into leaf node data, and a Merkle tree is constructed. The status data includes at least order identifier data, asset fingerprint data, lock status data, filtered numerical data, debt amount data, and collateral ratio data. Based on a hash-to-curve function, the root hash value of the Merkle tree is mapped to an elliptic curve group element. The elliptic curve group element is a curve point on a BLS curve. The result of each witness node performing a third signature operation on the elliptic curve group element using the BLS curve is used as the node signature data. Based on a preset group multiplication operation model, the node signature data is compressed to determine the aggregate signature data. Recursive proof information is determined based on the root hash value, the aggregate signature data, and the first M bytes of random anchor data in the aggregate signature data. The random anchor data is used to generate the random number seed for the preset recursive zero-knowledge proof system, where M is a positive integer. The recursive proof information and the corresponding Merkel authentication path data of the order are sent to the verification terminal so that the verification terminal can perform local verification calculations to determine the lock status of the corresponding order based on the recursive proof information and the corresponding Merkel authentication path data of the order.

[0061] In other words, the server encodes the status data of all outstanding mortgage orders recorded in the distributed witness node network at the current moment into leaf node data. Specifically, the status data can be serialized and hashed to generate leaf node values. Then, all leaf nodes are sorted according to preset rules (such as the dictionary order of order identifiers) to construct a Merkle tree, and the root hash value is calculated.

[0062] Subsequently, the server maps the root hash value to elliptic curve group (ECG) elements and sends them to the witness nodes. Each witness node also performs a third signature operation on the ECG elements using its BLS private key, specifically an ECG scalar multiplication, to generate node signature data. After collecting the signature data from each node, the server performs compression processing based on a preset ECG multiplication model, i.e., ECG dot-matrix addition, to obtain aggregate signature data, thus compressing multiple signatures into a single aggregate signature of constant size. Due to the aggregation characteristic of BLS signatures, the above aggregate signature data is equivalent to signing the ECG elements using the aggregated BLS private key. Verification requires only one bilinear pairing operation to verify the common endorsement of all witness nodes.

[0063] Subsequently, the server determines the recursive proof information based on the root hash value, the aggregate signature data, and the first M bytes of random anchor data in the aggregate signature data. Specifically, the M bytes of the aggregate signature data are used as the entropy source and input into the random number seed generator (such as the SHA-3-based extended function) of the preset recursive zero-knowledge proof system to generate a random number seed. The preset recursive zero-knowledge proof system can be a pre-set recursive proof system based on Halo2 or Nova. The server constructs circuit constraints and uses the root hash value and aggregate signature data as public inputs, the leaf node data and node signature data of the Merkle tree as private key witnesses, and the random anchor data as the random number seed to execute the proof generation algorithm of the preset recursive zero-knowledge proof system and output the recursive proof information. The circuit constraints are as follows: (1) The Merkle tree root hash value is equal to the root hash value of the public input; (2) The BLS aggregate signature is equal to the aggregate signature data of the public input; (3) The lock state data in each leaf node is validly locked.

[0064] During offline verification, the server can send recursive proof information and the Merkel authentication path data of the order (i.e., the hash values ​​of all sibling nodes on the path from the leaf node of the order to the root hash value) to the verifier terminal. The verifier terminal can recalculate the root hash value locally using the Merkel authentication path and compare it with the public input in the recursive proof information; secondly, it can verify the validity of the recursive proof information using the verification algorithm of the recursive zero-knowledge proof system; finally, it can verify the legality of the aggregate signature data. If all three verifications pass, the verifier terminal independently confirms that the lock state of the corresponding order is validly locked, without needing to establish a trust connection with the platform server or query the centralized database. This allows lenders to complete cryptographic verification in a completely offline environment, extending the trust boundary from the platform operator to the cryptographic protocol itself.

[0065] Through the above technical solutions, this application performs double-collateral detection through a distributed witness node network, which can determine double-collateralization without disclosing plaintext asset information, thus preventing multiple collateralizations of the same asset from the source. It employs threshold-based secret sharing to store asset disposal authorization data in shards and configures a two-level nested time lock. This mechanism prevents borrowers from unilaterally unlocking the asset during the loan period, and also prevents the platform from arbitrarily disposing of it. In case of emergency liquidation, it can be activated and released first through legal credentials, achieving verifiable forced locking without relying on physical seizure. Based on a volatility adaptive aggregation model to process multi-source time-series data, it can effectively suppress the disturbance of short-term outliers to real-time status indicators. Simultaneously, it injects differential privacy noise during data querying to prevent data sources from inferring the platform's asset distribution, thus protecting commercial privacy.

[0066] Furthermore, the introduction of a verifiable delay function forces a pre-defined sequential calculation cycle, preventing any node from preemptively clearing the liquidation process by increasing computing power. Combined with threshold decryption, behavioral guarantee information, and multi-factor verification (credentials, delayed output, decryption shards), the economic cost of nodes colluding to prematurely decrypt is extremely high, and their actions are traceable, ensuring the fairness and security of the liquidation process. The sequential steps of this application form a complete data loop, enabling a fully closed-loop security control method that eliminates the need for manual intervention. This method includes features such as double-collateral detection, mandatory ownership locking, conditional emergency channels, and automatic liquidation against bribery.

[0067] Figure 2 This is a schematic diagram of a distributed collateral security management system provided in an embodiment of this application. This system is capable of executing the aforementioned distributed collateral security management method. Figure 2 As shown, the distributed collateral security management system 200 includes: The execution module 201 performs duplicate collateral detection in a distributed witness node network based on the unique identifier of the collateral. The sharded storage module 202, upon successful detection, performs threshold-based secret sharing sharding of the asset disposal authorization data and stores it in the distributed witness node network, and configures a two-level nested time lock. The first-level time lock is bound to the expiration timestamp, and the second-level time lock is bound to the liquidation trigger certificate. The injection acquisition module 203 acquires collateral time-series sequences from multiple preset data sources, determines the real-time status indicator value corresponding to the collateral based on a preset volatility adaptive aggregation model, and injects privacy noise when sending query requests to the data sources. The generation and initiation module 204, when the real-time status indicator meets preset liquidation conditions, generates a liquidation trigger certificate to trigger the second-level time lock and initiates a verifiable delay function for a preset sequential calculation period. The verification module 205 is used to obtain the decryption fragments of the first preset number of nodes and the preset behavior guarantee information after the preset sequential calculation period ends, and to verify the liquidation trigger certificate, the verifiable delayed function output value and the decryption fragments, so as to perform threshold decryption and release asset disposal authorization data after the verification is passed.

[0068] Execution module 201 is specifically used for: The verifiable random function algorithm based on elliptic curves determines a verifiable random value based on a preset system private key, a unique identifier, and a random number from the current consensus round. This verifiable random value is then used in conjunction with a hash operation to determine the corresponding fingerprint data. The fingerprint data is divided into N detection sub-data units and distributed to each witness node. Each witness node then performs an equality check on its locally registered fingerprint database. Here, N is a natural number corresponding to the number of witness nodes. Each witness node performs a first signature operation on the equality check result using a threshold signature algorithm to obtain corresponding node confirmation data. A second signature operation is then performed on this node confirmation data to determine the aggregated confirmation data. The aggregated confirmation data is used to determine if the collateral is duplicated; if so, the corresponding collateral application is rejected.

[0069] Execution module 201 is also specifically used for: The system monitors the response status of each witness node. If no less than the number of aggregated confirmation data corresponding to the second preset number of nodes is received within the preset response time limit, the fingerprint data is re-determined based on the verifiable random function algorithm, and the detection sub-data distribution and signature operation are re-executed. If the preset number of retries is reached, the witness node that has not returned aggregated confirmation data is marked as an abnormal node, and an abnormal event information is sent to the management terminal to remove the abnormal node from the distributed witness node network.

[0070] When the fragmented storage module 202 is configured with a two-level nested time lock, it can specifically: The unlocking condition for the first-level time lock is set to the current time reaching its expiration timestamp and receiving expired signature data from at least a second preset number of witness nodes. The unlocking condition for the second-level time lock is set to verification of the liquidation trigger credential. The second-level time lock's activation overrides the first-level time lock's unlocking condition. Based on the witness nodes' consensus algorithm, the lock state data of the first and second-level time locks are written to the distributed ledger, and state synchronization is performed.

[0071] The injection acquisition module 203 is specifically used for: Acquire sliding window time-series data from multiple independent oracle nodes. Based on the historical volatility standard deviation of the sliding window time-series data, dynamically adjust the corresponding window length parameter to obtain the appropriate sliding window. Calculate the time-weighted average of the sampled data within the sliding window according to the data sampling time and local volatility to obtain the corresponding filtered value, which is then used as a real-time status indicator. When sending query requests to the data source, add Laplace noise to the query timestamp data and perform random replacement operations on the asset class identifier according to a preset probability.

[0072] The system can also: The status data of all outstanding mortgage orders recorded in the distributed witness node network at the current moment are encoded into leaf node data, and a Merkle tree is constructed. The status data includes at least order identifier data, asset fingerprint data, lock status data, filtered numerical data, debt amount data, and collateral ratio data. Based on a hash-to-curve function, the root hash value of the Merkle tree is mapped to an elliptic curve group element. The elliptic curve group element is a curve point on a BLS curve. The result of each witness node performing a third signature operation on the elliptic curve group element using the BLS curve is used as the node signature data. Based on a preset group multiplication operation model, the node signature data is compressed to determine the aggregate signature data. Recursive proof information is determined based on the root hash value, the aggregate signature data, and the first M bytes of random anchor data in the aggregate signature data. The random anchor data is used to generate the random number seed for the preset recursive zero-knowledge proof system, where M is a positive integer. The recursive proof information and the corresponding Merkel authentication path data of the order are sent to the verification terminal so that the verification terminal can perform local verification calculations to determine the lock status of the corresponding order based on the recursive proof information and the corresponding Merkel authentication path data of the order.

[0073] Specifically, the verification module 205 can: Obtain decryption shards and preset behavior guarantee information from each witness node. The preset behavior guarantee information includes node identity, on-chain token lock-up amount, and lock-up expiration time. Obtain shard verification fingerprint data from each witness node. The shard verification fingerprint data is determined by each witness node based on its node identity, verifiable delay function output value, and decryption shards. Calculate verification fingerprint data based on hash operations on the node identity, verifiable delay function output value, and decryption shards, and compare the shard verification fingerprint data with the original verification fingerprint data to obtain the first verification result. Perform digital signature verification on the liquidation trigger certificate based on the preset public key to obtain the second verification result. Perform verification on the verifiable delay function output value based on the preset verifiable delay function verification algorithm to obtain the third verification result. Finally, determine whether the number of valid decryption shards reaches the first preset number of nodes to obtain the fourth verification result. If there is no premature submission and all verification results are passed, reconstruct the asset disposal authorization data based on the preset Lagrange difference algorithm and send it to the preset liquidation execution node.

[0074] The system can also: If the number of valid decrypted fragments is less than the first preset number of nodes, a suspension signal is generated and a manual confirmation instruction is awaited. If the deviation between the actual calculation time of the verifiable delay function and the preset time is greater than a preset threshold, the clearing trigger certificate is regenerated and the verifiable delay function is restarted.

[0075] The system can also: Determine if the current number of remaining witness nodes is greater than or equal to the first preset number of nodes. If so, send a refresh command to each remaining witness node to obtain local random share data from each remaining witness node. The local random share data consists of random elements over a finite field shared by the threshold secret. Based on the local random share data, determine the corresponding refresh random parameters and send them to each remaining witness node, so that each remaining witness node can determine the new decryption fragment based on the refresh random parameters and its local old decryption fragment.

[0076] The various embodiments in this application are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the system embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0077] The systems and methods provided in this application are one-to-one correspondences. Therefore, the system also has similar beneficial technical effects as its corresponding method. Since the beneficial technical effects of the method have been described in detail above, the beneficial technical effects of the system will not be repeated here.

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

[0079] The above description is merely an embodiment of this application and is not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principle of this application should be included within the scope of the claims of this application.

Claims

1. A distributed collateral security management method, characterized in that, The method includes: Based on the unique identifier of the collateral, perform duplicate collateral detection in a distributed witness node network; When the test result is passed, the asset disposal authorization data is segmented into threshold secret sharing data and stored in the distributed witness node network, and a two-level nested time lock is configured; wherein, the first-level time lock is bound to the expiration timestamp, and the second-level time lock is bound to the liquidation trigger certificate; The collateral time series is obtained from multiple preset data sources, and the real-time status index value corresponding to the collateral is determined based on a preset volatility adaptive aggregation model. At the same time, privacy noise is injected when sending query requests to the data sources. When the real-time status indicator meets the preset settlement conditions, the settlement trigger certificate is generated to trigger the second-level time lock, and the verifiable delay function is started after a preset sequential calculation period; After the preset sequential calculation cycle ends, the decryption fragments of the first preset number of nodes and the preset behavior guarantee information are obtained. The liquidation trigger certificate, the verifiable delay function output value and the decryption fragments are verified so that the threshold decryption is performed and the asset disposal authorization data is released after the verification is passed.

2. The method for distributed collateral security management according to claim 1, characterized in that, The unique identifier of the collateral, used to perform duplicate collateral detection in the distributed witness node network, specifically includes: The verifiable random function algorithm based on elliptic curves determines a verifiable random value based on the preset system private key, the unique identifier, and the random number of the current consensus round, and determines the corresponding fingerprint data based on the verifiable random value and hash operation. The fingerprint data is divided into N detection sub-data and distributed to each witness node, so that each witness node can perform an equality test in its local registered fingerprint database; wherein, N is a natural number corresponding to the number of witness nodes; Based on the equality detection results of each witness node, a first signature operation is performed using a threshold signature algorithm to obtain the corresponding node confirmation data, and a second signature operation is performed based on the node confirmation data to determine the aggregated confirmation data; Based on the aggregated confirmation data, it is determined whether the collateral is subject to duplicate mortgage; if so, the mortgage application corresponding to the collateral is rejected.

3. The method for distributed collateral security management according to claim 2, characterized in that, When determining the aggregated confirmation data, the method further includes: Monitor the response status of each witness node. If no aggregated confirmation data corresponding to the number of second preset nodes is received within the preset response time limit, re-determine the fingerprint data based on the verifiable random function algorithm, and re-execute the detection sub-data distribution and signature operation. If the number of retries reaches a preset number, the witness node that fails to return the aggregated confirmation data is marked as an abnormal node, and an abnormal event information is sent to the management terminal to remove the abnormal node from the distributed witness node network.

4. The distributed collateral security management method according to claim 1, characterized in that, The configuration of the two-level nested time lock specifically includes: The unlocking condition for the first-level time lock is set to the current time reaching the expiration timestamp and receiving expiration signature data from witness nodes of no less than the number of second preset nodes; Set the unlocking condition for the second-level time lock to verify the liquidation trigger credential; Configure the second-level time lock to override the unlocking conditions of the first-level time lock after activation; Based on the witness node, the lock state data of the first-level time lock and the second-level time lock are written into the distributed ledger through a consensus algorithm, and state synchronization processing is performed.

5. The distributed collateral security management method according to claim 1, characterized in that, The step of determining the real-time status indicator value corresponding to the collateral based on a preset volatility adaptive aggregation model, and injecting privacy noise when sending a query request to the data source, specifically includes: Obtain sliding window time-series data from multiple independent oracle nodes; Based on the historical volatility standard deviation of the sliding window time series data, the corresponding window length parameter is dynamically adjusted to obtain the corresponding sliding window; Based on the data sampling time and local volatility, a time-weighted average is calculated on the sampled data within the sliding window to obtain the corresponding filtered value, and the filtered value is used as the real-time status indicator value. When sending query request data to the data source, Laplace noise data is added to the query timestamp data, and a random replacement operation is performed on the asset class identifier according to a preset probability.

6. The method for distributed collateral security management according to claim 1, characterized in that, The method further includes: The status data of all outstanding mortgage orders recorded in the distributed witness node network at the current moment are encoded into leaf node data, and a Merkle tree is constructed; wherein, the status data includes at least order identification data, asset fingerprint data, lock status data, filtered value data, debt amount data, and pledge ratio data; Based on the hash-to-curve function, the root hash value of the Merkle tree is mapped to an elliptic curve group element; wherein, the elliptic curve group element is a curve point on the BLS curve. The results of the third signature operation performed by each witness node on the elliptic curve group elements through the BLS curve are used as node signature data. Based on the preset group multiplication operation model, the node signature data is compressed to determine the aggregate signature data. Based on the root hash value, the aggregated signature data, and the first M bytes of random anchor data in the aggregated signature data, the recursive proof information is determined; the random anchor data is used to generate the random number seed for the preset recursive zero-knowledge proof system, and M is a positive integer; The recursive proof information and the corresponding Merkel authentication path data of the order are sent to the verification terminal so that the verification terminal can perform local verification calculations based on the recursive proof information and the corresponding Merkel authentication path data of the order to determine the lock status of the corresponding order.

7. The method for distributed collateral security management according to claim 1, characterized in that, The process of obtaining the decryption shards of the first preset number of nodes and the preset behavior guarantee information, verifying the liquidation trigger certificate, the verifiable delay function output value, and the decryption shards, and then performing threshold decryption and releasing the asset disposal authorization data after successful verification, specifically includes: Obtain the decrypted shards from each witness node and the preset behavior guarantee information; wherein, the preset behavior guarantee information includes node identity identifier, on-chain token lock-up amount and lock-up expiration time; Obtain fragmented verification fingerprint data from each of the witness nodes; wherein, the fragmented verification fingerprint data is determined by each of the witness nodes based on the node identity identifier, the verifiable delay function output value, and the decryption fragment; Based on the hash operation, the node identity identifier, the verifiable delay function output value, and the decryption fragment calculation, the verification fingerprint data is determined, and the fragment verification fingerprint data is compared with the verification fingerprint data to obtain the first verification result; The liquidation trigger credential is digitally signed and verified using a preset public key to obtain a second verification result. The output value of the verifiable delay function is verified based on a preset verifiable delay function verification algorithm to obtain a third verification result; and Determine whether the number of valid decrypted fragments has reached the first preset number of nodes to obtain the fourth verification result; If there is no pre-submission and all verification results are passed, the asset disposal authorization data is reconstructed based on the preset Lagrange difference algorithm and sent to the preset liquidation execution node.

8. The distributed collateral security management method according to claim 7, characterized in that, The method further includes: When the number of valid decryption fragments is less than the number of the first preset nodes, a suspension signal is generated and a manual confirmation instruction is awaited. If the deviation between the actual calculation time of the verifiable delay function and the preset time is greater than a preset threshold, the liquidation trigger certificate is regenerated and the verifiable delay function is restarted.

9. The distributed collateral security management method according to claim 3, characterized in that, After removing the abnormal node from the distributed witness node network, the method further includes: Determine whether the current number of remaining witness nodes is greater than or equal to the first preset number of nodes; If so, a refresh command is sent to each remaining witness node to obtain local random share data from each of the remaining witness nodes; wherein, the local random share data is a random element on the finite field of the threshold secret sharing; Based on the local random share data, the corresponding refresh random parameters are determined and sent to each of the remaining witness nodes, so that each of the remaining witness nodes can determine the new decryption fragment based on the refresh random parameters and the local old decryption fragment.

10. A distributed collateral security management system, characterized in that, The system is capable of executing a distributed collateral security management method as described in any one of claims 1-9; The system includes: The execution module is used to perform duplicate collateral detection in a distributed witness node network based on the unique identifier of the collateral. The sharded storage module is used to perform threshold-based secret sharing sharding of asset disposal authorization data and store it in the distributed witness node network when the detection result is passed, and to configure a two-level nested time lock; wherein, the first-level time lock is bound to the expiration timestamp, and the second-level time lock is bound to the liquidation trigger certificate; The injection acquisition module is used to acquire collateral time series from multiple preset data sources, determine the real-time status indicator value corresponding to the collateral based on a preset volatility adaptive aggregation model, and inject privacy noise when sending query requests to the data sources. The generation and startup module is used to generate the liquidation trigger certificate to trigger the second-level time lock when the real-time status indicator meets the preset liquidation conditions, and to start the verifiable delay function after a preset sequential calculation period. The verification module is used to obtain the decryption fragments of the first preset number of nodes and the preset behavior guarantee information after the preset sequential calculation period ends, and to verify the liquidation trigger certificate, the verifiable delay function output value and the decryption fragments, so as to perform threshold decryption and release the asset disposal authorization data after the verification is passed.

Images