Ödeme onayı evrensel bir blok sayısı değil, güven eşiğidir
Bir blokzincir ödemesi bütün ağlarda aynı anda operasyonel olarak tamamlanmaz. İşlem önce görünür, ardından bir bloğa alınabilir, daha güçlü onay kanıtları kazanabilir, ağın kendi kesinleşme düzeyine ulaşabilir ve işletmenin kabul politikasını karşılayabilir.
Bu aşamalar farklı soruları yanıtlar. Tespit, aday işlemin görülüp görülmediğine bakar. Onay, işlemin mevcut zincir konumunun ne kadar güçlü desteklendiğini gösterir. Kesinleşme, bu durumun geri alınmasının ne kadar istisnai veya maliyetli olacağını ifade eder. İşletme kabulü ise teslimat, hesap kredisi veya başka bir eylem için kanıtın yeterli olup olmadığına karar verir.
Bu analiz, ağ güveniyle ticari karar arasındaki sınırı ele alır. Blockchain Payments işlemin ticari ödemeye dönüşümünü; Blockchain Consensus ise ortak geçmişin nasıl kabul edildiğini açıklar.
Görünürlük, bloğa dahil edilme, onay, kesinleşme ve kabul farklı durumlardır
Cüzdan, blok gezgini, düğüm, ödeme ağ geçidi ve işletme paneli «onaylandı» sözcüğünü farklı güven düzeyleri için kullanabilir. Sağlam sistem, tek bir arayüz etiketine güvenmek yerine kendi durumlarını açıkça tanımlar.
- Yayın: Cüzdan imzalı işlemi göndermiştir; ağın kabulü veya yayılımı henüz kesin değildir.
- Tespit: Bir veya daha fazla gözlemci işlemi görmüştür; değiştirilme, düşme ve gecikme hâlâ mümkündür.
- Dahil edilme: İşlem önerilen veya kabul edilen bir blokta görünür; yakın geçmiş yeniden düzenlenebilir.
- Onay: Ağ, blok derinliği, doğrulayıcı oyu veya commitment düzeyi gibi ek kanıtlar sağlamıştır.
- Kesinleşme: Geri dönüş ağın güvenlik varsayımları altında olağanüstü bir fikir birliği hatası veya ekonomik saldırı gerektirir.
- İşletme kabulü: Tutar, varlık, ağ, zaman, sipariş, risk ve teslimat politikası değerlendirilmiştir.
Müşteri işlemi zincirde gördüğünü doğru biçimde söyleyebilir; işletme de ödemeyi beklemede tutmakta haklı olabilir. İkisi farklı durum katmanlarını anlatır, zorunlu olarak çelişmez.
Bu bölümün kaynakları: OxaPay
Onaylar esas olarak kararsız ve rakip işlem geçmişlerine karşı korur
Düğümler bazen en güncel geçerli geçmiş konusunda kısa süreli anlaşmazlık yaşayabilir. Neredeyse aynı anda iki blok önerildiğinde, çatallanma seçimi ve kesinleşme kuralları hangi dalın kanonik olacağını belirler.
Yeniden düzenleme, yakın geçmişteki bir dalın başka bir dalla değiştirilmesidir. Bir işlem farklı bloğa taşınabilir, mempool'a dönebilir veya çatışan harcama kazanırsa kabul edilmiş geçmişten çıkabilir. Onay derinliği ve kesinleşme sinyalleri bu riski azaltır.
Bitcoin'de birikmiş iş kanıtı geçmişi değiştirmenin maliyetini yükseltir. Bitcoin teknik makalesi, dürüst zincir büyüdükçe saldırganın yetişme olasılığının azaldığını açıklar; buna karşın her ödeme için sabit bir onay sayısı önermez. Mempool kayıtları yereldir ve kalıcı değildir; bayat bloklardaki işlemler geri dönebilir.
Bu bölümün kaynakları: Bitcoin Whitepaper · Bitcoin Developer Guide
Ağlar güven ve kesinleşmeyi kökten farklı mekanizmalarla üretir
Kesinleşme tek bir algoritmanın adı değildir; protokolün kendi güven modeli altında sunabildiği en güçlü geri döndürülemezlik güvencesidir. İşletme kuralına eşlemeden önce bu güvencenin kaynağını bilmek gerekir.
- Olasılıksal kesinleşme: Kanonik geçmiş ilerledikçe işlemi geri almak daha düşük olasılıklı ve daha pahalı olur; mutlak tek an yoktur.
- Oy veya kontrol noktası kesinleşmesi: Gerekli doğrulayıcı çoğunluğu belirli checkpoint'leri kesinleştirir; bunları geri almak ciddi hata veya ekonomik kayıp gerektirir.
- Katmanlı kesinleşme: Hızlı yerel yanıt ve daha güçlü ana zincir mutabakatı farklı aşamalarda oluşur; sıralayıcı, toplu veri yayımı ve kanıtlar önem taşır.
Ethereum zincir başının seçiminden checkpoint kesinleşmesini ayırır. Gasper'de payın üçte ikisi tarafından desteklenen bağlantılar kontrol noktalarının gerekçelendirilmesi ve kesinleştirilmesinde kullanılır. Head, Safe ve Finalized eşanlamlı değildir. Ekonomik kesinleşme yalnızca dahil edilmeden daha güçlüdür ama banka veya hukuki iade güvencesi değildir.
Bu bölümün kaynakları: Ethereum.org
Çok zincirli ödeme sistemleri farklı güven göstergelerini çevirmelidir
Her ağ kendi güven terimlerini ve veri yapılarını kullanır. Ortak işletme durumları yararlıdır; ancak zincir adaptörü bu durumları doğuran yerel protokol kanıtını saklamalıdır.
| Ağ | Erken sinyal | Daha güçlü sinyal | Operasyonel yorum |
|---|---|---|---|
| Bitcoin | Mempool görünürlüğü veya ilk blok | Artan onay derinliği | Olasılıksal güven, ödeme riskine göre ölçeklenmelidir. |
| Ethereum | Yeni zincir başı veya dahil edilme | Safe ve Finalized checkpoint'leri | Finalized, yeni bloğa dahil edilmeden daha güçlü ekonomik güven sağlar. |
| Solana | Processed | Confirmed ve Finalized | Processed hızlıdır ama çatallanmada düşebilir. |
| TON | Bekleyen veya onaylı işlem izi | Masterchain'e bağlı kesinleşme | Asenkron mesajlar ve bütün işlem izinin sonucu izlenmelidir. |
Solana belgeleri Processed, Confirmed ve Finalized ayrımını yapar. TON belgeleri asenkron mesaj izlerini ve masterchain referansını açıklar. Normalleştirilmiş etiket kullanılsa bile gerçek ağ kanıtı korunmalıdır.
Bu bölümün kaynakları: Solana Docs · TON Docs
Doğru onay eşiğini işletmenin karşılaşabileceği kayıp belirler
Her ödeme için mümkün olan en yüksek kesinleşmeye ulaşmak gerekmez; sonraki işlem için yeterli güven gerekir. Daha fazla beklemek ağ riskini azaltabilir ama ödeme dönüşümünü, aktivasyon hızını ve müşteri güvenini olumsuz etkileyebilir.
- Ödeme tutarı: Büyük tutarlar genellikle daha güçlü kanıt ve temkinli istisna yönetimi gerektirir.
- Geri alınabilirlik: İptal edilebilir erişim ile geri alınamayan dijital ürün veya gönderilmiş mal aynı riski taşımaz.
- Ağ kanıtı: Derinlik, oylar, ağın ilerlemesi ve yeniden düzenleme işaretleri zincire göre değerlendirilmelidir.
- Aciliyet: Perakende ödeme, anında erişim, B2B mutabakat ve hazine transferlerinde gecikme toleransı farklıdır.
- İstisnalar: Eksik tutar, yanlış ağ, zaman aşımı ve tekrarlı ödeme kesinleşmeden ayrı kontrol edilir.
«Altı onay» Bitcoin için tarihsel bir güven geleneğidir; her ağın her ödemesine uygulanacak kural değildir. Düşük değerli geri alınabilir kredi ile yüksek değerli geri dönülmez teslimat aynı eşiğe ihtiyaç duymaz.
Bu bölümün kaynakları: OxaPay
Mempool tespiti müşteriyi bilgilendirir, ancak mutabakat oluşturmaz
Bloğa alınmadan önce «ödeme tespit edildi» göstermek kullanıcıya hızlı geri bildirim verir. Bu erken işaretten doğrudan teslimat başlatmak ise gereksiz risk yaratır.
Mempool, bütün düğümlerin paylaştığı tek küresel bekleme odası değildir. Düğümlerin bağlantıları, kabul politikaları ve yerel görünümleri farklıdır. Düşük ücretli işlem gecikebilir, bazı havuzlardan silinebilir veya çakışan işlemle değiştirilebilir.
Daha yüksek ücret hızlı dahil edilme ihtimalini artırabilir; sipariş eşleşmesini veya kesinleşmeyi ispatlamaz. OxaPay'in mempool ve işlem gecikmeleri analizleri bu ayrımı inceler.
Onay motoru protokol kanıtını denetlenebilir iş kararına dönüştürür
Üretim sistemi tek bir blok gezgini etiketine bakıp sipariş tamamlamamalıdır. Güvenilir kanıt toplamalı, beklenen ödemeyle eşleşmeyi sınamalı, işletme politikasını uygulamalı ve durum değişikliğinin gerekçesini kaydetmelidir.
- Gözlem: İşlem, blok, commitment ve ağ sağlığı verilerini kaynak ve zaman damgasıyla toplayın.
- Zincir yorumu: Processed, Included, Safe, Finalized ve blok derinliğini farklılıklarını koruyarak ortak güven kanıtına çevirin.
- Ödeme doğrulama: Varlık, ağ, tutar, hedef adres, sipariş ve süreyi kontrol edin; kesinleşmiş işlem hâlâ yanlış ödeme olabilir.
- Politika değerlendirmesi: Tutar, geri alınabilirlik, ağ sağlığı ve istisnalara uygun eşik belirleyin.
- Kontrollü geçiş: Denetim kaydıyla tek ve idempotent durum geçişi gerçekleştirin; yinelenen sorgu veya webhook çift teslimat oluşturmasın.
Real-Time Monitoring çoklu gözlem kaynakları ve kaçırılan olayların kurtarılmasını ele alır. Ödeme durum makinesi başka bir derin tasarım konusudur. Burada odak, bu iki katman arasındaki güven kararıdır.
Bu bölümün kaynakları: OxaPay
İkinci katman ödemeleri hızlı yerel onay ve daha yavaş ana zincir kesinleşmesi sunabilir
Rollup işlemi sıralayıcıdan anında yanıt alabilir, daha sonra bir batch içinde yayımlanabilir ve en sonunda ana zincirin mutabakat güvencesini kazanabilir. Her aşamanın kendi güven varsayımları vardır.
Optimism, Unsafe, Safe ve Finalized aşamalarını belgeler: Unsafe işlenmiş fakat L1'e yazılmamıştır; Safe, L1'e yazılmış olsa da L1 yeniden düzenlemesinden etkilenebilir; Finalized, kesinleşmiş L1 geçmişine dayanır.
Arbitrum da sıralayıcının hızlı yumuşak kesinleşmesini, veriler ana zincire yazılıp kesinleştikten sonraki güçlü güvenceyle ayırır. Hızlı yanıt kullanıcı geri bildirimi için yeterli olabilir; yüksek tutarlı işlemler batch yayımı, L1 kesinleşmesi, kanıt veya alanlar arası doğrulama gerektirebilir.
Bu bölümün kaynakları: Optimism Docs · Arbitrum Docs
Aynı işlem durumu farklı işletmelerde farklı eylemleri haklı çıkarabilir
- Düşük tutarlı hesap kredisi: Tespiti anında gösterin, belirlenen eşikte geçici kredi verin ve güçlü kesinleşmeye kadar çekimi sınırlayın.
- Dijital ürün: Geri alınamayan indirme veya lisans tesliminden önce daha güçlü onay isteyin.
- Yüksek tutarlı B2B fatura: Kesinleşme, doğru fatura eşleşmesi, manuel kanıt incelemesi ve hazine kontrolü birlikte gerekir.
- Fiziksel sipariş: Tespit sonrasında paket hazırlığı başlayabilir, sevkiyat gereken güven düzeyini beklemelidir.
- Geç veya eksik ödeme: Kesinleşmiş bir işlem bile ek ödeme, iade, yeni fiyatlandırma ya da manuel inceleme gerektirebilir.
Net durum iletişimi gecikme algısını ve destek yükünü azaltır; erken tespit, geri alınamaz tamamlanma gibi sunulmamalıdır.
Bu bölümün kaynakları: OxaPay
OxaPay ağ ilerlemesini işletme operasyonlarına bağlamak için ödeme durumları sağlar
Her zincire ayrı adaptör, onay kuralı, eşleştirme motoru ve bildirim sistemi geliştirmek karmaşıktır. OxaPay yapılandırılmış ödeme talepleri oluşturmaya ve durum güncellemelerini almaya yönelik arayüzler sunar.
Generate Invoice API tutar, para birimi, geçerlilik süresi, sipariş kimliği, eksik ödeme toleransı, karışık ödeme seçeneği ve callback URL içerir. Bu alanlar, zincir onayının kendi başına bilmediği ticari bağlamı tanımlar.
Webhook belgeleri erken Paying güncellemesiyle sonraki Paid durumunu ayırır; HMAC doğrulamasını ve tekrar denemeleri açıklar. İşletme olayları kimlik doğrulayarak, kaydedip idempotent biçimde işlemeli ve ancak güvenli işlemden sonra uygun yanıt vermelidir.
- Tanımlayın: Tutar, süre, sipariş ve istisna kurallarıyla fatura oluşturun.
- Alın: Müşteri yönlendirmesini kanıt saymak yerine sunucudan sunucuya gelen doğrulanmış olayları işleyin.
- Uygulayın: Paid durumunu teslimat, erişim, muhasebe veya incelemeye bağlayın.
Bu bölümün kaynakları: OxaPay Docs · OxaPay Docs · OxaPay Docs · OxaPay
Geri döndürülemez bir eylemden önce beş kontrol uygulayın
- Ödeme kimliği: Varlık, ağ, adres, tutar ve sipariş doğru mu? Kesinleşme yanlış ödemeyi düzeltmez.
- Yerel ağ kanıtı: Gerçekte hangi onay veya kesinleşme düzeyine ulaşıldı?
- Ağ sağlığı: Zincir normal mi; gecikme, yeniden düzenleme, sıralayıcı arızası veya sağlayıcı uyuşmazlığı var mı?
- İş riski: Durum sonradan değişirse zarar ne olur ve eylemi geri almak mümkün müdür?
- Kontrollü geçiş: İşlem bir kez yapılıp günlük, mutabakat ve manuel istisna kuralıyla açıklanabilir mi?
En sağlam politika her zaman en yavaşı değildir. Amaç, güvenli eylem için yeterli en düşük güven düzeyini kullanıp mevcut durumu kullanıcıya dürüstçe açıklamaktır.
Kesinleşme iddialarını protokol, uygulamayı OxaPay belgeleriyle doğrulayın
Kesinleşme kavramları ve ağ mekanizmaları güncellemelerle değişebilir. Kabul eşiği belirlerken birincil kaynakları gözden geçirin.
- Bitcoin: teknik makale ve P2P kılavuzu; olasılıksal güvenlik, mempool ve bayat bloklar.
- Ethereum: Proof of Stake ve Gasper; çatallanma seçimi ve checkpoint kesinleşmesi.
- Solana: ödeme doğrulama araçları ve RPC ile Processed, Confirmed, Finalized düzeyleri.
- TON: asenkron mesajlar, işlem izleri ve masterchain referansı.
- Layer 2: Optimism ve Arbitrum; sıralayıcı, yumuşak kesinleşme ve L1 güvenceleri.
OxaPay uygulamaları için Invoice API, Webhook belgeleri ve Crypto Invoice hizmeti kullanılabilir.
Bu bölümün kaynakları: Bitcoin Whitepaper · Bitcoin Developer Guide · Ethereum.org · Ethereum.org · Solana Docs · Solana Docs · TON Docs · Optimism Docs · Arbitrum Docs · OxaPay Docs · OxaPay Docs · OxaPay