Blockchain-based log generation method, device, and storage medium

Abstract

The application relates to the field of information security and discloses a log generation method and device based on a block chain and a storage medium. The method comprises the following steps: assigning a serial number to a log addition request; reading a forward hash value from a preset local block chain; performing construction processing on the forward hash value and the serial number to generate addition metadata; writing the addition metadata into the local block chain to generate a chain-up abstract, and writing the chain-up abstract into a preset waiting queue; performing conversion construction processing on the chain-up abstract to generate a Merkle tree data abstract; performing record anchoring processing on the Merkle tree data abstract to generate a verification evidence package; receiving a log change request; performing verification processing on an unlocking parameter to generate a verification result; and adding change data corresponding to a target serial number in a block in the local block chain. In the embodiment of the application, the bandwidth and recording cost of the log transmission block chain are reduced, and the high-performance business demand is met without sacrificing the verifiability.

Description

Technical Field

[0001] This invention relates to the field of information security, and in particular to a method, device and storage medium for generating logs based on blockchain. Background Technology

[0002] In scenarios with high compliance requirements, such as clinical trials, chronic disease screening, and chronic disease management, the system needs to maintain complete operation logs, including information such as personnel, time, events, values, and remarks. Traditional audit logs are often stored in a single database, making them vulnerable to modification or deletion by personnel with administrator privileges or attackers, rendering the log data unreliable.

[0003] While blockchain offers immutability, its integration with existing business systems is complex due to its interconnectivity and privacy protection mechanisms. Furthermore, it struggles to handle "controlled change scenarios" (such as resetting certain states or lifting restrictions with regulatory approval). Existing public blockchains or large-scale blockchain platforms suffer from high integration costs, latency, and poor performance, making efficient integration with existing databases and logging systems difficult. Therefore, a solution is needed to address the current technical challenges of complex integration and high costs associated with public blockchains and logging systems. Summary of the Invention

[0004] The main objective of this invention is to solve the technical problems of complex integration and high cost of using current public blockchain and log recording systems.

[0005] The first aspect of this invention provides a blockchain-based log generation method, the blockchain-based log generation method comprising:

[0006] Receive a log add request and assign a sequence number to the log add request;

[0007] Read the forward hash value from the preset local blockchain;

[0008] According to the preset serialization rules, the forward hash value and the sequence number are constructed and processed to generate additional metadata;

[0009] The added metadata is written into the local blockchain, an on-chain summary is generated, and the on-chain summary is written into a preset waiting queue. The log addition event is also written into a preset audit event chain.

[0010] According to the preset conversion strategy, the on-chain digest in the waiting queue is converted and constructed to generate a Merkle tree data digest.

[0011] According to the preset public network anchoring algorithm, the Merkle tree data digest is recorded and anchored to generate a verification evidence package;

[0012] Receive a log change request, wherein the log change request includes: target serial number and unlock parameters;

[0013] Determine whether the time corresponding to the target sequence number is in a locked state;

[0014] When the device is in a locked state, the unlocking parameters are verified, and a verification result is generated.

[0015] Based on the verification results, new change data is added to the block corresponding to the target sequence number in the local blockchain, and the log change event is written into the preset audit event chain.

[0016] Optionally, in a first implementation of the first aspect of the present invention, the step of constructing and processing the forward hash value and the sequence number according to a preset serialization rule to generate added metadata includes:

[0017] Obtain target feature data;

[0018] According to a preset sequence sorting rule, the forward hash value, the sequence number, and the target feature data are sorted and concatenated to generate a concatenated string.

[0019] The pre-defined prefix string is appended to the concatenation string to generate the assembled string;

[0020] The assembled string is subjected to hash injection processing to generate additional metadata.

[0021] Optionally, in a second implementation of the first aspect of the present invention, the step of writing the added metadata into the local blockchain and generating an on-chain digest includes:

