Bu araştırma, elektrikli araç şarj oturumunun sonunda oluşturulan bir makbuzun yalnızca bir veritabanı kaydı olarak saklanması yerine, daha sonra değiştirildiğinin bağımsız biçimde anlaşılabilmesini sağlayan Proof-of-Charge adlı denetlenebilir bir kayıt platformu geliştirmektedir. Sistem şarj oturumunu deterministik bir makbuza dönüştürmekte, makbuz içeriğini SHA-256 ile özetlemekte, zaman sıralı sayaç ölçümlerini Merkle köküyle ilişkilendirmekte ve çok sayıda makbuzu tek bir Merkle batch kökü altında birleştirerek yalnız bu kompakt taahhüdü blockchain'e kaydetmektedir. Ayrıntılı şarj ve faturalandırma verileri ise zincir dışında PostgreSQL'de tutulmaktadır.

Prototip FastAPI, PostgreSQL, Python, Solidity ve yerel Ethereum uyumlu Anvil geliştirme zinciri kullanılarak uygulanmıştır. 10, 50, 100, 500 ve 1000 makbuzluk iş yüklerinin her biri on kez ölçülmüş; toplam 50 ölçümlü çalışmanın tamamında istenen, üretilen, kaydedilen, batch'e alınan, doğrulanan ve dışa aktarılan makbuz kimlikleri uzlaştırılmış; batch kökü kontrolleri ve yerel blockchain karşılaştırmaları başarılı olmuştur. Ortalama makbuz işleme gecikmesi test edilen iş yüklerinde 7,152–7,853 ms/makbuz, ortalama throughput ise 127,54–141,23 makbuz/s aralığında raporlanmıştır.

Çalışmanın dikkat çekici yönlerinden biri, blockchain'in bütün şarj kaydını saklamak için değil, dışarıdan karşılaştırılabilecek küçük bir bütünlük kontrol noktası olarak kullanılmasıdır. Şarj istasyonu kimliği, kullanıcı verisi, sayaç örnekleri, fiyatlandırma ve settlement ayrıntıları zincir dışında kalırken çok sayıda makbuzun tek batch kökü tek blockchain işlemiyle temsil edilebilmektedir. Yerel deneylerde 10 makbuz için batch sabitleme işlemi 143.329 gas birimi tüketirken 1000 makbuz için 143.365 gas birimi tüketmiştir; bu yakınlık, zincire makbuzların kendisinin değil sabit boyutlu bir kökün gönderilmesinden kaynaklanmaktadır.

Bununla birlikte sistem, kaydedilmiş bir verinin sonradan değiştirilmesini görünür hale getirmeyi amaçlar; ilk güvenilir kriptografik taahhüt oluşturulmadan önce yanlış üretilmiş, sahte veya hiç sisteme gönderilmemiş bir şarj olayının gerçek olduğunu kanıtlamaz. Çalışmada gerçek şarj cihazı imzası, sayaç düzeyinde dijital imza, sertifika zinciri, güvenilir zaman damgası, anahtar yaşam döngüsü, halka açık blockchain ağındaki finality veya gerçek OCPP/OCPI işletme verisi uygulanmamıştır. Bu nedenle Proof-of-Charge, kaynak verinin fiziksel olarak doğru olduğunu garanti eden bir ölçüm sistemi değil; kayıt oluşturulduktan sonraki bütünlüğü ve tutarlılığı denetlenebilir hale getiren bir prototiptir.

Türkiye açısından yorum: Mimari, kavramsal olarak Türkiye'deki elektrikli araç şarj platformlarında da değerlendirilebilecek genel bir kayıt ve denetim yaklaşımıdır; ancak araştırmada Türkiye'deki şarj işletmecileri, yerel sayaç altyapısı, gerçek şarj protokolleri, ödeme ve mutabakat sistemleri veya yerel işletme koşulları test edilmemiştir. Ayrıca bildirilen gecikme, throughput ve blockchain işlem değerleri doğrudan Türkiye'deki üretim altyapısına aktarılamaz. Gerçek kullanım için yerel şarj cihazları, gerçek sayaç verisi, kimlik ve anahtar yönetimi, ağ altyapısı, veritabanı ölçeği ve operasyonel mutabakat süreçleri üzerinde ayrıca doğrulama gerekir.

