Bank sensitive operation log non-tampering auditing method based on block chain

Abstract

The invention discloses a block chain-based bank sensitive operation log non-tampering auditing method. The method comprises the steps that sensitive operation logs of all business systems of a bank are captured in real time, and standardized preprocessing is carried out; 2, constructing a private block chain network to realize tamper-proof storage and automatic verification of logs; and providing a visual auditing tool and an automatic alarm mechanism to query the visual display operation chain according to the combination condition, and triggering a corresponding alarm response action according to the alarm mechanism. Through private block chain technology innovation, an efficient, safe and compliant solution is provided for integrity management of sensitive operation logs of banks, optimal balance among tamper-proofing, efficiency, compliance and cost is realized, an autonomous and controllable data security infrastructure is constructed for the bank industry, and the method has wide application value.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of blockchains, and in particular to a bank sensitive operation log tamper-proof auditing method based on a blockchain. BACKGROUND

[0002] Currently, banks generally use centralized databases to store operation logs and combine manual auditing or third-party evidence storage services for verification. However, the existing technology has the following significant defects: 1. Tampering risk: Traditional log management relies on centralized databases, and the storage and access permissions are concentrated in a few administrators. This architecture has many hidden dangers. First, internal personnel can easily abuse their powers, and administrators with high-level permissions can directly modify or delete logs. Second, once the database is hacked, attackers can delete or forge logs in bulk, rendering post-tracing ineffective.

[0003] 2. Inefficient tracing: The existing auditing process highly depends on manual operations, resulting in scattered multi-system logs. Specifically, each system in the bank operates independently, and the log formats and storage locations are different. When auditing, data needs to be manually exported from multiple databases and cross-compared, which is time-consuming and prone to false positives due to inconsistent data. In addition, third-party evidence has low credibility. Some banks store log hashes on third-party evidence platforms, but the centralized architecture has a single point of failure risk.

[0004] 3. Data silos: Different business system logs are stored in different places, and cross-department collaboration requires complex interfaces to interface, making it difficult to ensure data consistency.

[0005] 4. Insufficient technical adaptability: Existing solutions lack targeted design for the special needs of the banking industry.

[0006] To address the shortcomings of traditional centralized log systems, some technologies attempt to manage logs using blockchains, but there are still problems: 1. Low consensus efficiency Existing technologies use the PBFT algorithm for consensus, but this algorithm is excessively redundant in the log auditing scenario, requiring all nodes to participate in multiple rounds of voting, resulting in high latency and low throughput.

[0007] 2. Poor multi-system compatibility In existing technologies, there are differences in the definition of "user operations" across different systems, leading to compatibility issues when multiple systems are connected simultaneously.

[0008] 3. Low alarm coverage In existing methods, auditing rules rely on manual deployment, with an alarm coverage rate of less than 40%, making it difficult to meet industry requirements. SUMMARY

[0009] The present application aims at the deficiencies existing in the prior art, and provides a bank sensitive operation log non-tamperable auditing method based on a blockchain.

[0010] To achieve the above-mentioned purpose, the present application provides a bank sensitive operation log non-tamperable auditing method based on a blockchain, comprising: Step 1, capturing sensitive operation logs of each business system of a bank in real time, and performing standardized preprocessing; Step 2, constructing a private blockchain network to realize tamper-proof storage and automatic verification of the logs; Step 3, providing a visual auditing tool and an automatic alarm mechanism to visually display the operation chain according to a combined condition query and trigger corresponding alarm response actions according to the alarm mechanism.

[0011] Further, the sensitive operation logs of each business system of the bank comprise: Account management type: balance adjustment, account state change, customer information modification; Permission control type: user role promotion / demotion, access policy update, API key generation / cancellation; System configuration type: firewall rule modification, database table structure change, service start / stop operation.

[0012] Further, the standardized preprocessing mode is to convert the collected sensitive operation logs into a unified JSON format, and to attach a digital signature and a hash chain type associated field, which is specifically as follows: {global unique operation ID, operator identity, operation type, operation object identifier, state before operation, state after operation, operation time, previous log hash value, operator private key signature}.

[0013] Further, the private blockchain network adopts sharding channel isolation, and stores operation logs in independent channels according to business types to limit access by unauthorized departments; each channel has an independent blockchain ledger, and the ledgers of different channels are stored in independent directories in the node local, wherein the transaction logs are only visible to the participants in the channel, and the key-value pair storage is only allowed to read and write in the channel; multiple channels reuse the same smart contract, and the smart contract instance of each channel runs in an independent Docker container, so that the states are isolated from each other.

