A method and system for digitizing beef cattle transactions

Abstract

The application discloses a kind of digitalization beef transaction method and system, through preposition EDI standard and public XML mode, semantic level standardization is carried out to the multi-source heterogeneous traceability data;Sensitive field is calculated cryptography commitment and is generated with commitment as public input zero-knowledge compliance proof;With "target identification ‖ link type ‖ record commitment" hash as element and preposition deterministic link anchor point, build life cycle cryptography accumulator, give constant size member proof to chain record, give non-member proof to missing link anchor point, realize the cryptography binding of compliance and integrity;Rely on performance and data compliance double-channel Beta-Bernoulli posterior, combine subjective logic output comprehensive trust image with uncertainty;With double-threshold access smart contract, drive delivery, settlement and right confirmation automation, form reputation and traceability double closed loop, realize privacy protection, integrity verifiable digitalization beef transaction.

Description

Technical Field

[0001] This invention relates to the field of digital transaction technology for agricultural and livestock products, specifically to a digital beef cattle transaction method and system based on blockchain, cryptographic accumulator, zero-knowledge proof, and Bayesian reputation model. Background Technology

[0002] In the livestock product trading sector, traditional transactions primarily rely on offline distribution markets or intermediaries, with both parties confirming ownership and settling accounts through on-site inspections and paper documents. In recent years, electronic trading platforms have largely adopted centralized databases to uniformly store transaction orders and member information, using the platform's credit as a guarantee for all parties. In livestock product traceability scenarios, a common practice is for the platform to define a unified interface, with each farm, slaughterhouse, and logistics provider reporting data on breeding, quarantine, and distribution. The platform then links this data to transaction orders, allowing buyers to query associated traceability records before placing an order. Transaction settlement and fulfillment status are determined by the platform's backend logic and triggered manually or semi-automatically.

[0003] The most relevant prior art to this invention is a type of livestock trading system based on a centralized platform with external traceability records: the system is operated by a platform operator with a centralized database, multiple parties report traceability data according to the platform's defined interface, and the platform stores these data in association with transaction orders; traceability verification relies on the platform's internal comparison of associated records, transaction confirmation and performance determination rely on the platform's backend logic, and the credit of the parties is given by the platform based on a comprehensive score based on historical records.

[0004] However, the aforementioned existing technologies have the following two types of technical problems:

[0005] Technical Issue 1: The multiple parties involved in the transaction use heterogeneous information systems, and the field definitions, encoding rules, and message formats of the reported data are inconsistent, requiring extensive customization and adaptation on the platform side. At the same time, breeding costs, formulas, and complete quarantine records are considered the commercial privacy of the parties. The parties are caught in a dilemma between "not reporting makes traceability unreliable, while reporting raw data exposes privacy," resulting in either missing traceability data or data obtained at the expense of privacy, making it difficult to guarantee credibility.

[0006] Technical Issue 2: Transaction process data and traceability data are centrally stored in the platform's database, lacking a mechanism to prevent tampering and ensure integrity that can be independently verified by any third party; it is difficult to mathematically prove and locate whether a single record has been tampered with afterward or whether a record of a certain essential link in the lifecycle has been selectively omitted; the credit score of the main entity is an opaque single value, which is prone to misjudgment of new entrants and entities with sparse evidence, and it is difficult to resist score manipulation, and transaction access and risk control lack rigorous basis. Summary of the Invention

[0007] The purpose of this invention is to provide a digital beef cattle trading method and system to solve the technical problems in the prior art, such as the heavy burden of standardization and adaptation of multi-source heterogeneous data, the difficulty in balancing traceability privacy protection and credibility, the lack of anti-tampering and integrity mechanisms that can be independently verified by any third party, and the opaque and easily manipulated credit assessment.

[0008] The first aspect of this invention provides a digital beef cattle trading method, comprising the following steps:

[0009] It receives original messages submitted by multiple entities through heterogeneous information systems, parses business semantic fields according to the preset EDI standard and maps them to the public XML schema, converts them into standardized data objects, and collects them into standardized traceability datasets according to the identification of beef cattle.

[0010] For the sensitive fields in the standardized traceability dataset, cryptographic commitments are calculated, and zero-knowledge proofs are generated that use the commitments as public inputs to prove that the original data satisfies the pre-defined compliance assertions, thus obtaining a standardized traceability dataset with commitments and compliance proofs.

[0011] Based on the standardized traceability dataset with commitment and compliance proof, a lifecycle accumulator commitment and witness are generated, and the on-chain verification entry of the lifecycle accumulator commitment and each zero-knowledge proof is written into the blockchain ledger. Membership proof is given for on-chain records, and non-member proof is given for missing link anchors, so as to obtain the transaction chain integrity verifiable conclusion that compliance and integrity are bound by the commitment.

[0012] Based on the verifiable conclusion of the transaction chain integrity, digital certificate identity authentication is performed on all parties to obtain a trusted on-chain identity. Beta-Bernoulli post-verification evidence for the performance channel and the data compliance channel is maintained according to their performance results and data compliance verification status. The trust expectation and uncertainty of each channel are calculated according to subjective logic, and after filtering out abnormal scores, they are weighted and fused to obtain a profile of the transaction entity with identity identification, comprehensive trust expectation and uncertainty.

[0013] Based on the profile of the transaction entity, a smart contract is signed on the blockchain under the condition that the comprehensive trust expectation is not lower than the admission threshold and the uncertainty is not higher than the upper limit threshold. When the performance evidence, the corresponding member proof, and the zero-knowledge proof are all verified, the transaction status is advanced and settlement and confirmation of rights are executed. The performance result is written back to the performance channel evidence, the transaction record is included in the cryptographic accumulator, and a reliable transaction record is output.

[0014] Furthermore, the system receives original messages submitted by multiple entities through heterogeneous information systems, parses business semantic fields according to a pre-set EDI standard and maps them to a common XML schema, uniformly converts them into standardized data objects, and aggregates them into a standardized traceability dataset based on the identification of beef cattle. Specifically, this includes: receiving original messages submitted by farms, slaughterhouses, quarantine agencies, and logistics providers through their respective heterogeneous information systems; parsing the breeding records, health quarantine records, and circulation information in the original messages, which have different field definitions and encoding rules, according to the pre-set EDI standard; mapping the parsed fields to the common XML schema and converting them into standardized data objects; and aggregating the standardized data objects according to individual beef cattle identifiers or batch identifiers to obtain the standardized traceability dataset.

[0015] Furthermore, for sensitive fields in the standardized traceability dataset, cryptographic commitments are calculated and zero-knowledge proofs are generated. Specifically, this includes: the data holder calculating the cryptographic commitments locally for sensitive fields containing breeding costs, formulas, and complete quarantine records; for the pre-defined compliance assertions containing legal origin, qualified quarantine, and cold chain temperature within a specified range, generating the zero-knowledge proof with the commitments as public input, so that the zero-knowledge proof proves that the original data satisfies the pre-defined compliance assertions without exposing the original fields; and submitting the commitments and corresponding zero-knowledge proofs together with the standardized traceability dataset to obtain the standardized traceability dataset with commitments and compliance proofs.

[0016] Further, generating a lifecycle accumulator commitment and witnessing to obtain a verifiable conclusion on the integrity of the transaction chain specifically includes: generating an accumulator element for each record by hashing the concatenation of the target identifier, the stage type, and the commitment of the record; incorporating each stage element into the cryptographic accumulator one by one according to the lifecycle sequence of breeding, quarantine, slaughter, and circulation; for a pre-defined set of essential lifecycle stages, generating a deterministic stage anchor point for each essential stage, determined solely by the target identifier and the stage type and independent of the specific record content, and incorporating it into the cryptographic accumulator to obtain the lifecycle accumulator commitment and the conclusion that each element is related to the transaction chain integrity. The anchor point witnessing process involves writing the lifecycle accumulator commitment, the transaction target identifier, and the on-chain verification entry of each zero-knowledge proof into the blockchain ledger. This is then solidified by distributed node consensus, and a smart contract calls the verification key to verify each zero-knowledge proof. Records that pass verification are marked as compliant. When verification is initiated, a constant-size membership proof is given for records claiming to be on the chain using their witnessing process. For links that should be registered according to the set of essential lifecycle links, membership or non-membership proofs are given for the deterministic link anchor. If the deterministic link anchor does not exist, the missing link is confirmed and located, resulting in a verifiable conclusion on the integrity of the transaction chain. Since the accumulator element contains the commitment, data proven compliant by the zero-knowledge proof and data solidified by the cryptographic accumulator are bound by the same commitment. In the verifiable conclusion on the integrity of the transaction chain, the compliance proof and the integrity commitment point to the same data.

[0017] Further, the process involves identity verification and reputation assessment of the transaction entities, specifically including: digital certificate identity verification for all parties initiating or participating in the transaction to confirm the binding relationship between the on-chain identity and the real-world entity, thus obtaining the trusted on-chain identity; the smart contract maintaining the performance channel evidence count for each entity based on the historical transaction completion, default, and appeal ruling results, and maintaining the data compliance channel evidence count based on the verification results of its historical traceability records through zero-knowledge proofs, wherein the performance channel evidence count and the data compliance channel evidence count constitute the Beta-Bernoulli post-verification evidence for two independent channels; the trust expectation and uncertainty are calculated for the two independent channels according to subjective logic, wherein the sparser the data compliance channel evidence count, the higher the uncertainty of the data compliance channel; abnormal scores that deviate from the group distribution are filtered out, and then the two independent channels are weighted and fused to obtain the transaction entity profile.

[0018] Furthermore, the trust expectation and uncertainty are calculated for the two independent channels according to subjective logic, specifically including: counting the transaction results in the performance channel as positive evidence and the default results as negative evidence, thus forming the Beta-Bernoulli posterior of the performance channel; counting the records that pass the zero-knowledge proof verification in the data compliance channel as positive evidence and the records that fail the verification as negative evidence, thus forming the Beta-Bernoulli posterior of the data compliance channel; based on the positive and negative evidence in the Beta-Bernoulli posterior, the trust expectation and uncertainty of each channel are mapped according to subjective logic, and the uncertainty increases as the sum of the positive and negative evidence decreases.

[0019] Furthermore, the signing and execution of on-chain smart contracts based on the transaction entity profiles specifically includes: requiring both buyers and sellers to sign on-chain smart contracts with machine-readable conditions to agree on price, delivery, quality objections, and settlement rules under dual access conditions of identity authentication, comprehensive trust expectation not lower than the access threshold, and uncertainty not higher than the upper limit threshold; when the delivery vouchers and quality inspection conclusions submitted by the oracle or authorized node meet the conditions of the on-chain smart contract, and the member proof and zero-knowledge proof in the corresponding traceability link are both verified, the on-chain smart contract automatically advances the transaction status; triggers fund settlement and confirmation of rights transfer, writes the performance result of this transaction back to the performance channel evidence count, and incorporates the transaction record as a new link element into the cryptographic accumulator, outputting the trusted transaction record that has completed confirmation of rights and settlement.

[0020] Furthermore, the blockchain ledger is solidified by distributed node consensus, and the lifecycle accumulator commitment written into the blockchain ledger, the on-chain verification entry of each zero-knowledge proof, and the trusted transaction record are immutable after being agreed upon by the distributed nodes.

[0021] A second aspect of the present invention provides a digital beef cattle trading system, comprising:

[0022] The standardized access module is used to receive original messages submitted by multiple entities through heterogeneous information systems, parse business semantic fields according to the preset EDI standard and map them to the public XML schema, uniformly convert them into standardized data objects, and collect them into standardized traceability datasets according to the identification of beef cattle.

[0023] The compliance proof module is used to calculate cryptographic commitments for sensitive fields in the standardized traceability dataset and generate zero-knowledge proofs that prove the original data satisfies the pre-defined compliance assertions, with the commitments as public inputs, thus obtaining a standardized traceability dataset with commitments and compliance proofs.

