Soru tarihçesi
Bu soru, sigorta sektöründeki eski sistem modernizasyonu zorunluluklarının, Web3 teknolojilerinin çelişkili talepleriyle birleşmesinden ortaya çıkmıştır. Sigortacılar, yıllık 20 milyon dolardan fazla ana çerçeve bakım maliyetlerini azaltma baskısıyla karşılaşırken, Solvency II düzenleyicileri şeffaf, değiştirilemez risk hesaplama metodolojileri talep ettiğinde, blockchain dağıtılmış güven için teorik bir çözüm olarak ortaya çıkmıştır. Ancak, blockchain'in sadece ekleme mimarisi ile GDPR'nin silme hakkı arasındaki temel gerginlik ve belirleyici akıllı sözleşmelerde kesin kayan nokta hesaplamalarının teknik imkansızlığı, bir İş Analisti'nin uzlaştırılması zor mimari kısıtlamalarla başa çıkma yeteneğini test eden bir gereksinimler mühendisliği kabusu yaratmaktadır.
Problem
Temel problem, üç değişmez kısıtlamanın çarpışmasında yatmaktadır: veri silme için düzenleyici zorunluluklar (GDPR Madde 17), veri kalıcılığı için düzenleyici zorunluluklar (Solvency II denetim izleri) ve kesinlik için matematiksel gereksinimler (GAAP sigorta rezervleri hesaplaması). Ayrıca, ana çerçeve'nin alt-milisaniye işlem kapasitesi, Hyperledger Fabric'in mutabakat gecikmesi ile çelişirken, CFO'nun maliyet azaltma hedefi, CRO'nun dağıtılmış sistemlere karşı riske yönelik durumu ile çelişmektedir. İş Analisti, blockchain'in doğru çözüm olup olmadığını ya da hibrit bir mimarinin kısıtlamaları herhangi bir uyumluluk veya finansal doğruluğu tehlikeye atmadan karşılayıp karşılamadığını doğrulamalıdır.
Çözüm
Çözüm, Hyperledger Fabric özel kanalları içinde off-chain özel veri koleksiyonları kullanarak bir "değiştirilebilir değiştirilemezlik" deseninin mimarisi gerektirir. Kişisel olarak tanımlanabilir bilgilerin (PII) PostgreSQL'de tutulduğu, kriptografik hash'lerin blockchain'e bağlı olduğu bir yapı, off-chain silme yoluyla GDPR uyumluluğu sağlarken, açık-kayda denetim bütünlüğünü korur. Kesinlik için, Java zincir kodunda BigDecimal aritmetik kütüphaneleri ile aktüerler tarafından belirlenen belirleyici yuvarlama kuralları uygulanarak, yerel kayan nokta sınırlamalarını aşmak gereklidir. Gecikmeye hassas hesaplamalar için bir yan ortam AS/400 emülatörü uygulayın ve blockchain defteri için yalnızca denetim günlüğü için Apache Kafka olay akışı ile entegre edin. Böylece, CFO'nun bulut geçişi, tüm geçiş yerine aşamalı COBOL mikro hizmetlerine parçalama yoluyla sağlanacaktır.
Birçok uluslu bir reasürans grubu, AB ve ABD yargı bölgelerinde, felaket risklerini toplama platformunu modernize etme ihtiyacı duydu. Eski IBM z15 ana çerçevesi, 38 haneli kesinlik ile GAAP uyumluluğu için mülk maruziyetini COBOL programları kullanarak hesaplıyordu ve saniyede 10,000 konum güncellemesi ile 12ms yanıt süreleri sağlıyordu. Solvency II direktifi, belirli risklerin rezerv hesaplamalarını nasıl etkilediğine dair tam izlenebilirlik talep ederken, GDPR ekibi, Avrupa polis sahibi adreslerinin talep üzerine silinebilir olması gerektiğini savunuyordu. CTO, endüstri standartı denetim izleri oluşturmak için üç diğer sigortacılarla paylaşılan bir Hyperledger Fabric ağı önerdi.
Problem tanımı
İlk teknik keşif, Hyperledger Fabric'in varsayılan LevelDB durum veritabanının, yasal rezervler için gerekli olan 38 haneli ondalık hassasiyeti saklayamayacağını ortaya çıkardı. Bu durum, $999,999,999,999,999.99'un $1,000,000,000,000,000.00'a yuvarlamasını sağlayarak GAAP uyumluluğuna aykırıydı. Ayrıca, mutabakat mekanizması, gerçek zamanlı sigorta kararları için kabul edilemez olan 2-3 saniyelik bir gecikme getiriyordu. Gizlilik ikilemi oldukça belirgindi: poliçe sahiplerinin verilerini zincir üzerinde saklamak GDPR'yi ihlal ederken, bu verilerin kaldırılması, belirli riskleri sermaye rezervlerine bağlayan Solvency II denetim izini ortadan kaldırıyordu.
Çözüm 1: Tam zincir içi geçiş
Tüm mantığı Hyperledger Fabric akıllı sözleşmelerine taşımak ve zengin sorgular için CouchDB kullanmak. Bu, katılımcı üyeler arasında değiştirilemez tarihçe ve paylaşılan defter şeffaflığı aracılığıyla tam Solvency II uyumluluğu sağlayacaktır.
Artıları: Maksimum denetlenebilirlik, ana çerçeve lisans maliyetlerini ortadan kaldırır, konsorsiyum yönetim gereksinimlerini karşılar.
Eksileri: GDPR'yi ihlal eder (blockchain verileri silinemez), kayan nokta hesaplamalarında matematiksel hata, sigorta için kabul edilemez 3 saniyelik gecikme, performans için gerekli IBM LinuxONE sunucular nedeniyle %40 maliyet aşımı.
Çözüm 2: Hash-bağlı mimari
Tüm kişisel verileri off-chain Oracle veritabanlarında saklayarak yalnızca zincir üzerinde SHA-256 hash'leri bulundurmak. Akıllı sözleşmeler, hassas özellikleri saklamadan veri bütünlüğünü doğrular.
Artıları: GDPR uyumluluğu sağlanır (off-chain silinirse, hash değerini kaybeder), hash doğrulaması aracılığıyla Solvency II denetim izini sürdürür, blockchain depolama maliyetlerini %90 oranında azaltır.
Eksileri: İşlem doğrulama sırasında karmaşık iki aşamalı yükümlülük sorunları yaratır, Oracle ODBC bağlantıları her sorguda 200ms gecikme getirir, hash çakışmaları (teorik) aktüeryal risk yaratır, hash doğrulama anahtarları için karmaşık PKI yönetimi gerektirir.
Çözüm 3: Hibrit olay kaynağı ve ana çerçeve tutma
Kesin hesaplamalar ve yüksek hızlı işleme için COBOL ana çerçevesini koruyun, ancak hesaplama sonuçlarını yalnızca denetim izi amaçları için Hyperledger Fabric'e yayımlayın. Kafka akışlarını kullanarak, blockchain'e alma öncesinde GDPR'ye hassas alanları filtreleyin ve takma adlandırın.
Artıları: GAAP kesinliği ve alt-milisaniye performansı korur, ön işleme anonimleştirme yoluyla GDPR'yi karşılar, temel sistemlerde kesinti olmaksızın Solvency II izlenebilirliği sağlar, ana çerçeve iş yükü azaltılarak CFO'nun %30 maliyet hedefini gerçekleştirir (yalnızca denetim günlüklerinin boşaltılması).
Eksileri: Mimaride karmaşıklığı artırır, iki sistemin bakımını gerektirir (teknik borç), işlemlerin ara aşamalarda başarısız olursa MQ ve blockchain arasında tutarsızlık sorunları olabilir.
Seçilen çözüm ve nedeni
Çözüm 3, tüm sert kısıtlamaları aynı anda karşılayabilen tek yaklaşım olduğundan seçilmiştir. CRO, bir kanıt-konseptinin GDPR "silme hakkı"nın Kafka akış ön işleyicisinde ilişkilendirme anahtarını kaldırarak uygulanabileceğini gösterdiğinde karmaşıklığı kabul etmiştir; bu, blockchain kaydını etkili bir şekilde yetimleştirirken denetim zincirini kopartmamaktadır (hash mevcut ancak tanımlanabilir bir bireyle bağlantısı yoktur). CFO, ana çerçeve MIPS kullanımının denetim depolamasını daha ucuz AWS-barındırılan blockchain düğümlerine boşaltarak %35 düştüğü için onay vermiştir. Aktüeryal ekip, blockchain'in Solvency II tarafından talep edilen düzenleyici şeffaflığı sağlarken, rezerv hesaplamaları için COBOL kesinliğinin korunmuş olduğunu doğrulamıştır.
Sonuç
Hibrit mimari, ilk ayda 50,000 poliçeyi sıfır hassasiyet hatası ile işlemiştir. Almanya'dan bir poliçe sahibinden gelen bir GDPR silme talebi geldiğinde, ekip, Kafka konusunun Şema Kaydı'ndan ilişkilendirme anahtarını kaldırmış, böylece blockchain hash'ini 4 saat içinde geri alınamaz hale getirmiştir—düzenleyicileri tatmin etmiştir. Solvency II denetimi, rezerv çıktılarının NatCat model girdilerine kadar tamamen izlenebilirliğini göstermiştir ve düzenleyici incelemeden hiçbir bulgu olmadan geçmiştir. Ancak, proje, CFO'nun %30 tasarruf hedefinin, hibrit entegrasyonu yönetmek için artan DevOps maliyetleri tarafından kısmen dengelediğini ortaya çıkarmış ve %18 net tasarrufla, liderlik için kabul edilebilir fakat yeniden gözden geçirilen ROI projeksiyonlarını gerektirmiştir.
Bir düzenleyici, aynı işlem için hem değiştirilemez denetim izleri hem de veri silme gereksinimi getirdiğinde "Blockhash ve Unutma Hakkı" paradoksunu nasıl ele alırsınız?
Aday, mutlak değiştirilemezlik ve GDPR uyumluluğunun teknik olarak aynı katmanda uyumsuz olduğunu kabul etmelidir. Çözüm, blockchain'in şifrelenmiş verilerin bir hashini sakladığı, deşifre anahtarının ise ayrı bir HSM (Donanım Güvenlik Modülü) içinde tutulduğu kamuflaj hash'leri veya kriptografik taahhütler uygulamayı içermektedir. GDPR çerçevesinde, anahtarı yok ederek veriyi "silmek" mümkündür, bu da blockchain girişini değil, veriyi kriptografik olarak erişilemez kılmaktadır, yasal silme gereksinimlerini karşılamaktadır. İş Analistleri için, bu gereksinimlerde iki farklı veri sınıflandırmasını belgelemek gerekecektir: Değiştirilemez Denetim Meta Verisi (zincir üzerinde) ve Değiştirilebilir Kişisel Özellikler (off-chain veya geri alınabilir anahtarlarla şifrelenmiş).
Neden standart IEEE 754 kayan nokta aritmetiği blockchain akıllı sözleşmelerinde finansal hesaplamalar için kullanılamaz ve kesinliği sağlamak için hangi gereksinimler belirtilmelidir?
Standart kayan nokta işlemleri, farklı CPU mimarileri arasında (örn. Intel ile ARM arasında) kayıt boyutu farklılıkları nedeniyle hafifçe farklı sonuçlar üretmektedir. Ancak blockchain akıllı sözleşmeleri, tüm doğrulayıcı düğümlerde birbirinin aynı şekilde yürütülmelidir ki mutabakata ulaşılabilsin. Bu tutarsızlık, işlem reddine neden olur. Ayrıca, kayan nokta, sigorta rezervleri için kabul edilemez olan yuvarlama hataları yaratmaktadır. İş Analisti, sabit nokta aritmetiği veya ondalık veri türleri (örneğin, Java'da BigDecimal veya Solidity'de açık ondalık yerleri olan int256) ile belgelenmiş yuvarlama modlarını (HALF_UP, BANKERS_ROUNDING) belirtmelidir. Gereksinimler şunları içermelidir: (1) Açık kesinlik seviyeleri (örn. 18 ondalık basamak), (2) mutabakat sistemleri için onaylanmış belirleyici matematik kütüphaneleri, (3) taşma/azalma koruma mekanizmaları ve (4) paralel çalışmalarda blockchain çıktılarının COBOL ana çerçeve standartlarıyla karşılaştırılması için uzlaştırma protokolleri.
Bir ana çerçeveden dağıtık deftere geçerken, mutabakat mekanizmalarının doğası gereği ağ gecikmeleri getirdiği göz önünde bulundurulduğunda, gecikme için işlevsel olmayan gereksinimleri nasıl doğrularsınız?
Adaylar genellikle kodu optimize etmenin, blockchain sistemlerinde ana çerçeve düzeyindeki gecikmelere ulaşılmasını sağlayacağını varsaymakta ve dağıtık mutabakatın doğasını göz ardı etmektedirler (hatta PBFT veya Raft ağ atlamaları gerektirmektedir). İş Analisti, "gecikme"yi ayrı bileşenlere ayırmalıdır: Okuma Gecikmesi (durumu sorgulama), Yazma Gecikmesi (sıralama/doğrulama) ve Mutabakat Nihaiyeti (geri alınamazlık). Gereksinimler, gerçek zamanlı sigorta kararlarının (50ms'den az ihtiyaç duyan) ana çerçeve veya bellek önbellekleri (Redis) üzerinde kalmasını belirtmeli ve gün sonu rezerv hesaplamalarının (2-3 saniyeye katlanabilen) blockchain kullanmasını sağlamalıdır. Kaçırılan önemli gereksinim, Sonradan Tutarlılık toleransıdır—blockchain denetim izinin, operasyonel sistemden 5 dakikaya kadar gecikmesine izin vererek (bu, Solvency II raporlaması için kabul edilebilir) fakat asla bu sınırı aşmaması gerektiğini belirtilmelidir ve süreç sınırlarının aşılması durumunda Prometheus izleme uyarıları gerekmektedir.