Ethereum akıllı sözleşmeler Gas optimizasyonu en iyi uygulamaları
Ethereum ana ağındaki Gas ücretleri her zaman zorlu bir sorun olmuştur, özellikle ağın tıkanık olduğu zamanlarda daha belirgin hale gelir. Yoğun saatlerde kullanıcılar yüksek işlem ücretleri ödemek zorundadır. Bu nedenle, akıllı sözleşmeler geliştirme aşamasında Gas ücretlerini optimize etmek son derece önemlidir. Gas tüketimini optimize etmek, yalnızca işlem maliyetlerini etkin bir şekilde azaltmakla kalmaz, aynı zamanda işlem verimliliğini artırarak kullanıcılara daha ekonomik ve etkili 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şmeler geliştirirken Gas ücreti 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 ücretleri çalışma şeklini daha iyi anlamalarına yardımcı olmasını ve blockchain ekosistemindeki zorluklarla birlikte başa çıkmalarını sağlamasını istiyoruz.
EVM'nin Gas Ücreti Mekanizması Hakkında Kısa Bilgi
EVM uyumlu ağlarda, "Gas", belirli işlemleri gerçekleştirmek için gereken hesaplama gücünün ölçü birimidir.
EVM'nin yapı düzeninde, Gas tüketimi üç kısma ayrılır: işlem yürütme, dış mesaj çağrıları 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 * (taban ücreti + öncelik ücreti)
Temel ücret yok edilecektir, öncelikli ücret ise teşvik olarak kullanılacak, 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 ö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 koduna" yani opcodes'e dönüştürülür.
Her bir işlem kodu (, örneğin sözleşme oluşturma, mesaj çağrısı yapma, hesap depolamasına erişim sağlama 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 revizyonundan sonra, bazı işlem kodlarının Gas maliyetleri ayarlandı ve bu, sarı kitabın içeriğinden farklı olabilir.
Gaz 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 daha düşüktür:
Bellek değişkenlerini okuma ve yazma
Sabitleri ve değiştirilemez değişkenleri oku
Yerel değişkenleri okuma ve yazma
calldata değişkenini okuyun, örneğin calldata dizisi ve yapı
İç fonksiyon çağrısı
Maliyeti yüksek olan işlemler şunlardır:
Sözleşme depolamasında saklanan durum değişkenlerini okuma ve yazma
Harici fonksiyon çağrısı
Döngü işlemi
EVM Gaz Ücretleri Optimizasyonu İçin 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 ücret 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( belle)'den çok daha yüksektir. Her seferinde bir 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şleminin maliyeti bellek işlemlerinin maliyetinin 100 katından fazladır. Ö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 maliyet gerektirir.
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 atayın.
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 ü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 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 sığacak şekilde ayarlanmasını ifade eder.
Bu ayrıntı ayarıyla, geliştiriciler 20.000 Gas birimi tasarruf edebilir. (, kullanılmamış bir depolama alanı saklamak 20.000 Gas) gerektirirken, artık yalnızca iki depolama alanı gerekmektedir.
Her bir depolama alanı Gas tükettiği için, değişkenlerin paketlenmesi, 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 bit olarak 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 ekstra Gaz tüketir.
Tek başına bakıldığında, 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 slotuna paketleyebilirse, bunları yinelemenin toplam maliyeti dört uint256 değişkeninden daha düşük olacaktır. Bu şekilde, akıllı sözleşmeler bir depolama slotunu bir kez okuyup yazabilir ve tek bir işlemde dört uint8 değişkenini bellek/depolama alanına yerleştirebilir.
4. Sabit boyutlu değişkenleri dinamik değişkenler yerine kullanma
Eğer veriler 32 bayt içinde kontrol edilebiliyorsa, bytes veya strings yerine bytes32 veri tipinin kullanılması ö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'den bytes32'ye kadar en küçük uzunluğu seçin.
5. Haritalar ve Diziler
Solidity verilerinin listesi iki veri türü ile temsil edilebilir: dizi (Arrays ) ve harita (Mappings ), ancak sözdizimleri ve yapıları tamamen farklıdır.
Çoğu durumda, haritalama daha verimli ve maliyet açısından daha düşüktür, ancak diziler yine de yinelemelidir ve veri türlerini paketlemeyi destekler. Bu nedenle, veri listelerini yönetirken haritalamanın öncelikli olarak kullanılmasını öneriyoruz, yalnızca yineleme gerektiğinde veya veri türlerini paketleyerek Gas tüketimini optimize edebiliyorsanız.
6. calldata yerine memory kullanma
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 prensibi aklınızda bulundurun: Eğer fonksiyon parametreleri salt okunursa, öncelikle calldata kullanmalısınız, 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 byte kodunda saklanır. Bu nedenle, depolama ile kıyaslandığında erişim maliyetleri çok daha düşüktür; bu nedenle, mümkün olduğunca Constant veya Immutable anahtar kelimelerinin kullanılması önerilir.
Geliştiriciler aritmetik işlemlerin taşma veya alt sınır aşımına neden olmayacağını belirleyebildiklerinde, Solidity v0.8.0 ile tanıtılan unchecked anahtar kelimesini kullanarak gereksiz taşma veya alt sınır aşım kontrolünden kaçınabilir ve böylece Gaz maliyetlerini azaltabilirler.
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 entegre etmiştir.
9. Optimizasyon Değiştirici
Değiştirici kodu, değiştirilmiş işlevlere gömülü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()'e yeniden yapılandırarak, bu iç fonksiyonun değiştiriciler içinde 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 ilk koşul mantıksal ifadenin sonucunu belirlemek için yeterliyse, ikinci koşul değerlendirilmeyecektir.
Gas tüketimini optimize etmek için, düşük maliyetli 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 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çlerini kaldırmalısınız. Esasen, kullanılmayan herhangi bir hesaplama silinmelidir.
Ethereum'da, geliştiriciler depolama alanını serbest bırakarak Gas ödülü alabilirler. Artık bir değişkene ihtiyaç duyulmadığında, delete anahtar kelimesini kullanarak onu silmeli 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 tekrarlanan hesaplamaları döngü gövdesinin dışına çıkarın.
2. Önyükleme sözleşmesi 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şmelerin kullanılması, 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şmelerin örnekleri arasında eliptik eğri dijital imza algoritması (ECDSA) ve SHA2-256 hash algoritması bulunmaktadır. Bu önceden derlenmiş sözleşmeleri akıllı sözleşmelerde kullanarak, geliştiriciler Gas maliyetlerini düşürebilir ve uygulamaların çalışma verimliliğini artırabilir.
3. İç içe montaj 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ını sağlar, 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 ve böylece Gas ücretlerini daha da azaltır. Ayrıca, iç içe montaj, 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 sunar.
Ancak, iç içe montaj kullanmak da riskler getirebilir ve hatalara açık olabilir. Bu nedenle, dikkatli kullanılmalı ve yalnızca deneyimli geliştiriciler tarafından kullanılmalıdır.
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.
14 Likes
Reward
14
7
Repost
Share
Comment
0/400
SandwichTrader
· 23h ago
gas yine gökyüzüne yükseldi, yardım et
View OriginalReply0
MEVictim
· 08-10 14:16
Yine bu gereksiz teorileri suluyorsunuz, doğrudan bana Arbitraj'ı nasıl yapacağımı öğretin.
View OriginalReply0
UnluckyValidator
· 08-10 11:27
Bu gas ücreti gerçekten insanı zorluyor, blok oluşturduktan sonra yine bir şey kazanamadım.
View OriginalReply0
GasFeeCryer
· 08-10 11:15
gas ücreti neden yine yükseldi, ağlamaklı.
View OriginalReply0
AlwaysAnon
· 08-10 11:14
Aman ver! Bu gas ne zaman düşecek?
View OriginalReply0
0xSoulless
· 08-10 11:13
Onlar gas ile insanları enayi yerine koymak ve hâlâ bu boş şeyleri yapıyorlar.
View OriginalReply0
SleepyValidator
· 08-10 11:09
Gaz ücretleri o kadar yüksek ki yemek yiyemiyorum.
Ethereum akıllı sözleşmeler Gas optimizasyonu detayları: 10 pratik ipucu
Ethereum akıllı sözleşmeler Gas optimizasyonu en iyi uygulamaları
Ethereum ana ağındaki Gas ücretleri her zaman zorlu bir sorun olmuştur, özellikle ağın tıkanık olduğu zamanlarda daha belirgin hale gelir. Yoğun saatlerde kullanıcılar yüksek işlem ücretleri ödemek zorundadır. Bu nedenle, akıllı sözleşmeler geliştirme aşamasında Gas ücretlerini optimize etmek son derece önemlidir. Gas tüketimini optimize etmek, yalnızca işlem maliyetlerini etkin bir şekilde azaltmakla kalmaz, aynı zamanda işlem verimliliğini artırarak kullanıcılara daha ekonomik ve etkili 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şmeler geliştirirken Gas ücreti 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 ücretleri çalışma şeklini daha iyi anlamalarına yardımcı olmasını ve blockchain ekosistemindeki zorluklarla birlikte başa çıkmalarını sağlamasını istiyoruz.
EVM'nin Gas Ücreti Mekanizması Hakkında Kısa Bilgi
EVM uyumlu ağlarda, "Gas", belirli işlemleri gerçekleştirmek için gereken hesaplama gücünün ölçü birimidir.
EVM'nin yapı düzeninde, Gas tüketimi üç kısma ayrılır: işlem yürütme, dış mesaj çağrıları 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 * (taban ücreti + öncelik ücreti)
Temel ücret yok edilecektir, öncelikli ücret ise teşvik olarak kullanılacak, 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 ö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 koduna" yani opcodes'e dönüştürülür.
Her bir işlem kodu (, örneğin sözleşme oluşturma, mesaj çağrısı yapma, hesap depolamasına erişim sağlama 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 revizyonundan sonra, bazı işlem kodlarının Gas maliyetleri ayarlandı ve bu, sarı kitabın içeriğinden farklı olabilir.
Gaz 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 daha düşüktür:
Maliyeti yüksek olan işlemler şunlardır:
EVM Gaz Ücretleri Optimizasyonu İçin 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 ücret 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( belle)'den çok daha yüksektir. Her seferinde bir 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şleminin maliyeti bellek işlemlerinin maliyetinin 100 katından fazladır. Ö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 maliyet gerektirir.
Saklama kullanımını sınırlamanın yöntemleri şunlardır:
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 ü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 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 sığacak şekilde ayarlanmasını ifade eder.
Bu ayrıntı ayarıyla, geliştiriciler 20.000 Gas birimi tasarruf edebilir. (, kullanılmamış bir depolama alanı saklamak 20.000 Gas) gerektirirken, artık yalnızca iki depolama alanı gerekmektedir.
Her bir depolama alanı Gas tükettiği için, değişkenlerin paketlenmesi, 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 bit olarak 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 ekstra Gaz tüketir.
Tek başına bakıldığında, 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 slotuna paketleyebilirse, bunları yinelemenin toplam maliyeti dört uint256 değişkeninden daha düşük olacaktır. Bu şekilde, akıllı sözleşmeler bir depolama slotunu bir kez okuyup yazabilir ve tek bir işlemde dört uint8 değişkenini bellek/depolama alanına yerleştirebilir.
4. Sabit boyutlu değişkenleri dinamik değişkenler yerine kullanma
Eğer veriler 32 bayt içinde kontrol edilebiliyorsa, bytes veya strings yerine bytes32 veri tipinin kullanılması ö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'den bytes32'ye kadar en küçük uzunluğu seçin.
5. Haritalar ve Diziler
Solidity verilerinin listesi iki veri türü ile temsil edilebilir: dizi (Arrays ) ve harita (Mappings ), ancak sözdizimleri ve yapıları tamamen farklıdır.
Çoğu durumda, haritalama daha verimli ve maliyet açısından daha düşüktür, ancak diziler yine de yinelemelidir ve veri türlerini paketlemeyi destekler. Bu nedenle, veri listelerini yönetirken haritalamanın öncelikli olarak kullanılmasını öneriyoruz, yalnızca yineleme gerektiğinde veya veri türlerini paketleyerek Gas tüketimini optimize edebiliyorsanız.
6. calldata yerine memory kullanma
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 prensibi aklınızda bulundurun: Eğer fonksiyon parametreleri salt okunursa, öncelikle calldata kullanmalısınız, 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 byte kodunda saklanır. Bu nedenle, depolama ile kıyaslandığında erişim maliyetleri çok daha düşüktür; bu nedenle, mümkün olduğunca Constant veya Immutable anahtar kelimelerinin kullanılması önerilir.
8. Taşma/alt taşma olmayacağından emin olduğunuzda Unchecked kullanın
Geliştiriciler aritmetik işlemlerin taşma veya alt sınır aşımına neden olmayacağını belirleyebildiklerinde, Solidity v0.8.0 ile tanıtılan unchecked anahtar kelimesini kullanarak gereksiz taşma veya alt sınır aşım kontrolünden kaçınabilir ve böylece Gaz maliyetlerini azaltabilirler.
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 entegre etmiştir.
9. Optimizasyon Değiştirici
Değiştirici kodu, değiştirilmiş işlevlere gömülü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()'e yeniden yapılandırarak, bu iç fonksiyonun değiştiriciler içinde 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 ilk koşul mantıksal ifadenin sonucunu belirlemek için yeterliyse, ikinci koşul değerlendirilmeyecektir.
Gas tüketimini optimize etmek için, düşük maliyetli 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 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çlerini kaldırmalısınız. Esasen, kullanılmayan herhangi bir hesaplama silinmelidir.
Ethereum'da, geliştiriciler depolama alanını serbest bırakarak Gas ödülü alabilirler. Artık bir değişkene ihtiyaç duyulmadığında, delete anahtar kelimesini kullanarak onu silmeli 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 tekrarlanan hesaplamaları döngü gövdesinin dışına çıkarın.
2. Önyükleme sözleşmesi 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şmelerin kullanılması, 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şmelerin örnekleri arasında eliptik eğri dijital imza algoritması (ECDSA) ve SHA2-256 hash algoritması bulunmaktadır. Bu önceden derlenmiş sözleşmeleri akıllı sözleşmelerde kullanarak, geliştiriciler Gas maliyetlerini düşürebilir ve uygulamaların çalışma verimliliğini artırabilir.
3. İç içe montaj 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ını sağlar, 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 ve böylece Gas ücretlerini daha da azaltır. Ayrıca, iç içe montaj, 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 sunar.
Ancak, iç içe montaj kullanmak da riskler getirebilir ve hatalara açık olabilir. Bu nedenle, dikkatli kullanılmalı ve yalnızca deneyimli geliştiriciler tarafından kullanılmalıdır.
4.