İnsansız araç filoları görev sırasında telemetri, güzergâh, harita, algılama özeti, komut ve olay günlüğü gibi çok sayıda veri üretmektedir. Bu kayıtların tamamının doğrudan bir blockchain defterine yazılması güçlü bir denetim izi sağlar; ancak zincirin hızla büyümesine, düğümlerin daha fazla veri eşzamanlamasına ve hafif araç bilgisayarlarının zorlanmasına yol açar. Ham verilerin tamamen zincir dışında tutulması ise verinin kim tarafından, hangi görev için ve hangi koşullarda üretildiğinin doğrulanmasını güçleştirebilir.

Bu çalışma, TAVOS adı verilen görev farkındalıklı bir zincir içi/zincir dışı depolama yöntemi önermektedir. Ham veya şifrelenmiş operasyon verisi IPFS üzerinde saklanırken Hyperledger Fabric defterine yalnızca küçük fakat anlamsal olarak zengin bir indeks yazılmaktadır. Bu indeks; kayıt, görev, araç ve veri türü kimliklerinin yanı sıra zaman damgası, IPFS içerik adresi, SHA-256 özeti, veri büyüklüğü, toplu kayıt kimliği, imza ve erişim politikası gibi alanları birbirine bağlamaktadır.

Docker ortamında kurulan prototipte toplam 55.869.440 bayt büyüklüğünde 1.000 sentetik operasyon kaydı üretilmiştir. TAVOS’un zincir tarafındaki indeks büyüklüğü 0,7504 MB olarak ölçülmüştür. Aynı ham verilerin tamamen zincirde tutulması 53,2812 MB, gerçek Fabric karşılaştırmasında kullanılan RollStore temsili ise 1,1357 MB gerektirmiştir. Böylece TAVOS, zincir veya indeks tarafındaki alanı tam zincir içi depolamaya göre yüzde 98,59, RollStore’a göre yüzde 33,93 azaltmıştır.

Elli kaydın tek Fabric işlemiyle yazıldığı testlerde TAVOS’un ortalama toplu işlem süresi 2.443,10 milisaniye olmuştur. Yerel önbellek ve IPFS nesnesinin hazır olduğu sorgularda ortanca sorgulama-doğrulama süresi 756,30 milisaniye, soğuk IPFS geri okumalarında ise 6.360,30 milisaniyeye yükselmiştir. Yerel SHA-256 hesaplaması 0,3 milisaniyenin altında kalmış; gecikmenin esas olarak Fabric sorguları ve zaman zaman IPFS geri okumasından kaynaklandığı görülmüştür.

Toplu işlem büyüklüğü 10 kayıttan 200 kayda çıkarıldığında ölçülen kapasite saniyede 4,18 kayıttan 83,73 kayda yükselmiş, kayıt başına ortalama yazma gecikmesi 239,63 milisaniyeden 11,95 milisaniyeye düşmüştür. İncelenen hash uyuşmazlığı deneylerinde TAVOS ve RollStore bütün değiştirilmiş örnekleri reddetmiştir. Ancak bu sonuçlar yerel Docker ağına, sentetik verilere ve sınırlı kurcalama senaryolarına dayanmaktadır; gerçek araç filosunda çalışma, geniş alan ağı dayanıklılığı veya kapsamlı siber güvenlik doğrulaması yapılmamıştır.

Araştırmanın çözmeye çalıştığı problem nedir?

Birlikte görev yapan insansız araçlar, tek tip ve sabit büyüklükte veri üretmez. Durum telemetrisi ve kontrol komutları küçük fakat çok sık oluşurken güzergâh dosyaları, yerel haritalar ve algılama verileri daha büyük olabilir. Görev günlükleri ise olayların daha sonra yeniden canlandırılması, hataların araştırılması ve sorumluluğun belirlenmesi açısından özellikle önemlidir.

Bu verilerin güvenilir biçimde saklanması için üç gereksinimin aynı anda karşılanması gerekir:

• Bir kaydın hangi araç, görev, veri türü ve zaman aralığıyla ilişkili olduğunun bulunabilmesi.
• Zincir dışında getirilen verinin daha önce onaylanan içerikle birebir aynı olduğunun doğrulanabilmesi.
• Hafif araç ve uç düğümlerin bütün blockchain defterini ve bütün ham verileri indirmek zorunda kalmaması.

