A Permissioned Blockchain Architecture for National Athlete Information Management Using Hyperledger by IRJET Journal

A Permissioned Blockchain Architecture for National Athlete Information Management Using Hyperledger Fabric 2.0 and Off-Chain Storage

H. Han

1 Independent researcher, 260 Fortfield Rd, Bristol BS14 9QT, UK

Abstract - National-level athlete management requires continuous, secure information exchange among sports governing bodies, sport associations, and sports medicine and anti-doping institutes. Conventional centralized information systems exhibit single points of failure, weak auditability, and inefficient cross-organizational data sharing. This study proposesapermissionedblockchain-basedathleteinformation management system built on Hyperledger Fabric 2.0. The architecture models three key stakeholders as consortium members, employs Raft as a crash-fault-tolerant ordering service, and encodes six core transaction types personal, training, performance, health, medical, and data-sharing records through smart contracts (chaincode). To reconcile blockchain immutability with storage efficiency and privacy requirements, the system combines on-chain meta-data with off-chain JSON documents stored in CouchDB, linked via SHA256 hashes and protected by AES-256 encryption. A prototype was implemented using the Fabric First-Networkbaselineand evaluated with Hyperledger Caliper on mid-range hardware (Intel Core i5 1.6 GHz, 8 GB RAM, 1 TB SSD/HDD). Under readonly workloads, the system achieves up to 1,693.02 transactions per second (TPS) for 8 KB payloads and 164.06 TPS for 1 MB payloads, while write-only workloads reach 1,009.55 TPS and 112.87 TPS for the same sizes. These results demonstrate that the proposed architecture can sustain several hundred TPS under realistic data volumes, providing sufficient capacity for national-level athlete information management while delivering strong guarantees of integrity, confidentiality, authentication, and auditability.

Key Words: Permissionedblockchain,HyperledgerFabric, Secure data sharing, Off-chain data storage, Athlete informationmanagement

1. INTRODUCTION

Elite national sports programs operate within a multiorganizational ecosystem composed of several interdependent institutions. Governmental sports bodies establishnationalsportpolicies,overseeathleteselection, and allocate funding; national sport associations and federationsmanagesport-specifictrainingandcompetition activities; and sports medicine and anti-doping institutes monitor the medical, physiological, and biochemical wellbeing of athletes. Each of these actors maintains its own

informationsystems,generatingandmanagingvastamounts ofathlete-relateddatadailyforhundredsoreventhousands ofeliteanddevelopmentalcompetitors.Thecoexistenceof these distributed and independently operated systems creates significant challenges for data consistency, interoperability, and governance. The data generated and shared across this ecosystem encompass a wide range of sensitive and confidential information, including athlete identities, biometric profiles, competition performance indicators, injury histories, medical diagnostics, and antidopinglaboratoryresults.Safeguardingtheconfidentiality, integrity,availability,andtransparencyofthisinformationis essential not only to protect athlete privacy but also to ensure accountability, fairness, and public trust in the governance of sport. Transparency, in particular, plays a crucial role by enabling data transactions and updates to remain traceable, verifiable, and auditable across all participatingorganizationswithoutcompromisingprivacy. This allows authorized stakeholders to determine who accessedormodifiedrecords,underwhatauthority,andat what time, thereby discouraging data manipulation, favoritism,andfraudulentalterations.

Such transparency is especially vital for compliance with international oversight bodies such as the World AntiDopingAgency(WADA),wheretamper-proofreportingand audittrailsareindispensableforvalidatingtestresultsand enforcing sanctions. In the absence of standardized and transparentdata-sharingmechanisms,organizationsoften faceinformationsilos,disputesoverrecordauthenticity,and public skepticism regarding the fairness of regulatory processes. Consequently, ensuring both data security and operational transparency is fundamental to establishing a trustworthy digital ecosystem for modern sports governance.

1.1 Structural Problems in Current Practice

Threemajorstructuralproblemscharacterizethecurrent practice:

 Centralizationandsinglepointsoffailure:Training, performance,andmedicalmanagementsystemsare frequently built around centralized servers or institutionaldatabases.Anyoutage,compromise,or corruption at a single site can cascade to disrupt

International Research Journal of Engineering and Technology (IRJET) e-ISSN: 2395-0056

Volume: 12 Issue: 11 | Nov 2025 www.irjet.net p-ISSN: 2395-0072

decision-making and operational continuity at the entirenationallevel.

 Limited transparency and traceability: When informationismodifiedordeleted,itisoftendifficult toreconstructwhoperformedthechange,whenit occurred, and under whose authorization particularly when the transaction spans multiple organizations. This lack of auditability weakens institutionalaccountabilityandincreasestheriskof datamanipulationoradministrativedisputes.

 Inefficient cross-organizational data sharing: Data exchange between entities, such as between a medical institute and a national sport federation, typicallydependsonhierarchicalreportingchannels and manual approval processes. These lead to delays,dataduplication,andinformationsilosthat impede timely decision-making and coordinated athletemanagement.

1.2 Blockchain as a Candidate Solution

Blockchaintechnologyhasemergedasapotentialsolutionto severaloftheseproblemsbyprovidingareplicated,appendonlyledgerthatmultipleparticipantscanmaintainjointly. Suchledgersofferinherenttamperresistance,auditability, and decentralization. However, a naïve deployment of a publicblockchainformanagingathleteinformationwouldbe neitherscalablenorprivacycompliant.Publicblockchains relyonopenparticipationandenergy-intensiveconsensus mechanismssuchasproof-of-work,whichlimitthroughput andviolatelegalconstraintsrelatedtopersonalandmedical dataprotection.

