A cross-merchant green point settlement method and system based on distributed rights certification

Abstract

The application discloses a cross-merchant green point settlement method and system based on distributed right confirmation, and belongs to the technical field of data processing. Specifically, based on the built-in hardware module of the system itself, a double-mode identity fingerprint is acquired, and confusion coding and parameter initialization processing are performed, and the processing result is chained and stored for evidence; by using a reverse solution challenge algorithm technology, double-end parameter transmission and checking are performed, and frozen points are used to ensure safety; merchant identifiers in the frozen record are parsed and compared with the current settlement merchant, and after confirmation by using a consensus mechanism, point transfer is completed and a settlement voucher is generated; a real-time exception monitoring module is deployed to monitor abnormal settlement behavior, a dynamic sandbox is constructed to trace attack sources, intrusion features are extracted to update a blacklist, and an audit log is generated. By introducing a bidirectional biological feature reverse solution engine and a dynamic point sandbox mechanism, the application solves the technical problems of identity verification in the cross-merchant point system, easy penetration and the fact that abnormal settlement cannot be traced.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and in particular to a cross-merchant green points settlement method and system based on distributed rights confirmation. Background Technology

[0002] Green consumption points are a core incentive credential that promotes the transformation of green consumption, connects consumers, and spans across merchants and operating platforms. Its form has gradually evolved from early offline green incentive tools to electronic green membership points. In recent years, the industry has relied on blockchain and distributed ledger technology to explore a digital green points system that can be redeemed across merchants, realizing full-process evidence storage and traceability of points, and enhancing data credibility.

[0003] However, most current blockchain-based green points systems are only at a superficial level of application, focusing on on-chain storage of points transactions. For cross-merchant green points settlement scenarios, core technical bottlenecks still exist. 1. Lack of a reliable identity mechanism, with no heterogeneous identity anchoring and dynamic verification, making it prone to identity forgery and fraudulent green behavior to obtain points; 2. One-way fixed verification logic, lacking reverse challenge and real-time status verification mechanisms across the entire chain; 3. Settlement and rights confirmation highly rely on centralized platforms, without establishing a merchant identity consistency verification mechanism, making it prone to security vulnerabilities such as token interception and fraudulent settlement; 4. Passive and lagging security protection, only able to simply intercept and reject abnormal transactions, lacking proactive trapping, dynamic isolation, and full-process traceability capabilities. Summary of the Invention

[0004] This application proposes a cross-merchant green points settlement method and system based on distributed rights confirmation. With a distributed network as the core, it solves the above-mentioned technical problems in points 1 to 4 by introducing a "two-way biometric reverse decoding" and "dynamic points sandbox" mechanism, as well as a multi-dimensional identity verification algorithm mechanism.

[0005] The specific solutions provided in this application are as follows: This invention discloses a cross-merchant green points settlement method based on distributed rights confirmation, comprising: S1, collecting user biometrics and device fingerprints, and merchant business certificates and geographic location data, respectively generating UBF through local HSM obfuscation encoding and binding to generate MSLC, and storing the root hash on the blockchain to obtain user-merchant dual identity identifiers; S2, based on the user-merchant dual identity identifiers, using a reverse challenge method to initiate a challenge from the merchant side, forcing the user side to generate dynamic biometric fingerprints in real time, performing bidirectional verification, freezing points and generating a frozen record with a merchant identifier after successful verification; S3, using a distributed consensus mechanism to parse the initiating merchant identifier in the frozen record and perform consistency comparison and verification with the current settlement merchant identifier, triggering cross-domain transfer of points after successful verification, and generating an immutable settlement voucher; S4, deploying an anomaly monitoring module, when abnormal settlement behavior is detected, triggering an early warning mode to construct a virtual sandbox to trap intruder information and trace the attack path, and simultaneously generating an intrusion feature blacklist to immunize against attacks.

[0006] Further, step S1 includes the following sub-steps: S101. Call the sensors of the terminal device to collect the raw biometric data stream and device fingerprint data. At the same time, obtain the business certificate and parse it into a certificate data digest. Simultaneously, generate accurate geofence polygon data by continuous sampling through the GPS module. S102. Extract feature points from the original biometric data stream to form a biometric vector F. Use the irreversible transformation method to concatenate the biometric vector F with the device fingerprint data to form a fuzzy UBF. Perform SHA-256 operation on the fuzzy UBF to obtain the biometric-device fingerprint root hash. S103. Serialize the certificate data digest and geofence polygon data, sign the serialized data using the merchant terminal's private key, generate the original certificate MSLC, package the original certificate MSLC with the signature, calculate the hash value, and obtain the certificate root hash.

[0007] Furthermore, step S1 also includes the following sub-steps: S104. Write the biometric-device fingerprint root hash and credential root hash together with the public key into the DID document and submit it to the distributed network for evidence storage. S105. Based on the DID document that has been stored on the blockchain, use verifiable credential encapsulation technology to generate a user-merchant dual identity identifier containing a DID string, public key and root hash.

[0008] Further, step S2 includes the following sub-steps: S201. The user end constructs a message structure that includes dual user-merchant identity identifiers and transaction intent, signs it, and sends it to the merchant end. The merchant end verifies the validity of the signature and confirms the user's identity through signature verification, thereby obtaining the verified transaction message and user identity. S202. Based on the transaction message and user identity, the merchant uses a cryptographic random number generator to construct a challenge message structure including a random number, merchant identifier and timestamp and sends it to the user. S203. The user terminal receives the challenge message structure, collects the unlocking private key of biometrics and device fingerprint based on the fuzz extractor in the local HSM, digitally signs the challenge random number to generate a dynamic signature fingerprint, encrypts the dynamic signature fingerprint using the merchant's public key, obtains an encrypted response message and returns it to the merchant terminal.

[0009] Furthermore, step S2 also includes the following sub-steps: S204. After receiving the encrypted response message, the merchant decrypts it using the private key, obtains the user's public key from the user's identity, and calls the Verify function to verify the authenticity of the public key. When the return result is TRUE, it proves that the user has the private key corresponding to the registered public key and the current biometric feature has been successfully unlocked. When the return result is FALSE, the transaction is rejected, the exception is recorded, and a two-way verification flag is output. S205. Based on the two-way verification pass flag, the merchant submits a freeze request to the distributed points ledger. After balance verification, the specified points are frozen and an immutable freeze record including the initiating merchant's identifier is generated and stored on the blockchain. A transaction authorization token is then output.

