Fleets za magari yasiyo na dereva huzalisha data nyingi wakati wa mission, kama telemetry, route, map, perception summary, command na event log. Kuandika records hizi zote directly kwenye blockchain ledger kunatoa strong audit trail; lakini kunasababisha chain kukua rapidly, nodes kusynchronize data nyingi zaidi na lightweight vehicle computers kubanwa. Kuweka raw data yote off-chain kunaweza kufanya verification ya data ilitengenezwa na nani, kwa mission gani na chini ya conditions gani kuwa ngumu zaidi.

Study hii inapendekeza task-aware on-chain/off-chain storage method inayoitwa TAVOS. Raw au encrypted operational data inahifadhiwa kwenye IPFS, huku Hyperledger Fabric ledger ikiandikiwa only small but semantically rich index. Index hii inaunganisha record, task, vehicle na data-type identifiers pamoja na fields kama timestamp, IPFS content address, SHA-256 digest, data size, batch record identifier, signature na access policy.

Katika prototype iliyojengwa katika Docker environment, kwa total size ya bytes 55.869.440, synthetic operational records 1.000 zilitengenezwa. On-chain index size ya TAVOS ilipimwa kuwa 0,7504 MB. Kuhifadhi raw data hizohizo fully on-chain kulihitaji 53,2812 MB, huku RollStore representation iliyotumika katika real Fabric comparison ikihitaji 1,1357 MB. Kwa hivyo, TAVOS ilipunguza space upande wa chain au index kwa asilimia 98,59 dhidi ya full on-chain storage, na kwa asilimia 33,93 dhidi ya RollStore.

Katika tests ambapo records hamsini ziliandikwa kwa single Fabric transaction, average batch transaction time ya TAVOS ilikuwa milliseconds 2.443,10. Katika queries ambapo local cache na IPFS object zilikuwa ready, median query-verification time ilikuwa milliseconds 756,30; katika cold IPFS retrievals iliongezeka hadi milliseconds 6.360,30. Local SHA-256 computation ilibaki chini ya milliseconds 0,3; delay ilionekana kusababishwa mainly na Fabric queries na wakati mwingine IPFS retrieval.

Batch transaction size ilipoongezwa kutoka records 10 hadi 200, measured throughput iliongezeka kutoka records 4,18 kwa second hadi records 83,73 kwa second, huku average write latency per record ikishuka kutoka milliseconds 239,63 hadi milliseconds 11,95. Katika hash-mismatch experiments zilizochunguzwa, TAVOS na RollStore zilikataa all modified samples. Hata hivyo, results hizi zinategemea local Docker network, synthetic data na limited tampering scenarios; hakuna operation kwenye real vehicle fleet, wide-area network resilience au comprehensive cybersecurity validation iliyofanywa.

Ni problem gani study inajaribu kutatua?

Unmanned vehicles zinazofanya mission pamoja hazizalishi data ya aina moja na fixed size. State telemetry na control commands ni ndogo lakini hutokea very frequently, huku route files, local maps na perception data zikiwa larger. Mission logs ni muhimu hasa kwa replay ya events baadaye, investigation ya errors na determination ya responsibility.

Ili data hizi zihifadhiwe reliably, requirements tatu zinapaswa kutimizwa simultaneously:

• Kuweza kupata record inahusiana na vehicle gani, task gani, data type gani na time interval gani.
• Kuweza verify kwamba data iliyoretrieviwa off-chain ni exactly same na content iliyokuwa previously approved.
• Lightweight vehicle na edge nodes zisilazimike kudownload entire blockchain ledger na all raw data.

Full on-chain storage inaweza kutoa strong foundation kwa first two requirements; lakini replication ya large raw data kwa kila blockchain peer ina-limit scalability. Storage only kwenye IPFS inapunguza chain data, lakini applications zinahitaji extra databases ikiwa trustworthy index inayounganisha content address na task context, vehicle identity, access policy na transaction history haijajengwa.

TAVOS inalenga kuweka task-oriented balance kati ya approaches hizi mbili za extremes. Raw data inabaki off-chain huku information inayohitajika kwa task na verification ikihifadhiwa kwenye blockchain.

TAVOS ina maana gani?