[0014] Further, in the private blockchain network, the audit nodes are deployed in the independent machine room of the audit department, and adopt dual-machine hot standby and trusted execution environment; the business nodes are deployed in the servers where each business system is located, and the business nodes in the same channel synchronize the states through the Gossip protocol; the regulatory nodes are connected through the transmission layer security protocol encryption API, and only support querying specific channel logs, and the sensitive fields are displayed in the desensitization form.

[0015] Further, the consensus mechanism of the private blockchain network is as follows: The roles are classified into primary verifiers and secondary verifiers, wherein the primary verifiers are borne by the audit nodes and are responsible for preliminary verification of logs and generation of block proposals, and the secondary verifiers are borne by the business nodes and are responsible for checking the proposals without complete execution of the smart contract; Further, the primary verifier packs the logs in a time period into a block to reduce the consensus frequency.

[0016] Further, the block comprises a block header and a block body, the block header comprises a block number, a timestamp, an audit node signature, a Merkle root hash and a previous block hash.

[0017] Further, after the audit node generates the block, the block is broadcast to all business nodes through a gRPC protocol, each business node locally stores a full amount of ledger, and an incremental backup is generated to a disaster recovery center at a preset time interval; sensitive data is only permanently stored as a hash value on the chain, original data is stored in an off-chain database after encryption, and after the data expires, the data is destroyed according to the data sensitivity level, wherein highly sensitive data is physically destroyed, and other cases are logically destroyed.

[0018] Beneficial effects: the private blockchain technology innovation provides an efficient, safe and compliant solution for the integrity management of bank sensitive operation logs, and has the following significant advantages: 1. Automatic triggering mechanism of sensitive operation audit rules based on smart contract The smart contract is used to perform real-time signature verification and compliance rule checking, which effectively reduces the workload caused by the manual audit process. The audit period can be greatly reduced by supporting quick retrieval according to time, operation type, operator and the like. A large number of risk control rules are built in to effectively improve the abnormal event discovery rate.

[0019] 2. Log writing verification process based on multi-node role division and lightweight PBFT consensus optimization The traditional PBFT protocol is improved, the audit nodes are set as "primary verifiers" responsible for verifying logs and generating block proposals, and the business nodes are "secondary verifiers" only required to simply check the proposals without complete execution of the smart contract, thereby reducing the communication rounds between nodes. The logs in every 500ms are packed into a block to reduce the consensus frequency. Through the design, the throughput is improved by more than 40%, which is suitable for the high-frequency log scenario of banks.

[0020] 3. Judicial chain evidence storage The key audit result hash value is synchronized to the judicial alliance chain, realizes double evidence storage on and off the chain, and solves the pain point that electronic evidence is easy to be questioned. The original log and evidence hash are synchronized to multiple chains, and the enhancement of the legal evidence ability is realized.

[0021] The application realizes the optimal balance among tamper resistance, efficiency, compliance and cost through technical innovation, constructs a self-controllable data security infrastructure for the banking industry, and has wide application value. BRIEF DESCRIPTION OF DRAWINGS

[0022] Figure 1 is a system architecture diagram for implementing a bank sensitive operation log tamper-proof auditing method based on a blockchain; Figure 2 is a schematic diagram of resource reuse and isolation in a blockchain; Figure 3 is a network connection relationship diagram of various role nodes; Figure 4 is a log verification process schematic diagram of a smart contract; Figure 5 is a block structure schematic diagram of the embodiment of the application. DETAILED DESCRIPTION

[0023] The application will be further illustrated below in combination with the drawings and specific embodiments, and the embodiments are implemented on the premise of the technical scheme of the application, and it should be understood that the embodiments are only used to illustrate the application and not used to limit the scope of the application.

[0024] As shown in Figures 1 to 4 , the embodiment of the application provides a bank sensitive operation log tamper-proof auditing method based on a blockchain, which comprises: Step 1, real-time capture of sensitive operation logs of various business systems of a bank, and standardization preprocessing. For details, see Figure 1 , Figure 1 is a system architecture diagram for implementing the application. The above step 1 is completed by a data acquisition layer, and the data acquisition layer comprises three parts: a lightweight log agent, a data formatting module and a cache queue. The lightweight log agent is deployed in various business systems (such as a bank core system, a credit management system, etc.), and listens to operation events through a Hook mechanism or a database trigger. The data formatting module converts the original log into a unified JSON format, and adds a digital signature and a hash chain type associated field. The cache queue uses Kafka to temporarily store the log, so as to cope with a high-concurrency writing scene.