[0022] Using the mapping between the serial number and the added metadata as a retrieval index, the added metadata is written into the local blockchain to generate an on-chain summary.

[0023] Optionally, in a third implementation of the first aspect of the present invention, the step of transforming and constructing the on-chain digest in the waiting queue according to a preset transformation strategy to generate a Merkle tree data digest includes:

[0024] Based on a preset maximum interval duration or a preset maximum number of extractions, the data in the waiting queue is extracted in batches to obtain multiple on-chain summaries;

[0025] Extract the added metadata corresponding to a single on-chain digest from the multiple on-chain digests, write the added metadata into a preset leaf prefix constructor, and iterate through the constructor to generate a leaf hash array corresponding to multiple on-chain digests;

[0026] Based on the leaf hash array, a Merkle tree data digest is generated.

[0027] Optionally, in a fourth implementation of the first aspect of the present invention, the step of performing record anchoring processing on the Merkle tree data digest according to a preset public network anchoring algorithm to generate a verification evidence package includes:

[0028] The Merkle tree data digest is transmitted to an external timestamp server, and the timestamp token fed back by the timestamp server is received.

[0029] The Merkle tree data digest is transmitted to an external public blockchain, and on-chain data is received from the public blockchain.

[0030] A verification evidence package is generated based on the timestamp token and the on-chain data.

[0031] Optionally, in a fifth implementation of the first aspect of the present invention, the step of transmitting the Merkle tree data digest to an external timestamp server and receiving the timestamp token fed back by the timestamp server includes:

[0032] According to the preset RFC3161 specification, a message is constructed from the Merkle tree data digest to generate a request message;

[0033] The request message is sent to an external timestamp server, and the response data is received from the timestamp server.

[0034] Determine whether the response data matches the message imprint of the request message;

[0035] When they match, the timestamp token is extracted from the response data.

[0036] Optionally, in a sixth implementation of the first aspect of the present invention, the step of transmitting the Merkle tree data digest to an external public blockchain and receiving on-chain data fed back by the public blockchain includes:

[0037] The Merkle tree data digest is transmitted to an external public blockchain so that the public blockchain can sign and broadcast the transmission event;

[0038] When the number of block confirmations broadcast by the signature exceeds a preset confirmation threshold, the on-chain data fed back by the public blockchain is received.

[0039] Optionally, in a seventh implementation of the first aspect of the present invention, the steps of adding change data to the block corresponding to the target sequence number in the local blockchain based on the verification result, and writing the log change event into a preset audit event chain, include:

[0040] When the verification result is qualified, the log change request is marked as agreed to the modification status, the change data is added to the block corresponding to the target sequence number in the local blockchain, and the status of the log change request and the log change event are written into the preset audit event chain.

[0041] If the verification result is not qualified, the log change request is marked as unmodifiable, and the status of the log change request is written into the preset audit event chain.

[0042] A second aspect of the present invention provides a blockchain-based log generation device, comprising: a memory and at least one processor, wherein the memory stores instructions, and the memory and the at least one processor are interconnected via a circuit; the at least one processor invokes the instructions in the memory to cause the blockchain-based log generation device to execute the aforementioned blockchain-based log generation method.

[0043] A third aspect of the present invention provides a computer-readable storage medium storing instructions that, when executed on a computer, cause the computer to perform the above-described blockchain-based log generation method.

[0044] In this embodiment of the invention, by maintaining a high-throughput log chain and audit chain locally to meet performance requirements, Merkle tree data digests are constructed in batches and submitted to the public blockchain to generate verifiable digest data. The original data is still referenced locally according to a strategy, separating the verifiable digest from the local original data, and the audit chain records relevant transmission events. Compared to existing technologies that upload each log entry to a public or private blockchain, this solution significantly reduces bandwidth and recording costs. Furthermore, any record can be verified via the Merkle path, maintaining log verifiability. This meets high-performance business requirements without sacrificing verifiability, solving the technical problems of complex integration and high cost of current public blockchain and log recording systems. Attached Figure Description

