Her bakiye neden çift kayıtlı bir defterden gelmek zorunda

Her bankacılık sisteminde, ürünün en önemli sorusunu yanıtlayan bir tablo vardır: bu müşterinin ne kadar parası var? Güvenilir çekirdekleri kırılgan olanlardan ayıran tasarım kararı, o sayının saklanıyor mu — birinin güncellediği bir sütun — yoksa türetiliyor mu — yalnızca eklemeye izin veren bir defterin toplamı — olduğudur. Kulağa bir uygulama ayrıntısı gibi gelir. Oysa bakiyelerini kanıtlayabilen bir sistemle yalnızca iddia edebilen bir sistem arasındaki farktır.

Bu, bir fintech çekirdeğindeki en ağır sonuçlu mimari karardır ve bir demoda neredeyse görünmezdir. İki ürün ekranda birbirinin aynısı görünebilir; biri bakiye sütununu yerinde güncellerken diğeri her bakiyeyi çift kayıtlı bir defterden türetir. Fark sonradan ortaya çıkar — mutabakat kırılmalarında, kimsenin açıklayamadığı destek taleplerinde ve denetimlerde.

Mühendislik bağlamında çift kayıt ne demek

Çift kayıtlı defter tutma beş yüzyıllıktır, ama bir bankacılık backend'inde bir muhasebe formalitesi değildir — veritabanının zorla uyguladığı bir değişmezdir. Her para hareketi, en az iki kayıttan oluşan bir işlemdir: bir hesap borçlandırılır, bir başkası alacaklandırılır ve kayıtların toplamı sıfırdır. Para asla bir UPDATE ifadesiyle yaratılmaz ya da yok edilmez; yalnızca hesaplar arasında hareket eder ve hareketin kendisi kayıttır.

Müşteri bakiyesi bu durumda bir projeksiyondur: o hesaba dokunan tüm defter kayıtlarının toplamı. Performans için önbelleğe alınır, evet — ama her zaman yeniden hesaplanabilir ve doğru olan yeniden hesaplamadır. Önbellek ile defter bir gün uyuşmazsa defter kazanır ve uyuşmazlığın kendisi, incelenmesi gereken bir şeyin sinyalidir.

Sıfır toplam değişmezi, hiçbir saklanan-bakiye tasarımının sunamayacağı bir özellik verir: sistemin tamamı kontrol edilebilir. Her hesaptaki her kaydı toplayın — müşteri cüzdanları, ücret gelirleri, sağlayıcı takas hesapları, geçici hesaplar — ve toplam sıfırdır. Para kaybettiren her hata, yarış durumu veya kısmi arıza bu denklemi bozar ve tespit edilebilir hale gelir, genellikle aynı gün.

Saklanan bakiyeler nasıl kayar

Bakiye sütunu tasarımının arıza biçimi dramatik değildir. Sıradan canlı ortam trafiğinin ürettiği yavaş bir kaymadır:

• Eşzamanlılık: iki para çekme işlemi aynı anda aynı bakiyeyi okur, ikisi de kontrolü geçer, ikisi de yazar. Defter olmadan bakiyenin ne olması gerektiğine dair hiçbir kayıt kalmaz.
• Yeniden denemeler ve kısmi arızalar: bir ödeme sağlayıcısı zaman aşımına uğrar, istemci yeniden dener ve alacak iki kez işlenir — ya da “bakiyeyi güncelle” ile “işlemi kaydet” arasındaki bir çökme, ikisini kalıcı olarak tutarsız bırakır.
• Manuel işlemler: bir destek mühendisi bir şikayeti doğrudan UPDATE ile çözer. Müşteri memnundur; ortaya çıkan paranın kaynağı yoktur ve hiçbir rapor onu asla açıklayamayacaktır.
• Ücretler ve yuvarlama: bir yerde hesaplanıp başka yerde uygulanan bir ücret, iki tarafta farklı yuvarlanan bir kur çevrimi — birikerek gerçek farklara dönüşen kuruş kesirleri.

Bir defterin size dayattığı kurallar — hepsi de iyi

Türetilen bakiyelere bağlanmak, çekirdeğin geri kalanına disiplin getirir. Bu kısıtlar ilk gün katı gelir; üçüncü yılda sistemin doğru kalmasının nedeni oldukları anlaşılır:

• En küçük birimlerde tamsayı tutarlar — kuruşlar, satoshiler, wei — asla kayan nokta değil. İkili kayan sayılar 0,10 değerini tam temsil edemez; toplamı sıfır olmak zorunda bir defter, neredeyse tutan sayılar üzerine kurulamaz.
• Değiştirilemez kayıtlar: işlenmiş bir kayıt asla düzenlenmez ya da silinmez. Hatalar, bankaların her zaman düzelttiği gibi düzeltilir — hem hatayı hem düzeltmeyi kayıtta bırakan bir ters kayıtla.
• İdempotens: her işlem bir anahtar taşır; böylece yeniden denenen bir istek yalnızca bir kez işlenir. Defter kopyaları görünür kılar; idempotens onları engeller.
• Atomiklik: borç, alacak ve iş durumu değişikliği ya birlikte işlenir ya da hiç işlenmez. Hiçbir kod yolu, bir defter işleminin dışında bakiye güncellemez — sessiz üzerine yazmalar yerine sıradan, kime ait olduğu belli kayıtlara dönüşen idari düzeltmeler dahil.