TAVOS inawakilisha approach ya Kiingereza “Task-Aware Verifiable On/Off-Chain Storage”. Kwa Kiswahili, jina hili linaweza kuelezeka kama storage ya on-chain/off-chain inayofahamu task na inayoweza kuthibitishwa.

Distinctive aspect ya method si kupeleka raw data kwenye IPFS pekee. Hybrid systems nyingi zinazofanana pia huhifadhi content address na hash value kwenye blockchain. TAVOS inaongeza operational context kwenye cryptographic markers hizi. Hivyo, index haisemi tu “file hii ilirekodiwa hapo awali”, bali pia “data hii ilitengenezwa na vehicle hii, katika task hii, wakati huu na chini ya access conditions hizi.”

System ina layers zipi?

Architecture inayoonyeshwa katika Kielelezo 1 ina four main layers:

Separation hii inaruhusu raw-data management, trusted metadata management na application queries kuendelezwa independently. Link kati yao inalindwa na CID na DataHash fields.

Ni steps zipi zinatumika wakati record inaandikwa?

1. Vehicle au edge node inaserialize record identifier, task identifier, data type, vehicle identifier, timestamp na data content.
2. Ikiwa sensitive data ipo, content inaweza ku-encryptiwa kabla ya kutumwa kwenye IPFS.
3. SHA-256 digest ya serialized content inakokotolewa.
4. Raw au encrypted content inaandikwa kwenye IPFS na CID, yaani content address, inapokelewa.
5. CID, hash na task-related metadata zinaunganishwa katika single index record.
6. Producing node inasign index record.
7. Index inatumwa kwenye Fabric chaincode; peers zinaendorse transaction na ordering service inaiongeza kwenye ledger.

Raw operational data haiwekwi kwenye Fabric. Fabric huhifadhi only digest inayohitajika kwa verification na task queries.

Ni fields zipi ziko kwenye on-chain index?

Fields hizi zinaeleza kwa nini TAVOS ni kubwa kuliko smaller generic CID–hash index kama IPFS-BC. Badala ya pure space minimization, TAVOS inahifadhi additional metadata kwa task querying, provenance tracking na access control.

Lightweight client inafanyaje kazi bila kudownload entire ledger?

Workflow katika Kielelezo 2 ina two stages. Katika first stage, lightweight client huleta only block summaries, transaction-validity states na index records zinazohusiana na own task scope kwenda local cache. Raw data na entire blockchain ledger hazidownloadiwi.

Katika second stage, client inaquery local index kwa TaskID, DataType, VehicleID au time range. Kama record haiko cache, Fabric inaulizwa na index inaupdate. Ikiwa access policy inaruhusu, IPFS object inaretrieviwa kwa kutumia CID. Client inarecalculate SHA-256 digest ya content na kuicompare na DataHash katika Fabric.

• Hash values zikimatch, content inapewa application.
• Hash values zikitofautiana, record inakataliwa na event inaweza kuflagiwa kwa audit.
• Access policy ikikataa user, IPFS content haitumiki.

Structure hii inalenga kutoa common trusted entry point kwa applications tofauti kama mission replay, state query, anomaly investigation na record audit.

Storage cost imemodeliwa vipi?

Katika full on-chain storage, chain cost ya records N ni total size ya raw data:

\[ S_{\mathrm{full}}(N)=\sum_{i=1}^{N}|\mathrm{Raw}_i| \]

Kwa hybrid method m, chain-side cost ni sum ya record indexes pamoja na, ikiwa zipo, batch-verification au proof-metadata fields:

\[ S_m(N)=\sum_{i=1}^{N}|I_i^m|+\sum_{b=1}^{B}A_b^m \]

Chain-space reduction ratio dhidi ya full on-chain storage ya raw data ni:

\[ \eta_m=1-\frac{S_m(N)}{S_{\mathrm{full}}(N)} \]

Ratio hii inacompare only data upande wa blockchain au index. Kwa kuwa raw content inaendelea kubaki kwenye IPFS, η_m haipaswi kutafsiriwa kama reduction ya physical disk usage ya entire storage infrastructure.

Lightweight synchronization cost imeelezwaje?

Synchronization traffic ya lightweight clients K inategemea data ratio inayohifadhiwa na kila client ndani ya own task scope:

\[ C_m(K)=\sum_{k=1}^{K}\rho_{m,k}\left[S_m(N)+V_m+P_m\right],\quad 0<\rho_{m,k}\leq1 \]

Hapa ρ_m,k inaonyesha task-scope ratio inayosynchronizwa na relevant client, V_m transaction-validity information, na P_m verification proofs ikiwa zipo. Lengo la TAVOS ni kupunguza ρ, yaani kusynchronize only relevant task records badala ya kutuma indexes zote kwa every client.

Query na verification latency ina components zipi?

Total query latency ya record moja imemodeliwa kwa components zifuatazo:

\[ T_i=T_{\mathrm{lookup}}+T_{\mathrm{policy}}+T_{\mathrm{fetch}}(\mathrm{CID}_i)+T_{\mathrm{hash}}(|\mathrm{Raw}_i|) \]

• T_lookup: Fabric au local-index query time.
• T_policy: Access-policy checking time.
• T_fetch: IPFS content retrieval time.
• T_hash: Local SHA-256 digest computation time.

Experiments zinaonyesha kwamba local hash computation ina very small share ya total delay; Fabric calls na cold IPFS access ndizo more determining.

Integrity decision inafanywaje?

Content inakubaliwa only ikiwa access policy inaruhusu na calculated hash inamatch value iliyoko kwenye chain:

\[ \mathrm{Verify}_i(u)= \begin{cases} 1, & \mathrm{AccessPolicy}_i(u)=\mathrm{true}\ \land\ H(\mathrm{Raw}_i)=\mathrm{DataHash}_i \\ 0, & \mathrm{diğer\ durumlarda} \end{cases} \]

Study inachukulia SHA-256 kama ideal collision-resistant digest function na inaeleza probability kwamba modified content itoe same recorded digest kwa upper bound ya takribani 2⁻²⁵⁶. Theoretical value hii haijumuishi attack types nyingine kama software bug, key theft, abuse ya authorized user, IPFS unavailability au compromise ya Fabric nodes.

Ni methods zipi zilinganishwa?

Kwa sababu ya boundary hii, latency values za methods zote hazikulinganishwa directly. Real Fabric latency measurements ziliwasilishwa only kwa TAVOS na RollStore representation iliyojengwa katika study.

Experimental platform iliundwaje?

Hyperledger Fabric peers, ordering service, certificate authorities, chaincode na IPFS node ziliendeshwa katika local environment kwa Docker containers. Console screenshots zinaonyesha organization peers mbili, ordering node moja, organization na ordering certificate authorities, chaincode container na single IPFS node zikiwa active.

Total ya synthetic operational records 1.000 ilitengenezwa. Dataset ina classes zifuatazo:

• State telemetry
• Route na trajectory records
• Mission logs
• Grid maps
• Perception summaries
• Control commands

Total raw-data size ni bytes 55.869.440, sawa na takribani 53,2812 MB kwa binary megabyte. Kila record iliandikwa kwenye IPFS, CID ikapatikana na corresponding index ikatumwa kwenye Fabric chaincode.

Chain-space comparison ilionyesha nini?

TAVOS ilipunguza chain space kwa asilimia 98,59 dhidi ya full on-chain approach:

\[ 1-\frac{0{,}7504}{53{,}2812}\approx0{,}9859 \]

Reduction dhidi ya RollStore ni asilimia 33,93:

\[ 1-\frac{0{,}7504}{1{,}1357}\approx0{,}3393 \]

Kinyume chake, IPFS-BC, DAA-HSO na hasa TimeChain zilizalisha indexes ndogo zaidi. Advantage ya TAVOS si kuwa na absolutely smallest amount ya metadata. Additional space inatumika kuhifadhi task, vehicle, data type, batch record, signature na access-policy information directly ndani ya index.

Fabric batch-write latency iko katika level gani?

Katika batch transactions za records hamsini, average chaincode invocation times zilikuwa hivi:

Average difference ya takribani milliseconds 25 ni ndogo na study haijatoa statistical-significance test kwa difference hiyo. Kwa kuwa methods zote mbili zinatumia same local Fabric network na similar chaincode path, main message ya results ni kwamba TAVOS inaweza kubeba additional task fields bila significant increase katika transaction latency; definitive performance superiority haijaonyeshwa.