[0024] The accumulator verification module is used to generate lifecycle accumulator commitments and witnesses based on the standardized traceability dataset with commitments and compliance proofs, and write the lifecycle accumulator commitments and the on-chain verification entry of each zero-knowledge proof into the blockchain ledger. It provides member proofs for on-chain records and non-member proofs for missing link anchors, and obtains the transaction chain integrity verifiable conclusion that compliance and integrity are bound by the commitments.

[0025] The reputation assessment module is used to verify the identity of each party through digital certificates based on the verifiable conclusion of the integrity of the transaction chain to obtain a trusted on-chain identity. Based on the performance results and data compliance verification, it maintains the Beta-Bernoulli post-verification data of the performance channel and the data compliance channel respectively. It calculates the trust expectation and uncertainty of each channel according to subjective logic, filters abnormal scores, and then weights and fuses them to obtain a profile of the transaction entity with identity identification, comprehensive trust expectation and uncertainty.

[0026] The contract execution module is used to sign on-chain smart contracts based on the profile of the transaction subject, provided that the comprehensive trust expectation is not lower than the admission threshold and the uncertainty is not higher than the upper limit threshold. When the performance evidence, the corresponding member proof, and the zero-knowledge proof are all verified, the transaction status is advanced and settlement and confirmation of rights are executed. The performance result is written back to the performance channel evidence, the transaction record is included in the cryptographic accumulator, and a trusted transaction record is output.

[0027] The beneficial technical effects of the present invention are as follows:

[0028] (i) By combining the EDI (Electronic Data Interchange) standard with the public XML schema, the breeding, quarantine, and transfer data reported by multiple heterogeneous systems are semantically standardized and aggregated according to beef cattle standards, eliminating the need for platforms to customize and adapt to each one, and improving the relevance and consistency of traceability data; by calculating cryptographic commitments on sensitive fields containing commercial privacy at the standardized access terminal and generating compliance zero-knowledge proofs with the commitments as public inputs, and verifying them on the blockchain with verification keys, the goal of "traceability compliance can be verified by any third party without leaking original privacy data" is achieved, fundamentally resolving the dilemma of "untrustworthy if not reported, and privacy leaked if reported", and improving the integrity and credibility of traceability data.

[0029] (ii) By constructing a lifecycle cryptographic accumulator using hashes of "target identifier | link type | record commitment" as elements and pre-setting deterministic link anchors, a constant-size membership proof is provided for on-chain records, and a non-membership proof is provided for missing link anchors. This allows any third party to independently verify that the record has not been tampered with and mathematically locate missing links, upgrading integrity verification and breakpoint location from heuristic comparison to verifiable cryptographic conclusions. The accumulator elements contain commitments, binding integrity commitments and compliant zero-knowledge proofs through the same commitment, preventing data substitution. The Beta-Bernoulli post-hoc approach, which combines data compliance with subjective logic, outputs a comprehensive trust with uncertainty. It uses both trust expectation and uncertainty as thresholds for transaction admission, resisting misjudgments based on sparse evidence and score manipulation, and providing a rigorous basis for transaction admission and risk control. Through smart contracts, it drives the automation of delivery, settlement and confirmation of rights based on machine-readable conditions, and writes back the objective performance results as reputation evidence and incorporates transaction records into the accumulator, forming a dual closed loop of reputation assessment and traceability chain, reducing human intervention and improving transaction efficiency and the credibility of results. Attached Figure Description

[0030] Figure 1 This is a schematic diagram of the overall process of a digital beef cattle trading method according to the present invention;

[0031] Figure 2 This is a schematic diagram of the process for standardized access to multi-source heterogeneous data and generation of compliance proofs for sensitive fields in this invention;

[0032] Figure 3 This is a schematic diagram illustrating the integrity verification of the full lifecycle accumulator commitment structure and transaction chain of the present invention;

[0033] Figure 4 This is a schematic diagram of the dual-channel Bayesian reputation assessment model of the present invention;

[0034] Figure 5 This is a schematic diagram of the smart contract-driven transaction execution and settlement process of the present invention;

[0035] Figure 6 This is a schematic diagram of the structure of a digital beef cattle trading system according to the present invention. Detailed Implementation

[0036] The specific embodiments of the present invention will now be described in detail with reference to the accompanying drawings.

[0037] Example 1

[0038] like Figure 1As shown, this embodiment provides a digital beef cattle trading method. The overall solution of this invention takes the "lifecycle stages of beef cattle" as its main thread, sequentially proceeding through four stages: standardization of multi-source heterogeneous data and generation of compliance proofs for sensitive fields; on-chain commitment and integrity verification of the full lifecycle accumulator; entity identity authentication and dual-channel Bayesian reputation assessment; and automated execution of smart contracts and reputation feedback. This forms a closed loop of digital transactions that ensures privacy protection, integrity verification, and rigorous credit. The method of this embodiment specifically includes the following steps:

[0039] The overall architecture of this invention follows a pipeline principle: "data standardization precedes cryptographic processing, cryptographic processing precedes reputation accumulation, and reputation accumulation precedes contract execution." This ensures that the output of each stage provides reliable and uniformly formatted input for the next stage. Under this design, the data standardization stage eliminates format barriers caused by multi-source heterogeneity, providing structurally consistent raw materials for cryptographic processing. The cryptographic processing stage generates verifiable compliance commitments under privacy protection, providing binding cryptographic credentials for integrity verification. The integrity verification stage quantifies the credibility of the traceability chain into mathematically provable conclusions through accumulator commitments and member and non-member proofs, providing an objective basis for reputation assessment. The reputation assessment stage provides a rigorous threshold for transaction access using a multi-dimensional trust profile with uncertainty. The contract execution stage aggregates the credible results of all the above stages in a smart contract, forming a fully automated, human-intervention-proof settlement loop. These five stages are interconnected, with the cryptographic output of each stage serving as a credible input for the next stage, collectively forming a complete trust transfer chain. This ensures the overall solution achieves verifiability throughout the entire transaction process without relying on any single trusted third party.

[0040] S1: Receives original messages submitted by multiple entities through heterogeneous information systems, parses business semantic fields according to the preset EDI standard and maps them to a public XML schema, uniformly converts them into standardized data objects, and collects them into a standardized traceability dataset according to the identification of beef cattle.

[0041] Multiple entities, including farms, slaughterhouses, quarantine agencies, and logistics providers, operate their own independent information systems, resulting in inconsistent field definitions, encoding rules, and message formats in their original reports. Upon receiving these original reports, the trading center parses the business semantic fields according to a pre-defined EDI (Electronic Data Interchange) standard. It identifies business elements such as breeding records, health quarantine records, and transfer information from each entity's reports, mapping them to a unified public XML schema. This eliminates the differences in data formats among different entities, uniformly converting them into standardized data objects with a consistent structure. Subsequently, the standardized data objects submitted by each entity are aggregated according to individual cattle identifiers or batch identifiers, forming a standardized traceability dataset covering the complete lifecycle of the beef cattle.

[0042] In the aforementioned standardized process, the trading center does not need to customize and modify the information systems of each party individually. Instead, it uses a unified semantic mapping layer to convert messages from different sources and in different formats into standardized objects that conform to the same data specification. The core value of this design lies in the fact that when a new participating entity is added, it only needs to send messages according to the pre-defined EDI standard, without modifying the trading center's receiving logic, thus exhibiting excellent scalability. At the same time, semantic-level parsing, rather than merely format conversion, ensures that when different entities use different encoding rules for the same business concept (such as "quarantine qualified"), it can be correctly identified and mapped to a common semantic representation, eliminating ambiguity in cross-system data understanding and providing a semantically consistent data foundation for subsequent cryptographic processing.

[0043] S2: For the sensitive fields in the standardized traceability dataset, calculate the cryptographic commitment and generate a zero-knowledge proof that uses the commitment as public input to prove that the original data satisfies the pre-defined compliance assertion, thus obtaining a standardized traceability dataset with commitment and compliance proof.

[0044] Standardized traceability datasets often contain sensitive fields that constitute the commercial privacy of the data holder, such as breeding costs, feed formulas, and complete quarantine records. To prove data compliance without exposing the original fields, the data holder calculates a cryptographic commitment C locally for these sensitive fields. This commitment is both binding to the original field content (the commitment value uniquely corresponds to the commitment content) and hidden (the original content cannot be reconstructed from the commitment value alone). Based on this, for pre-defined compliance assertions (such as legal origin, qualified quarantine, and cold chain temperature within the specified range), a corresponding zero-knowledge proof is generated using commitment C as public input. This proof can demonstrate to any third party that the original data satisfies the corresponding compliance assertion without revealing the original field content. Finally, the commitment and the corresponding zero-knowledge proof are submitted together with the standardized traceability dataset, forming a standardized traceability dataset with commitments and compliance proofs.

[0045] It should be noted that the choice of cryptographic commitment scheme should be determined based on the requirements of the subsequent zero-knowledge proof construction. When compliance assertions involve numerical range comparisons (such as whether the cold chain temperature is within a specified range), the Pedersen commitment scheme, which supports homomorphic operations, is preferable because it can support efficient range proof circuit construction without exposing the original value. When compliance assertions only need to prove the existence of data or hash consistency, the hash commitment scheme is more suitable due to its simple construction and low computational overhead. Both commitment schemes provide computationally binding and perfect hiding of the original field content. Data holders can flexibly choose the corresponding commitment scheme for different types of sensitive fields, as long as they ensure that the subsequently generated zero-knowledge proof matches the selected commitment scheme.

[0046] S3: Based on the standardized traceability dataset with commitment and compliance proof, generate lifecycle accumulator commitment and witness, and write the lifecycle accumulator commitment and the on-chain verification entry of each zero-knowledge proof into the blockchain ledger. Provide member proof for on-chain records and non-member proof for missing link anchors, and obtain the transaction chain integrity verifiable conclusion that compliance and integrity are bound by the commitment.

[0047] The trading center generates an accumulator element for each record in the standardized traceability dataset with commitments and compliance proofs. This element is hashed by concatenating the identifier of the beef cattle, the lifecycle stage type, and the commitment C of the record. Elements from each stage are sequentially incorporated into the cryptographic accumulator according to the lifecycle order of breeding, quarantine, slaughter, and circulation. Simultaneously, for a pre-defined set of essential lifecycle stages, a deterministic stage anchor point, determined solely by the cattle identifier and stage type, is generated for each essential stage and incorporated into the accumulator, resulting in the lifecycle accumulator commitment ACC and the witnessing of each element and anchor point. The accumulator commitment ACC, the trading cattle identifier, and the on-chain verification entry points for each compliance zero-knowledge proof are written into the blockchain ledger, solidified by distributed node consensus, and verified line by line by a smart contract. Records that pass verification are marked as compliant. When verification is initiated, a constant-size membership proof is provided for records claiming to be on the chain, and a non-membership proof is provided for records lacking essential stage anchor points, resulting in a verifiable conclusion of the integrity of the trading chain bound by the commitment.

[0048] In this process, the design of deterministic anchor points is the key technology for ensuring the verifiability of the transaction chain's integrity. Since the anchor point is obtained solely from the hash of two deterministic elements—the identifier of the cattle and the type of the transaction—it is completely decoupled from the specific record content. Therefore, regardless of whether a necessary step actually occurs, the value of its corresponding anchor point is logically uniquely determined. When the anchor point is not in the accumulator, non-membership proofs can mathematically confirm precisely that the necessary step was never registered, rather than failing due to differences in record format or content. This property upgrades the determination of missing steps from relying on internal platform comparison logic to a cryptographic conclusion that can be independently verified by any third party holding an accumulator commitment, fundamentally improving the credibility level of traceability integrity verification.

[0049] S4: Based on the verifiable conclusion of the integrity of the transaction chain, digital certificate identity authentication is performed on all parties to obtain a trusted on-chain identity. Based on their performance results and data compliance verification, Beta-Bernoulli post-verification data for the performance channel and the data compliance channel are maintained respectively. The trust expectation and uncertainty of each channel are calculated according to subjective logic, and after filtering out abnormal scores, they are weighted and fused to obtain a profile of the transaction entity with identity identification, comprehensive trust expectation and uncertainty.