Tam zincir içi depolama ilk iki gereksinime güçlü bir temel sunabilir; ancak büyük ham verilerin her blockchain eşinde çoğaltılması ölçeklenebilirliği sınırlar. Yalnızca IPFS üzerinde depolama ise veriyi küçültür, fakat içerik adresini görev bağlamına, araç kimliğine, erişim politikasına ve işlem geçmişine bağlayan güvenilir bir indeks kurulmazsa uygulamalar ek veri tabanlarına ihtiyaç duyar.

TAVOS bu iki uç yaklaşım arasında görev odaklı bir denge kurmayı amaçlamaktadır. Ham veri zincir dışında tutulurken görev ve doğrulama için gerekli bilgiler blockchain üzerinde saklanmaktadır.

TAVOS ne anlama gelmektedir?

TAVOS, İngilizce “Task-Aware Verifiable On/Off-Chain Storage” yaklaşımını ifade etmektedir. Türkçede bu ad, görev farkındalıklı ve doğrulanabilir zincir içi/zincir dışı depolama olarak açıklanabilir.

Yöntemin ayırt edici yönü yalnızca ham veriyi IPFS’ye aktarması değildir. Benzer çok sayıda hibrit sistem de içerik adresini ve hash değerini blockchain üzerinde tutmaktadır. TAVOS, bu kriptografik işaretlere operasyon bağlamını eklemektedir. Böylece indeks yalnızca “bu dosya daha önce kaydedildi” bilgisini değil, “bu veri şu araç tarafından, şu görevde, şu zamanda ve şu erişim koşullarıyla üretildi” bilgisini de taşımaktadır.

Sistem hangi katmanlardan oluşmaktadır?

Şekil 1’de gösterilen mimari dört ana katman içermektedir:

Bu ayrım ham veri yönetiminin, güvenilir metadata yönetiminin ve uygulama sorgularının birbirinden bağımsız geliştirilebilmesine olanak vermektedir. Aralarındaki bağlantı CID ve DataHash alanlarıyla korunmaktadır.

Bir kayıt yazılırken hangi adımlar uygulanmaktadır?

1. Araç veya uç düğüm; kayıt kimliği, görev kimliği, veri türü, araç kimliği, zaman damgası ve veri içeriğini serileştirir.
2. Hassas veri bulunuyorsa içerik IPFS’ye gönderilmeden önce şifrelenebilir.
3. Serileştirilmiş içeriğin SHA-256 özeti hesaplanır.
4. Ham veya şifreli içerik IPFS’ye yazılır ve içerik adresi olan CID alınır.
5. CID, hash ve görevle ilgili metadata tek bir indeks kaydında birleştirilir.
6. Üreten düğüm indeks kaydını imzalar.
7. İndeks, Fabric zincir koduna gönderilir; eşler işlemi onaylar ve sıralama hizmeti işlemi deftere ekler.

Ham operasyon verisi Fabric üzerinde tutulmaz. Fabric yalnızca doğrulama ve görev sorguları için gerekli özeti saklar.

Zincir indeksinde hangi alanlar bulunmaktadır?

Bu alanlar TAVOS’un neden IPFS-BC gibi daha küçük bir genel CID–hash indeksinden büyük olduğunu açıklamaktadır. TAVOS saf alan minimizasyonu yerine görev sorgusu, köken takibi ve erişim kontrolü için ek metadata tutmaktadır.

Hafif istemci bütün defteri indirmeden nasıl çalışmaktadır?

Şekil 2’deki iş akışı iki aşamalıdır. İlk aşamada hafif istemci yalnızca kendi görev alanıyla ilişkili blok özetlerini, işlem geçerlilik durumlarını ve indeks kayıtlarını yerel önbelleğine alır. Ham veriler ve blockchain defterinin tamamı indirilmez.

İkinci aşamada istemci TaskID, DataType, VehicleID veya zaman aralığıyla yerel indeksi sorgular. Kayıt önbellekte yoksa Fabric’e başvurularak indeks güncellenir. Erişim politikası uygunsa CID kullanılarak IPFS nesnesi getirilir. İstemci içeriğin SHA-256 özetini yeniden hesaplar ve Fabric’teki DataHash ile karşılaştırır.

• Hash değerleri eşleşirse içerik uygulamaya verilir.
• Hash değerleri farklıysa kayıt reddedilir ve olay denetim için işaretlenebilir.
• Erişim politikası kullanıcıya yetki vermiyorsa IPFS içeriği kullanılmaz.

Bu yapı görev tekrar oynatma, durum sorgulama, anormallik araştırma ve kayıt denetimi gibi farklı uygulamalara ortak bir güvenilir giriş noktası sunmayı amaçlamaktadır.

Depolama maliyeti nasıl modellenmiştir?