1.3 Rationale for Using Hyperledger Fabric

To overcome these limitations, this study employs HyperledgerFabric,apermissionedblockchainframework designed for institutional and consortium-based environmentswhereparticipantsareknownbutmutually untrusted.Fabricversion2.0introducesenhancedlifecycle management,chaincodegovernance,andmodularconsensus options,makingitwellsuitedforsecuredatacollaboration amonggovernmentalandsportorganizations.Nonetheless, Fabricinheritsseveralfundamentalblockchainconstraints: (a)storingalldatafullyon-chainiscostlyandinefficient,and (b)itsimmutabilitycomplicatescompliancewithregulations that require data correction or selective deletion, such as GDPR’s“righttoerasure.”

1.4 Research Goals

In this work, we design and evaluate a Fabric-based national level athlete information management system to addressthesechallenges,guidedbythefollowingscientific goals:

 Toformalizeathlete-relateddataandprocessesasa set of transaction types and smart contracts that

directly map to real-world workflows such as athlete registration, training, performance monitoring,medicalrecordmanagement,andinterorganizationaldatasharing.

 To analyze and justify the adoption of the Raft consensusprotocolasacrash-fault-tolerant,leaderbased ordering service, providing deterministic transaction sequencing and operational simplicity compared with Fabric’s earlier mechanisms (Solo, Kafka) and with Byzantine fault-tolerant (BFT) alternatives.

 To design and implement an efficient off-chain storagemodelthatintegratesSHA-256hashingand AES-256 encryption with CouchDB as the state database, thereby ensuring data integrity, confidentiality,andstorageefficiency.Thisdesignis conceptually compared against pure on-chain models and alternative off-chain solutions such as the Interplanetary File System (IPFS) or external objectstores.

 Toexperimentallycharacterizethroughput–latency trade-offs under realistic payload sizes and mixed workloads using Hyperledger Caliper, and to interprettheseresultswithrespecttoFabric’sread–writesetsemantics,endorsementpolicies,andblockcutting strategies that influence performance scalability.

Throughtheseobjectives,thestudyaimstodemonstrate thatawell-configuredpermissionedblockchaincanmeetthe practical requirements of national level sport data governance combining transparency, security, and regulatory compliance within heterogeneous institutional environments.

1.5 Contributions

Blockchaintechnologyhasemergedasapotentialsolution to several of these problems by providing a replicated, append-onlyledgerthatmultipleparticipantscanmaintain jointly. Such ledgers offer inherent tamper resistance, auditability, and decentralization. However, a naïve deployment of a public blockchain for managing athlete information would be neither scalable nor privacy compliant.Publicblockchainsrelyonopenparticipationand energy-intensiveconsensus mechanisms suchasproof-ofwork,whichlimitthroughputandviolatelegalconstraints relatedtopersonalandmedicaldataprotection. Ourwork makesthefollowingcontributions:

 Domain-specific governance and data model for nationwide athlete management. We design a permissionedblockchainarchitecturethatistailored totheinstitutionallandscapeofelitesport,explicitly modelling the roles and interactions of ministries, national sport federations, National Olympic Committees, National Anti-Doping Organizations, and medical providers. This includes a transaction

International Research Journal of Engineering and Technology (IRJET) e-ISSN: 2395-0056

Volume: 12 Issue: 11 | Nov 2025 www.irjet.net p-ISSN: 2395-0072

and access-control model for athlete identity, performance,medical,andanti-dopingrecordsthat captures real decision rights and accountability in nationwideathletegovernance.

 Privacy-preserving hybrid on-/off-chaindesign for sensitiveathleterecords.Weproposeandimplement a hybrid storage architecture that keeps only integrity-criticalmetadataandcryptographichashes on-chain, while storing rich medical and performance documents off-chain under organizational control. The design integrates encryption, consent-aware access control, and verifiablelinkagebetweenon-chaineventsandoffchainartefacts,therebyreconcilingtransparencyand auditabilitywithGDPR-complianthandlingofhighly sensitiveathletedata.

 Raft-basedFabricdeploymentandtransactionflow optimized for sport-governance workloads. We instantiate the architecture on Hyperledger Fabric withRaftorderingandCouchDBstatedatabases,and we engineer endorsement policies, channel structure, and chaincode logic around typical workflows in elite athlete management (e.g., registration,medicalupdates,anti-dopingreporting, andinter-organizationaldatasharing).Thisyieldsa concrete,reproduciblereferencedesignforpublicsectorsportorganizationsseekingtooperationalize blockchain-baseddatagovernance.

 Empirical performance characterization under realistic, mixed workloads. Using Hyperledger Caliper, we conduct a systematic benchmark campaign that exercises read-intensive, writeintensive, and mixed workloads with varying payload sizes that reflect realistic athlete data operations.Wereportthroughputandlatencytrends underdifferenttransactionprofilesanddiscusstheir implications for scaling a nationwide deployment, thereby providing evidence-based configuration guidance for practitioners deploying Raft-based Fabricinsimilarpublic-sectorenvironments.

2. BACKGROUND AND RELATED WORK

2.1 Centralized Athlete Information Systems

