EVM Gas Ücreti Optimizasyonu - Ethereum Akıllı Sözleşmeler Geliştirme Rehberi

Ethereum ana ağındaki Gas ücretleri, özellikle ağın yoğun olduğu zamanlarda, oldukça dikkat çeken bir sorun olmuştur. Yoğun dönemlerde kullanıcılar genellikle pahalı işlem ücretleri ödemek zorunda kalmaktadır. Bu nedenle, akıllı sözleşme geliştirme aşamasında Gas ücretlerini optimize etmek son derece önemlidir. Gas tüketimini optimize etmek, işlem maliyetlerini etkin bir şekilde azaltmanın yanı sıra işlem verimliliğini de artırarak kullanıcılara daha ekonomik ve verimli bir blok zinciri deneyimi sunar.

Bu makale, Ethereum sanal makinesi ( EVM )'in Gas ücreti mekanizmasını, Gas ücreti optimizasyonuna ilişkin temel kavramları ve akıllı sözleşmeler geliştirirken Gas ücreti optimizasyonu için en iyi uygulamaları özetleyecektir. Bu içeriğin geliştiricilere ilham ve pratik yardım sağlamasını umuyoruz, aynı zamanda sıradan kullanıcıların EVM'in Gas ücretlerinin işleyişini daha iyi anlamalarına yardımcı olmasını ve blockchain ekosistemindeki zorluklarla birlikte başa çıkmalarını sağlamasını diliyoruz.

EVM'nin Gas Ücreti Mekanizması Hakkında Kısa Bilgi

EVM ile uyumlu ağlarda, "Gas", belirli bir işlemi gerçekleştirmek için gereken hesaplama gücünü ölçen bir birimdir.

EVM yapısının düzeninde, Gas tüketimi üç bölüme ayrılır: işlem yürütme, dış mesaj çağrısı ve bellek ile depolamanın okuma/yazma işlemleri.

Her işlem için gerekli olan hesaplama kaynakları nedeniyle, sonsuz döngü ve hizmet reddi ( DoS ) saldırılarını önlemek amacıyla belirli bir ücret alınacaktır. Bir işlemi tamamlamak için gereken ücret "Gas ücreti" olarak adlandırılır.

EIP-1559'un yürürlüğe girmesinden bu yana, Gas ücreti aşağıdaki formülle hesaplanmaktadır:

Gaz ücreti = kullanılan gaz birimleri * ( temel ücret + öncelik ücreti )

Temel ücret yok edilecektir, öncelikli ücret ise teşvik olarak kullanılır, doğrulayıcıları işlemleri blok zincirine eklemeye teşvik eder. İşlem gönderirken daha yüksek bir öncelikli ücret belirlemek, işlemin bir sonraki blokta yer alması olasılığını artırabilir. Bu, kullanıcıların doğrulayıcılara ödediği bir tür "bahşiş" gibidir.

EVM'deki Gas optimizasyonunu anlama

Solidity ile akıllı sözleşmeler derlendiğinde, sözleşme bir dizi "işlem koduna" yani opcodes'a dönüştürülür.

Her bir opcode ( örneğin akıllı sözleşme oluşturma, mesaj çağrısı yapma, hesap depolamasına erişme ve sanal makinede işlem gerçekleştirme ) için kabul edilen bir Gas tüketim maliyeti vardır, bu maliyetler Ethereum sarı kitabında kayıtlıdır.

Birçok EIP değişikliğinden sonra, bazı işlem kodlarının Gas maliyetleri ayarlandı, bu da sarı kitabın içeriğiyle farklılık gösterebilir.

Gaz optimizasyonunun temel kavramı

Gas optimizasyonunun temel ilkesi, EVM blok zincirinde maliyet etkinliği yüksek işlemleri öncelikli olarak seçmek ve Gas maliyeti yüksek işlemlerden kaçınmaktır.

EVM'de, aşağıdaki işlemlerin maliyeti daha düşüktür:

• Bellek değişkenlerini okuma ve yazma
• Sabit ve değişmez değişkenleri oku
• Yerel değişkenleri okuma ve yazma
• calldata değişkenini oku, örneğin calldata dizisi ve yapısı
• Dahili fonksiyon çağrısı

Maliyeti yüksek olan işlemler şunlardır:

• Sözleşme depolamasında saklanan durum değişkenlerini yazma ve okuma
• Dış fonksiyon çağrısı
• Döngüsel işlem

EVM Gas Ücretleri Optimizasyonu En İyi Uygulamaları

1. Depolama kullanımını mümkün olduğunca azaltın

Solidity'de, Storage( depolama) sınırlı bir kaynaktır ve Gas tüketimi, Memory( belleği) çok daha yüksektir. Her akıllı sözleşme depolamadan veri okuduğunda veya yazdığında yüksek Gas maliyetleri ortaya çıkar.

Ethereum sarı kitabına göre, depolama işlemlerinin maliyeti bellek işlemlerinin maliyetinden 100 kat daha fazladır. Örneğin, OPcodesmload ve mstore talimatları yalnızca 3 Gas birimi tüketirken, depolama işlemleri olan sload ve sstore en ideal durumda bile en az 100 birim maliyet gerektirir.