Araştırmanın temel problemi nedir?

Elektrikli araç şarjı yalnız aracın bataryasına enerji verilmesinden ibaret değildir. Halka açık bir şarj oturumunda sürücü, şarj noktası işletmecisi, e-mobilite hizmet sağlayıcısı, roaming platformu, ödeme sağlayıcısı ve başka enerji sistemi aktörleri aynı dijital kayıt zincirinde yer alabilir. Sayaç okumaları, zaman damgaları, tarifeler, işlem kimlikleri ve nihai fatura daha sonra ödeme uyuşmazlığı veya denetim için tekrar incelenmek zorunda kalabilir.

Çalışmanın hedeflediği sorun şudur: Bir veritabanında bulunan nihai makbuzun, makbuz oluşturulurken kullanılan zaman sıralı sayaç verisiyle gerçekten aynı kayda bağlı kaldığı ve sonradan değiştirilmediği nasıl bağımsız biçimde denetlenebilir?

OCPP ve OCPI gibi protokoller şarj altyapısı ile backend veya farklı hizmet sağlayıcıları arasında veri alışverişini desteklemektedir. Ancak araştırmacıların vurguladığı boşluk, veri iletiminin kendisinin uzun vadeli makbuz bütünlüğünü kanıtlayan bağımsız bir doğrulama mekanizması olmamasıdır.

Proof-of-Charge ne anlama geliyor?

Bu çalışmada Proof-of-Charge, tek bir hash değerinden daha geniş bir kavramdır. Terim; tamamlanmış bir EV şarj makbuzunu zaman sıralı sayaç kayıtlarına, batch üyeliğine ve blockchain'e sabitlenmiş kriptografik taahhüde bağlayan tüm doğrulama zincirini ifade etmektedir.

Temel akış şöyledir:

Neden bütün kayıt doğrudan blockchain'e yazılmıyor?

Araştırmacılar blockchain'i uygulama veritabanının yerine koymamaktadır. Tam bir şarj oturumunda kullanıcı ve EVSE kimlikleri, sayaç örnekleri, zaman damgaları, tarife ayrıntıları ve settlement değerleri bulunabilir. Bu ayrıntıların tamamının zincir üzerinde tutulması depolama yükünü ve işlem maliyetini artırabileceği gibi hassas verilerin gereksiz biçimde yayımlanmasına da yol açabilir.

Platform bu nedenle hibrit bir yapı kullanmaktadır:

• Off-chain: Tam oturum kayıtları, sayaç değerleri, makbuzlar, batch üyelikleri ve doğrulama geçmişi PostgreSQL'de tutulur.
• On-chain: Yalnız çok sayıda makbuzu temsil eden kompakt batch Merkle kökü tutulur.

Blockchain burada “bütün gerçeği taşıyan veritabanı” değil, daha sonra yerel kayıtla karşılaştırılabilecek dış bir kriptografik referanstır.

Kanonik makbuz neden gerekli?

Kriptografik hash hesaplamasında aynı bilimsel veya ticari anlamı taşıyan iki JSON belgesinin byte düzeyinde farklı olması farklı hash üretir. Anahtar sırası, Unicode biçimi, zaman dilimi yazımı, sayı yuvarlama biçimi veya gereksiz boşluklar değişirse hash de değişebilir. Araştırmacılar bu problemi önlemek için poc-c14n-v1 adlı açık bir kanonikleştirme profili tanımlamıştır.

Profilde yeni makbuzlar kompakt UTF-8 JSON olarak serileştirilir; nesne anahtarları Unicode kod noktasına göre sıralanır, dizi sırası anlamlı kabul edilir, metinler Unicode NFC'ye normalleştirilir, zaman damgaları UTC biçimine çevrilir ve enerji/fiyat/settlement miktarları ROUND_HALF_UP yöntemiyle üç ondalık basamaklı dizgiler halinde temsil edilir. Negatif sıfır 0.000'a dönüştürülmektedir.