[0045] Figure 1 This is a schematic diagram of one embodiment of the blockchain-based log generation method in this invention.

[0046] Figure 2 This is a schematic diagram of a specific embodiment of the 103 steps of the blockchain-based log generation method in this invention.

[0047] Figure 3 This is a schematic diagram of a specific embodiment of the 105 steps of the blockchain-based log generation method in this invention.

[0048] Figure 4 This is a schematic diagram of a specific embodiment of the 106 steps of the blockchain-based log generation method in this invention.

[0049] Figure 5 This is a schematic diagram of one embodiment of a blockchain-based log generation device according to the present invention. Detailed Implementation

[0050] This invention provides a method, device, and storage medium for generating logs based on blockchain.

[0051] The embodiments of the present invention will now be described in more detail with reference to the accompanying drawings. While some embodiments of the present invention are shown in the drawings, it should be understood that the present invention can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of the present disclosure. It should be understood that the accompanying drawings and embodiments are for illustrative purposes only and are not intended to limit the scope of protection of the present invention.

[0052] In the description of the embodiments disclosed in this invention, the term "comprising" and similar terms should be understood as open-ended inclusion, i.e., "including but not limited to". The term "based on" should be understood as "at least partially based on". The term "one embodiment" or "the embodiment" should be understood as "at least one embodiment". The terms "first", "second", etc., may refer to different or the same objects. Other explicit and implicit definitions may also be included below.

[0053] For ease of understanding, the specific process of the embodiments of the present invention is described below. Please refer to [link / reference]. Figure 1 One embodiment of the blockchain-based log generation method in this invention includes:

[0054] 101. Receive a log addition request and assign a sequence number to the log addition request;

[0055] In this embodiment, when the business system needs to record an operation event, the client or calling end submits a write request as a structured raw record. The structured raw record contains operator identifier, operation type, operation load, time lock metadata, etc.

[0056] The system calls the global sequence service to obtain a sequence number for the request, which serves as the identifier for the event's position in the global log. This sequence number is tightly bound to the write operation after its generation and is not reused by design to ensure the consistency and non-reversibility of the sequence.

[0057] 102. Read the forward hash value from the preset local blockchain;

[0058] In this embodiment, the system reads the hash value of the latest record from the index service as the forward hash value; if it is the first record and no forward hash value exists, an initial hash value, such as an all-zero string, is used as the forward hash value. The sequence number, forward hash value, operator identifier, operation type, timestamp (or server time if not provided by the caller), and the operation payload, standardized to a uniform field order and format, are combined to form a complete record. The existence of the forward hash value ensures the dependency of the record order; any overwriting or forgery of already written records will be detected in subsequent verifications.

[0059] 103. Based on the preset serialization rules, construct and process the forward hash value and the sequence number to generate additional metadata;

[0060] In this embodiment, the complete record is serialized, and the field order, numerical format, and date format are clearly defined to avoid hash inconsistencies caused by serialization differences between different implementations. The serialized string should include at least a forward hash value and a sequence number so that the block in the local blockchain can be retrieved later. The serialized string is hashed to generate a feedback hash value, which is then used as a unique fingerprint to upload the log add request log to the local blockchain.

[0061] Please see Figure 2 , Figure 2 This is a schematic diagram of a specific embodiment of step 103 of the blockchain-based log generation method in this invention. Step 103 includes the following specific implementation methods:

[0062] 1031. Obtain target feature data;

[0063] 1032. According to the preset sequence sorting rules, the forward hash value, the sequence number, and the target feature data are sorted and concatenated to generate a concatenated string;

[0064] 1033. Add the concatenation string to the preset prefix string to generate the assembled string;

[0065] 1034. Perform hash injection processing on the assembled string to generate additional metadata.

