Yapısal Tasarım Kalıplarından(Structural Patterns) olan Decorator Tasarım Kalıbı(Decorator Design Pattern) ile devam ediyoruz. Nedir? Nasıl kullanılır? C# kod örneğiyle inceleyeceğiz.

Decorator pattern, mevcut bir sınıfın yapısını, kodlamasını değiştirmeden çalışma zamanında yeni işlevler eklenmesine olanak tanır.

Yazının devamında aslında yukarıdaki cümlenin altını dolduracağız. Varolan bir sınıfın herhangi bir metodunu değiştirmeden yani kodlamasına müdahale etmeden çalışma davranışını değiştirmek istediğimiz durumlar olabilir. Aynı şekilde iç yapıyı etkilemeden yeni özellikler de eklemek isteyebiliriz. Decorator pattern bu noktada yardımcı olur.

Birazdan detayına gireceğiz ama mantığın kolay anlaşılabilmesi için görsel bir örnek üzerinden gidelim. Client ve Service isminde iki sınıfımız var. Client, Service’e çağrı atıyor ve bir sonuç dönüyor. Aşağıdaki şeklin ilk kısmında bunu görebiliriz. Sistem bu şekilde sorunsuz çalışırken Service sınıfına ek özellikler talep ediliyor. Şeklin ikinci kısmında buna çözüm olarak decorator uygulanıyor(Decorator1). Service kodlamasında herhangi bir değişiklik yapılmadan decorator sınıfı ile istenen düzenlemeler sağlanıyor. Devamında bir düzenleme daha isteniyor ve çözüm olarak şeklin üçüncü kısmında yeni bir decorator ekleniyor. Böylece sistemimizde iki adet decorator nesnesi oluyor(Decorator1 ve Decorator2).

Şekilden açıkça görüldüğü üzere decorator nesnesi, referansı verilen nesneye işlem uygular. Decorator2 nesnesi Decorator1 nesnesine, Decorator1 nesnesi de Service nesnesine işlem uygular veya dekore eder diyelim. Bu şekilde çalışma zamanında Service nesnesine istediğimiz kadar decorator uygulayabilir ve davranışını değiştirebiliriz. Bunu nasıl yaparız? Kod üzerinden daha net göreceğiz.

Peki OOP prensiplerinden inheritance(kalıtım) ile bunun ne farkı var? Service class’ını(superclass) alır ondan yeni bir class türetirim(subclass) neden bunu kullanayım? Sorularına cevap arayalım.

Evet bu gibi işleri subclass tanımlayarak ta yapabiliriz decorator pattern çalışma zamanında işlevselliğin uygulanması açısından çok iyi bir alternatif sunar.

Yukarıdaki örnekten devam edersek, Service nesnesine çalışma zamanında(runtime) decorator tarafından müdahale edilmektedir. Diğer ifadeyle Service nesnesine decorator dinamik olarak uygulanmakta. Yani öncelikli şart elimizde bir nesne olmalıdır ve bu nesne referansı decorator’a parametre olarak geçilir. Decorator içinde bu nesneye müdahale edilir.

Diğer önemli nokta ise her yeni özellik için kalıtım kullanmaya çalışırsak bu özelliklerin kombinasyonunu sağlamak için çok fazla türemiş sınıfımız olacaktır. Bu da sınıf sayısında patlamaya neden olacaktır. Oysa her bir özelliği tanımlayan decorator’ı ard arda uygulayarak bunu kolayca sağlayabiliriz.

Problem Tanımı

Şimdi daha somut örnek üzerinden gidelim. Pizza sınıfımız olsun, sınıf yapımızı aşağıdaki gibi kurmaya başlayalım.

public abstract class Pizza
{
    public abstract string Description();
    public abstract double GetCost();
}

public class Pepperoni : Pizza
{
    public override string Description() => $"{GetType().Name}";
    public override double GetCost() => 100;
}

public class Margherita : Pizza
{
    public override string Description() => $"{GetType().Name}";
    public override double GetCost() => 200;
}

Şimdilik iki ana tip pizzamız olsun Pepperoni ve Margherita. Mantarlı seçeneklerini ekleyelim.

public class PepperoniWithMushroom : Pepperoni
{
    public override string Description() => $"{GetType().Name}";
    public override double GetCost() => base.GetCost() + 10;    
}

public class MargheritaWithMushroom : Margherita
{
    public override string Description() => $"{GetType().Name}";
    public override double GetCost() => base.GetCost() + 10;
}

Şimdi de ekstra mozarella seçeneği geldi.

public class PepperoniWithMushroomWithExtraMozarella : PepperoniWithMushroom
{
    public override string Description() => $"{GetType().Name}";
    public override double GetCost() => base.GetCost() + 5;
}

public class MargheritaWithMushroomWithExtraMozarella : MargheritaWithMushroom
{
    public override string Description() => $"{GetType().Name}";
    public override double GetCost() => base.GetCost() + 5;
}

Eklenen her özellik nedeniyle yeni sınıflar ekledik ve sınıf sayısı daha şimdiden hızla artış göstermeye başladı.

Yeni sınıf eklemek yerine property ekleyerek çözebilir miyiz? Buna bakalım.

public abstract class Pizza
{
    public bool WithMushroom { get; set; }
    public bool WithExtraMozarella { get; set; }
    public bool WithSweetCorn { get; set; }

    public abstract string Description();
    public abstract double GetCost();
}

public class Pepperoni : Pizza
{
    public override string Description() => $"{GetType().Name}";
    public override double GetCost()
    {
        double cost = 100;

        if (WithMushroom)
        {
            cost += 10;
        }

        if (WithExtraMozarella)
        {
            cost += 5;
        }

        if (WithSweetCorn)
        {
            cost += 7;
        }

        //new ?
        return cost;
    }
}

public class Margherita : Pizza
{
    public override string Description() => $"{GetType().Name}";
    public override double GetCost()
    {
        double cost = 200;

        if (WithMushroom)
        {
            cost += 10;
        }

        if (WithExtraMozarella)
        {
            cost += 5;
        }

        if (WithSweetCorn)
        {
            cost += 7;
        }

        return cost;
    }
}

Bu çözümde ise ana sınıflarımız olan Pepperoni ve Margherita içerisine if kodları eklemek durumunda kaldık. Yeni eklenen her bir özellik için kodlara müdahale edilip hesaplama yapılıyor. Bu da iyi bir çözüm olmadı. Çünkü sınıflarımızın değişime kapalı fakat genişlemeye açık olmasını isteriz. Değişiklik istekleri her zaman yukarıdaki örnekteki gibi basit olmayacaktır. Daha önceden geliştirmesi tamamlanmış ve kullanıma sunulan sınıfların kodlarında değişiklikler yapılması önerilmez.

Decorator pattern tarafından sunulan çözüm de bu durumlara yöneliktir. Şimdi çözümü uygulayalım.

Önerilen Çözüm

Ana sınıflarımız olduğu gibi kalsın.

public abstract class Pizza
{
    public abstract string Description();
    public abstract double GetCost();
}

public class Pepperoni : Pizza
{
    public override string Description() => $"{GetType().Name}";
    public override double GetCost() => 100;
}

public class Margherita : Pizza
{
    public override string Description() => $"{GetType().Name}";
    public override double GetCost() => 200;
}

Decorator’larda kullanacağımız base decorator sınıfını ekleyelim.

public abstract class PizzaDecorator : Pizza
{
    protected Pizza _pizza;

    public override string Description() => _pizza.Description();    
    public override double GetCost() => _pizza.GetCost();
}

PizzaDecorator sınıfı Pizza sınıfından türemekle birlikte kendi içinde Pizza tipinde bir nesne barındırmakta. Bundan sonraki tüm decorator’larımızı PizzaDecorator’dan türeteceğiz ve dışarıdan Pizza tipinde nesneyi referans olarak alacaklar. Böylece Pizza nesnesinin kullanıldığı yerlerde decorator nesnemizi kullanabilirken bir yandan da Pizza nesnesini kullanarak ürettiği sonuca müdahale imkanımız olacak.

Decorator’larımız artık tanımlayabiliriz. Şimdilik iki adet yeterli.

public class WithMushroomDecorator : PizzaDecorator
{
    public override double GetCost() => base.GetCost() + 10;    
    public WithMushroomDecorator(Pizza pizza) => _pizza = pizza;    
}

public class WithExtraMozarellaDecorator : PizzaDecorator
{
    public override double GetCost() => base.GetCost() + 5;
    public WithExtraMozarellaDecorator(Pizza pizza) => _pizza = pizza;
}

Deneyelim:

Pizza pizza = new Pepperoni();
pizza = new WithMushroomDecorator(pizza); //decorator
pizza = new WithExtraMozarellaDecorator(pizza); //decorator
pizza = new WithExtraMozarellaDecorator(pizza); //decorator
Console.WriteLine(pizza.Description() + ":" + pizza.GetCost());
//Pepperoni:120

//another example
pizza = new WithMushroomDecorator(new Margherita()); //decorator
Console.WriteLine(pizza.Description() + ":" + pizza.GetCost());
//Margherita:210

Pizza sınıfımıza dokunmadan base decorator sınıfı oluşturduk ve tipi yine Pizza olabilecek şekilde türettik. Aynı zamanda bu base decorator sınıfının içinde Pizza nesnesine referans ekledik. Yeni eklenen decorator sınıflarını(concrete) base decorator sınıfından türeterek işlemleri bunlar içinde gerçekleştirdik.

Decorator tasarım kalıbının UML şeması aşağıdaki gibidir.

Şimdi yukarıdaki UML şemasını daha iyi anlayabilmek için aynı isimleri kullanarak sınıf yapısını ve decorator tasarımını yapalım. Öncelikle Component tanımını yapalım.

public interface IComponent
{
    void Operation();
}

public class ConcreteComponent : IComponent
{
    public void Operation() => Console.WriteLine(GetType().Name + ".Operation()");
}

ConcreteComponent sınıfına yeni bir özellik eklenmesi gerekti diyelim ve bunu decorator ile gerçekleştireceğiz. Bu durumda öncelikle decorator sınıfını eklemeliyiz.

public class Decorator : IComponent
{
    readonly IComponent _component;

    public Decorator(IComponent component) => _component = component;

    public virtual void Operation() => _component.Operation();
}

Decorator sınıfımız da IComponent’ten türedi yani aynı arabirimi sağlıyor. Ek olarak Component nesnesine de sahip. Decorator sınıfından türeyen decorator örneğimiz ile yani ConcreteDecorator tanımını da yapalım.

public class ConcreteDecorator : Decorator
{
    public ConcreteDecorator(IComponent component) : base(component) { }
    
    public override void Operation()
    {
        base.Operation();
        Console.WriteLine(GetType().Name + ".Operation()");
    }
}

Deneyelim:

IComponent component = new ConcreteComponent();
component = new ConcreteDecorator(component);
component.Operation();
// Console:
//ConcreteComponent.Operation()
//ConcreteDecorator.Operation()

ConcreteDecorator’ı istediğimiz kadar arka arkaya çağırabilir veya yeni decorator’lar ekleyebiliriz. ConcreteDecoratorA ve ConcreteDecoratorB ekleyelim ve son olarak bunları da çalıştıralım.

public class ConcreteDecoratorA : Decorator
{
    public ConcreteDecoratorA(IComponent component) : base (component) { }
    public override void Operation()
    {
        base.Operation();
        Console.WriteLine(GetType().Name + ".Operation()");
    }
}

public class ConcreteDecoratorB : Decorator
{
    public ConcreteDecoratorB(IComponent component) : base(component) { }
    public override void Operation()
    {
        base.Operation();
        Console.WriteLine(GetType().Name + ".Operation()");
    }
}

Deneyelim:

IComponent component = new ConcreteDecoratorA(new ConcreteDecoratorB(new ConcreteComponent()));
component.Operation();
//Console:
//ConcreteComponent.Operation()
//ConcreteDecoratorB.Operation()
//ConcreteDecoratorA.Operation()

Bu iki örnek konunun anlaşılması için sanırım yeterli olmuştur. Okuduğunuz için teşekkürler.

Engin ÜNAL

Bu yazıda RabbitMQ nedir? Nasıl kullanılır? Neden tercih ediliyor? Genel kullanım alanları nelerdir? Sorularına cevaplar arayacağız. Devamında C# ile RabbitMQ erişimi ve yönetimine değinip kodlama örnekleri ile bitireceğiz.

RabbitMQ, açık kaynaklı, çok kullanılan bir mesajlaşma aracısıdır. AMQP, MQTT, STOMP gibi mesajlaşma protokollerini destekler. Mesajların alım ve dağıtımında hızlı, ölçeklenebilir, dağıtık yapıların kurulmasına imkan tanımaktadır. Esasında ondan beklenen ve iyi yaptığı iş ise temel olarak ona iletilen mesajların alıcısına iletilmek üzere bir kuyrukta saklanması ve kuyruktan sırayla alıcıya/alıcılara iletilmesidir. Bu işleri yapan başka uygulamalar da bulunmaktadır. Örneğin ActiveMQ, MSMQ, Azure Service Bus, Amazon SQS, Google Cloud Pub/Sub bunlardan bazıları olarak sıralanabilir.

RabbitMQ bir mesaj kuyruğu yönetim uygulamasıdır veya mesajlaşma aracısıdır demiştik. Çeşitli protokolleri destekler, tek bir protokole bağımlı değildir fakat biz bu yazıda geniş kullanımdaki AMQP(Advanced Message Queuing Protocol) ile devam edeceğiz. AMQP bir mesajlaşma protokolü ve standardıdır. Mesajlaşmanın nasıl bir mimari ve kurallar bütünlüğü içinde olacağını belirleyen standartları tanımlar.

Burada karşımıza iki versiyon çıkar. AMQP 1.0 ve AMQP 0.9.1 versiyonları. 1.0 olan versiyonu 0.9.1'den oldukça farklıdır ve sanki yeni bir protokol tanımlar gibi yapısal değişiklikler içerir. RabbitMQ’nun desteklediği temel protokol 0.9.1 versiyonudur, geliştirilirken bu versiyon baz alınmıştır. Ayrıca sitesinde geliştiriciler için paylaşılan kod örneklerinde de 0.9.1 versiyonu kullanılmıştır. Yazıda da yaygın kullanımda olan bu versiyon yani AMQP 0–9–1 kullanılacaktır.

Peki RabbitMQ neden ve hangi ihtiyaçlar için kullanılır?

Bekleme gerektiren veya uzun süren işlemlerin sonuçlarını o anda almak istemeyebiliriz. Uygulamamızın bir işlemi tamamlaması ve kullanıcıya sonucunu dürmesi uzun sürebilir ve kullanıcının bu işlemi beklemesine gerek olmayabilir. Sonucu daha sonra bildirim, mesaj veya e-mail ile iletmek yeterli olabilir. Örneğin e-ticaret uygulamamız olduğunu düşünelim. Kullanıcı alışveriş yapmış olsun ve ödeme sonrasında kesilen faturanın kullanıcı e-mail adresine gönderilmesi gereksin. Faturanın satış anında gönderilmesiyle birkaç dakika sonra gönderilmesi arasında kullanıcı açısından bir fark olmayacaktır. Satış işlemi yapılır, e-mail mesajı bir mesaj kuyruğuna iletilir ve oradan e-mail gönderen servis gönderim işlemini gerçekleştirir. Bu şekilde arka plandaki servislerin asenkron olarak çalışmaları sağlanmış olur.

Servislerin birbirlerine sıkı bağlı çalışmaları da istenmeyen bir durumdur. Özellikle mikroservis projelerinde servisler arası gevşek bağlı (loosely coupled) ilişkiler tercih edilir. Bu tip tasarımlarda araya bir broker koyarak mimariye esneklik sağlanabilir. Örnekler ve kullanım alanları çok çeşitlidir. Birkaç örnek ile devam edelim. Arkaplandaki mikro-servislerin birbirlerini beklemeden asenkron olarak çalışmaları gerekebilir. Örneğin A servisi, B servisine kaydedilmek üzere bir veri göndersin ama kayıt sonucunu beklemesi gerekmesin. Bunu yapmak için RabbitMQ’daki kuyruğa mesaj gönderir ve B servisi bu mesajı aldığında işler. B servisi işini bitirdiğinde kuyruğa tamamlandı mesajını gönderir ve A servisi bu işin tamamlandığı bilgisini alır.

Veya yük dağılımı yapılarak bazı servislerin aşırı yük altında çalışmalarını önlemek isteyebiliriz. Örneğin fatura hazırlayan servisimiz çok yoğun çalışıyor ve aynı işi yapan ikinci, üçüncü servisleri açmak gerekli. Eğer fatura servisimiz yapacağı işleri RabbitMQ kuyruğundan alıyorsa bu süreç gayet kolay bir şekilde çözülür. Kuyruğu dinleyen ve birbirinden bağımsız çalışabilen fatura servisleri açabilir ve yük dağılımını ayarlayabiliriz.

Veya bazı servislerin kritik önemde olduğu ve üzerinde çalıştığı işleri kaybetmek istemediğimiz durumlar olabilir. Servis çöktüğünde sistemin aksamaması ve işlerin kesintiye uğramadan devam etmesi istenebilir. Bu işleri bir kuyruğa atıp ayakta olan servislerin devralması ve devam etmesine ihtiyaç olabilir. RabbitMQ bu konuda önemli kolaylıklar sağlamaktadır. Kuyruktan çekilen bir mesajın ack bilgisini sonradan verebilme imkanı sunarak servis çökmelerinde mesaj kaybolmasına karşı kolayca önlem alınmasını sağlar. Buna ileriki konularda değineceğim. Yukarıda verilen kullanım örnekleri çeşitlendirilebilir. Genel bakış açısı sağladığını umuyorum.

RabbitMQ nasıl çalışıyor?

Artık kavramlara geçebiliriz. Mesaj gönderme/alma işlemleri en temel olarak aşağıdaki gibi olmaktadır.

• Publisher: Mesajı RabbitMQ’ya gönderen uygulamadır. (Producer)
• Consumer: RabbitMQ’daki mesajları okuyan uygulamadır. (Subscriber)
• Queue: Mesajların saklandığı kuyruk. İlk gönderilen mesaj ilk okunur. (FIFO — First In First Out).

Mesajı gönderecek uygulama(publisher/producer) RabbitMQ’ya bağlanır ve gönderim yapmak istediği mesajı iletir. Mesajları okuyan uygulama(consumer/subscriber) ise RabbitMQ’ya bağlanır ve almak istediği mesajları içeren kuyruğu dinlemeye başlar, gelen mesajları okur.

Bu işlemleri ve ihtiyaca göre daha gelişmişlerini de gerçekleştirebilmek için RabbitMQ tarafında Exchange yapıları bulunmaktadır, şimdi bunları görelim.

Exchange

Dağıtıcı görevi görürler. Gelen postaları ilgili alıcılara dağıtan postacı gibi düşünülebilir. Publisher/Producer tarafından RabbitMQ sistemine gönderilen tüm mesajlar öncelikle Exchange tarafından karşılanırlar. Exchange, kendisine iletilen mesajların hangi kuyruğa/kuyruklara yönlendirileceğine(routing) karar verir.

Bunu yaparken binding, routing key ve header özelliklerini kullanmaktadırlar.

• Binding : Exchange ile Queue arasındaki bağlantıdır.
• Routing Key : Mesajın kuyruğa nasıl yönlendirileceğine karar vermek için Exchange’in baktığı alandır.
• Header Attributes : Mesajları routing key değerine göre değil header’daki değerlere göre kuyruğa yönlendirmek için kullanılır. Sadece Headers Exchange tipi için kullanılır. Gereken bilgi exchange tipleri altında verilecektir.

Exchange Tipleri

Direct, fanout, topic, headers isminde temel dört exchange tipi bulunmaktadır. Bunlar gelen mesajların routing key, header veya binding parametrelerine göre yönlendirme işlemini yaparlar. Bir de default exchange bulunmaktadır, direct exchange tipindedir, rabbitmq tarafından ön tanımlıdır ve kullanılırken ismi boş geçilir. Genellikle exchange tanımlama ile uğraşmadan doğrudan kuyruğa mesaj göndermek için kullanılmaktadır. Tüm kuyruklar kendi isimleriyle bu exchange’e bağlıdır, eğer routing key değerine kuyruk adı verilirse mesaj o kuyruğa yönlendirilir. Okuma için de aynı şekilde routing key değerine kuyruk adı verilerek exchange adı boş geçilerek okuma yapılır. Şimdi exchange tiplerini inceleyelim.

Direct Exchange

Gelen mesajların Routing Key değerlerine göre kuyruklara dağıtılması için kullanılan exchange çeşididir, bir çeşit unicast yapar. Queue ile Exchange arasında bağlantı kurmak gereklidir. Bunun için binding tanımı yapılır. Routing key ile ilişkisi ise şöyledir; binding tanımı yapılırken verilen routing key ile gelen mesajdaki routing key ile eşleşen kuyruğa mesaj iletilir.

Örneğin ex-direct isminde bir exchange oluşturalım. Bunun için rabbitmq kurulumu yapıp yönetim ekranına giriyoruz. Buradaki Exchanges sayfasından aşağıdaki gibi yeni bir exchange ekliyoruz.

Queue eklemek için ise Queues and Streams sayfasına girip “Add a new queue” kısmında yeni queue tanımlarımızı yapıyoruz. q1, q2, q3, q4 isminde dört adet queue oluşturalım.

Tanımladığımız ex-direct isimli exchange tanım ekranına girip(Exchanges sayfasından ex-direct seçilir) aşağıdaki gibi binding tanımlarını yapıyoruz.

Buraya kadar direct exchange tanımladık, q1, q2, q3, q4 kuyruklarına bağladık. Şimdi deneyelim. Aynı ekranda “Publish message” kısmından Payload’una birşeyler yazarak ve Routing key değerini boş bırakarak “Publish message” ile mesaj yayınlayalım.

“Message published” mesajı çıkacaktır. Queues ekranından kontrol edersek mesajın q1 ve q2 kuyruklarına yayınladığını görebiliriz.

Routing key değerine renk:mavi yazarak mesaj yayınlaması yaparsak sadece q3 ve q4 kuyruklarına mesaj yönlendirecektir.

Kuyrukları kontrol ettiğimizde gönderilen mesajdaki routing key ile eşleşen q3 ve q4 kuyruğuna mesajın iletildiğini görebiliriz.

