Blockchain-based traceability and tamper-proof management of offline handover of property

Abstract

The application provides a blockchain-based traceability and tamper-proof management method and system for offline transfer of property, and relates to the technical field of blockchains, which comprises establishing an offline connection through near field communication, generating a signature key based on the equipment hardware characteristic value in the trusted execution environment, generating a tamper-proof transfer voucher and performing digital signature verification; after re-accessing the blockchain network, the dynamic priority is calculated according to the congestion index, the property value and the timeliness requirement, and the data is written into the blockchain network in batches. The application realizes the traceability and tamper-proof management of property transfer in an offline environment, and improves the data reliability and security.

Description

Technical Field

[0001] This invention relates to blockchain technology, and more particularly to a blockchain-based method and system for offline transfer, traceability, and tamper-proof management of assets. Background Technology

[0002] With economic and social development and the advancement of digital transformation, the importance of asset transfer management has become increasingly prominent. In recent years, blockchain technology, due to its decentralized, immutable, and traceable characteristics, has been widely applied in asset management, supply chain tracking, and other fields, providing new technological solutions for asset transfer management. In offline asset transfer scenarios, existing technologies typically use traditional electronic signatures or third-party intermediary services for transfer confirmation. However, in unstable network or offline environments, these methods cannot guarantee the security and reliability of the transfer process. Meanwhile, with the widespread adoption of mobile devices, Near Field Communication (NFC) technology provides a convenient way for secure connections between devices. Combined with blockchain technology, secure transfers can be achieved in offline environments.

[0003] Existing technologies lack effective anti-tampering mechanisms in offline environments, failing to ensure the integrity and authenticity of handover data. This can lead to information being maliciously modified during the handover process without being detected, increasing the security risks of asset transfers.

[0004] Existing technologies do not take into account the isolation of offline data transfer from other application data, lack special protection measures for the transferred data, and are susceptible to interference or attacks from other applications on the device, so data security cannot be effectively guaranteed.

[0005] Existing technologies typically employ a fixed priority strategy during the data upload process, failing to dynamically adjust the upload priority based on actual business needs. This can lead to delays in confirming important data transfers due to blockchain network congestion, failing to meet the timeliness requirements of different asset transfer scenarios and impacting transfer efficiency and user experience. Summary of the Invention

[0006] This invention provides a blockchain-based method and system for offline transfer, traceability, and tamper-proof management of assets, which can solve the problems in the prior art.

[0007] A first aspect of this invention provides a blockchain-based method for offline transfer traceability and tamper-proof management of assets, comprising: The system obtains the identity information of the transferor and the recipient of the assets, generates a smart contract in the blockchain network, establishes an offline connection between the transferor and the recipient of the assets through near-field communication (NFC), and sends a handover request containing the smart contract to the recipient of the assets. After receiving the handover request, the recipient of the property isolates the handover data from other application data in the trusted execution environment, generates a signature key based on the device hardware feature value and stores the signature key in the secure storage area of ​​the trusted execution environment, uses the signature key to generate an anti-tamper signature, and combines the anti-tamper signature with the handover data to form an anti-tamper handover certificate. The transferring party and the receiving party shall sequentially verify the tamper-proof handover certificate with digital signatures. After the transferor and recipient of the property reconnect to the blockchain network, the dynamic priority of data uploading is calculated based on the current congestion index of the blockchain network, the value of the property, and the timeliness requirements. The tamper-proof handover certificate and digital signature information are then written into the blockchain network in batches according to the dynamic priority. When it is necessary to trace the transfer records of property, the tamper-proof transfer certificate and digital signature information are obtained for verification, and a property transfer traceability report is generated.

[0008] In one alternative implementation, The steps of establishing an offline connection between the transferor and the recipient of the property via Near Field Communication (NFC), and the transferor sending a handover request containing the smart contract to the recipient, include: An NFC communication connection is established between the transferor and the recipient of the property. The transferor generates a first random number, the recipient generates a second random number, and a session key is generated based on the first and second random numbers. A smart contract data structure containing financial information is generated; the smart contract data structure is encrypted using the session key to obtain ciphertext data; and a message authentication code is generated based on the session key. The number of data fragments is determined based on the size of the smart contract data structure. The encrypted data is then fragmented and a message structure is generated using the NFC data exchange format. The message structure includes a fragment sequence number, record header information, and data payload. During transmission, each data fragment is checked using a CRC check. When a transmission error is detected, the current fragment sequence number is recorded and the data is retransmitted until the recipient of the property successfully receives all data fragments. The recipient of the funds uses the session key to verify the message authentication code, and after successful verification, decrypts the data to obtain the smart contract data structure.

[0009] In one alternative implementation, The steps of isolating handover data from other application data in a trusted execution environment, generating a signature key based on device hardware characteristics and storing the signature key in the secure storage area of ​​the trusted execution environment, generating an tamper-proof signature using the signature key, and combining the tamper-proof signature with the handover data to form an tamper-proof handover credential include: After receiving the handover request, the recipient of the property imports the handover data into a trusted execution environment through a security monitoring instruction. In the trusted execution environment, an independent virtual address space is allocated for the handover data and access control permissions are set to achieve isolation from other application data. The device hardware circuit response signal is acquired, and the response signal is XORed with the environmental noise signal to obtain the device hardware feature value. The bit flipping characteristic is obtained by sampling the device hardware feature value multiple times. An error correction code is constructed based on the bit flipping characteristic to locate and correct errors, and a stable feature value is obtained by repeatability testing. The stable feature value is concatenated with the device's unique identification information to obtain the signature key. An encryption key is generated in the trusted execution environment. The signature key is encrypted using the encryption key to obtain key ciphertext. The integrity check value of the key ciphertext is calculated. The key ciphertext and the integrity check value are written into the secure storage area of ​​the trusted execution environment. The hash value of the handover data is calculated based on the signature key and encrypted to generate an tamper-proof signature; the tamper-proof signature is combined with the handover data to form an tamper-proof handover certificate.

[0010] In one alternative implementation, The steps include obtaining bit-flipping characteristics by sampling the hardware feature values ​​of the device multiple times, constructing error-correcting codes based on the bit-flipping characteristics for error localization and correction, and obtaining stable feature values ​​through repeatability testing: The number of times each bit of the device hardware feature value is flipped in multiple samplings is counted, the flip probability of each bit is calculated based on the number of flips, and the unstable bits that need to be corrected are determined based on the flip probability. The error correction capability of the error correction code is determined based on the number of unstable bits. The minimum Hamming distance is calculated based on the error correction capability. Galois field parameters are selected based on the minimum Hamming distance to generate a parity check matrix. The device hardware feature values ​​are encoded using the check matrix to obtain check codewords, the check vector of the check codewords is calculated, and the error location polynomial is obtained based on the check vector. The error location in the device hardware feature value is determined according to the error location polynomial, an error pattern corresponding to the error location is generated, and the error pattern is XORed with the device hardware feature value to obtain the correction feature value. The correction feature value is subjected to multiple repeatability tests, and the stability index of the feature value is calculated based on the test results. When the stability index exceeds a preset threshold, the correction feature value is determined as a stable feature value.

[0011] In one alternative implementation, The steps for the transferor and the recipient of the property to sequentially verify the tamper-proof handover certificate with digital signatures include: The recipient of the property generates a first digital signature on the tamper-proof handover certificate, and combines the first digital signature with the tamper-proof handover certificate to form a first signature data packet; the transferor of the property verifies the first digital signature, and generates verification confirmation information upon successful verification. The transferring party generates a second digital signature for the tamper-proof handover certificate and the verification confirmation information, and combines the second digital signature with the tamper-proof handover certificate and the verification confirmation information to form a second signature data packet; the receiving party verifies the second digital signature; The transferor and the recipient of the property respectively store complete signature records containing the first signature data packet and the second signature data packet, and calculate the hash value of the complete signature record as an on-chain index identifier for writing the complete signature record into the blockchain network.

[0012] In one alternative implementation, After the transferor and recipient of the assets reconnect to the blockchain network, the step of calculating the dynamic priority of data uploading to the blockchain based on the current congestion index of the blockchain network, the value of the assets, and timeliness requirements includes: The ratio of the number of pending transactions to the transaction pool capacity in the blockchain network is used as the transaction pool depth. The block confirmation delay time is obtained, and the network congestion index is calculated based on the transaction pool depth and the block confirmation delay time. Obtain the market valuation of the asset corresponding to the data to be uploaded to the blockchain and the deadline for data upload to the blockchain. Calculate the asset value based on the market valuation and calculate the time sensitivity based on the deadline using an exponential decay function. The network congestion index, the value of the property, and the time sensitivity are normalized to obtain normalized parameters. Obtain the predicted priority and actual priority from historical transaction data to construct a mean squared error optimization objective function, solve the mean squared error optimization objective function to obtain dynamic weight coefficients that satisfy the constraint that the sum of the weights is one and that each weight is a non-negative number; The predicted data on-chain priority is calculated based on the normalization parameters and the dynamic weight coefficients; the actual data on-chain priority is obtained, and the difference between the predicted data on-chain priority and the actual data on-chain priority is calculated to obtain the prediction error; the gradient value of the dynamic weight coefficients is calculated based on the prediction error, and the dynamic weight coefficients are updated based on a preset learning rate for calculating the on-chain priority of subsequent data to be on-chain.