[0010] Furthermore, step S3 includes the following sub-steps: S301. Combine the transaction authorization token, the current merchant ID, and the timestamp to construct a request message structure. Based on the merchant's private key, use the ECDSA algorithm to sign the request message structure to obtain a settlement transaction request packet, and submit it to the distributed network. S302. The distributed network verifies the merchant signature of the settlement request, obtains and parses the transaction authorization token based on the settlement transaction request packet, queries the corresponding freeze record from the chain, performs hash consistency verification, and extracts the identity identifier of the freeze initiating merchant. S303. The identity identifier of the initiating merchant to be frozen is compared with the identity identifier of the current settlement merchant, and the comparison result is returned. When the result is TRUE, the points transfer procedure is prepared to be initiated through verification. When the result is FALSE, the settlement is rejected.

[0011] Furthermore, step S3 also includes the following sub-steps: S304. Initiate the points transfer procedure. Based on the distributed atomic consensus mechanism, update the user's frozen points status to "consumed", add the corresponding points balance to the merchant, and generate an immutable settlement record, which is then written to the distributed network. S305. Encapsulate the settlement process information, including settlement records, transaction hashes, block heights, and Merkle proof paths, into a structured certificate. Sign the hash of the certificate and attach it to the certificate to obtain an immutable settlement certificate. Return the certificate to the user through the event interface.

[0012] Further, step S4 includes the following sub-steps: S401 When the anomaly monitoring module detects an anomaly, it uses a predefined set of anomaly detection rules to match the settlement request in real time, and uses a risk assessment algorithm to assess the level of the anomaly and capture the anomaly data packet. S402. Using containerization technology and SDN traffic redirection methods, sandboxes are built and network isolated in real time for the source IP and attack traffic in abnormal event packets, generating a unique sandbox instance identifier. S403. Based on a unique sandbox instance identifier, a dynamic trap data injection method is used to simulate a successful settlement environment to induce attackers to expose attack payloads, capture the operational behavior of the system within the sandbox, generate behavior log records, and automatically extract intrusion indicators.

[0013] Furthermore, step S4 also includes the following sub-steps: S404. Utilize machine learning methods to perform behavioral analysis and threat intelligence correlation. Based on behavioral log records and intrusion indicator sets, identify attack tactics and reconstruct the attack step timeline to generate intrusion behavior profiles and attack path diagrams. S405. Utilizing feature generalization algorithms and rule generation technology, based on intrusion behavior profiles and attack path graphs, automatically extract generalizable intrusion indicators and generate detection rules, update the intrusion feature blacklist and broadcast it synchronously to immunize against attacks, and simultaneously generate security audit logs for on-chain evidence storage.

[0014] Furthermore, a cross-merchant green points settlement system based on distributed rights confirmation specifically includes the following modules: Module 1 is used to collect user biometric device fingerprints and merchant spatial behavior credentials and store them on the blockchain to generate user-merchant on-chain identity identifiers. The second module is used to initiate a two-way reverse challenge to verify identity based on the user-merchant on-chain identity identifier. After passing the challenge, the points are frozen and a freeze record containing the merchant identifier is generated. Module 3 is used to parse the merchant identifier in the frozen record and compare it with the current settlement merchant. After consensus confirmation, the points transfer is completed and a settlement voucher is generated. Module 4 is used to monitor abnormal settlement behavior, build a dynamic sandbox for tracing and capturing the source, extract intrusion features to update the blacklist and generate audit logs.

[0015] Compared with the prior art, the present invention achieves at least one of the following beneficial effects: 1. This invention utilizes HSM obfuscation encoding to generate dynamic UBF, binds merchant business certificates with geographical locations to generate MSLC and stores them on the blockchain respectively, constructs cryptographic anchors for physical entities and digital identities, and solves the problem that existing technologies are easily forged and misused due to the lack of identity trust mechanisms and the failure to achieve heterogeneous identity anchoring and dynamic verification.

[0016] 2. This invention utilizes the merchant's side to initiate a reverse challenge that includes random numbers, forcing the user's side to collect current biometric features in real time and generate a dynamic signature fingerprint for verification. This changes the traditional one-way verification mode and solves the problem that the existing technology has one-way verification logic and lacks reverse challenge and state verification.

[0017] 3. This invention utilizes a distributed network to parse the initiating merchant identifier in the frozen record and compares it on-chain with the merchant identifier currently requesting settlement. When the identities match, a distributed consensus is triggered to complete the cross-domain transfer of points. This solves the problem that existing technologies rely on a central settlement and confirmation mechanism, lack a merchant identity consistency verification mechanism, and are prone to token interception and fraudulent settlement security vulnerabilities.

[0018] 4. This invention deploys an anomaly monitoring module to construct a virtual isolation sandbox. By injecting simulated successful fake data, it induces attackers to expose themselves more deeply. Simultaneously, it captures system behavior operation logs and extracts intrusion characteristics to generate a blacklist for broadcasting. This solves the problems of passive and lagging security protection in existing technologies, where abnormal transactions are simply rejected without the ability to actively capture, dynamically isolate, and trace the source. Attached Figure Description

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

[0020] Figure 1 This is a flowchart illustrating a cross-merchant green points settlement method based on distributed rights confirmation according to the present invention. Figure 2 This is an architecture diagram of a cross-merchant green points settlement system based on distributed rights confirmation according to the present invention; Figure 3 This is a schematic diagram illustrating the construction process of a dynamic trapping sandbox example according to the present invention; Figure 4 This is a schematic diagram illustrating the process of tracing the attack source in this invention. Detailed Implementation

[0021] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0022] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.

[0023] It should also be understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0024] As used in this application specification and the appended claims, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection." Similarly, the phrase "if determined" or "if detected [the described condition or event]" may be interpreted, depending on the context, as meaning "once determined," "in response to determination," "once detected [the described condition or event]," or "in response to detection [the described condition or event]."