[0025] Step 2, a private block chain network is constructed to realize tamper-proof storage and automatic verification of the log. The above step 2 is completed by a block chain network layer, and the core components of the block chain network layer include a multi-role node, an intelligent contract execution engine and a consensus module. The role node includes 1 audit node and N business nodes and a supervision node. The audit node is independently controlled by the bank audit department, has full account book access permission, is responsible for block generation and consensus; the business node is deployed on the server of each business department, can only submit the log of the department, and has no modification account book permission; the supervision node is deployed in an external supervision agency, and only reads specific channel data through a RESTFul API. The intelligent contract execution engine is used to execute the log verification rules, such as signature verification, operation compliance check and the like. The consensus module adopts an improved practical Byzantine fault tolerance algorithm (PBFT, Practical Byzantine Fault Tolerance), and optimizes communication efficiency.

[0026] Step 3, a visual audit tool and an automatic alarm mechanism are provided to visually display the operation chain according to the combined condition query and trigger the corresponding alarm response action according to the alarm mechanism. The above step 3 is completed by an audit application layer, and the core components of the audit application layer include a multi-dimensional query interface, a rule engine and a record storage module. Among them, the multi-dimensional query interface supports a series of combined condition retrieval logs according to time range, operation type, executor ID and the like. The rule engine has built-in audit rules (such as'more than 3 times of permission change of the same user in a day, then alarm'). The role of the record storage module is to synchronize the hash value of the key audit result to the judicial alliance chain.

[0027] The sensitive operation logs of the above bank business systems include: Account management type: balance adjustment, account state change, customer information modification; Permission control type: user role upgrade, access strategy update, API key generation / cancellation; System configuration type: firewall rule modification, database table structure change, service start / stop operation.

[0028] The application adopts JSON Schema to define a unified log structure, which is as follows: {global unique operation ID, operation person identity, operation type, operation object identifier, operation before state, operation after state, operation time, previous log hash value, operation person private key signature}.

[0029] The data signature and chain connection method of the application are as follows: (1) Signature mechanism: The operator uses a private key in a hardware security module (HSM) to sign the log through the SM2 algorithm (256 bits) to ensure that the identity is not repudiated.

[0030] (2) Hash chain construction: The pre_hash field of each log points to the hash value of the previous log, forming an irreversible chain structure. If any log is tampered with, all subsequent log hash values will be invalid, making it easy to check whether tampering has occurred.

[0031] The blockchain in the embodiment of the application is Hyperledger Fabric 2.5, which is as follows: (1) Channel division The embodiment of the application adopts a sharded channel isolation method, divides independent channels according to business types (such as account management, credit approval, and permission control), stores operation logs in the channels, and limits access by unauthorized departments. In addition, high-sensitive data (such as user privacy) is stored in a special channel, and low-sensitive data is stored in a shared channel, so as to balance efficiency and privacy.

[0032] (2) Reuse and isolation of node resources and smart contracts In terms of node resource reuse, a single node can join multiple channels. In terms of node resource isolation, each channel has an independent blockchain ledger, and the ledgers of different channels are stored in independent directories in the node. The transaction log is only visible to participants in the channel, and the key-value pair storage (LevelDB) only allows the channel to read and write. For smart contracts, the same smart contract can be reused in multiple channels, and the smart contract instance of each channel runs in an independent Docker container, so that the states are isolated from each other.

[0033] For details, see Figure 2 The nodes of channel X cannot access the ledger (including historical transactions and current state) of channel Y, even if they belong to the same organization. The nodes need to explicitly join the channel to access its data. For example, node 1 can join both channel X and channel Y, but the two ledgers are physically isolated.