Most current athlete information systems in national programsarebuiltusingtraditionalthree-tierarchitectures: relationaldatabases,applicationservers,andwebordesktop clients.Thesesystemsarewellunderstood,relativelyeasyto develop,andofferefficientqueryperformanceforlocaluse. However,theyexhibitthreestructuralweaknesses:

 Alltrustconcentratesatthedatabaseadministrator; malicious or compromised insiders can alter or deleterecordswithoutdetection.

 A physical or logical failure at the central server (hardware, software, or network) can render the systemunavailable.



Cross-organizationalsharingmustbeimplemented via custom interfaces, batch exports, or manual reporting,whichoftenlagbehindrealtime.

Theseweaknessesbecomecriticalinelitesport,wherethe timeliness and reliability of information feed directly into selectionandtrainingdecisions.

2.2Permissioned BlockchainsandHyperledgerFabric

Permissioned blockchains restrict participation to identified entities that are authenticated through cryptographic credentials. Hyperledger Fabric implements this model through a modular architecture in which endorsingpeersexecutechaincode,orderernodesestablish totaltransactionorder,andcommittingpeersvalidateand append blocks to the ledger. The Membership Service Provider(MSP)usesX.509digitalcertificatestomanagethe identities and roles of organizations and users, allowing institutionstoalignblockchaincredentialswiththeirexisting public-key infrastructure (PKI) or national certification authorities(Androulakietal.,2018).

Unlikepublicblockchainsthatmaximizedecentralization attheexpenseofperformanceandgovernance,permissioned systems mitigate the blockchain trilemma the trade-off amongdecentralization,scalability,andsecurity bylimiting consensus participation to verified members. Excessive decentralization can create significant latency, high computational overhead, and energy inefficiency under consensus algorithms such as proof-of-work. By contrast, permissioned networks provide a balanced design that maintainstrust,auditability,andgovernancetransparency while supporting higher throughput and predictable performance(Thakkaretal.,2018).Thisbalancemakesthem particularly suitable for regulated environments such as national sports management, where both efficiency and accountabilityarerequired.

PriorresearchhasshownthatHyperledgerFabricperforms effectivelyinsupply-chain,financial,andhealthcarecontexts, often achieving thousands of transactions per second and supporting flexible endorsement policies for complex businesslogic(Androulakietal.,2018;Thakkaretal.,2018; Khanetal.2025).However,applicationsofFabricwithinthe sports domain especially for integrated athlete data management spanning training, performance, and medical records remain largely unexplored. Recent systematic reviewshighlightthisresearchgap:althoughblockchainhas beendiscussedinsportforusecasessuchasanti-doping,fan engagement,anddataownership,technicalimplementations and performance analyses are still limited (Berkani et al., 2024). This work therefore builds on existing evidence to demonstratehowapermissionedblockchaininfrastructure can address these challenges by providing a secure, transparent,andscalablefoundationfornationallevelathlete informationmanagement.

International Research Journal of Engineering and Technology (IRJET) e-ISSN: 2395-0056

Volume: 12 Issue: 11 | Nov 2025 www.irjet.net p-ISSN: 2395-0072

2.3 Consensus: Raft vs. Kafka and BFT Protocols

Early versions of Hyperledger Fabric employed Solo (a single-node, non-fault-tolerant prototype) and Kafka/ZooKeeper–based ordering services. While Kafka offered high throughput, it introduced a complex external dependencyandwasnotatrueconsensusprotocol;Fabric used it mainly for crash-fault-tolerant log replication (Androulakietal.,2018).

StartingwithFabric2.0,theplatformadoptedRaftasits primary consensus mechanism. Raft is a leader-based replicated-log algorithm that maintains a consistent state amongnodesbyelectingaleaderresponsibleforappending entriesandreplicatingthemtofollowers.Onceamajorityof nodes acknowledge an entry, it is safely committed. Raft guaranteessafetyandlivenessaslongasaquorumremains operational under typical enterprise network conditions (Ongaro & Ousterhout, 2014). Compared with Kafka, Raft integrates natively into Fabric’s architecture, reducing operational complexity and external dependencies, while providingformallyverifiedcorrectness,deterministicleader election,andsnapshottingtoboundloggrowth.

Bylimitingparticipationtoauthenticatedorganizations,Raftbased ordering achieves a practical balance between decentralizationandefficiency.Itavoidstheperformanceand governance issues of overly decentralized consensus models sometimesdescribedastheblockchaintrilemmaof decentralization, scalability, and security (Thakkar et al., 2018). Although Byzantine-fault-tolerant (BFT) protocols suchasPBFTcantoleratearbitraryormaliciousfaults,they require O(n^2) message exchanges and impose heavy communication overhead. In national level institutional contexts where ordering nodes are operated by trusted public bodies and the dominant risks involve crashes, misconfiguration, or limited insider faults Raft offers a superior throughput-to-complexity trade-off, delivering reliability and simplicity suited to real-world consortium governance.

2.4 On-Chain vs. Off-Chain Data Management

Apureon-chainstoragedesignmaintainsallapplicationdata directlywithinblockchaintransactions,ensuringcomplete co-locationofdataandmetadataunderstrongimmutability guarantees.Whilethisapproachsimplifiesverificationand preserves end-to-end provenance, it introduces several drawbacks.Theledgergrowslinearlyaseverytransaction and payload are permanently replicated across all peers, leadingtoledgerbloatanddegradedqueryperformanceover time. It also conflicts with modern data-protection frameworks most notably the General Data Protection Regulation(GDPR) whichrequires theabilityto eraseor modifypersonalinformationunderthe“righttobeforgotten” (Finck, 2019; Casino et al., 2019). Moreover, storing large binary objects on-chain inflates storage and I/O overhead, particularly in permissioned networks where every peer maintainsafullcopyoftheledger.