[0066] In steps 1031-1034, the target feature data is actually the record contained in the log addition request, including the operator identifier, operation type, timestamp, and operation payload (normalized to a uniform field order and format). The forward hash value, sequence number, operator identifier, operation type, timestamp, and operation payload (normalized to a uniform field order and format) are concatenated according to a preset sequence sorting rule to obtain the concatenated string.

[0067] Using a predefined prefix rule, such as a 0x00 prefix string, the serialized bytes are concatenated to generate an assembled string. The SHA-256 algorithm is then used to hash the assembled string, yielding a feedback hash value. This feedback hash value is written back into the original assembled string as its unique fingerprint, generating additional metadata. Sequence normalization and prefix strings are key engineering measures to ensure consistent hashing across multiple implementations.

[0068] 104. Write the added metadata into the local blockchain, generate an on-chain summary, write the on-chain summary into a preset waiting queue, and write the log addition event into a preset audit event chain;

[0069] In this embodiment, the standardized and serialized added metadata is written to the local blockchain to generate an on-chain digest. The mapping between the sequence number and the added metadata is registered in the index service to ensure that it can be retrieved and verified in sequence. The on-chain digest is written to a preset waiting queue for subsequent batch anchoring.

[0070] The write action itself is also written into the audit event chain, recording the writer, write time and feedback hash value, added metadata and other audit metadata; if the write fails, the sequence is kept unused by the defined rollback strategy, for example, the sequence number is marked as obsolete and only rolled back and not reused.

[0071] Specifically, step 104 includes the following specific implementation methods:

[0072] 1041. Using the mapping between the serial number and the added metadata as a retrieval index, the added metadata is written into the local blockchain to generate an on-chain summary.

[0073] In step 1041, the mapping between the serial number and the added metadata, or the mapping between the serial number and the feedback hash value in the added metadata, is used as a retrieval index. The added metadata is then written into the local blockchain to generate an on-chain summary.

[0074] 105. According to the preset conversion strategy, the on-chain digest in the waiting queue is converted and constructed to generate a Merkle tree data digest;

[0075] In this embodiment, the system retrieves records to be anchored from the waiting queue according to a predetermined strategy period or quantity threshold, constructs batch evidence, and generates a Merkle tree data summary.

[0076] For details, please refer to Figure 3 , Figure 3 This is a schematic diagram of a specific embodiment of step 105 of the blockchain-based log generation method in this invention. Step 105 includes the following specific implementation methods:

[0077] 1051. Based on the preset maximum interval duration or the preset maximum number of extractions, batch extract the data in the waiting queue to obtain multiple on-chain digests;

[0078] 1052. Extract the added metadata corresponding to a single on-chain digest from the multiple on-chain digests, write the added metadata into a preset leaf prefix construction, and traverse the construction to generate a leaf hash array corresponding to multiple on-chain digests;

[0079] 1053. Based on the leaf hash array, generate a Merkle tree data digest.

[0080] In steps 1051-1053, the system can trigger batch construction based on two strategies: one is based on the maximum number of records to be extracted, such as 100–1000 records per batch; the other is based on the maximum waiting time, such as a waiting period of 30–300 seconds, to trigger a batch extraction of data from the waiting queue. The purpose of the triggering strategy is to avoid long delays in external anchoring under low write rates. In practice, both strategies can coexist to meet throughput and latency requirements.

[0081] For each selected record, extract the added metadata corresponding to a single on-chain digest from multiple on-chain digests. Construct leafHash = SHA256(0x00 ||recordHashBytes) from the feedback hash value in the added metadata according to the leaf prefix convention. Form a leaf hash array in the popped order, keeping it consistent with the sequence number order, and record the start and end sequence numbers of this range as the index range of this batch.