[0034] For details, see Figure 3 , Figure 3The network connection relationship between the various role nodes is shown. The audit node is deployed in the independent machine room of the audit department, and adopts dual-machine hot backup and trusted execution environment (SGX, Software Guard Extensions). Its permissions include unique block generation right (responsible for packaging logs into new blocks, and distributing the blocks), full-channel data access (can audit all logs across channels), and smart contract upgrade permission (contract deployment and contract code update). The audit node adopts 1 main 2 backup mode, uses Raft consensus inside to ensure high availability, and uses bidirectional gRPC for communication. The business node is deployed in the server where each business system is located (such as the core system server, the credit system server, etc.), and can be horizontally expanded. The business nodes in the same channel synchronize the state through the Gossip protocol. The business node can only submit logs to the specified channel (such as the credit system node can only write to the credit operation channel), and cannot read data of other channels, which is to prevent information leakage. In addition, the node certificate and access policy are managed through the membership service provider (MSP, Membership Service Provider) to realize node access control and improve the security of the private chain. The regulatory node connects through the transport layer security protocol (TLS, Transport Layer Security) encrypted API, and can only query the logs of a specific channel (such as regulatory agency A can access the anti-money laundering channel). Sensitive fields (such as customer identity card number, mobile phone number, etc.) are displayed in a desensitized form, which is to meet the privacy compliance requirements.

[0035] Compared with the traditional PBFT protocol, the consensus mechanism of the private block chain network of the embodiment of the application is as follows: (1) The roles are classified into primary validators and secondary validators. The primary validators are assumed by the audit nodes, which are responsible for preliminary verification of logs and generation of block proposals. The secondary validators are business nodes, which only need to perform simple verification (such as verifying the validity of the signature) on the proposal and do not need to execute the smart contract completely.

[0036] (2) Batch processing: logs within a certain time (such as 500 ms) are packaged into a block, reducing the consensus frequency. In a 10-node network, the improved consensus delay is reduced from 120 ms to 70 ms, and the throughput can be increased to 2500 TPS.

[0037] The log chaining and verification process is as follows: (1) Proxy listening: the business system captures database operations (such as MySQL Binlog), API calls (such as RESTful interface), and system events (such as Linux audit log) through the Fluentd proxy.

[0038] (2) Data desensitization: Partially mask sensitive fields (such as bank card number, mobile phone number, etc.) (such as "622363******1234", "136****5566"), and then calculate and store the hash value.

[0039] (3) Signature and caching: The log broker calls HSM to generate a signature and sends the log to Kafka, waiting to be uploaded to the chain.

[0040] The logic for log verification in the smart contract in this application is as follows: Figure 4 As shown, it includes five steps: format verification, uniqueness verification, signature verification, compliance verification, and hash chain verification. Details are as follows: (1) Format validation Check if the logs conform to the log structure defined by JSON Schema.

[0041] (2) Uniqueness check Verifying the global uniqueness of operation IDs aims to prevent replay attacks. Each channel maintains a strictly incrementing Nonce counter; new transactions must contain a Nonce value that is one greater than the previous transaction. Upon receiving a transaction, the audit node compares it against the Nonce of each channel. If Nonce = last_nonce + 1, the transaction is executed; if Nonce ≤ last_nonce, it is discarded; if Nonce > last_nonce + 1, it is an out-of-order transaction and is cached.

[0042] (3) Signature verification The signature verification process obtains the operator's public key from the bank's Identity and Access Management System (IAM) and uses the national cryptographic algorithm SM2 to verify the matching between the signature and the log content.

[0043] (4) Compliance verification The pre-defined rules engine is invoked to obtain the corresponding pre-defined rules based on the operation type, and each rule is verified to ensure compliance requirements are met.

[0044] (5) Hash chain verification The hash value of the current log is calculated using the SM3 algorithm (256-bit), and the pre_hash is verified to be consistent with the hash value of the previous log. If the verification passes, the log is marked as "verified" and pushed to the audit node to generate a block. If the verification fails, the log is stored in the isolation zone, triggering an alert and notifying the security team.

[0045] The specific methods for generating and storing blocks in this embodiment of the invention are as follows: (1) Block structure The block structure consists of a block header and a block body. The block header includes the block number, timestamp, audit node signature, Merkle root hash, and the hash of the previous block, etc. See also... Figure 5 , Figure 5 The block structure is illustrated. This method specifies that the block body stores a maximum of 200 raw data entries of verified logs.

[0046] (2) Distributed storage After the audit node generates a block, it broadcasts it to all business nodes via the gRPC protocol. Each node stores the full ledger locally and generates incremental backups to an off-site disaster recovery center every preset time interval (e.g., 24 hours). Furthermore, to comply with financial data governance requirements, sensitive data (such as user identity information) is only permanently stored as hash values ​​on the blockchain; the original data is encrypted and stored in an off-chain database for a period of 3 years. After the data expires, it is destroyed according to its sensitivity level: highly sensitive data is physically destroyed, and other data is logically destroyed.

[0047] This invention supports multi-dimensional audit queries, and auditors can perform the following operations through a web interface or API: (1) Condition filtering: Combined queries such as "All permission change operations performed by operator 23010101 from March 3 to 7, 2025".