[0025] Furthermore, in the description of this application and the appended claims, the terms "first," "second," "third," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0026] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0027] The following is an example: See appendix Figure 1This invention discloses a cross-merchant green points settlement method based on distributed rights confirmation, comprising: S1, collecting user biometrics and device fingerprints, and merchant business certificates and geographical location data, respectively generating UBF through local HSM obfuscation encoding and binding to generate MSLC, and storing the root hash on the blockchain to obtain user-merchant dual identity identifiers; S2, based on the user-merchant dual identity identifiers, using the reverse challenge method to initiate a challenge from the merchant side, forcing the user side to generate dynamic biometric fingerprints in real time, performing bidirectional verification, freezing points and generating a frozen record with merchant identifier after the verification is passed; S3, using a distributed consensus mechanism to parse the initiating merchant identifier in the frozen record and perform consistency comparison and verification with the current settlement merchant identifier, triggering cross-domain transfer of points after the verification is passed, generating an immutable settlement voucher; S4, deploying an anomaly monitoring module, when an abnormal settlement behavior is detected, triggering an early warning mode to build a virtual sandbox to trap intruder information and trace the attack path, and generating an intrusion feature blacklist to immunize against attacks.

[0028] The core design concept of this application is to build a distributed trust network with "proactive immunity, two-way rights confirmation, and closed-loop traceability", which upgrades the traditional passive verification to dynamic game confrontation, and realizes the full life cycle trusted management of points assets when they are transferred across merchants. Its core design subverts the inherent paradigm of "static authentication, passive defense, and centralized rights confirmation" in the traditional points system.

[0029] The following are the key technical points of this invention: 1. Reconstruct identity verification into a two-way cryptographic handshake and proactively initiate a "reverse verification challenge" by forcing the user to generate a dynamic fingerprint based on the current biometrics and device status in real time; 2. Construct a dynamic sandbox trapping mechanism. When an abnormal settlement attempt is detected, instead of directly returning "failure", a virtual sandbox consistent with the real environment is created for the intruder, and the false information of "settlement success" is returned. This lays a virtual transparent channel for the intruder, inducing him to use attack methods. The system monitors behind the scenes, and all its operations such as invocation, network connection, and file operation are transformed into an intelligence gathering operation. 3. Automatically reconstruct attack paths, identify the attack tactics used by intruders, and extract intrusion indicators with generalization capabilities. The extracted "knowledge" will be instantly converted into YARA rules and broadcast to all nodes in the network through a distributed network. When the sandbox of one node successfully traps and analyzes an attack, the entire points system will gain immunity against such attacks in a short period of time.

[0030] In specific implementation, step S1 includes the following sub-steps: S101. Call the sensors of the terminal device to collect the raw biometric data stream and device fingerprint data. At the same time, obtain the business certificate and parse it into a certificate data digest. Simultaneously, generate accurate geofence polygon data by continuous sampling through the GPS module. S102. Extract feature points from the original biometric data stream to form a biometric vector F. Use the irreversible transformation method to concatenate the biometric vector F with the device fingerprint data to form a fuzzy UBF. Perform SHA-256 operation on the fuzzy UBF to obtain the biometric-device fingerprint root hash. S103. Serialize the certificate data digest and geofence polygon data, sign the serialized data using the merchant terminal's private key, generate the original certificate MSLC, package the original certificate MSLC with the signature, calculate the hash value, and obtain the certificate root hash.

[0031] The above step S102 includes the following specific implementation steps: Step 1) Convert the biometric vector F into a binary string using a quantization function, and then concatenate it with the device fingerprint data and a temporary random number in sequence to form the original concatenated string raw. Step 2) Based on Step 1), call the collision-resistant cryptographic hash function (i.e., SHA-256 operation) to perform a hash operation on the original concatenated string raw. The formula is: Hraw = SHA-256(raw), where Hraw represents the original obfuscated hash value; SHA-256 represents the collision-resistant cryptographic hash function; and raw represents the original concatenated string. Step 3) Based on the current system version number introduced in Step 2), call the collision-resistant cryptographic hash function to perform a hash operation on the current system version number and the original obfuscated hash value Hraw again to generate the UBF fingerprint. Then, perform a hash operation on the UBF fingerprint again to obtain the root hash value (i.e., the biometric-device fingerprint root hash) used for on-chain evidence storage.

[0032] The irreversible transformation method is a composite transformation method that includes multi-factor dynamic binding and hierarchical irreversible mapping. This method concatenates the biometric vector with the device fingerprint (only a combination of the original data levels). Its key feature is that the concatenated data needs to be input into the hardware security module (HSM) and concatenated again with the current system version number, dynamic random number and time factor generated by the HSM. It then undergoes three irreversible transformations in sequence: vector permutation (rearranging the binary string based on a preset random permutation table), piecewise linear convolution (dividing the permuted data into multiple segments, each segment being convolved with a helper vector derived from the HSM modulo 2), and final hash (SHA-256), outputting a root hash value of fixed length.

[0033] The above step S103 includes the following specific implementation steps: Step 1) Convert the certificate data digest to UTF-8 encoded standard JSON format, and use the SHA-256 function to calculate the fixed length of the certificate data digest to obtain a fixed-length certificate data digest; Step 2) Convert the latitude and longitude coordinates of the geofence polygon data to the WGS84 coordinate system and retain 6 decimal places (i.e., 0.11 meter precision) in a fixed format. Sort the polygon vertex sequence in counterclockwise order, convert it into a standardized text representation (GeoJSON format), and call the SHA-256 function to calculate its hash value to obtain the geofence summary. Step 3) Based on Step 1) and Step 2), define the serialized structure data using a compact binary serialization format (such as ASN.1DER encoding or a custom TLV format); Step 4) Based on Step 3), call the SHA-256 function to calculate the hash value of the serialized structure data, use the merchant's private key SKA to sign the hash value, obtain the signature value and verify to ensure that it has not been tampered with; Steps 5 and 4) package the serialized structure data and signature value into a complete Merchant Space Behavior Certificate (MSLC) data structure (in JSON format), call the SHA-256 function to calculate the hash value, and obtain the final certificate root hash.

[0034] In specific implementation, step S1 further includes the following sub-steps: S104. Write the biometric-device fingerprint root hash and credential root hash together with the public key into the DID document and submit it to the distributed network for evidence storage. S105. Based on the DID document that has been stored on the blockchain, use verifiable credential encapsulation technology to generate a user-merchant dual identity identifier containing a DID string, public key and root hash.