Tam zincir içi depolamada N kaydın zincir maliyeti ham verilerin toplam büyüklüğüdür:

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

Hibrit bir m yöntemi için zincir tarafındaki maliyet, kayıt indeksleri ile varsa toplu doğrulama veya kanıt metadata alanlarının toplamıdır:

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

Ham verinin tam zincir içi depolanmasına göre zincir alanı azaltma oranı şöyledir:

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

Bu oran yalnızca blockchain veya indeks tarafındaki veriyi karşılaştırmaktadır. Ham içerik IPFS üzerinde kalmaya devam ettiği için η_m, bütün depolama altyapısının fiziksel disk kullanımındaki azalma olarak yorumlanmamalıdır.

Hafif eşzamanlama maliyeti nasıl ifade edilmiştir?

K hafif istemcinin eşzamanlama trafiği, her istemcinin görev alanında tuttuğu veri oranına bağlıdır:

\[ 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 \]

Burada ρ_m,k ilgili istemcinin eşzamanladığı görev alanı oranını, V_m işlem geçerliliği bilgilerini ve P_m varsa doğrulama kanıtlarını göstermektedir. TAVOS’un amacı ρ değerini küçültmek, yani her istemciye bütün indeksleri göndermek yerine yalnızca ilgili görev kayıtlarını eşzamanlamaktır.

Sorgulama ve doğrulama gecikmesi hangi bileşenlerden oluşmaktadır?

Bir kaydın toplam sorgulama gecikmesi şu bileşenlerle modellenmiştir:

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

• T_lookup: Fabric veya yerel indeks sorgulama süresi.
• T_policy: Erişim politikasının kontrol edilmesi.
• T_fetch: IPFS içeriğinin getirilmesi.
• T_hash: Yerel SHA-256 özetinin hesaplanması.

Deneyler, yerel hash hesabının toplam gecikmede çok küçük bir paya sahip olduğunu; Fabric çağrılarının ve soğuk IPFS erişiminin daha belirleyici olduğunu göstermiştir.

Bütünlük kararı nasıl verilmektedir?

İçerik yalnızca erişim politikası izin verdiğinde ve hesaplanan hash zincirdeki değerle eşleştiğinde kabul edilmektedir:

\[ \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} \]

Çalışma SHA-256’yı ideal çakışma dirençli özet fonksiyonu olarak ele almakta ve değiştirilmiş bir içeriğin aynı kayıtlı özeti üretme olasılığını yaklaşık 2⁻²⁵⁶ üst sınırıyla ifade etmektedir. Bu teorik değer, yazılım hatası, anahtar hırsızlığı, yetkili kullanıcının kötüye kullanımı, IPFS erişilemezliği veya Fabric düğümlerinin ele geçirilmesi gibi başka saldırı türlerini kapsamamaktadır.

Hangi yöntemlerle karşılaştırma yapılmıştır?

Bu sınır nedeniyle bütün yöntemlerin gecikme değerleri doğrudan karşılaştırılmamıştır. Gerçek Fabric gecikme ölçümleri yalnızca TAVOS ve çalışmada oluşturulan RollStore temsili için sunulmuştur.

Deney platformu nasıl kurulmuştur?

Hyperledger Fabric eşleri, sıralama hizmeti, sertifika otoriteleri, zincir kodu ve IPFS düğümü Docker konteynerleriyle yerel bir ortamda çalıştırılmıştır. Konsol görüntülerinde iki kuruluş eşinin, bir sıralama düğümünün, kuruluş ve sıralama sertifika otoritelerinin, zincir kodu konteynerinin ve tek IPFS düğümünün etkin olduğu görülmektedir.

Toplam 1.000 sentetik operasyon kaydı üretilmiştir. Veri kümesi şu sınıfları içermektedir:

• Durum telemetrisi
• Güzergâh ve yörünge kayıtları
• Görev günlükleri
• Izgara haritaları
• Algılama özetleri
• Kontrol komutları

Toplam ham veri büyüklüğü 55.869.440 bayt, ikili megabayt karşılığıyla yaklaşık 53,2812 MB’dir. Her kayıt IPFS’ye yazılmış, CID alınmış ve ilgili indeks Fabric zincir koduna gönderilmiştir.

Zincir alanı karşılaştırması ne göstermiştir?

TAVOS, tam zincir içi yaklaşıma göre zincir alanını yüzde 98,59 azaltmıştır:

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

RollStore’a göre azaltma yüzde 33,93’tür:

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

