GÜVEN MİMARİSİ
Güven bir söz değil, bir mimari kararlar bütünüdür.
"Güvenilir" demek kolay. Burada onun yerine, bir raporun neden sonradan değiştirilemediğini, bir hesabın neden başka birinin verisini göremediğini ve bir tutarın neden yuvarlama hatasıyla kaybolmadığını -- veritabanı seviyesinde -- tek tek gösteriyoruz.
Lancerix'te güven, uygulama kodunun "iyi niyetli" davranmasına değil, Postgres'in kendisinin belirli işlemleri reddetmesine dayanır: yetkisiz bir satır okunamaz, imzalanmış bir kayıt silinemez, parasal bir tutar asla ondalıklı bir sayı olarak saklanamaz. Bu sayfa, o kısıtların her birinin nerede ve nasıl uygulandığını anlatır.
Para, hiçbir noktada ondalıklı bir sayı olarak var olmaz
Her tutar kuruş cinsinden bir tam sayıdır (BIGINT), hiçbir zaman float değil. Oranlar baz puan cinsindendir (1000 = %10,00). Bu, kayan noktalı sayıların klasik hatasını -- 0,1 + 0,2'nin tam olarak 0,3 etmemesi -- para hesaplarından tamamen çıkarır.
Platform komisyonu, freelancer'ın net kazancından değil, müşterinin üstüne eklenen tutardan hesaplanır; müşteri ücreti ve freelancer net kazancı ikisi de tek bir brüt tutardan çıkarma yoluyla türetilir, ikinci bir yüzde hesabıyla değil -- böylece iki taraf da aynı toplam üzerinde asla anlaşamama riski taşımaz.
Bu mantık iki dilde ayrı ayrı yazılmaz: TypeScript tarafındaki hesaplama fonksiyonu ile Postgres'teki STORED GENERATED kolonlar birebir aynı yuvarlama kuralını (yarıdan büyükse yukarı) uygular ve otomatik testlerle karşılaştırılır.
Bir durum değişikliği yalnızca tek bir kapıdan geçebilir
Bir teslimatın veya bir ödeme aşamasının durumu, uygulama kodunda herhangi bir yerden değil, yalnızca tek bir veritabanı fonksiyonu üzerinden değişebilir. Hangi durumdan hangi duruma geçilebileceği ayrı bir tabloda tanımlıdır; tanımsız bir geçiş veritabanı tarafından reddedilir.
Bu fonksiyon, durum değişikliğini ve o değişikliği açıklayan kayıt defteri satırını aynı veritabanı işlemi (transaction) içinde yazar -- yarıda kesilen bir işlem, açıklaması olmayan bir durum değişikliği bırakamaz.
Bir tetikleyici (trigger), bu fonksiyonun dışından yapılan hiçbir durum güncellemesini kabul etmez -- uygulama kodunda bir hata olsa bile, veritabanı kuralı çiğnenemez.
Kayıt defteri yalnızca eklenebilir, asla silinemez veya değiştirilemez
Her durum değişikliği, her doğrulama raporu, kalıcı bir kayıt defterine yazılır. Bu tablolarda UPDATE veya DELETE için hiçbir izin (policy) tanımlı değildir -- ayrıca bunu engelleyen ayrı bir tetikleyici de vardır. Bu, uygulamanın en yetkili hesabı (admin) için bile geçerlidir.
Bir doğrulama raporunun kriptografik özeti (SHA-256), o raporun tam olarak hangi metni içerdiğinin değiştirilemez kanıtıdır -- rapor sonradan "düzeltilirse", özet artık eşleşmez ve bu fark açıkça görülür. Bu bir blokzincir değildir; dağıtık bir ağ yerine, tek bir güvenilir tarafın (Lancerix) veritabanı seviyesinde uyguladığı bir değiştirilemezlik garantisidir -- ama garantinin kendisi gerçektir, pazarlama süsü değildir.
Erişim, uygulama kodunda değil veritabanının kendisinde zorunlu kılınır
Her tabloda satır seviyesi güvenlik (Row Level Security) açıktır, istisnasız. Bir freelancer yalnızca kendi kayıtlarını, bir müşteri yalnızca kendi kayıtlarını görebilir -- bu kural uygulama kodunun bir sorguyu doğru yazmasına değil, Postgres'in kendisinin her sorguyu bu kurala göre süzmesine dayanır.
Bunun pratik sonucu şu: uygulama katmanında bir yetkilendirme hatası olsa bile (yanlış bir sorgu, unutulmuş bir kontrol), veritabanı yine de yetkisiz bir satırı döndürmez. Yetkilendirme, tek bir yerde, tek bir şekilde uygulanır.
Kimlik alanları, yazıldıkları anda doğrulanır
TCKN (11 haneli) ve VKN (10 haneli) alanları, hem tarayıcıda hem veritabanına yazılırken kendi resmi doğrulama algoritmalarıyla (checksum) kontrol edilir. Rastgele 11 haneli bir sayı sisteme kaydedilemez.
Sık sorulanlar
Bu bir blokzincir mi?
Hayır. Blokzincir, birbirine güvenmeyen çok sayıda tarafın ortak bir kayıt üzerinde anlaşmasını sağlayan dağıtık bir sistemdir. Lancerix'te tek bir güvenilir taraf (Lancerix'in kendi veritabanı) var; değiştirilemezlik garantisi dağıtık konsensüsten değil, o veritabanının kendi erişim kurallarından ve kriptografik özetlerden gelir. Daha basit bir sistemdir, ama gerçek ve doğrulanabilir bir garantidir.
Bağımsız bir güvenlik denetiminden geçtiniz mi?
Henüz hayır. Bu sayfada anlatılan mimari, şu ana kadar kendi iç disiplinimiz ve kod incelemelerimizle sürdürüldü. Bağımsız bir üçüncü taraf denetimi, Faz 2'nin (gerçek fon saklama) kapsamına girmeden önce atmayı planladığımız somut bir adım.
Bu mimari Faz 2'de (escrow) nasıl genişleyecek?
Aynı üç ilke -- tam sayı para birimi, tek kapılı durum makinesi, değiştirilemez kayıt defteri -- escrow hesap bakiyeleri için de kullanılacak. Faz 2 yeni bir güven modeli icat etmiyor, Faz 1'de zaten kanıtlanmış olanı gerçek fon hareketine genişletiyor.
Kaynak kodu inceleyebilir miyim?
Şu an için hayır, kaynak kod kapalı. Bu sayfa, kodu göstermeden mimarinin hangi kararları ve hangi garantileri içerdiğini olabildiğince somut anlatmak için var.
Mekanizmayı canlı görmek ister misin?
Örnek bir doğrulama raporuna bakabilir ya da doğrudan bir sözleşme oluşturup akışın tamamını deneyebilirsin.