@kodkedisi
· 4 gün önce
ingilizce kaynaklarda reorg diye geçen, bir blockchain ağında en son eklenen blokların daha uzun ya da ağın kabul ettiği başka bir dalla değiştirilmesi durumu. iki doğrulayıcı aynı anda farklı blok üretebilir, ağ kısa bir süre iki versiyonu birden görür, sonra biri kazanır. kaybeden daldaki bloklar ve içlerindeki işlemler, en azından o haliyle, hiç olmamış sayılır.
kullanıcı açısından çoğu zaman görünmez, ama zincirden veri okuyup kendi veritabanına yazan herkes için baş ağrısıdır. akıllı kontrat olaylarını dinleyen bir servis bir ödemeyi kaydeder, birkaç saniye sonra o blok zincirden düşer ve raporda aslında gerçekleşmemiş bir ödeme kalır. ağdan ağa reorg sıklığı ve derinliği değişir, kesinleşme yani finality kavramı da tam bu riskin ne zaman sıfırlandığını anlatır.
indeksleme yapan ekiplerin kullandığı çözümler benzer. her kaydın yanında blok numarası ve blok hash'i tutulur. belli sayıda onay gelmeden veri kesin tabloya taşınmaz ya da "kesinleşmemiş" diye işaretlenir. servis her yeni blokta önceki blokların hash'ini kontrol eder, uyuşmazlık görürse o noktaya kadar geri alıp yeniden işler. son işlenen blok numarasını ayrı bir tabloda tutmak hem reorg dönüşünde hem servis kapanıp açıldığında eksik blok bırakmamayı sağlar.
sık yapılan hata en son bloğu kesin kabul eden bir arayüz. bakiye ya da sipariş durumunu kullanıcıya hemen göstermek istiyorsan bunu "onay bekliyor" diye ayrı bir durumla göstermek, sonradan geri almaktan çok daha az sorun çıkarır.
kullanıcı açısından çoğu zaman görünmez, ama zincirden veri okuyup kendi veritabanına yazan herkes için baş ağrısıdır. akıllı kontrat olaylarını dinleyen bir servis bir ödemeyi kaydeder, birkaç saniye sonra o blok zincirden düşer ve raporda aslında gerçekleşmemiş bir ödeme kalır. ağdan ağa reorg sıklığı ve derinliği değişir, kesinleşme yani finality kavramı da tam bu riskin ne zaman sıfırlandığını anlatır.
indeksleme yapan ekiplerin kullandığı çözümler benzer. her kaydın yanında blok numarası ve blok hash'i tutulur. belli sayıda onay gelmeden veri kesin tabloya taşınmaz ya da "kesinleşmemiş" diye işaretlenir. servis her yeni blokta önceki blokların hash'ini kontrol eder, uyuşmazlık görürse o noktaya kadar geri alıp yeniden işler. son işlenen blok numarasını ayrı bir tabloda tutmak hem reorg dönüşünde hem servis kapanıp açıldığında eksik blok bırakmamayı sağlar.
sık yapılan hata en son bloğu kesin kabul eden bir arayüz. bakiye ya da sipariş durumunu kullanıcıya hemen göstermek istiyorsan bunu "onay bekliyor" diye ayrı bir durumla göstermek, sonradan geri almaktan çok daha az sorun çıkarır.