Özetle direct exchange tipinde bir exchange tanımladığımızda routing key değeri kullanılarak gelen mesajın hangi kuyruklara yönlendirileceğini tanımlayabiliriz. Mesajdaki routing key değeri ile exchange-queue binding tanımındaki routing key değeri eşleşen kuyruklara mesaj iletilmektedir.

Fanout Exchange

Gelen mesajların bağlı tüm kuyruklara dağıtılması için kullanılan exchange çeşididir. Mesajlar tüm alıcılara iletilir yani broadcast yapar. Queue ile Exchange arasında bağlantı kurmak gereklidir. Bunun için binding tanımı yapılır. Routing key dikkate alınmaz. Gelen mesaja routing key verilsin veya verilmesin bind edilmiş tüm kuyruklara bunu iletir.

Topic Exchange

Gelen mesajların hangi kuyruklara dağıtılacağına karar verirken, mesajın routing key değeri ile bağlı kuyrukların routing key desenlerini(pattern) karşılaştırır. Yani gelen mesajın routing key değerini alır, bind edilmiş kuyruğun routing key tanımlarını da alır ve aşağıda açıklayacağım kurallara göre mesajın hangi kuyruklara dağıtılacağına karar verir. Özetle multicast yapar diyebiliriz.

Topic exchange kullanımlarında kuyrukların exchange ile bağlantısında(bind) Routing key tanımlaması yaparken * ve # karakterlerini kullanabiliriz. Bunları regular expression pattern’leri gibi düşünebilirsiniz. Eğer * kullanılırsa sadece bir kelimeyi kıyaslar ve herhangi bir kelime olabilir anlamına gelir. Ve # kullanılırsa öncesi veya sonrası tüm kelimeler için herhangi biri olabilir anlamına gelir. Birazdan örnekte daha ne göreceğiz.

Öncelikle kelime kıyaslaması nedir? Buradan devam edelim. Mesajın routing key değeri . işareti ile ayrılmış kelimeler içermelidir. Kıyaslama yapılabilmesi için kelimelerin arasına . işareti konulur.

Örnek olarak kirmizi.kalem değerini routing key olarak gönderdiğimizi düşünelim. Routing işleminde ilk kelime olan “kırmızı” ve ikinci kelime olan “kalem” ayrı ayrı işleme alınıp hangi kuyruktaki pattern ile uyuşuyor kıyaslaması yapılacaktır. q1 adında bir kuyruğu ex-topic isminde tipi topic olan bir exchange açıp bağlayalım. Bağlarken routing key olarak *.kalem verelim. Bu tanımda ilk kelime ne olursa olsun ikinci kelimesi kalem olan mesajlar q1 kuyruğuna düşer. Şimdi q2 kuyruğunu oluşturup routing key değerini kirmizi.* verelim. Böylece ilk kelimesi kırmızı olan tüm mesajlar q2 kuyruğuna düşer. Gelen mesajdaki routing key değerikirmizi.kalem ise mesajımız her iki q1 ve q2 kuyruklarına da düşer. Eğer gelen mesaj tukenmez.kalem ise sadece q1 kuyruğuna düşecektir.

Diğer kıyaslama karakteri # demiştik. Bu da öncesinde veya sonrasındaki kelimelerin tümüne geçiş izni verir. Başka bir örnekle devam edelim. Yine ex-topic isminde bir topic exchange’imiz olsun. Ve isimleri “tshirt”, “pamuklu-tshirt”, “mavi”, “sentetik” isimlerinde dört kuyruğumuz olsun. Amacımız gelen mesajdaki routing key değerine göre tshirt ile başlayan tüm mesajları “tshirt” kuyruğuna, pamuklu tshirt’leri “pamuklu-tshirt” kuyruğuna, mavi renkteki ürünleri “mavi” isimli kuyruğa vs. yönlendirmek olsun. Binding tanımı yaparken örneğin tshirt ile başlayanların tümünü “tshirt” kuyruğuna göndermek için routing pattern olarak tshirt.# veririz. Veya tüm sentetik ürünleri “sentetik” kuyruğuna atmak için #.sentetik veririz.

Gelen mesajdaki routing key değeri “tshirt.mavi.pamuklu” olduğunu düşünelim. Mesajı karşılayan ex-topic, bağlı olan kuyruklardaki routing key pattern’lerini alır ve kıyaslama sonucunda “tshirt” kuyruğuna, “pamuklu-tshirt” kuyruğuna ve “mavi” kuyruğuna mesajı iletir.

Headers Exchange

Mesaj başlığındaki(headers) tanımları kullanarak yönlendirme yapan exchange tipidir. Routing key tanımları dikkate alınmaz/kullanılmaz. Headers exchange’in baktığı mesaj başlığı tanımlarına headers attribute denir. Headers attribute, birden çok olabilir. Gelen mesaj başlığındaki tanımların(header attribute) tümünün uyuştuğu veya en az birinin uyuştuğu durumları kurala bağlamak mümkündür. Eğer headers attribute tanımlarının tümü karşılansın isteniyorsa headers tanımlarına x-match = all değeri eklenir. Veya sadece biri bile karşılansa yeterli ise x-match = any değeri eklenir.

Örnek üzerinden daha açık görebiliriz. Öncelikle ex-headers isminde tipi headers olan bir exchange oluşturalım. Devamında binek-satis, satilanlar ve ticari-satis isminde üç kuyruk oluşturalım. Bunları ex-headers ile bind edeceğiz. Queue ile bind işlemlerinde Arguments kısmında her queue için aşağıdaki tanımları yapalım.

Yukarıdaki tanımlar şöyle çalışacaktır: Gelen mesajın header özelliklerinde islem:satis ve tip:binek değerlerinin ikisini de sağlayanlar binek-satis kuyruğuna gönderilir. Header’da durum:satildi veya islem:satis değerlerinden birini içerenler satilanlar kuyruğuna gönderilir. Header’da islem:satis ve tip:ticari değerlerinin ikisini de içerenler ticari-satis kuyruğuna gönderilir.

Özet

Exchange tipleri ilgili buraya kadar anlatılanların kısa bir özetini yapmak gerekirse. Direct exchange, gelen mesajların routing key değerleri ile bağlı kuyrukların routing key değerlerini kıyaslar ve eşleşenlere mesajları iletir. Fanout exchange, gelen mesajları bağlı tüm kuyruklara iletir. Topic exchange, gelen mesajları routing key değerleri ile bağlı kuyrukların routing key desenleri arasında karşılaştırma yapar fakat burada * ve # karakterlerini kullanarak dağıtımı kurallara göre yapar. Headers exchange, gelen mesajların header tanımlardan yola çıkarak bağlı kuyruklardaki header tanımlarının değerlerini karşılaştırır ve iletimi bu kurallara göre yapar.

Kodlama Örneği

Öncelikle mesaj gönderen Publisher örneğini devamında ise kuyruğu dinleyen Consumer örneğini kodlayacağız. Kodlama örneğini ilk olarak Direct Exchange için yapacağız. Projemizi oluşturalım ve RabbitMQ.Client paketini ekleyerek başlayalım.

mkdir RabbitMQ
dotnet new console -n Publisher
cd Publisher
dotnet add package RabbitMQ.Client 

Publisher projesindeki Program.cs içindeki kod aşağıdaki gibi olsun.

Direct exchange konusunda verdiğim örneğin koda dökülmüş hali, görüldüğü gibi RabbitMQ.Client ile exchange, queue vs. tanım yapmak veya silmek oldukça basit. Yukarıda exchange tanımını yapıp iki queue bind ettik ve iki mesaj gönderip test ettik ve sonra Console’dan bir tuşa basılmasını bekleyip oluşturduğumuz exchange ve queue’leri sildik. (Not: VS Code kullanıyorsanız ve ReadKey için hata alıyorsanız launch.json içerisinde “console”: “integratedTerminal” tanımını yapınız.)

Consumer örneğiyle devam edelim. RabbitMQ klasörümüze dönelim ve aşağıdaki komutlarla projeyi oluşturalım.

cd ..
dotnet new console -n Consumer
cd Consumer
dotnet add package RabbitMQ.Client

Yukarıdaki kod örneğinde BasicConsume ile q1 isimli kuyruk dinlemeye alınır ve bu kuyruğa bir mesaj ulaştığında consumer nesnesindeki Received event handler’ı içinde konsola mesaj içeriği yazdırılır. Publisher ve Consumer projelerini çalıştıralım, her biri için bir terminal window açıp dotnet run komutu ile çalıştıracağız.

cd Publisher
dotnet run

cd Consumer
dotnet run

Kod kalabalıklığı olmaması için tüm exchange ler için kod örneği eklemeyeceğim. Fanout Exchange için benzer kodlar kullanılabilir, bilindiği gibi orada sadece bind edilen kuyruklara yönlendirme yapıyor ve routing key’in bir önemi yoktu. Bu nedenle BasicPublish içinde routingKey değerini string.Empty ile boş geçiyoruz. Topic Exchange için de benzer bir durum sözkonusu. Orada da BasicPublish routingKey değeri . (nokta) ile ayrılmış olmalı ve queue tanımlarken pattern( * ve # ile) verebiliyorduk. Yani kodlama olarak değil içerik olarak değişenler olduğundan onları sizin denemenizi tavsiye ederim.

Headers Exchange ile devam edelim. Öncelikle projemizi oluşturalım.

cd ..
dotnet new console -n HeadersPublisher
cd HeadersPublisher
dotnet add package RabbitMQ.Client

QueueBind ile header key-value tanımlarını taşıyan Dictionary ekliyoruz. Artık BasicPublish yaparken properties parametresine geçeceğimiz header değerleri bu tanımlarla karşılaştırılarak ilgili queue’ya iletilecektir.

Mesajların Okundu Olarak İşaretlenmesi (ACK:Acknowledgment)

Şimdiye kadar verdiğim örneklerde consumer tarafında autoAck parametresini true olarak verdik. Bu kullanımda RabbitMQ, mesajı consumer’a iletir ve işlenmesini beklemeden okundu olarak işaretleyerek kuyruktan siler. Kuyruktan silmesi için işlenmesini beklemez iletilmesi yeterlidir. Fakat bu her zaman istenilen bir çalışma şekli olmayabilir.

Olası çökme veya hata durumlarında veri kaybı yaşanmaması önemlidir. Örneğin consumer sunucusu çökerse, ona iletilen ve o anda işlenmekte olan veya işlenmeyi bekleyen mesajların tümü kaybedilebilir. Böyle durumlara karşı manuel ack yöntemi önerilir.

Veya bir consumer problem yaşadığında yeni bir consumer açıp mesajların kayıp yaşanmadan yeni açılan consumer’dan işlenmeye devam etmesini isteyebiliriz. O nedenle RabbitMQ tarafındaki mesajın silinmesi sürecinin iyi analiz edilip tanımlanması gerekir.

Mesajların consumer tarafından işlenmesini bekleyip sonrasında bir onay ile kuyruktan silinmesini sağlamak için ack işlemini manuel yapabiliriz demiştik. Bunun için autoAck parametresini false verip mesaj işlendikten sonra BasicAck metoduyla okundu olarak işaretleriz.

Aşağıda uygulama kod örneği verilmiştir.

Kod örneğinde BasicAck metoduna gelinceye kadar mesaj kuyrukta bekletilir.

Sık Kullanılan Tasarımlar

RabbitMQ tarafından sunulan teknik çeşitliliğin farklı şekillerde kullanılması mümkün. Bu konuda tasarım kalıplarına uygun ve genel kullanımdaki birkaç örnekle devam edeceğiz.

Work Queue / Task Queue / Competing Consumers Pattern

Mesaj kuyruğundaki mesajların birden çok consumer tarafından paylaşılarak işlenmesine olanak tanıyan tasarımdır. Mesajları paralel olarak olarak işleyebilmek iş yükünün dengelenmesi, yatay olarak ölçeklenebilirlik(yeni consumer’lar ekleyerek), kaynakların optimize kullanılabilmesi gibi avantajlar sunar. Bu tasarım deseninde her mesaj boştaki bir consumer tarafından işlenmektedir.

Mesaj kuyruğundaki birikmelere karşı hızlı ve ölçeklenebilir çözüm üretebilmek, gerekmediği durumlarda da fazladan consumer bulundurmamak yani kaynakların verimli kullanımı bu tasarımın avantajlarıdır.

Örnek üzerinde gidelim. Diyelim ki e-ticaret uygulamanız var ve indirim günlerinde çok fazla işlem gerçekleşiyor. Arkaplanda kurguladığınız RabbitMQ kuyruğunda çok fazla mesaj birikiyor ve bunların eritilmesi gerekiyor ama bir adet consumer bağlamışsınız ve yetişemiyor. Böyle senaryolarda sisteminizi tasarlarken consumer sayılarının artırılıp azaltılabilmesine imkan verecek esnekliği uygulayabilirseniz iş yükünün fazla olduğu zamanlarda yeni consumer’ları devreye alarak işlemlerin tamamlanma sürelerini kısaltabilirsiniz.

RabbitMQ kuyruktaki mesajları consumer’lara dağıtırken standart olarak Round Robin algoritması kullanır yani sırayla dağıtır. Detayına gireceğiz, şimdi kod örneği üzerinden devam edelim. Publisher ve Consumer projesi oluşturup aşağıdaki kısa kodlamayı yapalım.

Publisher projesi Program.cs içeriği:

Publisher projesindeki Program.cs içerisindeki döngüde her saniye q1 isimli kuyruğa yeni bir mesaj gönderiliyor.

Consumer projesindeki Program.cs :

Consumer projesinde ise q1 isimli kuyruk dinlenerek gelen mesajlar ekrana yazdırılıyor. Dışarıdan argüman olarak saniye bilgisi verilirse o kadar saniye bekleme yapıyor sonrasın mesaj işlemeye devam ediyor.

Şimdi bu kodlamayı kullanarak bir publisher ve iki adet consumer çalıştıralım. Publisher her saniye bir mesaj üretip kuyruğa göndersin. Consumer’lar da her işlemde 2 saniye beklesin. Komut satırından aşağıdaki gibi çalıştıralım.

İlk consumer 1,3,5,… no’lu mesajları alırken ikincisi 2,4,6,.. no’lu mesajları işleme almış. RabbitMQ kuyruktaki mesajları dağıtırken Round Robin uyguladığı için sıralı dağıtıldı. Şimdi ilk consumer’ın bekleme süresini 5sn yapalım, ikincisi 2sn olsun. Tekrar çalıştıralım.

Görüldüğü gibi mesajların dağıtılmasında bir değişiklik yok. Sırayla dağıtılıyor. Fakat ilk consumer yavaş olduğundan yetişemiyor, geride kalıyor. Bu nedenle ilk consumer’a atanan fakat yavaş olmasından dolayı işlenemeyen mesajlar var bunlar kuyrukta birikiyor.

Yavaş olan consumer’ı beklediğimiz için kuyrukta birikme yaşanıyor, oysa işini daha kısa sürede bitirip boşta kalan ikinci consumer’a mesajları yönlendirmek daha verimli olacaktır. RabbitMQ’ya mesajı işleyip onaylayana kadar(ack) yeni bir mesaj göndermemesini söyleyebiliriz. Böylece RabbitMQ kuyruktan sıradaki mesajı meşgul olmayan bir sonraki consumer’a gönderecektir. Bunu da BasicQos metodu ile sağlarız. PrefetchCount: 1 vererek RabbitMQ’ya bir consumer’a aynı anda birden fazla mesaj iletmemesini söyleriz.

Consumer kodumuzun son durumu aşağıdaki gibi olur.

Tekrar çalıştırıp denersek aşağıdaki çıktıyı üretecektir.

Publish/Subscribe Pattern

Bu tasarım kalıbında, kuyruktaki bir mesaj birden çok consumer’a iletilmektedir. Önemli nokta kuyruğa gönderilen bir mesajın o sırada bağlı olan tüm consumer’lara iletilmesidir. Kaç adet consumer varsa o kadar kuyruk oluşur ve mesaj kopyalanarak kuyruklara iletilir. Bunu sağlamak için Fanout Exchange kullanılır.

Kullanım alanlarına geçersek. Örneğin mikroservislerin çalıştığı bir ortamda gelen bir mesajın tüm mikroservislere yayınlanması istenebilir. Daha somut örnekle; Web sitenizde yeni bir kullanıcı açma işlemi gerçekleşiyor olsun. Yeni kullanıcı açıldıktan sonra bir dizi işlem yapılacaktır ve bu işlemler birbirlerinden bağımsız gerçekleşebilir. Açılan kullanıcıya şifresini gönderen bir mikroservis, işlem loglarını kaydeden bir mikroservis vb. servislere yayınlanan mesajın iletilmesi gerekecektir. Bu örnekteki gibi aynı mesajın birden çok consumer’a yayınlanması ihtiyacı için pub/sub pattern kullanılabilir. Böylece producer’ın consumer’lara herhangi bir bağlılığı olmadan(decoupling) mesaj iletimini sağlayabilir, yeni consumer’ların sisteme kolayca eklenip çıkarılması esnekliğine sahip olabiliriz.

Kod örneği ile devam edelim. Önceki örneklerdeki basit yapımızı tekrar kurup Publisher ve Consumer projeleri oluşturalım. Publisher projesindeki Program.cs içeriği aşağıdaki gibi olsun.

Publisher sadece “ex-pubsub” isminde bir Fanout Exchange oluşturup her saniye bir mesaj gönderiyor. Consumer projesindeki Program.cs kodları aşağıdaki gibi olsun.

Burada ise consumer adını argümandan aldık ve “ex-pubsub” exchange’ine bağlanıp consumer adıyla bir kuyruk oluşturduk. Çalıştırıp deneyelim. iki consumer açalım ve isimleri A ve B olsun.(dotnet run Ave dotnet run Bile).

Görüldüğü gibi producer tarafından exchange’e gönderilen mesajlar iki consumer’a da dağıtılmakta. Örnekteki iki consumer yerine daha fazla consumer açarak deneyebilirsiniz. Kod satırında bıraktığım açıklamaya dikkat edilirse consumer’ların kapanması durumunda kuyrukların otomatik silinmesi istenilirse queueName = channel.QueueDeclare().QueueNameile tanım yapılabilir. Bu şekilde kuyruk tanımlandığında consumer ile kuyruk bağlantısı koptuğunda kuyruk kalıcı olmayacak ve silinecektir.

Request Reply Pattern

Diğer adıyla Request/Response Pattern olan bu tasarım kalıbında bir servis başka bir servise mesaj gönderir ve yanıtını aldıktan sonra işleme devam eder. Bu tasarım kalıbının RabbitMQ ile uygulanışında producer/consumer ayrımını yapmayacağız bunun yerine client/server olarak ayıracağız. Mesajı gönderen aynı zamanda sonucunu da bekleyeceğinden producer aynı zamanda bir consumer olmak durumunda veya tersi consumer aynı zamanda bir producer olacak. Şekil üzerinden daha açık görülebilir.

Bir client yani istemci, sunucudan yanıtını beklediği bir mesaj gönderir ve mesaj kuyruğa eklenir. Dinleme yapan sunucu mesajı kuyruktan alır ve sonucunu mesaj sonuçlarının olduğu başka bir kuyruğa ekler. İstemci sonucu kuyruktan alır ve süreç tamamlanır.

Server gelen bir mesajı işledikten sonra sonucunu hani kuyruğa atacağına nasıl karar veriyor? Client ise kuyruğa gelen mesajlar arasında gönderdiği mesajın sonucunu nasıl ilişkilendiriyor? Gelen mesaj hangi mesajın sonucu bunu nasıl bulabiliriz? Sorularına cevap vermemiz gerekir. Mesajlaşmayı başlatan yani örneğimizdeki client, gönderdiği mesaj içerisine tanımlayıcı bir değer koyar buna CorrelationId denir. CorrelationId değeri server tarafından alınır ve sonuç olarak üretilen mesaj içerisine de eklenir bu şekilde hangi mesajın sonucu olduğu ayrılabilir. Client tarafından gönderilen mesaj içerisine ayrıca bu mesajın sonucunun hangi kuyruğa atılacağı bilgisi de eklenir. Bu da ReplyTo ismiyle verilir.

Kod örneğiyle devam edelim. Server ve Client isminde iki projemiz olsun. Server projesindeki Program.cs kodları aşağıdaki gibi olsun.

Server, “request_queue” isimli kuyruğu dinler. Mesaj geldiğinde CorrelationId ve ReplyTo parametrelerini okur. ReplyTo ile verilen kuyruğa “This is reply message” mesajını gönderir. Kod açıklamalarından detay takip edilebilir.

Client projesindeki Program.cs kodları:

Client, “request_queue” kuyruğuna “**hi from client**” mesajını gönderir. Bu mesaj parametrelerine CorrelationId ve ReplyTo değerlerini ekler. ReplyTo parametresinde verdiği isimle açtığı kuyruğu dinlemeye alır. Server tarafından ReplyTo kuyruğuna bir mesaj gönderildiğinde bu mesajı alır ve ekrana yazdırır.

Yukarıdaki Client ve Server kodlarını ayrı terminal ekranlarında çalıştırdığımızda aşağıdaki gibi çıktı üretecektir.

RabbitMQ, kullanım alanlarının çeşitliliği, ihtiyaçlara yönelik üretilen çözümlerin ve teknik detayların fazla olması nedeniyle geniş bir konu. Bu yazıdaki amacım genel bir bakışı vermek ve teknik detaya boğmadan anlaşılabilir olmaktı. Umarım verdiğim bilgiler faydalı olur.

Okuduğunuz için teşekkürler.

Engin Ünal

JSON Web Token Nedir? Detaylı inceleyip WebApi ve .Net tarafındaki kullanım örneği ile yazıyı sonlandıracağız.

JWT yani JSON Web Token, verilerin taraflar arasında(alıcı-verici veya istemci-sunucu vb. olabilir) güvenli iletilmesi için tanımlanmış açık bir standarttır. Bu bilgiler dijital olarak imzalandığı için doğrulanabilir ve değiştirilmeye karşı güvenlidir. İmzalama için simetrik bir anahtar — Secret Key — (HMAC algoritmasıyla) veya Özel/Genel Anahtar Çifti — Private/Public Key Pair — (RSA veya ECDSA algoritmasıyla) kullanılabilir.

Ağırlıklı olarak kullanım alanları; Kimlik doğrulama, servis güvenliği, kaynak erişimi yetki kontrolü, servisler arası iletişimde güvenli iletişim ve mesajın bütünlüğünün garanti edilmesi durumu olarak özetlenebilir.

Bu yazıda örnek olarak seçeceğim kullanım ise bir webapi projesindeki kimlik doğrulama ve api erişim kontrolü olacaktır.

JWT İç Yapısı

JSON Web Token üç ana parçadan oluşmaktadır. Bunlar Header, Payload ve Signature olarak sıralanabilir.

Bu üç veri katmanı Base64 formatındadır ve aralarında “.” (nokta) ayracı vardır. Aşağıdaki örnekte jwt.io sitesindeki decoder ile token ve içeriği gösterilmiştir.

Header

Header verisi için genel olarak iki alan ön plana çıkmaktadır.

• alg : İmzalama veya şifreleme algoritması. (HS256, RS256, ES256)
• typ : Token’ın tipi yani JWT.

{
 “alg”: “HS256”,
 “typ”: “JWT”
}

Algoritma seçimi nasıl yapılır? Bunu Signature konusu devamında inceleyeceğiz.

Payload

Payload, token içindeki verinin taşındığı alandır. İçinde claim yapıları bulunur. Aynı header gibi JSON formatındadır. Payload içindeki claim’lerin bazıları ön tanımlı veya kayıtlı olmakla birlikte ihtiyaca göre kullanıcı tanımlı claim’ler de eklenebilir. Önemli olan kayıtlı bir claim ile aynı isimde kullanmamaya dikkat edilmelidir(detay). Kayıtlı claim’lerden bazıları ve açıklamaları aşağıda listelenmiştir. Bunlar zorunlu değildir fakat kullanılması standardizasyon açısından önerilir.

• iss : Issuer — Token’ı oluşturan veya yayınlayıcının adı.
• sub : Subject — Alıcı. Token’ın kim için oluşturulduğu bilgisini tutar.
• aud : Audience — Hedef kullanıcı, alıcı. Sadece buradaki kullanıcılar tarafından kullanılabilir.
• exp : Expiration Time — Son kullanım tarihi.
• nbf : Not Before — Verilen süreden öncesinde geçerli değil bilgisini tutar.
• iat : Issued At — Token oluşturulma zamanı.
• jti : JWT ID — Benzersiz kimlik değeri.

Signature

JWT verisinin imzasını taşıyan bölümdür. Burada token’ın imzası bulunur. Token’ın üreticisinin ve token bütünlüğünün kontrolünün yapılabilmesi signature verisi ile mümkün olmaktadır. Örneğin HMAC algoritması ile imzalama yapmak istersek aşağıdaki gibi bir yol izleriz.

HMACSHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  SECRET_KEY
)

