Ethereum akıllı sözleşmeler Gas optimizasyon uygulama kılavuzu

Ethereum ana ağındaki Gas ücretleri, özellikle ağın yoğun olduğu zamanlarda karmaşık bir sorun olmuştur. Yoğun dönemlerde kullanıcılar genellikle yüksek işlem ücretleri ödemek zorundadır. Bu nedenle, akıllı sözleşmeler geliştirme aşamasında Gas ücretlerinin optimize edilmesi 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 verimli bir blockchain deneyimi sunar.

Bu makale, Ethereum Sanal Makinesi ( EVM )'in Gas ücreti mekanizmasını, Gas ücreti optimizasyonunun ilgili temel kavramlarını ve akıllı sözleşmeler geliştirirken Gas ücreti optimizasyonu için en iyi uygulamaları özetleyecektir. Umarım bu içerikler geliştiricilere ilham ve pratik yardım sağlar, aynı zamanda sıradan kullanıcıların EVM'nin Gas ücreti işleyişini daha iyi anlamalarına yardımcı olur ve blockchain ekosistemindeki zorluklarla birlikte başa çıkmalarına olanak tanır.

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

EVM 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 işlem için yürütme, hesaplama kaynakları gerektirdiğinden, sonsuz döngü ve hizmet reddi ( DoS ) saldırılarını önlemek için belirli bir ücret alınır. Bir işlemin tamamlanması için gereken ücrete "Gas ücreti" denir.

EIP-1559( Londra hard fork'u ) tarihinden itibaren, 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. İşlemi 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 ödedikleri bir "bahşiş" gibidir.

EVM'de Gas optimizasyonunu anlama

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

Herhangi bir opcode ( örneğin sözleşme oluşturma, mesaj çağrısı yapma, hesap depolamasına erişme ve sanal makinede işlem yürütme ) için kabul gören bir Gas tüketim maliyeti vardır, bu maliyetler Ethereum sarı kitapta kaydedilmiştir.

Birçok EIP değişikliğinden sonra, bazı opcode'ların Gas maliyeti ayarlanmış ve bu durum sarı kitabındaki değerlerden 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 düşüktür:

• Bellek değişkenlerini okuma ve yazma
• Sabitler ve değişmez değişkenler okumak
• Yerel değişkenleri yazma ve okuma
• calldata değişkenlerini oku, örneğin calldata dizileri ve yapılandırmaları
• İç fonksiyon çağrısı

Maliyetli işlemler şunlardır:

• Sözleşme depolamasında saklanan durum değişkenlerini okumak ve yazmak
• Harici fonksiyon çağrısı
• Döngü işlemi

EVM Gaz Ücretleri Optimizasyonu En İyi Uygulamaları

Yukarıda belirtilen temel kavramlara dayanarak, geliştirici topluluğu için bir Gas ücreti optimizasyonu en iyi uygulamalar 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şturabilirler.

1. Depolama kullanımını en aza indirin.

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

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

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

• Geçici verileri bellekte saklamak
• 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 slotu) sayısı ve geliştiricinin 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 paketler ve 32 baytlık bir depolama yuvasını değişkenlerin depolanması için temel birim olarak kullanı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ığdırılabilmesini ifade eder.

Bu ayrıntı ayarı sayesinde, geliştiriciler 20.000 Gas birimi tasarruf edebilir. ( kullanılmamış bir depolama alanı depolamak 20.000 Gas) gerektirirken, şimdi yalnızca iki depolama alanı gerekmektedir.

Her depolama alanı Gas tükettiğinden, değişken paketleme, gereken 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 tipi ile temsil edilebilir, ancak farklı veri tiplerinin karşılık geldiği işlem maliyetleri de farklıdır. Uygun veri tipini 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şlem gerçekleştirdiğinden, uint8 kullanmak, EVM'nin önce bunu uint256'ya dönüştürmesi gerektiği anlamına gelir ve bu dönüşüm ek Gas tüketimine neden olur.

Tek başına bakıldığında, burada uint256 kullanmak uint8'den daha ucuzdur. Ancak, daha önce önerdiğimiz değişken paketleme optimizasyonu durumu değiştirir. Eğer geliştiriciler dört uint8 değişkenini bir depolama alanına paketleyebilirlerse, bunların toplam maliyeti dört uint256 değişkenine göre daha düşük olacaktır. Böylece, akıllı sözleşme bir depolama alanını bir kez okuyup yazabilir ve tek bir işlemde dört uint8 değişkenini bellek/depolama alanına alabilir.

