Trustworthy Inter-Provider Agreements in 6G Using a Privacy-Enabled Hybrid Blockchain Framework

Farhana Javed; Josep Mangues-Bafalluy

REVIEW 4 major objections 4 minor 20 references

Trustworthy Inter-Provider Agreements in 6G Using a Privacy-Enabled Hybrid Blockchain Framework

T0 review · 4 major / 4 minor · reviewed 2026-08-16 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read A hybrid blockchain can carry the full 6G inter-provider agreement lifecycle, keeping SLA breach records confidential without hiding service discovery.

desk verdict 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. read the letter →

arxiv 2505.02513 v1 pith:H2IARBAN submitted 2025-05-05 cs.NI

Farhana Javed , Josep Mangues-Bafalluy This is my paper · ORCID

classification cs.NI

keywords 6Gnetworksinter-provideragreementshybridblockchainHyperledgerBesuTesseraprivacygroupssmartcontractsSLAbreachreportingIBFT2.0

verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

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.

What carries the argument

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.

What would settle it

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.

Watch

Extended reading notes

Core claim

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.

Load-bearing premise

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.

Editorial extensions

If this is right

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.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

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.

Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Desk Editor's Note

read the 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.

The 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.

Smaller 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.

Overall: 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.

Referee Report

4 major / 4 minor

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.

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 (4)

[Section IV, Figure 4, Section V.B] 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 IV, Figure 4] 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 IV, Table IV] 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 IV] 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.

minor comments (4)

[Section III-B, Figure 1] Please fix typos: "setp 3" and "setp 4" should be "step 3" and "step 4," and "5Grwoth" in Figure 1 should be "5Growth."
[References] Reference [6] is explicitly marked as a "placeholder reference" and should be replaced with a concrete, verifiable citation before publication.
[Section IV] The phrase "averaging above 5 seconds" is not a precise statistic; report the mean, median, and dispersion along with the sample size.
[General] Consider adding an artifact availability statement or a link to the PoC code and configuration files; this would substantially improve reproducibility.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity found: the paper reports direct latency measurements from a testbed and the central claims are empirical interpretations, not derivations from fitted inputs or self-cited theorems.

full rationale

This paper contains no derivation chain of the kind that can be circular. It proposes a hybrid Besu/Tessera architecture, deploys a Docker-based PoC, and measures end-to-end latency for public and private transactions. The abstract's claim that private transactions incur overhead 'due to off-chain coordination' and that IBFT 2.0 had 'limited impact on private transaction latency' is presented as an interpretation of observed latency ranges, not as a result derived from an equation, fitted parameter, or imported uniqueness theorem. No quantity is defined in terms of another measured quantity such that the conclusion is forced by construction; the public-latency and private-latency figures are independent observations. The self-citations [17], [18], [19] are used only to motivate the research gap and are not load-bearing for any measured result. The main weakness, that block-interval effects are not isolated by a controlled experiment, is a correctness or evidentiary concern about causal attribution, not circularity. Accordingly, the appropriate finding is no significant circularity.

Assumptions & free parameters 0 free parameters · 4 assumptions · 0 invented entities

No parameters are fitted to data. The paper's conclusions rest on platform behavior and on the representativeness of a single-host testbed, which is not independently validated.

assumptions (4)

domain assumption The four requirements in Table II (registration, advertisement/selection, privacy-enabled lifecycle) fully cover the inter-provider agreement lifecycle
The contract design maps directly to these requirements; no evidence is given that this workflow is complete or representative of 6G agreements.
domain assumption Hyperledger Besu and Tessera provide the confidentiality and tamper-evidence properties the framework relies on
The paper cites platform behavior and ETSI guidelines but does not independently verify the security properties.
domain assumption A single-host deployment is representative of inter-domain operation
Section IV uses one Linux host for all nodes, excluding network propagation delay between domains; the paper does not state this as a limitation when drawing performance conclusions.
domain assumption IBFT 2.0 with four validators provides Byzantine fault tolerance and immediate finality
Stated in Section IV without a proof; it relies on standard IBFT 2.0 specifications.

how reviews work

0 comments

Cite this review

Pith. "Pith review of Trustworthy Inter-Provider Agreements in 6G Using a Privacy-Enabled Hybrid Blockchain Framework." pith.science (2026). https://pith.science/paper/H2IARBAN

@misc{pith2026250502513,
  author       = {Pith},
  title        = {Pith review of: Trustworthy Inter-Provider Agreements in 6G Using a Privacy-Enabled Hybrid Blockchain Framework},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/H2IARBAN}},
  note         = {Machine review of arXiv:2505.02513}
}

read the original abstract