[0013] In one alternative implementation, The steps for constructing the mean squared error optimization objective function by obtaining the predicted priority and actual priority from historical transaction data include: The historical network congestion index is calculated by obtaining the transaction pool depth and block confirmation delay time corresponding to each transaction record in the historical transaction data; the temporal fluctuation variance of the historical network congestion index is calculated in each block generation cycle, and the abrupt change point of the temporal fluctuation variance is detected as the load partition boundary to divide the historical transaction data into multiple load partitions. The squared difference between the predicted priority and the actual priority in the historical transaction data of each load partition is calculated to obtain the transaction throughput in each load partition. The partition weighted mean square error is constructed based on the product of the squared difference and the transaction throughput. The number of times each load partition is converted to other load partitions in the historical transaction data is calculated. The number of conversions is divided by the number of times the corresponding load partition appears to obtain the partition conversion probability. Obtain the current network congestion index, determine the current load partition by comparing the fluctuation variance of the current network congestion index with the load partition boundary, and determine the load partition with the highest conversion probability to the current load partition as the target load partition based on the partition conversion probability. A mean squared error optimization objective function is constructed based on the partition weighted mean squared error of the current load partition and the partition weighted mean squared error of the target load partition.

[0014] A second aspect of this invention provides a blockchain-based offline asset transfer traceability and tamper-proof management system, comprising: The first unit is used to obtain the identity information of the transferor and the recipient of the property, generate a smart contract in the blockchain network, and establish an offline connection between the transferor and the recipient of the property through near field communication (NFC), and send a handover request containing the smart contract to the recipient of the property. The second unit is used to isolate the handover data from other application data in a trusted execution environment after the property recipient receives the handover request, generate a signature key based on the device hardware feature value and store the signature key in the secure storage area of ​​the trusted execution environment, generate an anti-tamper signature using the signature key, and combine the anti-tamper signature with the handover data to form an anti-tamper handover certificate. The third unit is used for the transferor and the recipient of the property to sequentially verify the tamper-proof handover certificate with digital signatures. The fourth unit is used to calculate the dynamic priority of data uploading to the blockchain network based on the current congestion index of the blockchain network, the value of the property, and the timeliness requirements after the transferor and recipient of the property reconnect to the blockchain network; and to write the tamper-proof handover certificate and digital signature information to the blockchain network in batches according to the dynamic priority. The fifth unit is used to obtain the tamper-proof handover certificate and digital signature information for verification when it is necessary to trace the property handover record, and generate a property handover traceability report.

[0015] A third aspect of the present invention provides an electronic device, comprising: processor; Memory used to store processor-executable instructions; The processor is configured to invoke instructions stored in the memory to execute the aforementioned method.

[0016] A fourth aspect of the present invention provides a computer-readable storage medium having stored thereon computer program instructions that, when executed by a processor, implement the aforementioned method.

[0017] This invention establishes an offline connection through Near Field Communication (NFC) technology and generates a signature key based on the device's hardware characteristics in a trusted execution environment. This achieves information security protection during the transfer of assets, ensuring the authenticity and integrity of data even in an offline environment and effectively preventing the tampering of asset transfer information.

[0018] This invention employs a trusted execution environment to isolate the handover data from other application data and uses a signature key to generate an tamper-proof signature, forming an tamper-proof handover certificate. This improves the security and reliability of the property handover process and ensures that the handover information is not illegally accessed or modified.

[0019] This invention calculates the dynamic priority of data upload to the blockchain based on the blockchain network congestion index, asset value, and timeliness requirements, enabling data to be written to the blockchain network in batches. This ensures the timely upload of important asset transfer information to the blockchain, optimizes the utilization efficiency of blockchain resources, and provides a reliable traceability mechanism for asset transfer through the immutable nature of the blockchain. Attached Figure Description

[0020] Figure 1 This is a flowchart illustrating the offline transfer traceability and tamper-proof management method for assets based on blockchain, as described in an embodiment of the present invention.

[0021] Figure 2 This is a flowchart of the device hardware feature value stability processing based on multiple sampling and error correction coding. Detailed Implementation

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

[0023] The technical solution of the present invention will be described in detail below with reference to specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments.

[0024] Figure 1 This is a flowchart illustrating the blockchain-based offline transfer traceability and tamper-proof management method for assets, as described in an embodiment of the present invention. Figure 1 As shown, the method includes: The system obtains the identity information of the transferor and the recipient of the assets, generates a smart contract in the blockchain network, establishes an offline connection between the transferor and the recipient of the assets through near-field communication (NFC), and sends a handover request containing the smart contract to the recipient of the assets. After receiving the handover request, the recipient of the property isolates the handover data from other application data in the trusted execution environment, generates a signature key based on the device hardware feature value and stores the signature key in the secure storage area of ​​the trusted execution environment, uses the signature key to generate an anti-tamper signature, and combines the anti-tamper signature with the handover data to form an anti-tamper handover certificate. The transferring party and the receiving party shall sequentially verify the tamper-proof handover certificate with digital signatures. After the transferor and recipient of the property reconnect to the blockchain network, the dynamic priority of data uploading is calculated based on the current congestion index of the blockchain network, the value of the property, and the timeliness requirements. The tamper-proof handover certificate and digital signature information are then written into the blockchain network in batches according to the dynamic priority. When it is necessary to trace the transfer records of property, the tamper-proof transfer certificate and digital signature information are obtained for verification, and a property transfer traceability report is generated.

[0025] For example, the identity information of the transferor and recipient of the assets is obtained, including identification codes, digital certificates, and verification information. For instance, the transferor's identification code is "TR-ID-98765," and the digital certificate serial number is "TR-CERT-87654321"; the recipient's identification code is "RC-ID-12345," and the digital certificate serial number is "RC-CERT-12345678." The authenticity and validity of both parties' identity information are verified, including verifying whether the digital certificates were issued by a trusted certificate authority and are valid. After successful verification, a smart contract is generated in the blockchain network. This smart contract contains basic information about the asset transfer, execution conditions, and liability agreements. The smart contract's data structure includes the contract ID "CONTRACT-20240805-12345", the asset description "high-precision optical components", the handover conditions "intact and functional", the handover time range "2024-08-05 10:00 to 2024-08-05 18:00", the identity information of both parties, and default clauses. The smart contract is generated after verification by the blockchain network, and its creation time and initial state are recorded on the chain.

[0026] When the transferor and transferee of property conduct a physical transfer in an offline environment, a secure connection is established between their devices via Near Field Communication (NFC). Both parties bring their NFC-enabled devices close together, automatically initiating the NFC connection protocol on a 13.56MHz frequency. After establishing an initial connection, an NFC handshake verification is performed to confirm the NFC compatibility of both devices, and then a secure data transmission mode is switched. Once the connection is established, the transferor's device sends a transfer request containing a smart contract to the transferee's device. This transfer request includes the complete content of the aforementioned smart contract, the current transfer timestamp "2024-08-05 14:30:25", and geolocation information. The secure transmission mechanism of NFC ensures that the data is not intercepted or tampered with by any third party during transmission.

[0027] Upon receiving the handover request, the receiving party first verifies its integrity and authenticity. The receiving device then initiates a Trusted Execution Environment (TEE), such as ARM TrustZone or Intel SGX, creating a secure execution space isolated from normal operations. Security monitoring commands from the TEE are invoked to import the handover data from ordinary memory space into a dedicated secure area within the TEE. Within the TEE, a separate virtual address space is allocated for the handover data, and strict access control permissions are set to ensure that only authorized security applications can access the data, achieving complete isolation from other application data. The TEE protects the handover data from theft or modification by malicious software through hardware-level isolation mechanisms.

[0028] Device hardware characteristics are used as the basis for key generation. Unique hardware response characteristic values ​​are obtained by measuring the physical characteristics of the device's SRAM, PUF circuitry, or other hardware components. These characteristic values ​​are processed, and bit-flipping characteristics are analyzed through multiple samplings. Error-correcting coding techniques are applied to improve the stability of the characteristics. Stable hardware characteristic values ​​are then cryptographically processed to generate a device-unique signing key. This signing key is strongly bound to specific hardware and cannot be copied from one device to another. The signing key is encrypted and stored in a secure storage area within a trusted execution environment, ensuring that the key cannot be accessed by unauthorized applications or malware.

[0029] Based on the signature key stored in the secure area, a tamper-proof signature is generated for the handover data. The specific process involves first calculating the SHA-256 hash value of the handover data, then using the signature key to perform HMAC-SHA256 encryption on this hash value, generating a 64-byte tamper-proof signature "47DEA8C5B6F39A21D0E5C7F4A83B6D9CE721F5A03D8E4B19C7A0B8D6E5F4C3A2". This tamper-proof signature is combined with the original handover data to form a tamper-proof handover credential. The credential structure includes the original handover data, the tamper-proof signature value, the signature generation time, and device identification information. This hardware-based signature mechanism ensures the uniqueness and unforgeability of the credential.

