Mineral supply chain settlement bill multi-version consistency control method based on block chain

Abstract

The invention discloses a mineral supply chain settlement bill multi-version consistency control method based on a block chain. The method comprises the following steps: constructing a bill global state model on a chain for a settlement bill; performing state management on the bill according to a bill global state model through an intelligent contract on the block chain, receiving an operation request of a participating node, updating the model after consensus verification, and forming an ordered version chain; based on the updated bill global state model, synchronizing bill states among participating nodes, and enabling each node to independently verify the consistency of the bill states; when a dispute occurs in bill circulation, freezing state updating through the smart contract, performing arbitration based on the version chain to generate a new version, and recovering circulation; the version information is verified when the state is updated through the smart contract to prevent concurrent conflicts, and a bill history tracing function is provided for each node. According to the invention, the full-process credible tracing and efficient cooperation of the full life cycle of the mineral supply chain settlement bill are realized.

Description

Technical Field

[0001] This invention belongs to the interdisciplinary field of computer information technology and supply chain finance, and in particular relates to a blockchain-based method for controlling the consistency of multi-version settlement invoices in the mineral supply chain. Background Technology

[0002] With the accelerating globalization and digitalization of the mineral resource supply chain, the process from ore extraction to final sale involves collaboration among multiple entities, including mining companies, transportation companies, warehousing centers, smelters, traders, and financial institutions. Billing data at each stage flows through heterogeneous systems such as ERP, MES, WMS, and TMS, involving multiple fields related to payment terms, grade, weight, and exchange rates. In actual operation, although the settlement process for a particular batch of ore progresses linearly between nodes, the constantly changing business environment—for example, market price fluctuations triggering revaluation requiring repeated confirmation at each node—leads to frequent updates to the settlement billing version.

[0003] Under the current settlement system, a common strategy is to build a centralized, unified settlement invoice file version management platform. The settlement system needs to request settlement invoice files from this platform to complete the settlement tasks at each node. However, this centralized version management mechanism only focuses on file version iteration and data consistency maintenance, failing to effectively improve the flexibility, autonomy, and data collaboration capabilities of the settlement scenario. Especially in the context of today's increasingly flexible and dynamic internet marketing models, settlement invoices need to be real-time, reliable, and traceable, and adapt to the technical requirements of multiple versions coexisting and distributed collaborative processing. In summary, existing mineral supply chain invoice management systems mainly have the following key problems: 1. Multi-node bill version conflict: Each participating party, such as the transporter adjusting freight rates, the smelter updating grade data, and the clearing party modifying international ore prices independently, can easily lead to version forks and data inconsistencies. 2. Insufficient end-to-end traceability: Lack of a reliable tracking mechanism for the entire lifecycle of statement of account, from generation, modification, confirmation to reconciliation; 3. Centralized architecture poses trust risks: Relying on a single central database, it is susceptible to single points of failure such as data tampering and synchronization delays; 4. Difficulty in cross-border collaborative data alignment: Due to cross-border compliance requirements and time zone differences, the efficiency of bill synchronization between nodes is low and the delay is significant.

[0004] Therefore, there is an urgent need for a distributed control method that can achieve consensus verification of billing versions, automatic traceability, and trusted collaboration among heterogeneous systems of multiple enterprises, in order to ensure the uniformity and reliability of the entire billing process in the mineral supply chain. Summary of the Invention

[0005] To address the aforementioned technical challenges, this invention provides a blockchain-based method for controlling the consistency of multi-version settlement invoices in a mineral supply chain. It introduces blockchain consortium blockchain technology into the existing settlement system and, leveraging a distributed consensus protocol, constructs a distributed settlement invoice consistency control mechanism for multiple nodes. By utilizing blockchain's distributed management capabilities for the global state, a collaborative architecture centered on the global invoice state is established across heterogeneous systems, enabling consistent management of multiple invoice versions, reliable sharing of settlement results, and multi-scenario business collaboration.