[0035] Step S105 above includes the following specific implementation steps: Step 1) Extract key information from the DID document to construct the credential body, including the DID string, public key, biometric-device fingerprint root hash, credential root hash, hash algorithm (such as SHA-256) and version number, creation time, update time and server endpoint; Step 2) Based on Step 1), construct the credential metadata, including context identifier, type and issuer, time status, and credential subject, and finally generate a credential data object (VC) to be verified (stored in JSON format). Step 3) Based on step 2), call the SHA-256 function to hash the credential data object VC to obtain the digest to be signed, use the issuer's private key to sign to obtain the signature value (using ECDSA to sign), and encapsulate it with the credential data object VC into a verifiable credential in JWT format; Step 4) Based on Step 3), verify the verifiable credential in JWT format, including: 1- Parsing the JWT to extract the issuer's DID and the subject's DID; 2- Obtaining the issuer's DID document from the blockchain using a DID parser and extracting the public key; 3- Using the public key to verify the JWT signature, ensuring that the testimony was issued by a trusted issuer and has not been tampered with; 4- Verifying the validity period and issuance time in the JWT; encrypting the JWT string and storing it in the HSM secure storage area of ​​the user / merchant terminal, and providing a standard interface for invocation.

[0036] In specific implementation, step S2 includes the following sub-steps: S201. The user end constructs a message structure that includes dual user-merchant identity identifiers and transaction intent, signs it, and sends it to the merchant end. The merchant end verifies the validity of the signature and confirms the user's identity through signature verification, thereby obtaining the verified transaction message and user identity. S202. Based on the transaction message and user identity, the merchant uses a cryptographic random number generator to construct a challenge message structure including a random number, merchant identifier and timestamp and sends it to the user. S203. The user terminal receives the challenge message structure, collects the unlocking private key of biometrics and device fingerprint based on the fuzz extractor in the local HSM, digitally signs the challenge random number to generate a dynamic signature fingerprint, encrypts the dynamic signature fingerprint using the merchant's public key, obtains an encrypted response message and returns it to the merchant terminal.

[0037] Step S202 above includes the following specific implementation steps: Step 1) The merchant uses the built-in True Random Number Generator (TRNG) of HSM to collect physical entropy sources (such as thermal noise and clock jitter) to obtain pseudo-random numbers mixed from the kernel entropy pool. It then uses a cryptographically secure pseudo-random number generator (CSPRNG) compliant with FIPS 140-2 to generate a 256-bit (32-byte) random number Nom and associates it with the current context (such as user identity and timestamp) and stores it in the local cache for use in verifying the user's response signature. Step 2) The merchant reads the verifiable credential in JWT format from the local HSM sealed storage area, parses the JWT payload, extracts the merchant's DID string and converts it to a UTF-8 string; Step 3) The merchant's end periodically synchronizes with the NTP server to ensure that the system time deviation is within an acceptable range (e.g., <1 second) to prevent verification failure due to time asynchrony. The system interface is called to obtain the current Unix timestamp and convert the timestamp into a fixed-length integer. Step 4) Based on steps 1) to 3), assemble the random number Nom, the merchant's DID string, and the Unix timestamp into a challenge message string using JSON format; Step 5) Based on step 4), the merchant sends the challenge message string (i.e., the challenge message structure) to the user through a secure communication channel (such as HTTPS). The user records the metadata of the current challenge locally, including: 1-challenge random number; 2-challenge timestamp; 3-target user identifier; 4-challenge status; the cache time is set to 30 seconds, and it will be automatically deleted after the timeout.

[0038] Step S203 above includes the following specific implementation steps: Step 1) Parse the challenge message string using JSON and extract all fields for three-dimensional verification, including: 1- Decode the challenge random number Nom using Base64URL to restore it to a 256-bit binary random number; 2- For Unix timestamps, calculate the current timestamp to check if the challenge is within its validity period; 3- Query the local cache to see if there are any historical interaction records with the merchant to verify the legality of the merchant's DID. Step 2) Based on Step 1), the fingerprint sensor or camera is used to collect the current biometric image. After preprocessing (denoising and normalization), the same feature extraction method as in Step S1 is used to generate a feature vector F1. The feature vector F1 is quantized and converted into a binary biometric string BF by a threshold (preset to 0.5). The hardware identifier of the current device (MAC address, IMEI and motherboard serial number) is obtained and assembled into a string according to the concatenation order at the time of registration. The hash is calculated using a function to obtain the device fingerprint hash value. The biometric string BF and the device fingerprint hash value are concatenated to form a combined feature w. Step 3) Based on Step 2), the combined feature w and the auxiliary data P (obtained during the user registration phase) are XORed to obtain the word c1 containing the error code. BHC decoding is then performed on this word to attempt to recover the original codeword c2. The SHA-256 function is used to calculate the hash value of the original codeword c2, yielding the secret value R1. If decoding is successful and the combined feature w is close to the feature at the time of registration, then the secret value R1 equals the secret value generated during registration. If decoding fails, the process is terminated and an error is recorded. Step 4) Based on step 3), use the secret value R1 as the AES-256 key and use the AES-256-GCM algorithm to decrypt the encrypted user private key stored in the HSM to obtain the user private key plaintext; if decryption fails, it indicates that the key is incorrect or the ciphertext has been tampered with, the process is terminated and the exception is recorded. Step 5) Based on step 4), call the SHA-256 function to calculate the hash value of the challenge random number Nom. Based on the elliptic curve digital signature algorithm, use the user's private key to sign the hash value and generate a signature pair (r, s), where r represents the x-coordinate of the random point and s represents the private key signature value. Concatenate r and s with a fixed length (32 bytes each) to obtain a 64-byte original signature, which is used as the dynamic signature fingerprint. Step 6) Using the DID parser on the blockchain, query the DID document corresponding to the merchant's DID string, select the first public key from it, convert it into an elliptic curve public key that can be used for encryption (as the merchant's public key) according to its format, and store the public key locally. Step 7) Based on Step 6), the ECIES integrated encryption scheme is used to execute the following steps: 1- The user generates a temporary elliptic curve key pair, and performs an elliptic curve dot product with the merchant's public key to obtain a shared secret point Sx; 2- The encryption key key1 (256 bits) and MAC key key2 (256 bits) are derived from the shared secret point Sx using HKDF-SHA256; 3- The dynamic signature fingerprint is encrypted using AES-256-CTR mode to generate ciphertext C; 4- The temporary public key, initialization vector, and ciphertext C in the temporary elliptic curve key pair are serialized according to a predetermined format (JSON) to obtain the encrypted signature packet. Step 8) Based on steps 1) to 7), combine the encrypted signature packet, user DID, and timestamp into a response object (i.e., an encrypted response message) and store it in JSON format.