Toovercometheseissues,enterprise-scaleblockchains increasingly adopt off-chain data-management patterns, wherelargepayloadsaremovedtoexternalrepositories suchasrelationaldatabases,objectstores,ordistributedfile systemslikeIPFS whileonlyreferencesorcryptographic hashes are retained on-chain. This model maintains data integritybylinkingoff-chaincontenttoimmutableon-chain metadata while providing scalable storage and easier compliance witherasure requirements.The trade-offisan added layer of architectural complexity and the need to coordinatesecuritypoliciesacrossbothsystems.

In this study, we implement a hybrid off-chain storage strategy using CouchDB, the state database natively integrated with Hyperledger Fabric. Each athlete-related record is processed through a dual-layer cryptographic mechanism:(1)therawfileordataobjectisencryptedlocally usingAdvancedEncryptionStandard(AES-256)insymmetric mode,ensuringconfidentialityevenifthestoragerepository iscompromised; and (2)a SHA-256hash ofthe encrypted contentisgeneratedandwrittentotheblockchainledgeras an integrity proof. Only the metadata (file ID, timestamp, access policy, and hash) are stored on-chain, while the encryptedfileispreservedoff-chaininsecuredinstitutional storage.

The combination of AES-256 encryption and SHA-256 hashing provides complementary protection: AES-256 preventsunauthorizedaccesstotheactualcontent,whereas SHA-256 ensures tamper-evident verification of data integrity (Conti et al., 2018). Empirical evaluation of this designshowssubstantialimprovementsinthroughputand storageefficiencycomparedwithfullon-chainapproaches, whilemaintainingconfidentialityandverifiabletraceability an essential requirement for managing sensitive athlete medical and anti-doping information within national level sportdataecosystems.

3. SYSTEM MODEL AND DESIGN RATIONALE

The proposed system is a permissioned blockchain-based athlete information management platform built on HyperledgerFabric2.0,connectingnationalsportauthorities, federations,andsportsmedicineinstitutes.Itensuressecure, transparent,andauditabledataexchangeacrossinstitutions while protecting sensitive athlete information. Users are authenticatedthroughencryptedQRcodeslinkedtoX.509 certificates managed by the Membership Service Provider (MSP), enabling role-based access without exposing cryptographickeys.Athletedataarerecordedthroughsmart contracts representing six transaction types, processed by endorsing peers,and ordered usingRaft consensus, which provides crash-fault tolerance and high throughput. To balanceperformanceandprivacy,thesystemadoptsahybrid on-/off-chainstoragemodel:metadataandhashesarestored on-chain, while full records encrypted withAES-256and verified by SHA-256 hashes reside off-chain in CouchDB. Thisdesignminimizesledgergrowth,ensuresintegrityand confidentiality, and complies with data-protection regulations. Together, these components create a scalable,

International Research Journal of Engineering and Technology (IRJET) e-ISSN: 2395-0056

Volume: 12 Issue: 11 | Nov 2025 www.irjet.net p-ISSN: 2395-0072

secure, and trustworthy digital infrastructure for national levelathletedatagovernance.

Figure 3-1: Overallarchitectureoftheathlete managementsystemonHyperledgerFabricblockchain network.

3.1 Requirements and Threat Model

From domain analysis, we derive three classes of requirements:

 Functional: registration of athletes and users; creationandretrievaloftrainingdata,performance indicators, and medical records; crossorganizational information sharing; generation of daily summaries for the sports government sport body.

 Non-functional: high availability; bounded transaction latency; auditability; scalability to thousands of athletes and millions of records; support for heterogeneous devices (PCs, laptops, potentiallymobiles).

 Security: integrity (no undetected tampering), confidentiality(nounauthorizedreadingofsensitive data),authenticationandauthorizationofusersand organizations,andnon-repudiationofactions.

Thethreatmodelassumes:

 Honest-but-fallibleorganizations:mostactorsfollow the protocol, but crashes, misconfigurations, or limitedinsiderabusemayoccur.

 Network attackers with theabilityto observe and tamper with network traffic but not to break moderncryptography.

 Noglobal,coordinated,highlyresourcedadversary capableofsimultaneouslycompromisingamajority oforderingnodesandallorganizations’MSPs(such scenariosaretreatedasoutofscope).

Underthismodel,crash-fault-tolerantconsensusandstrong cryptography are appropriate, while full BFT consensus is consideredoverkill.

3.2 Consortium Structure and Network Topology

We instantiate the Fabric network with three organizations: sports government sport body, sport associations(groupedasaconsortium),andsportsmedicine institute(NADO).Eachorganizationhasoneormorepeers, and all share a common channel for national level athlete data.Thissingle-channeldesignismotivatedbytheneedfor consistent, shared views of athlete information across organizations, while access control is enforced at the applicationlayerviaMSPattributesandchaincodechecks.

Alternativedesignsinclude:

 Multiple channels for different data types (e.g., trainingvs.medical)orsports

 Privatedatacollectionsforhighlysensitivesubsets.

Wechooseasingle-channelplusrole-basedlogicasafirst stepbecauseitsimplifiesconfigurationandbenchmarking, and because many athlete-management scenarios require correlatedanalysisoftrainingandmedicaldataacrosssports. Futureworkcanextendthistomulti-channelarchitectures.