Buna karşılık IPFS-BC, DAA-HSO ve özellikle TimeChain daha küçük indeksler üretmiştir. TAVOS’un avantajı mutlak en küçük metadata miktarı değildir. Ek alan, görev, araç, veri türü, toplu kayıt, imza ve erişim politikası bilgilerini doğrudan indeks içinde korumak için kullanılmaktadır.

Fabric toplu yazma gecikmesi ne düzeydedir?

Elli kayıtlık toplu işlemlerde ortalama zincir kodu çağrı süreleri şöyledir:

Yaklaşık 25 milisaniyelik ortalama fark küçüktür ve çalışma fark için istatistiksel anlamlılık testi sunmamıştır. İki yöntem aynı yerel Fabric ağı ve benzer zincir kodu yolunu kullandığı için sonuçların temel mesajı TAVOS’un ek görev alanlarını önemli bir işlem gecikmesi artışı olmadan taşıyabilmesidir; kesin performans üstünlüğü gösterilmiş değildir.

Sorgulama, IPFS geri okuma ve hash maliyetleri nelerdir?

Önbellek isabetli örneklerde Fabric indeks okuması ve VerifyIndex çağrısı yaklaşık 370’er milisaniyelik iki büyük sabit maliyet oluşturmuştur. IPFS nesnesi yerel veya önbellekte hazır olduğunda geri okuma yaklaşık 4 milisaniye sürmüştür. SHA-256 hesaplaması en büyük veri parçalarında dahi 0,3 milisaniyenin altında kalmıştır.

Bu sonuç, kriptografik hash hesabının temel darboğaz olmadığını göstermektedir. Dağıtık bir kurulumda Fabric onay yolu, ağ gecikmesi, sıralama hizmeti ve IPFS nesnesinin hangi düğümde bulunduğu daha belirleyici olacaktır.

Toplu işlem büyüklüğü performansı nasıl değiştirmiştir?

Toplu işlem süresi yaklaşık 2,36–2,39 saniye arasında kalırken işlem içindeki kayıt sayısının artması sabit Fabric maliyetinin daha fazla kayıt arasında paylaştırılmasını sağlamıştır. Bunun sonucunda kayıt başına hesaplanan gecikme azalmış ve toplam kapasite yükselmiştir.

Büyük toplu işlemlerin bir bedeli vardır. Bir kaydın zincirde onaylanması için grubun dolmasının beklenmesi gerekebilir. Güvenlik açısından acil bir olayın 200 kayıtlık grubun tamamlanmasını beklemesi uygun olmayabilir. Gerçek sistemde toplu kayıt sayısının görev aciliyeti, izin verilen onay süresi ve ağ yüküne göre dinamik seçilmesi gerekir.

Kurcalama deneyi neyi doğrulamıştır?

Başarılı senaryoda IPFS’den geri getirilen içeriğin yerel hash değeri Fabric indeksindeki DataHash ile eşleşmiş ve doğrulama sonucu PASS olmuştur. Başarısız senaryoda RecordID ve CID aynı tutulurken doğrulamada kullanılan hash değeri değiştirilmiş; Fabric VerifyIndex sonucu false ve yerel sonuç VALIDATION=FAIL olarak kaydedilmiştir.

Çalışma ayrıca örneklenen tek bayt değişikliği testlerinin tamamının TAVOS ve RollStore tarafından reddedildiğini ve yüzde 100 tespit oranı elde edildiğini bildirmektedir.

Bu sonuç şu sınırlı iddiayı destekler: İndeksteki güvenilir SHA-256 özeti değişmeden kaldığı sürece farklı hash üreten değiştirilmiş bir içerik kabul edilmemektedir. Aşağıdaki daha geniş güvenlik sonuçlarını tek başına kanıtlamaz:

• Kötü niyetli bir Fabric yöneticisinin veya yeterli sayıda eşin sisteme müdahalesinin engellenmesi.
• Özel anahtar hırsızlığının veya sahte yetkili imzanın tespiti.
• IPFS nesnesinin silinmesi ya da ulaşılamaz hâle gelmesine karşı kullanılabilirlik.
• Hizmet engelleme, trafik analizi veya metadata sızıntısının önlenmesi.
• Erişim politikalarının aşılması, anahtar iptali veya dinamik rol değişikliklerinin güvenliği.
• Algılama ve kontrol verisinin kaynağında zaten yanlış üretilmesinin tespiti.

Ölçeklenebilirlik grafikleri gerçek ikinci bir deney midir?

