{"id":"84660a36-f7e8-4362-aaf0-c7737da89667","arxiv_id":"2506.19368","paper_version":1,"verdict":"REJECT","confidence":"MODERATE","novelty_score":4.0,"correctness_risk":"high","formal_verification":"none","parameter_count":0,"one_line_summary":"Yotta is a proposed batch data trading protocol that uses IPFS and zk-SNARKs to let many sellers prove data quality to many buyers via blockchain escrow.","lead":"This paper presents Yotta, a blockchain-based scheme for trading data in batches using IPFS storage and zk-SNARK proofs to certify data quality. The authors claim it is the first to satisfy their proposed SQUATS requirements and report up to 130 times speedup over a DCDH baseline.","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Yotta's Security/completeness claim fails as written: Step 1 encrypts only the IPFS address, not the data, so after Step 4 publishes K_i, anyone can recover the CID and fetch plaintext data; the later 'encrypted data storage' claim lacks a key-distribution step.","rationale":"The reader's weakest assumption already identified the missing data-layer encryption; I agree with that core concern and sharpen it into a dilemma from the paper's own text. Section 3.3 defines K_i as a key for the data address and never as a key for S_i; Section 3.5.1 asserts encrypted data storage but supplies no key-distribution step. This is not an implementation detail: the abstract's 'complete scheme' and the Section 3.4 conclusion that all six properties are satisfied depend on the Security property. There is also no security proof, no zk-SNARK circuit, and no released code to redeem the claim; but the core logical gap is sufficient. I set agreement to 'partial' because I add the converse branch (a separately encrypted payload would leave the buyer unable to decrypt it), whereas the reader focused on the plaintext-IPFS breach. The reader's REJECT verdict remains appropriate and should be unchanged.","tokens_in":8124,"tokens_out":8284,"duration_ms":87414,"concrete_test":"Implement the protocol literally for one seller: upload a plaintext S_i to IPFS to obtain its CID, compute C_i = Enc(K_i, CID), publish K_i on-chain as in Step 4, and have an independent observer recover the CID from the public K_i/C_i and fetch S_i from IPFS. If the observer retrieves the plaintext, the Security property is violated. If the authors instead claim S_i was encrypted before upload, ask for the specific data-encryption key and its distribution in Steps 1-5; absent such a step, demonstrate how the buyer decrypts S_i after obtaining only address_i.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The paper's central claim is that Yotta is the first complete batch data trading scheme satisfying all six SQUATS properties. The load-bearing gap is the Security property and, more broadly, the protection of the data payload. In Section 3.3.1 Step 1(2)-(4), each seller generates K_i 'for their secret data address', uploads S_i to IPFS, and computes C_i = Enc(K_i, address_i). No step encrypts S_i, and the zk-SNARK statement in Step 1(6) only binds S_i to the IPFS content and C_i to the address. In Step 4 (Section 3.3.4), all K_i are submitted to a public smart contract. Any observer can then decrypt C_i to obtain address_i and, since IPFS is a content-addressed public DHT, fetch the plaintext file. This contradicts the Security bullet in Section 3.4 ('only the encryption key K_i is visible on the blockchain, preventing any third party from accessing the actual data content') and Section 3.3.5's claim that 'the data address is privately shared.' The alternative reading, suggested by Section 3.5.1's 'Encrypted Data Storage: Sellers encrypt their data and store them on IPFS', is worse: Steps 1-5 never generate or distribute a key for that separately encrypted payload, so after Step 5 the buyer can decrypt the address but not the data. Thus the protocol is internally inconsistent: with plaintext IPFS objects, unauthorized parties obtain the data; with separately encrypted objects, the buyer cannot. Either way, the 'complete ... satisfies all properties' claim is unsupported.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper proposes Yotta, a blockchain-based batch data trading scheme combining IPFS, zk-SNARKs, and smart contracts. The authors introduce a set of six properties, SQUATS (Scalability, Quality, Usability, Autonomy, Transparency, Security), claim to be the first to formalize these requirements, and assert that Yotta satisfies all of them. A prototype simulation is reported to outperform a DCDH baseline by up to 130x at 10,000 sellers. The central claims are that Yotta is the first complete large-scale trustless data trading scheme and that it provides data security while supporting many-to-many transactions.","tokens_in":8468,"tokens_out":5202,"duration_ms":54371,"significance":"If the technical claims were correct, a batch data trading scheme with verifiable data quality and no trusted third party would be a meaningful contribution to blockchain-based data markets. The paper's five-step protocol is clearly presented, and the idea of using zk-SNARKs to bind a seller's data to an IPFS content hash and to the buyer's evaluation function is a sensible design goal. However, the paper provides no machine-checked proofs, no released code, no formal adversary model, and no reproducible experimental description. The central Security claim is contradicted by the protocol's own steps, and the performance evaluation is not independently checkable. For these reasons the claimed significance is not established.","major_comments":[{"comment":"The protocol does not protect the data payload. Step 1(3) uploads S_i to IPFS, Step 1(4) encrypts only address_i under K_i, and Step 4 publishes K_i on the smart contract. Once K_i is public, any party can decrypt C_i = Enc(K_i, address_i), obtain the IPFS content hash, and retrieve the plaintext file from IPFS. The alternative reading, suggested by Section 3.5.1's 'Encrypted Data Storage: Sellers encrypt their data and store them on IPFS', is that S_i itself is encrypted; but then the protocol never distributes the payload-decryption key to the buyer, so the buyer cannot access the purchased data. In either reading the Security property stated in Section 3.4, which promises that 'only the encryption key K_i is visible on the blockchain, preventing any third party from accessing the actual data content', is false, and the central claim that Yotta satisfies all six SQUATS properties is unsupported.","section":"Section 3.3.1, Steps 1(2)-(4), with Section 3.4 (Security)"},{"comment":"The claimed up-to-130x speedup over the 'DCDH' baseline is not supported by any reproducible experimental description. The baseline is not defined or cited, no experimental setup or methodology is given, Figure 2 has no axis labels or units, and no error bars or repeated runs are reported. Since the baseline may itself implement the key-exchange approach criticized in Section 2.2, the comparison cannot validate scalability. The performance claim should be either removed or backed by a released prototype and a described baseline.","section":"Section 4 and Figure 2"},{"comment":"The central quality guarantee rests on a zk-SNARK statement that the paper never instantiates. No circuit, proving key, verification key, or prover-cost measurement is provided for the claimed statement that S_i satisfies the buyer's evaluation function F(), that the committed data matches the IPFS content hash, and that C_i is an encryption of the address under K_i. Without a concrete circuit and cost analysis, the Quality property and the paper's scalability argument of constant proof size and verification cost are assertions, not results.","section":"Section 3.3.1, Step 1(6), with Section 3.4 (Quality)"},{"comment":"The SQUATS properties are introduced and evaluated by the same paper; the statement that Yotta 'satisfies all the essential properties' is established with informal prose bullets rather than formal definitions or independent verification. In particular, Scalability, Usability, and Autonomy are never given measurable criteria. As a result the paper's novelty claim of being the 'first' to formalize these requirements and to provide a 'complete' scheme is self-referential and cannot be checked by a reader. To make the claim meaningful, each property needs a formal definition and a method to test it.","section":"Section 3.4 and Section 1"}],"minor_comments":[{"comment":"The caption says 'DHDC' while the text and Section 4 refer to 'DCDH'; the two names should be reconciled.","section":"Figure 2 caption"},{"comment":"The paper uses 'address_i' in Step 1(4) and Step 5 but 'IPFS content hash H_ipfs_i' in Step 1(3) and Step 2; it should clarify that the encrypted value is the IPFS content hash or define the relation between the two notions.","section":"Notation, Sections 3.3.1 and 3.3.5"},{"comment":"The running header contains 'Trovato et al.' and the footer contains 'Received 20 February 2007; revised 12 March 2009; accepted 5 June 2009', which are clearly template remnants and should be removed.","section":"Page headers and footer"},{"comment":"Reference [12] is a generic editorial introduction and does not support the claim that data trading is a key focus of Web 3.0; a more specific citation would be appropriate.","section":"Reference [12]"}],"recommendation":"reject","confidential_remarks":"The manuscript reads as an early-stage proposal rather than a complete security paper: the main protocol leaks the data once K_i is public, the evaluation lacks a described baseline, and the 'first complete scheme' claim is validated only against the paper's own checklist. I would recommend rejection, with the possibility of reconsideration only if the protocol is redesigned to include actual payload encryption with a distributed key, and the experiments are made reproducible."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Here's my take on Yotta. The paper puts its finger on a real problem—batch many-to-many data trading on blockchain with some verifiable quality guarantee—and the high-level architecture (IPFS for storage, zk-SNARKs for quality proof, smart-contract escrow for key exchange) is a sensible combination. That combination is genuinely new, as far as I can tell, even though each ingredient is standard. The SQUATS list is a reasonable checklist of desiderata. So the initial problem statement is worth a reader's time.\n\nThe problem is that the protocol doesn't actually do what it claims. Step 1 encrypts only the IPFS address with K_i; the data S_i goes to IPFS in the clear (the text says 'uploads their data to IPFS' without any encryption). Step 4 publishes all K_i on-chain. Since IPFS is content-addressed, anyone who sees the ledger can decrypt C_i, recover the address, and fetch the file. The Security bullet in Section 3.4 claims 'only the encryption key K_i is visible,' but that key is exactly what unlocks the address. Later, Section 3.5.1 says sellers encrypt their data on IPFS, but the protocol steps never generate or distribute a key for that payload, so the buyer couldn't decrypt it after the exchange. The paper is internally inconsistent: with plaintext IPFS objects, third parties get the data; with encrypted objects, the buyer can't. Either way, the 'complete scheme satisfying all six properties' claim is unsupported.\n\nBeyond the security gap, there's no security proof, no adversarial model, no circuit description, and the evaluation is a simulation against an undescribed DCDH baseline with no code or parameters. The 130x speedup claim is not independently checkable. The SQUATS validation is a self-check against the paper's own checklist, which weakens the 'first to formalize' claim.\n\nSo the paper's real contribution is a clearly stated problem and a plausible architecture, not a working protocol. With a fix that actually encrypts the data and distributes the right keys, plus a real evaluation, it could be a worthwhile submission. As is, I wouldn't send it to a serious referee; desk reject is fair. If you see a revision that addresses the key-distribution problem and ships code, it's worth a second look.","headline":"Useful problem statement and a plausible combination of known pieces, but the security property fails on the protocol's own steps—the published key unlocks the IPFS address and the data is stored in the clear.","tokens_in":9009,"tokens_out":3150,"would_cite":false,"duration_ms":31482,"reading_group":"maybe","serious_thinker":"no","would_accept_peer_review":false},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"Yotta claims 130x faster blockchain data trading with six properties","keywords":["blockchain","data trading","Web 3.0","IPFS","zk-SNARK","smart contract","trustless system","SQUATS"],"falsifier":"Upload a plaintext dataset to IPFS, run the Yotta protocol with the address encrypted and the key published to the smart contract, and see whether an outside party who knows only the content address can retrieve the file; if they can, the claimed Security property fails.","tokens_in":7880,"feed_emoji":"⚡","tokens_out":7318,"duration_ms":69591,"temperature":0.7,"pith_summary":"The paper argues that no existing blockchain-based data-trading scheme can support large-scale, many-to-many exchanges while still protecting the data, and that the field has not even agreed on what properties such a scheme should have. It answers both gaps by proposing the SQUATS principles—Scalability, Quality, Usability, Autonomy, Transparency, Security—and then presenting Yotta, a batch trading protocol built on IPFS, smart contracts, and zk-SNARK proofs. In Yotta, each seller encrypts the IPFS address of their data, publishes a proof that the hidden data satisfies the buyer's stated quality function, and receives payment only after submitting a decryption key that the smart contract validates. The paper's central claim is that Yotta is the first complete scheme satisfying all SQUATS properties, with a prototype that outperforms the DCDH baseline by about 130 times at 10,000 sellers.","feed_headline":"Yotta claims 130x faster blockchain data trading with six properties","feed_subtitle":"Many sellers can prove data quality privately and get paid by smart contract, with no trusted third party","key_machinery":"The load-bearing object is the five-step Yotta workflow that couples address encryption with zk-SNARK provenance proofs and smart-contract key release. Its work is to decouple data possession and quality verification from key delivery: the seller proves possession and quality without revealing the data, while the blockchain handles payment deterministically only when the key decrypts the encrypted address correctly. Recursive SNARKs are the mechanism that lets one buyer verify many sellers' proofs in a single step, which is what converts one-to-many trades into many-to-many scale. The named property list SQUATS is the paper's own contribution as the formal target any large-scale trading scheme should satisfy.","core_discovery":"On the paper's own terms, Yotta is a trustless batch data-trading scheme for Web 3.0. Each seller stores their secret dataset on IPFS and encrypts only the IPFS address with a private key $K_i$, producing ciphertext $C_i$; the seller also uses zk-SNARK, a zero-knowledge proof with constant-size, data-independent verification, to demonstrate that the dataset satisfies the buyer's evaluation function $F()$, that $C_i$ really encrypts the address with $K_i$, and that $H(K_i)$ matches a published hash. The buyer verifies these proofs before depositing payment in a smart contract, and the contract pays each seller only if their submitted key decrypts $C_i$ to a valid address. The authors state that because only one of the key or the data is ever exposed and the data address is privately shared, the scheme achieves security along with scalability, making it a foundation for many-to-many data trading that no prior scheme has provided.","pith_inferences":["If the IPFS access assumption is not guaranteed, Yotta's security property requires that the data payload itself be encrypted before upload; the paper only specifies encrypting the address, so a reader should not infer stronger confidentiality than the protocol text states.","The 130x figure compares a purpose-built prototype against a DCDH-based scheme; in a real deployment with network latency, storage costs, and on-chain gas fees, the relative gain could deviate, though the scaling trend should persist.","SQUATS could be applied as an evaluation checklist beyond Yotta, turning the paper's contribution from a single system into a standard that future schemes can be measured against.","A natural testable extension is to replace IPFS with other decentralized storage or add quality functions like Shapley values; the protocol's address-encryption structure is agnostic to that choice, per the paper's extensibility discussion."],"forward_implications":["If Yotta's claims hold, large-scale data markets can operate without a trusted escrow: buyers deposit in a smart contract and sellers are paid automatically for correct keys.","Buyers can verify data quality before payment because zk-SNARK proofs bind the buyer's evaluation function to the content-addressed data stored on IPFS.","The scheme's cost profile favors growth: the reported prototype goes from roughly 3x over DCDH at 10 users to 130x at 10,000 users, so gains increase with market size.","Recursive SNARK aggregation means the buyer's verification cost stays sublinear in the number of sellers, making many-to-many batches practical.","The SQUATS list gives later designs a concrete target to check against, potentially serving as a common benchmark for Web 3.0 data-trading proposals."],"supporting_citations":[{"why":"supplies the IPFS content-addressed storage system that holds the traded datasets and their content identifiers","marker":"[2]"},{"why":"supplies a zk-SNARK construction used to generate proofs of data possession and quality","marker":"[5]"},{"why":"supplies the other zk-SNARK construction used for the same proof system","marker":"[10]"},{"why":"defines the Ethereum smart-contract platform on which Yotta's payment and key-release logic runs","marker":"[24]"},{"why":"provides the recursive SNARK technique that aggregates many sellers' proofs for one-step buyer verification","marker":"[3]"},{"why":"is the earlier blockchain-based large-scale data trading prototype that Yotta positions itself against and improves in efficiency","marker":"[26]"},{"why":"is the earlier decentralized privacy-preserving data sharing scheme that motivates the trustless design","marker":"[28]"}],"fun_headline_variants":["Yotta uses zk-SNARK to enable trustless data trading on blockchain","Trustless batch data trading on blockchain is 130x faster with Yotta","Yotta's zk-SNARKs make large-scale data trading trustless and fast","Yotta: 130x faster trustless data trading via zero-knowledge proofs"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The security property rests on the unstated assumption that files stored on IPFS cannot be fetched by anyone who knows their content address, because Yotta encrypts only the address and later releases the decryption key publicly for payment.","fun_headline_variants_meta":{"raw":{"variants":["Yotta uses zk-SNARK to enable trustless data trading on blockchain","Trustless batch data trading on blockchain is 130x faster with Yotta","Yotta's zk-SNARKs make large-scale data trading trustless and fast","Yotta: 130x faster trustless data trading via zero-knowledge proofs"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000765,"raw_usage":{"total_tokens":3367,"prompt_tokens":896,"completion_tokens":2471,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":512,"completion_tokens_details":{"reasoning_tokens":2383}},"tokens_in":512,"tokens_out":2471,"duration_ms":17850,"temperature":1.0,"reasoning_tokens":2383,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-06T23:07:29.036811+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Upload a plaintext dataset to IPFS, run the Yotta protocol with the address encrypted and the key published to the smart contract, and see whether an outside party who knows only the content address can retrieve the file; if they can, the claimed Security property fails.","supporting_citations":[{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"supplies a zk-SNARK construction used to generate proofs of data possession and quality"},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"supplies the other zk-SNARK construction used for the same proof system"},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"provides the recursive SNARK technique that aggregates many sellers' proofs for one-step buyer verification"},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"is the earlier blockchain-based large-scale data trading prototype that Yotta positions itself against and improves in efficiency"},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"is the earlier decentralized privacy-preserving data sharing scheme that motivates the trustless design"}],"review_version":1}