Query, IPFS retrieval na hash costs ni zipi?

Katika cache-hit samples, Fabric index read na VerifyIndex call zilikuwa fixed costs mbili kubwa za takribani milliseconds 370 kila moja. Wakati IPFS object ilikuwa local au tayari kwenye cache, retrieval ilichukua takribani milliseconds 4. SHA-256 computation ilibaki chini ya milliseconds 0,3 hata kwa largest data fragments.

Result hii inaonyesha kwamba cryptographic hash computation si main bottleneck. Katika distributed deployment, Fabric endorsement path, network latency, ordering service na node ambayo IPFS object iko ndivyo vitakuwa more determining.

Batch transaction size ilibadilisha performance vipi?

Batch transaction time ilibaki roughly kati ya seconds 2,36–2,39, huku kuongeza number of records ndani ya transaction kukiruhusu fixed Fabric cost kusambazwa kwa records zaidi. Kwa matokeo hayo, calculated latency per record ilipungua na total throughput ikaongezeka.

Large batch transactions zina cost yao. Record inaweza kulazimika kusubiri group ijaze kabla ya ku-confirmiwa kwenye chain. Kwa security-sensitive urgent event, kusubiri group ya records 200 ijazwe kunaweza kutofaa. Katika real system, batch record count inapaswa kuchaguliwa dynamically kulingana na mission urgency, allowed confirmation time na network load.

Tampering experiment ilithibitisha nini?

Katika successful scenario, local hash value ya content iliyoretrieviwa kutoka IPFS ilimatch DataHash katika Fabric index na verification result ikawa PASS. Katika unsuccessful scenario, RecordID na CID ziliwekwa same huku hash value iliyotumika katika verification ikibadilishwa; Fabric VerifyIndex result ilikuwa false na local result ikarekodiwa kama VALIDATION=FAIL.

Study pia inaripoti kwamba all sampled single-byte-change tests zilikataliwa na TAVOS na RollStore na detection rate ya asilimia 100 ikapatikana.

Result hii ina-support claim hii limited: mradi trusted SHA-256 digest katika index haijabadilika, modified content inayozalisha different hash haitakubaliwa. Peke yake haithibitishi broader security outcomes zifuatazo:

• Kuzuia malicious Fabric administrator au enough number of peers kuingilia system.
• Kutambua private-key theft au forged authorized signature.
• Availability dhidi ya deletion au unavailability ya IPFS object.
• Kuzuia denial-of-service, traffic analysis au metadata leakage.
• Security ya bypassing access policies, key revocation au dynamic role changes.
• Kutambua kwamba perception na control data zilitengenezwa incorrectly at source from the beginning.

Je, scalability graphs ni real second experiment?

Kielelezo 12 na Kielelezo 13 si new experiment iliyofanywa kwa larger Fabric network au real records 20.000. Watafiti walitumia stratified resampling kutoka size distribution ya measured records 1.000 kukadiria possible storage growth hadi records 20.000. Error bars zinaonyesha asilimia 10–90 range katika repeated samples.

Lightweight-client graph pia inawasilisha estimated communication amount chini ya different task-scope cache ratios. TimeChain inazalisha least data transfer, lakini inabadilisha record-level task query kuwa coarser time anchors. TAVOS inabeba more metadata, lakini inahifadhi record-, task-, vehicle- na policy-level queries.

Main design trade-off ya study ni nini?

Results hazionyeshi kwamba single best storage method imepatikana. Kila approach inatoa different trade-off:

• Full on-chain storage: Direct audit ni strong, lakini data-replication cost ni very high.
• Minimal CID–hash index: Chain space ni small, lakini task context lazima ihifadhiwe katika external systems.
• Temporal batch anchoring: Metadata ni very small, lakini kupata individual record directly kunaweza kuwa harder.
• Placement optimization: Inaweza kusawazisha cost na availability, lakini yenyewe haidefine task semantics.
• TAVOS: Inatumia larger index kuliko minimal methods, lakini inaunganisha task query, vehicle identity, record provenance na access policy kwenye common trusted index.

Ni conclusions zipi study ina-support?

