Ethereum akıllı sözleşmeler Gas ücreti optimizasyon rehberi

Ethereum ana ağındaki Gas ücretleri her zaman zor bir sorun olmuştur, özellikle de ağın tıkalı olduğu zamanlarda daha belirgindir. Yoğun saatlerde, kullanıcılar genellikle çok yüksek işlem ücretleri ödemek zorunda kalmaktadır. Bu nedenle, akıllı sözleşme geliştirme aşamasında Gas ücretlerini optimize etmek özellikle ö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 optimizasyonuna dair ilgili temel kavramları ve akıllı sözleşme geliştirirken Gas ücreti optimizasyonu için en iyi uygulamaları özetleyecektir. Bu içeriklerin, geliştiricilere ilham ve pratik yardım sağlaması, aynı zamanda sıradan kullanıcıların EVM'in Gas ücretleri çalışma şeklinin daha iyi anlaşılmasına yardımcı olması ve blockchain ekosistemindeki zorluklarla birlikte başa çıkmalarına katkıda bulunması umulmaktadır.

EVM'nin Gas Ücreti Mekanizmasının Tanıtımı

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

EVM'nin yapılandırmasında, Gas tüketimi üç bölüme ayrılır: işlem yürütme, dış mesaj çağrısı ve bellek ile depolamanın okunması ve yazılması.

Her işlem için gereken hesaplama kaynakları nedeniyle, sonsuz döngüler ve hizmet reddi ( DoS ) saldırılarını önlemek amacıyla 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 ) yürürlüğe girdiğinden beri, Gas ücreti aşağıdaki formülle hesaplanmaktadır:

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

Temel ücret yok edilecektir, öncelikli ücret ise teşvik olarak kullanılacak ve doğrulayıcıları işlemleri blok zincirine eklemeye teşvik edecektir. İşlemi gönderirken daha yüksek bir öncelikli ücret belirlemek, 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 anlamak

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

Herhangi bir işlem kodu ( ö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 edilen bir Gas tüketim maliyeti vardır, bu maliyetler Ethereum sarı kitabında kayıtlıdır.

Birçok EIP'nin revize edilmesiyle, bazı opcode'ların Gas maliyetleri ayarlandı ve bu, sarı kitapta belirtilenden farklı olabilir.

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 yazma ve okuma
• Sabitleri ve değişmez değişkenleri oku
• Yerel değişkenleri okumak ve yazmak
• calldata değişkenlerini okuyun, örneğin calldata dizileri ve yapıları
• İç fonksiyon çağrısı

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

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

EVM Gas Ü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 uygulamaları takip ederek, 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ı en aza indirin.

Solidity'de, Storage( depolama) sınırlı bir kaynaktır ve Gaz tüketimi Memory( bellek)'den çok daha yüksektir. Bir akıllı sözleşme her 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, depolama işlemleri olan sload ve sstore en ideal durumda bile, maliyet en az 100 birim gerektirir.

Saklama kullanımını sınırlamak için yöntemler şunlardır:

• Geçici verileri bellekte depolamak
• 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 slotu) 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 yuvasını değişkenlerin depolanmasında temel birim olarak kullanır. Değişken paketleme, değişkenlerin akıllıca düzenlenmesiyle, birden fazla değişkenin tek bir depolama yuvasına sığabilmesi anlamına gelir.

Bu ayrıntı ayarlaması sayesinde, geliştiriciler 20,000 Gas birimi tasarruf edebilir. ( kullanılmamış bir depolama alanı depolamak için 20,000 Gas ) tüketilmesi gerekirken, artık yalnızca iki depolama alanı gerekmektedir.