[0006] This invention provides a blockchain-based method for controlling the consistency of multi-version settlement invoices in a mineral supply chain, comprising the following steps: To settle billing, build an on-chain global state model for billing, which uniquely identifies the bill version and binds it to an off-chain file; Through smart contracts on the blockchain, the state of the bill is managed according to the global state model of the bill, operation requests from participating nodes are received, the model is updated after consensus verification, and an ordered version chain is formed. Based on the updated global billing state model, the billing state is synchronized among participating nodes, and each node can independently verify the consistency of the billing state. When a dispute arises during the billing process, the smart contract updates the frozen state and arbitrates based on the version chain to generate a new version, thus resuming the process. The smart contract verifies version information during state updates to prevent concurrent conflicts and provides each node with a billing history tracing function based on the version chain.

[0007] Optionally, constructing an on-chain global state model for settlement invoices specifically includes: When a bill is generated, the initiating node determines the core metadata and writes it into the blockchain ledger, establishing a global state model of the on-chain bill that uniquely identifies the bill version and is bound to the off-chain file. The core metadata includes at least the bill identifier, version number, previous version hash, current bill content hash, state identifier, multi-party signature list, timestamp, and off-chain file index information.

[0008] Optionally, the step of managing the state of the bill through a smart contract on the blockchain based on the global state model of the bill specifically includes: The smart contract provides interfaces for creating bills, modifying bills, approving bills, initiating disputes, resolving disputes, and confirming bill settlement. Each participating node initiates an operation by calling the corresponding interface, and the smart contract executes the logic and triggers the consensus process; Once consensus is reached, a new global state record is generated as a new version of the bill and updated to the blockchain ledger.

[0009] Optionally, enabling each node to independently verify the consistency of the billing status specifically includes: After obtaining the latest global state record of the bill, the node backtracks along the version chain to verify the continuity of the links between versions based on the previous version hash contained therein. Verify whether the hash of the off-chain file recorded in the current global state record is consistent with the actual hash value of the corresponding file obtained locally by the node.

[0010] Optionally, when a dispute arises regarding the billing process, the process is restored by updating the frozen state of the smart contract and arbitrating based on the version chain to generate a new version, specifically including: The arbitration node obtains the complete on-chain version record of the disputed invoice; A point set is constructed using the timestamps and version numbers of each version as coordinates, and key versions in the version evolution are identified by calculating the convex hull. Based on the latest key version, generate a new version corresponding to the arbitration decision, and point the previous version hash of the new version to the hash of the key version; The new version corresponding to the arbitration resolution is written into the ledger after being verified by the blockchain network consensus, and the status identifier of the global state model of the bill is updated to be valid to resume circulation.

[0011] Optionally, verifying version information during state updates via the smart contract to prevent concurrent conflicts specifically includes: When a node initiates a modification request, it must submit the desired version number when calling the smart contract; The smart contract compares the desired version number with the latest version number recorded on the chain; The modification is performed and a new state record with an incrementing version number is generated only if the two are consistent.

[0012] Optionally, providing each node with billing history tracing functionality based on the version chain specifically includes: Any node can obtain the current global state record of a specified bill by querying the blockchain; Based on the previous version hash field in the record, the global status record of all historical versions of the bill can be retrieved sequentially.

[0013] Optionally, the blockchain is a consortium blockchain that employs a Byzantine fault-tolerant consensus mechanism.

[0014] On the other hand, the present invention also provides an electronic device including a memory, a processor, and a computing program stored in the memory and executable on the processor, wherein the processor implements the method when executing the computing program.

[0015] On the other hand, the present invention also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the method.

[0016] Compared with the prior art, the present invention has the following advantages and technical effects: This invention introduces consortium blockchain technology and constructs a global state model for invoices, storing core metadata of invoices on the blockchain and using smart contracts to automate business processes and achieve multi-node collaborative verification. Based on the immutability, distributed consensus mechanism, and hash chain structure of blockchain, it achieves multi-version strong consistency control, full-process trusted traceability, and efficient collaboration throughout the entire lifecycle of settlement invoices in the mineral supply chain. This effectively solves the problems of version conflicts, traceability difficulties, high trust costs, and low efficiency of cross-border collaboration in existing centralized systems. Attached Figure Description