[0039] In practice, step S2 further includes the following sub-steps: S204. After receiving the encrypted response message, the merchant decrypts it using the private key, obtains the user's public key from the user's identity, and calls the Verify function to verify the authenticity of the public key. When the return result is TRUE, it proves that the user has the private key corresponding to the registered public key and the current biometric feature has been successfully unlocked. When the return result is FALSE, the transaction is rejected, the exception is recorded, and a two-way verification flag is output. S205. Based on the two-way verification pass flag, the merchant submits a freeze request to the distributed points ledger. After balance verification, the specified points are frozen and an immutable freeze record including the initiating merchant's identifier is generated and stored on the blockchain. A transaction authorization token is then output.

[0040] The above step S205 includes the following specific implementation steps: Step 1) If the result returned in step S204 is TRUE, construct a request object for submitting to the distributed network. The request object fields include user DID string, merchant DID string, points value, timestamp, and unique request identifier generated by the merchant. Normalize the request object into a JSON string, sign the request string using the merchant's private key (using ECDSA), and package the request object and signature into a frozen transaction package. Step 2) Based on Step 1), call the freezePoints method of the points management smart contract pre-deployed on the blockchain, encode the frozen transaction package as a contract call parameter, construct a blockchain transaction, and broadcast the transaction to the distributed blockchain network, wait for consensus confirmation, and the network returns the transaction hash for subsequent query; Step 3) Based on Step 2), read the business data object and signature of the freeze request from the transaction hash. According to the merchant's DID string, obtain the corresponding DID document from the chain through the DID parser, extract the merchant's public key, calculate the hash value of the business data object of the freeze request (using SHA256), and verify the signature using the merchant's public key. If the verification fails, the transaction is rolled back, triggering an exception event and recording it. Step 4) Based on Step 3), the points management smart contract on the blockchain queries the user's points account according to the user's DID string (i.e., user identity identifier), obtains the current available balance (excluding frozen portion), ensures that the same transaction has not been frozen, and outputs a balance verification pass flag. Step 5) Based on Step 4), generate a unique identifier for the frozen record according to the request content, mark the points value portion of the user's total balance as frozen and retain the details of each frozen record, store the frozen record in the on-chain mapping, trigger the freeze event and record the block height of the current event. Step 6) Based on Step 5), once the blockchain consensus is completed, the transaction is permanently written into the on-chain state. The immutability of the frozen record is guaranteed by the blockchain's hash chain. Any node can verify the existence of the record through the block header and Merkle tree. The entire frozen record is hashed again for quick verification of the record's existence. Step 7) Based on steps 1) to 6), construct a transaction authorization token including the freeze record ID, user DID string, merchant DID string, points value, freeze timestamp, and transaction hash.

[0041] In specific implementation, step S3 includes the following sub-steps: S301. Combine the transaction authorization token, the current merchant ID, and the timestamp to construct a request message structure. Based on the merchant's private key, use the ECDSA algorithm to sign the request message structure to obtain a settlement transaction request packet, and submit it to the distributed network. S302. The distributed network verifies the merchant signature of the settlement request, obtains and parses the transaction authorization token based on the settlement transaction request packet, queries the corresponding freeze record from the chain, performs hash consistency verification, and extracts the identity identifier of the freeze initiating merchant. S303. The identity identifier of the initiating merchant to be frozen is compared with the identity identifier of the current settlement merchant, and the comparison result is returned. When the result is TRUE, the points transfer procedure is prepared to be initiated through verification. When the result is FALSE, the settlement is rejected.

[0042] In step S301 above, the request message structure is signed using the ECDSA algorithm based on the merchant's private key to obtain the settlement transaction request packet. The processing method is the same as step S205 in step S2, and is processed according to the general paradigm of hash calculation → signature generation → signature encoding.

[0043] The specific implementation steps of step S302 above include: Step 1) Read the frozen record ID from the transaction authorization token and use it as the key to read the message structure of the corresponding frozen record from the storage mapping. When the record is detected to be NULL, it indicates that the frozen record ID does not need to refuse settlement. Verify the status of the frozen record to ensure that the points have not been consumed or expired, and output the frozen record object on the chain. Step 2) Based on Step 1), the fields of the records on the chain are serialized into normalized byte strings (such as compact ABI encoding or custom TLV format) in a predetermined order. The serialized data is then hashed using the SHA-256 function to obtain the serialized hash value. Step 3) Based on Step 2), extract the hash of the transaction authorization token. If the transaction authorization token contains a hash digest of the frozen record, compare it with the serialized hash value. If the transaction authorization token does not contain a hash digest of the frozen record, compare it with the frozen record ID. If the hash matching is not satisfied, it indicates that the transaction authorization token does not match the on-chain information, and settlement is rejected. Otherwise, output the hash verification pass flag (boolean value TRUE or FALSE).

[0044] In practice, step S3 further includes the following sub-steps: S304. Initiate the points transfer procedure. Based on the distributed atomic consensus mechanism, update the user's frozen points status to "consumed", add the corresponding points balance to the merchant, and generate an immutable settlement record, which is then written to the distributed network. S305. Encapsulate the settlement process information, including settlement records, transaction hashes, block heights, and Merkle proof paths, into a structured certificate. Sign the hash of the certificate and attach it to the certificate to obtain an immutable settlement certificate. Return the certificate to the user through the event interface.

