Bir blok zincirden düşerse bakiyenize ne olur?

Zincir bazen yakın geçmişini değiştirir. Ağ, yarışan iki dal arasından birini gerçek tarih olarak seçer ve kaybeden daldaki bloklar atılır; bu olayın adı reorg, açık hâliyle zincirin yeniden organizasyonu. Yalnızca atılan blokta yaşayan bir ödeme, o andan sonra zincirde değildir.

Satıcı için asıl soru mutabakat mekaniği değil. Teslim ettiğiniz siparişin sonradan ödenmemiş çıkıp çıkamayacağı. Paymos'ta çıkmaz: onaylanmış ödemenin alacağı satıcının bakiyesinde kalır.

Onayın ne kanıtladığı ve kaç onay bekleneceği burada anlatılmıyor. İlkini blokzincir onayı ve kesinlik, ikincisini tutara göre onay politikası üstleniyor. Bu yazının tek konusu şu: blok atılırsa parayı kim kaybeder ve sipariş sisteminiz bununla ne yapmalı?

Devamı sırayla ilerliyor. Paranın nerede olduğu, eksik tutarın hangi hesaba yazıldığı, kaydın neden silinmediği, bloğun gittiğine ne zaman karar verildiği ve akışınızın gerçekten neye ihtiyacı olduğu.

Reorg bir ödemeye ne yapar?

Ortadan kalkan kayıttır, para değil.

Kafa karıştıran ayrım tam burada. Kimseye iade yapılmadı, hiçbir işlem geri çevrilmedi. Ödeyenin cüzdanı bir işlem imzaladı, işlem bir bloğa girdi, sonra ağ o bloğu içermeyen bir tarihi seçti. Zincirin gözünden bakınca ödeme hiç olmamıştır; paralar da kazanan dalın gösterdiği yerde durur, ki bu genellikle hâlâ ödeyenin cüzdanıdır.

Çoğu zaman iş kendiliğinden kapanır. Aynı işlem bir iki blok içinde yeniden alınır — işlem geçerlidir, ağın onu reddetmek için bir gerekçesi yoktur. Tehlikeli senaryo dar: ödeme düştü, altyapınız size onu çoktan onaylanmış diye bildirmişti ve siz o bilgiyle hareket ettiniz.

Paymos'un onayladığı bir ödeme kaybolabilir mi?

Onay kaybolabilir, alacak kaybolmaz.

Paymos protokol kesinliğinden önce onaylar. Onay derinliği ağa ve ödeme tutarına göre seçilir; her ağda mutlak kesinliği beklemek bazı ödemeleri kullanılamayacak kadar yavaşlatırdı. Ödeme sayfasının hızı için bilerek verilmiş bir tavizdir bu — ve karşılığında, onaylanmış bir ödemenin bloğunun sonradan atılmış çıkması nadiren de olsa mümkündür.

Tavizin bedeli satıcıya yıkılmıyor. Blok gittiğinde satıcının bakiyesi olduğu gibi kalır; eksik tutarı platform kendi hesaplarına reorg zararı olarak yazar. Kural, defter kodunda kaydın hemen yanında duruyor: satıcıya dokunulmaz, alacağı ayakta kalmıştır, ne geri alınır ne ikiye katlanır.

Eksik tutarı kim karşılıyor?

Platform karşılıyor ve bunun ne demek olduğunu net söylemekte fayda var.

Derinlik kararı işlemcinin kararıdır: bu ağda, bu tutarda, bu derinlikte onayla. Karar, ödeyene hızlı bir ödeme deneyimi vermek için verilir. Yanlış çıktığında paralar gerçekten orada değildir ve açığı birinin bakiyesi kapatmak zorundadır. Bunu satıcıya yıkmak, satıcının sorumluluğunu hiç vermediği ve göremediği bir risk kararına bağlamak olurdu.

Zarar bu yüzden platforma yazılıyor. Bir doğa kanunu değil, bir politika bu — ve aynı soruyu her işlemciye doğrudan sormak yerinde olur: erken onaylıyorsanız ve zincir sizi yalanlarsa kimin bakiyesi oynar? Soruyu daha önce hiç düşünmemiş bir işlemcinin hazır cevabı olmaz; düşünmüş olan, hesabın adını söyler.

Kayıt neden silinmiyor?

Silmek, çift alacaklandırma hatalarının doğduğu yerdir.

Blok atıldığında ilk içgüdü kaydı kaldırmaktır: ödeme olmadı, satır gitsin. Burada tam tersi yapılıyor — transferler yapışkandır. Reorg yolu transferi hayalet (phantom) olarak işaretler ve hiçbir zaman silmez.