[0050] The trading center performs digital certificate authentication on all parties initiating or participating in transactions, confirming the binding relationship between their on-chain identities and real-world entities, thus obtaining trusted on-chain identities. Based on this, smart contracts maintain a performance credibility evidence count for each entity according to the objective performance results of historical transactions, and maintain a data compliance credibility evidence count based on the compliance zero-knowledge proof verification results of their historical traceability records. These two types of counts constitute Beta-Bernoulli post-verification evidence for two independent channels: performance and data compliance. The trading center calculates the trust expectation and uncertainty for both channels according to subjective logic, filters out abnormal scores that deviate from the group distribution, and then weights and merges the two dimensions to obtain a profile of the trading entity with identity identification, comprehensive trust expectation, and uncertainty. The sparser the evidence, the higher the uncertainty of the corresponding dimension, thus preventing new entrants from being misjudged as high-trust.

[0051] Furthermore, the dual-channel design offers significant technical advantages over a single comprehensive reputation score. First, performance and data compliance are fundamentally different in nature—the former reflects an entity's business integrity, while the latter reflects its data compliance. Combining the two into a single score would obscure the true situation across different dimensions. Second, the evidence sources for the two channels are independent: the performance channel's evidence comes from transaction results, while the data compliance channel's evidence comes from on-chain zero-knowledge proof verification. These two types of evidence cannot be manipulated, effectively preventing attacks that use high scores in one dimension to mask deficiencies in another. Third, the uncertainty index allows new entrants to enter the market with a reasonable, neutral assessment, rather than being forced to accept the lowest possible score, reflecting fairness for new participants and transparency for decision-makers.

[0052] S5: Based on the profile of the transaction entity, under the condition that the comprehensive trust expectation is not lower than the admission threshold and the uncertainty is not higher than the upper limit threshold, the on-chain smart contract is signed. When the performance evidence, the corresponding member proof, and the zero-knowledge proof are all verified, the transaction status is advanced and the settlement and confirmation of rights are executed. The performance result is written back to the performance channel evidence, the transaction record is included in the cryptographic accumulator, and the trusted transaction record is output.

[0053] The trading center requires both buyers and sellers to sign an on-chain smart contract with machine-readable conditions, stipulating prices, delivery, quality objections, and settlement rules, after passing identity authentication and meeting dual admission conditions (comprehensive trust expectation not lower than the admission threshold and uncertainty not higher than the upper limit threshold). When the delivery vouchers, quality inspection conclusions, and other performance evidence submitted by the oracle or authorized node meet the contract conditions, and the accumulator member proof and compliance zero-knowledge proof in the corresponding traceability link are both verified, the smart contract automatically advances the transaction status, triggers fund settlement and confirmation of rights transfer, writes the objective performance result of this transaction back to the entity's performance reputation evidence count, incorporates the transaction record as a new link element into the lifecycle accumulator of the target, and outputs a credible transaction record that completes the confirmation of rights and settlement, so that the reputation assessment and traceability chain form a continuously updated dual closed loop.

[0054] It should be understood that the step of incorporating transaction records into the cryptographic accumulator has significant technical implications: it not only persists the transaction results to an immutable on-chain traceability structure, but also makes each transaction itself a cryptographically verifiable link in the lifecycle of the beef cattle. Any subsequent doubts about the authenticity of the transaction record can be eliminated through member proof. This mechanism extends the traceability chain from the production and distribution stage to the transaction settlement stage, forming a complete and cryptographically verifiable record covering the entire lifecycle of the beef cattle, further strengthening the integrity and traceability of the trust system constructed by this invention.

[0055] Example 2

[0056] like Figure 2 As shown, this embodiment further elaborates on step S1 based on embodiment 1.

[0057] S1.1: Receive original messages submitted by farms, slaughterhouses, quarantine agencies and logistics providers through their respective heterogeneous information systems.

[0058] The various parties involved in beef cattle transactions include, but are not limited to, cattle farms, slaughterhouses, quarantine agencies, and logistics providers. Each of these entities operates its own independent information system, with significant differences in data formats, communication protocols, and field encoding rules. The trading center provides a unified data receiving interface, receiving raw messages from all parties through standardized communication protocols. This eliminates the need for any specific system modifications by the parties involved, removing interoperability barriers caused by multi-source heterogeneity at the access layer.

[0059] In designing a unified data receiving interface, the transaction center employs a protocol-independent access adaptation layer. This layer supports entities submitting messages via common e-commerce data exchange protocols such as HTTP / HTTPS and AS2, ensuring universality and security at the message transmission level. Upon receiving the original message, the access adaptation layer first identifies its format, determining the outer transmission protocol and inner data encoding method. It then uniformly transmits the message to the EDI parsing engine for semantic processing. This separation of responsibilities between message reception and semantic parsing reduces coupling between different stages. Adding new entity types requires no modification to the parsing engine logic; only the corresponding format recognition rules need to be added to the adaptation layer. This ensures the system's access scalability throughout its long-term evolution.

[0060] S1.2: Based on the preset EDI standard, parse the breeding records, health quarantine records and transfer information in the original message, which have different field definitions and encoding rules.

[0061] The trading center has a built-in EDI (Electronic Data Interchange) standard parsing engine that performs semantic-level parsing on the received raw messages. It accurately identifies and extracts breeding records (including individual identifiers, breeds, dates of birth, breeding locations, etc.), health quarantine records (including quarantine agency identifiers, quarantine dates, quarantine conclusions, etc.), and circulation information (including transfer time, transportation mode, cold chain temperature records, etc.) from the messages. This enables compatible parsing of different field definitions and encoding rules from various parties, eliminating data semantic ambiguity caused by heterogeneous systems.

[0062] In actual parsing, when the parsing engine analyzes the breeding records reported by farms, it can identify and process the farm's custom breed codes, birth region codes, and feeding stage markers, converting them into standard animal identification and feeding record semantics. When parsing quarantine reports reported by quarantine agencies, it can identify official quarantine agency identifiers, quarantine item codes, and pass / fail judgment marks, normalizing them into standard quarantine conclusion semantics. When parsing logistics reports reported by logistics providers, it can extract loading time, in-transit temperature and humidity sensor readings, and handover and receipt information, converting them into standard cold chain logistics semantics. After unified semantic parsing of the above-mentioned various types of reports, all business elements are presented with the same semantic tags, eliminating data ambiguity caused by coding differences, laying a semantically unified foundation for subsequent field mapping, and ensuring that similar business data from different entities can be consistently interpreted and compared after entering the public XML schema.

[0063] S1.3: Map the parsed fields to the public XML schema and convert them into standardized data objects.

[0064] After semantic parsing, the trading center converts each original field into a standardized representation conforming to the public XML schema according to preset mapping rules, unifying field names, data types, and encoding formats to form standardized data objects with consistent structure and clear semantics. The public XML schema covers standard field definitions for various traceability data throughout the entire life cycle of beef cattle, ensuring that similar data from different entities and systems have a unified data structure after conversion, eliminating the burden of customization and adaptation.

[0065] The public XML schema is designed to encompass three main levels: basic information about individual beef cattle, records of each lifecycle stage, and identifiers of participating entities. Strict element constraints and data type definitions ensure structural and semantic consistency in the standardized data objects after conversion. The public XML schema also sets dedicated placeholder elements for sensitive fields in each type of traceability data: after parsing the original message, the values ​​of sensitive fields are processed only locally by the data holder. The corresponding placeholder elements are filled with cryptographic commitment values ​​instead of the original field values ​​in the standardized data objects. This ensures that sensitive information does not leave the local environment of the data holder from the data structure design at the access layer, achieving structural protection of commercial privacy during the data standardization stage and fundamentally eliminating the possibility of the trading center accessing the original sensitive field content during the access process.

[0066] S1.4: The standardized data objects are aggregated according to the individual identifier or batch identifier of the beef cattle to obtain the standardized traceability dataset.

[0067] Using the unique identifier of each beef cattle (such as ear tag number) or batch identifier as the primary key, standardized data objects submitted by different entities at different times are associated and aggregated to form a standardized traceability dataset covering the entire lifecycle of the individual beef cattle or batch. This dataset uses the target identifier as an index to provide a consistent and complete data foundation for the subsequent generation of compliance proofs for sensitive fields and the construction of a full lifecycle accumulator.

[0068] Preferably, when beef cattle are managed by individual identifiers (such as electronic ear tag numbers or unique RFID tag codes), the standardized traceability dataset uses the individual identifier as the primary key to accurately track the complete chain of each cow from birth to sale. When beef cattle are managed by batch identifiers, the batch identifier is used as the primary key, and the common records (such as batch quarantine conclusions) and individual records (such as individual weight) of each cow within the same batch are stored hierarchically in the standardized traceability dataset. The above two aggregation methods can coexist in the same dataset, distinguished by identifier type, providing a clear index structure for subsequent construction of accumulator elements by identifier. This simultaneously meets the data management needs of both refined individual traceability and large-scale batch traceability business scenarios, enabling the invention to flexibly adapt to beef cattle trading scenarios with different scales and management precision requirements.

[0069] Example 3

[0070] like Figure 2 As shown, this embodiment further elaborates on step S2 based on embodiment 1.

[0071] S2.1: The data holder calculates the cryptographic commitment locally for sensitive fields containing breeding costs, formulas, and complete quarantine records.

[0072] Sensitive fields are processed entirely locally by the data holder, and the trading center and any other party do not need to access the original sensitive field content. Locally, the data holder calculates the corresponding cryptographic commitment C for fields containing commercially sensitive information such as breeding costs, feed formulas, and complete quarantine records using a cryptographic commitment scheme (such as Pedersen commitments or hash commitments). This commitment is bound to the original field content (the commitment value uniquely corresponds to the commitment content and cannot be forged) and is hidden (the original content cannot be reconstructed from the commitment value alone), providing a cryptographic foundation for subsequent zero-knowledge proof generation and on-chain verification.

[0073] Furthermore, the local processing mechanism for sensitive fields also includes joint commitment processing for multiple related sensitive fields. When there is a logical relationship between multiple sensitive fields (such as the breeding cost field and the feed formula field jointly constituting the basis for cost accounting), the data holder can combine multiple related fields into a vector and uniformly calculate a single cryptographic commitment. This allows subsequent zero-knowledge proofs to simultaneously prove the compliance of multiple fields based on this joint commitment, avoiding the on-chain verification overhead of generating commitments and proofs separately for each field. In addition, the calculation process of cryptographic commitments introduces a random number blinding factor to ensure that even if the same sensitive fields from different entities have the same value, the corresponding commitment values ​​will be different. This fundamentally prevents side-channel inference attacks that reverse-engineer the original field content by comparing commitment values, further strengthening the protection of commercial privacy.

[0074] S2.2: For the pre-defined compliance assertion that includes legal origin, qualified quarantine and cold chain temperature within the specified range, generate the zero-knowledge proof with the commitment as public input, so that the zero-knowledge proof proves that the original data satisfies the pre-defined compliance assertion without exposing the original fields.

[0075] The trading center pre-defines a set of compliance assertions to meet the regulatory requirements of beef cattle trading, including but not limited to: legal origin (e.g., origin within a registered breeding area), qualified quarantine (a qualified conclusion issued by a quarantine agency), and cold chain transportation temperature consistently within the specified range (e.g., 0℃ to 4℃). The data holder, using a cryptographic commitment C as public input, constructs a zero-knowledge proof corresponding to the above compliance assertions locally, based on a zero-knowledge proof protocol (e.g., zk-SNARK or Bulletproofs). This allows the verifier to confirm that the original field satisfies the corresponding compliance assertion simply by using commitment C and the corresponding zero-knowledge proof, without needing to obtain any content of the original field. This achieves the provision of verifiable compliance proofs to any third party without disclosing commercial privacy.