Eksik zorunlu alan, null değer, fazladan alan, zaman dilimi belirtilmemiş timestamp, sonlu olmayan sayı, duplicate JSON anahtarı, bilinmeyen profil veya desteklenmeyen algoritma durumunda işlem “fail closed” olacak şekilde tasarlanmıştır.

Araştırmacılar Python 3.13.3 ve Node.js v23.10 uygulamalarının belirlenmiş uygunluk vektörü için aynı UTF-8 byte dizisini ve aynı SHA-256 sonucunu ürettiğini bildirmektedir. Bu test yalnız incelenen Python–JavaScript eşleşmesini doğrular; her programlama dili veya her JSON serileştiricisi için evrensel birlikte çalışabilirlik kanıtı değildir.

Şarj oturumu matematiksel olarak nasıl temsil ediliyor?

Çalışmada bir şarj oturumu şu genel yapı ile tanımlanmaktadır:

\[ S=\{sid,uid,evse,tx,t_s,t_e,M,P,type\} \]

Burada sid oturum kimliği, uid kullanıcı kimliği, evse şarj noktası kimliği, tx işlem kimliği, \(t_s\) ve \(t_e\) başlangıç/bitiş zamanları, \(M\) sıralı sayaç verisi, \(P\) fiyatlandırma yapısı ve type ise oturumun yalnız şarj, yalnız deşarj veya çift yönlü olduğunu belirtmektedir.

Sayaç akışı:

\[ M=\{m_1,m_2,\ldots,m_n\} \]

biçimindedir. Her \(m_i\) bir zaman damgası ile enerjiyle ilgili ölçümleri taşır.

V2G için enerji hesabı nasıl modelleniyor?

Makbuz yalnız araca aktarılan enerjiyi değil, araçtan geri verilen enerjiyi de temsil edebilmektedir. Enerji özeti:

\[ E=\{E_{\mathrm{import}},E_{\mathrm{export}},E_{\mathrm{net}}\} \]

olarak tanımlanır ve temel invariant:

\[ E_{\mathrm{net}}= E_{\mathrm{import}}-E_{\mathrm{export}} \]

şeklindedir. Yalnız şarj oturumunda export sıfırdır. Yalnız deşarj oturumunda net enerji negatif olabilir. Çift yönlü oturumda aynı makbuz hem ithal edilen hem geri verilen enerjiyi içerebilir.

Settlement için kaynak metnin açıklamasında brüt ithalat maliyeti \(C_{\mathrm{import}}\), brüt ihracat kredisi \(C_{\mathrm{export}}\) ve net tutar \(C_{\mathrm{net}}\) tanımlanmakta ve:

\[ C_{\mathrm{net}}= C_{\mathrm{import}}-C_{\mathrm{export}} \]

ilişkisi kullanılmaktadır.

Kaynak notasyonu uyarısı: Çalışmanın Bölüm 4.3'ünde bu maliyet alanları açıklanırken Eşitlik (6) enerji değişkenlerini yeniden yazmaktadır. Bu nedenle Eşitlik (6)'daki gösterim ile hemen altındaki maliyet açıklaması arasında kaynak içi notasyon tutarsızlığı bulunmaktadır. Verianla bu ifadeyi sessizce değiştirmemektedir.

Makbuz hash'i neyi koruyor?

Kanonik makbuz \(R\) oluşturulduktan sonra:

\[ h_R=H(R) \]

hesaplanmaktadır. Prototipte \(H\), SHA-256'dır. Makbuzun zaman damgası, enerji miktarı, fiyat alanı, kimliği veya sayaç Merkle kökü değişirse yeniden hesaplanan hash farklılaşır.

Bu mekanizma “makbuzdaki bilginin fiziksel dünyada doğru olduğunu” kanıtlamaz. Kanıtlanan şey, belirli kanonik içeriğin hash oluşturulduktan sonra değiştirilip değiştirilmediğidir.

Neden sayaç verilerinin ayrıca Merkle kökü var?

Yalnız son enerji toplamını hash'lemek, o sonuca ulaşırken kullanılan ölçüm dizisini doğrudan bağlamaz. Bu nedenle her sayaç örneği önce hash'lenmekte:

\[ h_i=H(m_i) \]

ve ardından:

\[ root_M= MerkleRoot(h_1,h_2,\ldots,h_n) \]

hesaplanmaktadır. Sayaç kaydının değiştirilmesi, silinmesi, yeniden sıralanması veya sonradan araya başka bir örnek eklenmesi yeniden hesaplanan kökü değiştirebilir.

Örnekler timestamp'e göre sıralanmakta, import ve export kWh cinsinden kümülatif yönlü sayaçlar olarak ele alınmaktadır. Değerler 0,001 kWh hassasiyetine yuvarlanmakta ve azalan kümülatif sayaç değeri olası reset veya veri bozulması kabul edilerek reddedilmektedir.

Bununla birlikte prototip eksik sayaç örneğini tahmin etmez, sayaç resetini otomatik düzeltmez, saat kaymasını onarmaz ve kaynağın belirtmediği birimi dönüştürmez. En önemlisi, bir sayaç örneği sisteme ilk güvenilir taahhütten önce hiç gönderilmemişse, yalnız Merkle ağacı bunun eksik olduğunu bağımsız biçimde bilemez.

Batch Merkle kökü neden ikinci kez kullanılıyor?

Birinci Merkle ağacı tek bir oturumun sayaç dizisini temsil ederken ikinci Merkle ağacı çok sayıda makbuzu temsil eder:

\[ B=\{h_{R1},h_{R2},\ldots,h_{Rk}\} \]

ve:

\[ root_B= MerkleRoot(h_{R1},h_{R2},\ldots,h_{Rk}) \]

elde edilir. Blockchain'e her makbuz için ayrı işlem gönderilmesi yerine yalnız \(root_B\) gönderilir.

Yeni batch'lerde poc-batch-merkle-v1 profili kullanılmaktadır. Profil UTC batch gününü, zaman aralığını, sıralama kuralını, yaprak sayısını ve Merkle ağacı oluşturma bağlamını taahhüde bağlamaktadır. Kayıtlar normalize edilmiş UTC başlangıç zamanı, NFC normalize oturum kimliği ve makbuz hash byte'larına göre deterministik olarak sıralanmaktadır.

Profil duplicate session ID, duplicate receipt hash, duplicate leaf encoding, bozuk hash ve geçersiz indeksleri reddetmektedir. Tek sayıda düğüm bulunan bir Merkle seviyesinde son düğüm kendisiyle eşleştirilmektedir.

Bir makbuzun batch içinde olduğunu nasıl kanıtlıyor?

Sistem tüm batch'i paylaşmadan tek makbuzun batch üyeliğini doğrulayabilecek bağımsız JSON membership proof üretmektedir. 1000 yapraklı deterministik örnekte araştırmacılar:

• Merkle ağaç derinliğini 10,
• kardeş hash sayısını 10,
• serileştirilmiş JSON proof boyutunu 2064 byte,
• proof oluşturma süresini yaklaşık 0,060 ms,
• proof doğrulama süresini yaklaşık 0,057 ms

olarak bildirmiştir. Bu süreler aynı yerel deney ortamındaki tanısal ölçümlerdir ve genel amaçlı blockchain proof performansı olarak yorumlanmamalıdır.

Doğrulama neden katmanlı?

Tek bir hash kontrolü veritabanındaki her tutarsızlık türünü aynı hassasiyetle lokalize edemez. Bu nedenle çalışma beş tamamlayıcı kontrol yüzeyi kullanmaktadır:

1. Makbuz doğrulaması: Kanonik JSON yeniden hash'lenir.
2. Sayaç doğrulaması: Normalize sayaç satırlarından meter Merkle root yeniden hesaplanır.
3. Veritabanı audit'i: Oturumdan yeniden oluşturulan makbuz, kayıtlı JSON ve normalize sütunlar karşılaştırılır.
4. Batch doğrulaması: Üyelik snapshot'ı ve batch root yeniden hesaplanır.
5. On-chain doğrulama: Yerel batch root blockchain sözleşmesinden okunan kökle karşılaştırılır.

Bu yapı yalnız “doğrulama başarısız” demek yerine bozulmanın hangi kayıt katmanında ortaya çıktığını belirlemeye yardımcı olmaktadır.