Sebep, işlem geri döndüğünde ortaya çıkar. Orijinal kayıt silinmiş olsaydı, zincire yeniden dahil edilme yepyeni bir ödeme gibi görünürdü ve satıcı tek bir transfer için ikinci kez alacaklandırılırdı. Aynı transfer kimliğinin korunması, dönüşün başka bir ödeme değil aynı ödemenin dönüşü olarak tanınmasını sağlar. Tek bir ödeme için ikinci bir kayıt açmak bu yüzden kesin olarak yasaktır.

Bloğun gerçekten gittiğine ne zaman karar veriliyor?

Yalnızca protokol kesinliği söylediğinde.

Zincirler uç bloklarını rutin olarak değiştirir. Bir düğüm önce bir bloğu baş olarak görür, bir saniye sonra başkasını; ortada ne bir arıza vardır ne de kaybolan bir işlem. Her uç değişimini reorg saymak sürekli hayalet ödeme işaretlemek demek olurdu ve o uyarılar bir hafta içinde hiçbir işe yaramaz hâle gelirdi.

Hayalet işareti bu yüzden tek bir koşula bağlı. Kesinlik, bloğun kesinleşmiş zincirde bulunmadığını doğrulamalı — protokolün kendi kurallarına göre tarihin artık değişmediği noktanın ötesinde.

Reorg o yüksekliğin altına inerse hat mutabakat kurmaya kalkmaz. O ağın imlecini durdurur ve bekler, çünkü bir protokol ihlali otomatik kapatılacak bir vaka değildir.

Olay size nasıl bildiriliyor?

Ödeme kanallarında bir webhook ile. payment_channel.deposit.reorged, üç yatırma olayından biridir; diğer ikisi confirming ve confirmed ve üçü de aynı aboneliğe düşer.

Pratikte bunu muhasebe olayı değil operasyonel uyarı olarak ele almak doğru olur. Bakiyeniz değişmediği için defterinizin yapacağı bir şey yok. Olayın söylediği şey daha dar: belirli bir sipariş, o andan sonra ortadan kalkmış bir kanıta dayanarak kapatıldı.

Bilginin değeri de siparişin türüne bağlı. Hâlâ durdurabileceğiniz fiziksel bir sevkiyat için işe yarar; bir indirme bağlantısı için neredeyse hiç yaramaz.

İşlem zincire geri dönerse ne oluyor?

Zarar geri alınır ve satıcı bu yönde de yerinden oynamaz.

Yeniden dahil edilen transfer kendi kimliğiyle döner. Ödeme kanallarında bunun görünen hâli şu: aynı yatırma yeniden confirming durumuna geçer ve onaya kadar gidebilir.

Tersine çevrilen kayıt, zararı üstlenen hesapların üzerindedir. Paralar geri geldiği için platformun yazdığı reorg zararı sıfırlanır ve komisyon yeniden tanınır. Satıcının bakiyesi burada da hareket etmez, çünkü baştan hiç hareket etmemişti.

Hedef tek cümlede özetlenebilir. Bir kez alacaklandırılmak ve bir hayaletin, bir dönüşün arasından geçip bir kez alacaklandırılmış kalmak — tasarımın tamamı bunun için.

Sipariş sisteminiz ne yapmalı?

Sandığınızdan azını; tuzak, fazlasını yapmakta.

Kripto ödemenin sizin tarafınızdaki hâli zaten ihtiyacı olan biçimde: sipariş ödenmemiştir, sonra onaylanır, sonra karşılanır. Reorg bu akışa dördüncü bir durum eklemez, çünkü bakiyeniz değişmez ve mutabık kılınacak bir şey kalmaz.

Bir şey ekleyebilir: onay ile sevkiyat arasında kısa bir pencere. Gerekçesi de dar — malınız pahalıysa ve fiziksel olarak sevk ediliyorsa, uyarının düşeceği bir yer gerekir.

Malınız ne pahalı ne fiziksel ise doğru mühendislik cevabı hiçbir şey yapmamak. İndirme satan bir akışa reorg işleyişi yazmak kendini hiçbir zaman amorti etmez, üstelik koruduğu zarar zaten sizin zararınız değil.

Gerçek bir reorg'u beklemeden nasıl denenir?

Simüle edin. Sandbox bir kanal yatırmasını istediğiniz aşamaya sürükler ve reorged, kabul ettiği üç değerden biridir; diğerleri confirming ve confirmed.

Bunu bir kez yapmaya değer ve gerekçesinin reorg'la pek ilgisi yok: webhook işleyicinizin beklemediği bir olaydan sağ çıkıp çıkmadığını öğrenmenin en ucuz yolu bu. Entegrasyonların çoğu mutlu yol üzerine yazılır ve ilk sıra dışı olayla üretimde karşılaşır.

Bu olayı ise bir salı öğleden sonra, ortada hiçbir şey yokken karşılayabilirsiniz. Kart tarzı itirazın neden hiç olmadığı ayrı bir konu; reorg, ödemenin geri çevrilmesi değil, kaydın kaybolmasıdır.