Uçuş Verisi Doğrulama: Neden Blokzincir Kullanıyoruz

Sponsorlarımızdan biri Avalanche tabanlı bir blokzincir şirketi, bu yüzden 'blokzincir kullanın' fikri ilk başta sponsorluk kutusunu işaretlemek gibi görünüyordu. Ama oturup asıl problemi yazınca işin gerçek bir mühendislik tarafı çıktı: yarışma jürisine veya bir ziyaretçiye 'bu uçuş logu yarışmadan sonra değiştirilmedi' dediğimizde, bize neden inansınlar? Bir veritabanı kaydı gösterirsek, o kaydı biz de değiştirebiliriz. Çözüm basit: iddiayı bize sormak zorunda kalmayacakları bir yere yazmak.

Ne zincire yazıyoruz, ne yazmıyoruz

Log dosyasının kendisini hiçbir yere yüklemiyoruz, ne zincire ne sunucuya. Sadece SHA-256 özetini yazıyoruz, 32 baytlık bir parmak izi. Dosyanın kendisi bizde kalıyor, isteyen kendi kopyasıyla doğrular. Bunun iki sebebi var: dosya boyutu (bazı loglar onlarca MB) zincirde tutulamayacak kadar pahalı olurdu, ve asıl önemlisi, doğrulama için dosyanın herkese açık olması gerekmiyor, sadece değişmediğinin ispatlanabilir olması yeterli.

• Zincire yazılan: logId, başlık, tarih, SHA-256 özeti, işlem hash'i.
• Zincire yazılmayan: log dosyasının kendisi, ham telemetri, GPS verisi.
• Kontrat tek fonksiyonlu: anchorLog(logHash, logId, title), owner-only.
• Aynı logId ikinci kez zincire yazılamıyor (AlreadyAnchored), yani bir kayıt üzerine sonradan yazılamıyor.

Neden Fuji testnet, mainnet değil

Avalanche C-Chain mainnet'e yazmak da mümkündü ama bunun için gerçek AVAX harcamamız gerekirdi, öğrenci takımı bütçesiyle her uçuş sonrası gaz ücreti ödemek mantıklı değil. Fuji testnet EVM uyumlu, yani aynı kontrat kodu, aynı araçlar (viem), tek fark test AVAX'ın faucet'ten bedava gelmesi. Doğrulanabilirlik açısından hiçbir kayıp yok: testnet de mainnet gibi herkese açık, değiştirilemez, üçüncü bir tarafın kontrolünde değil. Yarışma bağlamında ispat gücü aynı, maliyet sıfır.

Bize güvenmeniz gerekmiyor. Matematiğe güvenmeniz yeterli, o da herkese açık.

Kontratı kasıtlı aptal tuttuk

FlightLogRegistry.sol'da upgrade mekanizması yok, rol yönetimi yok, tek fonksiyon var. İlk taslakta 'ileride lazım olur' diye çoklu yetkilendirme ve kayıt güncelleme fonksiyonu eklemeyi düşündük, sonra vazgeçtik. Bu kontratın tek işi var: bir hash'i, bir kez, geri alınamaz şekilde yazmak. Ne kadar az hareketli parça olursa, denetlemesi ve güvenmesi o kadar kolay oluyor. Kontrat Remix üzerinden elle deploy edildi, repoya Hardhat gibi bir toolchain eklemedik; tek seferlik bir işlem için gereksiz karmaşıklık olurdu.

Doğrulama akışı: sunucu araya girmiyor

/dogrulama sayfasında kendi dosyanı yüklediğinde, SHA-256 hesaplaması tarayıcında çalışıyor, dosya hiçbir zaman bize gönderilmiyor. Sonra tarayıcı doğrudan Fuji'nin herkese açık RPC'sine bağlanıp zincirdeki hash'i okuyor, salt-okunur bir çağrı, imza gerekmiyor. İki hash eşleşiyorsa 'eşleşti' yazıyor. Bizim sunucumuzun bu adımda hiçbir rolü yok, yani sonucu manipüle etme ihtimalimiz de yok. Admin tarafında ise tam tersi: dosya hash'i hesaplandıktan sonra takımın cüzdanından imzalanıp zincire yazılıyor, bu adım elbette yetki gerektiriyor.

Sonuç

Bu özellik gösteriş için eklenmiş bir rozet değil, gerçek bir sorunun çözümü: iddiamızı doğrulamak için bize güvenmen gerekmiyor. /dogrulama sayfasında hem kayıtlı logları hem kendi dosyanı doğrulama aracını bulabilirsin.