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

Ethereum ana ağındaki Gas ücretleri, özellikle ağın tıkalı olduğu zamanlarda çözülmesi zor bir sorun olmuştur. Zirve dönemlerde kullanıcılar genellikle yüksek işlem ücretleri ödemek zorunda kalıyor. Bu nedenle, akıllı sözleşme geliştirme aşamasında Gas ücretlerinin optimize edilmesi son derece önemlidir. Gas tüketiminin optimize edilmesi, yalnızca işlem maliyetlerini etkili bir şekilde azaltmakla 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 ücret mekanizmasını, Gas ücreti optimizasyonunun temel kavramlarını ve akıllı sözleşme geliştirmede Gas ücreti optimizasyonunun en iyi uygulamalarını özetleyecektir. Bu içeriklerin geliştiricilere ilham ve pratik yardım sağlamasını, aynı zamanda sıradan kullanıcıların EVM'nin Gas ücretlerinin nasıl çalıştığını daha iyi anlamalarına yardımcı olmasını umuyoruz; böylece blockchain ekosistemindeki zorluklarla birlikte başa çıkabiliriz.

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'in yapı düzeninde, Gas tüketimi üç kısma 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ınacaktır. Bir işlemi tamamlamak için gereken ücrete "Gas ücreti" denir.

EIP-1559( Londra hard fork'u ) tarihinden itibaren yürürlüğe girdiğinden beri, Gas ücreti aşağıdaki formüle göre hesaplanmaktadır:

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

Temel ücret yok edilecektir, öncelikli ücret ise teşvik olarak kullanılacak, doğrulayıcıların işlemleri blok zincirine eklemesini 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.

EVM'deki Gas optimizasyonunu anlama

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

Her 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 edilen bir Gas tüketim maliyeti vardır, bu maliyetler Ethereum sarı kitapçığında kayıtlıdır.

Birçok EIP'nin düzenlenmesinin ardından, bazı işlem kodlarının Gaz maliyeti ayarlandı ve bu, sarı kitabın içeriğinden farklı olabilir.

Gaz optimizasyonunun temel kavramı

Gas optimizasyonunun temel ilkesi, EVM blockchain'inde maliyet verimliliğ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 okumak ve yazmak
• Sabitleri ve değiştirilemez değişkenleri oku
• Yerel değişkenleri oku ve yaz.
• calldata değişkenini oku, örneğin calldata dizisi ve yapısı
• İç fonksiyon çağrısı

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

• Sözleşme depolamasında depolanan durum değişkenlerini oku ve yaz.
• 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ş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( 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ının tanımına göre, depolama işlemlerinin maliyeti bellek işlemlerinden 100 kat daha yüksektir. Örneğin, OPcodesmload ve mstore talimatları yalnızca 3 Gas birimi tüketirken, depolama işlemleri olan sload ve sstore, en ideal durumda bile, maliyeti en az 100 birim gerektirir.

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

• Geçici verileri bellekte depolayın
• Depolama değişiklik sayısını azaltma: Ara sonuçları bellekte saklayarak, tüm hesaplamalar tamamlandıktan sonra sonuçları depolama değişkenine 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 ücretinin tüketimini büyük ölçüde etkiler.

Solidity derleyicisi, derleme sürecinde ardışık depolama değişkenlerini paketler ve 32 baytlık bir depolama yuvasını değişkenlerin saklanması 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 uyum sağlaması anlamına gelir.

Bu detay ayarlaması sayesinde, geliştiriciler 20.000 Gas birimi tasarruf edebilirler. ( kullanılmamış bir depolama alanı depolamak için 20.000 Gas) harcanması gerekirken, şimdi yalnızca iki depolama alanı gerekmektedir.

Her depolama slotu Gas tükettiğinden, değişkenlerin paketlenmesi Gas kullanımını optimize etmek için gereken depolama slotu sayısını azaltır.

3. Veri türlerini optimize etme

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, tam sayılar farklı boyutlara ayrılabilir: uint8, uint16, uint32 vb. EVM'nin 256 bitlik birimlerle işlemleri gerçekleştirmesi nedeniyle, uint8 kullanmak EVM'nin önce bunu uint256'ya dönüştürmesi gerektiği anlamına gelir ve bu dönüşüm ekstra Gas tüketir.

Tek başına bakıldığında, uint256 kullanımı uint8'den daha ucuzdur. Ancak, değişkenleri paketleyerek optimize etmek durumunda farklıdır. Geliştiriciler dört uint8 değişkenini bir depolama alanına paketleyebilirse, bunları döngüye almak için toplam maliyet dört uint256 değişkenine göre daha düşük olacaktır. Böylece, akıllı sözleşmeler bir depolama alanını bir kez okuyup yazabilir ve tek bir işlemede dört uint8 değişkenini bellek/depolama alanına 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ün kullanılmasını öneririm. Genel olarak, sabit boyutlu değişkenler, değişken boyutlu değişkenlere göre daha az Gas tüketir. Bayt uzunluğu sınırlanabiliyorsa, mümkünse bytes1'den bytes32'ye kadar en küçük uzunluğu seçin.

5. Haritalar ve Diziler

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

Çoğu durumda, haritalama daha verimli ve daha düşük maliyetlidir, ancak diziler yinelemeye uygun olup veri türü paketlemeyi destekler. Bu nedenle, veri listelerini yönetirken haritalamanın öncelikli olarak kullanılması önerilir, aksi takdirde 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 hafızada saklanabilir. İkisi arasındaki temel fark, hafızanın fonksiyon tarafından değiştirilebilmesi, oysa calldata'nın değiştirilemez olmasıdır.

Bu prensibi unutmayın: Eğer fonksiyon parametreleri salt okunur ise, öncelikle calldata kullanılmalı, memory yerine. Bu, fonksiyonun calldata'sından memory'e gereksiz kopyalama işlemlerini önleyebilir.

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

Constant/Immutable değişkenler sözleşmenin depolaması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ün olduğunca Constant veya Immutable anahtar kelimelerini kullanmanız önerilir.

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çınabilirler, bu da Gas maliyetlerini tasarruf sağlar.

Ayrıca, 0.8.0 ve üzeri sürümlerdeki derleyiciler artık SafeMath kütüphanesini kullanmayı gerektirmiyor, çünkü derleyici kendisi taşma ve alt alma koruma özelliklerini yerleşik olarak sağlamaktadır.

9. Optimizasyon Değiştirici

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

Mantığı _checkOwner() adlı iç fonksiyona yeniden yapılandırarak, bu iç fonksiyonun modülatör içinde tekrar kullanılmasına izin vermek, bytecode boyutunu azaltabilir ve Gas maliyetini düşürebilir.

10. Kısa yol optimizasyonu

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

Gas tüketimini optimize etmek için, hesaplama maliyeti düşük olan koşulların öncelikli hale getirilmesi gerekir; böylece maliyeti yüksek hesaplamaları atlama olasılığı artar.

Ek Genel Tavsiyeler

1. Gereksiz kodları silin

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ş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ı serbest bırakarak Gas ödülleri kazanabilirler. Bir değişkene artık ihtiyaç duyulmuyorsa, 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 mümkün olduğunca birleştirin ve tekrar eden hesaplamaları döngü gövdesinin dışına çıkarın.

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

Önceden derlenmiş sözleşmeler, şifreleme ve hash işlemleri gibi karmaşık kütüphane fonksiyonları sunar. Kod EVM'de 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 iş yükünü azaltarak Gas tasarrufu sağlar.

Önceden derlenmiş sözleşmelere örnekler 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. Yerleşik derleme kodu kullanma

İç içe montaj ( 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 opcode'larını kullanmadan. İç içe montaj ayrıca belleğin ve depolamanın kullanılmasını daha hassas bir şekilde kontrol etmeye olanak tanır, böylece Gas ücretlerini daha da azaltır. Ayrıca, iç içe montaj, sadece Solidity kullanarak gerçekleştirilmesi zor olan bazı karmaşık işlemleri gerçekleştirebilir, Gas tüketimini optimize etmek için daha fazla esneklik sağlar.

Ancak, iç içe derleme kullanımı riskler de getirebilir ve hata yapma olasılığını artırabilir. Bu nedenle dikkatli kullanılmalı ve yalnızca deneyimli geliştiriciler tarafından uygulanmalıdır.

![Ethereum akıllı sözleşmelerin Gas optimizasyonu için en iyi on uygulama](