SatoshiTURK
Programmer
- BNB
- 0,00958379
Merhaba arkadaşlar, bu konu @Ajiba isimli kullanıcımızın isteği üzerine hazırlanmıştır.
Elimden geldiğince size örnekler ile anlatacağım, fakat şunu bilmenizde fayda var, burada anlatacağım bir çok şeyi youtube kanalımızda bulunan playlistlerde zaten değindim, fakat hangi konu hangi videoda bulamayabilirsiniz.
bu yüzden tek bir başlık altında yayımlamak daha mantıklı. Sizlerinde aklına gelen güvenlik önlemleri varsa lütfen sizde konuya katkıda bulunun.
Aşağıda 5 kural var bilmemiz gereken, kontratlarımızda bunlara en başta dikkat etmemiz gerekiyor, atladığım önemli hususlar varsa lütfen bildirin düzenleyelim gerekirse ekleme yapalım.
1 . Kural - Sürüm
Kontrat geliştirirken sürüm seçimi önemlidir.
pragma solidity ^0.8.0; ifadesi, 0.8.0 ve üzeri, ancak 0.9.0'dan düşük sürümlerle uyumlu olacağını belirtir.
2. Kural - Compile Versiyonu
3. Kural - Kod Temizliği, Bakımı ve Yorum Satırları Büyük Önem Taşır.
Şimdi arkadaşlar güvenlik konusuna derince girmeden önce bu neden önemli neden burada herkes hata yapıyor anlatayım 🙂
Biz bir proje yaptık Adı SatoshiTURK token veya Emlak Token, likidite sağladık herşeyi yaptık, artık projemiz tuttu 1m cmc cap oldu, Global bir borsada listeleyeceksiniz, güven sağlamak için Audit yaptırmak istiyorsunuz, işte burada sizin yazdığınız o dağınık kodlar güvenliği zayıf kontratlar patlıyor ve siz topluluğunuza Audit raporu sunamıyorsunuz, çünkü CertiK gibi firmalar sizin kodlarınızı detaylıca inceliyor ve rapor sunuyor buda sizin ne kadar ciddi adımlar attığınızı gösteriyor. unutmadan bu tarz kontratları bazı borsalar kabul etmiyor.
www.certik.com
Ben yinede size örnek bir rapor göstereyim.
Bakın bu kontrat en güvenli kontratlara bir örnek.
Bakın basit bir göz atın, Aşağıdaki Resimde
1 ile işaretli alan Kontratın ilk gönderim tarihi ve çözüme kavuştuğu tarihi gösteriyor 8 günde çözülmüş bu ekibin hızına bağlı tabiki.
2 ile işaretli alan ise kritik hatayı gösteriyor anlamı ise Mantık hatasının bulunduğu ve sonradan çözüldüğünü ifade ediyor.
Eğer büyük bir proje yapıyor ve bu gibi konulara önem veriyorsanız bunlara dikkat edin.
Peki yüksek skor için kurallar nelerdir.
4. Kural - Gas Optimizasyonu
5. Kural - Fonksiyonlar Ne Yapıyor Bilmelisiniz.
Şimdi hazır kontratlar kullanıyoruz, sağdan soldan kopyalıyoruz vs. fakat kontrat içerisindeki fonksiyonların neler yaptığını bilmeli ve bunlara hakim olmalısınız.
Örneğin deposit fonksiyonunuz var ve bu foksiyon payable özelliğini kullanıyor, yani dışarıdan her hangi birisi veya bir kontrat sizin kontratınıza Ether veya BNB gönderiyor, fakat ERC20 standartlarında Transfer işlevi kullanılır, doğal olarak sizin kontratınızda transfer işlevi yoksa gelen bakiyeyi kontrat nasıl yöneteceğini bilemez ve sorunlar baş gösterme başlar veya bir programcı Metamask veya benzeri bir cüzdan kullanmadan ether veya bnb gönderir.
Burada kontrata gelen bakiye veya varsa data verilerini sağlıklı yönetmelisiniz.
bunlar için detaylı bir video hazırladım fakat bu videoyu direk izlemek size pek bir şey kazandırmaz çünkü solidity ders videoları plasylistini komple izlemelisiniz ve fallback ayrıca receive işlevleri ile transfer veya dataları nasıl karşılayacağınıza kısacası transferleri nasıl yöneteceğinize karar vermenizi daha doğrusu kontratın karar vermesini sağlar.
ayrıca bu işlevlerin hatalı kullkanımlarıda büyük sorunlar oluşturabilir.
Bu videoda aslında transferlerin nasıl ele alabileceğinizi anlatıyorum fakat dediğim gibi solidity bilmiyorsanız size anlamsız gelecektir.
Buraya kadar temelde bilmemiz gerekenlerden bahsettim, şimdi biraz daha karmaşık konulara girelim, genel olarak kendi başımıza alabileceğimiz güvenlik önlemlerini bilelim.
Burada ERC20 standartları üzerinden gideceğim. Stanadar işlevlerde dikkat etmemiz gerekenler nelerdir, bunlara değineceğim. Fakat siz kendiniz yazıyorsanız kodlarınızı ne kadar uzman olursanız olun başka birinin incelemesi sizin için daha sağlıklı olacaktır.
ERC20 stanadartları gibi cümleleri eminim bir çok defa duymuşsunuzdur. Fakat hep böyle üzerinden geçmişsinizdir. Aşağıdaki videoyu izlemeniz gerekiyor. Çünkü standartları bilmiyorsanız bir çok problem ile karşılaşmanız an meselesi.
Aşağıdak işlev listesinide vereyim.
İşevler.
Eventlar.
1 - Reentry Attack
Şimdi bunu bir örnekle anlatalım arkadaşlar.
Ali, Elif'e bir hediye göndermek istiyor.
Bunun için postaneye gidiyor.
Fakat postane sistemine kötü niyetli bir çalışan girmiş.
Ali, Elif'e göndermek istediği hediyeyi paketler ve postaneye teslim eder.
Ancak, postane çalışanı, paketi alır almaz hızlıca bir kopyasını çıkarır ve üzerine kendi adresini yazar.
Sonra Ali'nin paketini postaneye geri verir.
Şimdi, Ali'nin asıl hediyeyi alması için normal bir işlem gerçekleşir.
Ancak kötü niyetli çalışanın yaptığı kopya işlemi de hızlıca postaneden yola çıkar.
Sonuç olarak, Elif, hem Ali'den gelen asıl hediyeyi alır, hem de güvenilmeyen çalışanın kopyasını alır.
Bu, postane sistemine kötü niyetli bir aracının, asıl işlemin yanında kendi amaçları doğrultusunda başka bir işlem gerçekleştirdiği bir durumu anlatır.
Önüne nasıl geçeriz?
Şimdi kodlama ile bunu anlatalım sonra openzeppelin kütüphanesinde nasıl kullanılır buna değinelim.
Böylelikle güvenliği ele almış oluruz.
Gelelelim openzeppelin kontratlarına, openzeppelin bu işlevi kütüphanesine ekledi fakat kullanıp kullanmamak size kalmış bir durum 🙂 örnek kullanım aşağıdadır ve bir modifer olarak çalışır.
aşağıdaki linkten standar bir token oluşturun. göreceksiniz koruma aktif değil, bunu sizin yapmanız gerekiyor.
Gelelim nasıul güvenliği sağlayacağımıza
Sanırım konuyu buraya kadar anladık, kafanıza takılan bir şey varsa sormalısınız arkadaşlar 🙂
2 - Mint Attack
Mint işlemini kısaca geçeceğim.
Genellikle, bir ERC-20 tokeni için sınırlı bir mint yetkisine sahip olmak tercih edilir.
Mint işlemi sırasında yaratılan token miktarının kontrol edilmesi gereklidir. Özellikle, beklenmedik bir şekilde çok fazla token yaratılması durumunda piyasa tepkisi olabilir veya kontratın sorunlar çıkartmasına sebebp olabilir.
Mint işlemlerinin izlenmesi ve denetlenmesi, potansiyel güvenlik risklerini azaltmada önemli bir rol oynar. Tüm mint işlemleri kaydedilmeli ve izlenmelidir. Bu, beklenmeyen veya şüpheli bir durumda hızlı bir şekilde müdahale edilmesini sağlar.
Mint yetkisi verilen kişilerin veya akıllı kontratların, güvenlik açıkları oluşturabilecek işlemleri gerçekleştirmediklerinden emin olunmalıdır. Bu nedenle, mint yetkisi verilen kişiler veya akıllı kontratlar için düzenli olarak güvenlik denetimleri ve güvenlik auditleri yapılmalıdır. Bu, sistemin güvenliğinin korunmasına ve potansiyel güvenlik risklerinin belirlenmesine yardımcı olur.
Kullanıcıların mint işlemleri hakkında bilgilendirilmesi ve işlem detaylarının şeffaf bir şekilde sunulması önemlidir. Kullanıcılar, yaratılan token miktarı ve mint işlemlerinin neden gerçekleştirildiği hakkında bilgi sahibi olmalıdır.
3 - Balina hareketlerini engellemek
Diyelim ki likidide sağladınız ve artık her şey yolunda gibi görünüyor, fakat max ve min alım ve satıma bir limit koymazsanız balina hareketlerinin önüne geçemezsiniz. Bu ani fiyat dalgalanmasının önüne geçer ve olabilecek art niyetli saldırıları minimuma indiri.
Ayrıca balinaların belirli tokenlerini kilitleyebilir ve kademeli hareket etmesini sağlayabilirsiniz. bu sizin kontrat üzerindeki mantığınıza dayalı bir yöntemdir.
4 - Integer Overflow/Underflow
Geldik en önemli konulardan birime Integer Overflow/Underflow bu yöntem baş belası olabilir. Integer overflow/underflow, bir işlem sonucunun beklenenden daha büyük veya daha küçük bir değere sahip olması durumudur. Bu durum, genellikle belirli bir veri türünün kapasitesini aşan veya altında kalan değerlerle ilgilidir. Özellikle Solidity gibi dillerde uint ve int veri türleri bu tür risklerle karşı karşıya kalabilir.
Zararları, Kayıplara yol açabilir, Veri bütünlüğünü bozabilir, Hani videolarda anlatmıştım arkadaşlar Storage olayları burada kaydedilen verileri bozabilirsiniz.
Örnek olması açısından iki işlev ekleyelim.
Bu işlev, iki değeri toplarken integer overflow/underflow riskini kontrol eder.
Toplam sonucun beklenenden büyük olması durumunda bir hata fırlatır.
Bu işlev, iki değeri toplarken integer overflow/underflow kontrolü yapmaz.
Bu nedenle, toplam sonucun beklenenden büyük veya daha küçük olması durumunda hatalara neden olabilir ve güvenlik açıklarına yol açabilir.
Arkadaşlar bir çok yöntem var, vampir ataktan tutunda flash botlara kadar fakat her birini bri günde anlatmak zor, bu yüzden konu altında özellikle sorabilirsiniz. Örneklerle anlatıız.
Umarım şlimdilik yeterli olmuştur, zamanım kısıtlı bu yüzden konuyu sabitliyorum, bu konuyu daha çok geliştireceğiz umarım. Hatalarım olduysa affola hızlı anlatmaya çalıştım...
Elimden geldiğince size örnekler ile anlatacağım, fakat şunu bilmenizde fayda var, burada anlatacağım bir çok şeyi youtube kanalımızda bulunan playlistlerde zaten değindim, fakat hangi konu hangi videoda bulamayabilirsiniz.
bu yüzden tek bir başlık altında yayımlamak daha mantıklı. Sizlerinde aklına gelen güvenlik önlemleri varsa lütfen sizde konuya katkıda bulunun.
Aşağıda 5 kural var bilmemiz gereken, kontratlarımızda bunlara en başta dikkat etmemiz gerekiyor, atladığım önemli hususlar varsa lütfen bildirin düzenleyelim gerekirse ekleme yapalım.
1 . Kural - Sürüm
Kontrat geliştirirken sürüm seçimi önemlidir.
- Güvenlik: Yeni sürümler, bilinen hataları ve güvenlik açıklarını düzeltir. Güncel sürümleri kullanmak, sözleşmenizin daha güvenli olmasını sağlar.
- Özellikler: Her yeni sürüm, dilin işlevselliğini genişleten yeni özellikler getirir. Bu özellikler, daha etkin ve optimize edilmiş sözleşmeler yazmanıza olanak tanır.
- Uyumluluk: Blockchain platformları ve araç setleri belirli Solidity sürümleriyle daha iyi çalışır. Uyumluluğu sağlamak için doğru sürümü kullanmak önemlidir.
pragma solidity ^0.8.0; ifadesi, 0.8.0 ve üzeri, ancak 0.9.0'dan düşük sürümlerle uyumlu olacağını belirtir.
2. Kural - Compile Versiyonu
- Uyumluluk: Derleyici sürümü, yazdığınız kodun syntax ve özelliklerle uyumlu olup olmadığını belirler. Eğer kodunuz belirli bir sürüm için yazılmışsa, o sürümle veya uyumlu sürümlerle derlenmesi gerekir.
- Güvenlik ve Stabilite: Derleyici sürümleri, güvenlik düzeltmeleri ve performans iyileştirmeleri içerebilir. Bu yüzden genellikle en güncel stabil sürümü kullanmak, güvenlik ve performans açısından avantaj sağlar.
- Kontrat Doğrulama Süreci: Buradaki sürüm ile kodunuzda bulunan pragma sürümü aynı değil ise Explorer yani block tarama sitelerinde kontrat doğrulama işlemini yapamazsınız.
3. Kural - Kod Temizliği, Bakımı ve Yorum Satırları Büyük Önem Taşır.
Şimdi arkadaşlar güvenlik konusuna derince girmeden önce bu neden önemli neden burada herkes hata yapıyor anlatayım 🙂
Biz bir proje yaptık Adı SatoshiTURK token veya Emlak Token, likidite sağladık herşeyi yaptık, artık projemiz tuttu 1m cmc cap oldu, Global bir borsada listeleyeceksiniz, güven sağlamak için Audit yaptırmak istiyorsunuz, işte burada sizin yazdığınız o dağınık kodlar güvenliği zayıf kontratlar patlıyor ve siz topluluğunuza Audit raporu sunamıyorsunuz, çünkü CertiK gibi firmalar sizin kodlarınızı detaylıca inceliyor ve rapor sunuyor buda sizin ne kadar ciddi adımlar attığınızı gösteriyor. unutmadan bu tarz kontratları bazı borsalar kabul etmiyor.
CertiK - Securing The Web3 World
CertiK is the leading security-focused ranking platform to analyze and monitor blockchain protocols and DeFi projects.
www.certik.com
Ben yinede size örnek bir rapor göstereyim.
Bakın bu kontrat en güvenli kontratlara bir örnek.
Bakın basit bir göz atın, Aşağıdaki Resimde
1 ile işaretli alan Kontratın ilk gönderim tarihi ve çözüme kavuştuğu tarihi gösteriyor 8 günde çözülmüş bu ekibin hızına bağlı tabiki.
2 ile işaretli alan ise kritik hatayı gösteriyor anlamı ise Mantık hatasının bulunduğu ve sonradan çözüldüğünü ifade ediyor.
Eğer büyük bir proje yapıyor ve bu gibi konulara önem veriyorsanız bunlara dikkat edin.
Peki yüksek skor için kurallar nelerdir.
- Kritik Riskler: Bu riskler, platformun güvenli işleyişini doğrudan etkileyebilir ve başlatılmadan önce ele alınmalıdır. Bu tür riskler genellikle yatırımcıların fonlarını doğrudan tehlikeye atabilir.
- Büyük Riskler: Bu kategori, merkezileşme sorunları ve mantıksal hataları içerebilir. Belirli koşullar altında, bu riskler fon kaybına veya projenin kontrolünün kaybına yol açabilir.
- Orta Dereceli Riskler: Bu tür riskler genellikle kullanıcıların fonlarına doğrudan zarar vermez, ancak platformun genel işleyişi üzerinde etkileri olabilir.
- Küçük Riskler: Genellikle projenin genel bütünlüğünü tehlikeye atmazlar, ancak diğer çözümlere göre daha az verimli olabilirler.
- Bilgilendirici Hatalar: Bu hatalar genellikle kod tarzını veya belirli işlemleri iyileştirmek için öneriler içerir ve genelde kodun işleyişini etkilemez.
- Yorum satırları: Bu hata değil fakat skoru etkileyen bir faktördür, her işlevin yni fonksiyonların input / output işlervlerini detaylıca yazmalısınız videolarda bahsetmiştim bunlardan.
4. Kural - Gas Optimizasyonu
- Kod Karmaşıklığı: Gas optimizasyonu çoğu zaman kodun daha karmaşık hale gelmesine neden olabilir. Karmaşık kodlar, hataların ve güvenlik açıklarının gözden kaçmasına yol açabilir. Örneğin, çok fazla iç içe geçmiş döngüler veya şartlar, mantıksal hatalara ve dolayısıyla güvenlik zafiyetlerine neden olabilir.
- Reentrancy Riski: Fonksiyon çağrılarını ve durum değişikliklerini gas tasarrufu amacıyla düzenlemek, reentrancy (yeniden giriş) saldırılarına kapı açabilir. Özellikle, call fonksiyonunu kullanarak işlem sırasını değiştirmek, saldırganların işlemlere müdahale etme şansını artırabilir.
- DoS (Denial of Service) Saldırıları: Gas optimizasyonu sırasında döngülerin kontrolsüz kullanılması, belirli koşullar altında işlemlerin aşırı maliyetli hale gelmesine ve böylece DoS saldırılarına yol açabilir.
- Daha Az Kontrol ve Doğrulama: Gas maliyetlerini düşürmek için bazı kontrol ve doğrulama adımlarının atlanması veya basitleştirilmesi, güvenlik zafiyetlerine yol açabilir. Örneğin, girdi doğrulamalarının azaltılması, beklenmedik veya zararlı girdilerin sisteme sızmasına izin verebilir.
5. Kural - Fonksiyonlar Ne Yapıyor Bilmelisiniz.
Şimdi hazır kontratlar kullanıyoruz, sağdan soldan kopyalıyoruz vs. fakat kontrat içerisindeki fonksiyonların neler yaptığını bilmeli ve bunlara hakim olmalısınız.
Örneğin deposit fonksiyonunuz var ve bu foksiyon payable özelliğini kullanıyor, yani dışarıdan her hangi birisi veya bir kontrat sizin kontratınıza Ether veya BNB gönderiyor, fakat ERC20 standartlarında Transfer işlevi kullanılır, doğal olarak sizin kontratınızda transfer işlevi yoksa gelen bakiyeyi kontrat nasıl yöneteceğini bilemez ve sorunlar baş gösterme başlar veya bir programcı Metamask veya benzeri bir cüzdan kullanmadan ether veya bnb gönderir.
Burada kontrata gelen bakiye veya varsa data verilerini sağlıklı yönetmelisiniz.
bunlar için detaylı bir video hazırladım fakat bu videoyu direk izlemek size pek bir şey kazandırmaz çünkü solidity ders videoları plasylistini komple izlemelisiniz ve fallback ayrıca receive işlevleri ile transfer veya dataları nasıl karşılayacağınıza kısacası transferleri nasıl yöneteceğinize karar vermenizi daha doğrusu kontratın karar vermesini sağlar.
ayrıca bu işlevlerin hatalı kullkanımlarıda büyük sorunlar oluşturabilir.
Bu videoda aslında transferlerin nasıl ele alabileceğinizi anlatıyorum fakat dediğim gibi solidity bilmiyorsanız size anlamsız gelecektir.
Buraya kadar temelde bilmemiz gerekenlerden bahsettim, şimdi biraz daha karmaşık konulara girelim, genel olarak kendi başımıza alabileceğimiz güvenlik önlemlerini bilelim.
Burada ERC20 standartları üzerinden gideceğim. Stanadar işlevlerde dikkat etmemiz gerekenler nelerdir, bunlara değineceğim. Fakat siz kendiniz yazıyorsanız kodlarınızı ne kadar uzman olursanız olun başka birinin incelemesi sizin için daha sağlıklı olacaktır.
ERC20 stanadartları gibi cümleleri eminim bir çok defa duymuşsunuzdur. Fakat hep böyle üzerinden geçmişsinizdir. Aşağıdaki videoyu izlemeniz gerekiyor. Çünkü standartları bilmiyorsanız bir çok problem ile karşılaşmanız an meselesi.
Aşağıdak işlev listesinide vereyim.
İşevler.
PHP:
function name() public view returns (string)
function symbol() public view returns (string)
function decimals() public view returns (uint8)
function totalSupply() public view returns (uint256)
function balanceOf(address _owner) public view returns (uint256 balance)
function transfer(address _to, uint256 _value) public returns (bool success)
function transferFrom(address _from, address _to, uint256 _value) public returns (bool success)
function approve(address _spender, uint256 _value) public returns (bool success)
function allowance(address _owner, address _spender) public view returns (uint256 remaining)Eventlar.
PHP:
event Transfer(address indexed _from, address indexed _to, uint256 _value)
event Approval(address indexed _owner, address indexed _spender, uint256 _value)1 - Reentry Attack
Şimdi bunu bir örnekle anlatalım arkadaşlar.
Ali, Elif'e bir hediye göndermek istiyor.
Bunun için postaneye gidiyor.
Fakat postane sistemine kötü niyetli bir çalışan girmiş.
Ali, Elif'e göndermek istediği hediyeyi paketler ve postaneye teslim eder.
Ancak, postane çalışanı, paketi alır almaz hızlıca bir kopyasını çıkarır ve üzerine kendi adresini yazar.
Sonra Ali'nin paketini postaneye geri verir.
Şimdi, Ali'nin asıl hediyeyi alması için normal bir işlem gerçekleşir.
Ancak kötü niyetli çalışanın yaptığı kopya işlemi de hızlıca postaneden yola çıkar.
Sonuç olarak, Elif, hem Ali'den gelen asıl hediyeyi alır, hem de güvenilmeyen çalışanın kopyasını alır.
Bu, postane sistemine kötü niyetli bir aracının, asıl işlemin yanında kendi amaçları doğrultusunda başka bir işlem gerçekleştirdiği bir durumu anlatır.
Önüne nasıl geçeriz?
Şimdi kodlama ile bunu anlatalım sonra openzeppelin kütüphanesinde nasıl kullanılır buna değinelim.
PHP:
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;
contract ReentrancyGuard {
// Reentrancy saldırılarına karşı koruma sağlayacak kilidi tanımlayalım
bool private locked;
// Constructor fonksiyonunda kilidi başlangıçta açık olarak ayarlayın false açık anlamına gelmektedir.
constructor() {
locked = false;
}
// Reentrancy koruması sağlayan modifier (değiştirici) tanımlayalım
modifier noReentrancy() {
require(!locked, "Reentrant call detected!");
locked = true;
_;
locked = false;
}
// Reentrancy koruması uygulanacak fonksiyon örneği
function secureWithdraw(uint amount) public noReentrancy {
// Para çekme işlemi burada gerçekleştirilir
// Örneğin, gönderenin bakiyesini azaltma, ether gönderme vs.
}
// Diğer işlevleri aşağıda yazmaya devam edebilirsiniz.
}- locked adında bir boolean değişken tanımlıyoruz. Bu değişken, reentrancy saldırılarına karşı korumayı sağlamak için kullanılır. Başlangıçta false değeriyle başlatılır, yani kilidin açık olduğunu gösterir.
- noReentrancy adında bir modifier tanımlıyoruz. Bu modifier, işlev çağrıldığında reentrancy saldırılarını engellemek için kullanılır. Modifier, işlevin başında locked değişkenini kontrol eder. Eğer locked değeri false ise işleve devam eder, sonra locked değerini true yapar ve işlev tamamlandıktan sonra tekrar false yapar.
- secureWithdraw adında bir fonksiyon tanımladık. Bu fonksiyon, reentrancy koruması ile işlevsel hale getirilmiştir. Yani bu fonksiyon çağrıldığında, reentrancy saldırılarına karşı korunaklı olur. Bu işlev, belirli bir miktarda para çekme işlemi gerçekleştirir.
Böylelikle güvenliği ele almış oluruz.
Gelelelim openzeppelin kontratlarına, openzeppelin bu işlevi kütüphanesine ekledi fakat kullanıp kullanmamak size kalmış bir durum 🙂 örnek kullanım aşağıdadır ve bir modifer olarak çalışır.
aşağıdaki linkten standar bir token oluşturun. göreceksiniz koruma aktif değil, bunu sizin yapmanız gerekiyor.
Gelelim nasıul güvenliği sağlayacağımıza
Sanırım konuyu buraya kadar anladık, kafanıza takılan bir şey varsa sormalısınız arkadaşlar 🙂
2 - Mint Attack
Mint işlemini kısaca geçeceğim.
Genellikle, bir ERC-20 tokeni için sınırlı bir mint yetkisine sahip olmak tercih edilir.
Mint işlemi sırasında yaratılan token miktarının kontrol edilmesi gereklidir. Özellikle, beklenmedik bir şekilde çok fazla token yaratılması durumunda piyasa tepkisi olabilir veya kontratın sorunlar çıkartmasına sebebp olabilir.
Mint işlemlerinin izlenmesi ve denetlenmesi, potansiyel güvenlik risklerini azaltmada önemli bir rol oynar. Tüm mint işlemleri kaydedilmeli ve izlenmelidir. Bu, beklenmeyen veya şüpheli bir durumda hızlı bir şekilde müdahale edilmesini sağlar.
Mint yetkisi verilen kişilerin veya akıllı kontratların, güvenlik açıkları oluşturabilecek işlemleri gerçekleştirmediklerinden emin olunmalıdır. Bu nedenle, mint yetkisi verilen kişiler veya akıllı kontratlar için düzenli olarak güvenlik denetimleri ve güvenlik auditleri yapılmalıdır. Bu, sistemin güvenliğinin korunmasına ve potansiyel güvenlik risklerinin belirlenmesine yardımcı olur.
Kullanıcıların mint işlemleri hakkında bilgilendirilmesi ve işlem detaylarının şeffaf bir şekilde sunulması önemlidir. Kullanıcılar, yaratılan token miktarı ve mint işlemlerinin neden gerçekleştirildiği hakkında bilgi sahibi olmalıdır.
3 - Balina hareketlerini engellemek
Diyelim ki likidide sağladınız ve artık her şey yolunda gibi görünüyor, fakat max ve min alım ve satıma bir limit koymazsanız balina hareketlerinin önüne geçemezsiniz. Bu ani fiyat dalgalanmasının önüne geçer ve olabilecek art niyetli saldırıları minimuma indiri.
Ayrıca balinaların belirli tokenlerini kilitleyebilir ve kademeli hareket etmesini sağlayabilirsiniz. bu sizin kontrat üzerindeki mantığınıza dayalı bir yöntemdir.
4 - Integer Overflow/Underflow
Geldik en önemli konulardan birime Integer Overflow/Underflow bu yöntem baş belası olabilir. Integer overflow/underflow, bir işlem sonucunun beklenenden daha büyük veya daha küçük bir değere sahip olması durumudur. Bu durum, genellikle belirli bir veri türünün kapasitesini aşan veya altında kalan değerlerle ilgilidir. Özellikle Solidity gibi dillerde uint ve int veri türleri bu tür risklerle karşı karşıya kalabilir.
Zararları, Kayıplara yol açabilir, Veri bütünlüğünü bozabilir, Hani videolarda anlatmıştım arkadaşlar Storage olayları burada kaydedilen verileri bozabilirsiniz.
Örnek olması açısından iki işlev ekleyelim.
Bu işlev, iki değeri toplarken integer overflow/underflow riskini kontrol eder.
Toplam sonucun beklenenden büyük olması durumunda bir hata fırlatır.
PHP:
// Olumlu işlev: Integer overflow/underflow kontrolü yapılıyor
function safeAdd(uint256 a, uint256 b) internal pure returns (uint256) {
uint256 c = a + b;
require(c >= a, "Integer overflow detected!");
return c;
}Bu işlev, iki değeri toplarken integer overflow/underflow kontrolü yapmaz.
Bu nedenle, toplam sonucun beklenenden büyük veya daha küçük olması durumunda hatalara neden olabilir ve güvenlik açıklarına yol açabilir.
PHP:
// Olumsuz işlev: Integer overflow/underflow kontrolü yapılmıyor
function unsafeAdd(uint256 a, uint256 b) internal pure returns (uint256) {
uint256 c = a + b;
return c;
}Arkadaşlar bir çok yöntem var, vampir ataktan tutunda flash botlara kadar fakat her birini bri günde anlatmak zor, bu yüzden konu altında özellikle sorabilirsiniz. Örneklerle anlatıız.
Umarım şlimdilik yeterli olmuştur, zamanım kısıtlı bu yüzden konuyu sabitliyorum, bu konuyu daha çok geliştireceğiz umarım. Hatalarım olduysa affola hızlı anlatmaya çalıştım...