[0048] (2) Association analysis: Visualize the operation chain (such as user A's permission change → account B's balance modification → transfer to external account).

[0049] (3) Evidence export: Generate a PDF report containing log details, associated block hash values ​​and electronic signatures of audit nodes.

[0050] In this embodiment of the invention, the rule engine pre-configures necessary alarm rules, while also allowing administrators to customize alarm rules and edit them online. The structure of the alarm rules is as follows: R = (Operation type, time window, executor category, expected behavior pattern, violation response strategy).

[0051] (2) Rule type Frequency-based rules: For example, "The balance of the same account changes more than 5 times within 1 hour".

[0052] Related rules: For example, "A large transfer occurs within 30 minutes after the permission change".

[0053] Blacklist / whitelist rules: For example, "Prohibit database deletion operations from non-specific IP addresses".

[0054] (3) Response action Primary alert: Send email / SMS notification to auditors.

[0055] Advanced response: Automatically freeze accounts, suspend API services, or isolate suspicious nodes.

[0056] When audit results involve legal disputes, key evidence such as hash values, timestamps, and signature information from relevant logs can be extracted from the system. Subsequently, the evidence hash values ​​are written to the judicial consortium blockchain via smart contracts to obtain judicial timestamp authentication. In litigation, banks can present local logs and judicial blockchain-stored evidence records to verify hash consistency and confirm that the evidence has not been tampered with.

[0057] For example, a suspected insider incident occurred at a city commercial bank where an account access privilege was illegally escalated. Administrator Zhang attempted to change customer Wang's ordinary deposit account privileges to a "VIP large-amount exemption account" to bypass the risk control system and conduct illegal transfers. This embodiment demonstrates how the method of this invention can intercept and trace this operation in real time.

[0058] Implementation steps: 1. Operation Triggering and Log Capture (1) Operation execution Zhang entered and executed SQL commands in the backend of the core system: UPDATE acct_privilege SET acct_level='VIP' WHERE account_id='ZM123456'; (2) Log collection a. Proxy listening: The Fluentd proxy deployed on the database server captures the SQL statement and context information (execution IP: 10.0.0.33, time: 2025-05-11 07:15:22).

[0059] b. Data anonymization: Mask the account ID “ZM123456” to generate “ZM****56” and then calculate the SM3 hash value.

[0060] c. Log formatting: Generate standardized JSON logs and attach Zhang's SM2 signature.

[0061] 2. Log on-chain verification and smart contract verification (1) Submit to the blockchain network The core system business nodes push logs to the "account management channel," triggering the smart contract to execute the following verification: a. Signature verification: Obtain Zhang's public key from the IAM system and verify the validity of the signature (verification result: passed).

[0062] b. Compliance check: The associated OA system finds that the operation has no approval record (rule: permission change operation needs department supervisor approval). And the operation time (7 am) exceeds the compliance window (rule: sensitive operation is only allowed to be executed during 9:00-18:00 on weekdays). Finally, check if the pre_hash matches the previous log hash (result: match).

[0063] (2) Consensus and block generation The smart contract determines that the operation violates two compliance rules, i.e. no approval record and operation time exceeds the compliance window, so it is marked as "high risk". The audit node refuses to generate a block and stores the log in the isolation area, triggering the alarm mechanism.

[0064] 3. Real-time alarm and emergency disposal The system automatically sends an alarm SMS to the audit supervisor: "Emergency alarm: Account ZM****56 has violated the right to change on 2025-05-11 07:15:22, operator Zhang, IP 10.0.0.33". At the same time, the bank's risk control system synchronously freezes Wang's account, preventing abnormal fund flow.

[0065] 4. Audit traceability and evidence solidification (1) Blockchain query Audit personnel input conditions through Web interface: "Time range 2025-05-11 07:00-08:00, operator Zhang", and retrieve the log details, including: desensitized original SQL statement; comparison of account permission status before and after operation (normal -> VIP); associated block hash (0x56b1b3...) and audit node signature.

[0066] (2) Judicial evidence The system automatically extracts log key fields (operation ID, timestamp, hash value, etc.), writes the hash value into the "judicial evidence chain" through the cross-chain smart contract, and obtains the evidence number: SF202505110001.

[0067] 5. After-treatment (1) Internal accountability The audit department retrieves OA logs and VPN login records to confirm that Zhang used illegal IP to violate the operation at non-working hours, and initiates the discipline review procedure.