Her depolama yuvasının Gas tüketmesi nedeniyle, değişken paketleme, 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 türü ile temsil edilebilir, ancak farklı veri türlerinin karşılık geldiği 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, tam sayılar farklı boyutlara ayrılabilir: uint8, uint16, uint32 vb. EVM'nin 256 bitlik birimlerle işlem yapması nedeniyle, 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ü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ştiriciler dört uint8 değişkenini bir depolama alanına paketleyebiliyorsa, o zaman bunları yinelemenin 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 seferde okuyup yazabilir ve dört uint8 değişkenini bir işlemde bellek/depolama alanına yerleştirebilir.

4. Sabit boyutlu değişkenler kullanarak dinamik değişkenlerin yerini alı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şkenlere göre daha az Gas tüketir. 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 veriler listesi, iki veri türüyle temsil edilebilir: diziler (Arrays) ve haritalar (Mappings), ancak bunların sözdizimi ve yapısı tamamen farklıdır.

Çoğu durumda haritalama daha verimli ve maliyet açısından daha düşüktür, ancak diziler yine de yinelemeye ve veri türü paketlemeye destek verir. Bu nedenle, veri listelerini yönetirken haritalamayı öncelikli olarak kullanmanız önerilir, yalnızca yinelemeye ihtiyaç duyuluyorsa 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 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 prensibi unutmayın: Eğer fonksiyon parametreleri sadece okunabilir ise, öncelikle calldata kullanmalısınız, memory yerine. Bu, fonksiyonun calldata'sından memory'ye gereksiz kopyalama işlemlerini önlemeye yardımcı olur.

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 byte kodunda saklanır. Bu nedenle, depolama ile karşılaştırıldığında, erişim maliyetleri çok daha düşüktür; bu yüzden mümkünse Constant veya Immutable anahtar kelimelerini kullanmanız önerilir.

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

Geliştiriciler aritmetik işlemlerin taşma veya alt sınır aşımı yaratmayacağından emin olduklarında, Solidity v0.8.0 ile tanıtılan unchecked anahtar kelimesini kullanarak gereksiz taşma veya alt sınır aşımı kontrollerinden kaçınabilir ve böylece Gas maliyetlerinden tasarruf edebilirler.

Ayrıca, 0.8.0 ve üzeri sürümler için 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 içermektedir.

9. Optimizasyon Değiştiricisi

Değiştirici kodu, değiştirilmiş işlevin içine gömülmüştür; her değiştirici kullanıldığında, bu kod kopyalanır. Bu, bytecode'un boyutunu artırır ve Gas tüketimini yükseltir.

Mantığı _checkOwner() adlı iç fonksiyona yeniden yapılandırarak, bu iç fonksiyonun modifikatörde tekrar kullanılmasına izin verilir, bu da bytecode boyutunu azaltır ve Gas maliyetini düşürür.

10. Kısa devre 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 belirleyebiliyorsa, ikinci koşul değerlendirilmez.

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

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şmede bazı hesaplamaların sonuçları doğrudan kullanılıyorsa, bu gereksiz hesaplama süreçlerini ortadan kaldırmalısınız. Temelde, kullanılmayan herhangi bir hesaplama silinmelidir.

• Ethereum'da geliştiriciler depolama alanı serbest bırakarak Gas ödülleri kazanabilirler. Eğer bir değişken artık gerekliyse, 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ş sözleşmeleri kullanma

Önceden derlenmiş sözleşmeler, şifreleme ve hash işlemleri gibi karmaşık kütüphane fonksiyonları sunar. Kod EVM üzerinde değil, istemci düğümünde yerel olarak ç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ğlamaya yardımcı olabilir.

Önceden derlenmiş sözleşme örnekleri arasında Eliptik Eğri Dijital İmza 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 azaltabilir 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 kod yazmalarına olanak tanır, pahalı Solidity opcode'ları kullanmadan. İç içe montaj 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 montaj bazı karmaşık işlemleri yalnızca Solidity kullanarak gerçekleştirilmesinin zor olduğu durumlarda yapılabilir, bu da Gas tüketimini optimize etmek için daha fazla esneklik sağlar.

Ancak, yerleşik derleme kullanmak da riskler getirebilir ve kolayca dışa aktarılabilir.