[0030] The transferring and receiving parties sequentially verify the tamper-proof handover certificate using digital signatures. First, the receiving party uses their private key to generate a first digital signature on the tamper-proof handover certificate, combining the signature and the certificate into a first signature data packet. Upon receiving this packet, the transferring party uses the receiving party's public key to verify the signature's validity; if successful, a verification confirmation message is generated. Subsequently, the transferring party uses their private key to generate a second digital signature on the tamper-proof handover certificate and the verification confirmation message, combining the signature, certificate, and confirmation message into a second signature data packet. Upon receiving this packet, the receiving party uses the transferring party's public key to verify the validity of the second digital signature. After both parties complete the signature verification, they each store the complete signature record and calculate the record's hash value as an on-chain index. This two-way signature mechanism ensures the non-repudiation of the handover process; neither party can deny their participation in the handover.

[0031] Once the transferring and receiving parties reconnect to the blockchain network, they need to upload the offline-generated handover certificate data to the blockchain. To efficiently utilize blockchain resources, a dynamic priority for data upload is calculated based on the current network conditions and the characteristics of the handover data. The transaction pool depth and block confirmation delay of the blockchain network are obtained to calculate the network congestion index; the market valuation of the assets and the upload deadline are obtained to calculate the asset value and time sensitivity; these parameters are normalized and combined with dynamic weighting coefficients to calculate the final upload priority. Historical transaction data is used to train and optimize the model, continuously adjusting the weighting coefficients to improve the accuracy of priority prediction. Based on the calculated priority, tamper-proof handover certificates and digital signature information are written to the blockchain network in batches. High-priority core data is uploaded first to ensure timely recording of key information; low-priority auxiliary data is uploaded later to optimize network resource utilization.

[0032] When it is necessary to trace the transfer of assets, comprehensive verification and traceability functions are provided. The traceability process first retrieves the tamper-proof transfer certificate and digital signature information stored on the blockchain network. The existence and integrity of the data on the blockchain are verified, checking the block timestamp and transaction hash. Subsequently, the tamper-proof transfer certificate is verified, including verifying the validity of the tamper-proof signature to confirm that the certificate content has not been tampered with; and verifying the digital signatures of the transferring and receiving parties to confirm that both parties are authentic and have confirmed the transfer content. Based on the verification results, a transfer traceability report is generated, containing key information such as the transfer timeline, participant information, asset details, transfer status, and verification results. The traceability report can serve as legal evidence for the transfer of ownership of assets and provides reliable evidence in dispute resolution.

[0033] This invention enables end-to-end management of asset transfers based on blockchain and hardware security, effectively solving trust issues and evidence retention challenges in traditional asset transfers. It achieves secure offline interaction through near-field communication, utilizes a trusted execution environment and hardware features to protect data security, ensures non-repudiation of the transfer process through a dual-party digital signature mechanism, and improves blockchain resource utilization efficiency through a dynamic priority on-chain strategy. It provides a complete traceability and verification mechanism, offering reliable electronic evidence for asset transfers, significantly reducing the risk of disputes, and is applicable to various scenarios such as the transfer of valuables, logistics delivery, and asset transfer.

[0034] In one optional implementation, establishing an offline connection between the transferor and the recipient of the property via Near Field Communication (NFC), and having the transferor send a handover request containing the smart contract to the recipient, includes the following steps: An NFC communication connection is established between the transferor and the recipient of the property. The transferor generates a first random number, the recipient generates a second random number, and a session key is generated based on the first and second random numbers. A smart contract data structure containing financial information is generated; the smart contract data structure is encrypted using the session key to obtain ciphertext data; and a message authentication code is generated based on the session key. The number of data fragments is determined based on the size of the smart contract data structure. The encrypted data is then fragmented and a message structure is generated using the NFC data exchange format. The message structure includes a fragment sequence number, record header information, and data payload. During transmission, each data fragment is checked using a CRC check. When a transmission error is detected, the current fragment sequence number is recorded and the data is retransmitted until the recipient of the property successfully receives all data fragments. The recipient of the funds uses the session key to verify the message authentication code, and after successful verification, decrypts the data to obtain the smart contract data structure.

[0035] For example, the party transferring the property carries a mobile device A with NFC functionality, and the party receiving the property carries a mobile device B with NFC functionality. When the transfer of property is required, the transferring party brings device A close to the receiving party's device B, establishing an NFC communication connection between the two devices. The two devices perform an initial handshake via the NFC protocol to verify each other's NFC capabilities and compatibility. At this time, the transferring party's device A automatically generates a 128-bit first random number, such as "A7B2C8D9E5F1G3H4I6J7K8L9M0N2P3"; simultaneously, the receiving party's device B generates a 128-bit second random number, such as "Q1R5S6T7U8V9W0X2Y3Z4A1B2C3D4E5". The two devices exchange these random numbers. Device A and Device B each concatenate two random numbers and then use the SHA-256 hash algorithm to generate a 256-bit session key, for example, "8D4E7F2A1C9B3A5D6E8F1A2C3B4D5E6F7A8C9D0E1F2A3B4C5D6E7F8A9B0". This session key will be used for encryption and authentication in subsequent communications.

[0036] Device A, the party transferring the assets, generates a smart contract data structure containing asset information. This data structure includes the asset identifier "ASSET20240501001", asset description "high-precision industrial sensor assembly, model PS-2024-XDR, quantity 5 units", transferor identifier "TRANSFEROR20240501", receiver identifier "RECIPIENT20240501", handover time "2024-05-01 14:30:00", handover location coordinates "114.05, 22.55", and handover conditions "no damage upon acceptance, normal function". Device A uses the AES-256-GCM encryption algorithm and the previously generated session key to encrypt the smart contract data structure, obtaining ciphertext data. Meanwhile, device A uses the HMAC-SHA256 algorithm to generate a 32-byte message authentication code based on the session key, such as "5A7B9C2D3E4F5A6B7C8D9E0F1A2B3C4D5E6F7A8B9C0D1E2F3A4B5C6D7E8".

[0037] Because NFC communication has a limited data transmission capacity per transaction, Device A determines the number of data fragments based on the size of the smart contract data structure. Assuming the encrypted smart contract data is 4096 bytes, and NFC's single transmission limit is 250 bytes, the data needs to be divided into 17 fragments (4096 ÷ 250 = 16.384, rounded up to 17). Device A performs fragment processing on the encrypted data, with each fragment being 250 bytes in size, and the last fragment being 96 bytes (4096 - 250 × 16 = 96).

[0038] Device A uses the NFC Data Exchange Format (NDEF) to generate message structures. Each NDEF message contains the following parts: a 4-byte fragment number (e.g., "0001" indicates the first fragment), a 16-byte record header (containing record type, length identifier, etc.), and the actual data payload (encrypted smart contract fragments). For example, the structure of the first NDEF message is: "0001|TYPE:SMART-CONTRACT|LEN:250|DATA:{encrypted-data-part-1}".

[0039] During transmission, device A performs a CRC-32 check on each data fragment, generating a 4-byte checksum and appending it to the end of each fragment. Upon receiving a fragment, device B also calculates the CRC checksum and compares it with the received checksum. If a transmission error is detected, such as data corruption during the transmission of the 5th fragment, device B records the current fragment sequence number "0005" and sends a retransmission request to device A. Upon receiving the retransmission request, device A retransmits the fragment with sequence number "0005" until device B successfully receives and verifies the fragment. This process continues until all 17 data fragments have been successfully transmitted and verified.

[0040] After receiving all data fragments, Device B, the recipient of the funds, reassembles them into complete encrypted data and a message authentication code in sequence. Device B first uses the previously generated session key to verify the validity of the message authentication code using the HMAC-SHA256 algorithm. If the verification passes, Device B then uses the session key and the AES-256-GCM algorithm to decrypt the encrypted data, obtaining the original smart contract data structure. The decrypted smart contract data structure will be displayed on Device B for the recipient to confirm the handover details.

[0041] This invention establishes an offline connection via NFC communication, uses randomly generated session keys from both parties for encrypted communication, and achieves secure transmission of financial transfer information. The security mechanism based on message authentication codes and CRC checks effectively prevents data from being tampered with or corrupted during transmission, ensuring data integrity. Data fragmentation and error retransmission mechanisms enhance communication reliability, enabling complete data transmission even under unstable network conditions.

