{"id":"4e84fc03-3c81-418d-a75d-48eddccc7292","arxiv_id":"2505.02513","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":4.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"A Hyperledger Besu hybrid blockchain with public service contracts and private SLA-breach contracts is feasible for inter-provider 6G agreements, but private transactions add 1 to 6 seconds of latency.","lead":"This paper builds a hybrid blockchain for 6G network agreements, with some data visible to all and sensitive breach records kept private. It measures that private records add extra seconds of delay compared to public ones, and that the block creation rate barely affects that delay.","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The claim that IBFT 2.0 block interval has limited impact on private-transaction latency is unsupported and likely confounded by the ~5 s block period; the paper's central performance trade-off is not demonstrated.","rationale":"The reader's weakest assumption was that the single-host Docker testbed does not represent a geographically distributed 6G deployment. That is a valid external-validity concern, but the more fundamental issue is internal: the reported private-transaction latencies (1–6 s) cannot support the causal attribution that the block interval has limited impact, because the paper defines end-to-end latency as time to final confirmation on the blockchain, which requires block inclusion. With a 5 s block period, the measured 1–6 s range is consistent with block-wait time dominating, so the conclusion could be inverted. The absence of error bars and n=2 in Figure 4 further weaken the empirical support. The paper does demonstrate a working proof of concept for public registration, advertisement, selection, and private breach recording, so the core feasibility claim is not contradicted; however, the performance-based rationale for the architecture is not secure. The reader already assigned CONDITIONAL, and this concern strengthens the conditions rather than changing the verdict, so UNCHANGED is appropriate.","tokens_in":10209,"tokens_out":4211,"duration_ms":49369,"concrete_test":"Re-run the Section IV experiment on the same testbed but vary the IBFT 2.0 block period in the genesis configuration (e.g., blockperiodseconds = 1, 2, 5, 10) while keeping Tessera and node topology fixed. For each setting, measure end-to-end latency for deployContract() and registerBreach() with at least 20 repetitions per setting and report medians and interquartile ranges. If median private-transaction latency increases with blockperiodseconds (e.g., by roughly the same increment as block period), the claim that block production has limited impact on private latency is falsified; if it is flat across a 10× change in block period, the claim is supported.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The most load-bearing concern is the causal attribution in the abstract and Sections IV–V: that the IBFT 2.0 block interval has 'limited impact' on private-transaction latency, with encryption and peer synchronization as the main cost. This is not established by the reported measurements and is arguably contradicted by them. In Hyperledger Besu, a private transaction is not finalized until its marker transaction is included in a block; with an approximately five-second IBFT block period, end-to-end latency to on-chain confirmation should contain a 0–5 s block-wait component (average ~2.5 s) plus Tessera encryption/distribution time. The paper reports public transaction latency 'around 5 seconds' and private registerBreach latency ranging from 1 to over 6 seconds. The 1–6 s range is precisely what one expects from arrival phase relative to a 5 s block interval plus overhead; it does not demonstrate insensitivity to block interval. No experiment varies blockperiodseconds; the data has only two reported points (n=2, Figure 4) and no error bars. Thus the headline trade-off—'private transactions incur overhead due to off-chain encryption and synchronization, rather than block production'—is an unsupported interpretation. If block-wait time is a large share of the 1–6 s range, the conclusion inverts: the consensus block interval may be the dominant factor, and the architectural lesson about privacy overhead would be misleading for 6G deployment decisions.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper proposes a hybrid permissioned blockchain framework, built on Hyperledger Besu with Tessera, for inter-provider agreements in 6G. Public smart contracts handle domain registration, service advertisement, and service selection, while a private contract inside dynamic privacy groups records SLA breaches. The authors deploy a Docker-based proof-of-concept with three Besu nodes, three Tessera nodes, and four validators under IBFT 2.0, and measure end-to-end latency for public and private operations. They report stable public latency around 5 seconds and variable private latency from 1 to over 6 seconds, and conclude that private-transaction overhead comes mainly from Tessera encryption and peer synchronization rather than the IBFT block interval. The paper closes with design lessons for smart contract modularization, validator management, and scalability.","tokens_in":10478,"tokens_out":4306,"duration_ms":54812,"significance":"If the performance interpretation were supported, the paper would provide a useful implementation-driven feasibility blueprint for privacy-enabled inter-provider agreements in 6G. The strengths are the concrete PoC, the explicit mapping of lifecycle requirements to public/private contract roles, and the qualitative lessons about contract modularization and privacy-group handling. The paper does not contain machine-checked proofs or released code, and the empirical evidence is thin; the central causal claim about block-interval impact is not demonstrated by the reported measurements. The topic is timely and the framework is plausible, but the quantitative conclusions need substantial strengthening before they can guide deployment decisions.","major_comments":[{"comment":"The claim that the IBFT 2.0 block interval has \"limited impact\" on private transaction latency is not established by the reported data. In Besu, a private transaction is finalized only when its public marker transaction is included in a block; with a block period of approximately 5 seconds, observed private latencies of 1 to over 6 seconds are exactly what one would expect from a 0-5 second block-wait component plus Tessera overhead. No experiment varies the block interval, and the data shown (Figure 4, n=2, no error bars) cannot separate the block-wait component from encryption/synchronization time. Please report latency distributions under controlled variations of the block interval (for example 1 s, 5 s, and 10 s) and revisit the causal attribution in the abstract and conclusion if the block-wait component is large.","section":"Section IV, Figure 4, Section V.B"},{"comment":"The quantitative performance claims rest on too little data. The text reports public operations as \"around 5 seconds,\" private contract deployment as \"averaging above 5 seconds,\" and registerBreach latency as \"1 to over 6 seconds,\" but no trial counts, confidence intervals, standard deviations, or run conditions are provided, and Figure 4 appears to contain only two data points (n=2). This is insufficient to support the assertion that public interactions \"maintain stable latency\" or to quantify the overhead of private transactions. Please report sample sizes, full distributions, and the number of independent runs for each operation.","section":"Section IV, Figure 4"},{"comment":"The topology description is internally inconsistent: the text and Table IV state that there are three Besu nodes and three Tessera nodes, but also that the validator set contains four nodes. Clarify whether every validator is a Besu node, whether the fourth validator exists outside the privacy-enabled set, and whether all validators participate in privacy groups. This mapping matters for interpreting consensus latency and for understanding which nodes receive private payloads.","section":"Section IV, Table IV"},{"comment":"All nodes in the testbed run on a single host (Ubuntu 22.04 on one i7-1265U machine), so all inter-node communication is loopback and no inter-domain network latency is present. The conclusion that private-transaction latency is dominated by Tessera encryption and peer synchronization rather than network factors cannot be extrapolated to geographically distributed 6G providers without additional evidence. Please qualify the performance conclusions to the single-host setting or add experiments on a distributed testbed with realistic WAN delays.","section":"Section IV"}],"minor_comments":[{"comment":"Please fix typos: \"setp 3\" and \"setp 4\" should be \"step 3\" and \"step 4,\" and \"5Grwoth\" in Figure 1 should be \"5Growth.\"","section":"Section III-B, Figure 1"},{"comment":"Reference [6] is explicitly marked as a \"placeholder reference\" and should be replaced with a concrete, verifiable citation before publication.","section":"References"},{"comment":"The phrase \"averaging above 5 seconds\" is not a precise statistic; report the mean, median, and dispersion along with the sample size.","section":"Section IV"},{"comment":"Consider adding an artifact availability statement or a link to the PoC code and configuration files; this would substantially improve reproducibility.","section":"General"}],"recommendation":"major_revision","confidential_remarks":"The feasibility of the hybrid Besu/Tessera framework is credible and the paper addresses a relevant 6G problem. The main weakness is the unsupported causal claim about block-interval impact on private transactions; this needs controlled experiments and better statistics before the paper can be accepted. The single-host testbed limitation should also be acknowledged more explicitly in the conclusions."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"First, the useful part. This group has built a working hybrid Besu/Tessera testbed and mapped the inter-provider agreement lifecycle onto four role-based contracts: three public, one private for SLA breaches. That modular split is a reasonable design and is more concrete than most blockchain-in-6G papers. The latency measurements, thin as they are, are direct observations and the paper doesn't hide its PoC nature. The lessons learned—privacy group reuse, contract modularity, validator management—are sensible and should be useful to people trying to replicate this stack.\n\nThe soft spot is the headline performance claim. The paper says IBFT 2.0 block interval had limited impact on private transaction latency, attributing the cost to Tessera's off-chain encryption and sync. That is not what the data show. In Besu, a private transaction is only finalized when its marker transaction lands in a block. With a ~5s IBFT block period, you expect a 0–5s block-wait component, which is exactly the 1–6s range they report for registerBreach. They never vary blockperiodseconds, so they cannot separate block waiting from Tessera overhead. The causal attribution in the abstract and Section IV is therefore unsupported, and likely wrong in the sense that block interval is a dominant contributor. This should be fixed by removing the claim or running a proper experiment.\n\nSmaller issues: Figure 4 has n=2 with no error bars or trial counts; the testbed is single-host, so inter-domain network latency is absent; there are three Besu nodes but four validators listed; reference [6] is a placeholder; and no code is released. None of these sink the feasibility result, but they prevent the performance conclusions from being generalized.\n\nOverall: this is a legitimate PoC contribution to the blockchain-in-telecom literature, not a fundamental advance. I would send it to peer review—the architecture and the honest feasibility demonstration deserve referee time—but I'd push for a major revision that either removes the block-interval claim or tests it properly.","headline":"Useful hybrid Besu/Tessera PoC for 6G inter-provider agreements, but the claim that IBFT block interval barely affects private latency is unsupported by the data.","tokens_in":10983,"tokens_out":2444,"would_cite":false,"duration_ms":28282,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"A hybrid blockchain can carry the full 6G inter-provider agreement lifecycle, keeping SLA breach records confidential without hiding service discovery.","keywords":["6G networks","inter-provider agreements","hybrid blockchain","Hyperledger Besu","Tessera privacy groups","smart contracts","SLA breach reporting","IBFT 2.0"],"falsifier":"Deploy the same contracts with each administrative domain's node on a separate host separated by a realistic WAN link and measure registerBreach() latency as block interval is varied; if private latency tracks the block interval rather than the privacy layer's sync time, the paper's attribution of overhead to encryption and peer synchronization would be overturned.","tokens_in":10018,"feed_emoji":"🔐","tokens_out":6240,"duration_ms":70026,"temperature":0.7,"pith_summary":"This paper argues that a single hybrid blockchain, running one public ledger for service registration, advertisement, and selection and a separate private channel for SLA breach records, is a workable trust layer for 6G inter-provider agreements. The authors build a proof of concept with role-based smart contracts and measure end-to-end latency for both paths. Public operations stay near five seconds, while private operations range from one to over six seconds. The extra private cost comes from encryption and peer synchronization in the privacy layer, not from the consensus protocol's block interval. The payoff, if the design holds, is a concrete blueprint for making multi-operator agreements both auditable and commercially confidential.","feed_headline":"Hybrid blockchain secures 6G agreements; privacy adds latency","feed_subtitle":"Private SLA breach records stay confidential, but encryption and peer sync add seconds of latency compared with public transactions.","key_machinery":"The mechanism is a hybrid transaction architecture: a permissioned Ethereum-compatible ledger (Hyperledger Besu) with a separate privacy manager (Tessera). Four role-based smart contracts split the agreement lifecycle—RegistrationAD.sol, AddService.sol, and SelectService.sol handle public registration, advertisement, and selection, while RegisterBreach.sol runs inside a privacy group for SLA breach records. The privacy manager encrypts private payloads, distributes them only to authorized group members, and maintains a separate private state, so the privacy group does the confidentiality work while the public ledger carries the transparent part of the workflow. Validators run IBFT 2.0 consensus with a four-validator set, producing blocks on roughly a five-second interval, but that interval only governs public finality; private transactions wait on the privacy layer's off-chain coordination.","core_discovery":"The central claim is that the inter-provider agreement lifecycle can be split by visibility without splitting the system: registration, advertisement, and selection run as public transactions on a permissioned Ethereum-compatible ledger, while SLA breach reporting runs as private transactions inside dynamically formed privacy groups restricted to the consumer and the chosen provider. Deploying the private contract and calling its breach-registration function both add measurable delay—averaging above five seconds for deployment and varying from one to over six seconds per call—whereas the public operations stay at roughly five seconds. Because private data travels through the privacy manager's encrypt-and-distribute path before any block is produced, the IBFT 2.0 five-second block interval has limited influence on private transaction latency. The paper presents this as evidence that privacy enforcement, not consensus timing, dominates the cost of confidentiality.","pith_inferences":["If the single-host testbed is replaced by geographically distributed provider domains, the private transaction overhead the authors attribute to encryption and synchronization will likely grow with wide-area network delay, while public latency may also rise; this remains untested in the paper.","The same split could apply to neighboring problems such as spectrum sharing agreements or multi-operator edge-compute leases, where public discovery plus private terms follows the same pattern.","A direct experiment that varies the number of privacy-group members while holding block interval fixed would quantify how much of the private overhead scales with group size, a dimension the paper leaves implicit.","Because gas costs are set to zero in the permissioned testbed, the economics of private transactions may differ in fee-based deployments; paid gas could change which functions dominate."],"forward_implications":["A single hybrid ledger can replace separate public and private systems for multi-operator coordination: domains register and advertise openly, but negotiated SLA breaches remain visible only to the parties involved.","In this testbed, public registration, service listing, and selection complete in about five seconds, while private contract deployment and breach registration add one to several seconds of overhead.","Tuning block interval or consensus speed will not meaningfully speed up private SLA workflows; reducing private latency means shrinking encryption, peer synchronization, and payload-handling costs.","The current four-validator IBFT 2.0 setup favors a small, stable validator set; scaling to many domains will require dynamic validator management rather than static configuration.","Design patterns like storing hashed SLA references, emitting encrypted events, and avoiding loops in private contracts can contain the extra private cost."],"supporting_citations":[{"why":"Supplies the 'trustworthiness by design' requirement for 6G that the framework is built to satisfy.","marker":"[5]"},{"why":"Provides a prior blockchain-based network sharing approach that this work extends with privacy-enabled transactions.","marker":"[9]"},{"why":"Motivates blockchain as a solution for federation in dynamic multi-domain environments.","marker":"[10]"},{"why":"Offers a prior performance comparison of private and public blockchains for service federation, which the paper distinguishes from its transaction-level analysis.","marker":"[12]"},{"why":"Informs the analysis of consensus mechanisms and validator trade-offs in network service federation.","marker":"[15]"},{"why":"The authors' earlier auction-versus-marketplace comparison that this work extends into a privacy-enabled hybrid design.","marker":"[17]"},{"why":"The authors' earlier SLA management work that the current privacy-enabled breach reporting builds on.","marker":"[18]"},{"why":"Supplies the prior empirical latency methodology for smart contracts that the present evaluation adapts to private transactions.","marker":"[19]"},{"why":"Supports the framing of blockchain and trust anchors for trustworthy 6G systems.","marker":"[20]"}],"fun_headline_variants":["Hybrid chain: privacy costs seconds in 6G deals","6G blockchain: public fast, private slow","Privacy, not consensus, slows 6G smart contracts","SLA breach reporting lags on private 6G chain","Hybrid ledger: public speed, private latency"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The latency conclusions rest on a Docker testbed where all blockchain and privacy-manager nodes run on one host, so the measured private-transaction overhead does not include real geographic inter-domain network delay.","fun_headline_variants_meta":{"raw":{"variants":["Hybrid chain: privacy costs seconds in 6G deals","6G blockchain: public fast, private slow","Privacy, not consensus, slows 6G smart contracts","SLA breach reporting lags on private 6G chain","Hybrid ledger: public speed, private latency"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000149,"raw_usage":{"total_tokens":1159,"prompt_tokens":879,"completion_tokens":280,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":495,"completion_tokens_details":{"reasoning_tokens":201}},"tokens_in":495,"tokens_out":280,"duration_ms":3970,"temperature":1.0,"reasoning_tokens":201,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-16T00:48:48.330676+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Deploy the same contracts with each administrative domain's node on a separate host separated by a realistic WAN link and measure registerBreach() latency as block interval is varied; if private latency tracks the block interval rather than the privacy layer's sync time, the paper's attribution of overhead to encryption and peer synchronization would be overturned.","supporting_citations":[{"cited_title":"6g trustworthiness considerations,","cited_arxiv_id":null,"evidence_quote":"Supplies the 'trustworthiness by design' requirement for 6G that the framework is built to satisfy."},{"cited_title":"Beat: Blockchain- enabled accountable and transparent network sharing in 6g,","cited_arxiv_id":null,"evidence_quote":"Provides a prior blockchain-based network sharing approach that this work extends with privacy-enabled transactions."},{"cited_title":"Federation in dynamic environments: Can blockchain be the solution?","cited_arxiv_id":null,"evidence_quote":"Motivates blockchain as a solution for federation in dynamic multi-domain environments."},{"cited_title":"Performance evaluation of private and public blockchains for multi-cloud service federation,","cited_arxiv_id":null,"evidence_quote":"Offers a prior performance comparison of private and public blockchains for service federation, which the paper distinguishes from its transaction-level analysis."},{"cited_title":"Applying blockchain consensus mechanisms to network service federation: Analysis and performance evaluation,","cited_arxiv_id":null,"evidence_quote":"Informs the analysis of consensus mechanisms and validator trade-offs in network service federation."},{"cited_title":"Blockchain-based 6g inter-provider agreements: Auction vs. marketplace,","cited_arxiv_id":null,"evidence_quote":"The authors' earlier auction-versus-marketplace comparison that this work extends into a privacy-enabled hybrid design."},{"cited_title":"Blockchain-based sla management for inter-provider agree- ments,","cited_arxiv_id":null,"evidence_quote":"The authors' earlier SLA management work that the current privacy-enabled breach reporting builds on."},{"cited_title":"The road to trustworthy 6g: A survey on trust anchor technologies,","cited_arxiv_id":null,"evidence_quote":"Supports the framing of blockchain and trust anchors for trustworthy 6G systems."}],"review_version":1}