EVM işleminde status ve logs: JSON makbuzunu adım adım okuma

Bir EVM işlem makbuzu, işlemin nasıl sonuçlandığını ve ürettiği olay kayıtlarını okumak için kullanılan teknik bir veri yapısıdır. İlk bakışta uzun adresler ve hexadecimal sayılar karmaşık görünebilir. Bu rehberde gerçek cüzdan bağlamadan, bilgisayarda oluşturduğumuz küçük bir örnekle alanları ayıracağız. Kod ağ isteği göndermez, işlem oluşturmaz ve imza atmaz. Örnekteki sayılar editör tarafından eğitim amacıyla seçilmiştir; canlı bir işlemden alınmış makbuz değildir.

1. Makbuzun yanıt zarfını ayırın

JSON-RPC yanıtında çağrıya ait kimlik ve sonuç bölümü bulunabilir; hata olduğunda hata nesnesiyle karşılaşabilirsiniz. İncelemede önce yanıtın gerçekten bir makbuz içerdiğini kontrol edin. Bir sorgunun null döndürmesi ile status değerinin başarısız olması aynı değildir. Birinci durumda elinizde okunacak makbuz olmayabilir; ikinci durumda makbuz içindeki yürütme sonucunu değerlendiriyorsunuzdur. Ekranda tek bir “hata” etiketi kullanmak, bu ayrımı görünmez hale getirir.

2. Status alanını iş hedefiyle karıştırmayın

Ethereum yürütme API’si işlem makbuzunda durum ve olay kayıtları için alanlar tanımlar. 0x1 başarılı, 0x0 başarısız yürütme durumunu ifade eder. Ancak başarılı bir yürütme sizin beklediğiniz ticari sonucu tek başına kanıtlamaz. Örnek uygulamamızda “dosya kontrolü tamamlandı” yazdıran bir iş akışı düşünün: program çalışmış olabilir, fakat yanlış dosya seçilmiş olabilir. Zincir kaydında da hangi sözleşme, hangi çağrı ve hangi varlıkla ilgilendiğinizi ayrıca eşleştirmeniz gerekir.

3. Logs listesini olaylar dizisi olarak okuyun

Her log satırını ayrı bir kayıt kabul edin. Kaydı üreten sözleşme adresi, konular ve veri alanı farklı görevler taşır. Sadece bir olay adını görüp onun doğru varlığa ait olduğunu varsaymayın; olayları yorumlamak için ilgili sözleşmenin arayüz bilgisine ihtiyaç duyabilirsiniz. Bu eğitimde ABI çözümleme yapmıyoruz. İlk hedefimiz log sayısını, hangi sözleşmelerden geldiklerini ve ham değerlerin nasıl tutulduğunu anlaşılır biçimde listelemek.

4. Yerel örnek üzerinde çalışan kod

Aşağıdaki kodu makbuz_oku.py adıyla kaydedip Python 3 ile çalıştırabilirsiniz. Dosyada sahte bir kayıt bulunur; adresler test anlatımı için tekrarlanan karakterlerden oluşur. Bu dosya başka bir hesaba bağlanmaz. Gerçek kayda geçtiğinizde, veri kaynağını ve ağını ayrıca not etmeniz gerekir. Kodun yazdırdığı sayıların para miktarı olmadığını özellikle göz önünde tutun; burada blok numarası ve kullanılan gas birimi okunuyor.

receipt = {
    "status": "0x1",
    "blockNumber": "0x64",
    "gasUsed": "0x5208",
    "logs": [{
        "address": "0x" + "11" * 20,
        "topics": ["0x" + "22" * 32],
        "data": "0x"
    }]
}

state = {"0x1": "başarılı", "0x0": "başarısız"}
print("Durum:", state.get(receipt.get("status"), "bilinmiyor"))
for field in ("blockNumber", "gasUsed"):
    raw = receipt.get(field)
    print(field, int(raw, 16) if isinstance(raw, str) else "eksik")
for index, log in enumerate(receipt.get("logs", []), 1):
    print("Log", index, "sözleşme:", log.get("address"))
    print("Konu sayısı:", len(log.get("topics", [])))

5. Çıktıyı elle kontrol edin

Örnek dosyada blok numarası 100, kullanılan gas değeri 21000 olarak görünür. Bu iki sonucun hangi hexadecimal girdiden üretildiğini not edin. Sonra yalnızca status alanını 0x0 yapıp programı tekrar çalıştırın. Durum açıklaması değişirken diğer alanlar aynı kalır; çünkü bu bir yerel eğitim nesnesidir ve gerçek ağ davranışı taklit edilmemektedir. Çalışmanın amacı bir işlem simülasyonu kurmak değil, alan okuma hatasını küçük bir veri üzerinde görünür hale getirmektir.

6. Eksik veya beklenmeyen alanlara hazırlanın

Bir alanın bulunmamasını otomatik olarak sıfır kabul etmek, raporda yanıltıcı sonuçlar doğurur. Örnekte bu nedenle eksik değer için ayrı metin yazdırıyoruz. Log listesi boşsa “token taşınmadı” gibi kapsamlı bir sonuç çıkarmayın; önce hangi olayı aradığınızı ve hangi sözleşmenin bunu üretmesinin beklendiğini belirleyin. Özellikle başarısız yürütme, önceden oluşturulmuş işlem nesnesi ve makbuz alanlarının farklı kaynaklardan karıştırılması, teknik raporu anlaşılmaz hale getirir.

7. İnceleme raporunu yeniden üretilebilir bırakın

Son notunuzda kullanılan ağ, sorgu yöntemi, kontrol zamanı ve yorumlanan alanların adları yer alsın. Ham makbuzla hazırladığınız açıklamayı ayrı saklamak, daha sonra yanlış yorumu düzeltmeyi kolaylaştırır. Aynı veriyi başka biri okuduğunda hangi satıra dayandığınızı anlayabilmelidir. Bu temel çalışma tamamlandıktan sonra, doğrulanmış sözleşme ABI’siyle olay çözümleme öğrenilebilir. Yalnızca log adını eşleştiren kestirme bir betiği, varlık hareketini kesin doğrulayan araç olarak sunmayın.

İlgili okumalar

• Stablecoin ağ ve sözleşme kontrolü: aynı isim neden yeterli değil?
• Kripto köprü işlemini okuma: kaynak ve hedef ağ kayıtlarını ayırma