[0017] The accompanying drawings, which form part of this application, are used to provide a further understanding of this application. The illustrative embodiments and descriptions of this application are used to explain this application and do not constitute an undue limitation of this application. In the drawings: Figure 1 This is a schematic diagram of the method flow according to an embodiment of the present invention. Detailed Implementation

[0018] It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other. This application will now be described in detail with reference to the accompanying drawings and embodiments.

[0019] It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions, and although a logical order is shown in the flowchart, in some cases the steps shown or described may be executed in a different order than that shown here.

[0020] Example 1 This embodiment provides a blockchain-based method for controlling the consistency of multi-version settlement invoices in a mineral supply chain, including the following steps: To settle billing, build an on-chain global state model for billing, which uniquely identifies the bill version and binds it to an off-chain file; Through smart contracts on the blockchain, the state of the bill is managed according to the global state model of the bill, operation requests from participating nodes are received, the model is updated after consensus verification, and an ordered version chain is formed. Based on the updated global billing state model, the billing state is synchronized among participating nodes, and each node can independently verify the consistency of the billing state. When a dispute arises during the billing process, the smart contract updates the frozen state and arbitrates based on the version chain to generate a new version, thus resuming the process. The smart contract verifies version information during state updates to prevent concurrent conflicts and provides each node with a billing history tracing function based on the version chain.

[0021] This feasible embodiment designs a Global Ledger State (GLS) model to write the core metadata of the bill (bill number, version number, state hash, multi-party signatures, timestamp, off-chain file index, etc.) into the consortium blockchain ledger, and uses smart contracts to automatically complete the processes of bill creation, revision, verification, dispute freezing, and settlement confirmation. This method balances the privacy protection of bill content with version traceability, forming a two-layer trusted billing system that "records the state on-chain and stores the original text off-chain".

[0022] The feasible approach to building an on-chain global state model for billing settlement specifically includes: When a bill is generated, the initiating node determines the core metadata and writes it into the blockchain ledger, establishing a global state model of the on-chain bill that uniquely identifies the bill version and is bound to the off-chain file. The core metadata includes at least the bill identifier, version number, previous version hash, current bill content hash, state identifier, multi-party signature list, timestamp, and off-chain file index information.

[0023] As a feasible implementation method, each invoice establishes a unique global state on the blockchain upon generation. The state structure includes an invoice identifier, version number, previous version hash (PrevHash), current invoice content hash (StateHash), state identifier (Created, InTransit, Received, Assayed, Settled, etc.), a list of multi-party signatures, a timestamp, and off-chain file index information. Modifications, confirmations, disputes, and settlements of the invoice will all generate new state versions, and all states form a version chain in hash pointer order.

[0024] Off-chain storage contains large amounts of data such as invoices, lab reports, and shipping documents. The off-chain and on-chain storage are linked by hash values ​​to ensure consistency between the off-chain and on-chain records. If an off-chain file is tampered with, its hash will not match the on-chain record, and the system will automatically detect this.

[0025] Implementable, the aforementioned management of the bill's state through smart contracts on the blockchain, based on the global bill state model, specifically includes: The smart contract provides interfaces for creating, modifying, approving, initiating, resolving, and confirming bill settlements. Each participating node initiates operations by calling the corresponding interface, the smart contract executes the logic, and triggers the consensus process. After consensus is reached, a new global state record is generated as a new version of the bill and updated to the blockchain ledger.

[0026] As a feasible implementation method, the system uses a contract interface to create and update invoices, with the main functions including: Create a bill: Create an initial version of the bill and put it on the blockchain; Bill modification: A bill modification proposal is initiated by the relevant party; Approval of bills: Bill updates are approved by other nodes; Initiating a dispute: Initiating the bill dispute freezing process; Dispute resolution: The arbitration node determines the outcome and generates a new version. Bill Settlement: Bill settlement is completed and confirmed on the blockchain.

[0027] All operations must be verified through PBFT consensus before being written into the blockchain ledger.