Şimdi biraz algoritma detaylarına ve seçiminin nasıl yapılabileceğine değinelim.

Algoritma Seçimi

İmzalama işlemlerinde, jwt içindeki header ve payload verileri alınır ve hash işleminden geçirilir devamıda bu veri imzalanır. Hash nedir? Öncelikle bunu hatırlayarak başlayalım.

Hash, bir veriyi boyutuna bağlı olmadan hep aynı uzunlukta bir çıktıya çeviren yani verinin parmak izini alan matematiksel fonksiyonlardır. Tek yönlü şifreleme yapar. Hash değerinden orjinal veriye ulaşmak mümkün değildir. Bu nedenle genellikle veri bütünlüğü kontrollerinde tercih edilir. Hash değerinin alınmasının önemli nedenlerinden biri de büyük boyutlu verinin tamamının şifrelenmesi yerine hash değerinin hesaplanarak çok daha verimli kontrollerin yapılabilmesini sağlamaktır.

Örneğin bir dosyanın değişmemesini istiyoruz ve bunu kontrol etmemiz gerekiyor. Bunun için hash değerini alıp saklarız. Eğer dosyada değişiklik olursa dosyanın güncel hash değerini hesaplatıp eskisiyle kıyaslayarak dosyanın orjinal olup olmadığını anlayabiliriz. Hash verisi hep aynı uzunlukta olacağından yani hash’i alınmak istenen verinin boyutundan bağımsız olacağından oldukça verimli bir yöntemdir.

Hash algoritması için JWT tarafında genellikle SHA-256, SHA-384, SHA-512 gibi seçenekler vardır bunlar SHA-2 hash algoritma ailesindendir. Buradaki numaralar üretilen hash verisinin boyutunu verir.
Örneğin SHA-256, 256-bit’lik bir hash üretirken SHA-512 ise 512-bit’lik hash üretmektedir.

JWT tarafında da hash işlemleri token bütünlüğünün kontrol edilmesi ve token üreticisinin doğrulanması için kullanılır. Konunun başında belirttiğim gibi token hash değeri alınır ve bu veri şifreleme algoritmasından geçirilerek şifrelenir ve token imzası yani Signature bölümüne yazılır.

İmzalama için kullanılabilecek algoritmalar kullanım alanlarına ve güvenlik seviyelerine göre farklılıklar göstermektedir.

HMAC

Simetirk şifreleme algoritmasıdır. Hash-based Message Authentication Codes kelimelerinin kısaltılmışıdır. Hash algoritması olarak HS256 için SHA-256, HS384 içi SHA-384 ve HS512 için SHA-512 kullanılır. Simetrik kriptografi ile anahtar(Secret Key) ve hash fonksiyonunu alarak mesajın güvenlik kodunu oluşturur.

İmzayı oluşturmak ve doğrulamak için aynı anahtarı kullanır. Anahtarın, imzalayıcı ve doğrulayıcı arasında paylaşılması güvenli olmadığından genellikle iç kullanımlarda tercih edilir.

RSA

Asimetrik şifreleme algoritmasıdır, yaygın olarak kullanılır. Adını bulucularının(Rivest–Shamir–Adleman) soyisimlerinin baş harflerinden almıştır. Temelindeki mantık bir anahtar ile şifrelenen verinin tekrar aynı anahtar ile çözülmesine ihtiyaç duymamasıdır. Bu anahtarlar private key ve public key çiftidir. Public key ile şifrelenen veri private key ile çözülebilir.
İmzalama işlemlerinde ise private key ile imzalanan veriler public key ile doğrulanır. Böylece private key’in karşı tarafa verilmesi gerekemez.

Genel anahtar kriptografi standardı(Public Key Cryptography Standard 1- PKCS #1) RSA algoritması kullanımına ilişkin şifreleme şemaları, formatları vs. bir çok standart belirlemiştir.
RSASSA’da bu tanımlamalardan biridir, RSA imzalarının ve doğrulamasının standartlarını belirler. RSASSA — RSA Signature Scheme With Appendix.

Burada önemli nokta RSASSA PKCS1 v1.5 ile deterministik imzalama yapılmaktadır.

Bu ne demek? Yani aynı header ve payload değerlerine sahip JWT imzaları aynı olacaktır.

JWT için seçenekler:

• RS256: RSASSA PKCS1 v1.5 — SHA-256
• RS384: RSASSA PKCS1 v1.5 — SHA-384
• RS512: RSASSA PKCS1 v1.5 — SHA-512

İmzaların daha güvenli olmasına imkan tanımak için RSASSA-PSS seçeneği de mevcuttur. RSASSA-PSS, RSA’nın olasılıksal versiyonudur. Buradaki PSS, Probabilistic Signature Scheme kelimelerinin kısaltılmışıdır.
Kriptografik olarak rastlantısal numara üreteci(RNG-Random Number Generator) kullanır. Bu nedenle imzalanan veri içeriği değişmese de imza değişir. Yani aynı header ve payload verisine sahip JWT her imzalamada farklı bir imza değeri üretir.

Daha güvenli olması nedeniyle RSASSA-PSS’in kullanımı önerilmektedir.

JWT için seçenekler:

• PS256: RSASSA-PSS — SHA-256
• PS384: RSASSA-PSS — SHA-384
• PS512: RSASSA-PSS — SHA-512

ECDSA

RSA gibi asimetrik şifreleme algoritmalarından biridir. Adını Elliptic-Curve Digital Signature Algorithm kelimelerinin ilk harfnden alır. RSA’daki gibi asal çarpanlarını kullanmak yerine eliptik eğriler(y2 = x3 + ax + b) üzerinde inşa edilmiştir.

RSA’ya göre avantajları ise kırılma olasılığı daha düşük olmakla birlikte daha kısa şifre anahtarı kullanır bu nedenle imza boyutu küçüktür. Örneğin 256-bit’lik bir Elliptic-Curve anahtarının sağladığı güvenlik için RSA tarafında 3072-bit gereklidir. Artısı yanında eksisi de var. İmzalamada hızlı olsa da imza doğrulamada RSA’a göre daha yavaştır. Ek olarak rastlantısal sayı üretimi imzanın güvenliği açısından kritiktir. Bu noktada RSA daha iyidir.

JWT için seçenekler:

• ES256: ECDSA — SHA-256
• ES384: ECDSA — SHA-384
• ES512: ECDSA — SHA-512

Özet

Eğer JWT ile güvenlik gerektiren işlemler yapılmakta ise yani iç kullanım gibi daha düşük güvenlik seviyesi gerektiren bir kullanım değilse ES veya PS tercih edilmelidir. Bu noktada algoritmaların arasında seçim için daha detaylı düşünmek gerekir. Örneğin imzalama işleminin yavaş olması önemli değil fakat doğrulama işleminin hızlı olması önemli bir durum ise PS daha iyi bir seçim olacaktır. Veya imza boyutu küçük olmalı ise ES iyi bir seçim olabilir. HMAC gibi seçimler yani simetrik anahtar ile şifreleme çözümleri dış kullanımlar için önerilmez.

Kodlama örneğimizle devam edelim.

JWT & WebApi Örneği

Kodlama örneğimizde daha önceden hazırda tuttuğum temel bir webapi projesini kullanacağım. İsterseniz aşağıda paylaştığım linkten siz de aynı şekilde ilerleyebilirsiniz.

https://github.com/enginunal/AspNetJWT/tree/webapi-base

Bu webapi projesinde item tablosu var ve servisteki CRUD(Create, Read, Update, Delete) fonksiyonları ile tablodan okuma ve tabloya yazma gibi temel işlemler bulunuyor. Bunu da ItemsController ile yapıyoruz. Veritabanı olarak SqLite kullandım. Bu kısa tanıtımdan sonra amacımıza geçelim.

Item servisimize sadece izin verdiğimiz ve token sahibi olanların erişmesini istiyoruz yani güvenlik katmanı ekleyeceğiz. Bunu da JWT ile sağlayacağız. Öncelikle JWT kütüphanelerimiz ekleyelim.

dotnet add package Microsoft.AspNetCore.Authentication.JwtBearer --version 7.0.10
dotnet add package System.IdentityModel.Tokens.Jwt --version 6.32.2

appsettings.json dosyasında jwt tanımlarımızı yapalım. Bunları token üretirken kullanacağız.

"JwtTokenOptions": {
    "Issuer": "AspNetJWT",
    "Audience": "ItemsAud",
    "SigningKey": "simetrik sifreleme anahtari kullanacagiz",
    "Expiration": 3600
  }

Program.cs dosyasına aşağıdaki tanımları ekleyelim.

builder.Services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
    .AddJwtBearer(opts =>
    {
        byte[] signingKey = Encoding.UTF8
         .GetBytes(builder.Configuration.GetSection("JwtTokenOptions")["SigningKey"]);

        opts.TokenValidationParameters = new TokenValidationParameters
        {            
            ValidIssuer = builder.Configuration.GetSection("JwtTokenOptions")["Issuer"],
            ValidAudience = builder.Configuration.GetSection("JwtTokenOptions")["Audience"],
            IssuerSigningKey = new SymmetricSecurityKey(signingKey)
        };
    });
builder.Services.AddAuthorization();
//Swagger için gerekli tanımları da ekleyelim. Bunu swagger üzerinden
//token denemesini yapmak için ekledim. Postman kullanıyorsanız gerek yok.
builder.Services.AddSwaggerGen(c =>
{
    c.SwaggerDoc("v1", new OpenApiInfo { Title = "AspNetJWT", Version = "1.0" });
    c.AddSecurityDefinition("Bearer", new OpenApiSecurityScheme
    {
        Name = "Authorization",
        Type = SecuritySchemeType.ApiKey,
        Scheme = "Bearer",
        BearerFormat = "JWT",
        In = ParameterLocation.Header,
        Description =
          "JWT Authorization header using the Bearer scheme. \r\n\r\n Enter 'Bearer' [space] and then your token in the text input below.\r\n\r\nExample: \"Bearer 12345abcdef\""
    });
    c.AddSecurityRequirement(new OpenApiSecurityRequirement
    {
        {
            new OpenApiSecurityScheme
            {
                Reference = new OpenApiReference
                {
                    Type = ReferenceType.SecurityScheme,
                    Id = "Bearer"
                }
            },
            new string[] { }
        }
    });
});
//...
//...
//bunlar mutlaka aşağıdaki sırayla olmalı
app.UseAuthentication();
app.UseAuthorization();

Tanımlar bu kadar. Şimdi token üretimi yapabilmek için bir controller ekleyelim. Bunun adı TokenController olsun.

dotnet aspnet-codegenerator controller -name TokenController -async -api -outDir Controllers

TokenController.cs dosyamıza aşağıdaki metodları ekleyelim. (Not: Tabi burada constructor içinde IConfiguration config de enjekte edilmeli).

[HttpGet("{pwd}")]
public async Task<IActionResult> GetToken(string pwd)
{
    if (pwd != "123") return Unauthorized("Şifre geçersiz.");
    string token = GenerateToken();
    return Ok(token);
}

private string GenerateToken()
{
    var keyBytes = Encoding.UTF8.GetBytes(_config.GetSection("JwtTokenOptions")["SigningKey"]);
    var symmetricKey = new SymmetricSecurityKey(keyBytes);

    var signingCredentials = new SigningCredentials(
        symmetricKey,
        SecurityAlgorithms.HmacSha256);

    var claims = new List<Claim>()
    {
        new Claim("sub", "eunal"),
        new Claim("name", "engin unal")
    };

    var roleClaims = new List<Claim>()
    {
        new Claim("role", "readers"),
        new Claim("role", "writers"),
    };

    claims.AddRange(roleClaims);

    var token = new JwtSecurityToken(
        issuer: _config.GetSection("JwtTokenOptions")["Issuer"],
        audience: _config.GetSection("JwtTokenOptions")["Audience"],
        claims: claims,
        expires: DateTime.Now.Add(TimeSpan.FromSeconds(double.Parse(_config.GetSection("JwtTokenOptions")["Expiration"]))),
        signingCredentials: signingCredentials);

    var tokenData = new JwtSecurityTokenHandler().WriteToken(token);
    return tokenData;
}

Son durumda swagger görüntüsü aşağıdaki gibi olur.

Şimdi JWT üretimini denemek için GetToken metodunu çağıralım.

Gelen token’ı jwt.io da incelediğimizde:

Şimdi ItemsController class tanımının üzerine [Authorize] atribute tanımını ekleyelim. Artık token olmadan doğrudan ItemsController’daki herhangi bir metodu çağırdığımızda 401 Unauthorized hatası alacağız. Amacımız GetToken metodundan token üretip çağırmaktı, yukarıda aldığımız token ile deneyelim. Bunun için swagger sağ üst köşedeki Authorize’a tıklayıp açılan pencereden Value kısmına -> Bearer tokenbilgisiniyapıştırıyoruz.

Ve GetItems metodunu çağırdığımızda:

Sonuçları geliyor. Buraya kadar olan kısımda JWT kütüphanesini ekledik, tanımlarını gördük ve devamında simetrik anahtar kullanan HS256 algoritması ile şifrelenmiş token üretimini gerçekleştirdik ve son olarak denedik. Yazının sonuna doğru kullanım pratiğinde genelde merak edilenlerle devam edeceğim.

Audience Nasıl Çalışıyor?

Tanım dosyamızda yani appsettings.json dosyamızda issuer ve audience tanımlarımız vardı. Issuer, token üreticisinin bilgisini taşırken audience ise token’ın kullanıcısını belirlemekteydi. Örneğin bir token ürettik ve bunun her serviste değil de sadece bazı servislerde kullanılabilmesini istemekteyiz. Bu durumda audience tanımını kullanırız. Somut örnek üzerinden gidelim. Örnek projemizde mevcut tanımlarla token üretelim.

Tanımlar:

 "JwtTokenOptions": {
    "Issuer": "AspNetJWT",
    "Audience": "ItemsAud",
    "SigningKey": "simetrik sifreleme anahtari kullanacagiz",
    "Expiration": 3600
  }

Üretittiğimiz token:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJldW5hbCIsIm5hbWUiOiJlbmdpbiB1bmFsIiwicm9sZSI6WyJyZWFkZXJzIiwid3JpdGVycyJdLCJleHAiOjE2OTMyMzQ4MjYsImlzcyI6IkFzcE5ldEpXVCIsImF1ZCI6Ikl0ZW1zQXVkIn0.FjQkT5i7EDPQ1_2KsFI7i3YkL9hhB5HKSrnLeCRtwMs

Token içinde aud değeri:
"aud": "ItemsAud"

Bu token ile GetItems servisini çağırdığımızda çalışacaktır. Projeyi kapatıp appsettings.json içindeki Audience değerini “DenemeServis” olarak değiştirelim ve projeyi tekrar başlatalım. Mevcut token’ı Swagger UI’daki Authorize ekranından aşağıdaki gibi girelim ve GetItems servisini çağıralım.

Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJldW5hbCIsIm5hbWUiOiJlbmdpbiB1bmFsIiwicm9sZSI6WyJyZWFkZXJzIiwid3JpdGVycyJdLCJleHAiOjE2OTMyMzQ4MjYsImlzcyI6IkFzcE5ldEpXVCIsImF1ZCI6Ikl0ZW1zQXVkIn0.FjQkT5i7EDPQ1_2KsFI7i3YkL9hhB5HKSrnLeCRtwMs

Aşağıdaki hatayı alırız:

www-authenticate: Bearer error="invalid_token",
error_description="The audience 'ItemsAud' is invalid" 

Servisimiz “DenemeServis” aud değerini bekliyor ama token içindeki değer “ItemsAud” olarak geldiğinden bu token bu servis için üretilmemiş ve ValidateAudience kontrolünden geçemiyor. (Not: Biz Program.cs içinde TokenValidationParameters altında ValidateAudience parametresini tanımlamadık bu nedenle default tanımıyla yani ValidateAudience=true olarak çalıştı). Yukarıdaki örnekte tek proje üzerinden anlatmaya çalıştım ama size önerim iki farklı web api projesi oluşturup birbiri ile haberleşmesinde bu parametreleri değiştirerek denemenizdir.

Şimdiye kadar anlatılanlarla ilgili kod örneğini aşağıdaki repo’dan inceleyebilirsiniz.

https://github.com/enginunal/AspNetJWT/tree/webapi-jwt-symmetric-hmac

Asimetrik Anahtar İle JWT Üretimi Nasıl Yapılır?

Simetrik anahtara göre çok daha güvenli bir yöntem olan asimetrik anahtar şifrelemesinin nasıl yapılacağını inceleyelim. Asimetrik şifreleme algoritması olarak PS256 (RSASSA-PSS — SHA-256) kullanacağım. Öncelikle Private/Public Key çiftine ihtiyacımız olacak. Bunu üretip appsettings.json içerisinde aşağıdaki değişikliği yapıyorum. (Not: Private Key en üst düzeyde korunması gereken bir veridir config dosyaları, proje dosyaları, kodlar vb. ortamlarda tutmayınız.)

{
  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "Microsoft.AspNetCore": "Warning"
    }
  },
  "AllowedHosts": "*",
  "ConnectionStrings": {
    "ItemsConnection": "Data Source=ItemsDb.db"
  },
  "JwtTokenOptions": {
    "Issuer": "AspNetJWT",
    "Audience": "ItemsAud",
    "Expiration": 10,
    "PrivateKey": "MIIEpAIBAAKCAQEA42x8DXg7KuqaIiQVAktrUpSBfnHfNpZBZrVqhk676oF0V9Jo4R9S/ML+t6W6/3jLfYriwmJAUK6i5XihKijYcGsgqbDnk7ymD9sX6JQi+7YviQdNiPPHlbd6ULxwaFRp8VRoeHkJwz7cb1S46I4KXjSDLzg7V9UoILllvfwkw2g5HmukQCwirOPTfJU4X6W0F8Cc6KYWILGMWoL3L965JxXrSBLUAynMw2XiuudWbAirS5H6aVM58QP5bhO884azLCsgTmQr78EHEtY3KuopMR3h607n8UB0SsaBXc+suN/FMFStLlIktej1KpZjPOQYplFVb1Za4qm550W3+vA3uQIDAQABAoIBAAe/tYZb92Ah+Dh7lD+sxC5fIv5k8N8SRY4zVjrXSe3WlVk8sRgikhhMqJMnUXTM79oKNmm7IUfee2xoLM2b8Kv76nP9tBZDkkDuDSV+jqaW8Y2wswKck8tVIhTIJuhXH/j6EEkyjpOZe7dLYrWByXamQWYFe3glqiVbS80qXzJNNVehJZKWE4C0p95zylLeve87z6ESRqEFEGGajg1fJ1y8HiBFLLIeo8PhXVQb+12Lli4nt4J5e26vGftZbEBc2hgHmy+z03lUIwlLjHtnSIMncdVNoDxpIGrk000tan77RMbUtEtoJDrDlT31nUihxghDKCo40M6dWIAn/mYF5QUCgYEA/BLInz+lgE3XLxVjDoTl5oln4d1iLfzmAx/D+AKeIsg+t4wEVFhJ8z35t9+Rgge2+0vdFIXt0cmCxT6xgvDwPB4tzRgihowierGs/LBA3ALChw87Km7ZhmZPNi0N1ZKOOQUpIEUVqquMRBuIPjGhX+/zrV9HD1EYgrhxllxnLbMCgYEA5vdnRFDufdMqYj274GgZBLPdRlmT9m+5fbBDczRzhRJuxwH0enmJ/pswpKtDi/233eLUAUQoFT9ncn/umLsJvpsmknXEjJu5j/+lhy5zMv37Zj0DZiV/tkmrNH2Z3fuVVHC0MRGKee/JQkAjq3498epkfHRgHallSzAlzxLdhuMCgYEAyffK4z29v2WfCkyah6GYCvUBVQlqhupg6RPkkqyWQ8wp5Cq9tU7gQZLgqKDrF0JTLFoGk1ET0ckhjCTFWeLuuVx82h2CXEefwKrnrbcS4LUdY9WiVEdo5rTGtuO2d+7rIWivIPn5eDvnMRLWQO7HG/VISxtR9kXF28coy47R5N0CgYB5IXmsT5G0tcG9wki9WXr9h2NeWO6LyW6L55yIWBLZ0J/+iRzx+roPqM5rHlMPoWID4cl0XI11D0qutz+oJDfpGi+xkkghwi4gwl/KtOa/8IofxZH5yWLgdGRw5AqFbEOWBIHMVjm817BCqabLcysDq/1FdDdQdx3jv/2kS22ZJwKBgQD6ZZc5imJ3R78wJt/PXkYXlqF/pvN83ImwSTGhyyDi+sLdhwqXhxGOoD9MlhR2Cv5bufzxYzsrRvpLt4szu6lE/9b+MjIjCjQqkGVxOcQjlTGuQg8Xd/pkhNePghD0aFKvzVThsNclhntiGkRvroG7eGW19gCWa71o54RzF6I5LQ==",
    "PublicKey": "MIIBCgKCAQEA42x8DXg7KuqaIiQVAktrUpSBfnHfNpZBZrVqhk676oF0V9Jo4R9S/ML+t6W6/3jLfYriwmJAUK6i5XihKijYcGsgqbDnk7ymD9sX6JQi+7YviQdNiPPHlbd6ULxwaFRp8VRoeHkJwz7cb1S46I4KXjSDLzg7V9UoILllvfwkw2g5HmukQCwirOPTfJU4X6W0F8Cc6KYWILGMWoL3L965JxXrSBLUAynMw2XiuudWbAirS5H6aVM58QP5bhO884azLCsgTmQr78EHEtY3KuopMR3h607n8UB0SsaBXc+suN/FMFStLlIktej1KpZjPOQYplFVb1Za4qm550W3+vA3uQIDAQAB"
  }
}

