An arXiv preprint testing TrustRAG, a blockchain-backed retrieval-augmented generation system that certifies documents before they are used in an AI-generated answer, found a sharp difference between two cryptographic proof methods: Groth16 generated vote-circuit proofs faster than PLONK at every tested Merkle depth. At depth 20, Groth16 took 1,624.51 milliseconds, compared with 9,946.89 milliseconds for PLONK.
The result is a performance finding about a software prototype, not a demonstration that the system gives correct answers. The design is meant to make credibility scores privacy-preserving and client-verifiable, bind results across chains and allow deterministic replay of the ranking process.
This was a prototype benchmark
The paper is a methods study built around a software prototype and computational benchmark data. Its evaluation covered configured vote circuits, chain-local tally workloads and committee-scaling tests rather than a human or clinical population. The comparisons were internal: Groth16 versus PLONK, full versus ablated protocol variants and different engineering configurations.
The reported configuration used a score bound of 10, a committee of four and a threshold of three. Tests were run on a MacBook Pro with an Apple M1 Pro processor and 32GB of memory on macOS.
Those comparisons do not include an external RAG baseline. The paper also reports no variance estimate, confidence interval or inferential statistical analysis, so the timings describe the tested configurations rather than a measured range of likely performance across other systems or workloads.
How TrustRAG builds its trust layer
Document anchors are registered as immutable records before they are used. Validators submit private evaluations; TrustRAG aggregates hidden scores with Shamir sharing and MP-SPDZ, then binds the outputs from each chain so a later verifier can replay the same result. The goal is to attach a checkable credibility layer to document-based AI retrieval without exposing each validator’s individual score.
The prototype used a Circom zero-knowledge circuit, a way to check a computation while keeping its underlying inputs hidden, and Solidity verification on a Hardhat EDR simulated network. In the benchmark, the circuit was used to test whether submitted votes met the protocol’s validity rules.
The main costs were uneven
The strongest timing contrast appeared in proof generation. Across all tested Merkle depths, Groth16’s proving time was substantially lower than PLONK’s. At depth 20, the two measurements were 1,624.51 ms and 9,946.89 ms, respectively. In that benchmark, Groth16 was the faster option.
The files needed to represent the circuit did not all grow in the same way. The R1CS artifact measured 702 KB at depth 8 and 3.6 MB at depth 50, while the compiled WASM artifact stayed in an approximately 1.7–1.9 MB range. The measured pattern was therefore different across the two artifact types as the tree became deeper.
For chain-local tallying, total latency remained around 1.1 seconds in the three reported workloads: 1123.24 ms for 20 votes, 1117.12 ms for 50 votes and 1118.86 ms for 100 votes. In this test, adding votes did not produce a corresponding increase in the total measured delay.
The cost breakdown identifies threshold authorization as the main source of tally delay. Pedersen commitments and Shamir operations were small compared with the total, according to the reported profile. The authorization step carried most of the measured overhead in this prototype.
In separate committee-scaling tests, BLS aggregation and Shamir reconstruction were reported to grow approximately linearly with effective threshold size. At n = 48 and t = n, BLS aggregation stayed below 300 ms, while Shamir reconstruction was close to 1.1 ms.
Checks came with trade-offs
Ablation tests showed what disappeared when individual mechanisms were removed. At 100 votes, the full variant retained all three listed checks: tamper detection, unauthorized-submission detection and dropout resilience. The No Pedersen variant lacked tamper detection; No Shamir lacked dropout resilience; and No BLS lacked unauthorized-submission detection. No BLS had a latency of 2.43 ms.
The formal analysis presents claims about data integrity, vote privacy, metadata integrity, retrieval verifiability, chain consistency, vote uniqueness, cross-chain binding integrity, retrieval atomicity and liveness under standard cryptographic assumptions. These are properties of the protocol and its checks under stated assumptions; they are not a guarantee that a generated answer is correct.
The paper explicitly says the system does not guarantee factual correctness of large-language-model outputs, defend against prompt injection or other generation attacks, or cover fully compromised validation domains and poor validator judgments. A high credibility score therefore cannot be read from this evidence as proof that a document, or an answer built from it, is true.
The design also emphasizes detectability rather than availability, and the service may refuse to return a result. That behavior is part of the stated system design, not evidence that the service will remain available under every operating condition.
The unanswered question is whether it helps
Because the performance study is modular, its components were measured separately and then interpreted as composable parts of the full system. The paper does not report a real-world deployment, corpus size or query workload. It also does not provide an end-to-end test of the complete retrieval-and-answer process.
The open questions are practical as well as technical: whether TrustRAG changes answer factuality, hallucination rates or safety in deployment; how credibility scores behave when validators make errors or collude below the threshold; and how costs change with realistic document, query, chain, validator and network scales. The paper also leaves unanswered whether proof packages would provide measurable value to users or regulators in high-stakes workflows.
Taken together, the results speak to cryptographic provenance, privacy-preserving validation and measured overhead in a prototype. They do not establish better factuality, protection against generation attacks, service availability or decision quality in human, clinical, legal, financial or other real-world use.
Publication note
The document is an arXiv version 1 preprint dated 20 Aug 2026. It reports support from the Henan Province Key Research and Development Special Project, Project No. 251111210400.
Paper data and sources
Original title: TrustRAG: Blockchain-Enhanced RAG via Committee-Based Credibility Scoring
Authors: Baixiang Liu, Haotian Che, Yuan Li
Journal/Repository: arXiv
Status: Preprint, not yet peer-reviewed
First online: 2026-08-20
DOI: Not available
Original paper · Full text