{"id":"a0c69253-f28c-4898-af7e-a5e54de4083c","arxiv_id":"2504.20544","paper_version":1,"verdict":"REJECT","confidence":"MODERATE","novelty_score":5.0,"correctness_risk":"high","formal_verification":"none","parameter_count":1,"one_line_summary":"MedBlockTree uses chameleon-hash collisions to turn one blockchain into a tree of parallel branches and claims roughly n times higher block throughput for EMR metadata sharing.","lead":"A proposed system for sharing electronic medical records stores record metadata on a blockchain-like tree with many parallel branches, claiming much faster processing than a single blockchain chain. It matters because hospitals need fast, trustworthy record sharing, but the design's security trade-offs need scrutiny.","discovery_kind":"extension","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Collision-block construction is internally inconsistent: if the branch index is hashed the collision breaks, if it is not hashed branch roots are indistinguishable and the patient-only secret key contradicts practitioner-generated collisions.","rationale":"The reader's weakest assumption identifies the same load-bearing concern I find: the collision-block mechanism cannot simultaneously produce identical hashes and distinct, verifiable branch roots. I read the paper in good faith and acknowledge the plausible kernel: if branches could be created, running consensus once per round over n branches would indeed raise throughput roughly n-fold, and the simulation's round-time trend is consistent with that append-loop behavior. However, the paper's own text contains the conflict. §3.1 defines ColliHash as producing the same chameleon hash for different messages; §4.2.1 defines a block index tuple that is part of the block; §4.2.2 claims practitioners use the patient's secret key while the assumptions and contribution list say only the patient holds that key. No proof, formal specification, or executable artifact resolves these contradictions. The simulation cannot validate the mechanism because it assumes collision blocks can be created and appended; it measures the cost of the append loop, not the cryptographic validity of the branches. I therefore see no reason to change the reader's rejection verdict. The paper would need a precise definition of the hashed message, a clear key-distribution model, and a proof or prototype showing that two blocks with the same chameleon hash and pre-hash can still be distinguished as branch roots before the central claim can be accepted.","tokens_in":12591,"tokens_out":4221,"duration_ms":46273,"concrete_test":"State the exact byte-string input to the chameleon hash for a block (does it include the block index B(n)-m, the pre_hash, the timestamp, and the chameleon string?), then symbolically check the two examples in §4.2.2 and Figure 2. If the index is in the input, the claimed equality HashVerif(..., Meta<cold>, ζ1) = HashVerif(..., Meta<Flu>, ζ2) with distinct indexes is false. If the index is not in the input, run a minimal two-branch append test and show that a verifier given only the ledger cannot determine whether the next block should be linked after B1-1 or B2-0. Either outcome refutes the branch-formation mechanism as written.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central throughput claim (n branches, n blocks per round) rests entirely on §4.2.2's collision block: a block with the same chameleon hash and pre-hash as the patient's former block but carrying new metadata, serving as a new branch root (Figures 2 and 4). This construction is not well-defined. Block indexes are explicitly part of the block structure (§4.2.1, Figure 1). If the index (B(n),m) is included in the message hashed by the chameleon hash, then two blocks with different indexes cannot have the same chameleon hash, so the collision equation in §4.2.2 fails exactly when the blocks are distinct. If the index is excluded, any hash-based verifier cannot tell the two branch roots apart: a third block linked via pre_hash to Chamehash(Alice) is equally valid after either, so branch identity is not cryptographically anchored. The paper never specifies the hash input. Separately, §4.2.2 says practitioners generate collision blocks 'in combination with the patient's private key (SK)', while Assumption 1 and the contributions claim SK is 'only held by patients'. Either the practitioner cannot generate the collision, or exclusive key possession does not ensure patient awareness. Both horns are load-bearing because without a verifiable distinct branch root the tree cannot grow and the n× throughput claim evaporates.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper proposes MedBlockTree, a blockchain data structure for EMR metadata in which a chameleon hash function is used to generate \"collision blocks\" for returning patients, turning a linear chain into a tree with n branches. It also introduces EnhancedPro, a Proof-of-Stake/BFT consensus protocol that elects one block proposer per branch per round. The authors claim that this achieves roughly n times the block throughput of a conventional single-chain EMR blockchain, while preserving patient awareness, and they support the claim with a simulation study varying branch count, network latency, network size, and collision rate.","tokens_in":12796,"tokens_out":11609,"duration_ms":129844,"significance":"If the described construction were fully specified and correct, the tree structure would be a plausible way to process multiple EMR metadata blocks per consensus round while keeping patients in the loop. The paper does provide a concrete simulation environment, per-component timing measurements, and a fairness comparison, which are useful empirical illustrations. However, the specification is incomplete at the exact point where the design's novelty lies: the authenticated creation of a distinct branch root via a chameleon collision. The patient-key handling is self-contradictory, the hash input to the chameleon hash is never defined, and the claimed n-fold speedup is largely built into the simulation's assumptions. As written, the central contributions are not established.","major_comments":[{"comment":"The description of who can generate a collision block is contradictory. The paper states that the patient's private key (SK) is \"only held by patients\" and that this \"strongly ensures\" patient awareness, but §4.2.2 says that \"clinic practitioners\" create collision blocks \"in combination with\" that same key. If practitioners have access to SK, the exclusivity claim in Contribution 3 is false; if they do not, no protocol is given for obtaining patient authorization. Since collision blocks are the only mechanism that creates new branch roots, the central throughput claim collapses unless this contradiction is resolved and the resulting trust model is analyzed.","section":"§4.2.2, Contribution 3, Section 4 assumptions"},{"comment":"The message input to the chameleon hash is never defined. The block index (B(n),m) is said to distinguish blocks with identical hash values, but the collision verification in §3.1 and §4.2.2 compares only metadata and chameleon strings. If the index is not part of the hashed message, hash verification cannot authenticate the branch identifier, and a collision block could potentially be relabelled to start a different branch. If the index is part of the message, the collision relation must be stated over the full block message, not just the metadata. The paper must specify the exact message that is hashed and prove that the resulting collision block is both a valid chameleon collision and a distinct, verifiable branch root.","section":"§4.2.1, §4.2.2, Figures 1-2"},{"comment":"The winner election is claimed to be \"fair and unpredictable,\" but the randomness source is the chameleon string ζ of an already-committed former block. Both ζ and n are public before the next round begins, so any worker can predict all winners in advance. The VRF is used only to authenticate proposals, not to select winners, so the unpredictability claim is unsupported. Figure 12 measures only the distribution of winners across workers; it does not test whether winners are unpredictable to an adversary who observes the public chain.","section":"§4.4.1, Equation (1), §5.6"},{"comment":"The n-fold throughput result is essentially a consequence of the assumption that there are n branches, each with one matching metadata pack per round. Algorithm 1 creates a block for B(n) only when n=ι, but no rule is given for assigning incoming metadata packs to branch numbers, and the simulation appears to maintain a fixed branch-count/metadata matching. Without an explicit scheduling or assignment mechanism, the reported speedup is not a validated prediction for arbitrary EMR workloads; it is a re-statement of the construction's parallelism.","section":"§4.4.1, Algorithm 1, §5.1-5.5"},{"comment":"The protocol text says collision blocks are \"initially validated\" and \"uploaded to the data pool to await processing,\" but also that collisions are \"updated at the end of each consensus round.\" It is unclear whether a collision block is a committed block or a pending transaction, and no consensus step is described that verifies the patient's authorization or the placement of the collision block as a branch root. This ambiguity is load-bearing because the tree grows only when collision blocks become new branch roots.","section":"§4.4.3"}],"minor_comments":[{"comment":"The labels in Figure 7 are inconsistent with the text: the B1-3 block is labelled \"Metadata(Bob<Flu>)\" while the text says Claire's Flu, and B2-1 is labelled \"Metadata(Ella<cold>)\" while the text says Daisy COVID.","section":"Figure 7"},{"comment":"The header contains the typo \"Syetem\" and should be \"System.\"","section":"Table IV"},{"comment":"The running example introduces Ella as a new patient but then uses only Claire and Daisy in the actual block construction; the narrative should be aligned with the figure.","section":"§4.4.3"},{"comment":"The benchmark and simulation results are reported without error bars, repetition counts, or confidence intervals; given the small differences among configurations, this limits the strength of the quantitative conclusions.","section":"§5"}],"recommendation":"reject","confidential_remarks":"The principal contributions of the paper are not established as written: the key-management description is self-contradictory, the hash-input specification is missing, and the throughput result is largely definitional. These are load-bearing issues in the core design, so I recommend rejection rather than minor or major revision. If the authors substantially redesign the collision-authorization protocol and provide a formal specification of the hashed block message, a resubmission could be considered."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"First thing you should know: this is not a paper to reject out of hand, but it is not ready for publication either. The core idea—use chameleon-hash collision blocks as branch roots so that n branches each append a block in one consensus round—is genuinely new relative to the cited chameleon-hash, sharding, and DAG work. If it worked, it would give a simple way to scale permissioned EMR blockchains. The EnhancedPro multi-winner election with VRF is a sensible adaptation, and the simulation shows the expected trend of throughput rising with branch count while consensus round time grows only slightly.\n\nWhat the paper does well: the problem (EMR upload latency) is real, the related work is fair, and the writing is clear enough that a reviewer can see exactly where the design is tricky. The authors also honestly note diminishing returns in the conclusion.\n\nNow the soft spots, and they are load-bearing. The collision-block construction is under-specified. The chameleon hash collides on the metadata message, but the block index (branch identifier) is not part of the hashed input as far as the paper states. If the index is excluded, then the index is not cryptographically anchored—nothing prevents an attacker from splicing a block from branch B2 onto branch B1, since both carry the same Chamehash. If the index is included, two blocks with different indexes cannot have the same chameleon hash, so the collision equation in §4.2.2 fails. The paper never says which. The same section says practitioners generate collision blocks using the patient's private key, while Assumption 1 states that key is only held by the patient. That is a direct contradiction, and it undermines the patient-awareness guarantee. There's also the standard chameleon-hash trapdoor issue: anyone who holds the secret key can manufacture collisions, so the tamper-evidence claim is weaker than the paper implies.\n\nThe evaluation is honest but limited: no code or data, no error bars, and no comparison with the DAG or sharding baselines discussed earlier. More importantly, the n× speedup is almost definitional—if you append n blocks per round, throughput scales with n—so the simulation is largely a demonstration of the construction rather than an independent test.\n\nBottom line: the paper deserves serious peer review, not because it is close to correct, but because the flaw is specific and instructive, and a good referee can help the authors either fix the construction (by defining what is hashed and who holds which key) or abandon it. As it stands, I would not cite it. For a reading group, it's a useful case study in why hash input domains matter.","headline":"Novel tree-branch idea with a plausible throughput trend, but the collision-block construction is under-specified and internally contradictory, breaking the central claim as written.","tokens_in":13393,"tokens_out":4082,"would_cite":false,"duration_ms":39097,"reading_group":"maybe","serious_thinker":"no","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"A chameleon-hash collision lets a returning patient's new record branch the EMR chain, letting one consensus round finalize n blocks.","keywords":["EMR sharing","blockchain scalability","block tree","chameleon hash","EnhancedPro consensus","patient awareness","throughput"],"falsifier":"Inspect what is fed into the chameleon hash when a block is created. If the branch index $B(n)$-$m$ is part of the hashed content, the claimed collision is impossible, because changing the index changes the hash; if the index is not hashed, no hash-based check can tell two blocks with the same chameleon hash apart, so branch identity and provenance would have to rely on a side channel. A second test is to try generating a collision block without the patient's secret key; if one succeeds, the patient-awareness guarantee is not enforced by the cryptography.","tokens_in":12259,"feed_emoji":"🌳","tokens_out":8140,"duration_ms":75112,"temperature":0.7,"pith_summary":"This paper claims that the low throughput of blockchain-based EMR sharing can be fixed by replacing a single chain with a block tree built from chameleon-hash collisions. In MedBlockTree, when a returning patient gets a new record, clinic staff create a collision block that carries the new metadata but the same chameleon hash as the patient's earlier block, and that block becomes the root of a new branch, so a consensus round can append one block per branch instead of one. The accompanying EnhancedPro protocol elects one proposer per branch using VRF-seeded randomness and confirms blocks through Byzantine-fault-tolerant voting. If the construction holds, throughput grows roughly with branch count; the paper reports blocks per second rising from 2.70 in the baseline to 16.18 with ten branches. The paper also presents patient awareness as a benefit, since collision generation is tied to a secret key held by the patient.","feed_headline":"Block tree turns one EMR chain into n parallel branches","feed_subtitle":"Chameleon-hash collisions let returning patients' records become new branches, so one consensus round processes n blocks.","key_machinery":"The load-bearing piece is the identity-based chameleon hash function, which behaves like an ordinary hash but lets whoever holds a trapdoor secret key produce a second input with the same hash value. MedBlockTree uses that collision capability to make a new metadata block hash-identical to a patient's earlier block while being treated as a separate branch root; the branch index is written as a tuple $(B(n), m)$. EnhancedPro pairs this with weighted sub-node randomness from a Verifiable Random Function and a two-phase Byzantine-fault-tolerant vote, pre-vote then commit, requiring two-thirds of staked voting power to finalize the block map for a round.","core_discovery":"MedBlockTree's central claim is that a chameleon hash lets a returning patient's new EMR metadata be packed into a collision block with the same hash and pre-hash as the patient's former block, so the chain can split into a tree where each branch is an independent append point. Each collision block counts as already validated, because it is made with the patient's secret key, and it starts a new branch at the same level as the old block. EnhancedPro runs one winner election per branch per round, producing $n$ finalized blocks per round and processing speeds the paper states as $\\nu\\cdot n$ times faster than a conventional chain. The reported simulations against an Enhanced Tendermint blockchain show gains across branch number, collision rate, network latency, and network size, with the paper itself noting a plateau in benefits as branches grow.","pith_inferences":["The branch-identity question has a binary outcome the paper leaves open: if the branch index $(B(n),m)$ is fed into the chameleon hash, the collision that creates the branch cannot exist, and if it is not fed in, no hash-based verifier can distinguish two blocks with the same hash, so branch provenance must rest on an unhashed, trusted index.","If the patient's secret key is the only way to make a collision, then practitioners must obtain that key to create emergency branches, which conflicts with the stated assumption that only the patient holds it; the practical system therefore seems to require delegated or shared keys, a different security model.","The same collision-branch trick could apply to any permissioned ledger where the same user returns repeatedly, such as supply-chain lot tracking or credential renewal, with the same hash-distinguishability caveat carrying over.","A direct stress test would be to let two branches that share a hash continue growing and then attempt to reorg or merge them; the outcome would show whether record sequence and auditability survive the parallel structure."],"forward_implications":["With $n$ branches, one consensus round finalizes $n$ blocks, and the reported blocks per second rise from 2.70 for the baseline chain to 16.18 for ten branches at 100 ms latency.","More frequent returning-patient collisions make the tree grow faster, so follow-up visits reduce rather than lengthen the upload queue; the paper reports overall processing time falling to 217.22 seconds at a 30-second collision rate versus 738.01 seconds for the baseline.","EnhancedPro keeps multiple branches consistent by electing one proposer per branch with VRF-seeded randomness and requiring a two-thirds stake-weighted vote to commit the round's blocks.","Larger networks reduce the gain, with 16 nodes averaging 5.77 blocks per second against 7.77 for 4 nodes, yet they still finish 2.13 times faster than the 4-node baseline chain.","The paper itself reports diminishing returns as branch count grows and names efficient branch management as future work."],"supporting_citations":[{"why":"Defines the chameleon-hash collision property that MedBlockTree relies on to make branch blocks.","marker":"[15]"},{"why":"Supplies the identity-based chameleon hash primitive actually used to create collision blocks.","marker":"[17]"},{"why":"Enhanced Tendermint is both the base protocol EnhancedPro builds on and the comparison baseline in the simulations.","marker":"[6]"},{"why":"Supplies the Verifiable Random Function used for winner election and proposal verification.","marker":"[20]"},{"why":"Establishes the off-chain storage and on-chain metadata pattern MedBlockTree adopts for EMR records.","marker":"[19]"},{"why":"Earlier on-chain-hash EMR ledger that MedBlockTree extends by parallelizing uploads.","marker":"[18]"}],"fun_headline_variants":["MedBlockTree: chameleon hashes split EMR chains into n branches","Chameleon hash turns one chain into a tree of n blocks per round","EMR block tree with n branches per round is n times faster","MedBlockTree grows a chain into n branches for faster EMR sharing"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The construction stands or falls on one premise: a collision block can share the exact chameleon hash and pre-hash of a patient's earlier block while still being a distinct, verifiable branch root, and clinic staff can create that collision using a secret key the paper says only the patient holds.","fun_headline_variants_meta":{"raw":{"variants":["MedBlockTree: chameleon hashes split EMR chains into n branches","Chameleon hash turns one chain into a tree of n blocks per round","EMR block tree with n branches per round is n times faster","MedBlockTree grows a chain into n branches for faster EMR sharing"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000454,"raw_usage":{"total_tokens":2269,"prompt_tokens":918,"completion_tokens":1351,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":534,"completion_tokens_details":{"reasoning_tokens":1270}},"tokens_in":534,"tokens_out":1351,"duration_ms":10035,"temperature":1.0,"reasoning_tokens":1270,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-16T05:27:08.870371+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Inspect what is fed into the chameleon hash when a block is created. If the branch index $B(n)$-$m$ is part of the hashed content, the claimed collision is impossible, because changing the index changes the hash; if the index is not hashed, no hash-based check can tell two blocks with the same chameleon hash apart, so branch identity and provenance would have to rely on a side channel. A second test is to try generating a collision block without the patient's secret key; if one succeeds, the patient-awareness guarantee is not enforced by the cryptography.","supporting_citations":[{"cited_title":"Cryptology ePrint Archive (1998)","cited_arxiv_id":null,"evidence_quote":"Defines the chameleon-hash collision property that MedBlockTree relies on to make branch blocks."},{"cited_title":"In: Proceedings of the IEEE International Conference on Acoustics, Speech and Signal Processing (ICASSP)","cited_arxiv_id":null,"evidence_quote":"Supplies the identity-based chameleon hash primitive actually used to create collision blocks."},{"cited_title":"In: Proceedings of the 12th International Symposium on Information and Communication Technology","cited_arxiv_id":null,"evidence_quote":"Enhanced Tendermint is both the base protocol EnhancedPro builds on and the comparison baseline in the simulations."},{"cited_title":"In: Proceedings of the 40th annual sym- posium on foundations of computer science (cat","cited_arxiv_id":null,"evidence_quote":"Supplies the Verifiable Random Function used for winner election and proposal verification."},{"cited_title":"Scientific Reports 14(1), 11746 (2024)","cited_arxiv_id":null,"evidence_quote":"Establishes the off-chain storage and on-chain metadata pattern MedBlockTree adopts for EMR records."},{"cited_title":"In: Proceedings of the IEEE Symposium on Computers and Communications (ISCC)","cited_arxiv_id":null,"evidence_quote":"Earlier on-chain-hash EMR ledger that MedBlockTree extends by parallelizing uploads."}],"review_version":1}