Şekil 12 ve Şekil 13, daha büyük bir Fabric ağı veya 20.000 gerçek kayıtla yapılan yeni bir deney değildir. Araştırmacılar, ölçülen 1.000 kaydın büyüklük dağılımından tabakalı yeniden örnekleme yaparak 20.000 kayda kadar olası depolama büyümesini tahmin etmiştir. Hata çubukları tekrarlanan örneklemelerdeki yüzde 10–90 aralığını göstermektedir.

Hafif istemci grafiği de farklı görev alanı önbellek oranları altında hesaplanan tahmini iletişim miktarını sunmaktadır. TimeChain en az veri aktarımını üretmekte, fakat kayıt düzeyinde görev sorgusunu daha kaba zaman çapalarına dönüştürmektedir. TAVOS daha fazla metadata taşımakta, buna karşılık kayıt, görev, araç ve politika düzeyindeki sorguları korumaktadır.

Çalışmanın temel tasarım dengesi nedir?

Sonuçlar tek bir en iyi depolama yöntemi bulunduğunu göstermemektedir. Her yaklaşım farklı bir ödünleşim sunmaktadır:

• Tam zincir içi depolama: Doğrudan denetim güçlüdür, fakat veri çoğaltma maliyeti çok yüksektir.
• Minimal CID–hash indeksi: Zincir alanı küçüktür, fakat görev bağlamı harici sistemlerde tutulmalıdır.
• Zamansal toplu çapa: Metadata çok küçüktür, fakat tek kaydı doğrudan bulmak daha güç olabilir.
• Yerleşim optimizasyonu: Maliyet ve kullanılabilirliği dengeleyebilir, fakat tek başına görev semantiği tanımlamaz.
• TAVOS: Minimal yöntemlerden daha büyük indeks kullanır, ancak görev sorgusu, araç kimliği, kayıt kökeni ve erişim politikasını ortak bir güvenilir indeks üzerinde birleştirir.

Çalışmanın desteklediği sonuçlar nelerdir?

• Ham operasyon verisinin IPFS’ye, görev ve doğrulama indeksinin Fabric’e yazıldığı çalışan bir yerel prototip kurulabilmiştir.
• 1.000 kayıtlık yükte TAVOS’un zincir veya indeks alanı tam zincir içi depolamadan yüzde 98,59 daha küçüktür.
• TAVOS’un görev farkındalıklı indeksi, çalışmadaki RollStore temsilinden yüzde 33,93 daha az alan kullanmıştır.
• Ek görev metadata alanları, 50 kayıtlık işlemlerde RollStore temsiline göre belirgin bir ortalama yazma gecikmesi cezası oluşturmamıştır.
• Fabric’in sabit işlem maliyeti, daha büyük kayıt gruplarıyla kayıt başına paylaştırılabilmiştir.
• Yerel hash hesaplama maliyeti toplam sorgu süresinin çok küçük bir bölümünü oluşturmuştur.
• Soğuk IPFS geri okuması, önbellek isabetli erişime göre gecikmeyi birkaç saniye artırmıştır.
• Örneklenen hash uyuşmazlıkları kabul edilmemiştir.
• Görev, araç ve erişim metadata alanlarının indeks üzerinde tutulması uygulamaların harici eşleştirme tablolarına duyduğu ihtiyacı azaltabilir.

Çalışmanın kanıtlamadığı sonuçlar nelerdir?

• TAVOS’un bütün blockchain–IPFS depolama yöntemlerinden daha az alan kullandığı gösterilmemiştir; üç mekanizma daha küçük indeks üretmiştir.
• Yüzde 98,59 değeri toplam disk, toplam ağ veya toplam enerji tasarrufu değildir.
• Bütün karşılaştırma sistemleri tam ve özgün platformlarıyla kurulmamıştır.
• Gerçek insansız araç filosunda, hareketli kablosuz ağda veya saha görevinde başarı gösterilmemiştir.
• 83,73 kayıt/s değeri bütün yüksek frekanslı araç verilerini karşılayacak evrensel bir kapasite değildir.
• Yaklaşık 2,4 saniyelik toplu işlem onayının sert gerçek zamanlı kontrol için yeterli olduğu gösterilmemiştir.
• Yüzde 100 kurcalama tespiti genel siber güvenlik doğruluğu değildir.
• İmza oluşturma, sertifika iptali, dinamik erişim politikası ve şifreleme anahtar yönetimi deneysel olarak karşılaştırılmamıştır.
• IPFS çoğaltma politikası, pinleme kaybı veya düğüm arızası altında veri kullanılabilirliği ölçülmemiştir.
• Çoklu sunucu, çoklu bölge, ağ bölünmesi veya kötü niyetli blockchain eşleri değerlendirilmemiştir.
• Enerji tüketimi, işlem başına maliyet ve araç üzerindeki CPU/bellek kullanımı raporlanmamıştır.