[0045] Step S304 above includes the following specific implementation steps: Step 1) Based on the settlementPoints (settlement points function) of the points management smart contract on the blockchain, call the parameters, including the frozen record ID, the DID of the current settlement merchant and the settlement timestamp, encode the called parameters into the contract ABI format, and construct the blockchain transaction parameter package; Step 2) Based on Step 1), parse the transaction parameter package, locate the settlementPoints, and verify whether the caller is consistent with the blockchain account corresponding to the merchant identity identifier (DID) currently applying for settlement. If they are consistent, settlement can be initiated (the purpose is to prevent malicious calls from third parties, which is achieved through the require method). Read the frozen record from the points management smart contract according to the frozen record ID to ensure that the record exists and the status is "frozen". Output the verified frozen record object. Step 3) Based on Step 2), extract the user identifier, the merchant identifier that initiated the freeze, and the number of frozen points from the frozen record object, and perform the following status update: 1- Deduct an equivalent number of points from the total balance of the user's points account, and at the same time reduce the frozen balance by the same amount; 2- Add the corresponding number of points to the points account of the current settlement merchant; 3- Update the status of the frozen record from "frozen" to "consumed" and record the settlement timestamp and settlement merchant identifier; If any of the three conditions is not met, the entire transaction rollback record is abnormal; Step 4) Based on steps 1) to 3), create a new on-chain record to permanently prove this settlement operation. To facilitate the generation of a unique ID for the settlement record, store the settlement record in the mapping of the points management smart contract and issue a settlement completion event for external listening and indexing. At the same time, construct a settlement certificate and return it to the user. This settlement certificate includes the transaction hash, the block height of the event, the settlement record ID, the Merkle proof of the settlement record, and the signature of the points management smart contract (stored in JSON format).

[0046] In specific implementation, step S4 includes the following sub-steps: S401 When the anomaly monitoring module detects an anomaly, it uses a predefined set of anomaly detection rules to match the settlement request in real time, and uses a risk assessment algorithm to assess the level of the anomaly and capture the anomaly data packet. S402. Using containerization technology and SDN traffic redirection methods, sandboxes are built and network isolated in real time for the source IP and attack traffic in abnormal event packets, generating a unique sandbox instance identifier. S403. Based on the unique sandbox instance identifier, use the dynamic trap data injection method to simulate a settlement success false environment for inducing the attacker to expose the attack payload, capture the operation behavior of the system in the sandbox, generate behavior log records, and automatically extract intrusion metrics.

[0047] The above uses a predefined set of anomaly detection rules to perform real-time matching on settlement requests, including: Step 1). The anomaly monitoring module extracts the feature vector for each settlement request and constructs the feature vector F2, including: f1 - whether the requester of the integral settlement is the same as the initiator of the integral freeze (boolean value, obtained from the settlement result in step 3); f2 - the result of the user signature verification (boolean value, known from the result of step 2); f3 - the timestamp of the current request; f4 - the timestamp of the user's most recent request; f5 - the geographical location of the source IP of the current request (queried through the IP geographical database); f6 - the geographical location of the source IP of the user's last request; f7 - the number of requests from the same source IP within the time window Δt; f8 - the number of failed requests from the same user within the time window Δt. Step 2). Based on step 1), define a set of anomaly detection rules, which includes a total of 5 rules, and each rule corresponds to an anomaly behavior pattern, specifically as follows: Rule 1. When f1 in the feature F2 is FALSE, the anomaly type "identity inconsistency" is triggered; Rule 2. When f2 in the feature F2 is FALSE, the anomaly type "verification failure anomaly" is triggered; Rule 3. When f3 - f4 < Tim (preset to 30 seconds) and f5 ≠ f6, the "time and space traversal anomaly" is triggered; Rule 4. When f7 > min (preset to 10 times), the "violent attempt anomaly" is triggered; Rule 5. Anomaly of high-frequency failures: When f8 > max (preset to 5 times), the "high-frequency failure anomaly" is triggered; When multiple rules are hit simultaneously, merge the list of anomaly types and take the highest severity as the main anomaly type, output the hit rule table.

[0048] The above uses a risk assessment algorithm to evaluate the level of anomaly events and capture anomaly event data packets, including: Step 1). For each hit rule, determine the basic risk score according to its predefined severity base number (Rule 1 = 80, Rule 2 = 70, Rule 3 = 60, Rule 4 = 50, and Rule 5 = 40). When no rule is hit, it is set to 0; Step 2). Considering the historical behavior of the same source IP (or the same user), calculate the frequency penalty factor. For the number of anomaly events from the same source IP within the most recent 1 hour, the frequency factor calculation formula is: I 频率= 1 + log(1 + ip), where I 频率 represents the frequency factor of the same source IP; log represents the logarithmic function; log(1 + ip) represents a linear transformation of 1 + the number of abnormal events (the purpose is to avoid the explosive growth of the risk score caused by a small number of abnormal events); ip represents the number of abnormal events of the same source IP address (used to amplify the risk score of the current abnormal event based on this IP); for the same user, for the number of abnormal events within the most recent 1 hour, the frequency factor calculation formula is: I 异常 = 1 + log(1 + user), where I 异常 represents the frequency factor of the same user IP; user represents the number of abnormal events of the same user account (used to amplify the risk score of any subsequent events of this user); take the larger value of I 频率 and I 异常 as the frequency adjustment factor; Step 3), based on Steps 1) to 2), take the product of the basic risk score and the frequency adjustment factor as the comprehensive risk score, and set the warning threshold Q = 60 and the record threshold M = 30. When the comprehensive risk score ≥ Q, trigger the warning process. When M ≤ comprehensive risk score < Q, only record the log. Finally, process the context and integrate all relevant information into a structured abnormal event data packet.

[0049] See Appendix Figure 2 , for the above Step S402, the specific implementation steps are as follows: Step 1), extract the attacker's source IP and related attack traffic characteristics from the abnormal event data packet, and use containerization technology (such as Docker) to dynamically create a virtual sandbox instance highly similar to the real production environment; Step 2), based on Step 1), call the software-defined network (SDN) controller, and dynamically issue flow table rules according to the source IP, and accurately redirect all subsequent network requests from this IP to the inside of the virtual sandbox instance. The real merchant system blocks the access of this IP through the access control list (ACL) to achieve transparent isolation and trapping of attack traffic; Step 3), based on Step 2), generate a unique sandbox identifier based on the source IP, abnormal occurrence time, and random number for each virtual sandbox instance, and associate and store it with the attack behavior to provide a traceable isolation environment anchor point for subsequent intrusion tracing and attack path analysis.