[0082] The Merkle tree data is constructed based on the leaf hash array described above. Internal nodes use a node prefix, such as 0x01, and nodeHash is defined as SHA256(0x01 || leftChild || rightChild). If the number of leaf nodes is odd, the "copy the last leaf" or "zero-hash padding" rule is adopted according to the configuration. The construction result is a Merkle tree data digest and the proof path from each leaf to the root.

[0083] Finally, a unique batch identifier and operation metadata are generated. The operation metadata includes batch ID, sequence number range, Merkle tree data digest, leafHashe, creation time, etc. The operation metadata is saved to a preset operation space, and the proof path from each leaf to the root is saved to a preset proof storage space for future verification and playback.

[0084] 106. Based on the preset public network anchoring algorithm, record anchoring processing is performed on the Merkle tree data digest to generate a verification evidence package;

[0085] In this embodiment, according to the preset public network anchoring algorithm, the Merkle tree data digest is submitted to the trusted time proof service or broadcast on the public blockchain to form an undeniable time identifier, and the time identifier is assembled into a verification evidence package.

[0086] For details, please refer to Figure 4 , Figure 4 This is a schematic diagram of a specific embodiment of the 106 steps of the blockchain-based log generation method in this invention. The 106 steps include the following specific implementation methods:

[0087] 1061. Transmit the Merkle tree data digest to an external timestamp server and receive the timestamp token fed back by the timestamp server;

[0088] 1062. Transmit the Merkle tree data digest to an external public blockchain and receive on-chain data fed back by the public blockchain;

[0089] 1063. Generate a verification evidence package based on the timestamp token and the on-chain data.

[0090] In steps 1061-1063, the Merkle tree data digest is first transmitted to an external timestamp server. This timestamp server provides timestamp services, performs timestamp verification on the Merkle tree data digest, and then returns a timestamp token.

[0091] The Merkle tree data digest is then transmitted to an external public blockchain, where it is broadcast and signed within internal blocks, providing on-chain data with a time stamp.

[0092] A verification evidence package is generated by using on-chain data and timestamp tokens in parallel as time-based verification evidence.

[0093] Furthermore, step 1061 includes the following specific implementation methods:

[0094] 10611. Construct a message from the Merkle tree data digest according to the preset RFC3161 specification to generate a request message;

[0095] 10612. Send the request message to an external timestamp server and receive the response data from the timestamp server;

[0096] 10613. Determine whether the response data is consistent with the message imprint of the request message;

[0097] 10614. When they match, the timestamp token is extracted from the response data.

[0098] In steps 10611-10614, message imprinting is performed on the Merkle tree data digest, and a request message is constructed according to the RFC3161 specification. The system sends the request message to the pre-configured TSA server via the HTTPS protocol and receives the response data from the TSA server.

[0099] The message imprint of the verification response data matches that of the original request message, and the generation time and TSA issuer information are extracted from the response data. Subsequently, a timestamp token is extracted from the response data, and either the timestamp token or its base64 encoding is recorded in the verification evidence packet for future verification.

[0100] Furthermore, step 1062 includes the following specific implementation methods:

[0101] 10621. Transmit the Merkle tree data digest to an external public blockchain so that the public blockchain can sign and broadcast the transmission event;

[0102] 10622. When the number of block confirmations broadcast by the signature is greater than the preset confirmation threshold, the on-chain data fed back by the public blockchain is received.

[0103] In steps 10621-10622, the Merkle tree data digest is transmitted to an external public blockchain to construct a transaction containing the Merkle tree data digest. The public blockchain signs and broadcasts the transaction containing the Merkle tree data digest. The blockchain waits for the number of broadcast blocks to exceed a preset confirmation threshold. If 6 blocks confirm more than the 5 confirmation threshold, the public blockchain returns the on-chain data of transaction ID, block height, and block time, and saves the on-chain data as time verification evidence.

[0104] 107. Receive a log change request, wherein the log change request includes: target serial number and unlock parameters;

