1. Ondalık sayılarla yapılan işlemlerin hassasiyet sorunu
Yaygın akıllı sözleşmeler programlama dili Solidity'den farklı olarak, Rust dili yerel olarak ondalık sayı hesaplamalarını desteklemektedir. Ancak, ondalık sayı hesaplamalarının kaçınılmaz hesaplama hassasiyeti sorunları vardır. Bu nedenle, akıllı sözleşme yazarken, özellikle önemli ekonomik veya finansal kararlarla ilgili oranlar veya faiz oranlarıyla ilgilenirken, ondalık sayı hesaplamalarının kullanılmasını önermemektedir.
Günümüzde ana akım programlama dilleri, kayan noktalı sayıları genellikle IEEE 754 standardına uygun olarak temsil eder ve Rust dili de bunun istisnası değildir. Çift hassasiyetli kayan nokta türü olan f64, bilgisayar içinde ikili veri biçiminde saklanır.
Kayan noktalı sayılar, tabanı 2 olan bilimsel gösterimle ifade edilir. Örneğin, sonlu basamaklı ikili sayı 0.1101, ondalık 0.8125'i temsil etmek için kullanılabilir. Ancak, 0.7 gibi ondalık sayılar için, kayan noktalı sayıya dönüştürme sürecinde sonsuz döngüsel ikili gösterimler oluşur; bu nedenle, sonlu uzunluktaki kayan noktalı sayılarla doğru bir şekilde temsil edilemez ve "yuvarlama" olayı meydana gelir.
0.7 token'un on kullanıcıya dağıtılması gerektiğini varsayalım, her bir kullanıcıya dağıtılan token miktarı result_0 değişkeninde saklanacaktır. İlgili test durumları çalıştırıldığında, amount'un değeri tam olarak 0.7'i değil, 0.69999999999999995559 gibi son derece yakın bir değeri göstermektedir. Ayrıca, amount/divisor'un tek bir bölme işleminin sonucu da beklenen 0.07 değil, tam olarak 0.06999999999999999 gibi kesin olmayan bir değere dönüşmektedir. Bu da kayan nokta hesaplamalarının belirsizliğini göstermektedir.
Buna göre, akıllı sözleşmelerde diğer tür sayı gösterim yöntemlerini, örneğin sabit nokta sayıları kullanmayı düşünmemiz gerekiyor. Gerçek akıllı sözleşme yazımında, genellikle belirli bir değeri ifade etmek için sabit bir paydası olan bir kesir kullanılır, örneğin kesir x/N, burada N sabit, x değişebilir.
Bazı kamu blok zincirlerinde, N'nin yaygın değeri 10^24'tür, yani 10^24 en küçük birim, 1 ana token birimine eşdeğerdir. Buna dayanarak, kesirli sayı hesaplamalarını tam sayı hesaplamalarına dönüştürerek daha doğru hesaplama sonuçları elde edebiliriz.
2. Rust tamsayı hesaplama hassasiyeti sorunu
Tam sayı hesaplamaları, bazı durumlarda kayan nokta hesaplamalarının doğruluk kaybı sorununu çözebilir. Ancak bu, tam sayı hesaplamalarının sonuçlarının tamamen doğru ve güvenilir olduğu anlamına gelmez. Tam sayı hesaplama doğruluğunu etkileyen bazı nedenler şunlardır:
2.1 İşlem Sırası
Aynı aritmetik önceliklere sahip çarpma ve bölme işlemlerinin sırasının değiştirilmesi doğrudan hesaplama sonucunu etkileyebilir ve tam sayı hesaplama hassasiyeti sorunlarına yol açabilir. Tam sayı bölme işlemi için, bölenin altındaki hassasiyet atılacaktır. Bu nedenle bazı hesaplama süreçlerinde, bölme işleminin önce yapılması hassasiyet kaybına yol açabilir.
2.2 çok küçük bir miktar
Sayıların çok küçük olduğu durumlarda, tam sayı işlemlerinde hassasiyet sorunları ortaya çıkabilir. Örneğin, bazı durumlarda, doğrudan tam sayı işlemi yapmak ile daha büyük bir ölçek getirdikten sonra işlem yapmak farklı sonuçlar verebilir.
3. Sayısal aktüeryalık için Rust akıllı sözleşmeler nasıl yazılır
Akıllı sözleşmelerdeki hesaplama hassasiyetini sağlamak için aşağıdaki koruma önlemleri alınabilir:
3.1 İşlem sırasını ayarlama
Tam sayı çarpımının, tam sayı bölümü öncelikli olmasına dikkat edin.
3.2 Tam sayıların büyüklüğünü artırma
Daha büyük bir ölçek kullanarak değerleri temsil edin, hesaplamalara daha büyük paylar dahil edin ve hassasiyeti artırın.
3.3 Kümülatif işlem hassasiyeti kaybı
Kaçınılmaz tam sayı hesaplama hassasiyeti sorunları için, birikmiş hesaplama hassasiyeti kaybını kaydetmeyi düşünebilirsiniz. Sonraki işlemlerde bu kayıpları dikkate alarak daha adil bir sonuç dağılımı sağlanabilir.
3.4 Rust Crate kütüphanesi rust-decimal kullanımı
Bu kütüphane, yüksek hassasiyetli hesaplamalar ve yuvarlama hatası olmayan ondalık finansal hesaplama senaryoları için uygundur.
3.5 Yuvarlama mekanizmasını dikkate alınız
Akıllı sözleşmeler tasarlanırken, yuvarlama sorunları genellikle "kendine avantaj sağlama, başkalarına dezavantaj verme" ilkesine uyar. Belirli durumlara göre aşağı yuvarlama, yukarı yuvarlama veya diğer uygun yuvarlama yöntemleri seçilir.
Bu önlemleri alarak, Rust akıllı sözleşmelerinde daha hassas sayısal hesaplamalar gerçekleştirilebilir ve hassasiyet sorunlarından kaynaklanan hatalar veya adaletsiz sonuçlar önlenebilir.
View Original
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.
Rust akıllı sözleşmeler içindeki sayısal hesaplama teknikleri: kayan nokta tuzaklarından kaçınma
Rust akıllı sözleşmeler yetiştirme günlüğü (7) Sayısal hesaplama
1. Ondalık sayılarla yapılan işlemlerin hassasiyet sorunu
Yaygın akıllı sözleşmeler programlama dili Solidity'den farklı olarak, Rust dili yerel olarak ondalık sayı hesaplamalarını desteklemektedir. Ancak, ondalık sayı hesaplamalarının kaçınılmaz hesaplama hassasiyeti sorunları vardır. Bu nedenle, akıllı sözleşme yazarken, özellikle önemli ekonomik veya finansal kararlarla ilgili oranlar veya faiz oranlarıyla ilgilenirken, ondalık sayı hesaplamalarının kullanılmasını önermemektedir.
Günümüzde ana akım programlama dilleri, kayan noktalı sayıları genellikle IEEE 754 standardına uygun olarak temsil eder ve Rust dili de bunun istisnası değildir. Çift hassasiyetli kayan nokta türü olan f64, bilgisayar içinde ikili veri biçiminde saklanır.
Kayan noktalı sayılar, tabanı 2 olan bilimsel gösterimle ifade edilir. Örneğin, sonlu basamaklı ikili sayı 0.1101, ondalık 0.8125'i temsil etmek için kullanılabilir. Ancak, 0.7 gibi ondalık sayılar için, kayan noktalı sayıya dönüştürme sürecinde sonsuz döngüsel ikili gösterimler oluşur; bu nedenle, sonlu uzunluktaki kayan noktalı sayılarla doğru bir şekilde temsil edilemez ve "yuvarlama" olayı meydana gelir.
0.7 token'un on kullanıcıya dağıtılması gerektiğini varsayalım, her bir kullanıcıya dağıtılan token miktarı result_0 değişkeninde saklanacaktır. İlgili test durumları çalıştırıldığında, amount'un değeri tam olarak 0.7'i değil, 0.69999999999999995559 gibi son derece yakın bir değeri göstermektedir. Ayrıca, amount/divisor'un tek bir bölme işleminin sonucu da beklenen 0.07 değil, tam olarak 0.06999999999999999 gibi kesin olmayan bir değere dönüşmektedir. Bu da kayan nokta hesaplamalarının belirsizliğini göstermektedir.
Buna göre, akıllı sözleşmelerde diğer tür sayı gösterim yöntemlerini, örneğin sabit nokta sayıları kullanmayı düşünmemiz gerekiyor. Gerçek akıllı sözleşme yazımında, genellikle belirli bir değeri ifade etmek için sabit bir paydası olan bir kesir kullanılır, örneğin kesir x/N, burada N sabit, x değişebilir.
Bazı kamu blok zincirlerinde, N'nin yaygın değeri 10^24'tür, yani 10^24 en küçük birim, 1 ana token birimine eşdeğerdir. Buna dayanarak, kesirli sayı hesaplamalarını tam sayı hesaplamalarına dönüştürerek daha doğru hesaplama sonuçları elde edebiliriz.
2. Rust tamsayı hesaplama hassasiyeti sorunu
Tam sayı hesaplamaları, bazı durumlarda kayan nokta hesaplamalarının doğruluk kaybı sorununu çözebilir. Ancak bu, tam sayı hesaplamalarının sonuçlarının tamamen doğru ve güvenilir olduğu anlamına gelmez. Tam sayı hesaplama doğruluğunu etkileyen bazı nedenler şunlardır:
2.1 İşlem Sırası
Aynı aritmetik önceliklere sahip çarpma ve bölme işlemlerinin sırasının değiştirilmesi doğrudan hesaplama sonucunu etkileyebilir ve tam sayı hesaplama hassasiyeti sorunlarına yol açabilir. Tam sayı bölme işlemi için, bölenin altındaki hassasiyet atılacaktır. Bu nedenle bazı hesaplama süreçlerinde, bölme işleminin önce yapılması hassasiyet kaybına yol açabilir.
2.2 çok küçük bir miktar
Sayıların çok küçük olduğu durumlarda, tam sayı işlemlerinde hassasiyet sorunları ortaya çıkabilir. Örneğin, bazı durumlarda, doğrudan tam sayı işlemi yapmak ile daha büyük bir ölçek getirdikten sonra işlem yapmak farklı sonuçlar verebilir.
3. Sayısal aktüeryalık için Rust akıllı sözleşmeler nasıl yazılır
Akıllı sözleşmelerdeki hesaplama hassasiyetini sağlamak için aşağıdaki koruma önlemleri alınabilir:
3.1 İşlem sırasını ayarlama
Tam sayı çarpımının, tam sayı bölümü öncelikli olmasına dikkat edin.
3.2 Tam sayıların büyüklüğünü artırma
Daha büyük bir ölçek kullanarak değerleri temsil edin, hesaplamalara daha büyük paylar dahil edin ve hassasiyeti artırın.
3.3 Kümülatif işlem hassasiyeti kaybı
Kaçınılmaz tam sayı hesaplama hassasiyeti sorunları için, birikmiş hesaplama hassasiyeti kaybını kaydetmeyi düşünebilirsiniz. Sonraki işlemlerde bu kayıpları dikkate alarak daha adil bir sonuç dağılımı sağlanabilir.
3.4 Rust Crate kütüphanesi rust-decimal kullanımı
Bu kütüphane, yüksek hassasiyetli hesaplamalar ve yuvarlama hatası olmayan ondalık finansal hesaplama senaryoları için uygundur.
3.5 Yuvarlama mekanizmasını dikkate alınız
Akıllı sözleşmeler tasarlanırken, yuvarlama sorunları genellikle "kendine avantaj sağlama, başkalarına dezavantaj verme" ilkesine uyar. Belirli durumlara göre aşağı yuvarlama, yukarı yuvarlama veya diğer uygun yuvarlama yöntemleri seçilir.
Bu önlemleri alarak, Rust akıllı sözleşmelerinde daha hassas sayısal hesaplamalar gerçekleştirilebilir ve hassasiyet sorunlarından kaynaklanan hatalar veya adaletsiz sonuçlar önlenebilir.