[0050] The above method of using dynamic trap data injection to simulate the settlement success false environment is as follows: Step 1) The system uses a points system simulator in the sandbox to listen to the attacker's requests in real time. Based on the parameters in the request, it dynamically generates a fake settlement response that conforms to the real business logic and returns a JSON data packet containing a forged transaction hash, settlement voucher ID and "settlement successful" status code, making the attacker mistakenly believe that the attack is effective. Step 2) Based on Step 1), the simulator continuously injects dynamically changing trap data to induce attackers to perform further malicious operations (such as attempting to steal data). Step 3) Based on Step 2), the sandbox adaptively adjusts the decoy content according to the attacker's behavior patterns, guiding the attacker to explore in depth, thereby capturing their complete attack tools, commands, control communication patterns and subsequent intentions, providing comprehensive evidence for intrusion tracing.

[0051] In practice, step S4 further includes the following sub-steps: S404. Utilize machine learning methods to perform behavioral analysis and threat intelligence correlation. Based on behavioral log records and intrusion indicator sets, identify attack tactics and reconstruct the attack step timeline to generate intrusion behavior profiles and attack path diagrams. S405. Utilizing feature generalization algorithms and rule generation technology, based on intrusion behavior profiles and attack path graphs, automatically extract generalizable intrusion indicators and generate detection rules, update the intrusion feature blacklist and broadcast it synchronously to immunize against attacks, and simultaneously generate security audit logs for on-chain evidence storage.

[0052] See appendix Figure 3 The specific implementation steps of step S404 above are as follows: Step 1) Based on behavior log records and intrusion indicators, use an integrated machine learning model (such as XGBoost) to identify behavior patterns. By extracting key operational data of the system during the attack process (such as call sequence, API call frequency, network connection mode) and comparing it with known attack behavior baselines, identify the tactics and procedures (TTPs) used by the attacker and classify the attack type. Step 2) Based on Step 1), using a multi-stage reasoning framework based on Large Language Model (LLM) (such as collaborative inference and verification), low-level log events are gradually abstracted into high-level attack semantics and automatically mapped to the tactical stages and technical items of the MITRE ATT&CK attack framework to form an attacker's tactical sequence. Step 3) Based on Step 2), an attack path reconstruction algorithm based on graph theory is used to construct an attack behavior graph with attack events as nodes and causal relationships as edges. A community detection algorithm (such as the Leiden algorithm) is used to mine the complete attack step chain from the graph. At the same time, the timeline of the attack behavior is reconstructed based on timestamps to generate a visualized attack path graph. Step 4) Based on Steps 1) to 3), the extracted IOCs (i.e., intrusion indicators, such as malicious IPs, domain names, and file hashes) are correlated with the global threat intelligence knowledge graph. Through graph-based clue traversal and similarity calculation (using the SSDeep code similarity comparison method), the attacker's organization, historical attack activities, and infrastructure associations are identified. By integrating behavioral patterns, tactical sequences, attack paths, and threat intelligence, a structured intrusion behavior profile is generated.

[0053] The specific implementation steps of step S405 above are as follows: Step 1) Extract all specific IOCs (Intrusion Indicators) from the attack path graph, including network layer IOCs, host layer IOCs, and behavior layer IOCs. Network layer IOCs include source IP, C2 domain name, TLSJA3 fingerprint, and URL path pattern; host layer IOCs include malicious file hash, registry path, mutex name, and process name; behavior layer IOCs include API call sequence patterns; finally, generalize each IOC based on the system call frequency. Step 2) Based on the generalized IOC obtained in Step 1), use automated rule generation technology to output detection rules in various formats, including YARA rules (for file feature matching, generating rule text), Sigma rules (for log feature matching), and Snort / Suricata rules (for network traffic feature matching), generate a rule set, and construct the generalized IOC into a list; Step 3) Based on Step 2), convert each IOC in the generalized IOC list into a blacklist entry and merge it with the current blacklist. Remove duplicates of IOCs of the same type and add a version number to the blacklist. Use the system private key (generated in HSM using the cryptographically secure random number generator CSPRNG) to sign the hash of the new version of the blacklist to obtain the updated global blacklist. Step 4) Based on Step 3), the updated global blacklist is submitted to the blockchain as a special transaction and written into the on-chain state. All nodes automatically obtain and return confirmation messages through the synchronization block to achieve immunity to attacks.

[0054] For specific implementation details, please refer to the appendix. Figure 4 A cross-merchant green points settlement system based on distributed rights confirmation specifically includes the following modules: Module 1 is used to collect user biometric device fingerprints and merchant spatial behavior credentials and store them on the blockchain to generate user-merchant on-chain identity identifiers. The second module is used to initiate a two-way reverse challenge to verify identity based on the user-merchant on-chain identity identifier. After passing the challenge, the points are frozen and a freeze record containing the merchant identifier is generated. Module 3 is used to parse the merchant identifier in the frozen record and compare it with the current settlement merchant. After consensus confirmation, the points transfer is completed and a settlement voucher is generated. Module 4 is used to monitor abnormal settlement behavior, build a dynamic sandbox for tracing and capturing the source, extract intrusion features to update the blacklist and generate audit logs.

[0055] Those skilled in the art will recognize that the algorithmic steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this application.

Claims

1. A cross-merchant green points settlement method based on distributed rights confirmation, characterized in that, include: S1. Collect user biometrics and device fingerprints, and merchant business certificate and geolocation data. Generate UBF and MSLC through local HSM obfuscation encoding and bind them respectively. Store the root hash on the blockchain to obtain user-merchant dual identity identifiers. S2. Based on the dual identity of user and merchant, the challenge is initiated from the merchant side using the reverse challenge method, which forces the user side to generate a dynamic biometric fingerprint in real time and perform two-way verification. After the verification is passed, the points are frozen and a frozen record with the merchant's identifier is generated. S3. Using a distributed consensus mechanism, the initiating merchant identifier in the freeze record is parsed and compared with the current settlement merchant identifier for consistency verification. After the verification is successful, the cross-domain transfer of points is triggered, and an immutable settlement voucher is generated. S4. Deploy an anomaly monitoring module. When an abnormal settlement behavior is detected, trigger the early warning mode to build a virtual sandbox to capture intruder information and trace the attack path. At the same time, generate an intrusion feature blacklist to immunize against attacks.