3.3 Identity Management, MSP, and QR-Based Usability

The MSP is configured to recognize the three organizations and their CAs. X.509 certificates carry attributes indicating roles (government sport body, association, medical, coach, scientist, physician). Endorsement policies and chaincode logic check these attributesbeforeallowingaccess:

 Governmentsportbody/Highestsportidentitiescan readalldataandissueaggregatequeries.

 Medical identities can read medical data for all sportsandrelatedtraining/performancedata.

 Otherrelatedidentitiescanreadandwritealldata fortheirownorrelatedathletesonly.

From a usability standpoint, directly handling long cryptographickeysandcertificatesisimpracticalforcoaches andphysicians.Therefore,weadoptencryptedQRcodesasa front-end for user credentials. When the CA issues a certificate,thesystemderivesauniqueidentifierandembeds it,inencryptedform,intoaQRcodethattheusercanstore (e.g.,printedcardorsecuredevice).Onlytheofficial client application can decrypt this QR code and retrieve the correspondingcertificatefromtheMSP.

This design trades minimal device requirements (a webcam or built-in camera) for robust, user-friendly authentication,reducingtheriskofcredentialmistypingor phishing(sincetheQRcontentisnothuman-readable).An alternative would be smart cards or hardware security tokens; these offer strongertamper resistance but require specializedhardwareandinfrastructurenotalwaysavailable insportsfacilities.

International Research Journal of Engineering and Technology (IRJET) e-ISSN: 2395-0056

Volume: 12 Issue: 11 | Nov 2025 www.irjet.net p-ISSN: 2395-0072

3.4 . Transaction Taxonomy and Chaincode Semantics

Each athlete-related event is modeled as one of six transactiontypes:personalinfo,traininginfo,performance metrics,status/healthindicators,specialistmedicalinfo,and information-sharingrequests.

Thechaincodedefines,foreachtype:

 Preconditionsoncallerauthorityandinputformat.

 Read–writesetgeneration:whichkeysarereadand whicharewrittenintotheworldstate.

Emittedevents(e.g.,fortriggerstooff-chainprocessesor reporting).

A design challenge in Fabric is the read–write set semantics:whenendorsingpeerssimulateatransaction,they recordwhichkeyswerereadandtheirversions,andwhich keysareupdated.Atcommittime,ifthekeyversionsdiffer fromthoseobservedduringsimulation(duetoconcurrent updates), the transaction is marked invalid. This ensures serializabilitybutconstrainshowwecanimplementmultistepupdates.

Intheathletesystem,weminimizeconflictsby:

 Avoidingmultiplewritestothesamekeywithina singleblock(byusingcompositekeysfordistinct dailyrecords).

 Structuring data such that high-contention fields (e.g.,cumulativestatistics)areeithercomputedoffchain or updated with separate transactions at lowerfrequency.

Thisdesigncontrastswithnaiveapproachesthatmight repeatedlyupdateasingle“total”keyoneveryevent,causing frequentversionconflictsandthroughputdegradation.

3.5Off-Chain Storage: Integrity,Confidentiality,and Efficiency

Foreachdocument,wecomputeaSHA-256hash:

 Thehashspaceis2²⁵⁶;understandardassumptions, the probability of collision between two random documentsisnegligible,andeventargetedcollision attacks require computational effort far beyond currentcapabilities.

 Inpractice,thisallowsthehashtoserveasaunique fingerprintforeachrecord.

The hash and minimal meta-data are written on-chain, whiletheJSONisstoredinCouchDBunderakeythatincludes thehash.Thisyieldsthreebenefits:

 Integrity:Anymodificationtotheoff-chaindocument willchangeitshash;mismatchbetweenstoredhash andrecomputedhashrevealstampering.

 Storage efficiency: On-chain data size per record is essentially constant (32 bytes plus headers), independent of the actual record size, drastically reducingblockchainstoragegrowth.

 Controlled mutability: Under regulatory or operational requirements, certain data can be logically“deleted”byremovingorencryptingtheoffchain record, while the on-chain hash continues to provethatarecordexistedatagiventime,preserving audittrails.

We secure off-chain documents using AES-256 encryption.AES-256iswidelyused,hasnopracticalknown attacks,andofferssufficientmarginevenagainstanticipated quantum advances when combined with appropriate key managementpractices.Symmetrickeysaresharedbetween organizations via secure channels and can be rotated periodically.

Alternativeoff-chainapproachescouldusedistributedfile systems (e.g., IPFS) or cloud object stores. We choose CouchDB for two reasons: (1) it is natively integrated as Fabric’s world state backend, reducing integration complexity,and(2)itsdocument-orientedmodelmatchesthe JSONrepresentationofathleterecords,enablingrichqueries over off-chain data without breaking the consistency link withtheblockchain.

3.6 Raft Ordering: From Theory to Practice

We adopt CouchDB as the off-chain repository for full records.EachrecordisaJSONdocumentincludingathleteID, timestamps,content(e.g.,trainingdescription,physiological metrics),andmetadatasuchastheresponsiblestaffmember. OurchoiceofRaftastheorderingmechanismisguidedby boththeoreticalandpracticalconsiderations.Theoretically, Raftoffers:

 Aformallyspecifiedandprovencrash-fault-tolerant consensus algorithm with leader election, log replication, and safety guarantees (Ongaro & Ousterhout,2014).

 Linearizablelogreplicationunderpartialsynchrony assumptions, which align with typical datacenter networksinpublicinstitutions.