[0076] It should be noted that the construction methods of zero-knowledge proofs differ for different types of compliance assertions. For origin legitimacy assertions, the proof circuit needs to verify that the original origin field value belongs to a pre-defined set of legitimate origins, usually achieved by constructing a set membership proof, i.e., proving that it belongs to a certain authorized origin list without revealing the specific origin value. For quarantine compliance assertions, the proof circuit needs to verify that the quarantine conclusion field meets specific compliance condition codes, achieved by constructing equality or inequality constraint relationships. For cold chain temperature range assertions, the proof circuit needs to verify that all readings in the temperature sensor recording sequence fall within the specified range, usually achieved through range proof techniques, using the homomorphic properties of the commitment scheme to support the range constraint verification of batch temperature values. The proof circuits for the above different types of assertions are pre-compiled during the system initialization phase, and the proof generation program is run locally by the data holder. The entire proof generation process and the original field value do not leave the holder's local environment, and only a compact zero-knowledge proof and corresponding commitment are output externally, ensuring that commercial privacy is reliably protected at the technical level.

[0077] S2.3: Submit the commitment and the corresponding zero-knowledge proof together with the standardized traceability dataset to obtain the standardized traceability dataset with commitment and compliance proof.

[0078] The data holder will submit the locally generated cryptographic commitment C and its corresponding compliant zero-knowledge proofs, along with the non-sensitive field data from the standardized traceability dataset, to the exchange. The exchange will associate and store the commitment, zero-knowledge proofs, and corresponding standardized data records to form a standardized traceability dataset with commitments and compliant proofs, for use in subsequent accumulator element generation and on-chain verification.

[0079] It should be understood that the standardized traceability dataset with commitments and compliance proofs uses each traceability record as the basic unit in its storage structure. Each unit contains three parts: plaintext data of non-sensitive fields (such as stage type labels, timestamps, and subject identifiers), cryptographic commitment values ​​corresponding to sensitive fields, and zero-knowledge proofs generated for each compliance assertion. This storage structure ensures that the compliance proof and its content commitment for each record are always stored together at the data level. This provides a clear data index relationship for commitment extraction during subsequent accumulator element construction and on-chain zero-knowledge proof verification, avoiding erroneous association between commitments and proofs in multi-record scenarios and ensuring the correctness and traceability of subsequent cryptographic operations.

[0080] Example 4

[0081] like Figure 3 As shown, this embodiment further elaborates on step S3 based on embodiment 1.

[0082] S3.1: Generate an accumulator element for each record by hashing the concatenation of the target identifier, the link type, and the commitment of the record.

[0083] Specifically, for each traceability record in the standardized traceability dataset with commitments and compliance proofs, the trading center concatenates the following three elements in a prescribed order: the identifier of the beef cattle corresponding to the record (e.g., ear tag number), the lifecycle stage type (e.g., breeding, quarantine, slaughter, or transfer), and the cryptographic commitment C of the record. This concatenation is then used to calculate the accumulator element e = Hash(Identifier || Stage Type || Commitment C) using a cryptographic hash function (e.g., SHA-256). Since the accumulator element e contains the commitment C, this element tightly binds the record's identity information (identifier and stage type) to the cryptographic fingerprint (commitment) of the record content. This lays the foundation for the subsequent cryptographic binding of compliance proofs and integrity commitments, preventing attacks that swap compliance proofs and integrity commitments for different data.

[0084] Furthermore, the introduction of each component in the three-component hash design is necessary. If only the target identifier and the stage type are hashed to form an element, all records of the same beef cattle and the same stage will produce the same element, making it impossible to distinguish multiple reports from the same stage. If only the record content is hashed to form an element, the binding relationship between the element and the target identifier and stage type needs to be maintained separately, increasing the complexity of the verification logic. By using the target identifier, stage type, and commitment to form an element, it ensures that different records correspond to different elements (because the commitment contains a random blinding factor), and directly encodes the record's identity information and content fingerprint within the element. This allows the membership proof to prove in one step that the target has a record bound by the content commitment in the stage. The logic is simple and the proof structure is compact. At the same time, it eliminates the possibility of forging membership relationships by changing the target identifier or stage type label at the element construction level.

[0085] S3.2: Incorporate each element of the life cycle of breeding, quarantine, slaughter and circulation into the cryptographic accumulator one by one.

[0086] The trading center sequentially incorporates accumulator elements corresponding to the breeding, quarantine, slaughter, and circulation stages of beef cattle into a cryptographic accumulator (such as an RSA accumulator or a general accumulator based on elliptic curves) according to the chronological order of the beef cattle's life cycle, dynamically updating the accumulator state. Each time a new element is incorporated, the accumulator generates a member witness corresponding to that element for subsequent member proofs.

[0087] The choice of cryptographic accumulator directly affects the size of the membership proof and the verification efficiency. The RSA accumulator utilizes the unknown order property of the RSA group, constructing membership proofs through exponentiation. The proof size is a fixed RSA modulus, and verification requires only two exponentiation operations. It also supports batch proof updates when the group order is known. A general accumulator based on elliptic curve pairing can obtain more compact proofs on curves with smaller group elements and supports batch witness updates based on polynomial commitments, suitable for scenarios with frequently changing element numbers. In this invention, regardless of the accumulator scheme chosen, the following core properties must be satisfied: for any element in the set, its membership witness size is independent of the total number of elements in the set (i.e., a constant size); the set state is represented by a single accumulator commitment value; after adding an element, the witnesses of existing elements can be efficiently updated through the accumulator state update algorithm without needing to be regenerated from scratch. These properties ensure that the generation and verification overhead of membership proofs remains stable as the number of records in the beef cattle lifecycle continuously increases, without expanding with the growth of the record size, suitable for the needs of dynamically changing record numbers in actual transaction scenarios.

[0088] S3.3: For the pre-defined set of essential lifecycle steps, generate a deterministic step anchor point for each essential step, which is determined solely by the target identifier and the step type and is independent of the specific record content, and incorporate it into the cryptographic accumulator to obtain the lifecycle accumulator commitment and the witnessing of each element and anchor point.

[0089] The trading center pre-defines a set of essential lifecycle stages (such as breeding registration, slaughter quarantine, slaughter inspection, and warehouse transfer). For each essential stage, a deterministic stage anchor point a = Hash(target identifier || stage type) is generated. This anchor point is determined solely by the identifier of the beef cattle target and the corresponding stage type, and is completely unrelated to the specific record content, possessing determinism and uniqueness. These deterministic stage anchor points, along with each accumulator element, are incorporated into a cryptographic accumulator to obtain the final lifecycle accumulator commitment ACC and the witnesses for each element and anchor point, providing a verifiable basis for subsequent member and non-member proofs.

[0090] Furthermore, the core technical significance of deterministic anchor points lies in transforming the yes / no question of "whether a certain essential step has occurred" into a cryptographically verifiable set membership or non-membership problem. In traditional tracing systems, determining whether a step is missing typically relies on the platform's internal record comparison logic, which has the following limitations: the judgment result depends on the platform's integrity and cannot be independently verified by a third party; if records cannot be matched due to format differences or inconsistent identifiers, the judgment may produce false alarms; the conclusion of the missing step judgment cannot be cryptographically transformed into a portable and verifiable proof. Deterministic anchor points overcome the above limitations through the following mechanism: since the anchor value is entirely determined by two publicly available pieces of information—the target identifier and the step type—any verifier who possesses these two pieces of information can independently calculate the expected value of the anchor; if the anchor is not in the accumulator (the non-membership proof is valid), then, under the guarantee of the accumulator's cryptographic security, it can be determined that the anchor was indeed never included during the accumulator's lifecycle, meaning the corresponding essential step was indeed never registered, completely unrelated to the specific record content and format. This mechanism gives the conclusion of missing link location the same cryptographic strength as member proof, fundamentally solving the problem that traditional comparison logic cannot provide credible missing proof to third parties, and shifting the root of trust for link integrity verification from the platform to publicly verifiable cryptographic assumptions.

[0091] It is worth noting that for the same essential step in the same beef cattle certification process, there may be multiple reports (such as supplementary quarantine inspections or corrected records). The definitive step anchor and the specific record element of that step are two different types of objects: the anchor marks that the step has occurred, while the specific record element carries the detailed content of that step. When the anchor exists but the member proof for a specific record fails, it indicates that the specific content of that record has been altered, rather than the entire step being missing. When the anchor does not exist, regardless of whether there are records claiming to belong to that step, it can be mathematically confirmed that the essential step has never been compliantly registered. These two types of proof complement each other, forming a complete integrity verification system that can accurately distinguish between the two different anomalies: "records exist but content has been altered" and "the entire step is missing," providing regulators with fine-grained traceability and anomaly location capabilities.

[0092] S3.4: Write the lifecycle accumulator commitment, the transaction target identifier, and the on-chain verification entry of each of the zero-knowledge proofs into the blockchain ledger, solidify them through distributed node consensus, and use the smart contract to call the verification key to verify each of the zero-knowledge proofs. Mark the records that pass the verification as verified and compliant.

[0093] The trading center uniformly writes the lifecycle accumulator commitment ACC, the identifier of the trading target, and the on-chain verification entry points (such as verification key addresses or proof hash indexes) of each compliant zero-knowledge proof into the blockchain ledger. Distributed nodes solidify the above data on the chain through a consensus mechanism to ensure its immutability. Subsequently, the smart contract deployed on the chain calls the corresponding verification key to perform on-chain verification of each compliant zero-knowledge proof according to the zero-knowledge proof verification algorithm. The traceability record of the verified proof is marked as "verified compliant", forming a compliance verification result that can be checked on the chain.

[0094] In the on-chain verification design of smart contracts, the verification key should be stored on-chain as a contract variable to ensure that it cannot be unilaterally tampered with once deployed. When the smart contract calls the verification key, it performs step-by-step calculations on the submitted zero-knowledge proof according to a pre-compiled verification algorithm. The verification algorithm itself is also embedded in the contract code, making it publicly transparent. Any third party can verify the correctness of the verification algorithm by reading the contract code. This design transforms the verification process of zero-knowledge proofs from internal platform logic to the execution of publicly transparent contract code on-chain. Combined with the immutability of the blockchain ledger, it ensures that the credibility and traceability of the verification conclusions reach the highest standards. Any objection to the verification result can be objectively verified by replaying the on-chain contract code, eliminating reliance on the platform's integrity from a system design perspective.

[0095] S3.5: When initiating verification, the member proof of a constant size is given for the record claimed to be on the chain using its witness, and the member or non-member proof is given for the deterministic link anchor for the link that should be registered according to the set of essential links in the life cycle. If the deterministic link anchor does not exist, the missing link is confirmed and located, and the conclusion that the integrity of the transaction chain can be proven is obtained.

[0096] When a buyer or regulator initiates traceability verification for a specific beef cattle product, for each traceability record claimed to be on the blockchain, its corresponding witness is used. Based on the cryptographic accumulator's membership proof algorithm, a membership proof of constant size (independent of the total number of elements in the accumulator) is generated to prove that the accumulator element corresponding to the record is indeed in the lifecycle accumulator and has never been tampered with. For each essential link in the set that should be registered, a membership or non-membership proof is given for its deterministic link anchor: if the anchor exists in the accumulator (membership proof is valid), it indicates that the link has been registered; if the anchor is not in the accumulator (non-membership proof is valid), the missing record of the essential link is mathematically confirmed and located precisely. A fully verifiable cryptographic conclusion can be given without relying on the platform's comparison logic. This upgrades integrity verification and breakpoint location from heuristic comparison to verifiable cryptographic conclusions, ultimately obtaining a verifiable conclusion of the integrity of the transaction chain, which is bound to compliance and integrity.