Türkiye açısından ne ifade etmektedir?

Türkiye’de insansız araçların yalnızca anlık kontrolü değil, görev sırasında üretilen verilerin daha sonra doğrulanması da önem taşımaktadır. Bir afet bölgesinde çalışan insansız hava araçları, tarım robotları, maden araçları, liman ve fabrika içi otonom taşıyıcılar veya çok araçlı haritalama sistemleri aynı göreve ilişkin farklı veri parçaları üretebilir.

TAVOS yaklaşımı bu kayıtların tamamını büyük bir blockchain defterine kopyalamadan ortak bir denetim izi oluşturmak için kullanılabilir. Örneğin görev günlüğü, rota kaydı ve algılama çıktısı IPFS veya kurumun izinli dağıtık depolamasında tutulurken; kayıt kimliği, hash, görev, araç ve erişim politikası izinli blockchain üzerinde saklanabilir.

Yerel uygulama için aşağıdaki çalışmaların ayrıca yapılması gerekir:

• Gerçek araç telemetrisi, görüntü veya LiDAR yükleriyle uzun süreli deney.
• Mobil ağ, özel 5G, uydu veya kesintili bağlantı koşullarında paket kaybı testi.
• Birden çok fiziksel Fabric eşinin farklı merkezlerde çalıştırılması.
• Görev aciliyetine göre uyarlanabilir toplu kayıt politikası.
• Kurum içi veri sınıflandırmasıyla uyumlu şifreleme, yetkilendirme ve anahtar iptali.
• IPFS pinleme, yedekleme, veri yaşam döngüsü ve silme yükümlülüklerinin tanımlanması.
• Araç üzerindeki enerji, işlemci, bellek ve haberleşme maliyetlerinin ölçülmesi.
• Sahte veri üretimi, ele geçirilmiş araç anahtarı ve kötü niyetli yetkili düğüm senaryolarının sınanması.

Çalışmanın Yöntemi ve Bulguları

Araştırma tasarımının özeti

Gerçek ölçüm ile hesaplanan sonuçların ayrımı

Başlıca nicel sonuçlar

1. TAVOS zincir indeksi 0,7504 MB olarak ölçülmüştür.
2. Tam zincir içi depolama 53,2812 MB gerektirmiştir.
3. RollStore temsili 1,1357 MB indeks üretmiştir.
4. TAVOS tam zincir içi yaklaşıma göre yüzde 98,59 zincir alanı azaltmıştır.
5. TAVOS RollStore temsiline göre yüzde 33,93 daha küçük indeks üretmiştir.
6. IPFS-BC, TimeChain ve DAA-HSO daha küçük metadata alanına sahip olmuş, fakat daha az görev semantiği tutmuştur.
7. TAVOS’un 50 kayıtlık ortalama Fabric yazma süresi 2.443,10 ms olmuştur.
8. RollStore’un karşılık gelen ortalaması 2.468,24 ms olmuştur.
9. TAVOS önbellek isabetli sorgularda 756,30 ms ortanca gecikme göstermiştir.
10. TAVOS soğuk IPFS erişiminde 6.360,30 ms ortanca gecikmeye yükselmiştir.
11. Yerel SHA-256 hesaplaması 0,3 ms’nin altında kalmıştır.
12. Toplu kayıt sayısı 10’dan 200’e çıkarıldığında kapasite 4,18’den 83,73 kayıt/s’ye yükselmiştir.
13. Aynı değişimde kayıt başına gecikme 239,63’ten 11,95 ms’ye düşmüştür.
14. İncelenen tek bayt değişikliği veya hash uyuşmazlığı örneklerinin tamamı reddedilmiştir.

Şekillerin sunduğu bilgiler

