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 de ağ tıkalı olduğunda daha da belirgin hale gelir. Zirve dönemlerinde, kullanıcılar genellikle yüksek işlem ücretleri ödemek zorunda kalır. Bu nedenle, akıllı sözleşmeler geliştirme aşamasında Gas ücreti optimizasyonu son derece önemlidir. Gas tüketimini optimize etmek, yalnızca işlem maliyetlerini etkili bir şekilde düşürmekle kalmaz, aynı zamanda işlem verimliliğini artırır ve kullanıcılara daha ekonomik ve verimli bir blockchain deneyimi sunar.
Bu makalede, Ethereum sanal makinesi ( EVM )'in Gas ücreti mekanizması, Gas ücreti optimizasyonuna dair ilgili temel kavramlar ve akıllı sözleşmeler geliştirilirken Gas ücreti optimizasyonu için en iyi uygulamalar ele alınacaktır. Bu içeriklerin geliştiricilere ilham ve pratik yardım sağlaması, aynı zamanda sıradan kullanıcıların EVM'in Gas ücretleri işleyişini daha iyi anlamalarına yardımcı olması ve blok zinciri ekosistemindeki zorluklarla birlikte başa çıkmalarına katkıda bulunması umulmaktadır.
EVM'nin Gas Ücreti Mekanizması Hakkında Genel 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 üç parçaya 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 kaynakları gerektiğinden, sonsuz döngüler ve hizmet reddi ( DoS ) saldırılarını önlemek için belirli bir ücret alınacaktır. Bir işlemi tamamlamak için gereken ücret "Gas ücreti" olarak adlandırılır.
EIP-1559( Londra hard fork'u )'den itibaren yürürlüğe girdiğinden 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, böylece doğrulayıcıların işlemleri blok zincirine eklemeleri teşvik edilecektir. İşlem 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 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 kodu"ya, yani opcodes'e 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 gerçekleştirme ) için kabul görmüş bir Gas tüketim maliyeti vardır, bu maliyetler Ethereum beyaz 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ı ile farklılık gösterebilir.
2.Gas optimizasyonunun temel kavramı
Gas optimizasyonunun temel ilkesi, EVM blockchain'inde 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 daha düşüktür:
Bellek değişkenlerini okumak ve yazmak
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ı
Maliyetli 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 hazırladık. 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)'dan çok daha yüksektir. Bir akıllı sözleşme depolamadan veri okuduğunda veya yazdığında, yüksek Gaz maliyetleri oluşur.
Ethereum sarı kitabının tanımına göre, depolama işlemlerinin maliyeti bellek işlemlerinden 100 kat daha fazladır. Örneğin, OPcodesmload ve mstore talimatları yalnızca 3 Gas birimi tüketirken, depolama işlemleri olan sload ve sstore en ideal koşullarda 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 atamak.
2. Değişken paketleme
akıllı sözleşmelerde kullanılan Storage slot( depolama slotunun) sayısı ve geliştiricilerin verileri gösterme ş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ını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 yuvasına sığabilmesini ifade eder.
Bu ayrıntı ayarı sayesinde, geliştiriciler 20.000 Gas birimini tasarruf edebilir. ( kullanılmamış bir depolama alanı depolamak için 20.000 Gas) tüketmekteydi, ancak şimdi sadece iki depolama alanına ihtiyaç var.
Her depolama slotu Gas harcadığı için, değişken paketleme gerekli depolama slotlarının 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 gelen 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 birimlerde 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 optimizasyonunu kullanırsak durum farklıdır. Geliştiriciler dört uint8 değişkenini bir depolama slotuna paketleyebilirse, onları 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şkenler kullanarak dinamik değişkenlerin yerine geçin.
Veri 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'den bytes32'ye en küçük uzunluğu seçin.
5. Haritalar ve diziler
Solidity verileri iki veri türü ile temsil edilebilir: dizi (Arrays ) ve harita (Mappings ), ancak sözdizimi ve yapıları tamamen farklıdır.
Haritalama, çoğu durumda daha yüksek verimlilik ve daha düşük maliyet sunar, ancak diziler yine de yinelemeye olanak tanır ve veri türlerini paketlemeyi destekler. Bu nedenle, veri listelerini yönetirken haritalamayı öncelikli olarak kullanmanız önerilir, yalnızca yinelemeye ihtiyaç duyuluyorsa veya veri türlerini paketleyerek Gas tüketimini optimize edebiliyorsanız istisna yapılmalıdır.
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 salt okunur ise, öncelikle calldata kullanmalısınız, memory yerine. Bu, fonksiyonun calldata'sından memory'ye gereksiz kopyalama işlemlerini önleyebilir.
7. Constant/Immutable anahtar kelimelerini mümkün olduğunca 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, depolamaya kıyasla erişim maliyetleri çok daha düşüktür, mümkün olduğunca Constant veya Immutable anahtar kelimelerini kullanmanız önerilir.
Geliştiriciler, aritmetik işlemlerin taşma veya alt taşma ile sonuçlanmayacağını belirlediğinde, Solidity v0.8.0 ile tanıtılan unchecked anahtar kelimesini kullanarak gereksiz taşma veya alt taşma kontrollerinden kaçınabilir ve böylece Gas maliyetlerini azaltabilir.
Ayrıca, 0.8.0 ve üzeri sürümlerde derleyici artık SafeMath kütüphanesini kullanmayı gerektirmiyor, çünkü derleyici kendisi taşma ve alt taşma koruma işlevlerini yerleşik olarak sunmaktadır.
9. Optimizasyon Değiştiricisi
Değiştirici kodu, değiştirilmiş fonksiyonun içine gömülmüştür; her değiştirici kullanıldığında kod kopyalanır. Bu, byte kodunun boyutunu artırır ve Gas tüketimini yükseltir.
Bu örnekte, mantığın _checkOwner() iç fonksiyonu olarak yeniden yapılandırılması, bu iç fonksiyonun değiştiricide tekrar kullanılmasına izin vererek byte kodu boyutunu azaltabilir ve Gas maliyetlerini düşürebilir.
10. Kısa Devre Optimizasyonu
|| ve && operatörleri için, mantıksal işlemler kısa devre değerlendirmesi gerçekleştirir, yani eğer ilk koşul mantıksal ifadenin sonucunu belirleyebiliyorsa, ikinci koşul değerlendirilmeyecektir.
Gas tüketimini optimize etmek için, hesaplama maliyeti düşük olan koşulların öncelikli olarak yer alması gerekir; böylece maliyeti yüksek hesaplamaları atlama olanağı sağlanabilir.
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çleri ortadan kaldırılmalıdır. Özünde, kullanılmayan herhangi bir hesaplama silinmelidir.
Ethereum'da geliştiriciler, depolama alanını serbest bırakarak Gas ödülleri alabilirler. Bir değişken artık gerekliyse, bunu 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 tekrarlanan 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 hashleme 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 sağlar.
Önceden derlenmiş sözleşmelerin örnekleri arasında Eliptik Eğri Dijital İmza Algoritması (ECDSA) ve SHA2-256 Hash Algoritması bulunur. Bu önceden derlenmiş sözleşmeleri akıllı sözleşmelerde kullanarak, geliştiriciler Gas maliyetlerini azaltabilir ve uygulamaların çalışma verimliliğini artırabilir.
3. Satır içi derleyici kodu kullanma
İç içe montaj ( in-line assembly ) geliştiricilerin EVM tarafından doğrudan yürütülebilen düşük seviyeli fakat verimli kod yazmalarına olanak tanır, pahalı Solidity işlem kodlarına ihtiyaç duymadan. İç içe montaj ayrıca bellek ve depolamanın kullanımını daha hassas bir şekilde kontrol etmeyi sağlar, 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 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 kolaydı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.
19 Likes
Reward
19
7
Repost
Share
Comment
0/400
AllInAlice
· 07-21 16:10
gas çok pahalı, artık dayanılmaz hale geldi.
View OriginalReply0
TopBuyerBottomSeller
· 07-21 00:35
gas gerçekten para alıyor ahh
View OriginalReply0
PoetryOnChain
· 07-20 06:30
gas çok pahalı, kim işlem yapacak?
View OriginalReply0
LightningClicker
· 07-18 19:09
Gece yarısı kodlama hep bunu öğreniyor.
View OriginalReply0
PerpetualLonger
· 07-18 19:05
gas düşmesin lütfen, pozisyon açamıyorum...
View OriginalReply0
FarmToRiches
· 07-18 18:53
Gaz çok pahalı, bireysel yatırımcılar hepsi kaçtı.
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 de ağ tıkalı olduğunda daha da belirgin hale gelir. Zirve dönemlerinde, kullanıcılar genellikle yüksek işlem ücretleri ödemek zorunda kalır. Bu nedenle, akıllı sözleşmeler geliştirme aşamasında Gas ücreti optimizasyonu son derece önemlidir. Gas tüketimini optimize etmek, yalnızca işlem maliyetlerini etkili bir şekilde düşürmekle kalmaz, aynı zamanda işlem verimliliğini artırır ve kullanıcılara daha ekonomik ve verimli bir blockchain deneyimi sunar.
Bu makalede, Ethereum sanal makinesi ( EVM )'in Gas ücreti mekanizması, Gas ücreti optimizasyonuna dair ilgili temel kavramlar ve akıllı sözleşmeler geliştirilirken Gas ücreti optimizasyonu için en iyi uygulamalar ele alınacaktır. Bu içeriklerin geliştiricilere ilham ve pratik yardım sağlaması, aynı zamanda sıradan kullanıcıların EVM'in Gas ücretleri işleyişini daha iyi anlamalarına yardımcı olması ve blok zinciri ekosistemindeki zorluklarla birlikte başa çıkmalarına katkıda bulunması umulmaktadır.
EVM'nin Gas Ücreti Mekanizması Hakkında Genel 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 üç parçaya 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 kaynakları gerektiğinden, sonsuz döngüler ve hizmet reddi ( DoS ) saldırılarını önlemek için belirli bir ücret alınacaktır. Bir işlemi tamamlamak için gereken ücret "Gas ücreti" olarak adlandırılır.
EIP-1559( Londra hard fork'u )'den itibaren yürürlüğe girdiğinden 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, böylece doğrulayıcıların işlemleri blok zincirine eklemeleri teşvik edilecektir. İşlem 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 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 kodu"ya, yani opcodes'e 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 gerçekleştirme ) için kabul görmüş bir Gas tüketim maliyeti vardır, bu maliyetler Ethereum beyaz 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ı ile farklılık gösterebilir.
2.Gas optimizasyonunun temel kavramı
Gas optimizasyonunun temel ilkesi, EVM blockchain'inde 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 daha düşüktür:
Maliyetli 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 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)'dan çok daha yüksektir. Bir akıllı sözleşme depolamadan veri okuduğunda veya yazdığında, yüksek Gaz maliyetleri oluşur.
Ethereum sarı kitabının tanımına göre, depolama işlemlerinin maliyeti bellek işlemlerinden 100 kat daha fazladır. Örneğin, OPcodesmload ve mstore talimatları yalnızca 3 Gas birimi tüketirken, depolama işlemleri olan sload ve sstore en ideal koşullarda bile en az 100 birim maliyet gerektirir.
Depolama kullanımını sınırlama yöntemleri şunlardır:
2. Değişken paketleme
akıllı sözleşmelerde kullanılan Storage slot( depolama slotunun) sayısı ve geliştiricilerin verileri gösterme ş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ını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 yuvasına sığabilmesini ifade eder.
Bu ayrıntı ayarı sayesinde, geliştiriciler 20.000 Gas birimini tasarruf edebilir. ( kullanılmamış bir depolama alanı depolamak için 20.000 Gas) tüketmekteydi, ancak şimdi sadece iki depolama alanına ihtiyaç var.
Her depolama slotu Gas harcadığı için, değişken paketleme gerekli depolama slotlarının 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 gelen 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 birimlerde 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 optimizasyonunu kullanırsak durum farklıdır. Geliştiriciler dört uint8 değişkenini bir depolama slotuna paketleyebilirse, onları 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şkenler kullanarak dinamik değişkenlerin yerine geçin.
Veri 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'den bytes32'ye en küçük uzunluğu seçin.
5. Haritalar ve diziler
Solidity verileri iki veri türü ile temsil edilebilir: dizi (Arrays ) ve harita (Mappings ), ancak sözdizimi ve yapıları tamamen farklıdır.
Haritalama, çoğu durumda daha yüksek verimlilik ve daha düşük maliyet sunar, ancak diziler yine de yinelemeye olanak tanır ve veri türlerini paketlemeyi destekler. Bu nedenle, veri listelerini yönetirken haritalamayı öncelikli olarak kullanmanız önerilir, yalnızca yinelemeye ihtiyaç duyuluyorsa veya veri türlerini paketleyerek Gas tüketimini optimize edebiliyorsanız istisna yapılmalıdır.
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 salt okunur ise, öncelikle calldata kullanmalısınız, memory yerine. Bu, fonksiyonun calldata'sından memory'ye gereksiz kopyalama işlemlerini önleyebilir.
7. Constant/Immutable anahtar kelimelerini mümkün olduğunca 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, depolamaya kıyasla erişim maliyetleri çok daha düşüktür, mümkün olduğunca Constant veya Immutable anahtar kelimelerini kullanmanız önerilir.
8. Overflow/underflow olmayacağından emin olduğunuzda Unchecked kullanın
Geliştiriciler, aritmetik işlemlerin taşma veya alt taşma ile sonuçlanmayacağını belirlediğinde, Solidity v0.8.0 ile tanıtılan unchecked anahtar kelimesini kullanarak gereksiz taşma veya alt taşma kontrollerinden kaçınabilir ve böylece Gas maliyetlerini azaltabilir.
Ayrıca, 0.8.0 ve üzeri sürümlerde derleyici artık SafeMath kütüphanesini kullanmayı gerektirmiyor, çünkü derleyici kendisi taşma ve alt taşma koruma işlevlerini yerleşik olarak sunmaktadır.
9. Optimizasyon Değiştiricisi
Değiştirici kodu, değiştirilmiş fonksiyonun içine gömülmüştür; her değiştirici kullanıldığında kod kopyalanır. Bu, byte kodunun boyutunu artırır ve Gas tüketimini yükseltir.
Bu örnekte, mantığın _checkOwner() iç fonksiyonu olarak yeniden yapılandırılması, bu iç fonksiyonun değiştiricide tekrar kullanılmasına izin vererek byte kodu boyutunu azaltabilir ve Gas maliyetlerini düşürebilir.
10. Kısa Devre Optimizasyonu
|| ve && operatörleri için, mantıksal işlemler kısa devre değerlendirmesi gerçekleştirir, yani eğer ilk koşul mantıksal ifadenin sonucunu belirleyebiliyorsa, ikinci koşul değerlendirilmeyecektir.
Gas tüketimini optimize etmek için, hesaplama maliyeti düşük olan koşulların öncelikli olarak yer alması gerekir; böylece maliyeti yüksek hesaplamaları atlama olanağı sağlanabilir.
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çleri ortadan kaldırılmalıdır. Özünde, kullanılmayan herhangi bir hesaplama silinmelidir.
Ethereum'da geliştiriciler, depolama alanını serbest bırakarak Gas ödülleri alabilirler. Bir değişken artık gerekliyse, bunu 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 tekrarlanan 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 hashleme 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 sağlar.
Önceden derlenmiş sözleşmelerin örnekleri arasında Eliptik Eğri Dijital İmza Algoritması (ECDSA) ve SHA2-256 Hash Algoritması bulunur. Bu önceden derlenmiş sözleşmeleri akıllı sözleşmelerde kullanarak, geliştiriciler Gas maliyetlerini azaltabilir ve uygulamaların çalışma verimliliğini artırabilir.
3. Satır içi derleyici kodu kullanma
İç içe montaj ( in-line assembly ) geliştiricilerin EVM tarafından doğrudan yürütülebilen düşük seviyeli fakat verimli kod yazmalarına olanak tanır, pahalı Solidity işlem kodlarına ihtiyaç duymadan. İç içe montaj ayrıca bellek ve depolamanın kullanımını daha hassas bir şekilde kontrol etmeyi sağlar, 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 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 kolaydır.