Akıllı Sözleşmeler Gas Optimizasyon Rehberi: 10 Büyük Uygulama ile İşlem Maliyetini Düşüş
Ethereum ana ağındaki Gas ücreti sorunu sürekli olarak ilgi görmektedir, özellikle ağın yoğun olduğu zamanlarda daha da belirgin hale gelmektedir. Zirve dönemlerinde kullanıcılar genellikle yüksek işlem ücretleri ödemek zorunda kalıyor. Bu nedenle, akıllı sözleşme geliştirme aşamasında Gas ücreti optimizasyonu son derece önemlidir. Gas tüketimini optimize etmek, yalnızca işlem maliyetini etkili bir şekilde düşürmekle 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 ücreti mekanizmasını, Gas ücreti optimizasyonuyla ilgili temel kavramları ve akıllı sözleşmeler geliştirirken Gas ücreti optimizasyonu için en iyi uygulamaları özetleyecektir. Bu içeriklerin geliştiricilere ilham vermesi ve pratik yardım sağlaması, aynı zamanda sıradan kullanıcıların EVM'in Gas maliyetleri işleyişini daha iyi anlamalarına yardımcı olması umulmaktadır; böylece blok zinciri ekosistemindeki zorluklarla birlikte mücadele edebiliriz.
EVM'nin Gas Ücreti Mekanizması Tanıtımı
EVM uyumlu ağlarda, "Gas", belirli işlemleri gerçekleştirmek için gerekli hesaplama gücünü ölçen bir birimdir.
EVM yapısında, Gas tüketimi esasen üç kısma ayrılır: işlem yürütme, dış mesaj çağrısı ve bellek ile depolamanın okuma/yazma işlemleri.
Her işlemin gerçekleştirilmesi için hesaplama kaynağı gerekmektedir, bu nedenle sonsuz döngü ve hizmet reddi ( DoS ) saldırılarını önlemek amacıyla belirli bir ücret alınır. Bir işlemin tamamlanması için gereken ücrete "Gas ücreti" denir.
EIP-1559'un yürürlüğe girmesinden bu yana, Gas ücreti aşağıdaki formülle hesaplanmaktadır:
Gaz ücreti = kullanılan gaz birimleri * ( temel ücret + öncelik ücreti )
Temel ücret yok edilecek, ö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 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.
EVM'deki Gas optimizasyonunu anlama
Solidity ile akıllı sözleşmeler derlendiğinde, sözleşme bir dizi "işlem kodu" ya da opcodes'a 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şim sağlama ve sanal makinede işlem yapma ) için tanınmış bir Gas tüketim maliyeti vardır, bu maliyetler Ethereum sarı kitabında kaydedilmiştir.
Birçok EIP'nin değişikliklerinden sonra, bazı işlem kodlarının Gas maliyetleri ayarlandı ve bu, sarı kitabın içeriğiyle farklılık gösterebilir.
Gaz optimizasyonunun temel kavramı
Gas optimizasyonunun temel ilkesi, EVM blok zincirinde maliyet verimliliği yüksek işlemleri öncelikli olarak seçmek, pahalı Gas maliyetine sahip işlemlerden kaçınmaktır.
EVM'de, aşağıdaki işlem maliyetleri daha düşüktür:
Bellek değişkenlerini okuma ve yazma
Sabitler ve değişmez değişkenler okumak
Yerel değişkenleri okumak ve yazmak
calldata değişkenini oku, örneğin calldata dizisi ve yapıları
Dahili fonksiyon çağrısı
Maliyetleri 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üsel İşlem
EVM Gas Ücretleri Optimizasyonu En İyi Uygulamaları
Yukarıda belirtilen temel kavramlara dayanarak, geliştirici topluluğu için bir Gas ücreti optimizasyonu en iyi uygulamalar listesi derledik. Bu uygulamaları takip ederek, geliştiriciler akıllı sözleşmelerin Gas ücreti tüketimini düşürebilir, işlem maliyetlerini azaltabilir 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( bellek)'den çok daha yüksektir. Her seferinde akıllı sözleşmeler 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şlemlerinden 100 kat daha fazladır. Örneğin, OPcodesmload ve mstore komutları yalnızca 3 Gas birimi tüketirken, sload ve sstore gibi depolama işlemlerinin maliyeti en ideal koşullarda bile en az 100 birim gerektirir.
Depolama değişiklik sayısını azaltma: Ara sonuçları bellekte tutarak, tüm hesaplamalar tamamlandıktan sonra sonuçları depolama değişkenlerine atama.
2. Değişken Paketleme
Akıllı sözleşmelerde kullanılan Storage slot ( depolama slotu ) sayısı ve geliştiricilerin verileri ifade etme şekli, Gas ü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şken depolamanın temel birimi olarak kullanır. Değişken paketleme, değişkenleri mantıklı bir şekilde düzenleyerek birden fazla değişkenin tek bir depolama yuvasına sığmasını sağlamak anlamına gelir.
Bu ayrıntı ayarı sayesinde, geliştiriciler 20.000 Gas birimi tasarruf edebilir. ( kullanılmamış bir depolama yuvası saklamak için 20.000 Gas ) harcamak gerekiyordu, ancak şimdi sadece iki depolama yuvası gerekiyor.
Her depolama yuvasının Gas tüketmesi nedeniyle, değişkenlerin paketlenmesi, gereken depolama yuvası sayısını azaltarak Gas kullanımını optimize eder.
3. Veri türlerini optimize etme
Bir değişken birden fazla veri türü ile temsil edilebilir, ancak farklı veri türlerinin 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, tamsayılar farklı boyutlara ayrılabilir: uint8, uint16, uint32 vb. EVM 256 bitlik birimlerle işlem yaptığından, 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, uint256 kullanımı uint8'den daha ucuzdur. Ancak, eğer değişkenlerin paketlenmesi optimize edilirse durum farklıdır. Eğer geliştirici 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şmeler bir depolama alanını bir kez okuyup yazabilir ve tek bir işlemde dört uint8 değişkenini bellek/depolama alanına alabilir.
4. Sabit boyutlu değişkenler kullanarak dinamik değişkenleri değiştirin
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şkenlerden 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. Harita ve Dizi
Solidity verilerinin listesi iki veri türü ile temsil edilebilir: diziler (Arrays ) ve haritalar (Mappings ), ancak bunların sözdizimi ve yapısı tamamen farklıdır.
Haritalama çoğu durumda daha verimli ve daha düşük maliyetli olsa da, diziler yine de yinelemeye ve veri türü paketlemeye destek verir. Bu nedenle, veri listelerini yönetirken haritalamayı öncelikli olarak kullanmanız önerilir, yalnızca yinelemeye ihtiyaç duyulursa veya veri türü paketlemesiyle Gas tüketimini optimize edebiliyorsanız.
6. calldata yerine memory kullanın
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, oysa calldata'nın değiştirilemez olmasıdır.
Bu prensibi unutmayın: Eğer fonksiyon parametreleri yalnızca okunabilir durumdaysa, öncelikle calldata kullanılmalı, memory yerine. Bu, fonksiyonun calldata'sından memory'ye gereksiz kopyalama işlemlerini önlemeye yardımcı olur.
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, mümkünse Constant veya Immutable anahtar kelimelerinin kullanılmasını öneririz.
Geliştiriciler, aritmetik işlemlerin taşma veya alt taşma ile sonuçlanmayacağını belirleyebildiğ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 maliyetini azaltabilir.
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 yerleşik olarak sunmaktadır.
9. Optimize Edici
Değiştirici kodu, değiştirilmiş fonksiyonun içine yerleştirilmiştir; her değiştirici kullanıldığında, bu kod kopyalanır. Bu, bytecode'un boyutunu artırır ve Gas tüketimini yükseltir.
Mantığı _checkOwner() adlı iç fonksiyona yeniden yapılandırarak, modifikatör içinde bu iç fonksiyonun tekrar kullanılmasına izin verilmesi, bytecode boyutunu azaltabilir ve İşlem Maliyeti üzerinde düşüş sağlayabilir.
10. Kısa yol 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 belirlemeye yeterliyse, ikinci koşul değerlendirilmez.
Gas tüketimini optimize etmek için, düşük maliyetli hesaplama koşullarının öncelikli hale getirilmesi gerekir; bu, maliyeti yüksek hesaplamaların atlanmasına olanak tanıyabilir.
Ek Genel Tavsiyeler
1. Gereksiz kodları kaldırın
Eğer sözleşmede kullanılmamış fonksiyonlar veya değişkenler varsa, bunların silinmesi önerilir. Bu, sözleşme dağıtım maliyetini düşürmenin ve sözleşmenin boyutunu küçük tutmanın en doğrudan yoludur.
Aşağıda bazı pratik öneriler var:
En etkili algoritmaları kullanarak hesaplama yapın. Eğer sözleşmede bazı hesaplamaların sonuçları doğrudan kullanılıyorsa, o zaman bu gereksiz hesaplama süreçleri kaldırılmalıdır. Temelde, kullanılmayan herhangi bir hesaplama silinmelidir.
Ethereum'da, geliştiriciler depolama alanı serbest bıraktıklarında Gas ödülü alabilirler. Bir değişkene artık ihtiyaç duyulmuyorsa, 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 tekrar eden 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 hash işlemleri gibi karmaşık kütüphane işlevleri sunar. Kod EVM üzerinde çalışmadığı için, yerel istemci düğümünde çalışır, bu nedenle gereken Gas daha azdır. Önceden derlenmiş sözleşmeler kullanarak, akıllı sözleşmelerin yürütülmesi için gereken hesaplama iş yükünü azaltarak Gas tasarrufu sağlanabilir.
Ö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 İşlem Maliyeti'nde düşüş sağlayabilir ve uygulamaların çalışma verimliliğini artırabilir.
3. Satır İçi 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ına olanak tanır ve pahalı Solidity işlem kodu kullanmalarını gerektirmez. İç içe montaj, ayrıca bellek ve depolama kullanımını daha hassas bir şekilde kontrol etmeye olanak tanır, böylece Gas maliyetini 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.
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.
11 Likes
Reward
11
4
Share
Comment
0/400
SilentObserver
· 07-20 19:53
gas bu kadar pahalı, ağlıyorum 555
View OriginalReply0
ConfusedWhale
· 07-20 19:53
Gündüz böyle harcanıyor, gece nasıl oynayacağız?
View OriginalReply0
NightAirdropper
· 07-20 19:48
eth, insanları enayi yerine koymak için yükseliş gas'ı.
10 büyük uygulama akıllı sözleşmeler Gas ücretini optimize etmeye yardımcı olur Eter işlem maliyetini düşüş
Akıllı Sözleşmeler Gas Optimizasyon Rehberi: 10 Büyük Uygulama ile İşlem Maliyetini Düşüş
Ethereum ana ağındaki Gas ücreti sorunu sürekli olarak ilgi görmektedir, özellikle ağın yoğun olduğu zamanlarda daha da belirgin hale gelmektedir. Zirve dönemlerinde kullanıcılar genellikle yüksek işlem ücretleri ödemek zorunda kalıyor. Bu nedenle, akıllı sözleşme geliştirme aşamasında Gas ücreti optimizasyonu son derece önemlidir. Gas tüketimini optimize etmek, yalnızca işlem maliyetini etkili bir şekilde düşürmekle 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 ücreti mekanizmasını, Gas ücreti optimizasyonuyla ilgili temel kavramları ve akıllı sözleşmeler geliştirirken Gas ücreti optimizasyonu için en iyi uygulamaları özetleyecektir. Bu içeriklerin geliştiricilere ilham vermesi ve pratik yardım sağlaması, aynı zamanda sıradan kullanıcıların EVM'in Gas maliyetleri işleyişini daha iyi anlamalarına yardımcı olması umulmaktadır; böylece blok zinciri ekosistemindeki zorluklarla birlikte mücadele edebiliriz.
EVM'nin Gas Ücreti Mekanizması Tanıtımı
EVM uyumlu ağlarda, "Gas", belirli işlemleri gerçekleştirmek için gerekli hesaplama gücünü ölçen bir birimdir.
EVM yapısında, Gas tüketimi esasen üç kısma ayrılır: işlem yürütme, dış mesaj çağrısı ve bellek ile depolamanın okuma/yazma işlemleri.
Her işlemin gerçekleştirilmesi için hesaplama kaynağı gerekmektedir, bu nedenle sonsuz döngü ve hizmet reddi ( DoS ) saldırılarını önlemek amacıyla belirli bir ücret alınır. Bir işlemin tamamlanması için gereken ücrete "Gas ücreti" denir.
EIP-1559'un yürürlüğe girmesinden bu yana, Gas ücreti aşağıdaki formülle hesaplanmaktadır:
Gaz ücreti = kullanılan gaz birimleri * ( temel ücret + öncelik ücreti )
Temel ücret yok edilecek, ö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 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.
EVM'deki Gas optimizasyonunu anlama
Solidity ile akıllı sözleşmeler derlendiğinde, sözleşme bir dizi "işlem kodu" ya da opcodes'a 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şim sağlama ve sanal makinede işlem yapma ) için tanınmış bir Gas tüketim maliyeti vardır, bu maliyetler Ethereum sarı kitabında kaydedilmiştir.
Birçok EIP'nin değişikliklerinden sonra, bazı işlem kodlarının Gas maliyetleri ayarlandı ve bu, sarı kitabın içeriğiyle farklılık gösterebilir.
Gaz optimizasyonunun temel kavramı
Gas optimizasyonunun temel ilkesi, EVM blok zincirinde maliyet verimliliği yüksek işlemleri öncelikli olarak seçmek, pahalı Gas maliyetine sahip işlemlerden kaçınmaktır.
EVM'de, aşağıdaki işlem maliyetleri daha düşüktür:
Maliyetleri 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 Gas ücreti optimizasyonu en iyi uygulamalar listesi derledik. Bu uygulamaları takip ederek, geliştiriciler akıllı sözleşmelerin Gas ücreti tüketimini düşürebilir, işlem maliyetlerini azaltabilir 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( bellek)'den çok daha yüksektir. Her seferinde akıllı sözleşmeler 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şlemlerinden 100 kat daha fazladır. Örneğin, OPcodesmload ve mstore komutları yalnızca 3 Gas birimi tüketirken, sload ve sstore gibi depolama işlemlerinin maliyeti en ideal koşullarda bile en az 100 birim gerektirir.
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 ) 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şken depolamanın temel birimi olarak kullanır. Değişken paketleme, değişkenleri mantıklı bir şekilde düzenleyerek birden fazla değişkenin tek bir depolama yuvasına sığmasını sağlamak anlamına gelir.
Bu ayrıntı ayarı sayesinde, geliştiriciler 20.000 Gas birimi tasarruf edebilir. ( kullanılmamış bir depolama yuvası saklamak için 20.000 Gas ) harcamak gerekiyordu, ancak şimdi sadece iki depolama yuvası gerekiyor.
Her depolama yuvasının Gas tüketmesi nedeniyle, değişkenlerin paketlenmesi, gereken depolama yuvası sayısını azaltarak Gas kullanımını optimize eder.
3. Veri türlerini optimize etme
Bir değişken birden fazla veri türü ile temsil edilebilir, ancak farklı veri türlerinin 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, tamsayılar farklı boyutlara ayrılabilir: uint8, uint16, uint32 vb. EVM 256 bitlik birimlerle işlem yaptığından, 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, uint256 kullanımı uint8'den daha ucuzdur. Ancak, eğer değişkenlerin paketlenmesi optimize edilirse durum farklıdır. Eğer geliştirici 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şmeler bir depolama alanını bir kez okuyup yazabilir ve tek bir işlemde dört uint8 değişkenini bellek/depolama alanına alabilir.
4. Sabit boyutlu değişkenler kullanarak dinamik değişkenleri değiştirin
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şkenlerden 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. Harita ve Dizi
Solidity verilerinin listesi iki veri türü ile temsil edilebilir: diziler (Arrays ) ve haritalar (Mappings ), ancak bunların sözdizimi ve yapısı tamamen farklıdır.
Haritalama çoğu durumda daha verimli ve daha düşük maliyetli olsa da, diziler yine de yinelemeye ve veri türü paketlemeye destek verir. Bu nedenle, veri listelerini yönetirken haritalamayı öncelikli olarak kullanmanız önerilir, yalnızca yinelemeye ihtiyaç duyulursa veya veri türü paketlemesiyle Gas tüketimini optimize edebiliyorsanız.
6. calldata yerine memory kullanın
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, oysa calldata'nın değiştirilemez olmasıdır.
Bu prensibi unutmayın: Eğer fonksiyon parametreleri yalnızca okunabilir durumdaysa, öncelikle calldata kullanılmalı, memory yerine. Bu, fonksiyonun calldata'sından memory'ye gereksiz kopyalama işlemlerini önlemeye yardımcı olur.
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, mümkünse Constant veya Immutable anahtar kelimelerinin kullanılmasını öneririz.
8. Taşma/alt taşma olmayacağından emin olunduğunda Unchecked kullanın
Geliştiriciler, aritmetik işlemlerin taşma veya alt taşma ile sonuçlanmayacağını belirleyebildiğ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 maliyetini azaltabilir.
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 yerleşik olarak sunmaktadır.
9. Optimize Edici
Değiştirici kodu, değiştirilmiş fonksiyonun içine yerleştirilmiştir; her değiştirici kullanıldığında, bu kod kopyalanır. Bu, bytecode'un boyutunu artırır ve Gas tüketimini yükseltir.
Mantığı _checkOwner() adlı iç fonksiyona yeniden yapılandırarak, modifikatör içinde bu iç fonksiyonun tekrar kullanılmasına izin verilmesi, bytecode boyutunu azaltabilir ve İşlem Maliyeti üzerinde düşüş sağlayabilir.
10. Kısa yol 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 belirlemeye yeterliyse, ikinci koşul değerlendirilmez.
Gas tüketimini optimize etmek için, düşük maliyetli hesaplama koşullarının öncelikli hale getirilmesi gerekir; bu, maliyeti yüksek hesaplamaların atlanmasına olanak tanıyabilir.
Ek Genel Tavsiyeler
1. Gereksiz kodları kaldırın
Eğer sözleşmede kullanılmamış fonksiyonlar veya değişkenler varsa, bunların silinmesi önerilir. Bu, sözleşme dağıtım maliyetini düşürmenin ve sözleşmenin boyutunu küçük tutmanın en doğrudan yoludur.
Aşağıda bazı pratik öneriler var:
En etkili algoritmaları kullanarak hesaplama yapın. Eğer sözleşmede bazı hesaplamaların sonuçları doğrudan kullanılıyorsa, o zaman bu gereksiz hesaplama süreçleri kaldırılmalıdır. Temelde, kullanılmayan herhangi bir hesaplama silinmelidir.
Ethereum'da, geliştiriciler depolama alanı serbest bıraktıklarında Gas ödülü alabilirler. Bir değişkene artık ihtiyaç duyulmuyorsa, 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 tekrar eden 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 hash işlemleri gibi karmaşık kütüphane işlevleri sunar. Kod EVM üzerinde çalışmadığı için, yerel istemci düğümünde çalışır, bu nedenle gereken Gas daha azdır. Önceden derlenmiş sözleşmeler kullanarak, akıllı sözleşmelerin yürütülmesi için gereken hesaplama iş yükünü azaltarak Gas tasarrufu sağlanabilir.
Ö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 İşlem Maliyeti'nde düşüş sağlayabilir ve uygulamaların çalışma verimliliğini artırabilir.
3. Satır İçi 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ına olanak tanır ve pahalı Solidity işlem kodu kullanmalarını gerektirmez. İç içe montaj, ayrıca bellek ve depolama kullanımını daha hassas bir şekilde kontrol etmeye olanak tanır, böylece Gas maliyetini 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.