• Şekil 1: Araç, uç düğüm, görev kontrolü, IPFS, Fabric ve hafif istemci katmanları arasındaki veri akışını göstermektedir.
• Şekil 2: Yerel indeks önbelleği, Fabric sorgusu, IPFS geri okuma ve hash karşılaştırmasından oluşan iki aşamalı hafif istemci akışını göstermektedir.
• Şekil 3: Fabric eşleri, sıralama hizmeti, sertifika otoriteleri, zincir kodu ve IPFS konteynerlerinin çalıştığına ilişkin Docker konsolunu sunmaktadır.
• Şekil 4: Zincir kodu dağıtımı, 1.000 kayıtlık toplu işlem ve deney özetlerinin konsol çıktısını göstermektedir.
• Şekil 5: Altı yöntemin logaritmik ölçekte zincir veya indeks alanını karşılaştırmaktadır.
• Şekil 6: TAVOS ve RollStore’un 50 kayıtlık gerçek Fabric işlem gecikmelerini, dağılımı ve aykırı değerleriyle göstermektedir.
• Şekil 7: Önbellek isabetli ve soğuk IPFS sorgularını ayırmakta; Fabric, IPFS ve hash maliyetlerini bileşenlere bölmektedir.
• Şekil 8: Toplu kayıt sayısı arttıkça kapasitenin yükseldiğini ve kayıt başına gecikmenin azaldığını göstermektedir.
• Şekil 9: Başarılı indeks yazma, VerifyIndex ve IPFS geri okuma çıktısını sunmaktadır.
• Şekil 10: Hatalı hash gönderildiğinde zincir kodunun kaydı reddettiğini göstermektedir.
• Şekil 11: Örneklenen kurcalama testlerinde iki yöntemin yüzde 100 reddetme oranını ve yaklaşık doğrulama maliyetlerini karşılaştırmaktadır.
• Şekil 12: Ölçülen kayıt dağılımından yeniden örneklenen 20.000 kayda kadar zincir alanı projeksiyonunu göstermektedir.
• Şekil 13: Görev alanı önbellek oranları farklı hafif istemcilerin tahmini eşzamanlama trafiğini göstermektedir.

Yöntemsel güçlü yönler

• Önerilen sistem yalnızca sözde kodla bırakılmamış, Fabric ve IPFS üzerinde çalıştırılmıştır.
• Ham veri büyüklüğü ve kayıt sayısı açıkça raporlanmıştır.
• Gerçek ölçüm ile mekanizma düzeyinde yeniden üretim arasındaki sınır açıkça belirtilmiştir.
• Normal önbellek erişimleri ile soğuk IPFS erişimleri ayrı raporlanmıştır.
• Gecikme tek bir toplam sayı olarak değil, Fabric, IPFS ve hash bileşenlerine ayrılmıştır.
• Aykırı Fabric işlem süreleri grafiklerden çıkarılmamıştır.
• Toplu işlem büyüklüğü için duyarlılık analizi yapılmıştır.
• Alan minimizasyonu ile görev semantiği arasındaki ödünleşim açıkça tartışılmıştır.
• Kurcalama sonucu konsol kanıtlarıyla gösterilmiştir.
• Ölçeklenebilirlik projeksiyonlarının ikinci gerçek kurulum olmadığı açıkça belirtilmiştir.

Yöntemsel sınırlılıklar

• Veri yükü gerçek araçlardan değil, operasyon türlerine göre sentetik olarak üretilmiştir.
• Yalnızca 1.000 kayıtla gerçek platform deneyi yapılmıştır.
• Fabric ve IPFS aynı yerel Docker ortamında çalıştırılmıştır.
• CPU modeli, disk türü, Docker sürümü, Fabric sürümü, IPFS sürümü ve ayrıntılı ağ yapılandırması yeterince raporlanmamıştır.
• Çoklu fiziksel IPFS düğümü veya uzak IPFS eşinden erişim denenmemiştir.
• Gerçek mobil ağ gecikmesi, paket kaybı ve bağlantı kesintisi bulunmamaktadır.
• Birden fazla eşzamanlı araç veya sorgu istemcisiyle yük testi yapılmamıştır.
• IPFS-BC, TimeChain ve DAA-HSO özgün platformlarıyla tam olarak yeniden kurulmamıştır.
• RollStore karşılaştırması özgün sistemin bütün protokol ve kanıt davranışlarını içeren tam yeniden üretim olarak gösterilmemiştir.
• Yazma ve sorgu farkları için istatistiksel anlamlılık veya güven aralığı analizi sunulmamıştır.
• Yüzde 100 kurcalama sonucu sınırlı ve deterministik hash uyuşmazlığı testine dayanmaktadır.
• İmza doğrulamasının hesaplama maliyeti ayrıca raporlanmamıştır.
• Erişim politikası ihlali, rol değişikliği ve yetki iptali deneyleri bulunmamaktadır.
• Şifreleme algoritması ve anahtar yönetim yöntemi uygulanmış bir deneyle açıklanmamıştır.
• IPFS kullanılabilirliği, pinleme ve veri çoğaltma arızaları incelenmemiştir.
• Blockchain düğümü ele geçirilmesi, gizli anlaşma veya kötü niyetli yönetici tehdidi modellenmemiştir.
• Enerji tüketimi ve araç üzerindeki kaynak kullanımı ölçülmemiştir.
• Deney kodu, ham CSV dosyaları veya yeniden üretilebilir açık depo bağlantısı verilmemiştir.

