Ethereum akıllı sözleşmelerinin Gas ücretlerini optimize etmenin en iyi uygulamaları

Ethereum ana ağındaki Gas ücretleri her zaman zor bir sorun olmuştur, özellikle de ağın yoğun olduğu zamanlarda daha belirgin hale gelir. Zirve dönemlerinde kullanıcılar yüksek işlem ücretleri ödemek zorundadı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 yalnızca işlem maliyetlerini etkili bir şekilde düşürmekle kalmaz, aynı zamanda işlem verimliliğini artırarak kullanıcılara daha ekonomik ve etkili bir blok zinciri deneyimi sunar.

Bu makalede Ethereum sanal makinesi (EVM)'in Gas ücreti mekanizması, Gas ücreti optimizasyonunun temel kavramları ve akıllı sözleşmeler geliştirilirken Gas ücreti optimizasyonu için en iyi uygulamalar ele alınacaktır. Umarız bu içerikler geliştiricilere ilham ve pratik yardımcı olurken, aynı zamanda sıradan kullanıcıların EVM'in Gas ücretleri işleyişini daha iyi anlamalarına yardımcı olur ve birlikte blockchain ekosistemindeki zorluklarla başa çıkmalarına katkıda bulunur.

EVM'nin Gas Ücreti Mekanizması Hakkında

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

EVM'nin yapı 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 bir işlemin gerçekleştirilmesi için hesaplama kaynağı gerektiğinden, sonsuz döngü ve hizmet reddi ( DoS ) saldırılarını önlemek amacıyla belirli bir ücret alınır. Bir işlemi tamamlamak için gereken ücrete "Gas ücreti" denir.

EIP-1559( Londra hard fork'u ) tarihinden itibaren geçerli olduğundan beri, Gas ücreti aşağıdaki formülle hesaplanmaktadır:

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

Temel ücret yok edilecek, öncelikli ücret ise teşvik olarak kullanılacak, böylece doğrulayıcıları işlemleri blok zincirine eklemeye teşvik edecektir. İşlem gönderirken daha yüksek bir öncelikli ücret ayarlamak, işlemin bir sonraki blokta yer alma olasılığını artırabilir. Bu, kullanıcıların doğrulayıcılara ödediği bir "bahşiş" gibidir.

1. EVM'deki Gas optimizasyonunu anlama

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

Herhangi bir işlem kodu (, örneğin sözleşme oluşturma, mesaj çağrıları yapma, hesap depolama alanına erişim sağlama 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 kaydedilmiştir.

Birçok EIP değişikliğinden sonra, bazı opcode'ların Gaz maliyetleri ayarlandı ve bunlar, sarı kitabın içeriğinden farklılık gösterebilir.

2.Gas optimizasyonunun temel kavramı

Gas optimizasyonunun temel prensibi, EVM blok zincirinde maliyet verimliliği yüksek işlemleri öncelikli olarak seçmek, pahalı Gas maliyetine sahip işlemlerden kaçınmaktır.

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

• Bellek değişkenlerini okumak ve yazmak
• Sabitleri ve değişmez değişkenleri oku
• Yerel değişkenleri okumak ve yazmak
• 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 deposunda saklanan durum değişkenlerini oku ve yaz.
• Harici fonksiyon çağrısı
• Döngüsel işlem

EVM Gaz Ücreti Optimizasyonu En İyi Uygulamaları

Yukarıda belirtilen temel kavramlara dayanarak, geliştirici topluluğu için bir Gas ücreti optimizasyonu en iyi uygulama listesi derledik. Bu uygulamalara uyarak, geliştiriciler akıllı sözleşmelerin Gas ücreti tüketimini azaltabilir, işlem maliyetlerini düşürebilir ve daha verimli ve kullanıcı dostu uygulamalar oluşturabilir.

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)'den çok daha yüksektir. Bir akıllı sözleşme depolamadan veri okuduğunda veya yazdığında yüksek Gas maliyetleri oluşur.

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

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

• Geçici verileri bellek içinde saklamak
• Depolama değişiklik sayısını azaltma: Ara sonuçları bellekte tutarak, 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 alanı) sayısı ve geliştiricilerin verileri ifade etme şekli, Gas ücretlerinin tüketimini büyük ölçüde etkileyebilir.

Solidity derleyicisi, derleme sürecinde ardışık depolama değişkenlerini paketler ve 32 baytlık depolama yuvasını değişkenlerin depolanması için temel birim olarak kullanır. Değişken paketleme, birden fazla değişkenin tek bir depolama yuvasına sığacak şekilde mantıklı bir şekilde düzenlenmesi anlamına gelir.

Bu ayrıntı ayarı sayesinde, geliştiriciler 20.000 Gas birimi tasarruf edebilir. ( kullanılmamış bir depolama alanı depolamak için 20.000 Gas ) harcamak gerekmekteydi, ancak artık yalnızca iki depolama alanına ihtiyaç var.

Her depolama alanı Gas tükettiği için, değişkenlerin paketlenmesi gerekli depolama alanı sayısını azaltarak Gas kullanımını optimize eder.

3. Veri türlerini optimize et

Bir değişken birden fazla veri türü ile temsil edilebilir, ancak farklı veri türlerinin karşılık gelen işlem maliyetleri de farklıdır. Uygun veri türünü seçmek, Gas kullanımını optimize etmeye yardımcı olur.

Örneğin, Solidity'de, tamsayılar farklı boyutlara ayrılabilir: uint8, uint16, uint32 vb. EVM 256 bitlik birimlerle işlemleri yerine getirdiğinden, uint8 kullanmak EVM'nin önce bunu uint256'ya dönüştürmesi gerektiği anlamına gelir ve bu dönüşüm ek Gaz tüketir.

