Ethereum akıllı sözleşmelerinin Gas optimizasyonu için en iyi uygulamalar

Ethereum ana ağının Gas ücretleri her zaman zor bir sorun olmuştur, özellikle de ağın tıkanık olduğu zamanlarda daha belirgin hale gelir. Pik saatlerde kullanıcılar genellikle pahalı işlem ücretleri ödemek zorunda kalır. Bu nedenle, akıllı sözleşme geliştirme aşamasında Gas ücreti optimizasyonu son derece önemlidir. Gas tüketimini optimize etmek 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 blok zinciri deneyimi sunar.

Bu makale, Ethereum Sanal Makinesi (EVM)'in Gas ücret mekanizmasını, Gas ücret optimizasyonunun temel kavramlarını ve akıllı sözleşme geliştirirken Gas ücret 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 çalışma şekmini daha iyi anlamalarına yardımcı olmasını ve blockchain ekosistemindeki zorluklarla birlikte başa çıkmalarını diliyoruz.

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ü ölçen bir birimdir.

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 gerçekleştirilirken hesaplama kaynakları gerektiğinden, sonsuz döngüleri ve hizmet reddi ( DoS ) saldırılarını önlemek için belirli bir ücret alınır. Bir işlemi tamamlamak için gereken ücret "Gas ücreti" olarak adlandırılır.

EIP-1559( Londra hard fork'u )'den 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 yakılacak, öncelikli ücret ise teşvik olarak kullanılacak, böylece doğrulayıcıları işlemleri blok zincirine eklemeye teşvik edecek. İşlem gönderirken daha yüksek bir öncelikli ücret ayarlamak, işlemin bir sonraki bloğa dahil edilme olasılığını artırabilir. Bu, kullanıcıların doğrulayıcılara ödediği bir tür "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 koduna" yani opcodlara 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 gerçekleştirme ) için kabul görmüş bir Gas tüketim maliyeti vardır, bu maliyetler Ethereum sarı kitabında kaydedilmiştir.

Birçok EIP değişikliği sonrası, bazı opcode'ların Gas maliyetleri ayarlanmış olup, bu durum sarı kitapta yer alanlardan farklılık gösterebilir.

2.Gas optimizasyonunun temel kavramı

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

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

• Bellek değişkenlerini okumak ve yazmak
• Sabit ve değişmez değişkenleri oku
• Yerel değişkenleri oku ve yaz.
• calldata değişkenini okuyun, örneğin calldata dizisi ve yapısı
• İç fonksiyon çağrısı

Maliyeti yüksek olan 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 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 geliştirebilir.

1. Depolama kullanımını mümkün olan en az seviyeye indirin.

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

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

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

• Geçici verileri bellek içinde saklayı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şkenlerine atama.

2. Değişken paketleme

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

Solidity derleyicisi, derleme sürecinde ardışık depolama değişkenlerini paketler ve 32 baytlık depolama slotunu değişken depolamanın temel birimi olarak kullanır. Değişken paketleme, değişkenlerin mantıklı bir şekilde düzenlenmesiyle birden fazla değişkenin tek bir depolama slotuna sığmasını sağlamaktır.

Bu detay ayarı sayesinde, geliştiriciler 20.000 Gas birimi tasarruf edebilir. ( Kullanılmamış bir depolama slotu depolamak için 20.000 Gas) gerekir, ancak şimdi yalnızca iki depolama slotu gerekmektedir.

Her depolama yuvasının Gas tüketmesi nedeniyle, değişkenlerin paketlenmesi, gereken depolama yuvası sayısını azaltarak Gas kullanımını optimize eder.

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 256 bitlik birimlerle işlemler gerçekleştirdiği 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 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. Eğer geliştirici dört uint8 değişkenini bir depolama alanına paketleyebilirse, o zaman bunları yinelemenin toplam maliyeti 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 kerede okuyup yazabilir ve tek bir işlemle dört uint8 değişkenini belleğe/depolamaya 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 tipinin kullanılması önerilir. Genel olarak, sabit boyutta değişkenler, değişken boyuttaki değişkenlere göre daha az Gaz tüketir. Eğer bayt uzunluğu sınırlanabiliyorsa, mümkünse bytes1 ile bytes32 arasındaki en küçük uzunluğu seçin.