• Working local prototype iliweza kujengwa ambapo raw operational data inaandikwa kwenye IPFS na task-verification index kwenye Fabric.
• Kwa workload ya records 1.000, chain au index space ya TAVOS ni asilimia 98,59 smaller kuliko full on-chain storage.
• Task-aware index ya TAVOS ilitumia asilimia 33,93 less space kuliko RollStore representation katika study.
• Additional task-metadata fields hazikusababisha noticeable average write-latency penalty dhidi ya RollStore representation katika transactions za records 50.
• Fixed Fabric transaction cost iliweza kusambazwa per record kwa larger record groups.
• Local hash-computation cost ilikuwa very small part ya total query time.
• Cold IPFS retrieval iliongeza latency kwa several seconds dhidi ya cache-hit access.
• Sampled hash mismatches hazikukubaliwa.
• Kuweka task, vehicle na access metadata fields kwenye index kunaweza kupunguza need ya applications kwa external mapping tables.

Ni conclusions zipi study haithibitishi?

• Haijaonyeshwa kwamba TAVOS inatumia less space kuliko all blockchain–IPFS storage methods; mechanisms tatu zilizalisha smaller indexes.
• Value ya asilimia 98,59 si total disk, total network au total energy saving.
• Comparison systems zote hazikuwekwa kwa full na original platforms zao.
• Success haijaonyeshwa katika real unmanned vehicle fleet, mobile wireless network au field mission.
• Value ya records 83,73/s si universal capacity inayoweza kuhandle all high-frequency vehicle data.
• Haijaonyeshwa kwamba batch-transaction confirmation ya takribani seconds 2,4 inatosha kwa hard real-time control.
• Asilimia 100 tampering detection si overall cybersecurity accuracy.
• Signature generation, certificate revocation, dynamic access policy na encryption-key management hazijalinganishwa experimentally.
• Data availability chini ya IPFS replication policy, pinning loss au node failure haijapimwa.
• Multi-server, multi-region, network partition au malicious blockchain peers hazijatathminiwa.
• Energy consumption, cost per transaction na on-vehicle CPU/memory usage hazijaripotiwa.

Ina maana gani kwa mtazamo wa Uturuki?

Nchini Uturuki, si real-time control ya unmanned vehicles pekee iliyo muhimu; verification ya data zinazozalishwa during mission baadaye pia ni muhimu. Unmanned aerial vehicles zinazofanya kazi katika disaster area, agricultural robots, mining vehicles, autonomous carriers ndani ya ports na factories, au multi-vehicle mapping systems zinaweza kuzalisha different data fragments zinazohusiana na same mission.

TAVOS approach inaweza kutumika kuunda common audit trail bila kunakili all records hizi kwenye large blockchain ledger. Kwa mfano, mission log, route record na perception output zinaweza kuhifadhiwa kwenye IPFS au organization’s permissioned distributed storage; record identity, hash, task, vehicle na access policy zikihifadhiwa kwenye permissioned blockchain.

Kwa local deployment, works zifuatazo zinahitaji kufanywa separately:

• Long-duration experiment kwa real vehicle telemetry, image au LiDAR payloads.
• Packet-loss testing chini ya mobile network, private 5G, satellite au intermittent-connectivity conditions.
• Running multiple physical Fabric peers katika different centers.
• Adaptive batch-record policy kulingana na mission urgency.
• Encryption, authorization na key revocation inayolingana na internal data classification ya organization.
• Definition ya IPFS pinning, backup, data life cycle na deletion obligations.
• Measurement ya energy, processor, memory na communication costs kwenye vehicle.
• Testing forged-data generation, compromised vehicle key na malicious authorized-node scenarios.

Mbinu na Matokeo ya Utafiti

Muhtasari wa research design

Distinction kati ya real measurements na calculated results

Main quantitative results