[0097] One key advantage of cryptographic accumulators over traditional data structures like hash trees is their constant-size membership proofs. In Merkle tree schemes, the size of a membership proof is proportional to the tree height and increases with the number of records. However, the size of a cryptographic accumulator's membership proof is independent of the set size, remaining a fixed single element of the accumulator group. As the number of records related to the lifecycle of cattle increases, the verification cost remains constant, making it suitable for efficient verification in large-scale traceability scenarios. Furthermore, non-membership proofs can also be generated at a constant size within the cryptographic accumulator framework. Their security relies on the computational difficulty assumptions upon which the accumulator is based (such as the RSA or discrete logarithm assumptions). Under these assumptions, any attempt to forge a non-membership proof is computationally infeasible, providing a robust cryptographic security guarantee for locating missing links. This allows regulators to independently verify the integrity of traceability without trusting the platform, truly achieving open traceability verification capabilities for any third party.

[0098] Example 5

[0099] like Figure 4 As shown, this embodiment further elaborates on step S4 based on embodiment 1.

[0100] S4.1: Perform digital certificate identity authentication on all parties initiating or participating in the transaction, confirm the binding relationship between the on-chain identity and the real entity, and obtain the trusted on-chain identity.

[0101] The trading center relies on the PKI (Public Key Infrastructure) system to authenticate the identities of various parties initiating or participating in transactions, including farms, slaughterhouses, quarantine agencies, logistics providers, and buyers, using digital certificates. The authentication process includes verifying the validity and expiration status of the digital certificates held by the entities, the binding relationship between the public key identified by the certificate and its on-chain identity, and the integrity of the Certificate Authority's (CA) trusted root chain. This ensures a verifiable and unique correspondence between the on-chain identity and the real-world entity, resulting in a trusted on-chain identity. This provides a reliable foundation for subsequent attribution of credit evidence and signature verification in contract signing.

[0102] During the digital certificate verification process, the exchange also performs restrictive verification on the certificate's usage scenarios to ensure that certificates used for transaction signing have the corresponding extended fields for key usage (such as digital signature, content submission), preventing certificates from being used beyond their authorized scope. For entities whose certificates have expired or been revoked, the exchange periodically checks the current status of the certificates through an online certificate status protocol or a certificate revocation list. Once a certificate is found to be invalid, the entity's transaction permissions are immediately suspended and its reputation status is marked until the entity updates a valid certificate and re-completes identity authentication. This complete certificate lifecycle management mechanism ensures the continuous validity of on-chain identities during transactions, prevents identity impersonation risks caused by certificate expiration or revocation, and provides a continuous and reliable identity anchor for the attribution of entities for reputation evidence counting.

[0103] S4.2: The smart contract maintains the performance channel evidence count for each entity based on the historical transaction results, defaults, and appeal rulings, and maintains the data compliance channel evidence count based on the verification results of its historical traceability records through zero-knowledge proofs. The performance channel evidence count and the data compliance channel evidence count constitute two independent channels of Beta-Bernoulli post-verification evidence.

[0104] In this embodiment, the smart contract deployed by the trading center maintains two independent evidence counters for each certified on-chain entity: one is the performance channel evidence count, which records the cumulative number of completed transactions (positive evidence), defaults (negative evidence), and appeal rulings (classified as positive or negative evidence according to the ruling results) in the entity's historical transactions; the other is the data compliance channel evidence count, which records the cumulative number of on-chain verifications that passed compliance zero-knowledge proof verification (positive evidence) and those that failed verification (negative evidence) in the historical traceability records submitted by the entity. These two types of counts are automatically updated by the smart contract after each transaction is completed or traceability record verification, constituting Beta-Bernoulli post-verification evidence for the two independent channels of performance and data compliance, respectively. The two channels are independent of each other, reflecting the credible history of the entity in terms of performance behavior and data compliance.

[0105] The classification rules for appeal rulings are pre-defined by a smart contract: when the appeal ruling is in favor of the appellant (i.e., the original judgment of breach of contract was incorrect), the performance result of the transaction is corrected from negative evidence to positive evidence, and the original negative evidence count is automatically cancelled; when the appeal ruling is in favor of the appellant (i.e., the breach of contract is established), the negative evidence count remains unchanged. These classification rules treat all parties equally and are automatically executed by the smart contract, preventing interference from any single party. This ensures that the evidence count in the performance channel always reflects the objective performance facts confirmed by arbitration, rather than any unilateral claim by any party, thus guaranteeing the objectivity and resistance to manipulation of the credit assessment from the perspective of evidence source.

[0106] S4.3: Calculate the trust expectation and uncertainty for the two independent channels respectively according to subjective logic. The sparser the evidence count of the data compliance channel, the higher the uncertainty of the data compliance channel.

[0107] The trading center uses a subjective logic framework to measure the trust in the Beta-Bernoulli post-verification evidence for two independent channels. Let α be the number of positive evidences and β be the number of negative evidences for a given channel. Then, the expected trust for that channel is E = α / (α+β+W), and the uncertainty is u = W / (α+β+W), where W is a priori weight constant. As the sum of the positive and negative evidence counts α+β increases, the uncertainty u gradually decreases. For new entrants or entities with sparse historical records, the sum of their evidence counts is smaller, resulting in higher uncertainty and a trust expectation biased towards a neutral prior, thus avoiding misjudgment as high trust due to a lack of negative evidence.

[0108] The core idea of ​​the subjective logic framework is to compensate for the shortcomings of traditional frequentist probability estimation in small-sample scenarios by introducing an uncertainty dimension. When an entity's historical evidence is extremely abundant, its trust expectation can converge relatively stably to its true historical reputation frequency. When historical evidence is sparse, subjective logic explicitly quantifies and presents this insufficiency to the decision-maker with a high degree of uncertainty, rather than providing a seemingly precise but unreliable point estimate. The introduction of uncertainty allows this invention to provide additional meta-information on "how reliable this assessment is" beyond trust expectation, providing a more complete information foundation for the dual-threshold admission criteria: the transacting party must not only pass the trust expectation assessment based on historical records but also the uncertainty assessment based on the sufficiency of evidence; both are indispensable, effectively preventing entities with sparse evidence but occasional good records from bypassing credit checks to enter high-value transactions.

[0109] Optionally, the setting of the prior weight constant reflects the system's neutral presupposition regarding new entrants in the absence of any evidence. Without any historical evidence, the system does not presuppose a subject as having high or low trust; instead, it sets its expected trust as the prior benchmark rate (typically corresponding to a neutral stance), while maximizing the uncertainty. This truthfully conveys the degree of unreliability of the current assessment to the counterparty, allowing the counterparty to decide whether to accept a transaction with a subject exhibiting higher uncertainty. This design demonstrates the system's full respect for participants' information rights while providing fair market access opportunities for new entrants, preventing them from being unreasonably discriminated against due to a lack of historical records. This allows the invention to maintain openness to new market participants while simultaneously managing risk.

[0110] S4.4: Filter out abnormal scores that deviate from the group distribution, and then weight and fuse the two independent channels to obtain the transaction subject profile.

[0111] After calculating the trust expectation and uncertainty for each channel, the trading center filters out abnormal scores that deviate from the overall distribution of the entity group (e.g., exceeding the mean ± 3σ range), eliminating extreme values ​​that may be caused by score manipulation or system anomalies, in order to resist attacks that artificially inflate reputation through fake transactions or bulk forgery of compliance records. Subsequently, the trust expectation and uncertainty of the performance channel and the data compliance channel are weighted and fused according to preset weights to obtain a comprehensive trust expectation and comprehensive uncertainty. Combined with the entity's trusted on-chain identity identifier, a trading entity profile with identity identifier, comprehensive trust expectation, and uncertainty is formed, providing a rigorous basis for trading access judgment.

[0112] It is worth noting that the aforementioned anomaly scoring filtering mechanism is technically based on periodically calculating the statistical distribution of the current trust expectation values ​​of all certified entities, identifying and marking extreme values ​​that deviate from the normal range of this distribution. The filtering operation only affects the input of the current fusion calculation and does not permanently modify the underlying Beta-Bernoulli post-validation data count. This means that the filtering operation is reversible: if an entity's abnormally high score is due to a genuine accumulation of a large number of legitimate transactions rather than score-boosting behavior, its extreme value will be encompassed by the statistical distribution over time, and the filtering mark will naturally be removed. Conversely, abnormally high scores generated by short-term concentrated score-boosting cannot be supported by new positive evidence after the concentrated score-boosting behavior stops, and the trust expectation tends to return to the normal range as new transactions gradually unfold. This mechanism balances the ability to resist score-boosting behavior with the fairness requirement of not unduly harming trustworthy and high-quality entities, enabling the anomaly filtering mechanism to adaptively adjust in a dynamic market environment.

[0113] Example 6

[0114] like Figure 4As shown, this embodiment further elaborates on step S4.3 based on embodiment 5.

[0115] S4.3.1: The transaction result in the performance channel evidence count is counted as positive evidence and the default result is counted as negative evidence, thus constituting the Beta-Bernoulli posterior of the performance channel.

[0116] For each entity's performance channel, the smart contract counts the final transaction results in the historical transactions as positive evidence (accumulated to parameter α), and counts the default results (including failure to deliver on time, unjustified breach of contract, and appeals that conclude that the entity is in breach) as negative evidence (accumulated to parameter β). The parameter pair (α, β) constitutes the Beta distribution posterior of the entity's performance channel, namely Beta(α+1, β+1) (using the uniform distribution of Beta(1,1) as the prior). This posterior distribution quantitatively reflects the overall credibility of the entity in its historical performance behavior.

[0117] The Beta distribution is suitable for posterior modeling of historical sequences of binary outcomes because it is the natural conjugate prior of Bernoulli trials. Its posterior form remains a Beta distribution, offering the mathematical convenience of closed-loop updates—each new positive or negative piece of evidence only requires incrementing the corresponding parameter to update the posterior, without needing to re-estimate the entire distribution. This makes it suitable for real-time incremental updates by smart contracts on-chain. Using a uniform distribution Beta(1,1) as the prior reflects a neutral stance that neither imposes excessive trust on new entrants nor is overly conservative. As positive and negative evidence gradually accumulates, the posterior distribution will gradually narrow and converge towards the subject's actual performance rate, ultimately forming a precise statistical characterization of the subject's historical performance behavior, providing a solid posterior foundation for subsequent subjective logical mapping.

[0118] S4.3.2: Records that pass the zero-knowledge proof verification in the data compliance channel evidence count are counted as positive evidence, and records that fail the verification are counted as negative evidence, thus forming the Beta-Bernoulli posterior of the data compliance channel.

[0119] For each entity's data compliance channel, the smart contract counts the zero-knowledge proof records that have passed verification by calling the verification key in the historical traceability records submitted by the entity as positive evidence (accumulated to parameter α), and the records that have failed verification as negative evidence (accumulated to parameter β). The parameter pair (α, β) constitutes the Beta distribution posterior of the entity's data compliance channel, namely Beta(α+1, β+1). This posterior distribution quantitatively reflects the entity's overall credibility in terms of data reporting compliance, and is independent of the performance channel, avoiding the cross-contamination of single-dimensional credibility.

[0120] Furthermore, the data compliance channel is modeled independently of the performance channel, preventing entities from using high scores in the performance channel to mask low scores in the data compliance channel, or vice versa. In practice, the following scenario may occur: an entity performs well in transaction performance (sufficient positive evidence), but the proportion of its submitted traceability records that pass zero-knowledge proof verification is low (more negative evidence). If the two types of evidence are modeled together, the entity's overall reputation may be obscured by its performance records, failing to draw sufficient attention from trading partners to the quality issues of its data reporting. The independent channel design ensures that the reputation of each dimension is presented to the decision-maker with independent Beta posterior values. Trading partners can review the entity's reputation in both dimensions separately, making more accurate risk assessments and improving the comprehensiveness and relevance of transaction access decisions.

[0121] S4.3.3: Based on the positive and negative evidence from the Beta-Bernoulli posterior, the trust expectation and uncertainty of each channel are mapped according to subjective logic, and the uncertainty increases as the sum of the positive and negative evidence decreases.