[0028] Implementable methods that enable each node to independently verify the consistency of billing status specifically include: After obtaining the latest global state record of the bill, the node backtracks along the version chain to verify the continuity of the links between versions based on the previous version hash contained therein; it also verifies whether the off-chain file hash recorded in the current global state record is consistent with the actual hash value of the corresponding file obtained locally by the node.

[0029] As a feasible implementation method, when the bill status is updated, all parties, including mining nodes (MN), transportation nodes (TN), storage nodes (WN), smelting nodes (RN), and trading nodes (SN), can obtain the latest status through the on-chain interface and independently verify the bill file hash, signature, and version chain to ensure that the bill status of each node is consistent.

[0030] The verification includes: consistency of version chain hashes; validity of digital signatures from all parties; existence of PBFT consensus results; and hash matching of off-chain files.

[0031] In practice, when a dispute arises during the billing process, the process can be restored by updating the frozen state of the smart contract and arbitrating based on the version chain to generate a new version, specifically including: Arbitration nodes obtain all on-chain version records of disputed bills; construct a point set using the timestamps and version numbers of each version as coordinates, and identify key versions in the version evolution by calculating the convex hull; based on the latest key version, generate a new version corresponding to the arbitration resolution, and point the hash of the previous version of the new version to the hash of the key version; after the new version corresponding to the arbitration resolution is verified by the blockchain network consensus, it is written into the ledger, and the state identifier of the global state model of the bill is updated to be valid to resume circulation.

[0032] As a feasible implementation method, when a dispute arises regarding the bill (such as a difference in grade or weight exceeding a threshold), a node can initiate a freeze request via contract, and the system will automatically halt settlement. Arbitration nodes or auditing institutions can make a ruling based on the on-chain bill version and off-chain evidence documents, and generate a new bill status version to resume circulation.

[0033] Implementable measures include verifying version information during state updates via the smart contract to prevent concurrent conflicts, specifically including: When a node initiates a modification request, it must submit the desired version number when calling the smart contract. The smart contract compares the desired version number with the latest version number recorded on the chain. Only when the two match will the modification be executed and a new state record with an incrementing version number be generated.

[0034] Furthermore, providing each node with a billing history tracing function based on the version chain specifically includes: Any node can obtain the current global state record of a specified bill by querying the blockchain; based on the previous version hash field in the record, it can sequentially retrieve the global state records of all historical versions of the bill.

[0035] As a feasible implementation, each bill modification requires submitting the desired version number in the contract. If a higher version already exists on the chain, the modification fails, thus preventing concurrent conflicts. Any node can trace back the history through the bill version chain to verify the source, time, and signatories of each modification.

[0036] It is feasible that the blockchain is a consortium blockchain that adopts a Byzantine fault-tolerant consensus mechanism.

[0037] This embodiment can achieve the following significant beneficial effects: Achieving strong consistency control: Through the distributed consensus of the blockchain and the version chain based on hash pointers, it is ensured that the bill state seen by all participating nodes at any time is unique and consistent, fundamentally solving the problems of multi-node version conflicts and data inconsistency.

[0038] Enhancing data credibility and traceability: Key metadata of invoices is anchored through an immutable on-chain global state model and bidirectionally bound to off-chain file hashes, establishing a trusted traceability chain throughout the entire lifecycle of the invoice. Any tampering with off-chain files can be easily detected.

[0039] Enhanced automation and trust in business collaboration: Smart contracts encode business rules (such as modification, approval, settlement, and dispute resolution) into automatically executed code, reducing human intervention and trust costs. Dispute arbitration is conducted based on an objective, consensus-recognized on-chain version of the blockchain, improving arbitration efficiency and fairness.

[0040] Optimizing system reliability and flexibility: The decentralized consortium blockchain architecture avoids the single point of failure and data tampering risks of centralized systems. At the same time, the two-layer model of "on-chain state + off-chain original data" takes into account data privacy and auditing requirements. The system can flexibly adapt to complex multi-party collaboration scenarios in the mining supply chain, especially in cross-border and cross-time zone businesses, providing efficient and reliable data synchronization and collaboration capabilities.