[0042] In one optional implementation, the steps of isolating handover data from other application data in a trusted execution environment, generating a signature key based on device hardware characteristics and storing the signature key in a secure storage area of ​​the trusted execution environment, generating an tamper-proof signature using the signature key, and combining the tamper-proof signature with the handover data to form an tamper-proof handover credential include: After receiving the handover request, the recipient of the property imports the handover data into a trusted execution environment through a security monitoring instruction. In the trusted execution environment, an independent virtual address space is allocated for the handover data and access control permissions are set to achieve isolation from other application data. The device hardware circuit response signal is acquired, and the response signal is XORed with the environmental noise signal to obtain the device hardware feature value. The bit flipping characteristic is obtained by sampling the device hardware feature value multiple times. An error correction code is constructed based on the bit flipping characteristic to locate and correct errors, and a stable feature value is obtained by repeatability testing. The stable feature value is concatenated with the device's unique identification information to obtain the signature key. An encryption key is generated in the trusted execution environment. The signature key is encrypted using the encryption key to obtain key ciphertext. The integrity check value of the key ciphertext is calculated. The key ciphertext and the integrity check value are written into the secure storage area of ​​the trusted execution environment. The hash value of the handover data is calculated based on the signature key and encrypted to generate an tamper-proof signature; the tamper-proof signature is combined with the handover data to form an tamper-proof handover certificate.

[0043] For example, when the transfer of property requires electronic recording, the transferring party initiates a transfer request, including information on the items being transferred, the time, and the location. Upon receiving the transfer request, the receiving party imports the transfer data from the normal execution environment to the trusted execution environment by invoking a security monitoring command. Specifically, the receiving device invokes the TrustZone security monitoring command (SMC), triggering the processor to switch from the normal world to the secure world, and then transmits the transfer data parameters to the trusted execution environment via a shared memory area.

[0044] In a trusted execution environment, a separate virtual address space is allocated for the imported handover data, such as a contiguous 64KB space from address 0x80000000 to 0x80010000. Access control permissions are also set to mark this address space as readable and writable only by specific security applications, preventing other applications from accessing it. Through page table attribute settings in the Memory Management Unit (MMU), the access permissions for this memory region are configured to the S-EL0 permission level, ensuring that ordinary applications cannot read or modify the data in this region, achieving physical isolation from data from other applications.

[0045] To generate a signature key based on hardware characteristics, the response signal of the device's hardware circuitry needs to be obtained. Specifically, a standard voltage (e.g., 1.2V) is applied to the SRAM cell, and its initial power-on state is measured. In practice, the initial values ​​of a 128KB SRAM cell block on the device are read to obtain an initial bit sequence as the original response signal, such as "10110101000111...". Simultaneously, ambient noise signals are collected, for example, by sampling the values ​​of an unconnected analog-to-digital converter (ADC), obtaining an ambient noise sequence such as "00101010100101...". A bitwise XOR operation is performed between the response signal and the ambient noise signal to obtain the device's hardware characteristic value, enhancing the randomness and unpredictability of the characteristic value. To address the stability issue of the hardware characteristic value under different environmental conditions, the hardware characteristic value is sampled multiple times, for example, 10 times each at different temperature conditions (25℃, 30℃, 35℃), and bit flipping characteristics are analyzed. Through statistical analysis, bit positions prone to flipping (e.g., bits 15, 47, and 82) and their flipping probabilities are identified. Based on these bit-flipping properties, a BCH(255,231) error-correcting code is constructed, capable of correcting up to 3 bits of error, used for error location and correction of feature values. Repeatability testing verifies that the stability of the error-corrected feature value reaches 99.7% in 100 tests, thus confirming a stable 256-bit feature value. This stable feature value is concatenated with the device's unique identifier (such as the 64-bit device serial number "AD7B2C9E8F15D360"), and then processed using the SHA-256 hash algorithm to obtain the final 256-bit signature key.

[0046] To securely store the signing key, an AES-256 encryption key is generated within the Trusted Execution Environment (TEE). A hardware random number generator produces a 256-bit random value as the encryption key. This encryption key is then used to encrypt the signing key using AES-GCM, yielding the ciphertext. An HMAC-SHA256 integrity check value is calculated for the ciphertext to ensure it is not tampered with during storage. The ciphertext and integrity check value are then written together to the secure storage area of ​​the TEE, located within the device's secure element or Trusted Platform Module (TPM), which is protected against physical attacks.

[0047] When tamper-proof protection of the handover data is required, the key ciphertext and integrity check value are read from the secure storage area. After verifying that the integrity check value is correct, the original signature key is obtained by decrypting it using the aforementioned encryption key. Using this signature key, the SHA-256 hash value is calculated for the handover data, which includes the handover item number (e.g., "ASSET-9876"), the handover time (e.g., "2023-10-15 14:30:25"), and the identity information of the handover parties (e.g., "USER-A" and "USER-B"), resulting in a 32-byte hash digest. Then, the HMAC-SHA256 algorithm is used, with the signature key as the key, to encrypt the hash digest, generating a tamper-proof signature.

[0048] The tamper-proof signature (a 64-byte hexadecimal string) is combined with the original handover data to form a complete tamper-proof handover credential. This credential can be stored in a blockchain or distributed ledger for subsequent handover verification and traceability. When the authenticity of the handover credential needs to be verified, the verifier generates a signature key from the device hardware characteristics through the same process, recalculates the tamper-proof signature, and compares it with the signature in the credential. If they match, it proves that the handover data has not been tampered with and its source is trustworthy.

[0049] This invention prevents unauthorized access to transferred data by other applications through virtual address space allocation and access control. It generates signature keys based on device hardware characteristics, providing device-level security and eliminating the need for users to remember complex passwords. The overall solution combines hardware security mechanisms with cryptographic techniques, achieving data tamper-proof capabilities based on physically unclonable properties, significantly improving the security and reliability of financial transfer credentials.

[0050] In one optional implementation, the steps of obtaining bit-flipping characteristics by sampling the hardware feature values ​​of the device multiple times, constructing error-correcting codes based on the bit-flipping characteristics for error location and correction, and obtaining stable feature values ​​through repeatability testing include: The number of times each bit of the device hardware feature value is flipped in multiple samplings is counted, the flip probability of each bit is calculated based on the number of flips, and the unstable bits that need to be corrected are determined based on the flip probability. The error correction capability of the error correction code is determined based on the number of unstable bits. The minimum Hamming distance is calculated based on the error correction capability. Galois field parameters are selected based on the minimum Hamming distance to generate a parity check matrix. The device hardware feature values ​​are encoded using the check matrix to obtain check codewords, the check vector of the check codewords is calculated, and the error location polynomial is obtained based on the check vector. The error location in the device hardware feature value is determined according to the error location polynomial, an error pattern corresponding to the error location is generated, and the error pattern is XORed with the device hardware feature value to obtain the correction feature value. The correction feature value is subjected to multiple repeatability tests, and the stability index of the feature value is calculated based on the test results. When the stability index exceeds a preset threshold, the correction feature value is determined as a stable feature value.

[0051] Combination Figure 2 The flowchart illustrating the stability processing of device hardware feature values ​​based on multiple sampling and error correction coding is provided below. For example, the hardware feature values ​​of the same device are read multiple times, such as 100 samplings. Each sampling yields a 128-bit binary sequence representing the device's hardware feature value. By comparing the results of these 100 samplings, the number of times each bit is flipped during the multiple samplings is recorded. For example, for the 5th bit, if it appears as "1" 20 times and "0" 80 times in 100 samplings, the number of flips for that bit is recorded as 20. This same statistical analysis is performed on each of the 128 bits, forming a flip count table.

[0052] The flip probability is equal to the number of times that bit has flipped divided by the total number of samples. Continuing the example above, the flip probability of the 5th bit is 20 / 100 = 0.2 or 20%. A flip probability threshold is set, for example, 0.1 (i.e., 10%). When the flip probability of a bit exceeds this threshold, that bit is considered an unstable bit. Suppose that statistically, 8 out of 128 bits have a flip probability exceeding 0.1; these 8 bits are marked as unstable bits requiring error correction, specifically bits 5, 17, 32, 46, 59, 73, 98, and 116.

[0053] The error-correcting capability of an error-correcting code is determined based on the number of unstable bits identified. In this example, since there are 8 unstable bits, to ensure reliable error correction and consider the potential impact of additional noise, the error-correcting capability t is set to 10, meaning it can correct a maximum of 10 errors. Based on the determined error-correcting capability t=10, the required minimum Hamming distance d is calculated. For an error-correcting code that can correct t errors, the minimum Hamming distance d must satisfy d≥2t+1. Therefore, for t=10, the minimum Hamming distance d≥21.

[0054] Based on the calculated minimum Hamming distance d ≥ 21, appropriate Galois field parameters need to be selected. The minimum Hamming distance directly affects the size and structure of the required Galois field. Specifically, to implement a BCH code with a minimum Hamming distance of 21, the coding needs to be constructed on a sufficiently large Galois field. Considering the eigenvalue length is 128 bits, the unstable bits are 8 bits, and the required minimum Hamming distance is 21, m = 8 is chosen, i.e., the error-correcting code is constructed on GF(2^8). This choice ensures sufficient coding space and error-correcting capability. A primitive polynomial P(x) = x^8 + x^4 + x^3 + x^2 + 1 is chosen on GF(2^8). This polynomial selection, based on the requirement of minimum Hamming distance d ≥ 21, can generate enough minimal polynomials to construct the required parity-check matrix.