Program.cs dosyamızda aşağıdaki düzenlemeyi yapıyoruz.

Yukarıdaki değişkliğimiz gelen token’ı doğrulayabilmek için Public Key verisini geçmekten ibaret. Bunu da IssuerSigningKey ile sağlıyoruz. Son olarak TokenController.cs içinde aşağıdaki düzenlemeyi yapıyoruz.

Buradaki düzenleme de çok farklı değil. Token üretirken imzalama için kullanılacak Private Key verisini SigningCredentials’a geçmek gerekiyor bunu sağladık. Şimdi deneyelim. GetToken metodunu çağırdığımızda aşağıdaki gibi imzalı token verisini üretecektir.

eyJhbGciOiJQUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJldW5hbCIsIm5hbWUiOiJlbmdpbiB1bmFsIiwicm9sZSI6WyJyZWFkZXJzIiwid3JpdGVycyJdLCJhdWQiOiJJdGVtc0F1ZCIsImV4cCI6MTY5MzI5ODczMiwiaXNzIjoiQXNwTmV0SldUIiwiaWF0IjoxNjkzMjk4MTMyLCJuYmYiOjE2OTMyOTgxMzJ9.QTKs7obfYKON2NmXsaiuRw3VIg4H5SxU00leTc1SGPgL5F8yyMxSOyPtBq7J-ITDl1mo1SQMQzUcWeikazmwj-qrCmw4kBTZpvpVQIaI2q6fTvjbJor0ORhrvOCv8Cq9IMhRUry2FDeIi240Jwjtq0FNdKQ23uM_UAmp9x0jp5hIfgDkefSpZYqEvydPYubz7e-VbaVrE3j4txXZy-zzf9ACsHsceMTDlzCm95kHuE4cm1i2REVWNoOkuNONDk5fxicEWdww_iENB84s5au62yx28wnpd1jsmcPj0aipiiOY75tkGn5FNkktsnHCztONMK64XWGrZ5KlM7EAoPBkOA

Tekrar çağıralım.

eyJhbGciOiJQUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJldW5hbCIsIm5hbWUiOiJlbmdpbiB1bmFsIiwicm9sZSI6WyJyZWFkZXJzIiwid3JpdGVycyJdLCJhdWQiOiJJdGVtc0F1ZCIsImV4cCI6MTY5MzI5ODc5OSwiaXNzIjoiQXNwTmV0SldUIiwiaWF0IjoxNjkzMjk4MTk5LCJuYmYiOjE2OTMyOTgxOTl9.aRz89LOLmAjx16us2El96zrWt2ZFhDBQSy8MYme35m8v4va0Ke2-0-vY5n1QEQcZ-NpHP5st77U0Y5IUDFroJoObhfiPTtpe5Z34um_QsE8yunbwDWt4jT00M6YTuXyUw3AcXd77COMaiW67-omM4aqdZVAF6BEQ4cxspb2t7ozaBFGHLImtrLHOGkd6wwTV-Y_aKzdGqQTwFtZtn7VnE8CZW9aX_PmruX3gX61T38yWlpjbQG60euGA1m25Zv_uCuYp79rW4jSm_F9HAYYcoxQtAgmOk4TVT1fHsxW_CZYMwiaXE5Y4hdGteJZdI894ZmRpMmHiI7ir16Kq9TX40A

İkincisinde farklı imza üretti.

// ilk token imzası
QTKs7obfYKON2NmXsaiuRw3VIg4H5SxU00leTc1SGPgL5F8yyMxSOyPtBq7J-ITDl1mo1SQMQzUcWeikazmwj-qrCmw4kBTZpvpVQIaI2q6fTvjbJor0ORhrvOCv8Cq9IMhRUry2FDeIi240Jwjtq0FNdKQ23uM_UAmp9x0jp5hIfgDkefSpZYqEvydPYubz7e-VbaVrE3j4txXZy-zzf9ACsHsceMTDlzCm95kHuE4cm1i2REVWNoOkuNONDk5fxicEWdww_iENB84s5au62yx28wnpd1jsmcPj0aipiiOY75tkGn5FNkktsnHCztONMK64XWGrZ5KlM7EAoPBkOA
// ikinci token imzası
aRz89LOLmAjx16us2El96zrWt2ZFhDBQSy8MYme35m8v4va0Ke2-0-vY5n1QEQcZ-NpHP5st77U0Y5IUDFroJoObhfiPTtpe5Z34um_QsE8yunbwDWt4jT00M6YTuXyUw3AcXd77COMaiW67-omM4aqdZVAF6BEQ4cxspb2t7ozaBFGHLImtrLHOGkd6wwTV-Y_aKzdGqQTwFtZtn7VnE8CZW9aX_PmruX3gX61T38yWlpjbQG60euGA1m25Zv_uCuYp79rW4jSm_F9HAYYcoxQtAgmOk4TVT1fHsxW_CZYMwiaXE5Y4hdGteJZdI894ZmRpMmHiI7ir16Kq9TX40A

Kullandığımız algoritma RSASSA-PSS olması nedeniyle imzalanan veri değişmese de imza değişir ve daha güvenli imzalar üretebilir. Bununla ilgili bilgiyi bu yazının başlarında vermiştim. Şimdi token ile GetItems metodunu çağırarak testi bitirelim.

Herşey istediğimiz gibi çalışıyor. Asimetrik anahtar ile imzalama örneği için aşağaki github repo’dan kodları inceleyebilirsiniz.

https://github.com/enginunal/AspNetJWT/tree/webapi-jwt-asymmetric-ps256

Yazının sonuna geldik. Okuduğunuz için teşekkürler.

Engin Ünal

Expression Tree konusuna girmeden önce bazı temel kavramların üzerinden geçmemiz faydalı olacak. Yazdığımız kodların yapı taşları olan bu kavramlar expression, statement ve block olarak sıralanabilir.

Expression, bir değer döndüren kod parçasıdır. Değişkenler, değişmezler, fonksiyon çağrıları ve operatörlerden veya bunların kombinasyonundan oluşabilir. Bir expression başka bir expression’ı içerebilir birazdan değineceğiz.

Statement, uygulamanın çalıştırılması için gereken temel kod birimleridir. Örneğin C# için “;” arasındaki ifadeler birer statement örneğidir veya if/else, for/do/while, break/continue, throw/try/catch gibi yapılar statement örnekleridir.

Block ise “{}” arasındaki bölümlerdir. İçerisinde hiç statement olmayabilir veya birden çok statement içerebilir.

Asıl konumuz olan Expression Tree ile ilgili bilgiler vermeden önce Expression konusunu daha derinden incelemeliyiz. Expression ve örnekleriyle devam edelim.

Expression

.Net expression yapılarının karşılığı olarak System.Linq.Expressions namespace altında Expression base class bulunmaktadır. Bu kütüphaneyi kullanarak expression oluşturabilir veya mevcut bir expression’ı inceleyebiliriz. Bu class içerisinde NodeType ve Type property’leri bulunmaktadır.

NodeType, kullanılan expression’ın hangi tipte olduğunu verir. Expression kütüphanesi oldukça geniş bir tipte expression oluşturmaya imkan tanımakta. Oluşturulan expression’ın tipine ulaşmak için bu property kullanılır. Neler var denilirse örnek olarak BinaryExpression, ConstantExpression, ConditionalExpression, LambdaExpression ve daha bir çoğu sayılabilir. Bu özel tipler kullanılarak amaca yönelik özelleştirilmiş expression’lar oluşturulabilir.

Type, expression’ın taşıdığı tipi döndürür. Örneğin expression içinde int tipinde bir değer varsa Type dönüşü int olacaktır. Aşağıdaki örneğimizle bir expression oluşturarak özelliklerini inceleyeceğiz.

Örnek : İki sayıyı toplayalım.

int a = 1 + 2;

1 + 2 işleminde 1 ve 2 değerleri sabit değer expression, toplama işlemi ise ikili işlem(binary) yapan bir expression olarak tanımlanır.

ConstantExpression exp1 = Expression.Constant(1, typeof(int));
ConstantExpression exp2 = Expression.Constant(2, typeof(int));
BinaryExpression expA = Expression.Add(exp1, exp2);

Yukarıdaki üç satırlık kodda 1 ve 2 değerlerini taşıyan exp1 ve exp2 expressionlarını aldık, toplama işlemi(Expression.Add) uyguladık ve bu işlemin sonucunda BinaryExpression tipinde expA ismini verdiğimiz expression’ımızı ürettik.

BinaryExpression’lar parametre olarak iki expression alır(left, right) ve bunlara uygulanacak işlemin operatör bilgisini(NodeType) tutar. Aritmetik işlemler (toplama, çarpma, bölme, üs alma vs.), kıyaslama işlemleri(eşit, eşit değil, büyük, küçük), bit seviyesi işlemleri(and, or, exor) gibi işlemler gerçekleştirilebilir.

Örneğin yukarıdaki kodlamadaki expA.NodeType değerine bakıldığında Add görülecektir. Expression.Add yerine Expression.Multipy olsaydi yani toplama yerine çarpma yapsaydık NodeType değeri Multiply olarak gelecekti.

Örnek : Diğer örnekle devam edelim, “merhaba” kelimesini büyük harfe çevireceğiz(string.ToUpper).

MethodCallExpression toUpperExp = Expression.Call(
  Expression.Constant("merhaba"), 
  typeof(String).GetMethod(nameof(String.ToUpper), new Type[] { }));

MethodCallExpression kullandık, bunun nedeni String sınıfı içindeki ToUpper metodunu çağırmaktır. Expression içerisinden başka bir sınıftaki veya nesnedeki metodların çağrılması ihtiyacı olduğunda MethodCallExpression kullanılmaktadır.

Şimdi “merhaba” string ifadesinin uzunluğunu nasıl alabiliriz onu görelim. Normalde kodlarken String.Length kullanarak alabiliyoruz, expression kullandığımızda da String.Length property’sini çağıracağız. Fakat bu bir method değil bir property. MethodCall ile yapamayız. Buna çözüm olarak Property ismiyle çağıracağımız factory metodumuz bize MemberExpression tipinde yeni bir expression üretecek.

MemberExpression lenExp = Expression.Property(
    Expression.Constant("merhaba"), 
    typeof(String).GetProperty(nameof(String.Length)));

Örnek : Console.WriteLine(“merhaba”) işlemini Expression api ile yapalım.

ConstantExpression constExp = Expression.Constant("merhaba", typeof(string));
MethodCallExpression methodCallExp = Expression.Call(
  typeof(Console).GetMethod("WriteLine", new Type[] { typeof(string) }), 
  constExp);

//methodCallExp System.Console.WriteLine("merhaba") üretir 

MethodCallExpression içinde Console class altındaki WriteLine metodunu constExp ile hazırladığımız parametreyi vererek çağırdık.

Bu örnekler expression konusunda bir miktar fikir vermiştir. Expression Tree ile devam edeceğiz.

Expression Tree

Buraya kadar expression yapılarını ve Api ile expression üretme yöntemini gördük. Aslında iç içe expression üretirken expression tree konusuna giriş yaptık. Expression’ların birbiri ile bağlantıları expression tree ile sağlanır. Expression tree içindeki node’lar yani expression’lar ağacın en alt dalından başlanarak hesaplanır ve en üst dalında(root) işlem sona erer. Örnekler üzerinden daha net görelim.

Örnek : 3 > 2 işlemini yapan kod parçamız olsun.

bool res = 3 > 2;

Bunun expresion Api kodlaması:

ConstantExpression exp1 = Expression.Constant(3);
ConstantExpression exp2 = Expression.Constant(2);
BinaryExpression expRes = Expression.GreaterThan(exp1, exp2);

Expression tree yapısı:

Örnek : Şimdi ağacı biraz daha büyütüp (5 > 4) && (3 > 2) ifadesi için yapalım.

bool res = (5 > 4) && (3 > 2);

Expression Api kodlaması:

ConstantExpression exp1 = Expression.Constant(5);
ConstantExpression exp2 = Expression.Constant(4);
BinaryExpression exp12 = Expression.GreaterThan(exp1, exp2);

ConstantExpression exp3 = Expression.Constant(3);
ConstantExpression exp4 = Expression.Constant(2);
BinaryExpression exp34 = Expression.GreaterThan(exp3, exp4);

BinaryExpression exp1234 = Expression.AndAlso(exp12, exp34);

Expression tree yapısı:

Buraya kadar olan kısımda expression tanımlama konusunu gördük fakat parametre geçmek gerektiğinde nasıl yapacağız? Bu expression’ları nasıl çalıştırıyoruz? Şimdi bu soruların cevaplarıyla devam edelim.

Bir expression’a dışarıdan parametre göndermek isteyebiliriz. Bunun için ParameterExpression sınıfını kullanacağız. Örneğin aşağıdaki gibi bir lambda expression kodlamış olalım. Lambda expression konusuna bu yazıda girmeyeceğim, bildiğinizi varsayarak devam edeceğim.

Func<int, bool> func1 = (i) => i > 2;

//Expression karşılığı
ParameterExpression expParam = Expression.Parameter(typeof(int), "i");
ConstantExpression expConst = Expression.Constant(2);
BinaryExpression expRes = Expression.GreaterThan(expParam, expConst);

ParameterExpression oluştururken parametrenin taşıdığı tipi ve opsiyonel olarak parametre adını veriyoruz. Bu şekilde oluşturduğumuz expression nesnesine dışarıdan parametre geçebiliyoruz. Örneğimizde func1 lambda expression’ı bulunmakta ve girdi olarak int tipinde parametre alırken çıkı olarak bool tipinde dönüş yapıyor.

Lambda expression’ın sağ tarafındaki ifadeyi üreterek başladık ve int tipinde parameter expression oluşturduk buna “i” ismini verdik, 2 değeriyle ConstantExpression oluşturduk ve bunları büyüktür işlemini yapacak BinaryExpression içine ekledik.

Oluşturduğumuz expression’ın çalıştırılması nasıl yapılıyor? Öncelikle func1 ismiyle yazdığımız lambda expression bildiğiniz üzere doğrudan çalıştırılabiliyor.

Func<int, bool> func1 = (i) => i > 2;
//func1 lambda expression çağırımı 
Console.WriteLine(func1(3)); // true
Console.WriteLine(func1(1)); // false

Expression için de durum farklı değil. Üretilen expression nesnesini çalıştırılabilir yapabilmek için öncelikle Lambda expression’a çevirmemiz gerekiyor. Bunu aşağıdaki gibi yapıyoruz.

Expression<Func<int, bool>> lambdaExp = Expression.Lambda<Func<int, bool>>(expRes, expParam);
Func<int, bool> func1FromExp = lambdaExp.Compile();
Console.WriteLine(func1FromExp(3)); // true
Console.WriteLine(func1FromExp(1)); // false

Örneğimizde ürettiğimiz expRes’i önce Lambda Expression’a çeviriyoruz.

Expression<Func<int, bool>> lambdaExp = 
            Expression.Lambda<Func<int, bool>>(expRes, expParam);

Expression.Lambda metoduyla int girdi alan ve bool dönen bir fonksiyon oluşturacağımızı bildiriyoruz. Parametre olarak alınacak expParam bilgisini de veriyoruz. Yani lambda expression oluştururken expression body ve parametre bilgisini kullandık. Bunun sonucunda elimizde lambdaExp isminde bir nesnemiz var bunu çalıştırmak için derlememiz gerekiyor. Bunun için ise Compile metodunu kullanarak derleme yapıyoruz ve çalıştırılabilir fonksiyonumuz hazır oluyor.

Func<int, bool> func1FromExp = lambdaExp.Compile();
Console.WriteLine(func1FromExp(3)); // true
Console.WriteLine(func1FromExp(1)); // false

Özetle, oluşturduğumuz expression’ları çalıştırılabilir yapabilmek için Lambda Expression’a çevirmemiz ve derlememiz gerekli bunun için de Expression kütüphanesinin Expression.Lambda metodunu ve sonrasında derleme için Expression.Compile metodunu kullanıyoruz.

Microsoft dokümanlarındaki açıklama:

Only expression trees that represent lambda expressions can be executed. Expression trees that represent lambda expressions are of type LambdaExpression or Expression<TDelegate>. To execute these expression trees, call the Compile method to create an executable delegate, and then invoke the delegate.

Executing Expression Trees

Yukarıdaki örnekte bir expression ürettik ve bunu lambda expression’a çevirip çalıştırdık. Tersi de geçerlidir. Lambda expression’dan expression tree oluşturmak mümkündür. Örnek:

Expression<Func<int, bool>> expFunc1 = (i) => i > 2;

Derleyici Expression<TDelegate> ifadesi ile başlayan lambda expression’ları expression tree olarak işleyecektir. Böylece üretilen expression içerisi görülebilir veya bu kullanılarak yeni expression tree’ler üretilebilir.

Expression<Func<int, bool>> expTree = i => i > 2;
Func<int, bool> func1 = expTree.Compile();
func1(3); // true

// expTree içeriği incelenebilir veya bunlar kullanılarak
// yeni bir expression tree üretilebilir ve bununla değiştirilebilir.
ParameterExpression param = (ParameterExpression)expTree.Parameters[0];
BinaryExpression operation = (BinaryExpression)expTree.Body;
ParameterExpression left = (ParameterExpression)operation.Left;
ConstantExpression right = (ConstantExpression)operation.Right;

Expression tree node’ları değiştirilemezdir, eğer değiştirmek gerekiyorsa yeni expression node oluşturulur. Expression tree düzenleme işlemleri ExpressionVisitor class yardımıyla yapılır. Dinamik filtreleme konusuna artık geçebiliriz. Oradaki örnek kodlarda kullanım alanları hakkında daha net bilgi sahibi olabileceğiz.

Dinamik Filtre Üretimi

Veritabanı sorgulamalarında LINQ kullanıyorsanız mutlaka expression tree yapılarını kullanmak durumunda kaldınız demektir. Örneğin IQueryable interface’ini miras alan bir nesnenin Where sorgusunda expression kullanmışsınızdır. Bu noktada IEnumarable ve IQueryable farkını da incelemenizi tavsiye ederim. Kısaca değinmek gerekirse, IEnumarable kullanıldığında Entity Framework(EF) tarafından veritabanından tüm kayıtlar çekilir ve bunlar üzerinde sorgu çalıştırılır yani filtreleme işlemini kod üstlenir. IQueryable kullanıldığında ise filtre sorgusu veritabanına gönderilir ve sonucu çekilir. Bu iki yöntemin de kullanım alanları vardır. Expression tree yapılarının temel kullanımı bu noktada olmaktadır. Yazılan LINQ kodları epxression tree’ye çevrilir.

//Aşağıdaki gibi bir sorgu ifademiz olsun. 
Expression<Func<int, bool>> func1 = i => i > 2;
//Derleyici bu ifadeyi okur ve aşağıdaki gibi bir expression tree üretir
ParameterExpression exp1 = Expression.Parameter(typeof(int), "i");
ConstantExpression exp2 = Expression.Constant(2);
BinaryExpression expRes = Expression.GreaterThan(exp1, exp2);
Expression<Func<int, bool>> expLambda = Expression.Lambda<Func<int, bool>>(expRes, exp1);

Bu sorgu nasıl işlenir? EF, gelen sorguyu database provider sınıfına gönderir ve database provider bu sorguyu alarak veritabanına gönderilecek örneğin SQL sorgusuna(SELECT Id,Name FROM Users..) çevirir. Bu işleme query translation denir. Translation işlemine başlanmadan araya girmek istenirse IQueryExpressionInterceptor gibi bir interceptor tanımı yapabilirsiniz veya IQueryTranslationPreprocessorFactory ‘den türeyen bir sınıf yazarak doğrudan müdahale edebilirsiniz. Yukarıdaki kısım burada not olarak bulunsun. Expression tree’nin işlenmesi ve sonra veritabanının anlayacağı sorgulara çevrilme kısmına şu aşamada ihtiyacımız olmayacak. Bize lazım olan bilgi: Entity Framework, LINQ sorgusunu expression tree’ye dönüştürür.