1. TAVOS chain index ilipimwa kuwa 0,7504 MB.
2. Full on-chain storage ilihitaji 53,2812 MB.
3. RollStore representation ilizalisha index ya 1,1357 MB.
4. TAVOS ilipunguza chain space kwa asilimia 98,59 dhidi ya full on-chain approach.
5. TAVOS ilizalisha index ndogo kwa asilimia 33,93 kuliko RollStore representation.
6. IPFS-BC, TimeChain na DAA-HSO zilikuwa na smaller metadata space, lakini zilihifadhi less task semantics.
7. Average Fabric write time ya TAVOS kwa records 50 ilikuwa 2.443,10 ms.
8. Corresponding average ya RollStore ilikuwa 2.468,24 ms.
9. TAVOS ilionyesha median latency ya 756,30 ms katika cache-hit queries.
10. TAVOS iliongezeka hadi median latency ya 6.360,30 ms katika cold IPFS access.
11. Local SHA-256 computation ilibaki chini ya 0,3 ms.
12. Batch record count ilipoongezwa kutoka 10 hadi 200, throughput iliongezeka kutoka 4,18 hadi 83,73 records/s.
13. Katika same change, latency per record ilishuka kutoka 239,63 hadi 11,95 ms.
14. All examined single-byte-change au hash-mismatch samples zilikataliwa.

Information inayotolewa na figures

• Kielelezo 1: Kinaonyesha data flow kati ya vehicle, edge node, mission control, IPFS, Fabric na lightweight-client layers.
• Kielelezo 2: Kinaonyesha two-stage lightweight-client flow yenye local index cache, Fabric query, IPFS retrieval na hash comparison.
• Kielelezo 3: Kinawasilisha Docker console inayoonyesha Fabric peers, ordering service, certificate authorities, chaincode na IPFS containers zikiwa running.
• Kielelezo 4: Kinaonyesha console output ya chaincode deployment, batch transaction ya records 1.000 na experiment summaries.
• Kielelezo 5: Kinalinganisha chain au index space ya methods sita kwa logarithmic scale.
• Kielelezo 6: Kinaonyesha real Fabric transaction latencies za records 50 kwa TAVOS na RollStore pamoja na distribution na outliers.
• Kielelezo 7: Kinatenganisha cache-hit na cold IPFS queries; kinagawanya Fabric, IPFS na hash costs kuwa components.
• Kielelezo 8: Kinaonyesha throughput kuongezeka na latency per record kupungua kadiri batch record count inavyoongezeka.
• Kielelezo 9: Kinawasilisha successful index write, VerifyIndex na IPFS retrieval output.
• Kielelezo 10: Kinaonyesha chaincode ikikataa record wakati incorrect hash imetumwa.
• Kielelezo 11: Kinalinganisha asilimia 100 rejection rate ya methods mbili katika sampled tampering tests na approximate verification costs.
• Kielelezo 12: Kinaonyesha chain-space projection hadi records 20.000 kutoka resampling ya measured record distribution.
• Kielelezo 13: Kinaonyesha estimated synchronization traffic ya lightweight clients wenye different task-scope cache ratios.

Methodological strengths

• Proposed system haikuachwa kama pseudocode pekee; iliendeshwa kwenye Fabric na IPFS.
• Raw-data size na record count zimeripotiwa clearly.
• Boundary kati ya real measurement na mechanism-level reproduction imeelezwa openly.
• Normal cache accesses na cold IPFS accesses zimeripotiwa separately.
• Latency imegawanywa kuwa Fabric, IPFS na hash components badala ya single total number.
• Outlier Fabric transaction times hazikuondolewa kwenye graphs.
• Sensitivity analysis imefanywa kwa batch transaction size.
• Trade-off kati ya space minimization na task semantics imejadiliwa openly.
• Tampering result imeonyeshwa kwa console evidence.
• Scalability projections zimeelezwa wazi kwamba si second real deployment.

Methodological limitations