Inter-provider agreements are central to 6G networks, where administrative domains must securely and dynamically share services. To address the dual need for transparency and confidentiality, we propose a privacy-enabled hybrid blockchain setup using Hyperledger Besu, integrating both public and private transaction workflows. The system enables decentralized service registration, selection, and SLA breach reporting through role-based smart contracts and privacy groups. We design and deploy a proof-of-concept implementation, evaluating performance using end-to-end latency as a key metric within privacy groups. Results show that public interactions maintain stable latency, while private transactions incur additional overhead due to off-chain coordination. The block production rate governed by IBFT 2.0 had limited impact on private transaction latency, due to encryption and peer synchronization. Lessons learned highlight design considerations for smart contract structure, validator management, and scalability patterns suitable for dynamic inter-domain collaboration. Our findings offer practical insights for deploying trustworthy agreement systems in 6G networks using privacy-enabled hybrid blockchains.

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

20 extracted references · 19 canonical work pages

[6]

Exploring blockchain-based settlement through catalyst projects,

“Exploring blockchain-based settlement through catalyst projects,” TM Forum, 2021, placeholder reference. See https://www.tmforum.org/ catalysts/ for various Catalyst projects

work page 2021
[1]

Camara: Telco global api alliance,

GSMA, “Camara: Telco global api alliance,” https://www.gsma.com/, accessed: 20-06-2023. [Online]. Available: https://www.gsma.com/futurenetworks/ip services/understanding-5g/ camara-telco-global-api-alliance/

work page 2023
[2]

Architecture en- hancements for PDL service provisioning in telecom networks,

European Telecommunications Standards Institute, “Architecture en- hancements for PDL service provisioning in telecom networks,” Euro- pean Telecommunications Standards Institute, Sophia Antipolis, France, ETSI Group Specification ETSI GS PDL 024 V1.1.1, November 2024, available at: https://www.etsi.org/deliver/etsi gs/PDL/001 099/024/01. 01.01 60/gs PDL0...

work page 2024
[3]

Technical Specification 23.251: Network Sharing; Architecture and Functional Description,

3GPP, “Technical Specification 23.251: Network Sharing; Architecture and Functional Description,” 3rd Generation Partnership Project (3GPP), Tech. Rep. TS 23.251, 2022, https://www.3gpp.org/DynaReport/23251. htm

work page 2022
[4]

Permissioned Distributed Ledger (PDL); Application Scenarios,

ETSI, “Permissioned Distributed Ledger (PDL); Application Scenarios,” European Telecommunications Standards Institute (ETSI), Tech. Rep. GR PDL 003 V1.1.1, Dec. 2020. [Online]. Available: https://www.etsi.org/deliver/etsi gr/PDL/001 099/003/01.01. 01 60/gr PDL003v010101p.pdf

work page 2020
[5]

6g trustworthiness considerations,

NGMN Alliance, “6g trustworthiness considerations,” https://www. ngmn.org, October 2023, accessed: 2025-03-10

work page 2023
[7]

Permissioned distributed ledgers (pdl); interoperability and se- curity,

ETSI, “Permissioned distributed ledgers (pdl); interoperability and se- curity,” European Telecommunications Standards Institute (ETSI), Tech. Rep. GR PDL 007, 2019, https://www.etsi.org/deliver/etsi gr/PDL/001 099/007/01.01.01 60/gr pdl007v010101p.pdf

work page 2019
[8]

Permissioned Distributed Ledgers (PDL); Smart Contracts Sys- tem Architecture and Functional Specification,

——, “Permissioned Distributed Ledgers (PDL); Smart Contracts Sys- tem Architecture and Functional Specification,” European Telecommu- nications Standards Institute (ETSI), Tech. Rep. GR PDL 004 V1.1.1, Feb. 2021

work page 2021

Show all 20 references

[9]

Beat: Blockchain- enabled accountable and transparent network sharing in 6g,

T. Faisal, M. Dohler, S. Mangiante, and D. R. Lopez, “Beat: Blockchain- enabled accountable and transparent network sharing in 6g,” IEEE Communications Magazine, vol. 60, no. 4, pp. 52–56, 2022

2022
[10]

Federation in dynamic environments: Can blockchain be the solution?

K. Antevski and C. J. Bernardos, “Federation in dynamic environments: Can blockchain be the solution?” IEEE Communications Magazine , vol. 60, no. 2, pp. 32–38, 2022

2022
[11]

Blockchain in next generation networks (ngns),

M. Xevgenis, D. G. Kogias, and H. C. Leligou, “Blockchain in next generation networks (ngns),” in Handbook of Blockchain Technology . Edward Elgar Publishing, 2025, pp. 329–348

2025
[12]

Performance evaluation of private and public blockchains for multi-cloud service federation,

A. Zahir, M. Groshev, K. Antevski, C. J. Bernardos, C. Ayimba, and A. De La Oliva, “Performance evaluation of private and public blockchains for multi-cloud service federation,” in Proceedings of the 25th International Conference on Distributed Computing and Network- ing, 2024...

2024
[13]

End-to-end latency analysis and optimal block size of proof-of-work blockchain applica- tions,

F. Wilhelmi, S. Barrachina-Mu ˜noz, and P. Dini, “End-to-end latency analysis and optimal block size of proof-of-work blockchain applica- tions,” IEEE Communications Letters , vol. 26, no. 10, pp. 2332–2335, 2022

2022
[14]

Blockchain and smart contracts for telecommunications: Requirements vs. cost analysis,