Dolayısıyla çalışma zamanında expression tree üretebiliyorsak dinamik sorgulama kapısını açabiliyoruz demektir. Temel çalışma mekanizması hakkında bazı bilgiler edindik şimdi bu bilgileri kullanarak dinamik filtreleme yöntemine geçebiliriz. Örneğimizin tanımını yapalım ve veri yapısını kodlayalım.

Örnek : Örneğimizde araç bilgilerini tutacak Car isminde bir sınıfımız var Id, Year, Make alanlarını içeriyor. Veritabanı ile ilgili tanım kodları kalabalık yapmasın diye sanki veritabanı varmış gibi bir class yapacağız adı DemoDb olacak. DemoDb içinde tüm araçları içeren _cars listemiz olacak. Bu listeyi sorgulayabilmek için Cars metoduyla IQueryable erişimini döndüreceğiz. Kısacası DemoDb veritabanında Cars isminde bir tablo olduğunu düşünelim.

public class Car
{
    public int Id { get; set; }
    public int Year { get; set; }
    public string Make { get; set; }

    public Car(int id, int year, string make)
    {
        Id = id;
        Year = year;
        Make = make;
    }

    public override string ToString()
    {
        return Id + " " + Year + " " + Make;
    }
}


public class DemoDb
{
    List<Car> _cars = new List<Car>();

    public DemoDb()
    {
        //seed
        _cars.Add(new Car(1, 2023, "Volvo"));
        _cars.Add(new Car(2, 2022, "Mercedes"));
        _cars.Add(new Car(3, 2021, "Tesla"));
        _cars.Add(new Car(4, 2023, "Toyota"));
        _cars.Add(new Car(5, 2022, "Audi"));
    }

    public IQueryable<Car> Cars()
    {
        return _cars.AsQueryable();
    }
}

Cars tablosuna sorgu atalım, örneğin 2023 yılına ait araçları çekelim.

var cars2023 = context.Cars().Where(x => x.Year == 2023).ToList();
cars2023.ForEach(x => Console.WriteLine(x.ToString()));

// Sonuçlar:
// 1 2023 Volvo
// 4 2023 Toyota

Bunu daha taşınabilir yapabiliriz. Örneğin sorgu expression parametresini Where içinde değil dışarıda hazırlayıp parametre olarak geçelim.

// Expression'ı önceden üretip kullanabiliriz
Expression<Func<Car, bool>> predicateYear2023 = car => car.Year == 2023;
cars2023 = context.Cars().Where(predicateYear2023).ToList();
cars2023.ForEach(x => Console.WriteLine(x.ToString()));

// Sonuçlar:
// 1 2023 Volvo
// 4 2023 Toyota

Taşınabilir olmasına çalıştık ama Year kolon adını koda gömmek gerekti. Bundan nasıl kurtulabiliriz? Dışarıdan kolon isimleri ve değerler gelsin biz içeride dinamik olarak Where içerisinde kullanacağımız expression’ı üretelim. Şöyle yapabiliriz:

Expression<Func<Car, bool>> predicateDynamic = ExpressionGenerator("Year", "==", 2023);
cars2023 = context.Cars().Where(predicateDynamic).ToList();
cars2023.ForEach(x => Console.WriteLine(x.ToString()));

Bir tane ExpressionGenerator yazalım ve bu tablomuzdaki kolon ve değerlerden bağımsız olarak expression üretsin böylece sorgulama katmanında kolon bağımlılığından kurtulmuş olur ve daha az kodla daha çok iş çıkarabiliriz.

Expression<Func<Car, bool>> ExpressionGenerator(string col, string opr, object val)
{   
}

ExpressionGenerator fonksiyonu col, opr, val parametrelerini yani kolon adı, karşılaştırma operatörü ve değer parametrelerini alarak expression tree üretecek. Böylece amacımız olan Where sorgusundaki LINQ ifadesini dinamik olarak üretebileceğiz. Aşağıda ExpressionGenerator’ın çalışan kodunu inceleyebilirsiniz. Kısa ve anlaşılabilir olması nedeniyle içinde herhangi bir kontrol vs. rutinler yok. Sadece örnek için yeterli olacak şekilde yazdım.

Expression<Func<Car, bool>> ExpressionGenerator(string col, string opr, object val)
{
    //x => x.Year == 2023, buradaki x parametre olarak geliyor, parameter expression olarak tanımlıyoruz.
    ParameterExpression paramExp = Expression.Parameter(typeof(Car), "x");
    //Year,Make alanlarının tipini alan adından alıyoruz.
    Type propType = typeof(Car).GetProperty(col).PropertyType;
    //x.Year diyebilmek için x'i tanımladık bu da alanın expression tanımı. 
    MemberExpression propExp = Expression.Property(paramExp, col);
    //x.Year == 2023 sorgusundaki 2023 değeri yani filtre değeri(val).
    ConstantExpression valExp = Expression.Constant(val, propType);
    Expression expRes;

    //Burada gelen operatör değerine göre farklı expression'lar üretmek gerekiyor. 
    //==, contains, startswith gibi bunlar çoğaltılabilir. 
    //Örneğin contains gelirse methodcall expression kullanılırken, == geldiğinden binary expression kullanılır.
    switch (opr)
    {
        case "StartsWith":
            expRes = Expression.Call(propExp, nameof(string.StartsWith), Type.EmptyTypes, valExp);
            break;
        case "Contains":
            expRes = Expression.Call(propExp, nameof(string.Contains), Type.EmptyTypes, valExp);
            break;
        case "==":
            expRes = Expression.Equal(propExp, valExp);
            break;
        case "!=":
            expRes = Expression.NotEqual(propExp, valExp);
            break;
        default:
            expRes = Expression.Equal(propExp, valExp);
            break;
    }
    
    Expression<Func<Car,bool>> lambdaExp = Expression.Lambda<Func<Car, bool>>(expRes, paramExp);
    return lambdaExp;    
}

Fonksiyon içerisinde neler yapıldı? Öncelikle ParameterExpression oluşturduk. Bunun nedeni x => x.Year == 2023 gibi bir sorgu oluşturabilmek için buradaki x’in Car tipinde olması gerekliydi ve x.Year ifadesi için ise Car sınıfının Year property’sine erişmek gerekliydi bunun için ise MemberExpression tanımladık. Bu noktaya kadar ifademizin sol tarafı hazır oldu. Yani x.Year veya x.Make tamam. Sağ tarafı için yani val değeri için ise ConstantExpression tanımladık. Bu noktada alanın tip bilgisi de gerekliydi ve alan adından tipini alarak ConstantExpression’a geçtik. Sağ ve sol taraflar hazır sadece kıyaslama veya işlem tanımı kaldı yani x.Year == 2023 ifadesindeki == işlemi. Bunun için ise gelen opr parametresine göre expression ürettik. Eğer contains işlemi olacaksa MethodCallExpression ile String.Contains metodunu çağırdık veya == işlemi olacaksa BinaryExpression ürettik ve Equals kullandık.

Son olarak lambda expression üretiyoruz Expression.Lambda’ya expRes ve paramExp parametrelerini geçiyoruz. Bunlar body ve parameter olarak adlandırılır. x => (x.Year == 2023) örneği üzerinden gidelim buradaki body, x.Year == 2023 olan bölüm iken parameter ise x’i temsil eder.

Şimdi deneyelim:

DemoDb context = new DemoDb();
List<Car> carsRes = new List<Car>();

Console.WriteLine("Filter: Year == 2023");
Expression<Func<Car, bool>> predicateDynamicYear2023 = ExpressionGenerator("Year", "==", 2023);
carsRes = context.Cars().Where(predicateDynamicYear2023).ToList();
carsRes.ForEach(x => Console.WriteLine(x.ToString()));

Console.WriteLine("Filter: Make StartsWith 'T'");
Expression<Func<Car, bool>> predicateDynamicStartsWithT = ExpressionGenerator("Make", "StartsWith", "T");
carsRes = context.Cars().Where(predicateDynamicStartsWithT).ToList();
carsRes.ForEach(x => Console.WriteLine(x.ToString()));

//Çıktıları:
//Filter: Year == 2023
//1 2023 Volvo
//4 2023 Toyota
//Filter: Make StartsWith 'T'
//3 2021 Tesla
//4 2023 Toyota

Buraya kadar expression tree oluşturma ve çalıştırma konusunda bazı bilgiler verdim. Expression tree içeriğini okumak veya değiştirmek gerekebilir bu gibi işlemler için ExpressionVisitor sınıfı kullanılır.

Tahmin edileceği gibi Expression Tree kütüphanesi, kullanım alanları ve kısıtları konularında pek çok detay bulunmakta konunun daha iyi anlaşılabilmesi için somut örnekler yaparak ilerlemek faydalı olacaktır.

Teşekkürler.

Engin Ünal

Yapısal Tasarım Kalıplarından(Structural Patterns) olan Proxy Tasarım Kalıbı(Proxy Design Pattern) nedir? Nasıl kullanılır? C# kod örneğiyle inceleyeceğiz.

Proxy Tasarım Kalıbı, mevcutta kullanılan bir nesnenin yerine geçen, o nesneye erişimi sınırlayan, öncesinde veya sonrasında yapılmak istenilen işlemlerin eklenmesine imkan tanıyan yapısal bir tasarım kalıbıdır.

Adından anlaşılacağı üzere vekil görevini üstlenir. Bir nesnenin yaptığı tüm işi başka bir nesneye devreder, bu şekilde yeni nesne üzerinden gereken kontroller veya işlemler yapılır. Asıl nesnenin çalışma davranışını değiştirmek için kullanılmaz. Böyle bir gereksinim varsa başka bir tasarım kalıbı kullanılmalıdır(ör: Decorator Pattern). Asıl nesne ile proxy nesnesi yer değiştirebilir olmalıdır.

Basitçe konunun mantığını gösterebilmek için aşağıda iki şema bulunmakta. İlkinde proxy pattern kullanmadan bir servis çağrısı yapılıyor, ikincisinde ise araya proxy nesnesi konularak aynı servis çağırılıyor.

Neden böyle bir tasarıma ihtiyaç duyulur? Yukarıdaki şemada servis nesnemize erişip kullanıyoruz. Servis nesnesinin oluşturulması uzun sürebilir bu durumda her çağrıda tekrar oluşturmak performans açısından olumsuz bir durumdur. Çözüm olarak araya proxy nesnesi kullanarak bunun içinde servis nesnesini üretir ve cache’leyebiliriz.

Veya servis nesnemizin performansını ölçmek istedik, bunun için servis kodlarında değişiklik yapılması da istediğimiz bir durum değil, test edilmiş ve sorunsuz çalışan kodlara müdahale etmeyi istemeyiz. Çözüm olarak bir proxy yazarak bunun içinden servis nesnemizi çağırırken ölçüm işlemini gerçekleştirebiliriz.

Veya servis çağrısı başında ve sonunda log atmak istiyoruz. Bu işlem için de servis kodlarına ekleme yapmak yerine proxy kullanarak servis çağrısını proxy içinden yapıp log işlemini buraya ekleyebiliriz.

Bu ve benzeri durumlar çoğaltılabilir, bunlara çözüm olarak araya proxy nesnesi ekleriz. Yukarıdaki örnekten devam edersek ServiceProxy içerisinden Service nesnemizi çağırabiliriz ve bu çağrı öncesi ve sonrasında istenilen düzenlemeleri yapabiliriz. Service kodlarında değişiklik gerekliliği olmayacaktır.

Yaklaşım yalın ve uygulaması kolay bir yaklaşımdır. Şimdi bunu C# kodlama örneği ile inceleyelim.

Kod Örneği

Örnek olarak veritabanı sorgusu için kullanılan bir servisimiz olsun ve serviste geçen süreyi loglayan bir değişiklik istenmiş olsun. Bunu proxy pattern ile nasıl yapabiliriz? Öncelikle servis metodumuzu görelim.

public interface IQueryDatabase
{
    string ExecuteQuery(string query);
}

class QueryDatabase : IQueryDatabase
{
    public string ExecuteQuery(string query)
    {
        Random rnd = new Random();
        System.Threading.Thread.Sleep(1000 * rnd.Next(3));
        return "some result";
    }
}

Not: Örnekteki kodların sade olması için veritabanı işlemleri yapılıyormuş gibi yapalım, 3 saniye bekleyip devam etsin.

QueryDatabase içindeki ExecuteQuery metodunu çağırıp sorgu sonucunu çektiğimizi düşünelim. Bizden istenen bu sürenin loglanmasıydı. Ama istenen log özelliğinin eklenmesini ExecuteQuery içinde yapmak istemeyiz.

IQueryDatabase dbQery = new QueryDatabase();
string res = dbQery.ExecuteQuery("test");
Console.WriteLine(res);

Bu durumda yeni bir proxy class oluşturup bunun içinden QueryDatabase nesnemize erişmeliyiz. Proxy class’ımızı tanımlayalım.

class QueryDatabaseMeasureProxy : IQueryDatabase
{
    IQueryDatabase _queryDatabase;

    public string ExecuteQuery(string query)
    {
        if(_queryDatabase == null)
          _queryDatabase = new QueryDatabase();
        Stopwatch stopwatch = new Stopwatch();
        stopwatch.Start();        
        string res = _queryDatabase.ExecuteQuery(query);
        stopwatch.Stop();
        Console.WriteLine($"Elapsed: {stopwatch.Elapsed}");
        return res;
    }
}

QueryDatabaseMeasureProxy class’ımız içinde QueryDatabase nesnesini oluşturup ExecuteQuery öncesinde ve sonrasında ne kadar süre aldığını ölçen işlemler yapıyoruz. Şimdi deneyelim.

IQueryDatabase dbQProxy = new QueryDatabaseMeasureProxy();
dbQProxy.ExecuteQuery("test");

Şu ana kadar ne yapmış olduk? Veritabanı sorgusu atan servisimize proxy yazdık. Aşağıdaki şekilde ilk satırda verilen yapıdan ikinci sıradakine geçiş yaptık. Bizden istenen süre loglama işlemini veritabanı kodlarımızda herhangi bir değişikliğe gitmeden sağladık.

Başka bir örnekle devam edelim. QueryDatabase servisimiz için yetki kontrolü yapan düzenleme istenmiş olsun. Aynı mantıkla bunun için de bir proxy yazıp servisimize erişelim.

class QueryDatabaseProtectionProxy : IQueryDatabase
{
    IQueryDatabase _queryDatabase;
    
    public string ExecuteQuery(string query)
    {
        if(_queryDatabase == null)
          _queryDatabase = new QueryDatabase();
        if (!CheckProtection()) 
          return "Protection error!";
        string res = _queryDatabase.ExecuteQuery(query);
        return res;
    }

    private bool CheckProtection()
    {
        return true;
    }
}

Bunun için de QueryDatabaseProtectionProxy isminde bir proxy yazıp içinde yetki kontrolü ekledik. Aşağıdaki gibi çağırarak servis yetki kontrolü içeren düzenlemeyi kullanabiliriz.

IQueryDatabase dbQProxy = new QueryDatabaseProtectionProxy();
dbQProxy.ExecuteQuery("test");

Örnekler çoğaltılabilirken iç içe proxy’ler de tanımlayabilirsiniz. Bu durumda üretilen çözümün karmaşıklığı artacaktır.

Kullanım Alanları

Bu tasarım kalıbının yaygın kullanım alanlarına değinerek yazıyı sonlandıralım.

• Caching Proxy: Cache yani ön belleğe alma amacıyla kullanılır. Yapılan çağrı için dönen sonuçların ön belleğe alınması ihtiyacı olabilir. Genelde bu tip durumlar performans gerektiren, sık sorgulanan yapılar, fazla veri dönülen sorgulamakar için sözkonusudur. Çözümlerden biri de Caching Proxy yapısı uygulamaktır.
• Protection Proxy: Erişim kontrolü yapılması için kullanılabilir. İstekte bulunan nesnenin bu isteğe yetkili mi değil mi kontrol edilmesi gerekebilir. Veya birtakım kurallar zinciri kontrolünden geçirilmesi istenebilir. Çözüm olarak Protection Proxy uygulanabilir.
• Remote Proxy: Uzaktaki bir nesneye erişimde kullanılır. Uzaktaki bir nesneye erişimde bazı network işlemleri veya erişim için gereken fazladan kodlamalar gerekebilir(protokol kodları vs.) işte bu tip işlemleri mevcut koddan ayırıp proxy nesnesi içinde yapmak mümkündür. Böylece çağırılan nesne uzaktan erişiliyor olsa bile sanki lokalde kullanılıyor gibi kolayca kullanılabilir.
• Logging Proxy: Çağrıları ve/veya dönüş verisini kayıt altına alma amacıyla kullanılabilir. Logging işlemleri için servis kodlarınızı değiştirmenize gerek kalmadan proxy yapısıyla loglama yaptırabilirsiniz. Tabi ki loglama yapan kodlar sadece servis metoduna giriş öncesi ve çıkış sonrası için eklenebilirler.
• Virtual Proxy: Geç yükleme(lazy loading) amaçlı kullanılabilir. Bazı nesnelerin ilk aşamada yüklenmesi sistemin performansı açısından gereksiz olabilir. İlgili nesnenin çağrı geldiğinde yüklenmesi veya gerekli olduğu anda yüklenmesi tercih edilebilir. Bu tip durumlarda Virtual Proxy kullanılabilir.

Yukarıda bu tasarım kalıbının kullanım alanlarından bazıları listelenmiştir. İhtiyaca göre çeşitlendirmek mümkündür.

Teşekkürler.

Engin ÜNAL

ERC-20 Token standardı anlatımı ve devamında kod örneğiyle kendi token’ımızı kodlayacağımız bir yazıyla devam ediyoruz.

Blockchain projeleri sürekli gelişmekte ve değişkmekte olan, standartları ihtiyaca göre güncellenen ve yeniliklere açık projelerdir. Merkezi olmayan projelerde yeniliklerin hayata geçirilmesi geliştiricilerin, validatörlerin veya kullanıcıların önerileri üzerinden ilerlemektedir.

Ethereum ekosisteminde yeniliklerin veya değişiklik isteklerinin önerilmesi süreci EIP’ler ile sağlanır. EIP, Ethereum Improvement Proposals ( ~ Ethereum İyileştirme Önerileri ) kelimelerinin kısaltılmışıdır. Örneğin platform temel mimarisi, api, kontrat, network veya diğer konularda EIP hazırlanarak öneri sunulabilir. Devamında öneriler tartışılır ve kabul görürse finalde standartlaşır. eips.ethereum.org adresinden EIP hazırlama kuralları, standartlaşmış EIP’ler ve halihazırdaki öneriler incelenebilir.

Bu kısa özetten sonra konumuz olan EIP-20 veya ERC-20 token standardına geçelim. ERC ise uygulama ve kontrat konularıyla ilgili EIP kategorisi için kullanılan alt başlıktır. ERC-20 dediğimizde EIP-20 önerisinin kontrat, token, URI, library vb. standartlarla ilgili olduğu anlaşılır.

EIP-20, Fabian Vogelsteller ve Vitalik Buterin’in 2015 yılında ERC kategorisinde önerdikleri bir token arayüz standardıdır. Bu standart ile ilgili detaya https://eips.ethereum.org/EIPS/eip-20 adresinden ulaşılabilir. ERC-20 token standardı, akıllı kontratlar kullanarak token oluşturma ve transfer işlemlerinin yönetilebilmesi için ortak bir arabirim/interface kuralları koyar. Böylece blockchain dışından da erişilebilen(örneğin cüzdan) özelleştirilmiş ve harcanabilir varlık oluşturma yolu açılmıştır. Devamında ekosistemde token patlaması yaşanmış, harcanabilir varlıklar konusunda ilerlemeler ve tartışmalar sonrasında alınan yol ile harcanamaz varlık yani NFT’ye giden sürece önemli katkıları olmuştur. İleriki yazılarda imkan olursa buna da değineceğim.

Şimdi ERC-20 token hangi standartları şart koşar? Bunları nasıl sağlayabiliriz? Ve kendimize minimun gereksinimleri sağlayan token yapmak istesek nasıl yapabiliriz? Sorularına sırayla cevaplarla devam edelim.

ERC-20 Token Standardı

ERC-20 token standardını incelediğimizde geliştirmek istediğimiz akıllı kontrat içerisinde en az aşağıdaki fonksiyon ve tanımların olması gerektiği görülmektedir. Eğer kodlayacağımız kontrat içerisinde aşağıdaki gereksinimler tam olarak sağlanamaz ise veya isimler aynı değilse token’ımız ERC-20 standardına uymayacaktır.

//fonksiyonlar
function totalSupply() public view returns (uint256)
function balanceOf(address _owner) public view returns (uint256 balance)
function transfer(address _to, uint256 _value) public returns (bool success)
function transferFrom(address _from, address _to, uint256 _value) public returns (bool success)
function approve(address _spender, uint256 _value) public returns (bool success)
function allowance(address _owner, address _spender) public view returns (uint256 remaining)

//eventler
event Transfer(address indexed _from, address indexed _to, uint256 _value)
event Approval(address indexed _owner, address indexed _spender, uint256 _value)

Yukarıdaki tanımlar kontratınız içerisinde mutlaka olmalıdır. Dikkat çekmek istediğim name ve symbol tanımlarının zorunlu olmaması. EVM tarafında veya validatörlerde bunun önemi yoktur. Aynı isme sahip token’lar oluşturmak mümkündür. Örneğin ABC isimli bir token olsun aynı isimde bir token daha yapılabilir. Güvenli olmayan bir alım satım işleminde orjinal ABC yerine sahtesine ödeme yapma mümkün olabilir. Bu nedenle name ve symbol değil kontrat adresi kontrol edilir. Yukarıdaki fonksiyon tanımları standart içerisindeki mutlaka olması gereken tanımlardır. Aşağıda ise standartta tanımlı fakat opsiyonel olarak eklenebilen fonksiyonlar verilmiştir.

function name() public view returns (string)
function symbol() public view returns (string)
function decimals() public view returns (uint8)

ERC-20 içerisindeki fonksiyonların açıklamaları:

• name() : Token’a verilen ismi döndürür. Örnek: Istanbul Token.
• symbol() : Verilen kısa ismi döndürür. Örnek: IST.
• decimals() : Ondalık hane sayısını döndürür. Ethereum’da minimum birim Wei’dir. 1 eth = 10¹⁸ wei’dir. Ondalık işlemler için özel bir tip bulunmaz. İşlemler wei’e çevrilerek yapılır. Örneğin 2.5 eth = 2.5 * 10¹⁸ olacaktır. ERC-20 token için de ondalıklı yapı kullanılmak isteniyorsa decimals tanımı yapılarak bu sağlanabilir. Genellikle 10¹⁸ kullanılır veya isteğe göre değiştirilebilir.
• totalSupply() : Toplamdaki token arzıdır.
• balanceOf(address _owner) : _owner ile belirtilen hesaptaki bakiye bilgisini dönmektedir.
• transfer(address _to, uint256 _value) : Çağıran hesaptan belirtilen _to adresine _value kadar token’ı gönderen fonksiyondur. Bu işlem sonucunda Transfer event’i fırlatılmalıdır. Hesapta yeterki kadar token yoksa hata fırlatmalıdır.
• transferFrom(address _from, address _to, uint256 _value) : _from adresinden _to adresine _value kadar token’ı transfer eder. transfer fonksiyonundaki mekanizmaya benzerdir.
• approve(address _spender, uint256 _value) : Belirtilen _spender adresine sahip hesabın toplamda _value değeri kadar çekme işlemi(withdraw) yapabilmesini tanımlamak için kullanılır.
• allowance(address _owner, address _spender) : _owner tarafından _spender adresine verilmiş çekme işlemi izni kalan miktarını döner.

Genel mekanizmayı gördüğümüze göre artık kodlama ve uygulamaya geçebiliriz. Öncelikle temel özelliklerde bir token yapalım.

Kendi Token’ımızı Yapalım

Geliştireceğimiz token sembolü ve adı GIST:Guzel Istanbul Token olsun. Token kontrat kodu aşağıdaki gibi olabilir.

Yukarıdaki kontratı yayınladığınızda artık ERC-20 standardına sahip bir token olan GIST token’ı test ortamında olsa da yayınladınız.

Artık bu token kontratı ile on-chain veya off-chain iletişime geçip bakiye kontrolü, ödünç verme ve transfer gibi işlemleri gerçekleştirebilirsiniz.

Görüldüğü üzere karmaşık işlemler içeren bir yapı değil. Karmaşık gelebilecek tek fonksiyon transferFrom ve onun işleyişi olabilir. Aşağıda onunla ilgili yeterli açıklamayı vermeye çalıştım.

Bir hesaptan(_from) başka bir hesaba(_to) istenilen miktarda(_value) token transferi yapmak için transferFrom kullanılır. Token’ı gönderen hesap token’a sahip olmak zorunda değildir. Peki birinin token’ını nasıl başka birine transfer edebiliyoruz? Bunun için allowance mekanizması kullanılır. Token sahibi, approve fonksiyonu yardımıyla istediği hesaba kendi token’ından kullanma yetkisi verebilir. approve fonksiyonu iki parametre alır. Birincisi yetki verilecek hesap bilgisi diğeri ise ne kadar token için yetki verileceği. Bu yetkilendirme sonrası yetkiyi alan hesap artık kendisinin olmayan token’lardan kendisine izin verilen kadarını başka hesaplara transfer edebilir.

İşte bu transfer işlemi için de transferFrom fonksiyonu kullanılır. Neden böyle birşey var? Aslında bu yetenek sayesinde Defi ve staking konularında oldukça hızlı gelişmeler yaşandı. Şöyle düşünebiliriz. Hesabınızdaki token’ları transfer etmeden bir Defi uygulaması hesabına veya staking hesabına approve ile yetki verebilir bu sayede token’larınız yerinde kalırken gelir elde edebileceğiniz modeller kullanabilirsiniz.

ERC-20 token geliştirmek için her defasında sıfırdan kodlama yapmak yerine hazır şablonları da kullanabilirsiniz. Bunun için seçenekler çeşitli fakat ben en çok tercih edileni OpenZeppelin ile devam edeceğim. Şimdi ERC-20 token geliştirmenin daha kolay yöntemi olan OpenZeppelin hazır kontratlarıyla devam edelim.

OpenZeppelin İle ERC-20 Token Üretimi

OpenZeppelin, kripto siber güvenlik ve hizmetleri konusunda uzmanlaşmış bir şirket olmakla beraber güvenli akıllı kontratlar ve ortak kullanılan kontratların hazır hallerini alıp kullanabileceğimiz kütüphaneleri ve kod örnekleri bulunmaktadır. Token kontrat geliştiriciler için de örnek ERC-20 kod örnekleri bulunmaktadır. https://www.openzeppelin.com/contracts adresinden ERC20 başlığı altındaki wizard yardımı ile manuel olarak yazdığımız token olan GIST için openzeppelin kütüphanesini kullanalım.

Remix ide ile açıp derleyelim ve devamında yayınlayalım.

Openzeppelin tarafından hazırlanmış ve test edilmiş ERC20 kontratından miras alarak kendi token kontratlarımızı çok kolay türetebildik.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.9;

import "@openzeppelin/contracts@4.8.0/token/ERC20/ERC20.sol";

contract GuzelIstanbulToken is ERC20 {
    constructor() ERC20("Guzel Istanbul Token", "GIST") {
        _mint(msg.sender, 100 * 10 ** decimals());
    }
}

Buna ek olarak arz miktarını değiştirebileceğimiz mint ve burn özelliklerini de kolayca ekleyebiliriz. Aynı şekilde sık kullanılan fonksiyonlar için de hazırlanmış kütüphaneler bulunmaktadır.

Openzeppelin sitesindeki dokümanlar kısmını incelemenizi ve ERC-20 veya diğer kontrat örneklerini de uygulamanızı önerebilirim.

Teşekkürler.

Serideki diğer yazılar:

Temel Bilgiler

İlk Akıllı Kontrat ve Remix

Tipler

Contract ve Function

Interface ve Library

Veri Yönetimi

Logs ve Events

Ödeme İşlemleri

Akıllı Kontrat Çağrıları

Engin Ünal

Bir akıllı kontrattan diğerini çağırmanın yollarını ve nasıl yapıldığını inceleyeceğiz.

Bazı durumlarda geliştirdiğiniz bir akıllı kontrat içinden başka bir kontrat çağırmanız ve bu işleme göre bazı süreçleri tetiklemeniz gerekebilir. Bu tip çağrı işlemlerine yönelik Solidity tarafında çeşitli çözümler bulunmaktadır. Geliştiriciler, kullanacakları çağrı mekanizmalarını doğru seçebilmek ve güvenlik risklerini minimize edebilmek için bu konularda yeterli bilgiye sahip olmalıdır.

Bazı durumlarda gelişmiş çağrı yöntemlerine ihtiyaç duyulmadan doğrudan diğer kontrata erişimle işler çözülebilir. Yazıda Solidity ekosisteminde yaygın olarak kullanılan çağrı yöntemleri ve farklarını göreceğiz.

Yazıda çağrı yöntemlerini iki temel başlıkta gruplamaya çalıştım. İlk bölümde kodlarına erişilebilen bir kontratı çağırma yöntemlerini inceleyeceğim. İkinci bölümde ise direkt olarak fonksiyon çağrısı yapma yöntemlerini inceleyeceğim.

Kodlarına Erişilebilen Kontrat Çağrıları

Bir akıllı kontrat içinden başka bir akıllı kontratı çağırmanın farklı yöntemleri olduğundan söz etmiştim. Çağıracağımız kontratın kodlarına veya türediği interface kodlarına erişebiliyorsak aşağıdaki yöntemlerle o kontratı çalıştırabiliriz.

1 — Kontrat İçinden Yeni Kontrat Oluşturmak Ve Çağırmak

Madde başlığı uzun olmasına rağmen konuyu özetlemekte. Bir akıllı kontrat içinden başka bir akıllı kontrat oluşturmak ve bunun fonksiyonlarını doğrudan çağırmak mümkündür. Kontrat içinden oluşturulan yeni kontrat da blockchain’e yayınlanır ve bir adrese sahip olur.

Aşağıdaki örnek üzerinden inceleyelim.

// SPDX-License-Identifier: MIT
pragma solidity >=0.8.7;

contract A {
  function Hi() public pure returns(string memory) {
    return "Hi from contract A";
  }
}

contract B {
  A public a;

  function createContractA() public returns(string memory) {
    a = new A();
    return a.Hi();
  }
}

A ve B isminde iki akıllı kontrat kodlaması yaptık. B içinden A oluşturuluyor ve Hi fonksiyonu çağırılıyor.

Önemsiz Not: A kontratını başka bir sol dosyası içine da alabiliriz, eğer böyle yaparsak A kontratını import etmemiz gerekir. B kontratımızın dosyası BContract.sol olursa ve A kontrat dosyası da AContract.sol olursa bu durumda B içinden import “./AContract.sol” tanımı ile A kontratını import ederek kullanabiliriz. Yukarıdaki ile aynı şeyi ifade eder sadece kontrat dosyalarını ayırmış oluruz. Daha sade olması açısından yukarıdaki örnek üzerinden devam edelim.

a = new A(); kodlaması ile yeni bir A kontrat oluşturuluyor ve devamında a.Hi() çağrısı ile yeni kontratın Hi fonksiyonu çağırılıp döndürdüğü string değer createContractA fonksiyonunun dönüş değeri oluyor.

Bu şekildeki kullanımda A ve B iki farklı akıllı kontrat olarak farklı adreslere yayınlanmış olur. A kontratını yayınlayan B kontratıdır. createContractA fonksiyonu çalıştırıldığında transaction(internal transaction) ile A kontratı oluşturulur.

Yukarıdaki örnekte A’nın yayınlandığı adresi alalım sonraki örnekte çağrı için kullanacağız.

2 — Mevcut Bir Kontratı Adresi İle Çağırmak

Bunu iki maddede inceleyebiliriz. Biri kontrat kodları bizimle paylaşılmış ise diğeri ise kontratın türediği interface kodları paylaşılmış ise.

a) Kontrat Kodları Paylaşılmış İse

Adresini bildiğimiz yani daha önce yayınlanmış ve kodlarına ulaşabileceğimiz bir kontrata erişmek ve fonksiyonlarını çalıştırabilmek mümkündür.

Önceki örnekte kontratı yayınlayıp doğrudan erişiyorduk şimdi ise yayınlanmış bir kontrata erişeceğiz. Bunun için adresinin ve kodlarının paylaşılmış olması gerekmektedir. Önceki örnekteki B akıllı kontrat kodlamasında aşağıdaki değişikliği yapalım. A olduğu gibi kalacak ve önceden yayınlandığı için adresini bilmemiz yeterli.

contract B {
  function callContractA(address _contractA) public pure returns(string memory) {
    A a = A(_contractA);
    return a.Hi();
  }
}

Şimdi B kontratı deploy edelim. A’nın adresini B contract içindeki createContractA fonksiyonuna geçmek için kullanacağız.

A’nın adresi: 0xD7B8da9bC7dbe4E5A…..

callContractA fonksiyonuna bu adresi parametre olarak geçip kontratı çalıştırdığımızda A kontrat içindeki Hi fonksiyonu çalışır ve “Hi from contract A” değerini döndürür.

Özetle, bu örnekte daha önce bir adrese yayınlanmış akıllı kontrata eriştik ve çalıştırdık.

Bu noktada önemli bir ayrıma yaklaştık. Dikkat edilirse şimdiye kadar kodlarına erişebildiğimiz akıllı kontratları çağırmak için kullanılabilecek yöntemleri gördük. Bu yöntemlerin eksi tarafı gereksiz kodları da barındırmamız gereksinimidir. Belki de hiç kullanmayacağımız fonksiyonlar olmasına rağmen bir kontratı saklamak verimsiz bir yöntemdir. Oysa bazen gerekli olan tüm kontrat değil daha dar kapsamlı bölümleri olabilir. Örneğin sadece bir fonksiyonu çağırmak yeterli olabilir fakat bunun için tüm kontrat kodlarını saklamak istemeyiz. Bu duruma çözümler mevcuttur. Devam ederek interface ile erişimi inceleyelim.

b) Kontrat Interface Kodları Paylaşılmış İse

Interface tanımlayarak daha dar kapsamdaki bölümleri parçalara ayırıp kullanabiliriz. Örnek üzerinden görelim. Aşağıdaki örnekte iki adet interface tanımı bulunmakta. A kontratı bunlardan ikisini de implemente etmekte ve B kontrat içerisinden sadece biri kullanılmakta.

B kontrat içindeki callContractA fonksiyonunda ihtiyacımız olan şey sadece A kontratta tanımlı Hi isimli fonksiyonu çağırmaktır. A kontrat içerisindeki diğer fonksiyonlar ile şu aşamada bir işimiz yoktur. A kontrat çeşitli fonksiyonlar içerebilir fakat B kontrat bunlardan ihtiyacı kadarına erişmek ve kullanmak isteyebilir. Bu tip durumlarda sadece gereken fonksiyonların tanımlandığı interface’ler kullanılarak çağrı yapılabilmektedir.

IHelloFunc interface içinde sadece Hi fonksiyonu tanımlı ve B kontrat için de bu yeterli. Böylece IHelloFunc interface ile birlikte A kontrat adresi verildiğinde sadece Hi fonksiyonuna erişebilir ve kullanabiliriz.

IHelloFunc a = IHelloFunc(_contractA);
val = a.Hi();

Yukarıda görüleceği üzere a.Hi çağrısı ile A kontratına erişilip Hi fonksiyonu çağırılır ve fonksiyondan dönen “Hi from contract A” değeri B kontrat içinde tanımlı olan val değişkenine atanır.

Örneği verilen bu yöntemle de diğer akıllı kontratların interface tanımlarındaki fonksiyonlarına erişip çalıştırmak mümkün olmaktadır.

Doğrudan Fonksiyon Çağrıları

İlk bölümdeki örneklerde çağıracağımız kontratın kodlarına veya interface kodlarına erişimimiz olduğunda nasıl çağrı yapabileceğimizi inceledik. Bu bölümde çağırmak istediğimiz akıllı kontratın adresini ve ilgili fonksiyon ve parametrelerini bildiğimiz durumda doğrudan fonksiyon çağrısı yapmanın yöntemlerini inceleyeceğiz.

Bu yöntemlerde çağrı oluşturmak için karşı kontratın adresi, fonksiyon adı ve parametreleri bilinmelidir. Interface veya kod içeriği gibi başka verilere ihtiyaç duyulmadan karşı kontrat fonksiyonlarının çağrılması için düşük seviye çağrılar(low level call) kullanılır. Bunlar call, delegatecall ve staticcall çağrılarıdır. Birazdan bunları inceleyeceğiz. Peki çağırmak istediğimiz fonksiyonu ve parametrelerini çağrıya hazır hale nasıl getirebiliriz? Öncelikle bunu görelim.

Bu noktada Function Signature ve Function Selector kavramları önümüzde çıkar. Solidity, bir fonksiyon çağrısı yapılmak istendiğinde çağrılmak istenen fonksiyonun Function Selector verisini ister. Bu 4-byte’lık bir veridir ve ilgili akıllı kontrat içindeki function’ı işaret eder, oluşturmak için Function Signature değerinin bilinmesi gerekir.

Function Signature

Kontrat içindeki fonksiyonun adı ve parametre tiplerinin verildiği ve parametre isimlerinin olmadığı tanıma function signature denir. Aşağıdaki gibi deneme isminde bir fonksiyonumuz olsun:

function deneme(int8 a) public pure returns(int8) { return a; }

Function Signature değeri:

deneme(int8)

Function Selector

Function Signature hash değerinin ilk 4-byte’lık kısmıdır. Yani bytes4(keccak256(signatureDeğeri)) olacaktır. Yukarıdaki deneme isimli fonksiyonumuz için signature değerini hesaplarsak.

bytes4 denemeSelector;
denemeSelector = bytes4(keccak256(bytes("deneme(int8)")));
//sonuc =  0x80a2fb15

Selector değeri farklı yöntemlerle kolayca hesaplanabilir. Aşağıdaki kod örneğinde signature ve selector için hesaplama örneği verilmiştir.

Çağrılarda sadece fonksiyon selector değeri elbette yeterli olmayacaktır. Eğer çağırdığımız fonksiyon parametre alıyorsa bunu da çağrımıza eklemeliyiz. Yukarıdaki örnekte deneme(int8 a) fonksiyonu int8 a parametresi alıyordu. Function selector ve parametre değerini birleştiren ve çağrıya hazır duruma getiren Solidity fonksiyonları bulunmaktadır.

Bunlar encodeWithSignature ve encodeWithSelector fonksiyonlarıdır. Bu iki fonksiyonun ilk parametreleri çağırılacak fonksiyon tanımı ile ilgili olmakla birlikte sonraki parametreler ise çağırılacak fonksiyona geçilecek parametre değerleridir. Özetle bunların yaptığı işlem, selector ve fonksiyona gönderilecek parametreleri byte tipinde hazırlamaktır. Yukarıdaki kod örneğindeki son iki fonksiyon buna örnektir.

Kod örneğindeki getCallParamsSig fonksiyonunu veya getCallParamsSel fonksiyonunu çağırdığımızda aşağıdaki çıktıyı verecektir.

0x80a2fb150000000000000000000000000000000000000000000000000000000000000064

Görüleceği üzere ilk 4-byte’lık 0x80a2fb15 değeri deneme fonksiyonunun function selector değeridir. Sonraki 32-byte’lık kısımda 0x64 yani decimal 100 değeri tutulmaktadır.

Fonksiyon çağrıları için bilmemiz gereken temel bilgileri tamamladık. Çağrı nasıl yapılıyor? Farkları nelerdir? Sorularına yanıtlarla ve örnek kodlamalarla call, delegatecall ve staticcall çağrılarını görelim.

Call

Önceki yazıda call fonksiyonunun ödeme süreçlerindeki kullanımından bahsetmiştim bu nedenle bu yazıda sadece fonksiyon çağrısı yapılması ile ilgili özelliklerini göreceğiz. Call fonksiyonu, adresi bilinen bir kontrattaki fonksiyon tanımı ve parametreleri bililen bir fonksiyonu çağırmak için kullanılan düşük seviye bir çağrı fonksiyonudur. Önerilen bir fonksiyon çağrı yöntemi değildir, kullanmadan önce durum değerlendirmesi yapılıp eğer diğer yöntemlerle çağırma imkanı yoksa kullanılması önerilmektedir.

Neden önerilmez? Type checking yapmaz, fonksiyon var mı kontrolü yapmaz vs. Bunun gibi kontrolleri yapmadan doğrudan çağırılan kontrattaki fonksiyonu ve parametreleri varmış varsayarak çağırmaya çalışır. Bu da sorunlara neden olabilir. Bunun yerine eğer imkan varsa fonksiyonu çağırılacak kontratın interface’i import edilmeli ve bu şekilde çağrı yapılması önerilmektedir.

Kullanımı ve örnek kodlaması aşağıda verilmiştir.

(bool success, bytes memory result) = address.call(abi.encodeWithSignature("funcToCall(type)", "valParam"));
veya
(bool success, bytes memory result) = address.call{value: 1 ether}(abi.encodeWithSignature("funcToCall(type)", "valParam")));
veya
(bool success, bytes memory result) = address.call{gas: 1000000, value: 1 ether}(abi.encodeWithSignature("funcToCall(type)", "valParam")));

Çağırılacak fonksiyon payable ise doğrudan o fonksiyona ödeme yapılabilir. Çağırılacak fonksiyon eğer adresi verilen kontrat içinde yoksa veya tanımı aynı değilse fallback fonksiyonu tetiklenir.

Dönüş değeri olarak işlemin başarılı olup olmadığını belirten bool tipinde bir dönüş değeri ve bytes tipinde dönüş verisini içeren değişken döner. Çağırılan fonksiyon bir dönüş değeri döndürüyorsa bu bytes tipindeki değişkende depolanır. Çağırılan fonksiyonun kaç adet dönüş değeri ve hangi tiplerde döndürdüğünü bilmek gerekir bu bilgiyle decode fonksiyonu çağırılarak dönüş verisi alınır.

Aşağıdaki kodlama örneğinde deneme isimli bir fonksiyonumuz var int8 tipinde bir parametre alıp yine int8 tipinde değer döndürüyor. Diğer kontrattaki denemeCall fonksiyonu ise bu fonksiyonumuzu çağırarak parametre olarak verilen değeri geçiyor ve dönüş değerini decode ederek int8 tipinde bir değişkene atıyor.

Bazı notlarla call konusunu bitirelim. Call ile çağırdığınız kontrat fonksiyonu, çağıran kontratın context’inde çalışmaz. Başka bir ifadeyle çağırılan fonksiyon ait olduğu kontrat içinde çalışır ve o kontratın state değişkenlerine erişebilir. Yukarıdaki örnekteki Deneme kontratı içindeki deneme fonksiyonu CallSamples kontratından çağırılıyor. Yapılan bu çağırma işleminde deneme fonksiyonu sadece Deneme kontratındaki değişkenlere müdahale edebilir çünkü o kontrat içinde çalışır. Bu bilgi delegatecall konusuna geçmeden önce önemli, delegatecall farklı şekilde çalışmaktadır.

Delegatecall

Buraya kadar akıllı kontratlarla ilgili hep aynı çalışma mantığını takip ettik. Buna göre her kontrat kendi çalışma alanında çalışır, her kontrat fonksiyonu sadece kendi kontratındaki state değişkenlerine erişebilir ve işlem yapabilir. Böylece bir kontrattan diğerini çağırdığımızda her ikisi de farklı adreslerde farklı storage alanlarında çalışıyordu ve doğal olarak fonksiyonları da birbirlerinin çalışma alanlarına müdahale edemiyordu. Özetle farklı context’lerde çalışmaktaydılar.

Bu durumun ihlal edildiği bir yapı mümkündür. Bunu delegatecall çağrıları sağlar. Bu tip çağrılarda çağırılan fonksiyon, çağıran kontrat içinde çalışıyormuş gibi davranır. Yani çağıran kontratın context’inde çalışır. Ve state değişkenlerine müdahale imkanına sahip olur.

Bunu başka bir kontrattan fonksiyon ödünç almak gibi düşünebiliriz. Ödünç alınan fonksiyon bizim kontratımız içinde sanki bizim yazdığımız fonksiyonmıuş gibi çalışarak işlemini tamamlar.

