Blokzincir işlemi, ağın durumunu değiştirmek için yetkilendirilmiş bir istektir
Bir blokzincir işlemi, değerin görünmez bir kanaldan akması değildir. Ağa belirli bir değişikliği uygulamasını isteyen yapılandırılmış veridir. Bu değişiklik yerel coin transferi, akıllı sözleşme çağrısı, token aktarımı, yeni varlık oluşturulması veya defterin başka bir bölümünün güncellenmesi olabilir.
Önce cüzdan işlem nesnesini oluşturur. Gerekli imza sahipleri dijital imzalarıyla işlemi yetkilendirir. İmzalı veriler ağ eşlerine yayınlanır, düğümler protokol kurallarına göre bağımsız doğrulama yapar ve işlem kabul edilen bir bloğa ya da sıralı işlem grubuna alınmak üzere seçilebilir.
Paylaşılan durumu yalnızca kabul edilmiş yürütme değiştirir. O ana kadar işlem bir öneridir. Görünür, geçerli ve çok sayıda düğüme yayılmış olsa bile bakiyelerde, sahiplik kayıtlarında veya sözleşme depolamasında henüz kanonik bir değişiklik yaratmamış olabilir.
Bitcoin işlemleri önceki çıktıları harcar ve yeni çıktılar üretir. Ethereum işlemleri bir hesaptan başlatılan kriptografik olarak imzalı talimatlardır. Solana, imzaları ve bir veya daha fazla talimatı işlemde birleştirir. TON'da bir hesap mesaj işleyip durumunu değiştirdiğinde işlem kaydedilir. Yapılar farklı olsa da temel düzen aynıdır.
Kullanıcı niyetini belirtir, işlem nesnesini ise cüzdan oluşturur
Kullanıcı genellikle basit komutlar düşünür: 0,01 BTC gönder, 50 USDT aktar, bir token takas et veya sözleşmeyle etkileşime gir. Blokzincir bu insan niyetini doğrudan işleyemez. Cüzdan ya da uygulama, niyeti seçilen ağın anlayacağı kesin işlem biçimine dönüştürmelidir.
Bu dönüşüm önemlidir; çünkü görünen komutun arkasında teknik kararlar vardır. Bitcoin cüzdanı harcanabilir çıktıları seçip para üstünü hesaplayabilir. Ethereum cüzdanı nonce belirler ve gas tahmini yapar. Solana ve TON cüzdanları gerekli hesapları, blok referanslarını ve mesajları hazırlar.
Bir adrese ödeme yapmak veya uygulama çağırmak gibi istenen sonuç.
İstenen değişikliği anlatan ağa özgü veri yapısı.
Gerekli anahtarların tam olarak o veriyi onayladığının kanıtı.
Kabul edilen işlem işlendiğinde ortaya çıkan durum değişikliği.
Dolayısıyla işlem yalnızca ödeme talimatı değildir; neyin değişeceğini, kimin onayladığını, hangi kaynakların kullanılabileceğini ve hangi ağ kurallarının sağlanacağını makinenin anlayacağı biçimde ifade eder.
Ağlar farklı alanlar kullanır, ancak her işlem doğrulanabilecek yeterli bağlamı taşımalıdır
Tüm blokzincirler için tek bir işlem biçimi yoktur. Yine de çoğu işlem kullanılabilir kaynakları, istenen sonucu, yetkiyi, yeniden oynatmaya veya yanlış sıralamaya karşı korumayı ve göndericinin kabul ettiği yürütme maliyetini tanımlar.
| Bileşen | İşlev | Yaygın örnekler |
|---|---|---|
| Kaynaklar | Neyin harcanabileceğini veya isteği hangi hesabın başlattığını belirler. | Bitcoin girdileri; Ethereum göndericisi; Solana hesap listesi |
| İstenen sonuç | Transferi, talimatı veya sözleşme çağrısını tarif eder. | Çıktılar, alıcı ve değer, program talimatları, mesaj gövdesi |
| Sıra koruması | İstenmeyen tekrarları önler veya geçerli sıralamayı kurar. | Outpoint, nonce, yakın tarihli blok karması, sıra numarası |
| Kaynak limitleri ve ücretler | Hesaplamayı sınırlar veya ağ işleme maliyetini karşılar. | Ücret oranı, gas limiti, öncelik ücreti, hesaplama bütçesi |
| İmzalar | Özel anahtarları açıklamadan gerekli onayı kanıtlar. | ECDSA, Schnorr, Ed25519, sözleşme düzeyinde doğrulama |
Bitcoin işlem rehberi girdilerin eski çıktılara nasıl atıf yaptığını ve yeni çıktıların gelecekteki harcama koşullarını nasıl belirlediğini anlatır. Ethereum işlem belgeleri alıcı, değer, veri, nonce, gas limiti ve ücret parametrelerini açıklar.
Dijital imza kesin işlem verisini yetkilendirir; tek başına fon transfer etmez
Cüzdan, işlem verisinin bir gösterimini bir ya da birkaç özel anahtarla imzalar. Ağ katılımcıları karşılık gelen açık anahtar veya harcama koşuluyla imzayı doğrulayabilir; özel anahtarı öğrenmeden doğru anahtarın veri için onay verdiğini görür.
İmza kişisel kimliği değil, yetkilendirmeyi kanıtlar. Geçerli bir imza, protokolün istediği anahtar üzerindeki kontrolü gösterir; insanın kim olduğunu, ticari anlaşma bulunduğunu veya alıcının gerçekten hedeflenen işletme olduğunu kanıtlamaz.
İmzalanan alanların kapsamı da önemlidir. Korunan tutar, hedef adres, talimat veya başka bir alan değiştirilirse imza geçersiz olur. Bu nedenle aracı normal koşullarda imzalanmış transferi değiştirip göndericinin onayını koruyamaz.
UTXO ve hesap tabanlı ağlar harcanabilir durumu farklı biçimlerde temsil eder
İşlem biçimi defter modeline bağlıdır. Bitcoin, harcanmamış işlem çıktısı anlamına gelen UTXO modelini kullanır. İşlem belirli eski çıktıları tüketir ve yenilerini üretir. Ağ, tek bir küresel Bitcoin hesap bakiyesini güncellemez; cüzdan harcama yetkisi bulunan çıktıları toplayarak kullanılabilir bakiyeyi hesaplar.
Ethereum hesap tabanlıdır. Harici sahipli hesapta bakiye ve nonce bulunur. İşlemler nonce sırasına göre uygulanır ve yürütme bakiyeleri, sözleşme kodunu ya da depolamayı değiştirebilir. Ethereum hesap belgeleri nonce değerinin aynı imzalı işlemin tekrar tekrar yürütülmesini nasıl önlediğini açıklar.
Solana işlemleri, talimatların okuyacağı veya yazacağı hesapları belirtir. Programlar talimatları işler ve yazılabilir hesapları günceller. Yakın tarihli blok karması işlemin geçerlilik süresini sınırlar. Resmî Solana rehberi imzaları, talimatları, hesap anahtarlarını ve blok karmasını açıklar.
TON mesaj temellidir. Gelen mesaj bir hesapta işlem başlatabilir, durumunu değiştirebilir ve başka hesaplara gidecek mesajlar üretebilir. Bu ilişki TON mesaj ve işlem belgelerinde açıklanır.
Ayrı harcanabilir çıktıları tüketir ve yenilerini üretir.
Bakiye, nonce ve depolamaya sıralı değişiklikler uygular.
Belirtilen hesapları okuyan ve değiştiren talimatları yürütür.
Her hesapta mesajları işler ve sonraki mesajları oluşturur.
Yayın, aday işlemi dağıtır; ağ uzlaşması oluşturmaz
İmzadan sonra cüzdan serileştirilmiş işlemi bir düğüme veya hizmete gönderir. Bu eş, temel kontrolleri yapıp işlemi kabul ederek başka eşlere iletmeye karar verir. Diğer düğümler süreci tekrarladıkça işlem ağa yayılır.
Yayılım anlık ya da tamamen eşit değildir. Düğümler farklı bağlantılara, yazılım politikalarına, kaynak limitlerine ve yerel görünümlere sahiptir. Bir blokzincir gezgini bekleyen işlemi başka bir hizmetten önce görebilir. Bazı düğümler, diğerlerinin tuttuğu işlemi reddedebilir.
Bitcoin eşler arası ağ rehberi tam düğümler arasındaki alışverişi açıklar. Dolayısıyla «yayınlandı» cüzdanın dağıtımı başlattığını gösterir; bütün katılımcıların tek bir kanonik sonucu kabul ettiğini değil.
Düğümler hem işlem verisini hem de yürütüleceği defter durumunu değerlendirir
İmza kontrolü doğrulamanın sadece bir adımıdır. Düğüm serileştirmeyi, alan değerlerini, referans kaynaklarını ve sıra gereksinimlerini inceler; ardından isteği mevcut defter görünümüne göre sınar.
Bitcoin'de belirtilen çıktılar mevcut ve harcanmamış olmalıdır. Kilit açma verileri harcama koşullarını karşılamalı; girdi değeri çıktılarla örtük ücreti karşılamalıdır. Zaten tüketilmiş çıktıyı harcamaya çalışan işlem o zincir durumunda geçersizdir.
Ethereum'da imza göndericiyi doğru biçimde belirlemeli, nonce hesap sıralamasına uymalı, göndericinin bakiyesi değer ve azami yürütme maliyetine yetmelidir. İşlem türü güncel kuralları da sağlamalıdır. Sözleşme yürütmesi ilave kontroller yapar ve başarısızlıkla geri dönebilir.
Solana gerekli imzaları, son blok karmasını, hesap kilitlerini, talimat yapısını, ücret kaynaklarını ve çalışma zamanı kurallarını kontrol eder. TON gelen mesajı doğrular ve hesabı protokolde tanımlanan aşamalardan geçirir.
Aday işlem ├─ yapı geçerli mi? ├─ gerekli imzalar doğru mu? ├─ girdiler veya hesap durumu kullanılabilir mi? ├─ sıra / nonce / blok karması uygun mu? ├─ ücret ve kaynaklar yeterli mi? └─ işleme protokol izin veriyor mu? ├─ hayır → reddet veya iletme └─ evet → bloğa alınabilecek aday olarak tut
Geçerlilik bağlama bağlıdır. İşlem imzalanırken geçerli olup bloğa girmeden kullanılamaz hâle gelebilir: başka işlem aynı Bitcoin çıktısını harcayabilir, Ethereum'da daha düşük nonce'lu işlem eksik kalabilir veya Solana blok karmasının süresi dolabilir.
Geçerli bekleyen işlem yerelde kabul edilmiştir; kanonik olarak kaydedilmemiştir
Birçok ağ, ilk kabul kontrollerini geçmiş ancak bloğa alınmamış işlemleri yerel havuzlarda tutar. «Mempool» ifadesi kullanışlı olsa da genellikle tek bir küresel havuz yoktur; her düğüm aday kümesini kendi görünümüne ve politikasına göre yönetir.
Blok üreticileri erişebildikleri işlemlerden seçim yapar. Kapasite, ücret teşvikleri, işlem bağımlılıkları, hesap sırası ve yürütme kısıtları seçimi etkiler. Geçerli işlem bekleyebilir, başka bir işlemle değiştirilebilir, süresi dolabilir veya bazı havuzlardan silinebilir.
OxaPay'in Mempool Açıklaması makalesi kapasite rekabetini ve dahil edilme süresindeki değişimleri ele alır. Burada havuzun yaşam döngüsündeki rolüne odaklanıyoruz; ücret piyasası ve blok alanı rekabeti ayrı bir derin analiz gerektirir.
Bloğa dahil edilme, kabul edilmiş tarih içinde yürütme konumunu belirler
Madenci, doğrulayıcı, lider veya sıralayıcı işlemleri seçip sıralı blok ya da grup önerir. Diğer katılımcılar bunu protokol kurallarına göre doğrular. Kabul edilen blok geçerli kanonik tarihe veya zamanla güçlenen kabul edilmiş aday geçmişe katılır.
Sıralama önemlidir; işlemler önceki duruma bağlıdır. İki işlem aynı kaynağı harcamaya çalışabilir, sözleşme çağrıları farklı sırada farklı sonuç verebilir, nonce sıralama gerektirir ve Solana hesap kilitleri paralel yürütmeyi etkiler.
Dolayısıyla dahil edilme yalnızca zaman damgası değildir. İşlemi durum geçişleri dizisinde belirli noktaya yerleştirir; önceki işlemlerden sonra ve sonraki işlemlerden önce değerlendirilmesini sağlar.
Yürütme, belirlenimci kurallarla önceki durumu sonraki duruma dönüştürür
İşlem sırasına ulaştığında ağ ilgili kuralları uygular. Bu işlem kavramsal olarak durum geçişi fonksiyonuyla gösterilebilir:
post_state = transition(pre_state, ordered_transaction, protocol_rules)
Bitcoin'de başarılı doğrulama tüketilen çıktıları UTXO kümesinden çıkarıp yenilerini ekler. Ethereum'da yürütme bakiyeleri değiştirebilir, göndericinin nonce değerini artırabilir, sözleşme dağıtabilir, depolamayı güncelleyebilir ve günlük kayıtları üretebilir. Ethereum yürütme testleri önceki durumu beklenen sonraki durumla karşılaştırır.
Solana'da her talimat belirtilen hesaplarla bir program çağırır. Hesap değişiklikleri atomiktir: işlem bütün olarak başarılı olur veya durum değişiklikleri geri alınır. TON'da mesaj işleme bir hesabı değiştirip başka hesaplarda daha sonra işlem başlatacak mesajlar oluşturabilir.
Token transferi, işlemin değer hareketiyle aynı olmadığını gösterir. Akıllı sözleşme ağlarında yerel işlem token sözleşmesini çağırır; sözleşme kendi sakladığı bakiyeleri değiştirir ve transfer olayı üretebilir. Adresler arasında fiziksel olarak taşınan ayrı bir token nesnesi yoktur.
Makbuzlar, günlükler, olaylar ve yürütme izleri gerçekleşene ilişkin kanıt sunar, ancak durumun kendisiyle aynı değildir. Uygulamalar olaylardan transfer tespit edebilir; yine de aradığı yetkili durum değişikliğini hangi çıktının temsil ettiğini bilmelidir.
Reddedilme, düşme, değiştirilme, süre dolması ve geri alma farklı katmanların sonuçlarıdır
«Başarısız işlem» yeterince kesin değildir. Hatalı biçimlenmiş veya yetkisiz işlem yayılmadan reddedilebilir. Geçerli işlem seçilmediği için bekleyebilir, rakip işlemle değiştirilebilir veya süresi dolabilir. Sözleşme çağrısı bloğa alınsa da yürütme sırasında geri dönebilir.
| Sonuç | Ne oldu? | Durum etkisi |
|---|---|---|
| Reddedildi | Kabul ya da uzlaşma kurallarına uymadı. | Kanonik değişiklik yok |
| Bekliyor veya düşürüldü | Aday olarak kaldı, dahil edilmedi veya tutulmadı. | Kanonik değişiklik yok |
| Değiştirildi veya çakıştı | Başka işlem kaynağı ya da sıra konumunu kullandı. | Yalnızca kabul edilen alternatif durumu değiştirir. |
| Dahil edildi ve başarılı | Yürütme kurallara uygun tamamlandı. | İstenen son durum kayda geçti. |
| Dahil edildi ama geri döndü | Sözleşme işlemi başladı fakat başarısız oldu. | Uygulama değişiklikleri geri alınır; ücret veya sıra değişimleri kalabilir. |
Bu ayrım blokzincir gezginlerinde kritik önemdedir. Dahil edilmiş Ethereum işlemi başarısız yürütme gösterebilir ve yine de gas harcayabilir. Kabul edilmiş zincirde olmayan Bitcoin işlemi geçerliliğini korur ve yeniden yayınlanırsa tekrar görünebilir. Solana işlemi son blok karması geçersizleşince süresi dolabilir.
İşlem karması veriyi tanımlar; işlemin tüm ticari anlamını açıklamaz
İşlem kimliği genellikle serileştirilmiş veriden türetilir. Düğümler, gezginler, cüzdanlar ve uygulamalar tam veriyi tekrarlamadan işlemi referans alabilir. Hash ve kimlik üretim kuralları ağa göre değişir.
OxaPay'in kripto işlem kimliği rehberi, işletmelerin TXID'yi doğrulama ve destek için nasıl kullandığını anlatır. Blokzincir gezgini adresleri, tutarları, ücretleri, blok konumunu, yürütme sonucunu ve onayları gösterebilir.
Ancak karma, işlemin siparişle eşleşip eşleşmediğini söylemez. Beklenen varlığı ve ağı, fatura tutarını, son ödeme süresini, müşteri kimliğini veya teslim politikasını bilmez. Ağ referansıdır; tam bir ticari kayıt değildir.
Yaşam döngüsü ortaktır, fakat işlemlerin anlamı ve güvenceleri zincire özgüdür
Her ağ önerilen işlemden kabul edilmiş duruma ilerler, ancak mekanizma değişir. Bitcoin çıktıları harcar; Ethereum ETH aktarır veya sözleşme çağırır; Solana belirtilmiş hesaplarla talimatları birleştirir; TON mesajlara ve hesap başına işlemeye dayanır.
Farklılıklar ücret hesaplamasını, boyutu, sıralamayı, paralelliği, süre dolmasını, token tespitini ve başarının anlamını etkiler. Ödeme sistemlerinin veriyi okuma yöntemi de değişir: ERC-20 ödemeleri sözleşme yürütmesi ve loglardan, yerel Bitcoin ödemeleri çıktılardan tespit edilir. TON jetton aktarımı sözleşmeler arasında bir mesaj izinin takip edilmesini gerektirebilir.
Varlık adı tek başına yeterli değildir; işletme hem varlığı hem ağı bilmelidir. OxaPay desteklenen para birimleri belgeleri ağ ayrıntılarını da sunar. Aynı token sembolü farklı ağlarda farklı işlem yorumları gerektirebilir.
Blokzincir işlemi, bütün bir ödeme sistemindeki kayıtlardan yalnızca biridir
Ödeme isteği sipariş, tutar, varlık seçimi, ağ, hedef, geçerlilik süresi ve işletme referansı gibi ticari bağlamla başlar. Blokzincir işlemi ödeyenin gerçekte ne gönderdiğini kaydeder; ödeme sistemi beklenen koşullarla gözlenen işlemi karşılaştırır.
OxaPay'in Payment Information uç noktası bu ayrımı gösterir. Ödeme kaydı takip kimliği, sipariş bağlamı ve genel ödeme durumu içerebilir. İşlem düzeyi veriler karmayı, tutarı, para birimini, ağı, adresi, durumu ve onay sayısını gösterebilir.
Ağ işlemi ile ödeme durumu ilişkili fakat birbirinin yerine geçmez. OxaPay ödeme durumları tablosu bekliyor, ödeniyor, ödendi, eksik ödendi, iade ediliyor, iade edildi ve süresi doldu gibi iş durumlarını içerir. Bu ticari anlamları blokzincir kendiliğinden oluşturmaz.
Ticari ödeme isteği
sipariş + beklenen tutar + varlık + ağ + süre
↓
Blokzincir işlemi
karma + girdiler/hesaplar + talimatlar + imza + yürütme
↓
Ödeme yorumu
eşleştirme + onay politikası + istisnalar + iş durumuBu nedenle ağ geçidi protokol ayrıntılarını üstlense bile işletmelerin işlem bilgisi önemlidir. Böylece ağ kanıtı ile ödeme tamamlanmasını ayırabilir; yanlış ağ, hatalı tutar, geç dahil olma, başarısız yürütme ve eşleşmeyen transferleri inceleyebilirler.
Her blokzincir işlemini anlamak için yedi adımlı model
- Niyet: kullanıcı veya uygulama istenen sonucu tanımlar.
- Oluşturma: cüzdan niyeti ağa özgü işlem nesnesine dönüştürür.
- Yetkilendirme: gerekli anahtarlar tam veriyi veya harcama koşullarını imzalar.
- Yayılım: eşler adayı alır, denetler ve iletir.
- Kabul ve seçim: geçerli adaylar yerel politika, kapasite, sıra ve ücret sınırlamaları altında bekler.
- Dahil edilme ve yürütme: işlem sıralı konum alır ve önceki duruma uygulanır.
- Kabul edilen durum: sonuç ağ tarihine girer ve zamanla daha güçlü taahhüt kazanır.
Birçok kişi «gönderildi» ifadesini «durum değişti» ile eş tutar. Oysa defterin sonucu göstermesi için oluşturma, yetkilendirme, doğrulama, sıralama ve yürütme aşamaları gerekir.