Practically,compared withFabric’s earlier Kafka-based approach:

 RaftisintegratedintoFabric,eliminatingtheneedto manageexternalKafkaandZooKeeperclusters.This reducesoperationalattacksurfaceandconfiguration complexity.

 Snapshotcapabilitiesallowtruncatingoldlogentries once they are reflected in the ledger, preventing unboundedgrowthoftheorderer’sstorage.

ComparedwithhypotheticalBFTorderingservices,Raft:

International Research Journal of Engineering and Technology (IRJET) e-ISSN: 2395-0056

Volume: 12 Issue: 11 | Nov 2025 www.irjet.net p-ISSN: 2395-0072

 Achieveshigherthroughputformoderatenetwork sizesbyavoidingthequadraticmessageoverheadof manyBFTprotocols.

 Matches the threat model: ordering nodes are operated by national institutions with strong administrative controls; crashes and connectivity issuesarerealistic,whereascoordinatedByzantine attacksonamajorityoforderersarelessso.

Our experiments with a single-orderer configuration alreadyachieveseveralhundredTPS;extendingtothreeor fiveorderersinaRaftclusterisexpectedtopreservesimilar throughput while improvingfault tolerance, aslongas the quorumsizeremainsmodest.

4. IMPLEMENTATION AND EXPERIMENTAL METHODOLOGY

The prototype of the national athlete information management system was implemented on a blockchain network derived from the standard First-Network configuration in Hyperledger Fabric 2.0. Building on this baseline,thearchitecturewasextendedwithcomponentsfor performance, security, and domain-specific functionality, yieldingafullyoperationalblockchainmodelforathletedata management.Thenetworkdeploysmultiplepeerswithinthe standard Fabric architecture, uses Raft as the ordering service, and distributes smart contracts (chaincode) that encodeandautomatethecorebusinesslogic.

The client application was developed in JavaScript and interactswiththeFabricnetworktosubmittransactionsand querydata.Becausetheprimaryobjectivewastoevaluate feasibility and performance rather than to deliver a productionuserinterface,resultsarepresentedinaconsolebased environment instead of a graphical dashboard. This implementationdemonstratestheoperationalviabilityofthe proposedblockchain-drivenathletemanagementframework andprovidesafoundationforfutureinterfacerefinementand optimization.

Development and testing used widely adopted opensourcetools.Gitsupportedversioncontrol,whilecURLwas used for REST API interaction and network testing. The blockchain infrastructure was containerized with Docker (version17.06.2-ceorhigher)andDockerComposetoensure reproducibledeployment.Applicationlogicandinteraction moduleswereimplementedwithNode.js10.15.3andNPM 6.14.6,andsmartcontractswerewritteninGoandJavaScript, reflectingHyperledgerFabric’sdual-languagesupport.

4.1

Prototype Setup

The implementation leveraged the Fabric-samples packageandDocker-baseddeploymenttoensuremodular, reproducibleconfigurationacrossdevelopmentandtesting. macOSCatalina10.15.5servedastheprimarydevelopment environment, and a virtual machine running Ubuntu LTS 18.04.4 hosted the peer nodes for distributed testing. The networkwasinitializedwiththeofficialHyperledgerFabric 2.0 binaries and executed in Docker containers under the

First-Network topology. The hardware environment consistedofanIntelCorei5CPU(1.6GHz),8GBRAM,anda1 TBSSD/HDD,providingsufficientresourcestoemulatemultinodeexecutionandmeasurethroughputandlatencyonmidrangeinstitutionalhardware.

The prototype configuration comprised three organizations the national sport governing body, sport associations,andthesportsmedicineinstitute connected through a single channel and hosting a total of five peer nodes. A Raft-based orderer provided crash-fault-tolerant transaction sequencing, and CouchDB served as the state database, supporting off-chain document storage and rich queries. The deployed chaincode implemented six transaction types corresponding to athlete information management processes: personal, training, performance, health, medical, and data-sharing records. Together, these elements form a controlled, reproducible blockchain environment representative of a national athlete managementsystem.

4.2 Workloads and Metrics

We use Hyperledger Caliper 1.0 as the benchmarking tool. Caliper sends transactions to the Fabric network via clientSDKsandrecordsthroughputandlatency.

Threeworkloadcategoriesaredefined:



Read-only: transactions that query existing athlete records(simulatingdashboardsandreports).

 Write-only: transactions that create new records (simulatingdailydataentry).

 Mixed: workloads combining reads and writes, approximatingmorerealisticusage.

Transaction payload sizes are set to 8, 16, 32, 64, 128, 256,518KB,and1MBtoexplorehowpayloadsizeaffects throughputandlatency.

Foreachconfiguration,weperformtworunsandreport averagethroughput(TPS),averagelatency,andmaximum latency.

5. RESULTS AND SCIENTIFIC DISCUSSION

This section evaluates the proposed Fabric-based architecture from both performance and security perspectives. Using Hyperledger Caliper on a modest, institution-grade testbed, we analyze resource utilization andcharacterizethroughput–latencybehaviorunderreadandwrite-intensiveworkloadswithvaryingpayloadsizes

International Research Journal of Engineering and Technology (IRJET) e-ISSN: 2395-0056

Volume: 12 Issue: 11 | Nov 2025 www.irjet.net p-ISSN: 2395-0072

5.1 Workload and performance