5. Haritalama ve Diziler

Solidity verileri 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 yüksek verimlilik ve daha düşük maliyet sunar, ancak diziler yine de yinelemeye sahip olup veri türü paketlemeyi destekler. Bu nedenle, veri listelerini yönetirken, yinelemeye ihtiyaç duyulmadıkça veya veri türü paketleme ile Gas tüketimi optimize edilebiliyorsa haritalamayı kullanmanız önerilir.

6. calldata yerine memory kullanın

Fonksiyon parametrelerinde tanımlanan değişkenler calldata veya memory içinde 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 ilkeleri unutmayın: Eğer fonksiyon parametreleri yalnızca okunuyorsa, öncelikle calldata kullanmalısınız, memory yerine. Bu, fonksiyonun calldata'sından memory'ye gereksiz kopyalamaları ö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 bytecode'unda saklanır. Bu nedenle, depolamaya kıyasla erişim maliyetleri çok daha düşüktür, mümkün olduğunca Constant veya Immutable anahtar kelimelerinin kullanılması ö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ğını belirleyebildiklerinde, Solidity v0.8.0 ile tanıtılan unchecked anahtar kelimesini kullanabilirler; böylece gereksiz taşma veya alt taşma kontrollerinden kaçınarak Gas maliyetinden tasarruf edebilirler.

Ayrıca, 0.8.0 ve üzeri sürümlerde, derleyicinin artık SafeMath kütüphanesini kullanmasına gerek yoktur, çü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ş işlevin içine yerleştirilir; her değiştirici kullanıldığında, kod kopyalanır. Bu, bayt kodunun boyutunu artırır ve Gas tüketimini yükseltir.

Mantığı _checkOwner() adlı iç fonksiyona yeniden yapılandırarak, bu iç fonksiyonun modifikatör içinde tekrar kullanılmasına izin verilir, böylece bytecode boyutu azaltılabilir ve Gas maliyetleri düşürülebilir.

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ğerlendirilmez.

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

Genel Tavsiyeler Ek

1. Gereksiz kodları sil

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 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çleri kaldırılmalıdır. Özünde, kullanılmayan herhangi bir hesaplama silinmelidir.

Ethereum'da, geliştiriciler depolama alanını serbest bıraktıklarında 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 tekrarlayan hesaplamaları döngü gövdesinin dışına çıkarın.

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

Önceden derlenmiş akıllı sözleşmeler, şifreleme ve hash işlemleri gibi karmaşık kütüphane işlevleri sunar. Kod EVM üzerinde çalışmadığı için, yerel istemci düğümünde çalışır, bu nedenle gereken Gas daha azdır. Önceden derlenmiş akıllı 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. 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 montaj kodu kullanma

İç içe derleme ( in-line assembly ), geliştiricilerin EVM tarafından doğrudan yürütülebilen düşük seviyeli ama etkili kodlar yazmasına olanak tanır; pahalı Solidity opcode'ları kullanmadan. İç içe derleme ayrıca bellek ve depolama kullanımını daha hassas bir şekilde kontrol etmeye olanak tanır, böylece Gas ücretlerini daha da azaltır. Ayrıca, iç içe derleme, sadece Solidity kullanarak gerçekleştirilmesi zor olan 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 getirebilir ve hata yapmayı kolaylaştırabilir. Bu nedenle, dikkatli kullanılmalı ve yalnızca deneyimli geliştiricilerin işlemesiyle sınırlı olmalıdır.

4. Layer 2 çözümleri kullanma

Layer 2 çözümleri kullanmak, Ethereum ana ağında depolanması ve hesaplanması gerekenleri azaltabilir.