• Data workload haikutoka kwenye real vehicles; ilitengenezwa synthetically kwa operational types.
• Real-platform experiment ilifanywa na records 1.000 pekee.
• Fabric na IPFS ziliendeshwa kwenye same local Docker environment.
• CPU model, disk type, Docker version, Fabric version, IPFS version na detailed network configuration hazijaripotiwa sufficiently.
• Multiple physical IPFS nodes au access kutoka remote IPFS peer hazikutestwa.
• Hakuna real mobile-network latency, packet loss au connection interruption.
• Hakuna load test iliyofanywa na multiple simultaneous vehicles au query clients.
• IPFS-BC, TimeChain na DAA-HSO hazikurebuildiwa fully kwa original platforms zao.
• RollStore comparison haijaonyeshwa kama full reproduction inayojumuisha all protocol na proof behaviors za original system.
• Hakuna statistical significance au confidence-interval analysis iliyotolewa kwa write na query differences.
• Asilimia 100 tampering result inategemea limited na deterministic hash-mismatch test.
• Computational cost ya signature verification haijaripotiwa separately.
• Hakuna access-policy violation, role-change au authorization-revocation experiments.
• Encryption algorithm na key-management method hazijaelezwa kwa implemented experiment.
• IPFS availability, pinning na data-replication failures hazijachunguzwa.
• Blockchain-node compromise, collusion au malicious-administrator threat haijamodeliwa.
• Energy consumption na on-vehicle resource usage hazijapimwa.
• Experiment code, raw CSV files au reproducible open-repository link haijatolewa.

Maelezo ya Chanzo na Mbinu

Jina kamili la asili la study: Task-Aware Verifiable On/Off-Chain Information Integration for High-Frequency Operational Data in Collaborative Unmanned Vehicle Networks

Waandishi: Rui Zhang; Guangtian Xu; Shuxin Hu; Shilei Li; Meijie Jin; Miaoxin Ge; Qingquan Liu.

Author order: List hapo juu inahifadhi original author order ya study.

Equal first author: Hakuna equal-first-authorship au equal-contribution statement.

Corresponding author: Qingquan Liu.

Corresponding-author e-mail: lqqneu@163.com

Institution iliyotajwa katika study: Shenyang University of Technology, Shenyang 110159, China.

Institution katika SSRN metadata record: Shenyang Ligong University. Information hii haipatani na institution kwenye first page ya study. Institutions hizi mbili ni organizations tofauti na correct institution haikuweza kuamuliwa kwa uhakika kutoka available official records.

DOI:10.2139/ssrn.6986768

Publication platform: SSRN.

Publication year: 2026.

Journal: Peer-reviewed journal au final journal publication haijathibitishwa.

Original publisher: Final journal publisher haijaelezwa. Study imeshirikiwa kwenye SSRN kama preprint.

Source type: Preprint research article yenye working prototype kwenye Hyperledger Fabric na IPFS, experimental software measurements na mechanism-level comparisons.

Peer-review status: Study haijapitia peer review. Pages zina warning “This preprint research paper has not been peer reviewed”.

Official source link:https://ssrn.com/abstract=6986768

Author contributions: Kulingana na acknowledgment na contribution statement, Rui Zhang aliandika paper na kufanya experimental simulation. Guangtian Xu na Shuxin Hu walichangia literature review; Shilei Li na Meijie Jin format checking na corrections; Miaoxin Ge submission process. Qingquan Liu aliamua direction na main structure ya study. Formal CRediT contribution table haijatolewa.

Funding: Hakuna funding organization au project number iliyotajwa katika study.

Conflict of interest: Hakuna explicit conflict-of-interest statement.

Data na code access: Inasemwa kwamba console na CSV outputs zilitumika; lakini experiment code, raw records au reproducible open-data repository link haijatolewa.

Maelezo haya ya kisayansi ya Kituruki yameandaliwa kwa kuchunguza study text, formulas, tables, architecture diagrams, performance graphs na console screenshots. Scientific content inategemea only system design, measurements na comparison boundaries zilizoelezwa na authors katika study. External sources zilitumika only kuthibitisha original title, author list, DOI, SSRN record na bibliographic identity.

Main contribution ya study ni kusogeza blockchain–IPFS hybrid storage beyond generic file archiving kwa kuihusisha na task, vehicle, data type na access policy. Main limitation ni kwamba real-platform results zime-limitwa kwa local Docker environment na synthetic records 1.000; sehemu muhimu ya other methods imecompareiwa katika mechanism level badala ya full deployment.

Storage reduction ya asilimia 98,59 inahusu upande wa chain au index. Bila kuhesabu raw data na possible replicas kwenye IPFS, haipaswi kudaiwa kwamba total physical storage ya system imepungua kwa same ratio. Vilevile, asilimia 100 tampering detection inamaanisha all examined hash-mismatch samples zilikataliwa; haipaswi kutafsiriwa kama overall attack-detection success au end-to-end system security.