Table 5-1: ResourceutilizationofDockercontainersand clientprocessduringtheperformanceevaluation, includingmaximumandaveragememoryusage,CPU usage,andnetwork/diskI/O

5.2 Throughput and Latency Behavior

Theexperimentsshowaclearpattern:

Table 5-2: Throughput and latency of read transactions versuspayloadsizeusingCouchDB

AsshowninTable5-2,read-onlyperformanceremained high across all payload sizes when using CouchDB as the statedatabase.With8KBtransactions,thesystemachieved apeakthroughputof1693.02TPS,withanaveragelatencyof 0.56sandamaximumlatencyof1.34s.Asthetransaction sizeincreased,throughputdecreasedandlatencyincreased, followingthe expectedtrendforlargerpayloads.Even for verylargereadpayloads(518KBand1MB),thenetwork still sustained 266.41TPS and 164.06 TPS, with average latencies of 2.25 s and 3.25 s, respectively. Overall, these results show that the prototype can support high read throughputwithmodestlatencyacrossawiderangeofdata sizes, indicating that the architecture is suitable for largescale query workloads in a national athlete management system.

Table 5-3: ThroughputandLatencyofWriteTransactions AcrossPayloadSizesUsingCouchDB

Table 5-3 reports the performance of write-only transactions using CouchDB as the state database across differentpayloadsizes.With8KBtransactions,thesystem achieves1009.55TPS,withanaveragelatencyof0.56sand amaximumlatencyof1.34s.Asthepayloadsizeincreases, throughput gradually declines and latency increases, followingtheexpectedpatternforlargerwriteoperations. Forlargerpayloads,performancedropsto112.87TPSat1 MB, with corresponding increases in both average and maximum latency. Overall, the results indicate that the prototype can sustain relatively high write throughput at small to medium payload sizes, while still providing acceptableperformanceforlargerathleterecordupdates.

Scientifically,theseresultscanbeinterpretedasfollows:

 Read-only transactions are limited primarily by peer-level query processing and network transmission; they do not incur the full endorsement–ordering–validation–commitpipeline for state updates. Hence read throughput is significantlyhigher.

 Writethroughputisboundedbythecombinedcost of chaincode execution, endorsement, ordering, validation,andledgercommit.Therelativeflatness ofwriteTPSforpayloadsbetween16and256KB suggeststhatcryptographicandI/Ocostsdominate more than pure payload size up to a certain threshold,beyondwhichlargerpayloadsincrease serializationandtransmissiontimenoticeably(518 KBand1MBcases).

Fromanapplicationstandpoint,thesenumbersindicate that the system can process a worst-case burst of several thousandathlete-relatedtransactionswithintensofseconds, which is acceptable for daily training and reporting workflows.

5.3 Comparison with Reported Fabric Benchmarks

TheabsoluteTPSachievedhereislowerthanthebestreported Fabric benchmarks (2,500 TPS and beyond) in highlyoptimizedenvironments.However,ourenvironment is intentionally modest and realistic for institutional deployments.WealsouseCouchDB,whichoffersrichquery

International Research Journal of Engineering and Technology (IRJET) e-ISSN: 2395-0056

Volume: 12 Issue: 11 | Nov 2025 www.irjet.net p-ISSN: 2395-0072

capabilities at some performance cost compared with LevelDB.

The main scientific insight is not the raw TPS but the shape of the throughput–payload curve under a concrete, domain-specificchaincodedesignandoff-chainpattern.This providesempiricalevidencethatourarchitecturalchoices (Raft,off-chainJSON,role-basedchaincode)donotintroduce unexpected bottlenecks beyond those inherent in Fabric’s design

5.4 Security Properties

From a scientific security perspective, the architecture achieves:

 Integrity:Anytransactioncommittedtotheledger is immutable under realistic computational assumptions; modifying a block would require recomputing hashes for that block and all successorsonamajorityofpeers,whichbecomes infeasibleonceblocksaccumulate.Additionally,offchain records are bound to their on-chain hashes viaSHA-256.

 Confidentiality: AES-256 encryption keying off symmetric keys shared between organizations protects off-chain records. TLS and potentially doubleTLSprotectdataintransit.

 Authenticationandauthorization:MSP-basedX.509 certificates and chaincode-level access checks enforce role-based access. Unauthorized entities cannotjointhenetworkwithoutbeingrecognized by the MSP configuration, and role escalation is preventedbycertificateattributevalidation.

 Auditability and non-repudiation: Every data creation and sharing event is logged as a transaction, including the identity (certificate), timestamp,andaffectedathletes.Thistracecanbe usedforinternalauditingandexternaloversight.

Compared with previous blockchain-based systems in healthcare,ourcontributionliesintheexplicitmodelingof athlete-centricworkflows,thecombinationofRaftandoffchain encryption tailored to high-frequency training data, andtheempiricalgroundinginperformancebenchmarksfor thisspecificdomain.

5.5 Limitations and Design Trade-Offs

Ascientificallyhonestassessmentmusthighlighttradeoffs:

 Byrelyingoncrash-fault-tolerantconsensusrather than BFT, we accept that compromised orderer quorums could, in principle, mis-order or censor transactions. For the assumed governancesetting (publicinstitutionsundernationaloversight),this risk is acceptable; for more adversarial