[0055] Based on the selected Galois field GF(2^8) and the primitive polynomial P(x), a parity-check matrix H is constructed. The design of the parity-check matrix H is directly related to the requirement of minimum Hamming distance d ≥ 21. For BCH codes, the parity-check matrix H consists of the roots of 2^t consecutive minimal polynomials. The primitive element α is chosen, which is the root of polynomial P(x) in GF(2^8). To satisfy the requirement of minimum Hamming distance d ≥ 21, each row of the parity-check matrix H consists of primitive elements of consecutive powers, starting from α and going up to α^(2^t). The i-th row of the parity-check matrix H is [1, α^i, (α^i)^2, (α^i)^3, ..., (α^i)^(n-1)], where i ranges from 1 to 2^t (i.e., 20). Therefore, a 32 × 160 parity-check matrix H is constructed, where each GF(2^8) element is represented as an 8-bit binary number. This matrix design ensures that the minimum Hamming distance between codewords is at least 21, satisfying the error correction capability requirement of t = 10.

[0056] The 128-bit hardware feature value is denoted as the information vector u = [u_0, u_1, ..., u_127]. The generator matrix G is derived from the parity check matrix H. Specifically, H is converted to the standard form [P^T|I], where P^T is a 32×128 matrix and I is a 32×32 identity matrix. The generator matrix G is then represented as [I|P], where I is a 128×128 identity matrix and P is a 128×32 matrix. By multiplying the information vector u by the generator matrix G, a 160-bit parity check codeword c = [c_0, c_1, ..., c_159] is obtained. In this encoding process, the first 128 bits remain the same as the original information, and the last 32 bits are the parity bits calculated from the parity check matrix. This encoding method ensures that the minimum distance between parity check codewords meets the preset minimum Hamming distance requirement.

[0057] The check vector S is calculated for error detection and location. It is calculated by multiplying the check codeword c by the check matrix H. In the absence of errors, S should be an all-zero vector; when errors exist, S contains error information. For example, suppose the resulting check vector S = [S_0, S_1, ..., S_31], where each element S_i is an element in GF(2^8), represented by 8 bits. Examples include S_0 = 01101100, S_1 = 10001101, etc. A non-zero S indicates an error in the check codeword, and the specific value of S is related to the error location and error mode.

[0058] Error location is performed based on the check vector S to obtain the error location polynomial. This step uses the Berlekamp–Massey algorithm, which is specifically designed to compute the error location polynomial from the check vector. First, the check polynomial S(x) = S_1 + S_3x + S_5x^2 + ... + S_(2t-1)x^(t-1) is constructed using the odd-indexed elements of the check vector. Then, the error location polynomial σ(x) is obtained by iteratively updating the polynomial. In each iteration, the coefficients of the error location polynomial are updated based on the current check element and the calculated polynomial coefficients. After t iterations, the resulting polynomial is the error location polynomial σ(x). For example, σ(x) = 1 + x^3 + x^5 + x^8 indicates an error at a specific location.

[0059] Solving for σ(x) = 0 in GF(2^8) yields the roots of the polynomial. In actual calculations, each α^j (j from 0 to 159) is substituted into the polynomial σ(x). If σ(α^j) = 0, then j is an error position. For example, calculations show σ(α^3) = 0, σ(α^5) = 0, and σ(α^8) = 0, indicating errors at positions 3, 5, and 8. These positions correspond to specific locations in the encoded 160-bit check codeword.

[0060] The error pattern is a binary sequence of the same length as the check codeword, with 1s at the error positions and 0s at the other positions. For example, for the error positions 3, 5, and 8, the error pattern e = [0,0,0,1,0,1,0,0,1,0,...,0] (160 bits, with only bits 3, 5, and 8 being 1s). This error pattern is XORed with the original device hardware characteristic value to obtain the corrected characteristic value. This process essentially flips the bit values ​​at the error positions, thus correcting the error.

[0061] The stability of the corrected feature value is verified by performing multiple repetitive tests. The sampling, encoding, and error correction process is repeated, for example, 50 tests, recording the result of the corrected feature value after each test. A stability index is calculated based on these results. For each bit, the number of times 0 and 1 appear in the 50 tests is counted. The state with the most frequent occurrences is taken as the dominant state for that bit. The stability of that bit is calculated by dividing the number of occurrences of the dominant state by the total number of tests. For example, if a bit is 1 48 times and 0 2 times in 50 tests, the stability of that bit is 48 / 50 = 0.96 or 96%. The average stability of all bits is calculated as the overall stability index. When the overall stability index exceeds a preset threshold (e.g., 99.5%), the current corrected feature value is determined as the final stable feature value. This stable feature value can be used for subsequent security applications such as key generation or authentication.

[0062] This invention solves the instability problem in the hardware feature extraction process by repeatedly sampling and analyzing the bit-flipping characteristics of the device's hardware feature values. The selection of Galois domain parameters and the generation of the parity check matrix provide mathematical stability guarantees for the hardware feature values, and the calculation of the error location polynomial supports precise error localization. Through repeatability testing and stability index evaluation, the reliability of the final feature values ​​is ensured, providing a stable and reliable foundation for subsequent signature key generation.

[0063] In one optional implementation, the step of the transferor and the recipient of the property sequentially verifying the tamper-proof handover certificate with digital signatures includes: The recipient of the property generates a first digital signature on the tamper-proof handover certificate, and combines the first digital signature with the tamper-proof handover certificate to form a first signature data packet; the transferor of the property verifies the first digital signature, and generates verification confirmation information upon successful verification. The transferring party generates a second digital signature for the tamper-proof handover certificate and the verification confirmation information, and combines the second digital signature with the tamper-proof handover certificate and the verification confirmation information to form a second signature data packet; the receiving party verifies the second digital signature; The transferor and the recipient of the property respectively store complete signature records containing the first signature data packet and the second signature data packet, and calculate the hash value of the complete signature record as an on-chain index identifier for writing the complete signature record into the blockchain network.

[0064] For example, at the start of the asset transfer, a tamper-proof transfer certificate containing detailed information about the transferred assets is first generated. This certificate includes key information such as the asset's unique identifier "PROP-2023-10-15-0001", asset name "Valuable Equipment A", asset value "50,000 yuan", transfer time "2023-10-15 14:30:00", transfer location "Secure Transfer Center", transferor's identification code "TR-ID-98765", and recipient's identification code "RC-ID-12345". This information is then hashed using the SHA-256 algorithm to generate the hash value of the tamper-proof transfer certificate: "7f83b1657ff1fc53b92dc18148a1d65dfc2d4b1fa3d677284addd200126d9069".

[0065] After receiving the tamper-proof handover certificate, the recipient of the funds signs the certificate using the ECDSA elliptic curve digital signature algorithm. The recipient first verifies the integrity of the certificate, confirming that its content has not been tampered with. Upon successful verification, the recipient uses its private key (assumed to be RC-PRIV-KEY) to perform a signature calculation on the certificate's hash value, generating a first digital signature "RC-SIG-3a7bd3e99f744b1c8c2d5b3a2a98a62cbd31450c76c1b2a462dbbeb393d4cddc". The recipient then combines this first digital signature with the original tamper-proof handover certificate to form a first signed data packet. The structure of this data packet is: the original tamper-proof handover certificate content, the first digital signature value, the signature time "2023-10-15 14:35:22", and the signer's identification code "RC-ID-12345".

[0066] After receiving the first signed data packet, the transferring party verifies the validity of the first digital signature using the receiving party's public key (RC-PUB-KEY). During verification, the transferring party recalculates the hash value of the tamper-proof transfer certificate and compares it with the signature value decrypted using the receiving party's public key. Upon successful verification, the transferring party generates verification confirmation information, including the confirmation status "VERIFIED", verification time "2023-10-15 14:40:15", verifier identification code "TR-ID-98765", and verification result description "Receiving party identity and signature valid".

[0067] The transferring party then generates a second digital signature by combining the tamper-proof handover certificate and the verification confirmation information. The transferring party first merges the original tamper-proof handover certificate content with the verification confirmation information, and uses the SHA-256 algorithm to calculate the hash value of the merged content: "9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08". The transferring party then signs this hash value using its private key (TR-PRIV-KEY), generating a second digital signature: "TR-SIG-5e884898da28047151d0e56f8dc6292773603d0d6aabbdd62a11ef721d1542d8". The party transferring the property shall combine this second digital signature with the original tamper-proof handover certificate and verification confirmation information to form a second signature data packet. The structure of this data packet is as follows: original tamper-proof handover certificate content, verification confirmation information, second digital signature value, signature time "2023-10-15 14:45:37", and signer identification code "TR-ID-98765".

[0068] After receiving the second-signed data packet, the recipient of the funds uses the public key (TR-PUB-KEY) of the transferor to verify the validity of the second digital signature. During the verification process, the recipient recalculates the hash value of the combination of the tamper-proof handover certificate and the verification confirmation information, and compares it with the signature value decrypted using the transferor's public key to confirm the signature's authenticity and validity.