[0041] Example 2 The overall architecture of this embodiment is as follows: Figure 1 As shown, its core is a consortium blockchain consensus layer employing a Byzantine fault-tolerant consensus mechanism (such as PBFT), forming a trusted foundation for data collaboration. Around this consensus layer, business nodes at each stage of the mineral supply chain are connected: the mining billing node (MN) is responsible for generating and submitting the initial bill; the transportation settlement node (TN) proposes revisions based on actual transport data; the warehousing verification node (WN) verifies arrival data in conjunction with the warehousing system; the smelting accounting node (RN) reviews and revises weight and grade; the trade settlement node (SN) confirms the final settlement terms; the financial clearing node (FN) anchors the clearing status in read-only mode; and the regulatory audit node (AN) is granted read-only permissions for full-process auditing. The off-chain service system stores the original billing file (A1-An) and the verified new file (At), and binds it to the global state (SA) recorded on the chain through hash values, thus forming a two-layer trusted collaborative system of "on-chain consensus state, off-chain storage of the original text," supporting the traceable, tamper-proof, and consistent flow of bills across multiple nodes.

[0042] The method proposed in this embodiment specifically includes the following steps: (1) such as Figure 1As shown, in the actual production and operation process of the mineral supply chain industry, the accounting system continuously generates and outputs ore billing files for each batch (such as the original bill A1.xlsx), which include: batch / weight / moisture content / grade / unit price / freight terms, etc. Then, the bill hash H1=SM3(A1.xlsx) and other global state fields are calculated. Subsequently, the global state SA of the new bill is uploaded to the blockchain by the MN node using the bill creation interface, and other nodes are notified via events that a new bill is available.

[0043] (2) Taking the storage verification node as an example, when new ore arrives at the storage verification node, or when a new bill needs to be recalculated due to changes in the bills of other nodes, the global status record SA of the specified batch of ore is obtained from the chain.

[0044] (3) Obtain the corresponding original bills A1-An from the off-chain accounting system based on SA, calculate the local hashes H_local1-H_localn for each bill, and pass if the hash values ​​are consistent with the on-chain state. If there is a discrepancy, it means that the original bill situation is incorrect, and it is necessary to call the dispute initiation interface to raise a dispute.

[0045] The feasible process of initiating a dispute by calling the dispute initiation interface includes: During the bill lifecycle, when a node initiates a dispute through a smart contract, the system freezes the bill status; after the arbitration node intervenes, it extracts all relevant version statuses recorded on the chain and constructs a set of version points in a two-dimensional coordinate system with the timestamp of each version as the horizontal axis and the version number as the vertical axis. The convex hull algorithm is performed on the constructed version point set to calculate the convex hull vertices of the point set. The bill versions corresponding to these convex hull vertices are identified as key versions, representing indispensable turning points in the bill state evolution path. Based on the identified key version, the arbitration node adjudicates and generates a new arbitration version state; the previous version hash of the new state is set to the hash value of the highest convex hull vertex version calculated in the above steps, thereby tracing the version chain back from the disputed branch and linking it to the most recent key version, forming a simplified new version chain confirmed by arbitration. The generated arbitration version status is verified through distributed consensus and then written into the blockchain ledger, thus unfreezing the bill status.

[0046] (4) After confirming that the original bill is correct, the warehouse verification system will store the ore in the warehouse according to the actual situation and generate a new verified original bill file At.

[0047] (5) The warehouse verification system hands over the updated bill status to the warehouse verification node WN. WN calculates the new global status record and calls the bill modification interface to transmit the new version of the global status record of the bill to the chain.

[0048] (6) Wait for other nodes to use the approval bill interface to verify the new global state record on the warehouse verification node WN and return a verification success notification to WN.

[0049] (7) The warehouse verification system delivers the new bill file At to the off-chain accounting system for storage.

[0050] Steps (2)-(7) are consistent for other participating nodes in the system. The only difference between different nodes is in their own business logic processing. The steps for obtaining, modifying, and verifying the global status record of the bill are completely consistent. In this way...

