{"id":"382cefbf-ce02-43b4-ab3e-29d7424115bf","arxiv_id":"1908.08503","paper_version":1,"verdict":"REJECT","confidence":"HIGH","novelty_score":2.0,"correctness_risk":"low","formal_verification":"none","parameter_count":0,"one_line_summary":"A 2019 state-of-the-art survey classifying blockchain-based access control systems by domain, access control method, and blockchain platform, with a discussion of open challenges.","lead":"This paper surveys how blockchain and smart contracts are being used to control who can access digital resources, and lists the remaining technical challenges. It is a short review of roughly two dozen prior systems rather than a new technology proposal.","discovery_kind":"review","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The central 'state of the art' claim rests on an unstated and internally inconsistent corpus: the paper's own text and Table 2 disagree about which systems are part of the field.","rationale":"The reader's weakest assumption identifies exactly the load-bearing point: the survey's conclusion depends on the representativeness and accuracy of a corpus that is never justified. My independent reading confirms this and adds internal evidence that the corpus is not even consistent with the paper's own prose: three systems explicitly discussed as access-control work are missing from the summary table, and the table has a reference/author mismatch. The paper does provide a useful starting bibliography and some accurate descriptive summaries, so I would not call the effort worthless; however, the central claim of presenting a comprehensive state of the art is not supported by the paper's own content. The independent support here is modest: citations are given for every described system, and some classifications (e.g., Maesa et al. Bitcoin/attribute-based) match the cited literature, but that does not repair the missing methodology. Because the concern is the same one the reader raised and the verdict is already REJECT, no adjustment is needed.","tokens_in":9328,"tokens_out":6482,"duration_ms":62178,"concrete_test":"Reconstruct the survey corpus from scratch: define the search query ('blockchain' AND 'access control' in title/abstract/keywords) over IEEE Xplore, ACM DL, Springer, and arXiv for 2014-2019, apply inclusion criteria matching the paper's domain categories, then compare the retrieved set with Table 2. If the systematic search yields many additional eligible systems in the listed domains, or if re-running the paper's own text-to-table reconciliation shows that ChainAchor, BC-PDS, and RBAC-SC remain missing, the 'state of the art' conclusion is not supported. A smaller follow-up check is to independently verify every Table 2 author name against its bibliography entry; any mismatch beyond 'Asaph et al. [5]' would further indicate that the classification artifact is unreliable.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The paper's central claim is that it presents the state of the art and challenges of blockchain-based access control, and that the reviewed systems show blockchain as viable supplementary infrastructure across domains. For that claim to hold, the survey corpus and its classification must be representative and internally consistent. That condition is not met. First, no search or selection methodology is reported: there is no database list, query, inclusion/exclusion criterion, or time window, so the reader cannot tell how the roughly 27 Table 2 entries were chosen rather than another set. Second, the paper is internally incomplete: ChainAchor (Section 3.5, ref [25]), BC-PDS/self-sovereign identities (Section 3.6, ref [55]), and RBAC-SC (Section 3.4, ref [13]) are described as relevant access-control systems but are absent from Table 2, so the classification table does not even cover the paper's own text. Third, Table 2 contains an attribution error that a reader cannot resolve from the paper alone: the row 'Asaph et al. [5]' does not match bibliography entry [5], which is Azaria et al. Together these point to an ad hoc rather than systematic corpus. Additionally, the abstract lists inefficiency as a problem addressed by blockchain, but Section 4 concedes that blockchain performance cannot compete with centralized solutions; the paper never reconciles this tension. The rejection is based on the unsupported central claim, not on author behavior.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"This paper is a short survey of blockchain-based access control systems. It motivates blockchain as a remedy for third-party dependence, inefficiency, and privacy problems in traditional access control; summarizes roughly two dozen systems in Table 2, categorized by domain, access-control method, and blockchain platform; and discusses challenges including off-chain/on-chain integration, smart-contract vulnerability, transaction transparency, and performance. It concludes with a summary and pointers to future work.","tokens_in":9574,"tokens_out":4144,"duration_ms":41642,"significance":"If the survey were reliable, it would provide a useful entry point for researchers entering the area: the categorization by domain, access-control method, and blockchain platform is clear, and Section 4 names several genuine challenges (off-chain/on-chain integration, smart-contract vulnerabilities, transparency vs. privacy, and performance). The paper also gives explicit credit to the systems it discusses. However, the central claim of presenting the state of the art is currently not supported, because the corpus is assembled without any stated selection methodology and the classification table is internally inconsistent with the text. As a result, the resource's value as a reference is limited until these issues are addressed.","major_comments":[{"comment":"The paper never states how the surveyed corpus was assembled: no databases, query strings, inclusion/exclusion criteria, or time window are given. Since the abstract and introduction claim that the paper presents the state of the art, the absence of a reproducible selection method leaves the representativeness of the roughly 27 entries in Table 2 unsupported. The authors should either add a methodology subsection or explicitly narrow the claim to a selected overview rather than a state of the art.","section":"Sections 2-3 and Table 2"},{"comment":"Table 2 omits systems that the paper itself describes as blockchain-based access-control systems in the body: RBAC-SC (Cruz et al. [13], Section 3.4), ChainAchor (Hardjono and Pentland [25], Section 3.5), and BC-PDS (Yan et al. [55], Section 3.6) have no rows in Table 2. Thus the classification table does not even cover the paper's own text, which undermines the claim that Table 2 is a summary of blockchain-based access-control applications.","section":"Table 2 vs. Sections 3.4, 3.5, 3.6"},{"comment":"The row labeled 'Asaph et al. [5]' for MedRec does not match bibliography entry [5], which lists 'Asaph Azaria, Ariel Ekblaw, Thiago Vieira, and Andrew Lippman' (i.e., Azaria et al.). The table uses the first author's first name as though it were the surname. This attribution error prevents a reader from independently verifying the entry and indicates that the table was not carefully checked against the reference list.","section":"Table 2, row for MedRec"},{"comment":"The abstract lists inefficiency as one of the problems that blockchain can address, and Section 2 frames blockchain as a solution to the problems of current access control systems. However, Section 4 states that 'the performance of the blockchain-based solutions cannot compete with the current centralized solutions.' The paper never reconciles this tension. The authors should qualify the efficiency claim or explain the specific conditions under which blockchain-based access control can be considered efficient despite this performance gap.","section":"Abstract, Section 2, and Section 4 (Performance)"}],"minor_comments":[{"comment":"The function name 'addUsert' appears to be a typo for 'addUser', and the sentence says the challenge-response protocol 'has five steps' but then lists only four steps (declaration, information check, challenge response, response verification).","section":"Section 3.4"},{"comment":"The spelling 'ChainAchor' in the text differs from 'ChainAnchor' in the title of reference [25]; please use one consistent spelling.","section":"Sections 3.5 and reference [25]"},{"comment":"Several bibliography entries have inconsistent formatting, such as 'jordi Subira' in [40] and the use of first names in [22]; a careful copyedit of the reference list is needed.","section":"References"},{"comment":"The summary states that the paper 'explained the required concepts related to blockchain, smart contracts, platforms, and access control methods,' but the paper does not actually provide such an explanation in depth; the sentence should be adjusted to match the content.","section":"Section 5"}],"recommendation":"major_revision","confidential_remarks":"The survey includes several works authored by the authors' own group (e.g., refs [16], [42], [44], [46], [47], [48]) and repeatedly cites the authors' prior survey [43]. Given that no selection methodology is reported, this is not by itself evidence of misconduct, but it does make the representativeness of the corpus harder to assess. If the authors add a methodology statement, they should also explain how the corpus was chosen with respect to their own prior work."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Colleague — this one is a survey of blockchain-based access control, roughly two dozen systems, classified by domain, access-control method, and platform. The useful part is the table and the bibliography: if you want a quick list of early systems (MedRec, Ancile, FairAccess, ControlChain, Maesa et al.'s line of work), it saves you some searching. The challenge section is mostly sensible but does not go beyond what the surveyed papers already say.\n\nWhat is not there is a defensible state of the art. No search or selection methodology is reported, so the corpus is just the papers the authors happened to read. The paper does not even cover its own text: ChainAchor, BC-PDS, and RBAC-SC are discussed as access-control systems but are missing from Table 2. And Table 2 has a visible attribution error — \"Asaph et al. [5]\" does not match Azaria et al. in the bibliography. That kind of mistake is small in isolation but matters in a survey whose entire value is accurate organization of other people's work. The abstract says blockchain addresses inefficiency, while Section 4 concedes blockchain cannot compete with centralized solutions; the paper never reconciles this tension.\n\nThe self-citations are worth noting but not damning on their own. Citing their own prior survey to motivate the focus is normal; including MediChain in the table is fine if it is relevant work. The problem is that when the authors' own work appears alongside mislabeled rows, the reader cannot trust the corpus boundaries.\n\nVerdict: I would not send this to a serious referee as is. It is a workshop-grade survey with a useful bibliography, not a reliable state of the art. If the authors wanted to make it publishable in a stronger venue, they would need to state a methodology, fix the table and reference mismatches, and treat the performance tension as an actual issue rather than two disconnected statements. For a newcomer looking for pointers into the 2017–2019 literature, it is still marginally useful.","headline":"A useful starting bibliography marred by an unstated corpus, missing table entries, and attribution errors; the 'state of the art' claim does not hold up.","tokens_in":10108,"tokens_out":1976,"would_cite":false,"duration_ms":20157,"reading_group":"no","serious_thinker":"unclear","would_accept_peer_review":false},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"The survey claims blockchain removes the trusted third party from access control and that surveyed systems show this works across healthcare, IoT, cloud, and multi-organization settings.","keywords":["blockchain","access control","smart contracts","distributed ledgers","attribute-based encryption","role-based access control","Internet of Things","healthcare data sharing"],"falsifier":"Set up a permissioned ledger in which a role-based policy is enforced by a smart contract, then ask one compromised validating peer to issue an access grant after the policy has been revoked. If that peer can still produce the grant and the audit log shows no disagreement, the paper's core claim that distributed consensus and immutability remove the single point of failure would fail in its own setting. On the completeness side, a systematic literature search with explicit inclusion criteria that finds a substantial cluster of excluded approaches, such as dynamic, self-generated policies, would undercut the survey's portrait of the gaps.","tokens_in":9092,"feed_emoji":"🔐","tokens_out":11181,"duration_ms":99338,"temperature":0.7,"pith_summary":"This paper surveys blockchain-based access control to establish that moving policy storage and enforcement onto distributed ledgers can fix the three standard complaints about current systems: reliance on a third party that can leak data, single points of failure, and weak or coarse-grained enforcement. It works through roughly two dozen proposed systems, classifying each by domain (healthcare, IoT, cloud federation, multi-organization, and general data sharing), access-control method (attribute-based, role-based, fine-grained), and blockchain platform (Bitcoin, Ethereum, Hyperledger Fabric, MultiChain). The paper's position is that blockchain is best used as supplementary infrastructure: records and policies on-chain, bulk data off-chain, and smart contracts doing the enforcement, not as a wholesale replacement for access control. If the paper is right, the forward path in data-heavy domains is hybrid, with a ledger for trust and audit, a conventional storage stack for data, and smart contracts as the policy-enforcement layer. The remaining blockers are listed as smart-contract security, on-chain/off-chain integration, transaction transparency versus privacy, and performance that still cannot match centralized systems.","feed_headline":"Survey: blockchain fixes access control's third-party problem","feed_subtitle":"A catalog of 20+ systems shows smart contracts and permissioned ledgers carrying the field's path forward.","key_machinery":"The survey's carrying device is its classification table, which pins every surveyed system to a triple: domain, access-control method, and blockchain platform. The comparison is driven by a short list of blockchain properties: distributed consensus removes the single point of failure and the third party; immutability and auditability turn the ledger into a truthful history of permission decisions; smart contracts enforce policies automatically, including time-limited or conditional grants; and permissioned platforms buy back transaction privacy at the cost of pure decentralization. This classification does the argumentative work, showing that the same handful of blockchain features recurs across unrelated domains and exposing the open challenges (off-chain/on-chain integration, smart-contract security, transparency, performance) that do not belong to any single domain.","core_discovery":"The central discovery, stated on the paper's own terms, is that blockchain-based access control has settled into a recognizable design pattern. Early systems stored access policies directly in Bitcoin transactions using OP_RETURN and MULTISIG; later systems moved to smart contracts, which give policy enforcement enough flexibility to check complex conditions, revoke permissions, and log every grant or denial. Across domains the paper observes a split: attribute-based encryption dominates data-sharing and IoT proposals, while role-based control appears in hospital records (MedRec, Ancile, MediChain) and physical access control. User-centricity is an explicit goal of several systems, which let data owners define, monitor, and revoke their own policies, and auditability is the goal of others, which use the ledger purely as a trustworthy log. The paper also records what is not solved: performance still trails centralized systems, public transparency can clash with enterprise privacy, smart contracts are hard to write securely, and the boundary between on-chain and off-chain storage remains the weak seam.","pith_inferences":["A natural extension of the paper's own gap list is that the field will converge on a hybrid architecture of on-chain policy records, off-chain data, and trusted-execution environments for policy evaluation; the paper lists the pieces but does not name this convergence.","If the smart-contract trend continues, the research frontier should shift from designing ledgers to formally verifying policy contracts, a step the paper flags as open but does not take.","A testable benchmark follows directly from the survey: implement one access-control scenario (role revocation plus audit-log retrieval) on a centralized server, a permissioned ledger, and a public ledger; the paper's own challenge list predicts the ledger designs lose on raw performance but win on auditability and resistance to single-point-of-failure.","A systematic corpus built with explicit inclusion criteria would test whether the gap list holds; such a corpus might add dynamic, self-generated policy systems that fall outside the surveyed pattern."],"forward_implications":["Access-control deployments in healthcare, IoT, and cloud-federation settings can expect to move policy records and permission logs onto permissioned ledgers while keeping bulk data in off-chain storage.","Data owners, not platform administrators, can define, monitor, and revoke permissions directly because smart contracts automate enforcement and the ledger makes each decision auditable.","Permissioned platforms (for example, Hyperledger Fabric and MultiChain) will continue to outrank public ones for enterprise use, since transaction privacy is a requirement that public transparency cannot satisfy.","The next bottleneck will be smart-contract correctness and the on-chain/off-chain data seam rather than distributed consensus itself.","Performance comparisons in future studies will need to benchmark against centralized baselines, not only against other blockchain systems, if the efficiency claim is to be tested."],"supporting_citations":[{"why":"States the privacy-leakage and single-point-of-failure problems that motivate blockchain-based access control.","marker":"[28]"},{"why":"Anchors the user-centric privacy branch with data ownership, transparency, and revocable fine-grained access.","marker":"[60]"},{"why":"Shows the earliest approach of storing access-control policies in Bitcoin transactions via OP_RETURN and MULTISIG.","marker":"[35]"},{"why":"Marks the shift from plain transactions to smart contracts for enforcing access-control policies on Ethereum.","marker":"[17]"},{"why":"Supplies the healthcare user-centric permission-management example that grounds the medical-data cluster.","marker":"[5]"},{"why":"Provides the data-sharing pattern combining attribute-based encryption, off-chain IPFS storage, and Ethereum smart contracts.","marker":"[51]"},{"why":"Gives the cloud-federation case that hides user attributes while checking policies and proposes blockchain plus trusted execution for integrity.","marker":"[2]"},{"why":"Represents the permissioned, role-based design line with medical data sharing on Hyperledger Fabric.","marker":"[42]"},{"why":"Uses a permissioned blockchain to distribute and record access policies in multi-administrative domains.","marker":"[40]"}],"fun_headline_variants":["Blockchain access control: survey maps designs and gaps","Survey: blockchain access control's pattern and pitfalls","Smart contracts lead blockchain access control, survey finds","From Bitcoin scripts to smart contracts: access control survey","Blockchain access control: strengths, splits, and challenges"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The load-bearing premise is that the roughly two dozen papers surveyed, chosen without stated selection criteria, fairly represent the state of blockchain-based access control; if the selection is biased, the claimed design pattern and the list of open gaps may not generalize.","fun_headline_variants_meta":{"raw":{"variants":["Blockchain access control: survey maps designs and gaps","Survey: blockchain access control's pattern and pitfalls","Smart contracts lead blockchain access control, survey finds","From Bitcoin scripts to smart contracts: access control survey","Blockchain access control: strengths, splits, and challenges"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000202,"raw_usage":{"total_tokens":1324,"prompt_tokens":831,"completion_tokens":493,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":447,"completion_tokens_details":{"reasoning_tokens":418}},"tokens_in":447,"tokens_out":493,"duration_ms":5743,"temperature":1.0,"reasoning_tokens":418,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-14T11:36:07.069442+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Set up a permissioned ledger in which a role-based policy is enforced by a smart contract, then ask one compromised validating peer to issue an access grant after the policy has been revoked. If that peer can still produce the grant and the audit log shows no disagreement, the paper's core claim that distributed consensus and immutability remove the single point of failure would fail in its own setting. On the completeness side, a systematic literature search with explicit inclusion criteria that finds a substantial cluster of excluded approaches, such as dynamic, self-generated policies, would undercut the survey's portrait of the gaps.","supporting_citations":[{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"States the privacy-leakage and single-point-of-failure problems that motivate blockchain-based access control."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Anchors the user-centric privacy branch with data ownership, transparency, and revocable fine-grained access."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Shows the earliest approach of storing access-control policies in Bitcoin transactions via OP_RETURN and MULTISIG."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Marks the shift from plain transactions to smart contracts for enforcing access-control policies on Ethereum."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Supplies the healthcare user-centric permission-management example that grounds the medical-data cluster."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Provides the data-sharing pattern combining attribute-based encryption, off-chain IPFS storage, and Ethereum smart contracts."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Gives the cloud-federation case that hides user attributes while checking policies and proposes blockchain plus trusted execution for integrity."},{"cited_title":"Rouhani, L","cited_arxiv_id":null,"evidence_quote":"Represents the permissioned, role-based design line with medical data sharing on Hyperledger Fabric."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Uses a permissioned blockchain to distribute and record access policies in multi-administrative domains."}],"review_version":1}