environments, hybrid or BFT consensus might be required.

 Off-chainstorageintroducesanextradependency (CouchDB)andpotentialfailuremode;ifoff-chain data are lost while on-chain hashes remain, integritycheckswillfailbuttheunderlyingrecord cannotberecovered.Thisisagenerallimitationof off-chainschemesandmustbeaddressedviarobust backupstrategies.

 The single-channel design simplifies initial deploymentbutmayexposemoremeta-datathan necessary (e.g., some organizations seeing that a transaction occurred, though not its content). Future work can use private data collections or multiplechannelsforstricterseparation.

6. CONCLUSION AND FUTURE DIRECTIONS

Thispaperhaspresentedascientificallygroundeddesign andevaluationofapermissionedblockchainarchitecturefor nationallevelathleteinformationmanagement.Bymodeling thegovernmentsportbody,sportassociations,andsports medicine institute as Fabric organizations, implementing Raft-basedordering,andusingoff-chainencryptedstorage, weaddresscentralization,transparency,andsharingissues inherentincurrentsystems.

Themainscientificcontributionsare:

 Adomain-specifictransactionanddatamodelthat capturesthefullathleteinformationlifecycle.

 A design rationale for using Raft, MSP-based identity, and off-chain storage that balances performance,security,andoperationalcomplexity.

 Empirical performance data across different payload sizes and workload types, interpreted throughFabric’sinternalsemantics.

 A security argument that combines blockchain immutabilitywithmoderncryptographytoprotect sensitiveathletedata.

Futureresearchwillproceedalongthreedirections:

 Extendedconsensusandtopologyexperiments.We plantodeploymulti-ordererRaftclusters,explore blocksizeandtimeouttuning,andevaluatemultichannelandprivatedataconfigurationsinlargerscalesimulations.

 Advancedprivacy-preservinganalytics.Integrating differential privacy, secure multi-party computation, or zero-knowledge proofs could enable external analytics providers to operate on athletedatawithoutlearningrawvalues.

 Integration with coaching and medical decision support. Building on the secure data layer, we intend to develop analytic dashboards and predictive models (e.g., injury risk, performance readiness) that exploit the longitudinal, tamper-

International Research Journal of Engineering and Technology (IRJET) e-ISSN: 2395-0056

Volume: 12 Issue: 11 | Nov 2025 www.irjet.net p-ISSN: 2395-0072

evidentdatasetwhilerespectingrole-basedaccess andregulatoryconstraints.

 To further increase throughput, the architecture couldbescaledandtunedbydeployingthenetwork onasmallclusterofdedicatedservers,simplifying chaincode to single-key operations, relaxing endorsementpoliciesforhigh-volumetransactions, and tuning Raft to use larger blocks and longer timeouts, as suggested by existing Fabric benchmarkstudies

In sum, the proposed architecture demonstrates that permissionedblockchains,whencarefullyengineeredwith appropriateconsensusandstoragemechanisms,canprovide ascientificallyrobustandpracticallyfeasiblefoundationfor modernathleteinformationmanagementatnationalscale.

REFERENCES

[1] Androulaki, E., Barger, A., Bortnikov, V., Cachin, C., Christidis, K., De Caro, A., Enyeart, D., Ferris, C., Laventman,G.,Manevich,Y.,Muralidharan,S.,Murthy, C.,Nguyen,B.,Sethi,M.,Singh,G.,Smith,K.,Sorniotti,A., Stathakopoulou, C., Vukolić, M., … Yellick, J. (2018). HyperledgerFabric:Adistributedoperatingsystemfor permissioned blockchains. Proceedings of the Thirteenth EuroSys Conference, 1–15. https://doi.org/10.1145/3190508.3190538

[2] Berkani, A. S., Abderrahim, A., & Lounis, A. (2024). Blockchain use cases in the sports industry: A systematicreview.InternationalJournalofNetworked and Distributed Computing, 12(1), 17–40. https://doi.org/10.1007/s44227-024-00022-3

[3] Casino, F., Dasaklis, T. K., & Patsakis, C. (2019). A systematic literature review of blockchain-based applications: Status, classification, and open issues. Telematics and Informatics, 36, 55–81. https://doi.org/10.1016/j.tele.2018.11.006

[4] Conti, M., Dehghantanha, A., Franke, K., & Watson, S. (2018). Internet of Things security and forensics: Challenges and opportunities. Future Generation ComputerSystems,78,544–546. https://doi.org/10.1016/j.future.2017.07.060

[5] Finck,M.(2019,July).BlockchainandtheGeneralData Protection Regulation: Can distributed ledgers be squaredwithEuropeandataprotectionlaw?ReportPE 634.445. European Parliamentary Research Service. https://www.europarl.europa.eu/RegData/etudes/STU D/2019/634445/EPRS_STU(2019)634445_EN.pdf

[6] Khan,M. M.,Khan,F. S.,Nadeem,M.,Khan,T. H.,Haider, S.,&Daas,D.(2025).Scalabilityandefficiencyanalysis of Hyperledger Fabric and private Ethereum in smart contract execution. Computers, 14(4), Article132.

https://doi.org/10.3390/computers14040132

[7] Ongaro, D., & Ousterhout, J. (2014). In search of an understandableconsensusalgorithm.InProceedingsof the2014USENIXAnnualTechnicalConference(USENIX ATC ’14) (pp. 305 319). USENIX Association. https://www.usenix.org/conference/atc14/technicalsessions/presentation/ongaro

[8] Thakkar, P., Nathan, S., & Vishwanathan, B. (2018). PerformancebenchmarkingandoptimizingHyperledger Fabric blockchain platform. arXiv Preprint arXiv:1805.11390.https://arxiv.org/abs/1805.11390