4. Sabit boyutlu değişkenler kullanarak dinamik değişkenlerin yerine geçin

Eğer veriler 32 bayt içinde kontrol edilebiliyorsa, bytes veya strings yerine bytes32 veri tipini kullanmanız önerilir. Genel olarak, sabit boyutlu değişkenler, değişken boyutlu olanlardan daha az Gaz tüketir. Bayt uzunluğu sınırlanabiliyorsa, mümkün olduğunca bytes1 ile bytes32 arasındaki en küçük uzunluğu seçin.

5. Haritalama ve diziler

Solidity'nin veri listesi iki veri tipiyle temsil edilebilir: dizi (Arrays ) ve harita (Mappings ), ancak bunların sözdizimi ve yapısı tamamen farklıdır.

Çoğu durumda, haritalama daha verimli ve daha düşük maliyetli olsa da, diziler yine de yinelemeye sahip olup veri türü paketlemesini destekler. Bu nedenle, veri listelerini yönetirken haritalamayı öncelikli olarak kullanmanız önerilir, yalnızca yineleme gerekiyorsa veya veri türü paketlemesi ile Gas tüketimini optimize edebiliyorsanız.

6. calldata yerine memory kullanın

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

Bu ilkeyi unutmayın: Eğer fonksiyon parametreleri salt okunursa, önce calldata kullanılmalı, memory yerine. Bu, fonksiyonun calldata'sından memory'ye gereksiz kopyalama işlemlerinden kaçınmayı sağlar.

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 byte 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 taşma ile sonuçlanmayacağından emin olduklarında, 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 maliyetinden tasarruf edebilirler.

Ayrıca, 0.8.0 ve üzeri sürümlerde derleyicinin SafeMath kütüphanesini kullanmasına artık gerek yoktur, çünkü derleyici kendisi taşma ve alt aşım koruma işlevlerini yerleşik olarak içermektedir.

9. Optimizasyon Değiştirici

Değiştirici kodu, değiştirilmiş işlevin içine yerleştirilmiştir, her değiştirici kullanıldığında, kodu kopyalanır. Bu, bytecode boyutunu artırır ve Gas tüketimini yükseltir.

Mantığı _checkOwner() iç fonksiyonuna yeniden yapılandırarak, bu iç fonksiyonun modifier içinde tekrar kullanılmasına izin vermek, bytecode boyutunu azaltabilir ve Gas maliyetlerini düşürebilir.

10. Kısa yol optimizasyonu

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

Gas tüketimini optimize etmek için, düşük maliyetli hesaplama koşullarının öncelikli olarak yer alması gerekir, bu şekilde yüksek maliyetli hesaplamaların atlanma olasılığı artar.

Genel Tavsiyeler Ek

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 maliyetini azaltmanın ve sözleşmenin boyutunu küçük tutmanın en doğrudan yoludur.

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

• En etkili algoritmalarla hesaplama yapın. Eğer sözleşmede bazı hesaplamaların sonuçları doğrudan kullanılıyorsa, bu gereksiz hesaplama süreçlerinin ortadan kaldırılması gerekir. Temelde, kullanılmayan herhangi bir hesaplama silinmelidir.

• Ethereum'da, geliştiriciler depolama alanını serbest bırakarak Gas ödülü alabilirler. Eğer bir değişken artık gerekli değilse, 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çının, döngüleri birleştirin ve tekrar eden hesaplamaları döngü gövdesinin dışına çıkarın.

2. Önceden derlenmiş sözleşmelerin kullanımı

Önceden derlenmiş sözleşmeler, şifreleme ve hash işlemleri gibi karmaşık kütüphane işlevleri sağlar. Kod EVM üzerinde değil, istemci düğümünde yerel olarak çalıştığı için gereken Gas miktarı 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 imza algoritması (ECDSA) ve SHA2-256 hash algoritması bulunmaktadır. Geliştiriciler, bu önceden derlenmiş sözleşmeleri akıllı sözleşmelerde kullanarak Gas maliyetlerini düşürebilir ve uygulamaların çalışma verimliliğini artırabilir.

3. Satır içi montaj kodu kullanma

İç içe montaj (in-line assembly), geliştiricilerin EVM tarafından doğrudan yürütülebilen düşük seviyeli ama etkili kodlar yazmalarına olanak tanır, bu sayede kullanmaya gerek kalmaz.