[0051] On the other hand, this embodiment also provides an electronic device, including a memory, a processor, and a computing program stored in the memory and executable on the processor, wherein the processor implements the method when executing the computing program.

[0052] On the other hand, this embodiment also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the method.

[0053] The above are merely preferred embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A blockchain-based method for multi-version consistency control of settlement invoices in a mineral supply chain, characterized in that, Includes the following steps: To settle billing, build an on-chain global state model for billing, which uniquely identifies the bill version and binds it to an off-chain file; Through smart contracts on the blockchain, the state of the bill is managed according to the global state model of the bill, operation requests from participating nodes are received, the model is updated after consensus verification, and an ordered version chain is formed. Based on the updated global billing state model, the billing state is synchronized among participating nodes, and each node can independently verify the consistency of the billing state. When a dispute arises during the billing process, the smart contract updates the frozen state and arbitrates based on the version chain to generate a new version, thus resuming the process. The smart contract verifies version information during state updates to prevent concurrent conflicts and provides each node with a billing history tracing function based on the version chain.

2. The method according to claim 1, characterized in that, Building an on-chain global state model for billing settlement specifically includes: When a bill is generated, the initiating node determines the core metadata and writes it into the blockchain ledger, establishing a global state model of the on-chain bill that uniquely identifies the bill version and is bound to the off-chain file. The core metadata includes at least the bill identifier, version number, previous version hash, current bill content hash, state identifier, multi-party signature list, timestamp, and off-chain file index information.

3. The method according to claim 1, characterized in that, The process of managing the state of the bill through a smart contract on the blockchain, based on the global state model of the bill, specifically includes: The smart contract provides interfaces for creating bills, modifying bills, approving bills, initiating disputes, resolving disputes, and confirming bill settlement. Each participating node initiates an operation by calling the corresponding interface, and the smart contract executes the logic and triggers the consensus process; Once consensus is reached, a new global state record is generated as a new version of the bill and updated to the blockchain ledger.

4. The method according to claim 1, characterized in that, Enabling each node to independently verify the consistency of the bill status specifically includes: After obtaining the latest global state record of the bill, the node backtracks along the version chain to verify the continuity of the links between versions based on the previous version hash contained therein. Verify whether the hash of the off-chain file recorded in the current global state record is consistent with the actual hash value of the corresponding file obtained locally by the node.

5. The method according to claim 1, characterized in that, When a dispute arises during the billing process, the smart contract freezes the status update and arbitrates based on the version chain to generate a new version, thus restoring the process. Specifically, this includes: The arbitration node obtains the complete on-chain version record of the disputed invoice; A point set is constructed using the timestamps and version numbers of each version as coordinates, and key versions in the version evolution are identified by calculating the convex hull. Based on the latest key version, generate a new version corresponding to the arbitration decision, and point the previous version hash of the new version to the hash of the key version; The new version corresponding to the arbitration resolution is written into the ledger after being verified by the blockchain network consensus, and the status identifier of the global state model of the bill is updated to be valid to resume circulation.

6. The method according to claim 1, characterized in that, To prevent concurrent conflicts, the smart contract verifies version information during state updates, specifically by including: When a node initiates a modification request, it must submit the desired version number when calling the smart contract; The smart contract compares the desired version number with the latest version number recorded on the chain; The modification is performed and a new state record with an incrementing version number is generated only if the two are consistent.

7. The method according to claim 6, characterized in that, Providing each node with the ability to trace billing history based on the version chain specifically includes: Any node can obtain the current global state record of a specified bill by querying the blockchain; Based on the previous version hash field in the record, the global status record of all historical versions of the bill can be retrieved sequentially.

8. The method according to claim 1, characterized in that, The blockchain in question is a consortium blockchain that employs a Byzantine fault-tolerant consensus mechanism.

9. An electronic device comprising a memory, a processor, and a computing program stored in the memory and executable on the processor, characterized in that, When the processor executes the computing program, it implements the method of any one of claims 1-8.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the method of any one of claims 1-8.

Images