Blockchain hangi güvenlik özelliklerini sağlamıyor?

Araştırmacılar blockchain'in kapsamını özellikle sınırlandırmaktadır. Mevcut prototipte içerik bütünlüğü, sayaç yeniden hesaplama, batch doğrulama, database audit ve zincir üzerindeki kök karşılaştırması uygulanmıştır. Ancak kimlik doğrulama ve kaynağın gerçekliği üretim aşamasına bırakılmıştır.

Gerçek dağıtım için kaynak; dijital imzalar, sertifika zincirleri, güvenilir anahtar yönetimi, revocation, trusted timestamp, yetkili yayıncı denetimi, replay koruması, contract governance, gizlilik mekanizmaları ve harici authoritative session registry ile uzlaştırma gibi ek kontroller önermektedir.

Dolayısıyla “blockchain'de var” ile “ölçüm kesinlikle gerçek” aynı bilimsel iddia değildir.

Çalışma ne söylüyor, ne söylemiyor?

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

• Deterministik EV şarj makbuzu üretimi ve tekrar hash doğrulaması uygulanmıştır.
• Zaman sıralı sayaç kayıtları oturum düzeyinde Merkle köküyle taahhüt edilebilmiştir.
• Makbuzlar batch Merkle kökü altında toplanarak tek blockchain işlemiyle temsil edilebilmiştir.
• 10–1000 makbuzluk toplam 50 ölçümlü tekrarda bütün tanımlanan correctness kontrolleri geçmiştir.
• Yedi kontrollü post-finalization tutarsızlığın tamamı önceden belirlenmiş ilgili doğrulama katmanlarında saptanmıştır.
• Charge-only, discharge-only ve bidirectional sentetik kayıtlar aynı temel makbuz/doğrulama mimarisiyle temsil edilmiştir.

Çalışmanın desteklemediği veya test etmediği sonuçlar:

• Gerçek şarj istasyonundan gelen verinin fiziksel olarak doğru olduğunu kanıtlamamaktadır.
• İlk kriptografik taahhütten önce uydurulmuş veya hiç kaydedilmemiş bir oturumu otomatik olarak tespit etmemektedir.
• Gerçek OCPP veya OCPI üretim sisteminde denenmemiştir.
• Canlı V2G şarj cihazı veya enerji piyasası settlement'ı test edilmemiştir.
• Halka açık Ethereum/EVM ağındaki gecikme, fee veya finality performansını ölçmemektedir.
• Digital signature, PKI, issuer authentication veya trusted timestamp uygulamamaktadır.
• Sonuçlar tek Apple M1 Max deney ortamından başka donanımlara doğrudan genellenemez.
• Yerel Anvil gas ücretleri gerçek ağ maliyeti olarak kullanılamaz.

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

Deney ortamı

Her iş yükü için bir warm-up çalışması yapılmış ve ardından on ölçümlü tekrar gerçekleştirilmiştir. Toplam 50 ölçümlü workload–seed kombinasyonu orchestration seed 20260801 kullanılarak rastgele sıraya konmuştur. Çalışma hiçbir gözlemi outlier olarak çıkarmamıştır.

Makbuz işleme performansı

Ortalama gecikmeler iş yükü arttıkça tek yönlü monoton bir artış göstermemiştir. Güven aralıklarının önemli ölçüde örtüşmesi nedeniyle çalışma, örneğin 50 makbuzun 100 makbuzdan intrinsik olarak daha hızlı olduğu sonucunu çıkarmamaktadır. Daha dar yorum, test edilen tek yerel ortamda makbuz başına ortalama pipeline gecikmesinin yaklaşık aynı bantta kalmasıdır.

Kuyruk gecikmesi ise daha belirgin bir davranış göstermiştir. 1000 makbuz iş yükünde p99 gecikmesi 15,076 ms'ye çıkarken 10 makbuz iş yükünde 11,032 ms'dir. Bu nedenle yalnız ortalama değere bakmak büyük iş yüklerindeki tail latency davranışını tam olarak göstermemektedir.

Pipeline'da asıl zamanı ne tüketiyor?

1000 makbuz iş yükünde aşamalara ayrılmış ortalama süreler şunlardır:

Çalışmanın kendi implementasyonunda baskın makbuz-pipeline bileşeni PostgreSQL persistence olmuştur. Makbuz oluşturma ve sayaç Merkle hesaplama süreleri bunun yanında çok küçüktür. Araştırmacılar daha iyi sonuç göstermek amacıyla mevcut per-receipt persistence yolunu toplu insert ile değiştirmemiştir.

Blockchain batch sabitlemesi nasıl ölçeklendi?

Gas kullanımı 10 ile 1000 makbuz arasında yalnız çok küçük ölçüde değişmiştir. Bunun nedeni Solidity sözleşmesine tüm makbuzların değil, bir adet sabit boyutlu Merkle batch kökü ve ilgili metadata'nın gönderilmesidir.

Tablodaki wei değerlerinin iş yükü büyüdükçe azalması “büyük batch blockchain'de mutlak olarak daha ucuzdur” şeklinde yorumlanmamalıdır; transaction fee gas kullanımı ile o yerel işlemdeki effective gas price'ın çarpımına bağlıdır. Üstelik bu deneyler otomatik mining kullanan yerel Anvil zincirindedir. Değerler gerçek Ethereum, Layer-2 veya başka halka açık ağların ücretleri değildir.

Çalışmanın batch yaklaşımındaki temel ölçekleme ilişkisi:

\[ C_{\mathrm{session}} = \frac{C_{\mathrm{tx}}}{N_{\mathrm{receipts}}} \]

şeklindedir. Aynı batch işleminin daha fazla makbuzu kapsaması halinde işlem başına değil, kapsanan makbuz başına efektif sabitleme maliyeti azalır.

Yedi kontrollü veri değiştirme testi ne gösterdi?

Yedi senaryonun tamamı önceden tanımlanmış davranışı göstermiş ve her senaryodan sonra savepoint rollback ile veritabanı orijinal duruma döndürülmüştür. T7 testinde gerçek Anvil işlemi bozulmamış; doğrulayıcıya kontrollü biçimde alternatif bir external root verilerek karşılaştırma katmanı test edilmiştir.

Bu deney bir saldırı tespit olasılığı veya gerçek saldırganlara karşı güvenlik oranı ölçmemektedir. Amaç, farklı kayıt yüzeyleri değiştirildiğinde hangi bütünlük katmanının tutarsızlığı yakaladığını deneysel olarak göstermektir.

V2G-ready desteği ne kadar gerçek?

Prototip charge-only, discharge-only ve bidirectional sentetik oturumları aynı makbuz şeması içinde işleyebilmektedir. İthal edilen enerji, ihraç edilen enerji, net enerji, import maliyeti, export kredisi ve net settlement tutarı ayrı alanlardır.

Ancak çalışma gerçek çift yönlü şarj cihazına bağlanmamış, batarya degradasyonunu modellememiş, aggregator davranışı incelememiş, enerji piyasasını simüle etmemiş ve gerçek grid hizmeti gerçekleştirmemiştir. Dolayısıyla “V2G-ready” ifadesi mevcut çalışmada esas olarak veri modeli ve settlement kayıt yapısının çift yönlü enerjiye hazır olması anlamındadır.

Kaynak ve Yöntem Notu

Tam özgün çalışma adı: A Reproducible Blockchain-Anchored Proof-of-Charge Platform for Auditable EV Charging Receipts

Yazarlar ve sıraları: Nexhibe Sejfuli-Ramadani; Valentina Angelkoska; Florim Idrizi; Valentin Rakovic; Erenis Ramadani; Aleksandar Risteski.

Sorumlu yazar: Aleksandar Risteski.

Eş katkı/eş birinci yazar: Kaynakta belirtilmemiştir.

Kurumlar:

• Faculty of Natural Sciences and Mathematics, University of Tetova, Tetovo, North Macedonia.
• Faculty of Economics, University of Skopje, Skopje, North Macedonia.
• Faculty of Electrical Engineering and Information Technologies, Ss. Cyril and Methodius University, Skopje, North Macedonia.
• Tarmac LLC, Skopje, North Macedonia.

Dergi: Future Internet