[0069] After verification by both parties, a complete signature record is generated, containing the entire contents of the first and second signature data packets. Specifically, it includes: the original tamper-proof handover certificate, the recipient's first digital signature and related information, the transferor's verification confirmation information, the transferor's second digital signature and related information, and the handover completion time "2023-10-15 14:50:08". Both the transferor and recipient store a copy of this complete signature record locally.

[0070] To ensure the traceability and immutability of the complete signature record, the hash value of the complete signature record, "8d969eef6ecad3c29a3a629280e686cf0c3f5d5a86aff3ca12020c923adc6c92", is calculated using the SHA-256 algorithm and serves as the on-chain index identifier for this record. This hash value is encapsulated together with the complete signature record, and the data is written to the blockchain network by calling the blockchain network's smart contract interface "recordTransferEvidence". After the data is on-chain, the transaction hash "0x7b5d8c8d299af1c7c245405e591698a67f607eee89412515e94fdd9ea7f9c433" and the block height "4,567,890" are returned as proof of successful on-chain processing.

[0071] The complete signature record is permanently stored in the blockchain network. When either party needs to verify the authenticity of the handover certificate later, they can query the original record through the on-chain index and verify the signatures of both parties through the public key, ensuring the integrity and non-repudiation of the handover process.

[0072] This invention establishes a two-way confirmation trust mechanism by having both parties sequentially verify the tamper-proof handover certificate with digital signatures.

[0073] In one optional implementation, after the transferor and recipient of the assets reconnect to the blockchain network, the step of calculating the dynamic priority of data uploading to the blockchain based on the current congestion index of the blockchain network, the value of the assets, and timeliness requirements includes: The ratio of the number of pending transactions to the transaction pool capacity in the blockchain network is used as the transaction pool depth. The block confirmation delay time is obtained, and the network congestion index is calculated based on the transaction pool depth and the block confirmation delay time. Obtain the market valuation of the asset corresponding to the data to be uploaded to the blockchain and the deadline for data upload to the blockchain. Calculate the asset value based on the market valuation and calculate the time sensitivity based on the deadline using an exponential decay function. The network congestion index, the value of the property, and the time sensitivity are normalized to obtain normalized parameters. Obtain the predicted priority and actual priority from historical transaction data to construct a mean squared error optimization objective function, solve the mean squared error optimization objective function to obtain dynamic weight coefficients that satisfy the constraint that the sum of the weights is one and that each weight is a non-negative number; The predicted data on-chain priority is calculated based on the normalization parameters and the dynamic weight coefficients; the actual data on-chain priority is obtained, and the difference between the predicted data on-chain priority and the actual data on-chain priority is calculated to obtain the prediction error; the gradient value of the dynamic weight coefficients is calculated based on the prediction error, and the dynamic weight coefficients are updated based on a preset learning rate for calculating the on-chain priority of subsequent data to be on-chain.

[0074] For example, the ratio of the number of pending transactions in the blockchain network to the transaction pool capacity is used as the transaction pool depth. For instance, if there are 2500 pending transactions in the pool and the pool capacity is 10000, the transaction pool depth is 0.25. Simultaneously, block confirmation latency is monitored, which is the average waiting time from transaction submission to being included in a block. Under normal network load, block confirmation latency might be 30 seconds, but it could extend to 300 seconds during network congestion. A network congestion index is calculated by weighting the transaction pool depth and block confirmation latency. The ratio of transaction pool depth to a standard depth (e.g., 0.15) is multiplied by 0.6, and the ratio of block confirmation latency to a standard latency (e.g., 60 seconds) is multiplied by 0.4; the sum of these two values ​​yields the network congestion index. If the transaction pool depth is 0.25 and the block confirmation delay is 180 seconds, then the network congestion index is (0.25 / 0.15)×0.6+(180 / 60)×0.4=1.0+1.2=2.2.

[0075] Obtain the market valuation of the asset corresponding to the data to be uploaded to the blockchain and the deadline for data upload. The market valuation is automatically assessed based on the current market price database. For example, the market valuation of a batch of electronic devices is 50,000 yuan. The deadline for data upload is the last day before the handover task must be completed. For example, if the current time is 14:30 and the task deadline is 16:30, then there are 2 hours remaining. Calculate the asset's value based on the market valuation and map the market valuation to a value range of 0-100. For an asset worth 50,000 yuan, its mapped value score might be 65 points. Calculate the timeliness sensitivity based on the deadline using an exponential decay function. The shorter the remaining time, the higher the timeliness sensitivity. For example, when there are 2 hours remaining, the timeliness sensitivity is 0.3; when the remaining time decreases to 1 hour, the timeliness sensitivity may rise to 0.7; when only 30 minutes remain, the timeliness sensitivity may reach 0.9.

[0076] The network congestion index, property value, and time sensitivity are normalized to obtain normalized parameters. The network congestion index of 2.2 is linearly normalized to the 0-1 interval, and the normalized value is calculated to be 0.73 (2.2 / 3.0) according to the preset upper limit of the congestion index of 3.0. The property value of 65 points is directly normalized to 0.65 within the value range of 0-100. The time sensitivity of 0.3 is already within the 0-1 interval, so the normalized value remains at 0.3.

[0077] A mean squared error (MSE) optimization objective function is constructed by obtaining predicted and actual priorities from historical transaction data. The historical data includes normalized parameters (network congestion index, asset value, and time sensitivity) and actual on-chain priorities from the past 100 transactions. Using this historical data, a model is trained to minimize the MSE between predicted and actual priorities. The MSE optimization objective function is solved using a gradient descent algorithm, updating the weights in each iteration to reduce the MSE. After multiple iterations, dynamic weight coefficients for the three parameters are obtained; for example, the network congestion index has a weight of 0.25, the asset value has a weight of 0.45, and the time sensitivity has a weight of 0.3. Based on the normalized parameters and dynamic weight coefficients, the predicted on-chain priority value is calculated by multiplying each of the three normalized parameters by its corresponding weight coefficient and then summing the results. For example, 0.75 × 0.25 + 0.65 × 0.45 + 0.3 × 0.3 = 0.1875 + 0.2925 + 0.09 = 0.57. The prediction priority is 0.57, which represents the relative priority among all pending transactions.

[0078] Obtain the actual data upload priority, which is the actual priority ultimately assigned to the transaction by the blockchain network based on the current overall situation. Assume the actual assigned priority is 0.62. Calculate the prediction error by subtracting the predicted data upload priority from the actual data upload priority: 0.62 - 0.57 = 0.05. Calculate the gradient of the dynamic weight coefficients based on the prediction error. For each weight coefficient, its gradient is proportional to the product of the prediction error and the corresponding normalization parameter. For example, the gradient of the network congestion index weight is 0.05 × 0.75 = 0.0375, the gradient of the asset value weight is 0.05 × 0.65 = 0.0325, and the gradient of the time sensitivity weight is 0.05 × 0.3 = 0.015.

[0079] The dynamic weight coefficients are updated based on a preset learning rate to calculate the on-chain priority of subsequent data to be uploaded to the blockchain. With a learning rate set to 0.1, the network congestion index weight is updated to 0.25 + 0.1 × 0.0375 = 0.2538, the asset value weight to 0.45 + 0.1 × 0.0325 = 0.4533, and the time sensitivity weight to 0.3 + 0.1 × 0.015 = 0.3015. The sum of the updated weights remains 1. If a weight becomes negative after the update, it will be set to 0, and other weights will be adjusted to ensure the sum of the weights is 1. This dynamic adjustment mechanism enables the adaptive learning of the optimal priority allocation strategy under different network environments and transaction characteristics.

[0080] This invention dynamically assesses network congestion, asset value, and timeliness requirements, and combines this with an adaptive weight adjustment mechanism to assign reasonable on-chain priorities to different transactions. This method significantly improves the efficiency of blockchain resource utilization, ensures timely processing of important transactions, and reduces transaction costs.

[0081] In one optional implementation, the step of constructing a mean squared error optimization objective function by obtaining the predicted priority and actual priority from historical transaction data includes: The historical network congestion index is calculated by obtaining the transaction pool depth and block confirmation delay time corresponding to each transaction record in the historical transaction data; the temporal fluctuation variance of the historical network congestion index is calculated in each block generation cycle, and the abrupt change point of the temporal fluctuation variance is detected as the load partition boundary to divide the historical transaction data into multiple load partitions. The squared difference between the predicted priority and the actual priority in the historical transaction data of each load partition is calculated to obtain the transaction throughput in each load partition. The partition weighted mean square error is constructed based on the product of the squared difference and the transaction throughput. The number of times each load partition is converted to other load partitions in the historical transaction data is calculated. The number of conversions is divided by the number of times the corresponding load partition appears to obtain the partition conversion probability. Obtain the current network congestion index, determine the current load partition by comparing the fluctuation variance of the current network congestion index with the load partition boundary, and determine the load partition with the highest conversion probability to the current load partition as the target load partition based on the partition conversion probability. A mean squared error optimization objective function is constructed based on the partition weighted mean squared error of the current load partition and the partition weighted mean squared error of the target load partition.

