Ethereum akıllı sözleşmeler Gas optimizasyonu uygulama kılavuzu
Ethereum ana ağındaki Gas ücretleri her zaman zorlu bir sorun olmuştur, özellikle ağın yoğun olduğu zamanlarda daha belirgin hale gelir. Yoğun saatlerde, kullanıcılar genellikle yüksek işlem ücretleri ödemek zorunda kalırlar. 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 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 ü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. Bu içeriklerin geliştiricilere ilham ve pratik yardım sunmasını umuyoruz, aynı zamanda sıradan kullanıcıların EVM'in Gas ücretleri çalışma şekmini daha iyi anlamalarına yardımcı olarak blockchain ekosistemindeki zorluklarla birlikte başa çıkmalarını sağlamayı hedefliyoruz.
EVM'nin Gas Ücreti Mekanizması Tanıtımı
EVM uyumlu ağlarda, "Gas", belirli bir işlemi gerçekleştirmek için gereken hesaplama gücünü ölçmek için kullanılan 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 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ş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 * ( 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. İşlem gönderirken daha yüksek bir öncelik ücreti belirlemek, 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 "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 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 depolama erişimi ve sanal makinede işlem yürütme ) 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ı işlem kodlarının Gas maliyetleri ayarlandı ve bu, sarı kitabın içeriği ile 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 işlemlerden kaçınmaktır.
EVM'de, aşağıdaki işlemlerin maliyeti düşüktür:
Bellek değişkenlerini okumak ve yazmak
Sabitler ve değişmez değişkenler oku
Yerel değişkenleri okumak ve yazmak
Çağrı verisi dizileri ve yapıları gibi çağrı verisi değişkenlerini okuyun
İç fonksiyon çağrısı
Maliyeti yüksek olan işlemler şunlardır:
Akıllı sözleşmelerde depolanan durum değişkenlerini okumak ve yazmak
Dış 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 hazırladık. 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 gaz tüketimi, Memory( hafıza)'den çok daha yüksektir. Her seferinde bir 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 maliyetinden 100 kat daha fazladır. Örneğin, OPcodesmload ve mstore komutları yalnızca 3 Gas birimi tüketirken, depolama işlemleri olan sload ve sstore, en ideal koşullarda bile en az 100 birim maliyet gerektirmektedir.
Depolama değişiklik sayısını azaltmak: Ara sonuçları bellekte saklayarak, tüm hesaplamalar tamamlandıktan sonra sonuçları depolama değişkenlerine atamak.
2. Değişken paketleme
Akıllı sözleşmelerde kullanılan Storage slot( depolama slotu)'un sayısı ve geliştiricilerin 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ının temel birimi olarak kullanır. Değişken paketi, değişkenlerin uygun bir şekilde düzenlenmesiyle, birden fazla değişkenin tek bir depolama yuvasına sığmasını sağlamaktadır.
Bu detay ayarı ile geliştiriciler 20,000 Gas birimi tasarruf edebilir. ( kullanılmamış bir depolama yuvası saklamak 20,000 Gas ) gerektiriyor, ancak artık yalnızca iki depolama yuvası gerekiyor.
Her depolama slotu Gas tükettiğinden, değişken paketleme, gereken depolama slotu 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 tipinin seçilmesi, 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şlem yaptığı 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ü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 optimizasyonunu kullanırsak durum farklıdır. Geliştiriciler dört uint8 değişkenini bir depolama alanına paketleyebilirse, 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 kez 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 alma
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şkenlerden daha az Gas tüketir. 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 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 yine de yinelemeli olup veri türü paketlemeyi destekler. Bu nedenle, veri listelerini yönetirken haritalamayı öncelikli olarak kullanmanız önerilir, yalnızca yineleme gerektiğinde veya veri türü paketleme ile Gas tüketimini optimize edebiliyorsanız bunun dışındaki durumlarda.
6. calldata yerine memory kullanın
Fonksiyon parametrelerinde tanımlanan değişkenler calldata veya memory içinde saklanabilir. İkisi arasındaki ana fark, memory'nin fonksiyon tarafından değiştirilebilmesi, oysa calldata'nın değiştirilemez olmasıdır.
Bu prensibi unutmayın: Eğer fonksiyon parametreleri yalnızca okunabilir ise, öncelikle calldata kullanılmalıdır, memory yerine. Bu, fonksiyonun calldata'sından memory'ye gereksiz kopyalama işlemlerini önleyebilir.
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, 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.
Geliştiriciler, aritmetik işlemlerin taşma veya altına inme ile sonuçlanmayacağını belirlediğinde, gereksiz taşma veya altına inme kontrollerinden kaçınmak için Solidity v0.8.0 ile tanıtılan unchecked anahtar kelimesini kullanabilir ve böylece Gas maliyetlerinden tasarruf edebilir.
Ayrıca, 0.8.0 ve üzeri sürümlerdeki derleyicilerin artık SafeMath kütüphanesini kullanmasına gerek yoktur, çünkü derleyici kendisi taşma ve alt taşma koruma özelliklerini içermektedir.
9. Optimize Editleyici
Değiştirici kodu, değiştirilmiş fonksiyonun içine gömülmüştür, her değiştirici kullanıldığında kodu kopyalanır. Bu, bytecode'un boyutunu artırır ve Gas tüketimini yükseltir.
İç fonksiyonu _checkOwner() olarak 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 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, hesaplama maliyeti düşük koşulları öncelikli hale getirmek gerekir, böylece yüksek maliyetli hesaplamaların atlanması mümkün olabilir.
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 belirli hesaplamaların sonuçları doğrudan kullanılıyorsa, bu gereksiz hesaplama süreçlerini ortadan kaldırmak gerekir. Temelde, kullanılmayan her hesaplama silinmelidir.
Ethereum'da geliştiriciler, depolama alanını serbest bıraktıklarında Gas ödülleri 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. Önyargılı sözleşmeleri kullanma
Önceden derlenmiş sözleşmeler, şifreleme ve hash işlemleri gibi karmaşık kütüphane fonksiyonları sağlar. 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 yapmayı 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. İç içe yerleşik kod kullanma
İçerideki derleme ( in-line assembly ), geliştiricilerin EVM tarafından doğrudan yürütülebilen düşük düzeyde ancak verimli kod yazmalarına izin verir, pahalı Solidity işlem kodları kullanmadan. İçerideki derleme, bellek ve depolamanın kullanımını daha hassas bir şekilde kontrol etmeye de olanak tanır, böylece Gas ücretlerini daha da azaltır. Ayrıca, içerideki derleme, yalnızca Solidity kullanarak gerçekleştirilmesi zor olan bazı 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 taşıyabilir ve hata yapma olasılığını artırabilir. Bu nedenle, dikkatli kullanılmalı ve yalnızca deneyimli geliştiricilerin işlemesi gereken bir durumdur.
4. Layer 2 çözümleri kullanma
Layer 2 çözümlerinin kullanılması, Ethereum ana ağında gerekeni azaltabilir.
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
Ethereum akıllı sözleşmeler Gas optimizasyonu uygulama kılavuzu
Ethereum akıllı sözleşmeler Gas optimizasyonu uygulama kılavuzu
Ethereum ana ağındaki Gas ücretleri her zaman zorlu bir sorun olmuştur, özellikle ağın yoğun olduğu zamanlarda daha belirgin hale gelir. Yoğun saatlerde, kullanıcılar genellikle yüksek işlem ücretleri ödemek zorunda kalırlar. 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 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 ü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. Bu içeriklerin geliştiricilere ilham ve pratik yardım sunmasını umuyoruz, aynı zamanda sıradan kullanıcıların EVM'in Gas ücretleri çalışma şekmini daha iyi anlamalarına yardımcı olarak blockchain ekosistemindeki zorluklarla birlikte başa çıkmalarını sağlamayı hedefliyoruz.
EVM'nin Gas Ücreti Mekanizması Tanıtımı
EVM uyumlu ağlarda, "Gas", belirli bir işlemi gerçekleştirmek için gereken hesaplama gücünü ölçmek için kullanılan 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 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ş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 * ( 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. İşlem gönderirken daha yüksek bir öncelik ücreti belirlemek, 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 "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 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 depolama erişimi ve sanal makinede işlem yürütme ) 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ı işlem kodlarının Gas maliyetleri ayarlandı ve bu, sarı kitabın içeriği ile 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 işlemlerden kaçınmaktır.
EVM'de, aşağıdaki işlemlerin maliyeti düşüktür:
Maliyeti yüksek olan işlemler şunlardır:
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 hazırladık. 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 gaz tüketimi, Memory( hafıza)'den çok daha yüksektir. Her seferinde bir 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 maliyetinden 100 kat daha fazladır. Örneğin, OPcodesmload ve mstore komutları yalnızca 3 Gas birimi tüketirken, depolama işlemleri olan sload ve sstore, en ideal koşullarda bile en az 100 birim maliyet gerektirmektedir.
Depolama kullanımını kısıtlama yöntemleri şunlardır:
2. Değişken paketleme
Akıllı sözleşmelerde kullanılan Storage slot( depolama slotu)'un sayısı ve geliştiricilerin 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ının temel birimi olarak kullanır. Değişken paketi, değişkenlerin uygun bir şekilde düzenlenmesiyle, birden fazla değişkenin tek bir depolama yuvasına sığmasını sağlamaktadır.
Bu detay ayarı ile geliştiriciler 20,000 Gas birimi tasarruf edebilir. ( kullanılmamış bir depolama yuvası saklamak 20,000 Gas ) gerektiriyor, ancak artık yalnızca iki depolama yuvası gerekiyor.
Her depolama slotu Gas tükettiğinden, değişken paketleme, gereken depolama slotu 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 tipinin seçilmesi, 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şlem yaptığı 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ü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 optimizasyonunu kullanırsak durum farklıdır. Geliştiriciler dört uint8 değişkenini bir depolama alanına paketleyebilirse, 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 kez 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 alma
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şkenlerden daha az Gas tüketir. 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 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 yine de yinelemeli olup veri türü paketlemeyi destekler. Bu nedenle, veri listelerini yönetirken haritalamayı öncelikli olarak kullanmanız önerilir, yalnızca yineleme gerektiğinde veya veri türü paketleme ile Gas tüketimini optimize edebiliyorsanız bunun dışındaki durumlarda.
6. calldata yerine memory kullanın
Fonksiyon parametrelerinde tanımlanan değişkenler calldata veya memory içinde saklanabilir. İkisi arasındaki ana fark, memory'nin fonksiyon tarafından değiştirilebilmesi, oysa calldata'nın değiştirilemez olmasıdır.
Bu prensibi unutmayın: Eğer fonksiyon parametreleri yalnızca okunabilir ise, öncelikle calldata kullanılmalıdır, memory yerine. Bu, fonksiyonun calldata'sından memory'ye gereksiz kopyalama işlemlerini önleyebilir.
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 bayt 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 olunarak Unchecked kullanın
Geliştiriciler, aritmetik işlemlerin taşma veya altına inme ile sonuçlanmayacağını belirlediğinde, gereksiz taşma veya altına inme kontrollerinden kaçınmak için Solidity v0.8.0 ile tanıtılan unchecked anahtar kelimesini kullanabilir ve böylece Gas maliyetlerinden tasarruf edebilir.
Ayrıca, 0.8.0 ve üzeri sürümlerdeki derleyicilerin artık SafeMath kütüphanesini kullanmasına gerek yoktur, çünkü derleyici kendisi taşma ve alt taşma koruma özelliklerini içermektedir.
9. Optimize Editleyici
Değiştirici kodu, değiştirilmiş fonksiyonun içine gömülmüştür, her değiştirici kullanıldığında kodu kopyalanır. Bu, bytecode'un boyutunu artırır ve Gas tüketimini yükseltir.
İç fonksiyonu _checkOwner() olarak 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 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, hesaplama maliyeti düşük koşulları öncelikli hale getirmek gerekir, böylece yüksek maliyetli hesaplamaların atlanması mümkün olabilir.
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 belirli hesaplamaların sonuçları doğrudan kullanılıyorsa, bu gereksiz hesaplama süreçlerini ortadan kaldırmak gerekir. Temelde, kullanılmayan her hesaplama silinmelidir.
Ethereum'da geliştiriciler, depolama alanını serbest bıraktıklarında Gas ödülleri 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. Önyargılı sözleşmeleri kullanma
Önceden derlenmiş sözleşmeler, şifreleme ve hash işlemleri gibi karmaşık kütüphane fonksiyonları sağlar. 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 yapmayı 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. İç içe yerleşik kod kullanma
İçerideki derleme ( in-line assembly ), geliştiricilerin EVM tarafından doğrudan yürütülebilen düşük düzeyde ancak verimli kod yazmalarına izin verir, pahalı Solidity işlem kodları kullanmadan. İçerideki derleme, bellek ve depolamanın kullanımını daha hassas bir şekilde kontrol etmeye de olanak tanır, böylece Gas ücretlerini daha da azaltır. Ayrıca, içerideki derleme, yalnızca Solidity kullanarak gerçekleştirilmesi zor olan bazı 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 taşıyabilir ve hata yapma olasılığını artırabilir. Bu nedenle, dikkatli kullanılmalı ve yalnızca deneyimli geliştiricilerin işlemesi gereken bir durumdur.
4. Layer 2 çözümleri kullanma
Layer 2 çözümlerinin kullanılması, Ethereum ana ağında gerekeni azaltabilir.