Saklama kullanımını sınırlama yöntemleri şunlardır:

• Geçici verileri bellek içinde depolamak
• Depolama değişiklik sayısını azaltma: Ara sonuçları bellekte saklayarak, tüm hesaplamalar tamamlandıktan sonra sonuçları depolama değişkenlerine atama.

2. Değişken paketleme

akıllı sözleşmelerde kullanılan Storage slot( depolama yuvasının) sayısı ve geliştiricilerin verileri ifade etme şekli, Gas ücretinin tüketimini büyük ölçüde etkileyecektir.

Solidity derleyicisi, derleme sürecinde ardışık depolama değişkenlerini paketleyecek ve 32 baytlık depolama yuvasını değişken depolamanın temel birimi olarak kullanacaktır. Değişken paketleme, değişkenlerin mantıklı bir şekilde düzenlenmesiyle, birden fazla değişkenin tek bir depolama yuvasına sığabilmesi anlamına gelir.

Değişken paketleme ile geliştiriciler büyük miktarda Gas birimi tasarrufu yapabilir. Her depolama alanı Gas tükettiğinden, değişken paketleme gerekli depolama alanı sayısını azaltarak Gas kullanımını optimize eder.

3. Veri türlerini optimize etme

Uygun veri türünü seçmek, Gas kullanımını optimize etmeye yardımcı olur. Örneğin, Solidity'de, tam sayılar farklı boyutlara ayrılabilir: uint8, uint16, uint32 vb. EVM 256 bitlik birimlerle işlem yaptığı için, uint8 kullanmak, EVM'nin önce bunu uint256'ya dönüştürmesi gerektiği anlamına gelir ve bu dönüşüm ek olarak Gas tüketir.

Ancak, değişkenleri paketleyerek optimize ederseniz, dört uint8 değişkenini bir depolama alanına paketlemenin toplam maliyeti, dört uint256 değişkeninden daha düşük olacaktır. Böylece, akıllı sözleşme bir depolama alanını bir kez okuyup yazabilir ve tek bir işlemle dört uint8 değişkenini bellek/depolama alanına yerleştirebilir.

4. Sabit boyutlu değişkenleri dinamik değişkenlerin yerine kullanın

Eğer veriler 32 bayt içinde kontrol edilebiliyorsa, bytes veya strings yerine bytes32 veri türünü kullanmanız önerilir. Genel olarak, sabit boyutlu değişkenler, değişken boyutlu değişkenlerden daha az gaz tüketir. Bayt uzunluğu kısıtlanabiliyorsa, mümkün olduğunca bytes1'den bytes32'ye en küçük boyutu seçin.

5. Haritalama ve Diziler

Solidity verileri listesi iki veri türü ile temsil edilebilir: diziler (Arrays ) ve haritalar (Mappings ), ancak sözdizimi ve yapıları tamamen farklıdır.

Çoğu durumda, haritalama daha verimlidir ve daha düşük maliyetlidir, ancak diziler yinelemeli olup veri türlerini paketlemeyi destekler. Bu nedenle, veri listelerini yönetirken haritalamanın öncelikli olarak kullanılması önerilir, yalnızca yineleme gerektiğinde veya veri türlerinin paketlenmesiyle Gas tüketimi optimize edilebiliyorsa.

6. calldata yerine memory kullanın

Fonksiyon parametrelerinde tanımlanan değişkenler calldata veya bellek içinde depolanabilir. İkisi arasındaki temel fark, belleğin fonksiyon tarafından değiştirilebilmesi, oysa calldata'nın değiştirilemez olmasıdır.

Bu prensibi unutmayın: Eğer fonksiyon parametreleri sadece okunabilir ise, öncelikle calldata kullanmalısınız, memory yerine. Bu, fonksiyonun calldata'sından memory'e gereksiz kopyalama işlemlerini önleyebilir.

7. Mümkünse Constant/Immutable anahtar kelimelerini kullanın

Constant/Immutable değişkenler, sözleşmenin depolama alanında saklanmaz. Bu değişkenler, derleme zamanında hesaplanır ve sözleşmenin bayt kodunda saklanır. Bu nedenle, depolamaya kıyasla erişim maliyetleri çok daha düşüktür, bu yüzden mümkünse Constant veya Immutable anahtar kelimelerinin kullanılmasını öneririz.

8. Taşma/alt taşma olmayacağından emin olurken Unchecked kullanın

Geliştiriciler, aritmetik işlemlerin taşma veya alt sınır aşımına neden olmayacağını belirleyebildiklerinde, gereksiz taşma veya alt sınır aşımını kontrol etmekten kaçınmak için Solidity v0.8.0 ile tanıtılan unchecked anahtar kelimesini kullanabilir ve böylece Gas maliyetinden tasarruf edebilir.

Ayrıca, 0.8.0 ve üzeri sürümlerde derleyicinin SafeMath kütüphanesini kullanması gerekmemektedir, çünkü derleyici kendisi taşma ve alt taşma koruma işlevlerini yerleşik olarak sunmaktadır.