[0082] For example, historical transaction data from the last 7 days is retrieved from the blockchain network database. Each record includes information such as transaction submission time, block confirmation time, transaction pool depth, block confirmation delay, transaction prediction priority, and actual allocation priority. For each historical transaction record, its transaction pool depth and block confirmation delay are extracted. For example, a record shows a transaction pool depth of 0.32 and a block confirmation delay of 125 seconds. The ratio of the transaction pool depth to the standard depth of 0.15 is multiplied by 0.6, and the ratio of the block confirmation delay to the standard delay of 60 seconds is multiplied by 0.4. The sum of these two values ​​yields the historical network congestion index for that record. In the example above, the historical network congestion index is calculated as (0.32 / 0.15)×0.6 + (125 / 60)×0.4 = 1.28 + 0.83 = 2.11. Similar calculations are performed on all transaction records within the last 7 days to obtain a time-series historical network congestion index dataset.

[0083] Historical network congestion indices are grouped according to block generation cycles, with each block generation cycle typically lasting 10 minutes. Within each block generation cycle, the variance of the historical network congestion index is calculated. Specifically, this is done by subtracting the average value from all network congestion index values ​​within the cycle, summing the squares of the differences, and dividing by the sample size. For example, if a block generation cycle contains 10 network congestion index values: 2.11, 2.15, 2.18, 2.23, 2.30, 2.37, 2.45, 2.51, 2.58, and 2.63, with an average of 2.35, then the variance of that cycle is [(2.11-2.35)^2+(2.15-2.35)^2+...+(2.63-2.35)^2] / 10=0.026. A series of variance fluctuations for consecutive block generation cycles is calculated, and significant changes in variance are detected by setting a threshold. The specific method involves marking a point as a breakout when the variance ratio of two adjacent periods exceeds a preset threshold of 3.0. For example, if the variance of the 20th period is 0.026 and the variance of the 21st period is 0.083, their ratio is 3.19, exceeding the threshold of 3.0. Therefore, the starting point of the 21st period is marked as the load partition boundary. Based on all identified load partition boundaries, the 7-day historical transaction data is divided into multiple load partitions, such as light load, medium load, heavy load, and extremely heavy load partitions.

[0084] Statistical analysis is performed on historical transaction data within each load partition. For each transaction record, the squared difference between its predicted priority and actual priority is calculated. For example, if a transaction's predicted priority is 0.57 and its actual priority is 0.62, the squared difference is (0.62-0.57)^2 = 0.0025. The sum of the squared differences of all transactions within each load partition is calculated and divided by the number of transactions in that partition to obtain the mean squared error of that partition. Assuming a lightly loaded partition contains 1000 transaction records, the sum of the squared differences is 2.5, so the mean squared error of that partition is 2.5 / 1000 = 0.0025. The transaction throughput within each load partition is obtained, which is the number of transactions processed per unit time in that partition. For example, the transaction throughput of a lightly loaded partition is 150 transactions / minute. The mean squared error of each partition is multiplied by the transaction throughput of that partition to obtain the partition-weighted mean squared error. For lightly loaded partitions, the partition weighted mean square error is 0.0025 × 150 = 0.375. This weighting method takes into account the efficiency differences in transaction processing among partitions with different loads, making the optimization objective more closely aligned with actual performance.

[0085] The system analyzes the transitions between different load partitions in historical transaction data. It iterates through the historical transaction data chronologically, recording the changes in load partitions for adjacent transactions. For example, from transaction 100 to transaction 101, if the network transitions from a light load partition to a medium load partition, this is recorded as one light-to-medium load transition. The system calculates the number of transitions for each load partition to other load partitions. Assuming that in 7 days of historical data, a light load partition appeared 200 times, with 85 transitions to a medium load partition, 60 to a heavy load partition, 30 to a very heavy load partition, and 25 remaining in the light load partition. Dividing each transition count by the total number of occurrences of that load partition yields the partition transition probability. For a light load partition, the probabilities of transitioning to medium, heavy, very heavy, and itself are 85 / 200 = 0.425, 60 / 200 = 0.3, 30 / 200 = 0.15, and 25 / 200 = 0.125, respectively. These transition probabilities reflect the dynamic changes in network load status and help predict future network conditions.

[0086] Obtain the current network congestion index using the same calculation method as historical data processing. Assuming the current transaction pool depth is 0.28 and the block confirmation delay is 110 seconds, the current network congestion index is calculated as (0.28 / 0.15)×0.6 + (110 / 60)×0.4 = 1.12 + 0.73 = 1.85. Calculate the network congestion index fluctuation variance within the most recent block generation cycle, assuming it to be 0.022. Compare this fluctuation variance with the pre-determined load partition boundaries to determine the current load partition. For example, a fluctuation variance of 0.022 falls within the range of a light load partition (0.01-0.03), therefore the current load partition is determined to be lightly loaded. Based on the transition probability of light load partitions, determine the target load partition with the highest transition probability to the current load partition. According to the previous statistics, the probability of a light load partition transitioning to a medium load partition is the highest (0.425), therefore the medium load partition is determined as the target load partition.

[0087] A mean squared error (MSE) optimization objective function is constructed based on the weighted mean squared errors of the current and target load partitions. Assume the weighted MSE of the light load partition is 0.375 and the weighted MSE of the medium load partition is 0.625. The constructed MSE optimization objective function is the weighted sum of the two MSEs, where the weight of the current load partition is 0.7 and the weight of the target load partition is 0.3. Specifically, the calculation is 0.7 × 0.375 + 0.3 × 0.625 = 0.2625 + 0.1875 = 0.45. This optimization objective function is used to solve for the subsequent dynamic weight coefficients, aiming to minimize this function value so that the predicted priority is as close as possible to the actual priority, improving the accuracy of priority prediction. In practical applications, historical transaction data is periodically updated, load partitions are re-divided, and transition probabilities are updated to ensure that the optimization objective function accurately reflects the current network state and future trends.

[0088] This invention achieves accurate characterization and prediction of blockchain network load status by introducing the concept of load partitioning and partition transition probability. The weighted mean square error optimization objective function, constructed based on historical data, comprehensively considers the current network state and potential future trends, making priority prediction more accurate and reliable. This dynamically adaptive optimization mechanism significantly improves the efficiency of blockchain resource allocation, reduces transaction latency, enhances adaptability to network fluctuations, and provides technical support for the efficient on-chain recording of financial transaction data.

[0089] A second aspect of this invention provides a blockchain-based offline asset transfer traceability and tamper-proof management system, comprising: The first unit is used to obtain the identity information of the transferor and the recipient of the property, generate a smart contract in the blockchain network, and establish an offline connection between the transferor and the recipient of the property through near field communication (NFC), and send a handover request containing the smart contract to the recipient of the property. The second unit is used to isolate the handover data from other application data in a trusted execution environment after the property recipient receives the handover request, generate a signature key based on the device hardware feature value and store the signature key in the secure storage area of ​​the trusted execution environment, generate an anti-tamper signature using the signature key, and combine the anti-tamper signature with the handover data to form an anti-tamper handover certificate. The third unit is used for the transferor and the recipient of the property to sequentially verify the tamper-proof handover certificate with digital signatures. The fourth unit is used to calculate the dynamic priority of data uploading to the blockchain network based on the current congestion index of the blockchain network, the value of the property, and the timeliness requirements after the transferor and recipient of the property reconnect to the blockchain network; and to write the tamper-proof handover certificate and digital signature information to the blockchain network in batches according to the dynamic priority. The fifth unit is used to obtain the tamper-proof handover certificate and digital signature information for verification when it is necessary to trace the property handover record, and generate a property handover traceability report.

[0090] A third aspect of the present invention provides an electronic device, comprising: processor; Memory used to store processor-executable instructions; The processor is configured to invoke instructions stored in the memory to execute the aforementioned method.

[0091] A fourth aspect of the present invention provides a computer-readable storage medium having stored thereon computer program instructions that, when executed by a processor, implement the aforementioned method.

[0092] This invention can be a method, apparatus, system, and / or computer program product. The computer program product may include a computer-readable storage medium having computer-readable program instructions loaded thereon for performing various aspects of the invention.

[0093] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A blockchain-based method for offline transfer traceability and tamper-proof management of assets, characterized in that: include: Obtain the identity information of the transferor and recipient of the assets, and generate a smart contract in the blockchain network; An offline connection is established between the transferor and the recipient of the property via Near Field Communication (NFC), and the transferor sends a handover request containing the smart contract to the recipient. After receiving the handover request, the recipient of the property isolates the handover data from other application data in the trusted execution environment, generates a signature key based on the device hardware feature value and stores the signature key in the secure storage area of ​​the trusted execution environment, uses the signature key to generate an anti-tamper signature, and combines the anti-tamper signature with the handover data to form an anti-tamper handover certificate. The transferring party and the receiving party shall sequentially verify the tamper-proof handover certificate with digital signatures. After the transferor and recipient of the property reconnect to the blockchain network, the dynamic priority of data uploading is calculated based on the current congestion index of the blockchain network, the value of the property, and the timeliness requirements. The tamper-proof handover certificate and digital signature information are then written into the blockchain network in batches according to the dynamic priority. When it is necessary to trace the transfer records of property, the tamper-proof transfer certificate and digital signature information are obtained for verification, and a property transfer traceability report is generated.