[0105] In this embodiment, to support regulatory scenarios involving "controlled changes," such as regulatory-permitted error correction, legitimate data entry, or unsealing required by regulations, a time-lock mechanism and a controlled unlocking approval process are designed. Time-lock definition and enforceability: When a record is written, the caller can set a time-lock attribute for that record. The time-lock attribute includes: UTC time, specified approval policy, and initial state. Before the UTC time expires, any modification, deletion, or overwriting of the record at the pre-defined service logic / interface layer is rejected. The firmware or service layer should ensure that it does not expose low-level interfaces that directly modify storage.

[0106] When receiving a log change request, which includes data such as the target sequence number and unlock parameters, multi-party signatures are required when correcting logs that are under time lock.

[0107] 108. Determine whether the time corresponding to the target sequence number is in a locked state;

[0108] In this embodiment, it is first determined whether the time corresponding to the target sequence number is in a locked state. If it is in a locked state, the log change request is considered to require approval signature collection. After signature approval, the unlocking process is performed. If it is not in a locked state, the log data is modified according to the log change request, and then the modified log is re-uploaded to the blockchain, and the modification record event is written into the audit event chain.

[0109] 109. When in a locked state, the unlocking parameters are verified to generate a verification result;

[0110] In this embodiment, if the device is in a locked state, an unlocking request is triggered. The unlocking parameters of the unlocking request include the target serial number, the applicant's identity, the reason, and the timestamp. These parameters are stored in the unlocked storage space and the audit log as a creation event, and a notification set of approvers is triggered simultaneously.

[0111] The approver digitally signs a standardized message containing fields such as request ID, sequence number, consenting person ID, and current time through their client. Upon receiving the signature, the system verifies it instantly, checking the signing certificate or public key reference, ensuring the signature time is within the allowed window to prevent replay, and saving the signature along with the consenting person ID. Only after collecting valid signatures from 3 to 5 consenting person IDs is the log change request considered legitimate, generating a valid verification result.

[0112] 110. Based on the verification results, add change data to the block corresponding to the target sequence number in the local blockchain, and write the log change event into the preset audit event chain.

[0113] In this embodiment, when the verification result is satisfactory, a new change data record is written to the block corresponding to the target sequence number in the local blockchain without directly modifying the original record. This change data record explicitly indicates the changes made to the original record, such as adding fields, comments, correction values, or reversal instructions. The change data record is also added to the anchoring queue to participate in the next anchoring of the Merkle tree data digest. The original record remains immutable, and all approval evidence signature sets, approval times, and approver identifiers are simultaneously written as log change events into the preset audit event chain.

[0114] Specifically, step 110 includes the following specific implementation methods:

[0115] 1101. When the verification result is qualified, the log change request is marked as agreed to the modification status, the change data is added to the block corresponding to the target sequence number in the local blockchain, and the status of the log change request and the log change event are written into the preset audit event chain.

[0116] 1102. When the verification result is not qualified, the log change request is marked as unmodifiable, and the status of the log change request is written into the preset audit event chain.

[0117] In steps 1101-1102, when the verification result is satisfactory, the log change request is marked as approved for modification. Without directly modifying the original record, a new change data record is written to the block corresponding to the target sequence number on the local blockchain. This change data record explicitly indicates the changes made to the original record, such as adding fields, comments, correction values, or reversal instructions. The change data record is also added to the anchoring queue to participate in the next anchoring of the Merkle tree data digest. The original record remains immutable, and all approval evidence signature sets, approval times, and approver identifiers are simultaneously written as log change events into the preset audit event chain.

[0118] When the verification result is unqualified, there are two possible outcomes: automatic expiration or rejection. If a log change request arrives and has already expired without pending approval, the log change request status is automatically set to EXPIRED / UNLOCKED according to the policy. EXPIRED / UNLOCKED is one type of unmodifiable status. If the log change request is rejected or signature verification fails, the reason for rejection is saved and the log change request is marked as REJECTED. REJECTED is one type of unmodifiable status, and all status change data is written to the audit event chain.