[0068] (2) Legal evidence The bank submits local logs and judicial chain evidence records to the court, verifies the hash consistency, confirms that the evidence has not been tampered with, and Zhang's behavior is judged illegal. Implementation effect

[0069] 1. Risk interception timeliness: the whole process from operation to account freezing takes less than 10 seconds, avoiding potential loss of funds.

[0070] 2. Audit traceability efficiency: the whole process takes less than 10 minutes, which is more than 90% more efficient than traditional manual audit.

[0071] The above is only the preferred embodiment of the present application, it should be noted that for those skilled in the art, other parts not specifically described belong to the prior art or common knowledge. Without departing from the principles of the present application, a number of improvements and refinements can also be made, which should be considered as the protection scope of the present application.

Claims

1. A blockchain-based method for tamper-proof auditing of sensitive bank operation logs, characterized in that, include: Step 1: Capture sensitive operation logs from various bank business systems in real time and perform standardized preprocessing; Step 2: Build a private blockchain network to achieve tamper-proof storage and automated verification of logs; Step 3: Provide visual auditing tools and automated alarm mechanisms to query and visualize the operation chain based on combined conditions, and trigger corresponding alarm response actions according to the alarm mechanism.

2. The blockchain-based method for tamper-proof auditing of sensitive bank operation logs according to claim 1, characterized in that, The sensitive operation logs of the various business systems of the bank include: Account management: Balance adjustment, account status change, customer information modification; Access control: User role promotion / demotion, access policy update, API key generation / revocation; System configuration: Firewall rule modification, database table structure change, service start / stop operations.

3. The blockchain-based method for tamper-proof auditing of sensitive bank operation logs according to claim 1, characterized in that, The standardized preprocessing method involves converting the collected sensitive operation logs into a unified JSON format and attaching digital signatures and hash chain association fields, as detailed below: {Globally unique operation ID, operator identity, operation type, operation object identifier, state before operation, state after operation, operation time, hash value of the previous log entry, operator's private key signature}.

4. The blockchain-based method for tamper-proof auditing of sensitive bank operation logs according to claim 1, characterized in that, The private blockchain network employs sharded channel isolation and divides operation logs into independent channels according to business type, restricting access to unauthorized departments. Each channel has an independent blockchain ledger, and the ledgers of different channels are stored in independent directories on the node's local machine. Transaction logs are only visible to participants in the current channel, and key-value pairs are only allowed to be read and written by the current channel. Multiple channels reuse the same smart contract, and the smart contract instance of each channel runs in an independent Docker container, ensuring that the states are isolated from each other.

5. The blockchain-based method for tamper-proof auditing of sensitive bank operation logs according to claim 4, characterized in that, In the private blockchain network, audit nodes are deployed in the audit department's independent data center, employing dual-machine hot standby and a trusted execution environment; business nodes are deployed on the servers of each business system, and business nodes within the same channel synchronize their status via the Gossip protocol; regulatory nodes connect via encrypted APIs using transport layer security protocols and only support querying logs from specific channels, with sensitive fields displayed in an anonymized form.

6. The blockchain-based method for tamper-proof auditing of sensitive bank operation logs according to claim 5, characterized in that, The consensus mechanism of the private blockchain network is as follows: The roles are divided into primary validators and secondary validators. The primary validator is the audit node, which is responsible for the initial verification of logs and the generation of block proposals. The secondary validator is the business node, which is responsible for verifying the proposals and does not need to fully execute the smart contract.

7. A blockchain-based method for tamper-proof auditing of sensitive bank operation logs, as described in claim 6, is characterized in that... The primary validator packages logs within a set time period into a block to reduce the frequency of consensus.

8. A blockchain-based method for tamper-proof auditing of sensitive bank operation logs according to claim 6, characterized in that, The block includes a block header and a block body. The block header includes the block number, timestamp, audit node signature, Merkle root hash, and previous block hash.

9. A blockchain-based method for tamper-proof auditing of sensitive bank operation logs, as described in claim 6, is characterized in that... After the audit node generates a block, it is broadcast to all business nodes via the gRPC protocol. Each business node stores the full ledger locally and generates incremental backups to the off-site disaster recovery center at preset time intervals. Sensitive data is only permanently stored on-chain as hash values. The original data is encrypted and stored in an off-chain database. After the data expires, it is destroyed according to its sensitivity level. Highly sensitive data is physically destroyed, while other data is logically destroyed.

Images