[0122] For each channel, based on its Beta-Bernoulli posterior positive evidence α and negative evidence β, the Beta posterior is mapped to a subjective opinion quadruple (confidence t, distrust d, uncertainty u, benchmark rate a) according to subjective logic, where confidence t = α / (α+β+W), distrust d, uncertainty u, benchmark rate a, and benchmark rate d, respectively. Uncertainty (W is the prior weight constant, usually W=2), Confidence Expectation (The benchmark rate 'a' is typically set to 0.5). As shown in the formula above, when α+β is small (evidence is sparse), the uncertainty u is close to 1, and the expected trust E is dominated by the benchmark rate 'a', leaning towards neutrality. As α+β increases, the uncertainty u approaches 0, and the expected trust E approaches α / (α+β), which is a frequency estimate based on historical evidence, gradually reflecting the entity's true creditworthiness. This mechanism ensures that newly entering entities or those with sparse historical records are not misjudged as having high trust due to a lack of negative evidence, while effectively resisting attempts to manipulate scores through false positive evidence, providing a rigorous mathematical basis for transaction access and risk control.

[0123] It should be understood that the above calculations of trust expectation and uncertainty reflect an assessment mechanism that dynamically converges with the accumulation of evidence. When the sum of positive and negative evidence for a certain channel is small (corresponding to new entrants or entities with scarce historical records), the uncertainty is close to its maximum value, and the trust expectation is mainly determined by the prior benchmark rate, leaning towards neutrality. As the sum of positive and negative evidence continues to increase, the uncertainty gradually decreases, and the trust expectation is increasingly determined by the proportion of positive evidence in historical evidence, eventually converging to the entity's historical true performance. This convergence process ensures that the system's trust assessment of entities becomes increasingly accurate and stable over time: new entrants will not be permanently excluded due to high initial uncertainty; as long as they continue to accumulate positive evidence, their trust assessment will gradually stabilize at a level consistent with their true performance, achieving a dynamic and fair assessment of both new and old market participants, while balancing risk control and market openness.

[0124] Example 7

[0125] like Figure 5 As shown, this embodiment further elaborates on step S5 based on embodiment 1.

[0126] S5.1: Requires both the buyer and seller to sign an on-chain smart contract with machine-readable conditions to agree on the price, delivery, quality objection and settlement rules under the dual access conditions of identity authentication, comprehensive trust expectation not lower than the access threshold and uncertainty not higher than the upper limit threshold.

[0127] When a buyer and seller initiate a transaction, the trading center first verifies their identities (see step S4.1) and reads their comprehensive trust expectation and comprehensive uncertainty from their respective transaction profiles. The system only allows both parties to proceed to the contract signing stage if both the buyer's and seller's comprehensive trust expectation is not lower than the system's preset entry threshold (e.g., 0.6) and their comprehensive uncertainty is not higher than the upper limit threshold (e.g., 0.4). This dual entry condition design requires both that the parties have an acceptable historical credit level and that this credit assessment is based on sufficient evidence, thus preventing new entrants with sparse evidence from bypassing credit checks to enter the transaction. After the dual entry conditions are met, the buyer and seller sign an on-chain smart contract using digital signatures. The contract, in a machine-readable format, clearly stipulates the transaction price, delivery standards, quality dispute handling rules, and fund settlement conditions. The contract text is hashed and stored in the blockchain ledger.

[0128] It should be understood that the machine-readable design of the aforementioned on-chain smart contracts requires all contract terms to be encoded in a form that can be directly parsed and executed by a computer, rather than natural language text. Specifically, price terms are encoded with precise numerical values ​​and currency units; delivery standard terms are encoded with structured fields (such as the number of cattle, weight range, and quality grade codes) that can be matched with data submitted by oracles; quality objection handling rules are encoded in the form of logical judgments such as objection deadlines, evidentiary requirements, and adjudication trigger conditions; and fund settlement conditions are encoded with Boolean logic expressions of pre-success conditions (passing of performance evidence, passing of member proof, and passing of zero-knowledge proof). This machine-readable encoding ensures that there is no step in the contract execution process that requires manual interpretation of contract terms, reducing the risk of disputes caused by disagreements in the interpretation of terms, and providing a strict logical basis for the fully automated execution of smart contracts, enabling all parties to the transaction to have complete pre-emptive knowledge and post-event traceability of the contract execution rules.

[0129] S5.2: When the delivery certificate and quality inspection conclusion submitted by the oracle or authorized node meet the conditions of the on-chain smart contract, and the member proof and the zero-knowledge proof in the corresponding traceability link are both verified, the on-chain smart contract will automatically advance the transaction status.

[0130] During the transaction fulfillment process, oracles or authorized third-party nodes (such as official quarantine agencies or logistics platforms) submit delivery documents (such as signed receipts or delivery slips) and quality inspection conclusions (such as quality certificates) to the smart contract. The smart contract automatically compares the above-mentioned fulfillment evidence with the contract terms, and simultaneously calls the accumulator verification interface to verify the member proof of the corresponding traceability link (confirming that the link is recorded on the chain and has not been tampered with), and calls the zero-knowledge proof verification interface to verify the corresponding compliant zero-knowledge proof (confirming that the record has passed compliance verification). Only when the triple verification of fulfillment evidence, member proof, and zero-knowledge proof passes, the smart contract automatically advances the transaction status from "pending delivery" to "delivery confirmation" or "pending settlement," without any manual intervention, reducing the possibility of human manipulation.

[0131] The introduction of oracles is a key technical means to bring off-chain real-world events (such as physical delivery and receipt, and on-site quality inspection) into on-chain smart contracts. In this invention, oracle nodes must undergo the same digital certificate authentication process as the subject's identity authentication to submit data to the smart contract with a trusted on-chain identity, ensuring the traceability of their data source. For scenarios involving quality disputes, multiple independent authorized verification nodes can be introduced. The smart contract aggregates the quality inspection conclusions submitted by multiple parties according to the majority confirmation rule to reduce the impact of a single oracle node failure or malicious behavior on the transaction results. The data submitted by the oracle is cross-checked with the on-chain, solidified traceability records at the smart contract level. If the submitted quality inspection conclusion has a significant inconsistency with the on-chain verified and compliant traceability records, the smart contract will suspend automatic processing and trigger a manual arbitration process to prevent erroneous settlements caused by abnormal oracle data, ensuring that the triple verification mechanism has manual fallback capabilities in abnormal situations.

[0132] S5.3: Trigger fund settlement and confirmation of rights transfer, write the performance result of this transaction back to the performance channel evidence count, and incorporate the transaction record as a new link element into the cryptographic accumulator, and output the trusted transaction record that has completed the confirmation of rights and settlement.

[0133] Once the transaction progresses to the point where settlement conditions are met, the smart contract automatically triggers the release and transfer of pre-locked funds, completing the settlement between the buyer and seller, and simultaneously recording the transfer of ownership of the beef cattle on the blockchain ledger (ownership from seller to buyer). After settlement, the smart contract writes the objective performance result (transaction) of this transaction back to the respective performance channel evidence counts of the seller and buyer via on-chain write, updating their Bayesian reputation posterior parameters. Simultaneously, this transaction record is incorporated as a new element (obtained by concatenating the target identifier, "transaction" stage type, and transaction record commitment hash) into the target's lifecycle cryptographic accumulator, updating the accumulator commitment and generating new witnesses, thus extending the traceability chain after the transaction. Finally, a complete and reliable transaction record is output, fully documenting the confirmation and settlement results of this transaction, forming a continuously updated dual closed loop of reputation assessment and traceability chain.

[0134] Regarding the on-chain recording of ownership transfers, the blockchain ledger uses the identifier of the beef cattle as an index to record each ownership transfer event (including the trusted on-chain identity of the transferor, the trusted on-chain identity of the recipient, the transaction timestamp, and the corresponding trusted transaction record hash), forming the on-chain property rights history of the asset. Before initiating a new round of transactions for the beef cattle asset, any subsequent entity can confirm the current ownership by querying the on-chain property rights history, without needing to trust the property rights claims of any intermediary platform, fundamentally eliminating the root cause of frequent property rights disputes in traditional transactions. The linkage between the ownership confirmation record and the lifecycle accumulator also ensures that the new owner can verify the integrity of the records of each previous stage of the asset through member proofs when receiving the asset, effectively reducing the risk of information asymmetry in cross-entity transactions, and enabling the buyer to independently verify the complete traceability chain of the asset before taking delivery.

[0135] Example 8

[0136] This embodiment, based on embodiment 4, further illustrates the binding effect of commitments in cryptographic accumulator elements and the mechanism for preventing data substitution.

[0137] Since the accumulator element contains the commitment, the data proven compliant by the zero-knowledge proof and the data solidified by the cryptographic accumulator are bound by the same commitment, and the compliance proof and integrity commitment in the transaction chain integrity provability conclusion point to the same data.

[0138] An accumulator element e = Hash(Target Identifier || Element Type || Commitment C), where commitment C is a cryptographic binding to the original record content. The compliance zero-knowledge proof uses commitment C as public input to prove that the original data satisfies the corresponding compliance assertion; the accumulator membership proof proves that the accumulator element e containing commitment C exists in the on-chain lifetime accumulator and has not been tampered with. Since the compliance proof and integrity proof are both bound to the same commitment C, any data substitution attack attempting to use the compliance proof for one content while corresponding the integrity commitment to another will fail: if the attacker replaces the record content, the corresponding commitment C will be inconsistent, and the compliance zero-knowledge proof will fail verification; if the attacker replaces commitment C, the accumulator element e will be inconsistent, and the membership proof will fail verification. This mechanism ensures that the compliance proof and integrity commitment in the transaction chain integrity verifiable conclusion always point to the same original data, cryptographically eliminating the possibility of data substitution and guaranteeing the inherent consistency between traceability compliance credibility and the on-chain integrity conclusion.

[0139] Furthermore, from the perspective of information security threat models, the data substitution attacks protected by the commitment binding mechanism can be specifically broken down into the following scenarios: First, compliance proof reuse attack—an attacker attempts to use a zero-knowledge proof generated for the content of a compliant record to prove the compliance of another piece of content; since the compliance zero-knowledge proof uses the commitment C of the original record as public input, the verifier will compare the commitment value during verification. If it does not match the commitment of the target record, the proof will be directly invalid, and the attack will fail. Second, accumulator member forgery attack—an attacker attempts to use a member proof of a verified record to prove another tampered record on the chain; since the accumulator element contains commitment C, and the element value changes with the content, the tampered record cannot generate a valid member proof corresponding to the original element, and this attack will also fail. Third, commitment replacement attack—an attacker attempts to replace the compliance zero-knowledge proof associated with the member proof while retaining the validity of the member proof; since the compliance zero-knowledge proof and the accumulator element share the same commitment C, any replacement of commitment C will simultaneously destroy the validity of the compliance proof or the member proof, making consistent replacement impossible. Fourth, the new record impersonation attack—an attacker attempts to forge a record that has never been added to the chain and generate a false membership proof for it; since the security guarantee of the accumulator is based on the assumption of computational difficulty, generating a valid membership proof for an element that has never been included is computationally infeasible without being able to manipulate the accumulator state. All four attack scenarios mentioned above are covered by the commitment binding mechanism, ensuring the comprehensive credibility of the verifiable conclusions regarding the integrity of the transaction chain, and providing a solid cryptographic foundation for the overall security of the present invention.

[0140] Furthermore, the aforementioned commitment binding mechanism also has significant legal evidentiary value. When disputes arise from transactions requiring judicial evidence, the shared nature of the membership proof and the compliance zero-knowledge proof, bound to the same commitment C, creates a mutually corroborating chain of on-chain evidence: the membership proof demonstrates that a record was indeed registered on the chain at a certain stage of its lifecycle, while the compliance zero-knowledge proof proves that the record's content meets the corresponding compliance standards. The shared commitment C ensures that both proofs point to the same original data, forming a complete closed loop of on-chain evidence. This provides judicial institutions with an objective chain of evidence supported by cryptography, possessing a strong legal admissibility foundation and helping to shift the burden of proof in tracing disputes from manual evidence collection to machine-readable cryptographic proofs.

[0141] Example 9