Yayınevi: MDPI, Basel, Switzerland

Cilt / sayı / makale: 18 / 8 / 423

Alınma tarihi: 6 Temmuz 2026

Revizyon tarihi: 2 Ağustos 2026

Kabul tarihi: 8 Ağustos 2026

Yayın tarihi: 10 Ağustos 2026

DOI: 10.3390/fi18080423

Resmî yayın bağlantısı:https://doi.org/10.3390/fi18080423

Kaynak türü: Araştırma makalesi; uygulanmış yazılım prototipi ve kontrollü hesaplamalı performans değerlendirmesi.

Hakemlik durumu: Hakemli dergide yayımlanmış makale.

Lisans: Creative Commons Attribution (CC BY).

Finansman: Araştırma dış finansman almamıştır.

Veri erişilebilirliği: Araştırmada gerçek EV şarj kullanıcısı verileri değil sentetik veriler kullanılmıştır. Kaynak makale; kod, sentetik veri üretim betikleri, deney iş akışları, oluşturulan veri setleri, ham zamanlama gözlemleri, run-level metrikler, istatistiksel özetler, şekiller, canonicalization test vektörleri, membership proof'lar, tamper-matrix çıktıları ve provenance manifestlerinin proje deposunda kamuya açık olduğunu bildirmektedir. Makaledeki erişim tarihi 7 Ağustos 2026'dır.

Yazar katkıları: Kaynakta Nexhibe Sejfuli-Ramadani kavramsallaştırma ve proje yönetiminde; Nexhibe Sejfuli-Ramadani, Erenis Ramadani ve Valentin Rakovic metodolojide; Nexhibe Sejfuli-Ramadani ve Erenis Ramadani yazılımda; Nexhibe Sejfuli-Ramadani, Erenis Ramadani, Valentina Angelkoska ve Florim Idrizi doğrulamada katkı sahibi olarak belirtilmektedir. Kaynak ayrıca formal analiz, veri kürasyonu, görselleştirme, yazım, denetim ve diğer katkıları yazar bazında ayrıntılı olarak bildirmektedir.

Çıkar çatışması: Kaynak, Erenis Ramadani'nin Tarmac LLC tarafından istihdam edildiğini; diğer yazarların ticari veya finansal çıkar çatışması oluşturabilecek ilişki bulunmadığını beyan ettiklerini bildirmektedir.

Kaynak içi notasyon tutarsızlığı: Bölüm 4.3'te settlement alanları maliyet değişkenleri C_import, C_export ve C_net olarak açıklanmasına rağmen Eşitlik (6) görünür biçimde enerji özeti E değişkenlerini tekrar etmektedir. Sonraki Eşitlik (7) ise C_net = C_import − C_export maliyet ilişkisini vermektedir. Bu notasyon farkı kaynakta bulunduğu biçimiyle not edilmiştir ve sessizce düzeltilmemiştir.

Temel yöntemsel sınırlılıklar: Test oturumları sentetiktir; canlı OCPP/OCPI sistemi kullanılmamıştır. Tekrarlanan benchmark tek Apple M1 Max ortamındadır. Blockchain testi yerel Anvil zincirindedir ve otomatik mining kullanmaktadır. Python–JavaScript canonicalization uyumu test edilmiş olsa da tüm diller doğrulanmamıştır. Sayaç düzeyinde dijital imza, issuer certificate doğrulaması, güvenilir timestamp, güvenli anahtar yaşam döngüsü, privacy-preserving disclosure ve harici authoritative session registry uzlaştırması uygulanmamıştır. İlk güvenilir taahhütten önce uydurulmuş veya atlanmış verilerin varlığı Merkle mekanizması tarafından tek başına tespit edilemez.

Bu Verianla makalesindeki bilimsel yöntem, sayısal sonuçlar, güvenlik kapsamı ve sınırlılıklar incelenen çalışmaya dayanmaktadır. Dış doğrulama yalnız yayın kimliği ve hakemli dergi durumunu doğrulamak amacıyla kullanılmış; dış kaynaklardan yeni deneysel performans değeri, yeni güvenlik iddiası veya yeni blockchain sonucu ana bilimsel içeriğe eklenmemiştir.