2. The method according to claim 1, characterized in that, The steps of establishing an offline connection between the transferor and the recipient of the property via Near Field Communication (NFC), and the transferor sending a handover request containing the smart contract to the recipient, include: An NFC communication connection is established between the transferor and the recipient of the property. The transferor generates a first random number, the recipient generates a second random number, and a session key is generated based on the first and second random numbers. A smart contract data structure containing financial information is generated; the smart contract data structure is encrypted using the session key to obtain ciphertext data; and a message authentication code is generated based on the session key. The number of data fragments is determined based on the size of the smart contract data structure. The encrypted data is then fragmented and a message structure is generated using the NFC data exchange format. The message structure includes a fragment sequence number, record header information, and data payload. During transmission, each data fragment is checked using a CRC check. When a transmission error is detected, the current fragment sequence number is recorded and the data is retransmitted until the recipient of the property successfully receives all data fragments. The recipient of the funds uses the session key to verify the message authentication code, and after successful verification, decrypts the data to obtain the smart contract data structure.

3. The method according to claim 1, characterized in that, The steps of isolating handover data from other application data in a trusted execution environment, generating a signature key based on device hardware characteristics and storing the signature key in the secure storage area of ​​the trusted execution environment, generating an tamper-proof signature using the signature key, and combining the tamper-proof signature with the handover data to form an tamper-proof handover credential include: After receiving the handover request, the recipient of the property imports the handover data into a trusted execution environment through a security monitoring instruction. In the trusted execution environment, an independent virtual address space is allocated for the handover data and access control permissions are set to achieve isolation from other application data. The device hardware circuit response signal is acquired, and the response signal is XORed with the environmental noise signal to obtain the device hardware feature value. The bit flipping characteristic is obtained by sampling the device hardware feature value multiple times. An error correction code is constructed based on the bit flipping characteristic to locate and correct errors, and a stable feature value is obtained by repeatability testing. The stable feature value is concatenated with the device's unique identification information to obtain the signature key. An encryption key is generated in the trusted execution environment. The signature key is encrypted using the encryption key to obtain key ciphertext. The integrity check value of the key ciphertext is calculated. The key ciphertext and the integrity check value are written into the secure storage area of ​​the trusted execution environment. The hash value of the handover data is calculated based on the signature key and encrypted to generate an tamper-proof signature; the tamper-proof signature is combined with the handover data to form an tamper-proof handover certificate.

4. The method according to claim 3, characterized in that, The steps include obtaining bit-flipping characteristics by sampling the hardware feature values ​​of the device multiple times, constructing error-correcting codes based on the bit-flipping characteristics for error localization and correction, and obtaining stable feature values ​​through repeatability testing: The number of times each bit of the device hardware feature value is flipped in multiple samplings is counted, the flip probability of each bit is calculated based on the number of flips, and the unstable bits that need to be corrected are determined based on the flip probability. The error correction capability of the error correction code is determined based on the number of unstable bits. The minimum Hamming distance is calculated based on the error correction capability. Galois field parameters are selected based on the minimum Hamming distance to generate a parity check matrix. The device hardware feature values ​​are encoded using the check matrix to obtain check codewords, the check vector of the check codewords is calculated, and the error location polynomial is obtained based on the check vector. The error location in the device hardware feature value is determined according to the error location polynomial, an error pattern corresponding to the error location is generated, and the error pattern is XORed with the device hardware feature value to obtain the correction feature value. The correction feature value is subjected to multiple repeatability tests, and the stability index of the feature value is calculated based on the test results. When the stability index exceeds a preset threshold, the correction feature value is determined as a stable feature value.

5. The method according to claim 1, characterized in that, The steps for the transferor and the recipient of the property to sequentially verify the tamper-proof handover certificate with digital signatures include: The recipient of the property generates a first digital signature on the tamper-proof handover certificate, and combines the first digital signature with the tamper-proof handover certificate to form a first signature data packet; the transferor of the property verifies the first digital signature, and generates verification confirmation information upon successful verification. The transferring party generates a second digital signature for the tamper-proof handover certificate and the verification confirmation information, and combines the second digital signature with the tamper-proof handover certificate and the verification confirmation information to form a second signature data packet; the receiving party verifies the second digital signature; The transferor and the recipient of the property respectively store complete signature records containing the first signature data packet and the second signature data packet, and calculate the hash value of the complete signature record as an on-chain index identifier for writing the complete signature record into the blockchain network.

6. The method according to claim 1, characterized in that, After the transferor and recipient of the assets reconnect to the blockchain network, the step of calculating the dynamic priority of data uploading to the blockchain based on the current congestion index of the blockchain network, the value of the assets, and timeliness requirements includes: The ratio of the number of pending transactions to the transaction pool capacity in the blockchain network is used as the transaction pool depth. The block confirmation delay time is obtained, and the network congestion index is calculated based on the transaction pool depth and the block confirmation delay time. Obtain the market valuation of the asset corresponding to the data to be uploaded to the blockchain and the deadline for data upload to the blockchain. Calculate the asset value based on the market valuation and calculate the time sensitivity based on the deadline using an exponential decay function. The network congestion index, the value of the property, and the time sensitivity are normalized to obtain normalized parameters. Obtain the predicted priority and actual priority from historical transaction data to construct a mean squared error optimization objective function, solve the mean squared error optimization objective function to obtain dynamic weight coefficients that satisfy the constraint that the sum of the weights is one and that each weight is a non-negative number; The predicted data on-chain priority is calculated based on the normalization parameters and the dynamic weight coefficients; the actual data on-chain priority is obtained, and the difference between the predicted data on-chain priority and the actual data on-chain priority is calculated to obtain the prediction error; the gradient value of the dynamic weight coefficients is calculated based on the prediction error, and the dynamic weight coefficients are updated based on a preset learning rate for calculating the on-chain priority of subsequent data to be on-chain.

7. The method according to claim 6, characterized in that, The steps for constructing the mean squared error optimization objective function by obtaining the predicted priority and actual priority from historical transaction data include: The historical network congestion index is calculated by obtaining the transaction pool depth and block confirmation delay time corresponding to each transaction record in the historical transaction data; the temporal fluctuation variance of the historical network congestion index is calculated in each block generation cycle, and the abrupt change point of the temporal fluctuation variance is detected as the load partition boundary to divide the historical transaction data into multiple load partitions. The squared difference between the predicted priority and the actual priority in the historical transaction data of each load partition is calculated to obtain the transaction throughput in each load partition. The partition weighted mean square error is constructed based on the product of the squared difference and the transaction throughput. The number of times each load partition is converted to other load partitions in the historical transaction data is calculated. The number of conversions is divided by the number of times the corresponding load partition appears to obtain the partition conversion probability. Obtain the current network congestion index, determine the current load partition by comparing the fluctuation variance of the current network congestion index with the load partition boundary, and determine the load partition with the highest conversion probability to the current load partition as the target load partition based on the partition conversion probability. A mean squared error optimization objective function is constructed based on the partition weighted mean squared error of the current load partition and the partition weighted mean squared error of the target load partition.

8. A blockchain-based offline transfer traceability and tamper-proof management system for assets, used to implement the method of any one of claims 1-7, characterized in that, include: The first unit is used to obtain the identity information of the transferor and the recipient of the property, and to generate a smart contract in the blockchain network. An offline connection is established between the transferor and the recipient of the property via Near Field Communication (NFC), and the transferor sends a handover request containing the smart contract to the recipient. The second unit is used to isolate the handover data from other application data in a trusted execution environment after the property recipient receives the handover request, generate a signature key based on the device hardware feature value and store the signature key in the secure storage area of ​​the trusted execution environment, generate an anti-tamper signature using the signature key, and combine the anti-tamper signature with the handover data to form an anti-tamper handover certificate. The third unit is used for the transferor and the recipient of the property to sequentially verify the tamper-proof handover certificate with digital signatures. The fourth unit is used to calculate the dynamic priority of data uploading to the blockchain network based on the current congestion index of the blockchain network, the value of the property, and the timeliness requirements after the transferor and recipient of the property reconnect to the blockchain network; and to write the tamper-proof handover certificate and digital signature information to the blockchain network in batches according to the dynamic priority. The fifth unit is used to obtain the tamper-proof handover certificate and digital signature information for verification when it is necessary to trace the property handover record, and generate a property handover traceability report.

9. An electronic device, characterized in that, include: processor; Memory used to store processor-executable instructions; The processor is configured to invoke instructions stored in the memory to execute the method according to any one of claims 1 to 7.

10. A computer-readable storage medium having computer program instructions stored thereon, characterized in that, When the computer program instructions are executed by the processor, they implement the method described in any one of claims 1 to 7.

Images