[0119] The approval process and the final modification result are both hashed and anchored as independent events to ensure the complete traceability of the change process.

[0120] In this embodiment of the invention, by maintaining a high-throughput log chain and audit chain locally to meet performance requirements, Merkle tree data digests are constructed in batches and submitted to the public blockchain to generate verifiable digest data. The original data is still referenced locally according to a strategy, separating the verifiable digest from the local original data, and the audit chain records relevant transmission events. Compared to existing technologies that upload each log entry to a public or private blockchain, this solution significantly reduces bandwidth and transaction costs. Furthermore, any record can be verified through the Merkle path, maintaining log verifiability. This meets high-performance business requirements without sacrificing verifiability, solving the technical problems of complex integration and high cost of current public blockchain and log recording systems.

[0121] Figure 5 This is a schematic diagram of the structure of a blockchain-based log generation device 500 provided in an embodiment of the present invention. The blockchain-based log generation device 500 can vary significantly due to different configurations or performance. It may include one or more central processing units (CPUs) 510 (e.g., one or more processors) and a memory 520, and one or more storage media 530 (e.g., one or more mass storage devices) for storing applications 533 or data 532. The memory 520 and storage media 530 can be temporary or persistent storage. The program stored in the storage media 530 may include one or more modules (not shown in the diagram), each module may include a series of instruction operations on the blockchain-based log generation device 500. Furthermore, the processor 510 may be configured to communicate with the storage media 530 and execute the series of instruction operations in the storage media 530 on the blockchain-based log generation device 500.

[0122] The blockchain-based log generation device 500 may also include one or more power supplies 540, one or more wired or wireless network interfaces 550, one or more input / output interfaces 560, and / or one or more operating systems 531, such as Windows Server, Mac OS X, Unix, Linux, FreeBSD, etc. Those skilled in the art will understand that... Figure 5 The illustrated blockchain-based log generation device structure does not constitute a limitation on blockchain-based log generation devices, which may include more or fewer components than illustrated, or combine certain components, or have different component arrangements.

[0123] The present invention also provides a computer-readable storage medium, which can be a non-volatile computer-readable storage medium or a volatile computer-readable storage medium, wherein the computer-readable storage medium stores instructions that, when the instructions are executed on a computer, cause the computer to perform the steps of the blockchain-based log generation method.

[0124] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0125] Furthermore, although the operations are described in a specific order, this should be understood as requiring that such operations be performed in the specific order shown or in sequential order, or requiring that all illustrated operations be performed to achieve the desired result. In certain environments, multitasking and parallel processing may be advantageous. Similarly, although several specific implementation details are included in the above discussion, these should not be construed as limiting the scope of this disclosure. Certain features described in the context of individual embodiments may also be implemented in combination in a single implementation. Conversely, various features described in the context of a single implementation may also be implemented individually or in any suitable sub-combination in multiple implementations.

[0126] Although the subject matter has been described using language specific to structural features and / or methodological logic, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or actions described above. Rather, the specific features and actions described above are merely illustrative examples of implementing the claims.

Claims