Tabi böyle çalışma imkanı verilen bir fonksiyon çağrısı da beraberinde yüksek güvenlik risklerini de birlikte getirir. Doğrudan kontratınıza müdahale edebilen ve sizin yazmadığınız bir fonksiyona güvenerek onu çağırmanız kontrolün kaybedilmesi riskini doğurabilir.

Kullanım alanlarına bakılırsa çoğunlukla library fonksiyonları kullanımında ve proxy kontratlar tarafından kullanılmaktadır.

Kod örneğiyle inceleyelim. Önceki kodlama örneğimize aşağıdaki denemeDelegatecall fonksiyonunu ekleyelim.

function denemeDelegatecall(int8 _newVal) public returns(int8) {
  (bool success, bytes memory result) = s_addr.delegatecall(abi.encodeWithSignature("deneme(int8)", _newVal));
  require(success, "call failed");
  int8 a = abi.decode(result, (int8));
  return a;
}

Çalıştırdığımızda farklı bir çalışma şeklini göreceğiz. Deneme kontrat içindeki s_val değerine baktığımızda değişmediğini görürüz fakat CallSamples kontrat içindeki s_val değişkeni ise değişmiştir. deneme fonksiyonu bizim CallSamples kontrat içinde olmamasına rağmen CallSamples kontrat içinde tanımlı s_val state değişkenini değiştirebildi ve Deneme kontrat içindeki değişkene müdahale edemedi.

Şu sonucu çıkarabiliriz: delegatecall ile çağırılan fonksiyon tanımlandığı kontrat içinde değil çağıran kontrat içinde çalışmaktadır. Yani deneme fonksiyonunu CallSamples içinde çalışması için ödünç almış olduk.

Peki bu çağrı yöntemi neden var? Ağırlıklı olarak library kullanırken yapılan çağrılar veya proxy pattern ile geliştirilen kontratlarda kullanılmaktadır. Özellikle dikkat edilmesi gereken bir yöntemdir, kontrolün başka bir kontrat içindeki fonksiyona verilmesi doğal olarak önceden tahmin edilmesi zor sorunlara neden olabilir.

Buna örnek olarak aşağıdaki kodlamayı inceleyebilirsiniz. İki kontrat tanımlandı. A ve B akıllı kontratları. A içerisindeki deneme fonksiyonu kontratın owner’ını değiştirebiliyor. B içinde ise owner değişimi engellenmiş sadece görüntülenebiliyor. B içinden A’daki deneme fonksiyonu delegatecall ile çağırıldığında B’nin owner’ı değiştirilerek B kontratı hackleniyor ve sahibi değiştirilebiliyor.

B kontratı owner’ını korumaya aldığını düşünerek kodlama yapmasına rağmen çağırdığı A kontratındaki deneme fonksiyonu owner’a erişebildiği için herhangi bir koruma kalmıyor ve B kontratı güvensiz hale düşüyor. Bunun gibi güvenlik açıkları oluşturabileceğinden kullanıma dikkat edilmelidir.

Staticcall

staticcall çağrıları call ile aynı şekilde çalışmaktadır. Aralarındaki fark staticcall ile çağrı yaptığınız fonksiyonun içerisinde state değişimi olamaz. Yani view ve pure fonksiyon çağrısı gibi çalışmalıdır. Eğer çağırılan fonksiyon içerisinde state değişikliği oluyorsa hata üretilir ve işlem revert edilir.

Kod örneğiyle yazıyı bitirelim. Önceki kod örneğine deneme2 fonksiyonu eklendi ve bu fonksiyon view olduğundan state üzerinde değişiklik yapmıyor. A kontratı çağıracağımız fonksiyonların tanımlandığı kontrat. CallAFunctions kontratı ise çağrıları başlattığımız akıllı kontrattır.

Yukarıdaki denemeStaticcall fonksiyonunda A kontrat içindeki deneme2 fonksiyonu çağırılıyor ve dönüş değeri alınıyor. staticcall ile deneme fonksiyonunu çağırsaydık işlem gerçekleşmeyecekti ve revert edilecekti.

Solidity çağrıları ile ilgili bu yazımızın sonuna geldik. Okuduğunuz için teşekkürler.

Serideki diğer yazılar:

Temel Bilgiler

İlk Akıllı Kontrat ve Remix

Tipler

Contract ve Function

Interface ve Library

Veri Yönetimi

Logs ve Events

Ödeme İşlemleri

Engin Ünal

Akıllı kontrat ödeme işlemleri konulu bu yazıyla seriye devam ediyoruz. Yazıda transfer, send ve call fonksiyonları incelenecektir.

Ödeme İşlemleri

İlk yazılardan hatırlarsınız Ethereum sisteminde varlık transfer işlemleri iki tip hesaba da yapılabilmekteydi; Biri akıllı kontrat diğeri ise EOA ismiyle bilinen cüzdan hesaplarına. Akıllı kontrata ödeme işlemlerinde alıcı kontratın receive veya fallback fonksiyonları otomatik olarak çalışmakta ve gelen miktarı algılayabilmekteydi. Akıllı kontrattan karşıdaki bir adrese ödeme işleminde temel kural karşı adresin payable olmasıdır. Ödeme almayan adreslere ödeme fonksiyonları işlem yapmazlar. Bir akıllı kontrattan diğerine veya akıllı kontrattan cüzdan hesabına ödeme işlemi için üç fonksiyon vardır.

• transfer
• send
• call

Bunları ve farklarını inceleyelim. Sonrasında örnek kodlarla farklı senaryoların çalışma mantığını göreceğiz.

Transfer Fonksiyonu

Akıllı kontrat içerisinden adresi verilmiş bir alıcıya ödeme yapılması için kullanılan fonksiyondır. Kullanımı:

aliciAdresi.transfer(wei_olarak_miktar);

Bu işlem sonrasında eğer kontrat bakiyesi yeterli ise ve alıcı ile ilgili bir sorun yoksa ve reddetmediyse transfer işlemi başarıyla gerçekleşir. Bir hata durumunda transfer fonksiyonu transaction’ı iptal eder ve işlemi revert eder.

Ödeme işleminde alıcı bir akıllı kontrat ise ödemeyi alan akıllı kontratın receive veya fallback fonksiyonu tetiklenir. Transfer işleminde 2300 gas alıcı kontrata aktarılarak receive/fallback fonksiyonundaki işlemi için kullanılır. 2300 gas alıcı kontrat receive/fallback fonksiyonuna yeterli gelmiyorsa işlem iptale düşer.

Send Fonksiyonu

Transfer fonksiyonuna benzer, hata üretip transaction’ı iptale düşürmez. Bunun yerine bool dönüş tipi verir, dönüş değeri kontrolü ile tüm kontrol kontrata bırakılmıştır. Kullanımı:

bool basarili = aliciAdresi.send(wei_olarak_miktar);

Bu işlem sonrasında eğer kontrat bakiyesi yeterli ise ve alıcı ile ilgili bir sorun yoksa ve reddetmediyse send işlemi başarıyla gerçekleşir ve sonuç olarak true döner. Bir hata durumunda send fonksiyonu false döner transaction’ı iptal etmez veya revert etmez.

Ödeme işleminde alıcı bir kontrat ise ödemeyi alan kontratın receive veya fallback fonksiyonu tetiklenir. Send işleminde 2300 gas alıcı kontrata aktarılarak receive/fallback fonksiyonundaki işlem için kullanılır. 2300 gas alıcı kontratın receive/fallback fonksiyonuna yeterli değil ise send fonksiyonu geriye false döner.

Görüldüğü üzere send fonksiyonunun dönüşü kontrol edilerek ödemenin başarılı olup olmadığı kontrol edilmelidir.

Call Fonksiyonu

Önceki başlıklarda bahsedilen transfer ve send fonksiyonlarının bazı kısıtlarına sahip değildir ve daha esnek bir kullanım sunar.

Transfer ve send fonksiyonlarından ödeme yapılan kontrata(receive/fallback çalıştırılmasına) 2300 gas gönderimi yapılıyordu. Call fonksiyonunda böyle bir limit yoktur. Bu nedenle komplike receive işlemlerinin çalışmasına imkan tanır. Bu süreç konu sonundaki örneklerle daha net anlaşılacaktır. Toparlamak gerekirse; Transfer ve send fonksiyonları kullanılırken ödeme yapılan kontratın receive/fallback fonksiyonu çalıştırmalarında kullanılmak üzere 2300 gas gönderilir. Bu gas neredeyse event fırlatılmasına yetecek kadarıdır. Yani state değişkenine bir değer atanmak istendiğinde yetmeyecektir. Bu nedenle receive fonksiyonlarını geliştirirken bu limit düşünülerek gas tüketimi minimum tutulmalıdır.

Call fonksiyonunun farkı 2300 gas limiti yoktur ve gereken gas gönderilir. Böylece call fonksiyonları kullanıldığında çağrılan kontrat receive fonksiyonunun gas tüketimine takılmaz ve işlem iptale düşmez. Kullanımı:

(bool ok, bytes memory data) = alici.call{value: miktar}("");

value değişkenine wei olarak gönderilen miktar verilir. (“”) ifadesinin detayına şimdilik girmeyeceğim temel görevi karşıdaki fonksiyonu çağırabilmesidir.

Bu işlem sonrasında eğer kontrat bakiyesi yeterli ise ve alıcı ile ilgili bir sorun yoksa ve reddetmediyse call işlemi başarıyla gerçekleşir ve sonuç true döner. Bir hata durumunda call fonksiyonu false döner, transaction’ı iptal etmez veya revert etmez.

Ödeme işleminde alıcı bir kontrat ise ödemeyi alan kontratın receive/fallback fonksiyonu tetiklenir.

Getirdiği esneklik ve gas kısıtı olmaması nedeniyle call kullanılması önerilmekte. Ayrıca transfer ve call fonksiyonlarındaki gas kısıtlaması sebebiyle ileride yapılacak bazı gas tüketim hesaplama değişikliklerinde ödeme işlemi yapan fonksiyonlarınız çalışamaz hale gelebilir. Bunun gibi kısıtlamalardan kurtulmak ve call kullanmak daha pratik olabilir fakat call kullanırken bazı güvenlik açıkları vermeniz ve saldırıya açık duruma düşme ihtimaliniz artar. Bu fonksiyonu kullanmadan önce Solidity güvenli kod geliştirme ile ilgili konuları incelemeniz önerilir, reentrancy atak gibi en bilinen saldırı tiplerine karşı önlem alınması gerekir.

Örnek:

Şimdi bu üç fonksiyon ile ilgili teorik bilgiyi pekiştireceğimiz kod örneği ile devam edelim.

İki kontrat örneğimiz var. SendEther1 ve GetEther1. SendEther1 içerisinde transfer, send ve call fonksiyonları ile ödeme işlemi örnekleri bulunmakta. SendEther1 kontrat içindeki transferTest, sendTest, callTest fonksiyonları iki parametre almakta. Bunlardan ilki ödemenin yapılacağı adres bilgisi(address payable _to) diğeri ise ne kadar ödeme yapılacağını ifade eden değer(uint256 _amount). Bildiğiniz gibi kullanılan birim wei.

GetEther1 ise ödemeyi alacak olan kontratımız olacak. Bu nedenle içerisinde receive fonksiyonu tanımlı ve bu fonksiyon içerisinde gas tüketimi düşük birkaç işlem yapılmakta. Her iki kontrat içerisinde de log üreten event tanımları da bulunmakta.

Akıllı kontratları çalıştırmadan önce deploy edelim. Ödemeyi yapacak kontrat SendEther1 olduğundan onu deploy ederken istediğimiz kadar Ether yükleyeceğiz, tabi bunun için constructor’ını payable yapıyoruz. Bu örnekte SendEther1'i 1000 Wei ile deploy edeceğim.

SendEther1 kontratını hesabında 1000 Wei olacak şekilde deploy ettik. Devamında GetEther1'i deploy edelim. İkisi de deploy edildi.

SendEther1 adresi : 0xd9145CCE52D386f254917e481eB44e9943F39138

GetEther1 adresi : 0xd8b934580fcE35a11B58C6D73aDeE468a2833fa8

Şimdi ödeme fonksiyonlarımızı test edelim.

transfer

İlk olarak transfer fonksiyonunu deneyeceğimiz SendEther1 kontrat içindeki transferTest ile başlayalım. GetEther1 kontratına 100 wei gönderelim. Bunun için GetEther1'in adresini alacağız ve transferTest fonksiyonuna parametre olarak vereceğiz.

Transact ile işlemi gerçekleştiriyoruz ve başarılı olarak tamamlanıyor. Log içeriğine baktığımızda SendEther1>transferTest ve GetEther1>receive fonksiyonları içindeki event’ler çalışıyor ve log üretiliyor. Log içeriğini incelediğimizde her ikisinin de bilgilerini görebiliriz.

Başarılı bir senaryoyu denedik. Peki hesabımızda şu anda yeterli olmayan bir rakamı örneğin 1000 Wei gönderelim. Tahmin edileceği üzere transaction başarılı olmayacak ve revert edilecektir.

transfer fonksiyonu kullanıldığında ve işlem başarılı sonlanmadığında hata üretir ve transaction revert edilir.

send

Transfer fonksiyonunda yaptığımız işlemin aynısını burada da denediğimizde başarılı durumlarda send fonksiyonu true dönecektir ve transaction tamamlanacaktır. Hata üretecek bir işlem deneyelim. 1000 Wei gönderimini send fonksiyonuyla denediğimizde ne olacak? Transaction başarılı olarak sonlanacak mı? Hata üretip işlem iptale mi düşecek?

İşlemi başlattığımızda yeterli bakiye olmamasına rağmen transaction’ın başarılı olarak tamamlandığını görürüz. Fakat GetEther1 kontratına bir ödeme yapılmadığı da görülecektir.

Peki hem transaction başarılı hem de ödeme gitmedi neden? Bunun cevabını sendTest kodlarını incelediğimizde görebiliriz.

function sendTest(address payable _to, uint256 _amount) external {
  bool ok = _to.send(_amount);
  emit SendLog(_to, _amount, ok);
}

Send fonksiyonu, çalışma tanımı gereği geriye sadece bool bir değer döner. Yani ödeme sonucu kontrolünü siz yapmalısınız, revert işlemine karar vermek tamamen size bırakılmıştır. Örneğimizde ödeme yapılamamasına rağmen transaction’ın başarılı olmasının nedeni budur. Burada send fonksiyonu bize false dönmüş fakat kodlamada false alındığında ne yapılacağı tanımlı olmadığından işlemler başarılı sonlanmıştır.

Logs içeriği incelendiğinde alıcı kontratın log üretmediği ve gönderici kontrat loglarında send fonksiyonunun false döndüğü görülebilir.

Send fonksiyonu kullanımlarında fonksiyon dönüş kontrolünün yapılması önemlidir. Burada yapılacak mantık hataları veya kontrol süreci sorunları büyük problemler doğurabilir.

call

Son örneğimizdeki call fonksiyonu kullanımında başarılı senaryo transfer veya send ile aynı olacaktır. Bir hata durumunda ise aynı send fonksiyonundaki gibi geriye bool değer döneceğinden dönüş değeri kontrol edilerek işlemin başarılı olup olmayacağına karar verilmelidir.

Kod örneğimizdeki gibi dönüş değeri kontrol edilmezse transaction başarılı olarak tamamlanır fakat ödeme işlemi gerçekleşmez.

transfer, send ve call Farkı

Yukarıdaki örneklerde GetEther1 içerisindeki receive fonksiyonunda 2300 gas tüketmeyecek işlemler yapılmaktaydı. Peki receive içerisinde state değişkeni set edersek ne olur? Bildiğiniz gibi state değişkenlerinin gas tüketimleri yüksek olacaktır. Kodlamadaki değişikliği aşağıdaki gibi yapalım.

contract GetEther1 {
  uint256 val;
  event LogIt(address, uint, uint);

  receive() external payable {
    val++;
    emit LogIt(msg.sender, msg.value, gasleft());
  }
}

Ve tekrar deploy edelim.

Yeni adresi : 0x358AA13c52544ECCEF6B0ADD0f801012ADAD5eE3

Bu adresi transferTest fonksiyonuna geçip 100 Wei gönderimi yapmak istediğimizde aşağıdaki çıktıyı verecektir.

Aynı şekilde send fonksiyonu da hata verir. Bunun nedeni alıcı kontratın receive fonksiyonuna ayrılan 2300 gas’lık rakamın yeterli olmamasıdır.

Fakat bu işlemi call fonksiyonuyla yaptığımızda bu limit olmadığından işlem başarılı gerçekleşir. Bu işlemin sonunda loglar oluşur. Bunu incelediğimizde 100 Wei’lik ödemenin gönderildiği ve karşı taraftan da alındığı listelenir.

Bu tip esneklikler sağlaması ve geri dönüş verisi (çağrılan fonksiyonun dönüş verisini) dönebilmesi gibi imkanlar sunması nedeniyle genellikle call fonksiyonu kullanımı tercih ediliyor. Fakat reentrancy ataklar gibi ataklara da açık hale gelinebiliyor. Bunlara karşı önlemler alınarak kullanıma dikkat edilmelidir.

Üç ödeme fonksiyonunu ve önemli detaylarını örnekle açıklamaya çalıştım umarım faydalı olmuştur. Okuduğunuz için teşekkürler.

Serideki diğer yazılar:

Temel Bilgiler

İlk Akıllı Kontrat ve Remix

Tipler

Contract ve Function

Interface ve Library

Veri Yönetimi

Logs ve Events

Engin Ünal

Veri yönetimi konusunun devamında ve onunla da ilgili bir konu olan Logs ve Events yapılarını göreceğiz. Öncelikle Logs devamında Event başlıklarını inceleyeceğiz. Birbiriyle ilişkili konular olduğundan kavramlara değinilip devamında iki konu birleştirilip örnekle yazı sonlanacaktır.

Logs

EVM, logs isminde özel veri yapısına sahiptir. Blockchain üzerinde gerçekleşen işlemleri bu özel veri yapısına kaydeder. İndeksli bir veri yapısı olan logs’a kaydedilen verilere akıllı kontratlar erişemez.

Ethereum node’ları üzerinden logs verilerine erişilebilir ve arama yapılabilir. Logs verileri front-End uygulamaları veya blockchain dışındaki uygulamalar için değerlidir. Logs yayınlarını takip ederek değişiklikleri dinlerler ve yapılan işlem ile ilgili bilgilere ulaşabilirler.

Bu neden önemli? Örneğin bir web uygulaması yazdınız ve burada bir transfer işlemi gerçekleşiyor olsun. Transfer sonucu sonunda ekran güncellenmeli. Tam bu aşamada logs kayıtları önemlidir bu kayıtlar dinlenerek transaction işleminin tamamlandığı bilgisi alındığında sayfa güncellenebilir. Başka bir örnekle devam edelim. Bir web servis yazdınız ve bunun görevi bir akıllı kontratı takibe almak ve onda yapılan işlemlere göre başka bir kontratı çalıştırmak olsun. Temel olarak web servisimizin yapması gereken en kritik iş takip ettiği kontrat işlemlerini dinlemek ve buna göre aksiyon almaktır. İşte bu dinleme işlemleri logs yapısı ile gerçekleşir.

Ethereum node’undan çekilmiş bir logs kaydı örneği:

{
  "address": "0xb59f67a8bff5d8cd03f...",
  "blockHash": "0x8243343df08b9751f5ca0c5f8c9c0460d83...",
  "blockNumber": "0x117a05",
  "data": "0x0000000000...0000000012a05f200",
  "logIndex": "0x56",
  "removed": false,
  "topics": [
    "0xddf252ad1be2c89b69c2b068fc378daa...",
    "0x00000000000000000000000000b46c...",
    "0x00000000000000000000000054a2d42a40f512..."
  ],
  "transactionHash": "0xab059a62e22e230fe0f56d8555340a2...",
  "transactionIndex": "0xac"
}

Topics değerleri indekslenmiş event verisini tutar. Data içerisinde ise indekslenmemiş event verilerini içerir. Buna events konusunda değineceğim.

Logs yapıları storage ile kıyaslandığında çok daha ekonomiktir. Bu nedenle eğer storage’da saklanması şart olmayan veya daha sonra okunmasına gerek olmayan veri saklanıyorsa bunu logs üzerinde almak gas ücretini önemli oranda düşürecektir.

Konuyu şu şekilde de özetleyebilirim: Web3 uygulamalarının veya merkezi olmayan uygulamaların(dApps) gereksinimlerinden biri de blockchain üzerinde gerçekleşen olaylardan haberdar olmaktır. Böylece uygulama kapsamına göre kullanıcıyla veya diğer uygulamalarla etkileşime girebilirler. Blockchain içerisinde gerçekleşen olayları logs yapılarından takip etmek mümkündür. Akıllı kontratlar bu yapılara veri gönderebilir ama okuyamaz. Okuma ve sorgulama işlemi blockchain node’ları üzerinden yapılmaktadır.

Events

Logs yapıları içinde tutulan veriler event verileridir. Logs yapısını bir veritabanı gibi düşünürsek events ise veri taşıyan satır gibi düşünülebilir. Solidity kodları ile event hazırlayıp gönderebiliriz yani logs’a event yazabiliriz fakat okuma yapamayız.

Peki bu ne işe yarıyor? Event yapılarıyla blockchain dışındaki yani dış dünyadaki uygulamaları tetikleme imkanı olmaktadır. Akıllı kontrat içinde yapılan bir işlemin herhangi bir web uygulamasına erişme şansı yok. Fakat event dinleyen bir web uygulamasının kontrat içindeki işlem ve değişiklikleri algılama imkanı olmaktadır. Bu köprü event ile kurulmaktadır. Kontrat kodlarında tanımlanan event ile istenilen veri gönderilir bu veri logs veritabanına kaydedilir. Yayınlanan event verisini herhangi bir uygulama dinleyebilir ve buna göre aksiyon alabilir.

Event içerisinde tanımlanan verinin indeksleme seçeneği bulunmaktadır. Indekslenmiş olarak işaretlenen veriler logs yapısında aranabilir ve filtrelenebilir tutulur. Bu şekilde logs üzerinde ilgili event verisini dinleyen veya arama yapan uygulama hızlıca indekslenmiş verilere erişebilir. İndekslenmemiş veriler abi encoded olarak saklanır ve decode edilmeleri gerekir. Indekslenmiş parametre tanımı limiti vardır, en fazla 3 adet yapılabilir.