Mutabakat: dış dünyaya karşı kanıt

İç değişmez, sistemin kendi içinde tutarlı olduğunu kanıtlar. Mutabakat, gerçeklikle tutarlı olduğunu kanıtlar. Bir fintech çekirdeği dış taraflarla pozisyon tutar — bankacılık rayları, kart işlemcileri, blockchain ağları — ve her biri doğrunun kendi sürümünü tutar. Günlük mutabakat, her sağlayıcı ekstresini ve her zincir üstü pozisyonu defterdeki karşılık gelen hesaplarla karşılaştırır ve her farkın açıklanmasını zorunlu kılar: yoldaki bir takas, henüz işlenmemiş bir sağlayıcı ücreti ya da aynı gün bir geçici hesap kaydı ve bir sorumlu alan gerçek bir kırılma.

Mutabakat, mimarinin kendini amorti ettiği yerdir. Çift kayıtlı bir defterle bir kırılma sınırlı bir aramadır: ortaya çıktığı gün, dokunduğu hesaplar, ilgili kayıtlar. Saklanan bakiyelerle aynı inceleme, geçmişi olmayan bir sayıdan başlar — bakiye sütunlu sistemlerde mutabakatı yapılmamış farkların çözülmek yerine silinip gitmesinin nedeni budur.

Kripto varlıklar riski büyütür. Zincir üstü bir bakiye herkese açıktır: kontrol ettiğiniz cüzdanları, müşterilere gösterdiğiniz bakiyelerle herkes karşılaştırabilir. Zincirle her gün mutabakatı yapılan bir defter olmadan self-custody, şirket dışından birinin keşfetmesini bekleyen bir farktır.

Denetçiler ve düzenleyiciler gerçekte ne sorar

Er ya da geç, düzenlemeye tabi bir fintech aynı sorunun bir sürümüyle karşılaşır: müşteri bakiyelerinin doğru olduğunu kanıtlayın. Pratik yanıt bir kanıt zinciridir — her bakiye yalnızca eklemeye izin veren bir defterden türetilir; defterin toplamı sıfırdır; her dış pozisyonla günlük mutabakatı yapılır; ve değiştirilemez, hash zincirli bir denetim kaydı her hareketi kimin, hangi cihazdan, hangi onayla başlattığını kaydeder.

Saklanan bakiye tasarımı üzerine inşa eden ekipler bu soruları adli çalışmayla yanıtlar — uygulama günlüklerinden ve sağlayıcı dışa aktarımlarından geçmişi, olabilecek en kötü zamanda ve bir teslim tarihi baskısı altında yeniden kurarak. Defteri olan ekipler bir sorguyla yanıtlar. Denetim gereksinimi yaratmaz; yalnızca mimarinin onu baştan beri karşılayıp karşılamadığını ortaya çıkarır.

Herhangi bir çekirdek bankacılık platformuna uygulanacak test

Bir platformu değerlendiriyorsanız — ya da kendi kurduğunuzu gözden geçiriyorsanız — soruları sormak beş dakika sürer ve yanıtları taklit etmek zordur:

• Müşterinin ekranındaki sayı nereden geliyor? Yanıt bir defter projeksiyonu değil de bir bakiye sütunuysa, geri kalan her şey süslemedir.
• Defter kaydı oluşturmadan bir bakiye değiştirilebiliyor mu? Özellikle yönetim araçlarını ve destek iş akışlarını sorun — sessiz UPDATE'ler orada saklanır.
• Tutarlar uçtan uca, kripto tarafı dahil, en küçük birimlerde tamsayı mı?
• Bana dünün mutabakatını gösterin: her sağlayıcı, her zincir, açıklanmış her fark. Bunu gösteremeyen bir platform, bunu yapmıyordur.
• Hatalı bir kayıt nasıl düzeltiliyor? Tek iyi yanıt, bir kişiye atfedilmiş, bir onay akışının arkasındaki ters kayıttır.

Coreza nerede duruyor

Coreza bu tasarımın katı sürümü üzerine inşa edilmiştir: her bakiye — fiat ve kripto — çift kayıtlı bir defterden türetilir; tutarlar her yerde en küçük birimlerde tamsayıdır; işlenmiş kayıtlar değiştirilemez, düzeltmeler maker-checker onayının arkasında ters kayıtlarla yapılır; ve her kurulum, bağlı her sağlayıcıyla ve üzerinde çalıştığı her zincirle günlük mutabakat yapar. Denetim kaydı yalnızca eklemeye izin verir ve hash zincirlidir: her hareketin kimini, ne zamanını ve nereden yapıldığını kaydeder.

Bunların hiçbiri bir ürün demosunda görünmez ve bu makalenin amacı tam da bu: defter, bir çekirdek bankacılık platformunun ekranlara bakarak değerlendirilemeyecek parçasıdır. Bu çekirdeğin bir sürümü 2024'ten beri düzenlemeye tabi bir Avrupa fintech şirketinde gerçek müşterileri ve gerçek parayı işliyor — ve yukarıdaki beş soru, bizimki dahil her platforma sormanızı önerdiğimiz sorulardır.