Kaynak ve Yöntem Notu

Çalışmanın tam özgün adı: Task-Aware Verifiable On/Off-Chain Information Integration for High-Frequency Operational Data in Collaborative Unmanned Vehicle Networks

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

Yazar sıralaması: Yukarıdaki liste çalışmanın özgün yazar sırasını korumaktadır.

Eş birinci yazar: Eş birinci yazarlık veya eş katkı beyanı bulunmamaktadır.

Sorumlu yazar: Qingquan Liu.

Sorumlu yazar e-posta adresi: lqqneu@163.com

Çalışmada belirtilen kurum: Shenyang University of Technology, Shenyang 110159, China.

SSRN metadata kaydındaki kurum: Shenyang Ligong University. Bu bilgi çalışmanın ilk sayfasındaki kurumla uyuşmamaktadır. İki kurum farklı kuruluşlardır ve erişilebilen resmî kayıtlardan doğru kurum kesin biçimde belirlenememiştir.

DOI:10.2139/ssrn.6986768

Yayın platformu: SSRN.

Yayın yılı: 2026.

Dergi: Hakemli bir dergi veya nihai dergi yayını doğrulanmamıştır.

Özgün yayınevi: Nihai bir dergi yayınevi belirtilmemiştir. Çalışma SSRN üzerinde preprint olarak paylaşılmıştır.

Kaynak türü: Hyperledger Fabric ve IPFS üzerinde çalışan prototip, deneysel yazılım ölçümleri ve mekanizma düzeyinde karşılaştırmalar içeren preprint araştırma makalesi.

Hakemlik durumu: Çalışma hakem değerlendirmesinden geçmemiştir. Sayfalarda “This preprint research paper has not been peer reviewed” uyarısı bulunmaktadır.

Resmî kaynak bağlantısı:https://ssrn.com/abstract=6986768

Yazar katkıları: Teşekkür ve katkı açıklamasına göre Rui Zhang makaleyi yazmış ve deneysel simülasyonu yürütmüştür. Guangtian Xu ve Shuxin Hu literatür taramasına; Shilei Li ve Meijie Jin biçim kontrolü ve düzeltmelere; Miaoxin Ge gönderim sürecine katkıda bulunmuştur. Qingquan Liu çalışmanın yönünü ve ana yapısını belirlemiştir. Resmî CRediT katkı tablosu verilmemiştir.

Finansman: Çalışmada finansman kuruluşu veya proje numarası belirtilmemiştir.

Çıkar çatışması: Açık bir çıkar çatışması beyanı bulunmamaktadır.

Veri ve kod erişimi: Konsol ve CSV çıktılarının kullanıldığı belirtilmiş; ancak deney kodu, ham kayıtlar veya yeniden üretilebilir açık veri deposu bağlantısı sunulmamıştır.

Bu Türkçe bilimsel açıklama, çalışmanın metni, formülleri, tabloları, mimari şemaları, performans grafikleri ve konsol görüntüleri incelenerek hazırlanmıştır. Bilimsel içerik yalnızca çalışmada sunulan sistem tasarımına, ölçümlere ve yazarların açıkladığı karşılaştırma sınırlarına dayanmaktadır. Dış kaynaklar yalnızca özgün başlığın, yazar listesinin, DOI’nin, SSRN kaydının ve bibliyografik kimliğin doğrulanması amacıyla kullanılmıştır.

Çalışmanın en önemli katkısı, blockchain–IPFS hibrit depolamasını genel dosya arşivlemenin ötesine taşıyarak görev, araç, veri türü ve erişim politikasıyla ilişkilendirmesidir. En önemli sınırlılığı ise gerçek platform sonuçlarının yerel Docker ortamı ve sentetik 1.000 kayıtla sınırlı olması; diğer yöntemlerin önemli bölümünün tam kurulum yerine mekanizma düzeyinde karşılaştırılmasıdır.

Yüzde 98,59 depolama azalması zincir veya indeks tarafına aittir. IPFS’deki ham veri ve olası kopyalar hesaba katılmadan sistemin toplam fiziksel depolamasının aynı oranda azaldığı ileri sürülmemelidir. Benzer biçimde yüzde 100 kurcalama tespiti, incelenen hash uyuşmazlığı örneklerinin tamamının reddedildiğini ifade eder; genel saldırı tespit başarısı veya uçtan uca sistem güvenliği olarak yorumlanmamalıdır.