[0142] This embodiment, based on Embodiment 1, further illustrates the mechanism for ensuring the immutability of the blockchain ledger.

[0143] The blockchain ledger is solidified by distributed node consensus. The lifecycle accumulator commitment written into the blockchain ledger, the on-chain verification entry of each zero-knowledge proof, and the trusted transaction record are immutable after being agreed upon by the distributed nodes.

[0144] The blockchain network upon which this invention is based consists of multiple geographically dispersed distributed nodes. Each data write operation is confirmed by a majority of nodes across the network through a consensus mechanism (such as Byzantine Fault Tolerance (BFT) or Proof-of-Stake (PoS). The Lifetime Accumulator Commitment (ACC), the on-chain verification entry points for each compliant zero-knowledge proof (such as proof hashes or verification contract addresses), and each trusted transaction record, after being submitted by any node, must undergo network-wide consensus verification before being written into the blockchain ledger. Once written, it forms a block of data with a chained hash pointer. Any subsequent attempt to tamper with the written data will destroy the hash chain integrity of that block and all subsequent blocks, and will be immediately detected and rejected in the network consensus. This mechanism ensures that any third party can independently verify the authenticity and tamper-proof status of the data by accessing the blockchain ledger without trusting any single platform. This upgrades the original anti-tampering mechanism, which relied on internal platform logic, to a cryptographic and consensus guarantee that can be independently verified by any third party.

[0145] Furthermore, the immutability of the blockchain ledger stems not only from the multi-node confirmation of write operations through the consensus mechanism but also from the chain-like hash integrity guarantee inherent in the blockchain data structure itself. Specifically, each block in the blockchain contains the complete hash value of the previous block in its block header, forming a chain of hash pointers covering all historical blocks. When a malicious party attempts to modify data already written in a historical block, the change in the block's content will alter its hash value, causing all subsequent blocks' header hash values ​​to no longer match. This anomaly will be detected and rejected by all honest nodes during the network-wide consensus verification. This integrity guarantee at the data structure level, combined with the write confirmation at the consensus mechanism level, forms a double anti-tampering barrier, ensuring the long-term trustworthiness of the accumulator commitment, the zero-knowledge proof verification entry point, and the trusted transaction records after they are written into the ledger.

[0146] Regarding node network design, the blockchain network to which this invention is applicable can choose between a consortium blockchain or a public blockchain architecture, depending on regulatory requirements and business scenarios. In a consortium blockchain architecture, the ledger nodes are jointly composed of representatives from the beef cattle trading regulatory agency, core trading entities, and third-party auditing institutions. Employing a Byzantine fault-tolerant consensus algorithm, it provides high transaction throughput and low confirmation latency under certain access controls, making it suitable for production deployment scenarios that require compliance with regulatory requirements. In a public blockchain architecture, any node holding a copy of the ledger can participate in verification, providing the highest degree of decentralization and censorship resistance, making it suitable for scenarios that require open traceability verification access to the public. Under both architectures, the accumulator commitment and the immutability guarantee of trusted transaction records are both valid, allowing for flexible selection based on the actual deployment environment. This achieves an optimal balance between transaction efficiency and decentralization, ensuring the technical solution of this invention has broad engineering applicability.

[0147] Example 10

[0148] like Figure 6 As shown, this embodiment provides a digital beef cattle trading system, and the functional entities corresponding to each step in the above method embodiment are as follows.

[0149] The standardized access module 601 receives raw messages submitted by multiple entities through heterogeneous information systems. It parses business semantic fields according to a pre-defined EDI standard and maps them to a public XML schema, uniformly converting them into standardized data objects. These are then aggregated into a standardized traceability dataset based on the beef cattle's identifier. The standardized access module 601 has a built-in EDI parsing engine and a public XML schema mapping layer, providing a unified data receiving interface to receive raw messages from heterogeneous systems of multiple entities, including farms 201, slaughterhouses 202, quarantine agencies 203, and logistics providers 204. The pre-defined EDI standard parser 205 performs semantic-level parsing on the raw messages, extracting breeding records, health quarantine records, and circulation information with varying field definitions and encoding rules. Subsequently, the public XML schema mapping layer 206 uniformly converts the parsed fields into standardized data objects 207, and aggregates them into a standardized traceability dataset 208 based on individual beef cattle identifiers or batch identifiers. This eliminates data format differences and customization burdens caused by heterogeneous systems, providing a unified and standardized data foundation for subsequent compliance certificate generation and accumulator construction.

[0150] The pre-built EDI standard parser 205 incorporates a semantic rule base for agricultural and livestock product trading scenarios. It can identify business entities (such as beef cattle identifiers, quarantine agencies, and cold chain equipment) and their attribute relationships in EDI messages of different formats. During parsing, it automatically performs field integrity checks and business logic consistency checks (e.g., quarantine date is no later than slaughter date). For messages that do not meet basic business logic requirements, the standardized access module 601 will refuse access and return specific error feedback to the submitter, guiding the subject to correct the message and resubmit. This ensures the basic quality of the standardized traceability dataset from the data access source, reduces the risk of subsequent cryptographic processing anomalies due to data quality defects, and clearly assigns data quality responsibility to each submitter, forming an automated closed-loop data quality management mechanism.

[0151] The compliance proof module 602 is used to calculate cryptographic commitments for sensitive fields in the standardized traceability dataset and generate zero-knowledge proofs that prove the original data satisfies pre-set compliance assertions, using the commitments as public inputs, thus obtaining a standardized traceability dataset with commitments and compliance proofs. The compliance proof module 602 supports data holders in calculating cryptographic commitments 209 locally for sensitive fields including breeding costs, formulas, and complete quarantine records; for pre-set compliance assertions such as legal origin, qualified quarantine, and cold chain temperature, it generates corresponding zero-knowledge proofs 210 using commitment 209 as public inputs; the compliance proof module 602 associates commitment 209 and zero-knowledge proof 210 with the corresponding standardized data records, forming a standardized traceability dataset 211 with commitments and compliance proofs. This provides verifiable compliance proofs to any third party without exposing commercial privacy, resolving the dilemma of "untrustworthy if not reported, and privacy leaked if reported."

[0152] At the system integration level, the compliance proof module 602 provides data holders with a locally deployed proof generation toolkit. This toolkit encapsulates proof circuits and proof keys for different types of compliance assertions (legal origin, quarantine compliance, temperature range). Data holders can run this toolkit locally to complete commitment calculation and zero-knowledge proof generation. After generation, the commitment and proof (excluding original field values) are uploaded to the compliance proof module 602 for associated storage. Throughout the entire process, the original sensitive field values ​​never leave the holder's local environment. The compliance proof module 602 has a built-in format validator that performs basic format legality checks on the received zero-knowledge proofs to ensure they conform to the structural specifications of the expected proof scheme. It then associates and stores the proof with the corresponding traceability record, providing an accurate data index for subsequent on-chain verification and ensuring the quality of input data in the on-chain verification process.

[0153] The accumulator verification module 603 is used to generate lifecycle accumulator commitments and witnesses based on the standardized traceability dataset with commitments and compliance proofs, and write the lifecycle accumulator commitments and the on-chain verification entry points of each zero-knowledge proof into the blockchain ledger. It provides member proofs for on-chain records and non-member proofs for missing link anchors, thereby obtaining a verifiable conclusion on the integrity of the transaction chain bound by the commitments. The accumulator verification module 603 generates an accumulator element 301 for each traceability record, with the hash of "target identifier || link type || commitment" as its content. This element is then incorporated into the cryptographic accumulator in lifecycle order. Simultaneously, deterministic link anchors 302 for each essential link are generated and incorporated. The accumulator commitment 303 and the zero-knowledge proof verification entry are written into the blockchain ledger 606. The smart contract calls the verification key to verify compliance proofs one by one and marks them as verified and compliant. During verification, member proofs 304 and non-member proofs 305 are generated respectively to cryptographically confirm the integrity of the on-chain record and the absence of essential links. Based on commitment binding, the substitution of compliance and integrity proofs is prevented, upgrading integrity verification from heuristic comparison to verifiable cryptographic conclusions.

[0154] It should be noted that the accumulator verification module 603 incorporates a dynamic witness update algorithm. After a new element is added to the accumulator, it automatically updates the membership witnesses of all existing elements and anchor points, ensuring that existing witnesses always remain consistent with the latest accumulator commitment state. This update mechanism is particularly important for long-lifecycle beef cattle tags: as new lifecycle records are continuously added, the witnesses of early-stage records (such as breeding) need to be updated accordingly to generate valid membership proofs based on the latest accumulator commitment. The accumulator verification module 603 associates and stores witness data with corresponding records and automatically maintains this as the accumulator state is updated, ensuring that valid membership proofs based on the current accumulator commitment can be generated at any time. This eliminates the need for the caller to maintain the temporal consistency of witness data, significantly reducing the technical threshold for integrating the traceability verification system.

[0155] The reputation assessment module 604 is used to perform digital certificate identity authentication on each party based on the verifiable conclusion of the integrity of the transaction chain to obtain a trusted on-chain identity. Based on the performance results and data compliance verification, it maintains the Beta-Bernoulli post-verification data of the performance channel and the data compliance channel respectively. It calculates the trust expectation and uncertainty of each channel according to subjective logic, filters abnormal scores, and then weights and fuses them to obtain a profile of the transaction entity with identity identification, comprehensive trust expectation and uncertainty. The reputation assessment module 604 integrates a PKI identity authentication component to verify the digital certificates of all parties involved and bind their trusted on-chain identities. Through on-chain smart contracts, it maintains the Beta-Bernoulli posterior distribution 401 for the performance channel and the Beta-Bernoulli posterior distribution 402 for the data compliance channel for each entity. Based on a subjective logic framework, it calculates the trust expectation 403 and uncertainty 404 for each channel. After removing extreme values ​​that deviate from the group distribution through the anomaly scoring filter 405, it weights and merges the two channels to generate a comprehensive trust profile 406 with uncertainty. This provides a reasonable uncertainty reflection for new entrants with sparse evidence, effectively resists score-brushing attacks, and provides a rigorous basis for transaction access.

[0156] Regarding inter-module collaboration, the Beta-Bernoulli posterior distribution update of the reputation assessment module 604 is triggered by the contract execution module 605 through on-chain write after each transaction. This ensures that the reputation data update operation itself is also solidified by blockchain consensus and cannot be unilaterally revoked or tampered with, fundamentally preventing the platform from manipulating transaction access by modifying reputation data. The reputation assessment module 604 provides a trusted on-chain query interface, through which any third party can query the current trust expectation and uncertainty of a specific entity (reading only the solidified posterior parameters on the chain) to independently verify the entity's reputation status without relying on unilateral data provided by the platform, fully guaranteeing the public accessibility and objective verifiability of reputation information.

[0157] The contract execution module 605 is used to sign an on-chain smart contract based on the profile of the transaction subject, provided that the comprehensive trust expectation is not lower than the admission threshold and the uncertainty is not higher than the upper limit threshold. When the performance evidence, the corresponding member proof, and the zero-knowledge proof are all verified, the transaction status is advanced and settlement and confirmation of rights are executed. The performance result is written back to the performance channel evidence, the transaction record is included in the cryptographic accumulator, and a trusted transaction record is output. The contract execution module 605 performs dual-threshold access verification 501 based on the transaction entity profile output by the reputation assessment module 604, and facilitates the signing and deployment of the on-chain smart contract 502 for buyers and sellers who meet the dual conditions of trust expectation and uncertainty. During the transaction performance process, the contract execution module 605 receives performance evidence submitted by the oracle or authorized node 503, and, in conjunction with the accumulator verification module 603 and the compliance proof module 602, completes triple verification 504 of member proof and zero-knowledge proof, driving the transaction status to advance automatically and triggering fund settlement and confirmation of rights transfer 505. After settlement is completed, the contract execution module 605 writes back the transaction performance result and transaction record to the performance channel evidence counter and cryptographic accumulator 506 of the reputation assessment module 604, and outputs a credible transaction record 507 that has completed confirmation of rights and settlement, forming a dual continuous closed loop of reputation assessment and traceability chain.

[0158] In terms of system reliability design, the contract execution module 605 performs full on-chain notarization of the smart contract execution results: each contract state advancement generates a corresponding state transition record, writes it to the blockchain ledger, and includes evidence of the conditions triggering the state transition (such as the hash of the oracle submission certificate, the member proof verification result marker, and the zero-knowledge proof verification result marker), forming a complete contract execution trajectory that can be used for post-event auditing and dispute arbitration. When any of the triple checks fails, the contract execution module 605 does not advance the transaction state and records the specific conditions that failed on the chain, providing relevant parties with a clear reason for the failure, guiding them to supplement or correct the corresponding evidence and resubmit, avoiding unnecessary disputes caused by the lack of transparency in the reasons for verification failure, and improving the overall user experience and dispute resolution efficiency of the transaction system.

[0159] Those skilled in the art should understand that the above embodiments are merely illustrative of specific implementations of the present invention and are not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, or improvements made within the spirit and principles of the present invention should be included within the scope of protection of the claims of the present invention.

Claims

1. A digital method for trading beef cattle, characterized in that, include: It receives original messages submitted by multiple entities through heterogeneous information systems, parses business semantic fields according to the preset EDI standard and maps them to the public XML schema, converts them into standardized data objects, and collects them into standardized traceability datasets according to the identification of beef cattle. For the sensitive fields in the standardized traceability dataset, cryptographic commitments are calculated, and zero-knowledge proofs are generated that use the commitments as public inputs to prove that the original data satisfies the pre-defined compliance assertions, thus obtaining a standardized traceability dataset with commitments and compliance proofs. Based on the standardized traceability dataset with commitment and compliance proof, a lifecycle accumulator commitment and witness are generated, and the on-chain verification entry of the lifecycle accumulator commitment and each zero-knowledge proof is written into the blockchain ledger. Membership proof is given for on-chain records, and non-member proof is given for missing link anchors, so as to obtain the transaction chain integrity verifiable conclusion that compliance and integrity are bound by the commitment. Based on the verifiable conclusion of the transaction chain integrity, digital certificate identity authentication is performed on all parties to obtain a trusted on-chain identity. Based on their performance results and data compliance verification, Beta-Bernoulli post-verification evidence for the performance channel and the data compliance channel are maintained respectively. The trust expectation and uncertainty of each channel are calculated according to subjective logic, and after filtering out abnormal scores, they are weighted and fused to obtain a profile of the transaction entity with identity identification, comprehensive trust expectation and uncertainty. Based on the profile of the transaction entity, a smart contract is signed on the blockchain under the condition that the comprehensive trust expectation is not lower than the admission threshold and the uncertainty is not higher than the upper limit threshold. When the performance evidence, the corresponding member proof, and the zero-knowledge proof are all verified, the transaction status is advanced and settlement and confirmation of rights are executed. The performance result is written back to the performance channel evidence, the transaction record is included in the cryptographic accumulator, and a reliable transaction record is output.

2. The method according to claim 1, characterized in that, It receives raw messages submitted by multiple entities through heterogeneous information systems, parses business semantic fields according to a pre-defined EDI standard and maps them to a common XML schema, uniformly converts them into standardized data objects, and aggregates them into a standardized traceability dataset according to the identification of beef cattle, including: Receive original messages submitted by farms, slaughterhouses, quarantine agencies and logistics providers through their respective heterogeneous information systems; Based on the preset EDI standard, the breeding records, health quarantine records and transfer information in the original message, which have different field definitions and encoding rules, are parsed. The parsed fields are mapped to the public XML schema and converted into standardized data objects; The standardized data objects are grouped according to individual cattle identifiers or batch identifiers to obtain the standardized traceability dataset.

3. The method according to claim 1, characterized in that, For sensitive fields in the standardized source tracing dataset, cryptographic commitments are calculated, and zero-knowledge proofs are generated using the commitments as public input to prove that the original data satisfies a pre-defined compliance assertion, resulting in a standardized source tracing dataset with commitments and compliance proofs, including: The data holder calculates the cryptographic commitment locally for sensitive fields including breeding costs, formulas, and complete quarantine records; For the pre-defined compliance assertions that include legal origin, qualified quarantine, and cold chain temperature within the specified range, generate the zero-knowledge proof with the commitment as public input, so that the zero-knowledge proof can prove that the original data satisfies the pre-defined compliance assertions without exposing the original fields; The commitment and the corresponding zero-knowledge proof are submitted together with the standardized traceability dataset to obtain the standardized traceability dataset with commitment and compliance proof.

4. The method according to claim 1, characterized in that, Based on the standardized traceability dataset with commitments and compliance proofs, a lifecycle accumulator commitment and witnesses are generated. The lifecycle accumulator commitments and the on-chain verification entries of each zero-knowledge proof are written into the blockchain ledger. Membership proofs are provided for on-chain records, and non-membership proofs are provided for missing link anchors. This yields a verifiable conclusion regarding the integrity of the transaction chain bound by the commitments, including: For each record, generate an accumulator element obtained by hashing the concatenation of the target identifier, the stage type, and the commitment of the record; The elements of each stage are incorporated into the cryptographic accumulator one by one according to the life cycle sequence of breeding, quarantine, slaughter and circulation; For a pre-defined set of essential lifecycle stages, a deterministic stage anchor is generated for each essential stage, which is determined solely by the target identifier and the stage type and is independent of the specific record content. This anchor is then incorporated into the cryptographic accumulator to obtain the lifecycle accumulator commitment and the witnessing of each element and anchor. The lifecycle accumulator commitment, the transaction target identifier, and the on-chain verification entry of each zero-knowledge proof are written into the blockchain ledger, solidified by the consensus of distributed nodes, and the smart contract calls the verification key to verify each zero-knowledge proof. Records that pass the verification are marked as verified and compliant. When verification is initiated, the member proof of a constant size is given for the records claimed to be on the chain using their witnesses. For the links that should be registered according to the set of essential links in the lifecycle, member or non-member proof is given for the deterministic link anchor. If the deterministic link anchor does not exist, the missing link is confirmed and located, and the conclusion that the integrity of the transaction chain can be proven is obtained.

5. The method according to claim 1, characterized in that, Based on the verifiable conclusion of the transaction chain integrity, digital certificate authentication is performed on all parties to obtain trusted on-chain identities. Beta-Bernoulli post-verification data for the performance channel and data compliance channel are maintained according to their performance results and data compliance verification status. Trust expectation and uncertainty for each channel are calculated subjectively, and after filtering out abnormal scores, a weighted fusion is performed to obtain a transaction entity profile with identity identifiers, comprehensive trust expectation, and uncertainty, including: Digital certificate authentication is performed on all parties initiating or participating in the transaction to confirm the binding relationship between the on-chain identity and the real entity, thereby obtaining the trusted on-chain identity; The smart contract maintains the performance channel evidence count for each entity based on the historical transaction results, defaults, and appeal rulings, and maintains the data compliance channel evidence count based on the verification results of its historical traceability records through zero-knowledge proofs. The performance channel evidence count and the data compliance channel evidence count constitute the Beta-Bernoulli post-verification evidence for two independent channels. The trust expectation and uncertainty are calculated for the two independent channels according to subjective logic. The sparser the evidence count of the data compliance channel, the higher the uncertainty of the data compliance channel. Abnormal scores that deviate from the group distribution are filtered out, and then the two independent channels are weighted and merged to obtain the profile of the transaction subject.

6. The method according to claim 5, characterized in that, The trust expectation and uncertainty are calculated separately for the two independent channels according to subjective logic. The sparser the evidence count of the data compliance channel, the higher the uncertainty of the data compliance channel, including: The transaction results in the performance channel evidence count are counted as positive evidence, and the default results are counted as negative evidence, thus forming the Beta-Bernoulli posterior of the performance channel. Records that pass the zero-knowledge proof verification in the data compliance channel evidence count are counted as positive evidence, and records that fail the verification are counted as negative evidence, thus constituting the Beta-Bernoulli posterior of the data compliance channel. Based on the positive and negative evidence from the Beta-Bernoulli posterior, the trust expectation and uncertainty of each channel are mapped according to subjective logic, and the uncertainty increases as the sum of the positive and negative evidence decreases.

7. The method according to claim 1, characterized in that, Based on the aforementioned transaction entity profile, and under the condition that the overall trust expectation is not lower than the admission threshold and the uncertainty is not higher than the upper limit threshold, an on-chain smart contract is signed. When the performance evidence, corresponding member proof, and zero-knowledge proof are all verified, the transaction status is advanced and settlement and confirmation of rights are executed. The performance result is written back to the performance channel evidence, the transaction record is included in the cryptographic accumulator, and a trusted transaction record is output, including: The buyer and seller are required to sign an on-chain smart contract with machine-readable conditions to agree on price, delivery, quality objection and settlement rules, under the dual access conditions of identity authentication, comprehensive trust expectation not lower than the access threshold and uncertainty not higher than the upper limit threshold. When the delivery certificate and quality inspection conclusion submitted by the oracle or authorized node meet the conditions of the on-chain smart contract, and the member proof and the zero-knowledge proof in the corresponding traceability link are both verified, the on-chain smart contract will automatically advance the transaction status. Triggering fund settlement and confirmation of rights transfer, the performance result of this transaction is written back to the performance channel evidence count, and the transaction record is included as a new element in the cryptographic accumulator, outputting the trusted transaction record that completes the confirmation of rights and settlement.

8. The method according to claim 4, characterized in that, Since the accumulator element contains the commitment, the data proven compliant by the zero-knowledge proof and the data solidified by the cryptographic accumulator are bound by the same commitment, and the compliance proof and integrity commitment in the transaction chain integrity provability conclusion point to the same data.

9. The method according to claim 1, characterized in that, The blockchain ledger is solidified by distributed node consensus. The lifecycle accumulator commitment written into the blockchain ledger, the on-chain verification entry of each zero-knowledge proof, and the trusted transaction record are immutable after being agreed upon by the distributed nodes.

10. A digital beef cattle trading system, characterized in that, include: The standardized access module is used to receive original messages submitted by multiple entities through heterogeneous information systems, parse business semantic fields according to the preset EDI standard and map them to the public XML schema, uniformly convert them into standardized data objects, and collect them into standardized traceability datasets according to the identification of beef cattle. The compliance proof module is used to calculate cryptographic commitments for sensitive fields in the standardized traceability dataset and generate zero-knowledge proofs that prove the original data satisfies the pre-defined compliance assertions, with the commitments as public inputs, thus obtaining a standardized traceability dataset with commitments and compliance proofs. The accumulator verification module is used to generate lifecycle accumulator commitments and witnesses based on the standardized traceability dataset with commitments and compliance proofs, and write the lifecycle accumulator commitments and the on-chain verification entry of each zero-knowledge proof into the blockchain ledger. It provides member proofs for on-chain records and non-member proofs for missing link anchors, and obtains the transaction chain integrity verifiable conclusion that compliance and integrity are bound by the commitments. The reputation assessment module is used to verify the identity of each party through digital certificates based on the verifiable conclusion of the integrity of the transaction chain to obtain a trusted on-chain identity. Based on the performance results and data compliance verification, it maintains the Beta-Bernoulli post-verification data of the performance channel and the data compliance channel respectively. It calculates the trust expectation and uncertainty of each channel according to subjective logic, filters abnormal scores, and then weights and fuses them to obtain a profile of the transaction entity with identity identification, comprehensive trust expectation and uncertainty. The contract execution module is used to sign on-chain smart contracts based on the profile of the transaction subject, provided that the comprehensive trust expectation is not lower than the admission threshold and the uncertainty is not higher than the upper limit threshold. When the performance evidence, the corresponding member proof, and the zero-knowledge proof are all verified, the transaction status is advanced and settlement and confirmation of rights are executed. The performance result is written back to the performance channel evidence, the transaction record is included in the cryptographic accumulator, and a trusted transaction record is output.

Images