2. The cross-merchant green points settlement method based on distributed rights confirmation according to claim 1, characterized in that, Step S1 includes the following sub-steps: S101. Call the sensors of the terminal device to collect the raw biometric data stream and device fingerprint data. At the same time, obtain the business certificate and parse it into a certificate data digest. Simultaneously, generate accurate geofence polygon data by continuous sampling through the GPS module. S102. Extract feature points from the original biometric data stream to form a biometric vector F. Use the irreversible transformation method to concatenate the biometric vector F with the device fingerprint data to form a fuzzy UBF. Perform SHA-256 operation on the fuzzy UBF to obtain the biometric-device fingerprint root hash. S103. Serialize the certificate data digest and geofence polygon data, sign the serialized data using the merchant terminal's private key, generate the original certificate MSLC, package the original certificate MSLC with the signature, calculate the hash value, and obtain the certificate root hash.

3. The cross-merchant green points settlement method based on distributed rights confirmation according to claim 2, characterized in that, Step S1 also includes the following sub-steps: S104. Write the biometric-device fingerprint root hash and credential root hash together with the public key into the DID document and submit it to the distributed network for evidence storage. S105. Based on the DID document that has been stored on the blockchain, use verifiable credential encapsulation technology to generate a user-merchant dual identity identifier containing a DID string, public key and root hash.

4. The cross-merchant green points settlement method based on distributed rights confirmation according to claim 3, characterized in that, Step S2 includes the following sub-steps: S201. The user end constructs a message structure that includes dual user-merchant identity identifiers and transaction intent, signs it, and sends it to the merchant end. The merchant end verifies the validity of the signature and confirms the user's identity through signature verification, thereby obtaining the verified transaction message and user identity. S202. Based on the transaction message and user identity, the merchant uses a cryptographic random number generator to construct a challenge message structure including a random number, merchant identifier and timestamp and sends it to the user. S203. The user terminal receives the challenge message structure, collects the unlocking private key of biometrics and device fingerprint based on the fuzz extractor in the local HSM, digitally signs the challenge random number to generate a dynamic signature fingerprint, encrypts the dynamic signature fingerprint using the merchant's public key, obtains an encrypted response message and returns it to the merchant terminal.

5. A cross-merchant green points settlement method based on distributed rights confirmation according to claim 4, characterized in that, Step S2 also includes the following sub-steps: S204. After receiving the encrypted response message, the merchant decrypts it using the private key, obtains the user's public key from the user's identity, and calls the Verify function to verify the authenticity of the public key. When the return result is TRUE, it proves that the user has the private key corresponding to the registered public key and the current biometric feature has been successfully unlocked. When the return result is FALSE, the transaction is rejected, the exception is recorded, and a two-way verification flag is output. S205. Based on the two-way verification pass flag, the merchant submits a freeze request to the distributed points ledger. After balance verification, the specified points are frozen and an immutable freeze record including the initiating merchant's identifier is generated and stored on the blockchain. A transaction authorization token is then output.

6. A cross-merchant green points settlement method based on distributed rights confirmation according to claim 5, characterized in that, Step S3 includes the following sub-steps: S301. Combine the transaction authorization token, the current merchant ID, and the timestamp to construct a request message structure. Based on the merchant's private key, use the ECDSA algorithm to sign the request message structure to obtain a settlement transaction request packet, and submit it to the distributed network. S302. The distributed network verifies the merchant signature of the settlement request, obtains and parses the transaction authorization token based on the settlement transaction request packet, queries the corresponding freeze record from the chain, performs hash consistency verification, and extracts the identity identifier of the freeze initiating merchant. S303. The identity identifier of the initiating merchant to be frozen is compared with the identity identifier of the current settlement merchant, and the comparison result is returned. When the result is TRUE, the points transfer procedure is prepared to be initiated through verification. When the result is FALSE, the settlement is rejected.

7. A cross-merchant green points settlement method based on distributed rights confirmation according to claim 6, characterized in that, Step S3 also includes the following sub-steps: S304. Initiate the points transfer procedure. Based on the distributed atomic consensus mechanism, update the user's frozen points status to "consumed", add the corresponding points balance to the merchant, and generate an immutable settlement record, which is then written to the distributed network. S305. Encapsulate the settlement process information, including settlement records, transaction hashes, block heights, and Merkle proof paths, into a structured certificate. Sign the hash of the certificate and attach it to the certificate to obtain an immutable settlement certificate. Return the certificate to the user through the event interface.

8. A cross-merchant green points settlement method based on distributed rights confirmation according to claim 7, characterized in that, Step S4 includes the following sub-steps: S401 When the anomaly monitoring module detects an anomaly, it uses a predefined set of anomaly detection rules to match the settlement request in real time, and uses a risk assessment algorithm to assess the level of the anomaly and capture the anomaly data packet. S402. Using containerization technology and SDN traffic redirection methods, sandboxes are built and network isolated in real time for the source IP and attack traffic in abnormal event packets, generating a unique sandbox instance identifier. S403. Based on a unique sandbox instance identifier, a dynamic trap data injection method is used to simulate a successful settlement environment to induce attackers to expose attack payloads, capture the operational behavior of the system within the sandbox, generate behavior log records, and automatically extract intrusion indicators.

9. A cross-merchant green points settlement method based on distributed rights confirmation according to claim 8, characterized in that, Step S4 also includes the following sub-steps: S404. Utilize machine learning methods to perform behavioral analysis and threat intelligence correlation. Based on behavioral log records and intrusion indicator sets, identify attack tactics and reconstruct the attack step timeline to generate intrusion behavior profiles and attack path diagrams. S405. Utilizing feature generalization algorithms and rule generation technology, based on intrusion behavior profiles and attack path graphs, automatically extract generalizable intrusion indicators and generate detection rules, update the intrusion feature blacklist and broadcast it synchronously to immunize against attacks, and simultaneously generate security audit logs for on-chain evidence storage.

10. A cross-merchant green points settlement system based on distributed rights confirmation, characterized in that, Specifically, it includes the following modules: Module 1 is used to collect user biometric device fingerprints and merchant spatial behavior credentials and store them on the blockchain to generate user-merchant on-chain identity identifiers. The second module is used to initiate a two-way reverse challenge to verify identity based on the user-merchant on-chain identity identifier. After passing the challenge, the points are frozen and a freeze record containing the merchant identifier is generated. Module 3 is used to parse the merchant identifier in the frozen record and compare it with the current settlement merchant. After consensus confirmation, the points transfer is completed and a settlement voucher is generated. Module 4 is used to monitor abnormal settlement behavior, build a dynamic sandbox for tracing and capturing the source, extract intrusion features to update the blacklist and generate audit logs.

Images