N. Afraz, F. Wilhelmi, H. Ahmadi, and M. Ruffini, “Blockchain and smart contracts for telecommunications: Requirements vs. cost analysis,” IEEE Access, 2023

2023
[15]

Applying blockchain consensus mechanisms to network service federation: Analysis and performance evaluation,

K. Antevski and C. J. Bernardos, “Applying blockchain consensus mechanisms to network service federation: Analysis and performance evaluation,” Computer Networks, vol. 234, p. 109913, 2023

2023
[16]

An overview of distributed firewalls and controllers intended for mobile cloud com- puting,

C. G. Suetor, D. Scrimieri, A. Qureshi, and I.-U. Awan, “An overview of distributed firewalls and controllers intended for mobile cloud com- puting,” Applied Sciences, vol. 15, no. 4, p. 1931, 2025

1931
[17]

Blockchain-based 6g inter-provider agreements: Auction vs. marketplace,

F. Javed and J. Mangues-Bafalluy, “Blockchain-based 6g inter-provider agreements: Auction vs. marketplace,” in GLOBECOM 2022-2022 IEEE Global Communications Conference . IEEE, 2022, pp. 1271–1277

2022
[18]

Blockchain-based sla management for inter-provider agree- ments,

——, “Blockchain-based sla management for inter-provider agree- ments,” in 2022 IEEE Conference on Network Function Virtualization and Software Defined Networks (NFV-SDN). IEEE, 2022, pp. 155–161

2022
[19]

An empirical smart contracts latency analysis on ethereum blockchain for trustworthy inter-provider agreements,

——, “An empirical smart contracts latency analysis on ethereum blockchain for trustworthy inter-provider agreements,” 2025. [Online]. Available: https://arxiv.org/abs/2503.01397

2025 arXiv
[20]

The road to trustworthy 6g: A survey on trust anchor technologies,

B. Veith, D. Krummacker, and H. D. Schotten, “The road to trustworthy 6g: A survey on trust anchor technologies,” IEEE Open Journal of the Communications Society, vol. 4, pp. 581–595, 2023

2023

Pith tools

Reviewed August 16, 2026 · model on record in the stance chip above.

[1] [6]

Exploring blockchain-based settlement through catalyst projects,

“Exploring blockchain-based settlement through catalyst projects,” TM Forum, 2021, placeholder reference. See https://www.tmforum.org/ catalysts/ for various Catalyst projects

work page 2021

[2] [1]

Camara: Telco global api alliance,

GSMA, “Camara: Telco global api alliance,” https://www.gsma.com/, accessed: 20-06-2023. [Online]. Available: https://www.gsma.com/futurenetworks/ip services/understanding-5g/ camara-telco-global-api-alliance/

work page 2023

[3] [2]

Architecture en- hancements for PDL service provisioning in telecom networks,

European Telecommunications Standards Institute, “Architecture en- hancements for PDL service provisioning in telecom networks,” Euro- pean Telecommunications Standards Institute, Sophia Antipolis, France, ETSI Group Specification ETSI GS PDL 024 V1.1.1, November 2024, available at: https://www.etsi.org/deliver/etsi gs/PDL/001 099/024/01. 01.01 60/gs PDL0...

work page 2024

[4] [3]

Technical Specification 23.251: Network Sharing; Architecture and Functional Description,

3GPP, “Technical Specification 23.251: Network Sharing; Architecture and Functional Description,” 3rd Generation Partnership Project (3GPP), Tech. Rep. TS 23.251, 2022, https://www.3gpp.org/DynaReport/23251. htm

work page 2022

[5] [4]

Permissioned Distributed Ledger (PDL); Application Scenarios,

ETSI, “Permissioned Distributed Ledger (PDL); Application Scenarios,” European Telecommunications Standards Institute (ETSI), Tech. Rep. GR PDL 003 V1.1.1, Dec. 2020. [Online]. Available: https://www.etsi.org/deliver/etsi gr/PDL/001 099/003/01.01. 01 60/gr PDL003v010101p.pdf

work page 2020

[6] [5]

6g trustworthiness considerations,

NGMN Alliance, “6g trustworthiness considerations,” https://www. ngmn.org, October 2023, accessed: 2025-03-10

work page 2023

[7] [7]

Permissioned distributed ledgers (pdl); interoperability and se- curity,

ETSI, “Permissioned distributed ledgers (pdl); interoperability and se- curity,” European Telecommunications Standards Institute (ETSI), Tech. Rep. GR PDL 007, 2019, https://www.etsi.org/deliver/etsi gr/PDL/001 099/007/01.01.01 60/gr pdl007v010101p.pdf

work page 2019

[8] [8]

Permissioned Distributed Ledgers (PDL); Smart Contracts Sys- tem Architecture and Functional Specification,

——, “Permissioned Distributed Ledgers (PDL); Smart Contracts Sys- tem Architecture and Functional Specification,” European Telecommu- nications Standards Institute (ETSI), Tech. Rep. GR PDL 004 V1.1.1, Feb. 2021

work page 2021