1. A blockchain-based log generation method, characterized in that, Including the following steps: Receive a log add request and assign a sequence number to the log add request; Read the forward hash value from the preset local blockchain; According to the preset serialization rules, the forward hash value and the sequence number are constructed and processed to generate additional metadata; The added metadata is written into the local blockchain, an on-chain summary is generated, and the on-chain summary is written into a preset waiting queue. The log addition event is also written into a preset audit event chain. According to the preset conversion strategy, the on-chain digest in the waiting queue is converted and constructed to generate a Merkle tree data digest. According to the preset public network anchoring algorithm, the Merkle tree data digest is recorded and anchored to generate a verification evidence package; Receive a log change request, wherein the log change request includes: target serial number and unlock parameters; Determine whether the time corresponding to the target sequence number is in a locked state; When the device is in a locked state, the unlocking parameters are verified, and a verification result is generated. Based on the verification results, new change data is added to the block corresponding to the target sequence number in the local blockchain, and the log change event is written into the preset audit event chain; The step of recording and anchoring the Merkle tree data digest according to a preset public network anchoring algorithm to generate a verification evidence package includes: The Merkle tree data digest is transmitted to an external timestamp server, and the timestamp token fed back by the timestamp server is received. The Merkle tree data digest is transmitted to an external public blockchain, and on-chain data is received from the public blockchain. Based on the timestamp token and the on-chain data, a verification evidence package is generated; The steps of adding change data to the block corresponding to the target sequence number in the local blockchain based on the verification result, and writing the log change event into the preset audit event chain, include: When the verification result is qualified, the log change request is marked as agreed to the modification status, the change data is added to the block corresponding to the target sequence number in the local blockchain, and the status of the log change request and the log change event are written into the preset audit event chain. If the verification result is not qualified, the log change request is marked as unmodifiable, and the status of the log change request is written into the preset audit event chain.

2. The blockchain-based log generation method according to claim 1, characterized in that, The step of constructing and processing the forward hash value and the sequence number according to the preset serialization rules to generate added metadata includes: Obtain target feature data; According to a preset sequence sorting rule, the forward hash value, the sequence number, and the target feature data are sorted and concatenated to generate a concatenated string. The pre-defined prefix string is appended to the concatenation string to generate the assembled string; The assembled string is subjected to hash injection processing to generate additional metadata.

3. The blockchain-based log generation method according to claim 1, characterized in that, The step of writing the added metadata into the local blockchain and generating an on-chain summary includes: Using the mapping between the serial number and the added metadata as a retrieval index, the added metadata is written into the local blockchain to generate an on-chain summary.

4. The blockchain-based log generation method according to claim 1, characterized in that, The step of transforming and constructing the on-chain digests in the waiting queue according to a preset transformation strategy to generate a Merkle tree data digest includes: Based on a preset maximum interval duration or a preset maximum number of extractions, the data in the waiting queue is extracted in batches to obtain multiple on-chain summaries; Extract the added metadata corresponding to a single on-chain digest from the multiple on-chain digests, write the added metadata into a preset leaf prefix constructor, and iterate through the constructor to generate a leaf hash array corresponding to multiple on-chain digests; Based on the leaf hash array, a Merkle tree data digest is generated.

5. The blockchain-based log generation method according to claim 1, characterized in that, The step of transmitting the Merkle tree data digest to an external timestamp server and receiving the timestamp token returned by the timestamp server includes: According to the preset RFC3161 specification, a message is constructed from the Merkle tree data digest to generate a request message; The request message is sent to an external timestamp server, and the response data is received from the timestamp server. Determine whether the response data matches the message imprint of the request message; When they match, the timestamp token is extracted from the response data.

6. The blockchain-based log generation method according to claim 1, characterized in that, The steps of transmitting the Merkle tree data digest to an external public blockchain and receiving on-chain data fed back from the public blockchain include: The Merkle tree data digest is transmitted to an external public blockchain so that the public blockchain can sign and broadcast the transmission event; When the number of block confirmations broadcast by the signature exceeds a preset confirmation threshold, the on-chain data fed back by the public blockchain is received.

7. A blockchain-based log generation device, characterized in that, The blockchain-based log generation device includes: a memory and at least one processor, wherein the memory stores instructions, and the memory and the at least one processor are interconnected via a line; The at least one processor invokes the instructions in the memory to cause the blockchain-based log generation device to execute the blockchain-based log generation method as described in any one of claims 1-6.

8. A computer-readable storage medium storing a computer program thereon, characterized in that, When the computer program is executed by a processor, it implements the blockchain-based log generation method as described in any one of claims 1-6.

Images