Bu kadar teorik bilgi yeterli, events konusunu kod örneği ile daha net anlayabiliriz.

Bu örnek kodlamada AmountChanged isimli bir event tanımladık. Daha sonra changeAmount fonksiyonu içinden bu event’i kullandık. Emit ile event gönderimi yapılmakta, tanımlı olan parametre tiplerine göre event verisi dolurulup emit ile yayınlanmaktadır. Tanımladığımız event içine eski ve yeni state değerleri bulunmakta. Artık kontrat içindeki state değişkenimizin değişimleri dış dünya tarafından takip edilebilir ve buna göre aksiyon alınabilir.

Yukarıdaki kontrat kodu yayınlanıp çalıştırıldığında log’a yazılacak çıktı aşağıdaki gibi olacaktır. Örnek olarak changeAmount fonksiyonunu 123 değeri ile çağıracağım(HEX değeri : 0x7B). Üretilen log verisi aşağıdaki gibi olacaktır.

Topics[0], event tanımı hash değeridir. Buradaki örnekte AmountChanged event tanımladık bunun hash değeri : keccak256(“AmountChanged(uint, uint )”).

Topics[1], oldAmount değerini gösterir. İlk değeri 0 idi.

Topics[2], newAmount değerini yani 0x7b(123) gösterir.

Şimdi indexed tanımını bir parametreden kaldırıp tekrar yayınlayalım. Event tanımı aşağıdaki gibi olsun.

event AmountChanged(uint oldAmount, uint indexed newAmount);

changeAmount fonksiyonunu yine aynı değerle çağırdığımızda log kaydı aşağıdaki gibi olacaktır.

Görüleceği üzere artık üç adet Topics yok. Indekslemediğimiz oldAmount topics içine eklenmedi. Fakat Data içerisinde bulunmakta.

Son örnekle konuyu sonlandıralım.

Bu örnekte AccountCreated isimli bir event tanımladık. Kontratın amacı bir banka hesabı oluşturmak ve hesap oluşma işlemi sonrasında bir event yayınlamaktır. Kodlamada herhangi bir güvenlik kontrolü, önlem vs. yoktur, sadece event örneği içindir. ceateAccount fonksiyonu içinde BankAccount nesnesi yaratılır ve accounts dizisine eklenir. Devamında AccountCreated event emit edilerek işlem sonlanır.

Bu kodlamada görüleceği üzere BankAccount tipinde bir değişken ve uint256 tipinde bir değişken verisinden event oluşturduk. Bu şekilde event yayınlaması da mümkündür. Bunun logs tarafındaki karşılığı aşağıdaki gibi olacaktır.

Topics[0], BankAccount içindeki veri yerine hash değeri geldi. Bu nedenle kompleks tiplerle çalışmak yerine sistem tipleri kullanılması önerilir.

Topics[1], uint256 tipinde dizi uzunluğunu ifade eden veri(tek eleman ekledik bu durumda : 1).

Örnekler kullanıma göre artırılabilir. Tanım ve kullanımı gayet kolaydır.

Tanım :

event EventAdı(tip tipAdı, …);

Event yayınlama :

emit EventAdı(değer1, …);

Event dinleyen web3 uygulamaları örneklerine sonraki yazılarda değinmek üzere okuduğunuz için teşekkürler.

Serideki diğer yazılar:

Temel Bilgiler

İlk Akıllı Kontrat ve Remix

Tipler

Contract ve Function

Interface ve Library

Veri Yönetimi

Engin Ünal

Ethereum Virtual Machine (EVM), veri saklama ve yönetimini kullanım yerine göre farklı şekillerde sağlamaktadır. Bunlara başlıklar halinde değinmeye çalışacağım. Takip edeceğim sıralama Storage, Memory, Calldata, Code. Bu başlıklardan sonra bu konuları toparlayıp özet geçerek kullanım örneği ile açıklamaya çalışıp bitireceğim. İşin detayına girmek istemeyenler için özet başlığı altında yeterli açıklama bulunmaktadır.

Konuyu bir cümle ile özetlemeye çalışırsam şöyle bir tanım yapabilirim: EVM bir sanal makine ve akıllı kontratı bir bilgisayar programı olarak varsayalım bu durumda storage’ı veritabanı, memory’i RAM, logs yapısını sistem log dosyaları gibi düşünmek daha kolay anlamayı sağlayabilir. Şimdi bunları daha yakından inceleyelim.

Storage

Akıllı kontrat içinde tanımlanmış tüm state değişkenleri kalıcı saklama alanında yani blockchain üzerinde depolanır. Bu tip saklama tipine storage ismi verilmektedir. Her bir kontrat için ayrı olarak oluşturulan, state değişkenlerinin saklandığı, okuma/yazma yapılabilen bir veri saklama alanıdır. Bilgisayarlardaki sabit disk gibi düşünülebilir, bilgisayar kapatılıp açıldığında sabit diskteki kaydedilmiş verilerin kaybolmaması gibi EVM tarafından kontrat her çalıştırıldığında state verilerine son kaydedildiği değerlerden kayıpsız olarak erişilebilir. Biraz daha detayına bakalım.

Storage kalıcı bir saklama alanıdır tanımı yapmıştık, storage iç yapısı slot’lardan oluşmaktadır. Her slot 32-byte(256-bit) uzunluktadır. Maksimum slot sayısı ise 2²⁵⁶ olarak tanımlıdır.

State değişkenleri tanımlandığı sıraya göre slot’lara referans edilirler. Kontrat üzerinde inceleyelim. Aşağıdaki kod örneğinde Storage1 isimli bir kontratımız var ve içerisinde uint256 tipinde a,b,c,d,e,f,g,h,i,j,k state değişkenleri bulunmakta. uint256 veya uint, 256-bit yani 32-byte’tır.

contract Storage1 {
  uint256 a;
  uint256 b;
  uint256 c;
  uint256 d;
  uint256 e;
  uint256 f;
  uint256 g;
  uint256 h;
  uint256 i;
  uint256 j;
  uint256 k;

  constructor() {
    f = 0xfafafa;
    k = 0xababab;
  }
}

Örnek kontrat içindeki değişkenlerin storage slotları sıfırdan başlayarak yerleşecektir. uint256 32-byte’lık bir veri tipi olduğundan her bir state değişkeni bir slot kaplar. Bu durumda slot görüntüsü:

Konunun daha detayını merak edenler için bu yerleşimin nasıl gerçekleştirildiğini ve değer ataması yapılırken nasıl bir mekanizma çalışyor? Gas tüketimi ile ilgisi nasıl? İnceleyelim. Yukarıdaki Storage1 kontratı derleyip opcode içindeki komutlara baktığımızda:

PUSH1 0x80 PUSH1 0x40 MSTORE CALLVALUE DUP1 ISZERO PUSH1 0xF JUMPI PUSH1 0x0 DUP1 REVERT JUMPDEST POP PUSH3 0xFAFAFA PUSH1 0x5 SSTORE PUSH3 0xABABAB PUSH1 0xA SSTORE PUSH1 0x3F DUP1 PUSH1 0x2B PUSH1 0x0 CODECOPY PUSH1 0x0 RETURN INVALID PUSH1 0x80 PUSH1 0x40 MSTORE PUSH1 0x0 DUP1 REVERT INVALID LOG2 PUSH5 0x6970667358 0x22 SLT KECCAK256 0xEE 0xCC SAR 0xE3 SDIV 0x1E SWAP8 0xC6 NUMBER PUSH5 0x1D00C2E1F7 CALLVALUE 0x4A 0xC7 CALLCODE 0xD3 0x2D TIMESTAMP 0x2B CODESIZE LOG1 0x26 DUP10 PUSH16 0x4B794CFB64736F6C6343000807003300

0xFAFAFA değeri 0x5 deki slot’a yazılacak, 0xABABAB değeri 0xA daki slot’a yazılacak. Slot yerleşimine bakarsak 0x5 no’lu slotta f değişkeni var, 0xA yani 10 no’lu slotta ise k değişkeni bulunmakta. SSTORE komutu ile storage kaydı işlemi gerçekleştirilmekte. Yani bu kontrat için EVM opcodes incelendiğinde çıkarılan sonuç: f ve k değişkenlerine değer atamaları yapılmış ve storage’a kaydedilmiş.

Diğer state değişkenleri için bir sstore komutu bulunmamakta. Bu da demektir ki bir değer atanmadığı sürece storage üzerinde bir işlem yapılmamakta yani maliyeti olmamaktadır. Storage üzerinde yazma ve yazılmış bir state değişkeninin okuma işlemlerinin maliyeti bulunur. SSTORE ve SLOAD komutları storage’a yazan ve oradan okuma yapan komutlardır.

Her bir slot için ön tanımlı değer sıfır olarak atanmaktadır. Yani değişkene ilk değer ataması yaparken sıfır değer verilmesine gerek yoktur. Eğer sıfırdan farklı bir değer atanmamış ise state değişkeninin maliyeti yoktur yani gas tüketimi yoktur.

Başka bir örnek üzerinden gidelim.

contract Storage2 {
  uint256 a;
  uint256[3] b;

  struct StructTest {
    uint256 x;
    uint256 y;
    uint256 z;
  }

  StructTest c;

  constructor() {
    a = 0xAAAAAA;
    b[0] = 0xBBBBBB;
    c.x = 0xC0C0C0;
    c.y = 0xC1C1C1;
    c.z = 0xC2C2C2;
  }
}

opcode çıktısı:

PUSH1 0x80 PUSH1 0x40 MSTORE CALLVALUE DUP1 ISZERO PUSH1 0xF JUMPI PUSH1 0x0 DUP1 REVERT JUMPDEST POP PUSH3 0xAAAAAA PUSH1 0x0 SSTORE PUSH3 0xBBBBBB PUSH1 0x1 SSTORE PUSH3 0xC0C0C0 PUSH1 0x4 SSTORE PUSH3 0xC1C1C1 PUSH1 0x5 SSTORE PUSH3 0xC2C2C2 PUSH1 0x6 SSTORE PUSH1 0x3F DUP1 PUSH1 0x40 PUSH1 0x0 CODECOPY PUSH1 0x0 RETURN INVALID PUSH1 0x80 PUSH1 0x40 MSTORE PUSH1 0x0 DUP1 REVERT INVALID LOG2 PUSH5 0x6970667358 0x22 SLT KECCAK256 BALANCE BLOCKHASH SWAP13 PUSH22 0x3DDF8CF6E74D025ADD302076288B6F9DB1E99BBBD758 0x25 0x2A 0x1F CODESIZE STATICCALL 0xD2 PUSH5 0x736F6C6343 STOP ADDMOD SMOD STOP CALLER

Slot yerleşimi:

Dikkat edilirse b[1] ve b[2] değişkenlerinin değerlerinde bir değişiklik yapılmadığı için storage üzerinde bir tüketimleri yok. Peki değişkenleri storage bilgimizi kullanarak daha verimli nasıl tanımlayabilirdik? Örnek üzerinden görelim.

contract Storage3 {
  uint64 a;
  uint64 b;
  uint64 c;
  uint64 d;

  constructor() {
    a = 0xA0A0A;
    b = 0xB0B0B0;
    c = 0xC0C0C0;
    d = 0xD0D0D0;
  }
}

Yukarıdaki şekildeki tanımlamada sadece bir slot kullanılır. Slot uzunluğunun 32-byte olduğunu düşündüğümüzde eğer değişkenlerimiz slot içerisine sığabilecek boyutlara indirilebiliyorsa fazladan slot rezerve etmeden kullanmak mümkündür. Derleme sonrasında opcode çıktısındaki komut listesi incelenirse bir adet SSTORE görülecektir.

Kendi örneklerinizi de yazıp slot kullanımını inceleyebilirsiniz. Burada küçük bir detay bulunur, statik bir array tanımlandığında önceki slot içinde boş yer olmasına rağmen ve array buna sığabilecek görünmesine rağmen yeni slot açılıyor. Veya array sonrasında yapılan bir tip değişkeni tanımı array’in bittiği slotta kalan yere sığabiliyor görünmesine rağmen yeni slot açılmakta. Örneğin

uint32 a;
uint32[2] b;

veya

uint32[2] b;
uint32 a;

Gibi tanımlamada iki slot kullanıldığı görülecektir. Oysa toplam 32-byte etmeyen bir alan ayırmak istiyoruz. a : 4-byte, b : 8-byte toplamda 12-byte için iki slot rezerve ediliyor. Burada garip bir durum var neden bu şekilde? Sorunun cevabı slot rezervasyonundaki algoritmanın bazı kurallar uygulamasıdır.

Dikkat edilmesi gereken bazı slot yerleşim kuralları :

• Struct ve array yapıları her zaman yeni bir slot ayırarak başlar.
• Struct veya array sonrasındaki tipler her zaman yeni bir slot’tan başlar.

Statik olarak tanımlanan değişkenlerin storage slotlarındaki yerleşimlerini gördük, şimdi dinamik tanımlanan değişkenleri inceleyelim. Statik değişkenlerde slot yerleşimlerinin hesaplanması çok daha kolay algoritmalarla sağlanabilmekte fakat iş dinamik değişkenlere geldiğinde karmaşıklaşabiliyor. Bunun nedeni de rezerve edilecek alanın önceden bilinmemesi ve dinamik olarak değişebilmesidir. Konunun çok fazla uzaması nedeniyle dinamik array ve mapping yapılarındaki slot rezervasyon işlemine iki cümle ile değinip geçeceğim.

Dinamik array yapılarında array’in başladığı slot numarasında array uzunluğu tutulur. Array elemanlarına ise hash(slot numarası) + (indeks * tip uzunluğu) formulüyle hesaplanarak erişilebilir. Mapping için de buna benzer bir algoritma ile slot yerleşimleri hesaplanmaktadır. Farkı ise mapping için bir indeks olmadığı için mapping ilk slot adresinde length tutulmaz. İlk slot numarası ve key hash bilgisi hesaplanarak okuma /yazma yapılacak slot numarası hesaplanır.

Storage mekanizmanın nasıl çalıştığını genel olarak anlamak daha verimli akıllı kontrat yazmayı kolaylaştıracağından önemlidir. Bir örnekle konuyu bitirelim. Diyelim ki kontrat içinde üç adet state değişkenimiz olsun.

uint128 a;
uint256 b;
uint128 c;

Herhangi bir kodlama düzenlemesi yapmadan ve sadece değişkenlerin kontrat içindeki yerleşimiyle oynayarak bile daha az gas tüketen kontratlar geliştirilebilir. Yukarıdaki örnekte 3 slot rezerve edilecektir.

uint128 a;
uint128 c;
uint256 b;

Oysa bunu yukarıdaki gibi değiştirdiğimizde 2 slot ile aynı işi gerçekleştirebiliriz. Benzer şekilde struct kullanımları ile değişkenlerin paketlenerek daha az slot rezerve etmesi ile daha az gas tüketen kontrat kodları üretilebilir.

Storage pahalı bir yapıdır, blockchain gibi dağıtık sistemler üzerinde veri saklamak, merkezi yapılarda veri saklamaya göre oldukça maliyetlidir. Bu nedenle gereksiz veya fazla verilerin storage’da saklanması önerilmez.

Memory

Memory, verinin kontrat çalışma zamanında saklandığı ve sonrasında silindiği yani veriyi geçici süreyle tutan yapılardır. RAM gibi de düşünülebilir. Akıllı kontrat, çalıştığı sürece memory içinde tutulan veriye erişerek her türlü işlemi gerçekleştirebilir, işlem sonlandığında rezerve edilen memory serbest bırakılır ve içindeki veriler silinir. Kontrat tekrar çalıştığında memory sıfırdan tekrar rezerve edilecek ve çalışma anı için oluşturulacaktır. Bu nedenle memory kullanımında bu alanın geçici olarak oluşturulduğunu ve içindeki verinin saklanmayacağını bilerek kodlama yapılmalıdır.

Aşağıdaki örnek ile devam edelim. s_ ile başlayan değişkenler storage’da saklanırken m_ ile başlayanlar memory’de saklanmaktadır.

Solidity compiler, özel tipler için storage, memory veya calldata tanımının yapılmasını ister. Bunlar struct, array, string ve mapping tanımlarıdır. Mapping memory ile kullanılamaz. Bu tiplerin yüksek boyutlara ulaşabilecek yer ihtiyaçları olabilir veya dinamik tanımlandıklarında çalışma sırasında değişken boyutlarda olabilirler. Solidity bunların veri yönetimlerini hangi veri ortamında(storage, memory) yapacağını bilmek ister. Fakat bundan önemlisi doğrudan storage değişkenleri üzerinde işlem yapmak maliyetlidir. Memory değişkenleri ile çalışmak gas tüketimini düşürecektir.

Şöyle de düşünebiliriz storage’da tanımlı 1000 elemanlı bir array olsun. Bunun elemanlarını gezmek yüksek maliyetler çıkarabilir. Oysa bunu bir memory’e atıp memory’deki array üzerinde çalışmak çok daha verimli olacaktır.

Memory konusunu anlayabilmek için şimdi yukarıdaki örnek üzerinden gidelim. User isimli struct tanımladık ve user1 isimli state değişkeni storage’da saklanır, AssignTest1 çağırıldığında storage üzerinde güncelleme işlemi yapar ve state değişkeni değişir.

AssignTest2 içinde user2 değişkeni tanımladık ve memory anahtar kelimesini kullandık. Bu şekildeki kullanımda user2 memory’de tanımlanmış olur sadece bu fonksiyon içinde geçerlidir ve fonksiyon çalışmasını bitirdiğinde erişilemez.

AssignTest3 içinde user3 değişkenini tanımlarken storage anahtar kelimesi kullanıldı ve user1'den atama yapıldı, böylece user2 üzerinde yapılan her değişiklik aynı zamanda user1 üzerinde yapılmış olacaktır. Yani user3 değişkeni user1 state değişkeninin storage adres referansını alacaktır.

AssignTest4 içinde user4 değişkenini tanımlarken memory anahtar kelimesi kullanıldı ve user1'den atama yapıldı, bu şekilde user4 üzerinde yapılan değişiklikler user1 state değişkenini etkilemez. Yani user4 değişkeni user1 state değişkeninin içeriğinin kopyalanmış halini alacaktır. Memory ile tanımlı değişkenler için yeni memory alanı ayrılarak değişken içeriği buraya kopyalanır. Yapılan güncelleme işlemleri sadece ilgili memory alanını etkiler.

Memory tanımları state değişkenleri gibi kontrat seviyesinde yapılamaz, fonksiyon parametreleri ve fonksiyon içerisinde kullanılabilir.

Calldata

Calldata, memory yapılarına benzer ancak değiştirilemezdir. Yani salt okunurdur. Transaction aracılığı ile yapılan fonksiyon çağrılarındaki verileri içerir. Adı üstünde çağrı verisini ifade eder yani msg.data içeriğidir.

Yukarıdaki örnek üzerinden gidelim. CallDataSample1 fonksiyonunun strCallData parametresi msg.data’dan gelen değiştirilemez calldata verisidir. Bunu sadece okuyabiliriz fakat yazamayız. Aynı fonksiyon içinde yeni bir string değişken olan newData değişkeni oluşturuluyor ve içerisine diğer fonksiyonların da ürettiği string değerler eklenip dönüş yapılıyor.

Örnekteki CallDataSample2 fonksiyonu aynı şekilde calldata özelliğinde parametre alarak buna ekler yapar ve yeni bir string üreterek döner.

CallDataSample3 ise memory string alır. Çağırıldığı yer incelendiğinde parametre olarak calldata geçildiği görülecektir. Bu bir yanlışlık gibi görünse de değildir. strMemData parametresi memory olarak tanımlandığı için calldata olarak tanımlanan strCallData parametresini alır ve yeni bir string üreterek içeriğini kopyalar. Böylece elimizde değiştirilebilir strMemData değişkenimiz olur. Solidity’in alt tarafta yaptığı işlem aşağıdaki mantıkta olacaktır.

string memory strMemData = strCallData;

Tekrar belirtmek gerekirse calldata sadece fonksiyon parametreleri için kullanılabilir, değiştirilemez sadece okuma yapılabilir.

Code

Akıllı kontrat içinde tanımlanan state değişkenlerinin storage’a kaydedildiğini, fonksiyon içindeki veya parametrelerinde memory tanımı yapılan değişkenlerin memory’e kaydedildiğini gördük. Calldata ise msg.data’dan gelen değişmez çağrı verisiydi. Bunların dışında code alanında saklanan veri de mevcuttur. Code isminden kasıt aslında akıllı kontrat kodlarıdır. Örnekle açıklarsak.

Akıllı kontrat içerisindeki constant ve immutable olarak tanımlanan veriler code içerisinde yani kontrat bytecode’unda saklanır. Bunlar aslında değişken gibi davranmaz. Solidity compiler, constant kullanılan yerlerde ilgili constant adı karşılığına onun değerini koyar.

Özet

Storage, blockchain’e kaydedilen verilerdir, hard disk gibi düşünülebilir. Memory, akıllı kontrat çalışırken fonksiyonlar tarafından kullanılan verilerdir, RAM gibi düşünülebilir. Calldata, transaction ile bir fonksiyon çağırılırken transaction.data veya msg.data içerisinde gelen fonksiyon parametre verileridir, değiştirilemez.

Storage ve memory kullanımı ile ilgili aşağıdaki kodlama örneği incelenebilir. Kod içerisinde açıklamalar eklenmiştir.

Calldata kullanım örneği:

function CalldataTest(string calldata cdString) external pure {
  //calldata degeri a degiskenine kopyalanır.
  string memory a = cdString;

  //a degiskeni memory tanımlandigindan degistirilebilir,
  //bu degisiklik cdString degiskenini etkilemez.
  a = "123abc"; 

  //calldata tanımı yapılırsa icerik degistirilemez.
  string calldata b = cdString; 
  //derleme hatası verir --> b = "aaa";
}

Yazının sonuna geldik. Umarım yeteri kadar açıklayıcı olmuştur. Okuduğunuz için teşekkürler.

Serideki diğer yazılar:

Temel Bilgiler

İlk Akıllı Kontrat ve Remix

Tipler

Contract ve Function

Interface ve Library

Engin Ünal