Ethereum akıllı sözleşmelerinin Gas optimizasyonu için en iyi uygulamalar
Ethereum ana ağındaki Gas ücretleri her zaman zor bir sorun olmuştur, özellikle de ağ yoğunlaştığında daha belirgin hale gelir. Zirve dönemlerinde, 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 makalede Ethereum sanal makinesi ( EVM )'in Gas ücreti mekanizması, Gas ücreti optimizasyonunun ilgili temel kavramları ve akıllı sözleşme geliştirirken Gas ücreti optimizasyonu için en iyi uygulamalar özetlenecektir. Bu içeriklerin geliştiricilere ilham ve pratik yardım sağlamasını, aynı zamanda sıradan kullanıcıların EVM'in Gas ücretleri çalışma şekmini daha iyi anlamalarına yardımcı olmasını umuyoruz, böylece blockchain ekosistemindeki zorluklarla birlikte başa çıkabiliriz.
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 birimdir.
EVM'nin yapı düzeninde, Gas tüketimi üç bölüme ayrılır: işlem yürütme, dış mesaj çağırma ve bellek ile depolamanın okuma/yazma işlemleri.
Her işlem gerçekleştirmek için hesaplama kaynakları gerektiğinden, sonsuz döngü 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'un yürürlüğe girmesinden bu yana, Gas ücreti aşağıdaki formülle hesaplanır:
Gaz ücreti = kullanılan gaz birimleri * ( taban ücreti + öncelik ücreti )
Temel ücret yok edilecek, ö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 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 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 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 kaydedilmiştir.
Birçok EIP değişikliğinden sonra, bazı opcode'ların Gas maliyetleri ayarlandı ve bu, sarı kitabın içeriğiyle bazı farklılıklar gösterebilir.
2.Gas optimize temel kavramı
Gas optimizasyonunun temel prensibi, EVM blok zincirinde maliyet etkinliği yüksek işlemleri önceliklendirmek 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
Sabitler ve değişmez değişkenler okumak
Yerel değişkenleri okuma yazma
calldata değişkenlerini oku, örneğin calldata dizileri ve yapıları
İç 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
Dış 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 Gaz ücreti optimizasyonu en iyi uygulamalar listesi derledik. Bu uygulamalara uyarak, geliştiriciler akıllı sözleşmelerin Gaz ü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. Her akıllı sözleşme depolamadan veri okuduğunda veya yazdığında, yüksek Gaz maliyetleri ortaya çıkar.
Ethereum sarı kitabının tanımına göre, depolama işleminin maliyeti bellek işlemlerinin maliyetinin 100 katından fazla. Örneğin, OPcodesmload ve mstore talimatları yalnızca 3 Gas birimi harcarken, depolama işlemleri olan sload ve sstore en ideal durumda bile maliyeti en az 100 birim gerektirir.
Depolama değişiklik sayısını azaltın: 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 bir depolama slotunu değişkenlerin saklandığı 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 slotuna sığabilmesini ifade eder.
Bu ayrıntı ayarlamaları sayesinde, geliştiriciler 20.000 Gas birimi tasarruf edebilir. ( kullanılmamış bir depolama alanı depolamak için 20.000 Gas) harcamak gerekiyordu, ancak şimdi yalnızca iki depolama alanına ihtiyaç var.
Her depolama kabının Gas tüketmesi nedeniyle, değişken paketleme, gereken depolama kabı 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 birimlerde 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 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 slotuna paketleyebilirse, bunları yinelemenin toplam maliyeti dört uint256 değişkeninden daha düşük olacaktır. Böylece, 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şkenlerin yerine kullanı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şkenlerden daha az Gas tüketir. Eğer bayt uzunluğu sınırlanabiliyorsa, bytes1 ile bytes32 arasındaki en küçük uzunluğu seçmeye çalışın.
5. Haritalama ve Diziler
Solidity'nin veri listesi iki veri tipi ile temsil edilebilir: dizi (Arrays ) ve harita (Mappings ), ancak bunların sözdizimi ve yapısı tamamen farklıdır.
Çoğu durumda, haritalama daha verimli ve maliyeti daha düşüktür, ancak diziler yineleyebilirlik sağlar ve veri türü paketlemeyi destekler. Bu nedenle, veri listelerini yönetirken haritalama kullanılması önerilir, yalnızca yinelemeye ihtiyaç duyuluyorsa veya veri türü paketlemesi ile Gaz tüketimi optimize edilebiliyorsa.
6. memory yerine calldata 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, calldata'nın ise değiştirilemez olmasıdır.
Bu prensibi unutmayın: Eğer fonksiyon parametreleri sadece okunabilir ise, öncelikle calldata kullanılmalıdır, memory yerine. Bu, fonksiyonun calldata'sından memory'e 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, depolama ile karşılaştırıldığında, erişim maliyetleri çok daha düşük olup, mümkünse Constant veya Immutable anahtar kelimelerinin kullanılması önerilir.
Geliştiriciler, aritmetik işlemlerin taşma veya alt taşma ile sonuçlanmayacağını belirleyebildiklerinde, fazla taşma veya alt taşma kontrolünden kaçınmak için Solidity v0.8.0 ile tanıtılan unchecked anahtar kelimesini kullanarak Gas maliyetlerini azaltabilirler.
Ayrıca, 0.8.0 ve üzeri sürümlerdeki derleyiciler artık SafeMath kütüphanesini kullanmayı gerektirmiyor, çünkü derleyici kendisi taşma ve alt taşma koruma işlevlerini içermektedir.
9. Optimizasyon Değiştirici
Değiştirici kodu, değiştirilmiş fonksiyona gömülmüştür; her değiştirici kullanıldığında, kodu kopyalanır. Bu, bytecode boyutunu artırır ve Gas tüketimini yükseltir.
İç fonksiyonu _checkOwner()'ye yeniden yapılandırarak, bu iç fonksiyonun modülatör 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şlemlerde kısa devre değerlendirmesi gerçekleşir; yani eğer birinci koşul mantıksal ifadenin sonucunu belirlemek için yeterliyse, ikinci koşul değerlendirilmez.
Gas tüketimini optimize etmek için, maliyeti düşük olan koşulların öncelikli olarak yer alması gerekir; böylece maliyeti yüksek olan hesaplamaları atlama olanağı doğabilir.
Ek Genel Öneriler
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şmenin 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 doğrudan bazı hesaplamaların sonuçları kullanılıyorsa, bu gereksiz hesaplama süreçlerinin ortadan kaldırılması gerekir. Esasen, kullanılmayan her hesaplama silinmelidir.
Ethereum'da, geliştiriciler depolama alanı serbest bırakarak Gas ödülü alabilirler. 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 birleştirin ve tekrarlayan hesaplamaları döngü gövdesinin dışına çıkarın.
2. Önceden derlenmiş akıllı sözleşmeler kullanma
Önceden derlenmiş sözleşmeler, şifreleme ve hash işlemleri gibi karmaşık kütüphane fonksiyonları sağlar. Kod, EVM'de değil, istemci düğümünde yerel olarak çalıştığı için gereken Gas miktarı daha azdır. Önceden derlenmiş sözleşmeler kullanmak, 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 azaltabilir ve uygulamaların çalışma verimliliğini artırabilir.
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
8
Repost
Share
Comment
0/400
SerumDegen
· 07-23 04:02
lmao gaz cüzdanımı boşaltıyor şu an... rekt af
View OriginalReply0
WalletDivorcer
· 07-21 18:08
Sözleşme optimizasyonunu görmek için bir el yeter.
View OriginalReply0
ProofOfNothing
· 07-20 15:12
gas parası yokken neyi konuşalım
View OriginalReply0
AlphaBrain
· 07-20 04:31
Boşver, gas'ı optimize etmeye üşeniyorum, L2'ye geç.
View OriginalReply0
ImpermanentLossEnjoyer
· 07-20 04:29
Kim 2000u'luk bir işlemin felaketini hatırlıyor?
View OriginalReply0
OvertimeSquid
· 07-20 04:19
Ticaret ücreti ödemek için mortgage'i geri ödemeniz gerekiyor.
Ethereum akıllı sözleşmeler Gas ücreti optimizasyon rehberi: En iyi on uygulama ve ipucu
Ethereum akıllı sözleşmelerinin Gas optimizasyonu için en iyi uygulamalar
Ethereum ana ağındaki Gas ücretleri her zaman zor bir sorun olmuştur, özellikle de ağ yoğunlaştığında daha belirgin hale gelir. Zirve dönemlerinde, 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 makalede Ethereum sanal makinesi ( EVM )'in Gas ücreti mekanizması, Gas ücreti optimizasyonunun ilgili temel kavramları ve akıllı sözleşme geliştirirken Gas ücreti optimizasyonu için en iyi uygulamalar özetlenecektir. Bu içeriklerin geliştiricilere ilham ve pratik yardım sağlamasını, aynı zamanda sıradan kullanıcıların EVM'in Gas ücretleri çalışma şekmini daha iyi anlamalarına yardımcı olmasını umuyoruz, böylece blockchain ekosistemindeki zorluklarla birlikte başa çıkabiliriz.
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 birimdir.
EVM'nin yapı düzeninde, Gas tüketimi üç bölüme ayrılır: işlem yürütme, dış mesaj çağırma ve bellek ile depolamanın okuma/yazma işlemleri.
Her işlem gerçekleştirmek için hesaplama kaynakları gerektiğinden, sonsuz döngü 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'un yürürlüğe girmesinden bu yana, Gas ücreti aşağıdaki formülle hesaplanır:
Gaz ücreti = kullanılan gaz birimleri * ( taban ücreti + öncelik ücreti )
Temel ücret yok edilecek, ö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 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 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 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 kaydedilmiştir.
Birçok EIP değişikliğinden sonra, bazı opcode'ların Gas maliyetleri ayarlandı ve bu, sarı kitabın içeriğiyle bazı farklılıklar gösterebilir.
2.Gas optimize temel kavramı
Gas optimizasyonunun temel prensibi, EVM blok zincirinde maliyet etkinliği yüksek işlemleri önceliklendirmek 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 Gas Ücretleri Optimizasyonu En İyi Uygulamaları
Yukarıda belirtilen temel kavramlara dayanarak, geliştirici topluluğu için bir Gaz ücreti optimizasyonu en iyi uygulamalar listesi derledik. Bu uygulamalara uyarak, geliştiriciler akıllı sözleşmelerin Gaz ü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. Her akıllı sözleşme depolamadan veri okuduğunda veya yazdığında, yüksek Gaz maliyetleri ortaya çıkar.
Ethereum sarı kitabının tanımına göre, depolama işleminin maliyeti bellek işlemlerinin maliyetinin 100 katından fazla. Örneğin, OPcodesmload ve mstore talimatları yalnızca 3 Gas birimi harcarken, depolama işlemleri olan sload ve sstore en ideal durumda bile maliyeti en az 100 birim 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 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 bir depolama slotunu değişkenlerin saklandığı 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 slotuna sığabilmesini ifade eder.
Bu ayrıntı ayarlamaları sayesinde, geliştiriciler 20.000 Gas birimi tasarruf edebilir. ( kullanılmamış bir depolama alanı depolamak için 20.000 Gas) harcamak gerekiyordu, ancak şimdi yalnızca iki depolama alanına ihtiyaç var.
Her depolama kabının Gas tüketmesi nedeniyle, değişken paketleme, gereken depolama kabı 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 birimlerde 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 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 slotuna paketleyebilirse, bunları yinelemenin toplam maliyeti dört uint256 değişkeninden daha düşük olacaktır. Böylece, 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şkenlerin yerine kullanı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şkenlerden daha az Gas tüketir. Eğer bayt uzunluğu sınırlanabiliyorsa, bytes1 ile bytes32 arasındaki en küçük uzunluğu seçmeye çalışın.
5. Haritalama ve Diziler
Solidity'nin veri listesi iki veri tipi ile temsil edilebilir: dizi (Arrays ) ve harita (Mappings ), ancak bunların sözdizimi ve yapısı tamamen farklıdır.
Çoğu durumda, haritalama daha verimli ve maliyeti daha düşüktür, ancak diziler yineleyebilirlik sağlar ve veri türü paketlemeyi destekler. Bu nedenle, veri listelerini yönetirken haritalama kullanılması önerilir, yalnızca yinelemeye ihtiyaç duyuluyorsa veya veri türü paketlemesi ile Gaz tüketimi optimize edilebiliyorsa.
6. memory yerine calldata 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, calldata'nın ise değiştirilemez olmasıdır.
Bu prensibi unutmayın: Eğer fonksiyon parametreleri sadece okunabilir ise, öncelikle calldata kullanılmalıdır, memory yerine. Bu, fonksiyonun calldata'sından memory'e 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, depolama ile karşılaştırıldığında, erişim maliyetleri çok daha düşük olup, mümkünse 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, fazla taşma veya alt taşma kontrolünden kaçınmak için Solidity v0.8.0 ile tanıtılan unchecked anahtar kelimesini kullanarak Gas maliyetlerini azaltabilirler.
Ayrıca, 0.8.0 ve üzeri sürümlerdeki derleyiciler artık SafeMath kütüphanesini kullanmayı gerektirmiyor, çünkü derleyici kendisi taşma ve alt taşma koruma işlevlerini içermektedir.
9. Optimizasyon Değiştirici
Değiştirici kodu, değiştirilmiş fonksiyona gömülmüştür; her değiştirici kullanıldığında, kodu kopyalanır. Bu, bytecode boyutunu artırır ve Gas tüketimini yükseltir.
İç fonksiyonu _checkOwner()'ye yeniden yapılandırarak, bu iç fonksiyonun modülatör 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şlemlerde kısa devre değerlendirmesi gerçekleşir; yani eğer birinci koşul mantıksal ifadenin sonucunu belirlemek için yeterliyse, ikinci koşul değerlendirilmez.
Gas tüketimini optimize etmek için, maliyeti düşük olan koşulların öncelikli olarak yer alması gerekir; böylece maliyeti yüksek olan hesaplamaları atlama olanağı doğabilir.
Ek Genel Öneriler
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şmenin 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 doğrudan bazı hesaplamaların sonuçları kullanılıyorsa, bu gereksiz hesaplama süreçlerinin ortadan kaldırılması gerekir. Esasen, kullanılmayan her hesaplama silinmelidir.
Ethereum'da, geliştiriciler depolama alanı serbest bırakarak Gas ödülü alabilirler. 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 birleştirin ve tekrarlayan hesaplamaları döngü gövdesinin dışına çıkarın.
2. Önceden derlenmiş akıllı sözleşmeler kullanma
Önceden derlenmiş sözleşmeler, şifreleme ve hash işlemleri gibi karmaşık kütüphane fonksiyonları sağlar. Kod, EVM'de değil, istemci düğümünde yerel olarak çalıştığı için gereken Gas miktarı daha azdır. Önceden derlenmiş sözleşmeler kullanmak, 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 azaltabilir ve uygulamaların çalışma verimliliğini artırabilir.