Tek başına bakıldığında, burada uint256 kullanmak uint8'den daha ucuzdur. Ancak, daha önce önerdiğimiz değişken paketleme optimizasyonu kullanıldığında durum farklıdır. Geliştirici dört uint8 değişkenini bir depolama slotuna paketleyebilirse, bunları yinelemenin toplam maliyeti dört uint256 değişkeninden daha düşük olacaktır. Bu şekilde, akıllı sözleşmeler bir depolama slotunu bir kez okuyup yazabilir ve tek bir işlemde dört uint8 değişkenini belleğe/depoya yerleştirebilir.

4. Sabit boyutlu değişkenler kullanarak dinamik değişkenleri değiştirme

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şkenlere göre daha az Gas harcar. Bayt uzunluğu sınırlanabiliyorsa, mümkünse bytes1'den bytes32'ye kadar en küçük boyutu seçin.

5. Haritalama ve Diziler

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

Haritalama çoğu durumda daha verimli ve daha düşük maliyetlidir, ancak diziler yine de yinelemeyi destekler ve veri türü paketlemesini destekler. Bu nedenle, veri listelerini yönetirken haritalamanın öncelikli olarak kullanılması önerilir, sadece yineleme gerekiyorsa veya veri türü paketlemesi ile Gas tüketimi optimize edilebiliyorsa.

6. calldata yerine memory kullanın

Fonksiyon parametrelerinde tanımlanan değişkenler calldata veya memory'de saklanabilir. İkisi arasındaki temel fark, memory'nin fonksiyon tarafından değiştirilebilmesi, calldata'nın ise değiştirilemez olmasıdır.

Bu prensibi unutmayın: Eğer fonksiyon parametreleri yalnızca okunuyorsa, öncelikle calldata yerine memory kullanmalısınız. Bu, fonksiyonun calldata'sından memory'ye gereksiz kopyalama işlemlerini önleyebilir.

7. Mümkün olduğunca 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, depolama ile karşılaştırıldığında erişim maliyeti çok daha düşüktür, bu yüzden mümkün olduğunca Constant veya Immutable anahtar kelimelerini kullanmanız önerilir.

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

Geliştiriciler, aritmetik işlemlerin taşma veya alt taşma ile sonuçlanmayacağını belirleyebildiklerinde, Solidity v0.8.0 ile tanıtılan unchecked anahtar kelimesini kullanarak gereksiz taşma veya alt taşma kontrollerinden kaçınabilir ve böylece Gas maliyetlerinden tasarruf edebilirler.

Ayrıca, 0.8.0 ve üzeri sürümlerde derleyici artık SafeMath kütüphanesini kullanmayı gerektirmiyor çünkü derleyici kendisi taşma ve alt taşma koruma işlevlerini yerleşik olarak barındırıyor.

9. Optimizasyon Değiştirici

Değiştiricinin kodu, değiştirilmiş fonksiyona gömülmüştür, her seferinde değiştirici kullanıldığında, kodu kopyalanır. Bu, bytecode boyutunu artırır ve Gas tüketimini yükseltir.

_checkOwner() iç işlevine dönüştürerek, bu iç işlevin modülatör içinde tekrar kullanılmasına izin vererek, bytecode boyutunu azaltabilir ve Gas maliyetini düşürebilirsiniz.

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 belirlemek için yeterliyse, ikinci koşul değerlendirilmeyecek.

Gas tüketimini optimize etmek için, hesaplama maliyeti düşük olan koşulları öne almak gerekir, böylece yüksek maliyetli hesaplamalardan atlanma olasılığı olabilir.

Ek Genel Tavsiyeler

1. Gereksiz kodları silin

Eğer sözleşmede kullanılmayan bir fonksiyon veya değişken 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 algoritmayı kullanarak hesaplama yapın. Eğer sözleşmede bazı hesaplamaların sonuçları doğrudan kullanılıyorsa, o zaman bu gereksiz hesaplama süreçleri ortadan kaldırılmalıdır. Temelde, kullanılmayan herhangi bir hesaplama silinmelidir.

Ethereum'da geliştiriciler, depolama alanı serbest bırakarak Gas ödülü kazanabilirler. Eğer bir değişkene artık ihtiyaç yoksa, onu silmek için delete anahtar kelimesini kullanmalı veya varsayılan değere ayarlamalıdır.

Döngü optimizasyonu: Yüksek maliyetli döngü işlemlerinden kaçının, döngüleri mümkün olduğunca birleştirin ve tekrar eden hesaplamaları döngü gövdesinin dışına çıkarın.

2. Önceden derlenmiş sözleşmeler kullanma

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

Önceden derlenmiş sözleşme örnekleri arasında Eliptik Eğri Dijital İmza Algoritması (ECDSA) ve SHA2-256 hash algoritması bulunmaktadır. Bu önceden derlenmiş sözleşmeleri akıllı sözleşmelerde kullanarak, geliştiriciler Gas maliyetlerini düşürebilir ve uygulamaların çalışma verimliliğini artırabilir.

3. İç içe montaj kodu kullanımı

İç içe montaj ( in-line assembly ) geliştiricilerin EVM tarafından doğrudan yürütülebilen düşük seviyeli ama etkili kodlar yazmalarını sağlar, pahalı Solidity işlem kodları kullanmadan. İç içe montaj, ayrıca bellek ve depolamanın kullanımını daha hassas bir şekilde kontrol etmeye olanak tanır, böylece Gaz ücretlerini daha da azaltır. Ayrıca, iç içe montaj şunları yapabilir