9. Optimizasyon Değiştirici

Değiştirici kodu, değiştirilmiş fonksiyona gömülmüştür, her değiştirici kullanıldığında, kodu kopyalanır. Bu, bytecode boyutunu artırır ve Gas tüketimini yükseltir. Bytecode boyutunu azaltmak ve Gas maliyetini düşürmek için mantığı iç fonksiyon olarak yeniden yapılandırarak bu iç fonksiyonu değiştiricide tekrar kullanabilirsiniz.

10. Kısa Devre Optimizasyonu

|| ve && operatörleri için, mantıksal işlemler kısa devre değerlendirmesi yapar; yani eğer ilk koşul mantıksal ifadenin sonucunu belirleyebiliyorsa, ikinci koşul değerlendirilmez.

Gas tüketimini optimize etmek için, hesaplama maliyeti düşük olan koşulların öncelikli olarak yerleştirilmesi gerekmektedir, bu şekilde maliyeti yüksek hesaplamaların atlanması mümkün olabilir.

Ek Genel Tavsiyeler

1. Gereksiz kodları sil

Eğer sözleşmede kullanılmayan fonksiyonlar veya değişkenler varsa, bunların silinmesi önerilir. Bu, sözleşme dağıtım maliyetlerini azaltmanın ve sözleşme boyutunu küçük tutmanın en doğrudan yoludur.

Aşağıda bazı pratik öneriler bulunmaktadır:

• En verimli algoritmaları kullanarak hesaplama yapın. Eğer sözleşme içinde bazı hesaplamaların sonuçları doğrudan kullanılıyorsa, bu gereksiz hesaplama süreçlerinin ortadan kaldırılması gerekir. Özünde, kullanılmayan her hesaplama silinmelidir.

• Ethereum'da, geliştiriciler depolama alanını serbest bırakarak Gaz ödülü alabilirler. Artık bir değişkene ihtiyaç yoksa, onu silmek için delete anahtar kelimesini kullanmalı veya varsayılan değerine ayarlamalıdır.

• Döngü optimizasyonu: Yüksek maliyetli döngü işlemlerinden kaçınmak, döngüleri birleştirmek ve tekrarlanan hesaplamaları döngü gövdesinin dışına almak.

2. Önceden derlenmiş akıllı sözleşmeler kullanma

Önceden derlenmiş akıllı sözleşmeler, şifreleme ve karma işlemleri gibi karmaşık kütüphane fonksiyonları sağlar. Kod EVM üzerinde değil, istemci düğümünde yerel olarak çalıştığı için gereken Gaz daha azdır. Önceden derlenmiş akıllı sözleşmeler kullanarak, akıllı sözleşmelerin yürütülmesi için gereken hesaplama yükünü azaltarak Gaz tasarrufu sağlanabilir.

Önceden derlenmiş sözleşme örnekleri arasında eliptik eğri dijital imza algoritması (ECDSA) ve SHA2-256 hash algoritması bulunmaktadır. Akıllı sözleşmelerde bu önceden derlenmiş sözleşmeleri kullanarak, geliştiriciler Gas maliyetlerini düşürebilir ve uygulamaların çalışma verimliliğini artırabilir.

3. Satır içi derleme kodu kullanma

İç içe derleme ( in-line assembly ) geliştiricilerin EVM tarafından doğrudan yürütülebilen düşük seviyeli ancak verimli kod yazmalarına olanak tanır, pahalı Solidity operasyon kodları kullanmadan. İç içe derleme ayrıca bellek ve depolama kullanımını daha hassas bir şekilde kontrol etmeyi sağlar, böylece Gas ücretlerini daha da azaltır. Ayrıca, iç içe derleme, yalnızca Solidity kullanılarak gerçekleştirilmesi zor bazı karmaşık işlemleri gerçekleştirebilir ve Gas tüketimini optimize etmek için daha fazla esneklik sağlar.

Ancak, iç içe montaj kullanmak da riskler taşıyabilir ve hata yapma olasılığını artırabilir. Bu nedenle, dikkatli kullanılmalı ve yalnızca deneyimli geliştiricilerin işlemesi için sınırlı tutulmalıdır.

4. Layer 2 çözümlerini kullanma

Layer 2 çözümlerinin kullanılması, Ethereum ana ağında depolanması ve hesaplanması gereken veri miktarını azaltabilir.

Rolluplar, yan zincirler ve durum kanalları gibi Layer 2 çözümleri, işlem işlemesini ana Ethereum zincirinden boşaltarak daha hızlı ve daha ucuz işlemler gerçekleştirmeyi mümkün kılar.

Bu çözümler, büyük miktarda işlemi bir araya getirerek, zincir üzerindeki işlem sayısını azaltmakta ve dolayısıyla Gas ücretlerini düşürmektedir. Layer 2 çözümlerinin kullanılması ayrıca Ethereum'un ölçeklenebilirliğini artırarak daha fazla kullanıcı ve uygulamanın ağa katılabilmesini sağlamakta, bu da sonuçta